DHCP server selection internet draft

[Glenn Stump <[e-mail]>]

Hi all,

Below is a (significant) portion of a short draft which I plan 
to introduce in SanJose.  I missed the internet-draft cut-off 
date, but Ralph has kindly agreed to place the entire draft 
on the Bucknell anonymous ftp site early next week for the 
downloading.

Please check it out when you get a chance and we'll discuss
more here as well as in SanJose in a few weeks.

Regards, Glenn

---------------------------------------------------------------------------------------
Network Working Group                                   Glenn Stump, IBM
INTERNET DRAFT                                         Pratik Gupta, IBM
                                                           November 1996
                                                        Expires May 1996


                  The Server Selection Option for DHCP
                      <draft-ietf-dhc-sso-00.txt>

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 offer from a DHCP. The information
   contained in this option is an hex value that represents an integer
   value indicating 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 particular requirements are capitalized.  These words
   are:

      o "MUST"

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





Stump, Gupta                                                    [Page 1]

DRAFT                 DHCP Server Selection Option         November 1996


      o "MUST NOT"

        This phrase means that the item is an absolute prohibition
        of this specification.

      o "SHOULD"

        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 course.

      o "SHOULD NOT"

        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 weighed before implementing any behavior
        described with this label.

      o "MAY"

        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"

        A 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.





Stump, Gupta                                                    [Page 2]

DRAFT                 DHCP Server Selection Option         November 1996


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 many DHCP in order to enhance
   availability and/or performance of DHCP services.

   However, for networks 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 determined 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 which enables a server-based policy for determining
      how clients select among DHCP offers would allow a network
      administrator to control the manner in which 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.

      This document specifies an option that can be configured by
      network administrators in DHCP servers and which can influence how
      DHCP clients select an offer from among those servers.

3.1  Motivation

   In general, the motivation for inventing the DHCP Server Selection
   option originates  from shortcomings identified in networks where
   multiple DHCP servers are used enhance DHCP serving performance,
   availability, or both.   Specifically, these problems are:
   1. Server Segregation
   2. Server Aggregation
   3. Server Introduction and Deprecation
   4. DNS IP Address Mapping Stability



Stump, Gupta                                                    [Page 3]

DRAFT                 DHCP Server Selection Option         November 1996


   There may well be others which are important - or will be important
   given new capabilities in the future - and not listed above.   The
   DHCP Server Selection mechanism defined herein must be flexible
   enough to accommodate future requirements.

3.1.1  Server Segregation:  Differentiating Servers Based on Varying
   Priorities

   Multiple DHCP servers can also be segregated to differentiate the
   importance or roles of some DHCP server or servers vs.  others.  The
   simplest and most common example here is where one DHCP server is
   intended as a "primary" or "preferred" server for a subnet while some
   other server is intended as a "secondary" or "backup" server capacity
   in the case the primary fails.   Typically, the preferred server(s)
   will have the most number of available addresses and the backups have
   some lesser number, which are only intended for use when the
   preferred server(s) fail or their addresses are depleted.   Again,
   all servers are assumed to provide an equivalent set of options to a
   requesting client.

   Segregated DHCP server deployments present two fundamental problems
   for today's DHCP implementations:

   1. There is no standard means for a client to differentiate which
      of many equivalent offers to accept.  Assuming that most client
      implementations will accept the first of many equivalent offers
      received, a "backup" server's address pool will be depleted each
      time its offers are served first to a client.  This may happen
      frequently, for example, during times of peak loads on the
      preferred servers.

   2. Once an address lease from an "alternate" DHCP server is selected
      (for any reason), that address will likely be re-selected on sub-
      sequent client reboot/init-reboots.

   A mechanism which enables DHCP clients to select an offer based on an
   administrative preference by encouraging clients to always select a
   preferred DHCP server (or order of servers) over others who respond
   in the network.

   *** MAILING LIST DISCUSSION *** NOTE:  Such a mechanism could also
   help  in preventing DHCP service disruption due to the accidental
   introduction of rogue DHCP servers.  That is, if all clients would be
   configured to choose offers with the DHCP Server Selection when
   present, and all DHCP Server Vendors would disable the option by
   default, then a DHCP offer from a rogue DHCP server accidentally
   started by a novice would essentially be ignored.  Is this worth
   mentioning as a motivation?



