[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 02 03

Network Working Group                                   Glenn Stump, IBM
INTERNET DRAFT                                         Pratik Gupta, IBM
                                                              March 1997
                                                  Expires September 1997

                  The Server Selection Option for DHCP

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

1.0  Abstract

   This option is provided by DHCP servers to DHCP clients so that
   clients may optionally select from among multiple offers received
   from DHCP servers in the network based on a network-administrated
   preference system.  The information contained in this option is a hex
   value that represents the priority of the offer in which this option
   is contained.

2.0  Definitions

   Throughout this document, the words that are used to define the
   significance of the particular requirements are capitalized.  These
   words are:


           This word or the adjective "REQUIRED" means that the item is
           an absolute requirement of this specification.

      MUST NOT

draft-ietf-dhc-sso-00.txt                                       [Page 1]

DRAFT                 DHCP Server Selection Option            March 1997

           This phrase means the item is an absolute prohibition of this


           This word or the adjective "RECOMMENDED" means that there may
           exist valid reasons in particular circumstances to ignore
           this item, but the full implications should be understood and
           the case carefully weighed before choosing a different


           This phrase means that there may exist valid reasons in
           particular circumstances when the listed behavior is
           acceptable or even useful, but the full implications should
           be understood and the case carefully weighted before
           implementing any behavior described with this label.


           This word or the adjective "OPTIONAL" means that this item is
           truly optional.  One vendor may choose to include the item
           because a particular marketplace requires it or because it
           enhances the product, for example, another vendor may omit
           the same item.

   This document also uses the following terms:

      o "DHCP client"

           DHCP client or "client" is an Internet host using DHCP to
           obtain configuration parameters such as a network address.

      o "DHCP server"

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

      o "binding"

           A binding is a collection of configuration parameters,
           including at least an IP address, associated with or "bound
           to" a DHCP client.  Bindings are managed by DHCP servers.

draft-ietf-dhc-sso-00.txt                                       [Page 2]

DRAFT                 DHCP Server Selection Option            March 1997

3.0  The DHCP Server Selection Option

   DHCP provides a powerful mechanism for automating and centralizing
   the administration of IP host configuration and has become a critical
   service in many large IP networks.  Because of its importance in
   networks and because it can create a single point of failure for
   network operations (from a DHCP client's perspective), many network
   administrators choose to deploy multiple DHCP servers in order to
   enhance availability and/or performance of DHCP services.

   However, for sites with multiple DHCP servers, the DHCP protocol does
   not provide a means by which a DHCP client may select from among the
   DHCP server offers according to policy defined by the network
   administrator.  The protocol [see RFC1541 or current internet draft]
   currently states that:

      "DHCP clients are free to use any strategy in selecting a DHCP server
      among those from which the client receives a DHCPOFFER message.

   Thus, currently, client "policy" , of which there is essentially no
   standardization, determines which offer is selected.  What's worse is
   that, in practice, most vendor's implementation of policy here is
   very basic (e.g., first offer received) and is "hard-coded" (i.e.,
   non- configurable).

   A mechanism that enables a server-based policy for determining how
   clients select among DHCP offers can provide a network administrator
   better control over how addresses are allocated across the multiple
   DHCP servers. This type of control takes on increased importance
   considering that IP address spaces cannot generally be shared across
   DHCP servers, thus requiring network administrators to divide the
   available addresses among many DHCP servers.

   For example, suppose a site requires local "primary" DHCP server and
   a remoted "backup" DHCP server. The administrator would want local
   DHCP clients to choose an offer from the primary DHCP server if
   available, or one from the "backup" only when the primary weren't
   responding.  The DHCP Server Selection Option can be used to
   institute this kind of DHCP serving policy.

   The DHCP Server Selection Option specifies a simple, relative
   "ranking" value associated with -- and contained in -- each server's
   DHCPOFFER.  The client can simply compare the relative "ranking"
   values of all the DHCPOFFERs received and choose the DHCPOFFER with
   the highest ranking value.

4.0  DHCP Server Selection Option Format

draft-ietf-dhc-sso-00.txt                                       [Page 3]

DRAFT                 DHCP Server Selection Option            March 1997

   The code for this option is TBD, and its length is 4 bytes.

          Code     Len       Priority
           |  TBD  |   2   |       rank         |

           r  =     rank, or relative priority (unsigned number),
                    of the server offer in which this option is
                    contained. The allowable range is x'00' to
                    x'FF', inclusive.

5.0  DHCP Server Behavior

   A DHCP Server which supports the DHCP Server Selection Option MUST
   include the option in (and only in?) DHCPOFFER packets to requesting
   clients.  The value "rank" in the priority field can be statically
   pre-configured or dynamically calculated.  Further, these values can
   be coordinated across DHCP servers to achieve the desired priority
   system behavior (see "Application Notes" below).  However, the rules
   for this coordination and the associated methods for determining the
   ranking values are considered server or administrative policy.

6.0  DHCP Client Behavior

   A DHCP client which supports the DHCP Server Selection option SHOULD
   use the DHCP Server Selection option as the primary discriminator for
   selecting among DHCPOFFERs from multiple DHCP servers.  The highest
   priority offer -- that containing the highest "rank" value in the
   DHCP Server Selection Option of the offer -- should be selected.  If
   two DHCPOFFERs have equivalent DHCP Server Selection priority values,
   then the DHCP client can use other mechanisms to choose among the
   equivalent offers.

7.0  Application Notes

   The DHCP Server Selection option allows the DHCP/network
   administrator to control DHCP services characteristics by influencing
   the way addresses are allocated across a set of DHCP servers.  The
   administrator may wish to configure all of the servers to have equal
   serving priority or to configure some to have a greater priority than
   others. Further, not only can the network administrator prescribe an
   address allocation scheme across DHCP servers, but the option can
   also be used to enable the servers to return to the prescribed state
   in the event that a server failure resulted in an imbalance.

draft-ietf-dhc-sso-00.txt                                       [Page 4]

DRAFT                 DHCP Server Selection Option            March 1997

   The following sections outline how the DHCP Server Selection option
   can be used to achieve a desired service behavior:

7.1  DHCP Server Segregation

   DHCP servers that are assigned different rank values, "r", are viewed
   by DHCP clients as having varying priorities.  That is, the DHCP
   servers are segregated according to a distinct priority system (set
   by the DHCP system administrator).  Clients will choose an offer
   received from the server with the highest assigned rank value, "r".

   Once a client can differentiate priorities among DHCP servers, the
   DHCP administrator can manipulate the priorities across DHCP servers
   to affect the DHCP serving system behavior, such as "primary-and-

   A simple example of the DHCP Server Selection Option used for the
   DHCP server segration would be a customer environment where a remoted
   "branch office" subnet has one local "primary" DHCP server and one
   (remote) "backup" at the corporate headquarter's IS center. The DHCP
   clients on the branch office subnet would choose an offer from one of
   the primary DHCP servers if available, or one from the "backup" in
   the event the primary wasn't operational (or wasn't responding in a
   timely fashion due to, for example, peak load).

7.2  DHCP Server Aggregation

   DHCP servers which assign the same rank value, "r", in their
   DHCPOFFERs are perceived by DHCP clients as equals.  That is, the
   servers are effectively an aggregated set of equivalent servers, and
   offers from equivalent servers can be selected using some other
   criteria (e.g., best option match, first offer received, or other
   client-based policy).

   An example where server aggregation is useful is a customer
   environment similar to the "primary-and-backup" example used above,
   but where a second local "primary" DHCP server is deployed (e.g., for
   the purposes of better service availability and for responsiveness
   during peak loads). Here, the "branch office" clients would always
   choose an offer from one of the primary DHCP servers (without
   preference) if available, or else from one from the "backup" in the
   event neither primary were operational.

7.3 Minimization of Change in Address Mappings

   The working group has discussed cases where clients can either forget
   (e.g., due to lost data) or not have the ability to remember (e.g.,
   due to lack of local store) a current binding.  This lack of memory

draft-ietf-dhc-sso-00.txt                                       [Page 5]

DRAFT                 DHCP Server Selection Option            March 1997

   can lead to undesirable results such as multiple active bindings for
   a client on a particular subnet as well as an associated DNS address
   mapping changes.

   The DHCP Server Selection option can be used here to effectively help
   the client "remember" that they have an active (or recent) binding
   reserved at a particular DHCP Server, thus resulting in less DNS
   mapping.  For example, a DHCP Server may be programmed to respond
   with a very high value(e.g., x'FFFF') to clients for which the DHCP
   Server has an active (or recent) binding.

6.0  Security Considerations

   There are currently no security mechanisms defined for the DHCP

7.0  References

   [RFC1533] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor

   [RFC1541] R. Droms, "Dynamic Host Configuration Protocol"

8.0  Acknowledgments

The authors would like to thank the following people for their review
and helpful comments in the formulation of this paper:  Thomas Narten,
Esther Burwell, Ralph Droms

9.0  Author Information

Pratik Gupta
IBM, Inc.
4205 S.Miami Blvd
Research Triangle Park, NC 27709
Phone: (919)254-5654
email: pratik_gupta@vnet.ibm.com

Glenn Stump
IBM, Inc.
4205 S.Miami Blvd
Research Triangle Park, NC 27709
Phone: (919)254-5616
email: glennstump@vnet.ibm.com

draft-ietf-dhc-sso-00.txt                                       [Page 6]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/