idnits 2.17.1 draft-ietf-dhc-netware-options-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-03-28) 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 abstract seems to contain references ([RFC2131], [RFC2132]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 157: '... SHOULD perform a NetWare Nearest...' RFC 2119 keyword, line 189: '...etWare/IP client SHOULD support NetWar...' 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 (January 1998) is 9569 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 section? 'RFC 2131' on line 226 looks like a reference -- Missing reference section? 'RFC 2132' on line 229 looks like a reference -- Missing reference section? 'RFC 854' on line 223 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms 2 INTERNET DRAFT Bucknell University 3 K. Fong 4 Novell 5 July 1997 6 Expires January 1998 8 Netware/IP Domain Name and Information 9 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``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.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 1.0 Abstract 31 The Dynamic Host Configuration Protocol (DHCP) [RFC 2131] provides a 32 framework for passing configuration information to hosts on a TCP/IP 33 network. DHCP includes options for specific configuration parameters 34 [RFC 2132]. This document defines options that carry Netware/IP 35 domain name and Netware/IP sub-options to DHCP clients. 37 1.1 Requirements 39 Throughout this document, the words that are used to define the 40 significance of particular requirements are capitalized. These words 41 are: 43 o "MUST" 45 This word or the adjective "REQUIRED" means that the 46 item is an absolute requirement of this specification. 48 o "MUST NOT" 50 This phrase means that the item is an absolute prohibition 51 of this specification. 53 o "SHOULD" 55 This word or the adjective "RECOMMENDED" means that there 56 may exist valid reasons in particular circumstances to ignore 57 this item, but the full implications should be understood and 58 the case carefully weighed before choosing a different course. 60 o "SHOULD NOT" 62 This phrase means that there may exist valid reasons in 63 particular circumstances when the listed behavior is acceptable 64 or even useful, but the full implications should be understood 65 and the case carefully weighed before implementing any behavior 66 described with this label. 68 o "MAY" 70 This word or the adjective "OPTIONAL" means that this item is 71 truly optional. One vendor may choose to include the item 72 because a particular marketplace requires it or because it 73 enhances the product, for example; another vendor may omit the 74 same item. 76 1.2 Terminology 78 This document uses the following terms: 80 o "DHCP client" 82 A DHCP client is an Internet host using DHCP to obtain 83 configuration parameters such as a network address. 85 o "DHCP server" 87 A DHCP server is an Internet host that returns configuration 88 parameters to DHCP clients. 90 2. The NetWare/IP Domain Name option 92 This option code is used to convey the NetWare/IP domain name used by 93 the NetWare/IP product. The NetWare/IP Domain in the option is an NVT 94 ASCII [RFC 854] string whose length is inferred from the option 'len' 95 field. 97 The code for this option is 62, and its maximum length is 255. 99 Code Len NetWare/IP Domain Name 100 +-----+-----+------+------+------+----- 101 | 62 | n | c1 | c2 | c3 | ... 102 +-----+-----+------+------+------+----- 104 3. The NetWare/IP Information option 106 The NetWare/IP option code will be used to convey all the NetWare/IP 107 related information except for the NetWare/IP domain name. 109 The code for this option is 63, and its maximum length is 255. A 110 number of NetWare/IP sub-options will be conveyed using this option 111 code. 113 Each sub-option contains in sequential order, a one byte sub-option 114 code, a one byte length, and an optional multiple byte value field. 116 One and only one of the following four sub-options must be the first 117 sub-option to be present in option 63 encoding. Each of them is 118 simply a type length pair with length set to zero. 120 Sub-options: 122 NWIP_DOES_NOTE_EXIST (code 1) 124 The responding DHCP server does not have any NetWare/IP 125 information configured. 127 NWIP_EXIST_IN_OPTIONS_AREA (code 2) 129 All NetWare/IP information is present in the 'options' area of the 130 DHCP response packet. 132 NWIP_EXIST_IN_SNAME_FILE (code 3) 134 All NetWare/IP information is present in the 'sname' and, if 135 necessary, 'file' fields of the DHCP response packet. If used, the 136 following DHCP server behavior is required: within the 'options' 137 area, option 63 is present with its length field set to 2. The 138 first byte of the value field is set to NWIP_EXIST_IN_SNAME_FILE 139 tag and the second byte is set to zero. Both option 62 and option 140 63 will be placed in the area covered by the sname and file 141 fields. Option 62 is encoded normally. Option 63 is encoded with 142 its tag, length and value. The value field does not contain any of 143 the first four sub-options described herein. 145 NWIP_EXIST_BUT_TOO_BIG (code 4) 147 Neither 'options' area nor 'sname' field can accommodate the 148 NetWare/IP information. 150 If either NWIP_EXIST_IN_OPTIONS_AREA or NWIP_EXIST_IN_SNAME_FILE 151 sub-options is set, one or more of the following sub-options may be 152 present. 154 NSQ_BROADCAST (code 5) 156 Length is 1 and a value of 1 or 0. If the value is 1, the client 157 SHOULD perform a NetWare Nearest Server Query to find out its 158 nearest NetWare/IP server. 160 PREFERRED_DSS (code 6) 162 Length is (n * 4) and the value is an array of n IP addresses, 163 each four bytes in length. The maximum number of addresses is 5 164 and therefore the maximum length value is 20. The list contains 165 the addresses of n NetWare Domain SAP/RIP Server (DSS). 167 NEAREST_NWIP_SERVER (code 7) 169 Length is (n * 4) and the value is an array of n IP addresses, 170 each four bytes in length. The maximum number of addresses is 5 171 and therefore the maximum length value is 20. The list contains 172 the addresses of n Nearest NetWare/IP servers. 174 AUTORETRIES (code 8) 176 Length is 1 and the value is a one byte integer value indicating 177 the number of times a NetWare/IP client should attempt to 178 communicate with a given DSS server at startup. 180 AUTORETRY_SECS (code 9) 182 Length is 1 and the value is a one byte integer value indicating 183 the amount of delay in seconds in between each NetWare/IP client 184 attempt to communicate with a given DSS server at startup. 186 NWIP_1_1 (code 10) 188 Length is 1 and the value is 1 or 0. If the value is 1, the 189 NetWare/IP client SHOULD support NetWare/IP Version 1.1 190 compatibility. A NetWare/IP client only needs this compatibility 191 if it will contact a NetWare/IP version 1.1 server. 193 PRIMARY_DSS (code 11) 195 Length of 4, and the value is a single IP address. This field 196 identifies the Primary Domain SAP/RIP Service server (DSS) for 197 this NetWare/IP domain. NetWare/IP administration utility uses 198 this value as Primary DSS server when configuring a secondary DSS 199 server. 201 An example of option 63 encoding is provided below. 203 Code Len NetWare/IP General Info 204 +-----+-----+----+----+ 205 | 63 | 11 | 2 | 0 | 206 +-----+-----+----+----+ 207 NWIP_EXIST_IN_OPTIONS_AREA (length 0) 209 +----+----+----+ 210 | 5 | 1 | 1 | 211 +----+----+----+ 212 NSQ_BROADCAST_SERVER (length 1) 213 value is YES 215 +----+----+------------+ 216 | 7 | 4 | IP address | 217 +----+----+------------+ 218 NEAREST_NWIP_SERVER (length 4) 219 value is IP address of server 221 4. References 223 [RFC 854] Postel, J. and J. Reynolds, "Telnet Protocol 224 Specification", RFC 854, May 1983. 226 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 227 2131, March 1997. 229 [RFC 2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 230 Extensions", RFC 2132. 232 5. Security considerations 234 These options can be used by unauthorized DHCP servers to 235 misconfigure Netware/IP clients with potentially disruptive 236 information. 238 6. Authors' addresses 240 Ralph Droms 241 Computer Science Department 242 323 Dana Engineering 243 Bucknell University 244 Lewisburg, PA 17837 246 Phone: (717) 524-1145 247 EMail: droms@bucknell.edu 249 Kester Fong 250 Information Access Division 251 Novell Inc. 252 SJF-8-265 253 2010 Fortune Dr, 254 San Jose, CA95131 256 Phone:(408)-577-8959 257 EMail: kfong@novell.com