draft-ietf-dhc-userclass-01.txt   draft-ietf-dhc-userclass-02.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
March 1997 November 1997
Expires September 1997 Expires May 1998
The User Class Option for DHCP The User Class Option for DHCP
<draft-ietf-dhc-userclass-01.txt> <draft-ietf-dhc-userclass-02.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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Throughout this document, the words that are used to define the Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words significance of particular requirements are capitalized. These words
are: are:
o "MUST" o "MUST"
This word or the adjective "REQUIRED" means that the This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification. item is an absolute requirement of this specification.
DRAFT The User Class Option for DHCP March 1997 DRAFT The User Class Option for DHCP November 1997
o "MUST NOT" o "MUST NOT"
This phrase means that the item is an absolute prohibition This phrase means that the item is an absolute prohibition
of this specification. of this specification.
o "SHOULD" o "SHOULD"
This word or the adjective "RECOMMENDED" means that there This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore may exist valid reasons in particular circumstances to ignore
skipping to change at page 3, line 5 skipping to change at page 3, line 5
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 March 1997 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.
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
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Although the user class option field only permits one NVT string, the Although the user class option field only permits one NVT string, the
working group envisions that multiple classes can be simulated by working group envisions that multiple classes can be simulated by
creating combination classes which map into a single class NVT 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 March 1997 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
If flexibility in a server's option precedence policy is not If flexibility in a server's option precedence policy is not
implemented by a vendor (or is perhaps implemented but not exercised implemented by a vendor (or is perhaps implemented but not exercised
by an administrator), a recommended default policy is that option by an administrator), a recommended default policy is that option
values of specific affiliations override those of less specific. values of specific affiliations override those of less specific.
That is, an option value designated for a specific client -- That is, an option value designated for a specific client --
sometimes known as a "reserved binding" -- SHOULD override option sometimes known as a "reserved binding" -- SHOULD override option
values designated for the client's user or vendor class, which SHOULD values designated for the client's user or vendor class, which SHOULD
override option values designated for the client's vendor class, override option values designated for the client's vendor class,
which SHOULD override option values for the client's subnet. which SHOULD override option values for the client's subnet.
DRAFT The User Class Option for DHCP March 1997 DRAFT The User Class Option for DHCP November 1997
Security Considerations Security Considerations
Security issues are not discussed in this document. DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed is section 7 of the
protocol specification [1].
References References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March
October 1993 1997
[2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997
Acknowledgments Acknowledgments
Author Information Author Information
Glenn Stump Glenn Stump
IBM Networking Software Solutions IBM Networking Software Solutions
4205 South Miami Blvd. 4205 South Miami Blvd.
RTP, NC 27709 RTP, NC 27709
Phone: (919) 254-5616 Phone: (919) 254-5616
 End of changes. 

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