idnits 2.17.1 draft-ietf-dhc-slp-07.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: ---------------------------------------------------------------------------- ** 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? == 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 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 2 characters in excess of 72. 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-svrloc-protocol-v2-12 ** Obsolete normative reference: RFC 2279 (ref. '5') (Obsoleted by RFC 3629) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Perkins 3 INTERNET DRAFT E. Guttman 4 Sun Microsystems 5 10 February 1999 7 DHCP Options for Service Location Protocol 8 draft-ietf-dhc-slp-07.txt 10 Status of This Memo 12 This document is a submission by the Dynamic Host Configuration 13 Working Group of the Internet Engineering Task Force (IETF). 14 Comments should be submitted to the dhcp-v4@bucknell.edu mailing 15 list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 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 The Dynamic Host Configuration Protocol provides a framework for 39 passing configuration information to hosts on a TCP/IP network. 40 Entities using the Service Location Protocol need to find out the 41 address of Directory Agents in order to transact messages. Another 42 option provides an assignment of scope for configuration of SLP User 43 and Service Agents. 45 1. Introduction 47 The Dynamic Host Configuration Protocol [2] provides a framework 48 for passing configuration information to hosts on a TCP/IP network. 49 Entities using the Service Location Protocol, Version 2 [3] and 50 Service Location Protocol, Version 1 [4] need to obtain the address 51 of Directory Agents and Scope configuration. The Service Location 52 Protocol (SLP) provides a default configuration for Scopes and 53 Directory Agents may be discovered using multicast or broadcast. It 54 is useful in a larger deployment to be able to configure SLP Agents 55 using DHCP, so as to centralize the administration and to deploy SLP 56 in networks where multicast routing is not available. 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 [1]. 62 2. Introduction 64 The DHCP options described below are used to configure Agents using 65 the Service Location Protocol, Version 2 [3] and Version 1 [4]. 67 The SLP Directory Agent option is used to configure User Agents and 68 Service Agents with the location of Directory Agents in the network. 70 The SLP Scope Option takes precedence over both default and static 71 scope configuration of SLP agents. 73 3. SLP Directory Agent Option 75 This option specifies the location of one or more SLP Directory 76 Agents. 78 0 1 2 3 79 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Code = 78 | Length | Mandatory | a1 | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | a2 | a3 | a4 | ... 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 The SLP Directory Agent Option specifies a list of IP addresses 87 for Directory Agents. Directory Agents MUST be listed in order of 88 preference, if there is an order of preference. 90 The Length value must include one for the 'Mandatory' byte and 91 include four for each Directory Agent address which follows. Thus, 92 the Length minus one of the option MUST always be divisible by 4 and 93 has a minimum value of 5. 95 The address of the Directory Agent is given in network byte order. 97 The 'Mandatory' byte in the Directory Agent option may be set to 98 either 0 or 1. If it is set to 1, the SLP User Agent or Service 99 Agent so configured MUST NOT employ either active or passive 100 multicast discovery of Directory Agents. 102 Note that for backward compatibility with some deployed software the 103 Mandatory byte MUST NOT be set to any byte value for which the high 104 order bit (0x80) is set. 106 The Directory Agents listed in this option MUST be configured with 107 the a non-empty subset of the scope list that the Agent receiving the 108 Directory Agent Option is configured with. See the notes below. 110 The SLPv2 specification [3] defines how to use this option. 112 4. SLP Service Scope Option 114 The scope list is a comma delimited list which indicates the scopes 115 that a SLP Agent is configured to use. 117 0 1 2 3 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Code = 79 | Length | Mandatory | ... 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 The Length indicates the number of bytes which follow. Since the 124 Scope-List String is encoded using UTF-8 [5] characters, it may be 125 the cast that the Length is not the same as the number of characters 126 in the Scope-List String. The Length value must include one for the 127 'Mandatory' byte. 129 The 'Mandatory' byte determines whether SLP Agents override their 130 static configuration for scopes with the string 131 provided by the option. This allows DHCP administrators to 132 implement a policy of assigning a set of scopes to Agents for service 133 provision. If the Mandatory byte is 0, static configuration takes 134 precedence over the DHCP provided scope list. If the Mandatory byte 135 is 1, the provided in this option MUST be used by the 136 SLP Agent. 138 The Scope List String syntax and usage are defined in the SLPv2 139 specification [3]. 141 4.1. Zero Length Scope-List String Configuration 143 A SLP Service Scope Option which indicates a Length of 1 (in other 144 words, omitting the string entirely) validly configures 145 the SLP User Agent to use "User Selectable Scopes." 147 The SLP Agent will use the aggregated list of scopes of all known 148 DAs. If no DAs are known, the UA will use SA discovery to determine 149 the list of scopes on the network, as defined in [3]. 151 Note that this configuration is tantamount to removing all 152 centralized control of the scope configuration of hosts on the 153 network. This makes it possible for every User Agent to see every 154 service. This may not be desirable as users may not be able to or 155 desire to decide which services are appropriate for them. 157 5. Security Considerations 159 If a malicious host is able to insert fraudulent information in 160 DHCPOFFER packets sent to a prospective SLP Agent then the SLP Agent 161 will be unable to obtain service, or may unwittingly be directed to 162 use the incorrect services. 164 Many opportunities for denial of service exist. A service agent 165 could find that it might rely on fraudulent or otherwise malicious 166 directory agents to advertise its services. DHCPOFFERs could prevent 167 the regular SLP framework from functioning by directing clients to 168 not use multicast, to use nonexistent directory agents and so on. 170 These difficulties are inherited from the much larger and more 171 serious problem, viz. securing or authenticating any information 172 whatsoever from a DHCP server (or client!) is not possible in common 173 DHCP deployments. 175 6. Full Copyright Statement 177 Copyright (C) The Internet Society (1997). All Rights Reserved. 179 This document and translations of it may be copied and furnished to 180 others, and derivative works that comment on or otherwise explain it 181 or assist in its implementation may be prepared, copied, published 182 and distributed, in whole or in part, without restriction of any 183 kind, provided that the above copyright notice and this paragraph 184 are included on all such copies and derivative works. However, 185 this document itself may not be modified in any way, such as by 186 removing the copyright notice or references to the Internet Society 187 or other Internet organizations, except as needed for the purpose 188 of developing Internet standards in which case the procedures 189 for copyrights defined in the Internet Standards process must be 190 followed, or as required to translate it into languages other than 191 English. 193 The limited permissions granted above are perpetual and will not be 194 revoked by the Internet Society or its successors or assigns. 196 This document and the information contained herein is provided on an 197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 203 References 205 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 206 Levels. RFC 2119, March 1997. 208 [2] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 209 1997. 211 [3] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service 212 Location Protocol version 2. draft-ietf-svrloc-protocol-v2-12.txt, 213 February 1999. (work in progress). 215 [4] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 216 Location Protocol. RFC 2165, July 1997. 218 [5] F. Yergeau. UTF-8, a transformation format of unicode and ISO 219 10646. RFC 2279, October 1998. 221 Author's Address 223 Questions about this memo can be directed to: 225 Charles E. Perkins Erik Guttman 226 Technology Development Group Technology Development Group 227 Mail Stop MPK15-214 Mail Stop UFRA02 228 Sun Microsystems, Inc. Sun Microsystems, Inc. 229 15 Network Circle Bahnstr. 2 230 Menlo Park, CA 94025 74915 Waibstadt, Germany 231 phone: +1 650-786-6464 phone: +49 7263 911 701 232 fax: +1 650-786-6445 or: +1 650 786 5992 233 email: Charles.Perkins@Sun.Com Erik.Guttman@Sun.Com 234 Web: http://www.svrloc.org/~charliep