doc/References.xml

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