RFC4173 日本語訳
4173 Bootstrapping Clients using the Internet Small Computer SystemInterface (iSCSI) Protocol. P. Sarkar, D. Missimer, C. Sapuntzakis. September 2005. (Format: TXT=27105 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Sarkar Request for Comments: 4173 IBM Category: Standards Track D. Missimer Hewlett-Packard Company C. Sapuntzakis Stanford University September 2005
コメントを求めるワーキンググループP.サルカールの要求をネットワークでつないでください: 4173年のIBMカテゴリ: 標準化過程D.Missimerヒューレット・パッカード会社C.Sapuntzakisスタンフォード大学2005年9月
Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
インターネットスモールコンピュータシステムインタフェース(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
インターネットSmallコンピュータSystem Interface(iSCSI)はTCPの上で作動するSmallコンピュータシステムズInterface(SCSI)のための提案されたトランスポート・プロトコルです。 このメモは、クライアントが自分たちを独力で進むのをiSCSIプロトコルを使用することで可能にするために標準のメカニズムについて説明します。 この規格の目標はiSCSIブーツクライアントがiSCSIブート・サーバーとのiSCSIセッションを開くために情報を得るのを可能にすることです。
1. Introduction
1. 序論
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.
SmallコンピュータシステムズInterface(SCSI)は入出力デバイスとコミュニケートするためのプロトコル、特に記憶装置のポピュラーなファミリーです。 SCSIは要求/応答メッセージング・プロトコルとして標準のアーキテクチャで特徴付けることができて、異なった装置クラスのためにコマンドセットをcomponentizedしました。
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はTCPの上で作動するSCSIのための提案されたトランスポート・プロトコルです。 iSCSIの役割はシステム内部連絡の共有されたバスから交換網までの発展によって必要とされます。 IPネットワークはiSCSIプロトコルへ道を開いて、SCSIを輸送する建築するのと性能必要条件を満たします。
Sarkar, et al. Standards Track [Page 1] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[1ページ]RFC4173iSCSI
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ブート・サーバーをクライアントを独力で進むのに必要である情報を得るためにステップについて説明して、すべての情報がまさしくその着手のときに利用可能であるというわけではないことは、可能です。
1.1. Keywords
1.1. キーワード
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[Bradner97]で説明されるように本書では解釈されることであるべきですか?
2. Requirements
2. 要件
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 Target Name。 (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. クライアントはユーザ介入(無人のパワーアップすることの間に現れるブーツのための)なしでブーツを完成できるべきです。 しかしながら、ユーザがブーツプロトコルのステージを迂回させるために値を入力するメカニズムがあるはずです。
Sarkar, et al. Standards Track [Page 2] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[2ページ]RFC4173iSCSI
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)が必要であるかもしれません。
3. Related Work
3. 関連仕事
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].
Dynamic RARP(DRARP)[Brownell96]で明らかに定義された拡大による逆アドレス解決プロトコル(RARP)[Finlayson84]は、ネットワーク・アドレス発見のその問題を訴えて、自動IPアドレス割当機構を含んでいます。 トリビアル・ファイル転送プロトコル(TFTP)[Sollins81]はブート・サーバーからブーツイメージの輸送に備えます。BOOTP[Croft85、Reynolds93、Wimer93]は設定情報の収集のための移送機構です。 また、BOOTPも広げることができます、そして、公式の拡大はいくつかの設定パラメータのために定義されました。 DHCPv4[Droms97、Droms93]とDHCPv6[Droms02]はホストがIPネットワークでダイナミックに構成されることになっている規格です。 Service Locationプロトコル(SLP)は、よりハイレベルにサービス[Guttman99]の位置に備えます。
4. Software Stage
4. ソフトウェアステージ
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創始者ソフトウェアをロードするのに使用されるかに関するどのブーツプロトコルがことである最終決定が作成者に任せることに注意してください。
5. DHCP Stage
5. DHCPステージ
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 Target PortのためのIP輸送終点はサーバをブートします。輸送がTCPであるなら、例えば、これはIPアドレスとTCPポートナンバーへの決心にTCPでした。 現在、TCPはiSCSIのために承認された唯一の輸送です。
Sarkar, et al. Standards Track [Page 3] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[3ページ]RFC4173iSCSI
- The eight-byte LUN structure identifying the Logical Unit within the iSCSI boot server.
- iSCSIブート・サーバーの中でLogical Unitを特定する8バイトのLUN構造。
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ブーツクライアントにすべての情報があるなら、ブーツクライアントは直接Bootステージに進むかもしれません。
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アドレス自動構成でそれを取得するかもしれません。 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.
別の方法でここで指定されない場合、クライアントIDやゲートウェイ情報などのBOOTPかDHCP分野が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:」 Root Pathオプションは現在、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>」: 「<プロトコル>」: 「<ポート>」: 「<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.
「ポート」という分野"servername"が「議定書を作っ」て、換算値が全くなければ、"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は.2セクション3.2URI Specification[Lee98][Hinden99]に概説された仕様に従わなければなりません。 また、許容されたキャラクタは同じ仕様のセクション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
「プロトコル」分野はトランスポート・プロトコルがiSCSIに使用されるIANAの承認されたストリングの10進表現です。 プロトコル分野がレフト・バンクであるなら、デフォルト値は想定されます。
Sarkar, et al. Standards Track [Page 4] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[4ページ]RFC4173iSCSI
"6" for TCP. The transport protocol MUST have been approved for use in iSCSI; currently, the only approved protocol is TCP.
「TCPのための6インチ。」 トランスポート・プロトコルは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ブート・サーバーが聴かれているポートの10進表現です。 指定されないなら、ポートはよく知られる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番号の16進表現です。 LUN分野が空白であるなら、LUN0は想定されます。 LUN分野が空白でないなら、表現を「-」によって切り離された4つの16進数字の4つのグループに分割しなければなりません。 9を超えたケタは、下側か大文字であるかもしれません。 そのような表現に関する例は4752-3A4F-6b7e-2F99でしょう。 簡潔にするために高々3先行ゼロ、(「0インチ) ケタは16進数字のどんなグループでも省略されるかもしれません」。 したがって、"LUN"表現6734-9-156f-127は6734-0009-156 f-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.
私たちが知っている限り、何も彼らのそれぞれのLUN0sとして数人の異なったSCSI創始者に数個の異なったLUsをエクスポートするのでSCSI目標を排除しないように、SCSI目標が異なったSCSI創始者のために異なったLU番号の付け方を提示できることに注意してください。
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 Nameです。 targetname分野の承認されたキャラクタはiSCSI String Profileドキュメント[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によって供給されるなら、その分野は、Boot段階(セクション7)でブート・サーバーに連絡するのに他の関連分野に関連して使用されます。 しかしながら、"servername"野原が供給されないなら、"targetname"分野はそして、他の関連分野(セクション6)に関連してディスカバリーService段階で使用されます。
6. Discovery Service Stage
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.
ディスカバリーServiceはSLPプロトコル[Guttman99、Bakke02]に基づくかもしれなくて、SLP Serviceかディレクトリエージェントの具体化です。 あるいはまた、ディスカバリーServiceはiSNSプロトコル[Tseng03]に基づくかもしれなくて、iSNS Serverの具体化です。
Sarkar, et al. Standards Track [Page 5] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[5ページ]RFC4173iSCSI
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 Target Concrete Service Type Templateの質問ストリング1を使用することでSLPディスカバリーServiceについて質問します、targetnameをIPアドレスとポートナンバーまで決議するためにiSCSI SLP相互作用ドキュメント[Bakke02]のセクション6.2で指定されるように。 あるいはまた、iSCSIブーツクライアントはDevice Attribute Queryと共に質問パラメタ[Tseng03]としてtargetnameでiSNSディスカバリーServiceについて質問するかもしれません。 いったんこれを得ると、iSCSIブーツクライアントはBootステージ(セクション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.
ディスカバリーServiceから得られたポートナンバーがDHCPステージから得るものと闘争するのは、可能です。 このような場合には、作成者には、Boot段階で両方のポートナンバーを試みるオプションがあります。
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 Target Concrete Service Type Templateの質問ひも4でSLPディスカバリーServiceについて質問するかもしれません、iSCSI SLP相互作用ドキュメント[Bakke02]のセクション6.2で指定されるように。 この質問、ServiceがiSCSIブート・サーバーのリストをもっているブーツクライアントに提供するSLPディスカバリーに対応して、ブーツクライアントはアクセサリーに許容されています。 あるいはまた、iSCSIブーツクライアントは、特定のディスカバリーDomainの目標が「戦利品-可能」[Tseng03]であるかどうか確かめるためにiSNSディスカバリーServiceについて質問できます。
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ブート・サーバーが連絡されるオーダーは作成者に任せます。
7. Boot Stage
7. 穂孕み期
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ブーツクライアントの起動させられたソフトウェアによって引き継がれるかもしれません。
Sarkar, et al. Standards Track [Page 6] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[6ページ]RFC4173iSCSI
8. Security Considerations
8. セキュリティ問題
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ベースのイメージローディングの1つの主要な違いはBootステージであるときに、ブーツイメージのアイデンティティが知られていないかもしれないという事実が始まるということです。 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ブーツSHOULD NOTは可能にされるか、または明白な管理動作なしでブーツオーダーを高く入れます。
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.
ソフトウェアステージSHOULD NOTが安全な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ブーツクライアントSHOULDは、DHCPが認証([Droms01]、IPv6のための[Droms02])であると実装します。 この場合、ネットワーク・インターフェースであるときに、DHCP認証資格証明書の構成に管理インタフェースSHOULDを提供して、マザーボードの上に両方があります。
Sarkar, et al. Standards Track [Page 7] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[7ページ]RFC4173iSCSI
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]、IPv6のための[Droms02])がイントラドメイン認証に焦点を合わせられることに注意してください。認証はiSCSIブーツシナリオに十分であると思われます。 安全なiSCSIの文脈では、DHCPステージSHOULDのDHCPサーバからのブートのプロセス、回答は、DNSサーバ(名前を決議するための)かディスカバリーService実体(targetnamesを見上げる)への信用を避けるためにIPv4(または、IPv6)形式でserverNameを含んでいます。 これは安全な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.
ディスカバリーServiceステージがSLPを使用することで実装されるなら、iSCSIブーツクライアントSHOULDはSLPプロトコルのサポート(使用へのOPTIONAL)をIPsecに供給します、[Bakke02]と[Aboba03]で定義されるように。 ディスカバリーServiceステージがiSNSを使用することで実装されるなら、iSCSIブーツクライアントSHOULDはiSNSプロトコルのサポート(使用へのOPTIONAL)をIPsecに供給します、[Tseng03]と[Aboba03]で定義されるように。 iSNSかSLPが使用されているときには、1パケットあたりのデータの最小限、発生源認証、保全、および反復操作による保護SHOULDで安全保障政策か設定情報を分配するのに、発見プロトコルを保護するのにおいて使用されてください。
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.
Bootステージ、IPsec、およびバンドにおける認証SHOULDにおけるiSCSIブーツクライアントとiSCSIブート・サーバーとの最終的なコミュニケーションに関しては、主なiSCSI草稿[Satran02]と[Aboba03]のガイドラインに従って、実装されてください。 メモリ規制のため、iSCSIブーツクライアントがIKEであらかじめ共有された主要な認証をサポートするだけであると予想されます。 ホストIPアドレスがダイナミックに割り当てられて、IKEの主なモードがSHOULD NOTであるところに、いてください。[Satran02]と[Aboba03]で説明されるように、使用されます。 または、前の段階(DHCP、SLP、iSNS)のパラメタを得た方法にかかわらず(しっかりと、)、iSCSIブーツセッションはどんなiSCSIセッションとしても被害を受け易いです(iSCSI軍事的脅威に関して[Satran02]と[Aboba03]を見てください)。 したがって、構成されていて、[Satran02]に従って使用されるこのセッションSHOULDと[Aboba03]ガイドラインのためのセキュリティ。
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.
iSCSIブーツチームを形成するイニシアチブを取って頂いて、ジョンHufferdに感謝申し上げます。 また、役立つ提案と指針について草稿ドキュメントに関してダグオーティス、ジュリアンSatran、バーナードAboba、デイビッド・ロビンソン、マーク・バッキー、オフェルBiran、およびMallikarjun Chadalapakaに感謝申し上げます。
Sarkar, et al. Standards Track [Page 8] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[8ページ]RFC4173iSCSI
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.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「IPの上でブロックストレージがプロトコルであると機密保護します」、RFC3723(2004年4月)。
[Alexander93] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[Alexander93] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年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] バッキー、M.、Hufferd、J.、Voruganti、K.、クルーガー、M.、およびT.スペリー、「Using Service Locationプロトコルバージョン2(SLPv2)でインターネットSmallコンピュータシステムズInterface(iSCSI)目標とName Serversを見つける」RFC4018(2005年4月)。
[Bakke04] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[Bakke04]バッキー、M.、「インターネットの小さいコンピュータ・システムインタフェース(iSCSI)名のためのストリングプロフィール」、RFC3722、2004年4月。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[Croft85] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[Croft85] 耕地とW.とJ.ギルモア、「プロトコルを独力で進んでください」、RFC951、1985年9月。
[Droms93] Droms, R., "Interoperation Between DHCP and BOOTP", RFC 1534, October 1993.
[Droms93]Droms、1993年10月のR.、「DHCPとBOOTPの間のInteroperation」RFC1534。
[Droms97] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[Droms97] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[Droms01] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[Droms01] DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年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.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[Guttman99] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[Guttman99] GuttmanとE.とパーキンスとC.とVeizades、J.とM.日、「サービス位置のプロトコル、バージョン2インチ、RFC2608、1999年6月。」
[Hinden99] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[Hinden99] Hinden、R.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
Sarkar, et al. Standards Track [Page 9] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[9ページ]RFC4173iSCSI
[Lee98] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[Lee98] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, August 1993.
[Reynolds93] レイノルズ、J.、「BOOTP売り主情報拡張子」、RFC1497、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.、メタンフェタミン、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、2004年4月。
[Tseng03] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, April 2005.
[Tseng03] ツェン、J.、ギボンズ、K.、Travostino、F.、Duレーニー、C.、およびJ.スザ、「インターネットストレージ名前サービス(iSNS)」、RFC4171 2005年4月。
[Yergeau98] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[Yergeau98]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[Wimer93] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[Wimer93]Wimer、W.、「明確化と拡大、プロトコルを独力で進んでください、」、RFC1542、10月1993日
Informative References
有益な参照
[Brownell96] Brownell, D., "Dynamic RARP Extensions for Automatic Network Address Acquisition", RFC 1931, April 1996.
[Brownell96] ブラウネル、D.、「自動ネットワーク・アドレス獲得のためのダイナミックなRARP拡張子」、RFC1931、1996年4月。
[Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[Finlayson84] フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」、STD38、RFC903、1984年6月。
[Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[Sollins81] Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年7月。
Sarkar, et al. Standards Track [Page 10] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[10ページ]RFC4173iSCSI
Authors' Addresses
作者のアドレス
Prasenjit Sarkar IBM Almaden Research Center 650 Harry Road San Jose, CA 95120, USA
PrasenjitサルカールIBMアルマデンResearch Center650ハリー・Roadサンノゼ、カリフォルニア 95120、米国
Phone: +1 408 927 1417 EMail: psarkar@almaden.ibm.com
以下に電話をしてください。 +1 1417年の408 927メール: psarkar@almaden.ibm.com
Duncan Missimer Hewlett-Packard Company 10955 Tantau Ave Cupertino, CA 95014, USA
Tantau Aveカルパチーノ、ダンカンMissimerヒューレット・パッカード社10955のカリフォルニア 95014、米国
EMail: duncan.missimer@ieee.org
メール: duncan.missimer@ieee.org
Constantine Sapuntzakis Stanford University 353 Serra Hall #407 Stanford, CA 94305, USA
カリフォルニア 94305、コンスタンティーヌSapuntzakisスタンフォード大学353のセラホール#407・スタンフォード(米国)
EMail: csapuntz@alum.mit.edu
メール: csapuntz@alum.mit.edu
Sarkar, et al. Standards Track [Page 11] RFC 4173 iSCSI Bootstrapping September 2005
サルカール、他 2005年9月に独力で進む標準化過程[11ページ]RFC4173iSCSI
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sarkar, et al. Standards Track [Page 12]
サルカール、他 標準化過程[12ページ]
一覧
スポンサーリンク