diff options
| author | David Hankins <dhankins@isc.org> | 2007-05-08 23:05:22 +0000 |
|---|---|---|
| committer | David Hankins <dhankins@isc.org> | 2007-05-08 23:05:22 +0000 |
| commit | 98bd7ca0990e6d88e3345d3bc966ebe8216691a7 (patch) | |
| tree | c4437ca467e8f733d530170a5c445747b2defd68 /doc | |
| parent | 74dc3e0b2786c46956e7517398ae6f7c6dad52d7 (diff) | |
| download | isc-dhcp-98bd7ca0990e6d88e3345d3bc966ebe8216691a7.tar.gz | |
DHCPv6 branch merged to HEAD.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/Makefile | 29 | ||||
| -rw-r--r-- | doc/References.html | 804 | ||||
| -rw-r--r-- | doc/References.txt | 840 | ||||
| -rw-r--r-- | doc/References.xml | 668 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-authentication-14.txt | 893 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-dhcp-dns-12.txt | 1072 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-failover-12.txt | 7451 | ||||
| -rw-r--r-- | doc/rfc1542.txt | 1291 | ||||
| -rw-r--r-- | doc/rfc2131.txt | 2523 | ||||
| -rw-r--r-- | doc/rfc2132.txt | 1907 | ||||
| -rw-r--r-- | doc/rfc2485.txt | 227 | ||||
| -rw-r--r-- | doc/rfc2489.txt | 283 | ||||
| -rw-r--r-- | doc/rfc951.txt | 684 |
13 files changed, 2341 insertions, 16331 deletions
diff --git a/doc/Makefile b/doc/Makefile new file mode 100644 index 00000000..03b27dcf --- /dev/null +++ b/doc/Makefile @@ -0,0 +1,29 @@ +# Copyright (c) 2004-2006 by Internet Systems Consortium, Inc. ("ISC") +# Copyright (c) 1995-2003 by Internet Software Consortium +# +# 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. +# +# 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. +# +# Internet Systems Consortium, Inc. +# 950 Charter Street +# Redwood City, CA 94063 +# <info@isc.org> +# http://www.isc.org/ + +all: References.txt References.html + +References.txt: References.xml + xml2txt References.xml + +References.html: References.xml + xml2html References.xml + 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> diff --git a/doc/References.txt b/doc/References.txt new file mode 100644 index 00000000..8e656efe --- /dev/null +++ b/doc/References.txt @@ -0,0 +1,840 @@ + + + +ISC-DHCP-REFERENCES D. Hankins + ISC + August 2006 + + + ISC DHCP References Collection + + +Copyright Notice + + Copyright (c) 2006-2007 by Internet Systems Consortium, Inc. ("ISC") + + 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. + + 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. + +Abstract + + This document describes a collection of Reference material that ISC + DHCP has been implemented to. + + + + + + + + + + + + + + + + + + + + + + +Hankins [Page 1] + + ISC DHCP References Collection August 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. Definition: Reference Implementation . . . . . . . . . . . . . 3 + + 3. Low Layer References . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Ethernet Protocol References . . . . . . . . . . . . . . . 6 + 3.2. Token Ring Protocol References . . . . . . . . . . . . . . 6 + 3.3. FDDI Protocol References . . . . . . . . . . . . . . . . . 6 + 3.4. Internet Protocol Version 4 References . . . . . . . . . . 6 + 3.5. Unicast Datagram Protocol References . . . . . . . . . . . 6 + + 4. BOOTP Protocol References . . . . . . . . . . . . . . . . . . 6 + + 5. DHCP Protocol References . . . . . . . . . . . . . . . . . . . 7 + 5.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 7 + 5.1.1. Core Protocol References . . . . . . . . . . . . . . . 7 + 5.2. DHCPv6 Protocol References . . . . . . . . . . . . . . . . 7 + 5.3. DHCP Option References . . . . . . . . . . . . . . . . . . 8 + 5.3.1. Relay Agent Information Option Options . . . . . . . . 10 + 5.3.2. Dynamic DNS Updates References . . . . . . . . . . . . 10 + 5.3.3. Experimental: Failover References . . . . . . . . . . 10 + 5.4. DHCP Procedures . . . . . . . . . . . . . . . . . . . . . 11 + + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + +Hankins [Page 2] + + ISC DHCP References Collection August 2006 + + +1. Introduction + + 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). + + 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. + + +2. Definition: Reference Implementation + + 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. + + 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." + + 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. + + Anything else is a bug, the only question is whether the bug is in + reference or software (failing to implement the reference). + + This means: + + + +Hankins [Page 3] + + ISC DHCP References Collection August 2006 + + + o To produce new externally-visible behaviour, one must first + provide a reference. + + o Before changing externally visible behaviour to work around simple + incompatibilities in any other implementation, one must first + provide a reference. + + 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. + + 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". + + 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. + + +3. Low Layer References + + 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. + + 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. + + 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 RFC2131 [8]. + + 1. 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 + + + +Hankins [Page 4] + + ISC DHCP References Collection August 2006 + + + address yet) interface. + + 2. 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. + + 3. Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to + IP:remote-system LinkLayer:remote-system, without transmitting a + single ARP. + + 4. 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. + + 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, RFC2131 [8] very explicitly demands that + these packets' IP destination addresses be set to 255.255.255.255. + + 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. + + 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. + + 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. + + 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 + + + +Hankins [Page 5] + + ISC DHCP References Collection August 2006 + + + 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. + +3.1. Ethernet Protocol References + + 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 RFC894 [3] (see the section + titled "Packet format"), and the following URL is also thought to be + useful. + + http://en.wikipedia.org/wiki/DIX + +3.2. Token Ring Protocol References + + IEEE 802.5 defines the Token Ring framing format used by ISC DHCP. + +3.3. FDDI Protocol References + + RFC1188 [6] is the most helpful reference ISC DHCP has used to form + FDDI packets. + +3.4. Internet Protocol Version 4 References + + RFC760 [1] fundamentally defines the bare IPv4 protocol which ISC + DHCP implements. + +3.5. Unicast Datagram Protocol References + + RFC768 [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. + + +4. BOOTP Protocol References + + 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. + + The ISC DHCP server supports BOOTP clients conforming to RFC951 [4] + and RFC1542 [7]. + + + + +Hankins [Page 6] + + ISC DHCP References Collection August 2006 + + +5. DHCP Protocol References + +5.1. DHCPv4 Protocol + + "The DHCP[v4] Protocol" is not defined in a single document. The + following collection of references of what ISC DHCP terms "The DHCPv4 + Protocol". + +5.1.1. Core Protocol References + + RFC2131 [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. + + RFC2132 [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. + +5.2. DHCPv6 Protocol References + + For now there is only one document that specifies the DHCPv6 protocol + (there have been no updates yet), RFC3315 [21]. + + 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 + + + +Hankins [Page 7] + + ISC DHCP References Collection August 2006 + + + sending one. There is no relay support. + + DHCPv6 introduces some new and uncomfortable ideas to the common + software library. + + 1. Options of zero length are normal in DHCPv6. Currently, all ISC + DHCP software treats zero-length options as errors. + + 2. 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. + + 3. 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. + + Precisely how to correctly support the above conundrums has not quite + yet been settled, so support is incomplete. + +5.3. DHCP Option References + + RFC2241 [10] defines options for Novell Directory Services. + + RFC2242 [11] defines an encapsulated option space for NWIP + configuration. + + RFC2485 [12] defines the Open Group's UAP option. + + RFC2610 [13] defines options for the Service Location Protocol (SLP). + + RFC2937 [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. + + RFC3004 [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. + + + +Hankins [Page 8] + + ISC DHCP References Collection August 2006 + + + RFC3011 [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. + + RFC3319 [22] defines the SIP server options for DHCPv6. + + RFC3396 [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. + + RFC3397 [24] documents the Domain-Search Option, which allows the + configuration of the /etc/resolv.conf 'search' parameter in a way + that is RFC1035 [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. + + RFC3646 [27] documents the DHCPv6 name-servers and domain-search + options. + + RFC3633 [26] documents the Identity Association Prefix Delegation, + which is included here for protocol wire reference, but which is not + supported by ISC DHCP. + + RFC3679 [28] documents a number of options that were documented + earlier in history, but were not made use of. + + RFC3898 [29] documents four NIS options for delivering NIS servers + and domain information in DHCPv6. + + RFC3925 [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. + + RFC3942 [31] redefined the 'site local' option space. + + RFC4075 [32] defines the DHCPv6 SNTP Servers option. + + RFC4242 [33] defines the Information Refresh Time option, which + advises DHCPv6 Information-Request clients to return for updated + information. + + RFC4280 [34] defines two BCMS server options. + + RFC4388 [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. + + + +Hankins [Page 9] + + ISC DHCP References Collection August 2006 + + + RFC4580> [36] defines a DHCPv6 subscriber-id option, which is similar + in principle to the DHCPv4 relay agent option of the same name. + + RFC4649 [37] defines a DHCPv6 remote-id option, which is similar in + principle to the DHCPv4 relay agent remote-id. + +5.3.1. Relay Agent Information Option Options + + RFC3046 [18] defines the Relay Agent Information Option and provides + a number of sub-option definitions. + + RFC3256 [20] defines the DOCSIS Device Class sub-option. + + RFC3527 [25] defines the Link Selection sub-option. + +5.3.2. Dynamic DNS Updates References + + The collection of documents that describe the standards-based method + to update dns names of DHCP clients starts most easily with RFC4703 + [40] to define the overall architecture, travels through RFCs 4702 + [39] and 4704 [41] to describe the DHCPv4 and DHCPv6 FQDN options (to + carry the client name), and ends up at RFC4701 [38] which describes + the DHCID RR used in DNS to perform a kind of atomic locking. + + ISC DHCP adoped early versions of these documents, and has not yet + synched up with the final standards versions. + + 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. + + 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. + +5.3.3. Experimental: Failover References + + The Failover Protocol defines a means by which two DHCP Servers can + + + +Hankins [Page 10] + + ISC DHCP References Collection August 2006 + + + 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. + + 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. + + 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. + + draft-ietf-dhc-failover-12.txt [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. + + RFC3074 [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). + +5.4. DHCP Procedures + + RFC2939 [15] explains how to go about obtaining a new DHCP Option + code assignment. + +6. References + + [1] Postel, J., "DoD standard Internet Protocol", RFC 760, + January 1980. + + [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [3] Hornig, C., "Standard for the transmission of IP datagrams over + Ethernet networks", STD 41, RFC 894, April 1984. + + [4] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, + + + +Hankins [Page 11] + + ISC DHCP References Collection August 2006 + + + September 1985. + + [5] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [6] Katz, D., "Proposed Standard for the Transmission of IP + Datagrams over FDDI Networks", RFC 1188, October 1990. + + [7] Wimer, W., "Clarifications and Extensions for the Bootstrap + Protocol", RFC 1542, October 1993. + + [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [10] Provan, D., "DHCP Options for Novell Directory Services", + RFC 2241, November 1997. + + [11] Droms, R. and K. Fong, "NetWare/IP Domain Name and + Information", RFC 2242, November 1997. + + [12] Drach, S., "DHCP Option for The Open Group's User + Authentication Protocol", RFC 2485, January 1999. + + [13] Perkins, C. and E. Guttman, "DHCP Options for Service Location + Protocol", RFC 2610, June 1999. + + [14] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, + September 2000. + + [15] Droms, R., "Procedures and IANA Guidelines for Definition of + New DHCP Options and Message Types", BCP 43, RFC 2939, + September 2000. + + [16] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., + Beser, B., and J. Privat, "The User Class Option for DHCP", + RFC 3004, November 2000. + + [17] Waters, G., "The IPv4 Subnet Selection Option for DHCP", + RFC 3011, November 2000. + + [18] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, + January 2001. + + [19] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load + Balancing Algorithm", RFC 3074, February 2001. + + + +Hankins [Page 12] + + ISC DHCP References Collection August 2006 + + + [20] 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", + RFC 3256, April 2002. + + [21] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [22] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration + Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) + Servers", RFC 3319, July 2003. + + [23] Lemon, T. and S. Cheshire, "Encoding Long Options in the + Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, + November 2002. + + [24] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol + (DHCP) Domain Search Option", RFC 3397, November 2002. + + [25] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link + Selection sub-option for the Relay Agent Information Option for + DHCPv4", RFC 3527, April 2003. + + [26] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [27] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [28] Droms, R., "Unused Dynamic Host Configuration Protocol (DHCP) + Option Codes", RFC 3679, January 2004. + + [29] Kalusivalingam, V., "Network Information Service (NIS) + Configuration Options for Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3898, October 2004. + + [30] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic + Host Configuration Protocol version 4 (DHCPv4)", RFC 3925, + October 2004. + + [31] Volz, B., "Reclassifying Dynamic Host Configuration Protocol + version 4 (DHCPv4) Options", RFC 3942, November 2004. + + [32] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) + Configuration Option for DHCPv6", RFC 4075, May 2005. + + + +Hankins [Page 13] + + ISC DHCP References Collection August 2006 + + + [33] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time + Option for Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 4242, November 2005. + + [34] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host + Configuration Protocol (DHCP) Options for Broadcast and + Multicast Control Servers", RFC 4280, November 2005. + + [35] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol + (DHCP) Leasequery", RFC 4388, February 2006. + + [36] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, + June 2006. + + [37] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006. + + [38] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record + (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) + Information (DHCID RR)", RFC 4701, October 2006. + + [39] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host + Configuration Protocol (DHCP) Client Fully Qualified Domain + Name (FQDN) Option", RFC 4702, October 2006. + + [40] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain + Name (FQDN) Conflicts among Dynamic Host Configuration Protocol + (DHCP) Clients", RFC 4703, October 2006. + + [41] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", + RFC 4704, October 2006. + + [42] Droms, R., "DHCP Failover Protocol", March 2003. + + + + + + + + + + + + + + + + +Hankins [Page 14] + + ISC DHCP References Collection August 2006 + + +Author's Address + + David W. Hankins + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 423 1300 + Email: David_Hankins@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hankins [Page 15] + diff --git a/doc/References.xml b/doc/References.xml new file mode 100644 index 00000000..5500ef46 --- /dev/null +++ b/doc/References.xml @@ -0,0 +1,668 @@ +<?xml version='1.0' ?> + +<!-- $Id: References.xml,v 1.2 2007/05/08 23:05:21 dhankins Exp $ --> + +<?rfc private="ISC-DHCP-REFERENCES" ?> + +<?rfc toc="yes"?> + +<?rfc compact="yes"?> +<?rfc subcompact="no"?> +<?rfc tocompact="no"?> + +<!DOCTYPE rfc SYSTEM 'rfc2629bis.dtd' [ + <!ENTITY rfc760 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0760.xml'> + <!ENTITY rfc768 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'> + <!ENTITY rfc894 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml'> + <!ENTITY rfc951 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0951.xml'> + <!ENTITY rfc1035 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'> + <!ENTITY rfc1188 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1188.xml'> + <!ENTITY rfc1542 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1542.xml'> + <!ENTITY rfc2131 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'> + <!ENTITY rfc2132 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'> + <!ENTITY rfc2241 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2241.xml'> + <!ENTITY rfc2242 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2242.xml'> + <!ENTITY rfc2485 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2485.xml'> + <!ENTITY rfc2610 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2610.xml'> + <!ENTITY rfc2937 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2937.xml'> + <!ENTITY rfc2939 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml'> + <!ENTITY rfc3004 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3004.xml'> + <!ENTITY rfc3011 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3011.xml'> + <!ENTITY rfc3046 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'> + <!ENTITY rfc3074 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3074.xml'> + <!ENTITY rfc3256 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3256.xml'> + <!ENTITY rfc3315 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'> + <!ENTITY rfc3319 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3319.xml'> + <!ENTITY rfc3396 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'> + <!ENTITY rfc3397 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml'> + <!ENTITY rfc3527 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3527.xml'> + <!ENTITY rfc3633 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'> + <!ENTITY rfc3646 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml'> + <!ENTITY rfc3679 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3679.xml'> + <!ENTITY rfc3898 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3898.xml'> + <!ENTITY rfc3925 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3925.xml'> + <!ENTITY rfc3942 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml'> + <!ENTITY rfc4075 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4075.xml'> + <!ENTITY rfc4242 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml'> + <!ENTITY rfc4280 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4280.xml'> + <!ENTITY rfc4388 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4388.xml'> + <!ENTITY rfc4580 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml'> + <!ENTITY rfc4649 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml'> + <!ENTITY rfc4701 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701.xml'> + <!ENTITY rfc4702 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702.xml'> + <!ENTITY rfc4703 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703.xml'> + <!ENTITY rfc4704 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4704.xml'> +]> + +<rfc ipr="none"> + <front> + <title>ISC DHCP References Collection</title> + + <author initials="D.H." surname="Hankins" fullname="David W. Hankins"> + <organization abbrev="ISC">Internet Systems Consortium, + Inc. + </organization> + + <address> + <postal> + <street>950 Charter Street</street> + <city>Redwood City</city> + <region>CA</region> + <code>94063</code> + </postal> + + <phone>+1 650 423 1300</phone> + <email>David_Hankins@isc.org</email> + </address> + </author> + + <date month="August" year="2006"/> + + <note title="Copyright Notice"> + <t>Copyright (c) 2006-2007 by Internet Systems Consortium, Inc. + ("ISC")</t> + + <t>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.</t> + + <t>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.</t> + </note> + + <keyword>ISC</keyword> + <keyword>DHCP</keyword> + <keyword>Reference Implementation</keyword> + + <abstract> + <t>This document describes a collection of Reference material that + ISC DHCP has been implemented to.</t> + </abstract> + </front> + + <middle> + <section title="Introduction"> + <t>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).</t> + + <t>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.</t> + </section> + + <section title="Definition: Reference Implementation"> + <t>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.</t> + + <t>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."</t> + + <t>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.</t> + + <t>Anything else is a bug, the only question is whether the + bug is in reference or software (failing to implement the + reference).</t> + + <t>This means:</t> + + <list style="symbols"> + <t>To produce new externally-visible behaviour, one must first + provide a reference.</t> + + <t>Before changing externally visible behaviour to work around + simple incompatibilities in any other implementation, one must + first provide a reference.</t> + </list> + + <t>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.</t> + + <t>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".</t> + + <t>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.</t> + </section> + + <section title="Low Layer References"> + <t>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.</t> + + <t>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.</t> + + <t>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 <xref target="RFC2131">RFC2131</xref>.</t> + + <list style="numbers"> + <t>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.</t> + + <t>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.</t> + + <t>Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to + IP:remote-system LinkLayer:remote-system, without transmitting a + single ARP.</t> + + <t>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.</t> + </list> + + <t>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, <xref target="RFC2131"> + RFC2131</xref> very explicitly demands that these packets' IP + destination addresses be set to 255.255.255.255.</t> + + <t>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.</t> + + <t>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.</t> + + <t>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.</t> + + <t>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.</t> + + <section title="Ethernet Protocol References"> + <t>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 <xref target="RFC0894"> + RFC894</xref> (see the section titled "Packet format"), and + the following URL is also thought to be useful.</t> + + <t>http://en.wikipedia.org/wiki/DIX</t> + </section> + + <section title="Token Ring Protocol References"> + <t>IEEE 802.5 defines the Token Ring framing format used by ISC + DHCP.</t> + </section> + + <section title="FDDI Protocol References"> + <t><xref target="RFC1188">RFC1188</xref> is the most helpful + reference ISC DHCP has used to form FDDI packets.</t> + </section> + + <section title="Internet Protocol Version 4 References"> + <t><xref target="RFC0760">RFC760</xref> fundamentally defines the + bare IPv4 protocol which ISC DHCP implements.</t> + </section> + + <section title="Unicast Datagram Protocol References"> + <t><xref target="RFC0768">RFC768</xref> 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.</t> + </section> + </section> + + <section title="BOOTP Protocol References"> + <t>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.</t> + + <t>The ISC DHCP server supports BOOTP clients conforming to + <xref target="RFC0951">RFC951</xref> and <xref target="RFC1542"> + RFC1542</xref>.</t> + </section> + + <section title="DHCP Protocol References"> + <section title="DHCPv4 Protocol"> + <t>"The DHCP[v4] Protocol" is not defined in a single document. The + following collection of references of what ISC DHCP terms "The + DHCPv4 Protocol".</t> + + <section title="Core Protocol References"> + <t><xref target="RFC2131">RFC2131</xref> 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.</t> + + <t><xref target="RFC2132">RFC2132</xref> 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.</t> + </section> + </section> + + <section title="DHCPv6 Protocol References"> + <t>For now there is only one document that specifies the DHCPv6 + protocol (there have been no updates yet), <xref target="RFC3315"> + RFC3315</xref>.</t> + + <t>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.</t> + + <t>DHCPv6 introduces some new and uncomfortable ideas to the common + software library.</t> + + <list style="numbers"> + <t>Options of zero length are normal in DHCPv6. Currently, all + ISC DHCP software treats zero-length options as errors.</t> + + <t>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.</t> + + <t>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.</t> + </list> + + <t>Precisely how to correctly support the above conundrums has not + quite yet been settled, so support is incomplete.</t> + </section> + + <section title="DHCP Option References"> + <t><xref target="RFC2241">RFC2241</xref> defines options for + Novell Directory Services.</t> + + <t><xref target="RFC2242">RFC2242</xref> defines an encapsulated + option space for NWIP configuration.</t> + + <t><xref target="RFC2485">RFC2485</xref> defines the Open Group's + UAP option.</t> + + <t><xref target="RFC2610">RFC2610</xref> defines options for + the Service Location Protocol (SLP).</t> + + <t><xref target="RFC2937">RFC2937</xref> 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.</t> + + <t><xref target="RFC3004">RFC3004</xref> 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.</t> + + <t><xref target="RFC3011">RFC3011</xref> 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.</t> + + <t><xref target="RFC3319">RFC3319</xref> defines the SIP server + options for DHCPv6.</t> + + <t><xref target="RFC3396">RFC3396</xref> 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.</t> + + <t><xref target="RFC3397">RFC3397</xref> documents the Domain-Search + Option, which allows the configuration of the /etc/resolv.conf + 'search' parameter in a way that is <xref target="RFC1035">RFC1035 + </xref> wire format compatible (in fact, it uses the RFC1035 wire + format). ISC DHCP has both client and server support, and supports + RFC1035 name compression.</t> + + <t><xref target="RFC3646">RFC3646</xref> documents the DHCPv6 + name-servers and domain-search options.</t> + + <t><xref target="RFC3633">RFC3633</xref> documents the Identity + Association Prefix Delegation, which is included here for protocol + wire reference, but which is not supported by ISC DHCP.</t> + + <t><xref target="RFC3679">RFC3679</xref> documents a number of + options that were documented earlier in history, but were not + made use of.</t> + + <t><xref target="RFC3898">RFC3898</xref> documents four NIS options + for delivering NIS servers and domain information in DHCPv6.</t> + + <t><xref target="RFC3925">RFC3925</xref> 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.</t> + + <t><xref target="RFC3942">RFC3942</xref> redefined the 'site local' + option space.</t> + + <t><xref target="RFC4075">RFC4075</xref> defines the DHCPv6 SNTP + Servers option.</t> + + <t><xref target="RFC4242">RFC4242</xref> defines the Information + Refresh Time option, which advises DHCPv6 Information-Request + clients to return for updated information.</t> + + <t><xref target="RFC4280">RFC4280</xref> defines two BCMS server + options.</t> + + <t><xref target="RFC4388">RFC4388</xref> 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.</t> + + <t><xref target="RFC4580">RFC4580></xref> defines a DHCPv6 + subscriber-id option, which is similar in principle to the DHCPv4 + relay agent option of the same name.</t> + + <t><xref target="RFC4649">RFC4649</xref> defines a DHCPv6 remote-id + option, which is similar in principle to the DHCPv4 relay agent + remote-id.</t> + + <section title="Relay Agent Information Option Options"> + <t><xref target="RFC3046">RFC3046</xref> defines the Relay Agent + Information Option and provides a number of sub-option + definitions.</t> + + <t><xref target="RFC3256">RFC3256</xref> defines the DOCSIS Device + Class sub-option.</t> + + <t><xref target="RFC3527">RFC3527</xref> defines the Link Selection + sub-option.</t> + </section> + + <section title="Dynamic DNS Updates References"> + <t>The collection of documents that describe the standards-based + method to update dns names of DHCP clients starts most easily + with <xref target="RFC4703">RFC4703</xref> to define the overall + architecture, travels through RFCs <xref target="RFC4702">4702</xref> + and <xref target="RFC4704">4704</xref> to describe the DHCPv4 and + DHCPv6 FQDN options (to carry the client name), and ends up at + <xref target="RFC4701">RFC4701</xref> which describes the DHCID + RR used in DNS to perform a kind of atomic locking.</t> + + <t>ISC DHCP adoped early versions of these documents, and has not + yet synched up with the final standards versions.</t> + + <t>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.</t> + + <t>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.</t> + </section> + + <section title="Experimental: Failover References"> + <t>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.</t> + + <t>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.</t> + + <t>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.</t> + + <t><xref target="draft-failover">draft-ietf-dhc-failover-12.txt</xref> + 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.</t> + + <t><xref target="RFC3074">RFC3074</xref> 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).</t> + </section> + </section> + + <section title="DHCP Procedures"> + <t><xref target="RFC2939">RFC2939</xref> explains how to go about + obtaining a new DHCP Option code assignment.</t> + </section> + </section> + </middle> + + <back> + <references> + &rfc760; + &rfc768; + &rfc894; + &rfc951; + &rfc1035; + &rfc1188; + &rfc1542; + &rfc2131; + &rfc2132; + &rfc2241; + &rfc2242; + &rfc2485; + &rfc2610; + &rfc2937; + &rfc2939; + &rfc3004; + &rfc3011; + &rfc3046; + &rfc3074; + &rfc3256; + &rfc3315; + &rfc3319; + &rfc3396; + &rfc3397; + &rfc3527; + &rfc3633; + &rfc3646; + &rfc3679; + &rfc3898; + &rfc3925; + &rfc3942; + &rfc4075; + &rfc4242; + &rfc4280; + &rfc4388; + &rfc4580; + &rfc4649; + &rfc4701; + &rfc4702; + &rfc4703; + &rfc4704; + + <reference anchor='draft-failover'> + <front> + <title>DHCP Failover Protocol</title> + + <author initials='R.' surname='Droms' fullname='Ralph Droms'> + <organization abbrev='Cisco'>Cisco Systems</organization> + </author> + + <date month='March' year='2003'/> + </front> + <format type="TXT" octets="312151" target="http://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt"/> + </reference> + </references> + </back> +</rfc> + diff --git a/doc/draft-ietf-dhc-authentication-14.txt b/doc/draft-ietf-dhc-authentication-14.txt deleted file mode 100644 index 43a1f8ae..00000000 --- a/doc/draft-ietf-dhc-authentication-14.txt +++ /dev/null @@ -1,893 +0,0 @@ -Network Working Group R. Droms, Editor -INTERNET DRAFT Bucknell University -Obsoletes: draft-ietf-dhc-authentication-13.txt W. Arbaugh, Editor - University of Maryland - July 2000 - Expires December 2000 - - - Authentication for DHCP Messages - <draft-ietf-dhc-authentication-14.txt> - -Status of this memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt, and the list of - Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) provides a framework - for passing configuration information to hosts on a TCP/IP network. - In some situations, network administrators may wish to constrain the - allocation of addresses to authorized hosts. Additionally, some - network administrators may wish to provide for authentication of the - source and contents of DHCP messages. This document defines a new - DHCP option through which authorization tickets can be easily - generated and newly attached hosts with proper authorization can be - automatically configured from an authenticated DHCP server. - -1. Introduction - - DHCP [1] transports protocol stack configuration parameters from - centrally administered servers to TCP/IP hosts. Among those - parameters are an IP address. DHCP servers can be configured to - dynamically allocate addresses from a pool of addresses, eliminating - - - -Droms, Arbaugh [Page 1] - -DRAFT Authentication for DHCP Messages March 2000 - - - a manual step in configuration of TCP/IP hosts. - - Some network administrators may wish to provide authentication of the - source and contents of DHCP messages. For example, clients may be - subject to denial of service attacks through the use of bogus DHCP - servers, or may simply be misconfigured due to unintentionally - instantiated DHCP servers. Network administrators may wish to - constrain the allocation of addresses to authorized hosts to avoid - denial of service attacks in "hostile" environments where the network - medium is not physically secured, such as wireless networks or - college residence halls. - - This document defines a technique that can provide both entity - authentication and message authentication. - - DISCUSSION: - - This draft combines the original Schiller-Huitema-Droms - authentication mechanism defined in a previous Internet Draft with - the "delayed authentication" proposal developed by Bill Arbaugh. - -1.1 DHCP threat model - - The threat to DHCP is inherently an insider threat (assuming a - properly configured network where BOOTP ports are blocked on the - enterprise's perimeter gateways.) Regardless of the gateway - configuration, however, the potential attacks by insiders and - outsiders are the same. - - The attack specific to a DHCP client is the possibility of the - establishment of a "rogue" server with the intent of providing - incorrect configuration information to the client. The motivation for - doing so may be to establish a "man in the middle" attack or it may - be for a "denial of service" attack. - - There is another threat to DHCP clients from mistakenly or - accidentally configured DHCP servers that answer DHCP client requests - with unintentionally incorrect configuration parameters. - - The threat specific to a DHCP server is an invalid client - masquerading as a valid client. The motivation for this may be for - "theft of service", or to circumvent auditing for any number of - nefarious purposes. - - The threat common to both the client and the server is the resource - "denial of service" (DoS) attack. These attacks typically involve the - exhaustion of valid addresses, or the exhaustion of CPU or network - bandwidth, and are present anytime there is a shared resource. In - - - -Droms, Arbaugh [Page 2] - -DRAFT Authentication for DHCP Messages March 2000 - - - current practice, redundancy mitigates DoS attacks the best. - -1.2 Design goals - - These are the goals that were used in the development of the - authentication protocol, listed in order of importance: - - 1. Address the threats presented in Section 1.1. - 2. Avoid changing the current protocol. - 3. Limit state required by the server. - 4. Limit complexity (complexity breeds design and implementation - errors). - -1.3 Requirements Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [5]. - -1.4 DHCP Terminology - - This document uses the following terms: - - o "DHCP client" - - A DHCP client or "client" is an Internet host using DHCP to obtain - configuration parameters such as a network address. - - o "DHCP server" - - A DHCP server or "server" is an Internet host that returns - configuration parameters to DHCP clients. - -2. Format of the authentication option - - The following diagram defines the format of the DHCP - authentication option: - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Length | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RDM | Replay Detection (64 bits) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Replay cont. | | - +-+-+-+-+-+-+-+-+ | - - - -Droms, Arbaugh [Page 3] - -DRAFT Authentication for DHCP Messages March 2000 - - - | | - | Authentication Information | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - The code for the authentication option is TBD, and the length field - contains the length of the protocol, RDM, algorithm, Replay Detection - fields and authentication information fields in octets. - - The protocol field defines the particular technique for - authentication used in the option. New protocols are defined as - described in Section 6. - - The algorithm field defines the specific algorithm within the - technique identified by the protocol field. - - The Replay Detection field is per the RDM, and the authentication - information field is per the protocol in use. - - The Replay Detection Method (RDM) field determines the type of replay - detection used in the Replay Detection field. - - If the RDM field contains 0x00, the replay detection field MUST be - set to the value of a monotonically increasing counter. Using a - counter value such as the current time of day (e.g., an NTP-format - timestamp [4]) can reduce the danger of replay attacks. This - method MUST be supported by all protocols. - - Other values of the RDM field are reserved for future definition - according to the procedures described in section 6. - - This document defines two protocols in sections 4 and 5, encoded with - protocol field values 0 and 1. Protocol field values 2-254 are - reserved for future use. Other protocols may be defined according to - the procedure described in section 6. - -3. Interaction with Relay Agents - - Because a DHCP relay agent may alter the values of the 'giaddr' and - 'hops' fields in the DHCP message, the contents of those two fields - MUST be set to zero for the computation of any hash function over the - message header. Additionally, a relay agent may append the DHCP relay - agent information option 82 [7] as the last option in a message to - servers. If a server finds option 82 included in a received message, - the server MUST compute any hash function as if the option were NOT - included in the message without changing the order of options. - - - -Droms, Arbaugh [Page 4] - -DRAFT Authentication for DHCP Messages March 2000 - - - Whenever the server sends back option 82 to a relay agent, the server - MUST not include the option in the computation of any hash function - over the message. - - -4. Protocol 0 - - If the protocol field is 0, the authentication information field - holds a simple authentication token: - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0| Replay Detection (64 bits) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Replay cont. | | - +-+-+-+-+-+-+-+-+ | - | | - | Authentication Information | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - The authentication token is an opaque, unencoded value known to both - the sender and receiver. The sender inserts the authentication token - in the DHCP message and the receiver matches the token from the - message to the shared token. If the authentication option is present - and the token from the message does not match the shared token, the - receiver MUST discard the message. - - Protocol 0 may be used to pass a plain-text password and provides - only weak entity authentication and no message authentication. This - protocol is only useful for rudimentary protection against - inadvertently instantiated DHCP servers. - - DISCUSSION: - - The intent here is to pass a constant, non-computed token such as - a plain-text password. Other types of entity authentication using - computed tokens such as Kerberos tickets or one-time passwords - will be defined as separate protocols. - - -5. Protocol 1 - - - - -Droms, Arbaugh [Page 5] - -DRAFT Authentication for DHCP Messages March 2000 - - - If the protocol field is 1, the message is using the "delayed - authentication" mechanism. In delayed authentication, the client - requests authentication in its DHCPDISCOVER message and the server - replies with a DHCPOFFER message that includes authentication - information. This authentication information contains a nonce value - generated by the source as a message authentication code (MAC) to - provide message authentication and entity authentication. - - This document defines the use of a particular technique based on the - HMAC protocol [3] using the MD5 hash [2]. - -5.1 Management Issues - - The "delayed authentication" protocol does not attempt to address - situations where a client may roam from one administrative domain to - another, i.e. interdomain roaming. This protocol is focused on - solving the intradomain problem where the out-of-band exchange of a - shared secret is feasible. - -5.2 Format - - The format of the authentication request in a DHCPDISCOVER message - for protocol 1 is: - - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Length |0 0 0 0 0 0 0 1| Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RDM | Replay Detection (64 bits) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Replay cont. | - +-+-+-+-+-+-+-+-+ - - - The format of the authentication information for protocol 1 is: - - - - - - - - - - - - - -Droms, Arbaugh [Page 6] - -DRAFT Authentication for DHCP Messages March 2000 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Length |0 0 0 0 0 0 0 1| Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RDM | Replay Detection (64 bits) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Replay cont. | Secret ID (32 bits) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | secret id cont| HMAC-MD5 (128 bits) .... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - This document defines one technique for use with protocol 1, which is - identified by setting the algorithm field to 1. Other techniques - that use different algorithms may be defined by future - specifications, see section 6. The following definitions will be - used in the description of the authentication information for - protocol 1, algorithm 1: - - Replay Detection - as defined by the RDM field - K - a secret value shared between the source and - destination of the message; each secret has a - unique identifier (not shown in figures) - secret ID - the unique identifier for the secret value - used to generate the MAC for this message - HMAC-MD5 - the MAC generating function [3, 2]. - - The sender computes the MAC using the HMAC generation algorithm [3] - and the MD5 hash function [2]. The entire DHCP message (except as - noted below), including the DHCP message header and the options - field, is used as input to the HMAC-MD5 computation function. The - 'secret ID' field MUST be set to the identifier of the secret used to - generate the MAC. - - DISCUSSION: - - Algorithm 1 specifies the use of HMAC-MD5. Use of a different - technique, such as HMAC-SHA, will be specified as a separate - protocol. - - Protocol 1 requires a shared secret key for each client on each - DHCP server with which that client may wish to use the DHCP - protocol. Each secret key has a unique identifier that can be - used by a receiver to determine which secret was used to generate - the MAC in the DHCP message. Therefore, protocol 1 may not scale - well in an architecture in which a DHCP client connects to - multiple administrative domains. - - - -Droms, Arbaugh [Page 7] - -DRAFT Authentication for DHCP Messages March 2000 - - - Note that the meaning of an authentication option can be changed - by removing the secret ID, and MAC, transforming an authentication - option with authentication information into a request for - authentication. Therefore, the authentication request form of - this option can only appear in a DHCPDISCOVER message or a - DHCPINFORM message. - -5.3 Message validation - - To validate an incoming message, the receiver first checks that - the value in the replay detection field is acceptable according to - the replay detection method specified by the RDM field. Next, the - receiver computes the MAC as described in [3]. The receiver MUST - set the 'MAC' field of the authentication option to all 0s for - computation of the MAC, and because a DHCP relay agent may alter - the values of the 'giaddr' and 'hops' fields in the DHCP message, - the contents of those two fields MUST also be set to zero for the - computation of the MAC. If the MAC computed by the receiver does - not match the MAC contained in the authentication option, the - receiver MUST discard the DHCP message. - - Section 3 provides additional information on handling messages - that include option 82 (Relay Agents). - -5.4 Key utilization - - Each DHCP client has a key, K. The client uses its key to encode - any messages it sends to the server and to authenticate and verify - any messages it receives from the server. The client's key SHOULD - be initially distributed to the client through some out-of-band - mechanism, and SHOULD be stored locally on the client for use in - all authenticated DHCP messages. Once the client has been given - its key, it SHOULD use that key for all transactions even if the - client's configuration changes; e.g., if the client is assigned a - new network address. - - Each DHCP server MUST know, or be able to obtain in a secure - manner, the keys for all authorized clients. If all clients use - the same key, clients can perform both entity and message - authentication for all messages received from servers. However, - the sharing of keys is strongly discouraged as it allows for - unauthorized clients to masquerade as authorized clients by - obtaining a copy of the shared key. To authenticate the identity - of individual clients, each client MUST be configured with a - unique key. Appendix A describes a technique for key management. - -5.5 Client considerations - - - - -Droms, Arbaugh [Page 8] - -DRAFT Authentication for DHCP Messages March 2000 - - - This section describes the behavior of a DHCP client using - authentication protocol 1. - -5.5.1 INIT state - - When in INIT state, the client uses protocol 1 as follows: - - 1. The client MUST include the authentication request option in - its DHCPDISCOVER message along with option 61 [6] to identify - itself uniquely to the server. - - 2. The client MUST validate any DHCPOFFER messages that include - authentication information using the mechanism specified in - section 5.3. The client MUST discard any messages which fail - to pass validation and MAY log the validation failure. The - client selects one DHCPOFFER message as its selected - configuration. If none of the DHCPOFFER messages received by - the client include authentication information, the client MAY - choose an unauthenticated message as its selected - configuration. The client SHOULD be configurable to accept or - reject unauthenticated DHCPOFFER messages. - 3. The client replies with a DHCPREQUEST message that MUST include - authentication information encoded with the same secret used by - the server in the selected DHCPOFFER message. - 4. The client MUST validate the DHCPACK message from the server. - The client MUST discard the DHCPACK if the message fails to - pass validation and MAY log the validation failure. If the - DHCPACK fails to pass validation, the client MUST revert to - INIT state and returns to step 1. The client MAY choose to - remember which server replied with a DHCPACK message that - failed to pass validation and discard subsequent messages from - that server. - -5.5.2 INIT-REBOOT state - - When in INIT-REBOOT state, the client MUST use the secret it used - in its DHCPREQUEST message to obtain its current configuration to - generate authentication information for the DHCPREQUEST message. - The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK - messages if no authenticated messages were received. The client - MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK - messages as specified in section 3.2 of [1]. - -5.5.3 RENEWING state - - When in RENEWING state, the client uses the secret it used in its - initial DHCPREQUEST message to obtain its current configuration to - generate authentication information for the DHCPREQUEST message. - - - -Droms, Arbaugh [Page 9] - -DRAFT Authentication for DHCP Messages March 2000 - - - If client receives no DHCPACK messages or none of the DHCPACK - messages pass validation, the client behaves as if it had not - received a DHCPACK message in section 4.4.5 of the DHCP - specification [1]. - -5.5.4 REBINDING state - - When in REBINDING state, the client uses the secret it used in its - initial DHCPREQUEST message to obtain its current configuration to - generate authentication information for the DHCPREQUEST message. - If client receives no DHCPACK messages or none of the DHCPACK - messages pass validation, the client behaves as if it had not - received a DHCPACK message in section 4.4.5 of the DHCP - specification [1]. - -5.5.5 DHCPINFORM message - - Since the client already has some configuration information, the - client may also have established a shared secret value, K, with a - server. Therefore, the client SHOULD use the authentication - request as in a DHCPDISCOVER message when a shared secret value - exists. The client MUST treat any received DHCPACK messages as it - does DHCPOFFER messages, see section 5.5.1. - -5.5.6 DHCPRELEASE message - - Since the client is already in the BOUND state, the client will - have a security association already established with the server. - Therefore, the client MUST include authentication information with - the DHCPRELEASE message. - -5.6 Server considerations - - This section describes the behavior of a server in response to - client messages using authentication protocol 1. - -5.6.1 General considerations - - Each server maintains a list of secrets and identifiers for those - secrets that it shares with clients and potential clients. This - information must be maintained in such a way that the server can: - - * Identify an appropriate secret and the identifier for that - secret for use with a client that the server may not have - previously communicated with - * Retrieve the secret and identifier used by a client to which the - server has provided previous configuration information - - - - -Droms, Arbaugh [Page 10] - -DRAFT Authentication for DHCP Messages March 2000 - - - Each server MUST save the counter from the previous authenticated - message. A server MUST discard any incoming message which fails - the replay detection check as defined by the RDM avoid replay - attacks. - - DISCUSSION: - - The authenticated DHCPREQUEST message from a client in INIT- - REBOOT state can only be validated by servers that used the - same secret in their DHCPOFFER messages. Other servers will - discard the DHCPREQUEST messages. Thus, only servers that used - the secret selected by the client will be able to determine - that their offered configuration information was not selected - and the offered network address can be returned to the server's - pool of available addresses. The servers that cannot validate - the DHCPREQUEST message will eventually return their offered - network addresses to their pool of available addresses as - described in section 3.1 of the DHCP specification [1]. - -5.6.2 After receiving a DHCPDISCOVER message - - The server selects a secret for the client and includes - authentication information in the DHCPOFFER message as specified - in section 5, above. The server MUST record the identifier of the - secret selected for the client and use that same secret for - validating subsequent messages with the client. - -5.6.3 After receiving a DHCPREQUEST message - - The server uses the secret identified in the message and validates - the message as specified in section 5.3. If the message fails to - pass validation or the server does not know the secret identified - by the 'secret ID' field, the server MUST discard the message and - MAY choose to log the validation failure. - - If the message passes the validation procedure, the server - responds as described in the DHCP specification. The server MUST - include authentication information generated as specified in - section 5.2. - -5.6.4 After receiving a DHCPINFORM message - - The server MAY choose to accept unauthenticated DHCPINFORM - messages, or only accept authenticated DHCPINFORM messages based - on a site policy. - - When a client includes the authentication request in a DHCPINFORM - message, the server MUST respond with an authenticated DHCPACK - - - -Droms, Arbaugh [Page 11] - -DRAFT Authentication for DHCP Messages March 2000 - - - message. If the server does not have a shared secret value - established with the sender of the DHCPINFORM message, then the - server MAY respond with an unauthenticated DHCPACK message, or a - DHCPNAK if the server does not accept unauthenticated clients - based on the site policy, or the server MAY choose not to respond - to the DHCPINFORM message. - -6. IANA Considerations - - The author of a new DHCP authentication protocol, algorithm or - replay detection method will follow these steps to obtain - acceptance of the new procedure as a part of the DHCP Internet - Standard: - - 1. The author devises the new authentication protocol, algorithm - or replay detection method. - 2. The author documents the new technique as an Internet Draft. - The protocol, algorithm or RDM code for any new procedure is - left as "To Be Determined" (TBD). - 3. The author submits the Internet Draft for review through the - IETF standards process as defined in "Internet Official - Protocol Standards" (STD 1). - 4. The new protocol progresses through the IETF standards process; - the specification of the new protocol will be reviewed by the - Dynamic Host Configuration Working Group (if that group still - exists), or as an Internet Draft not submitted by an IETF - working group. If the option is accepted as a Standard, the - specification for the option is published as a separate RFC. - 5. At the time of acceptance as a Proposed Internet Standard and - publication as an RFC, IANA assigns a DHCP authentication - protocol number to the new protocol. - - This procedure for defining new authentication protocols will - ensure that: - - * allocation of new protocol numbers is coordinated from a single - authority, - * new protocols are reviewed for technical correctness and - appropriateness, and - * documentation for new protocols is complete and published. - - - DISCUSSION: - This procedure is patterned after the procedure for acceptance - of new DHCP options. - -7. References - - - - -Droms, Arbaugh [Page 12] - -DRAFT Authentication for DHCP Messages March 2000 - - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - Bucknell University, March 1997. - - [2] Rivest, R., "The MD5 Message-Digest Algorithm", - RFC-1321, April 1992. - - [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for - Message Authentication," RFC-2104, February 1997. - - [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March - 1992. - - [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels," RFC-2219, March 1997. - - [6] Henry, M., "DHCP Option 61 UUID Type Definition," - <draft-henry-DHCP-opt61-UUID-type-00.txt> (work in - progress, November 1998. - - [7] Patrick, M., "DHCP Relay Agent Information Option," - <draft-ietf-dhc-agent-options-05.txt> (work in progress), - November 1998. - - [8] Gupta, V., "Flexible Authentication for DHCP Messages," - <draft-gupta-dhcp-auth-00.txt> (work in progress, June - 1998. - -8. Acknowledgments - - Jeff Schiller and Christian Huitema developed this scheme during a - terminal room BOF at the Dallas IETF meeting, December 1995. The - editor transcribed the notes from that discussion, which form the - basis for this document. The editor appreciates Jeff's and - Christian's patience in reviewing this document and its earlier - drafts. - - The "delayed authentication" mechanism used in section 5 is due to - Bill Arbaugh. The threat model and requirements in sections 1.1 - and 1.2 come from Bill's negotiation protocol proposal. The - attendees of an interim meeting of the DHC WG held in June, 1998, - including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill - Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, - Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike - Dooley, Greg Rabil and Arun Kapur, developed the threat model and - reviewed several alternative proposals. - - The replay detection method field is due to Vipul Gupta [8]. - - - - -Droms, Arbaugh [Page 13] - -DRAFT Authentication for DHCP Messages March 2000 - - - Other input from Bill Sommerfield is gratefully acknowledged. - - Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas - Narten for reviewing earlier drafts of this document. - -9. Security considerations - - This document describes authentication and verification mechanisms - for DHCP. - -10. Editors' addresses - - Ralph Droms - Computer Science Department - 323 Dana Engineering - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - Bill Arbaugh - Department of Computer Science - University of Maryland - A.V. Williams Building - College Park, MD 20742 - - Phone: (301) 455-2774 - Email: waa@cs.umd.edu - -10. Expiration - - This document will expire on December 31, 2000. - - - - - - - - - - - - - - - - - - -Droms, Arbaugh [Page 14] - -DRAFT Authentication for DHCP Messages March 2000 - - - Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of developing - Internet standards in which case the procedures for copyrights defined - in the Internet Standards process must be followed, or as required to - translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT - NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN - WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - -Droms, Arbaugh [Page 15] - -DRAFT Authentication for DHCP Messages March 2000 - - - Appendix A - Key Management Technique - - To avoid centralized management of a list of random keys, suppose K - for each client is generated from the pair (client identifier [6], - subnet address, e.g. 192.168.1.0), which must be unique to that - client. That is, K = MAC(MK, unique-id), where MK is a secret master - key and MAC is a keyed one-way function such as HMAC-MD5. - - Without knowledge of the master key MK, an unauthorized client cannot - generate its own key K. The server can quickly validate an incoming - message from a new client by regenerating K from the client-id. For - known clients, the server can choose to recover the client's K - dynamically from the client-id in the DHCP message, or can choose to - precompute and cache all of the Ks a priori. - - To avoid compromis of this key management system, the master key, MK, - MUST NOT be stored by any clients. The client SHOULD only be given - its key, K. If MK is compromised, a new MK SHOULD be chosen and all - clients given new individual keys. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms, Arbaugh [Page 16] - diff --git a/doc/draft-ietf-dhc-dhcp-dns-12.txt b/doc/draft-ietf-dhc-dhcp-dns-12.txt deleted file mode 100644 index c97ba625..00000000 --- a/doc/draft-ietf-dhc-dhcp-dns-12.txt +++ /dev/null @@ -1,1072 +0,0 @@ - - -DHC Working Group M. Stapp -Internet-Draft Y. Rekhter -Expires: September 2000 Cisco Systems, Inc. - March 10, 2000 - - - Interaction between DHCP and DNS - <draft-ietf-dhc-dhcp-dns-12.txt> - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - To view the entire list of Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 2000. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - DHCP provides a powerful mechanism for IP host configuration. - However, the configuration capability provided by DHCP does not - include updating DNS, and specifically updating the name to address - and address to name mappings maintained in the DNS. - - This document specifies how DHCP clients and servers should use the - Dynamic DNS Updates mechanism in RFC2136[5] to update the DNS name - to address and address to name mappings so that the mappings for - DHCP clients will be consistent with the IP addresses that the - clients acquire via DHCP. - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 1] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 - 4. Issues with DDNS in DHCP Environments . . . . . . . . . . . 4 - 4.1 Name Collisions . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2 Multiple DHCP servers . . . . . . . . . . . . . . . . . . . 6 - 4.3 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6 - 4.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . 6 - 4.4 DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Client FQDN Option . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 9 - 5.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 10 - 5.3 The Domain Name Field . . . . . . . . . . . . . . . . . . . 10 - 6. DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 10 - 7. DHCP Server behavior . . . . . . . . . . . . . . . . . . . . 12 - 8. Procedures for performing DNS updates . . . . . . . . . . . 14 - 8.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 14 - 8.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 15 - 8.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . 15 - 8.4 Updating other RRs . . . . . . . . . . . . . . . . . . . . . 16 - 9. Security Considerations . . . . . . . . . . . . . . . . . . 16 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 - - - - - - - - - - - - - - - - - - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 2] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119[6]. - -2. Introduction - - DNS (RFC1034[1], RFC1035[2]) maintains (among other things) the - information about mapping between hosts' Fully Qualified Domain - Names (FQDNs) RFC1594[4] and IP addresses assigned to the hosts. The - information is maintained in two types of Resource Records (RRs): A - and PTR. The A RR contains mapping from a FQDN to an IP address; the - PTR RR contains mapping from an IP address to a FQDN. The Dynamic - DNS Updates specification (RFC2136[5]) describes a mechanism that - enables DNS information to be updated over a network. - - DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client) - can acquire certain configuration information, along with its IP - address(es). However, DHCP does not provide any mechanisms to update - the DNS RRs that contain the information about mapping between the - host's FQDN and its IP address(es) (A and PTR RRs). Thus the - information maintained by DNS for a DHCP client may be incorrect - a - host (the client) could acquire its address by using DHCP, but the A - RR for the host's FQDN wouldn't reflect the address that the host - acquired, and the PTR RR for the acquired address wouldn't reflect - the host's FQDN. - - The Dynamic DNS Update protocol can be used to maintain consistency - between the information stored in the A and PTR RRs and the actual - address assignment done via DHCP. When a host with a particular FQDN - acquires its IP address via DHCP, the A RR associated with the - host's FQDN would be updated (by using the Dynamic DNS Updates - protocol) to reflect the new address. Likewise, when an IP address - is assigned to a host with a particular FQDN, the PTR RR associated - with this address would be updated (using the Dynamic DNS Updates - protocol) to reflect the new FQDN. - - Although this document refers to the A and PTR DNS record types and - to DHCP assignment of IPv4 addresses, the same procedures and - requirements apply for updates to the analogous RR types that are - used when clients are assigned IPv6 addresses via DHCPv6. - -3. Models of Operation - - When a DHCP client acquires a new address, a site's administrator - may desire that one or both of the A RR for the client's FQDN and - the PTR RR for the acquired address be updated. Therefore, two - separate Dynamic DNS Update transactions occur. Acquiring an address - - -Stapp & Rekhter Expires September 2000 [Page 3] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - via DHCP involves two entities: a DHCP client and a DHCP server. In - principle each of these entities could perform none, one, or both of - the transactions. However, in practice not all permutations make - sense. This document covers these possible design permutations: - - 1. DHCP client updates the A RR, DHCP server updates the PTR RR - 2. DHCP server updates both the A and the PTR RRs - - The only difference between these two cases is whether the FQDN to - IP address mapping is updated by a DHCP client or by a DHCP server. - The IP address to FQDN mapping is updated by a DHCP server in both - cases. - - The reason these two are important, while others are unlikely, has - to do with authority over the respective DNS domain names. A DHCP - client may be given authority over mapping its own A RRs, or that - authority may be restricted to a server to prevent the client from - listing arbitrary addresses or associating its address with - arbitrary domain names. In all cases, the only reasonable place for - the authority over the PTR RRs associated with the address is in the - DHCP server that allocates the address. - - In any case, whether a site permits all, some, or no DHCP servers - and clients to perform DNS updates into the zones which it controls - is entirely a matter of local administrative policy. This document - does not require any specific administrative policy, and does not - propose one. The range of possible policies is very broad, from - sites where only the DHCP servers have been given credentials that - the DNS servers will accept, to sites where each individual DHCP - client has been configured with credentials which allow the client - to modify its own domain name. Compliant implementations MAY support - some or all of these possibilities. Furthermore, this specification - applies only to DHCP client and server processes: it does not apply - to other processes which initiate dynamic DNS updates. - - This document describes a new DHCP option which a client can use to - convey all or part of its domain name to a DHCP server. - Site-specific policy determines whether DHCP servers use the names - that clients offer or not, and what DHCP servers may do in cases - where clients do not supply domain names. - -4. Issues with DDNS in DHCP Environments - - There are two DNS update situations that require special - consideration in DHCP environments: cases where more than one DHCP - client has been configured with the same FQDN, and cases where more - than one DHCP server has been given authority to perform DNS updates - in a zone. In these cases, it is possible for DNS records to be - modified in inconsistent ways unless the updaters have a mechanism - that allows them to detect anomolous situations. If DNS updaters can - - -Stapp & Rekhter Expires September 2000 [Page 4] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - detect these situations, site administrators can configure the - updaters' behavior so that the site's policies can be enforced. We - use the term "Name Collisions" to refer to cases where more than one - DHCP client has been associated with a single FQDN. This - specification describes a mechanism designed to allow updaters to - detect these situations, and requires that DHCP implementations use - this mechanism by default. - -4.1 Name Collisions - - How can the entity updating an A RR (either the DHCP client or DHCP - server) detect that a domain name has an A RR which is already in - use by a different DHCP client? Similarly, should a DHCP client or - server update a domain name which has an A RR that has been - configured by an administrator? In either of these cases, the - domain name in question would either have an additional A RR, or - would have its original A RR replaced by the new record. Either of - these effects may be considered undesirable by some sites. Different - authority and credential models have different levels of exposure to - name collisions. - - 1. Client updates A RR, uses Secure DNS Update with credentials - that are associated with the client's FQDN, and exclusive to the - client. Name collisions in this scenario are unlikely (though - not impossible), since the client has received credentials - specific to the name it desires to use. This implies that the - name has already been allocated (through some implementation- or - organization-specific procedure) to that client. - - 2. Client updates A RR, uses Secure DNS Update with credentials - that are valid for any name in the zone. Name collisions in this - scenario are possible, since the credentials necessary for the - client to update DNS are not necessarily name-specific. Thus, - for the client to be attempting to update a unique name requires - the existence of some administrative procedure to ensure client - configuration with unique names. - - 3. Server updates the A RR, uses a name for the client which is - known to the server. Name collisions in this scenario are likely - unless prevented by the server's name configuration procedures. - See Section 9 for security issues with this form of deployment. - - 4. Server updates the A RR, uses a name supplied by the client. - Name collisions in this scenario are highly likely, even with - administrative procedures designed to prevent them. (This - scenario is a popular one in real-world deployments in many - types of organizations.) See Section 9 for security issues with - this type of deployment. - - - Scenarios 2, 3, and 4 rely on administrative procedures to ensure - name uniqueness for DNS updates, and these procedures may break - down. Experience has shown that, in fact, these procedures will - break down at least occasionally. The question is what to do when - - -Stapp & Rekhter Expires September 2000 [Page 5] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - these procedures break down or, for example in scenario #4, may not - even exist. - - In all cases of name collisions, the desire is to offer two modes of - operation to the administrator of the combined DHCP-DNS capability: - first-update-wins (i.e., the first updating entity gets the name) or - most-recent-update-wins (i.e., the last updating entity for a name - gets the name). - -4.2 Multiple DHCP servers - - If multiple DHCP servers are able to update the same DNS zones, or - if DHCP servers are performing A RR updates on behalf of DHCP - clients, and more than one DHCP server may be able to serve - addresses to the same DHCP clients, the DHCP servers should be able - to provide reasonable and consistent DNS name update behavior for - DHCP clients. - -4.3 Use of the DHCID RR - - A solution to both of these problems is for the updating entities - (both DHCP clients and DHCP servers) to be able to detect that - another entity has been associated with a DNS name, and to offer - administrators the opportunity to configure update behavior. - - Specifically, a DHCID RR, described in DHCID RR[12] is used to - associate client identification information with a DNS name and the - A RR associated with that name. When either a client or server adds - an A RR for a client, it also adds a DHCID RR which specifies a - unique client identity (based on a "client specifier" created from - the client's client-id or MAC address). In this model, only one A - RR is associated with a given DNS name at a time. - - By associating this ownership information with each A RR, - cooperating DNS updating entities may determine whether their client - is the first or last updater of the name (and implement the - appropriately configured administrative policy), and DHCP clients - which currently have a host name may move from one DHCP server to - another without losing their DNS name. - - The specific algorithms utilizing the DHCID RR to signal client - ownership are explained below. The algorithms only work in the case - where the updating entities all cooperate -- this approach is - advisory only and is not substitute for DNS security, nor is it - replaced by DNS security. - -4.3.1 Format of the DHCID RRDATA - - The DHCID RR used to hold the DHCP client's identity is formatted as - - -Stapp & Rekhter Expires September 2000 [Page 6] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - follows: - - The name of the DHCID RR is the name of the A or PTR RR which refers - to the DHCP client. - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - bytes of binary data. From the perspective of DHCP clients and - servers, the DHC resource record consists of a 16-bit identifier - type, followed by one or more bytes representing the actual - identifier. There are two possible forms for a DHCID RR - one that - is used when the client's link-layer address is being used to - identify it, and one that is used when some DHCP option that the - DHCP client has sent is being used to identify it. - - - DISCUSSION: - Implementors should note that the actual identifying data is - never placed into the DNS directly. Instead, the client-identity - data is used as the input into a one-way hash algorithm, and the - output of that hash is then used as DNS RRDATA. This has been - specified in order to avoid placing data about DHCP clients that - some sites might consider sensitive into the DNS. - - When the updater is using the client's link-layer address, the first - two bytes of the DHCID RRDATA MUST be zero. To generate the rest of - the resource record, the updater MUST compute a one-way hash using - the MD5[13] algorithm across a buffer containing the client's - network hardware type and link-layer address. Specifically, the - first byte of the buffer contains the network hardware type as it - appears in the DHCP htype field of the client's DHCPREQUEST message. - All of the significant bytes of the chaddr field in the client's - DHCPREQUEST message follow, in the same order in which the bytes - appear in the DHCPREQUEST message. The number of significant bytes - in the chaddr field is specified in the hlen field of the - DHCPREQUEST message. - - When the updater is using a DHCP option sent by the client in its - DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the - option code of that option, in network byte order. For example, if - the DHCP client identifier option is being used, the first byte of - the DHCID RR should be zero, and the second byte should be 61 - decimal. The rest of the DHCID RR MUST contain the results of - computing a one-way hash across the payload of the option being - used, using the MD5 algorithm. The payload of a DHCP option consists - of the bytes of the option following the option code and length. - - In order for independent DHCP implementations to be able to use the - DHCID RR as a prerequisite in dynamic DNS updates, each updater must - be able to reliably choose the same identifier that any other would - choose. To make this possible, we specify a prioritization which - - -Stapp & Rekhter Expires September 2000 [Page 7] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - will ensure that for any given DHCP client request, any updater will - select the same client-identity data. All updaters MUST use this - order of prioritization by default, but all implementations SHOULD - be configurable to use a different prioritization if so desired by - the site administrators. Because of the possibility of future - changes in the DHCP protocol, implementors SHOULD check for updated - versions of this draft when implementing new DHCP clients and - servers which can perform DDNS updates, and also when releasing new - versions of existing clients and servers. - - DHCP clients and servers should use the following forms of client - identification, starting with the most preferable, and finishing - with the least preferable. If the client does not send any of these - forms of identification, the DHCP/DDNS interaction is not defined by - this specification. The most preferable form of identification is - the Globally Unique Identifier Option [TBD]. Next is the DHCP - Client Identifier option. Last is the client's link-layer address, - as conveyed in its DHCPREQUEST message. Implementors should note - that the link-layer address cannot be used if there are no - significant bytes in the chaddr field of the DHCP client's request, - because this does not constitute a unique identifier. - -4.4 DNS RR TTLs - - RRs associated with DHCP clients may be more volatile than - statically configured RRs. DHCP clients and servers which perform - dynamic updates should attempt to specify resource record TTLs which - reflect this volatility, in order to minimize the possibility that - there will be stale records in resolvers' caches. A reasonable basis - for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the - expected lease duration might be reasonable defaults. Because - configured DHCP lease times vary widely from site to site, it may - also be desirable to establish a fixed TTL ceiling. DHCP clients and - servers MAY allow administrators to configure the TTLs they will - supply, possibly as a fraction of the actual lease time, or as a - fixed value. - -5. Client FQDN Option - - To update the IP address to FQDN mapping a DHCP server needs to know - the FQDN of the client to which the server leases the address. To - allow the client to convey its FQDN to the server this document - defines a new DHCP option, called "Client FQDN". The FQDN Option - also contains Flags and RCode fields which DHCP servers can use to - convey information about DNS updates to clients. - - Clients MAY send the FQDN option, setting appropriate Flags values, - in both their DISCOVER and REQUEST messages. If a client sends the - FQDN option in its DISCOVER message, it MUST send the option in - - -Stapp & Rekhter Expires September 2000 [Page 8] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - subsequent REQUEST messages. - - The code for this option is 81. Its minimum length is 4. - - - Code Len Flags RCODE1 RCODE2 Domain Name - +------+------+------+------+------+------+-- - | 81 | n | | | | ... - +------+------+------+------+------+------+-- - - -5.1 The Flags Field - - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - | MBZ |E|O|S| - +-+-+-+-+-+-+-+-+ - - - When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or - DHCPREQUEST messages, it sets the right-most bit (labelled "S") to - indicate that it will not perform any Dynamic DNS updates, and that - it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS - update on its behalf. If this bit is clear, the client indicates - that it intends to maintain its own FQDN-to-IP mapping update. - - If a DHCP server intends to take responsibility for the A RR update - whether or not the client sending the FQDN option has set the "S" - bit, it sets both the "O" bit and the "S" bit, and sends the FQDN - option in its DHCPOFFER and/or DHCPACK messages. - - The data in the Domain Name field may appear in one of two formats: - ASCII, or DNS-style binary encoding (without compression, of - course), as described in RFC1035[2]. A client which sends the FQDN - option MUST set the "E" bit to indicate that the data in the Domain - Name field is DNS binary encoded. If a server receives an FQDN - option from a client, and intends to include an FQDN option in its - reply, it MUST use the same encoding that the client used. The DNS - encoding is recommended. The use of ASCII-encoded domain-names is - fragile, and the use of ASCII encoding in this option should be - considered deprecated. - - The remaining bits in the Flags field are reserved for future - assignment. DHCP clients and servers which send the FQDN option MUST - set the MBZ bits to 0, and they MUST ignore values in the part of - the field labelled "MBZ". - - - - -Stapp & Rekhter Expires September 2000 [Page 9] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -5.2 The RCODE Fields - - The RCODE1 and RCODE2 fields are used by a DHCP server to indicate - to a DHCP client the Response Code from any A or PTR RR Dynamic DNS - Updates it has performed. The server may also use these fields to - indicate whether it has attempted such an update before sending the - DHCPACK message. Each of these fields is one byte long. - - Implementors should note that EDNS0 describes a mechanism for - extending the length of a DNS RCODE to 12 bits. EDNS0 is specified - in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a - Dynamic DNS Update will be carried in the Client FQDN DHCP Option. - This provides enough number space to accomodate the RCODEs defined - in the Dynamic DNS Update specification. - -5.3 The Domain Name Field - - The Domain Name part of the option carries all or part of the FQDN - of a DHCP client. A client may be configured with a fully-qualified - domain name, or with a partial name that is not fully-qualified. If - a client knows only part of its name, it MAY send a single label, - indicating that it knows part of the name but does not necessarily - know the zone in which the name is to be embedded. The data in the - Domain Name field may appear in one of two formats: ASCII (with no - terminating NULL), or DNS encoding as specified in RFC1035[2]. If - the DHCP client wishes to use DNS encoding, it MUST set the - third-from-rightmost bit in the Flags field (the "E" bit); if it - uses ASCII encoding, it MUST clear the "E" bit. - - A DHCP client that can only send a single label using ASCII encoding - includes a series of ASCII characters in the Domain Name field, - excluding the "." (dot) character. The client SHOULD follow the - character-set recommendations of RFC1034[1] and RFC1035[2]. A client - using DNS binary encoding which wants to suggest part of its FQDN - MAY send a non-terminal sequence of labels in the Domain Name part - of the option. - -6. DHCP Client behavior - - The following describes the behavior of a DHCP client that - implements the Client FQDN option. - - If a client that owns/maintains its own FQDN wants to be responsible - for updating the FQDN to IP address mapping for the FQDN and - address(es) used by the client, then the client MUST include the - Client FQDN option in the DHCPREQUEST message originated by the - client. A DHCP client MAY choose to include the Client FQDN option - in its DISCOVER messages as well as its REQUEST messages. The - rightmost ("S") bit in the Flags field in the option MUST be set to - - -Stapp & Rekhter Expires September 2000 [Page 10] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - 0. Once the client's DHCP configuration is completed (the client - receives a DHCPACK message, and successfully completes a final check - on the parameters passed in the message), the client MAY originate - an update for the A RR (associated with the client's FQDN). The - update MUST be originated following the procedures described in - RFC2136[5] and Section 8. If the DHCP server from which the client - is requesting a lease includes the FQDN option in its ACK message, - and if the server sets both the "S" and the "O" bits (the two - rightmost bits) in the option's flags field, the DHCP client MUST - NOT initiate an update for the name in the Domain Name field. - - A client can choose to delegate the responsibility for updating the - FQDN to IP address mapping for the FQDN and address(es) used by the - client to the server. In order to inform the server of this choice, - the client SHOULD include the Client FQDN option in its DHCPREQUEST - message. The rightmost (or "S") bit in the Flags field in the option - MUST be set to 1. A client which delegates this responsibility MUST - NOT attempt to perform a Dynamic DNS update for the name in the - Domain Name field of the FQDN option. The client MAY supply an FQDN - in the Client FQDN option, or it MAY supply a single label (the - most-specific label), or it MAY leave that field empty as a signal - to the server to generate an FQDN for the client in any manner the - server chooses. - - Since there is a possibility that the DHCP server may be configured - to complete or replace a domain name that the client was configured - to send, the client might find it useful to send the FQDN option in - its DISCOVER messages. If the DHCP server returns different Domain - Name data in its OFFER message, the client could use that data in - performing its own eventual A RR update, or in forming the FQDN - option that it sends in its REQUEST message. There is no requirement - that the client send identical FQDN option data in its DISCOVER and - REQUEST messages. In particular, if a client has sent the FQDN - option to its server, and the configuration of the client changes so - that its notion of its domain name changes, it MAY send the new name - data in an FQDN option when it communicates with the server again. - This may allow the DHCP server to update the name associated with - the PTR record, and, if the server updated the A record representing - the client, to delete that record and attempt an update for the - client's current domain name. - - A client that delegates the responsibility for updating the FQDN to - IP address mapping to a server might not receive any indication - (either positive or negative) from the server whether the server was - able to perform the update. In this case the client MAY use a DNS - query to check whether the mapping is updated. - - A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN - option to 0 when sending the option. - - -Stapp & Rekhter Expires September 2000 [Page 11] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - If a client releases its lease prior to the lease expiration time - and the client is responsible for updating its A RR, the client - SHOULD delete the A RR (following the procedures described in - Section 8) associated with the leased address before sending a DHCP - RELEASE message. Similarly, if a client was responsible for updating - its A RR, but is unable to renew its lease, the client SHOULD - attempt to delete the A RR before its lease expires. A DHCP client - which has not been able to delete an A RR which it added (because it - has lost the use of its DHCP IP address) should attempt to notify - its administrator. - -7. DHCP Server behavior - - When a server receives a DHCPREQUEST message from a client, if the - message contains the Client FQDN option, and the server replies to - the message with a DHCPACK message, the server may be configured to - originate an update for the PTR RR (associated with the address - leased to the client). Any such update MUST be originated following - the procedures described in Section 8. The server MAY complete the - update before the server sends the DHCPACK message to the client. In - this case the RCODE from the update MUST be carried to the client in - the RCODE1 field of the Client FQDN option in the DHCPACK message. - Alternatively, the server MAY send the DHCPACK message to the client - without waiting for the update to be completed. In this case the - RCODE1 field of the Client FQDN option in the DHCPACK message MUST - be set to 255. The choice between the two alternatives is entirely - determined by the configuration of the DHCP server. Servers SHOULD - support both configuration options. - - When a server receives a DHCPREQUEST message containing the Client - FQDN option, the server MUST ignore the values carried in the RCODE1 - and RCODE2 fields of the option. - - In addition, if the Client FQDN option carried in the DHCPREQUEST - message has the "S" bit in its Flags field set, then the server MAY - originate an update for the A RR (associated with the FQDN carried - in the option) if it is configured to do so by the site's - administrator, and if it has the necessary credentials. The server - MAY be configured to use the name supplied in the client's FQDN - option, or it MAY be configured to modify the supplied name, or - substitute a different name. - - Any such update MUST be originated following the procedures - described in Section 8. The server MAY originate the update before - the server sends the DHCPACK message to the client. In this case the - RCODE from the update [RFC2136] MUST be carried to the client in the - RCODE2 field of the Client FQDN option in the DHCPACK message. - Alternatively the server MAY send the DHCPACK message to the client - without waiting for the update to be completed. In this case the - - -Stapp & Rekhter Expires September 2000 [Page 12] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - RCODE2 field of the Client FQDN option in the DHCPACK message MUST - be set to 255. The choice between the two alternatives is entirely - up to the DHCP server. In either case, if the server intends to - perform the DNS update and the client's REQUEST message included the - FQDN option, the server SHOULD include the FQDN option in its ACK - message, and MUST set the "S" bit in the option's Flags field. - - Even if the Client FQDN option carried in the DHCPREQUEST message - has the "S" bit in its Flags field clear (indicating that the client - wants to update the A RR), the server MAY be configured by the local - administrator to update the A RR on the client's behalf. A server - which is configured to override the client's preference SHOULD - include an FQDN option in its ACK message, and MUST set both the "O" - and "S" bits in the FQDN option's Flags field. The update MUST be - originated following the procedures described in Section 8. The - server MAY originate the update before the server sends the DHCPACK - message to the client. In this case the RCODE from the update - [RFC2136] MUST be carried to the client in the RCODE2 field of the - Client FQDN option in the DHCPACK message. Alternatively, the server - MAY send the DHCPACK message to the client without waiting for the - update to be completed. In this case the RCODE2 field of the Client - FQDN option in the DHCPACK message MUST be set to 255. Whether the - DNS update occurs before or after the DHCPACK is sent is entirely up - to the DHCP server's configuration. - - When a DHCP server sends the Client FQDN option to a client in the - DHCPACK message, the DHCP server SHOULD send its notion of the - complete FQDN for the client in the Domain Name field. The server - MAY simply copy the Domain Name field from the Client FQDN option - that the client sent to the server in the DHCPREQUEST message. The - DHCP server MAY be configured to complete or modify the domain name - which a client sent, or it MAY be configured to substitute a - different name. If the server initiates a DDNS update which is not - complete until after the server has replied to the DHCP client, the - server's The server MUST use the same encoding format (ASCII or DNS - binary encoding) that the client used in the FQDN option in its - DHCPREQUEST, and MUST set the "E" bit in the option's Flags field - accordingly. - - If a client's DHCPREQUEST message doesn't carry the Client FQDN - option (e.g., the client doesn't implement the Client FQDN option), - the server MAY be configured to update either or both of the A and - PTR RRs. The updates MUST be originated following the procedures - described in Section 8. - - If a server detects that a lease on an address that the server - leases to a client has expired, the server SHOULD delete any PTR RR - which it added via dynamic update. In addition, if the server added - an A RR on the client's behalf, the server SHOULD also delete the A - - -Stapp & Rekhter Expires September 2000 [Page 13] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - RR. The deletion MUST follow the procedures described in Section 8. - - If a server terminates a lease on an address prior to the lease's - expiration time, for instance by sending a DHCPNAK to a client, the - server SHOULD delete any PTR RR which it associated with the address - via DNS Dynamic Update. In addition, if the server took - responsibility for an A RR, the server SHOULD also delete that A RR. - The deletion MUST follow the procedures described in Section 8. - -8. Procedures for performing DNS updates - -8.1 Adding A RRs to DNS - - When a DHCP client or server intends to update an A RR, it first - prepares a DNS UPDATE query which includes as a prerequisite the - assertion that the name does not exist. The update section of the - query attempts to add the new name and its IP address mapping (an A - RR), and the DHCID RR with its unique client-identity. - - If this update operation succeeds, the updater can conclude that it - has added a new name whose only RRs are the A and DHCID RR records. - The A RR update is now complete (and a client updater is finished, - while a server might proceed to perform a PTR RR update). - - If the first update operation fails with YXDOMAIN, the updater can - conclude that the intended name is in use. The updater then - attempts to confirm that the DNS name is not being used by some - other host. The updater prepares a second UPDATE query in which the - prerequisite is that the desired name has attached to it a DHCID RR - whose contents match the client identity. The update section of - this query deletes the existing A records on the name, and adds the - A record that matches the DHCP binding and the DHCID RR with the - client identity. - - If this query succeeds, the updater can conclude that the current - client was the last client associated with the domain name, and that - the name now contains the updated A RR. The A RR update is now - complete (and a client updater is finished, while a server would - then proceed to perform a PTR RR update). - - If the second query fails with NXRRSET, the updater must conclude - that the client's desired name is in use by another host. At this - juncture, the updater can decide (based on some administrative - configuration outside of the scope of this document) whether to let - the existing owner of the name keep that name, and to (possibly) - perform some name disambiguation operation on behalf of the current - client, or to replace the RRs on the name with RRs that represent - the current client. If the configured policy allows replacement of - existing records, the updater submits a query that deletes the - - -Stapp & Rekhter Expires September 2000 [Page 14] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - existing A RR and the existing DHCID RR, adding A and DHCID RRs that - represent the IP address and client-identity of the new client. - - - DISCUSSION: - The updating entity may be configured to allow the existing DNS - records on the domain name to remain unchanged, and to perform - disambiguation on the name of the current client in order to - attempt to generate a similar but unique name for the current - client. In this case, once another candidate name has been - generated, the updater should restart the process of adding an A - RR as specified in this section. - -8.2 Adding PTR RR Entries to DNS - - The DHCP server submits a DNS query which deletes all of the PTR RRs - associated with the lease IP address, and adds a PTR RR whose data - is the client's (possibly disambiguated) host name. The server also - adds a DHCID RR specified in Section 4.3. - -8.3 Removing Entries from DNS - - The most important consideration in removing DNS entries is be sure - that an entity removing a DNS entry is only removing an entry that - it added, or for which an administrator has explicitly assigned it - responsibility. - - When a lease expires or a DHCP client issues a DHCPRELEASE request, - the DHCP server SHOULD delete the PTR RR that matches the DHCP - binding, if one was successfully added. The server's update query - SHOULD assert that the name in the PTR record matches the name of - the client whose lease has expired or been released. - - The entity chosen to handle the A record for this client (either the - client or the server) SHOULD delete the A record that was added when - the lease was made to the client. - - In order to perform this delete, the updater prepares an UPDATE - query which contains two prerequisites. The first prerequisite - asserts that the DHCID RR exists whose data is the client identity - described in Section 4.3. The second prerequisite asserts that the - data in the A RR contains the IP address of the lease that has - expired or been released. - - If the query fails, the updater MUST NOT delete the DNS name. It - may be that the host whose lease on the server has expired has moved - to another network and obtained a lease from a different server, - which has caused the client's A RR to be replaced. It may also be - that some other client has been configured with a name that matches - the name of the DHCP client, and the policy was that the last client - - -Stapp & Rekhter Expires September 2000 [Page 15] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - to specify the name would get the name. In this case, the DHCID RR - will no longer match the updater's notion of the client-identity of - the host pointed to by the DNS name. - -8.4 Updating other RRs - - The procedures described in this document only cover updates to the - A and PTR RRs. Updating other types of RRs is outside the scope of - this document. - -9. Security Considerations - - Unauthenticated updates to the DNS can lead to tremendous confusion, - through malicious attack or through inadvertent misconfiguration. - Administrators should be wary of permitting unsecured DNS updates to - zones which are exposed to the global Internet. Both DHCP clients - and servers SHOULD use some form of update request origin - authentication procedure (e.g., Simple Secure DNS Update[11]) when - performing DNS updates. - - Whether a DHCP client may be responsible for updating an FQDN to IP - address mapping, or whether this is the responsibility of the DHCP - server is a site-local matter. The choice between the two - alternatives may be based on the security model that is used with - the Dynamic DNS Update protocol (e.g., only a client may have - sufficient credentials to perform updates to the FQDN to IP address - mapping for its FQDN). - - Whether a DHCP server is always responsible for updating the FQDN to - IP address mapping (in addition to updating the IP to FQDN mapping), - regardless of the wishes of an individual DHCP client, is also a - site-local matter. The choice between the two alternatives may be - based on the security model that is being used with dynamic DNS - updates. In cases where a DHCP server is performing DNS updates on - behalf of a client, the DHCP server should be sure of the DNS name - to use for the client, and of the identity of the client. - - Currently, it is difficult for DHCP servers to develop much - confidence in the identities of its clients, given the absence of - entity authentication from the DHCP protocol itself. There are many - ways for a DHCP server to develop a DNS name to use for a client, - but only in certain relatively unusual circumstances will the DHCP - server know for certain the identity of the client. If DHCP - Authentication[10] becomes widely deployed this may become more - customary. - - One example of a situation which offers some extra assurances is one - where the DHCP client is connected to a network through an MCNS - cable modem, and the CMTS (head-end) of the cable modem ensures that - - -Stapp & Rekhter Expires September 2000 [Page 16] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - MAC address spoofing simply does not occur. Another example of a - configuration that might be trusted is one where clients obtain - network access via a network access server using PPP. The NAS itself - might be obtaining IP addresses via DHCP, encoding a client - identification into the DHCP client-id option. In this case, the - network access server as well as the DHCP server might be operating - within a trusted environment, in which case the DHCP server could be - configured to trust that the user authentication and authorization - procedure of the remote access server was sufficient, and would - therefore trust the client identification encoded within the DHCP - client-id. - -10. Acknowledgements - - Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter - Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear, - Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield, - Michael Patton, and Glenn Stump for their review and comments. - -References - - [1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC - 1034, Nov 1987. - - [2] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, Nov 1987. - - [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [4] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and - Answers to Commonly asked ``New Internet User'' Questions", RFC - 1594, March 1994. - - [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System", RFC 2136, April 1997. - - [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [7] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG) - (draft-ietf-dnsext-tsig-*)", July 1999. - - -Stapp & Rekhter Expires September 2000 [Page 17] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - [10] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages - (draft-ietf-dhc-authentication-*)", June 1999. - - [11] Wellington, B., "Simple Secure DNS Dynamic Updates - (draft-ietf-dnsext-simple-secure-update-*)", June 1999. - - [12] Gustafsson, A., "A DNS RR for encoding DHCP client identity - (draft-ietf-dnsext-dhcid-rr-*)", October 1999. - - [13] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, - April 1992. - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 250 Apollo Dr. - Chelmsford, MA 01824 - US - - Phone: 978.244.8498 - EMail: mjs@cisco.com - - Yakov Rekhter - Cisco Systems, Inc. - 170 Tasman Dr. - San Jose, CA 95134 - US - - Phone: 914.235.2128 - EMail: yakov@cisco.com - - - - - - - - - - - - - - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 18] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 19] - diff --git a/doc/draft-ietf-dhc-failover-12.txt b/doc/draft-ietf-dhc-failover-12.txt deleted file mode 100644 index 6d632e08..00000000 --- a/doc/draft-ietf-dhc-failover-12.txt +++ /dev/null @@ -1,7451 +0,0 @@ - - - - - - -Network Working Group Ralph Droms -INTERNET DRAFT Kim Kinnear - Mark Stapp - Cisco Systems - - Bernie Volz - Ericsson - - Steve Gonczi - Relicore - - Greg Rabil - Lucent Technologies - - Michael Dooley - Diamond IP Technologies - - Arun Kapur - K5 Networks - - March 2003 - Expires September 2003 - - - DHCP Failover Protocol - <draft-ietf-dhc-failover-12.txt> - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - - -Droms, et. al. Expires September 2003 [Page 1] - -Internet Draft DHCP Failover Protocol March 2003 - - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - DHCP [RFC 2131] allows for multiple servers to be operating on a - single network. Some sites are interested in running multiple - servers in such a way so as to provide redundancy in case of server - failure. In order for this to work reliably, the cooperating primary - and secondary servers must maintain a consistent database of the - lease information. This implies that servers will need to coordinate - any and all lease activity so that this information is synchronized - in case of failover. - - This document defines a protocol to provide such synchronization - between two servers. One server is designated the "primary" server, - the other is the "secondary" server. This document also describes a - way to integrate the failover protocol with the DHCP load balancing - approach. - - -Table of Contents - - - 1. Introduction................................................. 4 - 2. Terminology.................................................. 5 - 2.1. Requirements terminology................................... 5 - 2.2. DHCP and failover terminology.............................. 5 - 3. Background and External Requirements......................... 9 - 3.1. Key aspects of the DHCP protocol........................... 9 - 3.2. BOOTP relay agent implementation........................... 11 - 3.3. What does it mean if a server can't communicate with its partner? 12 - 3.4. Challenging scenarios for a Failover protocol.............. 13 - 3.5. Using TCP to detect partner server failure................. 14 - 4. Design Goals................................................. 15 - 4.1. Design goals for this protocol............................. 15 - 4.2. Limitations of this protocol............................... 17 - 5. Protocol Overview............................................ 17 - 5.1. Messages and States........................................ 18 - 5.2. Fundamental guarantees..................................... 20 - 5.3. Load balancing............................................. 27 - 5.4. IP address allocations between servers..................... 28 - 5.5. Operating in NORMAL state.................................. 30 - 5.6. Operating in COMMUNICATIONS-INTERRUPTED state.............. 31 - 5.7. Operating in PARTNER-DOWN state............................ 31 - - - - - -Droms, et. al. Expires September 2003 [Page 2] - -Internet Draft DHCP Failover Protocol March 2003 - - - - 5.8. Operating in RECOVER state................................. 31 - 5.9. Operating in STARTUP state................................. 31 - 5.10. Time synchronization between servers...................... 32 - 5.11. IP address binding-status................................. 33 - 5.12. DNS dynamic update considerations......................... 36 - 5.13. Reservations and failover................................. 41 - 5.14. Dynamic BOOTP and failover................................ 42 - 5.15. Guidelines for selecting MCLT............................. 43 - 5.16. What is sent in response to an UPDREQ or UPDREQALL message? 43 - 5.17. How do you determine that your partner is "up to date" for 45 - 6. Common Message Format........................................ 45 - 6.1. Message header format...................................... 46 - 6.2. Common option format....................................... 48 - 6.3. Batching multiple binding update transactions in one BNDUPD mes- 49 - 7. Protocol Messages............................................ 51 - 7.1. BNDUPD message [3]......................................... 51 - 7.2. BNDACK message [4]......................................... 62 - 7.3. UPDREQ message [9]......................................... 65 - 7.4. UPDREQALL message [7]...................................... 66 - 7.5. UPDDONE message [8]........................................ 67 - 7.6. POOLREQ message [1]........................................ 68 - 7.7. POOLRESP message [2]....................................... 69 - 7.8. CONNECT message [5]........................................ 70 - 7.9. CONNECTACK message [6]..................................... 74 - 7.10. STATE message [10]........................................ 78 - 7.11. CONTACT message [11]...................................... 79 - 7.12. DISCONNECT message [12]................................... 80 - 8. Connection Management........................................ 81 - 8.1. Connection granularity..................................... 81 - 8.2. Creating the TCP connection................................ 81 - 8.3. Using the TCP connection for determining communications status 83 - 8.4. Using the TCP connection for binding data.................. 85 - 8.5. Using the TCP connection for control messages.............. 85 - 8.6. Losing the TCP connection.................................. 85 - 9. Failover Endpoint States..................................... 86 - 9.1. Server Initialization...................................... 86 - 9.2. Server State Transitions................................... 86 - 9.3. STARTUP state.............................................. 90 - 9.4. PARTNER-DOWN state......................................... 93 - 9.5. RECOVER state.............................................. 95 - 9.6. RECOVER-WAIT state......................................... 97 - 9.7. RECOVER-DONE state......................................... 98 - 9.9. COMMUNICATIONS-INTERRUPTED State........................... 101 - 9.10. POTENTIAL-CONFLICT state.................................. 105 - 9.11. RESOLUTION-INTERRUPTED state.............................. 107 - 9.12. CONFLICT-DONE state....................................... 108 - 9.13. PAUSED state.............................................. 108 - - - -Droms, et. al. Expires September 2003 [Page 3] - -Internet Draft DHCP Failover Protocol March 2003 - - - 9.14. SHUTDOWN state............................................ 109 - 10. Safe Period................................................. 110 - 11. Security.................................................... 111 - 11.1. Simple shared secret...................................... 112 - 11.2. TLS....................................................... 113 - 12. Failover Options............................................ 113 - 12.1. addresses-transferred..................................... 114 - 12.2. assigned-IP-address....................................... 114 - 12.3. binding-status............................................ 114 - 12.4. client-identifier......................................... 115 - 12.5. client-hardware-address................................... 115 - 12.6. client-last-transaction-time.............................. 115 - 12.7. client-reply-options...................................... 116 - 12.8. client-request-options.................................... 116 - 12.9. DDNS...................................................... 117 - 12.10. delayed-service-parameter................................ 118 - 12.11. hash-bucket-assignment................................... 118 - 12.12. IP-flags................................................. 119 - 12.13. lease-expiration-time.................................... 120 - 12.14. max-unacked-bndupd....................................... 120 - 12.15. MCLT..................................................... 120 - 12.16. message.................................................. 121 - 12.17. message-digest........................................... 121 - 12.18. potential-expiration-time................................ 122 - 12.19. receive-timer............................................ 122 - 12.20. protocol-version......................................... 122 - 12.21. reject-reason............................................ 123 - 12.22. relationship-name........................................ 124 - 12.23. server-flags............................................. 124 - 12.24. server-state............................................. 125 - 12.25. start-time-of-state...................................... 125 - 12.26. TLS-reply................................................ 126 - 12.27. TLS-request.............................................. 126 - 12.28. vendor-class-identifier.................................. 126 - 12.29. vendor-specific-options.................................. 127 - 13. IANA Considerations......................................... 127 - 14. Acknowledgments............................................. 127 - 15. References.................................................. 129 - 16. Author's information........................................ 131 - 17. Full Copyright Statement.................................... 132 - - -1. Introduction - - DHCP [RFC 2131] allows for multiple servers to be operating on a sin- - gle network. Some sites are interested in running multiple servers - in such a way so as to provide redundancy in case of server failure - since the DHCP subsystem is in many cases a critical part of the - - - -Droms, et. al. Expires September 2003 [Page 4] - -Internet Draft DHCP Failover Protocol March 2003 - - - network infrastructure. - - This document defines a protocol to provide synchronization between - two servers in order that each can take over for the other should - either one fail or become unreachable. - - One server is designated the "primary" server, the other is the - "secondary" server, and most DHCP client requests are sent to each - server (see section 3.1.1 for details). - - In order to provide a high availability DHCP service, these - cooperating primary and secondary servers must maintain a consistent - database of lease information. This implies that servers will need - to coordinate all lease activity so that this information is syn- - chronized in case failover is required. The protocol messages and - processing techniques required to maintain a consistent database are - specified in the protocol described here. - - The failover protocol also contains a way to integrate the DHCP load- - balancing algorithm described in [RFC 3074] with the failover proto- - col. - -2. Terminology - - This section discusses both the generic requirements terminology com- - mon to many IETF protocol specifications as well as specialized DHCP - and failover protocol specific terminology. - -2.1. Requirements terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC 2119]. - - -2.2. DHCP and failover terminology - - This document uses the following terms: - - o "available IP address" - - An IP address is "available" if it may be allocated by a - specific DHCP server. An IP address is considered (for the - purposes of this document) to be available to a single server - for allocation unless otherwise noted. An IP address available - for allocation on a primary server has state FREE, and an IP - address available for allocation on a secondary server has - state BACKUP. - - - -Droms, et. al. Expires September 2003 [Page 5] - -Internet Draft DHCP Failover Protocol March 2003 - - - o "binding" - - A binding is a collection of configuration parameters, includ- - ing at least an IP address, associated with or "bound to" a - DHCP client. Bindings are managed by DHCP servers. - - o "binding database" - - The collection of bindings managed by a primary and secondary. - - o "binding update transaction" - - A binding update transaction refers to the set of information - (contained in options) necessary to perform a binding update - for a single IP address. It will be comprised of the - assigned-IP-address option, the binding-status option, along - with other options as appropriate. - - o "binding-status" - - The binding-status is the status of an IP address with respect - to its association with a client. There are specific binding- - status values defined for use by the failover protocol, e.g., - ACTIVE, FREE, RELEASED, ABANDONED, etc. These are designed to - map more or less directly onto the binding-status values used - internally in most DHCP server implementations. The term - binding-status refers to the concept also sometimes known as - "lease state" or "IP address state", but in this document the - term "state" is reserved for the failover state of a failover - endpoint, and binding-status is always used to refer to the - state associated with an IP address or lease. - - o "DHCP client" or "client" - - A DHCP client is an Internet host using DHCP to obtain confi- - guration parameters such as a network address. The term - "client" used within this document always means a DHCP client, - and never one of the two failover servers. - - o "DHCP server" or "server" - - A DHCP server is an Internet host that returns configuration - parameters to DHCP clients. - - o "DDNS" - - An abbreviation for "Dynamic DNS", which refers to the capabil- - ity to update a DNS server's name (actually resource record) - - - -Droms, et. al. Expires September 2003 [Page 6] - -Internet Draft DHCP Failover Protocol March 2003 - - - database using an on-the-wire protocol defined in [RFC 2136]. - - o "DNS" - - An abbreviation for "Domain Name System", a scheme where a cen- - tral name repository is used to map names to IP addresses and IP - addresses to names. - - o "failover endpoint" - - The failover protocol allows for there to be a unique failover - endpoint per partner per role per relationship (where role is - primary or secondary and the relationship is defined by the - relationship-name option). This failover endpoint can take - actions and hold unique states. Typically, there is a one fail- - over endpoint per partner, although there may be more. - - o "FQDN" - - An FQDN is a "fully qualified domain name". A fully qualified - domain name generally is a host name with at least one zone - name, for example "www.dhcp.org" is a fully qualified domain - name. - - o "lazy update" - - Lazy update refers to the requirement placed on a server imple- - menting a failover protocol to update its failover partner when- - ever the binding database changes. A failover protocol which - didn't support lazy update would require the failover partner - update to be complete before a DHCP server could respond to a - DHCP client request with a DHCPACK. A failover protocol which - does support lazy update places no such restriction on the - update of the failover partner server, and so a server can allo- - cate an IP address or extend a lease on an IP address and then - update its failover partner as time permits. A failover proto- - col which supports lazy update not only removes the requirement - to update the failover partner prior to responding to a DHCP - client with a DHCPACK, but also allows gathering up batches of - updates from one failover server to its partner. - - o "MCLT" - - The MCLT refers to maximum client lead time. This time is con- - figured on the primary server and transmitted from the primary - to the secondary server in the CONNECT message. It is the max- - imum amount of time that one server can extend a lease for a - client's binding beyond the time known by the partner server. - - - -Droms, et. al. Expires September 2003 [Page 7] - -Internet Draft DHCP Failover Protocol March 2003 - - - See section 5.2.1 for details. - - o "partner" - - A "partner", for the purposes of this document, refers to a - failover server, typically the other failover server. In many - (if not most) cases, the failover protocol is symmetric with - respect to the primary or secondary nature of the servers, and - so it is often appropriate to discuss "updating the partner - server", since it could be a primary server updating a secondary - server or a secondary server updating a primary server. - - o "Primary server" or "Primary" - - A DHCP server configured to provide primary service to a set of - DHCP clients for a particular set of subnet address pools. - - o "RR" - - "RR" is an abbreviation for "resource record". All records in - the DNS are resource records. The resource records of most - relevance to this document are the "A" resource record, which - maps a DNS name to a particular IP address, the "PTR" resource - record, which allows a "reverse map", from the IP address back - to a DNS name, and the "KEY" resource record, which is used in - ways defined in [FQDN] to tag a DNS name with the identity of - the DHCP client with which it is associated. - - o "Secondary server" or "Secondary" - - A DHCP server configured to act as backup to a primary server - for a particular set of subnet address pools. - - o "stable storage" - - Every DHCP server is assumed to have some form of what is called - "stable storage". Stable storage is used to hold information - concerning IP address bindings (among other things) so that this - information is not lost in the event of a server failure which - requires restart of the server. - - o "state" - - In this document, the term "state" refers exclusively to the - state of a failover endpoint, for example: NORMAL, - COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN. It is not used to - refer to any attributes of an IP address or a binding of an IP - address. See "binding-status". - - - -Droms, et. al. Expires September 2003 [Page 8] - -Internet Draft DHCP Failover Protocol March 2003 - - - o "subnet address pool" - - A subnet address pool is the set of IP addresses which is asso- - ciated with a particular network number and subnet mask. In the - simple case, there is a single network number and subnet mask - and a set of IP addresses. In the more complex case (sometimes - called "secondary subnets", sometimes "superscopes"), several - (apparently unrelated) network number and subnet mask combina- - tions with their associated IP addresses may all be configured - together into one subnet address pool. - - -3. Background and External Requirements - - This section highlights key aspects of the DHCP protocol on which the - failover protocol depends. It also discusses the requirements that - the failover protocol places on other aspects of the network infras- - tructure, and some general issues surrounding server failure detec- - tion. Some failure scenarios that provide particular challenges to a - failover protocol are discussed. Finally, the challenges inherent in - using a TCP connection as a means to detect failure of a partner - server are elaborated. - -3.1. Key aspects of the DHCP protocol - - The failover protocol is designed to augment the DHCP protocol as - described in RFC 2131 [RFC 2131]. There are several key aspects of - the DHCP protocol which are required by the failover protocol in - order to successfully meet its design goals. - -3.1.1. Broadcast behavior - - There are two aspects of the broadcast behavior of the DHCP protocol - which are key to making the failover protocol operate successfully. - The first is simply that the DHCP protocol requires a DHCP client to - broadcast all DHCPDISCOVER and DHCPREQUEST/INIT-REBOOT messages. - Because of this requirement, a DHCP client who was communicating with - one server will automatically be able to communicate with another - server if one is available. - - The second aspect of broadcast behavior is similar to the first, but - involves the distinction between a DHCPREQUEST/RENEW and - DHCPREQUEST/REBINDING. A DHCPREQUEST/RENEW is the message that a - DHCP client uses to extend its lease. It is unicast to the DHCP - server from which it acquired the lease. However, the DHCP protocol - (in a farsighted move), was explicitly designed so that in the event - that a DHCP client cannot contact the server from which it received a - lease on an IP address using a DHCPREQUEST/RENEW, the client is - - - -Droms, et. al. Expires September 2003 [Page 9] - -Internet Draft DHCP Failover Protocol March 2003 - - - required to broadcast its renewal using a DHCPREQUEST/REBINDING to - any available DHCP server. Since all DHCP clients were required to - implement this algorithm, the failover protocol can have a different - server from the one that initially granted a lease be the server to - renew a lease. Thus, one server can take over for another with no - interruption in the service as experienced by the DHCP client or its - associated applications software. - -3.1.2. Client responsibility - - In the DHCP protocol the DHCP clients are entrusted with a consider- - able responsibility. In particular, after they are granted a lease - on an IP address, they are enjoined to only use that IP address while - their lease is valid. Every DHCP client is expected to stop using an - IP address if the expiration time on the lease has passed and if it - cannot get an extension on the lease for that IP address from some - DHCP server. Thus, the correct behavior of every DHCP client in this - regard is required to ensure the integrity of the DHCP service. On - the other hand, incorrect behavior by a client in this area will tend - to adversely affect at most one other DHCP client. - - Furthermore, any DHCP client which sends in a DHCPREQUEST/RENEW or - DHCPREQUEST/REBINDING to a DHCP server (either unicast for a RENEW or - broadcast for a REBINDING) MUST still have time to run on the lease - for that IP address. The DHCP server sends the DHCPACK back unicast - to the IP address from which the RENEW or REBINDING originated. - - Given the existing responsibility placed on the client to only use an - IP address when the lease is valid, and to only send in a RENEW or - REBINDING if the lease is valid, the failover protocol relies on DHCP - clients to perform responsibly and will, in the absence of conflict- - ing information, believe a DHCP client that is attempting to RENEW or - REBIND a lease on an IP address is the legitimate owner of that IP - address. - - If clients do not follow these rules, it is possible for an address - to be in use by more than one client. For a single server, this hap- - pens because the server has leased the expired address to another - client and the original client is also attempting to use the address. - The server would NAK the renewal request. This is made slightly worse - in the failover protocol if the two servers are unable to communicate - with each other and one server leases an available address to a new - client while the other server receives a renewal from a different - client. In this case, both servers lease the same address to dif- - ferent clients for the MCLT time. - - One troublesome issue is that of the DHCP client responsibility when - sending in DHCPREQUEST/INIT-REBOOT requests. While the original DHCP - - - -Droms, et. al. Expires September 2003 [Page 10] - -Internet Draft DHCP Failover Protocol March 2003 - - - RFC was written to require a DHCP client to have time left to run on - the lease for an IP address if the client is sending an INIT-REBOOT - request, it was sufficiently unclear that some client vendors didn't - realize this until recently. Since the INIT-REBOOT request was sent - with the IP address in the dhcp-requested-address option and not in - the ciaddr (for perfectly good reasons), the similarity to the RENEW - and REBINDING case was lost on many people. - - At present, the failover protocol does not assume that a client send- - ing in an INIT-REBOOT request necessarily has a valid lease on the IP - address appearing in the dhcp-requested-address option in the INIT- - REBOOT request. - - The implications of this are as follows: Assume that there is a DHCP - client that gets a lease from one server while that server is unable - to communicate with its failover partner. Then, assume that after - that client reboots it is able only to communicate with the other - failover server. If the failover servers have not been able to com- - municate with each other during this process, then the DHCP client - will get a new IP address instead of being able to continue to use - its existing IP address. This will affect no applications on the DHCP - client, since it is rebooting. However, it will use up an additional - IP address in this marginal case. - -3.1.3. Stable storage update before DHCPACK - - The DHCP protocol allocates resources, and in order to operate - correctly it requires that a DHCP server update some form of stable - storage prior to sending a DHCPACK to a DHCP client in order to grant - that client a lease on an IP address. - - One of the goals of the failover protocol is that it not add signifi- - cant additional time to this already time consuming requirement to - update stable storage prior to a DHCPACK. In particular, adding a - requirement to communicate with another server prior to sending a - DHCPACK would greatly simplify the failover protocol, but it would - unacceptably limit the potential scalability of any DHCP server which - employed the failover protocol. - -3.2. BOOTP relay agent implementation - - Many DHCP clients are not resident on the same network segment as a - DHCP server. In order to support this form of network architecture, - most contemporary routers implement something known as a BOOTP Relay - Agent. This capability inside of a router listens for all broadcasts - at the DHCP port, port 67, and will relay any broadcasts that it - receives on to a DHCP server. The IP address of the DHCP server must - have been previously configured into the router. As part of the - - - -Droms, et. al. Expires September 2003 [Page 11] - -Internet Draft DHCP Failover Protocol March 2003 - - - relay process, the relay agent will place the address of the inter- - face on which it received the broadcast into the giaddr field of the - DHCP packet. - - Since the failover protocol requires two DHCP servers to receive any - broadcast DHCP messages, in order to work with DHCP clients which are - not local to the DHCP server, the BOOTP relay agent on the router - closest to the DHCP client must be configured to point at more than - one DHCP server. - - Most BOOTP relay agent implementations allow this duplication of - packets. - - If this is not possible, an administrator might be able to configure - the relay agent with a subnet broadcast address, but in this case the - primary and secondary DHCP servers in a failover pair must both - reside on the same subnet. - -3.3. What does it mean if a server can't communicate with its partner? - - In any protocol designed to allow one server to take over some - responsibilities from a partner server in the event of "failure" of - that partner server, there is an inherent difficulty in determining - when that partner server has failed. - - In fact, it is fundamentally impossible for one server to distinguish - a network communications failure from the outright failure of the - server to which it is trying to communicate. In the case where each - server is handing out resources (in this case IP addresses) to a - client community, mistaking an inability to communicate with a - partner server for failure of that partner server could easily cause - both servers to be handing out the same IP addresses to different - clients. - - One way that this is sometimes handled is for there to be more than - two servers. In the case of an odd number of servers, the servers - that can still communicate with a majority of other servers will con- - sider themselves operational, and any server which can't communicate - to a majority of other servers must immediately cease operations. - - While this technique works in some domains, having the only server to - which a DHCP client can communicate voluntarily shut itself down - seems like something worth avoiding. - - The failover protocol will operate correctly while both servers are - unable to communicate, whether they are both running or not. At some - point there may be resource contention, and if one of the servers is - actually down, then the operator can inform the operational server - - - -Droms, et. al. Expires September 2003 [Page 12] - -Internet Draft DHCP Failover Protocol March 2003 - - - and the operational server will be able to use all of the failed - server's resources. - - The protocol also allows detection of an orderly shutdown of a parti- - cipating server. - -3.4. Challenging scenarios for a Failover protocol - - There exist two failure scenarios which provide particular challenges - to the correctness guarantees of a failover protocol. - -3.4.1. Primary Server crash before "lazy" update: - - In the case where the primary server sends a DHCPACK to a client for - a newly allocated IP address and then crashes prior to sending the - corresponding update to the secondary server, the secondary server - will have no record of the IP address allocation. When the secondary - server takes over, it may well try to allocate that IP address to a - different client. In the case where the first client to receive the - IP address is not on the net at the time (yet while there was still - time to run on its lease), an ICMP echo (i.e., ping) will not prevent - the secondary server from allocating that IP address to a different - client. - - The failover protocol deals with this situation by having the primary - and secondary servers allocate addresses for new clients from dis- - joint address pools. See section 5.5 for details. - - A more likely (in that DHCPREQUEST/RENEWs are presumably more common - than DHCPDISCOVERs) and more subtle version of this problem is where - the primary server crashes after extending a client's lease time, and - before updating the secondary with a new time using a lazy update. - After the secondary takes over, if the client is not connected to the - network the secondary will believe the client's lease has expired - when, in fact, it has not. In this case as well, the IP address - might be reallocated to a different client while the first client is - still using it. - - This scenario is handled by the failover protocol through control of - the lease time and the use of the maximum client lead time (MCLT). - See section 5.2.1 for details. - -3.4.2. Network partition where DHCP servers can't communicate but each -can talk to clients: - - Several conditions are required for this situation to occur. First, - due to a network failure, the primary and secondary servers cannot - communicate. As well, some of the DHCP clients must be able to - - - -Droms, et. al. Expires September 2003 [Page 13] - -Internet Draft DHCP Failover Protocol March 2003 - - - communicate with the primary server, and some of the clients must now - only be able to communicate with the secondary server. When this - condition occurs, both primary and secondary servers could attempt to - allocate IP addresses for new clients from the same pool of available - addresses. At some point, then, two clients will end up being allo- - cated the same IP address. This will cause problems when the network - failure that created this situation is corrected. - - The failover protocol deals with this situation by having the primary - and secondary servers allocate addresses for new clients from dis- - joint address pools. See section 5.5 for details. - -3.5. Using TCP to detect partner server failure - - There are several characteristics of TCP that are important to the - functioning of the failover protocol, which uses one TCP connection - for both bulk data transfer as well as to assess communications - integrity with the other server. Reliable and ordered message - delivery are chief among these important characteristics. - - It would be nice to use the capabilities built in to TCP to allow it - to determine if communications integrity exists to the failover - partner but this strategy contains some problems which require - analysis. There exist three fundamental cases for an open TCP con- - nection that must be examined. - - 1. When no data is being sent on a TCP connection, the TCP layer - also does not exchange any signaling messages to assure that - the peer is still up. - - 2. When data is queued to be sent, and the receiver has not - blocked the sending of additional data, then messages are - flowing across the TCP connection containing the applications - data. - - 3. When data is queued to be sent, and the receiver has blocked - the transmission of additional data, then persist messages are - flowing from the receiver to the sender to ensure that the - sender doesn't miss the receiver opening the window for - further transmissions. - - The first case can be turned into the second case by sending - application-level keep-alive messages periodically when there is no - other data queued to be sent. Note TCP keep-alive messages might be - used as well, but they present additional problems. - - Thus, we can ensure that the TCP connection has messages flowing - periodically across the connection fairly easily. The question - - - -Droms, et. al. Expires September 2003 [Page 14] - -Internet Draft DHCP Failover Protocol March 2003 - - - remains as to what TCP will do if the other end of the connection - fails to respond (either because of network partition or because the - receiving server crashes). TCP will attempt to retransmit a message - with an exponential backoff, and will eventually timeout that - retransmission. However, the length of that timeout cannot, in gen- - eral, be set on a per-connection basis, and is frequently as long as - nine minutes, though in some cases it may be as short as two minutes. - On some systems it can be set system-wide, while on other systems it - cannot be changed at all. - - A value for this timeout that would be appropriate for the failover - protocol, say less than 1 minute, could have unpleasant side-effects - on other applications running on the same server, assuming that it - could be changed at all on the host operating system. - - Nine minutes is a long time for the DHCP service to be unavailable to - any new clients that were being served by the server which has - crashed, when there is another server running that could respond to - them as soon as it determines that its partner is not operational. - - The conclusion drawn from this analysis is that TCP provides very - useful support for the failover protocol in the areas of reliable and - ordered message delivery, but cannot by itself be relied upon to - detect partner server failure in a fashion acceptable to the needs of - the failover protocol. Additional failover protocol capabilities - have been created to support timely detection of partner server - failure. See section 8.3 for details on this mechanism. - -4. Design Goals - - This section lists the design goals and the limitations of the fail- - over protocol. - -4.1. Design goals for this protocol - - The following is a list of goals that are met by this protocol. They - are listed in priority order. - - 1. Implementations of this protocol must work with existing DHCP - client implementations based on the DHCP protocol [RFC 2131]. - - 2. Implementations of the protocol must work with existing BOOTP - relay agent implementations. - - 3. The protocol must provide failover redundancy between servers - that are not located on the same subnet. - - 4. Provide for continued service to DHCP clients through an - - - -Droms, et. al. Expires September 2003 [Page 15] - -Internet Draft DHCP Failover Protocol March 2003 - - - automated mechanism in the event of failure of the primary - server. - - 5. Avoid binding an IP address to a client while that binding is - currently valid for another client. In other words, do not - allocate the same IP address to two clients. - - 6. Minimize any need for manual administrative intervention. - - 7. Introduce no additional delays in server response time as a - result of the network communications required to implement the - failover protocol, i.e., don't require communications with the - partner between the receipt of a DHCPREQUEST and the - corresponding DHCPACK. - - 8. Share IP address ranges between primary and secondary servers; - i.e., impose no requirement that the pool of available - addresses be manually or permanently divided between servers. - - 9. Continue to meet the goals and objectives of this protocol in - the event of server failure or network partition. - - 10. Provide graceful reintegration of full protocol service after - server failure or network partition. - - 11. Allow for one computer to act as a secondary server for multi- - ple primary servers. The protocol must allow failover primary - and secondary configuration choices to be made at a granular- - ity smaller than "all of the subnets served by a single - server", though individual implementations may not choose to - allow such flexibility. - - 12. Ensure that an existing client can keep its existing IP - address binding if it can communicate with either the primary - or secondary DHCP server implementing this protocol - not just - whichever server that originally offered it the binding. - - 13. Ensure that a new client can get an IP address from some - server. Ensure that in the face of partition, where servers - continue to run but cannot communicate with each other, the - above goals and requirements may be met. In addition, when - the partition condition is removed, allow graceful automatic - re-integration without requiring human intervention. - - 14. If either primary or secondary server loses all of the infor- - mation that it has stored in stable storage, ensure that it be - able to refresh its stable storage from the other server. - - - - -Droms, et. al. Expires September 2003 [Page 16] - -Internet Draft DHCP Failover Protocol March 2003 - - - 15. Support load balancing between the primary and secondary - servers, and allow configuration of the percentage of the - client population served by each with a moderately fine granu- - larity. - - -4.2. Limitations of this protocol - - The following are explicit limitations of this protocol. - - 1. This protocol provides only one level of redundancy through a - single secondary server for each primary server. - - 2. A subset of the address pool is reserved for secondary server - use. In order to handle the failure case where both servers - are able to communicate with DHCP clients, but unable to com- - municate with each other, a subset of the IP address pool must - be set aside as a private address pool for the secondary - server. The secondary can use these to service newly arrived - DHCP clients during such a period. The required size of this - private pool is based only on the arrival rate of new DHCP - clients and the length of expected downtime, and is not influ- - enced in any way by the total number of DHCP clients supported - by the server pair. - - The failover protocol can be used in a mode where both the - primary and secondary servers can share the load between them - when both are operating. In this load balancing mode, the - addresses allocated by the primary server to the secondary - server are not unused, but are used instead to service the - portion of the client base to which the secondary server is - required to respond. See section 5.3 for more information on - load balancing. - - 3. The primary and secondary servers do not respond to client - requests at all while recovering from a failure that could - have resulted in duplicate IP assignments. (When synchroniz- - ing in POTENTIAL-CONFLICT state). - - -5. Protocol Overview - - This section will discuss the failover protocol at a relatively high - level of detail. In the event that a description in this section - conflicts (or appears to conflict due to the overview nature of this - section) with information in later sections of this draft, the infor- - mation in the later sections should be considered authoritative. - - - - -Droms, et. al. Expires September 2003 [Page 17] - -Internet Draft DHCP Failover Protocol March 2003 - - -5.1. Messages and States - - This protocol is centered around the message exchange used by one - server to update the other server of binding database changes result- - ing from DHCP client activity: - - o Communication of binding database changes - - The binding update (BNDUPD) message is used to send the binding - database changes to the partner server, and the partner server - responds with a binding acknowledgement (BNDACK) message when it - has successfully committed those changes to its own stable - storage. - - All of the other messages involve ancillary issues: - - o Management of available IP addresses - - The pool request (POOLREQ) message is used by the secondary - server to request an allocation of IP addresses from the primary - server. The pool response (POOLRESP) message is used by the - primary server to inform the secondary server how many IP - addresses were allocated to the secondary server as the result - of the pool request. - - o Synchronization of the binding databases between the servers - after they've been out of communications - - The update request (UPDREQ) message is used by one server to - request that its partner send it all binding database informa- - tion that it has not already seen. The update request all - (UPDREQALL) message is used by one server to request that all - binding database information be sent in order to recover from a - total loss of its binding database by the requesting server. - The update done (UPDDONE) message is used by the responding - server to indicate that all requested updates have been sent the - responding server and acked by the requesting server. - - o Connection establishment - - The connect (CONNECT) message is used by the primary server to - establish a high level connection with the other server, and to - transmit several important configuration data items between the - servers. The connect acknowledgement message (CONNECTACK) is - used by the secondary server to respond to a CONNECT message - from the primary server. The disconnect (DISCONNECT) message is - used by either server when closing a connection. - - - - -Droms, et. al. Expires September 2003 [Page 18] - -Internet Draft DHCP Failover Protocol March 2003 - - - o Server synchronization - - The state change (STATE) message is used by either server to - inform the other server of a change of failover state. - - o Connection integrity management - - The contact (CONTACT) message is used by either server to ensure - that the other server continues to see the connection as opera- - tional. It MUST be transmitted periodically over every esta- - blished connection if other message traffic is not flowing, and - it MAY be sent at any time. - -5.1.1. Failover endpoints - - The proper operation of the failover protocol requires more than the - transmission of messages between one server and the other. Each end- - point might seem to be a single DHCP server, but in fact there are - many situations where additional flexibility in configuration is use- - ful. - - For instance, there might be several servers which are each primary - for a distinct set of address pools, and one server which is secon- - dary for all of those address pools. The situation with the pri- - maries is straightforward, but the secondary will need to maintain a - separate failover state, partner state, and communications up/down - status for each of the separate primary servers for which it is act- - ing as a secondary. - - The failover protocol is SHOULD be configured with one failover rela- - tionship between each pair of failover servers. In this case there is - one failover endpoint for that relationship on each partner. This - failover relationship MUST have a unique name, which is communicated - using the relationship-name option in the CONNECT and CONNECTACK mes- - sages. - - There is typically little need for addtional relationships between - any two servers but there MAY be more than one failover relationship - between two servers -- however each MUST have a unique relationship - name (stored in the relationship-name option). - - Any failover endpoint can take actions and hold unique states. - - Thus, in the case where there are two primary servers A and B each - backed up by a single common secondary server C, there is one fail- - over endpoint on each of A and B, and two different failover end- - points on C. The two different failover endpoints on C each have - unique states, unique relationship names, and independent TCP - - - -Droms, et. al. Expires September 2003 [Page 19] - -Internet Draft DHCP Failover Protocol March 2003 - - - connections. - - This document frequently describes the behavior of the protocol in - terms of primary and secondary servers, not primary and secondary - failover endpoints. However, it is important to remember that every - 'server' described in this document is in reality a failover endpoint - that resides in a particular process, and that many failover end- - points may reside in the same server process. - - It is not the case that there is a unique failover endpoint for each - subnet address pool that participates in a failover relationship. On - one server, there is (typically) one failover endpoint per partner, - regardless of how many subnet address pools are managed by that com- - bination of partner and role. Conversely, on a particular server, - any given subnet address pool will be associated with exactly one - failover endpoint. - - When a connection is received from the partner, the unique failover - endpoint to which the message is directed is determined solely by the - IP address of the partner, the relationship-name, and the role of the - receiving server. See section 8.2. - -5.2. Fundamental guarantees - - There a several fundamental restrictions this protocol places on what - one server can do in the absence of knowledge of the other server. - Operating within these restrictions allows certain guarantees to be - made to the partner server, and these are key to the correct opera- - tion of the protocol. - -5.2.1. Control of lease time - - The key problem with lazy update is that when a server fails after - updating a client with a particular lease time and before updating - its partner, the partner will believe that a lease has expired even - though the client still retains a valid lease on that IP address. - - In order to handle this problem, a period of time known as the "Max- - imum Client Lead Time" (MCLT) is defined and must be known to both - the primary and secondary servers. Proper use of this time interval - places an upper bound on the difference allowed between the lease - time provided to a DHCP client by a server and the lease time known - by that server's partner. However, the MCLT is typically much less - than the lease time that a server has been configured to offer a - client, and so some strategy must exist to allow a server to offer - the configured lease time to a client. During a lazy update the - updating server typically updates its partner with a potential - expiration time which is longer than the lease time previously given - - - -Droms, et. al. Expires September 2003 [Page 20] - -Internet Draft DHCP Failover Protocol March 2003 - - - to the client and which is longer than the lease time that the server - has been configured to give a client. This allows that server to - give a longer lease time to the client the next time the client - renews its lease, since the time that it will give to the client will - not exceed the MCLT beyond the potential expiration time acknowledged - by its partner. - - The PARTNER-DOWN state exists so that a server can be sure that its - partner is, indeed, down. Correct operation while in that state - requires (generally) that the server wait the MCLT after anything - that happened prior to its transition into PARTNER-DOWN state (or, - more accurately, when the other server went down if that is known). - Thus, the server MUST wait the MCLT after the partner server went - down before allocating any of the partner's addresses which were - available for allocation. In the event the partner was not in com- - munication prior to going down, it might have allocated one or more - of its FREE addresses to a DHCP client and been unable to inform the - server entering PARTNER-DOWN prior to going down itself. By waiting - the MCLT after the time the partner went down, the server in - PARTNER-DOWN state ensures that any clients which have a lease on one - of the partner's FREE addresses will either time out or contact the - server in PARTNER-DOWN by the time that period ends. - - In addition, once a server has made a transition to PARTNER-DOWN - state, it MUST NOT reallocate an IP address from one client to - another client until the longer of the following two times: - - o The MCLT after the time the partner server went down (see - above). - - o An additional MCLT interval after the lease by the original - client expires. (Actually, until the maximum client lead time - after what it believes to be the lease expiration time of the - client.) - - Some optimizations exist for this restriction, in that it only - applies to leases that were issued BEFORE entering PARTNER-DOWN. Once - a server has entered PARTNER-DOWN and it leases out an address, it - need not wait this time as long as it has never communicated with the - partner since the lease was given out. - - The fundamental relationship on which much of the correctness of this - protocol depends is that the lease expiration time known to a DHCP - client MUST NOT be more than the maximum client lead time greater - than the potential expiration time known to a server's partner. - - The remainder of this section makes the above fundamental relation- - ship more explicit. - - - -Droms, et. al. Expires September 2003 [Page 21] - -Internet Draft DHCP Failover Protocol March 2003 - - - This protocol requires a DHCP server to deal with several different - lease intervals and places specific restrictions on their relation- - ships. The purpose of these restrictions is to allow the other server - in the pair to be able to make certain assumptions in the absence of - an ability to communicate between servers. - - The different lease times are: - - o desired lease interval - - The desired lease interval is the lease interval that a DHCP server - would like to give to a DHCP client in the absence of any restric- - tions imposed by the Failover protocol. Its determination is out- - side of the scope of this protocol. Typically this is the result of - external configuration of a DHCP server. - - o actual lease interval - - The actual lease internal is the lease interval that a DHCP server - gives out to a DHCP client in the dhcp-lease-time option of a - DHCPACK packet. It may be shorter than the desired client lease - interval (as explained below). - - o potential lease interval - - The potential lease interval is the lease expiration interval the - local server tells to its partner in the potential-expiration-time - option of a BNDUPD message. - - o acknowledged potential lease interval - - The acknowledged potential lease interval is the potential lease - interval the partner server has most recently acknowledged in the - potential-expiration-time option of a BNDACK message. - - The key restriction (and guarantee) that any server makes with - respect to lease intervals is that the actual client lease interval - never exceeds the acknowledged potential lease interval (if any) by - more than a fixed amount. This fixed amount is called the "Maximum - Client Lead Time" (MCLT). - - The MCLT MAY be configurable on the primary server, but for correct - server operation it MUST be the same and known to both the primary - and secondary servers. The secondary server determines the MCLT from - the MCLT option sent from the primary server to the secondary server - in the CONNECT message. - - A server MUST record in its stable storage both the actual lease - - - -Droms, et. al. Expires September 2003 [Page 22] - -Internet Draft DHCP Failover Protocol March 2003 - - - interval and the most recently acknowledged potential lease interval - for each IP address binding. It is assumed that the desired client - lease interval can be determined through techniques outside of the - scope of this protocol. See section 7.1.5 for more details concern- - ing the times that the server MUST record in its stable storage and - the way that they interact with the lease time that may be offered to - a DHCP client. - - Again, the fundamental relationship among these times which MUST be - maintained is: - - actual lease interval < - ( acknowledged potential lease interval + MCLT ) - - - Figure 5.2.1-1 illustrates an initial lease to a client using the - rules discussed in the example which follows it. Note that this is - only one example -- as long as the fundamental relationship is - preserved, the actual times used could be quite different. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 23] - -Internet Draft DHCP Failover Protocol March 2003 - - - - DHCP Primary Secondary - time Client Server Server - - | (time in intervals) | (absolute time) | - | | | - | >-DHCPDISCOVER-> | | - | <---DHCPOFFER-< | | - | lease-time=MCLT | | - | | | - | >-DHCPREQUEST-> | | - | (selecting) | | - | | | - t | <--------DHCPACK-< | | - | lease-time=MCLT | | - | | >-BNDUPD--> | - | | lease-expiration=t+MCLT - | | potential-expiration=t+(MCLT/2)+X - | | | - | | <-BNDACK-< | - | | potential-expiration=t+(MCLT/2)+X - ... ... ... - | | | - t+MCLT/2 | >-DHCPREQUEST-> | | - | (renew) | | - | | | - t1 | <--------DHCPACK-< | | - | lease-time=X | | - | | >-BNDUPD--> | - | | lease-expiration=t1+X - | | potential-expiration=t1+(X/2)+X - | | | - | | <-BNDACK-< | - | | potential-expiration=t1+(X/2)+X - ... ... ... - - Figure 5.2.1-1: Lazy Update Message Traffic - X = Desired Lease Interval - Assumes renewal interval = lease interval / 2 - - - DISCUSSION: - - This protocol mandates only that the above fundamental relation- - ship concerning lease intervals is preserved. - - In the interests of clarity, however, let's examine a specific - example. The MCLT in this case is 1 hour. The desired lease - - - -Droms, et. al. Expires September 2003 [Page 24] - -Internet Draft DHCP Failover Protocol March 2003 - - - interval is 3 days, and its renewal time is half the lease inter- - val. - - The rules for this example are: - - o What to tell the client: - - Take the remainder of the acknowledged potential lease interval. - If this is a new lease, then this value will be zero. If this - remainder plus the MCLT is greater than the desired lease inter- - val, give the client the desired lease interval else give the - client the remainder plus the MCLT. - - o What to tell the failover partner server: - - Take the renewal interval (typically half of the actual client - lease interval), add to it the desired lease interval, and add - it to the current time to yield the value that goes into the - potential-expiration-time option. - - Also tell the failover partner the actual lease interval by - adding it to the current time to yield the value that goes into - the lease-expiration option. - - In operation this might work as follows: - - When a server makes an offer for a new lease on an IP address to a - DHCP client, it determines the desired lease interval (in this - case, 3 days). It then examines the acknowledged potential lease - interval (which in this case is zero) and determines the remainder - of the time left to run, which is also zero. To this it adds the - MCLT. Since the actual lease interval cannot be allowed to exceed - the remainder of the current acknowledged potential lease interval - plus the MCLT, the offer made to the client is for the remainder - of the current acknowledged potential lease interval (i.e., zero) - plus the MCLT. Thus, the actual lease interval is 1 hour. - - Once the server has performed the DHCPACK to the DHCP client, it - will update the secondary server with the lease information. How- - ever, the desired potential lease interval will be composed of one - half of the current actual lease interval added to the desired - lease interval. Thus, the secondary server is updated with a - BNDUPD with a lease interval of 3 days + 1/2 hour specified in the - potential-expiration-time option. - - When the primary server receives a BNDACK to its update of the - secondary server's (partner's) potential lease interval, it - records that as the acknowledged potential lease interval. A - - - -Droms, et. al. Expires September 2003 [Page 25] - -Internet Draft DHCP Failover Protocol March 2003 - - - server MUST NOT send a BNDACK in response to a BNDUPD message - until it is sure that the information in the BNDUPD message - resides in its stable storage. Thus, the primary server in this - case can be sure that the secondary server has recorded the poten- - tial lease interval in its stable storage when the primary server - receives a BNDACK message from the secondary server. - - When the DHCP client attempts to renew at T1 (approximately one - half an hour from the start of the lease), the primary server - again determines the desired lease interval, which is still 3 - days. It then compares this with the remaining acknowledged - potential lease interval (3 days + 1/2 hour) and adjusts for the - time passed since the secondary was last updated (1/2 hour). Thus - the time remaining of the acknowledged potential lease interval is - 3 days. Adding the MCLT to this yields 3 days plus 1 hour, which - is more than the desired lease interval of 3 days. So the client - is renewed for the desired lease interval -- 3 days. - - When the primary DHCP server updates the secondary DHCP server - after the DHCP client's renewal ACK is complete, it will calculate - the desired potential lease interval as the T1 fraction of the - actual client lease interval (1/2 of 3 days this time = 1.5 days). - To this it will add the desired client lease interval of 3 days, - yielding a total desired partner server lease interval of 4.5 - days. In this way, the primary attempts to have the secondary - always "lead" the client in its understanding of the client's - lease interval so as to be able to always offer the client the - desired client lease interval. - - Once the initial actual client lease interval of the MCLT is past, - the protocol operates effectively like the DHCP protocol does - today in its behavior concerning lease intervals. However, the - guarantee that the actual client lease interval will never exceed - the remaining acknowledged partner server lease interval by more - than the MCLT allows full recovery from a variety of failures. - -5.2.2. Controlled re-allocation of IP addresses - - When in PARTNER-DOWN state there is a waiting period after which an - IP address can be re-allocated to another client. For IP addresses - which are available when the server enters PARTNER-DOWN state, the - period is the MCLT from entry into PARTNER-DOWN state. For IP - addresses which are not available when the server enters PARTNER-DOWN - state, the period is the MCLT after the IP address becomes available. - See section 9.4.2 for more details. - - In any other state, a server cannot reallocate an address from one - client to another without first notifying its partner (through a - - - -Droms, et. al. Expires September 2003 [Page 26] - -Internet Draft DHCP Failover Protocol March 2003 - - - BNDUPD message) and receiving acknowledgement (through a BNDACK mes- - sage) that its partner is aware that that first client is not using - the address. - - This could be modeled in the following way. Though this specific - implementation is in no way required, it may serve to better illus- - trate the concept. - - An "available" IP address on a server may be allocated to any client. - An IP address which was leased to a client and which expired or was - released by that client would take on a new state, EXPIRED or - RELEASED respectively. The partner server would then be notified - that this IP address was EXPIRED or RELEASED through a BNDUPD. When - the sending server received the BNDACK for that IP address showing it - was FREE, it would move the IP address from EXPIRED or RELEASED to - FREE, and it would be available for allocation by the primary server - to any clients. - - A server MAY reallocate an IP address in the EXPIRED or RELEASED - state to the same client with no restrictions provided it has not - sent a BNDUPD message to its partner. This situation would exist if - the lease expired or was released after the transition into PARTNER- - DOWN state, for instance. - - -5.3. Load balancing - - In order to implement load balancing between a primary and secondary - server pair, each server must respond to DHCPDISCOVER requests from - some clients and not from other clients. In order to do this suc- - cessfully, each server must be able to determine immediately upon - receipt of a DHCP client request whether it is to service this - request or to ignore it in order to allow the other server to service - the request. - - In addition, it should be possible to configure the percentage of - clients which will be serviced by either the primary or secondary - server. This configuration should be more or less continuous, from - all clients serviced by the primary through an even split with half - serviced by each, to all clients serviced by the secondary. - - The technique chosen to support these goals is described in [RFC - 3074]. - - A bitmap-style Hash Bucket Assignment (as described in [RFC 3074]) is - used to determine which DHCP clients can be processed. There are two - potential HBA's in a failover server -- a server HBA and a failover - HBA. The way that a server acquires a server HBA is outside of the - - - -Droms, et. al. Expires September 2003 [Page 27] - -Internet Draft DHCP Failover Protocol March 2003 - - - scope of the failover protocol, but both servers in a failover pair - MUST have the same server HBA. The failover HBA (which specifies the - clients that the secondary is supposed to process) is sent by the - primary server to the secondary server whenever a connection is esta- - blished, using the hash-bucket-assignment option defined in section - 12.11. - - When using the server HBA (if any) and the failover HBA (if any), to - decide whether to process a DHCP request, the server HBA always - applies in every failover state, and the failover HBA (which MUST be - a subset of the server HBA) is used by the secondary server to decide - which packets to process when in NORMAL state. - -5.4. IP address allocations between servers - - The failover protocol allows a DHCP server which implements it to - operate correctly in spite of the uncertainty over whether its - partner has failed or whether the communications link to its partner - has failed. This is made possible in part by the existence of - separate address pools on each server for allocation to newly arrived - DHCP clients. - - Thus, each server has its own pool of available IP addresses. Note - that an IP address is not "owned" by a particular server throughout - its entire lifetime. Only an IP address which is available is - "owned" by a particular server -- once it has been leased to a DHCP - client, it is not owned by either failover partner. When it finally - becomes available again, it will be owned initially by the primary - server, and it may or may not be allocated to the secondary server by - the primary server. - - So, the flow of IP address ownership is as follows: initially an IP - address is owned by the primary server. It may be allocated to the - secondary server if it is available, and then it is owned by the - secondary server. Either server can allocate available IP addresses - which they own to DHCP clients, in which case they cease to own them. - When the DHCP client releases the address or the lease on it expires, - it will again become available and will be owned by the primary. - - An IP address will not become owned by the server which allocated it - initially when it is released or the lease expires because, in gen- - eral, that server will have had to replenish its pool of available - addresses well in advance of any likely lease expirations. Thus, - having a particular IP address cycle back to the secondary might well - put the secondary more out of balance with respect to the primary - instead of enhancing the balance of available addresses between them. - - These address pools are used when in COMMUNICATIONS-INTERRUPTED state - - - -Droms, et. al. Expires September 2003 [Page 28] - -Internet Draft DHCP Failover Protocol March 2003 - - - and while waiting for the MCLT expiration in PARTNER-DOWN state. In - addition, when using load balancing, these pools are used when in - NORMAL state as well. - - This allocation and maintenance of these address pools is an area of - some sensitivity, since the goal is to maintain a more or less con- - stant ratio of available addresses between the two servers. - - The initial allocation when the servers first integrate is triggered - by the POOLREQ message from the secondary to the primary. This is - followed by the POOLRESP message where the primary tells the secon- - dary how many IP addresses it allocated to the secondary. Then, the - primary sends the allocated IP addresses to the secondary via BNDUPD - messages. l The POOLREQ/POOLRESP message is a trigger to the primary - to perform a scan of its database and to ensure that the secondary - has enough IP addresses (based on some configured ratio). - - The actual IP addresses are sent to the secondary using the BNDUPD - message with a state of BACKUP, which indicates the IP address is now - available for allocation by the secondary. Once the message is sent, - the primary MUST NOT use these addresses for allocation to DHCP - clients. - - The POOLREQ/POOLRESP message exchange initiated by the secondary is - valid at any time, and the primary server SHOULD, whenever it - receives the POOLREQ message, scan its database of address pools and - determine if the secondary needs more IP addresses from any of the IP - address pools. - - However, in order to support a reasonably dynamic balance of the IP - addresses between the failover partners, the primary server needs to - do additional work to ensure that the secondary server has as many IP - addresses as it needs (but that it doesn't have *more* than it needs - either). - - The primary server SHOULD examine the balance of available addresses - between the primary and secondary for a particular address pool when- - ever the number of available addresses for either the primary or - secondary changes. The primary server SHOULD adjust the available - address balance as required to ensure the configured address balance, - excepting that the primary server SHOULD employ some threshold - mechanism to such a balance adjustment in order to minimize the over- - head of maintaining this balance. - - An example of a threshold approach is: do not attempt to re-balance - the available pools on the primary and secondary until the out of - balance value exceeds a configured value. - - - - -Droms, et. al. Expires September 2003 [Page 29] - -Internet Draft DHCP Failover Protocol March 2003 - - - The primary server can, at any time, send an available IP address to - the secondary using a BNDUPD with the state BACKUP. The primary - server can attempt to take an available IP address away from the - secondary by sending a BNDUPD with the state FREE. If the secondary - accepts the BNDUPD, then it is now available to the PRIMARY and not - available to the secondary. Of course, the secondary MUST reject - that BNDUPD if it has already used that IP address for a DHCP client. - - Whenever the primary server examines the possible available IP - addresses which it could send to the secondary server, the primary - server SHOULD take into account whether load balancing is in use, and - it SHOULD attempt to send to the secondary any IP addresses whose - most recent client would be processed by the secondary under the - current load balancing regime in use. Likewise, when removing avail- - able IP addresses from the secondary server when load balancing is in - use, the primary server SHOULD first remove those IP addresses whose - most recent client would be processed by the primary server under the - current load balancing regime in use. - -5.5. Operating in NORMAL state - - When in NORMAL state, each server services DHCPDISCOVER's and all - other DHCP requests other than DHCPREQUEST/RENEWAL or - DHCPREQUEST/REBINDING from the client set defined by the load balanc- - ing algorithm [RFC 3074]. Each server services DHCPREQUEST/RENEWAL - or DHCPDISCOVER/REBINDING requests from any client. - - In general, whenever the binding database is changed in stable - storage (other than a change resulting from receiving a BNDUPD from - the failover partner), then a BNDUPD message is sent with the con- - tents of that change to the partner server. The partner server then - writes the information about that binding in its bindings database in - stable storage and replies with a BNDACK message. - - The binding database in a DHCP server would normally be changed as a - result of DHCP protocol activity with a DHCP client (e.g., granting - a lease to a DHCP client through the familiar - DISCOVER/OFFER/REQUEST/ACK cycle or extending a lease due to a - renewal from a DHCP client) or possibly (on some servers) because a - lease has expired or undergone another state change that must be - recorded in the DHCP binding database. These are the state changes - that would be communicated to the partner server using a BNDUPD mes- - sage. Of course, receipt of a BNDUPD message itself will normally - cause an update of the binding database for all of the IP addresses - contained in the BNDUPD, and a binding database change such as this - MUST NOT trigger a corresponding BNDUPD message to the partner. - - - - - -Droms, et. al. Expires September 2003 [Page 30] - -Internet Draft DHCP Failover Protocol March 2003 - - -5.6. Operating in COMMUNICATIONS-INTERRUPTED state - - When operating in COMMUNICATIONS-INTERRUPTED state, each server is - operating independently, but does not assume that its partner is not - operating. The partner server might be operating and simply unable - to communicate with this server, or might not be operating. - - Each server responds to the full range of DHCP client messages that - it receives (subject to server load balancing [RFC 3074]), but in - such a way that graceful reintegration is always possible when its - partner comes back into contact with it. - -5.7. Operating in PARTNER-DOWN state - - When operating in PARTNER-DOWN state, a server assumes that its - partner is not currently operating, but does make allowances for the - possibility that that server was operating in the past, though possi- - bly out of communications with this server. It responds to all DHCP - client requests in PARTNER-DOWN state (subject to server load balanc- - ing [RFC 3074]). - -5.8. Operating in RECOVER state - - A server operating in RECOVER state assumes that it is reintegrating - with a server that has been operating in PARTNER-DOWN state, and that - it needs to update its bindings database before it services DHCP - client requests. - - A server may also operate in RECOVER state in order to fully recover - its bindings database from its partner server. - -5.9. Operating in STARTUP state - - A server operating in STARTUP state assumes that failover is opera- - tional, and it spends a short time whenever it comes up attempting to - contact the partner. During this short time, the server is unrespon- - sive to DHCP client requests. This period exists in order to give a - server a chance to determine that its partner has changed state since - it was last in communications, and to react to that changed state (if - any) prior to responding to DHCP client requests. - - The startup period SHOULD be conditioned on the length of time the - server has been down (if that can be determined). If the server has - been down less than the MCLT then it can wait only a few (say 5 or - 10) seconds. If it has been down a longer time (such that the - partner may well have moved to PARTNER-DOWN state), a considerably - longer startup period of 30 to 60 seconds may be warranted, since the - consequences of running while the partner is in PARTNER-DOWN state - - - -Droms, et. al. Expires September 2003 [Page 31] - -Internet Draft DHCP Failover Protocol March 2003 - - - are unpleasant. - - The period of time a server remains in STARTUP state SHOULD be long - enough to ensure that it will connect to the other server if that - server is available for connections. - -5.10. Time synchronization between servers - - The failover protocol is designed to operate between two servers - which have time values which differ by an arbitrarily large amount. - A particular implementation MAY choose to only support servers whose - time values differ by an arbitrarily small amount. - - Note that if an implementation that requires time synchronization - between servers encounters a case where the time is not synchronized - to its satisfaction between two servers, then this failure will prob- - ably prevent the two servers from reaching communications OK status. - In this occurs, and if both servers continue to operate and deal with - clients, potentially troublesome things can happen. For instance, if - there is a safe period configured on either server, then it will - eventually go into PARTNER-DOWN state, but in this case the partner - will not be down. This will almost certainly create problems. Thus, - some method to prevent this sort of situation SHOULD exist in imple- - mentations that can be configured to require time synchronization. - - In any event, whether large or only small differences in time values - are supported, every message that is sent MUST include the time and - every packet that is received MUST be tagged with a time value as - soon as possible after receipt. This time value is used along with - the time value that is sent in every message between the failover - partners to develop a delta time between the servers. This delta - time is used during the connection process to establish a baseline - delta time between the servers, and upon receipt of each message, the - delta time for that message is used to refine the delta time for the - server pair. - - While the algorithm for this refinement of delta time is not speci- - fied as part of this protocol, a server SHOULD allow the delta time - value for a pair of failover servers to be periodically updated to - account for time drift. In addition, the delta time value between - servers SHOULD be smoothed in some fashion, so that transient network - delays will not cause it to vary wildly. - - A server SHOULD recognize a drastic change in the delta time value as - an event to be signaled to a network administrator, as well as reset- - ting the time delta between the failover partners. - - The specific definitions of a minor or drastic change in delta time - - - -Droms, et. al. Expires September 2003 [Page 32] - -Internet Draft DHCP Failover Protocol March 2003 - - - as well as the algorithm used to smooth minor changes into the run- - ning delta time are implementation issues and are not further - addressed in this document. - -5.11. IP address binding-status - - In most DHCP servers an IP address can take on several different - binding-status values, sometimes also called states. While no two - DHCP servers probably have exactly the same possible binding-status - values, the DHCP RFC enforces some commonality among the general - semantics of the binding-status values used by various DHCP server - implementations. - - In order to transmit binding database updates between one server and - another using the failover protocol, some common denominator - binding-status values must be defined. It is not expected that these - binding-status-values correspond with any actual implementation of - the DHCP protocol in a DHCP server, but rather that the binding- - status values defined in this document should be a common denominator - of those in use by many DHCP server implementations. It is a goal of - this protocol that any DHCP server can map the various IP address - binding-status values that it uses internally into these failover IP - address binding-status values on transmission of binding database - updates to its partner, and likewise that it can map any failover IP - address binding-status values it received in a binding update into - its internal IP address binding-status values. - - The IP address binding-status values defined for the failover proto- - col are listed below. Unless otherwise noted below, there MAY be - client information associated with each of these binding-status - values. - - o ACTIVE -- Lease is assigned to a client. Client identification - MUST appear. - - o EXPIRED -- indicates that a client's binding on an IP address - has expired. When the partner server ACK's the BNDUPD of an - EXPIRED IP address, the server sets its internal state to FREE. - It is then available for allocation to any client of the primary - server. It may be allocated to the same client on the server - where the lease expired if a BNDUPD containing the EXPIRED state - has not yet been sent to the partner (e.g., in the event that - the servers are not in communication). Client identification - SHOULD appear. - - o RELEASED -- indicates that a DHCP client sent in a DHCPRELEASE - message. When the partner server ACK's the BNDUPD of an - RELEASED IP address, the server sets its internal state to FREE, - - - -Droms, et. al. Expires September 2003 [Page 33] - -Internet Draft DHCP Failover Protocol March 2003 - - - and it is available for allocation by the primary server to any - DHCP client. It may be allocated to the same client if a BNDUPD - has not yet been sent to the partner. Client identification - SHOULD appear. - - o FREE -- is used when a DHCP server needs to communicate that an - IP address is unused by any DHCP client, but it was not just - released, expired, or reset by a network administrator. When - the partner server ACK's the BNDUPD of a FREE IP address, the - server sets its internal state such that it is available for - allocation by the primary DHCP server to any DHCP client. (Note - that in PARTNER-DOWN state, after waiting the MCLT, the IP - address MAY be allocated to a DHCP client by the secondary - server.) - - Note that when an IP address that was allocated by the secondary - reverts to the FREE state, it must (like any other IP address) - be assigned to the secondary through the POOLREQ/BNDUPD process - before the secondary can reallocate it. - - Client identification MAY appear. - - o ABANDONED -- indicates that an IP address is considered unusable - by the DHCP subsystem. An IP address for which a valid PING - response was received SHOULD be set to ABANDONED. An IP address - for which a DHCPDECLINE was received should be set to ABANDONED. - Client identification MUST NOT appear. - - o RESET -- indicates that this IP address was made available by - operator command. This is a distinct state so that the reason - that the IP address became FREE can be determined. Client iden- - tification MAY appear. - - o BACKUP -- indicates that this IP address can be allocated by the - secondary server to a DHCP client at any time. When the MCLT has - passed after its time of entry into PARTNER-DOWN state, the IP - address may be allocated by the primary to any DHCP client. - Client identification MAY appear. - - These binding-status values are communicated from one failover - partner to another using the binding-status option, see section 12.3 - for details of this option. Unless otherwise noted above there MAY - be client information associated with each of these binding-status - values. - - An IP address will move between these binding-status values using the - following state transition diagram: - - - - -Droms, et. al. Expires September 2003 [Page 34] - -Internet Draft DHCP Failover Protocol March 2003 - - - - - DHCP client DECLINE or - server detected problem - from any state - | - V - +----------+ +--+------+ - External >---->| RESET | (3) |ABANDONED| - command | +<--------+ | - +----------+ +---------+ - | - Comm w/Parter(1) - V - +---------+ Comm(1) +----------+ Comm(1) +---------+ - | EXPIRED |--------->| FREE |<----------| RELEASED| - | | w/Parter | | w/Partner | | - +---------+ +----------+ +---------+ - ^ ^ | | +-----------+ ^ - | | | | | | - | Exp. grace IP | IP addr alloc. IP addr | - | period ends address to sec.(2) reserved | - | | leased V | | - | | by | +----------+ | | - | | primary | BACKUP |<---+ | - | wait for | | | | - | grace period | +----------+ | - | | | | | - | | | IP addr leased by | - | Expired grace | secondary | - | period exists V V | - | | +----------+ | - | | Lease on | ACTIVE | DHCPRELEASE | - +-----+-IP addr---| |------------------+ - expires +----------+ - - - Figure 5.11-1: Transitions between binding-status values. - - (1) This transition MAY also occur if the server is in - PARTNER-DOWN state and the MCLT has passed since the entry - in the RELEASED, EXPIRED, or RESET states. - - (2) This transition MAY occur if the server is the secondary - and the MCLT has passed since its entry into PARTNER-DOWN state. - - (3) This transition MAY occur due to an implementation specific - handling of ABANDONED IP addresses. - - - -Droms, et. al. Expires September 2003 [Page 35] - -Internet Draft DHCP Failover Protocol March 2003 - - - - - - Again, note that a DHCP server implementing the failover protocol - does not have to implement either this state machine or use these - particular binding-status values in its normal operation of allocat- - ing IP addresses to DHCP clients. It only needs to map its internal - binding-status-values onto these "standard" binding-status values, - and map these "standard" binding-status values back into its internal - binding-status values. For example, a server which implements a - grace period for a IP address binding SHOULD simply wait to update - its partner server until the grace period on that binding has run - out. - - The process of setting an IP address to FREE deserves some detailed - discussion. When an IP address is moved to the EXPIRED,RELEASED, or - RESET binding-status on a server, it will send a BNDUPD with the - binding-status of EXPIRED, RELEASED, or RESET to its partner. If its - partner agrees that is acceptable (see sections 7.1.2 and 7.1.3 con- - cerning why a server might not accept a BNDUPD) it will return a - BNDACK with no reject-reason, signifying that it accepted the update. - As part of the BNDUPD processing, the server returning the BNDACK - will set the binding-status of the IP address to FREE, and upon - receipt of the BNDACK the server which sent the BNDUPD will set the - binding-status of the IP address to FREE. Thus, the EXPIRED, - RELEASED, or RESET binding-status is something of a transitory state. - This process is encoded in the transition diagram above by "Comm - w/Partner". - -5.12. DNS dynamic update considerations - - DHCP servers (and clients) can use DNS Dynamic Updates as described - in [RFC 2136] to maintain DNS name-mappings as they maintain DHCP - leases. Many different administrative models for DHCP-DNS integra- - tion are possible. Descriptions of several of these models, and - guidelines that DHCP servers and clients should follow in carrying - them out, are laid out in [FQDN]. The nature of the DHCP failover - protocol introduces some issues concerning dynamic DNS updates that - are not part of non-failover DHCP environments. This section - describes these issues, and defines the information which failover - partners should exchange and the protocol which they should follow in - order to ensure consistent behavior. The presence of this section - should not be interpreted as requiring that implementations of the - DHCP failover protocol must also support DDNS updates. The purpose - of this discussion is to clarify the areas where the DHCP failover - and DHCP-DDNS protocols intersect for the benefit of implementations - which support both protocols, not to introduce a new requirement into - the DHCP failover protocol. Thus, a DHCP server which implements the - - - -Droms, et. al. Expires September 2003 [Page 36] - -Internet Draft DHCP Failover Protocol March 2003 - - - failover protocol MAY also support dynamic DNS updates, but if it - does support dynamic DNS updates it SHOULD utilize the techniques - described here in order to correctly distribute them between the - failover partners. See [FQDN], [DNSRES], and [DHCID] for details of - how DHCP servers update DNS. - - From the standpoint of the failover protocol, there is no reason why - a server which is utilizing the DDNS protocol to update a DNS server - should not be a partner with a server which is not utilizing the DDNS - protocol to update a DNS server. However, a server which is not able - to support DDNS or is not configured to support DDNS SHOULD output a - warning message when it receives BNDUPD messages which indicate that - its failover partner is configured to support the DDNS protocol to - update a DNS server. An implementation MAY consider this an error - and refuse to operate, or it MAY choose to operate anyway, having - warned the user of the problem in some way. - -5.12.1. Relationship between failover and dynamic DNS update - - The failover protocol describes the conditions under which each fail- - over server may renew a lease to its current DHCP client, and - describes the conditions under which it may grant a lease to a new - DHCP client. An analogous set of conditions determines when a fail- - over server should initiate a DDNS update, and when it should attempt - to remove records from the DNS. The failover protocol's conditions - are based on the desired external behavior: avoiding duplicate - address assignments; allowing clients to continue using leases which - they obtained from one failover partner even if they can only commun- - icate with the other partner; allowing the backup DHCP server to - grant new leases even if it is unable to communicate with the primary - server. The desired external DDNS behavior for DHCP failover servers - is: - - 1. Allow timely DDNS updates from the server which grants a - client a lease. Recognize that there is often a DDNS update - lifecycle which parallels the DHCP lease lifecycle. This is - likely to include the addition of records when the lease is - granted, and the removal of DNS records when the lease is sub- - sequently made available for allocation to a different client. - - 2. Communicate enough information between the two failover - servers to allow one to complete the DDNS update 'lifecycle' - even if the other server originally granted the lease. - - 3. Avoid redundant or overlapping DDNS updates, where both fail- - over servers are attempting to perform DDNS updates for the - same lease-client binding. Avoid situations where one partner - is attempting to add RRs related to a lease binding while the - - - -Droms, et. al. Expires September 2003 [Page 37] - -Internet Draft DHCP Failover Protocol March 2003 - - - other partner is attempting to remove RRs related to the same - lease binding. - -5.12.2. Use of the DDNS option - - In order for either server to be able to complete a DDNS update, or - to remove DNS records which were added by its partner, both servers - need to know the FQDN associated with the lease-client binding. The - FQDN associated with the client's A RR and PTR RR SHOULD be communi- - cated from the server which adds records into the DNS to its partner. - The initiating server SHOULD use the DDNS option in the BNDUPD mes- - sages to inform the partner server of the status of any DDNS updates - associated with a lease binding. Failover servers MAY choose not to - include the DDNS option in BNDUPD messages if there has been no - change in the status of any DDNS update related to the lease binding. - The partner server receiving BNDUPD messages containing the DDNS - option SHOULD compare the status flags and the FQDN contained in the - option data with the current DDNS information it has associated with - the lease binding, and update its notion of the DDNS status accord- - ingly. - - The initiating server MAY send a BNDUPD to its partner before the - DDNS update has been successfully completed. If it does so, it SHOULD - leave the 'C' bit in the Flags field clear, to indicate to the - partner that the DDNS update may not be complete. When the DDNS - update has been successfully acknowledged by the DNS server, the ini- - tiating DHCP server SHOULD include the DDNS option in its next BNDUPD - message about the binding, so that the partner server will be able to - record the final status of the DDNS update. The initiating server - SHOULD set the 'C' bit in the DDNS option if the DDNS update was suc- - cessfully accepted by the DNS server. - - Some implementations will choose to send a BNDUPD without waiting for - the DDNS update to complete, and then will send a second BNDUPD once - the DDNS update is complete. Other implementations will delay sending - the partner a BNDUPD until the DDNS update has been acknowledged by - the DNS server, or until some time-limit has elapsed, in order to - avoid sending a second BNDUPD. - - The Domain Name field in the DDNS option contains the FQDN that will - be associated with the A RR (if the server is performing an A RR - update for the client) and the PTR RR. This FQDN may be composed in - any of several ways, depending on server configuration and the infor- - mation provided by the client in its DHCP messages. The client may - supply a hostname which it would like the server to use in forming - the FQDN, or it may supply the entire FQDN. The server may be config- - ured to attempt to use the information the client supplies, it may be - configured with an FQDN to use for the client, or it may be - - - -Droms, et. al. Expires September 2003 [Page 38] - -Internet Draft DHCP Failover Protocol March 2003 - - - configured to synthesize an FQDN. The responsive server SHOULD - include the FQDN that it will be using in DDNS updates it initiates - when it sends the DDNS option. - - Since the responsive server may not have completed the DDNS update at - the time it sends the first BNDUPD about the lease binding, there may - be cases where the FQDN in later BNDUPD messages does not match the - FQDN included in earlier messages. For example, the responsive - server may be configured to handle situations where two or more DHCP - client FQDNs are identical by modifying the most-specific label in - the FQDNs of some of the clients in an attempt to generate unique - FQDNs for them (a process sometimes called "disambiguation"). Alter- - natively, at sites which use some or all of the information which - clients supply to form the FQDN, it's possible that a client's confi- - guration may be changed so that it begins to supply new data. The - responsive server may react by removing the DNS records which it ori- - ginally added for the client, and replacing them with records that - refer to the client's new FQDN. In such cases, the responsive server - SHOULD include the actual FQDN that was used in subsequent DDNS - options. The responsive server SHOULD include relevant client-option - data in the client-request-options option in its BNDUPD messages. - This information may be necessary in order to allow the non- - responsive partner to detect client configuration changes that change - the hostname or FQDN data which the client includes in its DHCP - requests. - -5.12.3. Adding RRs to the DNS - - A failover server which is going to perform DDNS updates SHOULD ini- - tiate the DDNS update when it grants a new lease to a client. The - non-responsive partner SHOULD NOT initiate a DDNS update when it - receives the BNDUPD after the lease has been granted. The failover - protocol ensures that only one of the partners will grant a lease to - any individual client, so it follows that this requirement will - prevent both partners from initiating updates simultaneously. The - server initiating the update SHOULD follow the protocol in [FQDN]. - The server may be configured to perform an A RR update on behalf of - its clients, or not. Ordinarily, a failover server will not initiate - DDNS updates when it renews leases. In two cases, however, a failover - server MAY initiate a DDNS update when it renews a lease to its - existing client: - - 1. When the lease was granted before the server was configured to - perform DDNS updates, the server MAY be configured to perform - updates when it next renews existing leases. Since both - servers are responsive to renewals in NORMAL state, it is not - enough to simply require the non-responsive server to avoid a - DNS update in this case. The server which would be responsive - - - -Droms, et. al. Expires September 2003 [Page 39] - -Internet Draft DHCP Failover Protocol March 2003 - - - to a DHCPDISCOVER from this client (even though the current - request is a DHCPREQUEST/RENEW) is the server which should - initiate the DDNS update. - - 2. If a server is in PARTNER-DOWN state, it can conclude that its - partner is no longer attempting to perform an update for the - existing client. If the remaining server has not recorded that - an update for the binding has been successfully completed, the - server MAY initiate a DDNS update. It MAY initiate this - update immediately upon entry to PARTNER-DOWN state, it may - perform this in the background, or it MAY initiate this update - upon next hearing from the DHCP client. - -5.12.4. Deleting RRs from the DNS - - The failover server which makes an IP address FREE SHOULD initiate - any DDNS deletes, if it has recorded that DNS records were added on - behalf of the client. - - A server not in PARTNER-DOWN state "makes an IP address FREE" when it - initiates a BNDUPD with a binding-status of FREE, EXPIRED, or - RELEASED. Its partner confirms this status by acking that BNDUPD, - and upon receipt of the ACK the server has "made the IP address - FREE". Conversely, a server in PARTNER-DOWN state "makes an IP - address FREE" when it sets the binding-status to FREE, since in - PARTNER-DOWN state no communications is required with the partner. - - It is at this point that it should initiate the DDNS operations to - delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS - deletes for DNS records related to the lease binding as part of send- - ing the BNDACK message. The partner MAY have issued BNDUPD messages - with a binding-status of FREE, EXPIRED, or RELEASED previously, but - the other server will have NAKed these BNDUPD messages. - - The failover protocol ensures that only one of the two partner - servers will be able to make a lease FREE. The server making the - lease FREE may be doing so while it is in NORMAL communication with - its partner, or it may be in PARTNER-DOWN state. If a server is in - PARTNER-DOWN state, it may be performing DDNS deletes for RRs which - its partner added originally. This allows a single remaining partner - server to assume responsibility for all of the DDNS activity which - the two servers were undertaking. - - Another implication of this approach is that no DDNS RR deletes will - be performed while either server is in COMMUNICATIONS-INTERRUPTED - state, since no IP addresses are moved into the FREE state during - that period. - - - - -Droms, et. al. Expires September 2003 [Page 40] - -Internet Draft DHCP Failover Protocol March 2003 - - -5.13. Reservations and failover - - Some DHCP servers support a capability to offer specific pre- - configured IP addresses to DHCP clients. These are real DHCP - clients, they do the entire DHCP protocol, but these servers always - offer the client a specific pre-configured IP address -- and they - offer that IP address to no other clients. Such a capability has - several names, but it is sometimes called a "reservation", in that - the IP address is reserved for a particular DHCP client. - - In a situation where there are two DHCP servers serving the same sub- - net without using failover, the two DHCP server's need to have dis- - joint IP address pools, but identical reservations for the DHCP - clients. - - In a failover context, both servers need to be configured with the - proper reservations in an identical manner, but if we stop there - problems can occur around the edge conditions where reservations are - made for an IP address that has already been leased to a different - client. Different servers handle this conflict in different ways, - but the goal of the failover protocol is to allow correct operation - with any server's approach to the normal processing of the DHCP pro- - tocol. - - The general solution with regards to reservations is as follows. - Whenever a reserved IP address becomes FREE (i.e., when first config- - ured or whenever a client frees it or it expires or is reset), the - primary server MUST show that IP address as FREE (and thus available - for its own allocation) and it MUST send it to the secondary server - with the R bit set in the IP-flags option and the binding-status - BACKUP. - - Note that this implies that a reserved IP address goes through the - normal state changes from FREE to ACTIVE (and possibly back to FREE). - The failover protocol supports this approach to reservations, i.e., - where the IP address undergoes the normal state changes of any IP - address, but it can only be offered to the client for which it is - reserved. Other approaches to the support of reservations exist in - some DHCP server implementations (e.g., where the IP address is - apparently leased to a particular client forever, without any expira- - tion). The goal is for the failover protocol to support any of the - usual approaches to reservations, both those that allow an IP address - to go through different states when reserved, and those that don't. - - From the above, it follows that a reservation soley on the secondary - will not necessarily allow the secondary to offer that address to - client to whom it is reserved. The reservation must also appear on - the primary as well for the secondary to be able to offer the IP - - - -Droms, et. al. Expires September 2003 [Page 41] - -Internet Draft DHCP Failover Protocol March 2003 - - - address to the client to which is is reserved. - - When the reservation on an IP address is cancelled, if the IP address - is currently FREE and the server is the primary, or BACKUP and the - server is the secondary, the server MUST send a BNDUPD to the other - server with the binding-status FREE and the R bit clear. - -5.14. Dynamic BOOTP and failover - - Some DHCP servers support a capability to offer IP addresses to BOOTP - clients without having a particular address previously allocated for - those clients. This capability is often called something like - "dynamic BOOTP". It is discussed briefly in RFC 1534 [RFC 1534]. - - This capability has a negative interaction with the fundamental ele- - ments of the failover protocol, in that an address handed out to a - BOOTP device has no term (or effectively no term, in that usually - they are considered leases for "forever"). There is no opportunity - to hand out a lease which is only the MCLT long when first hearing - from a BOOTP device, because they may only interact once with the - DHCP server and they have no notion of a lease expiration time. Thus - the entire concept of the MCLT and waiting the MCLT after entering - PARTNER-DOWN state is defeated when dealing with BOOTP devices. - - With some restrictions, however, dynamic BOOTP devices can be sup- - ported in a server on a subnet where failover is supported. The only - restriction (and it is not small) is that on any portion of the sub- - net (in any address pool) where dynamic BOOTP devices can be allo- - cated IP addresses, a DHCP server MUST NOT ever use any of the IP - addresses which were previously available for allocation by its fail- - over partner. Thus, the addresses allocated by the primary to the - secondary for allocation that might have been allocated to BOOTP dev- - ices MUST NOT ever be used by the primary server even if it is in - PARTNER-DOWN state and has waited the MCLT after entering that state. - Conversely, addresses available for allocation by the primary MUST - NOT be used by the secondary even it is in PARTNER-DOWN state. The - reason for this is because one of those IP address could have been - allocated by the secondary server to a BOOTP device, and the primary - server would have no way of ever knowing that happened. - - Whenever a server sends BNDUPD message to its partner, if the client - associated with the IP address is a BOOTP client, then the server - MUST set the B bit in the IP-flags option. - - There is a very slight possibility that a BOOTP client could get an - IP address on each server of a failover pair. When these two servers - eventually attempt to resolve this conflict, they SHOULD agree to - disagree, since it is not possible to know which IP address the BOOTP - - - -Droms, et. al. Expires September 2003 [Page 42] - -Internet Draft DHCP Failover Protocol March 2003 - - - client will actually use -- indeed, it could use both. Operator - intervention will, in general, be required to rectify this situation. - Fortunately, it is extremely unlikely to ever actually occur. - -5.15. Guidelines for selecting MCLT - - There is no one correct value for the MCLT. There is an explicit - tradeoff between various factors in selecting an MCLT value. - -5.15.1. Short MCLT - - A short MCLT value will mean that after entering PARTNER-DOWN state, - a server will only have to wait a short time before it can start - allocating its partner's IP addresses to DHCP clients. Furthermore, - it will only have to wait a short time after the expiration of a - lease on an IP address before it can reallocate that IP address to - another DHCP client. - - However the downside of a short MCLT value is that the initial lease - interval that will be offered to every new DHCP client will be short, - which will cause increased traffic as those clients will need to send - in their first renew in a half of a short MCLT time. In addition, - the lease extensions that a server in COMMUNICATIONS-INTERRUPTED - state can give will be only the MCLT after the server has been in - COMMUNICATIONS-INTERRUPTED for around the desired client lease - period. If a server stays in COMMUNICATIONS-INTERRUPTED for that - long, then the leases it hands out will be short and that will - increase the load on that server, possibly causing difficulty. - -5.15.2. Long MCLT - - A long MCLT value will mean that the initial lease period will be - longer and the time that a server in COMMUNICATIONS-INTERRUPTED state - will be able to extend leases (after it has been in COMMUNICATIONS- - INTERRUPTED state for around the desired client lease period) will be - longer. - - However, a server entering PARTNER-DOWN state will have to wait the - longer MCLT before being able to allocate its partner's IP addresses - to new DHCP clients. This may mean that additional IP addresses are - required in order to cover this time period. Further, the server in - PARTNER-DOWN will have to wait the longer MCLT from every lease - expiration before it can reallocate an IP address to a different DHCP - client. - -5.16. What is sent in response to an UPDREQ or UPDREQALL message? - - In section 7.3, the UPDREQ message is defined, and it says that the - - - -Droms, et. al. Expires September 2003 [Page 43] - -Internet Draft DHCP Failover Protocol March 2003 - - - receiving server sends to the requesting server "all of the binding - database information that it has not already seen". In section - 7.4.2, the UPDREQALL message is defined, and it says that the receiv- - ing server sends to the requesting server "all binding database - information". - - Both of these statements need further elaboration. - - First, for the UPDREQ message, the information to be sent in BNDUPD - messages concerns "all of the binding database information it has not - already seen". Since every BNDUPD is acked by the receiving server, - the sending server need only keep track of which IP addresses have - binding database changes not yet seen by the partner, and when they - are finally acked by the partner it can record that. Thus, at any - time, it knows which IP addresses have unacked binding database - information. This is less simple when, across reconfigurations of - the servers, an IP address can change the failover partner to which - it is associated. In that case, it is important to reset the indica- - tion that the partner has seen this binding information. See section - 5.17, below, for a more complete discussion of this issue. - - Second, in the event that a failover server's binding database infor- - mation is restored from a backup, it will be partially out of date. - In this case, its partner's indication of which binding database - information the restored server has seen will be also be out of date. - - The solution to this problem is for a server which is connecting with - its partner to check the partner's last communicated time, and if it - is very much ahead of its own last communicated time, go to into - RECOVER state and transmit an UPDREQALL to allow it to refresh its - state. See section 9.3.2, step 5. If the partner's last communi- - cated time is very much behind its own record of when it last commun- - icated with the partner, then it SHOULD invalidate its information on - which binding database information the partner server knows, so that - it will send all of its relevant binding database information to the - partner. - - Third, in the event that a server receives a UPDREQALL message, what - constitutes "all binding database information"? At first glance this - would seem to be information on every configured IP address in the - server. While this would be technically correct, it may impose a - serious and unacceptable performance penalty on servers which have - millions of configured IP addresses. What can be done to lessen the - data that must be sent for an UPDREQALL? - - When sending "all binding database information", if the sending - server sends only information concerning IP addresses which have been - at some time associated with clients, it will send enough information - - - -Droms, et. al. Expires September 2003 [Page 44] - -Internet Draft DHCP Failover Protocol March 2003 - - - to satisfy the needs of the failover protocol. It need not send - information on any IP addresses that have never been used, since - presumably they will be initialized as available to the primary - server (i.e. FREE) on any server employing failover. - -5.17. How do you determine that your partner is "up to date" for -specific binding? - - Throughout this document, one server is assumed to know for each IP - address binding whether or not its partner is "up to date" for that - binding. There are some subtle issues involved in recording this "up - to date" information about a specific binding. - - In a steady state world, it would suffice to have a single bit in the - binding database to represent the information about whether the - partner was or was not up to date. - - In a more complex environment a configuration change affecting a par- - ticular IP address may change the failover endpoint with which it is - associated, and if this should happen, any "up to date" bit which is - written into the bindings database will be accurate for only the pre- - vious failover endpoint, but not the current failover endpoint. If - failover is disabled and then re-enabled (and the "up to date" bits, - if used, are not cleared) problems can also occur. - - A server MUST have be able to relate the "up to date" condition to a - particular failover endpoint and even a particular instantiation of - that failover endpoint. The techniques to do this are implementation - dependent. - - In addition, section 7.4 requires that a server be able to remember - that an UPDREQALL message has been received and to treat every UPDREQ - message as an UPDREQALL message until the first UPDDONE message is - sent. One way to do this is to clear all of the "up to date" indica- - tions for an entire failover endpoint upon receipt of an UPDREQALL - message, thereby ensuring that every active binding will be sent to - the partner whether through the completion of this UPDREQALL or - through processing of a subsequent UPDREQ message. This is actually - better than remembering that an UPDREQALL was received and turning - every UPDREQ into an UPDREQALL, since any information sent in an - incomplete UPDREQALL (or subsequent UPDREQ messages turned into "all" - messages) will be remembered and not re-sent. - -6. Common Message Format - - This section discusses the common message format that all failover - messages have in common, including the message header format as well - as the common option format. See section 12 for the the definitions - - - -Droms, et. al. Expires September 2003 [Page 45] - -Internet Draft DHCP Failover Protocol March 2003 - - - of the specific options used in the failover protocol. - -6.1. Message header format - - The options contained in the payload data section of the failover - message all use a two byte option number and two byte length format. - - All failover protocol messages are sent over the TCP connection - between failover endpoints and encoded using a message format - specific to the failover protocol. - - There exists a common message format for all failover messages, which - utilizes the options in a way similar to the DHCP protocol. For each - message type, some options are required and some are optional. In - addition, when a message is received any options that are not under- - stood by the receiving server MUST be ignored. - - All of the fields in the fixed portion of the message MUST be filled - with correct data in every message sent. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | message length (2) | msg type (1) |payload off (1)| - +---------------+---------------+---------------+---------------+ - | time (4) | - +---------------------------------------------------------------+ - | xid (4) | - +---------------------------------------------------------------+ - | 0 or more additional header bytes (variable) | - +---------------------------------------------------------------+ - | payload data (variable) | - | | - | formatted as DHCP-style options | - | using a two byte option code and two byte length | - | See section 6.2 for details. | - +---------------------------------------------------------------+ - - - - message length - 2 bytes, network byte order - - This is the length of the message in bytes. It includes the two byte - message length itself. The maximum length is 2048 bytes. The - minimum length is 12. - - - - - - -Droms, et. al. Expires September 2003 [Page 46] - -Internet Draft DHCP Failover Protocol March 2003 - - - msg type - 1 byte - - The message type field is used to distinguish between messages. - - The following message types are defined: - - Value Message Type - ----- ------------ - 0 reserved not used - 1 POOLREQ request allocation of addresses - 2 POOLRESP respond with allocation count - 3 BNDUPD update partner with binding info - 4 BNDACK acknowledge receipt of binding update - 5 CONNECT establish connection with the secondary - 6 CONNECTACK respond to attempt to establish connection with partner - 7 UPDREQALL request full transfer of binding info - 8 UPDDONE ack send and ack of req'd binding info - 9 UPDREQ request transfer of un-acked binding info - 10 STATE inform partner of current state or state change - 11 CONTACT probe communications integrity with partner - 12 DISCONNECT close a connection - - - New message types should be defined in one of two ranges, 0-127 or - 129-255. The range of 0-127 is used for messages that MUST be sup- - ported by every server, and if a server receives a message in the - range of 0-127 that it doesn't understand, it MUST close the TCP con- - nection. The range of 128-255 is used for messages which MAY be sup- - ported but are not required, and if a server receives a message in - this range that it does not understand it SHOULD ignore the message. - - payload offset - 1 byte - - The byte offset of the Payload Data, from the beginning of the - failover message header. The value for the current protocol version - (version 1) is 8. - - time - 4 bytes, network byte order - - The absolute time in GMT when the message was transmitted, - represented as seconds elapsed since Jan 1, 1970 (i.e., similar to - the ANSI C time_t time value representation). While the ANSI C - time_t value is signed, the value used in this specification is - unsigned. - - A server SHOULD set this time as close to the actual transmission of - the message as possible. - - - - -Droms, et. al. Expires September 2003 [Page 47] - -Internet Draft DHCP Failover Protocol March 2003 - - - xid - 4 bytes, network byte order - - This is the transaction id of the failover message. The sender of a - failover protocol message is responsible for setting this number, and - the receiver of the message copies the number over into any response - message, treating it as opaque data. The sender MUST ensure that - every message sent from a particular failover endpoint over the - associated TCP connection has a unique transaction id. - - For failover messages that have no corresponding response message, - the XID value is meaningless, but MUST be supplied. The XID value is - used solely by the receiver of a response message to determine the - corresponding request message. - - Request messages where the XID is used in the corresponding response - messages are: POOLREQ, BNDUPD, CONNECT, UPDREQALL, and UPDREQ. The - corresponding response messages are POOLRESP, BNDACK, CONNECTACK, - UPDDONE, and UPDDONE, respectively. - - As requests/responses don't survive connection reestablishment, XIDs - only need to be unique during a specific connection. - - - payload data - variable length - - The options are placed after the header, after skipping payload - offset bytes from beginning of the message. The payload data options - are not preceded by a "cookie" value. - - The payload data is formatted as DHCP style options using two byte - option codes and two byte option lengths. The option codes are in a - namespace which is unique to the failover protocol. - - The maximum length of the payload data in octets is 2048 less the - size of the header, i.e., the maximum message length is 2048 octets. - -6.2. Common option format - - The options contained in the payload data section of the failover - message all use a two byte option number and two byte length format. - - The option numbers are drawn from an option number space unique to - the failover protocol. All of the message types share a common - option number space and common options definitions, though not all - options are required or meaningful for every message. - - In contrast to the options which appear in DHCP client and server - messages, the options in failover message are ordered. That is, for - - - -Droms, et. al. Expires September 2003 [Page 48] - -Internet Draft DHCP Failover Protocol March 2003 - - - some messages the order in which the options appear in the payload - data area is significant. The messages for which option ordering is - significant explicitly describe the ordering requirements. If no - ordering requirements are mentioned, then the order is not signifi- - cant for that message. - - For all options which refer to time, they all use an absolute time in - GMT. Time synchronization has already been achieved between the - source and the target server using the CONNECT message and is updated - and refined using the time in every packet. - - The time value is an unsigned 32 bit integer in network byte order - giving the number of seconds since 00:00 UTC, 1st January 1970. This - can be converted to an NTP timestamp by adding decimal 2208988800. - This time format will not wrap until the year 2106. Until sometime - in 2038, it is equal to the ANSI C time_t value (which is a signed 32 - bit value and will overflow into a negative number in 2038). - - Options should appear once only in each message (except for BNDUPD - and BNDACK messages where bulking is used, see section 6.3 for - details.) An option that appears twice is not concatenated, but - treated as an error. - - Specific option values are described in section 12. - - See section 13 for how to define additional options. - -6.3. Batching multiple binding update transactions in one BNDUPD mes- -sage - - Implementations of this protocol MAY send multiple binding update - transactions in one BNDUPD message, where a binding update transac- - tion is defined as the set of options which are associated with the - update of a single IP address. All implementations of this protocol - MUST be prepared to receive BNDUPD messages which contain multiple - binding update transactions and respond correctly to them, including - replying with a BNDACK message which contains status for the multiple - binding update transactions contained in the BNDUPD message. - - In the discussion of sending and receiving BNDUPD messages in section - 7.1 and BNDACK messages in section 7.2, each BNDUPD message and - BNDACK message is assumed to contain a single binding update transac- - tion in order to reduce the complexity of the discussions in section - 7. - - Multiple binding update transactions MAY be batched together in one - BNDUPD protocol message with the data sets for the individual tran- - sactions delimited by the assigned-IP-address option, which MUST - - - -Droms, et. al. Expires September 2003 [Page 49] - -Internet Draft DHCP Failover Protocol March 2003 - - - appear first in the option set for each transaction. Ordering of - options between the assigned-IP-address options is not significant. - This is illustrated in the following schematic representation: - - - Non-IP Address/Non-client specific options first - assigned-IP-address option for the first IP address - Options pertaining to first address, including at least the - binding-status option and others as required. - assigned-IP-address option for the second IP address - Options pertaining to second address, including at least the - binding-status option and others as required. - ... - Trailing options (message digest). - - - There MUST be a one-to-one correspondence between BNDUPD and BNDACK - messages, and every BNDACK message MUST contain status for all of the - binding update transactions in the corresponding BNDUPD message. - - The BNDACK message corresponding to a BNDUPD message MUST contain - assigned-IP-address options for all of the binding update transac- - tions in the BNDUPD message. Thus, every BNDACK message contains - exactly the same assigned-IP-address options as does its correspond- - ing BNDUPD message. The order of the assigned-IP-address options - MAY, however, be different. Here is a schematic representation of a - BNDACK: - - - Non-IP Address/Non-client specific options first - assigned-IP-address option for the first IP address - If rejected, reject-reason option and message option. - assigned-IP-address option for the second IP address - If rejected, reject-reason option and message option. - ... - Trailing options (message digest). - - - In case the server chooses to reject some or all of the IP address - binding information in a BNDUPD message in a BNDACK reply, the BNDACK - message MUST contain a reject-reason option following every failed - assigned-IP-address option in order to indicate that the binding - update transaction for that IP address was not accepted and why. As - with a BNDACK message containing a single binding update transaction, - an assigned-IP-address option without any associated reject-reason - option indicates a successful binding update transaction. - - - - - -Droms, et. al. Expires September 2003 [Page 50] - -Internet Draft DHCP Failover Protocol March 2003 - - -7. Protocol Messages - - This section contains the detailed definition of the protocol mes- - sages, including the information to include when sending the message, - as well as the actions to take upon receiving the message. The mes- - sage type for each message appears as [n] in the heading for the mes- - sage (see section 6.1). - -7.1. BNDUPD message [3] - - The binding update (BNDUPD) message is used to send the binding data- - base changes (known as binding update transactions) to the partner - server, and the partner server responds with a binding acknowledge- - ment (BNDACK) message when it has successfully committed those - changes to its own stable storage. - - The rest of the failover protocol exists to determine whether the - partner server is able to communicate or not, and to enable the - partners to exchange BNDUPD/BNDACK messages in order to keep their - binding databases in stable storage synchronized. - - The rest of this section is written as though every BNDUPD message - contains only a single binding update transaction in order to reduce - the complexity of the discussion. See section 6.3 for information on - how to create and process BNDUPD and BNDACK messages which contain - multiple binding update transactions. Note that while a server MAY - generate BNDUPD messages with multiple binding update transactions, - every server MUST be able to process a BNDUPD message which contains - multiple binding update transactions and generate the corresponding - BNDACK messages with status for multiple binding update transactions. - - The following table summarizes the various options for the BNDUPD - message. - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 51] - -Internet Draft DHCP Failover Protocol March 2003 - - - - - binding-status BACKUP - RESET - ABANDONED - Option ACTIVE EXPIRED RELEASED FREE - ------ ------ ------- -------- ---- - assigned-IP-address (3) MUST MUST MUST MUST - IP-flags MUST(4) MUST(4) MUST(4) MUST(4) - binding-status MUST MUST MUST MUST - client-identifier MAY MAY MAY MAY(2) - client-hardware-address MUST MUST MUST MAY(2) - lease-expiration-time MUST MUST NOT MUST NOT MUST NOT - potential-expiration-time MUST MUST NOT MUST NOT MUST NOT - start-time-of-state SHOULD SHOULD SHOULD SHOULD - client-last-trans.-time MUST SHOULD MUST MAY - DDNS(1) SHOULD SHOULD SHOULD SHOULD - client-request-options SHOULD SHOULD NOT SHOULD SHOULD NOT - client-reply-options SHOULD SHOULD NOT SHOULD NOT SHOULD NOT - - (1) MUST if server is performing dynamic DNS for this IP address, else - MUST NOT. - (2) MUST NOT if binding-status is ABANDONED. - (3) assigned-IP-address MUST be the first option for an IP address - (4) IP-flags option MUST appear if any flags are non-zero, else it - MAY appear. - - Table 7.1-1: Options used in a BNDUPD message - - -7.1.1. Sending the BNDUPD message - - A BNDUPD message SHOULD be generated whenever any binding changes. A - change might be in the binding-status, the lease-expiration-time, or - even just the last-transaction-time. In general, any time a DHCP - server writes its stable storage, a BNDUPD message SHOULD be gen- - erated. This will often be the result of the processing of a DHCP - client request, but it might also be the result of a successful - dynamic DNS update operation. Stable storage updates due to BNDUPD - or BNDACK messages SHOULD NOT result in additional BNDUPD messages. - - BNDUPD (and BNDACK) messages refer to the binding-status of the IP - address, and this protocol defines a series of binding-statuses, dis- - cussed in more detail below. Some servers may not support all of - these binding-statuses, and so in those cases they will not be sent. - Upon receipt of a BNDUPD message which contains an unsupported - binding-status, a reasonable interpretation should be made (see sec- - tion 5.10). - - - -Droms, et. al. Expires September 2003 [Page 52] - -Internet Draft DHCP Failover Protocol March 2003 - - - All BNDUPD messages MUST contain the IP address of the binding update - transaction in the assigned-IP-address option. - - All binding update transactions MUST contain an IP-flags option if - the value of any of the flags would be non-zero. The IP-flags option - MAY be omitted if all of the flags that it contains are zero. The - IP-flags option contains a flag which indicates if the IP address is - currently reserved on the server sending the BNDUPD message. It also - contains a flag which indicates that the lease is associated with a - client that used the BOOTP protocol (as opposed to the DHCP protocol) - to interact with the DHCP server. - - All binding update transactions contain a binding-status option, and - it will have one of the values found in section 5.11. Client infor- - mation consists of client-hardware-address and possibly a client- - identifier, and is explained in more detail later in this section. - The following table indicates whether client information should or - should not appear with each binding-status in a binding update tran- - saction: - - - binding-status includes client information - ------------------------------------------------ - ACTIVE MUST - EXPIRED SHOULD - RELEASED SHOULD - FREE MAY - ABANDONED MUST NOT - RESET MAY - BACKUP MAY - - Table 7.1.1-1: Client information required by various - binding-status values. - - - The ACTIVE binding-status requires some options to indicate the - length of the binding: - - - o lease-expiration-time - - The lease-expiration-time option MUST appear, and be set to the - expiration time most recently ACKed to the DHCP client. Note - that the time ACKed to a DHCP client is a lease duration in - seconds, while the lease-expiration-time option in a BNDUPD mes- - sage is an absolute time value. - - o potential-expiration-time - - - -Droms, et. al. Expires September 2003 [Page 53] - -Internet Draft DHCP Failover Protocol March 2003 - - - The potential-expiration-time option MUST appear, and be set to - a value beyond that of the lease-expiration time. This is the - value that is ACKed by the BNDACK message. A server sending a - BNDUPD message MUST be able to recover the potential- - expiration-time sent in every BNDUPD, not just those that - receive a corresponding BNDACK, in order to be able to protect - against possible duplicate allocation of IP addresses after - transitioning to PARTNER-DOWN state. See section 5.2.1 for - details as to why the potential-expiration-time exists and - guidelines for how to decide on the value. - - The following option information applies to all BNDUPD messages, - regardless of the value of the binding-status, unless otherwise - noted. - - o Identifying the client - - For many of the binding-status values a client MUST appear while - for others a client MAY appear, and for some a client MUST NOT - appear. - - A client is identified in a BNDUPD message by at least one and pos- - sibly two options. The client-hardware-address option MUST appear - any time that a client appears in a BNDUPD message, and contains - the hardware type and chaddr information from the DHCP request - packet. A failover client-identifier option MUST appear any time - that a client appears in a BNDUPD message if and only if that - client used a DHCP client-identifier option when communicating with - the DHCP server. See section 12.5 and 12.4 for details of how to - construct these two options from a DHCP request packet. - - o start-time-of-state - - The start-time-of-state SHOULD appear. It is set to the time at - which this IP address first took on the state that corresponds to - the current value of binding-status. - - o last-transaction-time - - The last-transaction-time value SHOULD appear. This is the time at - which this DHCP server last received a packet from the DHCP client - referenced by the client-identifier or client-hardware-address that - was associated with the IP address referenced by the assigned-IP- - address. - - o DDNS - - If the DHCP server is performing dynamic DNS operations on behalf - - - -Droms, et. al. Expires September 2003 [Page 54] - -Internet Draft DHCP Failover Protocol March 2003 - - - of the DHCP client represented by the client-identifier or client- - hardware-address, then it should include a DDNS option containing - the domain name and status of any dynamic DNS operations enabled. - - o client-request-options - - If the BNDUPD was triggered by a request from a DHCP client (typi- - cally those with binding-status of ACTIVE and RELEASED), then the - server SHOULD include options of interest to a failover partner - from the client's request packet in the client-request-options for - transmission to its partner (see section 12.8). - - A server sending a BNDUPD SHOULD remember the "interesting" options - or the information that would appear in an "interesting" option for - transmission at a time when the BNDUPD is not closely associated - with a DHCP client request. - - A server SHOULD send the following "interesting" options. It MAY - send any DHCP client options. As new options are defined, the RFC - defining these options SHOULD include information that they are - "interesting to failover servers" if they should be sent as part of - a BNDUPD. - - - option option - number name - ----------------------------------------- - - 12 host-name - 81 client-FQDN [FQDN] - 82 relay-agent-information [RFC 3046] - 77 user-class [RFC 3004] - 60 vendor-class-identifier - 118 subnet-selection [RFC 3011] - - Table 7.1.1-2: Options which SHOULD be sent in - the client-request-options option in a BNDUPD message. - - - o client-reply-options - - If the BNDUPD was triggered by a request from a DHCP client (typi- - cally those with binding-status of ACTIVE and RELEASED), then the - server SHOULD include options of interest to a failover partner - from the server's DHCP reply packet in the client-reply-options for - transmission to its partner (see section 12.7). - - A server sending a BNDUPD SHOULD remember the "interesting" options - - - -Droms, et. al. Expires September 2003 [Page 55] - -Internet Draft DHCP Failover Protocol March 2003 - - - or the information that would appear in an "interesting" option for - transmission at a time when the BNDUPD is not closely associated - with a DHCP client request. - - A server SHOULD send the following "interesting" options. It MAY - send any DHCP client options. As new options are defined, the RFC - defining these options SHOULD include information that they are - "interesting to failover servers" if they should be sent as part of - a BNDUPD. - - - option option - number name - ----------------------------------------- - - 58 renewal-time - 59 rebinding-time - - Table 7.1.1-3: Options which SHOULD be sent in - the client-reply-options option in a BNDUPD message. - - - The BNDUPD message SHOULD be sent as soon as possible from the time - that the DHCP client received a response and the lease bindings data- - base is written on stable storage. - -7.1.2. Receiving the BNDUPD message - - When a server receives a BNDUPD message, it needs to decide how to - process the binding update transaction it contains and whether that - transaction represents a conflict of any sort. The conflict resolu- - tion process MUST be used on the receipt of every BNDUPD message, not - just those that are received while in POTENTIAL-CONFLICT state, in - order to increase the robustness of the protocol. - - There are three sorts of conflicts: - - o Two clients, one IP address conflict - - This is the duplicate IP address allocation conflict. There are - two different clients each allocated the same address. See sec- - tion 7.1.3 for how to resolve this conflict. - - o Two IP addresses, one client conflict - - This conflict exists when a client on one server is associated - with a one IP address, and on the other server with a different - IP address in the same or a related subnet. This does not refer - - - -Droms, et. al. Expires September 2003 [Page 56] - -Internet Draft DHCP Failover Protocol March 2003 - - - to the case where a single client has addresses in multiple dif- - ferent subnets or administrative domains, but rather the case - where on the same subnet the client has as lease on one IP - address in one server and on a different IP address on the other - server. - - This conflict may or may not be a problem for a given DHCP - server implementation. In the event that a DHCP server requires - that a DHCP client have only one outstanding lease for an IP - address on one subnet, this conflict should be resolved by - accepting the lease information which has the latest client- - last-transaction-time. - - o binding-status conflict - - This is normal conflict, where one server is updating the other - with newer information. See section 7.1.3 for details of how to - resolve these conflicts. - -7.1.3. Deciding whether to accept the binding update transaction in a -BNDUPD message - - When analyzing a BNDUPD message from a partner server, if there is - insufficient information in the BNDUPD to process it, then reject the - BNDUPD with reject-reason 3: "Missing binding information". - - If the IP address in the BNDUPD is not an IP address associated with - the failover endpoint which received the BNDUPD message, then reject - it with reject-reason 1: "Illegal IP address (not part of any address - pool)". - - IP addresses undergo binding status changes for several reasons, - including receipt and processing of DHCP client requests, administra- - tive inputs and receipt of BNDUPD messages. Every DHCP server needs - to respond to DHCP client requests and administrative inputs with - changes to its internal record of the binding-status of an IP - address, and this response is not in the scope of the failover proto- - col. However, the receipt of BNDUPD messages implies at least a pos- - sible change of the binding-status for an IP address, and must be - discussed here. See section 7.1.2 for general actions to take upon - receipt of a BNDUPD message. - - Every BNDUPD message SHOULD contain a client-last-transaction-time - option, which MUST, if it appears, be the time that the server last - interacted with the DHCP client. It MUST NOT be, for instance, the - time that the lease on an IP address expired. If there has been no - interaction with the DHCP client in question (or there is no DHCP - client presently associated with this IP address), then there will be - - - -Droms, et. al. Expires September 2003 [Page 57] - -Internet Draft DHCP Failover Protocol March 2003 - - - no client-last-transaction-time option in the BNDUPD message. - - The list in Figure 7.1.3-1 is indexed by the binding-status that a - server receives in a BNDUPD message. In many cases, the binding- - status of an IP address within the receiving server's data storage - will have an affect upon the checks performed prior to accepting the - new binding-status in a BNDUPD message. - - In Figure 7.1.3-1, to "accept" a BNDUPD means to update the server's - bindings database with the information contained in the BNDUPD and - once that update is complete, send a BNDACK message corresponding to - the BNDUPD message. To "reject" a BNDUPD means to respond to the - BNDUPD with a BNDACK with a reject-reason option included. - - When interpreting the information in the following table (Figure - 7.1.3-1), for those rules that are listed with "time" -- if a BNDUPD - doesn't have a client-last-transaction-time value, then it MUST NOT - be considered later than the client-last-transaction-time in the - receiving server's binding. If the BNDUPD contains a client-last- - transaction-time value and the receiving server's binding does not, - then the client-last-transaction-time value in the BNDUPD MUST be - considered later than the server's. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 58] - -Internet Draft DHCP Failover Protocol March 2003 - - - - binding-status in received BNDUPD - binding-status - in receiving FREE RESET - server ACTIVE EXPIRED RELEASED BACKUP ABANDONED - - ACTIVE accept(5) time(2) time(1) time(2) accept - EXPIRED time(1) accept accept accept accept - RELEASED time(1) time(1) accept accept accept - FREE/BACKUP accept accept accept accept accept - RESET time(3) accept accept accept accept - ABANDONED reject(4) reject(4) reject(4) reject(4) accept - - time(1): If the client-last-transaction-time in the BNDUPD - is later than the client-last-transaction-time in the - receiving server's binding, accept it, else reject it. - - time(2): If the current time is later than the receiving - servers' lease-expiration-time, accept it, else reject it. - - time(3): If the client-last-transaction-time in the BNDUPD - is later than the start-time-of-state in the receiving server's - binding, accept it, else reject it. - - (1,2,3): If rejecting, use reject reason 15: "Outdated binding - information". - - (4): Use reject reason 16: "Less critical binding information". - - (5): If the clients in a BNDUPD message and in a receiving - server's binding differ, then if the receiving server is a - secondary accept it, else reject it with a reject reason of 2: - "Fatal conflict exists: address in use by other client". - - Figure 7.1.3-1: Accepting BNDUPD messages - - - - If the IP address in the BNDUPD message has the R flag set in the - IP-flags option, indicating it is a reserved IP address, and if the - binding-status in the BNDUPD is BACKUP, then if the receiving server - does not show the IP address as reserved, the receiving server SHOULD - reject the BNDUPD using reject reason 19: "IP not reserved on this - server". - -7.1.4. Accepting the BNDUPD message - - When accepting a BNDUPD message, the information contained in the - - - -Droms, et. al. Expires September 2003 [Page 59] - -Internet Draft DHCP Failover Protocol March 2003 - - - client-request-options and client-reply-options SHOULD be examined - for any information of interest to this server. For instance, a - server which wished to detect changes in client specified host names - might want to examine and save information from the host-name or - client-FQDN options. Servers which expect to utilize information - from the relay-agent-information option SHOULD store this informa- - tion. - -7.1.5. Time values related to the BNDUPD message - - There are four time values that MAY be sent in a BNDUPD message. - - o lease-expiration-time - - The time that the server gave to the client, i.e., the time that - the server believes that the client's lease will expire. - - o potential-expiration-time - - The time that the server wants to be sure its partner waits - (added to the MCLT) before assuming that this lease has expired. - Typically some time beyond the desired client lease time. - - o client-last-transaction-time - - The time that the client last interacted with this server. - - o start-time-of-state - - The time at which the binding first went into the current state. - - As discussed in section 5.2, each server knows what its partner has - ACKed with regard to potential-expiration time. In addition, each - server needs to remember what it has told its partner as the - potential-expiration-time. Moreover, each server must remember what - it has acked to the *other* server as the most recent potential- - expiration-time from that server. - - Remember that each server sends a potential-expiration-time and - receives an ACK for that as well as receiving a potential- - expiration-time and needing to remember what it has acked for that. - - While they don't have to be named in any particular way, the times - that a server needs to remember for every IP address in order to - implement the failover protocol are: - - o lease-expiration-time - - - - -Droms, et. al. Expires September 2003 [Page 60] - -Internet Draft DHCP Failover Protocol March 2003 - - - The time that a server gave to the DHCP client. A DHCP server - needs to remember this time already, just to be a DHCP server. - A server SHOULD update this time with the lease-expiration time - received from a partner in a BNDUPD if the received lease- - expiration time is later than the lease-expiration time recorded - for this binding. - - o sent-potential-expiration-time - - The latest time sent to the partner for a potential-expiration- - time. - - o acked-potential-expiration-time - - The latest time that the partner has acked for a potential - expiration time. Typically the same as sent-potential- - expiration-time if there is not a BNDUPD outstanding. - - o received-potential-expiration-time - - The latest time that this server has ever received as a - potential-expiration-time from its partner in a BNDUPD that this - server ACKed. - - So, a server has to remember two additional times concerning BNDUPD - messages that it has initiated, and one additional time concerning - BNDUPD message that it has received. How are these times used? - - First, let's look at the time that a DHCP server can offer to a DHCP - client. A server can offer to a DHCP client a time that is no longer - than the MCLT beyond the max( received-potential-expiration-time, - acked-potential-expiration-time). One might think that the server - should be able to offer only the MCLT beyond the acked-potential- - expiration-time, and while that is certainly simple and easy to - understand, it has negative consequences in actual operation. - - To illustrate this, in the simple case where the primary updates the - secondary for a while and then fails, if the secondary can then renew - the client for only the MCLT beyond the acked-potential-expiration- - time, then the secondary will only be able to renew the client for - the MCLT, because the secondary has never sent a BNDUPD packet to the - primary concerning this IP address and client, and so its acked- - potential-expiration-time is zero. - - However, since the secondary is allowed to renew the client with the - MCLT beyond the max( received-potential-expiration-time, acked- - potential-expiration-time), then the secondary can usually renew the - client for the full lease period, at least for the first renew it - - - -Droms, et. al. Expires September 2003 [Page 61] - -Internet Draft DHCP Failover Protocol March 2003 - - - sees from the client, since the received-potential-expiration-time is - generally longer than the client's desired lease interval. The - difference in renew times could make a big difference in server load - on the secondary in this case. - - What are the consequences of allowing a server to offer a DHCP client - a lease term of the MCLT beyond the max( received-potential- - expiration-time, acked-potential-expiration-time)? The consequences - appear whenever a server enters PARTNER-DOWN state, and affect how - long that server has to wait before reallocating expired leases. - With this approach, when a server goes into PARTNER-DOWN state, it - must wait the MCLT beyond the max( lease-expiration-time, sent- - potential-expiration-time, acked-potential-expiration-time, - received-potential-expiration-time ) for each IP address before it - can reallocate that IP address to another DHCP client. One might - normally think that it needed to wait only the MCLT beyond the max( - lease-expiration-time, received-potential-expiration-time ), i.e., - beyond what it has told the client and what it has explicitly acked - to the other server. But with the optimization discussed above -- - where either server can offer the DHCP client a lease term of the - MCLT beyond the max( received-potential-expiration-time, acked- - potential-expiration-time), then the additional times sent- - potential-expiration-time and acked-potential-expiration-time must be - added into the expression, since the partner could have used those - times as part of its own lease time calculation. - - Thus this optimization may require a longer waiting time when enter- - ing PARTNER-DOWN state, but will generally allow servers to operate - considerably more effectively when running in COMMUNICATIONS- - INTERRUPTED state. - -7.2. BNDACK message [4] - - A server sends a binding acknowledgement (BNDACK) message when it has - processed a BNDUPD message and after it has successfully committed to - stable storage any binding database changes made as a result of pro- - cessing the BNDUPD message. A BNDACK message is used to both accept - or reject a BNDUPD message. A BNDACK message which contains a - reject-reason option is a rejection of the corresponding BNDUPD mes- - sage. - - In order to reduce the complexity of the discussion, the rest of this - section is written as though every BNDUPD message contains only a - single binding update transaction and thus every corresponding BNDACK - message would also contain reply information about only a single - binding update transaction. See section 6.3 for information on how - to create and process BNDUPD and BNDACK messages which contain multi- - ple binding update transactions. - - - -Droms, et. al. Expires September 2003 [Page 62] - -Internet Draft DHCP Failover Protocol March 2003 - - - Note that while a server MAY generate BNDUPD messages with multiple - binding update transactions, every server MUST be able to process a - BNDUPD message which contains multiple binding update transactions - and generate the corresponding BNDACK messages with status for multi- - ple binding update transactions. If a server does not ever create - BNDUPD messages which contain multiple binding update transactions, - then it does not need to be able to process a received BNDACK message - with multiple binding update transactions. However, all servers MUST - be able to create BNDACK messages which deal with multiple binding - update transactions received in a BNDUPD message. - - Every BNDUPD message that is received by a server MUST be responded - to with a corresponding BNDACK message. The receiving server SHOULD - respond quickly to every BNDUPD message but it MAY choose to respond - preferentially to DHCP client requests instead of BNDUPD messages, - since there is no absolute time period within which a BNDACK must be - sent in response to a BNDUPD message, while DHCP clients frequently - have strict time constraints. - - A BNDACK message can only be sent in response to a BNDUPD message - using the same TCP connection from which the BNDUPD message was - received, since the XID's in BNDUPD messages are guaranteed unique - only during the life of a single TCP connection. When a connection - to a partner server goes down, a server with unprocessed BNDUPD mes- - sages MAY simply drop all of those messages, since it can be sure - that the partner will resend them when they are next in communica- - tions (albeit with a different XID), or it MAY instead choose to pro- - cess those BNDUPD messages, but it MUST NOT send any BNDACK messages - in response. - - The following table summarizes the options for the BNDACK message. - - - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 63] - -Internet Draft DHCP Failover Protocol March 2003 - - - - - Option accept reject - ------ ------ ------ - assigned-IP-address (1) MUST MUST - IP-flags SHOULD NOT SHOULD NOT - binding-status SHOULD NOT SHOULD NOT - client-identifier SHOULD NOT SHOULD NOT - client-hardware-address SHOULD NOT SHOULD NOT - reject-reason SHOULD NOT MUST - message SHOULD NOT SHOULD - lease-expiration-time SHOULD NOT SHOULD NOT - potential-expiration-time SHOULD NOT SHOULD NOT - start-time-of-state SHOULD NOT SHOULD NOT - client-last-trans.-time SHOULD NOT SHOULD NOT - DDNS(1) SHOULD NOT SHOULD NOT - - (1) assigned-IP-address MUST be the first option for an IP address - - Table 7.2-1: Options used in a BNDACK message - - -7.2.1. Sending the BNDACK message - - The BNDACK message MUST contain the same xid as the corresponding - BNDUPD message. - - The assigned-IP-address option from the BNDUPD message MUST be - included in the BNDACK message. Any additional options from the - BNDUPD message SHOULD NOT appear in the BNDACK message. Note that - any information sent in options (e.g, a later lease-expiration time) - in the BNDACK message MUST NOT be assumed to necessarily be recorded - in the stable storage of the server who receives the BNDACK message - because there is no corresponding ACK of the BNDACK message. Any - information that SHOULD be recorded in the partner server's stable - storage MUST be transmitted in a subsequent BNDUPD. - - If the server is accepting the BNDUPD, the BNDACK message includes - only the assigned-IP-address option. If the server is rejecting the - BNDUPD, the additional option reject-reason MUST appear in the BNDACK - message, and the message option SHOULD appear in this case containing - a human-readable error message describing in some detail the reason - for the rejection of the BNDUPD message. - - If the server rejects the BNDUPD message with a BNDACK and a reject- - reason option, it may be because the server believes that it has - binding information that the other server should know. A server - which is rejecting a BNDUPD may initiate a BNDUPD of its own in order - - - -Droms, et. al. Expires September 2003 [Page 64] - -Internet Draft DHCP Failover Protocol March 2003 - - - to update its partner with what it believes is better binding infor- - mation, but it MUST ensure through some means that it will not end up - in a situation where each server is sending BNDUPD messages as fast - as possible because they can't agree on which server has better bind- - ing data. Placing a considerable delay on the initiation of a BNDUPD - message after sending a BNDACK with a reject-reason would be one way - to ensure this situation doesn't occur. - -7.2.2. Receiving the BNDACK message - - When a server receives a BNDACK message, if it doesn't contain a - reject-reason option that means that the BNDUPD message was accepted, - and the server which sent the BNDUPD SHOULD update its stable storage - with the potential-expiration-time value sent in the BNDUPD message. - - If the BNDACK message contains a reject-reason option, that means - that the BNDUPD was rejected. There SHOULD be a message option in - the BNDACK giving a text reason for the rejection, and the server - SHOULD log the message in some way. The server MUST NOT immediately - try to resend the BNDUPD message as there is no reason to believe the - partner won't reject it a second time. However a server MAY choose - to send another BNDUPD at some future time, for instance when the - server next processes an update request from its partner. - -7.3. UPDREQ message [9] - - The update request (UPDREQ) message is used by one server to request - that its partner send it all of the binding database information that - it has not already seen. Since each server is required to keep - track at all times of the binding information the other server has - ACKed, one server can request transmission of all un-ACKed binding - database information held by the other server by using the UPDREQ - message. - - The UPDREQ message is used whenever the sending server cannot proceed - before it has processed all previously un-ACKed binding update infor- - mation, since the UPDREQ message should yield a corresponding UPDDONE - message. The UPDDONE message is not sent until the server that sent - the UPDREQ message has responded to all of the BNDUPD messages gen- - erated by the UPDREQ message with BNDACK messages (they may either be - accepted or rejected by the BNDACK messages, but they MUST have been - responded to). Thus, the sender of the UPDREQ message can be sure - upon receipt of an UPDDONE message that it has received and committed - to stable storage all outstanding binding database updates. - - See section 9, Failover Endpoint States, for the details of when the - UPDREQ message is sent. - - - - -Droms, et. al. Expires September 2003 [Page 65] - -Internet Draft DHCP Failover Protocol March 2003 - - -7.3.1. Sending the UPDREQ message - - The UPDREQ message has no message specific options. - -7.3.2. Receiving the UPDREQ message - - A server receiving an UPDREQ message MUST send all binding database - changes that have not yet been ACKed by the sending server. These - changes are sent as undistinguished BNDUPD messages. - - However, the server which received and is processing the UPDREQ mes- - sage MUST track the BNDACK messages that correspond to the BNDUPD - messages triggered by the UPDREQ message and, when they are all - received, the server MUST send an UPDDONE message. - - The server processing the UPDREQ message and sending BNDUPD messages - to its partner SHOULD only track the BNDUPD and BNDACK message pairs - for unACKed binding database changes that were present upon the - receipt of the UPDREQ message. A server which has received an UPDREQ - message SHOULD send BNDUPD messages for binding database changes that - occur after receipt of the UPDREQ message, but it SHOULD NOT include - those additional BNDUPD messages and their corresponding BNDACK mes- - sages in the accounting necessary to consider the UPDREQ complete and - subsequently send the UPDDONE message. If some additional binding - database changes end up becoming part of the set of BNDUPD messages - considered as part of the UPDREQ (due to whatever algorithm the - server uses to scan its bindings database for unacked changes) it - will probably not cause any difficulty, but a server MUST NOT attempt - to include all such later BNDUPD messages in the accounting for the - UPDREQ in order to be able to transmit an UPDDONE message. - - When queuing up the BNDUPD messages for transmission to the sender of - the UPDREQ message, the server processing the UPDREQ message MUST - honor the value returned in the max-unacked-bndupd option in the CON- - NECT or CONNECTACK message that set up the connection with the send- - ing server. It MUST NOT send more BNDUPD messages without receiving - corresponding BNDACKs than the value returned in max-unacked-bndupd. - (See section 8 for more details.) - -7.4. UPDREQALL message [7] - - The update request all (UPDREQALL) message is used by one server to - request that its partner send it all of the binding database informa- - tion. This message is used to allow one server to recover from a - failure of stable storage and to restore its binding database in its - entirety from the other server. - - A server which sends an UPDREQALL message cannot proceed until all of - - - -Droms, et. al. Expires September 2003 [Page 66] - -Internet Draft DHCP Failover Protocol March 2003 - - - its binding update information is restored, and it knows that all of - that information is restored when an UPDDONE message is received. - - See section 9, Protocol state transitions, for the details of when - the UPDREQALL message is sent. - - The UPDREQALL message has no message specific options. - -7.4.1. Sending the UPDREQALL message - - The UPDREQALL is sent. - -7.4.2. Receiving the UPDREQALL message - - A server receiving an UPDREQALL message MUST send all binding data- - base information to the sending server. See section 5.16 for details - of what might actually comprise "all binding database information". - - A server receiving an UPDREQALL message MUST remember that such a - message has been received, ensure that all binding information extant - at that point is sent to the partner prior to any UPDDONE message - being sent to that partner. One way to do this is to remember the - receipt of an UPDREQALL message and to and treat every subsequent - UPDREQ message as an UPDREQALL message until it sends the first - UPDDONE message after receipt of the UPDREQALL message. This - requirement exists because communications may fail and become re- - established between the two servers, and the specific conditions - which provoked the UPDREQALL message may not longer exist even though - the UPDREQALL message may not yet have completed. See section 5.17 - for information on a more efficient way to meet the above require- - ment. - - These changes are sent as undistinguished BNDUPD messages. Otherwise - the processing is the same as for the UPDREQ message. See section - 7.3.2 for details. - -7.5. UPDDONE message [8] - - The update done (UPDDONE) message is used by a server receiving an - UPDREQ or UPDREQALL message to signify that it has sent all of the - BNDUPD messages requested by the UPDREQ or UPDREQALL request and that - it has received a BNDACK for each of those messages. - - While a BNDACK message MUST have been received for each BNDUPD mes- - sage prior to the transmission of the UPDDONE message, this doesn't - necessarily mean that all of the BNDUPD messages were accepted, only - that all of them were responded to with a BNDACK message. Thus, a - NAK (comprised of a BNDACK message containing a reject-reason option) - - - -Droms, et. al. Expires September 2003 [Page 67] - -Internet Draft DHCP Failover Protocol March 2003 - - - could be used to reject a BNDUPD, but for the purposes of the UPDDONE - message, such NAK would count as a response to the associated BNDUPD - message, and would not block the eventual transmission of the UPDDONE - message. - - The xid in an UPDDONE message MUST be identical to the xid in the - UPDREQ or UPDREQALL message that initiated the update process. - - The UPDDONE message has no message specific options. - -7.5.1. Sending the UPDDONE message - - The UPDDONE message SHOULD be sent as soon as the last BNDACK message - corresponding to a BNDUPD message requested by the UPDREQ or - UPDREQALL is received from the server which sent the UPDREQ or - UPDREQALL. The XID of the UPDDONE message MUST be the same as the - XID of the corresponding UPDREQ or UPDREQALL message. - -7.5.2. Receiving the UPDDONE message - - A server receiving the UPDDONE message knows that all of the informa- - tion that it requested by sending an UPDREQ or UPDREQALL message has - now been sent and that it has recorded this information in its stable - storage. It typically uses the receipt of an UPDDONE message to move - to a different failover state. See sections 9.5.2 and 9.8.3 for - details. - -7.6. POOLREQ message [1] - - The pool request (POOLREQ) message is used by the secondary server to - request an allocation of IP addresses from the primary server. It - MUST be sent by a secondary server to a primary server to request IP - address allocation by the primary. The IP addresses allocated are - transmitted using normal BNDUPD messages from the primary to the - secondary. - - The POOLREQ message SHOULD be sent from the secondary to the primary - whenever the secondary makes a transition into NORMAL state. It - SHOULD periodically be resent in order that any change in the number - of available IP addresses on the primary be reflected in the pool on - the secondary. The period may be influenced by the secondary - server's leasing activity. - - The POOLREQ message has no message specific options. - -7.6.1. Sending the POOLREQ message - - The POOLREQ message is sent. - - - -Droms, et. al. Expires September 2003 [Page 68] - -Internet Draft DHCP Failover Protocol March 2003 - - -7.6.2. Receiving the POOLREQ message - - When a primary server receives a POOLREQ message it SHOULD examine - the binding database and determine how many IP addresses the secon- - dary server should have, and set these IP addresses to BACKUP state. - It SHOULD then send BNDUPD messages concerning all of these IP - addresses to the secondary server. - - Servers frequently have several kinds of IP addresses available on a - particular network segment. The failover protocol assumes that both - primary and secondary servers are configured in such a way that each - knows the type and number of IP addresses on every network segment - participating in the failover protocol. The primary server is - responsible for allocating the secondary server the correct propor- - tion of available IP addresses of each kind, and the secondary server - is responsible for being configured in such a way that it can tell - the kind of every IP address based solely on the IP address itself. - - A primary server MUST keep track of how many IP addresses were allo- - cated as a result of processing the POOLREQ message, and send that - number in the POOLRESP message. - - A primary server MAY choose to defer processing a POOLREQ message - until a more convenient time to process it, but it should not depend - on the secondary server to resend the POOLREQ message in that case. - - If a secondary server receives a POOLREQ message it SHOULD report an - error. - -7.7. POOLRESP message [2] - - A primary server sends a POOLRESP message to a secondary server after - the allocation process for available addresses to the secondary - server is complete. Typically this message will precede some of the - BNDUPD messages that the primary uses to send the actual allocated IP - addresses to the secondary. - - The xid in the POOLRESP message MUST be identical to the xid in the - POOLREQ message for which this POOLRESP is a response. - - -7.7.1. Sending the POOLRESP message - - The POOLRESP message MUST contain the same xid as the corresponding - POOLREQ message. - - Only one option MUST appear in a POOLREQ message: - - - - -Droms, et. al. Expires September 2003 [Page 69] - -Internet Draft DHCP Failover Protocol March 2003 - - - o addresses-transferred - - The number of addresses allocated to the secondary server by the - primary server as a result of a POOLREQ is contained in the - addresses-transferred option in a POOLRESP message. Note this - is the number of addresses that are transferred to the secondary - in the primary's binding database as a result of the correspond- - ing POOLREQ message, and that it may be some time before they - can all be transmitted to the secondary server through the use - of BNDUPD messages. - -7.7.2. Receiving the POOLRESP message - - When a secondary server receives a POOLRESP message, it SHOULD send - another POOLREQ message if the value of the addresses-transferred - option is non-zero. - - Typically, no other action is taken on the reception of a POOLRESP - message. - -7.8. CONNECT message [5] - - The connect message is used to establish an applications level con- - nection over a newly created TCP connection. It gives the source - information for the connection and critical configuration informa- - tion. It MUST be sent only by the primary server. Either server can - initiate a TCP connection, but the CONNECT message is only sent by - the primary server. - - The CONNECT message MUST be the first message sent down a newly esta- - blished connection, and it MUST be sent only by the primary server. - - The following table summarizes the options that are associated with - the CONNECT message: - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 70] - -Internet Draft DHCP Failover Protocol March 2003 - - - - - Option - ------ - relationship-name MUST - max-unacked-bndupd MUST - receive-timer MUST - vendor-class-identifier MUST - protocol-version MUST - TLS-request MUST (1) - MCLT MUST - hash-bucket-assignment MUST - - (1) MUST NOT if CONNECT is being sent over a TLS connection - - Table 7.8-1: Options used in a CONNECT message - - -7.8.1. Sending the CONNECT message - - The CONNECT message MUST be the first message sent by the primary - server after the establishment of a new TCP connection with a secon- - dary server participating in the failover protocol. - - The xid of the CONNECT message is not related to any previous xid - sequence, but initiates the sequence for this connection. - - The name of the failover relationship MUST be placed in the - relationship-name option. This information is placed in an option - inside of the message in order to allow the identity of the sender to - be covered by a shared secret. - - The number of BNDUPD messages the primary server can accept without - blocking the TCP connection MUST be placed in the max-unacked-bndupd - option. This MUST be a number equal to or greater than 1, SHOULD be - a number greater than 10, and SHOULD be a number less than 100. - - The length of the receive timer (tReceive, see section 8.3) MUST be - placed in the receive-timer option. - - The MCLT MUST be placed in the MCLT option. - - The hash-bucket-assignment option MUST be included in the CONNECT - message. In the event that load balancing is not configured for this - server, the hash-bucket-assignment option will indicate that. The - value of the hash-bucket-assignment option is determined from the - specific buckets that the primary server has determined that the - secondary server MUST service as part of the load-balancing - - - -Droms, et. al. Expires September 2003 [Page 71] - -Internet Draft DHCP Failover Protocol March 2003 - - - algorithm. The way in which the primary server determines this - information is outside the scope of this protocol definition. The - primary server SHOULD be configured with a percentage of clients that - the secondary server will be instructed to service, and the primary - server SHOULD use the algorithm in [RFC 3074] to generate a Hash - Bucket Assignment which it sends to the secondary server. - - The vendor class identifier MUST be placed in the vendor-class- - identifier option. - - The protocol-version option MUST be included in every CONNECT mes- - sage. The current value of the protocol version is 1. - - The TLS-request option MUST be sent and contains the desired TLS con- - nection request as well as information concerning whether TLS is sup- - ported. If this CONNECT message is being sent over a already - created TLS connection, the TLS-request MUST NOT appear. - -7.8.2. Receiving the CONNECT message - - When a server established a TCP connection on a failover port, if it - is a PRIMARY server it should send a CONNECT message, and if it is a - secondary server it should wait for a CONNECT message before sending - any messages. To avoid denial of service attacks, a secondary should - only wait for a CONNECT message on a new connection for a limited - amount of time and close the connection if none is received during - that time. - - When a secondary server receives a CONNECT message it should: - - 1. Record the time at which the message was received. - - 2. Examine the protocol-version option, and decide if this server - is capable of interoperating with another server running that - protocol version. If not, send the CONNECTACK message with - the reject reason 14: "Protocol version mismatch". The server - MUST include its protocol-version in the CONNECTACK message. - - 3. Examine the TLS-request option. Figure out the TLS-reply - value based on the capabilities and configuration of this - server. If the result for the TLS-reply value is a 1 and the - connection is accepted, indicating use of TLS, then immedi- - ately send the CONNECTACK message and go into TLS negotiation. - If the TLS-reply value implies rejection of the connection, - then immediately send the CONNECTACK message with the TLS- - reply value and the appropriate reject-reason option value. - In all other cases, save the TLS-reply option information for - the eventual CONNECTACK message. - - - -Droms, et. al. Expires September 2003 [Page 72] - -Internet Draft DHCP Failover Protocol March 2003 - - - The possibilities for TLS-request and TLS-reply are: - - CONNECT CONNECTACK - TLS TLS - request reply - Reject - t1 t1 Reason Comments - -- -- ------ -------- - 0 0 no TLS used - 0 1 11 primary won't use TLS, secondary requires TLS - 1 0 primary desires TLS, secondary doesn't - 1 1 primary desires TLS, secondary will use TLS - 2 0 9, 10 primary requires TLS and secondary won't - 2 1 primary requires TLS and secondary will use TLS - - - - 4. Check to see if there is a message-digest option in the CON- - NECT message. If there was, and the server does not support - message-digests, then reject the connection with reject reason - 12: "Message digest not supported" in the CONNECTACK. If the - server does support message-digests, then check this message - for validity based on the message-digest, and reject it if the - digest indicates the message was altered with reject reason - 20: "Message digest failed to compare". - - 5. Determine if the sender (from the relationship-name option) - and the implicit role of the sender (i.e., primary) represents - a server with which the receiver was configured to engage in - failover activity. This is performed after any TLS or message - digest processing so that it occurs after a secure connection - is created, to ensure that there is no tampering with the - relationship name of the partner. In the absence of any other - security capability (i.e., when TLS or a message digest is not - used), the server MAY wish to be configured with the IP - address of the partner and check the source-ip of the CONNECT - message against that IP address as a weak form of security. - - If not, then the receiving server should reject the CONNECT - request by sending a CONNECTACK message with a reject-reason - value of: 8, invalid failover partner. - - If it is, then the receiving failover endpoint should be - determined. - - 6. Decide if the time delta between the sending of the message, - in the time field, and the receipt of the message, recorded in - step 1 above, is acceptable. A server MAY require an - - - -Droms, et. al. Expires September 2003 [Page 73] - -Internet Draft DHCP Failover Protocol March 2003 - - - arbitrarily small delta in time values in order to set up a - failover connection with another server. See section 5.10 for - information on time synchronization. - - If the delta between the time values is too great, the server - should reject the CONNECT request by sending a CONNECTACK mes- - sage with a reject-reason of 4, time mismatch too great. - - If the time mismatch is not considered too great then the - receiving server MUST record the delta between the servers. - The receiving server MUST use this delta to correct all of the - absolute times received from the other server in all time- - valued options. Note that servers can participate in failover - with arbitrarily great time mismatches, as long as it is more - or less constant. - - 7. Examine the MCLT option in the CONNECT request and use the - value of the MCLT as the MCLT for this failover endpoint. - - The secondary server SHOULD be able to operate with any MCLT - sent by the primary, but if it cannot, then it should send a - CONNECTACK with a reject-reason of 5, MCLT mismatch. In the - event that the MCLT from the primary does not match that con- - figured on the secondary, and the secondary will run with the - primary's value, then the secondary MUST save the MCLT in - secondary storage since it will need it even if it cannot con- - tact the primary. The secondary MUST NOT use a different MCLT - value than it received from the primary even if it cannot con- - tact the primary. - - 8. The server MUST store hash-bucket-assignment option for use - during processing during NORMAL state. If this hash bucket - assignment conflicts with the secondary server's configured - hash bucket assignment for use in other than NORMAL state, the - secondary server should send a CONNECTACK with a reject reason - of 19, Hash bucket assignment conflict. - - 9. The receiving server MAY use the vendor-class-identifier to do - vendor specific processing. - -7.9. CONNECTACK message [6] - - The CONNECTACK message is sent to accept or reject a CONNECT message. - It is sent by the secondary server which received a CONNECT message. - - Attempting immediately to reconnect after either receiving a CONNEC- - TACK with a reject-reason or after sending a CONNECTACK with a - reject-reason could yield unwanted looping behavior, since the reason - - - -Droms, et. al. Expires September 2003 [Page 74] - -Internet Draft DHCP Failover Protocol March 2003 - - - that the connection was rejected may well not have changed since the - last attempt. A simple suggested solution is to wait a minute or two - after sending or receiving a CONNECTACK message with a reject-reason - before attempting to reestablish communication. - - The following table summarizes the options associated with the CON- - NECTACK message: - - - Option accept reject - ------ - relationship-name MUST MUST - max-unacked-bndupd MUST MUST NOT - receive-timer MUST MUST NOT - vendor-class-identifier MUST MUST NOT - protocol-version MUST MUST - TLS-reply (1) (2) - reject-reason MUST NOT MUST - message MUST NOT SHOULD - MCLT MUST NOT MUST NOT - hash-bucket-assignment MUST NOT MUST NOT - - (1) MUST NOT if sending CONNECTACK after TLS negotiation, MUST - if TLS-request in CONNECT, else MUST NOT. - (2) MUST if TLS-request in CONNECT message, else MUST NOT. - - Table 7.9-1: Options used in a CONNECTACK message - - -7.9.1. Sending the CONNECTACK message - - The xid of the CONNECTACK message MUST be that of the corresponding - CONNECT message. - - The name of the relationship MUST be placed in the relationship-name - option. This information is placed in an option inside of the mes- - sage in order to allow the identity of the sender to be covered by a - shared secret. - - The protocol-version option MUST be included in every CONNECTACK mes- - sage. The current value of the protocol version is 1. - - If the connection has been rejected, the reject-reason option MUST be - placed in the CONNECTACK message with an appropriate reason, and a - message option SHOULD be included with a human-readable error message - describing the reason for the rejection in some detail. If the - reject-reason option appears, then the remaining options listed below - do not appear. The sending server should close the connection after - - - -Droms, et. al. Expires September 2003 [Page 75] - -Internet Draft DHCP Failover Protocol March 2003 - - - sending the CONNECTACK if the connection was rejected. - - The results of the TLS negotiation MUST be placed in the TLS-reply - option. If this CONNECTACK message is being sent over an already TLS - secured connection, then there MUST NOT be a TLS-reply option. - - If there was a message-digest option in the CONNECT message, then - there MUST be a message-digest in the CONNECTACK message and any sub- - sequent messages if the CONNECTACK does not contain a reject-reason. - - The number of BNDUPD messages the server can accept without blocking - the TCP connection MUST be placed in the max-unacked-bndupd option. - This SHOULD be a number greater than 10, and SHOULD be a number less - than 100. - - The length of the receive timer (tReceive, see section 8.3) MUST be - placed in the receive-timer option. - - The vendor class identifier MUST be placed in the vendor-class- - identifier option. - - After a connection is created (either by sending a CONNECTACK message - to the first CONNECT message, or sending a CONNECTACK message to a - CONNECT message received over a TLS connection), the server MUST send - a STATE message. - - After a connection is created, the server MUST start two timers for - the connection: tSend and tReceive. The tSend timer SHOULD be - approximately 33 percent of the time in the receiver-timer option in - the corresponding CONNECT message. The tReceive timer SHOULD be the - time sent in the receiver-timer option in the CONNECTACK message. - - The tReceive timer is reset whenever a message is received from this - TCP connection. If it ever expires, the TCP connection is dropped - and communications with this partner is considered not ok. The - reject reason 17: "No traffic within sufficient time" is placed in - the DISCONNECT message sent prior to dropping the TCP connection. - - The tSend timer is reset whenever a message is sent over this connec- - tion. When it expires, a CONTACT message MUST be sent. - -7.9.2. Receiving the CONNECTACK message - - If a CONNECTACK message is received with a different XID from the one - in the CONNECT that was sent, it SHOULD be ignored. To avoid denial - of service attacks, a primary should only wait for a CONNECTACK mes- - sage on a new connection for a limited amount of time and close the - connection if none is received during that time. - - - -Droms, et. al. Expires September 2003 [Page 76] - -Internet Draft DHCP Failover Protocol March 2003 - - - When a CONNECTACK message is received, the following actions should - be taken: - - 1. Record the time the message was received. - - 2. Check to see if the xid on the CONNECTACK matches an outstand- - ing CONNECT message on this TCP connection. - - 3. Check to see if there is a reject-reason option in the CONNEC- - TACK message. If not, continue with step 3. If there is a - reject-reason option, the server SHOULD report the error code. - If a message option appears a server SHOULD display the string - from the message option in a user visible way. The server - MUST close the connection if a reject-reason option appears. - - 4. Check the value of the TLS-reply option (if any, which there - won't be if this CONNECT is taking place utilizing TLS), and - if it was 1, then skip processing of the rest of the CONNEC- - TACK message, and immediately enter into TLS connection setup. - - This step occurs prior to steps 5 and 6 in order to allow - creation of a secure connection (if required) prior to pro- - cessing the protocol version and IP address information. - - 5. Examine the value of the protocol-version option. If this - server is able to establish connections with another server - running this protocol version, then continue, else close the - connection. - - 6. Decide if the time delta between the sending of the message, - in the time field, and the receipt of the message, recorded in - step 1 above, is acceptable. A server MAY require an arbi- - trarily small delta in time values in order to set up a fail- - over connection with another server. - - If the delta between the time values is too great, the server - should drop the TCP connection (see section 7.12). - - If the time mismatch is not considered too great then the - receiving server MUST record the delta between the servers. - The receiving server MUST use this delta to correct all of the - absolute times received from the other server in all time- - valued options. Note that the failover protocol is con- - structed so that two servers can be failover partners with - arbitrarily great time mismatches. - - 7. The receiving server MAY use the vendor-class-identifier to do - vendor specific processing. - - - -Droms, et. al. Expires September 2003 [Page 77] - -Internet Draft DHCP Failover Protocol March 2003 - - - 8. After accepting a CONNECTACK message, the server MUST send a - STATE message. - - After receiving a CONNECTACK message, the server MUST start - two timers for the connection: tSend and tReceive. The tSend - timer SHOULD be approximately 20 percent of the time in the - receiver-timer option in the corresponding CONNECTACK message. - The tReceive timer SHOULD be set to the time sent in the - receiver-timer option in the CONNECT message. - - The tReceive timer is reset whenever a message is received - from this TCP connection. If it ever expires, the TCP connec- - tion is dropped and communications with this partner is con- - sidered not ok. The reject reason 17: "No traffic within suf- - ficient time" is placed in the DISCONNECT message sent prior - to dropping the TCP connection. - - The tSend timer is reset whenever a message is sent over this - connection. When it expires, a CONTACT message MUST be sent. - -7.10. STATE message [10] - - The state (STATE) message is used to communicate the current failover - state to the partner server. - - The STATE message MUST be sent after sending a CONNECTACK message - that didn't contain a reject-reason option, and MUST be sent after - receiving a CONNECTACK message without a reject-reason option. - - A STATE message MUST be sent whenever the failover endpoint changes - its failover state and a connection exists to the partner. - - The STATE message requires no response from the failover partner. - - The following table shows the options that MUST appear in a STATE - message: - - - Option - ------ - sending-state MUST - server-flags MUST - start-time-of-state MUST - - Table 7.10-1: Options used in a STATE message - - - - - - -Droms, et. al. Expires September 2003 [Page 78] - -Internet Draft DHCP Failover Protocol March 2003 - - -7.10.1. Sending the STATE message - - The current failover state is placed in the server-state option and - the current state of the STARTUP flag is placed in the server-flags - option. - - The message is sent with a unique xid. - - A server SHOULD only send the STATE message either when the connec- - tion is created (i.e, after sending or receiving a CONNECTACK message - with no reject-reason option), or when there is a change from the - values sent in a previous STATE message. - -7.10.2. Receiving the STATE message - - Every STATE message SHOULD indicate a change in state or a change in - the flags. - - When a STATE message is received, any state transitions specified in - section 9 are taken. - - No response to a STATE message is required. - -7.11. CONTACT message [11] - - The contact (CONTACT) message is sent to verify communications - integrity with a failover partner. The CONTACT message is sent when - no messages have been sent to the failover partner for a specified - period of time. This is determined by the tSend timer expiring (see - section 8.3). - - The CONTACT message has no message specific options. - -7.11.1. Sending the CONTACT message - - The CONTACT message is sent. - -7.11.2. Receiving the CONTACT message - - When a CONTACT message is received, the tReceive timer is reset (as - it is with any message that is received). - - A server SHOULD use the time in the time field and the time the mes- - sage was received to refine the delta time calculations between the - servers. - - - - - - -Droms, et. al. Expires September 2003 [Page 79] - -Internet Draft DHCP Failover Protocol March 2003 - - -7.12. DISCONNECT message [12] - - The DISCONNECT is the last message sent over a connection before - dropping an established connection (note that an established connec- - tion is one where a CONNECTACK has been sent without a reject rea- - son). - - After sending or receiving a DISCONNECT message, a server needs to - have some mechanism to prevent an error loop. Simply reconnecting to - the partner immediately is not the best option, especially after - several consecutive attempts. - - A simple suggested solution is to wait a minute or two after sending - or receiving a DISCONNECT before attempting to reestablish communica- - tion. - - The DISCONNECT message MUST be the last message sent down a connec- - tion before it is closed. - - The following table summarizes the options that are associated with - the DISCONNECT message: - - - Option - ------ - reject-reason MUST - message SHOULD - - Table 7.12-1: Options used in a DISCONNECT message - - - -7.12.1. Sending the DISCONNECT message - - The DISCONNECT message MUST be the last message sent by the a server - which is dropping a TCP connection. - - The xid of the DISCONNECT message must be unique. - - The reject-reason option MUST appear giving a reason why the connec- - tion was dropped. A message option SHOULD appear giving a human - readable error message with possibly more details. - -7.12.2. Receiving the DISCONNECT message - - When a server receives a DISCONNECT message it should log the message - if there was one and possibly raise an alarm of some sort if the - reject reason was one that was sufficiently serious. - - - -Droms, et. al. Expires September 2003 [Page 80] - -Internet Draft DHCP Failover Protocol March 2003 - - -8. Connection Management - - Servers participating in the failover protocol communicate over TCP - connections. These TCP connections are used both to transmit bind- - ing information from one server to another as well as to allow each - server to determine whether communications is possible with the other - server. - - Central to the operation of the failover protocol is a notion of - "communications okay" or "communications failed". Failover state - transitions are taken in many cases when the status of communications - with the partner changes, and the existence or non-existence of a TCP - connections between failover endpoints is used to determine if com- - munications is "okay" or "failed". - - A single TCP connection exists which connects two failover endpoints. - -8.1. Connection granularity - - There exists one TCP connection between each set of failover end- - points. See section 5.1.1 for an explanation of failover endpoints. - - Typically there is one failover endpoint for each end of a failover - relationship between two servers, and only a single relationship - between any two servers. Given the integration of loadbalancing into - the failover protocol, there is little value in having more than one - failover relationship between two servers, though the protocol will - support multiple relationships between two servers. - - Each failover relationship MUST have a unique relationship-name, and - the relationship-name option is used to communicate this name in the - CONNECT and CONNECTACK messages. - -8.2. Creating the TCP connection - - All failover TCP connections are initiated over port 647. Every - server implementing the failover protocol MUST listen on port 647. - - Every server implementing the failover protocol SHOULD attempt to - connect to all of its partners periodically, where the period is - implementation dependent and SHOULD be configurable. In the event - that a connection has been rejected by a CONNECTACK message with a - reject-reason option contained in it or a DISCONNECT message, a - server SHOULD reduce the frequency with which it attempts to connect - to that server but it SHOULD continue to attempt to connect periodi- - cally. - - When a connection attempt succeeds, if the server generating the - - - -Droms, et. al. Expires September 2003 [Page 81] - -Internet Draft DHCP Failover Protocol March 2003 - - - connection attempt is a primary server for that relationship, then it - MUST send a CONNECT message down the connection. If it is not a pri- - mary server for the relationship, then it MUST just drop the connec- - tion and wait for the primary server to connect to it. - - When a connection attempt is received on port 647, the only informa- - tion that the receiving server has is the IP address of the partner - initiating a connection. It also knows whether it has the primary - role for any failover relationships with the connecting server. If - it has any relationships for which it is a primary server, it should - initiate a connection of its own to port 647 of the partner server, - one for each primary relationship it has with that server. - - If it has any relationships with the connecting server for which it - is a seconary server, it should just await the CONNECT message to - determine which relationship this connection is to serve. - - If it has no secondary relationships with the connecting server, it - SHOULD drop the connection. - - To summarize -- a primary server MUST use a connection that it has - initiated in order to send a CONNECT message. Every server that is a - secondary server in a relationship attempts to create a connection to - the server which is primary in the relationship, but that connection - is only used to stimulate the primary server into recognizing that - the secondary server is ready for operation. The reason behind this - is that the secondary server has no way to communicate to the primary - server which relationship a connection is designed to serve. - - A server which has multiple secondary relationships with a primary - server SHOULD only send one stimulus connection attempt to the pri- - mary server. - - Once a connection is established, the primary server MUST send a CON- - NECT message across the connection. A secondary server MUST wait for - the CONNECT message from a primary server. If the secondary server - doesn't receive a CONNECT message from the primary server in an ins- - tallation dependent amount of time, it MAY drop the connection and - send another stimulus connection attempt to the primary server. - - Every CONNECT message includes a TLS-request option, and if the CON- - NECTACK message does not reject the CONNECT message and the TLS-reply - option says TLS MUST be used, then the servers will immediately enter - into TLS negotiation. - - Once TLS negotiation is complete, the primary server MUST resend the - CONNECT message on the newly secured TLS connection and then wait for - the CONNECTACK message in response. The TLS-request and TLS-reply - - - -Droms, et. al. Expires September 2003 [Page 82] - -Internet Draft DHCP Failover Protocol March 2003 - - - options MUST NOT appear in either this second CONNECT or its associ- - ated CONNECTACK message as they had in the first messages. - - The second message sent over a new connection (either a bare TCP con- - nection or a connection utilizing TLS) is a STATE message. Upon the - receipt of this message, the receiver can consider communications up. - - It is entirely possible that two servers will attempt to make connec- - tions to each other essentially simultaneously, and in this case the - secondary server will be waiting for a CONNECT message on each con- - nection. The primary server MUST send a CONNECT message over one - connection and it MUST close the other connection. - - A secondary server MUST NOT respond to the closing of a TCP connec- - tion with a blind attempt to reconnect -- there may be another TCP - connection to the same failover partner already in use. - -8.3. Using the TCP connection for determining communications status - - The TCP connection is used to determine the communications status of - the other server, i.e., communications-ok, or communications- - interrupted. - - Three things must happen for a server to consider that communications - are ok with respect to another server: - - - 1. A TCP connection must be established to the other server. - - 2. A CONNECT message must be received and a CONNECTACK message - sent in response. The CONNECT message is used to determine - the identify of the failover endpoint of the other end of the - TCP connection -- without it, the failover endpoint cannot be - uniquely determined. Without knowledge of the failover end- - point, then the entity with which communications is ok is - undetermined. - - 3. A STATE message must be received from the other server over - the connection. This STATE message initializes important - information necessary to the operation of the state machine - the governs the behavior of this failover endpoint. - - There are two ways that a server can determine that communications - has failed: - - - 1. The TCP connection can go down, yielding an error when - attempting to send or receive a message. This will happen at - - - -Droms, et. al. Expires September 2003 [Page 83] - -Internet Draft DHCP Failover Protocol March 2003 - - - least as often as the period of the tSend timer. - - 2. The tReceive timer can expire. - - In either of these cases, communications is considered interrupted. - - If the tReceive timer expires, the connection MUST be dropped. The - reject reason 17: "No traffic within sufficient time" is placed in - the DISCONNECT message sent prior to dropping the TCP connection. - - Several difficulties arise when trying to use one TCP connection for - both bulk data transfer as well as to sense the communications status - of the other server. One aspect of the problem stems from the dif- - ferent requirements of both uses. The bulk data transfer is of - course critically important to the protocol, but the speed with which - it is processed is not terribly significant. It might well be - minutes before a BNDUPD message is processed, and while not optimal, - such an occasional delay doesn't compromise the correctness of the - protocol. However, the speed with which one server detects the other - server is up (or, more importantly, down) is more highly constrained. - Generally one server should be able to detect that the other server - is not communicating within a minute or less. - - These differing time constraints makes it difficult to use the same - TCP connection for data transfer as well as to sense communications - integrity. See section 3.5 for additional details on TCP. - - The solution to this problem is to require that some message be - received by each end of the connection within a limited time or that - the connection will be considered down. If no messages have been - sent recently, then a CONTACT message is sent. - - In the case where there is no data queued to be sent, this is not a - problem, but in the case where there is data queued to be sent to the - partner, then the CONTACT message will not actually be transmitted - until the queued data is sent. Section 3.5 explains why waiting for - TCP to determine that the connection is down is not acceptable, and - leads to a requirement that the receiving server never block the - sending server from sending CONTACT messages. - - In order to meet this requirement, each server tells the other server - the number of outstanding BNDUPD messages that it will accept. The - receiving server is required to always be able to accept that many - BNDUPD messages off of the connection's input queue even if it cannot - process them immediately, and to accept all other messages immedi- - ately. - - Thus, the sending server's TCP is never blocked from sending a - - - -Droms, et. al. Expires September 2003 [Page 84] - -Internet Draft DHCP Failover Protocol March 2003 - - - message except for very short periods, less than a few seconds unless - the network connection itself has problems. In this case, if the - CONTACT messages don't make it to the partner then the partner will - close the connection. - - DISCUSSION: - - When implementing this capability, one needs to be careful when - sending any message on the TCP connection as TCP can easily block - the server if the local TCP send buffers are full. This can't be - prevented because if the receiver is not reachable (via the net- - work), the sending TCP can't send and thus it will be unable to - empty the local TCP send buffers. So, all send operations either - need to assume they may block for some time or non-blocking sends - must be used carefully. - -8.4. Using the TCP connection for binding data - - Binding data, in the form of BNDUPD messages and BNDACK messages to - respond to them, are sent across the TCP connection. - - In order to support timely detection of any failure in the partner - server, the TCP connection MUST NOT block for more than a very short - time, on the order of a few seconds. Therefore, a server that is - sending BNDUPD messages MUST send only a restricted number before - receiving BNDACK messages about previous messages sent. - - The number of outstanding BNDUPD messages that each server will - accept without causing TCP to block transmission of additional data - (i.e, CONTACT messages) is sent by each server in the CONNECT and - CONNECTACK messages in the max-unacked-bndupd option. - -8.5. Using the TCP connection for control messages - - The TCP connection is used for control messages: POOLREQ, UPDREQ, - STATE, CONTACT, UPDREQALL and the corresponding reply messages: POOL- - RESP, UPDDONE. A server MUST immediately accept all of these mes- - sages from the TCP connection. A server MUST immediately accept any - BNDACK which is received as well. - -8.6. Losing the TCP connection - - When the TCP connection is lost, then communications is not ok with - the other server. A server which has lost communications SHOULD - immediately attempt to reconnect to the other server, and should - retry these connection attempts periodically. - - An acknowledgement message (BNDACK, POOLRESP, UPDDONE) message can - - - -Droms, et. al. Expires September 2003 [Page 85] - -Internet Draft DHCP Failover Protocol March 2003 - - - only be sent in response to a request message (BNDUPD, POOLREQ, - UPDREQ, UPDREQALL) on the same TCP connection from which the request - was received, in part since the XID's in the request messages are - guaranteed unique only during the life of a single TCP connection. - - When a connection to a partner server goes down, a server with unpro- - cessed request messages MAY simply drop all of those messages, since - it can be sure that the partner will resend them when they are next - in communications. A server with unprocessed BNDUPD messages when a - TCP connection goes down MAY instead choose to process those BNDUPD - messages, but it MUST NOT send any BNDACK messages in response (again - because of the issues surrounding XID uniqueness). - - When the TCP connection is closed explicitly, the DISCONNECT message - with a reject-reason option (and, ideally, a message option) MUST be - sent over the TCP connection. - -9. Failover Endpoint States - - This section discusses the various states that a failover endpoint - may take, and the server actions required when entering the state, - operating in the state, and leaving the state, as well as the events - that cause transitions out of the state into another state. - - The state transition diagram in Figure 9.2-1 is relevant for this - section. This is the common state transition diagram for both servers - in a failover pair. In the event that the textual description of a - state differs from the state transition diagram, the textual descrip- - tion is to be considered authoritative. - -9.1. Server Initialization - - When a server starts it starts out in STARTUP state. See section 9.3 - below for details. - -9.2. Server State Transitions - - Whenever a server makes a transition into a new state, it MUST record - the state and the time at which it entered that state in stable - storage. If communications is "ok", it MUST also send a STATE mes- - sage to its failover partner. - - Figure 9.2-1 is the diagram of the server state transitions. The - remainder of this section contains information important to the - understanding of that diagram. - - The server stays in the current state until all of the actions speci- - fied on the state transition are complete. If communications fails - - - -Droms, et. al. Expires September 2003 [Page 86] - -Internet Draft DHCP Failover Protocol March 2003 - - - during one of the actions, the server simply stays in the current - state and attempts a transition whenever the conditions for a transi- - tion are later fulfilled. - - In the state transition diagram below, the "+" or "-" in the upper - right corner of each state is a notation about whether communication - is ongoing with the other server. - - The legend "responsive", "balanced", or "unresponsive" in each state - indicates whether the server is responsive to all DHCP client - requests, running in load balanced mode, or totally unresponsive in - the respective state. The terms "responsive" and "unresponsive" have - the obvious meanings, while "balanced" means that a DHCP server may - respond to all DHCPREQUEST messages that are RENEWAL or REBINDING, - and to all other messages from clients for which the load balancing - algorithm indicates that it MUST respond to. See sections 5.3 and - 9.8.2 for details on load balancing. - - Note that in situations where a server does not respond to a DHCP - client message, it MUST NOT remember any of the information from that - message. - - In the state transition diagram below, when communication is reesta- - blished between the two servers, each must record the state of the - partner when communication was restored. State transitions on one - server in some cases imply state transitions on the partner server, - so a record of the current state of the partner server must be kept - by each server. - - If the state of the partner changes while communicating a server - moves through the communications-failed transition and into whatever - state results. It then immediately moves through whatever state - transition is appropriate given the current state of the partner - server. A server performing this operation SHOULD NOT close the TCP - connection to its partner. - - DISCUSSION: - - The point of this technique is simplicity, both in explanation of - the protocol and in its implementation. The alternative to this - technique of memory of partner state and automatic state transi- - tion on change of partner state is to have every state in the fol- - lowing diagram have a state transition for every possible state of - the partner. With the approach adopted, only the states in which - communications are reestablished require a state transition for - each possible partner state. - - The current state of a server MUST be recorded in stable storage and - - - -Droms, et. al. Expires September 2003 [Page 87] - -Internet Draft DHCP Failover Protocol March 2003 - - - thus be available to the server after a server restart. - - A transition into SHUTDOWN or PAUSED state is not represented in the - following figure, since other than sending that state to its partner, - the remaining actions involved look just like the server halting in - its otherwise current state, which then becomes the previous state - upon server restart. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 88] - -Internet Draft DHCP Failover Protocol March 2003 - - - - +---------------+ V +--------------+ - | RECOVER -|+| | | STARTUP - | - |(unresponsive) | +->+(unresponsive)| - +------+--------+ +--------------+ - +-Comm. OK +-----------------+ - | Other State: | PARTNER DOWN - +<----------------------+ - | RESOLUTION-INTER. | (responsive) | ^ - All POTENTIAL- +----+------------+ | - Others CONFLICT------------ | --------+ | - | CONFLICT-DONE Comm. OK | +--------------+ | - UPDREQ or Other State: | +--+ RESOLUTION - | | - UPDREQALL | | | | | INTERRUPTED | | - Rcv UPDDONE RECOVER All | | | (responsive) | | - | +---------------+ | Others | | +------------+-+ | - +->+RECOVER-WAIT +-| RECOVER | | | ^ | | - |(unresponsive) | WAIT or | | Comm. | Ext. | - +-----------+---+ DONE | | OK Comm. Cmd----->+ - Comm.---+ Wait MCLT | V V V Failed | - Changed | V +---+ +---+-----+--+-+ | | - | +---+----------++ | | POTENTIAL + +-------+ | - | |RECOVER-DONE +-| Wait | CONFLICT +------+ | - +->+(unresponsive) | for |(unresponsive)| Primary | - +------+--------+ Other +>+----+--------++ resolve Comm. | - Comm. OK State: | | ^ conflict Changed | - +---Other State:-+ RECOVER | Secondary | V V | | - | | | DONE | resolve | ++----------+---++ | - | All Others: POTENT. | | conflict | |CONFLICT-DONE-|+| | - | Wait for CONFLICT- | ----+ see (9.10) | | (responsive) | | - | Other State: V V | +------+---------+ | - | NORMAL or RECOVER ++------------+---+ Other State: NORMAL | - | | DONE | NORMAL + +<--------------+ | - | +--+----------+-->+ (balanced) +-------External Command--->+ - | ^ ^ +--------+--------+ or Other State: | - | | | | | SHUTDOWN | - | Wait for Comm. OK Comm. Failed or | | - | Other Other Other State: PAUSED | External - | State: State: | | Command - | RECOVER-DONE NORMAL Start Safe Comm. OK or - | | COMM. INT. Period Timer Other State: Safe - | Comm. OK. | V All Others Period - | Other State: | +---------+--------+ | expiration - | RECOVER +--+ COMMUNICATIONS - +----+ | - | +-------------+ INTERRUPTED | | - RECOVER | (responsive) +-------------------------->+ - RECOVER-WAIT--------->+------------------+ - Figure 9.2-1: Server state diagram. - - - - -Droms, et. al. Expires September 2003 [Page 89] - -Internet Draft DHCP Failover Protocol March 2003 - - - -9.3. STARTUP state - - The STARTUP state affords an opportunity for a server to probe its - partner server, before starting to service DHCP clients. - - DISCUSSION: - - Without the STARTUP state, a server would likely start in a state - derived from its previously stored state (held in stable storage), - if any. However, this may be inconsistent with the current state - of the partner. The STARTUP state affords the opportunity for a - server to potentially learn the partner's state and determine if - that state is consistent with its derived starting state or - whether some significant state change has occurred at the partner - that forces the server to start in another state. This is - especially critical if significant time has elapsed while the - server was down. - - -9.3.1. Operation while in STARTUP state - - Whenever a server is in STARTUP state, it MUST be unresponsive to - DHCP client requests, and so the time spent in the STARTUP state is - necessarily short, typically on the order of a few seconds to a few - tens of seconds. The exact time spent in the STARTUP state is imple- - mentation dependent, and the primary and secondary server are not - required to spend the same amount of time in the STARTUP state. See - section 5.9 for some guidelines on the time to spend in STARTUP - state. - - Whenever a STATE message is sent to the partner while in STARTUP - state the STARTUP bit MUST be set in the server-flags option and the - previously recorded failover state MUST be placed in the server-state - option. - - -9.3.2. Transition out of STARTUP state - - Each server starts out in startup state every time it initializes - itself, and performs the following algorithm as part of its initiali- - zation: - - 1. Is there any record in stable storage of a previous failover - state? If yes, set previous-state to the last recorded state - in stable storage, and continue with step 2. - - Is there any configuration information that indicates that - - - -Droms, et. al. Expires September 2003 [Page 90] - -Internet Draft DHCP Failover Protocol March 2003 - - - this server was previously running but lost its stable - storage? Such information must typically come from some - administrative intervention, since it is difficult for a - server to distinguish first startup from a startup after it - has lost its stable storage. If yes, then set the previous- - state to RECOVER, and set the time-of-failure to whatever time - was configured, and go on to step 2. This time-of-failure - will be used in the transition out of the RECOVER-WAIT state - into the RECOVER-DONE state, below. - - If there is no record of any previous failover state in stable - storage for this server, then set the previous-state to - RECOVER and set the time-of-failure to a time before the - maximum-client-lead-time before now. If using standard Posix - times, 0 would typically do quite well. This will allow two - servers which already have lease information to synchronize - themselves prior to operating. - - Note that neither server is responsive to DHCP client requests - while in the RECOVER state. If both servers can communicate, - however, they will come out of the RECOVER state and progress - through RECOVER-WAIT to RECOVER-DONE and thence to NORMAL or - COMMUNICATIONS-INTERRUPTED state quickly. If both have state, - then they will exchange information. If only one has state, - then the one that does not will complete its update of its - partner quickly (since it has nothing to send). - - In some cases, an existing server will be commissioned as a - failover server and brought back into operation where its - partner is not yet available. In this case, the newly commis- - sioned failover server will not operate until its partner - comes online -- but it has operational responsibilities as a - DHCP server nonetheless. To properly handle this situation, a - server SHOULD be configurable in such a way as to move - directly into PARTNER-DOWN state after the startup period - expires if it has been unable to contact its partner during - the startup period. - - 2. If the previous state is one where communications was "OK", - then set the previous state to the state that is the result of - the communications failed state transition in Figure 9.2-1 (if - such transition is shown -- some states don't have a communi- - cations failed state transition, since they allow both commun- - ications OK and failed). - - 3. Start the STARTUP state timer. The time that a server remains - in the STARTUP state (absent any communications with its - partner) is implementation dependent and SHOULD be - - - -Droms, et. al. Expires September 2003 [Page 91] - -Internet Draft DHCP Failover Protocol March 2003 - - - configurable. It SHOULD be long enough for a TCP connection - to be created to a heavily loaded partner across a slow net- - work. - - 4. Attempt to create a TCP connection to the failover partner. - See section 8.2. - - 5. Wait for "communications okay", i.e., the process discussed in - section 8.2 "Creating the TCP Connection", to complete, - including the receipt of a STATE message from the partner. - - When and if communications become "okay", clear the STARTUP - flag, and set the current state to the previous-state. - - If the partner is in PARTNER-DOWN state, and if the time at - which it entered PARTNER-DOWN state (as received in the - start-time-of-state option in the STATE message) is later than - the last recorded time of operation of this server, then set - the current state to RECOVER. If the time at which it entered - PARTNER-DOWN state is earlier than the last recorded time of - operation of this server, then set the current state to - POTENTIAL-CONFLICT. - - Then, transition to the current state and take the "communica- - tions okay" state transition based on the current state of - this server and the partner. - - 6. If the startup time expires, take an implementation dependent - action: The server MAY go to the previous-state, or the - server MAY wait. - - Reasons to go to previous-state and begin processing: - - If the current server is the only operational server, then if - it waits, there will be no operational DHCP servers. This - situation could occur very easily where one server fails and - then the other crashes and reboots. If the rebooting server - doesn't start processing DHCP client requests without first - being in communication with the other server, then the level - of DHCP redundancy is not particularly high. This is an - appropriate approach if the possibility of partition is low, - or if the safe period expiration time is well beyond the time - at which an operator would notice and react to a partition - situation. It is also quite appropriate if the safe period - will never expire. - - Reasons to wait: - - - - -Droms, et. al. Expires September 2003 [Page 92] - -Internet Draft DHCP Failover Protocol March 2003 - - - If the current server has been down for longer than the - maximum-client-lead-time, and it is partitioned from the other - server, then when it returns it will attempt to use its own - available addresses to allocate to new DHCP clients, and the - other server may well be in PARTNER-DOWN state and may have - already allocated some of those available addresses to DHCP - clients. In cases where the possibility of partition is high, - and the safe period expiration time is less than the likely - operator reaction time, this is a good approach to use. - -9.4. PARTNER-DOWN state - - PARTNER-DOWN state is a state either server can enter. When in this - state, the server does not assume that the other server could still - be operating and servicing a different set of clients, but instead - assumes that it is the only server operating. If one server is in - PARTNER-DOWN state, the other server MUST NOT be operating. - - -9.4.1. Upon entry to PARTNER-DOWN state - - No special actions are required when entering PARTNER-DOWN state. - - The server should continue to attempt to connect to the partner - periodically. - - -9.4.2. Operation while in PARTNER-DOWN state - - A server in PARTNER-DOWN state MUST respond to DHCP client requests. - It will allow renewal of all outstanding leases on IP addresses, and - will allocate IP addresses from its own pool, and after a fixed - period of time (the MCLT interval) has elapsed from entry into - PARTNER-DOWN state, it will allocate IP addresses from the set of all - available IP addresses. - - Once a server has entered NORMAL state, the PARTNER-DOWN state is - entered only on command of an external agency (typically an adminis- - trator of some sort) or after the expiration of an externally config- - ured minimum safe-time after the beginning of COMMUNICATIONS- - INTERRUPTED state. - - Any IP address tagged as available for allocation by the other server - (at entry to PARTNER-DOWN state) MUST NOT be allocated to a new - client until the maximum-client-lead-time beyond the entry into - PARTNER-DOWN state has elapsed. - - A server in PARTNER-DOWN state MUST NOT allocate an IP address to a - - - -Droms, et. al. Expires September 2003 [Page 93] - -Internet Draft DHCP Failover Protocol March 2003 - - - DHCP client different from that to which it was allocated at the - entrance to PARTNER-DOWN state until the maximum-client-lead-time - beyond the maximum of the following times: client expiration time, - most recently transmitted potential-expiration-time, most recently - received ack of potential-expiration-time from the partner, and most - recently acked potential-expiration-time to the partner. See section - 7.1.5 for details. If this time would be earlier than the current - time plus the maximum-client-lead-time, then the time the server - entered PARTNER-DOWN state plus the maximum-client-lead-time is used. - - Two options exist for lease times given out while in PARTNER-DOWN - state, with different ramifications flowing from each. - - If the server wishes the Failover protocol to protect it from loss of - stable storage in PARTNER-DOWN state, then it should ensure that the - MCLT based lease time restrictions in section 5.1 are maintained, - even in PARTNER-DOWN state. - - If the server wishes to forego the protection of the Failover proto- - col in the event of loss of stable storage, then it need recognize no - restrictions on actual client lease times while in PARTNER-DOWN - state. - - A server in PARTNER-DOWN state MUST continue to attempt to establish - communications and synchronization with its partner. - -9.4.3. Transitions out of PARTNER-DOWN state - - When a server in PARTNER-DOWN state succeeds in establishing a con- - nection to its partner, its actions are conditional on the state and - flags received in the STATE message from the other server as part of - the process of establishing the connection. - - If the STARTUP bit is set in the server-flags option of a received - STATE message, a server in PARTNER-DOWN state MUST NOT take any state - transitions based on reestablishing communications. Essentially, if a - server is in PARTNER-DOWN state, it ignores all STATE messages from - its partner that have the STARTUP bit set in the server-flags option - of the STATE message. - - If the STARTUP bit is not set in the server-flags option of a STATE - message received from its partner, then a server in PARTNER-DOWN - state takes the following actions based on the value of the server- - state option in the received STATE message (either immediately after - establishing communications or at any time later when a new state is - received): - - o partner in NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN, - - - -Droms, et. al. Expires September 2003 [Page 94] - -Internet Draft DHCP Failover Protocol March 2003 - - - POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or CONFLICT-DONE - state - - transition to POTENTIAL-CONFLICT state - - o partner in RECOVER, RECOVER-WAIT, SHUTDOWN, PAUSED state - - stay in PARTNER-DOWN state - - o partner in RECOVER-DONE state - - transition into NORMAL state - -9.5. RECOVER state - - This state indicates that the server has no information in its stable - storage or that it is re-integrating with a server in PARTNER-DOWN - state after it has been down. A server in this state MUST attempt to - refresh its stable storage from the other server. - -9.5.1. Operation in RECOVER state - - A server in RECOVER MUST NOT respond to DHCP client requests. - - A server in RECOVER state will attempt to reestablish communications - with the other server. - -9.5.2. Transitions out of RECOVER state - - If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, - or CONFLICT-DONE state when communications are reestablished, then - the server in RECOVER state will move to POTENTIAL-CONFLICT state - itself. - - If the other server is in any other state, then the server in RECOVER - state will request an update of missing binding information by send- - ing an UPDREQ message. If the server has been instructed (through - configuration or other external agency) that it has lost its stable - storage, or if it has deduced that from the fact that it has no - record of ever having talked to its partner, while its partner does - have a record of communicating with it, it MUST send an UPDREQALL - message, otherwise it MUST send an UPDREQ message. See Figure - 9.5.2-1. - - It will wait for an UPDDONE message, and upon receipt of that message - it will transition to RECOVER-WAIT state. - - If communications fails during the reception of the results of the - - - -Droms, et. al. Expires September 2003 [Page 95] - -Internet Draft DHCP Failover Protocol March 2003 - - - UPDREQ or UPDREQALL message, the server will remain in RECOVER state, - and will re-issue the UPDREQ or UPDREQALL when communications are - re-established. (See section 5.17). - - If an UPDDONE message isn't received within an implementation depen- - dent amount of time, and no BNDUPD messages are being received, the - connection SHOULD be dropped. - - - - - A B - Server Server - - | | - RECOVER PARTNER-DOWN - | | - | >--UPDREQ--------------------> | - | | - | <---------------------BNDUPD--< | - | >--BNDACK--------------------> | - ... ... - | | - | <---------------------BNDUPD--< | - | >--BNDACK--------------------> | - | | - | <--------------------UPDDONE--< | - | | - RECOVER-WAIT | - | | - | >--STATE-(RECOVER-WAIT)------> | - | | - | | - Wait MCLT from last known | - time of failover operation | - | | - RECOVER-DONE | - | | - | >--STATE-(RECOVER-DONE)------> | - | NORMAL - | <-------------(NORMAL)-STATE--< | - NORMAL | - | >---- State-(NORMAL)---------------> - | | - | | - - Figure 9.5.2-1: Transition out of RECOVER state - - - - -Droms, et. al. Expires September 2003 [Page 96] - -Internet Draft DHCP Failover Protocol March 2003 - - - -If, at any time while a server is in RECOVER state communications fails, -the server will stay in RECOVER state. When communications are -restored, it will restart the process of transitioning out of RECOVER -state. - -9.6. RECOVER-WAIT state - - This state indicates that the server has done an UPDREQ or UPDREQALL - and has received the UPDDONE message indicating that it has received - all outstanding binding update information. In the RECOVER-WAIT - state the server will wait for the MCLT in order to ensure that any - processing that this server might have done prior to losing its - stable storage will not cause future difficulties. - -9.6.1. Operation in RECOVER-WAIT state - - A server in RECOVER-WAIT MUST NOT respond to DHCP client requests. - -9.6.2. Transitions out of RECOVER-WAIT state - - Upon entry to RECOVER-WAIT state the server MUST start a timer whose - expiration is set to a time equal to the time the server went down - (if known) or the time the server started (if the down-time is - unknown) plus the maximum-client-lead-time. When this timer goes - off, the server will transition into RECOVER-DONE state. - - This is to allow any IP addresses that were allocated by this server - prior to loss of its client binding information in stable storage to - contact the other server or to time out. - - If this is the first time this server has run failover -- as - determined by the information received from the partner, not - necessarily only as determined by this server's stable storage (as - that may have been lost), then the waiting time discussed above may - be skipped, and the server may transition immediately to RECOVER-DONE - state. - - See Figure 9.5.2-1. - - DISCUSSION: - - The actual requirement on this wait period in RECOVER is that it - start not before the recovering server went down, not necessarily - when it came back up. If the time when the recovering server - failed is known, it could be communicated to the recovering server - (perhaps through actions of the network administrator), and the - wait period could be reduced to the maximum-client-lead-time less - - - -Droms, et. al. Expires September 2003 [Page 97] - -Internet Draft DHCP Failover Protocol March 2003 - - - the difference between the current time and the time the server - failed. In this way, the waiting period could be minimized. - Various heuristics could be used to estimate this time, for - example if the recovering server periodically updates stable - storage with a time stamp, the wait period could be calculated to - start at the time of the last update of stable storage plus the - time required for the next update (which never occurred). This - estimate is later than the server went down, but probably not too - much later. - - If the server has never before run failover, then there is no need - to wait in this state -- but, again, to determine if this server - has run failover it is vital that the information provided by the - partner be utilized, since the stable storage of this server may - have been lost. - - If communications fails while a server is in RECOVER-WAIT state, it - has no effect on the operation of this state. The server SHOULD - continue to operate its timer, and the timer goes off during the - period where communications with the other server have failed, then - the server SHOULD transition to RECOVER-DONE state. This is rare -- - failover state transitions are not usually made while communications - are interrupted, but in this case there is no reason to inhibit the - timer. A server MAY state in RECOVER-WAIT state even after expiry of - the timer and transition to RECOVER-DONE state upon re-establishing - communications with the partner if desired. The key point here is to - allow the timer to continue to operate, not whether or not the state - transition is made before or after communications are re-established. - - -9.7. RECOVER-DONE state - - This state exists to allow an interlocked transition for one server - from RECOVER state and another server from PARTNER-DOWN or - COMMUNICATIONS-INTERRUPTED state into NORMAL state. - -9.7.1. Operation in RECOVER-DONE state - - A server in RECOVER-DONE state MUST respond only to - DHCPREQUEST/RENEWAL and DHCPREQUEST/REBINDING DHCP messages. - -9.7.2. Transitions out of RECOVER-DONE state - - When a server in RECOVER-DONE state determines that its partner - server has entered NORMAL or RECOVER-DONE state, then it will transi- - tion into NORMAL state. - - If communications fails while in RECOVER-DONE state, a server will - - - -Droms, et. al. Expires September 2003 [Page 98] - -Internet Draft DHCP Failover Protocol March 2003 - - - stay in RECOVER-DONE state. - - - 9.8. NORMAL state - - NORMAL state is the state used by a server when it is communicating - with the other server, and any required resynchronization has been - performed. While some bindings database synchronization is performed - in NORMAL state, potential conflicts are resolved prior to entry into - NORMAL state as is binding database data loss. - - -9.8.1. Upon entry to NORMAL state - - When entering NORMAL state, a server will send to the other server - all currently unacknowledged binding updates as BNDUPD messages. - - When the above process is complete, if the server entering NORMAL - state is a secondary server, then it will request IP addresses for - allocation using the POOLREQ message. - - -9.8.2. Processing DHCP client requests and load balancing - - In NORMAL state, a server MUST process every DHCPREQUEST/RENEWAL or - DHCPREQUEST/REBINDING request it receives. And, it processes other - requests only for those clients as dictated by the load balancing - algorithm specified in [RFC 3074]. - - As discussed in section 5.3, each server will take the client- - identifier from each DHCP client request (or the client-hardware- - address, i.e., the chaddr if no client-identifier is present in the - request) and use it as the 'Request ID' specified in [RFC 3074]. - After applying the algorithm specified in [RFC 3074] and comparing - the result with the hash bucket assignment (performed during connect - processing between failover servers), each failover server will be - able to unambiguously determine if it should process the DHCP client - request. - -9.8.3. Operation in NORMAL state - - When in NORMAL state, for every DHCP client request that it - processes, as determined by the algorithm described in section 9.8.2, - above, a server will operate in the following manner: - - o Lease time calculations - - As discussed in section 5.2.1, "Control of lease time", the - - - -Droms, et. al. Expires September 2003 [Page 99] - -Internet Draft DHCP Failover Protocol March 2003 - - - lease interval given to a DHCP client can never be more than the - MCLT greater than the most recently received potential- - expiration-time from the failover partner or the current time, - whichever is later. - - As long as a server adheres to this constraint, the specifics of - the lease interval that it gives to a DHCP client or the value - of the potential-expiration-time sent to its failover partner - are implementation dependent. One possible approach is dis- - cussed in section 5.2.1, but that particular approach is in no - way required by this protocol. - - See section 7.1.5 for details concerning the storage of time - associated with IP addresses and how to use these times when - calculating lease times for DHCP clients. - - o Lazy update of partner server - - After an DHCPACK of a IP address binding, the server servicing a - DHCP client request attempts to update its partner with the new - binding information. The lease time used in the update of the - secondary MUST be at least that given to the DHCP client in the - DHCPACK, and the potential-expiration-time MUST be at least the - lease time, and SHOULD be considerably longer. - - o Reallocation of IP addresses between clients - - Whenever a client binding is released or expires, a BNDUPD mes- - sage must be sent to the partner, setting the binding state to - RELEASED or EXPIRED. However, until a BNDACK is received for - this message, the IP address cannot be allocated to another - client. It cannot be allocated to the same client again if a - BNDUPD was sent, otherwise it can. See section 5.2.2. - - In normal state, each server receives binding updates from its - partner server in BNDUPD messages. It records these in its client - binding database in stable storage and then sends a corresponding - BNDACK message to its partner server. It MUST ensure that the infor- - mation is recorded in stable storage prior to sending the BNDACK mes- - sage back to its partner. - - -9.8.4. Transitions out of NORMAL state - - If an external command is received by a server in NORMAL state - informing it that its partner is down, then transition into PARTNER- - DOWN state. Generally, this would be an unusual situation, where - some external agency knew the partner server was down. Using the - - - -Droms, et. al. Expires September 2003 [Page 100] - -Internet Draft DHCP Failover Protocol March 2003 - - - command in this case would be appropriate if the polling interval and - timeout were long. - - If a server in NORMAL state fails to receive acks to messages sent to - its partner for an implementation dependent period of time, it MAY - move into COMMUNICATIONS-INTERRUPTED state. This situation might - occur if the partner server was capable of maintaining the TCP con- - nection between the server and also capable of sending a CONTACT mes- - sage every tSend seconds, but was (for some reason) incapable of pro- - cessing BNDUPD messages. - - If the communications is determined to not be "ok" (as defined in - section 8), then transition into COMMUNICATIONS-INTERRUPTED state. - - If a server in NORMAL state receives any messages from its partner - where the partner has changed state from that expected by the server - in NORMAL state, then the server should transition into - COMMUNICATIONS-INTERRUPTED state and take the appropriate state tran- - sition from there. For example, it would be expected for the partner - to transition from POTENTIAL-CONFLICT into NORMAL state, but not for - the partner to transition from NORMAL into POTENTIAL-CONFLICT state. - - If a server in NORMAL state receives any messages from its partner - where the PARTNER has changed into PAUSED state, the server should - transition into COMMUNICATIONS-INTERRUPTED state. If a server in - NORMAL state receives any messages from its partner where the PARTNER - has changed into SHUTDOWN state, the server should transition into - PARTNER-DOWN state. - -9.9. COMMUNICATIONS-INTERRUPTED State - - A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is - unable to communicate with the other server. Primary and secondary - servers cycle automatically (without administrative intervention) - between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network - connection between them fails and recovers, or as the partner server - cycles between operational and non-operational. No duplicate IP - address allocation can occur while the servers cycle between these - states. - - -9.9.1. Upon entry to COMMUNICATIONS-INTERRUPTED state - - When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been - configured to support an automatic transition out of COMMUNICATIONS- - INTERRUPTED state and into PARTNER-DOWN state (i.e., a "safe period" - has been configured, see section 10), then a timer MUST be started - for the length of the configured safe period. - - - -Droms, et. al. Expires September 2003 [Page 101] - -Internet Draft DHCP Failover Protocol March 2003 - - - A server transitioning into the COMMUNICATIONS-INTERRUPTED state from - the NORMAL state SHOULD raise some alarm condition to alert adminis- - trative staff to a potential problem in the DHCP subsystem. - - -9.9.2. Operation in COMMUNICATIONS-INTERRUPTED State - - In this state a server MUST respond to all DHCP client requests, and - the algorithm for load balancing described in section 5.3 MUST NOT be - used. When allocating new IP addresses, each server allocates from - its own IP address pool, where the primary MUST allocate only FREE IP - addresses, and the secondary MUST allocate only BACKUP IP addresses. - When responding to renewal requests, each server will allow continued - renewal of a DHCP client's current lease on an IP address irrespec- - tive of whether that lease was given out by the receiving server or - not, although the renewal period MUST NOT exceed the maximum client - lead time (MCLT) beyond the latest of: 1) the potential-expiration- - time already acknowledged by the other server, or 2) the lease- - expiration-time, or 3) the potential-expiration-time received from - the partner server. - - However, since the server cannot communicate with its partner in this - state, the acknowledged-potential-expiration time will not be updated - in any new bindings. This is likely to eventually cause the actual- - client-lease-times to be the current time plus the maximum-client- - lead-time (unless this is greater than the desired-client-lease- - time). - - The server should continue to try to establish a connection with its - partner. - - -9.9.3. Transition out of COMMUNICATIONS-INTERRUPTED State - - If the safe period timer expires while a server is in the - COMMUNICATIONS-INTERRUPTED state, it will transition immediately into - PARTNER-DOWN state. - - If an external command is received by a server in COMMUNICATIONS- - INTERRUPTED state informing it that its partner is down, it will - transition immediately into PARTNER-DOWN state. - - If communications is restored with the other server, then the server - in COMMUNICATIONS-INTERRUPTED state will transition into another - state based on the state of the partner: - - o partner in NORMAL or COMMUNICATIONS-INTERRUPTED - - - - -Droms, et. al. Expires September 2003 [Page 102] - -Internet Draft DHCP Failover Protocol March 2003 - - - The partner SHOULD NOT be in NORMAL state here, since upon res- - toration of communications it MUST have created a new TCP con- - nection which would have forced it into COMMUNICATIONS- - INTERRUPTED state. Still, we should account for every state - just in case. - - Transition into the NORMAL state. - - o partner in RECOVER - - Stay in COMMUNICATIONS-INTERRUPTED state. - - o partner in RECOVER-DONE - - Transition into NORMAL state. - - o partner in PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or - RESOLUTION-INTERRUPTED - - Transition into POTENTIAL-CONFLICT state. - - o partner in PAUSED - - Stay in COMMUNICATIONS-INTERRUPTED state. - - o partner in SHUTDOWN - - Transition into PARTNER-DOWN state. - - The following figure illustrates the transition from NORMAL to - COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again. - - - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 103] - -Internet Draft DHCP Failover Protocol March 2003 - - - - Primary Secondary - Server Server - - NORMAL NORMAL - | >--CONTACT-------------------> | - | <--------------------CONTACT--< | - | [TCP connection broken] | - COMMUNICATIONS : COMMUNICATIONS - INTERRUPTED : INTERRUPTED - | [attempt new TCP connection] | - | [connection succeeds] | - | | - | >--CONNECT-------------------> | - | <-----------------CONNECTACK--< | - | NORMAL - | <-------------------STATE-----< | - NORMAL | - | >--STATE---------------------> | - | - | >--BNDUPD--------------------> | - | <---------------------BNDACK--< | - | | - | <---------------------BNDUPD--< | - | >------BNDACK----------------> | - ... ... - | | - | <--------------------POOLREQ--< | - | >--POOLRESP-(2)--------------> | - | | - | >--BNDUPD-(#1)---------------> | - | <---------------------BNDACK--< | - | | - | <--------------------POOLREQ--< | - | >--POOLRESP-(0)--------------> | - | | - | >--BNDUPD-(#2)---------------> | - | <---------------------BNDACK--< | - | | - - Figure 9.9.3-1: Transition from NORMAL to COMMUNICATIONS- - INTERRUPTED and back (example with 2 - addresses allocated to secondary) - - - - - - - - -Droms, et. al. Expires September 2003 [Page 104] - -Internet Draft DHCP Failover Protocol March 2003 - - - -9.10. POTENTIAL-CONFLICT state - - This state indicates that the two servers are attempting to re- - integrate with each other, but at least one of them was running in a - state that did not guarantee automatic reintegration would be - possible. In POTENTIAL-CONFLICT state the servers may determine that - the same IP address has been offered and accepted by two different - DHCP clients. - - It is a goal of this protocol to minimize the possibility that - POTENTIAL-CONFLICT state is ever entered. - -9.10.1. Upon entry to POTENTIAL-CONFLICT state - - When a primary server enters POTENTIAL-CONFLICT state it should - request that the secondary send it all updates of which it is - currently unaware by sending an UPDREQ message to the secondary - server. - - A secondary server entering POTENTIAL-CONFLICT state will wait for - the primary to send it an UPDREQ message. - -9.10.2. Operation in POTENTIAL-CONFLICT state - - Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming - DHCP requests. - - -9.10.3. Transitions out of POTENTIAL-CONFLICT state - - If communications fails with the partner while in POTENTIAL-CONFLICT - state, then the server will transition to RESOLUTION-INTERRUPTED - state. - - Whenever either server receives an UPDDONE message from its partner - while in POTENTIAL-CONFLICT state, it MUST transition to a new state. - The primary MUST transition to CONFLICT-DONE state, and the secondary - MUST transition to NORMAL state. This will cause the primary server - to leave POTENTIAL-CONFLICT state prior to the secondary, since the - primary sends an UPDREQ message and receives an UPDDONE before the - secondary sends an UPDREQ message and receives its UPDDONE message. - - When a secondary server receives an indication that the primary - server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE - state, it SHOULD send an UPDREQ message to the primary server. - - - - - -Droms, et. al. Expires September 2003 [Page 105] - -Internet Draft DHCP Failover Protocol March 2003 - - - - - Primary Secondary - Server Server - - | | - POTENTIAL-CONFLICT POTENTIAL-CONFLICT - | | - | >--UPDREQ--------------------> | - | | - | <---------------------BNDUPD--< | - | >--BNDACK--------------------> | - ... ... - | | - | <---------------------BNDUPD--< | - | >--BNDACK--------------------> | - | | - | <--------------------UPDDONE--< | - CONFLICT-DONE | - | >--STATE--(CONFLICT-DONE)----> | - | <---------------------UPDREQ--< | - | | - | >--BNDUPD--------------------> | - | <---------------------BNDACK--< | - ... ... - | >--BNDUPD--------------------> | - | <---------------------BNDACK--< | - | | - | >--UPDDONE-------------------> | - | NORMAL - | <------------STATE--(NORMAL)--< | - NORMAL | - | >--STATE--(NORMAL)-----------> | - | | - | <--------------------POOLREQ--< | - | >------POOLRESP-(n)----------> | - | addresses | - - Figure 9.10.3-1: Transition out of POTENTIAL-CONFLICT - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 106] - -Internet Draft DHCP Failover Protocol March 2003 - - - -9.11. RESOLUTION-INTERRUPTED state - - This state indicates that the two servers were attempting to re- - integrate with each other in POTENTIAL-CONFLICT state, but - communications failed prior to completion of re-integration. - - If the servers remained in POTENTIAL-CONFLICT while communications - was interrupted, neither server would be responsive to DHCP client - requests, and if one server had crashed, then there might be no - server able to process DHCP requests. - -9.11.1. Upon entry to RESOLUTION-INTERRUPTED state - - When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an - alarm condition to alert administrative staff of a problem in the - DHCP subsystem. - -9.11.2. Operation in RESOLUTION-INTERRUPTED state - - In this state a server MUST respond to all DHCP client requests, and - any load balancing (described in section 5.3) MUST NOT be used. When - allocating new IP addresses, each server SHOULD allocate from its own - IP address pool (if that can be determined), where the primary SHOULD - allocate only FREE IP addresses, and the secondary SHOULD allocate - only BACKUP IP addresses. When responding to renewal requests, each - server will allow continued renewal of a DHCP client's current lease - on an IP address irrespective of whether that lease was given out by - the receiving server or not, although the renewal period MUST not - exceed the maximum client lead time (MCLT) beyond the latest of: 1) - the potential-expiration-time already acknowledged by the other - server or 2) the lease-expiration-time or 3) `potential-expiration- - time received from the partner server. - - However, since the server cannot communicate with its partner in this - state, the acknowledged-potential-expiration time will not be updated - in any new bindings. - - -9.11.3. Transitions out of RESOLUTION-INTERRUPTED state - - If an external command is received by a server in RESOLUTION- - INTERRUPTED state informing it that its partner is down, it will - transition immediately into PARTNER-DOWN state. - - If communications is restored with the other server, then the server - in RESOLUTION-INTERRUPTED state will transition into POTENTIAL- - CONFLICT state. - - - -Droms, et. al. Expires September 2003 [Page 107] - -Internet Draft DHCP Failover Protocol March 2003 - - - -9.12. CONFLICT-DONE state - - This state indicates that during the process where the two servers - are attempting to re-integrate with each other, the primary server - has received all of the updates from the secondary server. It make a - transition into CONFLICT-DONE state in order that it may be totally - responsive to the client load, as opposed to NORMAL state where it - would be in a "balanced" responsive state, running the load balancing - algorithm. - -9.12.1. Upon entry to CONFLICT-DONE state - - A secondary server should never enter CONFLICT-DONE state. - -9.12.2. Operation in CONFLICT-DONE state - - A primary server in CONFLICT-DONE state is fully responsive to all - DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED - state). - - If communications fails, remain in CONFLICT-DONE state. If communi- - cations becomes OK, remain in CONFLICT-DONE state until the condi- - tions for transition out become satisfied. - - -9.12.3. Transitions out of CONFLICT-DONE state - - If communications fails with the partner while in CONFLICT-DONE - state, then the server will remain in CONFLICT-DONE state. - - When a primary server determines that the secondary server has made a - transition into NORMAL state, the primary server will also transition - into NORMAL state. - -9.13. PAUSED state - - This state exists to allow one server to inform another that it will - be out of service for what is predicted to be a relatively short - time, and to allow the other server to transition to COMMUNICATIONS- - INTERRUPTED state immediately and to begin servicing all DHCP clients - with no interruption in service to new DHCP clients. - - A server which is aware that it is shutting down temporarily SHOULD - send a STATE message with the server-state option containing PAUSED - state and close the TCP connection. - - While a server may or may not transition internally into PAUSED - - - -Droms, et. al. Expires September 2003 [Page 108] - -Internet Draft DHCP Failover Protocol March 2003 - - - state, the 'previous' state determined when it is restarted MUST be - the state the server was in prior to receiving the command to shut- - down and restart and which precedes its entry into the PAUSED state. - See section 9.3.2 concerning the use of the previous state upon - server restart. - -9.13.1. Upon entry to PAUSED state - - When entering PAUSED state, the server MUST store the previous state - in stable storage, and use that state as the previous state when it - is restarted. - -9.13.2. Transitions out of PAUSED state - - A server makes a transition out of PAUSED state by being restarted. - At that time, the previous state MUST be the state the server was in - prior to entering the PAUSED state. - - -9.14. SHUTDOWN state - - This state exists to allow one server to inform another that it will - be out of service for what is predicted to be a relatively long time, - and to allow the other server to transition immediately to PARTNER- - DOWN state, and take over completely for the server going down. - -9.14.1. Upon entry to SHUTDOWN state - - When entering SHUTDOWN state, the server MUST record the previous - state in stable storage for use when the server is restarted. It - also MUST record the current time as the last time operational. - - A server which is aware that it is shutting down SHOULD send a STATE - message with the server-state field containing SHUTDOWN. - -9.14.2. Operation in SHUTDOWN state - - A server in SHUTDOWN state MUST NOT respond to any DHCP client input. - - If a server receives any message indicating that the partner has - moved to PARTNER-DOWN state while it is in SHUTDOWN state then it - MUST record RECOVER state as the previous state to be used when it is - restarted. - - A server SHOULD wait for a few seconds after informing the partner of - entry into SHUTDOWN state (if communications are okay) to determine - if the partner entered PARTNER-DOWN state. - - - - -Droms, et. al. Expires September 2003 [Page 109] - -Internet Draft DHCP Failover Protocol March 2003 - - -9.14.3. Transitions out of SHUTDOWN state - - A server makes a transition out of SHUTDOWN state by being restarted. - -10. Safe Period - - Due to the restrictions imposed on each server while in - COMMUNICATIONS-INTERRUPTED state, long-term operation in this state - is not feasible for either server. One reason that these states - exist at all, is to allow the servers to easily survive transient - network communications failures of a few minutes to a few days - (although the actual time periods will depend a great deal on the - DHCP activity of the network in terms of arrival and departure of - DHCP clients on the network). - - Eventually, when the servers are unable to communicate, they will - have to move into a state where they no longer can re-integrate - without some possibility of a duplicate IP address allocation. There - are two ways that they can move into this state (known as PARTNER- - DOWN). - - They can either be informed by external command that, indeed, the - partner server is down. In this case, there is no difficulty in mov- - ing into the PARTNER-DOWN state since it is an accurate reflection of - reality and the protocol has been designed to operate correctly (even - during reintegration) as long as, when in PARTNER-DOWN state the - partner is, indeed, down. - - The more difficult scenario is when the servers are running unat- - tended for extended periods, and in this case an option is provided - to configure something called a "safe-period" into each server. This - OPTIONAL safe-period is the period after which either the primary or - secondary server will automatically transition to PARTNER-DOWN from - COMMUNICATIONS-INTERRUPTED state. If this transition is completed - and the partner is not down, then the possibility of duplicate IP - address allocations will exist. - - The goal of the "safe-period" is to allow network operations staff - some time to react to a server moving into COMMUNICATIONS-INTERRUPTED - state. During the safe-period the only requirement is that the net- - work operations staff determine if both servers are still running -- - and if they are, to either fix the network communications failure - between them, or to take one of the servers down before the expira- - tion of the safe-period. - - The length of the safe-period is installation dependent, and depends - in large part on the number of unallocated IP addresses within the - subnet address pool and the expected frequency of arrival of - - - -Droms, et. al. Expires September 2003 [Page 110] - -Internet Draft DHCP Failover Protocol March 2003 - - - previously unknown DHCP clients requiring IP addresses. Many - environments should be able to support safe-periods of several days. - - During this safe period, either server will allow renewals from any - existing client. The only limitation concerns the need for IP - addresses for the DHCP server to hand out to new DHCP clients and the - need to re-allocate IP addresses to different DHCP clients. - - The number of "extra" IP addresses required is equal to the expected - total number of new DHCP clients encountered during the safe period. - This is dependent only on the arrival rate of new DHCP clients, not - the total number of outstanding leases on IP addresses. - - In the unlikely event that a relatively short safe period of an hour - is all that can be used (given a dearth of IP addresses or a very - high arrival rate of new DHCP clients), even that can provide sub- - stantial benefits in allowing the DHCP subsystem to ride through - minor problems that could occur and be fixed within that hour. In - these cases, no possibility of duplicate IP address allocation - exists, and re-integration after the failure is solved will be - automatic and require no operator intervention. - -11. Security - - The Failover protocol communicates DHCP lease activity and this data - is generally easily discovered via other means, such as by pinging - addresses and doing DNS lookups. Therefore, the need to encrypt the - data over the wire is likely not great (though some sites may feel - differently). - - However, it is very desirable to assure the integrity of failover - partners and to thus ensure proper operation of the servers. For - example, denial of service attacks are possible by the communication - of invalid state information to one or both servers. - - Therefore, the Failover protocol MUST be capable of being secured by - using a simple shared secret message digest which covers each mes- - sage. This provides authentication of the servers, but does not pro- - vide encryption of the data exchange. - - The Failover protocol MAY also be secured by using TLS [RFC 2246] - (Transport Layer Security) if encryption of the data exchange is - desired. The use of the shared secret or TLS will not protect - against TCP or IP layer attacks (such as someone sending fake TCP RST - segments). IPsec [RFC 2401] SHOULD be used to protect against most - (if not all) of these kinds of attacks. - - - - - -Droms, et. al. Expires September 2003 [Page 111] - -Internet Draft DHCP Failover Protocol March 2003 - - -11.1. Simple shared secret - - Messages between the failover partners can be authenticated through - the use of a shared secret, which is never sent over the network and - must be known by each server. How each server is told about this - shared secret and secures its storage of the shared secret is outside - the scope of this document. If a server is configured with a shared - secret for a partner, it MUST send the message-digest option in ALL - messages to that partner and it MUST treat any messages received from - that partner without a message-digest option as failing authentica- - tion and reject them with reject reason 21: "Missing message digest". - Note that the message digest option MUST be the first option in the - message. - - If a server is not configured with a shared secret for a partner, it - MUST NOT send the message-digest option in any message to that - partner and it MUST treat any messages received from that partner - with a message-digest option as failing authentication with reject - reason 13: "Message digest not configured". - - The shared secret is used to calculate a 16 octet message-digest - which is sent in every failover message in the message-digest option. - See section 12.16. The message-digest contains a one-way 16 octet - HMAC-MD5 [RFC 2104] hash calculated over a stream of octets consist- - ing of the entire message concatenated with the shared secret. - - For calculation, the message includes the message-digest option with - the message-digest data zeroed (16-octets of zero). Once the calcula- - tion is complete, these 16 octets of zero are replaced by the 16- - octet HMAC-MD5 hash and the message is sent. - - For verification, the 16-octet message-digest is saved and replaced - with 16-octets of zero and calculated per above. The resulting HMAC- - MD5 hash is compared to the received hash and if they match, the mes- - sage is assumed authenticated. - - A failover partner that fails to authenticate a received message or - receives a message without a message-digest option when configured - with a shared secret MUST close the connection immediately and take - steps to notify operators. - - Every time a CONNECT message is received, the time at which that mes- - sage was sent by the partner (i.e., the time that actually appears in - the message itself) MUST be saved. If a CONNECT message is ever - received containing that time or containing a time before that time, - it MUST be rejected. - - The XID (see section 6.1) of every message received at a failover - - - -Droms, et. al. Expires September 2003 [Page 112] - -Internet Draft DHCP Failover Protocol March 2003 - - - endpoint MUST be greater than that of the previous message received - on that failover endpoint or the message just received MUST be - rejected. - - A server MAY operate with arbitrary time skew between servers (see - section 5.10), but when using a shared secret administrators MAY wish - to configure a maximum allowable time skew between a failover server - and its partner(s). Servers SHOULD allow an administrator to config- - ure a maximum allowable time skew between two failover partners. - -11.2. TLS - - TLS, Transport Layer Security, as specified in [RFC 2246] MAY be - used. The use of TLS would be similar to the way it is used with - SMTP [RFC 2487] and IMAP/POP3/ACAP [RFC 2595]. - - To request the use of TLS, the primary MUST send the TLS-request - option as part of the CONNECT message. The secondary receiving the - TLS-request option MUST respond with a TLS-reply option indicating - its acceptance or rejection of the TLS-request in the CONNECT mes- - sage." - - If the CONNECTACK message contained a TLS-reply of 1 , then both - servers immediately begin TLS negotiation. - - Upon completion of this negotiation, the primary server sends another - CONNECT message without any TLS-request option, and must wait for a - corresponding CONNECTACK. - - Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC 2246] - cipher suite is REQUIRED in Failover servers supporting TLS. This is - important as it assures that any two compliant implementations can be - configured to interoperate. - -12. Failover Options - - This section lists all of the options that are currently defined to - be used with the failover protocol. See section 6.2 for details con- - cerning time values. - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 113] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.1. addresses-transferred - - A 32 bit unsigned long in network byte order. Reports the number of - addresses transferred by the primary to the secondary server - (addresses to be used for the secondary server's private address - pool). - - Code Len Number of Addresses - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 1 | 0 | 4 | n1 | n2 | n3 | n4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - -12.2. assigned-IP-address - - The DHCP managed IP address to which this message refers. - - Code Len Address - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 2 | 0 | 4 | a1 | a2 | a3 | a4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - -12.3. binding-status - - This option is used to convey the current state of a binding. - - Code Len Type - +-----+-----+-----+-----+-----+ - | 0 | 3 | 0 | 1 | 1-7 | - +-----+-----+-----+-----+-----+ - - Legal values for this option are: - - Value Binding Status - ----- ------------------------------------------------ - 1 FREE Lease is currently available to the primary - 2 ACTIVE Lease is assigned to a client - 3 EXPIRED Lease has expired - 4 RELEASED Lease has been released by client - 5 ABANDONED A server, or client flagged address as unusable - 6 RESET Lease was freed by some external agent - 7 BACKUP Lease belongs to secondary's private address pool - - - - - - - -Droms, et. al. Expires September 2003 [Page 114] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.4. client-identifier - - This is the client-identifier for the client associated with a - binding. The client-identifier data is subject to the same - conventions as DHCP option 81 [RFC 2132]. - - Code Len Client Identifier - +-----+-----+-----+-----+----+-----+--- - | 0 | 4 | 0 | n | i1 | i2 | ... - +-----+-----+-----+-----+----+-----+-- - - -12.5. client-hardware-address - - This is the hardware address for the client associated with a - binding. Byte t1 (type) MUST be set to the proper ARP hardware - address code, as defined in the ARP section of RFC 1700 (it MUST NOT - be zero!) - - Code Len htype chaddr - +-----+-----+-----+-----+----+-----+-----+--- - | 0 | 5 | 0 | n | t1 | c1 | c2 | ... - +-----+-----+-----+-----+----+-----+-----+--- - - -12.6. client-last-transaction-time - - The time at which this server last received a DHCP request from a - particular client expressed as an absolute time (see section 6.2). - - - Code Len client last transaction time - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 6 | 0 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 115] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.7. client-reply-options - - This option contains options from a DHCP server's reply to a DHCP - client request. It is sent in a BNDUPD message. The first 4 bytes - of the option contain the "magic number" of the option area from - which the DHCP reply options were taken and serves to define the - format of the rest of the sub-options contained in this option. - After the magic number, the options included are in the normal - options format appropriate for that magic number. - - A server SHOULD NOT include all of the options in a DHCP server's - reply to a client's request in this option, but rather a server - SHOULD include only those options which are of likely interest to its - partner server. See section 7.1 for details. - - Code Len Magic Number Embedded options - +-----+-----+-----+-----+----+----+----+----+----+----+-- - | 0 | 7 | 0 | n | m1 | m2 | m3 | m4 | b1 | b2 | ... - +-----+-----+-----+-----+----+----+----+----+----+----+-- - - -12.8. client-request-options - - This option contains options from a DHCP client's request. It is - sent in a BNDUPD message. The first 4 bytes of the option contain - the "magic number" of the option area from which the DHCP client's - request options were taken and serves to define the format of the - rest of the sub-options contained in this option. After the magic - number, the options included are in the normal options format - appropriate for that magic number. - - A server SHOULD NOT include all of the options in a DHCP client - request in this option, but rather a server SHOULD include only those - options which are of likely interest to its partner server. See - section 7.1 for details. - - Code Len Magic Number Embedded options - +-----+-----+-----+-----+----+----+----+----+----+----+-- - | 0 | 8 | 0 | n | m1 | m2 | m3 | m4 | b1 | b2 | ... - +-----+-----+-----+-----+----+----+----+----+----+----+-- - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 116] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.9. DDNS - - If an implementation supports Dynamic DNS updates, this option is - used to communicate the status of the DDNS update associated with a - particular lease binding. The Flags field conveys the types of DNS - RRs that are to be updated by the DHCP server, and the status of the - DDNS update. The Domain Name field conveys the DNS FQDN that the - DHCP server is using to refer to the client, in DNS encoding as - specified in [RFC 1035]. - - Code Len Flags Domain Name - +-----+-----+-----+-----+-----+------+------+-----+------ - | 0 | 9 | 0 | n | flags | d1 | d2 | ... - +-----+-----+-----+-----+-----+------+------+-----+------ - - The Flags field is a 16-bit field; several bit positions are - specified here. - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |C|A|D|P| MBZ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The bits (numbered from the least-significant bit in network - byte-order) are used as follows: - - 0 (C): name to address (such as A RR) update successfully completed - 1 (A): Server is controlling A RR on behalf of the client - 2 (D): address to name (such as PTR RR) update successfully completed (Done) - 3 (P): Server is controlling PTR RR on behalf of the client - 4-15 : Must be zero - - All of the unspecified bit positions SHOULD be set to 0 by servers - sending the Failover-DDNS option, and they MUST be ignored by servers - receiving the option. - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 117] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.10. delayed-service-parameter - - The delayed-service-parameter is an optional load balancing tuning - parameter, defined in [RFC 3074]. If it is used, it MUST be sent in - the same message as the hash-bucket-assignment option (see section - 12.11). - - Format : - - - Code Len Seconds - +-----+-----+-----+-----+----+ - | 0 | 10 | 0 | 1 | S | - +-----+-----+-----+-----+----+ - - S is a one byte value, 1..255. - - -12.11. hash-bucket-assignment - - A set of load balancing hash values for the secondary server. A one - bit in the hash buckets indicates that the secondary is to service - that set of clients. See section 5.3 for more information on how - this option is used. This option is only sent from the primary to - the secondary. - - The format and usage of the data in this option is defined in [RFC - 3074]. - - Code Len Hash Buckets - +-----+-----+-----+-----+-----+-----+-----+-----+ - | 0 | 11 | 0 | 32 | b1 | b2 | ... | b32 | - +-----+-----+-----+-----+-----+-----+-----+-----+ - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 118] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.12. IP-flags - - This option is used to convey the current flags of the assigned-IP- - address option preceding it. - - Code Len IP Flags - +-----+-----+-----+-----+-----+-----+ - | 0 | 12 | 0 | 1 | f1 | f2 | - +-----+-----+-----+-----+-----+-----+ - - The IP-flags field is a 16-bit field; two bit positions are - specified here. - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |R|B| MBZ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The bits (numbered from the least-significant bit in network - byte-order) are used as follows: - - 0 (R): RESERVED (this bit allocated and in use and named "RESERVED") - Bit 0 MUST be set to 1 whenever the IP address in the preceding - assigned-IP-address option is reserved on the server sending the - packet. - 1 (B): BOOTP - Bit 1 MUST be set to 1 whenever the IP address in the preceding - assigned-IP-address option is a an IP address which has been - allocated due to an interaction with a BOOTP client (as opposed - to a DHCP client). - 2-15 : Must be zero - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 119] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.13. lease-expiration-time - - The lease expiration time is the lease interval that a DHCP server - has ACKed to a DHCP client added to the time at which that ACK was - transmitted -- expressed as an absolute time (see section 6.2). - - - Code Len Time - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 13 | 0 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - -12.14. max-unacked-bndupd - - The maximum number of BNDUPD message that this server is prepared to - accept over the TCP connection without causing the TCP connection to - block. A 32 bit unsigned integer value, in network byte order. - - - Code Len Maximum Unacked BNDUPD - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 14 | 0 | 4 | n1 | n2 | n3 | n4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - -12.15. MCLT - - Maximum Client Lead Time, an interval, in seconds. A 32 bit unsigned - integer value, in network byte order. - - Code Len Time - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 15 | 0 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 120] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.16. message - - This option is used to supply a human readable message text. It may - be used in association with the Reject Reason Code to provide a human - readable error message for the reject. - - - Code Len Text - +-----+-----+-----+-----+------+-----+-- - | 0 | 16 | 0 | n | c1 | c2 | ... - +-----+-----+-----+-----+------+-----+-- - - -12.17. message-digest - - The message digest for this message. - - This option consists of a variable number of bytes which contain the - message digest of the message prior to the inclusion of this option. - - When this option appears in a message, it MUST appear as the first - option in the message. It MUST appear in every message if message - digests are required. The Type MUST be configurable (once additional - types are defined). When additional types are defined, they MUST be - specified as either optional (MAY be supported) or required (MUST be - supported). See the section on IANA considerations for more details. - - Code Len Type Message Digest - +-----+-----+-----+-----+-----+-----+-----+-- - | 0 | 17 | 0 | n | t | d1 | d2 | ... - +-----+-----+-----+-----+-----+-----+-----+-- - - - Type: 0 Not Allowed - 1 HMAC-MD5 - 2-255 Not Allowed - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 121] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.18. potential-expiration-time - - The potential expiration time is the time that one server tells - another server that it may wish to grant in a lease to a DHCP client. - It is an absolute time. See section 6.2. - - - Code Len Time - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 18 | 0 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - -12.19. receive-timer - - The number of seconds (an interval) within which the server must - receive a message from its partner, or it will assume that - communications with the partner is not ok. An unsigned 32 bit - integer in network byte order. - - Code Len Receive Timer - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 19 | 0 | 4 | s1 | s2 | s3 | s4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - -12.20. protocol-version - - The protocol version being used by the server. It is only sent in the - CONNECT and CONNECTACK messages. The current value for the version - is 1. - - Code Len Version - +-----+-----+-----+-----+-----+ - | 0 | 20 | 0 | 1 | 1 | - +-----+-----+-----+-----+-----+ - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 122] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.21. reject-reason - - This option is used to selectively reject binding updates. It MAY be - used in a BNDACK message or a CONNECTACK message, always associated - with an assigned-IP-address option, which contains the IP address of - the update being rejected. - - Code Len Reason Code - +-----+-----+-----+-----+-----+ - | 0 | 21 | 0 | 1 | R1 | - +-----+-----+-----+-----+-----+ - - Reason codes (section where referenced in parentheses): - - 0 Reserved - 1 Illegal IP address (not part of any address pool). (7.1.3) - 2 Fatal conflict exists: address in use by other client. (7.1.3) - 3 Missing binding information. (7.1.3) - 4 Connection rejected, time mismatch too great. (7.8.2) - 5 Connection rejected, invalid MCLT. (7.8.2) - 6 Connection rejected, unknown reason. (not specifically referenced) - 7 Connection rejected, duplicate connection. (unused) - 8 Connection rejected, invalid failover partner. (7.8.2) - 9 TLS not supported. (7.8.2) - 10 TLS supported but not configured. (7.8.2) - 11 TLS required but not supported by partner. (7.8.2) - 12 Message digest not supported. (11.1) - 13 Message digest not configured. (11.1) - 14 Protocol version mismatch. (7.8.2) - 15 Outdated binding information. (7.1.3) - 16 Less critical binding information. (7.1.3) - 17 No traffic within sufficient time. (8.6) - 18 Hash bucket assignment conflict. (7.8.2) - 19 IP not reserved on this server. (7.1.3) - 20 Message digest failed to compare. (7.8.2) - 21 Missing message digest. (7.1.3) - 22-253, reserved. - 254 Unknown: Error occurred but does not match any reason code. - 255 Reserved for code expansion. - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 123] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.22. relationship-name - - A string which is a unique identifier for the failover relationship. - - Code Len Relationship Name - +-----+-----+-----+-----+----+-----+--- - | 0 | 22 | 0 | n | c1 | c2 | ... - +-----+-----+-----+-----+----+-----+--- - - -12.23. server-flags - - This option is used to convey the current flags of the failover - endpoint in the sending server. - - Code Len Server Flags - +-----+-----+-----+-----+-------+ - | 0 | 23 | 0 | 1 | flags | - +-----+-----+-----+-----+-------+ - - The flags field is an 8-bit field; one bit position is - specified here. - - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - |S| MBZ | - +-+-+-+-+-+-+-+-+ - - The bits (numbered from the least-significant bit in network - byte-order) are used as follows: - - 0 (S): STARTUP, - Bit 0 MUST be set to 1 whenever the server is in STARTUP state, - and set to 0 otherwise. (Note that when in STARTUP state, the - state transmitted in the server-state option is usually the last - recorded state from stable storage, but see section 9.3 for - details.) - 1-7 : Must be zero - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 124] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.24. server-state - - This option is used to convey the current state of the failover - endpoint in the sending server. - - Code Len Server State - +-----+-----+-----+-----+-----+ - | 0 | 24 | 0 | 1 | 1-9 | - +-----+-----+-----+-----+-----+ - - Legal values for this option are: - - Value Server State - ----- ------------------------------------------------------------- - 0 reserved - 1 STARTUP Startup state (1) - 2 NORMAL Normal state - 3 COMMUNICATIONS-INTERRUPTED Communication interrupted (safe) - 4 PARTNER-DOWN Partner down (unsafe mode) - 5 POTENTIAL-CONFLICT Synchronizing - 6 RECOVER Recovering bindings from partner - 7 PAUSED Shutting down for a short period. - 8 SHUTDOWN Shutting down for an extended - period. - 9 RECOVER-DONE Interlock state prior to NORMAL - 10 RESOLUTION-INTERRUPTED Comm. failed during resolution - 11 CONFLICT-DONE Primary has resolved its conflicts - - (1) The STARTUP state is never sent to the partner server, it is - indicated by the STARTUP bit in the server-flags options (see section - 12.22). - - -12.25. start-time-of-state - - This option is used for different states in different messages. In a - BNDUPD message it represents the start time of the state of the lease - in the BNDUPD message. In a STATE message, it represents the start - time of the partner server's failover state. In all cases it is an - absolute time. - - - Code Len Start Time of State - +-----+-----+-----+-----+----+-----+-----+-----+ - | 0 | 25 | 0 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+----+-----+-----+-----+ - - - - -Droms, et. al. Expires September 2003 [Page 125] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.26. TLS-reply - - This option contains information relating to TLS security - negotiation. It is sent in a CONNECTACK message - - A t1 value of 0 indicates no TLS operation, a value of 1 indicates - that TLS operation is required. - - Code Len TLS - +-----+-----+-----+-----+-----+ - | 0 | 26 | 0 | 1 | t1 | - +-----+-----+-----+-----+-----+ - - -12.27. TLS-request - - This option contains information relating to TLS security - negotiation. It is sent in a CONNECT message. - - The t1 byte is the TLS request from the primary server. A value of 0 - indicates no TLS operation (to communicate the secondary server MUST - NOT require TLS), a value of 1 indicates that TLS operation is - desired but not required (to communicate, the secondary server MAY - utilize TLS), and a value of 2 indicates that TLS operation is - required (to communicate the secondary server MUST utilize TLS) to - establish communications with the primary server. - - Code Len TLS - +-----+-----+-----+-----+-----+ - | 0 | 27 | 0 | 1 | t1 | - +-----+-----+-----+-----+-----+ - - -12.28. vendor-class-identifier - - A string which identifies the vendor of the failover protocol - implementation. - - Code Len vendor class string - +-----+-----+-----+-----+----+-----+--- - | 0 | 28 | 0 | n | c1 | c2 | ... - +-----+-----+-----+-----+----+-----+--- - - - - - - - - -Droms, et. al. Expires September 2003 [Page 126] - -Internet Draft DHCP Failover Protocol March 2003 - - - -12.29. vendor-specific-options - - This option is used to convey options specific to a particular - vendor's implementation. The vendor class identifier is used to - specify which option space the embedded options are drawn from. - Every message that uses vendor specific options MUST have a vendor- - class-identifier option in it. - - It functions similarly to the vendor class identifier and vendor - specific options in the DHCP protocol. - - This option contains other options in the same two byte code, two - byte length format. If this option appears in a message without a - corresponding vendor class identifier, it MUST be ignored. - - Code Len Embedded options - +-----+-----+-----+-----+----+-----+--- - | 0 | 29 | 0 | n | c1 | c2 | ... - +-----+-----+-----+-----+----+-----+--- - - - - -13. IANA Considerations - - This document defines several number spaces (failover options, fail- - over message types, message digest types, and failover reject reason - codes). For all of these number spaces, certain values are defined in - this specification. New values may only be defined by IETF Con- - sensus, as described in [RFC 2434]. Basically, this means that they - are defined by RFCs approved by the IESG. - - -14. Acknowledgments - - Ralph Droms started it all, by sketching out an initial interserver - draft that embodied ideas from several past IETF meetings. In that - draft, he acknowledged contributions by Jeff Mogul, Greg Minshall, - Rob Stevens, Walt Wimer, Ted Lemon, and the DHC working group. - - Kim Kinnear and Bob Cole each extended that draft, separately and - then together, until they created an interserver draft that supported - any number of servers. The complexity of that approach was just too - great, and that draft wasn't greeted with enthusiasm by many, includ- - ing its authors. - - It did however lead to a much simpler approach embodied in the first - - - -Droms, et. al. Expires September 2003 [Page 127] - -Internet Draft DHCP Failover Protocol March 2003 - - - Failover draft by Greg Rabil, Mike Dooley, Arun Kapur and Ralph - Droms. This draft posited only two servers -- a primary and a secon- - dary. - - Kim Kinnear then wrote the Safe Failover draft to layer on top of the - Failover Draft and increase its robustness in the face of certain - rare network failures. - - At the spring 1998 IETF meeting in LA, the DHC working group said - that they wanted a merged Failover and Safe Failover draft. Steve - Gonczi and Bernie Volz stepped up and produced the raw material for - such a merged draft, along with a new message format designed around - DHCP options and other extensions and clarifications. Kim Kinnear - edited their work into draft format and made other changes in time - for the Summer Chicago IETF meeting. - - Many people have reviewed the various earlier drafts that went into - this result. At American Internet, ideas were contributed by Brad - Parker. At Cisco Systems Paul Fox and Ellen Garvey contributed to - the design of the protocol. - - During the summer and fall of 1998, two groups worked on separate - implementations of the UDP failover draft. Bernie Volz and Steve - Gonczi constituted one group, and Kim Kinnear, Mark Stapp and Paul - Fox made up the other. These two groups worked together to produce - considerable changes and simplifications of the protocol during that - period, and Steve Gonczi and Kim Kinnear edited those changes into - -03 draft in time for submission to the December 1998 Orlando IETF - meeting. - - In February of 1999 Kim Kinnear and Mark Stapp hosted a meeting of - people interested in the failover draft. During that meeting a gen- - eral agreement was reached to recast the failover protocol to use TCP - instead of UDP. In addition, the group together brainstormed a work- - able load-balancing technique. Kim Kinnear rewrote the entire draft - to include the changes made at that meeting as well as to restructure - the draft along guidelines suggested by Thomas Narten. The result - was the -04 draft, submitted prior to the Oslo IETF meeting. - - The initial idea for a hash-based load balancing approach was offered - by Ted Lemon, and the determination of an algorithm and its integra- - tion into the draft was done by Steve Gonczi. The security section - was spearheaded by Bernie Volz. Both contributed considerably to the - ideas and text in the rest of the draft with several reviews. - - In early October of 1999, three conference calls were held to discuss - the -04 draft. The -05 includes changes as a result of those calls, - perhaps the largest of which was to remove the load balancing - - - -Droms, et. al. Expires September 2003 [Page 128] - -Internet Draft DHCP Failover Protocol March 2003 - - - approach into a separate draft. Thanks to all of the many people - who participated in the conference calls. Changes were made because - of contributions by: Ted Lemon, David Erdmann, Richard Jones, Rob - Stevens, Thomas Narten, Diana Lane, and Andre Kostur. - - Another conference call was held in mid-January of 2000, and the -06 - draft was produced to tighten up the the -05 draft both technically - as well as editorially. - - The -07 draft was edited by Kim Kinnear and was based in part on - reviews by Richard Jones, Bernie Volz, and Steve Gonczi. It embodies - several technical updates as well as numerous editorial revisions - that enhanced both correctness as well as clarity. - - The -08 draft was edited by Kim Kinnear and was based on the results - of two conference calls held in October and November of 2000. It - includes the correct second port number, a new state to synchronize - conflict resolution with load balancing, a generally accepted - approach to secondary pool allocation, and many other updates based - on both operational as well as implementation experience. - - The -09 draft was edited by Kim Kinnear based on discussions held at - the Minneapolis IETF in December of 2000, as well as issues raised by - Ted Lemon based on implementation and deployment. The specific - changes were mailed to the dhcp-v4 list. - - The -10 draft differed from the -09 draft in that figure 9.8.3-1 was - correctly relabeled figure 9.10.3-1, and it was updated to include - the CONFLICT-DONE message. One of the authors affiliations was also - updated. - - This, the -11 draft differs only slightly from the -10 draft in - correcting another author affiliation. - - These most recent changes have not been widely circulated among the - other authors prior to submission to the IETF. - - Glenn Waters of Nortel Networks contributed ideas and enthusiasm to - make a Failover protocol that was both "safe" and "lazy". - - -15. References - - - [DHCID] Stapp, M., Lemon, T., Gustafsson, A., "draft-ietf-dnsext- - dhcid-rr-02.txt", March, 2001. - - [DNSRES] Stapp, M., "draft-ietf-dhc-dns-resolution-01.txt", March, - - - -Droms, et. al. Expires September 2003 [Page 129] - -Internet Draft DHCP Failover Protocol March 2003 - - - 2001. - - [FQDN] Rekhter, Y., Stapp, M., "draft-ietf-dhc-fqdn-option-01.txt", - March, 2001. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", November, 1987. - - [RFC 1534] Droms, R., "Interoperation between DHCP and BOOTP", RFC - 1534, October 1993. - - [RFC 2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed - Hashing for Message Authentication", RFC 2104, IBM T.J. Watson - Research Center, University of California at San Diego, February - 1997. - - [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119. - - [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC - 2131, March 1997. - - [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor - Extensions", Internet RFC 2132, March 1997. - - [RFC 2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April - 1997 - - [RFC 2139] Rigney, C., "Radius Accounting", RFC 2139, Livingston - Enterprises, April 1997. - - [RFC 2246] Dierks, T., "The TLS Protocol, Version 1.0", RFC 2246, - January 1999. - - [RFC 2401] Kent, S., Atkinson, R., "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC 2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - - [RFC 2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over - TLS", RFC 2487, January 1999. - - [RFC 2595] Newman, C., "Using TLS with IMAP, POP3, and ACAP", RFC - 2595, June 1999. - - - - -Droms, et. al. Expires September 2003 [Page 130] - -Internet Draft DHCP Failover Protocol March 2003 - - - [RFC 3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, - A., Privat, J. "The User Class Option for DHCP", November 2000. - - [RFC 3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", - November 2000. - - [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC - 3046, January 2001. - - [RFC 3074] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load- - balancing Algorithm", February, 2001. - -16. Author's information - - Ralph Droms - Kim Kinnear - Mark Stapp - Cisco Systems - 250 Apollo Drive - Chelmsford, MA 01824 - - Phone: (978) 497-0000 - - EMail: rdroms@cisco.com - kkinnear@cisco.com - mjs@cisco.com - - - - Bernie Volz - Ericsson - 959 Concord St. - Framingham, MA 01701 - - Phone: (508) 875-3162 - - EMail: bernie.volz@ericsson.com - - - Steve Gonczi - Relicore, Inc. - One Wall Street - Burlington, MA 01803 - - Phone: (781) 229-1122 - - Email: steve@relicore.com - - - - -Droms, et. al. Expires September 2003 [Page 131] - -Internet Draft DHCP Failover Protocol March 2003 - - - Greg Rabil - Lucent Technologies - 400 Lapp Road - Malvern, PA 19355 - - Phone: (800) 208-2747 - - EMail: grabil@lucent.com - - - - - Michael Dooley - Diamond IP Technologies - One E Uwchlan Ave, Suite 112 - Exton, PA 19341 - - EMail: mdooley@diamondip.com - - - - - Arun Kapur - K5 Networks - 2 Toll House Lane - Colts Neck, NJ 07722 - - Phone: (732) 817-9475 - -17. Full Copyright Statement - -Copyright (C) The Internet Society (2003). All Rights Reserved. - -This document and translations of it may be copied and furnished to oth- -ers, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and dis- -tributed, in whole or in part, without restriction of any kind, provided -that the above copyright notice and this paragraph are included on all -such copies and derivative works. However, this document itself may not -be modified in any way, such as by removing the copyright notice or -references to the Internet Society or other Internet organizations, -except as needed for the purpose of developing Internet standards in -which case the procedures for copyrights defined in the Internet Stan- -dards process must be followed, or as required to translate it into -languages other than English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - - - -Droms, et. al. Expires September 2003 [Page 132] - -Internet Draft DHCP Failover Protocol March 2003 - - -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK -FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT -LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT -INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- -NESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms, et. al. Expires September 2003 [Page 133] -
\ No newline at end of file diff --git a/doc/rfc1542.txt b/doc/rfc1542.txt deleted file mode 100644 index cc03e669..00000000 --- a/doc/rfc1542.txt +++ /dev/null @@ -1,1291 +0,0 @@ - - - - - - -Network Working Group W. Wimer -Request for Comments: 1542 Carnegie Mellon University -Updates: 951 October 1993 -Obsoletes: 1532 -Category: Standards Track - - - Clarifications and Extensions for the Bootstrap Protocol - -Status of this Memo - - This RFC specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" for the standardization state and status - of this protocol. Distribution of this memo is unlimited. - -Abstract - - Some aspects of the BOOTP protocol were rather loosely defined in its - original specification. In particular, only a general description - was provided for the behavior of "BOOTP relay agents" (originally - called BOOTP forwarding agents"). The client behavior description - also suffered in certain ways. This memo attempts to clarify and - strengthen the specification in these areas. Due to some errors - introduced into RFC 1532 in the editorial process, this memo is - reissued as RFC 1542. - - In addition, new issues have arisen since the original specification - was written. This memo also attempts to address some of these. - -Table of Contents - - 1. Introduction................................................. 2 - 1.1 Requirements................................................ 3 - 1.2 Terminology................................................. 3 - 1.3 Data Transmission Order..................................... 4 - 2. General Issues............................................... 5 - 2.1 General BOOTP Processing.................................... 5 - 2.2 Definition of the 'flags' Field............................. 5 - 2.3 Bit Ordering of Hardware Addresses.......................... 7 - 2.4 BOOTP Over IEEE 802.5 Token Ring Networks................... 8 - 3. BOOTP Client Behavior........................................ 9 - 3.1 Client use of the 'flags' field............................. 9 - 3.1.1 The BROADCAST flag........................................ 9 - 3.1.2 The remainder of the 'flags' field........................ 9 - 3.2 Definition of the 'secs' field.............................. 10 - 3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10 - - - -Wimer [Page 1] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - 3.4 Interpretation of the 'giaddr' field........................ 11 - 3.5 Vendor information "magic cookie"........................... 12 - 4. BOOTP Relay Agents........................................... 13 - 4.1 General BOOTP Processing for Relay Agents................... 14 - 4.1.1 BOOTREQUEST Messages...................................... 14 - 4.1.2 BOOTREPLY Messages........................................ 17 - 5. BOOTP Server Behavior........................................ 18 - 5.1 Reception of BOOTREQUEST Messages........................... 18 - 5.2 Use of the 'secs' field..................................... 19 - 5.3 Use of the 'ciaddr' field................................... 19 - 5.4 Strategy for Delivery of BOOTREPLY Messages................. 20 - Acknowledgements................................................ 21 - References...................................................... 22 - Security Considerations......................................... 23 - Author's Address................................................ 23 - -1. Introduction - - The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which - allows a booting host to configure itself dynamically and without - user supervision. BOOTP provides a means to notify a host of its - assigned IP address, the IP address of a boot server host, and the - name of a file to be loaded into memory and executed [1]. Other - configuration information such as the local subnet mask, the local - time offset, the addresses of default routers, and the addresses of - various Internet servers can also be communicated to a host using - BOOTP [2]. - - Unfortunately, the original BOOTP specification [1] left some issues - of the protocol open to question. The exact behavior of BOOTP relay - agents formerly called "BOOTP forwarding agents") was not clearly - specified. Some parts of the overall protocol specification actually - conflict, while other parts have been subject to misinterpretation, - indicating that clarification is needed. This memo addresses these - problems. - - Since the introduction of BOOTP, the IEEE 802.5 Token Ring Network - has been developed which presents a unique problem for BOOTP's - particular message-transfer paradigm. This memo also suggests a - solution for this problem. - - NOTE: Unless otherwise specified in this document or a later - document, the information and requirements specified througout this - document also apply to extensions to BOOTP such as the Dynamic Host - Configuration Protocol (DHCP) [3]. - - - - - - -Wimer [Page 2] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - -1.1 Requirements - - In this memo, the words that are used to define the significance of - particular requirements are capitalized. These words are: - - o "MUST" - - This word or the adjective "REQUIRED" means that the item - is an absolute requirement of the specification. - - o "MUST NOT" - - This phrase means that the item is an absolute prohibition - of the specification. - - o "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to - ignore this item, but the full implications should be - understood and the case carefully weighed before choosing a - different course. - - o "SHOULD NOT" - - This phrase means that there may exist valid reasons in - particular circumstances when the listed behavior is - acceptable or even useful, but the full implications should - be understood and the case carefully weighed before - implementing any behavior described with this label. - - o "MAY" - - This word or the adjective "OPTIONAL" means that this item - is truly optional. One vendor may choose to include the - item because a particular marketplace requires it or - because it enhances the product, for example; another - vendor may omit the same item. - -1.2 Terminology - - This memo uses the following terms: - - BOOTREQUEST - - A BOOTREQUEST message is a BOOTP message sent from a BOOTP - client to a BOOTP server, requesting configuration information. - - - - -Wimer [Page 3] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - BOOTREPLY - - A BOOTREPLY message is a BOOTP message sent from a BOOTP server - to a BOOTP client, providing configuration information. - - Silently discard - - This memo specifies several cases where a BOOTP entity is to - "silently discard" a received BOOTP message. This means that - the entity is to discard the message without further - processing, and that the entity will not send any ICMP error - message as a result. However, for diagnosis of problems, the - entity SHOULD provide the capability of logging the error, - including the contents of the silently-discarded message, and - SHOULD record the event in a statistics counter. - -1.3 Data Transmission Order - - The order of transmission of the header and data described in this - document is resolved to the octet level. Whenever a diagram shows a - group of octets, the order of transmission of those octets is the - normal order in which they are read in English. For example, in the - following diagram, the octets are transmitted in the order they are - numbered. - - 0 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 1 | 2 | - +-------------------------------+ - | 3 | 4 | - +-------------------------------+ - | 5 | 6 | - +-------------------------------+ - - Whenever an octet represents a numeric quantity, the leftmost bit in - the diagram is the high order or most significant bit. That is, the - bit labeled 0 is the most significant bit. For example, the - following diagram represents the value 170 (decimal). - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - |1 0 1 0 1 0 1 0| - +---------------+ - - Similarly, whenever a multi-octet field represents a numeric quantity - the leftmost bit of the whole field is the most significant bit. - When a multi-octet quantity is transmitted the most significant octet - - - -Wimer [Page 4] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - is transmitted first. - -2. General Issues - - This section covers issues of general relevance to all BOOTP entities - (clients, servers, and relay agents). - -2.1 General BOOTP Processing - - The following consistency checks SHOULD be performed on BOOTP - messages: - - o The IP Total Length and UDP Length must be large enough to - contain the minimal BOOTP header of 300 octets (in the UDP - data field) specified in [1]. - - NOTE: Future extensions to the BOOTP protocol may increase the size - of BOOTP messages. Therefore, BOOTP messages which, according to the - IP Total Length and UDP Length fields, are larger than the minimum - size specified by [1] MUST also be accepted. - - o The 'op' (opcode) field of the message must contain either the - code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2). - - BOOTP messages not meeting these consistency checks MUST be silently - discarded. - -2.2 Definition of the 'flags' Field - - The standard BOOTP message format defined in [1] includes a two-octet - field located between the 'secs' field and the 'ciaddr' field. This - field is merely designated as "unused" and its contents left - unspecified, although Section 7.1 of [1] does offer the following - suggestion: - - "Before setting up the packet for the first time, it is a good - idea to clear the entire packet buffer to all zeros; this will - place all fields in their default state." - - This memo hereby designates this two-octet field as the 'flags' - field. - - This memo hereby defines the most significant bit of the 'flags' - field as the BROADCAST (B) flag. The semantics of this flag are - discussed in Sections 3.1.1 and 4.1.2 of this memo. - - The remaining bits of the 'flags' field are reserved for future - use. They MUST be set to zero by clients and ignored by servers - - - -Wimer [Page 5] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - and relay agents. - - The 'flags' field, then, appears as follows: - - 0 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |B| MBZ | - +-+-----------------------------+ - - where: - - B BROADCAST flag (discussed in Sections 3.1.1 and 4.1.2) - - MBZ MUST BE ZERO (reserved for future use) - - The format of a BOOTP message is shown below. The numbers in - parentheses indicate the size of each field in octets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wimer [Page 6] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | op (1) | htype (1) | hlen (1) | hops (1) | - +---------------+---------------+---------------+---------------+ - | xid (4) | - +-------------------------------+-------------------------------+ - | secs (2) | flags (2) | - +-------------------------------+-------------------------------+ - | ciaddr (4) | - +---------------------------------------------------------------+ - | yiaddr (4) | - +---------------------------------------------------------------+ - | siaddr (4) | - +---------------------------------------------------------------+ - | giaddr (4) | - +---------------------------------------------------------------+ - | | - | chaddr (16) | - | | - | | - +---------------------------------------------------------------+ - | | - | sname (64) | - +---------------------------------------------------------------+ - | | - | file (128) | - +---------------------------------------------------------------+ - | | - | vend (64) | - +---------------------------------------------------------------+ - -2.3 Bit Ordering of Hardware Addresses - - The bit ordering used for link-level hardware addresses in the - 'chaddr' field SHOULD be the same as the ordering used for the ARP - protocol [4] on the client's link-level network (assuming ARP is - defined for that network). - - The 'chaddr' field MUST be preserved as it was specified by the BOOTP - client. A relay agent MUST NOT reverse the bit ordering of the - 'chaddr' field even if it happens to be relaying a BOOTREQUEST - between two networks which use different bit orderings. - - DISCUSSION: - - One of the primary reasons the 'chaddr' field exists is to - enable BOOTP servers and relay agents to communicate directly - - - -Wimer [Page 7] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - with clients without the use of broadcasts. In practice, the - contents of the 'chaddr' field is often used to create an ARP- - cache entry in exactly the same way the normal ARP protocol - would have. Clearly, interoperability can only be achieved if - a consistent interpretation of the 'chaddr' field is used. - - As a practical example, this means that the bit ordering used - for the 'chaddr' field by a BOOTP client on an IEEE 802.5 Token - Ring network is the opposite of the bit ordering used by a - BOOTP client on a DIX ethernet network. - -2.4 BOOTP Over IEEE 802.5 Token Ring Networks - - Special consideration of the client/server and client/relay agent - interactions must be given to IEEE 802.5 networks because of non- - transparent bridging. - - The client SHOULD send its broadcast BOOTREQUEST with an All Routes - Explorer RIF. This will enable servers/relay agents to cache the - return route if they choose to do so. For those server/relay agents - which cannot cache the return route (because they are stateless, for - example), the BOOTREPLY message SHOULD be sent to the client's - hardware address, as taken from the BOOTP message, with a Spanning - Tree Rooted RIF. The actual bridge route will be recorded by the - client and server/relay agent by normal ARP processing code. - - DISCUSSION: - - In the simplest case, an unbridged, single ring network, the - broadcast behavior of the BOOTP protocol is identical to that - of Ethernet networks. However, a BOOTP client cannot know, a - priori, that an 802.5 network is not bridged. In fact, the - likelihood is that the server, or relay agent, will not know - either. - - Of the four possible scenerios, only two are interesting: where - the assumption is that the 802.5 network is not bridged and it - is, and the assumption that the network is bridged and it is - not. In the former case, the Routing Information Field (RIF) - will not be used; therefore, if the server/relay agent are on - another segment of the ring, the client cannot reach it. In - the latter case, the RIF field will be used, resulting in a few - extraneous bytes on the ring. It is obvious that an almost - immeasurable inefficiency is to be preferred over a complete - failure to communicate. - - - - - - -Wimer [Page 8] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - Given that the assumption is that RIF fields will be needed, it - is necesary to determine the optimum method for the client to - reach the server/relay agent, and the optimum method for the - response to be returned. - -3. BOOTP Client Behavior - - This section clarifies various issues regarding BOOTP client - behavior. - -3.1 Client use of the 'flags' field - -3.1.1 The BROADCAST flag - - Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY - messages directly to a client using unicast delivery. The IP - destination address (in the IP header) is set to the BOOTP 'yiaddr' - address and the link-layer destination address is set to the BOOTP - 'chaddr' address. Unfortunately, some client implementations are - unable to receive such unicast IP datagrams until they know their own - IP address (thus we have a "chicken and egg" issue). Often, however, - they can receive broadcast IP datagrams (those with a valid IP - broadcast address as the IP destination and the link-layer broadcast - address as the link-layer destination). - - If a client falls into this category, it SHOULD set (to 1) the - newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY - messages it generates. This will provide a hint to BOOTP servers and - relay agents that they should attempt to broadcast their BOOTREPLY - messages to the client. - - If a client does not have this limitation (i.e., it is perfectly able - to receive unicast BOOTREPLY messages), it SHOULD NOT set the - BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0). - - DISCUSSION: - - This addition to the protocol is a workaround for old host - implementations. Such implementations SHOULD be modified so - that they may receive unicast BOOTREPLY messages, thus making - use of this workaround unnecessary. In general, the use of - this mechanism is discouraged. - -3.1.2 The remainder of the 'flags' field - - The remaining bits of the 'flags' field are reserved for future use. - A client MUST set these bits to zero in all BOOTREQUEST messages it - generates. A client MUST ignore these bits in all BOOTREPLY messages - - - -Wimer [Page 9] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - it receives. - -3.2 Definition of the 'secs' field - - The 'secs' field of a BOOTREQUEST message SHOULD represent the - elapsed time, in seconds, since the client sent its first BOOTREQUEST - message. Note that this implies that the 'secs' field of the first - BOOTREQUEST message SHOULD be set to zero. - - Clients SHOULD NOT set the 'secs' field to a value which is constant - for all BOOTREQUEST messages. - - DISCUSSION: - - The original definition of the 'secs' field was vague. It was - not clear whether it represented the time since the first - BOOTREQUEST message was sent or some other time period such as - the time since the client machine was powered-up. This has - limited its usefulness as a policy control mechanism for BOOTP - servers and relay agents. Furthermore, certain client - implementations have been known to simply set this field to a - constant value or use incorrect byte-ordering. Incorrect - byte-ordering usually makes it appear as if a client has been - waiting much longer than it really has, so a relay agent will - relay the BOOTREQUEST sooner than desired (usually - immediately). These implementation errors have further - undermined the usefulness of the 'secs' field. These incorrect - implementations SHOULD be corrected. - -3.3 Use of the 'ciaddr' and 'yiaddr' fields - - If a BOOTP client does not know what IP address it should be using, - the client SHOULD set the 'ciaddr' field to 0.0.0.0. If the client - has the ability to remember the last IP address it was assigned, or - it has been preconfigured with an IP address via some alternate - mechanism, the client MAY fill the 'ciaddr' field with that IP - address. If the client does place a non-zero IP address in the - 'ciaddr' field, the client MUST be prepared to accept incoming - unicast datagrams addressed to that IP address and also answer ARP - requests for that IP address (if ARP is used on that network). - - The BOOTP server is free to assign a different IP address (in the - 'yiaddr' field) than the client expressed in 'ciaddr'. The client - SHOULD adopt the IP address specified in 'yiaddr' and begin using it - as soon as possible. - - - - - - -Wimer [Page 10] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - DISCUSSION: - - There are various interpretations about the purpose of the - 'ciaddr' field and, unfortunately, no agreement on a single - correct interpretation. One interpretation is that if a client - is willing to accept whatever IP address the BOOTP server - assigns to it, the client should always place 0.0.0.0 in the - 'ciaddr' field, regardless of whether it knows its previously- - assigned address. Conversely, if the client wishes to assert - that it must have a particular IP address (e.g., the IP address - was hand-configured by the host administrator and BOOTP is only - being used to obtain a boot file and/or information from the - 'vend' field), the client will then fill the 'ciaddr' field - with the desired IP address and ignore the IP address assigned - by the BOOTP server as indicated in the 'yiaddr' field. An - alternate interpretation holds that the client always fills the - 'ciaddr' field with its most recently-assigned IP address (if - known) even if that address may be incorrect. Such a client - will still accept and use the address assigned by the BOOTP - server as indicated in the 'yiaddr' field. The motivation for - this interpretation is to aid the server in identifying the - client and/or in delivering the BOOTREPLY to the client. Yet a - third (mis)interpretation allows the client to use 'ciaddr' to - express the client's desired IP address, even if the client has - never used that address before or is not currently using that - address. - - The last interpretation is incorrect as it may prevent the - BOOTREPLY from reaching the client. The server will usually - unicast the reply to the address given in 'ciaddr' but the - client may not be listening on that address yet, or the client - may be connected to an incorrect subnet such that normal IP - routing (correctly) routes the reply to a different subnet. - - The second interpretation also suffers from the "incorrect - subnet" problem. - - The first interpretation seems to be the safest and most likely - to promote interoperability. - -3.4 Interpretation of the 'giaddr' field - - The 'giaddr' field is rather poorly named. It exists to facilitate - the transfer of BOOTREQUEST messages from a client, through BOOTP - relay agents, to servers on different networks than the client. - Similarly, it facilitates the delivery of BOOTREPLY messages from the - servers, through BOOTP relay agents, back to the client. In no case - does it represent a general IP router to be used by the client. A - - - -Wimer [Page 11] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all - BOOTREQUEST messages it generates. - - A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY - message to be the IP address of an IP router. A BOOTP client SHOULD - completely ignore the contents of the 'giaddr' field in BOOTREPLY - messages. - - DISCUSSION: - - The semantics of the 'giaddr' field were poorly defined. - Section 7.5 of [1] states: - - "If 'giaddr' (gateway address) is nonzero, then the packets - should be forwarded there first, in order to get to the - server." - - In that sentence, "get to" refers to communication from the client to - the server subsequent to the BOOTP exchange, such as a TFTP session. - Unfortunately, the 'giaddr' field may contain the address of a BOOTP - relay agent that is not itself an IP router (according to [1], - Section 8, fifth paragraph), in which case, it will be useless as a - first-hop for TFTP packets sent to the server (since, by definition, - non-routers don't forward datagrams at the IP layer). - - Although now prohibited by Section 4.1.1 of this memo, the 'giaddr' - field might contain a broadcast address according to Section 8, sixth - paragraph of [1]. Not only would such an address be useless as a - router address, it might also cause the client to ARP for the - broadcast address (since, if the client didn't receive a subnet mask - in the BOOTREPLY message, it would be unable to recognize a subnet - broadcast address). This is clearly undesirable. - - To reach a non-local server, clients can obtain a first-hop router - address from the "Gateway" subfield of the "Vendor Information - Extensions" [2] (if present), or via the ICMP router discovery - protocol [5] or other similar mechanism. - -3.5 Vendor information "magic cookie" - - It is RECOMMENDED that a BOOTP client always fill the first four - octets of the 'vend' (vendor information) field of a BOOTREQUEST with - a four-octet identifier called a "magic cookie." A BOOTP client - SHOULD do this even if it has no special information to communicate - to the BOOTP server using the 'vend' field. This aids the BOOTP - server in determining what vendor information format it should use in - its BOOTREPLY messages. - - - - -Wimer [Page 12] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - If a special vendor-specific magic cookie is not being used, a BOOTP - client SHOULD use the dotted decimal value 99.130.83.99 as specified - in [2]. In this case, if the client has no information to - communicate to the server, the octet immediately following the magic - cookie SHOULD be set to the "End" tag (255) and the remaining octets - of the 'vend' field SHOULD be set to zero. - - DISCUSSION: - - Sometimes different operating systems or networking packages - are run on the same machine at different times (or even at the - same time!). Since the hardware address placed in the 'chaddr' - field will likely be the same, BOOTREQUESTs from completely - different BOOTP clients on the same machine will likely be - difficult for a BOOTP server to differentiate. If the client - includes a magic cookie in its BOOTREQUESTs, the server will at - least know what format the client expects and can understand in - corresponding BOOTREPLY messages. - -4. BOOTP Relay Agents - - In many cases, BOOTP clients and their associated BOOTP - server(s) do not reside on the same IP network or subnet. In - such cases, some kind of third-party agent is required to - transfer BOOTP messages between clients and servers. Such an - agent was originally referred to as a "BOOTP forwarding agent." - However, in order to avoid confusion with the IP forwarding - function of an IP router, the name "BOOTP relay agent" is - hereby adopted instead. - - DISCUSSION: - - A BOOTP relay agent performs a task which is distinct from an - IP router's normal IP forwarding function. While a router - normally switches IP datagrams between networks more-or-less - transparently, a BOOTP relay agent may more properly be thought - to receive BOOTP messages as a final destination and then - generate new BOOTP messages as a result. It is incorrect for a - relay agent implementation to simply forward a BOOTP message - "straight through like a regular packet." - - This relay-agent functionality is most conveniently located in - the routers which interconnect the clients and servers, but may - alternatively be located in a host which is directly connected - to the client subnet. - - Any Internet host or router which provides BOOTP relay-agent - capability MUST conform to the specifications in this memo. - - - -Wimer [Page 13] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - -4.1 General BOOTP Processing for Relay Agents - - All locally delivered UDP messages whose UDP destination port number - is BOOTPS (67) are considered for special processing by the host or - router's logical BOOTP relay agent. - - In the case of a host, locally delivered datagrams are simply all - datagrams normally received by that host, i.e., broadcast and - multicast datagrams as well as unicast datagrams addressed to IP - addresses of that host. - - In the case of a router, locally delivered datagrams are broadcast - and multicast datagrams as well as unicast datagrams addressed to IP - addresses of that router. These are datagrams for which the router - should be considered an end destination as opposed to an intermediate - switching node. Thus a unicast datagram with an IP destination not - matching any of the router's IP addresses is not considered for - processing by the router's logical BOOTP relay agent. - - Hosts and routers are usually required to silently discard incoming - datagrams containing illegal IP source addresses. This is generally - known as "Martian address filtering." One of these illegal addresses - is 0.0.0.0 (or actually anything on network 0). However, hosts or - routers which support a BOOTP relay agent MUST accept for local - delivery to the relay agent BOOTREQUEST messages whose IP source - address is 0.0.0.0. BOOTREQUEST messages from legal IP source - addresses MUST also be accepted. - - A relay agent MUST silently discard any received UDP messages whose - UDP destination port number is BOOTPC (68). - - DISCUSSION: - - There should be no need for a relay agent to process messages - addressed to the BOOTPC port. Careful reading of the original - BOOTP specification [1] will show this. Nevertheless, some - relay agent implementations incorrectly relay such messages. - - The consistency checks specified in Section 2.1 SHOULD be performed - by the relay agent. BOOTP messages not meeting these consistency - checks MUST be silently discarded. - -4.1.1 BOOTREQUEST Messages - - Some configuration mechanism MUST exist to enable or disable the - relaying of BOOTREQUEST messages. Relaying MUST be disabled by - default. - - - - -Wimer [Page 14] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - When the BOOTP relay agent receives a BOOTREQUEST message, it MAY use - the value of the 'secs' (seconds since client began booting) field of - the request as a factor in deciding whether to relay the request. If - such a policy mechanism is implemented, its threshold SHOULD be - configurable. - - DISCUSSION: - - To date, this feature of the BOOTP protocol has not necessarily - been shown to be useful. See Section 3.2 for a discussion. - - The relay agent MUST silently discard BOOTREQUEST messages whose - 'hops' field exceeds the value 16. A configuration option SHOULD be - provided to set this threshold to a smaller value if desired by the - network manager. The default setting for a configurable threshold - SHOULD be 4. - - If the relay agent does decide to relay the request, it MUST examine - the 'giaddr' ("gateway" IP address) field. If this field is zero, - the relay agent MUST fill this field with the IP address of the - interface on which the request was received. If the interface has - more than one IP address logically associated with it, the relay - agent SHOULD choose one IP address associated with that interface and - use it consistently for all BOOTP messages it relays. If the - 'giaddr' field contains some non-zero value, the 'giaddr' field MUST - NOT be modified. The relay agent MUST NOT, under any circumstances, - fill the 'giaddr' field with a broadcast address as is suggested in - [1] (Section 8, sixth paragraph). - - The value of the 'hops' field MUST be incremented. - - All other BOOTP fields MUST be preserved intact. - - At this point, the request is relayed to its new destination (or - destinations). This destination MUST be configurable. Further, this - destination configuration SHOULD be independent of the destination - configuration for any other so-called "broadcast forwarders" (e.g., - for the UDP-based TFTP, DNS, Time, etc. protocols). - - DISCUSSION: - - The network manager may wish the relaying destination to be an - IP unicast, multicast, broadcast, or some combination. A - configurable list of destination IP addresses provides good - flexibility. More flexible configuration schemes are - encouraged. For example, it may be desirable to send to the - limited broadcast address (255.255.255.255) on specific - physical interfaces. However, if the BOOTREQUEST message was - - - -Wimer [Page 15] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - received as a broadcast, the relay agent MUST NOT rebroadcast - the BOOTREQUEST on the physical interface from whence it came. - - A relay agent MUST use the same destination (or set of - destinations) for all BOOTREQUEST messages it relays from a - given client. - - DISCUSSION: - - At least one known relay agent implementation uses a round- - robin scheme to provide load balancing across multiple BOOTP - servers. Each time it receives a new BOOTREQUEST message, it - relays the message to the next BOOTP server in a list of - servers. Thus, with this relay agent, multiple consecutive - BOOTREQUEST messages from a given client will be delivered to - different servers. - - Unfortunately, this well-intentioned scheme reacts badly with - DHCP [3] and perhaps other variations of the BOOTP protocol - which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY - messages between clients and servers. Therefore, all - BOOTREQUEST messages from a given client MUST be relayed to the - same destination (or set of destinations). - - One way to meet this requirement while providing some load- - balancing benefit is to hash the client's link-layer address - (or some other reliable client-identifying information) and use - the resulting hash value to select the appropriate relay - destination (or set of destinations). The simplest solution, - of course, is to not use a load-balancing scheme and just relay - ALL received BOOTREQUEST messages to the same destination (or - set of destinations). - - When transmitting the request to its next destination, the - relay agent may set the IP Time-To-Live field to either the - default value for new datagrams originated by the relay agent, - or to the TTL of the original BOOTREQUEST decremented by (at - least) one. - - DISCUSSION: - - As an extra precaution against BOOTREQUEST loops, it is - preferable to use the decremented TTL from the original - BOOTREQUEST. Unfortunately, this may be difficult to do in - some implementations. - - If the BOOTREQUEST has a UDP checksum (i.e., the UDP checksum - is non-zero), the checksum must be recalculated before - - - -Wimer [Page 16] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - transmitting the request. - -4.1.2 BOOTREPLY Messages - - BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients. - It is the responsibility of BOOTP servers to send BOOTREPLY messages - directly to the relay agent identified in the 'giaddr' field. - Therefore, a relay agent may assume that all BOOTREPLY messages it - receives are intended for BOOTP clients on its directly-connected - networks. - - When a relay agent receives a BOOTREPLY message, it should examine - the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 'hlen' fields. - These fields should provide adequate information for the relay agent - to deliver the BOOTREPLY message to the client. - - The 'giaddr' field can be used to identify the logical interface from - which the reply must be sent (i.e., the host or router interface - connected to the same network as the BOOTP client). If the content - of the 'giaddr' field does not match one of the relay agent's - directly-connected logical interfaces, the BOOTREPLY messsage MUST be - silently discarded. - - The 'htype', 'hlen', and 'chaddr' fields supply the link-layer - hardware type, hardware address length, and hardware address of the - client as defined in the ARP protocol [4] and the Assigned Numbers - document [6]. The 'yiaddr' field is the IP address of the client, as - assigned by the BOOTP server. - - The relay agent SHOULD examine the newly-defined BROADCAST flag (see - Sections 2.2 and 3.1.1 for more information). If this flag is set to - 1, the reply SHOULD be sent as an IP broadcast using the IP limited - broadcast address 255.255.255.255 as the IP destination address and - the link-layer broadcast address as the link-layer destination - address. If the BROADCAST flag is cleared (0), the reply SHOULD be - sent as an IP unicast to the IP address specified by the 'yiaddr' - field and the link-layer address specified in the 'chaddr' field. If - unicasting is not possible, the reply MAY be sent as a broadcast, in - which case it SHOULD be sent to the link-layer broadcast address - using the IP limited broadcast address 255.255.255.255 as the IP - destination address. - - DISCUSSION: - - The addition of the BROADCAST flag to the protocol is a - workaround to help promote interoperability with certain client - implementations. - - - - -Wimer [Page 17] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - Note that since the 'flags' field was previously defined in [1] - simply as an "unused" field, it is possible that old client or - server implementations may accidentally and unknowingly set the - new BROADCAST flag. It is actually expected that such - implementations will be rare (most implementations seem to - zero-out this field), but interactions with such - implementations must nevertheless be considered. If an old - client or server does set the BROADCAST flag to 1 incorrectly, - conforming relay agents will generate broadcast BOOTREPLY - messages to the corresponding client. The BOOTREPLY messages - should still properly reach the client, at the cost of one - (otherwise unnecessary) additional broadcast. This, however, - is no worse than a server or relay agent which always - broadcasts its BOOTREPLY messages. - - Older client or server implementations which accidentally set - the BROADCAST flag SHOULD be corrected to properly comply with - this newer specification. - - All BOOTP fields MUST be preserved intact. The relay agent - MUST NOT modify any BOOTP field of the BOOTREPLY message when - relaying it to the client. - - The reply MUST have its UDP destination port set to BOOTPC - (68). - - If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is - non-zero), the checksum must be recalculated before - transmitting the reply. - -5. BOOTP Server Behavior - - This section provides clarifications on the behavior of BOOTP - servers. - -5.1 Reception of BOOTREQUEST Messages - - All received UDP messages whose UDP destination port number is BOOTPS - (67) are considered for processing by the BOOTP server. - - Hosts and routers are usually required to silently discard incoming - datagrams containing illegal IP source addresses. This is generally - known as "Martian address filtering." One of these illegal addresses - is 0.0.0.0 (or actually anything on network 0). However, hosts or - routers which support a BOOTP server MUST accept for local delivery - to the server BOOTREQUEST messages whose IP source address is - 0.0.0.0. BOOTREQUEST messages from legal IP source addresses MUST - also be accepted. - - - -Wimer [Page 18] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - A BOOTP server MUST silently discard any received UDP messages whose - UDP destination port number is BOOTPC (68). - - DISCUSSION: - - There should be no need for a BOOTP server to process messages - addressed to the BOOTPC port. Careful reading of the original - BOOTP specification [1] will show this. - - The consistency checks specified in Section 2.1 SHOULD be - performed by the BOOTP server. BOOTP messages not meeting - these consistency checks MUST be silently discarded. - -5.2 Use of the 'secs' field - - When the BOOTP server receives a BOOTREQUEST message, it MAY use the - value of the 'secs' (seconds since client began booting) field of the - request as a factor in deciding whether and/or how to reply to the - request. - - DISCUSSION: - - To date, this feature of the BOOTP protocol has not necessarily - been shown to be useful. See Section 3.2 for a discussion. - -5.3 Use of the 'ciaddr' field - - There have been various client interpretations of the 'ciaddr' field - for which Section 3.3 should be consulted. A BOOTP server SHOULD be - prepared to deal with these varying interpretations. In general, the - 'ciaddr' field SHOULD NOT be trusted as a sole key in identifying a - client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen' - fields, and probably other information (perhaps in the 'file' and - 'vend' fields) SHOULD all be considered together in deciding how to - respond to a given client. - - BOOTP servers SHOULD preserve the contents of the 'ciaddr' field in - BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY message - SHOULD exactly match the contents of 'ciaddr' in the corresponding - BOOTREQUEST message. - - DISCUSSION: - - It has been suggested that a client may wish to use the - contents of 'ciaddr' to further verify that a particular - BOOTREPLY message was indeed intended for it. - - - - - -Wimer [Page 19] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - -5.4 Strategy for Delivery of BOOTREPLY Messages - - Once the BOOTP server has created an appropriate BOOTREPLY message, - that BOOTREPLY message must be properly delivered to the client. - - The server SHOULD first check the 'ciaddr' field. If the 'ciaddr' - field is non-zero, the BOOTREPLY message SHOULD be sent as an IP - unicast to the IP address identified in the 'ciaddr' field. The UDP - destination port MUST be set to BOOTPC (68). However, the server - MUST be aware of the problems identified in Section 3.3. The server - MAY choose to ignore the 'ciaddr' field and act as if the 'ciaddr' - field contains 0.0.0.0 (and thus continue with the rest of the - delivery algorithm below). - - The server SHOULD next check the 'giaddr' field. If this field is - non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to - the IP address identified in the 'giaddr' field. The UDP destination - port MUST be set to BOOTPS (67). This action will deliver the - BOOTREPLY message directly to the BOOTP relay agent closest to the - client; the relay agent will then perform the final delivery to the - client. If the BOOTP server has prior knowledge that a particular - client cannot receive unicast BOOTREPLY messages (e.g., the network - manager has explicitly configured the server with such knowledge), - the server MAY set the newly-defined BROADCAST flag to indicate that - relay agents SHOULD broadcast the BOOTREPLY message to the client. - Otherwise, the server MUST preserve the state of the BROADCAST flag - so that the relay agent can correctly act upon it. - - If the 'giaddr' field is set to 0.0.0.0, then the client resides on - one of the same networks as the BOOTP server. The server SHOULD - examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1 and - 4.1.2 for more information). If this flag is set to 1 or the server - has prior knowledge that the client is unable to receive unicast - BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast using - the IP limited broadcast address 255.255.255.255 as the IP - destination address and the link-layer broadcast address as the - link-layer destination address. If the BROADCAST flag is cleared - (0), the reply SHOULD be sent as an IP unicast to the IP address - specified by the 'yiaddr' field and the link-layer address specified - in the 'chaddr' field. If unicasting is not possible, the reply MAY - be sent as a broadcast in which case it SHOULD be sent to the link- - layer broadcast address using the IP limited broadcast address - 255.255.255.255 as the IP destination address. In any case, the UDP - destination port MUST be set to BOOTPC (68). - - - - - - - -Wimer [Page 20] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - - DISCUSSION: - - The addition of the BROADCAST flag to the protocol is a - workaround to help promote interoperability with certain client - implementations. - - The following table summarizes server delivery decisions for - BOOTREPLY messages based upon information in BOOTREQUEST - messages: - - BOOTREQUEST fields BOOTREPLY values for UDP, IP, link-layer - +-----------------------+-----------------------------------------+ - | 'ciaddr' 'giaddr' B | UDP dest IP destination link dest | - +-----------------------+-----------------------------------------+ - | non-zero X X | BOOTPC (68) 'ciaddr' normal | - | 0.0.0.0 non-zero X | BOOTPS (67) 'giaddr' normal | - | 0.0.0.0 0.0.0.0 0 | BOOTPC (68) 'yiaddr' 'chaddr' | - | 0.0.0.0 0.0.0.0 1 | BOOTPC (68) 255.255.255.255 broadcast | - +-----------------------+-----------------------------------------+ - - B = BROADCAST flag - - X = Don't care - - normal = determine from the given IP destination using normal - IP routing mechanisms and/or ARP as for any other - normal datagram - -Acknowledgements - - The author would like to thank Gary Malkin for his contribution of - the "BOOTP over IEEE 802.5 Token Ring Networks" section, and Steve - Deering for his observations on the problems associated with the - 'giaddr' field. - - Ralph Droms and the many members of the IETF Dynamic Host - Configuration and Router Requirements working groups provided ideas - for this memo as well as encouragement to write it. - - Philip Almquist and David Piscitello offered many helpful suggestions - for improving the clarity, accuracy, and organization of this memo. - These contributions are graciously acknowledged. - - - - - - - - - -Wimer [Page 21] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - -References - - [1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, - Stanford University and Sun Microsystems, September 1985. - - [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, - USC/Information Sciences Institute, August 1993. This RFC is - occasionally reissued with a new number. Please be sure to - consult the latest version. - - [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, - Bucknell University, October 1993. - - [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, - RFC 826, MIT, November 1982. - - [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox - PARC, September 1991. - - [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, - USC/Information Sciences Institute, July, 1992. This RFC is - periodically reissued with a new number. Please be sure to - consult the latest version. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wimer [Page 22] - -RFC 1542 Clarifications and Extensions for BOOTP October 1993 - - -Security Considerations - - There are many factors which make BOOTP in its current form quite - insecure. BOOTP is built directly upon UDP and IP which are as yet - inherently insecure themselves. Furthermore, BOOTP is generally - intended to make maintenance of remote and/or diskless hosts easier. - While perhaps not impossible, configuring such hosts with passwords or - keys may be difficult and inconvenient. This makes it difficult to - provide any form of reasonable authentication between servers and - clients. - - Unauthorized BOOTP servers may easily be set up. Such servers can - then send false and potentially disruptive information to clients such - as incorrect or duplicate IP addresses, incorrect routing information - (including spoof routers, etc.), incorrect domain nameserver addresses - (such as spoof nameservers), and so on. Clearly, once this "seed" - mis-information is planted, an attacker can further compromise the - affected systems. - - Unauthorized BOOTP relay agents may present some of the same problems - as unauthorized BOOTP servers. - - Malicious BOOTP clients could masquerade as legitimate clients and - retrieve information intended for those legitimate clients. Where - dynamic allocation of resources is used, a malicious client could - claim all resources for itself, thereby denying resources to - legitimate clients. - -Author's Address - - Walt Wimer - Network Development - Carnegie Mellon University - 5000 Forbes Avenue - Pittsburgh, PA 15213-3890 - - Phone: (412) 268-6252 - EMail: Walter.Wimer@CMU.EDU - - - - - - - - - - - - - -Wimer [Page 23] -
\ No newline at end of file diff --git a/doc/rfc2131.txt b/doc/rfc2131.txt deleted file mode 100644 index f45d9b86..00000000 --- a/doc/rfc2131.txt +++ /dev/null @@ -1,2523 +0,0 @@ - - - - - - -Network Working Group R. Droms -Request for Comments: 2131 Bucknell University -Obsoletes: 1541 March 1997 -Category: Standards Track - - Dynamic Host Configuration Protocol - -Status of this memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) provides a framework - for passing configuration information to hosts on a TCPIP network. - DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the - capability of automatic allocation of reusable network addresses and - additional configuration options [19]. DHCP captures the behavior of - BOOTP relay agents [7, 21], and DHCP participants can interoperate - with BOOTP participants [9]. - -Table of Contents - - 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4 - 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1 Configuration parameters repository . . . . . . . . . . . . . 11 - 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12 - 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 - 3.1 Client-server interaction - allocating a network address. . . 13 - 3.2 Client-server interaction - reusing a previously allocated - network address . . . . . . . . . . . . . . . . . . . . . . . 17 - 3.3 Interpretation and representation of time values. . . . . . . 20 - 3.4 Obtaining parameters with externally configured network - address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21 - 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22 - 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22 - 4. Specification of the DHCP client-server protocol. . . . . . . 22 - - - -Droms Standards Track [Page 1] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22 - 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 - 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26 - 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34 - 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42 - 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43 - 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44 - A. Host Configuration Parameters . . . . . . . . . . . . . . . .45 -List of Figures - 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9 - 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11 - 3. Timeline diagram of messages exchanged between DHCP client and - servers when allocating a new network address. . . . . . . . . 15 - 4. Timeline diagram of messages exchanged between DHCP client and - servers when reusing a previously allocated network address. . 18 - 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34 -List of Tables - 1. Description of fields in a DHCP message. . . . . . . . . . . . 10 - 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28 - 4. Client messages from various states. . . . . . . . . . . . . . 33 - 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37 - -1. Introduction - - The Dynamic Host Configuration Protocol (DHCP) provides configuration - parameters to Internet hosts. DHCP consists of two components: a - protocol for delivering host-specific configuration parameters from a - DHCP server to a host and a mechanism for allocation of network - addresses to hosts. - - DHCP is built on a client-server model, where designated DHCP server - hosts allocate network addresses and deliver configuration parameters - to dynamically configured hosts. Throughout the remainder of this - document, the term "server" refers to a host providing initialization - parameters through DHCP, and the term "client" refers to a host - requesting initialization parameters from a DHCP server. - - A host should not act as a DHCP server unless explicitly configured - to do so by a system administrator. The diversity of hardware and - protocol implementations in the Internet would preclude reliable - operation if random hosts were allowed to respond to DHCP requests. - For example, IP requires the setting of many parameters within the - protocol implementation software. Because IP can be used on many - dissimilar kinds of network hardware, values for those parameters - cannot be guessed or assumed to have correct defaults. Also, - distributed address allocation schemes depend on a polling/defense - - - -Droms Standards Track [Page 2] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - mechanism for discovery of addresses that are already in use. IP - hosts may not always be able to defend their network addresses, so - that such a distributed address allocation scheme cannot be - guaranteed to avoid allocation of duplicate network addresses. - - DHCP supports three mechanisms for IP address allocation. In - "automatic allocation", DHCP assigns a permanent IP address to a - client. In "dynamic allocation", DHCP assigns an IP address to a - client for a limited period of time (or until the client explicitly - relinquishes the address). In "manual allocation", a client's IP - address is assigned by the network administrator, and DHCP is used - simply to convey the assigned address to the client. A particular - network will use one or more of these mechanisms, depending on the - policies of the network administrator. - - Dynamic allocation is the only one of the three mechanisms that - allows automatic reuse of an address that is no longer needed by the - client to which it was assigned. Thus, dynamic allocation is - particularly useful for assigning an address to a client that will be - connected to the network only temporarily or for sharing a limited - pool of IP addresses among a group of clients that do not need - permanent IP addresses. Dynamic allocation may also be a good choice - for assigning an IP address to a new client being permanently - connected to a network where IP addresses are sufficiently scarce - that it is important to reclaim them when old clients are retired. - Manual allocation allows DHCP to be used to eliminate the error-prone - process of manually configuring hosts with IP addresses in - environments where (for whatever reasons) it is desirable to manage - IP address assignment outside of the DHCP mechanisms. - - The format of DHCP messages is based on the format of BOOTP messages, - to capture the BOOTP relay agent behavior described as part of the - BOOTP specification [7, 21] and to allow interoperability of existing - BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates - the necessity of having a DHCP server on each physical network - segment. - -1.1 Changes to RFC 1541 - - This document updates the DHCP protocol specification that appears in - RFC1541. A new DHCP message type, DHCPINFORM, has been added; see - section 3.4, 4.3 and 4.4 for details. The classing mechanism for - identifying DHCP clients to DHCP servers has been extended to include - "vendor" classes as defined in sections 4.2 and 4.3. The minimum - lease time restriction has been removed. Finally, many editorial - changes have been made to clarify the text as a result of experience - gained in DHCP interoperability tests. - - - - -Droms Standards Track [Page 3] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -1.2 Related Work - - There are several Internet protocols and related mechanisms that - address some parts of the dynamic host configuration problem. The - Reverse Address Resolution Protocol (RARP) [10] (through the - extensions defined in the Dynamic RARP (DRARP) [5]) explicitly - addresses the problem of network address discovery, and includes an - automatic IP address assignment mechanism. The Trivial File Transfer - Protocol (TFTP) [20] provides for transport of a boot image from a - boot server. The Internet Control Message Protocol (ICMP) [16] - provides for informing hosts of additional routers via "ICMP - redirect" messages. ICMP also can provide subnet mask information - through the "ICMP mask request" message and other information through - the (obsolete) "ICMP information request" message. Hosts can locate - routers through the ICMP router discovery mechanism [8]. - - BOOTP is a transport mechanism for a collection of configuration - information. BOOTP is also extensible, and official extensions [17] - have been defined for several configuration parameters. Morgan has - proposed extensions to BOOTP for dynamic IP address assignment [15]. - The Network Information Protocol (NIP), used by the Athena project at - MIT, is a distributed mechanism for dynamic IP address assignment - [19]. The Resource Location Protocol RLP [1] provides for location - of higher level services. Sun Microsystems diskless workstations use - a boot procedure that employs RARP, TFTP and an RPC mechanism called - "bootparams" to deliver configuration information and operating - system code to diskless hosts. (Sun Microsystems, Sun Workstation - and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun - networks also use DRARP and an auto-installation mechanism to - automate the configuration of new hosts in an existing network. - - In other related work, the path minimum transmission unit (MTU) - discovery algorithm can determine the MTU of an arbitrary internet - path [14]. The Address Resolution Protocol (ARP) has been proposed - as a transport protocol for resource location and selection [6]. - Finally, the Host Requirements RFCs [3, 4] mention specific - requirements for host reconfiguration and suggest a scenario for - initial configuration of diskless hosts. - -1.3 Problem definition and issues - - DHCP is designed to supply DHCP clients with the configuration - parameters defined in the Host Requirements RFCs. After obtaining - parameters via DHCP, a DHCP client should be able to exchange packets - with any other host in the Internet. The TCP/IP stack parameters - supplied by DHCP are listed in Appendix A. - - - - - -Droms Standards Track [Page 4] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - Not all of these parameters are required for a newly initialized - client. A client and server may negotiate for the transmission of - only those parameters required by the client or specific to a - particular subnet. - - DHCP allows but does not require the configuration of client - parameters not directly related to the IP protocol. DHCP also does - not address registration of newly configured clients with the Domain - Name System (DNS) [12, 13]. - - DHCP is not intended for use in configuring routers. - -1.4 Requirements - - Throughout this document, the words that are used to define the - significance of particular requirements are capitalized. These words - are: - - o "MUST" - - This word or the adjective "REQUIRED" means that the - item is an absolute requirement of this specification. - - o "MUST NOT" - - This phrase means that the item is an absolute prohibition - of this specification. - - o "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to ignore - this item, but the full implications should be understood and - the case carefully weighed before choosing a different course. - - o "SHOULD NOT" - - This phrase means that there may exist valid reasons in - particular circumstances when the listed behavior is acceptable - or even useful, but the full implications should be understood - and the case carefully weighed before implementing any behavior - described with this label. - - - - - - - - - -Droms Standards Track [Page 5] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - o "MAY" - - This word or the adjective "OPTIONAL" means that this item is - truly optional. One vendor may choose to include the item - because a particular marketplace requires it or because it - enhances the product, for example; another vendor may omit the - same item. - -1.5 Terminology - - This document uses the following terms: - - o "DHCP client" - - A DHCP client is an Internet host using DHCP to obtain - configuration parameters such as a network address. - - o "DHCP server" - - A DHCP server is an Internet host that returns configuration - parameters to DHCP clients. - - o "BOOTP relay agent" - - A BOOTP relay agent or relay agent is an Internet host or router - that passes DHCP messages between DHCP clients and DHCP servers. - DHCP is designed to use the same relay agent behavior as specified - in the BOOTP protocol specification. - - o "binding" - - A binding is a collection of configuration parameters, including - at least an IP address, associated with or "bound to" a DHCP - client. Bindings are managed by DHCP servers. - -1.6 Design goals - - The following list gives general design goals for DHCP. - - o DHCP should be a mechanism rather than a policy. DHCP must - allow local system administrators control over configuration - parameters where desired; e.g., local system administrators - should be able to enforce local policies concerning allocation - and access to local resources where desired. - - - - - - - -Droms Standards Track [Page 6] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - o Clients should require no manual configuration. Each client - should be able to discover appropriate local configuration - parameters without user intervention and incorporate those - parameters into its own configuration. - - o Networks should require no manual configuration for individual - clients. Under normal circumstances, the network manager - should not have to enter any per-client configuration - parameters. - - o DHCP should not require a server on each subnet. To allow for - scale and economy, DHCP must work across routers or through the - intervention of BOOTP relay agents. - - o A DHCP client must be prepared to receive multiple responses - to a request for configuration parameters. Some installations - may include multiple, overlapping DHCP servers to enhance - reliability and increase performance. - - o DHCP must coexist with statically configured, non-participating - hosts and with existing network protocol implementations. - - o DHCP must interoperate with the BOOTP relay agent behavior as - described by RFC 951 and by RFC 1542 [21]. - - o DHCP must provide service to existing BOOTP clients. - - The following list gives design goals specific to the transmission of - the network layer parameters. DHCP must: - - o Guarantee that any specific network address will not be in - use by more than one DHCP client at a time, - - o Retain DHCP client configuration across DHCP client reboot. A - DHCP client should, whenever possible, be assigned the same - configuration parameters (e.g., network address) in response - to each request, - - o Retain DHCP client configuration across server reboots, and, - whenever possible, a DHCP client should be assigned the same - configuration parameters despite restarts of the DHCP mechanism, - - o Allow automated assignment of configuration parameters to new - clients to avoid hand configuration for new clients, - - o Support fixed or permanent allocation of configuration - parameters to specific clients. - - - - -Droms Standards Track [Page 7] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -2. Protocol Summary - - From the client's point of view, DHCP is an extension of the BOOTP - mechanism. This behavior allows existing BOOTP clients to - interoperate with DHCP servers without requiring any change to the - clients' initialization software. RFC 1542 [2] details the - interactions between BOOTP and DHCP clients and servers [9]. There - are some new, optional transactions that optimize the interaction - between DHCP clients and servers that are described in sections 3 and - 4. - - Figure 1 gives the format of a DHCP message and table 1 describes - each of the fields in the DHCP message. The numbers in parentheses - indicate the size of each field in octets. The names for the fields - given in the figure will be used throughout this document to refer to - the fields in DHCP messages. - - There are two primary differences between DHCP and BOOTP. First, - DHCP defines mechanisms through which clients can be assigned a - network address for a finite lease, allowing for serial reassignment - of network addresses to different clients. Second, DHCP provides the - mechanism for a client to acquire all of the IP configuration - parameters that it needs in order to operate. - - DHCP introduces a small change in terminology intended to clarify the - meaning of one of the fields. What was the "vendor extensions" field - in BOOTP has been re-named the "options" field in DHCP. Similarly, - the tagged data items that were used inside the BOOTP "vendor - extensions" field, which were formerly referred to as "vendor - extensions," are now termed simply "options." - - - - - - - - - - - - - - - - - - - - - -Droms Standards Track [Page 8] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | op (1) | htype (1) | hlen (1) | hops (1) | - +---------------+---------------+---------------+---------------+ - | xid (4) | - +-------------------------------+-------------------------------+ - | secs (2) | flags (2) | - +-------------------------------+-------------------------------+ - | ciaddr (4) | - +---------------------------------------------------------------+ - | yiaddr (4) | - +---------------------------------------------------------------+ - | siaddr (4) | - +---------------------------------------------------------------+ - | giaddr (4) | - +---------------------------------------------------------------+ - | | - | chaddr (16) | - | | - | | - +---------------------------------------------------------------+ - | | - | sname (64) | - +---------------------------------------------------------------+ - | | - | file (128) | - +---------------------------------------------------------------+ - | | - | options (variable) | - +---------------------------------------------------------------+ - - Figure 1: Format of a DHCP message - - DHCP defines a new 'client identifier' option that is used to pass an - explicit client identifier to a DHCP server. This change eliminates - the overloading of the 'chaddr' field in BOOTP messages, where - 'chaddr' is used both as a hardware address for transmission of BOOTP - reply messages and as a client identifier. The 'client identifier' - is an opaque key, not to be interpreted by the server; for example, - the 'client identifier' may contain a hardware address, identical to - the contents of the 'chaddr' field, or it may contain another type of - identifier, such as a DNS name. The 'client identifier' chosen by a - DHCP client MUST be unique to that client within the subnet to which - the client is attached. If the client uses a 'client identifier' in - one message, it MUST use that same identifier in all subsequent - messages, to ensure that all servers correctly identify the client. - - - - -Droms Standards Track [Page 9] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - DHCP clarifies the interpretation of the 'siaddr' field as the - address of the server to use in the next step of the client's - bootstrap process. A DHCP server may return its own address in the - 'siaddr' field, if the server is prepared to supply the next - bootstrap service (e.g., delivery of an operating system executable - image). A DHCP server always returns its own address in the 'server - identifier' option. - - FIELD OCTETS DESCRIPTION - ----- ------ ----------- - - op 1 Message op code / message type. - 1 = BOOTREQUEST, 2 = BOOTREPLY - htype 1 Hardware address type, see ARP section in "Assigned - Numbers" RFC; e.g., '1' = 10mb ethernet. - hlen 1 Hardware address length (e.g. '6' for 10mb - ethernet). - hops 1 Client sets to zero, optionally used by relay agents - when booting via a relay agent. - xid 4 Transaction ID, a random number chosen by the - client, used by the client and server to associate - messages and responses between a client and a - server. - secs 2 Filled in by client, seconds elapsed since client - began address acquisition or renewal process. - flags 2 Flags (see figure 2). - ciaddr 4 Client IP address; only filled in if client is in - BOUND, RENEW or REBINDING state and can respond - to ARP requests. - yiaddr 4 'your' (client) IP address. - siaddr 4 IP address of next server to use in bootstrap; - returned in DHCPOFFER, DHCPACK by server. - giaddr 4 Relay agent IP address, used in booting via a - relay agent. - chaddr 16 Client hardware address. - sname 64 Optional server host name, null terminated string. - file 128 Boot file name, null terminated string; "generic" - name or null in DHCPDISCOVER, fully qualified - directory-path name in DHCPOFFER. - options var Optional parameters field. See the options - documents for a list of defined options. - - Table 1: Description of fields in a DHCP message - - The 'options' field is now variable length. A DHCP client must be - prepared to receive DHCP messages with an 'options' field of at least - length 312 octets. This requirement implies that a DHCP client must - be prepared to receive a message of up to 576 octets, the minimum IP - - - -Droms Standards Track [Page 10] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - datagram size an IP host must be prepared to accept [3]. DHCP - clients may negotiate the use of larger DHCP messages through the - 'maximum DHCP message size' option. The options field may be further - extended into the 'file' and 'sname' fields. - - In the case of a client using DHCP for initial configuration (before - the client's TCP/IP software has been completely configured), DHCP - requires creative use of the client's TCP/IP software and liberal - interpretation of RFC 1122. The TCP/IP software SHOULD accept and - forward to the IP layer any IP packets delivered to the client's - hardware address before the IP address is configured; DHCP servers - and BOOTP relay agents may not be able to deliver DHCP messages to - clients that cannot accept hardware unicast datagrams before the - TCP/IP software is configured. - - To work around some clients that cannot accept IP unicast datagrams - before the TCP/IP software is configured as discussed in the previous - paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is - defined as the BROADCAST (B) flag. The semantics of this flag are - discussed in section 4.1 of this document. The remaining bits of the - flags field are reserved for future use. They MUST be set to zero by - clients and ignored by servers and relay agents. Figure 2 gives the - format of the 'flags' field. - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |B| MBZ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - B: BROADCAST flag - - MBZ: MUST BE ZERO (reserved for future use) - - Figure 2: Format of the 'flags' field - -2.1 Configuration parameters repository - - The first service provided by DHCP is to provide persistent storage - of network parameters for network clients. The model of DHCP - persistent storage is that the DHCP service stores a key-value entry - for each client, where the key is some unique identifier (for - example, an IP subnet number and a unique identifier within the - subnet) and the value contains the configuration parameters for the - client. - - For example, the key might be the pair (IP-subnet-number, hardware- - address) (note that the "hardware-address" should be typed by the - - - -Droms Standards Track [Page 11] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - type of hardware to accommodate possible duplication of hardware - addresses resulting from bit-ordering problems in a mixed-media, - bridged network) allowing for serial or concurrent reuse of a - hardware address on different subnets, and for hardware addresses - that may not be globally unique. Alternately, the key might be the - pair (IP-subnet-number, hostname), allowing the server to assign - parameters intelligently to a DHCP client that has been moved to a - different subnet or has changed hardware addresses (perhaps because - the network interface failed and was replaced). The protocol defines - that the key will be (IP-subnet-number, hardware-address) unless the - client explicitly supplies an identifier using the 'client - identifier' option. A client can query the DHCP service to - retrieve its configuration parameters. The client interface to the - configuration parameters repository consists of protocol messages to - request configuration parameters and responses from the server - carrying the configuration parameters. - -2.2 Dynamic allocation of network addresses - - The second service provided by DHCP is the allocation of temporary or - permanent network (IP) addresses to clients. The basic mechanism for - the dynamic allocation of network addresses is simple: a client - requests the use of an address for some period of time. The - allocation mechanism (the collection of DHCP servers) guarantees not - to reallocate that address within the requested time and attempts to - return the same network address each time the client requests an - address. In this document, the period over which a network address - is allocated to a client is referred to as a "lease" [11]. The - client may extend its lease with subsequent requests. The client may - issue a message to release the address back to the server when the - client no longer needs the address. The client may ask for a - permanent assignment by asking for an infinite lease. Even when - assigning "permanent" addresses, a server may choose to give out - lengthy but non-infinite leases to allow detection of the fact that - the client has been retired. - - In some environments it will be necessary to reassign network - addresses due to exhaustion of available addresses. In such - environments, the allocation mechanism will reuse addresses whose - lease has expired. The server should use whatever information is - available in the configuration information repository to choose an - address to reuse. For example, the server may choose the least - recently assigned address. As a consistency check, the allocating - server SHOULD probe the reused address before allocating the address, - e.g., with an ICMP echo request, and the client SHOULD probe the - newly received address, e.g., with ARP. - - - - - -Droms Standards Track [Page 12] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -3. The Client-Server Protocol - - DHCP uses the BOOTP message format defined in RFC 951 and given in - table 1 and figure 1. The 'op' field of each DHCP message sent from - a client to a server contains BOOTREQUEST. BOOTREPLY is used in the - 'op' field of each DHCP message sent from a server to a client. - - The first four octets of the 'options' field of the DHCP message - contain the (decimal) values 99, 130, 83 and 99, respectively (this - is the same magic cookie as is defined in RFC 1497 [17]). The - remainder of the 'options' field consists of a list of tagged - parameters that are called "options". All of the "vendor extensions" - listed in RFC 1497 are also DHCP options. RFC 1533 gives the - complete set of options defined for use with DHCP. - - Several options have been defined so far. One particular option - - the "DHCP message type" option - must be included in every DHCP - message. This option defines the "type" of the DHCP message. - Additional options may be allowed, required, or not allowed, - depending on the DHCP message type. - - Throughout this document, DHCP messages that include a 'DHCP message - type' option will be referred to by the type of the message; e.g., a - DHCP message with 'DHCP message type' option type 1 will be referred - to as a "DHCPDISCOVER" message. - -3.1 Client-server interaction - allocating a network address - - The following summary of the protocol exchanges between clients and - servers refers to the DHCP messages described in table 2. The - timeline diagram in figure 3 shows the timing relationships in a - typical client-server interaction. If the client already knows its - address, some steps may be omitted; this abbreviated interaction is - described in section 3.2. - - 1. The client broadcasts a DHCPDISCOVER message on its local physical - subnet. The DHCPDISCOVER message MAY include options that suggest - values for the network address and lease duration. BOOTP relay - agents may pass the message on to DHCP servers not on the same - physical subnet. - - 2. Each server may respond with a DHCPOFFER message that includes an - available network address in the 'yiaddr' field (and other - configuration parameters in DHCP options). Servers need not - reserve the offered network address, although the protocol will - work more efficiently if the server avoids allocating the offered - network address to another client. When allocating a new address, - servers SHOULD check that the offered network address is not - - - -Droms Standards Track [Page 13] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - already in use; e.g., the server may probe the offered address - with an ICMP Echo Request. Servers SHOULD be implemented so that - network administrators MAY choose to disable probes of newly - allocated addresses. The server transmits the DHCPOFFER message - to the client, using the BOOTP relay agent if necessary. - - Message Use - ------- --- - - DHCPDISCOVER - Client broadcast to locate available servers. - - DHCPOFFER - Server to client in response to DHCPDISCOVER with - offer of configuration parameters. - - DHCPREQUEST - Client message to servers either (a) requesting - offered parameters from one server and implicitly - declining offers from all others, (b) confirming - correctness of previously allocated address after, - e.g., system reboot, or (c) extending the lease on a - particular network address. - - DHCPACK - Server to client with configuration parameters, - including committed network address. - - DHCPNAK - Server to client indicating client's notion of network - address is incorrect (e.g., client has moved to new - subnet) or client's lease as expired - - DHCPDECLINE - Client to server indicating network address is already - in use. - - DHCPRELEASE - Client to server relinquishing network address and - cancelling remaining lease. - - DHCPINFORM - Client to server, asking only for local configuration - parameters; client already has externally configured - network address. - - Table 2: DHCP messages - - - - - - - - - - - - -Droms Standards Track [Page 14] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - Server Client Server - (not selected) (selected) - - v v v - | | | - | Begins initialization | - | | | - | _____________/|\____________ | - |/DHCPDISCOVER | DHCPDISCOVER \| - | | | - Determines | Determines - configuration | configuration - | | | - |\ | ____________/ | - | \________ | /DHCPOFFER | - | DHCPOFFER\ |/ | - | \ | | - | Collects replies | - | \| | - | Selects configuration | - | | | - | _____________/|\____________ | - |/ DHCPREQUEST | DHCPREQUEST\ | - | | | - | | Commits configuration - | | | - | | _____________/| - | |/ DHCPACK | - | | | - | Initialization complete | - | | | - . . . - . . . - | | | - | Graceful shutdown | - | | | - | |\ ____________ | - | | DHCPRELEASE \| - | | | - | | Discards lease - | | | - v v v - Figure 3: Timeline diagram of messages exchanged between DHCP - client and servers when allocating a new network address - - - - - - - -Droms Standards Track [Page 15] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - 3. The client receives one or more DHCPOFFER messages from one or more - servers. The client may choose to wait for multiple responses. - The client chooses one server from which to request configuration - parameters, based on the configuration parameters offered in the - DHCPOFFER messages. The client broadcasts a DHCPREQUEST message - that MUST include the 'server identifier' option to indicate which - server it has selected, and that MAY include other options - specifying desired configuration values. The 'requested IP - address' option MUST be set to the value of 'yiaddr' in the - DHCPOFFER message from the server. This DHCPREQUEST message is - broadcast and relayed through DHCP/BOOTP relay agents. To help - ensure that any BOOTP relay agents forward the DHCPREQUEST message - to the same set of DHCP servers that received the original - DHCPDISCOVER message, the DHCPREQUEST message MUST use the same - value in the DHCP message header's 'secs' field and be sent to the - same IP broadcast address as the original DHCPDISCOVER message. - The client times out and retransmits the DHCPDISCOVER message if - the client receives no DHCPOFFER messages. - - 4. The servers receive the DHCPREQUEST broadcast from the client. - Those servers not selected by the DHCPREQUEST message use the - message as notification that the client has declined that server's - offer. The server selected in the DHCPREQUEST message commits the - binding for the client to persistent storage and responds with a - DHCPACK message containing the configuration parameters for the - requesting client. The combination of 'client identifier' or - 'chaddr' and assigned network address constitute a unique - identifier for the client's lease and are used by both the client - and server to identify a lease referred to in any DHCP messages. - Any configuration parameters in the DHCPACK message SHOULD NOT - conflict with those in the earlier DHCPOFFER message to which the - client is responding. The server SHOULD NOT check the offered - network address at this point. The 'yiaddr' field in the DHCPACK - messages is filled in with the selected network address. - - If the selected server is unable to satisfy the DHCPREQUEST message - (e.g., the requested network address has been allocated), the - server SHOULD respond with a DHCPNAK message. - - A server MAY choose to mark addresses offered to clients in - DHCPOFFER messages as unavailable. The server SHOULD mark an - address offered to a client in a DHCPOFFER message as available if - the server receives no DHCPREQUEST message from that client. - - 5. The client receives the DHCPACK message with configuration - parameters. The client SHOULD perform a final check on the - parameters (e.g., ARP for allocated network address), and notes the - duration of the lease specified in the DHCPACK message. At this - - - -Droms Standards Track [Page 16] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - point, the client is configured. If the client detects that the - address is already in use (e.g., through the use of ARP), the - client MUST send a DHCPDECLINE message to the server and restarts - the configuration process. The client SHOULD wait a minimum of ten - seconds before restarting the configuration process to avoid - excessive network traffic in case of looping. - - If the client receives a DHCPNAK message, the client restarts the - configuration process. - - The client times out and retransmits the DHCPREQUEST message if the - client receives neither a DHCPACK or a DHCPNAK message. The client - retransmits the DHCPREQUEST according to the retransmission - algorithm in section 4.1. The client should choose to retransmit - the DHCPREQUEST enough times to give adequate probability of - contacting the server without causing the client (and the user of - that client) to wait overly long before giving up; e.g., a client - retransmitting as described in section 4.1 might retransmit the - DHCPREQUEST message four times, for a total delay of 60 seconds, - before restarting the initialization procedure. If the client - receives neither a DHCPACK or a DHCPNAK message after employing the - retransmission algorithm, the client reverts to INIT state and - restarts the initialization process. The client SHOULD notify the - user that the initialization process has failed and is restarting. - - 6. The client may choose to relinquish its lease on a network address - by sending a DHCPRELEASE message to the server. The client - identifies the lease to be released with its 'client identifier', - or 'chaddr' and network address in the DHCPRELEASE message. If the - client used a 'client identifier' when it obtained the lease, it - MUST use the same 'client identifier' in the DHCPRELEASE message. - -3.2 Client-server interaction - reusing a previously allocated network - address - - If a client remembers and wishes to reuse a previously allocated - network address, a client may choose to omit some of the steps - described in the previous section. The timeline diagram in figure 4 - shows the timing relationships in a typical client-server interaction - for a client reusing a previously allocated network address. - - - - - - - - - - - -Droms Standards Track [Page 17] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - 1. The client broadcasts a DHCPREQUEST message on its local subnet. - The message includes the client's network address in the - 'requested IP address' option. As the client has not received its - network address, it MUST NOT fill in the 'ciaddr' field. BOOTP - relay agents pass the message on to DHCP servers not on the same - subnet. If the client used a 'client identifier' to obtain its - address, the client MUST use the same 'client identifier' in the - DHCPREQUEST message. - - 2. Servers with knowledge of the client's configuration parameters - respond with a DHCPACK message to the client. Servers SHOULD NOT - check that the client's network address is already in use; the - client may respond to ICMP Echo Request messages at this point. - - Server Client Server - - v v v - | | | - | Begins | - | initialization | - | | | - | /|\ | - | _________ __/ | \__________ | - | /DHCPREQU EST | DHCPREQUEST\ | - |/ | \| - | | | - Locates | Locates - configuration | configuration - | | | - |\ | /| - | \ | ___________/ | - | \ | / DHCPACK | - | \ _______ |/ | - | DHCPACK\ | | - | Initialization | - | complete | - | \| | - | | | - | (Subsequent | - | DHCPACKS | - | ignored) | - | | | - | | | - v v v - - Figure 4: Timeline diagram of messages exchanged between DHCP - client and servers when reusing a previously allocated - network address - - - -Droms Standards Track [Page 18] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - If the client's request is invalid (e.g., the client has moved - to a new subnet), servers SHOULD respond with a DHCPNAK message to - the client. Servers SHOULD NOT respond if their information is not - guaranteed to be accurate. For example, a server that identifies a - request for an expired binding that is owned by another server SHOULD - NOT respond with a DHCPNAK unless the servers are using an explicit - mechanism to maintain coherency among the servers. - - If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on - the same subnet as the server. The server MUST - broadcast the DHCPNAK message to the 0xffffffff broadcast address - because the client may not have a correct network address or subnet - mask, and the client may not be answering ARP requests. - Otherwise, the server MUST send the DHCPNAK message to the IP - address of the BOOTP relay agent, as recorded in 'giaddr'. The - relay agent will, in turn, forward the message directly to the - client's hardware address, so that the DHCPNAK can be delivered even - if the client has moved to a new network. - - 3. The client receives the DHCPACK message with configuration - parameters. The client performs a final check on the parameters - (as in section 3.1), and notes the duration of the lease specified - in the DHCPACK message. The specific lease is implicitly identified - by the 'client identifier' or 'chaddr' and the network address. At - this point, the client is configured. - - If the client detects that the IP address in the DHCPACK message - is already in use, the client MUST send a DHCPDECLINE message to the - server and restarts the configuration process by requesting a - new network address. This action corresponds to the client - moving to the INIT state in the DHCP state diagram, which is - described in section 4.4. - - If the client receives a DHCPNAK message, it cannot reuse its - remembered network address. It must instead request a new - address by restarting the configuration process, this time - using the (non-abbreviated) procedure described in section - 3.1. This action also corresponds to the client moving to - the INIT state in the DHCP state diagram. - - The client times out and retransmits the DHCPREQUEST message if - the client receives neither a DHCPACK nor a DHCPNAK message. The - client retransmits the DHCPREQUEST according to the retransmission - algorithm in section 4.1. The client should choose to retransmit - the DHCPREQUEST enough times to give adequate probability of - contacting the server without causing the client (and the user of - that client) to wait overly long before giving up; e.g., a client - retransmitting as described in section 4.1 might retransmit the - - - -Droms Standards Track [Page 19] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - DHCPREQUEST message four times, for a total delay of 60 seconds, - before restarting the initialization procedure. If the client - receives neither a DHCPACK or a DHCPNAK message after employing - the retransmission algorithm, the client MAY choose to use the - previously allocated network address and configuration parameters - for the remainder of the unexpired lease. This corresponds to - moving to BOUND state in the client state transition diagram shown - in figure 5. - - 4. The client may choose to relinquish its lease on a network - address by sending a DHCPRELEASE message to the server. The - client identifies the lease to be released with its - 'client identifier', or 'chaddr' and network address in the - DHCPRELEASE message. - - Note that in this case, where the client retains its network - address locally, the client will not normally relinquish its - lease during a graceful shutdown. Only in the case where the - client explicitly needs to relinquish its lease, e.g., the client - is about to be moved to a different subnet, will the client send - a DHCPRELEASE message. - -3.3 Interpretation and representation of time values - - A client acquires a lease for a network address for a fixed period of - time (which may be infinite). Throughout the protocol, times are to - be represented in units of seconds. The time value of 0xffffffff is - reserved to represent "infinity". - - As clients and servers may not have synchronized clocks, times are - represented in DHCP messages as relative times, to be interpreted - with respect to the client's local clock. Representing relative - times in units of seconds in an unsigned 32 bit word gives a range of - relative times from 0 to approximately 100 years, which is sufficient - for the relative times to be measured using DHCP. - - The algorithm for lease duration interpretation given in the previous - paragraph assumes that client and server clocks are stable relative - to each other. If there is drift between the two clocks, the server - may consider the lease expired before the client does. To - compensate, the server may return a shorter lease duration to the - client than the server commits to its local database of client - information. - -3.4 Obtaining parameters with externally configured network address - - If a client has obtained a network address through some other means - (e.g., manual configuration), it may use a DHCPINFORM request message - - - -Droms Standards Track [Page 20] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - to obtain other local configuration parameters. Servers receiving a - DHCPINFORM message construct a DHCPACK message with any local - configuration parameters appropriate for the client without: - allocating a new address, checking for an existing binding, filling - in 'yiaddr' or including lease time parameters. The servers SHOULD - unicast the DHCPACK reply to the address given in the 'ciaddr' field - of the DHCPINFORM message. - - The server SHOULD check the network address in a DHCPINFORM message - for consistency, but MUST NOT check for an existing lease. The - server forms a DHCPACK message containing the configuration - parameters for the requesting client and sends the DHCPACK message - directly to the client. - -3.5 Client parameters in DHCP - - Not all clients require initialization of all parameters listed in - Appendix A. Two techniques are used to reduce the number of - parameters transmitted from the server to the client. First, most of - the parameters have defaults defined in the Host Requirements RFCs; - if the client receives no parameters from the server that override - the defaults, a client uses those default values. Second, in its - initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the - server with a list of specific parameters the client is interested - in. If the client includes a list of parameters in a DHCPDISCOVER - message, it MUST include that list in any subsequent DHCPREQUEST - messages. - - The client SHOULD include the 'maximum DHCP message size' option to - let the server know how large the server may make its DHCP messages. - The parameters returned to a client may still exceed the space - allocated to options in a DHCP message. In this case, two additional - options flags (which must appear in the 'options' field of the - message) indicate that the 'file' and 'sname' fields are to be used - for options. - - The client can inform the server which configuration parameters the - client is interested in by including the 'parameter request list' - option. The data portion of this option explicitly lists the options - requested by tag number. - - In addition, the client may suggest values for the network address - and lease time in the DHCPDISCOVER message. The client may include - the 'requested IP address' option to suggest that a particular IP - address be assigned, and may include the 'IP address lease time' - option to suggest the lease time it would like. Other options - representing "hints" at configuration parameters are allowed in a - DHCPDISCOVER or DHCPREQUEST message. However, additional options may - - - -Droms Standards Track [Page 21] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - be ignored by servers, and multiple servers may, therefore, not - return identical values for some options. The 'requested IP address' - option is to be filled in only in a DHCPREQUEST message when the - client is verifying network parameters obtained previously. The - client fills in the 'ciaddr' field only when correctly configured - with an IP address in BOUND, RENEWING or REBINDING state. - - If a server receives a DHCPREQUEST message with an invalid 'requested - IP address', the server SHOULD respond to the client with a DHCPNAK - message and may choose to report the problem to the system - administrator. The server may include an error message in the - 'message' option. - -3.6 Use of DHCP in clients with multiple interfaces - - A client with multiple network interfaces must use DHCP through each - interface independently to obtain configuration information - parameters for those separate interfaces. - -3.7 When clients should use DHCP - - A client SHOULD use DHCP to reacquire or verify its IP address and - network parameters whenever the local network parameters may have - changed; e.g., at system boot time or after a disconnection from the - local network, as the local network configuration may change without - the client's or user's knowledge. - - If a client has knowledge of a previous network address and is unable - to contact a local DHCP server, the client may continue to use the - previous network address until the lease for that address expires. - If the lease expires before the client can contact a DHCP server, the - client must immediately discontinue use of the previous network - address and may inform local users of the problem. - -4. Specification of the DHCP client-server protocol - - In this section, we assume that a DHCP server has a block of network - addresses from which it can satisfy requests for new addresses. Each - server also maintains a database of allocated addresses and leases in - local permanent storage. - -4.1 Constructing and sending DHCP messages - - DHCP clients and servers both construct DHCP messages by filling in - fields in the fixed format section of the message and appending - tagged data items in the variable length option area. The options - area includes first a four-octet 'magic cookie' (which was described - in section 3), followed by the options. The last option must always - - - -Droms Standards Track [Page 22] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - be the 'end' option. - - DHCP uses UDP as its transport protocol. DHCP messages from a client - to a server are sent to the 'DHCP server' port (67), and DHCP - messages from a server to a client are sent to the 'DHCP client' port - (68). A server with multiple network address (e.g., a multi-homed - host) MAY use any of its network addresses in outgoing DHCP messages. - - The 'server identifier' field is used both to identify a DHCP server - in a DHCP message and as a destination address from clients to - servers. A server with multiple network addresses MUST be prepared - to to accept any of its network addresses as identifying that server - in a DHCP message. To accommodate potentially incomplete network - connectivity, a server MUST choose an address as a 'server - identifier' that, to the best of the server's knowledge, is reachable - from the client. For example, if the DHCP server and the DHCP client - are connected to the same subnet (i.e., the 'giaddr' field in the - message from the client is zero), the server SHOULD select the IP - address the server is using for communication on that subnet as the - 'server identifier'. If the server is using multiple IP addresses on - that subnet, any such address may be used. If the server has - received a message through a DHCP relay agent, the server SHOULD - choose an address from the interface on which the message was - recieved as the 'server identifier' (unless the server has other, - better information on which to make its choice). DHCP clients MUST - use the IP address provided in the 'server identifier' option for any - unicast requests to the DHCP server. - - DHCP messages broadcast by a client prior to that client obtaining - its IP address must have the source address field in the IP header - set to 0. - - If the 'giaddr' field in a DHCP message from a client is non-zero, - the server sends any return messages to the 'DHCP server' port on the - BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' - field is zero and the 'ciaddr' field is nonzero, then the server - unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. - If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is - set, then the server broadcasts DHCPOFFER and DHCPACK messages to - 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and - 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK - messages to the client's hardware address and 'yiaddr' address. In - all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK - messages to 0xffffffff. - - If the options in a DHCP message extend into the 'sname' and 'file' - fields, the 'option overload' option MUST appear in the 'options' - field, with value 1, 2 or 3, as specified in RFC 1533. If the - - - -Droms Standards Track [Page 23] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - 'option overload' option is present in the 'options' field, the - options in the 'options' field MUST be terminated by an 'end' option, - and MAY contain one or more 'pad' options to fill the options field. - The options in the 'sname' and 'file' fields (if in use as indicated - by the 'options overload' option) MUST begin with the first octet of - the field, MUST be terminated by an 'end' option, and MUST be - followed by 'pad' options to fill the remainder of the field. Any - individual option in the 'options', 'sname' and 'file' fields MUST be - entirely contained in that field. The options in the 'options' field - MUST be interpreted first, so that any 'option overload' options may - be interpreted. The 'file' field MUST be interpreted next (if the - 'option overload' option indicates that the 'file' field contains - DHCP options), followed by the 'sname' field. - - The values to be passed in an 'option' tag may be too long to fit in - the 255 octets available to a single option (e.g., a list of routers - in a 'router' option [21]). Options may appear only once, unless - otherwise specified in the options document. The client concatenates - the values of multiple instances of the same option into a single - parameter list for configuration. - - DHCP clients are responsible for all message retransmission. The - client MUST adopt a retransmission strategy that incorporates a - randomized exponential backoff algorithm to determine the delay - between retransmissions. The delay between retransmissions SHOULD be - chosen to allow sufficient time for replies from the server to be - delivered based on the characteristics of the internetwork between - the client and the server. For example, in a 10Mb/sec Ethernet - internetwork, the delay before the first retransmission SHOULD be 4 - seconds randomized by the value of a uniform random number chosen - from the range -1 to +1. Clients with clocks that provide resolution - granularity of less than one second may choose a non-integer - randomization value. The delay before the next retransmission SHOULD - be 8 seconds randomized by the value of a uniform number chosen from - the range -1 to +1. The retransmission delay SHOULD be doubled with - subsequent retransmissions up to a maximum of 64 seconds. The client - MAY provide an indication of retransmission attempts to the user as - an indication of the progress of the configuration process. - - The 'xid' field is used by the client to match incoming DHCP messages - with pending requests. A DHCP client MUST choose 'xid's in such a - way as to minimize the chance of using an 'xid' identical to one used - by another client. For example, a client may choose a different, - random initial 'xid' each time the client is rebooted, and - subsequently use sequential 'xid's until the next reboot. Selecting - a new 'xid' for each retransmission is an implementation decision. A - client may choose to reuse the same 'xid' or select a new 'xid' for - each retransmitted message. - - - -Droms Standards Track [Page 24] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - Normally, DHCP servers and BOOTP relay agents attempt to deliver - DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using - uicast delivery. The IP destination address (in the IP header) is - set to the DHCP 'yiaddr' address and the link-layer destination - address is set to the DHCP 'chaddr' address. Unfortunately, some - client implementations are unable to receive such unicast IP - datagrams until the implementation has been configured with a valid - IP address (leading to a deadlock in which the client's IP address - cannot be delivered until the client has been configured with an IP - address). - - A client that cannot receive unicast IP datagrams until its protocol - software has been configured with an IP address SHOULD set the - BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or - DHCPREQUEST messages that client sends. The BROADCAST bit will - provide a hint to the DHCP server and BOOTP relay agent to broadcast - any messages to the client on the client's subnet. A client that can - receive unicast IP datagrams before its protocol software has been - configured SHOULD clear the BROADCAST bit to 0. The BOOTP - clarifications document discusses the ramifications of the use of the - BROADCAST bit [21]. - - A server or relay agent sending or relaying a DHCP message directly - to a DHCP client (i.e., not to a relay agent specified in the - 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' - field. If this bit is set to 1, the DHCP message SHOULD be sent as - an IP broadcast using an IP broadcast address (preferably 0xffffffff) - as the IP destination address and the link-layer broadcast address as - the link-layer destination address. If the BROADCAST bit is cleared - to 0, the message SHOULD be sent as an IP unicast to the IP address - specified in the 'yiaddr' field and the link-layer address specified - in the 'chaddr' field. If unicasting is not possible, the message - MAY be sent as an IP broadcast using an IP broadcast address - (preferably 0xffffffff) as the IP destination address and the link- - layer broadcast address as the link-layer destination address. - -4.2 DHCP server administrative controls - - DHCP servers are not required to respond to every DHCPDISCOVER and - DHCPREQUEST message they receive. For example, a network - administrator, to retain stringent control over the clients attached - to the network, may choose to configure DHCP servers to respond only - to clients that have been previously registered through some external - mechanism. The DHCP specification describes only the interactions - between clients and servers when the clients and servers choose to - interact; it is beyond the scope of the DHCP specification to - describe all of the administrative controls that system - administrators might want to use. Specific DHCP server - - - -Droms Standards Track [Page 25] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - implementations may incorporate any controls or policies desired by a - network administrator. - - In some environments, a DHCP server will have to consider the values - of the vendor class options included in DHCPDISCOVER or DHCPREQUEST - messages when determining the correct parameters for a particular - client. - - A DHCP server needs to use some unique identifier to associate a - client with its lease. The client MAY choose to explicitly provide - the identifier through the 'client identifier' option. If the client - supplies a 'client identifier', the client MUST use the same 'client - identifier' in all subsequent messages, and the server MUST use that - identifier to identify the client. If the client does not provide a - 'client identifier' option, the server MUST use the contents of the - 'chaddr' field to identify the client. It is crucial for a DHCP - client to use an identifier unique within the subnet to which the - client is attached in the 'client identifier' option. Use of - 'chaddr' as the client's unique identifier may cause unexpected - results, as that identifier may be associated with a hardware - interface that could be moved to a new client. Some sites may choose - to use a manufacturer's serial number as the 'client identifier', to - avoid unexpected changes in a clients network address due to transfer - of hardware interfaces among computers. Sites may also choose to use - a DNS name as the 'client identifier', causing address leases to be - associated with the DNS name rather than a specific hardware box. - - DHCP clients are free to use any strategy in selecting a DHCP server - among those from which the client receives a DHCPOFFER message. The - client implementation of DHCP SHOULD provide a mechanism for the user - to select directly the 'vendor class identifier' values. - -4.3 DHCP server behavior - - A DHCP server processes incoming DHCP messages from a client based on - the current state of the binding for that client. A DHCP server can - receive the following messages from a client: - - o DHCPDISCOVER - - o DHCPREQUEST - - o DHCPDECLINE - - o DHCPRELEASE - - o DHCPINFORM - - - - -Droms Standards Track [Page 26] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - Table 3 gives the use of the fields and options in a DHCP message by - a server. The remainder of this section describes the action of the - DHCP server for each possible incoming message. - -4.3.1 DHCPDISCOVER message - - When a server receives a DHCPDISCOVER message from a client, the - server chooses a network address for the requesting client. If no - address is available, the server may choose to report the problem to - the system administrator. If an address is available, the new address - SHOULD be chosen as follows: - - o The client's current address as recorded in the client's current - binding, ELSE - - o The client's previous address as recorded in the client's (now - expired or released) binding, if that address is in the server's - pool of available addresses and not already allocated, ELSE - - o The address requested in the 'Requested IP Address' option, if that - address is valid and not already allocated, ELSE - - o A new address allocated from the server's pool of available - addresses; the address is selected based on the subnet from which - the message was received (if 'giaddr' is 0) or on the address of - the relay agent that forwarded the message ('giaddr' when not 0). - - As described in section 4.2, a server MAY, for administrative - reasons, assign an address other than the one requested, or may - refuse to allocate an address to a particular client even though free - addresses are available. - - Note that, in some network architectures (e.g., internets with more - than one IP subnet assigned to a physical network segment), it may be - the case that the DHCP client should be assigned an address from a - different subnet than the address recorded in 'giaddr'. Thus, DHCP - does not require that the client be assigned as address from the - subnet in 'giaddr'. A server is free to choose some other subnet, - and it is beyond the scope of the DHCP specification to describe ways - in which the assigned IP address might be chosen. - - While not required for correct operation of DHCP, the server SHOULD - NOT reuse the selected network address before the client responds to - the server's DHCPOFFER message. The server may choose to record the - address as offered to the client. - - The server must also choose an expiration time for the lease, as - follows: - - - -Droms Standards Track [Page 27] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - o IF the client has not requested a specific lease in the - DHCPDISCOVER message and the client already has an assigned network - address, the server returns the lease expiration time previously - assigned to that address (note that the client must explicitly - request a specific lease to extend the expiration time on a - previously assigned address), ELSE - - o IF the client has not requested a specific lease in the - DHCPDISCOVER message and the client does not have an assigned - network address, the server assigns a locally configured default - lease time, ELSE - - o IF the client has requested a specific lease in the DHCPDISCOVER - message (regardless of whether the client has an assigned network - address), the server may choose either to return the requested - lease (if the lease is acceptable to local policy) or select - another lease. - -Field DHCPOFFER DHCPACK DHCPNAK ------ --------- ------- ------- -'op' BOOTREPLY BOOTREPLY BOOTREPLY -'htype' (From "Assigned Numbers" RFC) -'hlen' (Hardware address length in octets) -'hops' 0 0 0 -'xid' 'xid' from client 'xid' from client 'xid' from client - DHCPDISCOVER DHCPREQUEST DHCPREQUEST - message message message -'secs' 0 0 0 -'ciaddr' 0 'ciaddr' from 0 - DHCPREQUEST or 0 -'yiaddr' IP address offered IP address 0 - to client assigned to client -'siaddr' IP address of next IP address of next 0 - bootstrap server bootstrap server -'flags' 'flags' from 'flags' from 'flags' from - client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST - message message message -'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from - client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST - message message message -'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from - client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST - message message message -'sname' Server host name Server host name (unused) - or options or options -'file' Client boot file Client boot file (unused) - name or options name or options -'options' options options - - - -Droms Standards Track [Page 28] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -Option DHCPOFFER DHCPACK DHCPNAK ------- --------- ------- ------- -Requested IP address MUST NOT MUST NOT MUST NOT -IP address lease time MUST MUST (DHCPREQUEST) MUST NOT - MUST NOT (DHCPINFORM) -Use 'file'/'sname' fields MAY MAY MUST NOT -DHCP message type DHCPOFFER DHCPACK DHCPNAK -Parameter request list MUST NOT MUST NOT MUST NOT -Message SHOULD SHOULD SHOULD -Client identifier MUST NOT MUST NOT MAY -Vendor class identifier MAY MAY MAY -Server identifier MUST MUST MUST -Maximum message size MUST NOT MUST NOT MUST NOT -All others MAY MAY MUST NOT - - Table 3: Fields and options used by DHCP servers - - Once the network address and lease have been determined, the server - constructs a DHCPOFFER message with the offered configuration - parameters. It is important for all DHCP servers to return the same - parameters (with the possible exception of a newly allocated network - address) to ensure predictable client behavior regardless of which - server the client selects. The configuration parameters MUST be - selected by applying the following rules in the order given below. - The network administrator is responsible for configuring multiple - DHCP servers to ensure uniform responses from those servers. The - server MUST return to the client: - - o The client's network address, as determined by the rules given - earlier in this section, - - o The expiration time for the client's lease, as determined by the - rules given earlier in this section, - - o Parameters requested by the client, according to the following - rules: - - -- IF the server has been explicitly configured with a default - value for the parameter, the server MUST include that value - in an appropriate option in the 'option' field, ELSE - - -- IF the server recognizes the parameter as a parameter - defined in the Host Requirements Document, the server MUST - include the default value for that parameter as given in the - Host Requirements Document in an appropriate option in the - 'option' field, ELSE - - -- The server MUST NOT return a value for that parameter, - - - -Droms Standards Track [Page 29] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - The server MUST supply as many of the requested parameters as - possible and MUST omit any parameters it cannot provide. The - server MUST include each requested parameter only once unless - explicitly allowed in the DHCP Options and BOOTP Vendor - Extensions document. - - o Any parameters from the existing binding that differ from the Host - Requirements Document defaults, - - o Any parameters specific to this client (as identified by - the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER - or DHCPREQUEST message), e.g., as configured by the network - administrator, - - o Any parameters specific to this client's class (as identified - by the contents of the 'vendor class identifier' - option in the DHCPDISCOVER or DHCPREQUEST message), - e.g., as configured by the network administrator; the parameters - MUST be identified by an exact match between the client's vendor - class identifiers and the client's classes identified in the - server, - - o Parameters with non-default values on the client's subnet. - - The server MAY choose to return the 'vendor class identifier' used to - determine the parameters in the DHCPOFFER message to assist the - client in selecting which DHCPOFFER to accept. The server inserts - the 'xid' field from the DHCPDISCOVER message into the 'xid' field of - the DHCPOFFER message and sends the DHCPOFFER message to the - requesting client. - -4.3.2 DHCPREQUEST message - - A DHCPREQUEST message may come from a client responding to a - DHCPOFFER message from a server, from a client verifying a previously - allocated IP address or from a client extending the lease on a - network address. If the DHCPREQUEST message contains a 'server - identifier' option, the message is in response to a DHCPOFFER - message. Otherwise, the message is a request to verify or extend an - existing lease. If the client uses a 'client identifier' in a - DHCPREQUEST message, it MUST use that same 'client identifier' in all - subsequent messages. If the client included a list of requested - parameters in a DHCPDISCOVER message, it MUST include that list in - all subsequent messages. - - - - - - - -Droms Standards Track [Page 30] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - Any configuration parameters in the DHCPACK message SHOULD NOT - conflict with those in the earlier DHCPOFFER message to which the - client is responding. The client SHOULD use the parameters in the - DHCPACK message for configuration. - - Clients send DHCPREQUEST messages as follows: - - o DHCPREQUEST generated during SELECTING state: - - Client inserts the address of the selected server in 'server - identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be - filled in with the yiaddr value from the chosen DHCPOFFER. - - Note that the client may choose to collect several DHCPOFFER - messages and select the "best" offer. The client indicates its - selection by identifying the offering server in the DHCPREQUEST - message. If the client receives no acceptable offers, the client - may choose to try another DHCPDISCOVER message. Therefore, the - servers may not receive a specific DHCPREQUEST from which they can - decide whether or not the client has accepted the offer. Because - the servers have not committed any network address assignments on - the basis of a DHCPOFFER, servers are free to reuse offered - network addresses in response to subsequent requests. As an - implementation detail, servers SHOULD NOT reuse offered addresses - and may use an implementation-specific timeout mechanism to decide - when to reuse an offered address. - - o DHCPREQUEST generated during INIT-REBOOT state: - - 'server identifier' MUST NOT be filled in, 'requested IP address' - option MUST be filled in with client's notion of its previously - assigned address. 'ciaddr' MUST be zero. The client is seeking to - verify a previously allocated, cached configuration. Server SHOULD - send a DHCPNAK message to the client if the 'requested IP address' - is incorrect, or is on the wrong network. - - Determining whether a client in the INIT-REBOOT state is on the - correct network is done by examining the contents of 'giaddr', the - 'requested IP address' option, and a database lookup. If the DHCP - server detects that the client is on the wrong net (i.e., the - result of applying the local subnet mask or remote subnet mask (if - 'giaddr' is not zero) to 'requested IP address' option value - doesn't match reality), then the server SHOULD send a DHCPNAK - message to the client. - - - - - - - -Droms Standards Track [Page 31] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - If the network is correct, then the DHCP server should check if - the client's notion of its IP address is correct. If not, then the - server SHOULD send a DHCPNAK message to the client. If the DHCP - server has no record of this client, then it MUST remain silent, - and MAY output a warning to the network administrator. This - behavior is necessary for peaceful coexistence of non- - communicating DHCP servers on the same wire. - - If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on - the same subnet as the server. The server MUST broadcast the - DHCPNAK message to the 0xffffffff broadcast address because the - client may not have a correct network address or subnet mask, and - the client may not be answering ARP requests. - - If 'giaddr' is set in the DHCPREQUEST message, the client is on a - different subnet. The server MUST set the broadcast bit in the - DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the - client, because the client may not have a correct network address - or subnet mask, and the client may not be answering ARP requests. - - o DHCPREQUEST generated during RENEWING state: - - 'server identifier' MUST NOT be filled in, 'requested IP address' - option MUST NOT be filled in, 'ciaddr' MUST be filled in with - client's IP address. In this situation, the client is completely - configured, and is trying to extend its lease. This message will - be unicast, so no relay agents will be involved in its - transmission. Because 'giaddr' is therefore not filled in, the - DHCP server will trust the value in 'ciaddr', and use it when - replying to the client. - - A client MAY choose to renew or extend its lease prior to T1. The - server may choose not to extend the lease (as a policy decision by - the network administrator), but should return a DHCPACK message - regardless. - - o DHCPREQUEST generated during REBINDING state: - - 'server identifier' MUST NOT be filled in, 'requested IP address' - option MUST NOT be filled in, 'ciaddr' MUST be filled in with - client's IP address. In this situation, the client is completely - configured, and is trying to extend its lease. This message MUST - be broadcast to the 0xffffffff IP broadcast address. The DHCP - server SHOULD check 'ciaddr' for correctness before replying to - the DHCPREQUEST. - - - - - - -Droms Standards Track [Page 32] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - The DHCPREQUEST from a REBINDING client is intended to accommodate - sites that have multiple DHCP servers and a mechanism for - maintaining consistency among leases managed by multiple servers. - A DHCP server MAY extend a client's lease only if it has local - administrative authority to do so. - -4.3.3 DHCPDECLINE message - - If the server receives a DHCPDECLINE message, the client has - discovered through some other means that the suggested network - address is already in use. The server MUST mark the network address - as not available and SHOULD notify the local system administrator of - a possible configuration problem. - -4.3.4 DHCPRELEASE message - - Upon receipt of a DHCPRELEASE message, the server marks the network - address as not allocated. The server SHOULD retain a record of the - client's initialization parameters for possible reuse in response to - subsequent requests from the client. - -4.3.5 DHCPINFORM message - - The server responds to a DHCPINFORM message by sending a DHCPACK - message directly to the address given in the 'ciaddr' field of the - DHCPINFORM message. The server MUST NOT send a lease expiration time - to the client and SHOULD NOT fill in 'yiaddr'. The server includes - other parameters in the DHCPACK message as defined in section 4.3.1. - -4.3.6 Client messages - - Table 4 details the differences between messages from clients in - various states. - - --------------------------------------------------------------------- - | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | - --------------------------------------------------------------------- - |broad/unicast |broadcast |broadcast |unicast |broadcast | - |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | - |requested-ip |MUST |MUST |MUST NOT |MUST NOT | - |ciaddr |zero |zero |IP address |IP address| - --------------------------------------------------------------------- - - Table 4: Client messages from different states - - - - - - - -Droms Standards Track [Page 33] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -4.4 DHCP client behavior - - Figure 5 gives a state-transition diagram for a DHCP client. A - client can receive the following messages from a server: - - o DHCPOFFER - - o DHCPACK - - o DHCPNAK - - The DHCPINFORM message is not shown in figure 5. A client simply - sends the DHCPINFORM and waits for DHCPACK messages. Once the client - has selected its parameters, it has completed the configuration - process. - - Table 5 gives the use of the fields and options in a DHCP message by - a client. The remainder of this section describes the action of the - DHCP client for each possible incoming message. The description in - the following section corresponds to the full configuration procedure - previously described in section 3.1, and the text in the subsequent - section corresponds to the abbreviated configuration procedure - described in section 3.2. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms Standards Track [Page 34] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - -------- ------- -| | +-------------------------->| |<-------------------+ -| INIT- | | +-------------------->| INIT | | -| REBOOT |DHCPNAK/ +---------->| |<---+ | -| |Restart| | ------- | | - -------- | DHCPNAK/ | | | - | Discard offer | -/Send DHCPDISCOVER | --/Send DHCPREQUEST | | | - | | | DHCPACK v | | - ----------- | (not accept.)/ ----------- | | -| | | Send DHCPDECLINE | | | -| REBOOTING | | | | SELECTING |<----+ | -| | | / | | |DHCPOFFER/ | - ----------- | / ----------- | |Collect | - | | / | | | replies | -DHCPACK/ | / +----------------+ +-------+ | -Record lease, set| | v Select offer/ | -timers T1, T2 ------------ send DHCPREQUEST | | - | +----->| | DHCPNAK, Lease expired/ | - | | | REQUESTING | Halt network | - DHCPOFFER/ | | | | - Discard ------------ | | - | | | | ----------- | - | +--------+ DHCPACK/ | | | - | Record lease, set -----| REBINDING | | - | timers T1, T2 / | | | - | | DHCPACK/ ----------- | - | v Record lease, set ^ | - +----------------> ------- /timers T1,T2 | | - +----->| |<---+ | | - | | BOUND |<---+ | | - DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/ - DHCPNAK/Discard ------- | Broadcast Halt network - | | | | DHCPREQUEST | - +-------+ | DHCPACK/ | | - T1 expires/ Record lease, set | | - Send DHCPREQUEST timers T1, T2 | | - to leasing server | | | - | ---------- | | - | | |------------+ | - +->| RENEWING | | - | |----------------------------+ - ---------- - Figure 5: State-transition diagram for DHCP clients - - - - - - - -Droms Standards Track [Page 35] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -4.4.1 Initialization and allocation of network address - - The client begins in INIT state and forms a DHCPDISCOVER message. - The client SHOULD wait a random time between one and ten seconds to - desynchronize the use of DHCP at startup. The client sets 'ciaddr' - to 0x00000000. The client MAY request specific parameters by - including the 'parameter request list' option. The client MAY - suggest a network address and/or lease time by including the - 'requested IP address' and 'IP address lease time' options. The - client MUST include its hardware address in the 'chaddr' field, if - necessary for delivery of DHCP reply messages. The client MAY - include a different unique identifier in the 'client identifier' - option, as discussed in section 4.2. If the client included a list - of requested parameters in a DHCPDISCOVER message, it MUST include - that list in all subsequent messages. - - The client generates and records a random transaction identifier and - inserts that identifier into the 'xid' field. The client records its - own local time for later use in computing the lease expiration. The - client then broadcasts the DHCPDISCOVER on the local hardware - broadcast address to the 0xffffffff IP broadcast address and 'DHCP - server' UDP port. - - If the 'xid' of an arriving DHCPOFFER message does not match the - 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message - must be silently discarded. Any arriving DHCPACK messages must be - silently discarded. - - The client collects DHCPOFFER messages over a period of time, selects - one DHCPOFFER message from the (possibly many) incoming DHCPOFFER - messages (e.g., the first DHCPOFFER message or the DHCPOFFER message - from the previously used server) and extracts the server address from - the 'server identifier' option in the DHCPOFFER message. The time - over which the client collects messages and the mechanism used to - select one DHCPOFFER are implementation dependent. - - - - - - - - - - - - - - - - -Droms Standards Track [Page 36] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, - DHCPINFORM DHCPRELEASE ------ ------------ ----------- ----------- -'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST -'htype' (From "Assigned Numbers" RFC) -'hlen' (Hardware address length in octets) -'hops' 0 0 0 -'xid' selected by client 'xid' from server selected by - DHCPOFFER message client -'secs' 0 or seconds since 0 or seconds since 0 - DHCP process started DHCP process started -'flags' Set 'BROADCAST' Set 'BROADCAST' 0 - flag if client flag if client - requires broadcast requires broadcast - reply reply -'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE) - client's network address client's network - network address (BOUND/RENEW/REBIND) address - (DHCPINFORM) (DHCPRELEASE) -'yiaddr' 0 0 0 -'siaddr' 0 0 0 -'giaddr' 0 0 0 -'chaddr' client's hardware client's hardware client's hardware - address address address -'sname' options, if options, if (unused) - indicated in indicated in - 'sname/file' 'sname/file' - option; otherwise option; otherwise - unused unused -'file' options, if options, if (unused) - indicated in indicated in - 'sname/file' 'sname/file' - option; otherwise option; otherwise - unused unused -'options' options options (unused) - - - - - - - - - - - - - - - - -Droms Standards Track [Page 37] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE, - DHCPINFORM DHCPRELEASE ------- ------------ ----------- ----------- -Requested IP address MAY MUST (in MUST - (DISCOVER) SELECTING or (DHCPDECLINE), - MUST NOT INIT-REBOOT) MUST NOT - (INFORM) MUST NOT (in (DHCPRELEASE) - BOUND or - RENEWING) -IP address lease time MAY MAY MUST NOT - (DISCOVER) - MUST NOT - (INFORM) -Use 'file'/'sname' fields MAY MAY MAY -DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/ - DHCPINFORM DHCPRELEASE -Client identifier MAY MAY MAY -Vendor class identifier MAY MAY MUST NOT -Server identifier MUST NOT MUST (after MUST - SELECTING) - MUST NOT (after - INIT-REBOOT, - BOUND, RENEWING - or REBINDING) -Parameter request list MAY MAY MUST NOT -Maximum message size MAY MAY MUST NOT -Message SHOULD NOT SHOULD NOT SHOULD -Site-specific MAY MAY MUST NOT -All others MAY MAY MUST NOT - - Table 5: Fields and options used by DHCP clients - - If the parameters are acceptable, the client records the address of - the server that supplied the parameters from the 'server identifier' - field and sends that address in the 'server identifier' field of a - DHCPREQUEST broadcast message. Once the DHCPACK message from the - server arrives, the client is initialized and moves to BOUND state. - The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER - message. The client records the lease expiration time as the sum of - the time at which the original request was sent and the duration of - the lease from the DHCPACK message. The client SHOULD perform a - check on the suggested address to ensure that the address is not - already in use. For example, if the client is on a network that - supports ARP, the client may issue an ARP request for the suggested - request. When broadcasting an ARP request for the suggested address, - the client must fill in its own hardware address as the sender's - hardware address, and 0 as the sender's IP address, to avoid - confusing ARP caches in other hosts on the same subnet. If the - - - -Droms Standards Track [Page 38] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - network address appears to be in use, the client MUST send a - DHCPDECLINE message to the server. The client SHOULD broadcast an ARP - reply to announce the client's new IP address and clear any outdated - ARP cache entries in hosts on the client's subnet. - -4.4.2 Initialization with known network address - - The client begins in INIT-REBOOT state and sends a DHCPREQUEST - message. The client MUST insert its known network address as a - 'requested IP address' option in the DHCPREQUEST message. The client - may request specific configuration parameters by including the - 'parameter request list' option. The client generates and records a - random transaction identifier and inserts that identifier into the - 'xid' field. The client records its own local time for later use in - computing the lease expiration. The client MUST NOT include a - 'server identifier' in the DHCPREQUEST message. The client then - broadcasts the DHCPREQUEST on the local hardware broadcast address to - the 'DHCP server' UDP port. - - Once a DHCPACK message with an 'xid' field matching that in the - client's DHCPREQUEST message arrives from any server, the client is - initialized and moves to BOUND state. The client records the lease - expiration time as the sum of the time at which the DHCPREQUEST - message was sent and the duration of the lease from the DHCPACK - message. - -4.4.3 Initialization with an externally assigned network address - - The client sends a DHCPINFORM message. The client may request - specific configuration parameters by including the 'parameter request - list' option. The client generates and records a random transaction - identifier and inserts that identifier into the 'xid' field. The - client places its own network address in the 'ciaddr' field. The - client SHOULD NOT request lease time parameters. - - The client then unicasts the DHCPINFORM to the DHCP server if it - knows the server's address, otherwise it broadcasts the message to - the limited (all 1s) broadcast address. DHCPINFORM messages MUST be - directed to the 'DHCP server' UDP port. - - Once a DHCPACK message with an 'xid' field matching that in the - client's DHCPINFORM message arrives from any server, the client is - initialized. - - If the client does not receive a DHCPACK within a reasonable period - of time (60 seconds or 4 tries if using timeout suggested in section - 4.1), then it SHOULD display a message informing the user of the - problem, and then SHOULD begin network processing using suitable - - - -Droms Standards Track [Page 39] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - defaults as per Appendix A. - -4.4.4 Use of broadcast and unicast - - The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM - messages, unless the client knows the address of a DHCP server. The - client unicasts DHCPRELEASE messages to the server. Because the - client is declining the use of the IP address supplied by the server, - the client broadcasts DHCPDECLINE messages. - - When the DHCP client knows the address of a DHCP server, in either - INIT or REBOOTING state, the client may use that address in the - DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. - The client may also use unicast to send DHCPINFORM messages to a - known DHCP server. If the client receives no response to DHCP - messages sent to the IP address of a known DHCP server, the DHCP - client reverts to using the IP broadcast address. - -4.4.5 Reacquisition and expiration - - The client maintains two times, T1 and T2, that specify the times at - which the client tries to extend its lease on its network address. - T1 is the time at which the client enters the RENEWING state and - attempts to contact the server that originally issued the client's - network address. T2 is the time at which the client enters the - REBINDING state and attempts to contact any server. T1 MUST be - earlier than T2, which, in turn, MUST be earlier than the time at - which the client's lease will expire. - - To avoid the need for synchronized clocks, T1 and T2 are expressed in - options as relative times [2]. - - At time T1 the client moves to RENEWING state and sends (via unicast) - a DHCPREQUEST message to the server to extend its lease. The client - sets the 'ciaddr' field in the DHCPREQUEST to its current network - address. The client records the local time at which the DHCPREQUEST - message is sent for computation of the lease expiration time. The - client MUST NOT include a 'server identifier' in the DHCPREQUEST - message. - - Any DHCPACK messages that arrive with an 'xid' that does not match - the 'xid' of the client's DHCPREQUEST message are silently discarded. - When the client receives a DHCPACK from the server, the client - computes the lease expiration time as the sum of the time at which - the client sent the DHCPREQUEST message and the duration of the lease - in the DHCPACK message. The client has successfully reacquired its - network address, returns to BOUND state and may continue network - processing. - - - -Droms Standards Track [Page 40] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - If no DHCPACK arrives before time T2, the client moves to REBINDING - state and sends (via broadcast) a DHCPREQUEST message to extend its - lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its - current network address. The client MUST NOT include a 'server - identifier' in the DHCPREQUEST message. - - Times T1 and T2 are configurable by the server through options. T1 - defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * - duration_of_lease). Times T1 and T2 SHOULD be chosen with some - random "fuzz" around a fixed value, to avoid synchronization of - client reacquisition. - - A client MAY choose to renew or extend its lease prior to T1. The - server MAY choose to extend the client's lease according to policy - set by the network administrator. The server SHOULD return T1 and - T2, and their values SHOULD be adjusted from their original values to - take account of the time remaining on the lease. - - In both RENEWING and REBINDING states, if the client receives no - response to its DHCPREQUEST message, the client SHOULD wait one-half - of the remaining time until T2 (in RENEWING state) and one-half of - the remaining lease time (in REBINDING state), down to a minimum of - 60 seconds, before retransmitting the DHCPREQUEST message. - - If the lease expires before the client receives a DHCPACK, the client - moves to INIT state, MUST immediately stop any other network - processing and requests network initialization parameters as if the - client were uninitialized. If the client then receives a DHCPACK - allocating that client its previous network address, the client - SHOULD continue network processing. If the client is given a new - network address, it MUST NOT continue using the previous network - address and SHOULD notify the local users of the problem. - -4.4.6 DHCPRELEASE - - If the client no longer requires use of its assigned network address - (e.g., the client is gracefully shut down), the client sends a - DHCPRELEASE message to the server. Note that the correct operation - of DHCP does not depend on the transmission of DHCPRELEASE messages. - - - - - - - - - - - - -Droms Standards Track [Page 41] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -5. Acknowledgments - - The author thanks the many (and too numerous to mention!) members of - the DHC WG for their tireless and ongoing efforts in the development - of DHCP and this document. - - The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John - Mendonca in organizing DHCP interoperability testing sessions are - gratefully acknowledged. - - The development of this document was supported in part by grants from - the Corporation for National Research Initiatives (CNRI), Bucknell - University and Sun Microsystems. - -6. References - - [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December - 1983. - - [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 1533, Lachman Technology, Inc., Bucknell - University, October 1993. - - [3] Braden, R., Editor, "Requirements for Internet Hosts -- - Communication Layers", STD 3, RFC 1122, USC/Information Sciences - Institute, October 1989. - - [4] Braden, R., Editor, "Requirements for Internet Hosts -- - Application and Support, STD 3, RFC 1123, USC/Information - Sciences Institute, October 1989. - - [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol - (DRARP)", Work in Progress. - - [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory - Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer - Communications Review), 20(4):50--59, 1990. - - [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, - Stanford and SUN Microsystems, September 1985. - - [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox - PARC, September 1991. - - [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, - Bucknell University, October 1993. - - - - - -Droms Standards Track [Page 42] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse - Address Resolution Protocol", RFC 903, Stanford, June 1984. - - [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant - Mechanism for Distributed File Cache Consistency", In Proc. of - the Twelfth ACM Symposium on Operating Systems Design, 1989. - - [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - - [13] Mockapetris, P., "Domain Names -- Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, - November 1990. - - [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached - Hosts", Work in Progress. - - [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, - USC/Information Sciences Institute, September 1981. - - [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, - USC/Information Sciences Institute, August 1993. - - [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, - USC/Information Sciences Institute, October 1994. - - [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic - Assignment of IP Addresses for use on an Ethernet. (Available - from the Athena Project, MIT), 1989. - - [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, - June 1981. - - [21] Wimer, W., "Clarifications and Extensions for the Bootstrap - Protocol", RFC 1542, Carnegie Mellon University, October 1993. - -7. Security Considerations - - DHCP is built directly on UDP and IP which are as yet inherently - insecure. Furthermore, DHCP is generally intended to make - maintenance of remote and/or diskless hosts easier. While perhaps - not impossible, configuring such hosts with passwords or keys may be - difficult and inconvenient. Therefore, DHCP in its current form is - quite insecure. - - - - -Droms Standards Track [Page 43] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - - Unauthorized DHCP servers may be easily set up. Such servers can - then send false and potentially disruptive information to clients - such as incorrect or duplicate IP addresses, incorrect routing - information (including spoof routers, etc.), incorrect domain - nameserver addresses (such as spoof nameservers), and so on. - Clearly, once this seed information is in place, an attacker can - further compromise affected systems. - - Malicious DHCP clients could masquerade as legitimate clients and - retrieve information intended for those legitimate clients. Where - dynamic allocation of resources is used, a malicious client could - claim all resources for itself, thereby denying resources to - legitimate clients. - -8. Author's Address - - Ralph Droms - Computer Science Department - 323 Dana Engineering - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms Standards Track [Page 44] - -RFC 2131 Dynamic Host Configuration Protocol March 1997 - - -A. Host Configuration Parameters - - IP-layer_parameters,_per_host:_ - - Be a router on/off HRC 3.1 - Non-local source routing on/off HRC 3.3.5 - Policy filters for - non-local source routing (list) HRC 3.3.5 - Maximum reassembly size integer HRC 3.3.2 - Default TTL integer HRC 3.2.1.7 - PMTU aging timeout integer MTU 6.6 - MTU plateau table (list) MTU 7 - IP-layer_parameters,_per_interface:_ - IP address (address) HRC 3.3.1.6 - Subnet mask (address mask) HRC 3.3.1.6 - MTU integer HRC 3.3.3 - All-subnets-MTU on/off HRC 3.3.3 - Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6 - Perform mask discovery on/off HRC 3.2.2.9 - Be a mask supplier on/off HRC 3.2.2.9 - Perform router discovery on/off RD 5.1 - Router solicitation address (address) RD 5.1 - Default routers, list of: - router address (address) HRC 3.3.1.6 - preference level integer HRC 3.3.1.6 - Static routes, list of: - destination (host/subnet/net) HRC 3.3.1.2 - destination mask (address mask) HRC 3.3.1.2 - type-of-service integer HRC 3.3.1.2 - first-hop router (address) HRC 3.3.1.2 - ignore redirects on/off HRC 3.3.1.2 - PMTU integer MTU 6.6 - perform PMTU discovery on/off MTU 6.6 - - Link-layer_parameters,_per_interface:_ - Trailers on/off HRC 2.3.1 - ARP cache timeout integer HRC 2.3.2.1 - Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3 - - TCP_parameters,_per_host:_ - TTL integer HRC 4.2.2.19 - Keep-alive interval integer HRC 4.2.3.6 - Keep-alive data size 0/1 HRC 4.2.3.6 - -Key: - - MTU = Path MTU Discovery (RFC 1191, Proposed Standard) - RD = Router Discovery (RFC 1256, Proposed Standard) - - - -Droms Standards Track [Page 45] - diff --git a/doc/rfc2132.txt b/doc/rfc2132.txt deleted file mode 100644 index e9c4f4b3..00000000 --- a/doc/rfc2132.txt +++ /dev/null @@ -1,1907 +0,0 @@ - - - - - - -Network Working Group S. Alexander -Request for Comments: 2132 Silicon Graphics, Inc. -Obsoletes: 1533 R. Droms -Category: Standards Track Bucknell University - March 1997 - - DHCP Options and BOOTP Vendor Extensions - -Status of this memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) [1] provides a - framework for passing configuration information to hosts on a TCP/IP - network. Configuration parameters and other control information are - carried in tagged data items that are stored in the 'options' field - of the DHCP message. The data items themselves are also called - "options." - - This document specifies the current set of DHCP options. Future - options will be specified in separate RFCs. The current list of - valid options is also available in ftp://ftp.isi.edu/in- - notes/iana/assignments [22]. - - All of the vendor information extensions defined in RFC 1497 [2] may - be used as DHCP options. The definitions given in RFC 1497 are - included in this document, which supersedes RFC 1497. All of the - DHCP options defined in this document, except for those specific to - DHCP as defined in section 9, may be used as BOOTP vendor information - extensions. - -Table of Contents - - 1. Introduction .............................................. 2 - 2. BOOTP Extension/DHCP Option Field Format .................. 4 - 3. RFC 1497 Vendor Extensions ................................ 5 - 4. IP Layer Parameters per Host .............................. 11 - 5. IP Layer Parameters per Interface ........................ 13 - 6. Link Layer Parameters per Interface ....................... 16 - 7. TCP Parameters ............................................ 17 - 8. Application and Service Parameters ........................ 18 - 9. DHCP Extensions ........................................... 25 - - - -Alexander & Droms Standards Track [Page 1] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - 10. Defining new extensions ................................... 31 - 11. Acknowledgements .......................................... 31 - 12. References ................................................ 32 - 13. Security Considerations ................................... 33 - 14. Authors' Addresses ........................................ 34 - -1. Introduction - - This document specifies options for use with both the Dynamic Host - Configuration Protocol and the Bootstrap Protocol. - - The full description of DHCP packet formats may be found in the DHCP - specification document [1], and the full description of BOOTP packet - formats may be found in the BOOTP specification document [3]. This - document defines the format of information in the last field of DHCP - packets ('options') and of BOOTP packets ('vend'). The remainder of - this section defines a generalized use of this area for giving - information useful to a wide class of machines, operating systems and - configurations. Sites with a single DHCP or BOOTP server that is - shared among heterogeneous clients may choose to define other, site- - specific formats for the use of the 'options' field. - - Section 2 of this memo describes the formats of DHCP options and - BOOTP vendor extensions. Section 3 describes options defined in - previous documents for use with BOOTP (all may also be used with - DHCP). Sections 4-8 define new options intended for use with both - DHCP and BOOTP. Section 9 defines options used only in DHCP. - - References further describing most of the options defined in sections - 2-6 can be found in section 12. The use of the options defined in - section 9 is described in the DHCP specification [1]. - - Information on registering new options is contained in section 10. - - This document updates the definition of DHCP/BOOTP options that - appears in RFC1533. The classing mechanism has been extended to - include vendor classes as described in section 8.4 and 9.13. The new - procedure for defining new DHCP/BOOTP options in described in section - 10. Several new options, including NIS+ domain and servers, Mobile - IP home agent, SMTP server, TFTP server and Bootfile server, have - been added. Text giving definitions used throughout the document has - been added in section 1.1. Text emphasizing the need for uniqueness - of client-identifiers has been added to section 9.14. - - - - - - - - -Alexander & Droms Standards Track [Page 2] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -1.1 Requirements - - Throughout this document, the words that are used to define the - significance of particular requirements are capitalized. These words - are: - - o "MUST" - - This word or the adjective "REQUIRED" means that the item is an - absolute requirement of this specification. - - o "MUST NOT" - - This phrase means that the item is an absolute prohibition of - this specification. - - o "SHOULD" - - This word or the adjective "RECOMMENDED" means that there may - exist valid reasons in particular circumstances to ignore this - item, but the full implications should be understood and the case - carefully weighed before choosing a different course. - - o "SHOULD NOT" - - This phrase means that there may exist valid reasons in - particular circumstances when the listed behavior is acceptable - or even useful, but the full implications should be understood - and the case carefully weighed before implementing any behavior - described with this label. - - o "MAY" - - This word or the adjective "OPTIONAL" means that this item is - truly optional. One vendor may choose to include the item - because a particular marketplace requires it or because it - enhances the product, for example; another vendor may omit the - same item. - -1.2 Terminology - - This document uses the following terms: - - o "DHCP client" - - A DHCP client or "client" is an Internet host using DHCP to - obtain configuration parameters such as a network address. - - - - -Alexander & Droms Standards Track [Page 3] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - o "DHCP server" - - A DHCP server of "server"is an Internet host that returns - configuration parameters to DHCP clients. - - o "binding" - - A binding is a collection of configuration parameters, including - at least an IP address, associated with or "bound to" a DHCP - client. Bindings are managed by DHCP servers. - -2. BOOTP Extension/DHCP Option Field Format - - - DHCP options have the same format as the BOOTP 'vendor extensions' - defined in RFC 1497 [2]. Options may be fixed length or variable - length. All options begin with a tag octet, which uniquely - identifies the option. Fixed-length options without data consist of - only a tag octet. Only options 0 and 255 are fixed length. All - other options are variable-length with a length octet following the - tag octet. The value of the length octet does not include the two - octets specifying the tag and length. The length octet is followed - by "length" octets of data. Options containing NVT ASCII data SHOULD - NOT include a trailing NULL; however, the receiver of such options - MUST be prepared to delete trailing nulls if they exist. The - receiver MUST NOT require that a trailing null be included in the - data. In the case of some variable-length options the length field - is a constant but must still be specified. - - Any options defined subsequent to this document MUST contain a length - octet even if the length is fixed or zero. - - All multi-octet quantities are in network byte-order. - - When used with BOOTP, the first four octets of the vendor information - field have been assigned to the "magic cookie" (as suggested in RFC - 951). This field identifies the mode in which the succeeding data is - to be interpreted. The value of the magic cookie is the 4 octet - dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in - network byte order. - - All of the "vendor extensions" defined in RFC 1497 are also DHCP - options. - - Option codes 128 to 254 (decimal) are reserved for site-specific - options. - - - - - -Alexander & Droms Standards Track [Page 4] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Except for the options in section 9, all options may be used with - either DHCP or BOOTP. - - Many of these options have their default values specified in other - documents. In particular, RFC 1122 [4] specifies default values for - most IP and TCP configuration parameters. - - Many options supply one or more 32-bit IP address. Use of IP - addresses rather than fully-qualified Domain Names (FQDNs) may make - future renumbering of IP hosts more difficult. Use of these - addresses is discouraged at sites that may require renumbering. - -3. RFC 1497 Vendor Extensions - - This section lists the vendor extensions as defined in RFC 1497. - They are defined here for completeness. - -3.1. Pad Option - - The pad option can be used to cause subsequent fields to align on - word boundaries. - - The code for the pad option is 0, and its length is 1 octet. - - Code - +-----+ - | 0 | - +-----+ - -3.2. End Option - - The end option marks the end of valid information in the vendor - field. Subsequent octets should be filled with pad options. - - The code for the end option is 255, and its length is 1 octet. - - Code - +-----+ - | 255 | - +-----+ - -3.3. Subnet Mask - - The subnet mask option specifies the client's subnet mask as per RFC - 950 [5]. - - If both the subnet mask and the router option are specified in a DHCP - reply, the subnet mask option MUST be first. - - - -Alexander & Droms Standards Track [Page 5] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for the subnet mask option is 1, and its length is 4 octets. - - Code Len Subnet Mask - +-----+-----+-----+-----+-----+-----+ - | 1 | 4 | m1 | m2 | m3 | m4 | - +-----+-----+-----+-----+-----+-----+ - -3.4. Time Offset - - The time offset field specifies the offset of the client's subnet in - seconds from Coordinated Universal Time (UTC). The offset is - expressed as a two's complement 32-bit integer. A positive offset - indicates a location east of the zero meridian and a negative offset - indicates a location west of the zero meridian. - - The code for the time offset option is 2, and its length is 4 octets. - - Code Len Time Offset - +-----+-----+-----+-----+-----+-----+ - | 2 | 4 | n1 | n2 | n3 | n4 | - +-----+-----+-----+-----+-----+-----+ - -3.5. Router Option - - The router option specifies a list of IP addresses for routers on the - client's subnet. Routers SHOULD be listed in order of preference. - - The code for the router option is 3. The minimum length for the - router option is 4 octets, and the length MUST always be a multiple - of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.6. Time Server Option - - The time server option specifies a list of RFC 868 [6] time servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for the time server option is 4. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - - - - - -Alexander & Droms Standards Track [Page 6] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.7. Name Server Option - - The name server option specifies a list of IEN 116 [7] name servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for the name server option is 5. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.8. Domain Name Server Option - - The domain name server option specifies a list of Domain Name System - (STD 13, RFC 1035 [8]) name servers available to the client. Servers - SHOULD be listed in order of preference. - - The code for the domain name server option is 6. The minimum length - for this option is 4 octets, and the length MUST always be a multiple - of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.9. Log Server Option - - The log server option specifies a list of MIT-LCS UDP log servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for the log server option is 7. The minimum length for this - option is 4 octets, and the length MUST always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - - - -Alexander & Droms Standards Track [Page 7] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -3.10. Cookie Server Option - - The cookie server option specifies a list of RFC 865 [9] cookie - servers available to the client. Servers SHOULD be listed in order - of preference. - - The code for the log server option is 8. The minimum length for this - option is 4 octets, and the length MUST always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.11. LPR Server Option - - The LPR server option specifies a list of RFC 1179 [10] line printer - servers available to the client. Servers SHOULD be listed in order - of preference. - - The code for the LPR server option is 9. The minimum length for this - option is 4 octets, and the length MUST always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.12. Impress Server Option - - The Impress server option specifies a list of Imagen Impress servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for the Impress server option is 10. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.13. Resource Location Server Option - - This option specifies a list of RFC 887 [11] Resource Location - servers available to the client. Servers SHOULD be listed in order - of preference. - - - -Alexander & Droms Standards Track [Page 8] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for this option is 11. The minimum length for this option - is 4 octets, and the length MUST always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.14. Host Name Option - - This option specifies the name of the client. The name may or may - not be qualified with the local domain name (see section 3.17 for the - preferred way to retrieve the domain name). See RFC 1035 for - character set restrictions. - - The code for this option is 12, and its minimum length is 1. - - Code Len Host Name - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -3.15. Boot File Size Option - - This option specifies the length in 512-octet blocks of the default - boot image for the client. The file length is specified as an - unsigned 16-bit integer. - - The code for this option is 13, and its length is 2. - - Code Len File Size - +-----+-----+-----+-----+ - | 13 | 2 | l1 | l2 | - +-----+-----+-----+-----+ - -3.16. Merit Dump File - - This option specifies the path-name of a file to which the client's - core image should be dumped in the event the client crashes. The - path is formatted as a character string consisting of characters from - the NVT ASCII character set. - - The code for this option is 14. Its minimum length is 1. - - Code Len Dump File Pathname - +-----+-----+-----+-----+-----+-----+--- - | 14 | n | n1 | n2 | n3 | n4 | ... - +-----+-----+-----+-----+-----+-----+--- - - - -Alexander & Droms Standards Track [Page 9] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -3.17. Domain Name - - This option specifies the domain name that client should use when - resolving hostnames via the Domain Name System. - - The code for this option is 15. Its minimum length is 1. - - Code Len Domain Name - +-----+-----+-----+-----+-----+-----+-- - | 15 | n | d1 | d2 | d3 | d4 | ... - +-----+-----+-----+-----+-----+-----+-- - -3.18. Swap Server - - This specifies the IP address of the client's swap server. - - The code for this option is 16 and its length is 4. - - Code Len Swap Server Address - +-----+-----+-----+-----+-----+-----+ - | 16 | n | a1 | a2 | a3 | a4 | - +-----+-----+-----+-----+-----+-----+ - -3.19. Root Path - - This option specifies the path-name that contains the client's root - disk. The path is formatted as a character string consisting of - characters from the NVT ASCII character set. - - The code for this option is 17. Its minimum length is 1. - - Code Len Root Disk Pathname - +-----+-----+-----+-----+-----+-----+--- - | 17 | n | n1 | n2 | n3 | n4 | ... - +-----+-----+-----+-----+-----+-----+--- - -3.20. Extensions Path - - A string to specify a file, retrievable via TFTP, which contains - information which can be interpreted in the same way as the 64-octet - vendor-extension field within the BOOTP response, with the following - exceptions: - - - the length of the file is unconstrained; - - all references to Tag 18 (i.e., instances of the - BOOTP Extensions Path field) within the file are - ignored. - - - - -Alexander & Droms Standards Track [Page 10] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for this option is 18. Its minimum length is 1. - - Code Len Extensions Pathname - +-----+-----+-----+-----+-----+-----+--- - | 18 | n | n1 | n2 | n3 | n4 | ... - +-----+-----+-----+-----+-----+-----+--- - -4. IP Layer Parameters per Host - - This section details the options that affect the operation of the IP - layer on a per-host basis. - -4.1. IP Forwarding Enable/Disable Option - - This option specifies whether the client should configure its IP - layer for packet forwarding. A value of 0 means disable IP - forwarding, and a value of 1 means enable IP forwarding. - - The code for this option is 19, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 19 | 1 | 0/1 | - +-----+-----+-----+ - -4.2. Non-Local Source Routing Enable/Disable Option - - This option specifies whether the client should configure its IP - layer to allow forwarding of datagrams with non-local source routes - (see Section 3.3.5 of [4] for a discussion of this topic). A value - of 0 means disallow forwarding of such datagrams, and a value of 1 - means allow forwarding. - - The code for this option is 20, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 20 | 1 | 0/1 | - +-----+-----+-----+ - -4.3. Policy Filter Option - - This option specifies policy filters for non-local source routing. - The filters consist of a list of IP addresses and masks which specify - destination/mask pairs with which to filter incoming source routes. - - Any source routed datagram whose next-hop address does not match one - of the filters should be discarded by the client. - - - -Alexander & Droms Standards Track [Page 11] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - See [4] for further information. - - The code for this option is 21. The minimum length of this option is - 8, and the length MUST be a multiple of 8. - - Code Len Address 1 Mask 1 - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - | 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - Address 2 Mask 2 - +-----+-----+-----+-----+-----+-----+-----+-----+--- - | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+--- - -4.4. Maximum Datagram Reassembly Size - - This option specifies the maximum size datagram that the client - should be prepared to reassemble. The size is specified as a 16-bit - unsigned integer. The minimum value legal value is 576. - - The code for this option is 22, and its length is 2. - - Code Len Size - +-----+-----+-----+-----+ - | 22 | 2 | s1 | s2 | - +-----+-----+-----+-----+ - -4.5. Default IP Time-to-live - - This option specifies the default time-to-live that the client should - use on outgoing datagrams. The TTL is specified as an octet with a - value between 1 and 255. - - The code for this option is 23, and its length is 1. - - Code Len TTL - +-----+-----+-----+ - | 23 | 1 | ttl | - +-----+-----+-----+ - -4.6. Path MTU Aging Timeout Option - - This option specifies the timeout (in seconds) to use when aging Path - MTU values discovered by the mechanism defined in RFC 1191 [12]. The - timeout is specified as a 32-bit unsigned integer. - - The code for this option is 24, and its length is 4. - - - - -Alexander & Droms Standards Track [Page 12] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Code Len Timeout - +-----+-----+-----+-----+-----+-----+ - | 24 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+-----+-----+ - -4.7. Path MTU Plateau Table Option - - This option specifies a table of MTU sizes to use when performing - Path MTU Discovery as defined in RFC 1191. The table is formatted as - a list of 16-bit unsigned integers, ordered from smallest to largest. - The minimum MTU value cannot be smaller than 68. - - The code for this option is 25. Its minimum length is 2, and the - length MUST be a multiple of 2. - - Code Len Size 1 Size 2 - +-----+-----+-----+-----+-----+-----+--- - | 25 | n | s1 | s2 | s1 | s2 | ... - +-----+-----+-----+-----+-----+-----+--- - -5. IP Layer Parameters per Interface - - This section details the options that affect the operation of the IP - layer on a per-interface basis. It is expected that a client can - issue multiple requests, one per interface, in order to configure - interfaces with their specific parameters. - -5.1. Interface MTU Option - - This option specifies the MTU to use on this interface. The MTU is - specified as a 16-bit unsigned integer. The minimum legal value for - the MTU is 68. - - The code for this option is 26, and its length is 2. - - Code Len MTU - +-----+-----+-----+-----+ - | 26 | 2 | m1 | m2 | - +-----+-----+-----+-----+ - -5.2. All Subnets are Local Option - - This option specifies whether or not the client may assume that all - subnets of the IP network to which the client is connected use the - same MTU as the subnet of that network to which the client is - directly connected. A value of 1 indicates that all subnets share - the same MTU. A value of 0 means that the client should assume that - some subnets of the directly connected network may have smaller MTUs. - - - -Alexander & Droms Standards Track [Page 13] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for this option is 27, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 27 | 1 | 0/1 | - +-----+-----+-----+ - -5.3. Broadcast Address Option - - This option specifies the broadcast address in use on the client's - subnet. Legal values for broadcast addresses are specified in - section 3.2.1.3 of [4]. - - The code for this option is 28, and its length is 4. - - Code Len Broadcast Address - +-----+-----+-----+-----+-----+-----+ - | 28 | 4 | b1 | b2 | b3 | b4 | - +-----+-----+-----+-----+-----+-----+ - -5.4. Perform Mask Discovery Option - - This option specifies whether or not the client should perform subnet - mask discovery using ICMP. A value of 0 indicates that the client - should not perform mask discovery. A value of 1 means that the - client should perform mask discovery. - - The code for this option is 29, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 29 | 1 | 0/1 | - +-----+-----+-----+ - -5.5. Mask Supplier Option - - This option specifies whether or not the client should respond to - subnet mask requests using ICMP. A value of 0 indicates that the - client should not respond. A value of 1 means that the client should - respond. - - The code for this option is 30, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 30 | 1 | 0/1 | - +-----+-----+-----+ - - - - -Alexander & Droms Standards Track [Page 14] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -5.6. Perform Router Discovery Option - - This option specifies whether or not the client should solicit - routers using the Router Discovery mechanism defined in RFC 1256 - [13]. A value of 0 indicates that the client should not perform - router discovery. A value of 1 means that the client should perform - router discovery. - - The code for this option is 31, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 31 | 1 | 0/1 | - +-----+-----+-----+ - -5.7. Router Solicitation Address Option - - This option specifies the address to which the client should transmit - router solicitation requests. - - The code for this option is 32, and its length is 4. - - Code Len Address - +-----+-----+-----+-----+-----+-----+ - | 32 | 4 | a1 | a2 | a3 | a4 | - +-----+-----+-----+-----+-----+-----+ - -5.8. Static Route Option - - This option specifies a list of static routes that the client should - install in its routing cache. If multiple routes to the same - destination are specified, they are listed in descending order of - priority. - - The routes consist of a list of IP address pairs. The first address - is the destination address, and the second address is the router for - the destination. - - The default route (0.0.0.0) is an illegal destination for a static - route. See section 3.5 for information about the router option. - - The code for this option is 33. The minimum length of this option is - 8, and the length MUST be a multiple of 8. - - - - - - - - -Alexander & Droms Standards Track [Page 15] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Code Len Destination 1 Router 1 - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - Destination 2 Router 2 - +-----+-----+-----+-----+-----+-----+-----+-----+--- - | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+--- - -6. Link Layer Parameters per Interface - - This section lists the options that affect the operation of the data - link layer on a per-interface basis. - -6.1. Trailer Encapsulation Option - - This option specifies whether or not the client should negotiate the - use of trailers (RFC 893 [14]) when using the ARP protocol. A value - of 0 indicates that the client should not attempt to use trailers. A - value of 1 means that the client should attempt to use trailers. - - The code for this option is 34, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 34 | 1 | 0/1 | - +-----+-----+-----+ - -6.2. ARP Cache Timeout Option - - This option specifies the timeout in seconds for ARP cache entries. - The time is specified as a 32-bit unsigned integer. - - The code for this option is 35, and its length is 4. - - Code Len Time - +-----+-----+-----+-----+-----+-----+ - | 35 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+-----+-----+ - -6.3. Ethernet Encapsulation Option - - This option specifies whether or not the client should use Ethernet - Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) encapsulation - if the interface is an Ethernet. A value of 0 indicates that the - client should use RFC 894 encapsulation. A value of 1 means that the - client should use RFC 1042 encapsulation. - - - - -Alexander & Droms Standards Track [Page 16] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for this option is 36, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 36 | 1 | 0/1 | - +-----+-----+-----+ - -7. TCP Parameters - - This section lists the options that affect the operation of the TCP - layer on a per-interface basis. - -7.1. TCP Default TTL Option - - This option specifies the default TTL that the client should use when - sending TCP segments. The value is represented as an 8-bit unsigned - integer. The minimum value is 1. - - The code for this option is 37, and its length is 1. - - Code Len TTL - +-----+-----+-----+ - | 37 | 1 | n | - +-----+-----+-----+ - -7.2. TCP Keepalive Interval Option - - This option specifies the interval (in seconds) that the client TCP - should wait before sending a keepalive message on a TCP connection. - The time is specified as a 32-bit unsigned integer. A value of zero - indicates that the client should not generate keepalive messages on - connections unless specifically requested by an application. - - The code for this option is 38, and its length is 4. - - Code Len Time - +-----+-----+-----+-----+-----+-----+ - | 38 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+-----+-----+ - -7.3. TCP Keepalive Garbage Option - - This option specifies the whether or not the client should send TCP - keepalive messages with a octet of garbage for compatibility with - older implementations. A value of 0 indicates that a garbage octet - should not be sent. A value of 1 indicates that a garbage octet - should be sent. - - - - -Alexander & Droms Standards Track [Page 17] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for this option is 39, and its length is 1. - - Code Len Value - +-----+-----+-----+ - | 39 | 1 | 0/1 | - +-----+-----+-----+ - -8. Application and Service Parameters - - This section details some miscellaneous options used to configure - miscellaneous applications and services. - -8.1. Network Information Service Domain Option - - This option specifies the name of the client's NIS [17] domain. The - domain is formatted as a character string consisting of characters - from the NVT ASCII character set. - - The code for this option is 40. Its minimum length is 1. - - Code Len NIS Domain Name - +-----+-----+-----+-----+-----+-----+--- - | 40 | n | n1 | n2 | n3 | n4 | ... - +-----+-----+-----+-----+-----+-----+--- - -8.2. Network Information Servers Option - - This option specifies a list of IP addresses indicating NIS servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for this option is 41. Its minimum length is 4, and the - length MUST be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.3. Network Time Protocol Servers Option - - This option specifies a list of IP addresses indicating NTP [18] - servers available to the client. Servers SHOULD be listed in order - of preference. - - The code for this option is 42. Its minimum length is 4, and the - length MUST be a multiple of 4. - - - - -Alexander & Droms Standards Track [Page 18] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.4. Vendor Specific Information - - This option is used by clients and servers to exchange vendor- - specific information. The information is an opaque object of n - octets, presumably interpreted by vendor-specific code on the clients - and servers. The definition of this information is vendor specific. - The vendor is indicated in the vendor class identifier option. - Servers not equipped to interpret the vendor-specific information - sent by a client MUST ignore it (although it may be reported). - Clients which do not receive desired vendor-specific information - SHOULD make an attempt to operate without it, although they may do so - (and announce they are doing so) in a degraded mode. - - If a vendor potentially encodes more than one item of information in - this option, then the vendor SHOULD encode the option using - "Encapsulated vendor-specific options" as described below: - - The Encapsulated vendor-specific options field SHOULD be encoded as a - sequence of code/length/value fields of identical syntax to the DHCP - options field with the following exceptions: - - 1) There SHOULD NOT be a "magic cookie" field in the encapsulated - vendor-specific extensions field. - - 2) Codes other than 0 or 255 MAY be redefined by the vendor within - the encapsulated vendor-specific extensions field, but SHOULD - conform to the tag-length-value syntax defined in section 2. - - 3) Code 255 (END), if present, signifies the end of the - encapsulated vendor extensions, not the end of the vendor - extensions field. If no code 255 is present, then the end of - the enclosing vendor-specific information field is taken as the - end of the encapsulated vendor-specific extensions field. - - The code for this option is 43 and its minimum length is 1. - - Code Len Vendor-specific information - +-----+-----+-----+-----+--- - | 43 | n | i1 | i2 | ... - +-----+-----+-----+-----+--- - - - - - - -Alexander & Droms Standards Track [Page 19] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - When encapsulated vendor-specific extensions are used, the - information bytes 1-n have the following format: - - Code Len Data item Code Len Data item Code - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - -8.5. NetBIOS over TCP/IP Name Server Option - - The NetBIOS name server (NBNS) option specifies a list of RFC - 1001/1002 [19] [20] NBNS name servers listed in order of preference. - - The code for this option is 44. The minimum length of the option is - 4 octets, and the length must always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- - | 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- - -8.6. NetBIOS over TCP/IP Datagram Distribution Server Option - - The NetBIOS datagram distribution server (NBDD) option specifies a - list of RFC 1001/1002 NBDD servers listed in order of preference. The - code for this option is 45. The minimum length of the option is 4 - octets, and the length must always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- - | 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- - -8.7. NetBIOS over TCP/IP Node Type Option - - The NetBIOS node type option allows NetBIOS over TCP/IP clients which - are configurable to be configured as described in RFC 1001/1002. The - value is specified as a single octet which identifies the client type - as follows: - - Value Node Type - ----- --------- - 0x1 B-node - 0x2 P-node - 0x4 M-node - 0x8 H-node - - - - - -Alexander & Droms Standards Track [Page 20] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - In the above chart, the notation '0x' indicates a number in base-16 - (hexadecimal). - - The code for this option is 46. The length of this option is always - 1. - - Code Len Node Type - +-----+-----+-----------+ - | 46 | 1 | see above | - +-----+-----+-----------+ - -8.8. NetBIOS over TCP/IP Scope Option - - The NetBIOS scope option specifies the NetBIOS over TCP/IP scope - parameter for the client as specified in RFC 1001/1002. See [19], - [20], and [8] for character-set restrictions. - - The code for this option is 47. The minimum length of this option is - 1. - - Code Len NetBIOS Scope - +-----+-----+-----+-----+-----+-----+---- - | 47 | n | s1 | s2 | s3 | s4 | ... - +-----+-----+-----+-----+-----+-----+---- - -8.9. X Window System Font Server Option - - This option specifies a list of X Window System [21] Font servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for this option is 48. The minimum length of this option is - 4 octets, and the length MUST be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+--- - | 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+--- - -8.10. X Window System Display Manager Option - - This option specifies a list of IP addresses of systems that are - running the X Window System Display Manager and are available to the - client. - - Addresses SHOULD be listed in order of preference. - - - - - -Alexander & Droms Standards Track [Page 21] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for the this option is 49. The minimum length of this option - is 4, and the length MUST be a multiple of 4. - - Code Len Address 1 Address 2 - - +-----+-----+-----+-----+-----+-----+-----+-----+--- - | 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+--- - -8.11. Network Information Service+ Domain Option - - This option specifies the name of the client's NIS+ [17] domain. The - domain is formatted as a character string consisting of characters - from the NVT ASCII character set. - - The code for this option is 64. Its minimum length is 1. - - Code Len NIS Client Domain Name - +-----+-----+-----+-----+-----+-----+--- - | 64 | n | n1 | n2 | n3 | n4 | ... - +-----+-----+-----+-----+-----+-----+--- - -8.12. Network Information Service+ Servers Option - - This option specifies a list of IP addresses indicating NIS+ servers - available to the client. Servers SHOULD be listed in order of - preference. - - The code for this option is 65. Its minimum length is 4, and the - length MUST be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.13. Mobile IP Home Agent option - - This option specifies a list of IP addresses indicating mobile IP - home agents available to the client. Agents SHOULD be listed in - order of preference. - - The code for this option is 68. Its minimum length is 0 (indicating - no home agents are available) and the length MUST be a multiple of 4. - It is expected that the usual length will be four octets, containing - a single home agent's address. - - - - - -Alexander & Droms Standards Track [Page 22] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Code Len Home Agent Addresses (zero or more) - +-----+-----+-----+-----+-----+-----+-- - | 68 | n | a1 | a2 | a3 | a4 | ... - +-----+-----+-----+-----+-----+-----+-- - -8.14. Simple Mail Transport Protocol (SMTP) Server Option - - The SMTP server option specifies a list of SMTP servers available to - the client. Servers SHOULD be listed in order of preference. - - The code for the SMTP server option is 69. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.15. Post Office Protocol (POP3) Server Option - - The POP3 server option specifies a list of POP3 available to the - client. Servers SHOULD be listed in order of preference. - - The code for the POP3 server option is 70. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.16. Network News Transport Protocol (NNTP) Server Option - - The NNTP server option specifies a list of NNTP available to the - client. Servers SHOULD be listed in order of preference. - - The code for the NNTP server option is 71. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - - - - - -Alexander & Droms Standards Track [Page 23] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -8.17. Default World Wide Web (WWW) Server Option - - The WWW server option specifies a list of WWW available to the - client. Servers SHOULD be listed in order of preference. - - The code for the WWW server option is 72. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.18. Default Finger Server Option - - The Finger server option specifies a list of Finger available to the - client. Servers SHOULD be listed in order of preference. - - The code for the Finger server option is 73. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.19. Default Internet Relay Chat (IRC) Server Option - - The IRC server option specifies a list of IRC available to the - client. Servers SHOULD be listed in order of preference. - - The code for the IRC server option is 74. The minimum length for - this option is 4 octets, and the length MUST always be a multiple of - 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.20. StreetTalk Server Option - - The StreetTalk server option specifies a list of StreetTalk servers - available to the client. Servers SHOULD be listed in order of - preference. - - - - -Alexander & Droms Standards Track [Page 24] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for the StreetTalk server option is 75. The minimum length - for this option is 4 octets, and the length MUST always be a multiple - of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -8.21. StreetTalk Directory Assistance (STDA) Server Option - - The StreetTalk Directory Assistance (STDA) server option specifies a - list of STDA servers available to the client. Servers SHOULD be - listed in order of preference. - - The code for the StreetTalk Directory Assistance server option is 76. - The minimum length for this option is 4 octets, and the length MUST - always be a multiple of 4. - - Code Len Address 1 Address 2 - +-----+-----+-----+-----+-----+-----+-----+-----+-- - | 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... - +-----+-----+-----+-----+-----+-----+-----+-----+-- - -9. DHCP Extensions - - This section details the options that are specific to DHCP. - -9.1. Requested IP Address - - This option is used in a client request (DHCPDISCOVER) to allow the - client to request that a particular IP address be assigned. - - The code for this option is 50, and its length is 4. - - Code Len Address - +-----+-----+-----+-----+-----+-----+ - | 50 | 4 | a1 | a2 | a3 | a4 | - +-----+-----+-----+-----+-----+-----+ - -9.2. IP Address Lease Time - - This option is used in a client request (DHCPDISCOVER or DHCPREQUEST) - to allow the client to request a lease time for the IP address. In a - server reply (DHCPOFFER), a DHCP server uses this option to specify - the lease time it is willing to offer. - - - - - -Alexander & Droms Standards Track [Page 25] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The time is in units of seconds, and is specified as a 32-bit - unsigned integer. - - The code for this option is 51, and its length is 4. - - Code Len Lease Time - +-----+-----+-----+-----+-----+-----+ - | 51 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+-----+-----+ - -9.3. Option Overload - - This option is used to indicate that the DHCP 'sname' or 'file' - fields are being overloaded by using them to carry DHCP options. A - DHCP server inserts this option if the returned parameters will - exceed the usual space allotted for options. - - If this option is present, the client interprets the specified - additional fields after it concludes interpretation of the standard - option fields. - - The code for this option is 52, and its length is 1. Legal values - for this option are: - - Value Meaning - ----- -------- - 1 the 'file' field is used to hold options - 2 the 'sname' field is used to hold options - 3 both fields are used to hold options - - Code Len Value - +-----+-----+-----+ - | 52 | 1 |1/2/3| - +-----+-----+-----+ - -9.4 TFTP server name - - This option is used to identify a TFTP server when the 'sname' field - in the DHCP header has been used for DHCP options. - - The code for this option is 66, and its minimum length is 1. - - Code Len TFTP server - +-----+-----+-----+-----+-----+--- - | 66 | n | c1 | c2 | c3 | ... - +-----+-----+-----+-----+-----+--- - - - - - -Alexander & Droms Standards Track [Page 26] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -9.5 Bootfile name - - This option is used to identify a bootfile when the 'file' field in - the DHCP header has been used for DHCP options. - - The code for this option is 67, and its minimum length is 1. - - Code Len Bootfile name - +-----+-----+-----+-----+-----+--- - | 67 | n | c1 | c2 | c3 | ... - +-----+-----+-----+-----+-----+--- - -9.6. DHCP Message Type - - This option is used to convey the type of the DHCP message. The code - for this option is 53, and its length is 1. Legal values for this - option are: - - Value Message Type - ----- ------------ - 1 DHCPDISCOVER - 2 DHCPOFFER - 3 DHCPREQUEST - 4 DHCPDECLINE - 5 DHCPACK - 6 DHCPNAK - 7 DHCPRELEASE - 8 DHCPINFORM - - Code Len Type - +-----+-----+-----+ - | 53 | 1 | 1-9 | - +-----+-----+-----+ - -9.7. Server Identifier - - This option is used in DHCPOFFER and DHCPREQUEST messages, and may - optionally be included in the DHCPACK and DHCPNAK messages. DHCP - servers include this option in the DHCPOFFER in order to allow the - client to distinguish between lease offers. DHCP clients use the - contents of the 'server identifier' field as the destination address - for any DHCP messages unicast to the DHCP server. DHCP clients also - indicate which of several lease offers is being accepted by including - this option in a DHCPREQUEST message. - - The identifier is the IP address of the selected server. - - The code for this option is 54, and its length is 4. - - - -Alexander & Droms Standards Track [Page 27] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - Code Len Address - +-----+-----+-----+-----+-----+-----+ - | 54 | 4 | a1 | a2 | a3 | a4 | - +-----+-----+-----+-----+-----+-----+ - -9.8. Parameter Request List - - This option is used by a DHCP client to request values for specified - configuration parameters. The list of requested parameters is - specified as n octets, where each octet is a valid DHCP option code - as defined in this document. - - The client MAY list the options in order of preference. The DHCP - server is not required to return the options in the requested order, - but MUST try to insert the requested options in the order requested - by the client. - - The code for this option is 55. Its minimum length is 1. - - Code Len Option Codes - +-----+-----+-----+-----+--- - | 55 | n | c1 | c2 | ... - +-----+-----+-----+-----+--- - -9.9. Message - - This option is used by a DHCP server to provide an error message to a - DHCP client in a DHCPNAK message in the event of a failure. A client - may use this option in a DHCPDECLINE message to indicate the why the - client declined the offered parameters. The message consists of n - octets of NVT ASCII text, which the client may display on an - available output device. - - The code for this option is 56 and its minimum length is 1. - - Code Len Text - +-----+-----+-----+-----+--- - | 56 | n | c1 | c2 | ... - +-----+-----+-----+-----+--- - -9.10. Maximum DHCP Message Size - - This option specifies the maximum length DHCP message that it is - willing to accept. The length is specified as an unsigned 16-bit - integer. A client may use the maximum DHCP message size option in - DHCPDISCOVER or DHCPREQUEST messages, but should not use the option - in DHCPDECLINE messages. - - - - -Alexander & Droms Standards Track [Page 28] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The code for this option is 57, and its length is 2. The minimum - legal value is 576 octets. - - Code Len Length - +-----+-----+-----+-----+ - | 57 | 2 | l1 | l2 | - +-----+-----+-----+-----+ - -9.11. Renewal (T1) Time Value - - This option specifies the time interval from address assignment until - the client transitions to the RENEWING state. - - The value is in units of seconds, and is specified as a 32-bit - unsigned integer. - - The code for this option is 58, and its length is 4. - - Code Len T1 Interval - +-----+-----+-----+-----+-----+-----+ - | 58 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+-----+-----+ - -9.12. Rebinding (T2) Time Value - - This option specifies the time interval from address assignment until - the client transitions to the REBINDING state. - - The value is in units of seconds, and is specified as a 32-bit - unsigned integer. - - The code for this option is 59, and its length is 4. - - Code Len T2 Interval - +-----+-----+-----+-----+-----+-----+ - | 59 | 4 | t1 | t2 | t3 | t4 | - +-----+-----+-----+-----+-----+-----+ - -9.13. Vendor class identifier - - This option is used by DHCP clients to optionally identify the vendor - type and configuration of a DHCP client. The information is a string - of n octets, interpreted by servers. Vendors may choose to define - specific vendor class identifiers to convey particular configuration - or other identification information about a client. For example, the - identifier may encode the client's hardware configuration. Servers - not equipped to interpret the class-specific information sent by a - client MUST ignore it (although it may be reported). Servers that - - - -Alexander & Droms Standards Track [Page 29] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - respond SHOULD only use option 43 to return the vendor-specific - information to the client. - - The code for this option is 60, and its minimum length is 1. - - Code Len Vendor class Identifier - +-----+-----+-----+-----+--- - | 60 | n | i1 | i2 | ... - +-----+-----+-----+-----+--- - -9.14. Client-identifier - - This option is used by DHCP clients to specify their unique - identifier. DHCP servers use this value to index their database of - address bindings. This value is expected to be unique for all - clients in an administrative domain. - - Identifiers SHOULD be treated as opaque objects by DHCP servers. - - The client identifier MAY consist of type-value pairs similar to the - 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist - of a hardware type and hardware address. In this case the type field - SHOULD be one of the ARP hardware types defined in STD2 [22]. A - hardware type of 0 (zero) should be used when the value field - contains an identifier other than a hardware address (e.g. a fully - qualified domain name). - - For correct identification of clients, each client's client- - identifier MUST be unique among the client-identifiers used on the - subnet to which the client is attached. Vendors and system - administrators are responsible for choosing client-identifiers that - meet this requirement for uniqueness. - - The code for this option is 61, and its minimum length is 2. - - Code Len Type Client-Identifier - +-----+-----+-----+-----+-----+--- - | 61 | n | t1 | i1 | i2 | ... - +-----+-----+-----+-----+-----+--- - - - - - - - - - - - - -Alexander & Droms Standards Track [Page 30] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -10. Defining new extensions - - The author of a new DHCP option will follow these steps to obtain - acceptance of the option as a part of the DHCP Internet Standard: - - 1. The author devises the new option. - 2. The author requests a number for the new option from IANA by - contacting: - Internet Assigned Numbers Authority (IANA) - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, California 90292-6695 - - or by email as: iana@iana.org - - 3. The author documents the new option, using the newly obtained - option number, as an Internet Draft. - 4. The author submits the Internet Draft for review through the IETF - standards process as defined in "Internet Official Protocol - Standards" (STD 1). The new option will be submitted for eventual - acceptance as an Internet Standard. - 5. The new option progresses through the IETF standards process; the - new option will be reviewed by the Dynamic Host Configuration - Working Group (if that group still exists), or as an Internet - Draft not submitted by an IETF working group. - 6. If the new option fails to gain acceptance as an Internet - Standard, the assigned option number will be returned to IANA for - reassignment. - - This procedure for defining new extensions will ensure that: - - * allocation of new option numbers is coordinated from a single - authority, - * new options are reviewed for technical correctness and - appropriateness, and - * documentation for new options is complete and published. - -11. Acknowledgements - - The author thanks the many (and too numerous to mention!) members of - the DHC WG for their tireless and ongoing efforts in the development - of DHCP and this document. - - The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John - Mendonca in organizing DHCP interoperability testing sessions are - gratefully acknowledged. - - - - - -Alexander & Droms Standards Track [Page 31] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - The development of this document was supported in part by grants from - the Corporation for National Research Initiatives (CNRI), Bucknell - University and Sun Microsystems. - -12. References - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - Bucknell University, March 1997. - - [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, - USC/Information Sciences Institute, August 1993. - - [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951, - Stanford University and Sun Microsystems, September 1985. - - [4] Braden, R., Editor, "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, USC/Information Sciences - Institute, October 1989. - - [5] Mogul, J., and J. Postel, "Internet Standard Subnetting - Procedure", STD 5, RFC 950, USC/Information Sciences Institute, - August 1985. - - [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC - 868, USC/Information Sciences Institute, SRI, May 1983. - - [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences - Institute, August 1979. - - [8] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865, - USC/Information Sciences Institute, May 1983. - - [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The - Wollongong Group, August 1990. - - [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU, - December 1983. - - [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, - DECWRL, Stanford University, November 1990. - - [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, - Xerox PARC, September 1991. - - - - -Alexander & Droms Standards Track [Page 32] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - - [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893, - U. C. Berkeley, April 1984. - - [15] Hornig, C., "Standard for the Transmission of IP Datagrams over - Ethernet Networks", RFC 894, Symbolics, April 1984. - - [16] Postel, J. and J. Reynolds, "Standard for the Transmission of - IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information - Sciences Institute, February 1988. - - [17] Sun Microsystems, "System and Network Administration", March - 1990. - - [18] Mills, D., "Internet Time Synchronization: The Network Time - Protocol", RFC 1305, UDEL, March 1992. - - [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service - on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001, - March 1987. - - [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service - on a TCP/UDP transport: Detailed Specifications", STD 19, RFC - 1002, March 1987. - - [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198, - MIT Laboratory for Computer Science, January 1991. - - [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, - USC/Information Sciences Institute, July 1992. - -13. Security Considerations - - Security issues are not discussed in this memo. - - - - - - - - - - - - - - - - - - -Alexander & Droms Standards Track [Page 33] - -RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 - - -14. Authors' Addresses - - Steve Alexander - Silicon Graphics, Inc. - 2011 N. Shoreline Boulevard - Mailstop 510 - Mountain View, CA 94043-1389 - - Phone: (415) 933-6172 - EMail: sca@engr.sgi.com - - - Ralph Droms - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Alexander & Droms Standards Track [Page 34] - diff --git a/doc/rfc2485.txt b/doc/rfc2485.txt deleted file mode 100644 index 752b03c5..00000000 --- a/doc/rfc2485.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -Network Working Group S. Drach -Request for Comments: 2485 Sun Microsystems -Category: Standards Track January 1999 - - - - DHCP Option for The Open Group's User Authentication Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - This document defines a DHCP [1] option that contains a list of - pointers to User Authentication Protocol servers that provide user - authentication services for clients that conform to The Open Group - Network Computing Client Technical Standard [2]. - -Introduction - - The Open Group Network Computing Client Technical Standard, a product - of The Open Group's Network Computing Working Group (NCWG), defines a - network computing client user authentication facility named the User - Authentication Protocol (UAP). - - UAP provides two levels of authentication, basic and secure. Basic - authentication uses the Basic Authentication mechanism defined in the - HTTP 1.1 [3] specification. Secure authentication is simply basic - authentication encapsulated in an SSLv3 [4] session. - - In both cases, a UAP client needs to obtain the IP address and port - of the UAP service. Additional path information may be required, - depending on the implementation of the service. A URL [5] is an - excellent mechanism for encapsulation of this information since many - UAP servers will be implemented as components within legacy HTTP/SSL - servers. - - - - - - -Drach Standards Track [Page 1] - -RFC 2485 DCHP Option for the Open Group's UAP January 1999 - - - Most UAP clients have no local state and are configured when booted - through DHCP. No existing DHCP option [6] has a data field that - contains a URL. Option 72 contains a list of IP addresses for WWW - servers, but it is not adequate since a port and/or path can not be - specified. Hence there is a need for an option that contains a list - of URLs. - -User Authentication Protocol Option - - This option specifies a list of URLs, each pointing to a user - authentication service that is capable of processing authentication - requests encapsulated in the User Authentication Protocol (UAP). UAP - servers can accept either HTTP 1.1 or SSLv3 connections. If the list - includes a URL that does not contain a port component, the normal - default port is assumed (i.e., port 80 for http and port 443 for - https). If the list includes a URL that does not contain a path - component, the path /uap is assumed. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Code | Length | URL list - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Code 98 - - Length The length of the data field (i.e., URL list) in - bytes. - - URL list A list of one or more URLs separated by the ASCII - space character (0x20). - -References - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [2] Technical Standard: Network Computing Client, The Open Group, - Document Number C801, October 1998. - - [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. - Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC - 2068, January 1997. - - [4] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol, - Version 3.0", Netscape Communications Corp., November 1996. - Standards Information Base, The Open Group, - http://www.db.opengroup.org/sib.htm#SSL_3. - - - -Drach Standards Track [Page 2] - -RFC 2485 DCHP Option for the Open Group's UAP January 1999 - - - [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - -Security Considerations - - DHCP currently provides no authentication or security mechanisms. - Potential exposures to attack are discussed in section 7 of the DHCP - protocol specification. - - The User Authentication Protocol does not have a means to detect - whether or not the client is communicating with a rogue - authentication service that the client contacted because it received - a forged or otherwise compromised UAP option from a DHCP service - whose security was compromised. Even secure authentication does not - provide relief from this type of attack. This security exposure is - mitigated by the environmental assumptions documented in the Network - Computing Client Technical Standard. - -Author's Address - - Steve Drach - Sun Microsystems, Inc. - 901 San Antonio Road - Palo Alto, CA 94303 - - Phone: (650) 960-1300 - EMail: drach@sun.com - - - - - - - - - - - - - - - - - - - - - -Drach Standards Track [Page 3] - -RFC 2485 DCHP Option for the Open Group's UAP January 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Drach Standards Track [Page 4] - diff --git a/doc/rfc2489.txt b/doc/rfc2489.txt deleted file mode 100644 index 42e066ec..00000000 --- a/doc/rfc2489.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group R. Droms -Request for Comments: 2489 Bucknell University -BCP: 29 January 1999 -Category: Best Current Practice - - - Procedure for Defining New DHCP Options - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) provides a framework - for passing configuration information to hosts on a TCP/IP network. - Configuration parameters and other control information are carried in - tagged data items that are stored in the 'options' field of the DHCP - message. The data items themselves are also called "options." - - New DHCP options may be defined after the publication of the DHCP - specification to accommodate requirements for conveyance of new - configuration parameters. This document describes the procedure for - defining new DHCP options. - -1. Introduction - - The Dynamic Host Configuration Protocol (DHCP) [1] provides a - framework for passing configuration information to hosts on a TCP/IP - network. Configuration parameters and other control information are - carried in tagged data items that are stored in the 'options' field - of the DHCP message. The data items themselves are also called - "options." [2] - - This document describes the procedure for defining new DHCP options. - The procedure will guarantee that: - - * allocation of new option numbers is coordinated from a single - authority, - * new options are reviewed for technical correctness and - appropriateness, and - * documentation for new options is complete and published. - - - -Droms Best Current Practice [Page 1] - -RFC 2489 Defining New DCHP Options January 1999 - - - As indicated in "Guidelines for Writing an IANA Considerations - Section in RFCs" (see references), IANA acts as a central authority - for assignment of numbers such as DHCP option codes. The new - procedure outlined in this document will provide guidance to IANA in - the assignment of new option codes. - -2. Overview and background - - The procedure described in this document modifies and clarifies the - procedure for defining new options in RFC 2131 [2]. The primary - modification is to the time at which a new DHCP option is assigned an - option number. In the procedure described in this document, the - option number is not assigned until specification for the option is - about to be published as an RFC. - - Since the publication of RFC 2132, the option number space for - publically defined DHCP options (1-127) has almost been exhausted. - Many of the defined option numbers have not been followed up with - Internet Drafts submitted to the DHC WG. There has been a lack of - specific guidance to IANA from the DHC WG as to the assignment of - DHCP option numbers - - The procedure as specified in RFC 2132 does not clearly state that - new options are to be reviewed individually for technical - correctness, appropriateness and complete documentation. RFC 2132 - also does not require that new options are to be submitted to the - IESG for review, and that the author of the option specification is - responsible for bringing new options to the attention of the IESG. - Finally, RFC 2132 does not make clear that newly defined options are - not to be incorporated into products, included in other - specifications or otherwise used until the specification for the - option is published as an RFC. - - In the future, new DHCP option codes will be assigned by IETF - consensus. New DHCP options will be documented in RFCs approved by - the IESG, and the codes for those options will be assigned at the - time the relevant RFCs are published. Typically, the IESG will seek - input on prospective assignments from appropriate sources (e.g., a - relevant Working Group if one exists). Groups of related options may - be combined into a single specification and reviewed as a set by the - IESG. Prior to assignment of an option code, it is not appropriate - to incorporate new options into products, include the specification - in other documents or otherwise make use of the new options. - - The DHCP option number space (1-254) is split into two parts. The - site-specific options (128-254) are defined as "Private Use" and - require no review by the DHC WG. The public options (1-127) are - - - - -Droms Best Current Practice [Page 2] - -RFC 2489 Defining New DCHP Options January 1999 - - - defined as "Specification Required" and new options must be reviewed - prior to assignment of an option number by IANA. The details of the - review process are given in the following section of this document. - -3. Procedure - - The author of a new DHCP option will follow these steps to obtain - approval for the option and publication of the specification of the - option as an RFC: - - 1. The author devises the new option. - - 2. The author documents the new option, leaving the option code as - "To Be Determined" (TBD), as an Internet Draft. - - The requirement that the new option be documented as an Internet - Draft is a matter of expediency. In theory, the new option could - be documented on the back of an envelope for submission; as a - practical matter, the specification will eventually become an - Internet Draft as part of the review process. - - 3. The author submits the Internet Draft for review by the IESG. - Preferably, the author will submit the Internet Draft to the DHC - Working Group, but the author may choose to submit the Internet - Draft directly to the IESG. - - Note that simply publishing the new option as an Internet Draft - does not automatically bring the option to the attention of the - IESG. The author of the new option must explicitly forward a - request for action on the new option to the DHC WG or the IESG. - - 4. The specification of the new option is reviewed by the IESG. The - specification is reviewed by the DHC WG (if it exists) or by the - IETF. If the option is accepted for inclusion in the DHCP - specification, the specification of the option is published as an - RFC. It may be published as either a standards-track or a non- - standards-track RFC. - - 5. At the time of publication as an RFC, IANA assigns a DHCP option - number to the new option. - -4. References - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - - -Droms Best Current Practice [Page 3] - -RFC 2489 Defining New DCHP Options January 1999 - - - [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", - RFC 2142, November 1997. - - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - -5. Security Considerations - - Information that creates or updates an option number assignment needs - to be authenticated. - - An analysis of security issues is required for all newly defined DHCP - options. The description of security issues in the specification of - new options must be as accurate as possible. The specification for a - new option may reference the "Security Considerations" section in the - DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and - Information" [3]): - - DHCP currently provides no authentication or security mechanisms. - Potential exposures to attack are discussed in section 7 of the - DHCP protocol specification [RFC 2131]. - -6. IANA Considerations - - RFC 2132 provided guidance to the IANA on the procedure it should - follow when assigning option numbers for new DHCP options. This - document updates and replaces those instructions. In particular, - IANA is requested to assign DHCP option numbers only for options that - have been approved for publication as RFCs; i.e., documents that have - been approved through "IETF consensus" as defined in RFC 2434 [4]. - -7. Author's Address - - Ralph Droms - Computer Science Department - 323 Dana Engineering - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - - - - - - - - - -Droms Best Current Practice [Page 4] - -RFC 2489 Defining New DCHP Options January 1999 - - -8. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Droms Best Current Practice [Page 5] - diff --git a/doc/rfc951.txt b/doc/rfc951.txt deleted file mode 100644 index 86cd69e6..00000000 --- a/doc/rfc951.txt +++ /dev/null @@ -1,684 +0,0 @@ - - -Network Working Group Bill Croft (Stanford University) -Request for Comments: 951 John Gilmore (Sun Microsystems) - September 1985 - - BOOTSTRAP PROTOCOL (BOOTP) - - -1. Status of this Memo - - This RFC suggests a proposed protocol for the ARPA-Internet - community, and requests discussion and suggestions for improvements. - Distribution of this memo is unlimited. - -2. Overview - - This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows - a diskless client machine to discover its own IP address, the address - of a server host, and the name of a file to be loaded into memory and - executed. The bootstrap operation can be thought of as consisting of - TWO PHASES. This RFC describes the first phase, which could be - labeled 'address determination and bootfile selection'. After this - address and filename information is obtained, control passes to the - second phase of the bootstrap where a file transfer occurs. The file - transfer will typically use the TFTP protocol [9], since it is - intended that both phases reside in PROM on the client. However - BOOTP could also work with other protocols such as SFTP [3] or - FTP [6]. - - We suggest that the client's PROM software provide a way to do a - complete bootstrap without 'user' interaction. This is the type of - boot that would occur during an unattended power-up. A mechanism - should be provided for the user to manually supply the necessary - address and filename information to bypass the BOOTP protocol and - enter the file transfer phase directly. If non-volatile storage is - available, we suggest keeping default settings there and bypassing - the BOOTP protocol unless these settings cause the file transfer - phase to fail. If the cached information fails, the bootstrap should - fall back to phase 1 and use BOOTP. - - Here is a brief outline of the protocol: - - 1. A single packet exchange is performed. Timeouts are used to - retransmit until a reply is received. The same packet field - layout is used in both directions. Fixed length fields of maximum - reasonable length are used to simplify structure definition and - parsing. - - 2. An 'opcode' field exists with two values. The client - broadcasts a 'bootrequest' packet. The server then answers with a - 'bootreply' packet. The bootrequest contains the client's - hardware address and its IP address, if known. - - -Croft & Gilmore [Page 1] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - 3. The request can optionally contain the name of the server the - client wishes to respond. This is so the client can force the - boot to occur from a specific host (e.g. if multiple versions of - the same bootfile exist or if the server is in a far distant - net/domain). The client does not have to deal with name / domain - services; instead this function is pushed off to the BOOTP server. - - 4. The request can optionally contain the 'generic' filename to be - booted. For example 'unix' or 'ethertip'. When the server sends - the bootreply, it replaces this field with the fully qualified - path name of the appropriate boot file. In determining this name, - the server may consult his own database correlating the client's - address and filename request, with a particular boot file - customized for that client. If the bootrequest filename is a null - string, then the server returns a filename field indicating the - 'default' file to be loaded for that client. - - 5. In the case of clients who do not know their IP addresses, the - server must also have a database relating hardware address to IP - address. This client IP address is then placed into a field in - the bootreply. - - 6. Certain network topologies (such as Stanford's) may be such - that a given physical cable does not have a TFTP server directly - attached to it (e.g. all the gateways and hosts on a certain cable - may be diskless). With the cooperation of neighboring gateways, - BOOTP can allow clients to boot off of servers several hops away, - through these gateways. See the section 'Booting Through - Gateways' below. This part of the protocol requires no special - action on the part of the client. Implementation is optional and - requires a small amount of additional code in gateways and - servers. - -3. Packet Format - - All numbers shown are decimal, unless indicated otherwise. The BOOTP - packet is enclosed in a standard IP [8] UDP [7] datagram. For - simplicity it is assumed that the BOOTP packet is never fragmented. - Any numeric fields shown are packed in 'standard network byte order', - i.e. high order bits are sent first. - - In the IP header of a bootrequest, the client fills in its own IP - source address if known, otherwise zero. When the server address is - unknown, the IP destination address will be the 'broadcast address' - 255.255.255.255. This address means 'broadcast on the local cable, - (I don't know my net number)' [4]. - - - -Croft & Gilmore [Page 2] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - The UDP header contains source and destination port numbers. The - BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) - and 'BOOTP server' (67). The client sends requests using 'BOOTP - server' as the destination port; this is usually a broadcast. The - server sends replies using 'BOOTP client' as the destination port; - depending on the kernel or driver facilities in the server, this may - or may not be a broadcast (this is explained further in the section - titled 'Chicken/Egg issues' below). The reason TWO reserved ports - are used, is to avoid 'waking up' and scheduling the BOOTP server - daemons, when a bootreply must be broadcast to a client. Since the - server and other hosts won't be listening on the 'BOOTP client' port, - any such incoming broadcasts will be filtered out at the kernel - level. We could not simply allow the client to pick a 'random' port - number for the UDP source port field; since the server reply may be - broadcast, a randomly chosen port number could confuse other hosts - that happened to be listening on that port. - - The UDP length field is set to the length of the UDP plus BOOTP - portions of the packet. The UDP checksum field can be set to zero by - the client (or server) if desired, to avoid this extra overhead in a - PROM implementation. In the 'Packet Processing' section below the - phrase '[UDP checksum.]' is used whenever the checksum might be - verified/computed. - - FIELD BYTES DESCRIPTION - ----- ----- ----------- - - op 1 packet op code / message type. - 1 = BOOTREQUEST, 2 = BOOTREPLY - - htype 1 hardware address type, - see ARP section in "Assigned Numbers" RFC. - '1' = 10mb ethernet - - hlen 1 hardware address length - (eg '6' for 10mb ethernet). - - hops 1 client sets to zero, - optionally used by gateways - in cross-gateway booting. - - xid 4 transaction ID, a random number, - used to match this boot request with the - responses it generates. - - secs 2 filled in by client, seconds elapsed since - client started trying to boot. - - -Croft & Gilmore [Page 3] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - -- 2 unused - - ciaddr 4 client IP address; - filled in by client in bootrequest if known. - - yiaddr 4 'your' (client) IP address; - filled by server if client doesn't - know its own address (ciaddr was 0). - - siaddr 4 server IP address; - returned in bootreply by server. - - giaddr 4 gateway IP address, - used in optional cross-gateway booting. - - chaddr 16 client hardware address, - filled in by client. - - sname 64 optional server host name, - null terminated string. - - file 128 boot file name, null terminated string; - 'generic' name or null in bootrequest, - fully qualified directory-path - name in bootreply. - - vend 64 optional vendor-specific area, - e.g. could be hardware type/serial on request, - or 'capability' / remote file system handle - on reply. This info may be set aside for use - by a third phase bootstrap or kernel. - -4. Chicken / Egg Issues - - How can the server send an IP datagram to the client, if the client - doesnt know its own IP address (yet)? Whenever a bootreply is being - sent, the transmitting machine performs the following operations: - - 1. If the client knows its own IP address ('ciaddr' field is - nonzero), then the IP can be sent 'as normal', since the client - will respond to ARPs [5]. - - 2. If the client does not yet know its IP address (ciaddr zero), - then the client cannot respond to ARPs sent by the transmitter of - the bootreply. There are two options: - - a. If the transmitter has the necessary kernel or driver hooks - - -Croft & Gilmore [Page 4] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - to 'manually' construct an ARP address cache entry, then it can - fill in an entry using the 'chaddr' and 'yiaddr' fields. Of - course, this entry should have a timeout on it, just like any - other entry made by the normal ARP code itself. The - transmitter of the bootreply can then simply send the bootreply - to the client's IP address. UNIX (4.2 BSD) has this - capability. - - b. If the transmitter lacks these kernel hooks, it can simply - send the bootreply to the IP broadcast address on the - appropriate interface. This is only one additional broadcast - over the previous case. - -5. Client Use of ARP - - The client PROM must contain a simple implementation of ARP, e.g. the - address cache could be just one entry in size. This will allow a - second-phase-only boot (TFTP) to be performed when the client knows - the IP addresses and bootfile name. - - Any time the client is expecting to receive a TFTP or BOOTP reply, it - should be prepared to answer an ARP request for its own IP to - hardware address mapping (if known). - - Since the bootreply will contain (in the hardware encapsulation) the - hardware source address of the server/gateway, the client MAY be able - to avoid sending an ARP request for the server/gateway IP address to - be used in the following TFTP phase. However this should be treated - only as a special case, since it is desirable to still allow a - second-phase-only boot as described above. - -6. Comparison to RARP - - An earlier protocol, Reverse Address Resolution Protocol (RARP) [1] - was proposed to allow a client to determine its IP address, given - that it knew its hardware address. However RARP had the disadvantage - that it was a hardware link level protocol (not IP/UDP based). This - means that RARP could only be implemented on hosts containing special - kernel or driver modifications to access these 'raw' packets. Since - there are many network kernels existent now, with each source - maintained by different organizations, a boot protocol that does not - require kernel modifications is a decided advantage. - - BOOTP provides this hardware to IP address lookup function, in - addition to the other useful features described in the sections - above. - - - -Croft & Gilmore [Page 5] - - - -RFC 951 September 1985 -Bootstrap Protocol - - -7. Packet Processing - - 7.1. Client Transmission - - Before setting up the packet for the first time, it is a good idea - to clear the entire packet buffer to all zeros; this will place - all fields in their default state. The client then creates a - packet with the following fields. - - The IP destination address is set to 255.255.255.255. (the - broadcast address) or to the server's IP address (if known). The - IP source address and 'ciaddr' are set to the client's IP address - if known, else 0. The UDP header is set with the proper length; - source port = 'BOOTP client' port destination port = 'BOOTP - server' port. - - 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware - address type as assigned in the ARP section of the "Assigned - Numbers" RFC. 'hlen' is set to the length of the hardware address, - e.g. '6' for 10mb ethernet. - - 'xid' is set to a 'random' transaction id. 'secs' is set to the - number of seconds that have elapsed since the client has started - booting. This will let the servers know how long a client has - been trying. As the number gets larger, certain servers may feel - more 'sympathetic' towards a client they don't normally service. - If a client lacks a suitable clock, it could construct a rough - estimate using a loop timer. Or it could choose to simply send - this field as always a fixed value, say 100 seconds. - - If the client knows its IP address, 'ciaddr' (and the IP source - address) are set to this value. 'chaddr' is filled in with the - client's hardware address. - - If the client wishes to restrict booting to a particular server - name, it may place a null-terminated string in 'sname'. The name - used should be any of the allowable names or nicknames of the - desired host. - - The client has several options for filling the 'file' name field. - If left null, the meaning is 'I want to boot the default file for - my machine'. A null file name can also mean 'I am only interested - in finding out client/server/gateway IP addresses, I dont care - about file names'. - - The field can also be a 'generic' name such as 'unix' or - - - -Croft & Gilmore [Page 6] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - 'gateway'; this means 'boot the named program configured for my - machine'. Finally the field can be a fully directory qualified - path name. - - The 'vend' field can be filled in by the client with - vendor-specific strings or structures. For example the machine - hardware type or serial number may be placed here. However the - operation of the BOOTP server should not DEPEND on this - information existing. - - If the 'vend' field is used, it is recommended that a 4 byte - 'magic number' be the first item within 'vend'. This lets a - server determine what kind of information it is seeing in this - field. Numbers can be assigned by the usual 'magic number' - process --you pick one and it's magic. A different magic number - could be used for bootreply's than bootrequest's to allow the - client to take special action with the reply information. - - [UDP checksum.] - - 7.2. Client Retransmission Strategy - - If no reply is received for a certain length of time, the client - should retransmit the request. The time interval must be chosen - carefully so as not to flood the network. Consider the case of a - cable containing 100 machines that are just coming up after a - power failure. Simply retransmitting the request every four - seconds will inundate the net. - - As a possible strategy, you might consider backing off - exponentially, similar to the way ethernet backs off on a - collision. So for example if the first packet is at time 0:00, - the second would be at :04, then :08, then :16, then :32, then - :64. You should also randomize each time; this would be done - similar to the ethernet specification by starting with a mask and - 'and'ing that with with a random number to get the first backoff. - On each succeeding backoff, the mask is increased in length by one - bit. This doubles the average delay on each backoff. - - After the 'average' backoff reaches about 60 seconds, it should be - increased no further, but still randomized. - - Before each retransmission, the client should update the 'secs' - field. [UDP checksum.] - - - - - -Croft & Gilmore [Page 7] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - 7.3. Server Receives BOOTREQUEST - - [UDP checksum.] If the UDP destination port does not match the - 'BOOTP server' port, discard the packet. - - If the server name field (sname) is null (no particular server - specified), or sname is specified and matches our name or - nickname, then continue with packet processing. - - If the sname field is specified, but does not match 'us', then - there are several options: - - 1. You may choose to simply discard this packet. - - 2. If a name lookup on sname shows it to be on this same cable, - discard the packet. - - 3. If sname is on a different net, you may choose to forward - the packet to that address. If so, check the 'giaddr' (gateway - address) field. If 'giaddr' is zero, fill it in with my - address or the address of a gateway that can be used to get to - that net. Then forward the packet. - - If the client IP address (ciaddr) is zero, then the client does - not know its own IP address. Attempt to lookup the client - hardware address (chaddr, hlen, htype) in our database. If no - match is found, discard the packet. Otherwise we now have an IP - address for this client; fill it into the 'yiaddr' (your IP - address) field. - - We now check the boot file name field (file). The field will be - null if the client is not interested in filenames, or wants the - default bootfile. If the field is non-null, it is used as a - lookup key in a database, along with the client's IP address. If - there is a default file or generic file (possibly indexed by the - client address) or a fully-specified path name that matches, then - replace the 'file' field with the fully-specified path name of the - selected boot file. If the field is non-null and no match was - found, then the client is asking for a file we dont have; discard - the packet, perhaps some other BOOTP server will have it. - - The 'vend' vendor-specific data field should now be checked and if - a recognized type of data is provided, client-specific actions - should be taken, and a response placed in the 'vend' data field of - the reply packet. For example, a workstation client could provide - - - - -Croft & Gilmore [Page 8] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - an authentication key and receive from the server a capability for - remote file access, or a set of configuration options, which can - be passed to the operating system that will shortly be booted in. - - Place my (server) IP address in the 'siaddr' field. Set the 'op' - field to BOOTREPLY. The UDP destination port is set to 'BOOTP - client'. If the client address 'ciaddr' is nonzero, send the - packet there; else if the gateway address 'giaddr' is nonzero, set - the UDP destination port to 'BOOTP server' and send the packet to - 'giaddr'; else the client is on one of our cables but it doesnt - know its own IP address yet --use a method described in the 'Egg' - section above to send it to the client. If 'Egg' is used and we - have multiple interfaces on this host, use the 'yiaddr' (your IP - address) field to figure out which net (cable/interface) to send - the packet to. [UDP checksum.] - - 7.4. Server/Gateway Receives BOOTREPLY - - [UDP checksum.] If 'yiaddr' (your [the client's] IP address) - refers to one of our cables, use one of the 'Egg' methods above to - forward it to the client. Be sure to send it to the 'BOOTP - client' UDP destination port. - - 7.5. Client Reception - - Don't forget to process ARP requests for my own IP address (if I - know it). [UDP checksum.] The client should discard incoming - packets that: are not IP/UDPs addressed to the boot port; are not - BOOTREPLYs; do not match my IP address (if I know it) or my - hardware address; do not match my transaction id. Otherwise we - have received a successful reply. 'yiaddr' will contain my IP - address, if I didnt know it before. 'file' is the name of the - file name to TFTP 'read request'. The server address is in - 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the - packets should be forwarded there first, in order to get to the - server. - -8. Booting Through Gateways - - This part of the protocol is optional and requires some additional - code in cooperating gateways and servers, but it allows cross-gateway - booting. This is mainly useful when gateways are diskless machines. - Gateways containing disks (e.g. a UNIX machine acting as a gateway), - might as well run their own BOOTP/TFTP servers. - - Gateways listening to broadcast BOOTREQUESTs may decide to forward or - rebroadcast these requests 'when appropriate'. For example, the - - -Croft & Gilmore [Page 9] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - gateway could have, as part of his configuration tables, a list of - other networks or hosts to receive a copy of any broadcast - BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea - to simply globally rebroadcast the requests, since broadcast loops - will almost certainly occur. - - The forwarding could begin immediately, or wait until the 'secs' - (seconds client has been trying) field passes a certain threshold. - - If a gateway does decide to forward the request, it should look at - the 'giaddr' (gateway IP address) field. If zero, it should plug its - own IP address (on the receiving cable) into this field. It may also - use the 'hops' field to optionally control how far the packet is - reforwarded. Hops should be incremented on each forwarding. For - example, if hops passes '3', the packet should probably be discarded. - [UDP checksum.] - - Here we have recommended placing this special forwarding function in - the gateways. But that does not have to be the case. As long as - some 'BOOTP forwarding agent' exists on the net with the booting - client, the agent can do the forwarding when appropriate. Thus this - service may or may not be co-located with the gateway. - - In the case of a forwarding agent not located in the gateway, the - agent could save himself some work by plugging the broadcast address - of the interface receiving the bootrequest into the 'giaddr' field. - Thus the reply would get forwarded using normal gateways, not - involving the forwarding agent. Of course the disadvantage here is - that you lose the ability to use the 'Egg' non-broadcast method of - sending the reply, causing extra overhead for every host on the - client cable. - -9. Sample BOOTP Server Database - - As a suggestion, we show a sample text file database that the BOOTP - server program might use. The database has two sections, delimited - by a line containing an percent in column 1. The first section - contains a 'default directory' and mappings from generic names to - directory/pathnames. The first generic name in this section is the - 'default file' you get when the bootrequest contains a null 'file' - string. - - The second section maps hardware addresstype/address into an - ipaddress. Optionally you can also overide the default generic name - by supplying a ipaddress specific genericname. A 'suffix' item is - also an option; if supplied, any generic names specified by the - client will be accessed by first appending 'suffix' to the 'pathname' - - -Croft & Gilmore [Page 10] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - appropriate to that generic name. If that file is not found, then - the plain 'pathname' will be tried. This 'suffix' option allows a - whole set of custom generics to be setup without a lot of effort. - Below is shown the general format; fields are delimited by one or - more spaces or tabs; trailing empty fields may be omitted; blank - lines and lines beginning with '#' are ignored. - - # comment line - - homedirectory - genericname1 pathname1 - genericname2 pathname2 - ... - - % end of generic names, start of address mappings - - hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix - hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix - ... - - Here is a specific example. Note the 'hardwaretype' number is the - same as that shown in the ARP section of the 'Assigned Numbers' RFC. - The 'hardwaretype' and 'ipaddr' numbers are in decimal; - 'hardwareaddr' is in hex. - - # last updated by smith - - /usr/boot - vmunix vmunix - tip ethertip - watch /usr/diag/etherwatch - gate gate. - - % end of generic names, start of address mappings - - hamilton 1 02.60.8c.06.34.98 36.19.0.5 - burr 1 02.60.8c.34.11.78 36.44.0.12 - 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101 - mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh - welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip - welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip - - In the example above, if 'mjh-gateway' does a default boot, it will - get the file '/usr/boot/gate.mjh'. - - - - - -Croft & Gilmore [Page 11] - - - -RFC 951 September 1985 -Bootstrap Protocol - - -10. Acknowledgements - - Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP - bootstraping [2] using RARP [1]. - - We would also like to acknowledge the previous work and comments of - Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer. - -REFERENCES - - 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A - Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984. - - 2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC, - June, 1984. - - 3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC, - September, 1984. - - 4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC, - October, 1984. - - 5. David Plummer. An Ethernet Address Resolution Protocol. RFC - 826, NIC, September, 1982. - - 6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980. - - 7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980. - - 8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981. - - 9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC, - June, 1981. - - - - - - - - - - - - - - - - -Croft & Gilmore [Page 12] - |