idnits 2.17.1 draft-ietf-dhc-useraddr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '... assumed that the DHCP Client MAY send...' RFC 2119 keyword, line 126: '... the DHCP Server MAY be configured wit...' RFC 2119 keyword, line 134: '...is seen by the DHCP Server, it MUST do...' RFC 2119 keyword, line 137: '...procedure MUST be adopted:...' RFC 2119 keyword, line 140: '... the DHCP Server MUST attempt to choos...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 1999) is 9143 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) == Unused Reference: '2' is defined on line 190, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ye Gu, Microsoft 2 INTERNET DRAFT Ramesh Vyaghrapuri, Microsoft 3 Burcak Beser, 3Com 4 October 1998 5 Expires April 1999 7 DHCP Use of the User Class Option for Address Assignment 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts as 20 reference material or to cite them other than as a "working draft" or 21 "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 Abstract 30 This document proposes a mechanism that DHCP clients can use optionally 31 to obtain their IP addresses from different address pools configured on 32 a DHCP server. A DHCP client can specify a class to which it belongs. 33 Based on the class, a DHCP server selects the appropriate address pool 34 to assign an address to the client. 36 1. Introduction 38 With the popularity and importance of the Internet growing, many 39 organizations and public carriers are deploying IP-based networks. An 40 IP network is a heterogeneous environment that supports various kinds 41 of devices, users and applications (which are referred to generically 42 as "users" in the rest of this document). Often IP network 43 administrators are faced with the need to provide different levels of 44 service quality or access privilege to different users. 46 In order for an IP network to implement differentiated services, it 47 needs a way to classify users. A simple solution to this is to use 48 source IP addresses for classification. 50 Under this scheme, network administrators first configure network 51 devices such as routers to recognize traffic from a particular source 52 IP address (or address range) and handle it specially to meet the 53 desired level of service. Next, they assign the IP address(es) to the 54 host(s) of the intended user(s) so that the user(s) will receive the 55 appropriate level(s) of service. They can configure the hosts manually 56 with these addresses. However, they cannot use DHCP [1] for address 57 assignment, even if they are already running a DHCP server in their 58 network. A current RFC-compliant DHCP server assigns IP addresses 59 based on the location of the DHCP Client in the network topology, not 60 the type of user it supports. 62 This document describes a simple extension of the DHCP protocol that 63 enables a DHCP server to assign IP addresses from different address 64 pools depending on the types of client from which it receive DHCP 65 requests. With this new extension, network administrators will be able 66 to use DHCP to hand out the appropriate addresses to users (assuming 67 that the user type maps to the client type). 69 An example intended usage is a corporate network subnet consisting of 70 different departments of users, such as Accounting, Legal, Staff etc. 71 It may be desirable to allocate logical address pools to each of the 72 departments so that network policies may be implemented easily on IP 73 address ranges; and this would facilitate providing differential 74 services, such as network reachability. 76 2. Definitions 78 Throughout this document, the words that are used to define the 79 significance of particular requirements are capitalized. These words 80 are: 82 o "MUST" 84 This word or the adjective "REQUIRED" means that the 85 item is an absolute requirement of this specification. 87 o "MUST NOT" 89 This phrase means that the item is an absolute prohibition 90 of this specification. 92 o "SHOULD" 94 This word or the adjective "RECOMMENDED" means that there 95 may exist valid reasons in particular circumstances to 96 ignore this item, but the full implications should be 97 understood and the case carefully weighed before choosing a 98 different course. 100 o "SHOULD NOT" 102 This phrase means that there may exist valid reasons in 103 particular circumstances when the listed behavior is 104 acceptable or even useful, but the full implications should 105 be understood and the case carefully weighed before 106 implementing any behavior described with this label. 108 o "MAY" 110 This word or the adjective "OPTIONAL" means that this item 111 is truly optional. One vendor may choose to include the 112 item because a particular marketplace requires it or because 113 it enhances the product, for example; another vendor may 114 omit the same item. 116 3. Schema Overview 118 The user class option [3] is used by a DHCP client to inform DHCP 119 servers about the category of system, user or application it 120 represents. 122 In the following section, it is assumed that the DHCP Client MAY send 123 multiple User Class options in the same message. (They may or may not 124 occur consequetively). 126 Each address pool on the DHCP Server MAY be configured with a set of 127 ALLOWED USER CLASSES, specifying the category of clients accepted by 128 the DHCP Server; and with a set of DISALLOWED USER CLASSES, specifying 129 the category of clients that must NOT be offered addresses from the 130 address pool. 132 4. Address Assignment 134 Whenever any DHCP client message is seen by the DHCP Server, it MUST do 135 the regular processing [1] and if the DHCP Server determines that the 136 Client is to be offered a new (or unbound)IP address, the following 137 procedure MUST be adopted: 139 If the client DHCP message does not contain any User Class options, 140 then the DHCP Server MUST attempt to choose an available address pool 141 which has both the ALLOWED and DISALLOWED USER CLASSES empty. If no 142 such address pool is available, and if the DHCP Server has been 143 specifically configured to do so, it MUST attempt chose any available 144 address pool. 146 If the client DHCP Message contains any User Class options, then the 147 DHCP Server MUST attempt to choose an available address pool for which 148 the ALLOWED USER CLASSES set contains one of the user class options 149 present in the DHCP message; and for which none of the User Class 150 options present in the DHCP message are also present in the DISALLOWED 151 USER CLASSES set. If no such address pool is available, and if the 152 DHCP Server has been specifically configured to do so, it MUST attempt 153 to choose any address pool for which none of the User Class options 154 present in the DHCP message are also present in the DISALLOWED USER 155 CLASSES set. 157 If the DHCP Server is unable to find a suitable address pool, it MUST 158 NOT offer an IP address to the Client. It MAY indicate the condition 159 to the administrator. 161 5. Address Renewal 163 At renewal time, before the DHCP Server sends an DHCP ACK as per [1], 164 it MUST check to see if the address pool of the Client's IP address has 165 any of the User Class option values in the DHCP message of the Client 166 present in the DISALLOWED USER CLASSES set; or, if the ALLOWED USER 167 CLASSES set has none of the User Class option values in the DHCP 168 message, and the DHCP Server is NOT specifically configured to allow a 169 client whose user class options do not belong to either of the two sets 170 of USER CLASSES. If either of the two checks above succeed, the DHCP 171 Server MUST send a DHCP NACK message to the client and remove the 172 binding information. The DHCP Server MAY send an indication via the 173 MESSAGE option. 175 6. Security Considerations 177 DHCP currently provides no authentication or security mechanisms. 178 Potential exposures to attack are discussed is section 7 of the 179 protocol specification [1]. 181 7. Acknowledgements 183 The authors would like to thank Munil Shah and Peter Ford for reviewing 184 this draft. 186 8. References 188 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 189 1997. 190 [2] Alexander, S., and Droms R., "DHCP Options and BOOTP Vendor 191 Extensions", RFC 2132, March 1997. 192 [3] Stump, G., and Droms R., "The User Class Option for DHCP", Internet 193 Draft, November 1997. 195 9. Author's Address 197 Ye Gu 198 Microsoft Corporation 199 One Microsoft Way 200 Redmond, WA 98052 202 Phone: 425 936 8601 203 EMail: yegu@microsoft.com 205 Ramesh Vyaghrapuri 206 Microsoft Corporation 207 One Microsoft Way 208 Redmond, WA 98052 210 Phone: 425 703 9581 211 Email: rameshv@microsoft.com 213 Burcak Beser 214 3Com Corporation 215 3800 Golf Road 216 Rolling Meadows, IL 218 Phone: 847 262 2195 219 Email: Burcak_Beser@3com.com 221 This document will expire in April 1999.