Annotation of embedaddon/dhcp/doc/References.xml, revision 1.1
1.1 ! misho 1: <?xml version='1.0' ?>
! 2:
! 3: <!-- $Id: References.xml,v 1.3.400.1.10.2 2011-07-05 16:59:16 sar Exp $ -->
! 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