Network Working Group Glenn Stump, IBM INTERNET DRAFT Ralph Droms, Bucknell University Obsoletes: draft-ietf-dhc-userclass-02.txt November
19971998 Expires May 19981999 The User Class Option for DHCP <draft-ietf-dhc-userclass-02.txt><draft-ietf-dhc-userclass-03.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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learnview the current statusentire list of any Internet-Draft,current Internet-Drafts, please check the ``1id-abstracts.txt''"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ds.internic.netftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1.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 object that represents the user class of which the client is a member. 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. DRAFT1. Requirements Terminology The User Class Option for DHCP November 1997 okey words "MUST", "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. oNOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "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. oNOT", "RECOMMENDED", "MAY" This word or the adjectiveand "OPTIONAL" means thatin 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. Thisdocument also uses the following terms:are to be interpreted as described in RFC 2119 . 2. 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. DRAFT The User Class Option for DHCP November 1998 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. DRAFT The User Class Option for DHCP November 19973. User Class Information 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 represents 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 convey information about a client's software configuration or about its user's preferences. For example, an identifier may specify that 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 77.TBD. The minimum length for this option is two. Code Len text1 +-----+-----+-----+-----+----- | 77TBD | N | c1 | c2 | ... +-----+-----+-----+-----+----- Implemention Note:DRAFT The User Class Option for DHCP November 1998 DISCUSSION: Simulating Multiple User Classes 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 logical user classes, including: "mobile" -- These hosts receive short lease times and are assumed to dynamically update their own DNS records DRAFT The User Class Option for DHCP November 1997"engineer" -- These hosts are assigned a high- performance NFS file server For the above two classes, then, a combination class could look something like: "mobeng" -- hosts of this mobile-engineer combination class get assigned a high-performance file server and a short lease time, and a DNS proxy A record update is not attempted on their behalf. Thus, by mapping combinations of classes into single class names, you can effectively implement multiple user classing at a site using only the single NVT string field. Implementation Note:DISCUSSION: Serving Competing Option Values When servicing a request from a client of a particular user class, a DHCP server makes decisions about what collection of options to include in its response. These decisions are expected to consider 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 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 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. DRAFT The User Class Option for DHCP November 19974. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed is section 7 of the protocol specification . 5. References  Droms, R., "Dynamic Host Configuration Protocol", RFC2131,RFC 2131, March 19971997.  S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997 Acknowledgments1997.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. DRAFT The User Class Option for DHCP November 1998 6. Author Information Glenn Stump IBM Networking Software Solutions 4205 South Miami Blvd.P.O. Box 12195 RTP, NC 27709 Phone: (919) 254-5616301-4277 email: firstname.lastname@example.org@us.ibm.com Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 email: email@example.com 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.