idnits 2.17.1 draft-ietf-ips-iscsi-boot-11.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 545 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 (25 July 2003) is 7571 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: 'Bradner96' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'Bradner97' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'Droms93' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'Droms97' is defined on line 439, 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. 'Droms02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Guttman99' ** 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 (~~), 8 warnings (==), 9 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-11.txt Duncan Missimer 5 Category: Standards Track Brocade 6 Constantin Sapuntzakis 7 Stanford University 8 25 July 2003 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 25 July 2003 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. However, both may be overridden at the time of configuration. 87 Additional information may be required at each stage of the boot 88 process. 90 3. It is possible for the iSCSI boot client to have none of the above 91 information or capability on starting. 93 4. The client should be able to complete boot without user 94 intervention (for boots that occur during an unattended power-up). 95 However, there should be a mechanism for the user to input values so 96 as to bypass stages of the boot protocol. 98 5. Additional protocol software (for example, DHCP) may be necessary 100 Standards Track iSCSI BootStrapping Draft 25 July 2003 102 if the minimum information required for an iSCSI session is not 103 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 software images on requests from boot 129 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 - The eight-byte LUN structure identifying the Logical Unit within 150 Standards Track iSCSI BootStrapping Draft 25 July 2003 152 the iSCSI boot server. 154 At boot time, all or none of this information may be stored in the 155 iSCSI boot client. This section describes techniques for obtaining 156 the required information via the DHCP stage. Otherwise, if the iSCSI 157 boot client has all the information, the boot client may proceed 158 directly to the Boot stage. 160 An iSCSI boot client which does not know its IP address at power-on 161 may acquire its IP address via DHCP (v4 or v6). 163 Unless otherwise specified here, DHCP fields such as the client ID 164 and gateway information are used in an identical way as applications 165 other than iSCSI do. 167 A DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach 168 its boot device. This is done using the variable length DHCP option 169 named Root Path. The use of the option field is reserved for iSCSI 170 boot use by prefacing the string with "iscsi:". 172 The option field consists of an UTF-8 [Yergeau98] string. The string 173 MUST contain only alphanumberic characters, "." , ":" and "-"; no 174 other characters are permissible. The string has the following 175 composition: 177 "iscsi:"":"":"":"":" 179 The fields "servername", "port", "protocol" and "LUN" are OPTIONAL 180 and should be left blank if there are no corresponding values. The 181 "targetname" field is not optional and MUST be provided. 183 The "servername" is the name of iSCSI server and contains either a 184 valid domain name, a literal IPv4 address, or a literal IPv6 address. 186 If the "servername" field contains a literal IPv4 address, the IPv4 187 address MUST be in standard dotted decimal notation as defined in 188 Section 2.1 of RFC 1123 [Braden89]. 190 If the "servername" field contains an IPv6 address, the address MUST 191 be represented in the IPv6 address format x.x.x.x.x.x.x.x where the 192 'x's are the hexadecimal values of the eight 16-bit pieces of the 193 address. Note that this format representation is specific to iSCSI 194 boot. 196 If the "servername" is a domain name, the name MUST be a fully 197 qualified domain name (FQDN) and should abide by the rules specified 198 in Sections 3.1 and 3.5 of RFC 1034 [Mockaopetris87] and the reply 199 from the host configuration server should contain the Domain Name 201 Standards Track iSCSI BootStrapping Draft 25 July 2003 203 Server Option [Alexander93]. It must also be pointed out that the 204 use of DNS for address translation in enterprise environments must 205 contain adequate levels of fault tolerance and security. 207 If the "servername" field contains 4 decimal components, the 208 "servername" is assumed to be an IPv4 address. If there are more than 209 4 decimal components or if there is a hexadecimal component, the the 210 "servername" is assumed to be an IPv6 address. If the least 211 significant (rightmost) component is an approved domain extension, 212 then the "servername" field is assumed to be a domain name. If the 213 "servername" field is left blank, then no default value is assumed in 214 its place. 216 The "protocol" field is the decimal representation of the IANA- 217 approved string for the trasport protocol to be used for iSCSI. If 218 the protocol field is left bank, the default value is assumed to be 219 "6" for TCP. The transport protocol MUST have been approved for use 220 in iSCSI; currently, the only approved protocol is TCP. 222 The "port" is the decimal representation of the port on which the 223 iSCSI boot server is listening. If not specified, the port defaults 224 to the well-known iSCSI port. 226 The "LUN" field is a hexadecimal representation of the LU number. If 227 the LUN field is blank, then LUN 0 is assumed. If the LUN field is 228 not blank, the representation MUST be divided into four groups of 229 four hexadecimal digits, separated by "-". Digits above 9 may be 230 either lower or upper case. An example of such a representation 231 would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three 232 leading zero ("0") digits MAY be omitted in any group of hexadecimal 233 digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent 234 to 6734-0009-156f-0127. Furthermore, trailing groups containing only 235 the "0" digit MAY be omitted along with the preceding "-". So, the 236 "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000. 237 Other concise representations of the LUN field MUST NOT be used. 239 Note that SCSI targets are allowed to present different LU numberings 240 for different SCSI initiators, so that to our knowledge nothing 241 precludes a SCSI target from exporting several different LUs to 242 several different SCSI initiators as their respective LUN 0s. 244 The "targetname" field is an iSCSI Name that is defined by the iSCSI 245 standard [Satran02] to uniquely identify an iSCSI target. 247 If the "servername" field is provided by DHCP, then that field is 248 used in conjunction with other associated fields to contact the boot 249 server in the Boot stage (Section 7). However, if the "servername" 250 field is not provided, then the "targetname" field is then used in 252 Standards Track iSCSI BootStrapping Draft 25 July 2003 254 the Discovery Service stage in conjunction with other associated 255 fields. (Section 6). 257 6. Discovery Service stage 259 This stage is required if the DHCP server (v4 or v6) is unaware of 260 any iSCSI boot servers or if the DHCP server is unable to provide the 261 minimum information required to connect to the iSCSI boot server 262 other than the targetname. 264 The Discovery Service may be based on the SLP protocol [Guttman99, 265 Bakke02] and is an instantiation of the SLP Service or Directory 266 Agent. Alternatively, the Discovery Service may be based on the iSNS 267 protocol [Tseng03] and is an instantiation of the iSNS Server. 269 The iSCSI boot client may have obtained the targetname of the iSCSI 270 boot server in the DHCP stage (Section 5). In that case, the iSCSI 271 boot client queries the SLP Discovery Service using query string 1 of 272 the iSCSI Target Concrete Service Type Template as specified in 273 Section 6.2 of the iSCSI SLP interaction document [Bakke02] to 274 resolve the targetname to an IP address and port number. 275 Alternatively, the iSCSI boot client may query the iSNS Discovery 276 Service with a Device Attribute Query with the targetname as the 277 query parameter [Tseng03]. Once this is obtained, the iSCSI boot 278 client proceeds to the Boot stage (Section 7). 280 It is possible that the port number obtained from the Discovery 281 Service may conflict with the one obtained from the DHCP service. In 282 such a case, the implementor has the option to try both port numbers 283 in the Boot stage. 285 If the iSCSI boot client does not have any targetname information, 286 the iSCSI boot client then may query the SLP Discovery Service with 287 query string 4 of the iSCSI Target Concrete Service Type Template as 288 specified in Section 6.2 of the iSCSI SLP interaction document 289 [Bakke02]. In response to this query, the SLP Discovery Service 290 provides the boot client with a list of iSCSI boot servers the boot 291 client is allowed to access. Alternatively, the iSCSI boot client 292 can query the iSNS Discovery Service to verify if the targets in 293 particular Discovery Domain are bootable [Tseng03]. 295 If the list of iSCSI boot servers is empty, subsequent actions are 296 left to the discretion of the implementor. Otherwise, the iSCSI boot 297 client may contact any iSCSI boot server in the list. Moreover, the 298 order in which iSCSI boot servers are contacted is also left to the 299 discretion of the implementor. 301 Standards Track iSCSI BootStrapping Draft 25 July 2003 303 7. Boot stage 305 Once the iSCSI boot client has obtained the minimum information to 306 open an iSCSI session with the iSCSI boot server, the actual booting 307 process can start. 309 The actual sequence of iSCSI commands needed to complete the boot 310 process is left to the implementor. This was done because of varying 311 requirements from different vendors and equipment, making it 312 difficult to specify a common subset of the iSCSI standard that would 313 be acceptable to everybody. 315 The iSCSI session established for boot may be taken over by the 316 booted software in the iSCSI boot client. 318 8. Security Considerations 320 The security discussion is centered around securing the communication 321 involved in the iSCSI boot process. 323 However, the issue of applying credentials to a boot image loaded 324 through the iSCSI boot mechanism is outside the scope of this 325 document. One key difference between the iSCSI boot mechanism and 326 BOOTP-based image loading is the fact that the identity of a boot 327 image may not be known when the Boot stage starts. The identity of 328 certain boot images and their locations are known only after 329 examining the contents of a boot disk exposed by the iSCSI boot 330 service. Furthermore, images themselves may recursively load other 331 images based on both hardware configurations and user input. 332 Consequently, a practical way to verify loaded boot images is to make 333 sure that each image loading software verifies the image to be loaded 334 using a mechanism of their choice. 336 The considerations involved in designing a security architecture for 337 the iSCSI boot process include configuration, deployment and 338 provisioning issues apart from typical security considerations. 339 Enabling iSCSI boot creates a critical operational dependence on an 340 external system with obvious security implications, and thus 341 administrator awareness of such enablement is extremely important. 342 Therefore, iSCSI boot SHOULD NOT be enabled, or put high in the boot 343 order, without an explicit administrative action. 345 The software stage SHOULD NOT be involved in a secure iSCSI boot 346 process as this would add the additional complexity of trying to 347 secure the process of loading the software necessary to run the later 348 stages of iSCSI boot. Authentication and integrity protection of 349 downloaded boot software has proven to be difficult and complex due 351 Standards Track iSCSI BootStrapping Draft 25 July 2003 353 to administrative issues and limitations of the BIOS environment. It 354 is therefore assumed that all the necessary software is resident on 355 the iSCSI boot client. 357 If the DHCP stage is implemented, the iSCSI boot client SHOULD 358 implement the DHCP authentication ([Droms01], [Droms02] for IPv6). In 359 this case an administration interface SHOULD be provided for the 360 configuration of the DHCP authentication credentials, both when the 361 network interface is on the motherboard, and when it is removable. 362 Note that DHCP authentication ([Droms01],[Droms02] for IPv6) is 363 focused on intra-domain authentication, which is assumed to be enough 364 for iSCSI boot scenarios. In the context of the secure iSCSI boot 365 process, the reply from the DHCP server in the DHCP stage SHOULD 366 include the serverName in IPv4 (or IPv6) format to avoid reliance on 367 a DNS server (for resolving names) or a Discovery Service entity (to 368 look up targetnames). This reduces the number of entities involved in 369 the secure iSCSI boot process. 371 If the Discovery Service stage is implemented using SLP, the iSCSI 372 boot client SHOULD provide IPsec support (OPTIONAL to use) for the 373 SLP protocol, as defined in [Bakke02] and [Aboba03]. If the Discovery 374 Service stage is implemented using iSNS, the iSCSI boot client SHOULD 375 provide IPsec support (OPTIONAL to use) for the iSNS protocol, as 376 defined in [Tseng03] and [Aboba03]. When iSNS or SLP are used to 377 distribute security policy or configuration information, at a 378 minimum, per-packet data origin authentication, integrity and replay 379 protection SHOULD be used to protect the discovery protocol. 381 For the final communication between the iSCSI boot client and the 382 iSCSI boot server in the Boot stage, IPsec and in-band authentication 383 SHOULD be implemented according to the guidelines in the main iSCSI 384 draft [Satran02] and [Aboba03]. Due to memory constraints, it is 385 expected that iSCSI boot clients will only support the pre-shared key 386 authentication in IKE. Where the host IP address is assigned 387 dynamically, IKE main mode SHOULD NOT be used, as explained in 388 [Satran02] and [Aboba03]. Regardless of the way parameters in 389 previous stages (DHCP, SLP, iSNS) were obtained (securely or not), 390 the iSCSI boot session is vulnerable as any iSCSI session (see 391 [Satran02] and [Aboba03] for iSCSI security threats). Therefore 392 security for this session SHOULD be configured and used according to 393 [Satran02] and [Aboba03] guidelines. 395 Another point to be noted is that if a boot image inherits an iSCSI 396 session from a previously loaded boot image, the boot image also 397 inherits the security properties of the iSCSI session. 399 Acknowledgments 401 Standards Track iSCSI BootStrapping Draft 25 July 2003 403 We wish to thank John Hufferd for taking the initiative to form the 404 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 405 Bernard Aboba, David Robinson, Mark Bakke, Ofer Biran and Mallikarjun 406 Chadalapaka for helpful suggestions and pointers regarding the draft 407 document. 409 Normative References 411 [Aboba03] Aboba, S. et al. "Securing Block Storage Protocols over 412 IP", Work in Progress, January 2003. 414 [Alexander93] Alexander, S., and R. Droms, "DHCP Options and BOOTP 415 Vendor 416 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 417 University, October 1993. 419 [Bakke02] Bakke, M., et al. "Finding iSCSI Targets and Name Servers 420 using SLP", Work in Progress, March 2002. 422 [Braden89] Braden, R., "Requirements for Internet Hosts - Application 423 and Support", RFC 1123, October 1989. 425 [Bradner96] Bradner, S., "The Internet Standards Process -- 426 Revision 3", RFC 2026, October 1996. 428 [Bradner97] Bradner, S. "Key Words for use in RFCs to indicate 429 Requirement Levels", RFC 2119, Harvard University, March 1997. 431 [Croft85] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", 432 RFC 951, 433 Stanford and SUN Microsystems, September 1985. 435 [Droms93] Droms, D., "Interoperation between DHCP and BOOTP" RFC 436 1534, 437 Bucknell University, October 1993. 439 [Droms97] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 440 Bucknell University, March 1997. 442 [Droms01] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 443 RFC 3118, June 2001. 445 [Droms02] Droma, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 446 Carney, M., "Dynamic Host Configuration Protocol for IPv6", Work in 447 Progress, November 2002. 449 [Guttman99] Guttman, E., Perkins, C., Verizades, J., Day, M., 451 Standards Track iSCSI BootStrapping Draft 25 July 2003 453 "Service Location Protocol v2", RFC 2608, June 1999. 455 [Mockaopetris87] Mockaopertis, P., "Domain Names - Concepts and 456 Facilities", RFC 1034, November 1987. 458 [Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 459 1497, 460 USC/Information Sciences Institute, August 1993. 462 [Satran02] Satran, J. et al., "iSCSI", Work in Progress, September 463 2002. 465 [Tseng03] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., 466 Souza, J., "Internet Storage Name Service", Work in Progress, June 467 2003. 469 [Yergeau98] Yergeau, F., "UTF-8: A Transformation Format for 470 ISO-10646", RFC 2279, January 1998. 472 [Wimer93] Wimer, W., "Clarifications and Extensions for the Bootstrap 473 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 475 Informative References 477 [Brownell96] Brownell, D, "Dynamic RARP extensions for Automatic 478 Network Adress 479 Acquisition", RFC 1931, SUN Microsystems, April 1996. 481 [Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 482 Reverse 483 Address Resolution Protocol", RFC 903, Stanford, June 1984. 485 [Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, 486 NIC, 487 June 1981. 489 Authors' Addresses 491 Prasenjit Sarkar 492 IBM Almaden Research Center 493 650 Harry Road 494 San Jose, CA 95120, USA 495 Phone: +1 408 927 1417 496 Email: psarkar@almaden.ibm.com 498 Duncan Missimer 499 Brocade Communication Systems 501 Standards Track iSCSI BootStrapping Draft 25 July 2003 503 1745 Technology Drive, 504 San Jose, CA 95110, USA 505 Email: dmissime@brocade.com 507 Constantine Sapuntzakis 508 Stanford University 509 353 Serra Hall #406 510 Stanford, CA 94306, USA 511 Phone: +1 650 520 0205 512 Email: csapuntz@stanford.edu 514 Full Copyright Statement 516 "Copyright (C) The Internet Society (date). All Rights Reserved. This 517 document and translations of it may be copied and furnished to 518 others, and derivative works that comment on or otherwise explain it 519 or assist in its implementation may be prepared, copied, published 520 and distributed, in whole or in part, without restriction of any 521 kind, provided that the above copyright notice and this paragraph are 522 included on all such copies and derivative works. However, this 523 document itself may not be modified in any way, such as by removing 524 the copyright notice or references to the Internet Society or other 525 Internet organizations, except as needed for the purpose of 526 developing Internet standards in which case the procedures for 527 copyrights defined in the Internet Standards process must be 528 followed, or as required to translate it into languages other than 529 English. 531 The limited permissions granted above are perpetual and will not be 532 revoked by the Internet Society or its successors or assigns. 534 This document and the information contained herein is provided on an 535 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 536 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 537 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 538 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 539 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 541 Intellectual Property Rights 543 The IETF takes no position regarding the validity or scope of 544 any intellectual property or other rights that might be claimed 545 to pertain to the implementation or use of the technology 546 described in this document or the extent to which any license 547 under such rights might or might not be available; neither does 548 it represent that it has made any effort to identify any such 549 rights. Information on the IETF's procedures with respect to 551 Standards Track iSCSI BootStrapping Draft 25 July 2003 553 rights in standards-track and standards-related documentation 554 can be found in BCP-11. Copies of claims of rights made 555 available for publication and any assurances of licenses to 556 be made available, or the result of an attempt made 557 to obtain a general license or permission for the use of such 558 proprietary rights by implementors or users of this 559 specification can be obtained from the IETF Secretariat." 561 The IETF invites any interested party to bring to its 562 attention any copyrights, patents or patent applications, or 563 other proprietary rights which may cover technology that may be 564 required to practice this standard. Please address the 565 information to the IETF Executive Director.