Stump, Gupta                                                    [Page 4]

DRAFT                 DHCP Server Selection Option         November 1996


3.1.2  Server Aggregation:  Grouping Servers of Equal Priority

   Multiple DHCP servers, typically two, which have essentially
   equivalent configuration characteristics - typically in terms of the
   options served and the number of addresses available -- be aggregated
   to enhance the responsiveness and availability of DHCP services to a
   particular subnet.

   However, in the event that one of the DHCP servers responds more
   quickly than others the number of addresses available at one server
   (e.g., a "fast" server) may be disproportionately low.  Thus, failure
   of another server in the aggregated set (e.g., the other, "slower"
   server) will cause a disproportionately high risk in availability of
   DHCP services (e.g., when a slow server, with more available
   addresses, fails or is removed from operation temporarily).

   A mechanism which enables DHCP clients to select an offer based on
   server- administrated  preference could allow clients to choose
   leases from among servers in a way which could maintain a prescribed
   balance of address availability across servers (by maintaining a
   balance in the relative address depletion rates).

3.1.3  DHCP Server Introduction or Deprecation

   Currently, the process of changing the number of DHCP servers in a
   network cannot generally be done gradually or gracefully because,
   currently, there is no standard means of allowing servers to share IP
   address spaces.  A mechanism which enables DHCP clients to select an
   offer based on an administrative preference could help in this
   process by identifying particular DHCP servers to (or from) which
   clients should "migrate" (rather than continuing to use an existing
   server).

3.1.4  DNS Address Mapping Stability

   Regardless of whether multiple DHCP servers are aggregated,
   segregated, or a combination or both, a "mobile" DHCP client which...
      1. moves frequently across many networks or subnetworks, and/or.
      2. does not keep track of which leases are active beyond their current lease.
   connections and reconnections.  This is due to the fact that, the
   client would not necessarily choose a lease based on an active or
   previous lease association since it is not instructed to do so and/or
   is no aware that one exists.

   In network environments where either dynamic DNS updates are not
   employed or where there is a desire to minimize the number of updates
   to DNS mappings,  a mechanism to identify a lease representing a
   previous address association can be used to, in effect, reduce the



Stump, Gupta                                                    [Page 5]

DRAFT                 DHCP Server Selection Option         November 1996


   number of changes in a DNS host-name-to-address mapping (i.e., A-RR).

3.2  DHCP Server Selection Option Format

   The code for this option is TBD, and its length is 4 bytes.
          Code     Len       Priority
           +-------+-------+---------+---------+
           |  TBD  |   2   |         p         |
           +-------+-------+---------+---------+

        where:  "p" is the priority value chosen for the
                server (x'0000'- x'FFFF', inclusive).

   *** MAILING LIST DISCUSSION *** Should/can we use only len=1, or  8
   bits?

   It is envisioned that this field can be used in many ways to
   accomplish various system behavior across servers.  However, the
   values within this field must be administered consistently across all
   DHCP servers in "the system" (i.e., those serving a particular
   subnet) and across DHCP server vendors (so that the same basic
   capabilities are administered) in order to achieve the desired
   behaviors.

   To that end, the policies for acceptable uses of the priority field
   will be directed through the specification of DHCP Server Selection
   option "profiles", which will be maintained - at least for now -- as
   appendices to this document.   Each profile will list how the
   priority field value is derived, what DHCP serving behaviors are
   possible, and how these behaviors are achieved.

