Network Working GroupInternet Engineering Task Force       Glenn Stump, IBM
INTERNET DRAFT                        Ralph Droms, Bucknell University
Obsoletes: draft-ietf-dhc-userclass-02.txt                 November 1998
                                                        Expires May
Date: October 1999                    Ye Gu, Ramesh Vyaghrapuri,
Expires: April 2000                   Ann Demirtjis, Microsoft
                                      Burcak Beser, 3Com
                                      Jerome Privat, BT

                The User Class Option for DHCP
                   <draft-ietf-dhc-userclass-03.txt>
                <draft-ietf-dhc-userclass-04.txt>

Status of this Memo

   This

The document is an Internet-Draft. Internet-Draft and is in full conformance with all
of the provisions of Section 10 of RFC 2026.

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 Intenet-Drafts as reference
material or to cite them other than as ``work "work in progress.''

   To view the entire progress."

The list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft 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). can be accessed at
http://www.ietf.org/shadow.html.

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
Based on 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 class, a network address.

DRAFT                The User Class Option for DHCP        November 1998

   o "DHCP server"

     A DHCP server of "server"is selects the appropriate address
pool to assign an Internet host that returns address to the client and the appropriate
configuration parameters parameters.
This document attempts to DHCP clients.

   o "binding"

     A binding merge draft-ietf-dhc-userclass-03.txt
and draft-ietf-dhc-useraddr-00.txt.

1. Introduction

It is a collection often desirable to provide different levels of service
to different users of configuration parameters, including
     at least an IP address, associated with or "bound to" network.
In order for an IP network to implement this service
differentiation, it needs a DHCP
     client.  Bindings are managed by DHCP servers.

3. User Class Information

   This option way to classify users. A simple
solution to this is used by to use source IP addresses for classification.
Under this scheme, network administrators first configure network
devices such as routers to recognize traffic from a DHCP client particular
source IP address (or address range) and handle it specially to optionally identify
meet the type
   or category desired level of user or applications it represents.  The information
   contained in this option is an NVT ASCII text object service. Next, they assign the IP
addresses to the hosts of the intended users so that represents the user class will
receive the appropriate level of which service. They can configure the client is a member.

   This option is
hosts manually with these addresses. However, they cannot use DHCP
for address assignment, even if they are already running a DHCP option
server in their network. A current RFC-compliant DHCP server assigns
IP addresses based on the location of the DHCP Client in the network
topology, not the type of user it supports.
This document describes a simple extension of the DHCP protocol
that enables a DHCP server to assign IP addresses from different
address pools depending on the types of client from which it receives
DHCP requests. With this new extension, network administrators will
be able to use DHCP to hand out the appropriate addresses to clients.
An example intended usage is a corporate network subnet consisting
of different departments of users, such as Accounting, Legal, Staff,
etc. It may be desirable to allocate logical address pools to each
of the departments so that network policies may be implemented easily
on IP address ranges; and this would facilitate providing differential
services, such as network reachibility.
A DHCP server can also use the information contained in the User Class
to allocate other configuration parameters than the IP address. For
example, a DHCP server receiving a request from a client with the User
Class set to "accounting auditors" may return an option with the
address of a particular database server.
Indeed a DHCP server may have a single pool of addresses and only use
the user class to select parameters other than IP addresses.

2. 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].

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

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.

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

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

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

5. Server behaviour

Each address pool on the DHCP Server MAY be configured with a
set of ALLOWED USER CLASSES, specifying the category of clients
that can be offered addresses from the address pool; and with a member
set of DISALLOWED USER CLASSES, specifying the class "accounting
   auditors", which have special service needs such as category of
clients that must NOT be offered addresses from the address pool.

In this section, we consider the simple case where the user can
send a particular
   database server. single User Class. Section 6 discusses potential multiple
classes support.

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 whenever any DHCP client message is seen by the client.  Further, DHCP
server, it MUST do the regular processing and if the DHCP server responds
   with
determines that the set of options corresponding Client is to be offered a new (or unbound) IP
address, the given user class, it following procedure MUST return this option (with be adopted:

If the given user class value) to client DHCP message does not contain a User Class
option, then the
   client.

   Clients DHCP Server MUST attempt to choose an available
