draft-ietf-dhc-userclass-02.txt   draft-ietf-dhc-userclass-03.txt 
Network Working Group Glenn Stump, IBM Network Working Group Glenn Stump, IBM
INTERNET DRAFT Ralph Droms, Bucknell University INTERNET DRAFT Ralph Droms, Bucknell University
November 1997 Obsoletes: draft-ietf-dhc-userclass-02.txt November 1998
Expires May 1998 Expires May 1999
The User Class Option for DHCP The User Class Option for DHCP
<draft-ietf-dhc-userclass-02.txt> <draft-ietf-dhc-userclass-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
1. Abstract Abstract
This option is used by a DHCP client to optionally identify the type This option is used by a DHCP client to optionally identify the type
or category of user or applications it represents. The information or category of user or applications it represents. The information
contained in this option is an NVT ASCII text object that represents contained in this option is an NVT ASCII text object that represents
the user class of which the client is a member. the user class of which the client is a member.
2. Definitions 1. Requirements Terminology
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.
DRAFT The User Class Option for DHCP November 1997
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.
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
truly optional. One vendor may choose to include the item "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
because a particular marketplace requires it or because it document are to be interpreted as described in RFC 2119 [3].
enhances the product, for example; another vendor may omit the
same item.
This document also uses the following terms: 2. DHCP Terminology
o "DHCP client" o "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
DRAFT The User Class Option for DHCP November 1998
o "DHCP server" o "DHCP server"
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.
DRAFT The User Class Option for DHCP November 1997
3. User Class Information 3. User Class Information
This option is used by a DHCP client to optionally identify the type This option is used by a DHCP client to optionally identify the type
or category of user or applications it represents. The information or category of user or applications it represents. The information
contained in this option is an NVT ASCII text object that represents contained in this option is an NVT ASCII text object that represents
the user class of which the client is a member. 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 DHCP administrators may define specific user class identifiers to
convey information about a client's software configuration or about convey information about a client's software configuration or about
its user's preferences. For example, an identifier may specify that its user's preferences. For example, an identifier may specify that
a particular DHCP client is a member of the class "accounting a particular DHCP client is a member of the class "accounting
auditors", which have special service needs such as a particular auditors", which have special service needs such as a particular
database server. database server.
Servers not equipped to interpret the user class specified by a Servers not equipped to interpret the user class specified by a
client MUST ignore it (although it may be reported). Otherwise, client MUST ignore it (although it may be reported). Otherwise,
servers SHOULD respond with the set of options corresponding to the servers SHOULD respond with the set of options corresponding to the
user class specified by the client. Further, if the server responds user class specified by the client. Further, if the server responds
with the set of options corresponding to the given user class, it with the set of options corresponding to the given user class, it
MUST return this option (with the given user class value) to the MUST return this option (with the given user class value) to the
client. client.
Clients which do not receive information for the user class requested Clients which do not receive information for the user class requested
SHOULD make an attempt to operate without it, although they may do so SHOULD make an attempt to operate without it, although they may do so
(and may announce they are doing so) in a degraded mode. (and may announce they are doing so) in a degraded mode.
The code for this option is 77. The minimum length for this option The code for this option is TBD. The minimum length for this option
is two. is two.
Code Len text1 Code Len text1
+-----+-----+-----+-----+----- +-----+-----+-----+-----+-----
| 77 | N | c1 | c2 | ... | TBD | N | c1 | c2 | ...
+-----+-----+-----+-----+----- +-----+-----+-----+-----+-----
Implemention Note: Simulating Multiple User Classes DRAFT The User Class Option for DHCP November 1998
Although the user class option field only permits one NVT string, the DISCUSSION: Simulating Multiple User Classes
working group envisions that multiple classes can be simulated by
creating combination classes which map into a single class NVT 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 string. For example, suppose a site desires to create multiple
logical user classes, including: logical user classes, including:
"mobile" -- These hosts receive short lease times "mobile" -- These hosts receive short lease times
and are assumed to dynamically update and are assumed to dynamically update
their own DNS records their own DNS records
DRAFT The User Class Option for DHCP November 1997
"engineer" -- These hosts are assigned a high- "engineer" -- These hosts are assigned a high-
performance NFS file server performance NFS file server
For the above two classes, then, a combination class could look For the above two classes, then, a combination class could look
something like: something like:
"mobeng" -- hosts of this mobile-engineer combination "mobeng" -- hosts of this mobile-engineer combination
class get assigned a high-performance class get assigned a high-performance
file server and a short lease time, and file server and a short lease time, and
a DNS proxy A record update is not attempted a DNS proxy A record update is not attempted
on their behalf. on their behalf.
Thus, by mapping combinations of classes into single class names, you Thus, by mapping combinations of classes into single class names,
can effectively implement multiple user classing at a site using only you can effectively implement multiple user classing at a site
the single NVT string field. using only the single NVT string field.
Implementation Note: Serving Competing Option Values DISCUSSION: Serving Competing Option Values
When servicing a request from a client of a particular user class, a When servicing a request from a client of a particular user class,
DHCP server makes decisions about what collection of options to a DHCP server makes decisions about what collection of options to
include in its response. These decisions are expected to consider include in its response. These decisions are expected to consider
options and values designated for the client host by virtue of its options and values designated for the client host by virtue of its
subnet/location, vendor class, user class, or client id. subnet/location, vendor class, user class, or client id.
In cases where multiple option values are possible for return to the In cases where multiple option values are possible for return to
client due to multiple, overlapping "affiliations", DHCP server the client due to multiple, overlapping "affiliations", DHCP
policy may dictate which values take precedence over others. A DHCP server policy may dictate which values take precedence over
server implementation SHOULD provide flexibility in specifying DHCP others. A DHCP server implementation SHOULD provide flexibility
option precedence policy so that DHCP administrators can customize a in specifying DHCP option precedence policy so that DHCP
DHCP system to best suit their network environments. administrators can customize a DHCP system to best suit their
network environments.
If flexibility in a server's option precedence policy is not DRAFT The User Class Option for DHCP November 1998
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.
DRAFT The User Class Option for DHCP November 1997 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.
Security Considerations 4. Security Considerations
DHCP currently provides no authentication or security mechanisms. DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed is section 7 of the Potential exposures to attack are discussed is section 7 of the
protocol specification [1]. protocol specification [1].
References 5. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
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.
Acknowledgments [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997.
Author Information DRAFT The User Class Option for DHCP November 1998
6. Author Information
Glenn Stump Glenn Stump
IBM Networking Software Solutions IBM Networking Software
4205 South Miami Blvd. P.O. Box 12195
RTP, NC 27709 RTP, NC 27709
Phone: (919) 254-5616 Phone: (919) 301-4277
email: glennstump@vnet.ibm.com email: stumpga@us.ibm.com
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
email: droms@bucknell.edu 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
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.
 End of changes. 

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