The User Class Option for DHCP
RFC 3004

Network Working Group G. Stump
Request for Comments: 3004 IBM
Category: Standards Track R. Droms
 Cisco Systems
 Y. Gu
 R. Vyaghrapuri
 A. Demirtjis
 Microsoft
 B. Beser
 Pacific Broadband Communications
 J. Privat
 Northstream AB
 November 2000
 The User Class Option for DHCP
Status of this Memo
 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements. Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
 Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
 This option is used by a Dynamic Host Configuration Protocol (DHCP)
 client to optionally identify the type or category of user or
 applications it represents. The information contained in this option
 is an opaque 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 option should be
 configurable by a user.
1. Introduction
 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, the User Class option can be
 used to configure all clients of people in the accounting department
 with a different printer than clients of people in the marketing
 department.
Stump, et al. Standards Track [Page 1]
RFC 3004 The User Class Option for DHCP November 2000
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].
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 or "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 option
 This option is used by a DHCP client to optionally identify the type
 or category of user or applications it represents. A DHCP server
 uses the User Class option to choose the address pool it allocates an
 address from and/or to select any other configuration option.
 This option is a DHCP option [1, 2].
 This option MAY carry multiple User Classes. Servers may interpret
 the meanings of multiple class specifications in an implementation
 dependent or configuration dependent manner, and so the use of
 multiple classes by a DHCP client should be based on the specific
 server implementation and configuration which will be used to process
 that User class option.
 The format of this option is as follows:
 Code Len Value
 +-----+-----+--------------------- . . . --+
 | 77 | N | User Class Data ('Len' octets) |
 +-----+-----+--------------------- . . . --+
 where Value consists of one or more instances of User Class Data.
 Each instance of User Class Data is formatted as follows:
Stump, et al. Standards Track [Page 2]
RFC 3004 The User Class Option for DHCP November 2000
 UC_Len_i User_Class_Data_i
 +--------+------------------------ . . . --+
 | L_i | Opaque-Data ('UC_Len_i' octets) |
 +--------+------------------------ . . . --+
 Each User Class value (User_Class_Data_i) is indicated as an opaque
 field. The value in UC_Len_i does not include the length field
 itself and MUST be non-zero. Let m be the number of User Classes
 carried in the option. The length of the option as specified in Len
 must be the sum of the lengths of each of the class names plus m:
 Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m. If any instances of
 User Class Data are present, the minimum value of Len is two (Len =
 UC_Len_1 +たす 1 =わ 1 +たす 1 =わ 2).
 The Code for this option is 77.
 A server that is not equipped to interpret any given user class
 specified by a client MUST ignore it (although it may be reported).
 If a server recognizes one or more user classes specified by the
 client, but does not recognize one or more other user classes
 specified by the client, the server MAY use the user classes it
 recognizes.
 DHCP clients implementing this option SHOULD allow users to enter one
 or more user class values.
5. IANA Considerations
 Option 77, which IANA has already assigned for this purpose, should
 be used as the User Class Option for DHCP.
6. Security Considerations
 DHCP currently provides no authentication or security mechanisms.
 Potential exposures to attack are discussed is section 7 of the
 protocol specification [1].
 This lack of authentication mechanism means that a DHCP server cannot
 check if a client or user is authorized to use a given User Class.
 This introduces an obvious vulnerability when using the User Class
 option. For example, if the User Class is used to give out a special
 parameter (e.g., a particular database server), there is no way to
 authenticate a client and it is therefore impossible to check if a
 client is authorized to use this parameter.
Stump, et al. Standards Track [Page 3]
RFC 3004 The User Class Option for DHCP November 2000
7. References
 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
 1997.
 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
 Extensions", RFC 2132, March 1997.
 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
 Levels", BCP 14, RFC 2119, March 1997.
8. Acknowledgments
 This document is based on earlier drafts by Glenn Stump, Ralph Droms,
 Ye Gu, Ramesh Vyaghrapuri and Burcak Beser. Thanks to Ted Lemon,
 Steve Gonczi, Kim Kinnear, Bernie Volz, Richard Jones, Barr Hibbs and
 Thomas Narten for their comments and suggestions.
9. Authors' Addresses
 Glenn Stump
 IBM Networking Software
 P.O. Box 12195
 RTP, NC 27709
 Phone: 919 301 4277
 EMail: stumpga@us.ibm.com
 Ralph Droms
 Cisco Systems
 300 Apollo Drive
 Chelmsford, MA 01824
 Phone: 978 244 4733
 EMail: rdroms@cisco.com
 Ye Gu
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 Phone: 425 936 8601
 EMail: yegu@microsoft.com
Stump, et al. Standards Track [Page 4]
RFC 3004 The User Class Option for DHCP November 2000
 Ramesh Vyaghrapuri
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 Phone: 425 703 9581
 EMail: rameshv@microsoft.com
 Burcak Beser
 Pacific Broadband Communications
 3103 North 1st Street
 San Jose, CA 95134
 Phone: 408 468 6265
 Email: Burcak@pacband.com
 Ann Demirtjis
 Microsoft Corporation
 One Microsoft Way
 Redmond WA 98052
 Phone: 425 705 2254
 EMail: annd@microsoft.com
 Jerome Privat
 Northstream AB
 Espace Beethoven 1
 1200 Route des Lucioles
 BP 302
 06906 Sophia Antipolis Cedex
 France
 Phone: +33 4 97 23 40 45
 Fax: +33 4 97 23 24 51
 Mobile: +33 6 13 81 76 71
 Email: jerome.privat@northstream.se
Stump, et al. Standards Track [Page 5]
RFC 3004 The User Class Option for DHCP November 2000
Full Copyright Statement
 Copyright (C) The Internet Society (2000). 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
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
 Funding for the RFC Editor function is currently provided by the
 Internet Society.
Stump, et al. Standards Track [Page 6]