idnits 2.17.1 draft-ietf-ips-iscsi-boot-12.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 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 538 has weird spacing: '... to pertain...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (18 March 2004) is 7337 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) == Unused Reference: 'Alexander93' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'Braden89' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'Bradner96' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'Bradner97' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'Droms93' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'Droms97' is defined on line 432, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Aboba03' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bakke02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bakke04' -- Possible downref: Non-RFC (?) normative reference: ref. 'Droms02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Lee04' ** Obsolete normative reference: RFC 1497 (ref. 'Reynolds93') (Obsoleted by RFC 1533) -- Possible downref: Non-RFC (?) normative reference: ref. 'Satran02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tseng03' ** Obsolete normative reference: RFC 2279 (ref. 'Yergeau98') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 1532 (ref. 'Wimer93') (Obsoleted by RFC 1542) -- Obsolete informational reference (is this intentional?): RFC 783 (ref. 'Sollins81') (Obsoleted by RFC 1350) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Storage Working Group Prasenjit Sarkar 3 Internet Draft IBM 4 Document: draft-ietf-ips-iscsi-boot-12.txt Duncan Missimer 5 Category: Standards Track Brocade 6 Constantin Sapuntzakis 7 Stanford University 8 18 March 2004 10 Bootstrapping Clients using the iSCSI Protocol 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at 22 any time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." The list 24 of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 31 documents are to be interpreted as described in RFC 2119. 33 Abstract 35 iSCSI is a proposed transport protocol for SCSI that operates on top 36 of TCP. This memo describes a standard mechanism to enable clients 37 to bootstrap themselves using the iSCSI protocol. The goal of this 38 standard is to enable iSCSI boot clients to obtain the information to 39 open an iSCSI session with the iSCSI boot server. 41 1. Introduction 43 The Small Computer Systems Interface (SCSI) is a popular family of 44 protocols for communicating with I/O devices, especially storage 45 devices. SCSI can be characterized as a request/response messaging 46 protocol with a standard architecture and componentized command sets 47 for different device classes. 49 Standards Track iSCSI BootStrapping Draft 18 March 2004 51 iSCSI is a proposed transport protocol for SCSI that operates on top 52 of TCP. The role of iSCSI is necessitated by the evolution of the 53 system interconnect from a shared bus to a switched network. IP 54 networks meet the architectural and performance requirements of 55 transporting SCSI, paving the way for the iSCSI protocol. 57 Many diskless clients sometimes bootstrap off remote SCSI devices. 58 Such diskless entities are lightweight, space-efficient and power- 59 conserving, and are increasingly popular in various environments. 61 This memo describes a standard mechanism to enable clients to 62 bootstrap themselves using the iSCSI protocol. The goal of this 63 standard is to enable iSCSI boot clients to obtain the information to 64 open an iSCSI session with the iSCSI boot server. It is possible that 65 all the information is not available at the very outset, so the memo 66 describes steps to obtain the information required to bootstrap 67 clients off an iSCSI boot server. 69 2. Requirements 71 1. There must be no restriction of network topology between the iSCSI 72 boot client and the boot server other than those in effect for 73 establishing the iSCSI session. Consequently, it is possible for an 74 iSCSI boot client to boot from an iSCSI boot server behind gateways 75 or firewalls as long as it is possible to establish an iSCSI session 76 between the client and the server. 78 2. The following represents the minimum information required for an 79 iSCSI boot client to contact an iSCSI boot server: (a) the client's 80 IP address (IPv6 or IPv4); (b) the server's iSCSI Target Name; and 81 (c) mandatory iSCSI initiator capability. 83 The above assumes that the default LUN for the boot process is 0 and 84 the default port for the iSCSI boot server is the well-known iSCSI 85 port [Satran02]. However, both may be overridden at the time of 86 configuration. 88 Additional information may be required at each stage of the boot 89 process. 91 3. It is possible for the iSCSI boot client to have none of the above 92 information or capability on starting. 94 4. The client should be able to complete boot without user 95 intervention (for boots that occur during an unattended power-up). 96 However, there should be a mechanism for the user to input values so 97 as to bypass stages of the boot protocol. 99 Standards Track iSCSI BootStrapping Draft 18 March 2004 101 5. Additional protocol software (for example, BOOTP or DHCP) may be 102 necessary if the minimum information required for an iSCSI session is 103 not provided. 105 3. Related Work 107 The Reverse Address Resolution Protocol (RARP) [Finlayson84] through 108 the extensions defined in the Dynamic RARP (DRARP)) [Brownell96] 109 explicitly addresses the problem of network address discovery, and 110 includes an automatic IP address assignment mechanism. The Trivial 111 File Transfer Protocol (TFTP) [Sollins81] provides for transport of a 112 boot image from a boot server. BOOTP [Croft85, Reynolds93, Wimer93] 113 is a transport mechanism for a collection of configuration 114 information. BOOTP is also extensible, and official extensions have 115 been defined for several configuration parameters. DHCPv4 [Droms97, 116 Droms93] and DHCPv6 [Droms02] are standards for hosts to be 117 dynamically configured in an IP network. The Service Location 118 Protocol (SLP) provides for location of higher level services 119 [Guttman99]. 121 4. Software stage 123 Some iSCSI boot clients may lack the resources to boot up with the 124 mandatory iSCSI initiator capability. Such boot clients may choose to 125 obtain iSCSI initiator software from a boot server. Currently, there 126 are many established protocols that allow such a service to enable 127 clients to load software images. For example, BOOTP and DHCP servers 128 have the capability to provide the locations of servers that can 129 serve software images on requests from boot clients. 131 It is to be noted that this document does not recommend any of the 132 above protocols, and the final decision of which boot protocol is to 133 be used to load iSCSI initiator software is left to the discretion of 134 the implementor. 136 5. DHCP stage 138 In order to use an iSCSI boot server, the following pieces of 139 information are required for an ISCSI boot client. 141 - The IP address of the iSCSI boot client (IPv4 or IPv6) 143 - The IP transport endpoint for the iSCSI Target Port for the iSCSI 144 boot server. If the transport is TCP, for example, this has to 145 resolve to an IP address and a TCP port number. TCP is currently the 146 only transport approved for iSCSI. 148 Standards Track iSCSI BootStrapping Draft 18 March 2004 150 - The eight-byte LUN structure identifying the Logical Unit within 151 the iSCSI boot server. 153 At boot time, all or none of this information may be stored in the 154 iSCSI boot client. This section describes techniques for obtaining 155 the required information via the DHCP stage. Otherwise, if the iSCSI 156 boot client has all the information, the boot client may proceed 157 directly to the Boot stage. 159 An iSCSI boot client which does not know its IP address at power-on 160 may acquire its IP address via BOOTP or DHCP (v4 or v6). Please note 161 that DHCP settings (such as the RA settings in DHCPv6) may prohibit 162 the use of DHCP in distributing iSCSI boot information -- in this 163 case, the DHCP stage cannot be used. 165 Unless otherwise specified here, BOOTP or DHCP fields such as the 166 client ID and gateway information are used in an identical way as 167 applications other than iSCSI do. 169 A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to 170 reach its boot device. This is done using the variable length option 171 named Root Path. The use of the option field is reserved for iSCSI 172 boot use by prefacing the string with "iscsi:". The Root Path option 173 is not currently defined for DHCPv6; if the option is defined for 174 DHCPv6 in the future, the use of the option as defined for iSCSI boot 175 will apply. 177 The option field consists of an UTF-8 [Yergeau98] string. The string 178 has the following composition: 180 "iscsi:"":"":"":"":" 182 The fields "servername", "port", "protocol" and "LUN" are OPTIONAL 183 and should be left blank if there are no corresponding values. The 184 "targetname" field is not optional and MUST be provided. 186 The "servername" is the name of iSCSI server and contains either a 187 valid domain name, a literal IPv4 address, or a literal IPv6 address. 188 The servername must follow the specifications outlined in Section 189 3.2.2 of the URI Specification[Lee04]. The characters allowed must 190 also conform to Section 2.2 of the same specification. Servername 191 compression MUST NOT be used in this field. 193 The "protocol" field is the decimal representation of the IANA- 194 approved string for the trasport protocol to be used for iSCSI. If 195 the protocol field is left bank, the default value is assumed to be 196 "6" for TCP. The transport protocol MUST have been approved for use 197 in iSCSI; currently, the only approved protocol is TCP. 199 Standards Track iSCSI BootStrapping Draft 18 March 2004 201 The "port" is the decimal representation of the port on which the 202 iSCSI boot server is listening. If not specified, the port defaults 203 to the well-known iSCSI port [Satran02]. 205 The "LUN" field is a hexadecimal representation of the LU number. If 206 the LUN field is blank, then LUN 0 is assumed. If the LUN field is 207 not blank, the representation MUST be divided into four groups of 208 four hexadecimal digits, separated by "-". Digits above 9 may be 209 either lower or upper case. An example of such a representation 210 would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three 211 leading zero ("0") digits MAY be omitted in any group of hexadecimal 212 digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent 213 to 6734-0009-156f-0127. Furthermore, trailing groups containing only 214 the "0" digit MAY be omitted along with the preceding "-". So, the 215 "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000. 216 Other concise representations of the LUN field MUST NOT be used. 218 Note that SCSI targets are allowed to present different LU numberings 219 for different SCSI initiators, so that to our knowledge nothing 220 precludes a SCSI target from exporting several different LUs to 221 several different SCSI initiators as their respective LUN 0s. 223 The "targetname" field is an iSCSI Name that is defined by the iSCSI 224 standard [Satran02] to uniquely identify an iSCSI target. The 225 approved characters in the targetname field are stated in the iSCSI 226 String Profile document[Bakke04]. 228 If the "servername" field is provided by BOOTP or DHCP, then that 229 field is used in conjunction with other associated fields to contact 230 the boot server in the Boot stage (Section 7). However, if the 231 "servername" field is not provided, then the "targetname" field is 232 then used in the Discovery Service stage in conjunction with other 233 associated fields. (Section 6). 235 6. Discovery Service stage 237 This stage is required if the BOOTP or DHCP server (v4 or v6) is 238 unaware of any iSCSI boot servers or if the BOOTP or DHCP server is 239 unable to provide the minimum information required to connect to the 240 iSCSI boot server other than the targetname. 242 The Discovery Service may be based on the SLP protocol [Guttman99, 243 Bakke02] and is an instantiation of the SLP Service or Directory 244 Agent. Alternatively, the Discovery Service may be based on the iSNS 245 protocol [Tseng03] and is an instantiation of the iSNS Server. 247 The iSCSI boot client may have obtained the targetname of the iSCSI 249 Standards Track iSCSI BootStrapping Draft 18 March 2004 251 boot server in the DHCP stage (Section 5). In that case, the iSCSI 252 boot client queries the SLP Discovery Service using query string 1 of 253 the iSCSI Target Concrete Service Type Template as specified in 254 Section 6.2 of the iSCSI SLP interaction document [Bakke02] to 255 resolve the targetname to an IP address and port number. 256 Alternatively, the iSCSI boot client may query the iSNS Discovery 257 Service with a Device Attribute Query with the targetname as the 258 query parameter [Tseng03]. Once this is obtained, the iSCSI boot 259 client proceeds to the Boot stage (Section 7). 261 It is possible that the port number obtained from the Discovery 262 Service may conflict with the one obtained from the DHCP stage. In 263 such a case, the implementor has the option to try both port numbers 264 in the Boot stage. 266 If the iSCSI boot client does not have any targetname information, 267 the iSCSI boot client then may query the SLP Discovery Service with 268 query string 4 of the iSCSI Target Concrete Service Type Template as 269 specified in Section 6.2 of the iSCSI SLP interaction document 270 [Bakke02]. In response to this query, the SLP Discovery Service 271 provides the boot client with a list of iSCSI boot servers the boot 272 client is allowed to access. Alternatively, the iSCSI boot client 273 can query the iSNS Discovery Service to verify if the targets in 274 particular Discovery Domain are bootable [Tseng03]. 276 If the list of iSCSI boot servers is empty, subsequent actions are 277 left to the discretion of the implementor. Otherwise, the iSCSI boot 278 client may contact any iSCSI boot server in the list. Moreover, the 279 order in which iSCSI boot servers are contacted is also left to the 280 discretion of the implementor. 282 7. Boot stage 284 Once the iSCSI boot client has obtained the minimum information to 285 open an iSCSI session with the iSCSI boot server, the actual booting 286 process can start. 288 The actual sequence of iSCSI commands needed to complete the boot 289 process is left to the implementor. This was done because of varying 290 requirements from different vendors and equipment, making it 291 difficult to specify a common subset of the iSCSI standard that would 292 be acceptable to everybody. 294 The iSCSI session established for boot may be taken over by the 295 booted software in the iSCSI boot client. 297 8. Security Considerations 299 Standards Track iSCSI BootStrapping Draft 18 March 2004 301 The security discussion is centered around securing the communication 302 involved in the iSCSI boot process. 304 However, the issue of applying credentials to a boot image loaded 305 through the iSCSI boot mechanism is outside the scope of this 306 document. One key difference between the iSCSI boot mechanism and 307 BOOTP-based image loading is the fact that the identity of a boot 308 image may not be known when the Boot stage starts. The identity of 309 certain boot images and their locations are known only after 310 examining the contents of a boot disk exposed by the iSCSI boot 311 service. Furthermore, images themselves may recursively load other 312 images based on both hardware configurations and user input. 313 Consequently, a practical way to verify loaded boot images is to make 314 sure that each image loading software verifies the image to be loaded 315 using a mechanism of their choice. 317 The considerations involved in designing a security architecture for 318 the iSCSI boot process include configuration, deployment and 319 provisioning issues apart from typical security considerations. 320 Enabling iSCSI boot creates a critical operational dependence on an 321 external system with obvious security implications, and thus 322 administrator awareness of such enablement is extremely important. 323 Therefore, iSCSI boot SHOULD NOT be enabled, or put high in the boot 324 order, without an explicit administrative action. 326 In all phases of the boot process, a client must ensure that a server 327 is authorized to send it certain information. This means that the 328 authenticated identity of a server must have an authorization 329 indication. A list of authorized servers can be pre-configured into 330 a client, or the list can be downloaded in an authenticated form from 331 a prior stage in the boot process. 333 The software stage SHOULD NOT be involved in a secure iSCSI boot 334 process as this would add the additional complexity of trying to 335 secure the process of loading the software necessary to run the later 336 stages of iSCSI boot. Authentication and integrity protection of 337 downloaded boot software has proven to be difficult and complex due 338 to administrative issues and limitations of the BIOS environment. It 339 is therefore assumed that all the necessary software is resident on 340 the iSCSI boot client. 342 If the DHCP stage is implemented using the DHCP protocol, the iSCSI 343 boot client SHOULD implement the DHCP authentication ([Droms01], 344 [Droms02] for IPv6). In this case an administration interface SHOULD 345 be provided for the configuration of the DHCP authentication 346 credentials, both when the network interface is on the motherboard, 347 and when it is removable. Note that DHCP authentication 348 ([Droms01],[Droms02] for IPv6) is focused on intra-domain 350 Standards Track iSCSI BootStrapping Draft 18 March 2004 352 authentication, which is assumed to be enough for iSCSI boot 353 scenarios. In the context of the secure iSCSI boot process, the reply 354 from the DHCP server in the DHCP stage SHOULD include the serverName 355 in IPv4 (or IPv6) format to avoid reliance on a DNS server (for 356 resolving names) or a Discovery Service entity (to look up 357 targetnames). This reduces the number of entities involved in the 358 secure iSCSI boot process. 360 If the Discovery Service stage is implemented using SLP, the iSCSI 361 boot client SHOULD provide IPsec support (OPTIONAL to use) for the 362 SLP protocol, as defined in [Bakke02] and [Aboba03]. If the Discovery 363 Service stage is implemented using iSNS, the iSCSI boot client SHOULD 364 provide IPsec support (OPTIONAL to use) for the iSNS protocol, as 365 defined in [Tseng03] and [Aboba03]. When iSNS or SLP are used to 366 distribute security policy or configuration information, at a 367 minimum, per-packet data origin authentication, integrity and replay 368 protection SHOULD be used to protect the discovery protocol. 370 For the final communication between the iSCSI boot client and the 371 iSCSI boot server in the Boot stage, IPsec and in-band authentication 372 SHOULD be implemented according to the guidelines in the main iSCSI 373 draft [Satran02] and [Aboba03]. Due to memory constraints, it is 374 expected that iSCSI boot clients will only support the pre-shared key 375 authentication in IKE. Where the host IP address is assigned 376 dynamically, IKE main mode SHOULD NOT be used, as explained in 377 [Satran02] and [Aboba03]. Regardless of the way parameters in 378 previous stages (DHCP, SLP, iSNS) were obtained (securely or not), 379 the iSCSI boot session is vulnerable as any iSCSI session (see 380 [Satran02] and [Aboba03] for iSCSI security threats). Therefore 381 security for this session SHOULD be configured and used according to 382 [Satran02] and [Aboba03] guidelines. 384 Another point to be noted is that if a boot image inherits an iSCSI 385 session from a previously loaded boot image, the boot image also 386 inherits the security properties of the iSCSI session. 388 Acknowledgments 390 We wish to thank John Hufferd for taking the initiative to form the 391 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 392 Bernard Aboba, David Robinson, Mark Bakke, Ofer Biran and Mallikarjun 393 Chadalapaka for helpful suggestions and pointers regarding the draft 394 document. 396 Normative References 398 [Aboba03] Aboba, S. et al. "Securing Block Storage Protocols over 400 Standards Track iSCSI BootStrapping Draft 18 March 2004 402 IP", Work in Progress, January 2003. 404 [Alexander93] Alexander, S., and R. Droms, "DHCP Options and BOOTP 405 Vendor 406 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 407 University, October 1993. 409 [Bakke02] Bakke, M., et al. "Finding iSCSI Targets and Name Servers 410 using SLP", Work in Progress, March 2002. 412 [Bakke04] Bakke, M., "String Profiles for iSCSI Names", Work in 413 Progress, February 2004. 415 [Braden89] Braden, R., "Requirements for Internet Hosts - Application 416 and Support", RFC 1123, October 1989. 418 [Bradner96] Bradner, S., "The Internet Standards Process -- 419 Revision 3", RFC 2026, October 1996. 421 [Bradner97] Bradner, S. "Key Words for use in RFCs to indicate 422 Requirement Levels", RFC 2119, Harvard University, March 1997. 424 [Croft85] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", 425 RFC 951, 426 Stanford and SUN Microsystems, September 1985. 428 [Droms93] Droms, D., "Interoperation between DHCP and BOOTP" RFC 429 1534, 430 Bucknell University, October 1993. 432 [Droms97] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 433 Bucknell University, March 1997. 435 [Droms01] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 436 RFC 3118, June 2001. 438 [Droms02] Droma, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 439 Carney, M., "Dynamic Host Configuration Protocol for IPv6", Work in 440 Progress, November 2002. 442 [Guttman99] Guttman, E., Perkins, C., Verizades, J., Day, M., 443 "Service Location Protocol v2", RFC 2608, June 1999. 445 [Lee04] Lee, T., Fielding, R., Masinter, L., "Uniform Resource 446 Identifier (URI): General Syntax", Work in Progress, February 2004. 448 [Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 449 1497, 451 Standards Track iSCSI BootStrapping Draft 18 March 2004 453 USC/Information Sciences Institute, August 1993. 455 [Satran02] Satran, J. et al., "iSCSI", Work in Progress, September 456 2002. 458 [Tseng03] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., 459 Souza, J., "Internet Storage Name Service", Work in Progress, June 460 2003. 462 [Yergeau98] Yergeau, F., "UTF-8: A Transformation Format for 463 ISO-10646", RFC 2279, January 1998. 465 [Wimer93] Wimer, W., "Clarifications and Extensions for the Bootstrap 466 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 468 Informative References 470 [Brownell96] Brownell, D, "Dynamic RARP extensions for Automatic 471 Network Adress 472 Acquisition", RFC 1931, SUN Microsystems, April 1996. 474 [Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 475 Reverse 476 Address Resolution Protocol", RFC 903, Stanford, June 1984. 478 [Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, 479 NIC, 480 June 1981. 482 Authors' Addresses 484 Prasenjit Sarkar 485 IBM Almaden Research Center 486 650 Harry Road 487 San Jose, CA 95120, USA 488 Phone: +1 408 927 1417 489 Email: psarkar@almaden.ibm.com 491 Duncan Missimer 492 Brocade Communication Systems 493 1745 Technology Drive, 494 San Jose, CA 95110, USA 495 Email: dmissime@brocade.com 497 Constantine Sapuntzakis 498 Stanford University 499 353 Serra Hall #406 501 Standards Track iSCSI BootStrapping Draft 18 March 2004 503 Stanford, CA 94306, USA 504 Phone: +1 650 520 0205 505 Email: csapuntz@stanford.edu 507 Full Copyright Statement 509 "Copyright (C) The Internet Society (date). All Rights Reserved. This 510 document and translations of it may be copied and furnished to 511 others, and derivative works that comment on or otherwise explain it 512 or assist in its implementation may be prepared, copied, published 513 and distributed, in whole or in part, without restriction of any 514 kind, provided that the above copyright notice and this paragraph are 515 included on all such copies and derivative works. However, this 516 document itself may not be modified in any way, such as by removing 517 the copyright notice or references to the Internet Society or other 518 Internet organizations, except as needed for the purpose of 519 developing Internet standards in which case the procedures for 520 copyrights defined in the Internet Standards process must be 521 followed, or as required to translate it into languages other than 522 English. 524 The limited permissions granted above are perpetual and will not be 525 revoked by the Internet Society or its successors or assigns. 527 This document and the information contained herein is provided on an 528 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 529 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 530 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 531 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 532 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 534 Intellectual Property Rights 536 The IETF takes no position regarding the validity or scope of 537 any intellectual property or other rights that might be claimed 538 to pertain to the implementation or use of the technology 539 described in this document or the extent to which any license 540 under such rights might or might not be available; neither does 541 it represent that it has made any effort to identify any such 542 rights. Information on the IETF's procedures with respect to 543 rights in standards-track and standards-related documentation 544 can be found in BCP-11. Copies of claims of rights made 545 available for publication and any assurances of licenses to 546 be made available, or the result of an attempt made 547 to obtain a general license or permission for the use of such 548 proprietary rights by implementors or users of this 549 specification can be obtained from the IETF Secretariat." 551 Standards Track iSCSI BootStrapping Draft 18 March 2004 553 The IETF invites any interested party to bring to its 554 attention any copyrights, patents or patent applications, or 555 other proprietary rights which may cover technology that may be 556 required to practice this standard. Please address the 557 information to the IETF Executive Director.