aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authordiogo464 <[email protected]>2025-10-07 10:34:12 +0100
committerdiogo464 <[email protected]>2025-10-07 10:34:12 +0100
commitc0148cb62800789e94ef41e34bee53e58fac02f2 (patch)
tree8c2c5588cb075b4ef94f6ca81f8f2e3228c1097e
parent5bf4135847954bec6b8c90ef2996439783ae8056 (diff)
split some code into modules
Diffstat
-rw-r--r--RFC 2131: Dynamic Host Configuration Protocol.html2681
-rw-r--r--src/dhcp.rs214
-rw-r--r--src/main.rs7
-rw-r--r--src/tftp.rs365
-rw-r--r--src/wire.rs81
5 files changed, 3347 insertions, 1 deletions
diff --git a/RFC 2131: Dynamic Host Configuration Protocol.html b/RFC 2131: Dynamic Host Configuration Protocol.html
new file mode 100644
index 0000000..bd3e419
--- /dev/null
+++ b/RFC 2131: Dynamic Host Configuration Protocol.html
@@ -0,0 +1,2681 @@
1
2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
4 <head>
5 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
6 <meta name="robots" content="index,follow" />
7 <meta name="creator" content="rfchandler version 0.2" />
8 <meta name="citation_author" content="R. Droms"/>
9 <meta name="citation_publication_date" content="March, 1997"/>
10 <meta name="citation_title" content=" Dynamic Host Configuration Protocol "/>
11 <meta name="citation_doi" content="10.17487/RFC2131"/>
12 <meta name="citation_issn" content="2070-1721"/>
13 <meta name="citation_technical_report_number" content="rfc2131"/>
14 <meta name="citation_pdf_url" content="https://www.rfc-editor.org/rfc/pdfrfc/rfc2131.txt.pdf"/>
15<title>RFC 2131: Dynamic Host Configuration Protocol </title>
16
17
18 <style type="text/css">
19 @media only screen
20 and (min-width: 992px)
21 and (max-width: 1199px) {
22 body { font-size: 14pt; }
23 div.content { width: 96ex; margin: 0 auto; }
24 }
25 @media only screen
26 and (min-width: 768px)
27 and (max-width: 991px) {
28 body { font-size: 14pt; }
29 div.content { width: 96ex; margin: 0 auto; }
30 }
31 @media only screen
32 and (min-width: 480px)
33 and (max-width: 767px) {
34 body { font-size: 11pt; }
35 div.content { width: 96ex; margin: 0 auto; }
36 }
37 @media only screen
38 and (max-width: 479px) {
39 body { font-size: 8pt; }
40 div.content { width: 96ex; margin: 0 auto; }
41 }
42 @media only screen
43 and (min-device-width : 375px)
44 and (max-device-width : 667px) {
45 body { font-size: 9.5pt; }
46 div.content { width: 96ex; margin: 0; }
47 }
48 @media only screen
49 and (min-device-width: 1200px) {
50 body { font-size: 10pt; margin: 0 4em; }
51 div.content { width: 96ex; margin: 0; }
52 }
53 h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
54 font-weight: bold;
55 /* line-height: 0pt; */
56 display: inline;
57 white-space: pre;
58 font-family: monospace;
59 font-size: 1em;
60 font-weight: bold;
61 }
62 pre {
63 font-size: 1em;
64 margin-top: 0px;
65 margin-bottom: 0px;
66 }
67 .pre {
68 white-space: pre;
69 font-family: monospace;
70 }
71 .header{
72 font-weight: bold;
73 }
74 .newpage {
75 page-break-before: always;
76 }
77 .invisible {
78 text-decoration: none;
79 color: white;
80 }
81 a.selflink {
82 color: black;
83 text-decoration: none;
84 }
85 @media print {
86 body {
87 font-family: monospace;
88 font-size: 10.5pt;
89 }
90 h1, h2, h3, h4, h5, h6 {
91 font-size: 1em;
92 }
93
94 a:link, a:visited {
95 color: inherit;
96 text-decoration: none;
97 }
98 .noprint {
99 display: none;
100 }
101 }
102 @media screen {
103 .grey, .grey a:link, .grey a:visited {
104 color: #777;
105 }
106 .docinfo {
107 background-color: #EEE;
108 }
109 .top {
110 border-top: 7px solid #EEE;
111 }
112 .bgwhite { background-color: white; }
113 .bgred { background-color: #F44; }
114 .bggrey { background-color: #666; }
115 .bgbrown { background-color: #840; }
116 .bgorange { background-color: #FA0; }
117 .bgyellow { background-color: #EE0; }
118 .bgmagenta{ background-color: #F4F; }
119 .bgblue { background-color: #66F; }
120 .bgcyan { background-color: #4DD; }
121 .bggreen { background-color: #4F4; }
122
123 .legend { font-size: 90%; }
124 .cplate { font-size: 70%; border: solid grey 1px; }
125 }
126 </style>
127 <!--[if IE]>
128 <style>
129 body {
130 font-size: 13px;
131 margin: 10px 10px;
132 }
133 </style>
134 <![endif]--> <script type="text/javascript"><!--
135 function addHeaderTags() {
136 var spans = document.getElementsByTagName("span");
137 for (var i=0; i < spans.length; i++) {
138 var elem = spans[i];
139 if (elem) {
140 var level = elem.getAttribute("class");
141 if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
142 elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
143 }
144 }
145 }
146 }
147 var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> </table>";
148 function showElem(id) {
149 var elem = document.getElementById(id);
150 elem.innerHTML = eval(id+"_html");
151 elem.style.visibility='visible';
152 }
153 function hideElem(id) {
154 var elem = document.getElementById(id);
155 elem.style.visibility='hidden';
156 elem.innerHTML = "";
157 }
158 // -->
159 </script></head>
160<body>
161<span class="pre noprint docinfo">[<a href="https://www.rfc-editor.org" title="RFC Editor">RFC Home</a>] [<a href="/rfc/rfc2131.txt">TEXT</a>|<a href="/rfc/pdfrfc/rfc2131.txt.pdf">PDF</a>|<a href="/rfc/rfc2131.html">HTML</a>] [<a href='https://datatracker.ietf.org/doc/rfc2131' title='IETF Datatracker information for this document'>Tracker</a>] [<a href="https://datatracker.ietf.org/ipr/search/?rfc=2131&amp;submit=rfc" title="IPR disclosures related to this document">IPR</a>] [<a class="boldtext" href="/errata/rfc2131" target="_blank">Errata</a>] [<a href='https://www.rfc-editor.org/info/rfc2131' title='Info page'>Info page</a>] </span><br/><span class="pre noprint docinfo"> </span><br /><span class="pre noprint docinfo"> DRAFT STANDARD</span><br /><span class="pre noprint docinfo">Updated by: <a href="/rfc/rfc3396" target="_blank">3396</a>, <a href="/rfc/rfc4361" target="_blank">4361</a>, <a href="/rfc/rfc5494" target="_blank">5494</a>, <a href="/rfc/rfc6842" target="_blank">6842</a> <span style='color: #C00;'>Errata Exist</span></span><pre>Network Working Group R. Droms
162Request for Comments: 2131 Bucknell University
163Obsoletes: <a href="./rfc1541">1541</a> March 1997
164Category: Standards Track
165
166 <span class="h1">Dynamic Host Configuration Protocol</span>
167
168Status of this memo
169
170 This document specifies an Internet standards track protocol for the
171 Internet community, and requests discussion and suggestions for
172 improvements. Please refer to the current edition of the "Internet
173 Official Protocol Standards" (STD 1) for the standardization state
174 and status of this protocol. Distribution of this memo is unlimited.
175
176Abstract
177
178 The Dynamic Host Configuration Protocol (DHCP) provides a framework
179 for passing configuration information to hosts on a TCPIP network.
180 DHCP is based on the Bootstrap Protocol (BOOTP) [<a href="#ref-7" title="&quot;Bootstrap Protocol (BOOTP)&quot;">7</a>], adding the
181 capability of automatic allocation of reusable network addresses and
182 additional configuration options [<a href="#ref-19" title="MIT)">19</a>]. DHCP captures the behavior of
183 BOOTP relay agents [<a href="#ref-7" title="&quot;Bootstrap Protocol (BOOTP)&quot;">7</a>, <a href="#ref-21" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">21</a>], and DHCP participants can interoperate
184 with BOOTP participants [<a href="#ref-9" title="&quot;Interoperation between DHCP and BOOTP&quot;">9</a>].
185
186Table of Contents
187
188 <a href="#section-1">1</a>. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
189 <a href="#section-1.1">1.1</a> Changes to <a href="./rfc1541">RFC1541</a>. . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
190 <a href="#section-1.2">1.2</a> Related Work. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
191 <a href="#section-1.3">1.3</a> Problem definition and issues . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
192 <a href="#section-1.4">1.4</a> Requirements. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
193 <a href="#section-1.5">1.5</a> Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
194 <a href="#section-1.6">1.6</a> Design goals. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
195 <a href="#section-2">2</a>. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
196 <a href="#section-2.1">2.1</a> Configuration parameters repository . . . . . . . . . . . . . <a href="#page-11">11</a>
197 <a href="#section-2.2">2.2</a> Dynamic allocation of network addresses . . . . . . . . . . . <a href="#page-12">12</a>
198 <a href="#section-3">3</a>. The Client-Server Protocol. . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
199 <a href="#section-3.1">3.1</a> Client-server interaction - allocating a network address. . . <a href="#page-13">13</a>
200 3.2 Client-server interaction - reusing a previously allocated
201 network address . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
202 <a href="#section-3.3">3.3</a> Interpretation and representation of time values. . . . . . . <a href="#page-20">20</a>
203 3.4 Obtaining parameters with externally configured network
204 address . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
205 <a href="#section-3.5">3.5</a> Client parameters in DHCP . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
206 <a href="#section-3.6">3.6</a> Use of DHCP in clients with multiple interfaces . . . . . . . <a href="#page-22">22</a>
207 <a href="#section-3.7">3.7</a> When clients should use DHCP. . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
208 <a href="#section-4">4</a>. Specification of the DHCP client-server protocol. . . . . . . <a href="#page-22">22</a>
209
210
211
212<span class="grey">Droms Standards Track [Page 1]</span></pre>
213<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
214<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
215
216
217 <a href="#section-4.1">4.1</a> Constructing and sending DHCP messages. . . . . . . . . . . . <a href="#page-22">22</a>
218 <a href="#section-4.2">4.2</a> DHCP server administrative controls . . . . . . . . . . . . . <a href="#page-25">25</a>
219 <a href="#section-4.3">4.3</a> DHCP server behavior. . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
220 <a href="#section-4.4">4.4</a> DHCP client behavior. . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
221 <a href="#section-5">5</a>. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-42">42</a>
222 <a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-42">42</a>
223 <a href="#section-7">7</a>. Security Considerations. . . . . . . . . . . . . . . . . . . .<a href="#page-43">43</a>
224 <a href="#section-8">8</a>. Author's Address . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-44">44</a>
225 <a href="#appendix-A">A</a>. Host Configuration Parameters . . . . . . . . . . . . . . . .<a href="#page-45">45</a>
226List of Figures
227 <a href="#section-1">1</a>. Format of a DHCP message . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
228 <a href="#section-2">2</a>. Format of the 'flags' field. . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
229 3. Timeline diagram of messages exchanged between DHCP client and
230 servers when allocating a new network address. . . . . . . . . <a href="#page-15">15</a>
231 4. Timeline diagram of messages exchanged between DHCP client and
232 servers when reusing a previously allocated network address. . <a href="#page-18">18</a>
233 <a href="#section-5">5</a>. State-transition diagram for DHCP clients. . . . . . . . . . . <a href="#page-34">34</a>
234List of Tables
235 <a href="#section-1">1</a>. Description of fields in a DHCP message. . . . . . . . . . . . <a href="#page-10">10</a>
236 <a href="#section-2">2</a>. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
237 <a href="#section-3">3</a>. Fields and options used by DHCP servers. . . . . . . . . . . . <a href="#page-28">28</a>
238 <a href="#section-4">4</a>. Client messages from various states. . . . . . . . . . . . . . <a href="#page-33">33</a>
239 <a href="#section-5">5</a>. Fields and options used by DHCP clients. . . . . . . . . . . . <a href="#page-37">37</a>
240
241<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
242
243 The Dynamic Host Configuration Protocol (DHCP) provides configuration
244 parameters to Internet hosts. DHCP consists of two components: a
245 protocol for delivering host-specific configuration parameters from a
246 DHCP server to a host and a mechanism for allocation of network
247 addresses to hosts.
248
249 DHCP is built on a client-server model, where designated DHCP server
250 hosts allocate network addresses and deliver configuration parameters
251 to dynamically configured hosts. Throughout the remainder of this
252 document, the term "server" refers to a host providing initialization
253 parameters through DHCP, and the term "client" refers to a host
254 requesting initialization parameters from a DHCP server.
255
256 A host should not act as a DHCP server unless explicitly configured
257 to do so by a system administrator. The diversity of hardware and
258 protocol implementations in the Internet would preclude reliable
259 operation if random hosts were allowed to respond to DHCP requests.
260 For example, IP requires the setting of many parameters within the
261 protocol implementation software. Because IP can be used on many
262 dissimilar kinds of network hardware, values for those parameters
263 cannot be guessed or assumed to have correct defaults. Also,
264 distributed address allocation schemes depend on a polling/defense
265
266
267
268<span class="grey">Droms Standards Track [Page 2]</span></pre>
269<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
270<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
271
272
273 mechanism for discovery of addresses that are already in use. IP
274 hosts may not always be able to defend their network addresses, so
275 that such a distributed address allocation scheme cannot be
276 guaranteed to avoid allocation of duplicate network addresses.
277
278 DHCP supports three mechanisms for IP address allocation. In
279 "automatic allocation", DHCP assigns a permanent IP address to a
280 client. In "dynamic allocation", DHCP assigns an IP address to a
281 client for a limited period of time (or until the client explicitly
282 relinquishes the address). In "manual allocation", a client's IP
283 address is assigned by the network administrator, and DHCP is used
284 simply to convey the assigned address to the client. A particular
285 network will use one or more of these mechanisms, depending on the
286 policies of the network administrator.
287
288 Dynamic allocation is the only one of the three mechanisms that
289 allows automatic reuse of an address that is no longer needed by the
290 client to which it was assigned. Thus, dynamic allocation is
291 particularly useful for assigning an address to a client that will be
292 connected to the network only temporarily or for sharing a limited
293 pool of IP addresses among a group of clients that do not need
294 permanent IP addresses. Dynamic allocation may also be a good choice
295 for assigning an IP address to a new client being permanently
296 connected to a network where IP addresses are sufficiently scarce
297 that it is important to reclaim them when old clients are retired.
298 Manual allocation allows DHCP to be used to eliminate the error-prone
299 process of manually configuring hosts with IP addresses in
300 environments where (for whatever reasons) it is desirable to manage
301 IP address assignment outside of the DHCP mechanisms.
302
303 The format of DHCP messages is based on the format of BOOTP messages,
304 to capture the BOOTP relay agent behavior described as part of the
305 BOOTP specification [<a href="#ref-7" title="&quot;Bootstrap Protocol (BOOTP)&quot;">7</a>, <a href="#ref-21" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">21</a>] and to allow interoperability of existing
306 BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
307 the necessity of having a DHCP server on each physical network
308 segment.
309
310<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Changes to <a href="./rfc1541">RFC 1541</a></span>
311
312 This document updates the DHCP protocol specification that appears in
313 <a href="./rfc1541">RFC1541</a>. A new DHCP message type, DHCPINFORM, has been added; see
314 <a href="#section-3.4">section 3.4</a>, 4.3 and 4.4 for details. The classing mechanism for
315 identifying DHCP clients to DHCP servers has been extended to include
316 "vendor" classes as defined in sections <a href="#section-4.2">4.2</a> and <a href="#section-4.3">4.3</a>. The minimum
317 lease time restriction has been removed. Finally, many editorial
318 changes have been made to clarify the text as a result of experience
319 gained in DHCP interoperability tests.
320
321
322
323
324<span class="grey">Droms Standards Track [Page 3]</span></pre>
325<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
326<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
327
328
329<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a> Related Work</span>
330
331 There are several Internet protocols and related mechanisms that
332 address some parts of the dynamic host configuration problem. The
333 Reverse Address Resolution Protocol (RARP) [<a href="#ref-10" title="&quot;A Reverse Address Resolution Protocol&quot;">10</a>] (through the
334 extensions defined in the Dynamic RARP (DRARP) [<a href="#ref-5" title="&quot;Dynamic Reverse Address Resolution Protocol (DRARP)&quot;">5</a>]) explicitly
335 addresses the problem of network address discovery, and includes an
336 automatic IP address assignment mechanism. The Trivial File Transfer
337 Protocol (TFTP) [<a href="#ref-20" title="&quot;The TFTP Protocol (Revision 2)&quot;">20</a>] provides for transport of a boot image from a
338 boot server. The Internet Control Message Protocol (ICMP) [<a href="#ref-16" title="&quot;Internet Control Message Protocol&quot;">16</a>]
339 provides for informing hosts of additional routers via "ICMP
340 redirect" messages. ICMP also can provide subnet mask information
341 through the "ICMP mask request" message and other information through
342 the (obsolete) "ICMP information request" message. Hosts can locate
343 routers through the ICMP router discovery mechanism [<a href="#ref-8" title="&quot;ICMP Router Discovery Messages&quot;">8</a>].
344
345 BOOTP is a transport mechanism for a collection of configuration
346 information. BOOTP is also extensible, and official extensions [<a href="#ref-17" title="&quot;BOOTP Vendor Information Extensions&quot;">17</a>]
347 have been defined for several configuration parameters. Morgan has
348 proposed extensions to BOOTP for dynamic IP address assignment [<a href="#ref-15" title="&quot;Dynamic IP Address Assignment for Ethernet Attached Hosts&quot;">15</a>].
349 The Network Information Protocol (NIP), used by the Athena project at
350 MIT, is a distributed mechanism for dynamic IP address assignment
351 [<a href="#ref-19" title="MIT)">19</a>]. The Resource Location Protocol RLP [<a href="#ref-1" title="&quot;Resource Location Protocol&quot;">1</a>] provides for location
352 of higher level services. Sun Microsystems diskless workstations use
353 a boot procedure that employs RARP, TFTP and an RPC mechanism called
354 "bootparams" to deliver configuration information and operating
355 system code to diskless hosts. (Sun Microsystems, Sun Workstation
356 and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
357 networks also use DRARP and an auto-installation mechanism to
358 automate the configuration of new hosts in an existing network.
359
360 In other related work, the path minimum transmission unit (MTU)
361 discovery algorithm can determine the MTU of an arbitrary internet
362 path [<a href="#ref-14" title="&quot;Path MTU Discovery&quot;">14</a>]. The Address Resolution Protocol (ARP) has been proposed
363 as a transport protocol for resource location and selection [<a href="#ref-6" title="&quot;Uniform Access to Internet Directory Services&quot;">6</a>].
364 Finally, the Host Requirements RFCs [<a href="#ref-3" title="&quot;Requirements for Internet Hosts -- Communication Layers&quot;">3</a>, <a href="#ref-4" title="Editor">4</a>] mention specific
365 requirements for host reconfiguration and suggest a scenario for
366 initial configuration of diskless hosts.
367
368<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a> Problem definition and issues</span>
369
370 DHCP is designed to supply DHCP clients with the configuration
371 parameters defined in the Host Requirements RFCs. After obtaining
372 parameters via DHCP, a DHCP client should be able to exchange packets
373 with any other host in the Internet. The TCP/IP stack parameters
374 supplied by DHCP are listed in <a href="#appendix-A">Appendix A</a>.
375
376
377
378
379
380<span class="grey">Droms Standards Track [Page 4]</span></pre>
381<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
382<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
383
384
385 Not all of these parameters are required for a newly initialized
386 client. A client and server may negotiate for the transmission of
387 only those parameters required by the client or specific to a
388 particular subnet.
389
390 DHCP allows but does not require the configuration of client
391 parameters not directly related to the IP protocol. DHCP also does
392 not address registration of newly configured clients with the Domain
393 Name System (DNS) [<a href="#ref-12" title="&quot;Domain Names -- Concepts and Facilities&quot;">12</a>, <a href="#ref-13" title="&quot;Domain Names -- Implementation and Specification&quot;">13</a>].
394
395 DHCP is not intended for use in configuring routers.
396
397<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a> Requirements</span>
398
399 Throughout this document, the words that are used to define the
400 significance of particular requirements are capitalized. These words
401 are:
402
403 o "MUST"
404
405 This word or the adjective "REQUIRED" means that the
406 item is an absolute requirement of this specification.
407
408 o "MUST NOT"
409
410 This phrase means that the item is an absolute prohibition
411 of this specification.
412
413 o "SHOULD"
414
415 This word or the adjective "RECOMMENDED" means that there
416 may exist valid reasons in particular circumstances to ignore
417 this item, but the full implications should be understood and
418 the case carefully weighed before choosing a different course.
419
420 o "SHOULD NOT"
421
422 This phrase means that there may exist valid reasons in
423 particular circumstances when the listed behavior is acceptable
424 or even useful, but the full implications should be understood
425 and the case carefully weighed before implementing any behavior
426 described with this label.
427
428
429
430
431
432
433
434
435
436<span class="grey">Droms Standards Track [Page 5]</span></pre>
437<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
438<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
439
440
441 o "MAY"
442
443 This word or the adjective "OPTIONAL" means that this item is
444 truly optional. One vendor may choose to include the item
445 because a particular marketplace requires it or because it
446 enhances the product, for example; another vendor may omit the
447 same item.
448
449<span class="h3"><a class="selflink" id="section-1.5" href="#section-1.5">1.5</a> Terminology</span>
450
451 This document uses the following terms:
452
453 o "DHCP client"
454
455 A DHCP client is an Internet host using DHCP to obtain
456 configuration parameters such as a network address.
457
458 o "DHCP server"
459
460 A DHCP server is an Internet host that returns configuration
461 parameters to DHCP clients.
462
463 o "BOOTP relay agent"
464
465 A BOOTP relay agent or relay agent is an Internet host or router
466 that passes DHCP messages between DHCP clients and DHCP servers.
467 DHCP is designed to use the same relay agent behavior as specified
468 in the BOOTP protocol specification.
469
470 o "binding"
471
472 A binding is a collection of configuration parameters, including
473 at least an IP address, associated with or "bound to" a DHCP
474 client. Bindings are managed by DHCP servers.
475
476<span class="h3"><a class="selflink" id="section-1.6" href="#section-1.6">1.6</a> Design goals</span>
477
478 The following list gives general design goals for DHCP.
479
480 o DHCP should be a mechanism rather than a policy. DHCP must
481 allow local system administrators control over configuration
482 parameters where desired; e.g., local system administrators
483 should be able to enforce local policies concerning allocation
484 and access to local resources where desired.
485
486
487
488
489
490
491
492<span class="grey">Droms Standards Track [Page 6]</span></pre>
493<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
494<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
495
496
497 o Clients should require no manual configuration. Each client
498 should be able to discover appropriate local configuration
499 parameters without user intervention and incorporate those
500 parameters into its own configuration.
501
502 o Networks should require no manual configuration for individual
503 clients. Under normal circumstances, the network manager
504 should not have to enter any per-client configuration
505 parameters.
506
507 o DHCP should not require a server on each subnet. To allow for
508 scale and economy, DHCP must work across routers or through the
509 intervention of BOOTP relay agents.
510
511 o A DHCP client must be prepared to receive multiple responses
512 to a request for configuration parameters. Some installations
513 may include multiple, overlapping DHCP servers to enhance
514 reliability and increase performance.
515
516 o DHCP must coexist with statically configured, non-participating
517 hosts and with existing network protocol implementations.
518
519 o DHCP must interoperate with the BOOTP relay agent behavior as
520 described by <a href="./rfc951">RFC 951</a> and by <a href="./rfc1542">RFC 1542</a> [<a href="#ref-21" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">21</a>].
521
522 o DHCP must provide service to existing BOOTP clients.
523
524 The following list gives design goals specific to the transmission of
525 the network layer parameters. DHCP must:
526
527 o Guarantee that any specific network address will not be in
528 use by more than one DHCP client at a time,
529
530 o Retain DHCP client configuration across DHCP client reboot. A
531 DHCP client should, whenever possible, be assigned the same
532 configuration parameters (e.g., network address) in response
533 to each request,
534
535 o Retain DHCP client configuration across server reboots, and,
536 whenever possible, a DHCP client should be assigned the same
537 configuration parameters despite restarts of the DHCP mechanism,
538
539 o Allow automated assignment of configuration parameters to new
540 clients to avoid hand configuration for new clients,
541
542 o Support fixed or permanent allocation of configuration
543 parameters to specific clients.
544
545
546
547
548<span class="grey">Droms Standards Track [Page 7]</span></pre>
549<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
550<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
551
552
553<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Protocol Summary</span>
554
555 From the client's point of view, DHCP is an extension of the BOOTP
556 mechanism. This behavior allows existing BOOTP clients to
557 interoperate with DHCP servers without requiring any change to the
558 clients' initialization software. <a href="./rfc1542">RFC 1542</a> [<a href="#ref-2" title="&quot;DHCP Options and BOOTP Vendor Extensions&quot;">2</a>] details the
559 interactions between BOOTP and DHCP clients and servers [<a href="#ref-9" title="&quot;Interoperation between DHCP and BOOTP&quot;">9</a>]. There
560 are some new, optional transactions that optimize the interaction
561 between DHCP clients and servers that are described in sections <a href="#section-3">3</a> and
562 4.
563
564 Figure 1 gives the format of a DHCP message and table 1 describes
565 each of the fields in the DHCP message. The numbers in parentheses
566 indicate the size of each field in octets. The names for the fields
567 given in the figure will be used throughout this document to refer to
568 the fields in DHCP messages.
569
570 There are two primary differences between DHCP and BOOTP. First,
571 DHCP defines mechanisms through which clients can be assigned a
572 network address for a finite lease, allowing for serial reassignment
573 of network addresses to different clients. Second, DHCP provides the
574 mechanism for a client to acquire all of the IP configuration
575 parameters that it needs in order to operate.
576
577 DHCP introduces a small change in terminology intended to clarify the
578 meaning of one of the fields. What was the "vendor extensions" field
579 in BOOTP has been re-named the "options" field in DHCP. Similarly,
580 the tagged data items that were used inside the BOOTP "vendor
581 extensions" field, which were formerly referred to as "vendor
582 extensions," are now termed simply "options."
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604<span class="grey">Droms Standards Track [Page 8]</span></pre>
605<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
606<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
607
608
609 0 1 2 3
610 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
611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
612 | op (1) | htype (1) | hlen (1) | hops (1) |
613 +---------------+---------------+---------------+---------------+
614 | xid (4) |
615 +-------------------------------+-------------------------------+
616 | secs (2) | flags (2) |
617 +-------------------------------+-------------------------------+
618 | ciaddr (4) |
619 +---------------------------------------------------------------+
620 | yiaddr (4) |
621 +---------------------------------------------------------------+
622 | siaddr (4) |
623 +---------------------------------------------------------------+
624 | giaddr (4) |
625 +---------------------------------------------------------------+
626 | |
627 | chaddr (16) |
628 | |
629 | |
630 +---------------------------------------------------------------+
631 | |
632 | sname (64) |
633 +---------------------------------------------------------------+
634 | |
635 | file (128) |
636 +---------------------------------------------------------------+
637 | |
638 | options (variable) |
639 +---------------------------------------------------------------+
640
641 Figure 1: Format of a DHCP message
642
643 DHCP defines a new 'client identifier' option that is used to pass an
644 explicit client identifier to a DHCP server. This change eliminates
645 the overloading of the 'chaddr' field in BOOTP messages, where
646 'chaddr' is used both as a hardware address for transmission of BOOTP
647 reply messages and as a client identifier. The 'client identifier'
648 is an opaque key, not to be interpreted by the server; for example,
649 the 'client identifier' may contain a hardware address, identical to
650 the contents of the 'chaddr' field, or it may contain another type of
651 identifier, such as a DNS name. The 'client identifier' chosen by a
652 DHCP client MUST be unique to that client within the subnet to which
653 the client is attached. If the client uses a 'client identifier' in
654 one message, it MUST use that same identifier in all subsequent
655 messages, to ensure that all servers correctly identify the client.
656
657
658
659
660<span class="grey">Droms Standards Track [Page 9]</span></pre>
661<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
662<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
663
664
665 DHCP clarifies the interpretation of the 'siaddr' field as the
666 address of the server to use in the next step of the client's
667 bootstrap process. A DHCP server may return its own address in the
668 'siaddr' field, if the server is prepared to supply the next
669 bootstrap service (e.g., delivery of an operating system executable
670 image). A DHCP server always returns its own address in the 'server
671 identifier' option.
672
673 FIELD OCTETS DESCRIPTION
674 ----- ------ -----------
675
676 op 1 Message op code / message type.
677 1 = BOOTREQUEST, 2 = BOOTREPLY
678 htype 1 Hardware address type, see ARP section in "Assigned
679 Numbers" RFC; e.g., '1' = 10mb ethernet.
680 hlen 1 Hardware address length (e.g. '6' for 10mb
681 ethernet).
682 hops 1 Client sets to zero, optionally used by relay agents
683 when booting via a relay agent.
684 xid 4 Transaction ID, a random number chosen by the
685 client, used by the client and server to associate
686 messages and responses between a client and a
687 server.
688 secs 2 Filled in by client, seconds elapsed since client
689 began address acquisition or renewal process.
690 flags 2 Flags (see figure 2).
691 ciaddr 4 Client IP address; only filled in if client is in
692 BOUND, RENEW or REBINDING state and can respond
693 to ARP requests.
694 yiaddr 4 'your' (client) IP address.
695 siaddr 4 IP address of next server to use in bootstrap;
696 returned in DHCPOFFER, DHCPACK by server.
697 giaddr 4 Relay agent IP address, used in booting via a
698 relay agent.
699 chaddr 16 Client hardware address.
700 sname 64 Optional server host name, null terminated string.
701 file 128 Boot file name, null terminated string; "generic"
702 name or null in DHCPDISCOVER, fully qualified
703 directory-path name in DHCPOFFER.
704 options var Optional parameters field. See the options
705 documents for a list of defined options.
706
707 Table 1: Description of fields in a DHCP message
708
709 The 'options' field is now variable length. A DHCP client must be
710 prepared to receive DHCP messages with an 'options' field of at least
711 length 312 octets. This requirement implies that a DHCP client must
712 be prepared to receive a message of up to 576 octets, the minimum IP
713
714
715
716<span class="grey">Droms Standards Track [Page 10]</span></pre>
717<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
718<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
719
720
721 datagram size an IP host must be prepared to accept [<a href="#ref-3" title="&quot;Requirements for Internet Hosts -- Communication Layers&quot;">3</a>]. DHCP
722 clients may negotiate the use of larger DHCP messages through the
723 'maximum DHCP message size' option. The options field may be further
724 extended into the 'file' and 'sname' fields.
725
726 In the case of a client using DHCP for initial configuration (before
727 the client's TCP/IP software has been completely configured), DHCP
728 requires creative use of the client's TCP/IP software and liberal
729 interpretation of <a href="./rfc1122">RFC 1122</a>. The TCP/IP software SHOULD accept and
730 forward to the IP layer any IP packets delivered to the client's
731 hardware address before the IP address is configured; DHCP servers
732 and BOOTP relay agents may not be able to deliver DHCP messages to
733 clients that cannot accept hardware unicast datagrams before the
734 TCP/IP software is configured.
735
736 To work around some clients that cannot accept IP unicast datagrams
737 before the TCP/IP software is configured as discussed in the previous
738 paragraph, DHCP uses the 'flags' field [<a href="#ref-21" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">21</a>]. The leftmost bit is
739 defined as the BROADCAST (B) flag. The semantics of this flag are
740 discussed in <a href="#section-4.1">section 4.1</a> of this document. The remaining bits of the
741 flags field are reserved for future use. They MUST be set to zero by
742 clients and ignored by servers and relay agents. Figure 2 gives the
743 format of the 'flags' field.
744
745 1 1 1 1 1 1
746 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
748 |B| MBZ |
749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
750
751 B: BROADCAST flag
752
753 MBZ: MUST BE ZERO (reserved for future use)
754
755 Figure 2: Format of the 'flags' field
756
757<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Configuration parameters repository</span>
758
759 The first service provided by DHCP is to provide persistent storage
760 of network parameters for network clients. The model of DHCP
761 persistent storage is that the DHCP service stores a key-value entry
762 for each client, where the key is some unique identifier (for
763 example, an IP subnet number and a unique identifier within the
764 subnet) and the value contains the configuration parameters for the
765 client.
766
767 For example, the key might be the pair (IP-subnet-number, hardware-
768 address) (note that the "hardware-address" should be typed by the
769
770
771
772<span class="grey">Droms Standards Track [Page 11]</span></pre>
773<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
774<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
775
776
777 type of hardware to accommodate possible duplication of hardware
778 addresses resulting from bit-ordering problems in a mixed-media,
779 bridged network) allowing for serial or concurrent reuse of a
780 hardware address on different subnets, and for hardware addresses
781 that may not be globally unique. Alternately, the key might be the
782 pair (IP-subnet-number, hostname), allowing the server to assign
783 parameters intelligently to a DHCP client that has been moved to a
784 different subnet or has changed hardware addresses (perhaps because
785 the network interface failed and was replaced). The protocol defines
786 that the key will be (IP-subnet-number, hardware-address) unless the
787 client explicitly supplies an identifier using the 'client
788 identifier' option. A client can query the DHCP service to
789 retrieve its configuration parameters. The client interface to the
790 configuration parameters repository consists of protocol messages to
791 request configuration parameters and responses from the server
792 carrying the configuration parameters.
793
794<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Dynamic allocation of network addresses</span>
795
796 The second service provided by DHCP is the allocation of temporary or
797 permanent network (IP) addresses to clients. The basic mechanism for
798 the dynamic allocation of network addresses is simple: a client
799 requests the use of an address for some period of time. The
800 allocation mechanism (the collection of DHCP servers) guarantees not
801 to reallocate that address within the requested time and attempts to
802 return the same network address each time the client requests an
803 address. In this document, the period over which a network address
804 is allocated to a client is referred to as a "lease" [<a href="#ref-11" title="&quot;Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency&quot;">11</a>]. The
805 client may extend its lease with subsequent requests. The client may
806 issue a message to release the address back to the server when the
807 client no longer needs the address. The client may ask for a
808 permanent assignment by asking for an infinite lease. Even when
809 assigning "permanent" addresses, a server may choose to give out
810 lengthy but non-infinite leases to allow detection of the fact that
811 the client has been retired.
812
813 In some environments it will be necessary to reassign network
814 addresses due to exhaustion of available addresses. In such
815 environments, the allocation mechanism will reuse addresses whose
816 lease has expired. The server should use whatever information is
817 available in the configuration information repository to choose an
818 address to reuse. For example, the server may choose the least
819 recently assigned address. As a consistency check, the allocating
820 server SHOULD probe the reused address before allocating the address,
821 e.g., with an ICMP echo request, and the client SHOULD probe the
822 newly received address, e.g., with ARP.
823
824
825
826
827
828<span class="grey">Droms Standards Track [Page 12]</span></pre>
829<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
830<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
831
832
833<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Client-Server Protocol</span>
834
835 DHCP uses the BOOTP message format defined in <a href="./rfc951">RFC 951</a> and given in
836 table 1 and figure 1. The 'op' field of each DHCP message sent from
837 a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
838 'op' field of each DHCP message sent from a server to a client.
839
840 The first four octets of the 'options' field of the DHCP message
841 contain the (decimal) values 99, 130, 83 and 99, respectively (this
842 is the same magic cookie as is defined in <a href="./rfc1497">RFC 1497</a> [<a href="#ref-17" title="&quot;BOOTP Vendor Information Extensions&quot;">17</a>]). The
843 remainder of the 'options' field consists of a list of tagged
844 parameters that are called "options". All of the "vendor extensions"
845 listed in <a href="./rfc1497">RFC 1497</a> are also DHCP options. <a href="./rfc1533">RFC 1533</a> gives the
846 complete set of options defined for use with DHCP.
847
848 Several options have been defined so far. One particular option -
849 the "DHCP message type" option - must be included in every DHCP
850 message. This option defines the "type" of the DHCP message.
851 Additional options may be allowed, required, or not allowed,
852 depending on the DHCP message type.
853
854 Throughout this document, DHCP messages that include a 'DHCP message
855 type' option will be referred to by the type of the message; e.g., a
856 DHCP message with 'DHCP message type' option type 1 will be referred
857 to as a "DHCPDISCOVER" message.
858
859<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Client-server interaction - allocating a network address</span>
860
861 The following summary of the protocol exchanges between clients and
862 servers refers to the DHCP messages described in table 2. The
863 timeline diagram in figure 3 shows the timing relationships in a
864 typical client-server interaction. If the client already knows its
865 address, some steps may be omitted; this abbreviated interaction is
866 described in <a href="#section-3.2">section 3.2</a>.
867
868 1. The client broadcasts a DHCPDISCOVER message on its local physical
869 subnet. The DHCPDISCOVER message MAY include options that suggest
870 values for the network address and lease duration. BOOTP relay
871 agents may pass the message on to DHCP servers not on the same
872 physical subnet.
873
874 2. Each server may respond with a DHCPOFFER message that includes an
875 available network address in the 'yiaddr' field (and other
876 configuration parameters in DHCP options). Servers need not
877 reserve the offered network address, although the protocol will
878 work more efficiently if the server avoids allocating the offered
879 network address to another client. When allocating a new address,
880 servers SHOULD check that the offered network address is not
881
882
883
884<span class="grey">Droms Standards Track [Page 13]</span></pre>
885<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
886<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
887
888
889 already in use; e.g., the server may probe the offered address
890 with an ICMP Echo Request. Servers SHOULD be implemented so that
891 network administrators MAY choose to disable probes of newly
892 allocated addresses. The server transmits the DHCPOFFER message
893 to the client, using the BOOTP relay agent if necessary.
894
895 Message Use
896 ------- ---
897
898 DHCPDISCOVER - Client broadcast to locate available servers.
899
900 DHCPOFFER - Server to client in response to DHCPDISCOVER with
901 offer of configuration parameters.
902
903 DHCPREQUEST - Client message to servers either (a) requesting
904 offered parameters from one server and implicitly
905 declining offers from all others, (b) confirming
906 correctness of previously allocated address after,
907 e.g., system reboot, or (c) extending the lease on a
908 particular network address.
909
910 DHCPACK - Server to client with configuration parameters,
911 including committed network address.
912
913 DHCPNAK - Server to client indicating client's notion of network
914 address is incorrect (e.g., client has moved to new
915 subnet) or client's lease as expired
916
917 DHCPDECLINE - Client to server indicating network address is already
918 in use.
919
920 DHCPRELEASE - Client to server relinquishing network address and
921 cancelling remaining lease.
922
923 DHCPINFORM - Client to server, asking only for local configuration
924 parameters; client already has externally configured
925 network address.
926
927 Table 2: DHCP messages
928
929
930
931
932
933
934
935
936
937
938
939
940<span class="grey">Droms Standards Track [Page 14]</span></pre>
941<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
942<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
943
944
945 Server Client Server
946 (not selected) (selected)
947
948 v v v
949 | | |
950 | Begins initialization |
951 | | |
952 | _____________/|\____________ |
953 |/DHCPDISCOVER | DHCPDISCOVER \|
954 | | |
955 Determines | Determines
956 configuration | configuration
957 | | |
958 |\ | ____________/ |
959 | \________ | /DHCPOFFER |
960 | DHCPOFFER\ |/ |
961 | \ | |
962 | Collects replies |
963 | \| |
964 | Selects configuration |
965 | | |
966 | _____________/|\____________ |
967 |/ DHCPREQUEST | DHCPREQUEST\ |
968 | | |
969 | | Commits configuration
970 | | |
971 | | _____________/|
972 | |/ DHCPACK |
973 | | |
974 | Initialization complete |
975 | | |
976 . . .
977 . . .
978 | | |
979 | Graceful shutdown |
980 | | |
981 | |\ ____________ |
982 | | DHCPRELEASE \|
983 | | |
984 | | Discards lease
985 | | |
986 v v v
987 Figure 3: Timeline diagram of messages exchanged between DHCP
988 client and servers when allocating a new network address
989
990
991
992
993
994
995
996<span class="grey">Droms Standards Track [Page 15]</span></pre>
997<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
998<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
999
1000
1001 3. The client receives one or more DHCPOFFER messages from one or more
1002 servers. The client may choose to wait for multiple responses.
1003 The client chooses one server from which to request configuration
1004 parameters, based on the configuration parameters offered in the
1005 DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
1006 that MUST include the 'server identifier' option to indicate which
1007 server it has selected, and that MAY include other options
1008 specifying desired configuration values. The 'requested IP
1009 address' option MUST be set to the value of 'yiaddr' in the
1010 DHCPOFFER message from the server. This DHCPREQUEST message is
1011 broadcast and relayed through DHCP/BOOTP relay agents. To help
1012 ensure that any BOOTP relay agents forward the DHCPREQUEST message
1013 to the same set of DHCP servers that received the original
1014 DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
1015 value in the DHCP message header's 'secs' field and be sent to the
1016 same IP broadcast address as the original DHCPDISCOVER message.
1017 The client times out and retransmits the DHCPDISCOVER message if
1018 the client receives no DHCPOFFER messages.
1019
1020 4. The servers receive the DHCPREQUEST broadcast from the client.
1021 Those servers not selected by the DHCPREQUEST message use the
1022 message as notification that the client has declined that server's
1023 offer. The server selected in the DHCPREQUEST message commits the
1024 binding for the client to persistent storage and responds with a
1025 DHCPACK message containing the configuration parameters for the
1026 requesting client. The combination of 'client identifier' or
1027 'chaddr' and assigned network address constitute a unique
1028 identifier for the client's lease and are used by both the client
1029 and server to identify a lease referred to in any DHCP messages.
1030 Any configuration parameters in the DHCPACK message SHOULD NOT
1031 conflict with those in the earlier DHCPOFFER message to which the
1032 client is responding. The server SHOULD NOT check the offered
1033 network address at this point. The 'yiaddr' field in the DHCPACK
1034 messages is filled in with the selected network address.
1035
1036 If the selected server is unable to satisfy the DHCPREQUEST message
1037 (e.g., the requested network address has been allocated), the
1038 server SHOULD respond with a DHCPNAK message.
1039
1040 A server MAY choose to mark addresses offered to clients in
1041 DHCPOFFER messages as unavailable. The server SHOULD mark an
1042 address offered to a client in a DHCPOFFER message as available if
1043 the server receives no DHCPREQUEST message from that client.
1044
1045 5. The client receives the DHCPACK message with configuration
1046 parameters. The client SHOULD perform a final check on the
1047 parameters (e.g., ARP for allocated network address), and notes the
1048 duration of the lease specified in the DHCPACK message. At this
1049
1050
1051
1052<span class="grey">Droms Standards Track [Page 16]</span></pre>
1053<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
1054<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1055
1056
1057 point, the client is configured. If the client detects that the
1058 address is already in use (e.g., through the use of ARP), the
1059 client MUST send a DHCPDECLINE message to the server and restarts
1060 the configuration process. The client SHOULD wait a minimum of ten
1061 seconds before restarting the configuration process to avoid
1062 excessive network traffic in case of looping.
1063
1064 If the client receives a DHCPNAK message, the client restarts the
1065 configuration process.
1066
1067 The client times out and retransmits the DHCPREQUEST message if the
1068 client receives neither a DHCPACK or a DHCPNAK message. The client
1069 retransmits the DHCPREQUEST according to the retransmission
1070 algorithm in <a href="#section-4.1">section 4.1</a>. The client should choose to retransmit
1071 the DHCPREQUEST enough times to give adequate probability of
1072 contacting the server without causing the client (and the user of
1073 that client) to wait overly long before giving up; e.g., a client
1074 retransmitting as described in <a href="#section-4.1">section 4.1</a> might retransmit the
1075 DHCPREQUEST message four times, for a total delay of 60 seconds,
1076 before restarting the initialization procedure. If the client
1077 receives neither a DHCPACK or a DHCPNAK message after employing the
1078 retransmission algorithm, the client reverts to INIT state and
1079 restarts the initialization process. The client SHOULD notify the
1080 user that the initialization process has failed and is restarting.
1081
1082 6. The client may choose to relinquish its lease on a network address
1083 by sending a DHCPRELEASE message to the server. The client
1084 identifies the lease to be released with its 'client identifier',
1085 or 'chaddr' and network address in the DHCPRELEASE message. If the
1086 client used a 'client identifier' when it obtained the lease, it
1087 MUST use the same 'client identifier' in the DHCPRELEASE message.
1088
1089<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Client-server interaction - reusing a previously allocated network</span>
1090<span class="h3"> address</span>
1091
1092 If a client remembers and wishes to reuse a previously allocated
1093 network address, a client may choose to omit some of the steps
1094 described in the previous section. The timeline diagram in figure 4
1095 shows the timing relationships in a typical client-server interaction
1096 for a client reusing a previously allocated network address.
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108<span class="grey">Droms Standards Track [Page 17]</span></pre>
1109<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
1110<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1111
1112
1113 1. The client broadcasts a DHCPREQUEST message on its local subnet.
1114 The message includes the client's network address in the
1115 'requested IP address' option. As the client has not received its
1116 network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
1117 relay agents pass the message on to DHCP servers not on the same
1118 subnet. If the client used a 'client identifier' to obtain its
1119 address, the client MUST use the same 'client identifier' in the
1120 DHCPREQUEST message.
1121
1122 2. Servers with knowledge of the client's configuration parameters
1123 respond with a DHCPACK message to the client. Servers SHOULD NOT
1124 check that the client's network address is already in use; the
1125 client may respond to ICMP Echo Request messages at this point.
1126
1127 Server Client Server
1128
1129 v v v
1130 | | |
1131 | Begins |
1132 | initialization |
1133 | | |
1134 | /|\ |
1135 | _________ __/ | \__________ |
1136 | /DHCPREQU EST | DHCPREQUEST\ |
1137 |/ | \|
1138 | | |
1139 Locates | Locates
1140 configuration | configuration
1141 | | |
1142 |\ | /|
1143 | \ | ___________/ |
1144 | \ | / DHCPACK |
1145 | \ _______ |/ |
1146 | DHCPACK\ | |
1147 | Initialization |
1148 | complete |
1149 | \| |
1150 | | |
1151 | (Subsequent |
1152 | DHCPACKS |
1153 | ignored) |
1154 | | |
1155 | | |
1156 v v v
1157
1158 Figure 4: Timeline diagram of messages exchanged between DHCP
1159 client and servers when reusing a previously allocated
1160 network address
1161
1162
1163
1164<span class="grey">Droms Standards Track [Page 18]</span></pre>
1165<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
1166<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1167
1168
1169 If the client's request is invalid (e.g., the client has moved
1170 to a new subnet), servers SHOULD respond with a DHCPNAK message to
1171 the client. Servers SHOULD NOT respond if their information is not
1172 guaranteed to be accurate. For example, a server that identifies a
1173 request for an expired binding that is owned by another server SHOULD
1174 NOT respond with a DHCPNAK unless the servers are using an explicit
1175 mechanism to maintain coherency among the servers.
1176
1177 If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
1178 the same subnet as the server. The server MUST
1179 broadcast the DHCPNAK message to the 0xffffffff broadcast address
1180 because the client may not have a correct network address or subnet
1181 mask, and the client may not be answering ARP requests.
1182 Otherwise, the server MUST send the DHCPNAK message to the IP
1183 address of the BOOTP relay agent, as recorded in 'giaddr'. The
1184 relay agent will, in turn, forward the message directly to the
1185 client's hardware address, so that the DHCPNAK can be delivered even
1186 if the client has moved to a new network.
1187
1188 3. The client receives the DHCPACK message with configuration
1189 parameters. The client performs a final check on the parameters
1190 (as in <a href="#section-3.1">section 3.1</a>), and notes the duration of the lease specified
1191 in the DHCPACK message. The specific lease is implicitly identified
1192 by the 'client identifier' or 'chaddr' and the network address. At
1193 this point, the client is configured.
1194
1195 If the client detects that the IP address in the DHCPACK message
1196 is already in use, the client MUST send a DHCPDECLINE message to the
1197 server and restarts the configuration process by requesting a
1198 new network address. This action corresponds to the client
1199 moving to the INIT state in the DHCP state diagram, which is
1200 described in <a href="#section-4.4">section 4.4</a>.
1201
1202 If the client receives a DHCPNAK message, it cannot reuse its
1203 remembered network address. It must instead request a new
1204 address by restarting the configuration process, this time
1205 using the (non-abbreviated) procedure described in <a href="#section-3.1">section</a>
1206 <a href="#section-3.1">3.1</a>. This action also corresponds to the client moving to
1207 the INIT state in the DHCP state diagram.
1208
1209 The client times out and retransmits the DHCPREQUEST message if
1210 the client receives neither a DHCPACK nor a DHCPNAK message. The
1211 client retransmits the DHCPREQUEST according to the retransmission
1212 algorithm in <a href="#section-4.1">section 4.1</a>. The client should choose to retransmit
1213 the DHCPREQUEST enough times to give adequate probability of
1214 contacting the server without causing the client (and the user of
1215 that client) to wait overly long before giving up; e.g., a client
1216 retransmitting as described in <a href="#section-4.1">section 4.1</a> might retransmit the
1217
1218
1219
1220<span class="grey">Droms Standards Track [Page 19]</span></pre>
1221<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
1222<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1223
1224
1225 DHCPREQUEST message four times, for a total delay of 60 seconds,
1226 before restarting the initialization procedure. If the client
1227 receives neither a DHCPACK or a DHCPNAK message after employing
1228 the retransmission algorithm, the client MAY choose to use the
1229 previously allocated network address and configuration parameters
1230 for the remainder of the unexpired lease. This corresponds to
1231 moving to BOUND state in the client state transition diagram shown
1232 in figure 5.
1233
1234 4. The client may choose to relinquish its lease on a network
1235 address by sending a DHCPRELEASE message to the server. The
1236 client identifies the lease to be released with its
1237 'client identifier', or 'chaddr' and network address in the
1238 DHCPRELEASE message.
1239
1240 Note that in this case, where the client retains its network
1241 address locally, the client will not normally relinquish its
1242 lease during a graceful shutdown. Only in the case where the
1243 client explicitly needs to relinquish its lease, e.g., the client
1244 is about to be moved to a different subnet, will the client send
1245 a DHCPRELEASE message.
1246
1247<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Interpretation and representation of time values</span>
1248
1249 A client acquires a lease for a network address for a fixed period of
1250 time (which may be infinite). Throughout the protocol, times are to
1251 be represented in units of seconds. The time value of 0xffffffff is
1252 reserved to represent "infinity".
1253
1254 As clients and servers may not have synchronized clocks, times are
1255 represented in DHCP messages as relative times, to be interpreted
1256 with respect to the client's local clock. Representing relative
1257 times in units of seconds in an unsigned 32 bit word gives a range of
1258 relative times from 0 to approximately 100 years, which is sufficient
1259 for the relative times to be measured using DHCP.
1260
1261 The algorithm for lease duration interpretation given in the previous
1262 paragraph assumes that client and server clocks are stable relative
1263 to each other. If there is drift between the two clocks, the server
1264 may consider the lease expired before the client does. To
1265 compensate, the server may return a shorter lease duration to the
1266 client than the server commits to its local database of client
1267 information.
1268
1269<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a> Obtaining parameters with externally configured network address</span>
1270
1271 If a client has obtained a network address through some other means
1272 (e.g., manual configuration), it may use a DHCPINFORM request message
1273
1274
1275
1276<span class="grey">Droms Standards Track [Page 20]</span></pre>
1277<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
1278<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1279
1280
1281 to obtain other local configuration parameters. Servers receiving a
1282 DHCPINFORM message construct a DHCPACK message with any local
1283 configuration parameters appropriate for the client without:
1284 allocating a new address, checking for an existing binding, filling
1285 in 'yiaddr' or including lease time parameters. The servers SHOULD
1286 unicast the DHCPACK reply to the address given in the 'ciaddr' field
1287 of the DHCPINFORM message.
1288
1289 The server SHOULD check the network address in a DHCPINFORM message
1290 for consistency, but MUST NOT check for an existing lease. The
1291 server forms a DHCPACK message containing the configuration
1292 parameters for the requesting client and sends the DHCPACK message
1293 directly to the client.
1294
1295<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a> Client parameters in DHCP</span>
1296
1297 Not all clients require initialization of all parameters listed in
1298 <a href="#appendix-A">Appendix A</a>. Two techniques are used to reduce the number of
1299 parameters transmitted from the server to the client. First, most of
1300 the parameters have defaults defined in the Host Requirements RFCs;
1301 if the client receives no parameters from the server that override
1302 the defaults, a client uses those default values. Second, in its
1303 initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
1304 server with a list of specific parameters the client is interested
1305 in. If the client includes a list of parameters in a DHCPDISCOVER
1306 message, it MUST include that list in any subsequent DHCPREQUEST
1307 messages.
1308
1309 The client SHOULD include the 'maximum DHCP message size' option to
1310 let the server know how large the server may make its DHCP messages.
1311 The parameters returned to a client may still exceed the space
1312 allocated to options in a DHCP message. In this case, two additional
1313 options flags (which must appear in the 'options' field of the
1314 message) indicate that the 'file' and 'sname' fields are to be used
1315 for options.
1316
1317 The client can inform the server which configuration parameters the
1318 client is interested in by including the 'parameter request list'
1319 option. The data portion of this option explicitly lists the options
1320 requested by tag number.
1321
1322 In addition, the client may suggest values for the network address
1323 and lease time in the DHCPDISCOVER message. The client may include
1324 the 'requested IP address' option to suggest that a particular IP
1325 address be assigned, and may include the 'IP address lease time'
1326 option to suggest the lease time it would like. Other options
1327 representing "hints" at configuration parameters are allowed in a
1328 DHCPDISCOVER or DHCPREQUEST message. However, additional options may
1329
1330
1331
1332<span class="grey">Droms Standards Track [Page 21]</span></pre>
1333<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
1334<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1335
1336
1337 be ignored by servers, and multiple servers may, therefore, not
1338 return identical values for some options. The 'requested IP address'
1339 option is to be filled in only in a DHCPREQUEST message when the
1340 client is verifying network parameters obtained previously. The
1341 client fills in the 'ciaddr' field only when correctly configured
1342 with an IP address in BOUND, RENEWING or REBINDING state.
1343
1344 If a server receives a DHCPREQUEST message with an invalid 'requested
1345 IP address', the server SHOULD respond to the client with a DHCPNAK
1346 message and may choose to report the problem to the system
1347 administrator. The server may include an error message in the
1348 'message' option.
1349
1350<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a> Use of DHCP in clients with multiple interfaces</span>
1351
1352 A client with multiple network interfaces must use DHCP through each
1353 interface independently to obtain configuration information
1354 parameters for those separate interfaces.
1355
1356<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a> When clients should use DHCP</span>
1357
1358 A client SHOULD use DHCP to reacquire or verify its IP address and
1359 network parameters whenever the local network parameters may have
1360 changed; e.g., at system boot time or after a disconnection from the
1361 local network, as the local network configuration may change without
1362 the client's or user's knowledge.
1363
1364 If a client has knowledge of a previous network address and is unable
1365 to contact a local DHCP server, the client may continue to use the
1366 previous network address until the lease for that address expires.
1367 If the lease expires before the client can contact a DHCP server, the
1368 client must immediately discontinue use of the previous network
1369 address and may inform local users of the problem.
1370
1371<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Specification of the DHCP client-server protocol</span>
1372
1373 In this section, we assume that a DHCP server has a block of network
1374 addresses from which it can satisfy requests for new addresses. Each
1375 server also maintains a database of allocated addresses and leases in
1376 local permanent storage.
1377
1378<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Constructing and sending DHCP messages</span>
1379
1380 DHCP clients and servers both construct DHCP messages by filling in
1381 fields in the fixed format section of the message and appending
1382 tagged data items in the variable length option area. The options
1383 area includes first a four-octet 'magic cookie' (which was described
1384 in <a href="#section-3">section 3</a>), followed by the options. The last option must always
1385
1386
1387
1388<span class="grey">Droms Standards Track [Page 22]</span></pre>
1389<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
1390<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1391
1392
1393 be the 'end' option.
1394
1395 DHCP uses UDP as its transport protocol. DHCP messages from a client
1396 to a server are sent to the 'DHCP server' port (67), and DHCP
1397 messages from a server to a client are sent to the 'DHCP client' port
1398 (68). A server with multiple network address (e.g., a multi-homed
1399 host) MAY use any of its network addresses in outgoing DHCP messages.
1400
1401 The 'server identifier' field is used both to identify a DHCP server
1402 in a DHCP message and as a destination address from clients to
1403 servers. A server with multiple network addresses MUST be prepared
1404 to to accept any of its network addresses as identifying that server
1405 in a DHCP message. To accommodate potentially incomplete network
1406 connectivity, a server MUST choose an address as a 'server
1407 identifier' that, to the best of the server's knowledge, is reachable
1408 from the client. For example, if the DHCP server and the DHCP client
1409 are connected to the same subnet (i.e., the 'giaddr' field in the
1410 message from the client is zero), the server SHOULD select the IP
1411 address the server is using for communication on that subnet as the
1412 'server identifier'. If the server is using multiple IP addresses on
1413 that subnet, any such address may be used. If the server has
1414 received a message through a DHCP relay agent, the server SHOULD
1415 choose an address from the interface on which the message was
1416 recieved as the 'server identifier' (unless the server has other,
1417 better information on which to make its choice). DHCP clients MUST
1418 use the IP address provided in the 'server identifier' option for any
1419 unicast requests to the DHCP server.
1420
1421 DHCP messages broadcast by a client prior to that client obtaining
1422 its IP address must have the source address field in the IP header
1423 set to 0.
1424
1425 If the 'giaddr' field in a DHCP message from a client is non-zero,
1426 the server sends any return messages to the 'DHCP server' port on the
1427 BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
1428 field is zero and the 'ciaddr' field is nonzero, then the server
1429 unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
1430 If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
1431 set, then the server broadcasts DHCPOFFER and DHCPACK messages to
1432 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
1433 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
1434 messages to the client's hardware address and 'yiaddr' address. In
1435 all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
1436 messages to 0xffffffff.
1437
1438 If the options in a DHCP message extend into the 'sname' and 'file'
1439 fields, the 'option overload' option MUST appear in the 'options'
1440 field, with value 1, 2 or 3, as specified in <a href="./rfc1533">RFC 1533</a>. If the
1441
1442
1443
1444<span class="grey">Droms Standards Track [Page 23]</span></pre>
1445<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
1446<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1447
1448
1449 'option overload' option is present in the 'options' field, the
1450 options in the 'options' field MUST be terminated by an 'end' option,
1451 and MAY contain one or more 'pad' options to fill the options field.
1452 The options in the 'sname' and 'file' fields (if in use as indicated
1453 by the 'options overload' option) MUST begin with the first octet of
1454 the field, MUST be terminated by an 'end' option, and MUST be
1455 followed by 'pad' options to fill the remainder of the field. Any
1456 individual option in the 'options', 'sname' and 'file' fields MUST be
1457 entirely contained in that field. The options in the 'options' field
1458 MUST be interpreted first, so that any 'option overload' options may
1459 be interpreted. The 'file' field MUST be interpreted next (if the
1460 'option overload' option indicates that the 'file' field contains
1461 DHCP options), followed by the 'sname' field.
1462
1463 The values to be passed in an 'option' tag may be too long to fit in
1464 the 255 octets available to a single option (e.g., a list of routers
1465 in a 'router' option [<a href="#ref-21" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">21</a>]). Options may appear only once, unless
1466 otherwise specified in the options document. The client concatenates
1467 the values of multiple instances of the same option into a single
1468 parameter list for configuration.
1469
1470 DHCP clients are responsible for all message retransmission. The
1471 client MUST adopt a retransmission strategy that incorporates a
1472 randomized exponential backoff algorithm to determine the delay
1473 between retransmissions. The delay between retransmissions SHOULD be
1474 chosen to allow sufficient time for replies from the server to be
1475 delivered based on the characteristics of the internetwork between
1476 the client and the server. For example, in a 10Mb/sec Ethernet
1477 internetwork, the delay before the first retransmission SHOULD be 4
1478 seconds randomized by the value of a uniform random number chosen
1479 from the range -1 to +1. Clients with clocks that provide resolution
1480 granularity of less than one second may choose a non-integer
1481 randomization value. The delay before the next retransmission SHOULD
1482 be 8 seconds randomized by the value of a uniform number chosen from
1483 the range -1 to +1. The retransmission delay SHOULD be doubled with
1484 subsequent retransmissions up to a maximum of 64 seconds. The client
1485 MAY provide an indication of retransmission attempts to the user as
1486 an indication of the progress of the configuration process.
1487
1488 The 'xid' field is used by the client to match incoming DHCP messages
1489 with pending requests. A DHCP client MUST choose 'xid's in such a
1490 way as to minimize the chance of using an 'xid' identical to one used
1491 by another client. For example, a client may choose a different,
1492 random initial 'xid' each time the client is rebooted, and
1493 subsequently use sequential 'xid's until the next reboot. Selecting
1494 a new 'xid' for each retransmission is an implementation decision. A
1495 client may choose to reuse the same 'xid' or select a new 'xid' for
1496 each retransmitted message.
1497
1498
1499
1500<span class="grey">Droms Standards Track [Page 24]</span></pre>
1501<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
1502<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1503
1504
1505 Normally, DHCP servers and BOOTP relay agents attempt to deliver
1506 DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
1507 uicast delivery. The IP destination address (in the IP header) is
1508 set to the DHCP 'yiaddr' address and the link-layer destination
1509 address is set to the DHCP 'chaddr' address. Unfortunately, some
1510 client implementations are unable to receive such unicast IP
1511 datagrams until the implementation has been configured with a valid
1512 IP address (leading to a deadlock in which the client's IP address
1513 cannot be delivered until the client has been configured with an IP
1514 address).
1515
1516 A client that cannot receive unicast IP datagrams until its protocol
1517 software has been configured with an IP address SHOULD set the
1518 BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
1519 DHCPREQUEST messages that client sends. The BROADCAST bit will
1520 provide a hint to the DHCP server and BOOTP relay agent to broadcast
1521 any messages to the client on the client's subnet. A client that can
1522 receive unicast IP datagrams before its protocol software has been
1523 configured SHOULD clear the BROADCAST bit to 0. The BOOTP
1524 clarifications document discusses the ramifications of the use of the
1525 BROADCAST bit [<a href="#ref-21" title="&quot;Clarifications and Extensions for the Bootstrap Protocol&quot;">21</a>].
1526
1527 A server or relay agent sending or relaying a DHCP message directly
1528 to a DHCP client (i.e., not to a relay agent specified in the
1529 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
1530 field. If this bit is set to 1, the DHCP message SHOULD be sent as
1531 an IP broadcast using an IP broadcast address (preferably 0xffffffff)
1532 as the IP destination address and the link-layer broadcast address as
1533 the link-layer destination address. If the BROADCAST bit is cleared
1534 to 0, the message SHOULD be sent as an IP unicast to the IP address
1535 specified in the 'yiaddr' field and the link-layer address specified
1536 in the 'chaddr' field. If unicasting is not possible, the message
1537 MAY be sent as an IP broadcast using an IP broadcast address
1538 (preferably 0xffffffff) as the IP destination address and the link-
1539 layer broadcast address as the link-layer destination address.
1540
1541<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> DHCP server administrative controls</span>
1542
1543 DHCP servers are not required to respond to every DHCPDISCOVER and
1544 DHCPREQUEST message they receive. For example, a network
1545 administrator, to retain stringent control over the clients attached
1546 to the network, may choose to configure DHCP servers to respond only
1547 to clients that have been previously registered through some external
1548 mechanism. The DHCP specification describes only the interactions
1549 between clients and servers when the clients and servers choose to
1550 interact; it is beyond the scope of the DHCP specification to
1551 describe all of the administrative controls that system
1552 administrators might want to use. Specific DHCP server
1553
1554
1555
1556<span class="grey">Droms Standards Track [Page 25]</span></pre>
1557<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
1558<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1559
1560
1561 implementations may incorporate any controls or policies desired by a
1562 network administrator.
1563
1564 In some environments, a DHCP server will have to consider the values
1565 of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
1566 messages when determining the correct parameters for a particular
1567 client.
1568
1569 A DHCP server needs to use some unique identifier to associate a
1570 client with its lease. The client MAY choose to explicitly provide
1571 the identifier through the 'client identifier' option. If the client
1572 supplies a 'client identifier', the client MUST use the same 'client
1573 identifier' in all subsequent messages, and the server MUST use that
1574 identifier to identify the client. If the client does not provide a
1575 'client identifier' option, the server MUST use the contents of the
1576 'chaddr' field to identify the client. It is crucial for a DHCP
1577 client to use an identifier unique within the subnet to which the
1578 client is attached in the 'client identifier' option. Use of
1579 'chaddr' as the client's unique identifier may cause unexpected
1580 results, as that identifier may be associated with a hardware
1581 interface that could be moved to a new client. Some sites may choose
1582 to use a manufacturer's serial number as the 'client identifier', to
1583 avoid unexpected changes in a clients network address due to transfer
1584 of hardware interfaces among computers. Sites may also choose to use
1585 a DNS name as the 'client identifier', causing address leases to be
1586 associated with the DNS name rather than a specific hardware box.
1587
1588 DHCP clients are free to use any strategy in selecting a DHCP server
1589 among those from which the client receives a DHCPOFFER message. The
1590 client implementation of DHCP SHOULD provide a mechanism for the user
1591 to select directly the 'vendor class identifier' values.
1592
1593<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a> DHCP server behavior</span>
1594
1595 A DHCP server processes incoming DHCP messages from a client based on
1596 the current state of the binding for that client. A DHCP server can
1597 receive the following messages from a client:
1598
1599 o DHCPDISCOVER
1600
1601 o DHCPREQUEST
1602
1603 o DHCPDECLINE
1604
1605 o DHCPRELEASE
1606
1607 o DHCPINFORM
1608
1609
1610
1611
1612<span class="grey">Droms Standards Track [Page 26]</span></pre>
1613<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
1614<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1615
1616
1617 Table 3 gives the use of the fields and options in a DHCP message by
1618 a server. The remainder of this section describes the action of the
1619 DHCP server for each possible incoming message.
1620
1621<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a> DHCPDISCOVER message</span>
1622
1623 When a server receives a DHCPDISCOVER message from a client, the
1624 server chooses a network address for the requesting client. If no
1625 address is available, the server may choose to report the problem to
1626 the system administrator. If an address is available, the new address
1627 SHOULD be chosen as follows:
1628
1629 o The client's current address as recorded in the client's current
1630 binding, ELSE
1631
1632 o The client's previous address as recorded in the client's (now
1633 expired or released) binding, if that address is in the server's
1634 pool of available addresses and not already allocated, ELSE
1635
1636 o The address requested in the 'Requested IP Address' option, if that
1637 address is valid and not already allocated, ELSE
1638
1639 o A new address allocated from the server's pool of available
1640 addresses; the address is selected based on the subnet from which
1641 the message was received (if 'giaddr' is 0) or on the address of
1642 the relay agent that forwarded the message ('giaddr' when not 0).
1643
1644 As described in <a href="#section-4.2">section 4.2</a>, a server MAY, for administrative
1645 reasons, assign an address other than the one requested, or may
1646 refuse to allocate an address to a particular client even though free
1647 addresses are available.
1648
1649 Note that, in some network architectures (e.g., internets with more
1650 than one IP subnet assigned to a physical network segment), it may be
1651 the case that the DHCP client should be assigned an address from a
1652 different subnet than the address recorded in 'giaddr'. Thus, DHCP
1653 does not require that the client be assigned as address from the
1654 subnet in 'giaddr'. A server is free to choose some other subnet,
1655 and it is beyond the scope of the DHCP specification to describe ways
1656 in which the assigned IP address might be chosen.
1657
1658 While not required for correct operation of DHCP, the server SHOULD
1659 NOT reuse the selected network address before the client responds to
1660 the server's DHCPOFFER message. The server may choose to record the
1661 address as offered to the client.
1662
1663 The server must also choose an expiration time for the lease, as
1664 follows:
1665
1666
1667
1668<span class="grey">Droms Standards Track [Page 27]</span></pre>
1669<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
1670<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1671
1672
1673 o IF the client has not requested a specific lease in the
1674 DHCPDISCOVER message and the client already has an assigned network
1675 address, the server returns the lease expiration time previously
1676 assigned to that address (note that the client must explicitly
1677 request a specific lease to extend the expiration time on a
1678 previously assigned address), ELSE
1679
1680 o IF the client has not requested a specific lease in the
1681 DHCPDISCOVER message and the client does not have an assigned
1682 network address, the server assigns a locally configured default
1683 lease time, ELSE
1684
1685 o IF the client has requested a specific lease in the DHCPDISCOVER
1686 message (regardless of whether the client has an assigned network
1687 address), the server may choose either to return the requested
1688 lease (if the lease is acceptable to local policy) or select
1689 another lease.
1690
1691Field DHCPOFFER DHCPACK DHCPNAK
1692----- --------- ------- -------
1693'op' BOOTREPLY BOOTREPLY BOOTREPLY
1694'htype' (From "Assigned Numbers" RFC)
1695'hlen' (Hardware address length in octets)
1696'hops' 0 0 0
1697'xid' 'xid' from client 'xid' from client 'xid' from client
1698 DHCPDISCOVER DHCPREQUEST DHCPREQUEST
1699 message message message
1700'secs' 0 0 0
1701'ciaddr' 0 'ciaddr' from 0
1702 DHCPREQUEST or 0
1703'yiaddr' IP address offered IP address 0
1704 to client assigned to client
1705'siaddr' IP address of next IP address of next 0
1706 bootstrap server bootstrap server
1707'flags' 'flags' from 'flags' from 'flags' from
1708 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
1709 message message message
1710'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
1711 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
1712 message message message
1713'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
1714 client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
1715 message message message
1716'sname' Server host name Server host name (unused)
1717 or options or options
1718'file' Client boot file Client boot file (unused)
1719 name or options name or options
1720'options' options options
1721
1722
1723
1724<span class="grey">Droms Standards Track [Page 28]</span></pre>
1725<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
1726<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1727
1728
1729Option DHCPOFFER DHCPACK DHCPNAK
1730------ --------- ------- -------
1731Requested IP address MUST NOT MUST NOT MUST NOT
1732IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
1733 MUST NOT (DHCPINFORM)
1734Use 'file'/'sname' fields MAY MAY MUST NOT
1735DHCP message type DHCPOFFER DHCPACK DHCPNAK
1736Parameter request list MUST NOT MUST NOT MUST NOT
1737Message SHOULD SHOULD SHOULD
1738Client identifier MUST NOT MUST NOT MAY
1739Vendor class identifier MAY MAY MAY
1740Server identifier MUST MUST MUST
1741Maximum message size MUST NOT MUST NOT MUST NOT
1742All others MAY MAY MUST NOT
1743
1744 Table 3: Fields and options used by DHCP servers
1745
1746 Once the network address and lease have been determined, the server
1747 constructs a DHCPOFFER message with the offered configuration
1748 parameters. It is important for all DHCP servers to return the same
1749 parameters (with the possible exception of a newly allocated network
1750 address) to ensure predictable client behavior regardless of which
1751 server the client selects. The configuration parameters MUST be
1752 selected by applying the following rules in the order given below.
1753 The network administrator is responsible for configuring multiple
1754 DHCP servers to ensure uniform responses from those servers. The
1755 server MUST return to the client:
1756
1757 o The client's network address, as determined by the rules given
1758 earlier in this section,
1759
1760 o The expiration time for the client's lease, as determined by the
1761 rules given earlier in this section,
1762
1763 o Parameters requested by the client, according to the following
1764 rules:
1765
1766 -- IF the server has been explicitly configured with a default
1767 value for the parameter, the server MUST include that value
1768 in an appropriate option in the 'option' field, ELSE
1769
1770 -- IF the server recognizes the parameter as a parameter
1771 defined in the Host Requirements Document, the server MUST
1772 include the default value for that parameter as given in the
1773 Host Requirements Document in an appropriate option in the
1774 'option' field, ELSE
1775
1776 -- The server MUST NOT return a value for that parameter,
1777
1778
1779
1780<span class="grey">Droms Standards Track [Page 29]</span></pre>
1781<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
1782<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1783
1784
1785 The server MUST supply as many of the requested parameters as
1786 possible and MUST omit any parameters it cannot provide. The
1787 server MUST include each requested parameter only once unless
1788 explicitly allowed in the DHCP Options and BOOTP Vendor
1789 Extensions document.
1790
1791 o Any parameters from the existing binding that differ from the Host
1792 Requirements Document defaults,
1793
1794 o Any parameters specific to this client (as identified by
1795 the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
1796 or DHCPREQUEST message), e.g., as configured by the network
1797 administrator,
1798
1799 o Any parameters specific to this client's class (as identified
1800 by the contents of the 'vendor class identifier'
1801 option in the DHCPDISCOVER or DHCPREQUEST message),
1802 e.g., as configured by the network administrator; the parameters
1803 MUST be identified by an exact match between the client's vendor
1804 class identifiers and the client's classes identified in the
1805 server,
1806
1807 o Parameters with non-default values on the client's subnet.
1808
1809 The server MAY choose to return the 'vendor class identifier' used to
1810 determine the parameters in the DHCPOFFER message to assist the
1811 client in selecting which DHCPOFFER to accept. The server inserts
1812 the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
1813 the DHCPOFFER message and sends the DHCPOFFER message to the
1814 requesting client.
1815
1816<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a> DHCPREQUEST message</span>
1817
1818 A DHCPREQUEST message may come from a client responding to a
1819 DHCPOFFER message from a server, from a client verifying a previously
1820 allocated IP address or from a client extending the lease on a
1821 network address. If the DHCPREQUEST message contains a 'server
1822 identifier' option, the message is in response to a DHCPOFFER
1823 message. Otherwise, the message is a request to verify or extend an
1824 existing lease. If the client uses a 'client identifier' in a
1825 DHCPREQUEST message, it MUST use that same 'client identifier' in all
1826 subsequent messages. If the client included a list of requested
1827 parameters in a DHCPDISCOVER message, it MUST include that list in
1828 all subsequent messages.
1829
1830
1831
1832
1833
1834
1835
1836<span class="grey">Droms Standards Track [Page 30]</span></pre>
1837<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
1838<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1839
1840
1841 Any configuration parameters in the DHCPACK message SHOULD NOT
1842 conflict with those in the earlier DHCPOFFER message to which the
1843 client is responding. The client SHOULD use the parameters in the
1844 DHCPACK message for configuration.
1845
1846 Clients send DHCPREQUEST messages as follows:
1847
1848 o DHCPREQUEST generated during SELECTING state:
1849
1850 Client inserts the address of the selected server in 'server
1851 identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
1852 filled in with the yiaddr value from the chosen DHCPOFFER.
1853
1854 Note that the client may choose to collect several DHCPOFFER
1855 messages and select the "best" offer. The client indicates its
1856 selection by identifying the offering server in the DHCPREQUEST
1857 message. If the client receives no acceptable offers, the client
1858 may choose to try another DHCPDISCOVER message. Therefore, the
1859 servers may not receive a specific DHCPREQUEST from which they can
1860 decide whether or not the client has accepted the offer. Because
1861 the servers have not committed any network address assignments on
1862 the basis of a DHCPOFFER, servers are free to reuse offered
1863 network addresses in response to subsequent requests. As an
1864 implementation detail, servers SHOULD NOT reuse offered addresses
1865 and may use an implementation-specific timeout mechanism to decide
1866 when to reuse an offered address.
1867
1868 o DHCPREQUEST generated during INIT-REBOOT state:
1869
1870 'server identifier' MUST NOT be filled in, 'requested IP address'
1871 option MUST be filled in with client's notion of its previously
1872 assigned address. 'ciaddr' MUST be zero. The client is seeking to
1873 verify a previously allocated, cached configuration. Server SHOULD
1874 send a DHCPNAK message to the client if the 'requested IP address'
1875 is incorrect, or is on the wrong network.
1876
1877 Determining whether a client in the INIT-REBOOT state is on the
1878 correct network is done by examining the contents of 'giaddr', the
1879 'requested IP address' option, and a database lookup. If the DHCP
1880 server detects that the client is on the wrong net (i.e., the
1881 result of applying the local subnet mask or remote subnet mask (if
1882 'giaddr' is not zero) to 'requested IP address' option value
1883 doesn't match reality), then the server SHOULD send a DHCPNAK
1884 message to the client.
1885
1886
1887
1888
1889
1890
1891
1892<span class="grey">Droms Standards Track [Page 31]</span></pre>
1893<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
1894<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1895
1896
1897 If the network is correct, then the DHCP server should check if
1898 the client's notion of its IP address is correct. If not, then the
1899 server SHOULD send a DHCPNAK message to the client. If the DHCP
1900 server has no record of this client, then it MUST remain silent,
1901 and MAY output a warning to the network administrator. This
1902 behavior is necessary for peaceful coexistence of non-
1903 communicating DHCP servers on the same wire.
1904
1905 If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
1906 the same subnet as the server. The server MUST broadcast the
1907 DHCPNAK message to the 0xffffffff broadcast address because the
1908 client may not have a correct network address or subnet mask, and
1909 the client may not be answering ARP requests.
1910
1911 If 'giaddr' is set in the DHCPREQUEST message, the client is on a
1912 different subnet. The server MUST set the broadcast bit in the
1913 DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
1914 client, because the client may not have a correct network address
1915 or subnet mask, and the client may not be answering ARP requests.
1916
1917 o DHCPREQUEST generated during RENEWING state:
1918
1919 'server identifier' MUST NOT be filled in, 'requested IP address'
1920 option MUST NOT be filled in, 'ciaddr' MUST be filled in with
1921 client's IP address. In this situation, the client is completely
1922 configured, and is trying to extend its lease. This message will
1923 be unicast, so no relay agents will be involved in its
1924 transmission. Because 'giaddr' is therefore not filled in, the
1925 DHCP server will trust the value in 'ciaddr', and use it when
1926 replying to the client.
1927
1928 A client MAY choose to renew or extend its lease prior to T1. The
1929 server may choose not to extend the lease (as a policy decision by
1930 the network administrator), but should return a DHCPACK message
1931 regardless.
1932
1933 o DHCPREQUEST generated during REBINDING state:
1934
1935 'server identifier' MUST NOT be filled in, 'requested IP address'
1936 option MUST NOT be filled in, 'ciaddr' MUST be filled in with
1937 client's IP address. In this situation, the client is completely
1938 configured, and is trying to extend its lease. This message MUST
1939 be broadcast to the 0xffffffff IP broadcast address. The DHCP
1940 server SHOULD check 'ciaddr' for correctness before replying to
1941 the DHCPREQUEST.
1942
1943
1944
1945
1946
1947
1948<span class="grey">Droms Standards Track [Page 32]</span></pre>
1949<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
1950<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
1951
1952
1953 The DHCPREQUEST from a REBINDING client is intended to accommodate
1954 sites that have multiple DHCP servers and a mechanism for
1955 maintaining consistency among leases managed by multiple servers.
1956 A DHCP server MAY extend a client's lease only if it has local
1957 administrative authority to do so.
1958
1959<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a> DHCPDECLINE message</span>
1960
1961 If the server receives a DHCPDECLINE message, the client has
1962 discovered through some other means that the suggested network
1963 address is already in use. The server MUST mark the network address
1964 as not available and SHOULD notify the local system administrator of
1965 a possible configuration problem.
1966
1967<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a> DHCPRELEASE message</span>
1968
1969 Upon receipt of a DHCPRELEASE message, the server marks the network
1970 address as not allocated. The server SHOULD retain a record of the
1971 client's initialization parameters for possible reuse in response to
1972 subsequent requests from the client.
1973
1974<span class="h4"><a class="selflink" id="section-4.3.5" href="#section-4.3.5">4.3.5</a> DHCPINFORM message</span>
1975
1976 The server responds to a DHCPINFORM message by sending a DHCPACK
1977 message directly to the address given in the 'ciaddr' field of the
1978 DHCPINFORM message. The server MUST NOT send a lease expiration time
1979 to the client and SHOULD NOT fill in 'yiaddr'. The server includes
1980 other parameters in the DHCPACK message as defined in <a href="#section-4.3.1">section 4.3.1</a>.
1981
1982<span class="h4"><a class="selflink" id="section-4.3.6" href="#section-4.3.6">4.3.6</a> Client messages</span>
1983
1984 Table 4 details the differences between messages from clients in
1985 various states.
1986
1987 ---------------------------------------------------------------------
1988 | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
1989 ---------------------------------------------------------------------
1990 |broad/unicast |broadcast |broadcast |unicast |broadcast |
1991 |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
1992 |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
1993 |ciaddr |zero |zero |IP address |IP address|
1994 ---------------------------------------------------------------------
1995
1996 Table 4: Client messages from different states
1997
1998
1999
2000
2001
2002
2003
2004<span class="grey">Droms Standards Track [Page 33]</span></pre>
2005<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
2006<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2007
2008
2009<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a> DHCP client behavior</span>
2010
2011 Figure 5 gives a state-transition diagram for a DHCP client. A
2012 client can receive the following messages from a server:
2013
2014 o DHCPOFFER
2015
2016 o DHCPACK
2017
2018 o DHCPNAK
2019
2020 The DHCPINFORM message is not shown in figure 5. A client simply
2021 sends the DHCPINFORM and waits for DHCPACK messages. Once the client
2022 has selected its parameters, it has completed the configuration
2023 process.
2024
2025 Table 5 gives the use of the fields and options in a DHCP message by
2026 a client. The remainder of this section describes the action of the
2027 DHCP client for each possible incoming message. The description in
2028 the following section corresponds to the full configuration procedure
2029 previously described in <a href="#section-3.1">section 3.1</a>, and the text in the subsequent
2030 section corresponds to the abbreviated configuration procedure
2031 described in <a href="#section-3.2">section 3.2</a>.
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060<span class="grey">Droms Standards Track [Page 34]</span></pre>
2061<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
2062<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2063
2064
2065 -------- -------
2066| | +--------------------------&gt;| |&lt;-------------------+
2067| INIT- | | +--------------------&gt;| INIT | |
2068| REBOOT |DHCPNAK/ +----------&gt;| |&lt;---+ |
2069| |Restart| | ------- | |
2070 -------- | DHCPNAK/ | | |
2071 | Discard offer | -/Send DHCPDISCOVER |
2072-/Send DHCPREQUEST | | |
2073 | | | DHCPACK v | |
2074 ----------- | (not accept.)/ ----------- | |
2075| | | Send DHCPDECLINE | | |
2076| REBOOTING | | | | SELECTING |&lt;----+ |
2077| | | / | | |DHCPOFFER/ |
2078 ----------- | / ----------- | |Collect |
2079 | | / | | | replies |
2080DHCPACK/ | / +----------------+ +-------+ |
2081Record lease, set| | v Select offer/ |
2082timers T1, T2 ------------ send DHCPREQUEST | |
2083 | +-----&gt;| | DHCPNAK, Lease expired/ |
2084 | | | REQUESTING | Halt network |
2085 DHCPOFFER/ | | | |
2086 Discard ------------ | |
2087 | | | | ----------- |
2088 | +--------+ DHCPACK/ | | |
2089 | Record lease, set -----| REBINDING | |
2090 | timers T1, T2 / | | |
2091 | | DHCPACK/ ----------- |
2092 | v Record lease, set ^ |
2093 +----------------&gt; ------- /timers T1,T2 | |
2094 +-----&gt;| |&lt;---+ | |
2095 | | BOUND |&lt;---+ | |
2096 DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
2097 DHCPNAK/Discard ------- | Broadcast Halt network
2098 | | | | DHCPREQUEST |
2099 +-------+ | DHCPACK/ | |
2100 T1 expires/ Record lease, set | |
2101 Send DHCPREQUEST timers T1, T2 | |
2102 to leasing server | | |
2103 | ---------- | |
2104 | | |------------+ |
2105 +-&gt;| RENEWING | |
2106 | |----------------------------+
2107 ----------
2108 Figure 5: State-transition diagram for DHCP clients
2109
2110
2111
2112
2113
2114
2115
2116<span class="grey">Droms Standards Track [Page 35]</span></pre>
2117<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
2118<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2119
2120
2121<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a> Initialization and allocation of network address</span>
2122
2123 The client begins in INIT state and forms a DHCPDISCOVER message.
2124 The client SHOULD wait a random time between one and ten seconds to
2125 desynchronize the use of DHCP at startup. The client sets 'ciaddr'
2126 to 0x00000000. The client MAY request specific parameters by
2127 including the 'parameter request list' option. The client MAY
2128 suggest a network address and/or lease time by including the
2129 'requested IP address' and 'IP address lease time' options. The
2130 client MUST include its hardware address in the 'chaddr' field, if
2131 necessary for delivery of DHCP reply messages. The client MAY
2132 include a different unique identifier in the 'client identifier'
2133 option, as discussed in <a href="#section-4.2">section 4.2</a>. If the client included a list
2134 of requested parameters in a DHCPDISCOVER message, it MUST include
2135 that list in all subsequent messages.
2136
2137 The client generates and records a random transaction identifier and
2138 inserts that identifier into the 'xid' field. The client records its
2139 own local time for later use in computing the lease expiration. The
2140 client then broadcasts the DHCPDISCOVER on the local hardware
2141 broadcast address to the 0xffffffff IP broadcast address and 'DHCP
2142 server' UDP port.
2143
2144 If the 'xid' of an arriving DHCPOFFER message does not match the
2145 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
2146 must be silently discarded. Any arriving DHCPACK messages must be
2147 silently discarded.
2148
2149 The client collects DHCPOFFER messages over a period of time, selects
2150 one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
2151 messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
2152 from the previously used server) and extracts the server address from
2153 the 'server identifier' option in the DHCPOFFER message. The time
2154 over which the client collects messages and the mechanism used to
2155 select one DHCPOFFER are implementation dependent.
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172<span class="grey">Droms Standards Track [Page 36]</span></pre>
2173<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
2174<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2175
2176
2177Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
2178 DHCPINFORM DHCPRELEASE
2179----- ------------ ----------- -----------
2180'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
2181'htype' (From "Assigned Numbers" RFC)
2182'hlen' (Hardware address length in octets)
2183'hops' 0 0 0
2184'xid' selected by client 'xid' from server selected by
2185 DHCPOFFER message client
2186'secs' 0 or seconds since 0 or seconds since 0
2187 DHCP process started DHCP process started
2188'flags' Set 'BROADCAST' Set 'BROADCAST' 0
2189 flag if client flag if client
2190 requires broadcast requires broadcast
2191 reply reply
2192'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
2193 client's network address client's network
2194 network address (BOUND/RENEW/REBIND) address
2195 (DHCPINFORM) (DHCPRELEASE)
2196'yiaddr' 0 0 0
2197'siaddr' 0 0 0
2198'giaddr' 0 0 0
2199'chaddr' client's hardware client's hardware client's hardware
2200 address address address
2201'sname' options, if options, if (unused)
2202 indicated in indicated in
2203 'sname/file' 'sname/file'
2204 option; otherwise option; otherwise
2205 unused unused
2206'file' options, if options, if (unused)
2207 indicated in indicated in
2208 'sname/file' 'sname/file'
2209 option; otherwise option; otherwise
2210 unused unused
2211'options' options options (unused)
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228<span class="grey">Droms Standards Track [Page 37]</span></pre>
2229<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
2230<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2231
2232
2233Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
2234 DHCPINFORM DHCPRELEASE
2235------ ------------ ----------- -----------
2236Requested IP address MAY MUST (in MUST
2237 (DISCOVER) SELECTING or (DHCPDECLINE),
2238 MUST NOT INIT-REBOOT) MUST NOT
2239 (INFORM) MUST NOT (in (DHCPRELEASE)
2240 BOUND or
2241 RENEWING)
2242IP address lease time MAY MAY MUST NOT
2243 (DISCOVER)
2244 MUST NOT
2245 (INFORM)
2246Use 'file'/'sname' fields MAY MAY MAY
2247DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
2248 DHCPINFORM DHCPRELEASE
2249Client identifier MAY MAY MAY
2250Vendor class identifier MAY MAY MUST NOT
2251Server identifier MUST NOT MUST (after MUST
2252 SELECTING)
2253 MUST NOT (after
2254 INIT-REBOOT,
2255 BOUND, RENEWING
2256 or REBINDING)
2257Parameter request list MAY MAY MUST NOT
2258Maximum message size MAY MAY MUST NOT
2259Message SHOULD NOT SHOULD NOT SHOULD
2260Site-specific MAY MAY MUST NOT
2261All others MAY MAY MUST NOT
2262
2263 Table 5: Fields and options used by DHCP clients
2264
2265 If the parameters are acceptable, the client records the address of
2266 the server that supplied the parameters from the 'server identifier'
2267 field and sends that address in the 'server identifier' field of a
2268 DHCPREQUEST broadcast message. Once the DHCPACK message from the
2269 server arrives, the client is initialized and moves to BOUND state.
2270 The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
2271 message. The client records the lease expiration time as the sum of
2272 the time at which the original request was sent and the duration of
2273 the lease from the DHCPACK message. The client SHOULD perform a
2274 check on the suggested address to ensure that the address is not
2275 already in use. For example, if the client is on a network that
2276 supports ARP, the client may issue an ARP request for the suggested
2277 request. When broadcasting an ARP request for the suggested address,
2278 the client must fill in its own hardware address as the sender's
2279 hardware address, and 0 as the sender's IP address, to avoid
2280 confusing ARP caches in other hosts on the same subnet. If the
2281
2282
2283
2284<span class="grey">Droms Standards Track [Page 38]</span></pre>
2285<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
2286<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2287
2288
2289 network address appears to be in use, the client MUST send a
2290 DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
2291 reply to announce the client's new IP address and clear any outdated
2292 ARP cache entries in hosts on the client's subnet.
2293
2294<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a> Initialization with known network address</span>
2295
2296 The client begins in INIT-REBOOT state and sends a DHCPREQUEST
2297 message. The client MUST insert its known network address as a
2298 'requested IP address' option in the DHCPREQUEST message. The client
2299 may request specific configuration parameters by including the
2300 'parameter request list' option. The client generates and records a
2301 random transaction identifier and inserts that identifier into the
2302 'xid' field. The client records its own local time for later use in
2303 computing the lease expiration. The client MUST NOT include a
2304 'server identifier' in the DHCPREQUEST message. The client then
2305 broadcasts the DHCPREQUEST on the local hardware broadcast address to
2306 the 'DHCP server' UDP port.
2307
2308 Once a DHCPACK message with an 'xid' field matching that in the
2309 client's DHCPREQUEST message arrives from any server, the client is
2310 initialized and moves to BOUND state. The client records the lease
2311 expiration time as the sum of the time at which the DHCPREQUEST
2312 message was sent and the duration of the lease from the DHCPACK
2313 message.
2314
2315<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a> Initialization with an externally assigned network address</span>
2316
2317 The client sends a DHCPINFORM message. The client may request
2318 specific configuration parameters by including the 'parameter request
2319 list' option. The client generates and records a random transaction
2320 identifier and inserts that identifier into the 'xid' field. The
2321 client places its own network address in the 'ciaddr' field. The
2322 client SHOULD NOT request lease time parameters.
2323
2324 The client then unicasts the DHCPINFORM to the DHCP server if it
2325 knows the server's address, otherwise it broadcasts the message to
2326 the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
2327 directed to the 'DHCP server' UDP port.
2328
2329 Once a DHCPACK message with an 'xid' field matching that in the
2330 client's DHCPINFORM message arrives from any server, the client is
2331 initialized.
2332
2333 If the client does not receive a DHCPACK within a reasonable period
2334 of time (60 seconds or 4 tries if using timeout suggested in <a href="#section-4.1">section</a>
2335 <a href="#section-4.1">4.1</a>), then it SHOULD display a message informing the user of the
2336 problem, and then SHOULD begin network processing using suitable
2337
2338
2339
2340<span class="grey">Droms Standards Track [Page 39]</span></pre>
2341<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
2342<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2343
2344
2345 defaults as per <a href="#appendix-A">Appendix A</a>.
2346
2347<span class="h4"><a class="selflink" id="section-4.4.4" href="#section-4.4.4">4.4.4</a> Use of broadcast and unicast</span>
2348
2349 The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
2350 messages, unless the client knows the address of a DHCP server. The
2351 client unicasts DHCPRELEASE messages to the server. Because the
2352 client is declining the use of the IP address supplied by the server,
2353 the client broadcasts DHCPDECLINE messages.
2354
2355 When the DHCP client knows the address of a DHCP server, in either
2356 INIT or REBOOTING state, the client may use that address in the
2357 DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
2358 The client may also use unicast to send DHCPINFORM messages to a
2359 known DHCP server. If the client receives no response to DHCP
2360 messages sent to the IP address of a known DHCP server, the DHCP
2361 client reverts to using the IP broadcast address.
2362
2363<span class="h4"><a class="selflink" id="section-4.4.5" href="#section-4.4.5">4.4.5</a> Reacquisition and expiration</span>
2364
2365 The client maintains two times, T1 and T2, that specify the times at
2366 which the client tries to extend its lease on its network address.
2367 T1 is the time at which the client enters the RENEWING state and
2368 attempts to contact the server that originally issued the client's
2369 network address. T2 is the time at which the client enters the
2370 REBINDING state and attempts to contact any server. T1 MUST be
2371 earlier than T2, which, in turn, MUST be earlier than the time at
2372 which the client's lease will expire.
2373
2374 To avoid the need for synchronized clocks, T1 and T2 are expressed in
2375 options as relative times [<a href="#ref-2" title="&quot;DHCP Options and BOOTP Vendor Extensions&quot;">2</a>].
2376
2377 At time T1 the client moves to RENEWING state and sends (via unicast)
2378 a DHCPREQUEST message to the server to extend its lease. The client
2379 sets the 'ciaddr' field in the DHCPREQUEST to its current network
2380 address. The client records the local time at which the DHCPREQUEST
2381 message is sent for computation of the lease expiration time. The
2382 client MUST NOT include a 'server identifier' in the DHCPREQUEST
2383 message.
2384
2385 Any DHCPACK messages that arrive with an 'xid' that does not match
2386 the 'xid' of the client's DHCPREQUEST message are silently discarded.
2387 When the client receives a DHCPACK from the server, the client
2388 computes the lease expiration time as the sum of the time at which
2389 the client sent the DHCPREQUEST message and the duration of the lease
2390 in the DHCPACK message. The client has successfully reacquired its
2391 network address, returns to BOUND state and may continue network
2392 processing.
2393
2394
2395
2396<span class="grey">Droms Standards Track [Page 40]</span></pre>
2397<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
2398<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2399
2400
2401 If no DHCPACK arrives before time T2, the client moves to REBINDING
2402 state and sends (via broadcast) a DHCPREQUEST message to extend its
2403 lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
2404 current network address. The client MUST NOT include a 'server
2405 identifier' in the DHCPREQUEST message.
2406
2407 Times T1 and T2 are configurable by the server through options. T1
2408 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
2409 duration_of_lease). Times T1 and T2 SHOULD be chosen with some
2410 random "fuzz" around a fixed value, to avoid synchronization of
2411 client reacquisition.
2412
2413 A client MAY choose to renew or extend its lease prior to T1. The
2414 server MAY choose to extend the client's lease according to policy
2415 set by the network administrator. The server SHOULD return T1 and
2416 T2, and their values SHOULD be adjusted from their original values to
2417 take account of the time remaining on the lease.
2418
2419 In both RENEWING and REBINDING states, if the client receives no
2420 response to its DHCPREQUEST message, the client SHOULD wait one-half
2421 of the remaining time until T2 (in RENEWING state) and one-half of
2422 the remaining lease time (in REBINDING state), down to a minimum of
2423 60 seconds, before retransmitting the DHCPREQUEST message.
2424
2425 If the lease expires before the client receives a DHCPACK, the client
2426 moves to INIT state, MUST immediately stop any other network
2427 processing and requests network initialization parameters as if the
2428 client were uninitialized. If the client then receives a DHCPACK
2429 allocating that client its previous network address, the client
2430 SHOULD continue network processing. If the client is given a new
2431 network address, it MUST NOT continue using the previous network
2432 address and SHOULD notify the local users of the problem.
2433
2434<span class="h4"><a class="selflink" id="section-4.4.6" href="#section-4.4.6">4.4.6</a> DHCPRELEASE</span>
2435
2436 If the client no longer requires use of its assigned network address
2437 (e.g., the client is gracefully shut down), the client sends a
2438 DHCPRELEASE message to the server. Note that the correct operation
2439 of DHCP does not depend on the transmission of DHCPRELEASE messages.
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452<span class="grey">Droms Standards Track [Page 41]</span></pre>
2453<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
2454<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2455
2456
2457<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
2458
2459 The author thanks the many (and too numerous to mention!) members of
2460 the DHC WG for their tireless and ongoing efforts in the development
2461 of DHCP and this document.
2462
2463 The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
2464 Mendonca in organizing DHCP interoperability testing sessions are
2465 gratefully acknowledged.
2466
2467 The development of this document was supported in part by grants from
2468 the Corporation for National Research Initiatives (CNRI), Bucknell
2469 University and Sun Microsystems.
2470
2471<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
2472
2473 [<a id="ref-1">1</a>] Acetta, M., "Resource Location Protocol", <a href="./rfc887">RFC 887</a>, CMU, December
2474 1983.
2475
2476 [<a id="ref-2">2</a>] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
2477 Extensions", <a href="./rfc1533">RFC 1533</a>, Lachman Technology, Inc., Bucknell
2478 University, October 1993.
2479
2480 [<a id="ref-3">3</a>] Braden, R., Editor, "Requirements for Internet Hosts --
2481 Communication Layers", STD 3, <a href="./rfc1122">RFC 1122</a>, USC/Information Sciences
2482 Institute, October 1989.
2483
2484 [<a id="ref-4">4</a>] Braden, R., Editor, "Requirements for Internet Hosts --
2485 Application and Support, STD 3, <a href="./rfc1123">RFC 1123</a>, USC/Information
2486 Sciences Institute, October 1989.
2487
2488 [<a id="ref-5">5</a>] Brownell, D, "Dynamic Reverse Address Resolution Protocol
2489 (DRARP)", Work in Progress.
2490
2491 [<a id="ref-6">6</a>] Comer, D., and R. Droms, "Uniform Access to Internet Directory
2492 Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
2493 Communications Review), 20(4):50--59, 1990.
2494
2495 [<a id="ref-7">7</a>] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", <a href="./rfc951">RFC 951</a>,
2496 Stanford and SUN Microsystems, September 1985.
2497
2498 [<a id="ref-8">8</a>] Deering, S., "ICMP Router Discovery Messages", <a href="./rfc1256">RFC 1256</a>, Xerox
2499 PARC, September 1991.
2500
2501 [<a id="ref-9">9</a>] Droms, D., "Interoperation between DHCP and BOOTP", <a href="./rfc1534">RFC 1534</a>,
2502 Bucknell University, October 1993.
2503
2504
2505
2506
2507
2508<span class="grey">Droms Standards Track [Page 42]</span></pre>
2509<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
2510<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2511
2512
2513 [<a id="ref-10">10</a>] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
2514 Address Resolution Protocol", <a href="./rfc903">RFC 903</a>, Stanford, June 1984.
2515
2516 [<a id="ref-11">11</a>] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
2517 Mechanism for Distributed File Cache Consistency", In Proc. of
2518 the Twelfth ACM Symposium on Operating Systems Design, 1989.
2519
2520 [<a id="ref-12">12</a>] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
2521 13, <a href="./rfc1034">RFC 1034</a>, USC/Information Sciences Institute, November 1987.
2522
2523 [<a id="ref-13">13</a>] Mockapetris, P., "Domain Names -- Implementation and
2524 Specification", STD 13, <a href="./rfc1035">RFC 1035</a>, USC/Information Sciences
2525 Institute, November 1987.
2526
2527 [<a id="ref-14">14</a>] Mogul J., and S. Deering, "Path MTU Discovery", <a href="./rfc1191">RFC 1191</a>,
2528 November 1990.
2529
2530 [<a id="ref-15">15</a>] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
2531 Hosts", Work in Progress.
2532
2533 [<a id="ref-16">16</a>] Postel, J., "Internet Control Message Protocol", STD 5, <a href="./rfc792">RFC 792</a>,
2534 USC/Information Sciences Institute, September 1981.
2535
2536 [<a id="ref-17">17</a>] Reynolds, J., "BOOTP Vendor Information Extensions", <a href="./rfc1497">RFC 1497</a>,
2537 USC/Information Sciences Institute, August 1993.
2538
2539 [<a id="ref-18">18</a>] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, <a href="./rfc1700">RFC 1700</a>,
2540 USC/Information Sciences Institute, October 1994.
2541
2542 [<a id="ref-19">19</a>] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
2543 Assignment of IP Addresses for use on an Ethernet. (Available
2544 from the Athena Project, MIT), 1989.
2545
2546 [<a id="ref-20">20</a>] Sollins, K., "The TFTP Protocol (Revision 2)", <a href="./rfc783">RFC 783</a>, NIC,
2547 June 1981.
2548
2549 [<a id="ref-21">21</a>] Wimer, W., "Clarifications and Extensions for the Bootstrap
2550 Protocol", <a href="./rfc1542">RFC 1542</a>, Carnegie Mellon University, October 1993.
2551
2552<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
2553
2554 DHCP is built directly on UDP and IP which are as yet inherently
2555 insecure. Furthermore, DHCP is generally intended to make
2556 maintenance of remote and/or diskless hosts easier. While perhaps
2557 not impossible, configuring such hosts with passwords or keys may be
2558 difficult and inconvenient. Therefore, DHCP in its current form is
2559 quite insecure.
2560
2561
2562
2563
2564<span class="grey">Droms Standards Track [Page 43]</span></pre>
2565<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
2566<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2567
2568
2569 Unauthorized DHCP servers may be easily set up. Such servers can
2570 then send false and potentially disruptive information to clients
2571 such as incorrect or duplicate IP addresses, incorrect routing
2572 information (including spoof routers, etc.), incorrect domain
2573 nameserver addresses (such as spoof nameservers), and so on.
2574 Clearly, once this seed information is in place, an attacker can
2575 further compromise affected systems.
2576
2577 Malicious DHCP clients could masquerade as legitimate clients and
2578 retrieve information intended for those legitimate clients. Where
2579 dynamic allocation of resources is used, a malicious client could
2580 claim all resources for itself, thereby denying resources to
2581 legitimate clients.
2582
2583<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Author's Address</span>
2584
2585 Ralph Droms
2586 Computer Science Department
2587 323 Dana Engineering
2588 Bucknell University
2589 Lewisburg, PA 17837
2590
2591 Phone: (717) 524-1145
2592 EMail: [email protected]
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620<span class="grey">Droms Standards Track [Page 44]</span></pre>
2621<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
2622<span class="grey"><a href="./rfc2131">RFC 2131</a> Dynamic Host Configuration Protocol March 1997</span>
2623
2624
2625<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">A</a>. Host Configuration Parameters</span>
2626
2627 IP-layer_parameters,_per_host:_
2628
2629 Be a router on/off HRC 3.1
2630 Non-local source routing on/off HRC 3.3.5
2631 Policy filters for
2632 non-local source routing (list) HRC 3.3.5
2633 Maximum reassembly size integer HRC 3.3.2
2634 Default TTL integer HRC 3.2.1.7
2635 PMTU aging timeout integer MTU 6.6
2636 MTU plateau table (list) MTU 7
2637 IP-layer_parameters,_per_interface:_
2638 IP address (address) HRC 3.3.1.6
2639 Subnet mask (address mask) HRC 3.3.1.6
2640 MTU integer HRC 3.3.3
2641 All-subnets-MTU on/off HRC 3.3.3
2642 Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
2643 Perform mask discovery on/off HRC 3.2.2.9
2644 Be a mask supplier on/off HRC 3.2.2.9
2645 Perform router discovery on/off RD 5.1
2646 Router solicitation address (address) RD 5.1
2647 Default routers, list of:
2648 router address (address) HRC 3.3.1.6
2649 preference level integer HRC 3.3.1.6
2650 Static routes, list of:
2651 destination (host/subnet/net) HRC 3.3.1.2
2652 destination mask (address mask) HRC 3.3.1.2
2653 type-of-service integer HRC 3.3.1.2
2654 first-hop router (address) HRC 3.3.1.2
2655 ignore redirects on/off HRC 3.3.1.2
2656 PMTU integer MTU 6.6
2657 perform PMTU discovery on/off MTU 6.6
2658
2659 Link-layer_parameters,_per_interface:_
2660 Trailers on/off HRC 2.3.1
2661 ARP cache timeout integer HRC 2.3.2.1
2662 Ethernet encapsulation (<a href="./rfc894">RFC 894</a>/RFC 1042) HRC 2.3.3
2663
2664 TCP_parameters,_per_host:_
2665 TTL integer HRC 4.2.2.19
2666 Keep-alive interval integer HRC 4.2.3.6
2667 Keep-alive data size 0/1 HRC 4.2.3.6
2668
2669Key:
2670
2671 MTU = Path MTU Discovery (<a href="./rfc1191">RFC 1191</a>, Proposed Standard)
2672 RD = Router Discovery (<a href="./rfc1256">RFC 1256</a>, Proposed Standard)
2673
2674
2675
2676Droms Standards Track [Page 45]
2677</pre>
2678
2679</body>
2680</html>
2681
diff --git a/src/dhcp.rs b/src/dhcp.rs
new file mode 100644
index 0000000..b53ee92
--- /dev/null
+++ b/src/dhcp.rs
@@ -0,0 +1,214 @@
1use std::{
2 io::{Result, Write},
3 net::Ipv4Addr,
4};
5
6use crate::wire;
7
8const MAGIC_COOKIE: [u8; 4] = [0x63, 0x82, 0x53, 0x63];
9
10#[derive(Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
11pub enum BootOp {
12 #[default]
13 Request,
14 Reply,
15}
16
17impl BootOp {
18 pub const OP_REQUEST: u8 = 1;
19 pub const OP_REPLY: u8 = 2;
20}
21
22impl From<BootOp> for u8 {
23 fn from(value: BootOp) -> Self {
24 match value {
25 BootOp::Request => BootOp::OP_REQUEST,
26 BootOp::Reply => BootOp::OP_REPLY,
27 }
28 }
29}
30
31#[derive(Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
32pub enum HardwareType {
33 #[default]
34 Ethernet,
35}
36
37impl HardwareType {
38 pub const TYPE_ETHER: u8 = 1;
39 pub const LEN_ETHER: u8 = 6;
40
41 pub fn hardware_len(&self) -> u8 {
42 match self {
43 HardwareType::Ethernet => Self::LEN_ETHER,
44 }
45 }
46}
47
48impl From<HardwareType> for u8 {
49 fn from(value: HardwareType) -> Self {
50 match value {
51 HardwareType::Ethernet => HardwareType::TYPE_ETHER,
52 }
53 }
54}
55
56#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
57pub enum DhcpMessageType {
58 Ack,
59}
60
61impl DhcpMessageType {
62 pub const CODE_ACK: u8 = 5;
63
64 pub fn code(&self) -> u8 {
65 match self {
66 DhcpMessageType::Ack => Self::CODE_ACK,
67 }
68 }
69}
70
71#[derive(Debug, Clone)]
72pub enum DhcpOption {
73 Pad,
74 End,
75 MessageType(DhcpMessageType),
76 ServerIdentifier(Ipv4Addr),
77 VendorClassIdentifier(String),
78 TftpServerName(String),
79 TftpFileName(String),
80 UserClassInformation(String),
81 ClientMachineIdentifier(String),
82 Unknown { code: u8, data: Vec<u8> },
83}
84
85impl DhcpOption {
86 pub const CODE_PAD: u8 = 0;
87 pub const CODE_END: u8 = 255;
88 pub const CODE_DHCP_MESSAGE_TYPE: u8 = 53;
89 pub const CODE_DHCP_SERVER_IDENTIFIER: u8 = 54;
90 pub const CODE_VENDOR_CLASS_IDENTIFIER: u8 = 60;
91 pub const CODE_TFTP_SERVER_NAME: u8 = 66;
92 pub const CODE_TFTP_FILE_NAME: u8 = 67;
93 pub const CODE_USER_CLASS_INFORMATION: u8 = 77;
94 pub const CODE_CLIENT_MACHINE_IDENTIFIER: u8 = 97;
95
96 pub fn code(&self) -> u8 {
97 match self {
98 DhcpOption::Pad => Self::CODE_PAD,
99 DhcpOption::End => Self::CODE_END,
100 DhcpOption::MessageType(_) => Self::CODE_DHCP_MESSAGE_TYPE,
101 DhcpOption::ServerIdentifier(_) => Self::CODE_DHCP_SERVER_IDENTIFIER,
102 DhcpOption::VendorClassIdentifier(_) => Self::CODE_VENDOR_CLASS_IDENTIFIER,
103 DhcpOption::TftpServerName(_) => Self::CODE_TFTP_SERVER_NAME,
104 DhcpOption::TftpFileName(_) => Self::CODE_TFTP_FILE_NAME,
105 DhcpOption::UserClassInformation(_) => Self::CODE_USER_CLASS_INFORMATION,
106 DhcpOption::ClientMachineIdentifier(_) => Self::CODE_CLIENT_MACHINE_IDENTIFIER,
107 DhcpOption::Unknown { code, .. } => *code,
108 }
109 }
110}
111
112#[derive(Debug)]
113pub struct DhcpPacket {
114 pub op: BootOp,
115 pub htype: HardwareType,
116 pub xid: u32,
117 pub secs: u16,
118 pub flags: u16,
119 pub ciaddr: Ipv4Addr,
120 pub yiaddr: Ipv4Addr,
121 pub siaddr: Ipv4Addr,
122 pub giaddr: Ipv4Addr,
123 pub chaddr: [u8; 16],
124 // server host name
125 pub sname: Option<String>,
126 // boot file name
127 pub file: Option<String>,
128 pub options: Vec<DhcpOption>,
129}
130
131impl Default for DhcpPacket {
132 fn default() -> Self {
133 Self {
134 op: Default::default(),
135 htype: Default::default(),
136 xid: Default::default(),
137 secs: Default::default(),
138 flags: Default::default(),
139 ciaddr: Ipv4Addr::UNSPECIFIED,
140 yiaddr: Ipv4Addr::UNSPECIFIED,
141 siaddr: Ipv4Addr::UNSPECIFIED,
142 giaddr: Ipv4Addr::UNSPECIFIED,
143 chaddr: Default::default(),
144 sname: Default::default(),
145 file: Default::default(),
146 options: Default::default(),
147 }
148 }
149}
150
151pub fn write_packet<W: Write>(mut writer: W, packet: &DhcpPacket) -> Result<()> {
152 wire::write_u8(&mut writer, u8::from(packet.op))?;
153 wire::write_u8(&mut writer, u8::from(packet.htype))?;
154 wire::write_u8(&mut writer, packet.htype.hardware_len())?;
155 wire::write_u8(&mut writer, 0)?; // hops
156 wire::write_u32(&mut writer, packet.xid)?;
157 wire::write_u16(&mut writer, packet.secs)?;
158 wire::write_u16(&mut writer, packet.flags)?;
159 wire::write_ipv4(&mut writer, packet.ciaddr)?;
160 wire::write_ipv4(&mut writer, packet.yiaddr)?;
161 wire::write_ipv4(&mut writer, packet.siaddr)?;
162 wire::write_ipv4(&mut writer, packet.giaddr)?;
163 wire::write(&mut writer, &packet.chaddr)?;
164 match &packet.sname {
165 Some(name) => wire::write_null_terminated_string(&mut writer, &name)?,
166 None => wire::write_null_terminated_string(&mut writer, "")?,
167 };
168 match &packet.file {
169 Some(name) => wire::write_null_terminated_string(&mut writer, &name)?,
170 None => wire::write_null_terminated_string(&mut writer, "")?,
171 };
172 wire::write(&mut writer, &MAGIC_COOKIE)?;
173 for option in &packet.options {
174 write_option(&mut writer, option)?;
175 }
176 write_option(&mut writer, &DhcpOption::End)?;
177 Ok(())
178}
179
180pub fn write_option<W: Write>(mut writer: W, option: &DhcpOption) -> Result<()> {
181 wire::write_u8(&mut writer, option.code())?;
182 match option {
183 DhcpOption::Pad | DhcpOption::End => {}
184 DhcpOption::MessageType(t) => {
185 wire::write_u8(&mut writer, 1)?;
186 wire::write_u8(&mut writer, t.code())?;
187 }
188 DhcpOption::ServerIdentifier(ip) => {
189 wire::write_u8(&mut writer, 4)?;
190 wire::write_ipv4(&mut writer, *ip)?;
191 }
192 DhcpOption::VendorClassIdentifier(vendor_class) => {
193 write_option_len_prefixed_string(&mut writer, &vendor_class)?
194 }
195 DhcpOption::TftpServerName(name) => write_option_len_prefixed_string(&mut writer, &name)?,
196 DhcpOption::TftpFileName(name) => write_option_len_prefixed_string(&mut writer, &name)?,
197 DhcpOption::UserClassInformation(user_class) => {
198 write_option_len_prefixed_string(&mut writer, &user_class)?
199 }
200 DhcpOption::ClientMachineIdentifier(identifier) => {
201 write_option_len_prefixed_string(&mut writer, &identifier)?
202 }
203 DhcpOption::Unknown { data, .. } => {
204 wire::write_u8(&mut writer, u8::try_from(data.len()).unwrap())?;
205 wire::write(&mut writer, &data)?;
206 }
207 }
208 Ok(())
209}
210
211fn write_option_len_prefixed_string<W: Write>(mut writer: W, s: &str) -> Result<()> {
212 wire::write_u8(&mut writer, u8::try_from(s.len()).unwrap())?;
213 wire::write(&mut writer, s.as_bytes())
214}
diff --git a/src/main.rs b/src/main.rs
index 87ea283..3d86a8e 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -1,3 +1,8 @@
1#![feature(cursor_split)]
2pub mod dhcp;
3pub mod tftp;
4pub mod wire;
5
1use std::io::{BufRead, Cursor, Read, Result, Write}; 6use std::io::{BufRead, Cursor, Read, Result, Write};
2use std::net::{Ipv4Addr, SocketAddr, SocketAddrV4, UdpSocket}; 7use std::net::{Ipv4Addr, SocketAddr, SocketAddrV4, UdpSocket};
3 8
@@ -15,7 +20,7 @@ const MAGIC_COOKIE: [u8; 4] = [0x63, 0x82, 0x53, 0x63];
15const BOOT_FILE_NAME: &[u8] = b"ipxe.efi"; 20const BOOT_FILE_NAME: &[u8] = b"ipxe.efi";
16const BOOT_FILE_NAME_IPXE: &[u8] = b"test.ipxe"; 21const BOOT_FILE_NAME_IPXE: &[u8] = b"test.ipxe";
17 22
18const LOCAL_IPV4: Ipv4Addr = Ipv4Addr::new(192, 168, 2, 184); 23const LOCAL_IPV4: Ipv4Addr = Ipv4Addr::new(192, 168, 1, 100);
19 24
20#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)] 25#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
21enum BootOp { 26enum BootOp {
diff --git a/src/tftp.rs b/src/tftp.rs
new file mode 100644
index 0000000..becaa65
--- /dev/null
+++ b/src/tftp.rs
@@ -0,0 +1,365 @@
1use std::{
2 io::{Cursor, Read as _, Result, Write},
3 net::UdpSocket,
4 path::{Path, PathBuf},
5 str::FromStr,
6};
7
8use crate::wire;
9
10pub const PORT: u16 = 69;
11
12#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
13pub struct InvalidTftpOp(u16);
14
15impl std::fmt::Display for InvalidTftpOp {
16 fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
17 write!(f, "invalid tftp opcode '{}'", self.0)
18 }
19}
20
21impl std::error::Error for InvalidTftpOp {}
22#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
23pub enum TftpOp {
24 ReadRequest,
25 WriteRequest,
26 Data,
27 Ack,
28 Error,
29 Oack,
30}
31
32impl Into<u16> for TftpOp {
33 fn into(self) -> u16 {
34 match self {
35 TftpOp::ReadRequest => 1,
36 TftpOp::WriteRequest => 2,
37 TftpOp::Data => 3,
38 TftpOp::Ack => 4,
39 TftpOp::Error => 5,
40 TftpOp::Oack => 6,
41 }
42 }
43}
44
45impl TryFrom<u16> for TftpOp {
46 type Error = InvalidTftpOp;
47
48 fn try_from(value: u16) -> std::result::Result<Self, InvalidTftpOp> {
49 match value {
50 1 => Ok(Self::ReadRequest),
51 2 => Ok(Self::WriteRequest),
52 3 => Ok(Self::Data),
53 4 => Ok(Self::Ack),
54 5 => Ok(Self::Error),
55 6 => Ok(Self::Oack),
56 unknown => Err(InvalidTftpOp(unknown)),
57 }
58 }
59}
60
61#[derive(Debug)]
62pub struct InvalidTftpMode(String);
63
64impl std::fmt::Display for InvalidTftpMode {
65 fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
66 write!(f, "invalid tftp mode '{}'", self.0)
67 }
68}
69
70impl std::error::Error for InvalidTftpMode {}
71
72#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
73pub enum TftpMode {
74 NetAscii,
75 Octet,
76 Mail,
77}
78
79impl FromStr for TftpMode {
80 type Err = InvalidTftpMode;
81
82 fn from_str(s: &str) -> std::result::Result<Self, Self::Err> {
83 match s.to_lowercase().as_str() {
84 "netascii" => Ok(Self::NetAscii),
85 "octet" => Ok(Self::Octet),
86 "mail" => Ok(Self::Mail),
87 _ => Err(InvalidTftpMode(s.to_string())),
88 }
89 }
90}
91
92#[derive(Debug)]
93pub enum TftpPacket {
94 Request(TftpRequestPacket),
95 Data(TftpDataPacket),
96 Ack(TftpAckPacket),
97 OAck(TftpOAckPacket),
98 Error(TftpErrorPacket),
99}
100
101impl TftpPacket {
102 pub fn write<W: Write>(&self, writer: W) -> Result<()> {
103 match self {
104 TftpPacket::Request(p) => p.write(writer),
105 TftpPacket::Data(p) => p.write(writer),
106 TftpPacket::Ack(p) => p.write(writer),
107 TftpPacket::OAck(p) => p.write(writer),
108 TftpPacket::Error(p) => p.write(writer),
109 }
110 }
111}
112
113#[derive(Debug)]
114pub struct TftpRequestPacket {
115 pub filename: String,
116 pub mode: TftpMode,
117 pub tsize: Option<u64>,
118 pub blksize: Option<u64>,
119}
120
121impl TftpRequestPacket {
122 pub fn write<W: Write>(&self, mut writer: W) -> Result<()> {
123 todo!()
124 }
125}
126
127#[derive(Debug)]
128pub struct TftpDataPacket {
129 pub block: u16,
130 pub data: Vec<u8>,
131}
132
133impl TftpDataPacket {
134 pub fn write<W: Write>(&self, mut writer: W) -> Result<()> {
135 wire::write_u16(&mut writer, TftpOp::Data.into())?;
136 wire::write_u16(&mut writer, self.block)?;
137 wire::write(&mut writer, &self.data)?;
138 Ok(())
139 }
140}
141
142#[derive(Debug)]
143pub struct TftpAckPacket {
144 pub block: u16,
145}
146
147impl TftpAckPacket {
148 pub fn write<W: Write>(&self, mut writer: W) -> Result<()> {
149 wire::write_u16(&mut writer, TftpOp::Data.into())?;
150 wire::write_u16(&mut writer, self.block)?;
151 Ok(())
152 }
153}
154
155#[derive(Debug)]
156pub struct TftpOAckPacket {
157 pub tsize: Option<u64>,
158 pub blksize: Option<u64>,
159}
160
161impl TftpOAckPacket {
162 pub fn write<W: Write>(&self, mut writer: W) -> Result<()> {
163 wire::write_u16(&mut writer, TftpOp::Oack.into())?;
164
165 // Only include options that were requested by the client
166 if let Some(blksize_val) = self.blksize {
167 wire::write(&mut writer, b"blksize")?;
168 wire::write_u8(&mut writer, 0)?; // null terminator
169 let blksize_str = blksize_val.to_string();
170 wire::write(&mut writer, blksize_str.as_bytes())?;
171 wire::write_u8(&mut writer, 0)?; // null terminator
172 }
173
174 if let Some(tsize_val) = self.tsize {
175 wire::write(&mut writer, b"tsize")?;
176 wire::write_u8(&mut writer, 0)?; // null terminator
177 let tsize_str = tsize_val.to_string();
178 wire::write(&mut writer, tsize_str.as_bytes())?;
179 wire::write_u8(&mut writer, 0)?; // null terminator
180 }
181
182 Ok(())
183 }
184}
185
186#[derive(Debug)]
187pub struct TftpErrorPacket {
188 pub code: u16,
189 pub message: String,
190}
191
192impl TftpErrorPacket {
193 pub fn write<W: Write>(&self, mut writer: W) -> Result<()> {
194 wire::write_u16(&mut writer, TftpOp::Error.into())?;
195 wire::write_u16(&mut writer, self.code)?;
196 wire::write_null_terminated_string(&mut writer, &self.message)?;
197 Ok(())
198 }
199}
200
201pub fn parse_packet(buf: &[u8]) -> Result<TftpPacket> {
202 let mut cursor = Cursor::new(buf);
203 let op = TftpOp::try_from(wire::read_u16(&mut cursor)?).unwrap();
204
205 match op {
206 TftpOp::ReadRequest => {
207 let filename = wire::read_null_terminated_string(&mut cursor)?;
208 let mode = wire::read_null_terminated_string(&mut cursor)?
209 .parse::<TftpMode>()
210 .unwrap();
211
212 let mut tsize = None;
213 let mut blksize = None;
214
215 while let Ok(opt_name) = wire::read_null_terminated_string(&mut cursor) {
216 if opt_name.is_empty() {
217 break;
218 }
219 let opt_data = wire::read_null_terminated_string(&mut cursor)?;
220 match opt_name.as_str() {
221 "tsize" => tsize = Some(opt_data.parse::<u64>().unwrap()),
222 "blksize" => blksize = Some(opt_data.parse::<u64>().unwrap()),
223 _ => eprintln!("unknown tftp request option '{opt_name}'"),
224 }
225 }
226
227 Ok(TftpPacket::Request(TftpRequestPacket {
228 filename,
229 mode,
230 tsize,
231 blksize,
232 }))
233 }
234 TftpOp::WriteRequest => unimplemented!(),
235 TftpOp::Data => {
236 let block = wire::read_u16(&mut cursor)?;
237 let mut data = Vec::new();
238 cursor.read_to_end(&mut data)?;
239 Ok(TftpPacket::Data(TftpDataPacket { block, data }))
240 }
241 TftpOp::Ack => {
242 let block = wire::read_u16(&mut cursor)?;
243 Ok(TftpPacket::Ack(TftpAckPacket { block }))
244 }
245 TftpOp::Error => {
246 let code = wire::read_u16(&mut cursor)?;
247 let message = wire::read_null_terminated_string(&mut cursor)?;
248 Ok(TftpPacket::Error(TftpErrorPacket { code, message }))
249 }
250 TftpOp::Oack => {
251 let mut tsize = None;
252 let mut blksize = None;
253
254 while let Ok(opt_name) = wire::read_null_terminated_string(&mut cursor) {
255 if opt_name.is_empty() {
256 break;
257 }
258 let opt_data = wire::read_null_terminated_string(&mut cursor)?;
259 match opt_name.as_str() {
260 "tsize" => tsize = Some(opt_data.parse::<u64>().unwrap()),
261 "blksize" => blksize = Some(opt_data.parse::<u64>().unwrap()),
262 _ => eprintln!("unknown tftp ack option '{opt_name}'"),
263 }
264 }
265 Ok(TftpPacket::OAck(TftpOAckPacket { tsize, blksize }))
266 }
267 }
268}
269
270pub fn serve(dir: &Path) -> Result<()> {
271 let socket = UdpSocket::bind(format!("0.0.0.0:{PORT}"))?;
272
273 // TODO: this needs to be done per addr
274 let mut last_blksize = 512u64;
275 let mut current_file = PathBuf::default();
276
277 loop {
278 let mut buf = [0u8; 1500];
279 let (n, addr) = socket.recv_from(&mut buf)?;
280 let packet = parse_packet(&buf[..n]).unwrap();
281
282 let response = match packet {
283 TftpPacket::Request(req) => {
284 println!(
285 "Request options: tsize={:?}, blksize={:?}",
286 req.tsize, req.blksize
287 );
288
289 let filepath = dir.join(req.filename);
290 current_file = filepath.clone();
291 let meta = std::fs::metadata(&filepath).unwrap();
292 let actual_file_size = meta.len();
293
294 // Only send OACK if client sent options
295 if req.tsize.is_some() || req.blksize.is_some() {
296 if let Some(blksize) = req.blksize {
297 last_blksize = blksize;
298 }
299
300 let tsize_response = if req.tsize.is_some() {
301 Some(actual_file_size)
302 } else {
303 None
304 };
305
306 Some(TftpPacket::OAck(TftpOAckPacket {
307 tsize: req.tsize,
308 blksize: req.blksize,
309 }))
310 } else {
311 // No options, send first data block directly
312 let contents = std::fs::read(&filepath).unwrap();
313 let block_size = 512;
314 let first_block = if contents.len() > block_size {
315 contents[..block_size].to_vec()
316 } else {
317 contents
318 };
319
320 Some(TftpPacket::Data(TftpDataPacket {
321 block: 1,
322 data: first_block,
323 }))
324 }
325 }
326 TftpPacket::Data(dat) => unimplemented!(),
327 TftpPacket::Ack(ack) => {
328 println!("Received ACK packet: block {}", ack.block);
329
330 let contents = std::fs::read(&current_file).unwrap();
331 let next_block = ack.block + 1;
332 let start_offset = (next_block - 1) as u64 * last_blksize;
333 let end_offset = next_block as u64 * last_blksize;
334 let prev_start_offset = (next_block.saturating_sub(2)) as u64 * last_blksize;
335 let prev_remain = contents.len() - prev_start_offset as usize;
336 if prev_remain as u64 >= last_blksize || ack.block == 0 {
337 let end = std::cmp::min(end_offset as usize, contents.len());
338 let block_data = contents[start_offset as usize..end].to_vec();
339 println!("sending tftp data packet with {} bytes", block_data.len());
340 Some(TftpPacket::Data(TftpDataPacket {
341 block: next_block,
342 data: block_data,
343 }))
344 } else {
345 None
346 }
347 }
348 TftpPacket::OAck(ack) => todo!(),
349 TftpPacket::Error(err) => {
350 println!(
351 "Received ERROR packet: code {}, message: {}",
352 err.code, err.message
353 );
354 None
355 }
356 };
357
358 if let Some(response) = response {
359 let mut writer = Cursor::new(&mut buf[..]);
360 response.write(&mut writer).unwrap();
361 let (response, _) = writer.split();
362 socket.send_to(&response, addr).unwrap();
363 }
364 }
365}
diff --git a/src/wire.rs b/src/wire.rs
new file mode 100644
index 0000000..dda7690
--- /dev/null
+++ b/src/wire.rs
@@ -0,0 +1,81 @@
1use std::{
2 io::{BufRead, Read, Result, Write},
3 net::Ipv4Addr,
4};
5
6pub fn write<W: Write>(mut writer: W, v: &[u8]) -> Result<()> {
7 writer.write_all(v)
8}
9
10pub fn write_u8<W: Write>(mut writer: W, v: u8) -> Result<()> {
11 writer.write_all(&[v])
12}
13
14pub fn write_u16<W: Write>(mut writer: W, v: u16) -> Result<()> {
15 writer.write_all(&u16::to_be_bytes(v))
16}
17
18pub fn write_u32<W: Write>(mut writer: W, v: u32) -> Result<()> {
19 writer.write_all(&u32::to_be_bytes(v))
20}
21
22pub fn write_ipv4<W: Write>(mut writer: W, v: Ipv4Addr) -> Result<()> {
23 writer.write_all(&v.octets())
24}
25
26pub fn write_null_terminated_string<W: Write>(mut writer: W, v: &str) -> Result<()> {
27 writer.write_all(v.as_bytes())?;
28 writer.write_all(&[0u8])
29}
30
31pub fn read_u8<R: Read>(mut reader: R) -> Result<u8> {
32 let mut buf = [0u8; 1];
33 reader.read_exact(&mut buf)?;
34 Ok(buf[0])
35}
36
37pub fn read_u16<R: Read>(mut reader: R) -> Result<u16> {
38 let mut buf = [0u8; 2];
39 reader.read_exact(&mut buf)?;
40 Ok(u16::from_be_bytes(buf))
41}
42
43pub fn read_u32<R: Read>(mut reader: R) -> Result<u32> {
44 let mut buf = [0u8; 4];
45 reader.read_exact(&mut buf)?;
46 Ok(u32::from_be_bytes(buf))
47}
48
49pub fn read_arr<const N: usize, R: Read>(mut reader: R) -> Result<[u8; N]> {
50 let mut buf = [0u8; N];
51 reader.read_exact(&mut buf)?;
52 Ok(buf)
53}
54
55pub fn read_null_terminated_vec<R: BufRead>(mut reader: R) -> Result<Vec<u8>> {
56 let mut buf = Vec::default();
57 reader.read_until(0, &mut buf)?;
58 buf.pop();
59 Ok(buf)
60}
61
62pub fn read_null_terminated_string<R: BufRead>(reader: R) -> Result<String> {
63 let buf = read_null_terminated_vec(reader)?;
64 Ok(String::from_utf8(buf).unwrap())
65}
66
67pub fn read_len8_prefixed_vec<R: BufRead>(mut reader: R) -> Result<Vec<u8>> {
68 let len = read_u8(&mut reader)?;
69 let mut buf = vec![0u8; len as usize];
70 reader.read_exact(&mut buf)?;
71 Ok(buf)
72}
73
74pub fn read_len8_prefixed_string<R: BufRead>(reader: R) -> Result<String> {
75 let buf = read_len8_prefixed_vec(reader)?;
76 Ok(String::from_utf8(buf).unwrap())
77}
78
79pub fn read_ipv4<R: BufRead>(reader: R) -> Result<Ipv4Addr> {
80 Ok(Ipv4Addr::from_octets(read_arr(reader)?))
81}
generated by cgit (git 2.34.1) at 2026-04-05 16:57:05 +0000