Remove building with NOCRYPTO option

[minix3.git] / external / bsd / dhcp / dist / doc / References.xml

<?xml version='1.0' ?>

<!-- Id: References.xml,v 1.8 2012/01/05 00:03:17 sar Exp  -->

<?rfc private="ISC-DHCP-REFERENCES" ?>

<?rfc toc="yes"?>

<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocompact="no"?>
<?rfc symrefs="yes"?>

<!DOCTYPE rfc SYSTEM 'rfc2629bis.dtd' [
  <!ENTITY rfc760 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0760.xml'>
  <!ENTITY rfc768 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'>
  <!ENTITY rfc894 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml'>
  <!ENTITY rfc951 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0951.xml'>
  <!ENTITY rfc1035 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
  <!ENTITY rfc1188 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1188.xml'>
  <!ENTITY rfc1542 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1542.xml'>
  <!ENTITY rfc2131 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
  <!ENTITY rfc2132 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
  <!ENTITY rfc2241 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2241.xml'>
  <!ENTITY rfc2242 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2242.xml'>
  <!ENTITY rfc2485 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2485.xml'>
  <!ENTITY rfc2610 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2610.xml'>
  <!ENTITY rfc2937 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2937.xml'>
  <!ENTITY rfc2939 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml'>
  <!ENTITY rfc3004 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3004.xml'>
  <!ENTITY rfc3011 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3011.xml'>
  <!ENTITY rfc3046 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'>
  <!ENTITY rfc3074 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3074.xml'>
  <!ENTITY rfc3256 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3256.xml'>
  <!ENTITY rfc3315 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
  <!ENTITY rfc3319 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3319.xml'>
  <!ENTITY rfc3396 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'>
  <!ENTITY rfc3397 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml'>
  <!ENTITY rfc3527 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3527.xml'>
  <!ENTITY rfc3633 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'>
  <!ENTITY rfc3646 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml'>
  <!ENTITY rfc3679 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3679.xml'>
  <!ENTITY rfc3898 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3898.xml'>
  <!ENTITY rfc3925 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3925.xml'>
  <!ENTITY rfc3942 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml'>
  <!ENTITY rfc4075 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4075.xml'>
  <!ENTITY rfc4242 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml'>
  <!ENTITY rfc4361 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml'>
  <!ENTITY rfc4388 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4388.xml'>
  <!ENTITY rfc4580 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml'>
  <!ENTITY rfc4649 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml'>
  <!ENTITY rfc4701 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701.xml'>
  <!ENTITY rfc4702 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702.xml'>
  <!ENTITY rfc4703 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703.xml'>
  <!ENTITY rfc5453 PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453.xml'>
  ]>



