draft-ietf-dhc-userclass-04.txt   draft-ietf-dhc-userclass-05.txt 
Internet Engineering Task Force Glenn Stump, IBM Internet Engineering Task Force Glenn Stump, IBM
INTERNET DRAFT Ralph Droms, Bucknell University INTERNET DRAFT Ralph Droms, Bucknell University
Date: October 1999 Ye Gu, Ramesh Vyaghrapuri, Date: February 2000 Ye Gu, Ramesh Vyaghrapuri,
Expires: April 2000 Ann Demirtjis, Microsoft Expires: July 2000 Ann Demirtjis, Microsoft
Burcak Beser, 3Com Burcak Beser, 3Com
Jerome Privat, BT Jerome Privat, BT
The User Class Option for DHCP The User Class Option for DHCP
<draft-ietf-dhc-userclass-04.txt> <draft-ietf-dhc-userclass-05.txt>
Status of this Memo Status of this Memo
The document is an Internet-Draft and is in full conformance with all The document is an Internet-Draft and is in full conformance with all
of the provisions of Section 10 of RFC 2026. of the provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 36 skipping to change at line 36
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This option is used by a DHCP client to optionally identify the This option is used by a DHCP client to optionally identify the
type or category of user or applications it represents. The type or category of user or applications it represents. The
information contained in this option is an NVT ASCII text object information contained in this option is an opaque field
that represents the user class of which the client is a member. that represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate pool to assign an address to the client and the appropriate
configuration parameters. configuration parameters.
This document attempts to merge draft-ietf-dhc-userclass-03.txt This option should be configurable by a user.
and draft-ietf-dhc-useraddr-00.txt.
1. Introduction 1. Introduction
It is often desirable to provide different levels of service It is often desirable to provide different levels of service
to different users of an IP network. to different users of an IP network.
In order for an IP network to implement this service In order for an IP network to implement this service
differentiation, it needs a way to classify users. A simple differentiation, it needs a way to classify users. A simple
solution to this is to use source IP addresses for classification. solution to this is to use source IP addresses for classification.
Under this scheme, network administrators first configure network Under this scheme, network administrators first configure network
devices such as routers to recognize traffic from a particular devices such as routers to recognize traffic from a particular
skipping to change at line 64 skipping to change at line 63
meet the desired level of service. Next, they assign the IP meet the desired level of service. Next, they assign the IP
addresses to the hosts of the intended users so that the user will addresses to the hosts of the intended users so that the user will
receive the appropriate level of service. They can configure the receive the appropriate level of service. They can configure the
hosts manually with these addresses. However, they cannot use DHCP hosts manually with these addresses. However, they cannot use DHCP
for address assignment, even if they are already running a DHCP for address assignment, even if they are already running a DHCP
server in their network. A current RFC-compliant DHCP server assigns server in their network. A current RFC-compliant DHCP server assigns
IP addresses based on the location of the DHCP Client in the network IP addresses based on the location of the DHCP Client in the network
topology, not the type of user it supports. topology, not the type of user it supports.
This document describes a simple extension of the DHCP protocol This document describes a simple extension of the DHCP protocol
that enables a DHCP server to assign IP addresses from different that enables a DHCP server to assign IP addresses from different
address pools depending on the types of client from which it receives address pools depending on the type of users from which it receives
DHCP requests. With this new extension, network administrators will DHCP requests. With this new extension, network administrators will
be able to use DHCP to hand out the appropriate addresses to clients. be able to use DHCP to hand out the appropriate addresses to clients.
An example intended usage is a corporate network subnet consisting An example intended usage is a corporate network subnet consisting
of different departments of users, such as Accounting, Legal, Staff, of different departments of users, such as Accounting, Legal, Staff,
etc. It may be desirable to allocate logical address pools to each etc. It may be desirable to allocate logical address pools to each
of the departments so that network policies may be implemented easily of the departments so that network policies may be implemented easily
on IP address ranges; and this would facilitate providing differential on IP address ranges; and this would facilitate providing
services, such as network reachibility. differential services, such as network reachibility.
A DHCP server can also use the information contained in the User Class A DHCP server can also use the information contained in the User
to allocate other configuration parameters than the IP address. For Class to allocate other configuration parameters than the IP
example, a DHCP server receiving a request from a client with the User address. For example, a DHCP server receiving a request from a
Class set to "accounting auditors" may return an option with the client with the User Class set to "accounting auditors" may return
address of a particular database server. an option with the address of a particular database server.
Indeed a DHCP server may have a single pool of addresses and only use Indeed a DHCP server may have a single pool of addresses and
the user class to select parameters other than IP addresses. only use the user class to select parameters other than IP
addresses.
Note:
This document combines ideas from draft-ietf-dhc-userclass-03.txt
and draft-ietf-dhc-useraddr-00.txt. It has been published as a
revision to draft-ietf-dhc-userclass-03.txt.
2. Requirements Terminology 2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
3. DHCP Terminology 3. DHCP Terminology
o "DHCP client" o "DHCP client"
skipping to change at line 105 skipping to change at line 110
A DHCP server of "server"is an Internet host that returns A DHCP server of "server"is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
o "binding" o "binding"
A binding is a collection of configuration parameters, including A binding is a collection of configuration parameters, including
at least an IP address, associated with or "bound to" a DHCP at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers. client. Bindings are managed by DHCP servers.
4. User Class Information 4. User Class option
This option is used by a DHCP client to optionally identify the This option is used by a DHCP client to optionally identify the
type or category of user or applications it represents. type or category of user or applications it represents.
The information contained in this option is an NVT ASCII text A DHCP server uses the User Class option to choose the address
object that represents the user class of which the client is a pool it allocates an address from and/or to select any other
member. configuration option.
This option is a DHCP option [1, 2]. This option is a DHCP option [1, 2].
DHCP administrators may define specific user class identifiers to This option MAY carry multiple User Classes.
convey information about a client's software configuration or about
its user's preferences.
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 The code for this option is TBD.
set of ALLOWED USER CLASSES, specifying the category of clients Each User Class value is indicated in an opaque field and is
that can be offered addresses from the address pool; and with a preceded by a one-byte field giving its length.
set of DISALLOWED USER CLASSES, specifying the category of If i is the number of User Classes carried in the option,
clients that must NOT be offered addresses from the address pool. its total length N is equal to i + sum(Li).
In this section, we consider the simple case where the user can Code Len Len1 Len2
send a single User Class. Section 6 discusses potential multiple +-----+-----+-----+----------+-----+--------------+----
classes support. | TBD | N | L1 | class 1 | L2 | class 2 |...
+-----+-----+-----+----------+-----+--------------+----
Servers not equipped to interpret the user class specified by Servers not equipped to interpret the user class specified by
a client MUST ignore it (although it may be reported). a client MUST ignore it (although it may be reported).
Otherwise, whenever any DHCP client message is seen by the DHCP
server, it MUST do the regular processing 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 a User Class
option, 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 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 option present in the DHCP message. It SHOULD also check that
the User Class option present in the DHCP message is NOT present
in the DISALLOWED USER CLASS set [this is to cope with possible
misconfigurations in which an administrator will have by mistake put
a User Class in both the ALLOWED and the DISALLOWED sets].
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 the User Class options present in
the DHCP message is NOT present in the DISALLOWED USER CLASS set.
If the server responds with all the parameters corresponding to
the given user class, it MUST return this option (with the given
user class value) to the client.
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.
DISCUSSION: Serving Competing Option Values
When servicing a request from a client of a particular user class, DHCP clients implementing this option SHOULD allow users to enter
a DHCP server makes decisions about what address and what collection their User Class.
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.
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.
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 client receives a response from a DHCP Server with the same User
Class option value as it puts in its request, then it knows that the
server responded with parameters corresponding to the given user
class.
Clients which do not receive all the configuration for the user class
requested but which received an IP address SHOULD 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 User Class
requested MUST announce it.
8. Security Considerations 5. Security Considerations
DHCP currently provides no authentication or security DHCP currently provides no authentication or security
mechanisms. Potential exposures to attack are discussed mechanisms. Potential exposures to attack are discussed
is section 7 of the protocol specification [1]. is section 7 of the protocol specification [1].
9. References 6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997. Levels," RFC 2119, March 1997.
10. Acknowledgments 7. Acknowledgments
This document attempts to merge draft-ietf-dhc-userclass-03.txt This document combines ideas from draft-ietf-dhc-userclass-03.txt
(by Glen Stump and Ralph Droms) and (by Glenn Stump and Ralph Droms) and
draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and
Burcak Beser). Burcak Beser). It has been published as a revision to
draft-ietf-dhc-userclass-03.txt.
11. Author Information 8. Author Information
Glenn Stump Glenn Stump
IBM Networking Software IBM Networking Software
P.O. Box 12195 P.O. Box 12195
RTP, NC 27709 RTP, NC 27709
Phone: (919) 301-4277 Phone: (919) 301-4277
Email: stumpga@us.ibm.com Email: stumpga@us.ibm.com
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
skipping to change at line 316 skipping to change at line 216
Phone: 425-705-2254 Phone: 425-705-2254
Email: annd@microsoft.com Email: annd@microsoft.com
Jerome Privat Jerome Privat
BT Advanced Communications Technology Centre BT Advanced Communications Technology Centre
Adastral Park, Martlesham Heath, IP5 3RE Adastral Park, Martlesham Heath, IP5 3RE
UK UK
Phone: +44 1473 648910 Phone: +44 1473 648910
Email: jerome.privat@bt.com Email: jerome.privat@bt.com
12. Expiration 9. Expiration
This document will expire on April 2000. This document will expire on July 2000.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/