[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. Security Considerations
DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed is section 7 of the
protocol specification [1].
7. Acknowledgements
The authors would like to thank Munil Shah and Peter Ford for reviewing
this draft.
8. References
[1] 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
9. 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]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/