Network Working Group                                 Ye Gu, Microsoft
INTERNET DRAFT                           Ramesh Vyaghrapuri, Microsoft
                                                    Burcak Beser, 3Com
                                                          October 1998
                                                    Expires April 1999



       DHCP Use of the User Class Option for Address Assignment
                  <draft-ietf-dhc-useraddr-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.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or
"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.ietf.org, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.

Abstract

This document proposes a mechanism that DHCP clients can use optionally
to obtain their IP addresses from different address pools configured on
a DHCP server.  A DHCP client can specify a class to which it belongs.
Based on the class, a DHCP server selects the appropriate address pool
to assign an address to the client.

. Introduction

With the popularity and importance of the Internet growing, many
organizations and public carriers are deploying IP-based networks.  An
IP network is a heterogeneous environment that supports various kinds
of devices, users and applications (which are referred to generically
as "users" in the rest of this document).  Often IP network
administrators are faced with the need to provide different levels of
service quality or access privilege to different users.

In order for an IP network to implement differentiated services, it
needs a way to classify users.  A simple solution to this is to use
source IP addresses for classification.

Under this scheme, network administrators first configure network


Gu, Vyaghrapuri, Beser                                        [Page 1]

 
Internet Draft    User Class Option for Address Assignment    Nov 1998


devices such as routers to recognize traffic from a particular source
IP address (or address range) and handle it specially to meet the
desired level of service.  Next, they assign the IP address(es) to the
host(s) of the intended user(s) so that the user(s) will receive the
appropriate level(s) of service.  They can configure the hosts manually
with these addresses.  However, they cannot use DHCP [1] for address
assignment, even if they are already running a DHCP 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 receive DHCP
requests.  With this new extension, network administrators will be able
to use DHCP to hand out the appropriate addresses to users (assuming
that the user type maps to the client type).

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

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

      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.




Gu, Vyaghrapuri, Beser                                        [Page 2]

 
Internet Draft    User Class Option for Address Assignment    Nov 1998



      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.

. Schema Overview

The user class option [3] is used by a DHCP client to inform DHCP
servers about the category of system, user or application it
represents.

In the following section, it is assumed that the DHCP Client MAY send
multiple User Class options in the same message.  (They may or may not
occur consequetively).

Each address pool on the DHCP Server MAY be configured with a set of
ALLOWED USER CLASSES, specifying the category of clients accepted by
the DHCP Server; and with a set of DISALLOWED USER CLASSES, specifying
the category of clients that must NOT be offered addresses from the
address pool.

. Address Assignment

Whenever any DHCP client message is seen by the DHCP Server, it MUST do
the regular processing [1] and if the DHCP Server determines that the
Client is to be offered a new (or unbound)IP address, the following
procedure MUST be adopted:

If the client DHCP message does not contain any User Class options,
then the 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 so, it MUST attempt chose any available
address pool.

If the client DHCP Message contains any User Class options, then the
DHCP Server MUST attempt to choose an available address pool for which
the ALLOWED USER CLASSES set contains one of the user class options


Gu, Vyaghrapuri, Beser                                        [Page 3]

 
Internet Draft    User Class Option for Address Assignment    Nov 1998


present in the DHCP message; and for which none of the User Class
options present in the DHCP message are also present in the DISALLOWED
USER CLASSES set.  If no such address pool is available, and if the
DHCP Server has been specifically configured to do so, it MUST attempt
to choose any address pool for which none of the User Class options
present in the DHCP message are also present in the DISALLOWED USER
CLASSES set.

If the DHCP Server is unable to find a suitable address pool, it MUST
NOT offer an IP address to the Client.  It MAY indicate the condition
to the administrator.

. Address Renewal

At renewal time, before the DHCP Server sends an DHCP ACK as per [1],
it MUST check to see if the address pool of the Client's IP address has
any of the User Class option values in the DHCP message of the Client
present in the DISALLOWED USER CLASSES set; or, if the ALLOWED USER
CLASSES set has none of the User Class option values in the DHCP
message, and the DHCP Server is NOT specifically configured to allow a
client whose user class options do not belong to either of the two sets
of USER CLASSES.   If either of the two checks above succeed, the DHCP
Server MUST send a DHCP NACK message to the client and remove the
binding information.   The DHCP Server MAY send an indication via the
MESSAGE option.

. Security Considerations

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

. Acknowledgements

The authors would like to thank Munil Shah and Peter Ford for reviewing
this draft.

. References

[] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[2] Alexander, S., and Droms R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[3] Stump, G., and Droms R., "The User Class Option for DHCP", Internet
Draft, November 1997.







Gu, Vyaghrapuri, Beser                                        [Page 4]

 
Internet Draft    User Class Option for Address Assignment    Nov 1998


. Author's Address

   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

   This document will expire in April 1999.

























Gu, Vyaghrapuri, Beser                                        [Page 5]