draft-ietf-dhc-failover-07.txt

open source dhcp server client etc...

         for a single IP address.  It will be comprised of the
         assigned-IP-address option and the binding-status option, along
         other options as appropriate.

      o  "binding-status"

         The binding-status is the status of an IP address with respect
         to its association with a client.  There are specific binding-
         status values defined for use by the failover protocol, e.g.,
         ACTIVE, FREE, RELEASED, ABANDONED, etc.  These are designed to
         map more or less directly onto the binding-status values used
         internally in most DHCP server implementations.  The term
         binding-status refers to the concept also sometimes known as
         "lease state" or "IP address state", but in this document the
         term "state" is reserved for the failover state of a failover
         endpoint, and binding-status is always used to refer to the
         state associated with an IP address or lease.

      o "DHCP client" or "client"

        A DHCP client is an Internet host using DHCP to obtain confi-
        guration parameters such as a network address.  The term
        "client" used within this document always means a DHCP client,
        and never one of the two failover servers.

      o "DHCP server" or "server"

        A DHCP server is an Internet host that returns configuration
        parameters to DHCP clients.

      o "DDNS"

        An abbreviation for "Dynamic DNS", which refers to the capabil-
        ity to update a DNS server's name (actually resource record)
        database using an on-the-wire protocol defined in [RFC 2136].

      o "DNS"

        An abbreviation for "Domain Name System", a scheme where a cen-
        tral name repository is used to map names to IP addresses and IP
        addresses to names.

      o "failover endpoint"

        The failover protocol allows for there to be a unique failover
        endpoint per partner per role (where role is primary or secon-
        dary).  This failover endpoint can take actions and hold unique
        states.  There are thus a maximum of two failover endpoints per



Droms, et. al.            Expires January 2001                  [Page 6]

Internet Draft           DHCP Failover Protocol               July 2000


        server per partner (one for each partner as a primary and one
        for that same partner as a secondary.)

      o "FQDN"

        An FQDN is a "fully qualified domain name".  A fully qualified
        domain name generally is a host name with at least one zone
        name, for example "www.dhcp.org" is a fully qualified domain
        name.

      o "lazy update"

        Lazy update refers to the requirement placed on a server imple-
        menting a failover protocol to update its failover partner when-
        ever the binding database changes.  A failover protocol which
        didn't support lazy update would require the failover partner
        update to be complete before a DHCP server could respond to a
        DHCP client request with a DHCPACK.  A failover protocol which
        does support lazy update places no such restriction on the
        update of the failover partner server, and so a server can allo-
        cate an IP address or extend a lease on an IP address and then
        update its failover partner as time permits.  A failover proto-
        col which supports lazy update not only removes the requirement
        to update the failover partner prior to responding to a DHCP
        client with a DHCPACK, but also allows gathering up batches of
        updates from one failover server to its partner.

      o "MCLT"

        The MCLT refers to maximum client lead time.  This time is con-
        figured on the primary server and transmitted from the primary
        to the secondary server in the CONNECT message.  It is the max-
        imum amount of time that one server can extend a lease for a
        client's binding beyond the time known by the partner server.
        See section 5.2.1 for details.

      o "partner"

        A "partner", for the purposes of this document, refers to a
        failover server, typically the other failover server.  In many
        (if not most) cases, the failover protocol is symmetric with
        respect to the primary or secondary nature of the servers, and
        so it is often appropriate to discuss "updating the partner
        server", since it could be a primary server updating a secondary
        server or a secondary server updating a primary server.

      o "Primary server" or "Primary"




Droms, et. al.            Expires January 2001                  [Page 7]

Internet Draft           DHCP Failover Protocol               July 2000


        A DHCP server configured to provide primary service to a set of
        DHCP clients for a particular set of subnet address pools.

      o "RR"

        "RR" is an abbreviation for "resource record".  All records in
        the DNS are resource records.  The resource records of most
        relevance to this document are the "A" resource record, which
        maps a DNS name to a particular IP address, the "PTR" resource
        record, which allows a "reverse map", from the IP address back
        to a DNS name, and the "KEY" resource record, which is used in
        ways defined in [DDNS] to tag a DNS name with the identity of
        the DHCP client with which it is associated.

      o "Secondary server" or "Secondary"

        A DHCP server configured to act as backup to a primary server
        for a particular set of subnet address pools.

      o "stable storage"

        Every DHCP server is assumed to have some form of what is called
        "stable storage".  Stable storage is used to hold information
        concerning IP address bindings (among other things) so that this
        information is not lost in the event of a server failure which
        requires restart of the server.

      o "state"

        In this document, the term "state" refers exclusively to the
        state of a failover endpoint, for example: NORMAL,
        COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN.  It is not used to
        refer to any attributes of an IP address or a binding of an IP
        address.  See "binding-status".

      o "subnet address pool"

        A subnet address pool is the set of IP addresses which is asso-
        ciated with a particular network number and subnet mask.  In the
        simple case, there is a single network number and subnet mask
        and a set of IP addresses.  In the more complex case (sometimes
        called "secondary subnets", sometimes "superscopes"), several
        (apparently unrelated) network number and subnet mask combina-
        tions with their associated IP addresses may all be configured
        together into one subnet address pool.






