idnits 2.17.1 draft-ietf-dhc-userclass-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2000) is 8617 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Stump 2 Dynamic Host Configuration Working Group IBM 3 Internet Draft R. Droms 4 Expires: January 2001 Bucknell University 5 draft-ietf-dhc-userclass-10.txt Y. Gu 6 R. Vyaghrapuri 7 A. Demirtjis 8 Microsoft 9 B. Beser 10 3Com 11 J. Privat 12 BT 13 August 2000 15 The User Class Option for DHCP 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- Drafts 29 as reference material or to cite them other than as "work in 30 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This option is used by a DHCP client to optionally identify the type 39 or category of user or applications it represents. 40 The information contained in this option is an opaque field that 41 represents the user class of which the client is a member. 42 Based on this class, a DHCP server selects the appropriate address 43 pool to assign an address to the client and the appropriate 44 configuration parameters. 45 This option should be configurable by a user. 47 1. Introduction 49 DHCP administrators may define specific user class identifiers to 50 convey information about a client's software configuration or about 51 its user's preferences. For example, the User Class option can be 52 used to configure all clients of people in the accounting department 53 with a different printer than clients of people in the marketing 54 department. 56 2. Requirements Terminology 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [3]. 62 3. DHCP Terminology 64 o "DHCP client" 65 A DHCP client or "client" is an Internet host using DHCP to obtain 66 configuration parameters such as a network address. 68 o "DHCP server" 69 A DHCP server or "server" is an Internet host that returns 70 configuration parameters to DHCP clients. 72 o "binding" 73 A binding is a collection of configuration parameters, including at 74 least an IP address, associated with or "bound to" a DHCP client. 75 Bindings are managed by DHCP servers. 77 4. User Class option 79 This option is used by a DHCP client to optionally identify the type 80 or category of user or applications it represents. 81 A DHCP server uses the User Class option to choose the address pool 82 it allocates an address from and/or to select any other 83 configuration option. 85 This option is a DHCP option [1, 2]. 87 This option MAY carry multiple User Classes. 88 Servers may interpret the meanings of multiple class specifications 89 in an implementation dependent or configuration dependent manner, 90 and so the use of multiple classes by a DHCP client should be based 91 on the specific server implementation and configuration which will 92 be used to process that User class option. 94 The format of this option is as follows: 96 Code Len Value 97 +-----+-----+--------------------- . . . --+ 98 | 77 | N | User Class Data ('Len' octets) | 99 +-----+-----+--------------------- . . . --+ 101 where Value consists of one or more instances of User Class Data. 102 Each instance of User Class Data is formatted as follows: 104 UC_Len_i User_Class_Data_i 105 +--------+------------------------ . . . --+ 106 | L_i | Opaque-Data ('UC_Len_i' octets) | 107 +--------+------------------------ . . . --+ 109 Each User Class value (User_Class_Data_i) is indicated as an opaque 110 field. 111 The value in UC_Len_i does not include the length field itself and 112 MUST be non-zero. 113 Let m be the number of User Classes carried in the option. The 114 length of the option as specified in Len must be the sum of the 115 lengths of each of the class names plus m: 116 Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m. 117 If any instances of User Class Data are present, the minimum value 118 of Len is two (Len = UC_Len_1 + 1 = 1 + 1 = 2). 120 The Code for this option is 77. 122 A server that is not equipped to interpret any given user class 123 specified by a client MUST ignore it (although it may be reported). 124 If a server recognizes one or more user classes specified by the 125 client, but does not recognize one or more other user classes 126 specified by the client, the server MAY use the user classes it 127 recognizes. 129 DHCP clients implementing this option SHOULD allow users to enter 130 one or more user class values. 132 5. IANA Considerations 134 Option 77, which IANA has already assigned for this purpose, should 135 be used as the User Class Option for DHCP. 137 6. Security Considerations 139 DHCP currently provides no authentication or security mechanisms. 140 Potential exposures to attack are discussed is section 7 of the 141 protocol specification [1]. 143 This lack of authentication mechanism means that a DHCP server 144 cannot check if a client or user is authorised to use a given User 145 Class. 146 This introduces an obvious vulnerability when using the User Class 147 option. For example, if the User Class is used to give out a special 148 parameter (e.g. a particular database server), there is no way to 149 authenticate a client and it is therefore impossible to check if a 150 client is authorised to use this parameter. 152 7. References 154 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 155 March 1997. 157 [2] Alexander, S., and Droms R., "DHCP Options and BOOTP Vendor 158 Extensions", RFC 2132, March 1997. 160 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 161 Levels," RFC 2119, March 1997. 163 8. Acknowledgments 165 This document is based on earlier drafts by Glenn Stump, Ralph 166 Droms, Ye Gu, Ramesh Vyaghrapuri and Burcak Beser. 167 Thanks to Ted Lemon, Steve Gonczi, Kim Kinnear, Bernie Volz, Richard 168 Jones, Barr Hibbs and Thomas Narten for their comments and 169 suggestions. 171 9. Author Information 173 Glenn Stump 174 IBM Networking Software 175 P.O. Box 12195 176 RTP, NC 27709 177 Phone: (919) 301-4277 178 Email: stumpga@us.ibm.com 180 Ralph Droms 181 Computer Science Department 182 323 Dana Engineering 183 Bucknell University 184 Lewisburg, PA 17837 185 Phone: (717) 524-1145 186 Email: droms@bucknell.edu 188 Ye Gu 189 Microsoft Corporation 190 One Microsoft Way 191 Redmond, WA 98052 192 Phone: 425 936 8601 193 Email: yegu@microsoft.com 195 Ramesh Vyaghrapuri 196 Microsoft Corporation 197 One Microsoft Way 198 Redmond, WA 98052 199 Phone: 425 703 9581 200 Email: rameshv@microsoft.com 202 Burcak Beser 203 3Com Corporation 204 3800 Golf Road 205 Rolling Meadows, IL 206 Phone: 847 262 2195 207 Email: Burcak_Beser@3com.com 209 Ann Demirtjis 210 Microsoft Corporation 211 One Microsoft Way 212 Redmond WA 98052 213 Phone: 425-705-2254 214 Email: annd@microsoft.com 216 Jerome Privat 217 BT Advanced Communications Technology Centre 218 Adastral Park, Martlesham Heath, IP5 3RE 219 UK 220 Phone: +44 1473 606304 221 Email: jprivat@talk21.com 222 Full Copyright Statement 224 "Copyright (C) The Internet Society (2000). All Rights Reserved. 226 This document and translations of it may be copied and furnished to 227 others, and derivative works that comment on or otherwise explain it 228 or assist in its implmentation may be prepared, copied, published 229 and distributed, in whole or in part, without restriction of any 230 kind, provided that the above copyright notice and this paragraph 231 are included on all such copies and derivative works. However, this 232 document itself may not be modified in any way, such as by removing 233 the copyright notice or references to the Internet Society or other 234 Internet organizations, except as needed for the purpose of 235 developing Internet standards in which case the procedures for 236 copyrights defined in the Internet Standards process must be 237 followed, or as required to translate it into languages other than 238 English. 240 The limited permissions granted above are perpetual and will not be 241 revoked by the Internet Society or its successors or assigns. 243 This document and the information contained herein is provided on an 244 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 245 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 246 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 247 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 248 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."