idnits 2.17.1 draft-ietf-dhc-slp-02.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. ** 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 52: '... The scope MAY be denoted in any sta...' RFC 2119 keyword, line 59: '...ion listed below MAY be included multi...' RFC 2119 keyword, line 60: '...EST. If so, then the options SHOULD be...' RFC 2119 keyword, line 92: '...ing Directory Agents MUST NOT be used....' RFC 2119 keyword, line 97: '...d upon reception; MUST be sent as zero...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '... scope the...' -- 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 (24 April 1997) is 9864 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) ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '1') ** Obsolete normative reference: RFC 1541 (ref. '2') (Obsoleted by RFC 2131) -- Unexpected draft version: The latest known version of draft-ietf-svrloc-protocol is -16, but you're referring to -17. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins 2 INTERNET DRAFT Sun Microsystems 3 24 April 1997 5 DHCP Options for Service Location Protocol 6 draft-ietf-dhc-slp-02.txt 8 Status of This Memo 10 This document is a submission to the Dynamic Host Configuration 11 Working Group of the Internet Engineering Task Force (IETF). Comments 12 should be submitted to the dhcp-v4@bucknell.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 29 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 30 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 The Dynamic Host Configuration Protocol provides a framework for 35 passing configuration information to hosts on a TCP/IP network. 36 Entities using the Service Location Protocol need to find out the 37 address of Directory Agents in order to transact messages. In 38 certain other instances they may need to discover the correct scope 39 to be used in conjunction with the service attributes which are 40 exchanged using the Service Location Protocol. 42 1. Introduction 44 The Dynamic Host Configuration Protocol [2] provides a framework 45 for passing configuration information to hosts on a TCP/IP network. 46 Entities using the Service Location Protocol [3] need to find out 47 the address of Directory Agents in order to transact messages. In 48 certain other instances they may need to discover the correct scope 49 to be used in conjunction with the service attributes which are 50 exchanged using the Service Location Protocol. 52 The scope MAY be denoted in any standardized character set. Values 53 for character encoding can be found in IANA's database 54 http://www.isi.edu/in-notes/iana/assignments/character-sets 55 and have the values referred by the MIBEnum value. Note that in some 56 character sets, each character may require two or more octets of data 57 for its representation. 59 Note that each option listed below MAY be included multiple times in 60 the same DHCPOFFER or DHCPREQUEST. If so, then the options SHOULD be 61 included in order of decreasing preference. 63 2. Directory Agent Option 65 This option requests or specifies a Directory Agent (DA), along with 66 zero or more scopes supported by that DA. 68 0 1 2 3 69 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 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Code | Length |D|F|M|S| rsv | DA Length | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 | Directory Agent (variable length) ... 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 | Char Encoding | Service Scope (variable length) 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 Code 78 80 Length (variable) The length of the option. 82 D If the 'D' bit is set, the Directory Agent field is 83 present. 85 F If the 'F' bit is set, the Directory Agent is indicated 86 by including its variable length host name or Fully 87 Qualified Domain Name (FQDN) instead of its 4 octet IP 88 address. 90 M If the 'M' bit is set, the Directory Agent address is 91 the only one that may be used, and multicast methods for 92 discovering Directory Agents MUST NOT be used. 94 S If the 'S' bit is set, the scope is present, encoded in 95 the indicated character set. 97 rsv reserved; ignored upon reception; MUST be sent as zero 99 DA Length The length (in octets) of the Directory Agent field. 101 Directory Agent 102 The Fully Qualified Domain Name (FQDN), host name, or IP 103 address of the Directory Agent. 105 Char Encoding 106 The standardized encoding for the characters denoting the 107 scope. 109 scope The characters denoting the scope. 111 In order to simplify administration of the configuration of Directory 112 Agents for Service Location Protocol clients, the Directory Agent 113 can be indicated by presenting its FQDN or host name instead of its 114 IP address. This allows renumbering to proceed more smoothly [1]. 115 When the FQDN or host name is used, the server sets the 'F' bit. The 116 host name can be distinguished from the FQDN by the presence of a '.' 117 character. In any case, the DA length field is set to be the length 118 of the Directory Agent field. When the 'F' bit is not set, the DA 119 Length MUST be 4. 121 Note that more than one Directory Agent option may be present in a 122 DHCP message. Each such option may have the same or different scope. 123 The client may request any Directory Agent with a particular scope, 124 by including the Directory Agent option in a DHCP Request message 125 with no Directory Agent address included (the 'D' bit set to zero), 126 and the characters denoting the scope. The length of the scope is 127 only indicated implicitly by the overall length of the option. 129 3. Service Scope Option 131 This option indicates a scope that should be used by a Service Agent 132 (SA) [3], when responding to Service Request messages as specified by 133 the Service Location Protocol. 135 0 1 2 3 136 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Code | Length | Char Encoding | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Service Scope ... 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Code 79 146 Length (variable) The length of the option. 148 Char Encoding 149 The standardized encoding for the characters denoting the 150 scope. 152 scope the characters denoting the scope. 154 Note that more than one Service Scope option may be present in a DHCP 155 message. The length of the scope is only indicated implicitly by the 156 overall length of the option. 158 4. Security Considerations 160 If a malicious host is able to insert fraudulent information in 161 DHCPOFFER packets sent to a prospective client of the Service 162 Location Protocol, then the client will be unable to obtain service, 163 and vulnerable to disclosing information to unauthorized service 164 agents. Likewise, a service agent would find that it might rely on 165 fraudulent or otherwise malicious directory agents to advertise its 166 services. Many opportunities for denial of service exist. 168 This difficulty is inherited from the much larger and more serious 169 problem, viz. securing or authenticating any information whatsoever 170 from a DHCP server (or client!) is not possible in common DHCP 171 deployments. 173 5. Acknowledgements 175 Thanks to Erik Guttman for his helpful suggestions in the creation of 176 this draft. 178 References 180 [1] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, 181 February 1996. 183 [2] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 184 October 1993. 186 [3] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 187 Location Protocol, April 1997. draft-ietf-svrloc-protocol-17.txt 188 (work in progress). 190 Author's Address 192 Questions about this memo can be directed to: 194 Charles E. Perkins 195 Sun Microsystems 196 2550 Garcia Avenue 197 Mountain View, CA 94043 199 Phone: +1 415 336 7153 200 Fax: +1 415 336 0670 202 EMail: charliep@acm.org