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

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 3004

Network Working Group                                   Glenn Stump, IBM
INTERNET DRAFT                          Ralph Droms, Bucknell University
Obsoletes: draft-ietf-dhc-userclass-02.txt                 November 1998
                                                        Expires May 1999


                     The User Class Option for DHCP
                   <draft-ietf-dhc-userclass-03.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 view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (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.

1. Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

2. DHCP Terminology

   o "DHCP client"

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





Stump, Droms                                                    [Page 1]


DRAFT                The User Class Option for DHCP        November 1998


   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.

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

   This option is a DHCP option [1, 2].

   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 TBD.  The minimum length for this option
   is two.

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





Stump, Droms                                                    [Page 2]


DRAFT                The User Class Option for DHCP        November 1998


   DISCUSSION: 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

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



   DISCUSSION:  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.




Stump, Droms                                                    [Page 3]


DRAFT                The User Class Option for DHCP        November 1998


      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.


4. Security Considerations

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


5. References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
       March 1997.

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

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels," RFC 2119, March 1997.






















Stump, Droms                                                    [Page 4]


DRAFT                The User Class Option for DHCP        November 1998


6. Author Information


   Glenn Stump
   IBM Networking Software
   P.O. Box 12195
   RTP, NC 27709
   Phone: (919) 301-4277
   email: stumpga@us.ibm.com

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

7. Expiration

   This document will expire on May 31, 1999.


   Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Stump, Droms                                                    [Page 5]


DRAFT                The User Class Option for DHCP        November 1998


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















































Stump, Droms                                                    [Page 6]


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