Network Working Group                                   Glenn Stump, IBM
INTERNET DRAFT                          Ralph Droms, Bucknell University
                                                           November 1997
                                                        Expires May 1998


                     The User Class Option for DHCP
                   <draft-ietf-dhc-userclass-02.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).

. Abstract

   This option is used by a DHCP client to optionally identify the type
   or category of user or applications it represents.  The information
   contained in this option is an NVT ASCII text object that represents
   the user class of which the client is a member.

. 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, Droms                                                    [Page 1]

 
DRAFT                The User Class Option for DHCP        November 1997


      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, Droms                                                    [Page 2]

 
DRAFT                The User Class Option for DHCP        November 1997


. User Class Information

   This option is used by a DHCP client to optionally identify the type
   or category of user or applications it represents.  The information
   contained in this option is an NVT ASCII text object that represents
   the user class of which the client is a member.

   DHCP administrators may define specific user class identifiers to
   convey information about a client's software configuration or about
   its user's preferences.  For example, an identifier may specify that
   a particular DHCP client is a member of the class "accounting
   auditors", which have special service needs such as a particular
   database server.

   Servers not equipped to interpret the user class specified by a
   client MUST ignore it (although it may be reported).  Otherwise,
   servers SHOULD respond with the set of options corresponding to the
   user class specified by the client.  Further, if the server responds
   with the set of options corresponding to the given user class, it
   MUST return this option (with the given user class value) to the
   client.

   Clients which do not receive information for the user class requested
   SHOULD make an attempt to operate without it, although they may do so
   (and may announce they are doing so) in a degraded mode.

   The code for this option is 77.  The minimum length for this option
   is two.

      Code   Len     text1
     +-----+-----+-----+-----+-----
     | 77  |  N  |  c1 |  c2 | ...
     +-----+-----+-----+-----+-----



Implemention Note: Simulating Multiple User Classes

   Although the user class option field only permits one NVT string, the
   working group envisions that multiple classes can be simulated by
   creating combination classes which map into a single class NVT
   string.  For example, suppose a site desires to create multiple
   logical user classes, including:

      "mobile"  -- These hosts receive short lease times
                   and are assumed to dynamically update
                   their own DNS records




Stump, Droms                                                    [Page 3]

 
DRAFT                The User Class Option for DHCP        November 1997


      "engineer" -- These hosts are assigned a high-
                   performance NFS file server


   For the above two classes, then, a combination class could look
   something like:

       "mobeng" -- hosts of this mobile-engineer combination
                   class get assigned a high-performance
                   file server and a short lease time, and
                   a DNS proxy A record update is not attempted
                   on their behalf.


   Thus, by mapping combinations of classes into single class names, you
   can effectively implement multiple user classing at a site using only
   the single NVT string field.



Implementation Note:  Serving Competing Option Values

   When servicing a request from a client of a particular user class, a
   DHCP server makes decisions about what collection of options to
   include in its response.  These decisions are expected to consider
   options and values designated for the client host by virtue of its
   subnet/location, vendor class, user class, or client id.

   In cases where multiple option values are possible for return to the
   client due to multiple, overlapping "affiliations", DHCP server
   policy may dictate which values take precedence over others.  A DHCP
   server implementation SHOULD provide flexibility in specifying DHCP
   option precedence policy so that DHCP administrators can customize a
   DHCP system to best suit their network environments.


   If flexibility in a server's option precedence policy is not
   implemented by a vendor (or is perhaps implemented but not exercised
   by an administrator), a recommended default policy is that option
   values of specific affiliations override those of less specific.
   That is, an option value designated for a specific client --
   sometimes known as a "reserved binding" -- SHOULD override option
   values designated for the client's user or vendor class, which SHOULD
   override option values designated for the client's vendor class,
   which SHOULD override option values for the client's subnet.






Stump, Droms                                                    [Page 4]

 
DRAFT                The User Class Option for DHCP        November 1997


Security Considerations

   DHCP currently provides no authentication or security mechanisms.
   Potential exposures to attack are discussed is section 7 of the
   protocol specification [1].


References

   [] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March
   1997

   [] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
   Extensions", RFC 2132, March 1997

Acknowledgments

Author Information


   Glenn Stump
   IBM Networking Software Solutions
   4205 South Miami Blvd.
   RTP, NC 27709
   Phone: (919) 254-5616
   email: glennstump@vnet.ibm.com

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837
   Phone: (717) 524-1145
   email: droms@bucknell.edu

















Stump, Droms                                                    [Page 5]