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


               The Server Identification Option for DHCP
                      <draft-ietf-dhc-sio-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 to identify
   the origin of a DHCPOFFER -- on a basis other than a server's IP
   address -- so that a DHCP client may optionally select from among
   multiple offers based on a client's preference to a particular DHCP
   server(s).  The information contained in this option is a hex value
   indicating the assigned identification of the server originating the
   DHCPOFFER 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:

      MUST

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




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

 
DRAFT              DHCP Server Identification Option          March 1997


      MUST NOT

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

      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.

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

      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"

           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-sio-00.txt                                       [Page 2]

 
DRAFT              DHCP Server Identification Option          March 1997


3.0  The DHCP Server Identification 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 servers 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 "pre-specify" a
   preference for offers from a particular DHCP server -- or set of
   servers -- on the network.  Such a means would allow, for example,
   clients on a large, switched LAN subnet to choose DHCPOFFERs from a
   preferred, "local" DHCP server (e.g.,one located on the same floor of
   the building and adminstered by the client host user's department).

   The DHCP protocol specification [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 of many offers is selected.  In
   practice, most vendors' implementation of "policy" here is very basic
   (e.g., first offer received) and is "hard-coded" (i.e., non-
   configurable).

   In order for a client to choose a DHCPOFFER from a particular DHCP
   server, it must have a means of identifying the server.  That is,
   unless a DHCP client can identify an individual server, the client
   has no means by which to select it.

   Thus, the problem of a client specifying a preference for a
   particular server is simply that of identifying DHCP servers to the
   client so that the client can select a DHCPOFFER from a particular
   server (e.g., by matching a pre-configured, preferred server identity
   against the set of server identities contained in DHCPOFFERs
   received).


   This document specifies an option that can be specified at DHCP
   servers by network administrators to identify particular DHCP server
   (or servers) to DHCP clients in order to enable the DHCP clients to
   select from available identities.  The option, known as the DHCP



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

 
DRAFT              DHCP Server Identification Option          March 1997


   Server Identification Option, specifies a simple DHCP server
   identification value to be included in DHCPOFFERs so that DHCP
   clients can distinguish among DHCP servers when making an offer
   selection decision.

4.0  DHCP Server Identification Option Format

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

          Code     Len       DHCP Server ID
           +-------+-------+---------+----------+
           |  TBD  |   2   |     server_id      |
           +-------+-------+---------+----------+

   where:
           server_id is an unsigned integer (x'00' thru x'FF',
           inclusive)which identifies the DHCP server originating
           the DHCPOFFER packet in which the option is contained.

5.0  DHCP Server Behavior

   A DHCP Server which supports the DHCP Server Identification Option
   MUST include the option in (and only in?) DHCPOFFER packets to
   requesting clients.  Note that there is no requirement for the
   server_id values to be unique in a subnet or across the network. That
   is, two or more DHCP servers may share the same server_id value and
   therefore be considered equivalent from the perspective of the DHCP
   client's selection decision.

   In the case where a DHCP Server Identification Option with server_id
   value is included in a client's DHCPDISCOVER message and the
   server_id value does not match that of the server, then the server
   MAY ignore the DHCPDISCOVER.  If the DHCP Server Identification
   Option is included (in the requested parameter list) without a
   server_id value, then the DHCP Server SHOULD respond with a DHCPOFFER
   and include the appropriate server_id value in the DHCP Server
   Identification option (assuming an available address/binding and
   defined server_id value exist).

6.0  DHCP Client Behavior

   A DHCP client MAY use the DHCP Server Identification Option to make a
   DHCPOFFER selection decision. If two DHCPOFFERs have equivalent DHCP
   Server Identification Option values or if no DHCP Server
   Identification Option is included, then the DHCP client SHOULD report
   the error and SHOULD use another mechanism to choose from among the
   multiple offers.




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

 
DRAFT              DHCP Server Identification Option          March 1997


   Also, note that a client may specify a DHCP Server Identification
   Option in a DHCPDISCOVER to express a preference for a particular
   DHCP server  (Is this a good idea?  ...seems harmless, but what's the
   point...unless a particular implied behavior?).



7.0  Application Notes

   The DHCP Server Identification option allows a DHCP client to select
   a DHCPOFFER from a preferred server or servers. The following
   sections outline some useful applications of this capability:

7.1  DHCP Server Segregation within (large) Subnets

   In large, flat networks (e.g., large, switched LANs), the DHCP Server
   Identification option can be used to "assign" groups of clients to be
   served by a particular DHCP server (e.g., one which serves a
   particular workgroup/department/organization or a particular building
   or floor of a building).  This is accomplished by configuring clients
   to prefer DHCPOFFERs with a designated DHCP server identification
   option value.

7.2  Pre-production Testing of DHCP Servers

   Similarly, in networks where a DHCP Server is being introduced into
   production, DHCP clients which support the DHCP server identification
   option can be used to specifically exercise that newly introduced
   DHCP server for the purposes of testing configuration correctness,
   etc.

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:  Thomas
   Narten, Esther Burwell, Ralph Droms




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

 
DRAFT              DHCP Server Identification Option          March 1997


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-sio-00.txt                                       [Page 6]