Internet Engineering Task Force Glenn Stump, IBM INTERNET DRAFT Ralph Droms, Bucknell University Date:
October 1999February 2000 Ye Gu, Ramesh Vyaghrapuri, Expires: AprilJuly 2000 Ann Demirtjis, Microsoft Burcak Beser, 3Com Jerome Privat, BT The User Class Option for DHCP <draft-ietf-dhc-userclass-04.txt><draft-ietf-dhc-userclass-05.txt> Status of this Memo The document is an Internet-Draft and is in full conformance with all of the provisions of Section 10 of RFC 2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Intenet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text objectopaque field 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.option should be configurable by a user. 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 typestype of clientusers 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. 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 . 3. DHCP Terminology o "DHCP client" A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server of "server"is an Internet host that returns configuration parameters to DHCP clients. o "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers. 4. User Class Informationoption This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that representsA DHCP server uses the user class of whichUser Class option to choose the client is a member.address pool it allocates an address from and/or to select any other configuration option. This option is a DHCP option [1, 2]. DHCP administrators may define specific user class identifiers to convey information about a client's software configuration or about its user's preferences.This option MAY carry multiple User Classes. The code for this option is TBD. The minimumEach User Class value is indicated in an opaque field and is preceded by a one-byte field giving its length. If i is the number of User Classes carried in the option, its total length for this optionN is two.equal to i + sum(Li). Code Len text1 +-----+-----+-----+-----+-----Len1 Len2 +-----+-----+-----+----------+-----+--------------+---- | TBD | N | c1L1 | c2class 1 | ... +-----+-----+-----+-----+----- 5. Server behaviour 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. In this section, we consider the simple case where the user can send a single User Class. Section 6 discusses potential multiple classes support.L2 | class 2 |... +-----+-----+-----+----------+-----+--------------+---- Servers not equipped to interpret the user class specified by 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 theDHCP server determines that the Client isclients implementing this option SHOULD allow users to be offered a new (or unbound) IP address, the following procedure MUST be adopted: If the client DHCP message does not contain aenter their User Class option, then theClass. 5. Security Considerations DHCP Server MUST attempt to choose an available address pool which has both the ALLOWED and DISALLOWED USER CLASSES empty. Ifcurrently provides no such address poolauthentication or security mechanisms. Potential exposures to attack are discussed 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, a DHCP server makes decisions about what address and what collection 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 DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed is section 7 ofsection 7 of the protocol specification . 9.6. References  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. 10.7. Acknowledgments This document attempts to mergecombines ideas from draft-ietf-dhc-userclass-03.txt (by GlenGlenn Stump and Ralph Droms) and draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and Burcak Beser). 11.It has been published as a revision to draft-ietf-dhc-userclass-03.txt. 8. Author Information Glenn Stump IBM Networking Software P.O. Box 12195 RTP, NC 27709 Phone: (919) 301-4277 Email: firstname.lastname@example.org Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 Email: email@example.com Ye Gu Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425 936 8601 Email: firstname.lastname@example.org Ramesh Vyaghrapuri Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425 703 9581 Email: email@example.com Burcak Beser 3Com Corporation 3800 Golf Road Rolling Meadows, IL Phone: 847 262 2195 Email: Burcak_Beser@3com.com Ann Demirtjis Microsoft Corporation One Microsoft Way Redmond WA 98052 Phone: 425-705-2254 Email: firstname.lastname@example.org Jerome Privat BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, IP5 3RE UK Phone: +44 1473 648910 Email: email@example.com 12.9. Expiration This document will expire on AprilJuly 2000.