idnits 2.17.1 draft-ietf-dhc-slp-01.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 -- 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 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 53: '... The scope MAY be denoted in any sta...' RFC 2119 keyword, line 59: '...EST. If so, then the options SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 79 has weird spacing: '... Length vari...' == Line 117 has weird spacing: '... Length vari...' -- 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 (14 March 1997) is 9905 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) ** Obsolete normative reference: RFC 1738 (ref. '1') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1541 (ref. '2') (Obsoleted by RFC 2131) == Outdated reference: A later version (-16) exists of draft-ietf-svrloc-protocol-15 Summary: 12 errors (**), 0 flaws (~~), 4 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 IBM 4 14 March 1997 6 DHCP Options for Service Location Protocol 7 draft-ietf-dhc-slp-01.txt 9 Status of This Memo 11 This document is a submission to the Dynamic Host Configuration 12 Working Group of the Internet Engineering Task Force (IETF). Comments 13 should be submitted to the dhcp@bucknell.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 30 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 31 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 The Dynamic Host Configuration Protocol provides a framework for 36 passing configuration information to hosts on a TCP/IP network. 37 Entities using the Service Location Protocol need to find out the 38 address of Directory Agents in order to transact messages. In 39 certain other instances they may need to discover the correct scope 40 to be used in conjunction with the service attributes and URLS which 41 are exchanged using the Service Location Protocol. 43 1. Introduction 45 The Dynamic Host Configuration Protocol [2] provides a framework 46 for passing configuration information to hosts on a TCP/IP network. 47 Entities using the Service Location Protocol [3] need to find out 48 the address of Directory Agents in order to transact messages. In 49 certain other instances they may need to discover the correct scope 50 to be used in conjunction with the service attributes and URLs [1] 51 which are exchanged using the Service Location Protocol. 53 The scope MAY be denoted in any standardized character set. Values 54 for character encoding can be found in IANA's database 55 http://www.isi.edu/in-notes/iana/assignments/character-sets 56 and have the values referred by the MIBEnum value. 58 Note that each option listed below may be included multiple times in 59 the same DHCPOFFER or DHCPREQUEST. If so, then the options SHOULD be 60 included in order of decreasing preference. 62 2. Directory Agent Option 64 This option requests or specifies a Directory Agent (DA), along with 65 zero or more scopes supported by that DA. 67 0 1 2 3 68 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 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | Code | Length |D|S| reserved | 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 | (if present) Directory Agent address | 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | Char Encoding | scope ... 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 Code 78 79 Length variable 81 D If the 'D' bit is set, the Directory Agent address is 82 present. 84 S If the 'S' bit is set, the scope is present, encoded in 85 the indicated character set. 87 Char Encoding 88 The standardized encoding for the characters making up 89 the string denoting the scope. 91 scope A string denoting the scope. 93 Note that more than one Directory Agent option may be present in a 94 DHCP message. Each such option may have the same or different scope. 95 The client may request any Directory Agent with a particular scope, 96 by including the Directory Agent option in a DHCP Request message 97 with no Directory Agent address included (the 'D' bit set to zero), 98 and the string denoting the scope. The length of the scope string is 99 only indicated implicitly by the overall length of the option. 101 3. Service Scope Option 103 This option indicates a scope that should be used by a Service Agent 104 (SA) [3], when responding to Service Request messages as specified by 105 the Service Location Protocol. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Code | Length | Char Encoding | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | scope ... 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Code 79 117 Length variable 119 Char Encoding 120 The standardized encoding for the characters making up 121 the string denoting the scope. 123 scope A string denoting the scope. 125 Note that more than one Service Scope option may be present in a DHCP 126 message. The length of the scope string is only indicated implicitly 127 by the overall length of the option. 129 4. Security Considerations 131 If a malicious host is able to insert fraudulent information in 132 DHCPOFFER packets sent to a prospective client of the Service 133 Location Protocol, then the client will be unable to obtain service, 134 and vulnerable to disclosing information to unauthorized service 135 agents. Likewise, a service agent would find that it might rely on 136 fraudulent or otherwise malicious directory agents to advertise its 137 services. Many opportunities for denial of service exist. 139 This difficulty is inherited from the much larger and more serious 140 problem, viz. securing or authenticating any information whatsoever 141 from a DHCP server (or client!) is not possible in common DHCP 142 deployments. 144 5. Acknowledgements 146 Thanks to Erik Guttman for his helpful suggestions in the creation of 147 this draft. 149 References 151 [1] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 152 Locators (URL). RFC 1738, December 1994. 154 [2] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 155 October 1993. 157 [3] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 158 Location Protocol, November 1996. draft-ietf-svrloc-protocol-15.txt 159 (work in progress). 161 Author's Address 163 Questions about this memo can be directed to: 165 Charles E. Perkins 166 Sun Microsystems 167 2550 Garcia Avenue 168 Mountain View, CA 94043 170 Phone: +1 415 336 7153 171 Fax: +1 415 336 0670 173 EMail: charliep@acm.org