doc/References.xml

   1 <?xml version='1.0' ?>
   2
   3 <!-- $Id: References.xml,v 1.2 2007/05/08 23:05:21 dhankins 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="August" year="2006"/>
 121
 122     <note title="Copyright Notice">
 123         <t>Copyright (c) 2006-2007 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 adoped early versions of these documents, and has not
 544           yet synched up 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="http://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt"/>
 664         </reference>
 665     </references>
 666   </back>
 667 </rfc>
 668