]>
Commit | Line | Data |
---|---|---|
98bd7ca0 DH |
1 | <?xml version='1.0' ?> |
2 | ||
de6c9af6 | 3 | <!-- $Id: References.xml,v 1.8 2012/01/05 00:03:17 sar Exp $ --> |
98bd7ca0 DH |
4 | |
5 | <?rfc private="ISC-DHCP-REFERENCES" ?> | |
6 | ||
7 | <?rfc toc="yes"?> | |
8 | ||
9 | <?rfc compact="yes"?> | |
10 | <?rfc subcompact="no"?> | |
11 | <?rfc tocompact="no"?> | |
802fdea1 | 12 | <?rfc symrefs="yes"?> |
98bd7ca0 DH |
13 | |
14 | <!DOCTYPE rfc SYSTEM 'rfc2629bis.dtd' [ | |
15 | <!ENTITY rfc760 PUBLIC '' | |
16 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0760.xml'> | |
17 | <!ENTITY rfc768 PUBLIC '' | |
18 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'> | |
19 | <!ENTITY rfc894 PUBLIC '' | |
20 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml'> | |
21 | <!ENTITY rfc951 PUBLIC '' | |
22 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0951.xml'> | |
23 | <!ENTITY rfc1035 PUBLIC '' | |
24 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'> | |
25 | <!ENTITY rfc1188 PUBLIC '' | |
26 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1188.xml'> | |
27 | <!ENTITY rfc1542 PUBLIC '' | |
28 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1542.xml'> | |
29 | <!ENTITY rfc2131 PUBLIC '' | |
30 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'> | |
31 | <!ENTITY rfc2132 PUBLIC '' | |
32 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'> | |
33 | <!ENTITY rfc2241 PUBLIC '' | |
34 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2241.xml'> | |
35 | <!ENTITY rfc2242 PUBLIC '' | |
36 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2242.xml'> | |
37 | <!ENTITY rfc2485 PUBLIC '' | |
38 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2485.xml'> | |
39 | <!ENTITY rfc2610 PUBLIC '' | |
40 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2610.xml'> | |
41 | <!ENTITY rfc2937 PUBLIC '' | |
42 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2937.xml'> | |
43 | <!ENTITY rfc2939 PUBLIC '' | |
44 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml'> | |
45 | <!ENTITY rfc3004 PUBLIC '' | |
46 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3004.xml'> | |
47 | <!ENTITY rfc3011 PUBLIC '' | |
48 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3011.xml'> | |
49 | <!ENTITY rfc3046 PUBLIC '' | |
50 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'> | |
51 | <!ENTITY rfc3074 PUBLIC '' | |
52 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3074.xml'> | |
53 | <!ENTITY rfc3256 PUBLIC '' | |
54 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3256.xml'> | |
55 | <!ENTITY rfc3315 PUBLIC '' | |
56 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'> | |
57 | <!ENTITY rfc3319 PUBLIC '' | |
58 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3319.xml'> | |
59 | <!ENTITY rfc3396 PUBLIC '' | |
60 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'> | |
61 | <!ENTITY rfc3397 PUBLIC '' | |
62 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml'> | |
63 | <!ENTITY rfc3527 PUBLIC '' | |
64 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3527.xml'> | |
65 | <!ENTITY rfc3633 PUBLIC '' | |
66 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'> | |
67 | <!ENTITY rfc3646 PUBLIC '' | |
68 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml'> | |
69 | <!ENTITY rfc3679 PUBLIC '' | |
70 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3679.xml'> | |
71 | <!ENTITY rfc3898 PUBLIC '' | |
72 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3898.xml'> | |
73 | <!ENTITY rfc3925 PUBLIC '' | |
74 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3925.xml'> | |
75 | <!ENTITY rfc3942 PUBLIC '' | |
76 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml'> | |
77 | <!ENTITY rfc4075 PUBLIC '' | |
78 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4075.xml'> | |
79 | <!ENTITY rfc4242 PUBLIC '' | |
80 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml'> | |
802fdea1 TM |
81 | <!ENTITY rfc4361 PUBLIC '' |
82 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml'> | |
98bd7ca0 DH |
83 | <!ENTITY rfc4388 PUBLIC '' |
84 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4388.xml'> | |
85 | <!ENTITY rfc4580 PUBLIC '' | |
86 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml'> | |
87 | <!ENTITY rfc4649 PUBLIC '' | |
88 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml'> | |
89 | <!ENTITY rfc4701 PUBLIC '' | |
90 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701.xml'> | |
91 | <!ENTITY rfc4702 PUBLIC '' | |
92 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702.xml'> | |
93 | <!ENTITY rfc4703 PUBLIC '' | |
94 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703.xml'> | |
de6c9af6 SR |
95 | <!ENTITY rfc5453 PUBLIC '' |
96 | 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453.xml'> | |
802fdea1 TM |
97 | ]> |
98 | ||
99 | ||
98bd7ca0 DH |
100 | |
101 | <rfc ipr="none"> | |
102 | <front> | |
103 | <title>ISC DHCP References Collection</title> | |
104 | ||
105 | <author initials="D.H." surname="Hankins" fullname="David W. Hankins"> | |
106 | <organization abbrev="ISC">Internet Systems Consortium, | |
107 | Inc. | |
108 | </organization> | |
109 | ||
110 | <address> | |
111 | <postal> | |
429a56d7 TM |
112 | <street>PO Box 360</street> |
113 | <city>Newmarket</city> | |
114 | <region>NH</region> | |
115 | <code>03857</code> | |
116 | <country>USA</country> | |
98bd7ca0 | 117 | </postal> |
802fdea1 TM |
118 | </address> |
119 | </author> | |
120 | ||
121 | <author initials="T." surname="Mrugalski" fullname="Tomasz Mrugalski"> | |
122 | <organization abbrev="ISC">Internet Systems Consortium, | |
123 | Inc. | |
124 | </organization> | |
98bd7ca0 | 125 | |
802fdea1 TM |
126 | <address> |
127 | <postal> | |
429a56d7 TM |
128 | <street>PO Box 360</street> |
129 | <city>Newmarket</city> | |
130 | <region>NH</region> | |
131 | <code>03857</code> | |
132 | <country>USA</country> | |
802fdea1 | 133 | </postal> |
98bd7ca0 DH |
134 | </address> |
135 | </author> | |
136 | ||
de6c9af6 | 137 | <date day="04" month="January" year="2012"/> |
802fdea1 TM |
138 | |
139 | <keyword>ISC</keyword> | |
140 | <keyword>DHCP</keyword> | |
141 | <keyword>Reference Implementation</keyword> | |
142 | ||
143 | <abstract> | |
144 | <t>This document describes a collection of reference material | |
145 | to which ISC DHCP has been implemented as well as a more | |
146 | complete listing of references for DHCP and DHCPv6 protocols.</t> | |
147 | </abstract> | |
98bd7ca0 DH |
148 | |
149 | <note title="Copyright Notice"> | |
49a7fb58 | 150 | <t>Copyright (C) 2006-2022 Internet Systems |
802fdea1 | 151 | Consortium, Inc. ("ISC")</t> |
98bd7ca0 | 152 | |
7512d88b TM |
153 | <t>This Source Code Form is subject to the terms of the Mozilla Public |
154 | License, v. 2.0. If a copy of the MPL was not distributed with this | |
155 | file, You can obtain one at http://mozilla.org/MPL/2.0/. | |
156 | </t> | |
98bd7ca0 DH |
157 | |
158 | <t>THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES | |
159 | WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF | |
160 | MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR | |
161 | ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES | |
162 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN | |
163 | ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT | |
164 | OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.</t> | |
165 | </note> | |
166 | ||
98bd7ca0 DH |
167 | </front> |
168 | ||
169 | <middle> | |
170 | <section title="Introduction"> | |
171 | <t>As a little historical anecdote, ISC DHCP once packaged all the | |
172 | relevant RFCs and standards documents along with the software | |
173 | package. Until one day when a voice was heard from one of the | |
174 | many fine institutions that build and distribute this software... | |
175 | they took issue with the IETF's copyright on the RFC's. It | |
176 | seems the IETF's copyrights don't allow modification of RFC's | |
177 | (except for translation purposes).</t> | |
178 | ||
179 | <t>Our main purpose in providing the RFCs is to aid in | |
180 | documentation, but since RFCs are now available widely from many | |
181 | points of distribution on the Internet, there is no real need to | |
182 | provide the documents themselves. So, this document has been | |
183 | created in their stead, to list the various IETF RFCs one might | |
184 | want to read, and to comment on how well (or poorly) we have | |
185 | managed to implement them.</t> | |
186 | </section> | |
187 | ||
188 | <section title="Definition: Reference Implementation"> | |
189 | <t>ISC DHCP, much like its other cousins in ISC software, is | |
190 | self-described as a 'Reference Implementation.' There has been | |
191 | a great deal of confusion about this term. Some people seem to | |
192 | think that this term applies to any software that once passed | |
193 | a piece of reference material on its way to market (but may do | |
194 | quite a lot of things that aren't described in any reference, or | |
195 | may choose to ignore the reference it saw entirely). Other folks | |
196 | get confused by the word 'reference' and understand that to mean | |
197 | that there is some special status applied to the software - that | |
198 | the software itself is the reference by which all other software | |
199 | is measured. Something along the lines of being "The DHCP | |
200 | Protocol's Reference Clock," it is supposed.</t> | |
201 | ||
202 | <t>The truth is actually quite a lot simpler. Reference | |
203 | implementations are software packages which were written | |
204 | to behave precisely as appears in reference material. They | |
205 | are written "to match reference."</t> | |
206 | ||
207 | <t>If the software has a behaviour that manifests itself | |
208 | externally (whether it be something as simple as the 'wire | |
209 | format' or something higher level, such as a complicated | |
210 | behaviour that arises from multiple message exchanges), that | |
211 | behaviour must be found in a reference document.</t> | |
212 | ||
213 | <t>Anything else is a bug, the only question is whether the | |
214 | bug is in reference or software (failing to implement the | |
215 | reference).</t> | |
216 | ||
217 | <t>This means:</t> | |
218 | ||
802fdea1 | 219 | <t> |
98bd7ca0 DH |
220 | <list style="symbols"> |
221 | <t>To produce new externally-visible behaviour, one must first | |
222 | provide a reference.</t> | |
223 | ||
224 | <t>Before changing externally visible behaviour to work around | |
225 | simple incompatibilities in any other implementation, one must | |
226 | first provide a reference.</t> | |
227 | </list> | |
802fdea1 | 228 | </t> |
98bd7ca0 DH |
229 | |
230 | <t>That is the lofty goal, at any rate. It's well understood that, | |
231 | especially because the ISC DHCP Software package has not always been | |
232 | held to this standard (but not entirely due to it), there are many | |
233 | non-referenced behaviours within ISC DHCP.</t> | |
234 | ||
235 | <t>The primary goal of reference implementation is to prove the | |
236 | reference material. If the reference material is good, then you | |
237 | should be able to sit down and write a program that implements the | |
238 | reference, to the word, and come to an implementation that | |
239 | is distinguishable from others in the details, but not in the | |
240 | facts of operating the protocol. This means that there is no | |
241 | need for 'special knowledge' to work around arcane problems that | |
242 | were left undocumented. No secret handshakes need to be learned | |
243 | to be imparted with the necessary "real documentation".</t> | |
244 | ||
245 | <t>Also, by accepting only reference as the guidebook for ISC | |
246 | DHCP's software implementation, anyone who can make an impact on | |
247 | the color texture or form of that reference has a (somewhat | |
248 | indirect) voice in ISC DHCP's software design. As the IETF RFC's | |
249 | have been selected as the source of reference, that means everyone | |
250 | on the Internet with the will to participate has a say.</t> | |
251 | </section> | |
252 | ||
253 | <section title="Low Layer References"> | |
254 | <t>It may surprise you to realize that ISC DHCP implements 802.1 | |
255 | 'Ethernet' framing, Token Ring, and FDDI. In order to bridge the | |
256 | gap there between these physical and DHCP layers, it must also | |
257 | implement IP and UDP framing.</t> | |
258 | ||
259 | <t>The reason for this stems from Unix systems' handling of BSD | |
260 | sockets (the general way one might engage in transmission of UDP | |
261 | packets) on unconfigured interfaces, or even the handling of | |
262 | broadcast addressing on configured interfaces.</t> | |
263 | ||
264 | <t>There are a few things that DHCP servers, relays, and clients all | |
265 | need to do in order to speak the DHCP protocol in strict compliance | |
802fdea1 | 266 | with <xref target="RFC2131"/>. |
98bd7ca0 DH |
267 | |
268 | <list style="numbers"> | |
269 | <t>Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to | |
270 | IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP | |
271 | address yet) interface.</t> | |
272 | ||
273 | <t>Receive a UDP packet from IP:remote-system LinkLayer:remote-system, | |
274 | destined to IP:255.255.255.255 LinkLayer:Broadcast, again on an | |
275 | unconfigured interface.</t> | |
276 | ||
802fdea1 | 277 | <t>Transmit a UDP packet from IP:Self, Ethernet:Self, destined to |
98bd7ca0 DH |
278 | IP:remote-system LinkLayer:remote-system, without transmitting a |
279 | single ARP.</t> | |
280 | ||
281 | <t>And of course the simple case, a regular IP unicast that is | |
282 | routed via the usual means (so it may be direct to a local system, | |
283 | with ARP providing the glue, or it may be to a remote system via | |
284 | one or more routers as normal). In this case, the interfaces are | |
285 | always configured.</t> | |
802fdea1 | 286 | </list></t> |
98bd7ca0 DH |
287 | |
288 | <t>The above isn't as simple as it sounds on a regular BSD socket. | |
289 | Many unix implementations will transmit broadcasts not to | |
290 | 255.255.255.255, but to x.y.z.255 (where x.y.z is the system's local | |
291 | subnet). Such packets are not received by several known DHCP client | |
802fdea1 TM |
292 | implementations - and it's not their fault, <xref target="RFC2131"/> |
293 | very explicitly demands that these packets' IP destination | |
294 | addresses be set to 255.255.255.255.</t> | |
98bd7ca0 DH |
295 | |
296 | <t>Receiving packets sent to 255.255.255.255 isn't a problem on most | |
297 | modern unixes...so long as the interface is configured. When there | |
298 | is no IPv4 address on the interface, things become much more murky.</t> | |
299 | ||
300 | <t>So, for this convoluted and unfortunate state of affairs in the | |
301 | unix systems of the day ISC DHCP was manufactured, in order to do | |
302 | what it needs not only to implement the reference but to interoperate | |
303 | with other implementations, the software must create some form of | |
304 | raw socket to operate on.</t> | |
305 | ||
306 | <t>What it actually does is create, for each interface detected on | |
307 | the system, a Berkeley Packet Filter socket (or equivalent), and | |
308 | program it with a filter that brings in only DHCP packets. A | |
309 | "fallback" UDP Berkeley socket is generally also created, a single | |
310 | one no matter how many interfaces. Should the software need to | |
311 | transmit a contrived packet to the local network the packet is | |
312 | formed piece by piece and transmitted via the BPF socket. Hence | |
313 | the need to implement many forms of Link Layer framing and above. | |
314 | The software gets away with not having to implement IP routing | |
315 | tables as well by simply utilizing the aforementioned 'fallback' | |
f6b8f48d | 316 | UDP socket when unicasting between two configured systems is |
802fdea1 | 317 | needed.</t> |
98bd7ca0 DH |
318 | |
319 | <t>Modern unixes have opened up some facilities that diminish how | |
320 | much of this sort of nefarious kludgery is necessary, but have not | |
802fdea1 | 321 | found the state of affairs absolutely resolved. In particular, |
98bd7ca0 DH |
322 | one might now unicast without ARP by inserting an entry into the |
323 | ARP cache prior to transmitting. Unconfigured interfaces remain | |
324 | the sticking point, however...on virtually no modern unixes is | |
325 | it possible to receive broadcast packets unless a local IPv4 | |
326 | address has been configured, unless it is done with raw sockets.</t> | |
327 | ||
328 | <section title="Ethernet Protocol References"> | |
329 | <t>ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant | |
330 | of IEEE 802.2. No good reference of this framing is known to exist | |
802fdea1 TM |
331 | at this time, but it is vaguely described in <xref target="RFC0894"/> |
332 | see the section titled "Packet format"), and | |
98bd7ca0 DH |
333 | the following URL is also thought to be useful.</t> |
334 | ||
802fdea1 | 335 | <t><eref target="http://en.wikipedia.org/wiki/DIX_Ethernet">http://en.wikipedia.org/wiki/DIX_Ethernet</eref></t> |
98bd7ca0 DH |
336 | </section> |
337 | ||
338 | <section title="Token Ring Protocol References"> | |
339 | <t>IEEE 802.5 defines the Token Ring framing format used by ISC | |
340 | DHCP.</t> | |
341 | </section> | |
342 | ||
343 | <section title="FDDI Protocol References"> | |
802fdea1 | 344 | <t><xref target="RFC1188"/> is the most helpful |
98bd7ca0 DH |
345 | reference ISC DHCP has used to form FDDI packets.</t> |
346 | </section> | |
347 | ||
348 | <section title="Internet Protocol Version 4 References"> | |
349 | <t><xref target="RFC0760">RFC760</xref> fundamentally defines the | |
350 | bare IPv4 protocol which ISC DHCP implements.</t> | |
351 | </section> | |
352 | ||
353 | <section title="Unicast Datagram Protocol References"> | |
354 | <t><xref target="RFC0768">RFC768</xref> defines the User Datagram | |
355 | Protocol that ultimately carries the DHCP or BOOTP protocol. The | |
356 | destination DHCP server port is 67, the client port is 68. Source | |
357 | ports are irrelevant.</t> | |
358 | </section> | |
359 | </section> | |
360 | ||
361 | <section title="BOOTP Protocol References"> | |
362 | <t>The DHCP Protocol is strange among protocols in that it is | |
363 | grafted over the top of another protocol - BOOTP (but we don't | |
364 | call it "DHCP over BOOTP" like we do, say "TCP over IP"). BOOTP | |
365 | and DHCP share UDP packet formats - DHCP is merely a conventional | |
366 | use of both BOOTP header fields and the trailing 'options' space.</t> | |
367 | ||
368 | <t>The ISC DHCP server supports BOOTP clients conforming to | |
369 | <xref target="RFC0951">RFC951</xref> and <xref target="RFC1542"> | |
370 | RFC1542</xref>.</t> | |
371 | </section> | |
372 | ||
802fdea1 | 373 | <section title="DHCPv4 Protocol References"> |
98bd7ca0 DH |
374 | <section title="DHCPv4 Protocol"> |
375 | <t>"The DHCP[v4] Protocol" is not defined in a single document. The | |
376 | following collection of references of what ISC DHCP terms "The | |
377 | DHCPv4 Protocol".</t> | |
378 | ||
802fdea1 | 379 | <section title="Core Protocol References"> |
98bd7ca0 DH |
380 | <t><xref target="RFC2131">RFC2131</xref> defines the protocol format |
381 | and procedures. ISC DHCP is not known to diverge from this document | |
382 | in any way. There are, however, a few points on which different | |
383 | implementations have arisen out of vagueries in the document. | |
384 | DHCP Clients exist which, at one time, present themselves as using | |
385 | a Client Identifier Option which is equal to the client's hardware | |
386 | address. Later, the client transmits DHCP packets with no Client | |
387 | Identifier Option present - essentially identifying themselves using | |
388 | the hardware address. Some DHCP Servers have been developed which | |
389 | identify this client as a single client. ISC has interpreted | |
390 | RFC2131 to indicate that these clients must be treated as two | |
391 | separate entities (and hence two, separate addresses). Client | |
392 | behaviour (Embedded Windows products) has developed that relies on | |
393 | the former implementation, and hence is incompatible with the | |
394 | latter. Also, RFC2131 demands explicitly that some header fields | |
395 | be zeroed upon certain message types. The ISC DHCP Server instead | |
396 | copies many of these fields from the packet received from the client | |
397 | or relay, which may not be zero. It is not known if there is a good | |
398 | reason for this that has not been documented.</t> | |
399 | ||
400 | <t><xref target="RFC2132">RFC2132</xref> defines the initial set of | |
401 | DHCP Options and provides a great deal of guidance on how to go about | |
402 | formatting and processing options. The document unfortunately | |
403 | waffles to a great extent about the NULL termination of DHCP Options, | |
404 | and some DHCP Clients (Windows 95) have been implemented that rely | |
405 | upon DHCP Options containing text strings to be NULL-terminated (or | |
406 | else they crash). So, ISC DHCP detects if clients null-terminate the | |
407 | host-name option and, if so, null terminates any text options it | |
408 | transmits to the client. It also removes NULL termination from any | |
409 | known text option it receives prior to any other processing.</t> | |
802fdea1 | 410 | </section> |
98bd7ca0 DH |
411 | </section> |
412 | ||
802fdea1 | 413 | <section title="DHCPv4 Option References"> |
98bd7ca0 DH |
414 | <t><xref target="RFC2241">RFC2241</xref> defines options for |
415 | Novell Directory Services.</t> | |
416 | ||
417 | <t><xref target="RFC2242">RFC2242</xref> defines an encapsulated | |
418 | option space for NWIP configuration.</t> | |
419 | ||
420 | <t><xref target="RFC2485">RFC2485</xref> defines the Open Group's | |
421 | UAP option.</t> | |
422 | ||
423 | <t><xref target="RFC2610">RFC2610</xref> defines options for | |
424 | the Service Location Protocol (SLP).</t> | |
425 | ||
426 | <t><xref target="RFC2937">RFC2937</xref> defines the Name Service | |
427 | Search Option (not to be confused with the domain-search option). | |
428 | The Name Service Search Option allows eg nsswitch.conf to be | |
429 | reconfigured via dhcp. The ISC DHCP server implements this option, | |
430 | and the ISC DHCP client is compatible...but does not by default | |
431 | install this option's value. One would need to make their relevant | |
432 | dhclient-script process this option in a way that is suitable for | |
433 | the system.</t> | |
434 | ||
435 | <t><xref target="RFC3004">RFC3004</xref> defines the User-Class | |
436 | option. Note carefully that ISC DHCP currently does not implement | |
437 | to this reference, but has (inexplicably) selected an incompatible | |
438 | format: a plain text string.</t> | |
439 | ||
440 | <t><xref target="RFC3011">RFC3011</xref> defines the Subnet-Selection | |
441 | plain DHCPv4 option. Do not confuse this option with the relay agent | |
802fdea1 TM |
442 | "link selection" sub-option, although their behaviour is |
443 | similar.</t> | |
98bd7ca0 DH |
444 | |
445 | <t><xref target="RFC3396">RFC3396</xref> documents both how long | |
446 | options may be encoded in DHCPv4 packets, and also how multiple | |
447 | instances of the same option code within a DHCPv4 packet will be | |
448 | decoded by receivers.</t> | |
449 | ||
450 | <t><xref target="RFC3397">RFC3397</xref> documents the Domain-Search | |
451 | Option, which allows the configuration of the /etc/resolv.conf | |
452 | 'search' parameter in a way that is <xref target="RFC1035">RFC1035 | |
453 | </xref> wire format compatible (in fact, it uses the RFC1035 wire | |
454 | format). ISC DHCP has both client and server support, and supports | |
455 | RFC1035 name compression.</t> | |
456 | ||
98bd7ca0 DH |
457 | <t><xref target="RFC3679">RFC3679</xref> documents a number of |
458 | options that were documented earlier in history, but were not | |
459 | made use of.</t> | |
460 | ||
98bd7ca0 DH |
461 | <t><xref target="RFC3925">RFC3925</xref> documents a pair of |
462 | Enterprise-ID delimited option spaces for vendors to use in order | |
463 | to inform servers of their "vendor class" (sort of like 'uname' | |
464 | or 'who and what am I'), and a means to deliver vendor-specific | |
465 | and vendor-documented option codes and values.</t> | |
466 | ||
467 | <t><xref target="RFC3942">RFC3942</xref> redefined the 'site local' | |
468 | option space.</t> | |
469 | ||
802fdea1 TM |
470 | <t><xref target="RFC4280" /> defines two BCMS server options |
471 | for each protocol family.</t> | |
98bd7ca0 DH |
472 | |
473 | <t><xref target="RFC4388">RFC4388</xref> defined the DHCPv4 | |
474 | LEASEQUERY message type and a number of suitable response messages, | |
475 | for the purpose of sharing information about DHCP served addresses | |
476 | and clients.</t> | |
477 | ||
802fdea1 | 478 | <section title="Relay Agent Information Option Options"> |
98bd7ca0 DH |
479 | <t><xref target="RFC3046">RFC3046</xref> defines the Relay Agent |
480 | Information Option and provides a number of sub-option | |
481 | definitions.</t> | |
482 | ||
483 | <t><xref target="RFC3256">RFC3256</xref> defines the DOCSIS Device | |
484 | Class sub-option.</t> | |
485 | ||
486 | <t><xref target="RFC3527">RFC3527</xref> defines the Link Selection | |
802fdea1 TM |
487 | sub-option.</t> |
488 | </section> | |
489 | ||
98bd7ca0 DH |
490 | |
491 | <section title="Dynamic DNS Updates References"> | |
492 | <t>The collection of documents that describe the standards-based | |
493 | method to update dns names of DHCP clients starts most easily | |
494 | with <xref target="RFC4703">RFC4703</xref> to define the overall | |
495 | architecture, travels through RFCs <xref target="RFC4702">4702</xref> | |
496 | and <xref target="RFC4704">4704</xref> to describe the DHCPv4 and | |
497 | DHCPv6 FQDN options (to carry the client name), and ends up at | |
498 | <xref target="RFC4701">RFC4701</xref> which describes the DHCID | |
499 | RR used in DNS to perform a kind of atomic locking.</t> | |
500 | ||
b80dae47 SR |
501 | <t>ISC DHCP adopted early versions of these documents, and has not |
502 | yet synchronized with the final standards versions.</t> | |
98bd7ca0 DH |
503 | |
504 | <t>For RFCs 4702 and 4704, the 'N' bit is not yet supported. The | |
505 | result is that it is always set zero, and is ignored if set.</t> | |
506 | ||
507 | <t>For RFC4701, which is used to match client identities with names | |
508 | in the DNS as part of name conflict resolution. Note that ISC DHCP's | |
509 | implementation of DHCIDs vary wildly from this specification. | |
510 | First, ISC DHCP uses a TXT record in which the contents are stored | |
511 | in hexadecimal. Second, there is a flaw in the selection of the | |
512 | 'Identifier Type', which results in a completely different value | |
513 | being selected than was defined in an older revision of this | |
514 | document...also this field is one byte prior to hexadecimal | |
515 | encoding rather than two. Third, ISC DHCP does not use a digest | |
516 | type code. Rather, all values for such TXT records are reached | |
517 | via an MD5 sum. In short, nothing is compatible, but the | |
518 | principle of the TXT record is the same as the standard DHCID | |
519 | record. However, for DHCPv6 FQDN, we do use DHCID type code '2', | |
520 | as no other value really makes sense in our context.</t> | |
521 | </section> | |
522 | ||
523 | <section title="Experimental: Failover References"> | |
802fdea1 | 524 | <t>The Failover Protocol defines means by which two DHCP Servers |
98bd7ca0 DH |
525 | can share all the relevant information about leases granted to |
526 | DHCP clients on given networks, so that one of the two servers may | |
527 | fail and be survived by a server that can act responsibly.</t> | |
528 | ||
f6b8f48d | 529 | <t>Unfortunately it has been quite some years (2003) since the last |
802fdea1 | 530 | time this document was edited, and the authors no longer show any |
98bd7ca0 DH |
531 | interest in fielding comments or improving the document.</t> |
532 | ||
533 | <t>The status of this protocol is very unsure, but ISC's | |
534 | implementation of it has proven stable and suitable for use in | |
535 | sizable production environments.</t> | |
536 | ||
537 | <t><xref target="draft-failover">draft-ietf-dhc-failover-12.txt</xref> | |
538 | describes the Failover Protocol. In addition to what is described | |
539 | in this document, ISC DHCP has elected to make some experimental | |
540 | changes that may be revoked in a future version of ISC DHCP (if the | |
541 | draft authors do not adopt the new behaviour). Specifically, ISC | |
542 | DHCP's POOLREQ behaviour differs substantially from what is | |
543 | documented in the draft, and the server also implements a form of | |
544 | 'MAC Address Affinity' which is not described in the failover | |
545 | document. The full nature of these changes have been described on | |
546 | the IETF DHC WG mailing list (which has archives), and also in ISC | |
547 | DHCP's manual pages. Also note that although this document | |
548 | references a RECOVER-WAIT state, it does not document a protocol | |
549 | number assignment for this state. As a consequence, ISC DHCP has | |
550 | elected to use the value 254.</t> | |
551 | ||
802fdea1 TM |
552 | <t> An optimization described in the failover protocol draft |
553 | is included since 4.2.0a1. It permits a DHCP server | |
554 | operating in communications-interrupted state to 'rewind' a | |
555 | lease to the state most recently transmitted to its peer, | |
556 | greatly increasing a server's endurance in | |
557 | communications-interrupted. This is supported using a new | |
558 | 'rewind state' record on the dhcpd.leases entry for each | |
559 | lease. | |
560 | </t> | |
561 | ||
562 | <t><xref target="RFC3074" /> describes the Load Balancing | |
98bd7ca0 DH |
563 | Algorithm (LBA) that ISC DHCP uses in concert with the Failover |
564 | protocol. Note that versions 3.0.* are known to misimplement the | |
565 | hash algorithm (it will only use the low 4 bits of every byte of | |
566 | the hash bucket array).</t> | |
567 | </section> | |
568 | </section> | |
569 | ||
570 | <section title="DHCP Procedures"> | |
802fdea1 | 571 | <t><xref target="RFC2939" /> explains how to go about |
98bd7ca0 DH |
572 | obtaining a new DHCP Option code assignment.</t> |
573 | </section> | |
574 | </section> | |
802fdea1 TM |
575 | |
576 | ||
577 | <section title="DHCPv6 Protocol References"> | |
578 | ||
579 | <section title="DHCPv6 Protocol References"> | |
580 | <t>For now there is only one document that specifies the base | |
581 | of the DHCPv6 protocol (there have been no updates yet), | |
582 | <xref target="RFC3315"/>.</t> | |
583 | ||
584 | <t>Support for DHCPv6 was first added in version 4.0.0. The server | |
585 | and client support only IA_NA. While the server does support multiple | |
586 | IA_NAs within one packet from the client, our client only supports | |
587 | sending one. There is no relay support.</t> | |
588 | ||
589 | <t>DHCPv6 introduces some new and uncomfortable ideas to the common | |
590 | software library.</t> | |
591 | ||
592 | <t> | |
593 | <list style="numbers"> | |
594 | <t>Options sometimes may appear multiple times. The common | |
595 | library used to treat all appearance of multiple options as | |
596 | specified in RFC2131 - to be concatenated. DHCPv6 options | |
597 | may sometimes appear multiple times (such as with IA_NA or | |
598 | IAADDR), but often must not. As of 4.2.1-P1, multiple IA_NA, IA_PD | |
599 | or IA_TA are not supported.</t> | |
600 | ||
601 | <t>The same option space appears in DHCPv6 packets multiple times. | |
602 | If the packet was got via a relay, then the client's packet is | |
603 | stored to an option within the relay's packet...if there were two | |
604 | relays, this recurses. At each of these steps, the root "DHCPv6 | |
605 | option space" is used. Further, a client packet may contain an | |
606 | IA_NA, which may contain an IAADDR - but really, in an abstract | |
607 | sense, this is again re-encapsulation of the DHCPv6 option space | |
608 | beneath options it also contains.</t> | |
609 | </list> | |
610 | </t> | |
611 | ||
612 | <t>Precisely how to correctly support the above conundrums has not | |
613 | quite yet been settled, so support is incomplete.</t> | |
de6c9af6 SR |
614 | |
615 | <t><xref target="RFC5453"/> creates a registry at IANA to reserve | |
616 | interface identifiers and specifies a starting set. These IIDs should | |
617 | not be used when constructing addresses to avoid possible conflicts.</t> | |
802fdea1 TM |
618 | </section> |
619 | ||
620 | <section title="DHCPv6 Options References"> | |
621 | <t><xref target="RFC3319"/> defines the SIP server | |
622 | options for DHCPv6.</t> | |
623 | ||
624 | <t><xref target="RFC3646"/> documents the DHCPv6 | |
625 | name-servers and domain-search options.</t> | |
626 | ||
627 | <t><xref target="RFC3633"/> documents the Identity | |
628 | Association Prefix Delegation for DHCPv6, which is included | |
629 | here for protocol wire reference, but which is not supported | |
630 | by ISC DHCP.</t> | |
631 | ||
632 | <t><xref target="RFC3898"/> documents four NIS options | |
633 | for delivering NIS servers and domain information in DHCPv6.</t> | |
634 | ||
635 | <t><xref target="RFC4075"/> defines the DHCPv6 SNTP | |
636 | Servers option.</t> | |
637 | ||
638 | <t><xref target="RFC4242"/> defines the Information | |
639 | Refresh Time option, which advises DHCPv6 Information-Request | |
640 | clients to return for updated information.</t> | |
641 | ||
642 | <t><xref target="RFC4280"/> defines two BCMS server options | |
643 | for each protocol family.</t> | |
644 | ||
645 | <t><xref target="RFC4580"/> defines a DHCPv6 | |
646 | subscriber-id option, which is similar in principle to the DHCPv4 | |
647 | relay agent option of the same name.</t> | |
648 | ||
649 | <t><xref target="RFC4649"/> defines a DHCPv6 remote-id | |
650 | option, which is similar in principle to the DHCPv4 relay agent | |
651 | remote-id.</t> | |
652 | ||
653 | </section> | |
654 | </section> | |
655 | ||
98bd7ca0 DH |
656 | </middle> |
657 | ||
658 | <back> | |
802fdea1 | 659 | <references title="Published DHCPv4 References"> |
98bd7ca0 DH |
660 | &rfc760; |
661 | &rfc768; | |
662 | &rfc894; | |
663 | &rfc951; | |
664 | &rfc1035; | |
665 | &rfc1188; | |
666 | &rfc1542; | |
667 | &rfc2131; | |
668 | &rfc2132; | |
669 | &rfc2241; | |
670 | &rfc2242; | |
671 | &rfc2485; | |
802fdea1 | 672 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2563'?> |
98bd7ca0 | 673 | &rfc2610; |
802fdea1 | 674 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2855'?> |
98bd7ca0 DH |
675 | &rfc2937; |
676 | &rfc2939; | |
677 | &rfc3004; | |
678 | &rfc3011; | |
679 | &rfc3046; | |
680 | &rfc3074; | |
802fdea1 TM |
681 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118'?> |
682 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3203'?> | |
98bd7ca0 | 683 | &rfc3256; |
802fdea1 | 684 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3361'?> |
98bd7ca0 DH |
685 | &rfc3396; |
686 | &rfc3397; | |
802fdea1 TM |
687 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3442'?> |
688 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3456'?> | |
689 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3495'?> | |
98bd7ca0 | 690 | &rfc3527; |
802fdea1 TM |
691 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3594'?> |
692 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3634'?> | |
98bd7ca0 | 693 | &rfc3679; |
802fdea1 | 694 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825'?> |
98bd7ca0 DH |
695 | &rfc3925; |
696 | &rfc3942; | |
802fdea1 TM |
697 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3993'?> |
698 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4014'?> | |
699 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4030'?> | |
700 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4039'?> | |
701 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4174'?> | |
702 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4243'?> | |
703 | &rfc4361; | |
98bd7ca0 | 704 | &rfc4388; |
802fdea1 TM |
705 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4390'?> |
706 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4436'?> | |
707 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701'?> | |
708 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702'?> | |
709 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703'?> | |
710 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5010'?> | |
711 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5071'?> | |
712 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5107'?> | |
713 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5192'?> | |
714 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5223'?> | |
715 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5859'?> | |
716 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969'?> | |
98bd7ca0 DH |
717 | |
718 | <reference anchor='draft-failover'> | |
719 | <front> | |
720 | <title>DHCP Failover Protocol</title> | |
98bd7ca0 DH |
721 | <author initials='R.' surname='Droms' fullname='Ralph Droms'> |
722 | <organization abbrev='Cisco'>Cisco Systems</organization> | |
723 | </author> | |
98bd7ca0 DH |
724 | <date month='March' year='2003'/> |
725 | </front> | |
2c85ac9b | 726 | <format type="TXT" octets="312151" target="https://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt"/> |
98bd7ca0 | 727 | </reference> |
802fdea1 TM |
728 | |
729 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-relay-encapsulation-00.xml'?> | |
730 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-bulk-leasequery-03.xml'?> | |
731 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-leasequery-by-remote-id-09.xml'?> | |
732 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-relay-id-suboption-07.xml'?> | |
733 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mip6-hiopt-17.xml'?> | |
734 | ||
735 | </references> | |
736 | ||
737 | <references title="Published Common (DHCPv4/DHCPv6) References"> | |
738 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4280'?> | |
739 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4477'?> | |
740 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4578'?> | |
741 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776'?> | |
742 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4833'?> | |
743 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5417'?> | |
744 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5678'?> | |
745 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5908'?> | |
746 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5970'?> | |
747 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5986'?> | |
748 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-vpn-option-12.xml'?> | |
749 | ||
750 | </references> | |
751 | ||
752 | <references title="Published DHCPv6 References"> | |
753 | ||
754 | &rfc3315; | |
755 | &rfc3319; | |
756 | &rfc3633; | |
757 | &rfc3646; | |
758 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736'?> | |
759 | &rfc3898; | |
760 | &rfc4075; | |
761 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4076'?> | |
762 | &rfc4242; | |
763 | &rfc4580; | |
764 | &rfc4649; | |
765 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4704'?> | |
766 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4994'?> | |
767 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5007'?> | |
de6c9af6 | 768 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453'?> |
802fdea1 TM |
769 | <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5460'?> |
770 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-dhcpv6-route-option'?> | |
771 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-ldra'?> | |
772 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-relay-supplied-options'?> | |
773 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-pd-exclude-01.xml'?> | |
774 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-secure-dhcpv6-02.xml'?> | |
775 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-pd'?> | |
776 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-duid-uuid-03.xml'?> | |
777 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-ds-lite-tunnel-option-10.xml'?> | |
778 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-dns-server-selection-01.xml'?> | |
779 | <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-geopriv-rfc3825bis-17.xml'?> | |
780 | ||
781 | <reference anchor='draft-addr-params'> | |
782 | <front> | |
783 | <title>Address Parameters Option for DHCPv6</title> | |
784 | <author initials='T.' surname='Mrugalski' fullname='Mrugalski'> | |
785 | <organization abbrev='Cisco'>Gdansk University of Technology</organization> | |
786 | </author> | |
787 | <date month='April' year='2007'/> | |
788 | </front> | |
789 | <format type="TXT" target="http://klub.com.pl/dhcpv6/doc/draft-mrugalski-addropts-XX-2007-04-17.txt"/> | |
790 | </reference> | |
791 | ||
98bd7ca0 DH |
792 | </references> |
793 | </back> | |
794 | </rfc> |