address pool which has both the ALLOWED and DISALLOWED USER CLASSES
empty. If no such address pool is available, and if the DHCP Server
has been specifically configured to do not receive information so, it MUST attempt to choose
an address from any available address pool.

If the Client DHCP message contains a User Class option, then
the DHCP server MUST attempt to choose an available address pool
for which the ALLOWED USER CLASSES set contains the user
class requested option present in the DHCP message. It SHOULD make an attempt also check that
the User Class option present in the DHCP message is NOT present
in the DISALLOWED USER CLASS set [this is to operate without it, although they may do so
   (and may announce they are doing so) cope with possible
misconfigurations in which an administrator will have by mistake put
a degraded mode.

   The code for this option User Class in both the ALLOWED and the DISALLOWED sets].
If no such address pool is TBD.  The minimum length available, and if the DHCP Server has been
specifically configured to do so, it MUST attempt to choose any
address pool for this option
   is two.

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

DRAFT                The which the User Class Option for options present in
the DHCP        November 1998

   DISCUSSION: Simulating Multiple User Classes

      Although message is NOT present in the DISALLOWED USER CLASS set.

If the server responds with all the parameters corresponding to
the given user class class, it MUST return this option field only permits one NVT string, (with 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 given
user classes, including:

         "mobile"  -- These hosts receive short lease times
                      and are assumed class value) 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 client.

If the DHCP 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 unable to find a site
      using only suitable address pool, it
MUST NOT offer an IP address to the single NVT string field. Client. It MAY indicate the
condition to the administrator.

DISCUSSION:  Serving Competing Option Values

When servicing a request from a client of a particular user class,
a DHCP server makes decisions about what address and what collection
of options to include in its response. These decisions are expected
to consider addresses, 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 addresses or 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.

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

6. Multiple User Classes

This section intends to raise some of the issues associated with
supporting multiple user classes. Feedback from the Working Group
is welcome.

- Should we allow a client to send multiple User Classes to a
server?
If yes:
- Should we allow the client to send the option twice in a message
with each option instance containing one class or should we let the
user concatenate classes inside one option?
- How should the server behave?
option1: the server considers the classes to be ANDed
[ie. chooses an address pool for which the ALLOWED USER CLASSES set
contains all the User Classes present in the DHCP message and
the DISALLOWED USER CLASSES set contains none of the User Classes
in the DHCP message].
option 2: the server considers the classes to be ORed
[ie. chooses an address pool for which the ALLOWED USER CLASSES set
contains one of the User Classes present in the DHCP message and
the DISALLOWED USER CLASSES set contains none of the User Classes
in the DHCP message].
option 3: the server should not assume anything and the administrator
of the server MUST define the behaviour.

7. Client behaviour

If a specific client -- sometimes known as receives a "reserved binding" -- SHOULD
      override response from a DHCP Server with the same User
Class option values designated for value as it puts in its request, then it knows that the client's
server responded with parameters corresponding to the given user or vendor
      class,
class.
Clients which SHOULD override option values designated do not receive all the configuration for the
      client's vendor class, user class
requested but which received an IP address SHOULD override option values for make an attempt to
operate without it, although they may do so (and may announce they are
doing so) in a degraded mode.
Clients which do not receive an IP address because of the
      client's subnet.

4. User Class
requested MUST announce it.

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

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

DRAFT                The User Class Option for DHCP        November 1998

6.

10. Acknowledgments

This document attempts to merge draft-ietf-dhc-userclass-03.txt
(by Glen Stump and Ralph Droms) and
draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and
Burcak Beser).

11. Author Information

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

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

7.

Ye Gu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425 936 8601
Email: yegu@microsoft.com

Ramesh Vyaghrapuri
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425 703 9581
Email: rameshv@microsoft.com

Burcak Beser
3Com Corporation
3800 Golf Road
Rolling Meadows, IL
Phone: 847 262 2195
Email: Burcak_Beser@3com.com

Ann Demirtjis
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
Phone: 425-705-2254
Email: annd@microsoft.com

Jerome Privat
BT Advanced Communications Technology Centre
Adastral Park, Martlesham Heath, IP5 3RE
UK
Phone: +44 1473 648910
Email: jerome.privat@bt.com

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

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. April 2000.