summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3004.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3004.txt')
-rw-r--r--doc/rfc/rfc3004.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3004.txt b/doc/rfc/rfc3004.txt
new file mode 100644
index 0000000..1c941aa
--- /dev/null
+++ b/doc/rfc/rfc3004.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+