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