idnits 2.17.1 draft-ietf-dhc-userclass-09.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 (July 2000) is 8686 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: December 2000 Bucknell University 5 draft-ietf-dhc-userclass-09.txt Y. Gu 6 R. Vyaghrapuri 7 A. Demirtjis 8 Microsoft 9 B. Beser 10 3Com 11 J. Privat 12 BT 13 July 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 It is often desirable to provide different levels of service to 50 different users of an IP network. 51 In order for an IP network to implement this service 52 differentiation, it needs a way to classify users. A simple solution 53 to this is to use source IP addresses for classification. Under this 54 scheme, network administrators first configure network devices such 55 as routers to recognize traffic from a particular source IP address 56 (or address range) and handle it specially to meet the desired level 57 of service. Next, they assign the IP addresses to the hosts of the 58 intended users so that the user will receive the appropriate level 59 of service. They can configure the hosts manually with these 60 addresses. However, they cannot use DHCP for address assignment, 61 even if they are already running a DHCP server in their network. A 62 current RFC-compliant DHCP server assigns IP addresses based on the 63 location of the DHCP Client in the network topology, not the type of 64 user it supports. 65 This document describes a simple extension of the DHCP protocol that 66 enables a DHCP server to assign IP addresses from different address 67 pools depending on the type of users from which it receives DHCP 68 requests. With this new extension, network administrators will be 69 able to use DHCP to hand out the appropriate addresses to clients. 70 An example intended usage is a corporate network subnet consisting 71 of different departments of users, such as Accounting, Legal, Staff, 72 etc. It may be desirable to allocate logical address pools to each 73 of the departments so that network policies may be implemented 74 easily on IP address ranges; and this would facilitate providing 75 differential services, such as network reachability. 76 A DHCP server can also use the information contained in the User 77 Class to allocate other configuration parameters than the IP 78 address. For example, a DHCP server receiving a request from a 79 client with the User Class set to "accounting auditors" may return 80 an option with the address of a particular database server. Indeed a 81 DHCP server may have a single pool of addresses and only use the 82 user class to select parameters other than IP addresses. 84 2. Requirements Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [3]. 90 3. DHCP Terminology 92 o "DHCP client" 93 A DHCP client or "client" is an Internet host using DHCP to obtain 94 configuration parameters such as a network address. 96 o "DHCP server" 97 A DHCP server or "server" is an Internet host that returns 98 configuration parameters to DHCP clients. 100 o "binding" 101 A binding is a collection of configuration parameters, including at 102 least an IP address, associated with or "bound to" a DHCP client. 103 Bindings are managed by DHCP servers. 105 4. User Class option 107 This option is used by a DHCP client to optionally identify the type 108 or category of user or applications it represents. 109 A DHCP server uses the User Class option to choose the address pool 110 it allocates an address from and/or to select any other 111 configuration option. 113 This option is a DHCP option [1, 2]. 115 This option MAY carry multiple User Classes. 116 Servers may interpret the meanings of multiple class specifications 117 in an implementation dependent or configuration dependent manner, 118 and so the use of multiple classes by a DHCP client should be based 119 on the specific server implementation and configuration which will 120 be used to process that User class option. 122 The format of this option is as follows: 124 Code Len Value 125 +-----+-----+--------------------- . . . --+ 126 | 77 | N | User Class Data ('Len' octets) | 127 +-----+-----+--------------------- . . . --+ 129 where Value consists of one or more instances of User Class Data. 130 Each instance of User Class Data is formatted as follows: 132 UC_Len_i User_Class_Data_i 133 +--------+------------------------ . . . --+ 134 | L_i | Opaque-Data ('UC_Len_i' octets) | 135 +--------+------------------------ . . . --+ 137 Each User Class value (User_Class_Data_i) is indicated as an opaque 138 field. 139 The value in UC_Len_i does not include the length field itself and 140 MUST be non-zero. 141 Let m be the number of User Classes carried in the option. The 142 length of the option as specified in Len must be the sum of the 143 lengths of each of the class names plus m: 144 Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m. 145 If any instances of User Class Data are present, the minimum value 146 of Len is two (Len = UC_Len_1 + 1 = 1 + 1 = 2). 148 The Code for this option is 77. 150 A server that is not equipped to interpret any given user class 151 specified by a client MUST ignore it (although it may be reported). 152 If a server recognizes one or more user classes specified by the 153 client, but does not recognize one or more other user classes 154 specified by the client, the server MAY use the user classes it 155 recognizes. 157 DHCP clients implementing this option SHOULD allow users to enter 158 one or more user class values. 160 5. IANA Considerations 162 Option 77, which IANA has already assigned for this purpose, should 163 be used as the User Class Option for DHCP. 165 6. Security Considerations 167 DHCP currently provides no authentication or security mechanisms. 168 Potential exposures to attack are discussed is section 7 of the 169 protocol specification [1]. 170 This lack of authentication mechanism means that a DHCP server 171 cannot check if a client or user is authorised to use a given User 172 Class. 173 This introduces an obvious vulnerability when using the User Class 174 option. For example, if the User Class is used to give out special 175 IP addresses that have better QoS associated with them (as described 176 in section 1), there is no way to authenticate a client and it is 177 therefore impossible to check if a client is authorised to use such 178 an IP address. 180 7. References 182 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 183 March 1997. 185 [2] Alexander, S., and Droms R., "DHCP Options and BOOTP Vendor 186 Extensions", RFC 2132, March 1997. 188 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 189 Levels," RFC 2119, March 1997. 191 8. Acknowledgments 192 This document is based on earlier drafts by Glenn Stump, Ralph 193 Droms, Ye Gu, Ramesh Vyaghrapuri and Burcak Beser. 194 Thanks to Ted Lemon, Steve Gonczi, Kim Kinnear, Bernie Volz, Richard 195 Jones, Barr Hibbs and Thomas Narten for their comments and 196 suggestions. 198 9. Author Information 200 Glenn Stump 201 IBM Networking Software 202 P.O. Box 12195 203 RTP, NC 27709 204 Phone: (919) 301-4277 205 Email: stumpga@us.ibm.com 207 Ralph Droms 208 Computer Science Department 209 323 Dana Engineering 210 Bucknell University 211 Lewisburg, PA 17837 212 Phone: (717) 524-1145 213 Email: droms@bucknell.edu 215 Ye Gu 216 Microsoft Corporation 217 One Microsoft Way 218 Redmond, WA 98052 219 Phone: 425 936 8601 220 Email: yegu@microsoft.com 222 Ramesh Vyaghrapuri 223 Microsoft Corporation 224 One Microsoft Way 225 Redmond, WA 98052 226 Phone: 425 703 9581 227 Email: rameshv@microsoft.com 229 Burcak Beser 230 3Com Corporation 231 3800 Golf Road 232 Rolling Meadows, IL 233 Phone: 847 262 2195 234 Email: Burcak_Beser@3com.com 236 Ann Demirtjis 237 Microsoft Corporation 238 One Microsoft Way 239 Redmond WA 98052 240 Phone: 425-705-2254 241 Email: annd@microsoft.com 242 Jerome Privat 243 BT Advanced Communications Technology Centre 244 Adastral Park, Martlesham Heath, IP5 3RE 245 UK 246 Phone: +44 1473 606304 247 Email: jerome.privat@bt.com 248 Full Copyright Statement 250 "Copyright (C) The Internet Society (2000). All Rights Reserved. 252 This document and translations of it may be copied and furnished to 253 others, and derivative works that comment on or otherwise explain it 254 or assist in its implmentation may be prepared, copied, published 255 and distributed, in whole or in part, without restriction of any 256 kind, provided that the above copyright notice and this paragraph 257 are included on all such copies and derivative works. However, this 258 document itself may not be modified in any way, such as by removing 259 the copyright notice or references to the Internet Society or other 260 Internet organizations, except as needed for the purpose of 261 developing Internet standards in which case the procedures for 262 copyrights defined in the Internet Standards process must be 263 followed, or as required to translate it into languages other than 264 English. 266 The limited permissions granted above are perpetual and will not be 267 revoked by the Internet Society or its successors or assigns. 269 This document and the information contained herein is provided on an 270 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 271 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 272 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 273 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 274 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."