doc/References.xml

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