<rfc ipr="none">
  <front>
    <title>ISC DHCP References Collection</title>

    <author initials="D.H." surname="Hankins" fullname="David W. Hankins">
      <organization abbrev="ISC">Internet Systems Consortium,
                                 Inc.
      </organization>

      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
        </postal>
      </address>
    </author>

    <author initials="T." surname="Mrugalski" fullname="Tomasz Mrugalski">
      <organization abbrev="ISC">Internet Systems Consortium,
                                 Inc.
      </organization>

      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
        </postal>

        <phone>+1 650 423 1345</phone>
        <email>Tomasz_Mrugalski@isc.org</email>
      </address>
    </author>

    <date day="04" month="January" year="2012"/>

    <keyword>ISC</keyword>
    <keyword>DHCP</keyword>
    <keyword>Reference Implementation</keyword>

    <abstract>
        <t>This document describes a collection of reference material
        to which ISC DHCP has been implemented as well as a more
        complete listing of references for DHCP and DHCPv6 protocols.</t>
    </abstract>

    <note title="Copyright Notice">
        <t>Copyright (c) 2006-2007,2009,2011 by Internet Systems
          Consortium, Inc. ("ISC")</t>

        <t>Permission to use, copy, modify, and distribute this software for
        any purpose with or without fee is hereby granted, provided that the
        above copyright notice and this permission notice appear in all
        copies.</t>

        <t>THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
        WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
        MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR
        ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
        WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
        ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
        OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.</t>
    </note>

  </front>

  <middle>
    <section title="Introduction">
        <t>As a little historical anecdote, ISC DHCP once packaged all the
        relevant RFCs and standards documents along with the software
        package.  Until one day when a voice was heard from one of the
        many fine institutions that build and distribute this software...
        they took issue with the IETF's copyright on the RFC's.  It
        seems the IETF's copyrights don't allow modification of RFC's
        (except for translation purposes).</t>

        <t>Our main purpose in providing the RFCs is to aid in
        documentation, but since RFCs are now available widely from many
        points of distribution on the Internet, there is no real need to
        provide the documents themselves.  So, this document has been
        created in their stead, to list the various IETF RFCs one might
        want to read, and to comment on how well (or poorly) we have
        managed to implement them.</t>
    </section>

    <section title="Definition: Reference Implementation">
        <t>ISC DHCP, much like its other cousins in ISC software, is
        self-described as a 'Reference Implementation.'  There has been
        a great deal of confusion about this term.  Some people seem to
        think that this term applies to any software that once passed
        a piece of reference material on its way to market (but may do
        quite a lot of things that aren't described in any reference, or
        may choose to ignore the reference it saw entirely).  Other folks
        get confused by the word 'reference' and understand that to mean
        that there is some special status applied to the software - that
        the software itself is the reference by which all other software
        is measured.  Something along the lines of being "The DHCP
        Protocol's Reference Clock," it is supposed.</t>

        <t>The truth is actually quite a lot simpler.  Reference
        implementations are software packages which were written
        to behave precisely as appears in reference material.  They
        are written "to match reference."</t>

        <t>If the software has a behaviour that manifests itself
        externally (whether it be something as simple as the 'wire
        format' or something higher level, such as a complicated
        behaviour that arises from multiple message exchanges), that
        behaviour must be found in a reference document.</t>

        <t>Anything else is a bug, the only question is whether the
        bug is in reference or software (failing to implement the
        reference).</t>

        <t>This means:</t>

        <t>
      <list style="symbols">
        <t>To produce new externally-visible behaviour, one must first
        provide a reference.</t>

        <t>Before changing externally visible behaviour to work around
        simple incompatibilities in any other implementation, one must
        first provide a reference.</t>
      </list>
        </t>

        <t>That is the lofty goal, at any rate.  It's well understood that,
        especially because the ISC DHCP Software package has not always been
        held to this standard (but not entirely due to it), there are many
        non-referenced behaviours within ISC DHCP.</t>

        <t>The primary goal of reference implementation is to prove the
        reference material.  If the reference material is good, then you
        should be able to sit down and write a program that implements the
        reference, to the word, and come to an implementation that
        is distinguishable from others in the details, but not in the
        facts of operating the protocol.  This means that there is no
        need for 'special knowledge' to work around arcane problems that
        were left undocumented.  No secret handshakes need to be learned
        to be imparted with the necessary "real documentation".</t>

        <t>Also, by accepting only reference as the guidebook for ISC
        DHCP's software implementation, anyone who can make an impact on
        the color texture or form of that reference has a (somewhat
        indirect) voice in ISC DHCP's software design.  As the IETF RFC's
        have been selected as the source of reference, that means everyone
        on the Internet with the will to participate has a say.</t>
    </section>

    <section title="Low Layer References">
        <t>It may surprise you to realize that ISC DHCP implements 802.1
        'Ethernet' framing, Token Ring, and FDDI.  In order to bridge the
        gap there between these physical and DHCP layers, it must also
        implement IP and UDP framing.</t>

        <t>The reason for this stems from Unix systems' handling of BSD
        sockets (the general way one might engage in transmission of UDP
        packets) on unconfigured interfaces, or even the handling of
        broadcast addressing on configured interfaces.</t>

        <t>There are a few things that DHCP servers, relays, and clients all
        need to do in order to speak the DHCP protocol in strict compliance
        with <xref target="RFC2131"/>.

      <list style="numbers">
        <t>Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to
        IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP
        address yet) interface.</t>

        <t>Receive a UDP packet from IP:remote-system LinkLayer:remote-system,
        destined to IP:255.255.255.255 LinkLayer:Broadcast, again on an
        unconfigured interface.</t>

        <t>Transmit a UDP packet from IP:Self, Ethernet:Self, destined to
        IP:remote-system LinkLayer:remote-system, without transmitting a
        single ARP.</t>

        <t>And of course the simple case, a regular IP unicast that is
        routed via the usual means (so it may be direct to a local system,
        with ARP providing the glue, or it may be to a remote system via
        one or more routers as normal).  In this case, the interfaces are
        always configured.</t>
      </list></t>

        <t>The above isn't as simple as it sounds on a regular BSD socket.
        Many unix implementations will transmit broadcasts not to
        255.255.255.255, but to x.y.z.255 (where x.y.z is the system's local
        subnet).  Such packets are not received by several known DHCP client
        implementations - and it's not their fault, <xref target="RFC2131"/>
        very explicitly demands that these packets' IP destination
        addresses be set to 255.255.255.255.</t>

        <t>Receiving packets sent to 255.255.255.255 isn't a problem on most
        modern unixes...so long as the interface is configured.  When there
        is no IPv4 address on the interface, things become much more murky.</t>

        <t>So, for this convoluted and unfortunate state of affairs in the
        unix systems of the day ISC DHCP was manufactured, in order to do
        what it needs not only to implement the reference but to interoperate
        with other implementations, the software must create some form of
        raw socket to operate on.</t>

        <t>What it actually does is create, for each interface detected on
        the system, a Berkeley Packet Filter socket (or equivalent), and
        program it with a filter that brings in only DHCP packets.  A
        "fallback" UDP Berkeley socket is generally also created, a single
        one no matter how many interfaces.  Should the software need to
        transmit a contrived packet to the local network the packet is
        formed piece by piece and transmitted via the BPF socket.  Hence
        the need to implement many forms of Link Layer framing and above.
        The software gets away with not having to implement IP routing
        tables as well by simply utilizing the aforementioned 'fallback'
        UDP socket when unicasting between two configured systems is 
        needed.</t>

        <t>Modern unixes have opened up some facilities that diminish how
        much of this sort of nefarious kludgery is necessary, but have not
        found the state of affairs absolutely resolved.  In particular,
        one might now unicast without ARP by inserting an entry into the
        ARP cache prior to transmitting.  Unconfigured interfaces remain
        the sticking point, however...on virtually no modern unixes is
        it possible to receive broadcast packets unless a local IPv4
        address has been configured, unless it is done with raw sockets.</t>

      <section title="Ethernet Protocol References">
        <t>ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant
        of IEEE 802.2.  No good reference of this framing is known to exist
        at this time, but it is vaguely described in <xref target="RFC0894"/>
        see the section titled "Packet format"), and
        the following URL is also thought to be useful.</t>

        <t><eref target="http://en.wikipedia.org/wiki/DIX_Ethernet">http://en.wikipedia.org/wiki/DIX_Ethernet</eref></t>
      </section>

      <section title="Token Ring Protocol References">
        <t>IEEE 802.5 defines the Token Ring framing format used by ISC
        DHCP.</t>
      </section>

      <section title="FDDI Protocol References">
        <t><xref target="RFC1188"/> is the most helpful
        reference ISC DHCP has used to form FDDI packets.</t>
      </section>

      <section title="Internet Protocol Version 4 References">
        <t><xref target="RFC0760">RFC760</xref> fundamentally defines the
        bare IPv4 protocol which ISC DHCP implements.</t>
      </section>

      <section title="Unicast Datagram Protocol References">
        <t><xref target="RFC0768">RFC768</xref> defines the User Datagram
        Protocol that ultimately carries the DHCP or BOOTP protocol.  The
        destination DHCP server port is 67, the client port is 68.  Source
        ports are irrelevant.</t>
      </section>
    </section>

    <section title="BOOTP Protocol References">
        <t>The DHCP Protocol is strange among protocols in that it is
        grafted over the top of another protocol - BOOTP (but we don't
        call it "DHCP over BOOTP" like we do, say "TCP over IP").  BOOTP
        and DHCP share UDP packet formats - DHCP is merely a conventional
        use of both BOOTP header fields and the trailing 'options' space.</t>

        <t>The ISC DHCP server supports BOOTP clients conforming to
        <xref target="RFC0951">RFC951</xref> and <xref target="RFC1542">
        RFC1542</xref>.</t>
    </section>

    <section title="DHCPv4 Protocol References">
      <section title="DHCPv4 Protocol">
        <t>"The DHCP[v4] Protocol" is not defined in a single document.  The
        following collection of references of what ISC DHCP terms "The
        DHCPv4 Protocol".</t>

        <section title="Core Protocol References">
          <t><xref target="RFC2131">RFC2131</xref> defines the protocol format
        and procedures.  ISC DHCP is not known to diverge from this document
        in any way.  There are, however, a few points on which different
        implementations have arisen out of vagueries in the document.
        DHCP Clients exist which, at one time, present themselves as using
        a Client Identifier Option which is equal to the client's hardware
        address.  Later, the client transmits DHCP packets with no Client
        Identifier Option present - essentially identifying themselves using
        the hardware address.  Some DHCP Servers have been developed which
        identify this client as a single client.  ISC has interpreted
        RFC2131 to indicate that these clients must be treated as two
        separate entities (and hence two, separate addresses).  Client
        behaviour (Embedded Windows products) has developed that relies on
        the former implementation, and hence is incompatible with the
        latter.  Also, RFC2131 demands explicitly that some header fields
        be zeroed upon certain message types.  The ISC DHCP Server instead
        copies many of these fields from the packet received from the client
        or relay, which may not be zero.  It is not known if there is a good
        reason for this that has not been documented.</t>

          <t><xref target="RFC2132">RFC2132</xref> defines the initial set of
        DHCP Options and provides a great deal of guidance on how to go about
        formatting and processing options.  The document unfortunately
        waffles to a great extent about the NULL termination of DHCP Options,
        and some DHCP Clients (Windows 95) have been implemented that rely
        upon DHCP Options containing text strings to be NULL-terminated (or
        else they crash).  So, ISC DHCP detects if clients null-terminate the
        host-name option and, if so, null terminates any text options it
        transmits to the client.  It also removes NULL termination from any
        known text option it receives prior to any other processing.</t>
        </section>
      </section>

      <section title="DHCPv4 Option References">
        <t><xref target="RFC2241">RFC2241</xref> defines options for
        Novell Directory Services.</t>

        <t><xref target="RFC2242">RFC2242</xref> defines an encapsulated
        option space for NWIP configuration.</t>

        <t><xref target="RFC2485">RFC2485</xref> defines the Open Group's
        UAP option.</t>

        <t><xref target="RFC2610">RFC2610</xref> defines options for
        the Service Location Protocol (SLP).</t>

        <t><xref target="RFC2937">RFC2937</xref> defines the Name Service
        Search Option (not to be confused with the domain-search option).
        The Name Service Search Option allows eg nsswitch.conf to be
        reconfigured via dhcp.  The ISC DHCP server implements this option,
        and the ISC DHCP client is compatible...but does not by default
        install this option's value.  One would need to make their relevant
        dhclient-script process this option in a way that is suitable for
        the system.</t>

        <t><xref target="RFC3004">RFC3004</xref> defines the User-Class
        option.  Note carefully that ISC DHCP currently does not implement
        to this reference, but has (inexplicably) selected an incompatible
        format: a plain text string.</t>

        <t><xref target="RFC3011">RFC3011</xref> defines the Subnet-Selection
        plain DHCPv4 option.  Do not confuse this option with the relay agent
        "link selection" sub-option, although their behaviour is
        similar.</t>

        <t><xref target="RFC3396">RFC3396</xref> documents both how long
        options may be encoded in DHCPv4 packets, and also how multiple
        instances of the same option code within a DHCPv4 packet will be
        decoded by receivers.</t>

        <t><xref target="RFC3397">RFC3397</xref> documents the Domain-Search
        Option, which allows the configuration of the /etc/resolv.conf
        'search' parameter in a way that is <xref target="RFC1035">RFC1035
        </xref> wire format compatible (in fact, it uses the RFC1035 wire
        format).  ISC DHCP has both client and server support, and supports
        RFC1035 name compression.</t>

        <t><xref target="RFC3679">RFC3679</xref> documents a number of
        options that were documented earlier in history, but were not
        made use of.</t>

        <t><xref target="RFC3925">RFC3925</xref> documents a pair of
        Enterprise-ID delimited option spaces for vendors to use in order
        to inform servers of their "vendor class" (sort of like 'uname'
        or 'who and what am I'), and a means to deliver vendor-specific
        and vendor-documented option codes and values.</t>

        <t><xref target="RFC3942">RFC3942</xref> redefined the 'site local'
        option space.</t>

        <t><xref target="RFC4280" /> defines two BCMS server options
        for each protocol family.</t>

        <t><xref target="RFC4388">RFC4388</xref> defined the DHCPv4
        LEASEQUERY message type and a number of suitable response messages,
        for the purpose of sharing information about DHCP served addresses
        and clients.</t>

        <section title="Relay Agent Information Option Options">
          <t><xref target="RFC3046">RFC3046</xref> defines the Relay Agent
          Information Option and provides a number of sub-option
          definitions.</t>

          <t><xref target="RFC3256">RFC3256</xref> defines the DOCSIS Device
          Class sub-option.</t>

          <t><xref target="RFC3527">RFC3527</xref> defines the Link Selection
          sub-option.</t>
        </section>


        <section title="Dynamic DNS Updates References">
          <t>The collection of documents that describe the standards-based
          method to update dns names of DHCP clients starts most easily
          with <xref target="RFC4703">RFC4703</xref> to define the overall
          architecture, travels through RFCs <xref target="RFC4702">4702</xref>
          and <xref target="RFC4704">4704</xref> to describe the DHCPv4 and
          DHCPv6 FQDN options (to carry the client name), and ends up at
          <xref target="RFC4701">RFC4701</xref> which describes the DHCID
          RR used in DNS to perform a kind of atomic locking.</t>

          <t>ISC DHCP adopted early versions of these documents, and has not
          yet synchronized with the final standards versions.</t>

          <t>For RFCs 4702 and 4704, the 'N' bit is not yet supported.  The
          result is that it is always set zero, and is ignored if set.</t>

          <t>For RFC4701, which is used to match client identities with names
          in the DNS as part of name conflict resolution.  Note that ISC DHCP's
          implementation of DHCIDs vary wildly from this specification.
          First, ISC DHCP uses a TXT record in which the contents are stored
          in hexadecimal.  Second, there is a flaw in the selection of the
          'Identifier Type', which results in a completely different value
          being selected than was defined in an older revision of this
          document...also this field is one byte prior to hexadecimal
          encoding rather than two.  Third, ISC DHCP does not use a digest
          type code.  Rather, all values for such TXT records are reached
          via an MD5 sum.  In short, nothing is compatible, but the
          principle of the TXT record is the same as the standard DHCID
          record.  However, for DHCPv6 FQDN, we do use DHCID type code '2',
          as no other value really makes sense in our context.</t>
        </section>

        <section title="Experimental: Failover References">
          <t>The Failover Protocol defines means by which two DHCP Servers
          can share all the relevant information about leases granted to
          DHCP clients on given networks, so that one of the two servers may
          fail and be survived by a server that can act responsibly.</t>

          <t>Unfortunately it has been quite some years (2003) since the last 
          time this document was edited, and the authors no longer show any
          interest in fielding comments or improving the document.</t>

          <t>The status of this protocol is very unsure, but ISC's
          implementation of it has proven stable and suitable for use in
          sizable production environments.</t>

          <t><xref target="draft-failover">draft-ietf-dhc-failover-12.txt</xref>
          describes the Failover Protocol.  In addition to what is described
          in this document, ISC DHCP has elected to make some experimental
          changes that may be revoked in a future version of ISC DHCP (if the
          draft authors do not adopt the new behaviour).  Specifically, ISC
          DHCP's POOLREQ behaviour differs substantially from what is
          documented in the draft, and the server also implements a form of
          'MAC Address Affinity' which is not described in the failover
          document.  The full nature of these changes have been described on
          the IETF DHC WG mailing list (which has archives), and also in ISC
          DHCP's manual pages.  Also note that although this document
          references a RECOVER-WAIT state, it does not document a protocol
          number assignment for this state.  As a consequence, ISC DHCP has
          elected to use the value 254.</t>

          <t> An optimization described in the failover protocol draft
          is included since 4.2.0a1. It permits a DHCP server
          operating in communications-interrupted state to 'rewind' a
          lease to the state most recently transmitted to its peer,
          greatly increasing a server's endurance in
          communications-interrupted.  This is supported using a new
          'rewind state' record on the dhcpd.leases entry for each
          lease.
          </t>

          <t><xref target="RFC3074" /> describes the Load Balancing
          Algorithm (LBA) that ISC DHCP uses in concert with the Failover
          protocol.  Note that versions 3.0.* are known to misimplement the
          hash algorithm (it will only use the low 4 bits of every byte of
          the hash bucket array).</t>
        </section>
      </section>

      <section title="DHCP Procedures">
        <t><xref target="RFC2939" /> explains how to go about
        obtaining a new DHCP Option code assignment.</t>
      </section>
    </section>


    <section title="DHCPv6 Protocol References">

      <section title="DHCPv6 Protocol References">
        <t>For now there is only one document that specifies the base
        of the DHCPv6 protocol (there have been no updates yet),
        <xref target="RFC3315"/>.</t>

        <t>Support for DHCPv6 was first added in version 4.0.0.  The server
        and client support only IA_NA.  While the server does support multiple
        IA_NAs within one packet from the client, our client only supports
        sending one.  There is no relay support.</t>

        <t>DHCPv6 introduces some new and uncomfortable ideas to the common
        software library.</t>

        <t>
        <list style="numbers">
          <t>Options sometimes may appear multiple times.  The common
          library used to treat all appearance of multiple options as
          specified in RFC2131 - to be concatenated.  DHCPv6 options
          may sometimes appear multiple times (such as with IA_NA or
          IAADDR), but often must not. As of 4.2.1-P1, multiple IA_NA, IA_PD
          or IA_TA are not supported.</t>

          <t>The same option space appears in DHCPv6 packets multiple times.
          If the packet was got via a relay, then the client's packet is
          stored to an option within the relay's packet...if there were two
          relays, this recurses.  At each of these steps, the root "DHCPv6
          option space" is used.  Further, a client packet may contain an
          IA_NA, which may contain an IAADDR - but really, in an abstract
          sense, this is again re-encapsulation of the DHCPv6 option space
          beneath options it also contains.</t>
        </list>
        </t>

        <t>Precisely how to correctly support the above conundrums has not
        quite yet been settled, so support is incomplete.</t>

        <t><xref target="RFC5453"/> creates a registry at IANA to reserve
        interface identifiers and specifies a starting set.  These IIDs should
        not be used when constructing addresses to avoid possible conflicts.</t>
      </section>

      <section title="DHCPv6 Options References">
        <t><xref target="RFC3319"/> defines the SIP server
        options for DHCPv6.</t>

        <t><xref target="RFC3646"/> documents the DHCPv6
        name-servers and domain-search options.</t>

        <t><xref target="RFC3633"/> documents the Identity
        Association Prefix Delegation for DHCPv6, which is included
        here for protocol wire reference, but which is not supported
        by ISC DHCP.</t>

        <t><xref target="RFC3898"/> documents four NIS options
        for delivering NIS servers and domain information in DHCPv6.</t>

        <t><xref target="RFC4075"/> defines the DHCPv6 SNTP
        Servers option.</t>

        <t><xref target="RFC4242"/> defines the Information
        Refresh Time option, which advises DHCPv6 Information-Request
        clients to return for updated information.</t>

        <t><xref target="RFC4280"/> defines two BCMS server options
        for each protocol family.</t>

        <t><xref target="RFC4580"/> defines a DHCPv6
        subscriber-id option, which is similar in principle to the DHCPv4
        relay agent option of the same name.</t>

        <t><xref target="RFC4649"/> defines a DHCPv6 remote-id
        option, which is similar in principle to the DHCPv4 relay agent
        remote-id.</t>

      </section>
    </section>

  </middle>

  <back>
    <references title="Published DHCPv4 References">
        &rfc760;
        &rfc768;
        &rfc894;
        &rfc951;
        &rfc1035;
        &rfc1188;
        &rfc1542;
        &rfc2131;
        &rfc2132;
        &rfc2241;
        &rfc2242;
        &rfc2485;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2563'?>
        &rfc2610;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2855'?>
        &rfc2937;
        &rfc2939;
        &rfc3004;
        &rfc3011;
        &rfc3046;
        &rfc3074;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3203'?>
        &rfc3256;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3361'?>
        &rfc3396;
        &rfc3397;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3442'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3456'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3495'?>
        &rfc3527;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3594'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3634'?>
        &rfc3679;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825'?>
        &rfc3925;
        &rfc3942;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3993'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4014'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4030'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4039'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4174'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4243'?>
        &rfc4361;
        &rfc4388;
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4390'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4436'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5010'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5071'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5107'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5192'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5223'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5859'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969'?>

        <reference anchor='draft-failover'>
          <front>
            <title>DHCP Failover Protocol</title>
            <author initials='R.' surname='Droms' fullname='Ralph Droms'>
                <organization abbrev='Cisco'>Cisco Systems</organization>
            </author>
            <date month='March' year='2003'/>
          </front>
          <format type="TXT" octets="312151" target="https://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt"/>
        </reference>

        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-relay-encapsulation-00.xml'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-bulk-leasequery-03.xml'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-leasequery-by-remote-id-09.xml'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-relay-id-suboption-07.xml'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mip6-hiopt-17.xml'?>

    </references>

    <references title="Published Common (DHCPv4/DHCPv6) References">
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4280'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4477'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4578'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4833'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5417'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5678'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5908'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5970'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5986'?>
        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-vpn-option-12.xml'?>

    </references>

    <references title="Published DHCPv6 References">

      &rfc3315;
      &rfc3319;
      &rfc3633;
      &rfc3646;
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736'?>
      &rfc3898;
      &rfc4075;
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4076'?>
      &rfc4242;
      &rfc4580;
      &rfc4649;
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4704'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4994'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5007'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5460'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-dhcpv6-route-option'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-ldra'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-relay-supplied-options'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-pd-exclude-01.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-secure-dhcpv6-02.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-pd'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-duid-uuid-03.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-ds-lite-tunnel-option-10.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-dns-server-selection-01.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-geopriv-rfc3825bis-17.xml'?>

      <reference anchor='draft-addr-params'>
        <front>
          <title>Address Parameters Option for DHCPv6</title>
          <author initials='T.' surname='Mrugalski' fullname='Mrugalski'>
            <organization abbrev='Cisco'>Gdansk University of Technology</organization>
          </author>
          <date month='April' year='2007'/>
        </front>
        <format type="TXT" target="http://klub.com.pl/dhcpv6/doc/draft-mrugalski-addropts-XX-2007-04-17.txt"/>
      </reference>

    </references>
  </back>
</rfc>