4.0  DHCP Client Behavior

   A client supporting the DHCP Server Selection option MUST use the
   DHCP Server Selection option as the primary discriminator for
   selecting among multiple offers from servers.  The highest priority
   value gets first preference. If two DHCP Server Selection priority
   values are equivalent, then the DHCP client can use other mechanisms
   as described in RFC1541 to choose among the offers.

   *** MAILING LIST DISCUSSION *** Should the client be required to use
   the DHCP Server Selection offer if present? In general, how should
   this option relate to other decision factors (implicit or explicit).

5.0  DHCP Server Behavior

   When a DHCP server supports the DHCP Server Selection option, the
   server MUST select a value for the field according to the policy set



Stump, Gupta                                                    [Page 6]

DRAFT                 DHCP Server Selection Option         November 1996


   forth by a selected DHCP Server Selection Option "profile".  The set
   of standardized DHCP Server Selection profiles will be maintained by
   the IETF DHC Working Group.  The current list of profiles under
   consideration is maintained in the appendices of this document.

   It is intended that all of the DHCP servers serving a particular
   subnet or set of hosts MUST support the same profile in order to
   achieve the associated/desired DHCP service behavior for that subnet
   or set of hosts.


6.0  Security Considerations

   There are currently no security mechanisms defined for the DHCP
   protocol.

7.0  References

   [RFC1533] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
   Extensions" [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:


9.0  Author Information

   Pratik Gupta
   IBM, Inc.
   4205 S.Miami Blvd
   Research Triangle Park, NC 27709
   Phone: [phone]
   email: [e-mail]

   Glenn Stump
   IBM, Inc.
   4205 S.Miami Blvd
   Research Triangle Park, NC 27709
   Phone: [phone]
   email: [e-mail]

Appendix A:  Profile 0  [Rank (only)]

   The DHCP Server Selection option specifies a mechanism for an
   administrator to determine the policy governing how a client chooses



Stump, Gupta                                                    [Page 7]

DRAFT                 DHCP Server Selection Option         November 1996


   among multiple DHCP offers.  In this profile, Profile 0,  the
   selection criteria used to govern DHCPOFFER selection policy is a
   simple, relative "ranking" value.  That is, a client will select the
   offer from the server with the highest designated priority.

A.1  DHCP Server Selection Option Format

   The code for this option is TBD, and its length is 4 bytes.
          Code     Len       Priority
           +-------+-------+---------+----------+
           |  TBD  |   2   |    r    | reserved |
           +-------+-------+---------+----------+

   where:
           r  =     rank, or relative priority,  of server (higher order 8 bits)
           reserved = reserved for future use;  must be x'00'

   The priority field is actually a concatenation of the "rank",
   "address availability, and "flags" field.  The "flags" field,
   represented in the lower order byte, can be used to instruct the
   client to give preference to offers from servers which have a
   currently active or recently expired lease  association.   The
   priority field, represented in the high order byte, can be used to
   instruct the client to accept a lease from a server according to some
   other criteria (see "DHCP Server Behavior" below).

A.2  DHCP Server Behavior

   When a server supports the "rank" field, the value can be statically
   pre-configured or dynamically calculated and set to any integer
   between x'00' and x'FF', inclusive.  The values can be coordinated
   across DHCP servers to achieve the desired priority system behavior.

A.3  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.

   The following outlines how the DHCP Server Selection option can be
   used in each of these situations to achieve the desired service
   behavior.  Note that these scenarios presume that there are no DHCP



Stump, Gupta                                                    [Page 8]

DRAFT                 DHCP Server Selection Option         November 1996


   server-to-server coordination mechanisms which could be used to
   synchronize the server's databases and effectively share address
   spaces.

A.3.1 Server Segregation

   DHCP servers which 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-backup
     -  graceful addition or deletion of DHCP servers

A.3.2  Server Aggregation

   DHCP servers which are assigned the same rank value, "r", are viewed
   by DHCP clients as equal.  That is, the servers are an aggregated set
   of equivalent servers, and offers from equivalent servers can be
   selected using some other criteria (e.g., first offer received).


   
Appendix B:  Profile 1 ...