Droms, et. al.            Expires January 2001                  [Page 8]

Internet Draft           DHCP Failover Protocol               July 2000


3.  Background and External Requirements

   This section highlights key aspects of the DHCP protocol on which the
   failover protocol depends.  It also discusses the requirements that
   the failover protocol places on other aspects of the network infras-
   tructure, and some general issues surrounding server failure detec-
   tion.  Some failure scenarios that provide particular challenges to a
   failover protocol are discussed.  Finally, the challenges inherent in
   using a TCP connection as a means to detect failure of a partner
   server are elaborated.

3.1.  Key aspects of the DHCP protocol

   The failover protocol is designed to augment the DHCP protocol as
   described in RFC 2131 [RFC 2131].  There are several key aspects of
   the DHCP protocol which are required by the failover protocol in
   order to successfully meet its design goals.

3.1.1.  Broadcast behavior

   There are two aspects of the broadcast behavior of the DHCP protocol
   which are key to making the failover protocol operate successfully.
   The first is simply that the DHCP protocol requires a DHCP client to
   broadcast all DHCPDISCOVER and DHCPREQUEST/INIT-REBOOT messages.
   Because of this requirement, a DHCP client who was communicating with
   one server will automatically be able to communicate with another
   server if one is available.

   The second aspect of broadcast behavior is similar to the first, but
   involves the distinction between a DHCPREQUEST/RENEW and
   DHCPREQUEST/REBINDING.  A DHCPREQUEST/RENEW is the message that a
   DHCP client uses to extend its lease.  It is unicast to the DHCP
   server from which it acquired the lease.   However, the DHCP protocol
   (in a farsighted move), was explicitly designed so that in the event
   that a DHCP client cannot contact the server from which it received a
   lease on an IP address using a DHCPREQUEST/RENEW, the client is
   required to broadcast its renewal using a DHCPREQUEST/REBINDING to
   any available DHCP server.  Since all DHCP clients were required to
   implement this algorithm, the failover protocol can have a different
   server from the one that initially granted a lease be the server to
   renew a lease.  Thus, one server can take over for another with no
   interruption in the service as experienced by the DHCP client or its
   associated applications software.

3.1.2.  Client responsibility

   In the DHCP protocol the DHCP clients are entrusted with a consider-
   able responsibility.  In particular, after they are granted a lease



Droms, et. al.            Expires January 2001                  [Page 9]

Internet Draft           DHCP Failover Protocol               July 2000


   on an IP address, they are enjoined to only use that IP address while
   their lease is valid.  Every DHCP client is expected to stop using an
   IP address if the expiration time on the lease has passed and if it
   cannot get an extension on the lease for that IP address from some
   DHCP server.  Thus, the correct behavior of every DHCP client in this
   regard is required to ensure the integrity of the DHCP service.  On
   the other hand, incorrect behavior by a client in this area will tend
   to adversely affect at most one other DHCP client.

   Furthermore, any DHCP client which sends in a DHCPREQUEST/RENEW or
   DHCPREQUEST/REBINDING to a DHCP server (either unicast for a RENEW or
   broadcast for a REBINDING) MUST still have time to run on the lease
   for that IP address.  The DHCP server sends the DHCPACK back unicast
   to the IP address from which the RENEW or REBINDING originated.

   Given the existing responsibility placed on the client to only use an
   IP address when the lease is valid, and to only send in a RENEW or
   REBINDING if the lease is valid, the failover protocol relies on DHCP
   clients to perform responsibly and will, in the absence of conflict-
   ing information, believe a DHCP client that is attempting to RENEW or
   REBIND a lease on an IP address is the legitimate owner of that IP
   address.

   If clients do not follow these rules, it is possible for an address
   to be in use by more than one client. For a single server, this hap-
   pens because the server has leased the expired address to another
   client and the original client is also attempting to use the address.
   The server would NAK the renewal request. This is made slightly worse
   in the failover protocol if the two servers are unable to communicate
   with each other and one server leases an available address to a new
   client while the other server receives a renewal from a different
   client.  In this case, both servers lease the same address to dif-
   ferent clients for the MCLT time.

   One troublesome issue is that of the DHCP client responsibility when
   sending in DHCPREQUEST/INIT-REBOOT requests.  While the original DHCP
   RFC was written to require a DHCP client to have time left to run on
   the lease for an IP address if the client is sending an INIT-REBOOT
   request, it was sufficiently unclear that some client vendors didn't
   realize this until recently.  Since the INIT-REBOOT request was sent
   with the IP address in the dhcp-requested-address option and not in
   the ciaddr (for perfectly good reasons), the similarity to the RENEW
   and REBINDING case was lost on many people.

   At present, the failover protocol does not assume that a client send-
   ing in an INIT-REBOOT request necessarily has a valid lease on the IP
   address appearing in the dhcp-requested-address option in the INIT-
   REBOOT request.



Droms, et. al.            Expires January 2001                 [Page 10]

Internet Draft           DHCP Failover Protocol               July 2000


   The implications of this are as follows: Assume that there is a DHCP