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