Network Working Group P. Sarkar
Request for Comments: 4173 IBM
Category: Standards Track D. Missimer
Hewlett-Packard Company
C. Sapuntzakis
Stanford University
September 2005
Network Working Group P. Sarkar
Request for Comments: 4173 IBM
Category: Standards Track D. Missimer
Hewlett-Packard Company
C. Sapuntzakis
Stanford University
September 2005
Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
使用Internet小型计算机系统接口（iSCSI）协议引导客户端
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server.
Internet小型计算机系统接口（iSCSI）是一种为小型计算机系统接口（SCSI）提出的传输协议，它在TCP之上运行。本备忘录描述了一种标准机制，用于使客户端能够使用iSCSI协议自行引导。本标准的目标是使iSCSI引导客户端能够获取信息，以打开与iSCSI引导服务器的iSCSI会话。
The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. SCSI can be characterized as a request/response messaging protocol with a standard architecture and componentized command sets for different device classes.
小型计算机系统接口（SCSI）是与I/O设备（尤其是存储设备）通信的一个流行协议系列。SCSI可以被描述为具有标准体系结构和针对不同设备类别的组件化命令集的请求/响应消息传递协议。
iSCSI is a proposed transport protocol for SCSI that operates on top of TCP. The role of iSCSI is necessitated by the evolution of the system interconnect from a shared bus to a switched network. IP networks meet the architectural and performance requirements of transporting SCSI, paving the way for the iSCSI protocol.
iSCSI是一种提议的SCSI传输协议，它在TCP之上运行。iSCSI的作用是由系统互连从共享总线发展到交换网络所必需的。IP网络满足传输SCSI的体系结构和性能要求，为iSCSI协议铺平了道路。
Many diskless clients sometimes bootstrap off remote SCSI devices. Such diskless entities are lightweight, space efficient, and power-conserving and are increasingly popular in various environments.
许多无盘客户机有时会引导远程SCSI设备。这种无盘实体具有轻量级、节省空间和节能的特点，在各种环境中越来越流行。
This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. It is possible that all the information is not available at the very outset, so the memo describes steps to obtain the information required to bootstrap clients off an iSCSI boot server.
本备忘录描述了一种标准机制，用于使客户端能够使用iSCSI协议自行引导。本标准的目标是使iSCSI引导客户端能够获取信息，以打开与iSCSI引导服务器的iSCSI会话。所有信息可能在一开始就不可用，因此备忘录介绍了获取从iSCSI引导服务器引导客户端所需信息的步骤。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Bradner97].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[Bradner97]中所述进行解释。
1. There must be no restriction of network topology between the iSCSI boot client and the boot server other than that in effect for establishing the iSCSI session. Consequently, it is possible for an iSCSI boot client to boot from an iSCSI boot server behind gateways or firewalls as long as it is possible to establish an iSCSI session between the client and the server.
1. iSCSI启动客户端和启动服务器之间不得存在任何网络拓扑限制，但用于建立iSCSI会话的网络拓扑限制除外。因此，只要能够在客户机和服务器之间建立iSCSI会话，iSCSI启动客户机就可以从网关或防火墙后面的iSCSI启动服务器启动。
2. The following represent the minimum information required for an iSCSI boot client to contact an iSCSI boot server: (a) the client's IP address (IPv6 or IPv4); (b) the server's iSCSI Target Name; and (c) mandatory iSCSI initiator capability.
2. 以下是iSCSI启动客户端联系iSCSI启动服务器所需的最低信息：（a）客户端的IP地址（IPv6或IPv4）；（b） 服务器的iSCSI目标名称；和（c）强制iSCSI启动器功能。
The above assume that the default LUN for the boot process is 0 and that the default port for the iSCSI boot server is the well-known iSCSI port [Satran02]. However, both may be overridden at the time of configuration.
以上假设引导过程的默认LUN为0，iSCSI引导服务器的默认端口为众所周知的iSCSI端口[Satran02]。但是，在配置时可能会覆盖这两者。
Additional information may be required at each stage of the boot process.
在引导过程的每个阶段都可能需要其他信息。
3. It is possible for the iSCSI boot client to have none of the above information or capability on starting.
3. iSCSI启动客户端在启动时可能不具备上述信息或功能。
4. The client should be able to complete boot without user intervention (for boots that occur during an unattended power-up). However, there should be a mechanism for the user to input values so as to bypass stages of the boot protocol.
4. 客户端应该能够在没有用户干预的情况下完成引导（对于无人值守的通电期间发生的引导）。但是，应该有一种机制供用户输入值，以便绕过引导协议的各个阶段。
5. Additional protocol software (for example, BOOTP or DHCP) may be necessary if the minimum information required for an iSCSI session is not provided.
5. 如果未提供iSCSI会话所需的最低信息，则可能需要其他协议软件（例如，BOOTP或DHCP）。
The Reverse Address Resolution Protocol (RARP) [Finlayson84] through the extensions defined in the Dynamic RARP (DRARP) [Brownell96] explicitly addresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [Sollins81] provides for transport of a boot image from a boot server. BOOTP [Croft85, Reynolds93, Wimer93] is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions have been defined for several configuration parameters. DHCPv4 [Droms97, Droms93] and DHCPv6 [Droms02] are standards by which hosts are to be dynamically configured in an IP network. The Service Location Protocol (SLP) provides for location of higher-level services [Guttman99].
反向地址解析协议（RARP）[Finlayson84]通过动态RARP（DRARP）[Brownell96]中定义的扩展明确解决了网络地址发现问题，并包括一个自动IP地址分配机制。普通文件传输协议（TFTP）[Sollins81]提供了从引导服务器传输引导映像的功能。BOOTP[Croft85，Reynolds93，Wimer93]是一种用于收集配置信息的传输机制。BOOTP也是可扩展的，并且已经为几个配置参数定义了官方扩展。DHCPv4[Droms97、Droms93]和DHCPv6[Droms02]是在IP网络中动态配置主机的标准。服务定位协议（SLP）提供了更高级别服务的定位[Guttman99]。
Some iSCSI boot clients may lack the resources to boot up with the mandatory iSCSI initiator capability. Such boot clients may choose to obtain iSCSI initiator software from a boot server. Currently, many established protocols allow such a service in order to enable clients to load software images. For example, BOOTP and DHCP servers have the capability to provide the locations of servers that can serve software images on requests from boot clients.
某些iSCSI启动客户端可能缺少使用强制iSCSI启动器功能启动的资源。此类引导客户端可以选择从引导服务器获取iSCSI启动器软件。目前，许多已建立的协议允许这样的服务，以便使客户端能够加载软件映像。例如，BOOTP和DHCP服务器能够提供服务器的位置，这些服务器可以根据启动客户机的请求提供软件映像。
Note that this document does not recommend any of the above protocols, and the final decision of which boot protocol is to be used to load iSCSI initiator software is left to the discretion of the implementor.
请注意，本文档不推荐上述任何协议，至于使用哪种引导协议来加载iSCSI启动器软件，则由实施者自行决定。
In order to use an iSCSI boot server, the following pieces of information are required for an ISCSI boot client.
要使用iSCSI引导服务器，iSCSI引导客户端需要以下信息。
- The IP address of the iSCSI boot client (IPv4 or IPv6)
- iSCSI启动客户端的IP地址（IPv4或IPv6）
- The IP transport endpoint for the iSCSI Target Port for the iSCSI boot server. If the transport is TCP, for example, this has to resolve to an IP address and a TCP port number. TCP is currently the only transport approved for iSCSI.
- iSCSI启动服务器的iSCSI目标端口的IP传输终结点。例如，如果传输是TCP，则必须解析为IP地址和TCP端口号。TCP是目前唯一批准用于iSCSI的传输。
- The eight-byte LUN structure identifying the Logical Unit within the iSCSI boot server.
- 八字节LUN结构，用于标识iSCSI启动服务器中的逻辑单元。
At boot time, all or none of this information may be stored in the iSCSI boot client. This section describes techniques for obtaining the required information via the DHCP stage. Otherwise, if the iSCSI boot client has all the information, the boot client may proceed directly to the Boot stage.
在启动时，所有或全部信息都可能存储在iSCSI启动客户端中。本节介绍通过DHCP阶段获取所需信息的技术。否则，如果iSCSI引导客户端拥有所有信息，则引导客户端可能会直接进入引导阶段。
An iSCSI boot client that does not know its IP address at power-on may acquire it via BOOTP or DHCP (v4 or v6), or via IPv6 address autoconfiguration. Please note that DHCP settings (such as the RA settings in DHCPv6) may prohibit the use of DHCP in distributing iSCSI boot information; in this case, the DHCP stage cannot be used.
开机时不知道其IP地址的iSCSI引导客户端可以通过BOOTP或DHCP（v4或v6）或IPv6地址自动配置获取IP地址。请注意，DHCP设置（如DHCPv6中的RA设置）可能会禁止在分发iSCSI启动信息时使用DHCP；在这种情况下，无法使用DHCP阶段。
Unless specified otherwise here, BOOTP or DHCP fields such as the client ID and gateway information are used in an identical way as applications other than iSCSI.
除非此处另有规定，否则BOOTP或DHCP字段（如客户端ID和网关信息）的使用方式与iSCSI以外的应用程序相同。
A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach its boot device. This is done using the variable-length option named Root Path [Alexander93, Reynolds93]. The use of the option field is reserved for iSCSI boot use by prefacing the string with "iscsi:". The Root Path option is not currently defined for DHCPv6; if the option is defined for DHCPv6 in the future, the use of the option as defined for iSCSI boot will apply.
BOOTP或DHCP服务器（v4或v6）可以指示iSCSI客户端如何访问其引导设备。这是使用名为Root Path的可变长度选项[Alexander93，Reynolds93]完成的。选项字段的使用保留为iSCSI引导使用，方法是在字符串前面加上“iSCSI:”。当前未为DHCPv6定义根路径选项；如果将来为DHCPv6定义了该选项，则将使用为iSCSI引导定义的选项。
The option field consists of an UTF-8 [Yergeau98] string. The string has the following composition:
选项字段由UTF-8[Yergeau98]字符串组成。该字符串具有以下组成：
"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>
"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>
The fields "servername", "port", "protocol", and "LUN" are OPTIONAL and should be left blank if there are no corresponding values. The "targetname" field is not optional and MUST be provided.
“服务器名”、“端口”、“协议”和“LUN”字段是可选字段，如果没有相应的值，则应保留为空。“targetname”字段不是可选字段，必须提供。
The "servername" is the name of iSCSI server and contains either a valid domain name, a literal IPv4 address, or a literal IPv6 address. The servername must follow the specifications outlined in Section 3.2.2 of the URI Specification [Lee98] [Hinden99]. The characters allowed must also conform to Section 2.2 of the same specification. Servername compression MUST NOT be used in this field.
“servername”是iSCSI服务器的名称，包含有效域名、文字IPv4地址或文字IPv6地址。servername必须遵循URI规范[Lee98][Hinden99]第3.2.2节中概述的规范。允许的字符还必须符合同一规范的第2.2节。此字段中不得使用Servername压缩。
The "protocol" field is the decimal representation of the IANA-approved string for the transport protocol to be used for iSCSI. If the protocol field is left bank, the default value is assumed to be
“协议”字段是IANA批准的用于iSCSI的传输协议字符串的十进制表示形式。如果协议字段为left bank，则假定默认值为
"6" for TCP. The transport protocol MUST have been approved for use in iSCSI; currently, the only approved protocol is TCP.
“6”表示TCP。传输协议必须已批准在iSCSI中使用；目前，唯一批准的协议是TCP。
The "port" is the decimal representation of the port on which the iSCSI boot server is listening. If not specified, the port defaults to the well-known iSCSI port [Satran02].
“端口”是iSCSI引导服务器正在侦听的端口的十进制表示形式。如果未指定，则端口默认为众所周知的iSCSI端口[Satran02]。
The "LUN" field is a hexadecimal representation of the LU number. If the LUN field is blank, then LUN 0 is assumed. If the LUN field is not blank, the representation MUST be divided into four groups of four hexadecimal digits, separated by "-". Digits above 9 may be either lower or upper case. An example of such a representation would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three leading zero ("0") digits MAY be omitted in any group of hexadecimal digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent to 6734-0009-156f-0127. Furthermore, trailing groups containing only the "0" digit MAY be omitted along with the preceding "-". So, the "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000. Other concise representations of the LUN field MUST NOT be used.
“LUN”字段是LU编号的十六进制表示形式。如果LUN字段为空，则假定LUN为0。如果LUN字段不是空的，则表示形式必须分为四组，每组四个十六进制数字，以“-”分隔。9以上的数字可以是小写或大写。4752-3A4F-6b7e-2F99是此类表示的一个示例。为简洁起见，在任何一组十六进制数字中，最多可省略三个前导零（“0”）位。因此，“LUN”表示6734-9-156f-127相当于6734-0009-156f-0127。此外，仅包含“0”位的尾随组可以与前面的“-”一起省略。因此，“LUN”表示4186-9相当于4186-0009-0000-0000。不得使用LUN字段的其他简明表示形式。
Note that SCSI targets are allowed to present different LU numberings for different SCSI initiators, so to our knowledge nothing precludes a SCSI target from exporting several different LUs to several different SCSI initiators as their respective LUN 0s.
请注意，允许SCSI目标为不同的SCSI启动器提供不同的LU编号，因此据我们所知，没有什么可以阻止SCSI目标将多个不同的LU作为各自的LUN 0导出到多个不同的SCSI启动器。
The "targetname" field is an iSCSI Name that is defined by the iSCSI standard [Satran02] to uniquely identify an iSCSI target. The approved characters in the targetname field are stated in the iSCSI String Profile document[Bakke04].
“targetname”字段是iSCSI标准[Satran02]定义的iSCSI名称，用于唯一标识iSCSI目标。targetname字段中批准的字符在iSCSI字符串配置文件文档[Bakke04]中有说明。
If the "servername" field is provided by BOOTP or DHCP, then that field is used in conjunction with other associated fields to contact the boot server in the Boot stage (Section 7). However, if the "servername" field is not provided, then the "targetname" field is then used in the Discovery Service stage in conjunction with other associated fields (Section 6).
如果“servername”字段是由BOOTP或DHCP提供的，那么该字段将与其他相关字段一起用于在引导阶段联系引导服务器（第7节）。但是，如果未提供“servername”字段，则“targetname”字段将在发现服务阶段与其他相关字段一起使用（第6节）。
This stage is required if the BOOTP or DHCP server (v4 or v6) is unaware of any iSCSI boot servers or if the BOOTP or DHCP server is unable to provide the minimum information required to connect to the iSCSI boot server, other than the targetname.
如果BOOTP或DHCP服务器（v4或v6）不知道任何iSCSI引导服务器，或者BOOTP或DHCP服务器无法提供连接到iSCSI引导服务器所需的最低信息（targetname除外），则需要此阶段。
The Discovery Service may be based on the SLP protocol [Guttman99, Bakke02] and is an instantiation of the SLP Service or Directory Agent. Alternatively, the Discovery Service may be based on the iSNS protocol [Tseng03] and is an instantiation of the iSNS Server.
发现服务可以基于SLP协议[Guttman99，Bakke02]，并且是SLP服务或目录代理的实例。或者，发现服务可以基于iSNS协议[Tseng03]，并且是iSNS服务器的实例。
The iSCSI boot client may have obtained the targetname of the iSCSI boot server in the DHCP stage (Section 5). In that case, the iSCSI boot client queries the SLP Discovery Service using query string 1 of the iSCSI Target Concrete Service Type Template, as specified in Section 6.2 of the iSCSI SLP interaction document [Bakke02], to resolve the targetname to an IP address and port number. Alternatively, the iSCSI boot client may query the iSNS Discovery Service with a Device Attribute Query with the targetname as the query parameter [Tseng03]. Once this is obtained, the iSCSI boot client proceeds to the Boot stage (Section 7).
iSCSI引导客户端可能已在DHCP阶段（第5节）获得iSCSI引导服务器的targetname。在这种情况下，iSCSI引导客户端使用iSCSI目标具体服务类型模板的查询字符串1查询SLP发现服务，如iSCSI SLP交互文档[Bakke02]第6.2节所述，以将targetname解析为IP地址和端口号。或者，iSCSI引导客户端可以使用设备属性查询来查询iSNS发现服务，查询参数为targetname[Tseng03]。获得此信息后，iSCSI引导客户端将进入引导阶段（第7节）。
It is possible that the port number obtained from the Discovery Service may conflict with the one obtained from the DHCP stage. In such a case, the implementor has the option to try both port numbers in the Boot stage.
从发现服务获得的端口号可能与从DHCP阶段获得的端口号冲突。在这种情况下，实现者可以选择在引导阶段尝试这两个端口号。
If the iSCSI boot client does not have any targetname information, the iSCSI boot client may then query the SLP Discovery Service with query string 4 of the iSCSI Target Concrete Service Type Template, as specified in Section 6.2 of the iSCSI SLP interaction document [Bakke02]. In response to this query, the SLP Discovery Service provides the boot client with a list of iSCSI boot servers the boot client is allowed to access. Alternatively, the iSCSI boot client can query the iSNS Discovery Service to verify if the targets in particular Discovery Domain are bootable [Tseng03].
如果iSCSI引导客户端没有任何targetname信息，则iSCSI引导客户端可以使用iSCSI目标具体服务类型模板的查询字符串4查询SLP发现服务，如iSCSI SLP交互文档[Bakke02]第6.2节所述。为响应此查询，SLP发现服务向引导客户端提供允许引导客户端访问的iSCSI引导服务器列表。或者，iSCSI引导客户端可以查询iSNS发现服务，以验证特定发现域中的目标是否可引导[Tseng03]。
If the list of iSCSI boot servers is empty, subsequent actions are left to the discretion of the implementor. Otherwise, the iSCSI boot client may contact any iSCSI boot server in the list. Moreover, the order in which iSCSI boot servers are contacted is also left to the discretion of the implementor.
如果iSCSI启动服务器列表为空，后续操作将由实施者自行决定。否则，iSCSI启动客户端可能会联系列表中的任何iSCSI启动服务器。此外，iSCSI启动服务器的联系顺序也由实施者自行决定。
Once the iSCSI boot client has obtained the minimum information to open an iSCSI session with the iSCSI boot server, the actual booting process can start.
一旦iSCSI引导客户端获得了打开与iSCSI引导服务器的iSCSI会话的最低信息，就可以开始实际的引导过程。
The actual sequence of iSCSI commands that are needed to complete the boot process is left to the implementor. This was done because of varying requirements from different vendors and equipment, making it difficult to specify a common subset of the iSCSI standard that would be acceptable to everybody.
完成引导过程所需的iSCSI命令的实际顺序留给实施者。之所以这样做，是因为不同供应商和设备的要求各不相同，因此很难指定每个人都能接受的iSCSI标准的通用子集。
The iSCSI session established for boot may be taken over by the booted software in the iSCSI boot client.
为启动而建立的iSCSI会话可由iSCSI启动客户端中的启动软件接管。
The security discussion is centered around securing the communication involved in the iSCSI boot process.
安全性讨论的中心是保护iSCSI启动过程中涉及的通信。
However, the issue of applying credentials to a boot image loaded through the iSCSI boot mechanism is outside the scope of this document. One key difference between the iSCSI boot mechanism and BOOTP-based image loading is the fact that the identity of a boot image may not be known when the Boot stage starts. The identity of certain boot images and their locations are known only after the contents of a boot disk exposed by the iSCSI boot service are examined. Furthermore, images themselves may recursively load other images based on both hardware configurations and user input. Consequently, a practical way to verify loaded boot images is to make sure that each image loading software verifies the image to be loaded using a mechanism of their choice.
但是，将凭据应用于通过iSCSI引导机制加载的引导映像的问题超出了本文档的范围。iSCSI启动机制和基于BOOTP的映像加载之间的一个关键区别是，启动阶段启动时，可能不知道启动映像的标识。只有在检查iSCSI引导服务公开的引导磁盘的内容后，才能知道某些引导映像的标识及其位置。此外，图像本身可以基于硬件配置和用户输入递归地加载其他图像。因此，验证加载的引导映像的一种实用方法是确保每个映像加载软件使用其选择的机制验证要加载的映像。
The considerations involved in designing a security architecture for the iSCSI boot process include configuration, deployment, and provisioning issues apart from typical security considerations. Enabling iSCSI boot creates a critical operational dependence on an external system with obvious security implications, and thus administrator awareness of this enablement is extremely important. Therefore, iSCSI boot SHOULD NOT be enabled or put high in the boot order without an explicit administrative action.
为iSCSI引导过程设计安全体系结构所涉及的注意事项包括配置、部署和资源调配问题，以及典型的安全注意事项。启用iSCSI引导会对外部系统造成严重的操作依赖性，这会带来明显的安全隐患，因此管理员了解此启用非常重要。因此，在没有明确的管理操作的情况下，不应启用iSCSI引导或将其置于引导顺序的高位。
In all phases of the boot process, a client must ensure that a server is authorized to send it certain information. This means that the authenticated identity of a server must have an authorization indication. A list of authorized servers can be pre-configured into a client, or the list can be downloaded in an authenticated form from a prior stage in the boot process.
在引导过程的所有阶段，客户机必须确保服务器有权向其发送特定信息。这意味着服务器的经过身份验证的标识必须具有授权指示。授权服务器的列表可以预先配置到客户机中，或者可以从引导过程的前一阶段以经过身份验证的形式下载该列表。
The software stage SHOULD NOT be involved in a secure iSCSI boot process, as this would add the additional complexity of trying to secure the process of loading the software necessary to run the later stages of iSCSI boot. Authentication and integrity protection of downloaded boot software has proven to be difficult and complex due to administrative issues and limitations of the BIOS environment. It is therefore assumed that all the necessary software is resident on the iSCSI boot client.
安全iSCSI引导过程中不应涉及软件阶段，因为这会增加尝试确保加载运行iSCSI引导后期阶段所需软件的过程安全的额外复杂性。由于BIOS环境的管理问题和限制，已证明下载的引导软件的身份验证和完整性保护既困难又复杂。因此，假设所有必需的软件都驻留在iSCSI引导客户端上。
If the DHCP stage is implemented using the DHCP protocol, the iSCSI boot client SHOULD implement the DHCP authentication ([Droms01], [Droms02] for IPv6). In this case, an administration interface SHOULD be provided for the configuration of the DHCP authentication credentials, both when the network interface is on the motherboard
如果使用DHCP协议实现DHCP阶段，iSCSI引导客户端应实现DHCP身份验证（[Droms01]，[Droms02]用于IPv6）。在这种情况下，当网络接口位于主板上时，应为DHCP身份验证凭据的配置提供管理接口
and when it is removable. Note that DHCP authentication ([Droms01],[Droms02] for IPv6) is focused on intra-domain authentication, which is assumed to be enough for iSCSI boot scenarios. In the context of the secure iSCSI boot process, the reply from the DHCP server in the DHCP stage SHOULD include the serverName in IPv4 (or IPv6) format to avoid reliance on a DNS server (for resolving names) or a Discovery Service entity (to look up targetnames). This reduces the number of entities involved in the secure iSCSI boot process.
当它是可移动的。请注意，DHCP身份验证（[Droms01]、[Droms02]用于IPv6）主要关注域内身份验证，这对于iSCSI引导场景来说已经足够了。在安全iSCSI引导过程的上下文中，DHCP阶段DHCP服务器的回复应包括IPv4（或IPv6）格式的服务器名，以避免依赖DNS服务器（用于解析名称）或发现服务实体（用于查找目标名称）。这减少了安全iSCSI引导过程中涉及的实体数量。
If the Discovery Service stage is implemented using SLP, the iSCSI boot client SHOULD provide IPsec support (OPTIONAL to use) for the SLP protocol, as defined in [Bakke02] and [Aboba03]. If the Discovery Service stage is implemented using iSNS, the iSCSI boot client SHOULD provide IPsec support (OPTIONAL to use) for the iSNS protocol, as defined in [Tseng03] and [Aboba03]. When iSNS or SLP are used to distribute security policy or configuration information, at a minimum, per-packet data origin authentication, integrity, and replay protection SHOULD be used to protect the discovery protocol.
如果发现服务阶段是使用SLP实现的，则iSCSI引导客户端应按照[Bakke02]和[Aboba03]中的定义，为SLP协议提供IPsec支持（可选）。如果发现服务阶段是使用iSNS实现的，则iSCSI引导客户端应为iSNS协议提供IPsec支持（可选使用），如[Tseng03]和[Aboba03]中所定义。当使用iSNS或SLP分发安全策略或配置信息时，至少应使用每包数据源身份验证、完整性和重播保护来保护发现协议。
For the final communication between the iSCSI boot client and the
iSCSI boot server in the Boot stage, IPsec and in-band authentication
SHOULD be implemented according to the guidelines in the main iSCSI
draft [Satran02] and [Aboba03]. Due to memory constraints, it is
expected that iSCSI boot clients will only support the pre-shared key
authentication in IKE. Where the host IP address is assigned
dynamically, IKE main mode SHOULD NOT be used, as explained in
[Satran02] and [Aboba03]. Regardless of the way parameters in
previous stages (DHCP, SLP, iSNS) were obtained (securely or not),
the iSCSI boot session is vulnerable as any iSCSI session (see
[Satran02] and [Aboba03] for iSCSI security threats). Therefore,
security for this session SHOULD be configured and used according to
[Satran02] and [Aboba03] guidelines.
For the final communication between the iSCSI boot client and the
iSCSI boot server in the Boot stage, IPsec and in-band authentication
SHOULD be implemented according to the guidelines in the main iSCSI
draft [Satran02] and [Aboba03]. Due to memory constraints, it is
expected that iSCSI boot clients will only support the pre-shared key
authentication in IKE. Where the host IP address is assigned
dynamically, IKE main mode SHOULD NOT be used, as explained in
[Satran02] and [Aboba03]. Regardless of the way parameters in
previous stages (DHCP, SLP, iSNS) were obtained (securely or not),
the iSCSI boot session is vulnerable as any iSCSI session (see
[Satran02] and [Aboba03] for iSCSI security threats). Therefore,
security for this session SHOULD be configured and used according to
[Satran02] and [Aboba03] guidelines.
Note that if a boot image inherits an iSCSI session from a previously loaded boot image, it also inherits the security properties of the iSCSI session.
请注意，如果引导映像从以前加载的引导映像继承iSCSI会话，则它也会继承iSCSI会话的安全属性。
Acknowledgements
致谢
We wish to thank John Hufferd for taking the initiative to form the iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, Bernard Aboba, David Robinson, Mark Bakke, Ofer Biran, and Mallikarjun Chadalapaka for helpful suggestions and pointers regarding the draft document.
我们要感谢John Hufferd主动组建iSCSI启动团队。我们还要感谢Doug Otis、Julian Satran、Bernard Aboba、David Robinson、Mark Bakke、Ofer Biran和Mallikarjun Chadalapaka就文件草案提出了有益的建议和建议。
Normative References
规范性引用文件
[Aboba03] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[Aboba03]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[Alexander93] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[Alexander93]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[Bakke02] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)", RFC 4018, April 2005.
[Bakke02]Bakke，M.，Hufferd，J.，Voruganti，K.，Krueger，M.，和T.Sperry，“通过使用服务位置协议版本2（SLPv2）查找Internet小型计算机系统接口（iSCSI）目标和命名服务器”，RFC 4018，2005年4月。
[Bakke04] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[Bakke04]Bakke，M.，“互联网小型计算机系统接口（iSCSI）名称的字符串配置文件”，RFC 3722，2004年4月。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Croft85] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[Croft85]Croft，W.和J.Gilmore，“引导协议”，RFC 9511985年9月。
[Droms93] Droms, R., "Interoperation Between DHCP and BOOTP", RFC 1534, October 1993.
[Droms93]Droms，R.，“DHCP和BOOTP之间的互操作”，RFC 1534，1993年10月。
[Droms97] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[Droms97]Droms，R.，“动态主机配置协议”，RFC 21311997年3月。
[Droms01] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[Droms01]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[Droms02] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[Droms02]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33151003年7月。
[Guttman99] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[Guttman 99]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[Hinden99] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[Hinden99]Hinden，R.，Carpenter，B.，和L.Masinter，“URL中文字IPv6地址的格式”，RFC 2732，1999年12月。
[Lee98] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[Lee98]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, August 1993.
[Reynolds93]Reynolds，J.，“BOOTP供应商信息扩展”，RFC 1497，1993年8月。
[Satran02] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[Satran02]Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[Tseng03] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, April 2005.
[Tseng 03]Tseng，J.，Gibbons，K.，Travostino，F.，Du Laney，C.，和J.Souza，“互联网存储名称服务（iSNS）”，RFC 41712005年4月。
[Yergeau98] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[Yergeau98]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[Wimer93] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[Wimer93]Wimer，W.“引导协议的澄清和扩展”，RFC 1542，1993年10月。
Informative References
资料性引用
[Brownell96] Brownell, D., "Dynamic RARP Extensions for Automatic Network Address Acquisition", RFC 1931, April 1996.
[Brownell96]Brownell，D.，“用于自动网络地址获取的动态RARP扩展”，RFC 19311996年4月。
[Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[Finlayson84]Finlayson，R.，Mann，T.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，1984年6月。
[Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[Sollins81]Sollins，K.，“TFTP协议（修订版2）”，STD 33，RFC 1350，1992年7月。
Authors' Addresses
作者地址
Prasenjit Sarkar IBM Almaden Research Center 650 Harry Road San Jose, CA 95120, USA
美国加利福尼亚州圣何塞哈里路650号Prasenjit Sarkar IBM Almaden研究中心，邮编95120
Phone: +1 408 927 1417
EMail: psarkar@almaden.ibm.com
Phone: +1 408 927 1417
EMail: psarkar@almaden.ibm.com
Duncan Missimer Hewlett-Packard Company 10955 Tantau Ave Cupertino, CA 95014, USA
Duncan Missimer惠普公司美国加利福尼亚州库珀蒂诺坦托大道10955号，邮编95014
EMail: duncan.missimer@ieee.org
EMail: duncan.missimer@ieee.org
Constantine Sapuntzakis Stanford University 353 Serra Hall #407 Stanford, CA 94305, USA
康斯坦丁·萨潘扎基斯斯坦福大学353 Serra Hall#407斯坦福，加利福尼亚州94305，美国
EMail: csapuntz@alum.mit.edu
EMail: csapuntz@alum.mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。