idnits 2.17.1 draft-ietf-dhc-sio-00.txt: ** The Abstract section seems to be numbered 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 -- 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 an Introduction section. ** 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 44: '... MUST...' RFC 2119 keyword, line 49: '... MUST NOT...' RFC 2119 keyword, line 54: '... SHOULD...' RFC 2119 keyword, line 62: '... SHOULD NOT...' RFC 2119 keyword, line 70: '... MAY...' (6 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 (September 1997) is 9720 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) == Missing Reference: 'RFC1541' is mentioned on line 227, but not defined ** Obsolete undefined reference: RFC 1541 (Obsoleted by RFC 2131) == Unused Reference: 'RFC1533' is defined on line 226, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1533 (Obsoleted by RFC 2132) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glenn Stump, IBM 3 INTERNET DRAFT Pratik Gupta, IBM 4 March 1997 5 Expires September 1997 7 The Server Identification Option for DHCP 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, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 1.0 Abstract 30 This option is provided by DHCP servers to DHCP clients to identify 31 the origin of a DHCPOFFER -- on a basis other than a server's IP 32 address -- so that a DHCP client may optionally select from among 33 multiple offers based on a client's preference to a particular DHCP 34 server(s). The information contained in this option is a hex value 35 indicating the assigned identification of the server originating the 36 DHCPOFFER in which this option is contained. 38 2.0 Definitions 40 Throughout this document, the words that are used to define the 41 significance of the particular requirements are capitalized. These 42 words are: 44 MUST 46 This word or the adjective "REQUIRED" means that the item is 47 an absolute requirement of this specification. 49 MUST NOT 51 This phrase means the item is an absolute prohibition of this 52 specification. 54 SHOULD 56 This word or the adjective "RECOMMENDED" means that there may 57 exist valid reasons in particular circumstances to ignore 58 this item, but the full implications should be understood and 59 the case carefully weighed before choosing a different 60 course. 62 SHOULD NOT 64 This phrase means that there may exist valid reasons in 65 particular circumstances when the listed behavior is 66 acceptable or even useful, but the full implications should 67 be understood and the case carefully weighted before 68 implementing any behavior described with this label. 70 MAY 72 This word or the adjective "OPTIONAL" means that this item is 73 truly optional. One vendor may choose to include the item 74 because a particular marketplace requires it or because it 75 enhances the product, for example, another vendor may omit 76 the same item. 78 This document also uses the following terms: 80 o "DHCP client" 82 DHCP client or "client" is an Internet host using DHCP to 83 obtain configuration parameters such as a network address. 85 o "DHCP server" 87 A DHCP server of "server"is an Internet host that returns 88 configuration parameters to DHCP clients. 90 o "binding" 92 A binding is a collection of configuration parameters, 93 including at least an IP address, associated with or "bound 94 to" a DHCP client. Bindings are managed by DHCP servers. 96 3.0 The DHCP Server Identification Option 98 DHCP provides a powerful mechanism for automating and centralizing 99 the administration of IP host configuration and has become a critical 100 service in many large IP networks. Because of its importance in 101 networks and because it can create a single point of failure for 102 network operations (from a DHCP client's perspective), many network 103 administrators choose to deploy many DHCP servers in order to enhance 104 availability and/or performance of DHCP services. 106 However, for networks with multiple DHCP servers, the DHCP protocol 107 does not provide a means by which a DHCP client may "pre-specify" a 108 preference for offers from a particular DHCP server -- or set of 109 servers -- on the network. Such a means would allow, for example, 110 clients on a large, switched LAN subnet to choose DHCPOFFERs from a 111 preferred, "local" DHCP server (e.g.,one located on the same floor of 112 the building and adminstered by the client host user's department). 114 The DHCP protocol specification [see RFC1541 or current internet 115 draft] currently states that: 117 "DHCP clients are free to use any strategy in selecting a DHCP server 118 among those from which the client receives a DHCPOFFER message." 120 Thus, currently, client "policy" -- of which there is essentially no 121 standardization -- determines which of many offers is selected. In 122 practice, most vendors' implementation of "policy" here is very basic 123 (e.g., first offer received) and is "hard-coded" (i.e., non- 124 configurable). 126 In order for a client to choose a DHCPOFFER from a particular DHCP 127 server, it must have a means of identifying the server. That is, 128 unless a DHCP client can identify an individual server, the client 129 has no means by which to select it. 131 Thus, the problem of a client specifying a preference for a 132 particular server is simply that of identifying DHCP servers to the 133 client so that the client can select a DHCPOFFER from a particular 134 server (e.g., by matching a pre-configured, preferred server identity 135 against the set of server identities contained in DHCPOFFERs 136 received). 138 This document specifies an option that can be specified at DHCP 139 servers by network administrators to identify particular DHCP server 140 (or servers) to DHCP clients in order to enable the DHCP clients to 141 select from available identities. The option, known as the DHCP 142 Server Identification Option, specifies a simple DHCP server 143 identification value to be included in DHCPOFFERs so that DHCP 144 clients can distinguish among DHCP servers when making an offer 145 selection decision. 147 4.0 DHCP Server Identification Option Format 149 The code for this option is TBD, and its length is 4 bytes. 151 Code Len DHCP Server ID 152 +-------+-------+---------+----------+ 153 | TBD | 2 | server_id | 154 +-------+-------+---------+----------+ 156 where: 157 server_id is an unsigned integer (x'00' thru x'FF', 158 inclusive)which identifies the DHCP server originating 159 the DHCPOFFER packet in which the option is contained. 161 5.0 DHCP Server Behavior 163 A DHCP Server which supports the DHCP Server Identification Option 164 MUST include the option in (and only in?) DHCPOFFER packets to 165 requesting clients. Note that there is no requirement for the 166 server_id values to be unique in a subnet or across the network. That 167 is, two or more DHCP servers may share the same server_id value and 168 therefore be considered equivalent from the perspective of the DHCP 169 client's selection decision. 171 In the case where a DHCP Server Identification Option with server_id 172 value is included in a client's DHCPDISCOVER message and the 173 server_id value does not match that of the server, then the server 174 MAY ignore the DHCPDISCOVER. If the DHCP Server Identification 175 Option is included (in the requested parameter list) without a 176 server_id value, then the DHCP Server SHOULD respond with a DHCPOFFER 177 and include the appropriate server_id value in the DHCP Server 178 Identification option (assuming an available address/binding and 179 defined server_id value exist). 181 6.0 DHCP Client Behavior 183 A DHCP client MAY use the DHCP Server Identification Option to make a 184 DHCPOFFER selection decision. If two DHCPOFFERs have equivalent DHCP 185 Server Identification Option values or if no DHCP Server 186 Identification Option is included, then the DHCP client SHOULD report 187 the error and SHOULD use another mechanism to choose from among the 188 multiple offers. 190 Also, note that a client may specify a DHCP Server Identification 191 Option in a DHCPDISCOVER to express a preference for a particular 192 DHCP server (Is this a good idea? ...seems harmless, but what's the 193 point...unless a particular implied behavior?). 195 7.0 Application Notes 197 The DHCP Server Identification option allows a DHCP client to select 198 a DHCPOFFER from a preferred server or servers. The following 199 sections outline some useful applications of this capability: 201 7.1 DHCP Server Segregation within (large) Subnets 203 In large, flat networks (e.g., large, switched LANs), the DHCP Server 204 Identification option can be used to "assign" groups of clients to be 205 served by a particular DHCP server (e.g., one which serves a 206 particular workgroup/department/organization or a particular building 207 or floor of a building). This is accomplished by configuring clients 208 to prefer DHCPOFFERs with a designated DHCP server identification 209 option value. 211 7.2 Pre-production Testing of DHCP Servers 213 Similarly, in networks where a DHCP Server is being introduced into 214 production, DHCP clients which support the DHCP server identification 215 option can be used to specifically exercise that newly introduced 216 DHCP server for the purposes of testing configuration correctness, 217 etc. 219 6.0 Security Considerations 221 There are currently no security mechanisms defined for the DHCP 222 protocol. 224 7.0 References 226 [RFC1533] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 227 Extensions" [RFC1541] R. Droms, "Dynamic Host Configuration Protocol" 229 8.0 Acknowledgments 231 The authors would like to thank the following people for their review 232 and helpful comments in the formulation of this paper: Thomas 233 Narten, Esther Burwell, Ralph Droms 235 9.0 Author Information 237 Pratik Gupta 238 IBM, Inc. 239 4205 S.Miami Blvd 240 Research Triangle Park, NC 27709 241 Phone: (919)254-5654 242 email: pratik_gupta@vnet.ibm.com 244 Glenn Stump 245 IBM, Inc. 246 4205 S.Miami Blvd 247 Research Triangle Park, NC 27709 248 Phone: (919)254-5616 249 email: glennstump@vnet.ibm.com