idnits 2.17.1 draft-ietf-ips-iscsi-boot-00.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: ---------------------------------------------------------------------------- ** 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. == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines 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. ** The abstract seems to contain references ([12]), 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 143: '...iguration server MAY contain the Domai...' RFC 2119 keyword, line 195: '...boot client then MAY send a message to...' 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 (17 November 2000) is 8558 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) -- Looks like a reference, but probably isn't: 'RFC2279' on line 162 == Unused Reference: '2' is defined on line 259, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 275, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 887 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Duplicate reference: RFC2132, mentioned in '6', was also mentioned in '2'. ** Obsolete normative reference: RFC 1497 (ref. '8') (Obsoleted by RFC 1533) ** Obsolete normative reference: RFC 783 (ref. '9') (Obsoleted by RFC 1350) ** Obsolete normative reference: RFC 1532 (ref. '10') (Obsoleted by RFC 1542) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPS Prasenjit Sarkar 2 Internet Draft IBM 3 Document: draft-ietf-ips-iscsi-boot-00.txt Duncan Missimer 4 Category: Standards Track HP 5 Constantin Sapuntzakis 6 Cisco 7 17 November 2000 9 A Standard for BootStrapping Clients using the iSCSI Protocol 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [11]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or made obsolete by other documents at 21 any time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." The list 23 of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 25 Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Small Computer Systems Interface (SCSI) is a popular family of 31 protocols for communicating with I/O devices, especially storage 32 devices. iSCSI is a proposed transport protocol for SCSI that 33 operates on top of TCP[12]. This memo describes a standard mechanism 34 to enable clients to bootstrap themselves using the iSCSI protocol. 35 The goal of this standard is to enable clients to obtain the 36 information to open an iSCSI session with the iSCSI bootstrpping 37 server, assuming this information is not available. 39 1. Requirements 41 1. There must be no restriction of network topology between the iSCSI 42 boot client and the boot server. Consequently, it is possible for an 43 iSCSI boot client to boot from an iSCSI boot server behind 44 gateways/firewalls/etc as long as it is possible to establish an 45 iSCSI session between the client and the server. 47 2. The following represents the minimum information required for an 49 Standards-Track iSCSI BootStrapping Draft 17 November 2000 51 iSCSI boot client to contact an iSCSI boot server: (a) the client's 52 IP address (IPv6 or IPv4) and (b) the server's iSCSI Service Delivery 53 Port Name. 55 The above assumes that the default LUN for the boot process is 0 and 56 the default port for the iSCSI boot server is the well-known iSCSI 57 port. However, both can be overridden at the time of configuration. 59 Additional information may be required at each stage of the boot 60 process. 62 3. It is possible for the iSCSI boot client to have none of the above 63 information when the boot client software is started. 65 4. The client should be able to complete boot without user 66 intervention (for boots that occur during an unattended power-up). 67 However, there should be a mechanism for the user to input values so 68 as to bypass stages of the boot protocol. 70 5. Additional protocol software (for example, DHCP) may be necessary 71 if the minimum information required for an iSCSI session is not 72 provided. 74 2. Related Work 76 The Reverse Address Resolution Protocol (RARP)[7](through the 77 extensions defined in the Dynamic RARP (DRARP))[4] explicitly 78 addresses the problem of network address discovery, and includes an 79 automatic IP address assignment mechanism. The Trivial File Transfer 80 Protocol (TFTP)[9] provides for transport of a boot image from a boot 81 server. BOOTP[5,8,10] is a transport mechanism for a collection of 82 configuration information. BOOTP is also extensible, and official 83 extensions have been defined for several configuration parameters. 84 DHCPv4[3,6] and DHCPv6[13] are standards for hosts to be dynamically 85 configured in an IP network. The Resource Location Protocol RLP 86 provides for location of higher level services[1]. 88 3. DHCP stage 90 In order to use an iSCSI boot server, the following pieces of 91 information are required. 93 - The IP address of the iSCSI boot client (IPv4 or IPv6) 95 - The IP transport endpoint for the iSCSI service delivery port for 96 the iSCSI boot server. If the transport is TCP, for example, this 97 has to resolve to an IP address and a TCP port number. 99 Standards-Track iSCSI BootStrapping Draft 17 November 2000 101 - The eight-byte LUN structure identifying the device within the 102 iSCSI boot server (see section 4.12.2 of SAM-2 17 Sept 2000) 104 At boot time, all or none of this information may be stored in the 105 firmware of the iSCSI boot client. This section describes techniques 106 for obtaining the required information. 108 An iSCSI boot client which does not know its IP address at power-on 109 may acquire its IP address via DHCP. An iSCSI boot client which is 110 capable of using both DHCPv6 and DHCPv4 should first attempt to use 111 DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event 112 of failure. 114 Unless otherwise specified here, DHCP fields such as the client ID 115 and gateway information are used identically with applications other 116 than iSCSI. 118 A DHCPv4 or BOOTP server may instruct an iSCSI client how to reach 119 its boot device. The servers use the "file" field of the BOOTP/DHCPV4 120 header to instruct the iSCSI client of which boot server to connect 121 to and how to do so. The format of the "file" field is: 123 "iscsi:" ":" ":" ":" 125 The "file" field begins with literal UTF-8 string "iscsi:" to 126 instruct the client to use iSCSI/TCP (as opposed to NFS or some other 127 mechanism) to boot. 129 The fields "port", "LUN" and "targetname" are optional and should be 130 left blank if there are no values corresponding to the fields. 132 The "servername" is the name of iSCSI server and contains either a 133 domain name, a literal IPv4 address, or a bracketed literal IPv6 134 address. If the servername field contains a domain name, the domain 135 name must comply with the restrictions in section 3 of RFC1034 and 136 section 2.1 of RFC1123. If the servername field contains a literal 137 IPv4 address, the IPv4 address is in standard dotted decimal 138 notation. If the servername field contains an IPv6 address, the 139 address is represented in bracketed literal IPv6 address format as 140 specified in RFCs 2373 and 2732. 142 If the "servername" is a domain name, then the reply from the host 143 configuration server MAY contain the Domain Name Server Option 144 described in section 3.8 of RFC 2132. 146 The "port" is the decimal representation of the port on which the 147 iSCSI server is listening. If not specified, the port defaults to the 148 well-known iSCSI port. 150 Standards-Track iSCSI BootStrapping Draft 17 November 2000 152 The "LUN" field is 16 UTF-8 bytes representing the 8-byte LU number 153 in hex. Digits above 9 may be either lower or upper case, and all 16 154 nibbles must be present. The LUN field is blank, then LUN 0 is 155 assumed. 157 Note that SCSI targets are allowed to present different LU numberings 158 for different SCSI initiators, so that to our knowledge nothing 159 precludes a SCSI target from exporting several different devices to 160 several different SCSI initiators as their respective LU 0s. 162 The "targetname" field is a UTF-8 ([RFC2279]) string containing the 163 name of the iSCSI target, the details of which are specified by the 164 iSCSI standard[12]. If the targetname is provided, the iSCSI boot 165 client may use the targetname as mandated by the iSCSI standard. 167 In the case of a DHCPv6 server, a proposed extension for iSCSI boot 168 information would provide the information returned in the "file" 169 field by a DHCPv4 server. The interpretation of the information will 170 be identical in both DHCPv4 and DHCPv6. The proposed extension would 171 be obtained as per the rules stated in RFC 2939. 173 If the iSCSI working group registers an extension for iSCSI boot 174 information which may be used by both DHCPv4 and DHCPv6, then that 175 extension field shall be used by the DHCPv4 server rather than the 176 "file" field. 178 The above assumes that the default connection method uses TCP as 179 stated in the iSCSI standard. Should SCTP (RFC 2960) be also approved 180 as a transport mechanism for iSCSI, then the draft will be amended to 181 provide for alternate transport protocols. 183 Detailed message formats will be available in a future version of 184 this draft. 186 4. Discovery Server stage: 188 This stage is required if the DHCP server (v4 or v6) is unaware of 189 the identity of the iSCSI boot server. In such a situation, the DHCP 190 server must return the identity of an iSCSI discovery server within a 191 proposed extension for iSCSI Discovery Server. This extension would 192 be obtained following the rules stated in RFC 2939 and would apply to 193 both DHCPv4 and DHCPv6. 195 The iscsi boot client then MAY send a message to the discovery server 196 according to the specifications stated in the iSCSI Naming and 197 Discovery document[14]. The discovery server provides the boot client 198 a list of SCSI targets the client is allowed to access, along with 199 the access permissions for each of the target. 201 Standards-Track iSCSI BootStrapping Draft 17 November 2000 203 The iscsi boot client goes through the list of SCSI targets and must 204 select the first SCSI target with the bootable attribute as the iSCSI 205 boostrapping server. If such an attribute does not exist in any of 206 the SCSI targets, the boot client must select the first SCSI target 207 in the list of SCSI targets as the iSCSI boot server. 209 If the list of SCSI targets is empty, subsequent actions are left to 210 the discretion of the implementor. 212 The packets and software requirements are stated in the iSCSI Naming 213 and Discovery document[14]. 215 5. Boot Stage 217 Once the iSCSI boot client has obtained the minimum information to 218 open an iSCSI session with the iSCSI boot server, the actual booting 219 process can start. 221 The actual sequence of iSCSI commands needed to complete the boot 222 process is left to the implementor. This was done because of varying 223 requirements from different vendors and equipment, making it 224 difficult to specify a common subset of the iSCSI standard that would 225 be acceptable to everybody. 227 The iSCSI session established for boot may be taken over the booted 228 software in the boostrapping client - this is left to the discretion 229 of the implementor. 231 6. Security 233 Securing the host configuration protocol is beyond the scope of this 234 document. Authentication of DHCP messages is described in draft-ietf- 235 dhc-authentication-14.txt. 237 The iSCSI standard support various methods of authenticated login and 238 encrypted and authenticated connections for security. How to 239 configure the security parameters of an iSCSI boot client is beyond 240 the (current) scope of this document. 242 The security discussions in the iSCSI standard[12] are applicable to 243 this document. 245 Acknowledgments 247 We wish to thank John Hufferd (IBM) for taking the initiative to form 248 the iSCSI boot team, and Julian Satran (IBM) for providing insightful 249 comments. We also wish to thank the unnamed others for their help 250 with this document. 252 Standards-Track iSCSI BootStrapping Draft 17 November 2000 254 References 256 [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 257 1983. 259 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 260 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 261 University, October 1993. 263 [3] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 264 Bucknell University, March 1997. 266 [4] Brownell, D, "Dynamic Reverse Address Resolution Protocol 267 (DRARP)", Work in Progress. 269 [5] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 270 Stanford and SUN Microsystems, September 1985. 272 [6] Droms, D., "Interoperation between DHCP and BOOTP" RFC 2132, 273 Bucknell University, October 1993. 275 [7] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse 276 Address Resolution Protocol", RFC 903, Stanford, June 1984. 278 [8] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, 279 USC/Information Sciences Institute, August 1993. 281 [9] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, 282 June 1981. 284 [10] Wimer, W., "Clarifications and Extensions for the Bootstrap 285 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 287 [11] Bradner, S., "The Internet Standards Process -- 288 Revision 3", RFC 2026, October 1996. 290 [12] Satran, J., "iSCSI", Internet-Draft, November 2000. 292 [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 293 Configuration 294 Protocol for IPv6", Internet-Draft, May 2000. 296 [14] Voruganti, K. et al., "iSCSI Naming and Discovery", Internet- 297 Draft, 298 November 2000. 300 Author's Addresses 301 Standards-Track iSCSI BootStrapping Draft 17 November 2000 303 Prasenjit Sarkar 304 IBM Almaden Research Center 305 650 Harry Road 306 San Jose, CA 95120, USA 307 Phone: +1 408 927 1417 308 Email: psarkar@almaden.ibm.com 310 Duncan Missimer 311 Hewlett-Packard Company 312 19420 Homestead Road, M/S 43lo 313 Cupertino, CA 95014, USA 314 Phone: +1 408 447 5390 315 Email: duncan_missimer@hp.com 317 Constantine Sapuntzakis 318 Cisco Systems, Inc. 319 170 W. Tasman Drive 320 San Jose, CA 95134, USA 321 Phone: +1 650 520 0205 322 Email: csapuntz@cisco.com 324 Full Copyright Statement 326 "Copyright (C) The Internet Society (date). All Rights Reserved. This 327 document and translations of it may be copied and furnished to 328 others, and derivative works that comment on or otherwise explain it 329 or assist in its implementation may be prepared, copied, published 330 and distributed, in whole or in part, without restriction of any 331 kind, provided that the above copyright notice and this paragraph are 332 included on all such copies and derivative works. However, this 333 document itself may not be modified in any way, such as by removing 334 the copyright notice or references to the Internet Society or other 335 Internet organizations, except as needed for the purpose of 336 developing Internet standards in which case the procedures for 337 copyrights defined in the Internet Standards process must be 338 followed, or as required to translate it into languages other than 339 English. 341 The limited permissions granted above are perpetual and will not be 342 revoked by the Internet Society or its successors or assigns. 344 This document and the information contained herein is provided on an 345 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 346 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 347 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 348 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 349 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."