draft-ietf-dhc-userclass-03.txt		draft-ietf-dhc-userclass-04.txt
			Internet Engineering Task Force Glenn Stump, IBM
	Network Working Group Glenn Stump, IBM
	INTERNET DRAFT Ralph Droms, Bucknell University		INTERNET DRAFT Ralph Droms, Bucknell University
	Obsoletes: draft-ietf-dhc-userclass-02.txt November 1998		Date: October 1999 Ye Gu, Ramesh Vyaghrapuri,
	Expires May 1999		Expires: April 2000 Ann Demirtjis, Microsoft
			Burcak Beser, 3Com
			Jerome Privat, BT
	The User Class Option for DHCP		The User Class Option for DHCP
	<draft-ietf-dhc-userclass-03.txt>		<draft-ietf-dhc-userclass-04.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		The document is an Internet-Draft and is in full conformance with all
	documents of the Internet Engineering Task Force (IETF), its areas,		of the provisions of Section 10 of RFC 2026.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		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 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 Intenet-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 view the entire list of current Internet-Drafts, please check the		The list of current Internet-Drafts can be accessed at
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		http://www.ietf.org/ietf/1id-abstracts.txt.
	Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific		The list of Internet-Draft Shadow Directories can be accessed at
	Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).		http://www.ietf.org/shadow.html.
	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
	or category of user or applications it represents. The information		type or category of user or applications it represents. The
	contained in this option is an NVT ASCII text object that represents		information contained in this option is an NVT ASCII text object
	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
			pool to assign an address to the client and the appropriate
			configuration parameters.
			This document attempts to merge draft-ietf-dhc-userclass-03.txt
			and draft-ietf-dhc-useraddr-00.txt.
	1. Requirements Terminology		1. Introduction
			It is often desirable to provide different levels of service
			to different users of an IP network.
			In order for an IP network to implement this service
			differentiation, 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
			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
			addresses to the hosts of the intended users so that the user will
			receive the appropriate level of service. They can configure the
			hosts manually with these addresses. However, they cannot use DHCP
			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 receives
			DHCP requests. With this new extension, network administrators will
			be able to use DHCP to hand out the appropriate addresses to clients.
			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 reachibility.
			A DHCP server can also use the information contained in the User Class
			to allocate other configuration parameters than the IP address. For
			example, a DHCP server receiving a request from a client with the User
			Class set to "accounting auditors" may return an option with the
			address of a particular database server.
			Indeed a DHCP server may have a single pool of addresses and only use
			the user class to select parameters other than IP addresses.
			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].
	2. DHCP Terminology		3. 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.
	3. User Class Information		4. 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
	or category of user or applications it represents. The information		type or category of user or applications it represents.
	contained in this option is an NVT ASCII text object that represents		The information contained in this option is an NVT ASCII text
	the user class of which the client is a member.		object that represents the user class of which the client is a
			member.
	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		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.
	a particular DHCP client is a member of the class "accounting
	auditors", which have special service needs such as a particular
	database server.
	Servers not equipped to interpret the user class specified by a
	client MUST ignore it (although it may be reported). Otherwise,
	servers SHOULD respond with the set of options corresponding to the
	user class specified by the client. Further, if the server responds
	with the set of options corresponding to the given user class, it
	MUST return this option (with the given user class value) to the
	client.
	Clients which do not receive information for the user class requested
	SHOULD make an attempt to operate without it, although they may do so
	(and may announce they are doing so) in a degraded mode.
	The code for this option is TBD. The minimum length for this option		The code for this option is TBD. The minimum length for this
	is two.		option is two.
	Code Len text1		Code Len text1
	+-----+-----+-----+-----+-----		+-----+-----+-----+-----+-----
	| TBD | N | c1 | c2 | ...		| TBD | N | c1 | c2 | ...
	+-----+-----+-----+-----+-----		+-----+-----+-----+-----+-----
	DRAFT The User Class Option for DHCP November 1998		5. Server behaviour
	DISCUSSION: Simulating Multiple User Classes		Each address pool on the DHCP Server MAY be configured with a
			set of ALLOWED USER CLASSES, specifying the category of clients
			that can be offered addresses from the address pool; and with a
			set of DISALLOWED USER CLASSES, specifying the category of
			clients that must NOT be offered addresses from the address pool.
	Although the user class option field only permits one NVT string,		In this section, we consider the simple case where the user can
	the working group envisions that multiple classes can be simulated		send a single User Class. Section 6 discusses potential multiple
	by creating combination classes which map into a single class NVT		classes support.
	string. For example, suppose a site desires to create multiple
	logical user classes, including:
	"mobile" -- These hosts receive short lease times		Servers not equipped to interpret the user class specified by
	and are assumed to dynamically update		a client MUST ignore it (although it may be reported).
	their own DNS records		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:
	"engineer" -- These hosts are assigned a high-		If the client DHCP message does not contain a User Class
	performance NFS file server		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.
	For the above two classes, then, a combination class could look		If the Client DHCP message contains a User Class option, then
	something like:		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.
	"mobeng" -- hosts of this mobile-engineer combination		If the server responds with all the parameters corresponding to
	class get assigned a high-performance		the given user class, it MUST return this option (with the given
	file server and a short lease time, and		user class value) to the client.
	a DNS proxy A record update is not attempted
	on their behalf.
	Thus, by mapping combinations of classes into single class names,		If the DHCP server is unable to find a suitable address pool, it
	you can effectively implement multiple user classing at a site		MUST NOT offer an IP address to the Client. It MAY indicate the
	using only the single NVT string field.		condition to the administrator.
	DISCUSSION: Serving Competing Option Values		DISCUSSION: Serving Competing Option Values
	When servicing a request from a client of a particular user class,		When servicing a request from a client of a particular user class,
	a DHCP server makes decisions about what collection of options to		a DHCP server makes decisions about what address and what collection
	include in its response. These decisions are expected to consider		of options to include in its response. These decisions are expected
	options and values designated for the client host by virtue of its		to consider addresses, options and values designated for the client
	subnet/location, vendor class, user class, or client id.		host by virtue of its subnet/location, vendor class, user class, or
			client id.
	In cases where multiple 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.
	DRAFT The User Class Option for DHCP November 1998		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		If flexibility in a server's option precedence policy is not
	implemented by a vendor (or is perhaps implemented but not		implemented by a vendor (or is perhaps implemented but not exercised
	exercised by an administrator), a recommended default policy is		by an administrator), a recommended default policy is that option
	that option values of specific affiliations override those of less		values of specific affiliations override those of less specific.
	specific. That is, an option value designated for a specific		That is, an option value designated for a specific client --
	client -- sometimes known as a "reserved binding" -- SHOULD		sometimes known as a "reserved binding" -- SHOULD override option
	override option values designated for the client's user or vendor		values designated for the client's user or vendor class, which
	class, which SHOULD override option values designated for the		SHOULD override option values designated for the client's vendor
	client's vendor class, which SHOULD override option values for the		class, which SHOULD override option values for the client's subnet.
	client's subnet.
	4. Security Considerations		6. Multiple User Classes
	DHCP currently provides no authentication or security mechanisms.		This section intends to raise some of the issues associated with
	Potential exposures to attack are discussed is section 7 of the		supporting multiple user classes. Feedback from the Working Group
	protocol specification [1].		is welcome.
	5. References		- 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
			DHCP currently provides no authentication or security
			mechanisms. Potential exposures to attack are discussed
			is section 7 of the protocol specification [1].
			9. 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.
	DRAFT The User Class Option for DHCP November 1998		10. Acknowledgments
	6. Author Information		This document attempts to merge draft-ietf-dhc-userclass-03.txt
			(by Glen Stump and Ralph Droms) and
			draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and
			Burcak Beser).
			11. 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
	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		Ye Gu
			Microsoft Corporation
			One Microsoft Way
			Redmond, WA 98052
			Phone: 425 936 8601
			Email: yegu@microsoft.com
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Ramesh Vyaghrapuri
			Microsoft Corporation
			One Microsoft Way
			Redmond, WA 98052
			Phone: 425 703 9581
			Email: rameshv@microsoft.com
	This document and translations of it may be copied and furnished to		Burcak Beser
	others, and derivative works that comment on or otherwise explain it		3Com Corporation
	or assist in its implementation may be prepared, copied, published		3800 Golf Road
	and distributed, in whole or in part, without restriction of any		Rolling Meadows, IL
	kind, provided that the above copyright notice and this paragraph are		Phone: 847 262 2195
	included on all such copies and derivative works. However, this		Email: Burcak_Beser@3com.com
	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		Ann Demirtjis
	revoked by the Internet Society or its successors or assigns.		Microsoft Corporation
			One Microsoft Way
			Redmond WA 98052
			Phone: 425-705-2254
			Email: annd@microsoft.com
	This document and the information contained herein is provided on an		Jerome Privat
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		BT Advanced Communications Technology Centre
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		Adastral Park, Martlesham Heath, IP5 3RE
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		UK
			Phone: +44 1473 648910
			Email: jerome.privat@bt.com
	DRAFT The User Class Option for DHCP November 1998		12. Expiration
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		This document will expire on April 2000.
	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/