Network Working Group M. Bakke
Request for Comments: 3721 Cisco
Category: Informational J. Hafner
J. Hufferd
K. Voruganti
IBM
M. Krueger
Hewlett-Packard
April 2004
Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.
iSCSIイニシエータによって;（TCP上またはSCSIのiSCSI）名の建設とiSCSIリソース（ターゲット）の発見の議論をこのドキュメントはインターネット小型コンピュータシステムインタフェースの例を提供します。この文書では、iSCSIプロトコルの文書を補完します。柔軟性は、このドキュメントの後ろのキー案内原理です。それは、努力は、セキュア/スケーラブルなソリューションを必要とする小さな孤立した環境、ならびに大規模な環境の両方のニーズを満たすためになされたものでれます。
Table of Contents
目次
1. iSCSI Names and Addresses. . . . . . . . . . . . . . . . . . . 3
1.1. Constructing iSCSI names using the iqn. format . . . . . 5
1.2. Constructing iSCSI names using the eui. format . . . . . 8
2. iSCSI Alias. . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Purpose of an Alias. . . . . . . . . . . . . . . . . . . 8
2.2. Target Alias . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Initiator Alias. . . . . . . . . . . . . . . . . . . . . 10
3. iSCSI Discovery. . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A: iSCSI Naming Notes. . . . . . . . . . . . . . . . . . 15
Appendix B: Interaction with Proxies and Firewalls. . . . . . . . 16
B.1. Port Redirector . . . . . . . . . . . . . . . . 16
B.2. SOCKS server. . . . . . . . . . . . . . . . . . 17
B.3. SCSI gateway. . . . . . . . . . . . . . . . . . 17
B.4. iSCSI Proxy . . . . . . . . . . . . . . . . . . 18
B.5. Stateful Inspection Firewall. . . . . . . . . . 18
Appendix C: iSCSI Names and Security Identifiers. . . . . . . . . 19
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 22
The main addressable, discoverable entity in iSCSI is an iSCSI Node. An iSCSI node can be either an initiator, a target, or both. The rules for constructing an iSCSI name are specified in [RFC3720].
iSCSIの中にメインのアドレス指定可能、検出可能実体は、iSCSIノードです。 iSCSIノードは、イニシエータ、ターゲット、またはその両方のいずれかであり得ます。 iSCSI名を構築するための規則は[RFC3720]で指定されています。
This document provides examples of name construction that might be used by a naming authority.
この文書では、命名機関によって使用されるかもしれない名前の構築の例を示します。
Both targets and initiators require names for the purpose of identification, so that iSCSI storage resources can be managed regardless of location (address). An iSCSI name is the unique identifier for an iSCSI node, and is also the SCSI device name [SAM2] of an iSCSI device. The iSCSI name is the principal object used in authentication of targets to initiators and initiators to targets. This name is also used to identify and manage iSCSI storage resources.
iSCSIストレージリソースに関係なく位置（アドレス）を管理することができるように、ターゲットとイニシエータの両方が、特定の目的の名前を必要とします。 iSCSI名は、iSCSIノードの一意の識別子であり、また、iSCSIデバイスのSCSIデバイス名[SAM2]です。 iSCSI名は、ターゲットへのイニシエータとイニシエータとターゲットの認証に使用される主要な目的です。この名前は、iSCSIストレージリソースを特定し、管理するために使用されます。
Furthermore, iSCSI names are associated with iSCSI nodes instead of with network adapter cards to ensure the free movement of network HBAs between hosts without loss of SCSI state information (reservations, mode page settings etc) and authorization configuration.
また、iSCSI名はSCSI状態情報（予約、モード・ページの設定など）及び許可の設定を失うことなくホスト間のネットワークのHBAの自由な移動を確保するためのiSCSIノードとの代わりに、ネットワークアダプタカードに関連付けられています。
An iSCSI node also has one or more addresses. An iSCSI address specifies a single path to an iSCSI node and consists of the iSCSI name, plus a transport (TCP) address which uses the following format:
iSCSIノードはまた、1つ以上のアドレスを持っています。 iSCSIのアドレスがiSCSIノードへの単一のパスを指定し、iSCSI名で構成され、加えて、次の形式を使用してトランスポート（TCP）アドレス：
<domain-name>[:<port>]
<ドメイン名> [：<ポート>]
Where <domain-name> is one of:
ここで、<ドメイン名>のいずれかです。
- IPv4 address, in dotted decimal notation. Assumed if the name contains exactly four numbers, separated by dots (.), where each number is in the range 0..255.
- IPv4アドレスドット付き10進表記です。名前は、ドットで区切られ、正確に4つの数字が含まれている場合に想定（。）、各数値範囲0..255です。
- IPv6 address, in colon-separated hexadecimal notation, as specified in [RFC3513] and enclosed in "[" and "]" characters, as specified in [RFC2732].
- IPv6アドレス、コロンで区切られた16進数で、[RFC3513]で指定し、[RFC2732]で指定されるように、「[」と「]」文字で囲まれています。
- Fully Qualified Domain Name (host name). Assumed if the <domain-name> is neither an IPv4 nor an IPv6 address.
- 完全修飾ドメイン名（ホスト名）。 <ドメイン名>は、IPv4やIPv6アドレスでもない場合を想定。
For iSCSI targets, the <port> in the address is optional; if specified, it is the TCP port on which the target is listening for connections. If the <port> is not specified, the default port 3260, assigned by IANA, will be assumed. For iSCSI initiators, the <port> is omitted.
iSCSIターゲットの場合は、アドレスで、<port>はオプションです。指定された場合、それは、ターゲットが接続を監視しているTCPポートです。 <ポート>は、IANAによって割り当てられ、デフォルトのポート3260、指定されていない場合は、想定されます。 iSCSIイニシエータの場合は、<port>は省略されています。
Examples of addresses:
アドレスの例：
192.0.2.2 192.0.2.23:5003 [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] [1080:0:0:0:8:800:200C:417A] [3ffe:2a00:100:7031::1] [1080::8:800:200C:417A] [1080::8:800:200C:417A]:3260 [::192.0.2.5] mydisks.example.com moredisks.example.com:5003
192.0.2.2 192.0.2.23:5003 [FEDC：BA98：3210：7654 FEDC：BA98：7654：3210] [1080：800：0：0：0：8 200C：417A] [3FFE：2a00：7031：100 :: 1]〜[1080 :: 8：800：200C：417A] [1080 :: 8：800：200C：417A]：3260 [:: 192.0.2.5] mydisks.example.com moredisks.example.com:5003
The concepts of names and addresses have been carefully separated in iSCSI:
名前とアドレスの概念は慎重にiSCSIの中で分離されています：
- An iSCSI Name is a location-independent, permanent identifier for an iSCSI node. An iSCSI node has one iSCSI name, which stays constant for the life of the node. The terms "initiator name" and "target name" also refer to an iSCSI name.
- iSCSI名は、iSCSIノードの位置に依存しない、永久的な識別子です。 iSCSIノードは、ノードの人生のために一定のまま1人のiSCSI名を、持っています。用語「イニシエータ名」と「ターゲット名」には、iSCSI名を参照してください。
- An iSCSI Address specifies not only the iSCSI name of an iSCSI node, but also a location of that node. The address consists of a host name or IP address, a TCP port number (for the target), and the iSCSI Name of the node. An iSCSI node can have any number of addresses, which can change at any time, particularly if they are assigned via DHCP.
- iSCSIのアドレスは、iSCSIノードのiSCSI名、だけでなく、そのノードの位置だけでなく、指定します。アドレスは、ノードのホスト名またはIPアドレス、（ターゲットの）TCPポート番号、およびiSCSI名で構成されています。 iSCSIノードは、それらがDHCP経由で割り当てられている場合は特に、いつでも変更することができ、任意の数のアドレスを持つことができます。
A similar analogy exists for people. A person in the USA might be:
同様のアナロジーは人のために存在します。アメリカの人は次のようになります。
Robert Smith SSN+DateOfBirth: 333-44-5555 14-MAR-1960 Phone: +1 (763) 555.1212 Home Address: 555 Big Road, Minneapolis, MN 55444 Work Address: 222 Freeway Blvd, St. Paul, MN 55333
ロバート・スミスSSN + dateOfBirthの：333-44-5555 14-MAR-1960電話：+1（763）555.1212ホーム住所：555ビッグロード、ミネアポリス、MN 55444勤務先住所：222フリーウェイブールバード、セントポール、ミネソタ55333
In this case, Robert's globally unique name is really his Social Security Number plus Date of Birth. His common name, "Robert Smith", is not guaranteed to be unique. Robert has three locations at which he may be reached; two Physical addresses, and a phone number.
この場合は、ロバートのグローバルに一意の名前が本当に彼の社会保障番号プラス誕生日です。彼の一般的な名前は、「ロバート・スミス」は一意であることが保証されていません。ロバートは、彼が到達される場合の3つの拠点を持っています。 2つの物理アドレス、電話番号。
In this example, Robert's SSN+DOB is like the iSCSI Name (date of birth is required to disambiguate SSNs that have been reused), his phone number and addresses are analogous to an iSCSI node's TCP addresses, and "Robert Smith" would be a human-friendly label for this person.
この例では、ロバートのSSN + DOBは、iSCSI名のようなものです（生年月日が再利用されているのSSNを明確にするために必要です）、彼の電話番号とアドレスがiSCSIノードのTCPアドレスに類似しており、「ロバート・スミス」になりますこの人のために人に優しいラベル。
To assist in providing a more human-readable user interface for devices that contain iSCSI targets and initiators, a target or initiator may also provide an alias. This alias is a simple UTF-8 string, is not globally unique, and is never interpreted or used to identify an initiator or device within the iSCSI protocol. Its use is described further in section 2.
iSCSIターゲットとイニシエータを含むデバイスのためのより多くの人間が読み取り可能なユーザインタフェースを提供するのを助けるために、ターゲットまたはイニシエータはまた、エイリアスを提供することができます。このエイリアスは、簡単なUTF-8文字列で、グローバルに一意ではない、と解釈されない、またはiSCSIプロトコル内イニシエータまたはデバイスを識別するために使用されません。その使用は、セクション2にさらに記載されています。
The iSCSI naming scheme was constructed to give an organizational naming authority the flexibility to further subdivide the responsibility for name creation to subordinate naming authorities. The iSCSI qualified name format is defined in [RFC3720] and contains (in order):
iSCSIの命名スキームは、組織の命名機関にさらに下位の命名当局に名を作成するための責任を細分化するための柔軟性を与えるために構築しました。 iSCSI修飾名の形式は、[RFC3720]で定義されており、（順番に）含まれています。
- The string "iqn."
- 文字列 "IQN。"
- A date code specifying the year and month in which the organization registered the domain or sub-domain name used as the naming authority string.
- 組織が命名機関の文字列として使用されるドメインまたはサブドメイン名を登録した年と月を指定する日付コード。
- The organizational naming authority string, which consists of a valid, reversed domain or subdomain name.
- 有効な、逆のドメインまたはサブドメイン名で構成され、組織の命名機関列、。
- Optionally, a ':', followed by a string of the assigning organization's choosing, which must make each assigned iSCSI name unique.
- 必要に応じて、A「：」、それぞれ割り当てられたiSCSI名を一意にする必要があります割り当てる組織の選んだ、の文字列が続きます。
The following is an example of an iSCSI qualified name from an equipment vendor:
以下は、機器ベンダーからのiSCSI修飾名の例です。
Organizational Subgroup Naming Authority
Naming and/or string Defined by
Type Date Auth Org. or Local Naming Authority
+--++-----+ +---------+ +--------------------------------+
| || | | | | |
iqn.2001-04.com.example:diskarrays-sn-a8675309
iqn.2001-04.com.example：diskarrays-すぐ-a8675309
Where:
どこ：
"iqn" specifies the use of the iSCSI qualified name as the authority.
「IQNは」権威としてiSCSI修飾名の使用を指定します。
"2001-04" is the year and month on which the naming authority acquired the domain name used in this iSCSI name. This is used to ensure that when domain names are sold or transferred to another organization, iSCSI names generated by these organizations will be unique.
「2001-04は、」命名機関は、このiSCSI名で使用されるドメイン名を取得した上で年と月です。これは、ドメイン名を販売または別の組織に転送されたときに、これらの組織によって生成されたiSCSI名が一意であることを保証するために使用されます。
"com.example" is a reversed DNS name, and defines the organizational naming authority. The owner of the DNS name "example.com" has the sole right of use of this name as this part of an iSCSI name, as well as the responsibility to keep the remainder of the iSCSI name unique. In this case, example.com happens to manufacture disk arrays.
「com.exampleは」逆転DNS名であり、組織の命名権限を定義します。 DNS名「example.com」の所有者は、固有のiSCSI名の残りの部分を維持するiSCSI名のこの部分だけでなく、責任として、この名前を使用することの唯一の権利を有します。この場合、example.comは、ディスクアレイを製造するために起こります。
"diskarrays" was picked arbitrarily by example.com to identify the disk arrays they manufacture. Another product that ACME makes might use a different name, and have its own namespace independent of the disk array group. The owner of "example.com" is responsible for keeping this structure unique.
「diskarrays」は、それらが製造するディスクアレイを識別するために、example.comが任意に選ばれました。 ACMEが行う他の製品には、別の名前を使用し、ディスクアレイグループの独自の名前空間から独立している可能性があります。 「example.com」の所有者は、ユニークなこの構造を維持する責任があります。
"sn" was picked by the disk array group of ACME to show that what follows is a serial number. They could have just assumed that all iSCSI Names are based on serial numbers, but they thought that perhaps later products might be better identified by something else. Adding "sn" was a future-proof measure.
「SN」は次にくるものがシリアル番号であることを示すために、ACMEのディスクアレイグループによって選ばれました。彼らはただ、すべてのiSCSI名をシリアル番号に基づいていることを想定している可能性が、彼らはおそらく、後の製品は、より良い何か他のものによって識別されるかもしれないと思いました。 「SN」を追加すると、将来を見据えた措置でした。
"a8675309" is the serial number of the disk array, uniquely identifying it from all other arrays.
「a8675309」が一意に他のすべての配列からそれを識別する、ディスクアレイのシリアル番号です。
Another example shows how the ':' separator helps owners of sub-domains to keep their name spaces unique:
別の例は、方法を示して「：」セパレータは、サブドメインの所有者はユニークな彼らの名前空間を維持するのに役立ちます：
Naming Defined by
Type Date Authority Naming Authority
+--++-----+ +-----------------+ +-----------+
| || | | | | |
iqn.2001-04.com.example.storage:tape.sys1.xyz
いｑん。２００１ー０４。こｍ。えぁｍｐぇ。ｓとらげ：たぺ。ｓｙｓ１。ｘｙｚ
Naming Defined by
Type Date Authority Naming Authority
+--++-----+ +----------------------+ +-----------+
| || | | | | |
iqn.2001-04.com.example.storage.tape:sys1.xyz
iqn.2001-04.com.example.storage.tape：sys1.xyz
Note that, except for the ':' separator, both names are identical. The first was assigned by the owner of the subdomain "storage.example.com"; the second was assigned by the owner of "tape.storage.example.com". These are both legal names, and are unique.
「：」を除き、なお、セパレータ、両方の名前は同じです。最初のサブドメイン「storage.example.com」の所有者によって割り当てられていました。第二は、「tape.storage.example.com」の所有者によって割り当てられました。これらは、両方の法的名で、ユニークです。
The following is an example of a name that might be constructed by a research organization:
以下は、研究機関によって構築されるかもしれない名前の例です。
Naming Defined by Defined by
Type Date Authority cs dept User "oaks"
+-+ +-----+ +------------+ +--------+ +-----------+
| | | | | | | | | |
iqn.2000-02.edu.example.cs:users.oaks:proto.target4
In the above example, Professor Oaks of Example University is building research prototypes of iSCSI targets. EU's computer science department allows each user to use his or her user name as a naming authority for this type of work, by attaching "users.<username>" after the ':', and another ':', followed by a string of the user's choosing (the user is responsible for making this part unique). Professor Oaks chose to use "proto.target4" for this particular target.
上記の例では、例大学の教授オークスは、iSCSIターゲットの研究プロトタイプを構築しています。 、および他：「」EUのコンピュータサイエンス部門は後に「<ユーザー名>のユーザーを」各ユーザが装着することにより、この種の作業のための命名権威として自分のユーザー名を使用することができます「：」の文字列が続きますユーザーが選択（ユーザーが独自のこの部分を作るための責任があります）。教授オークスは、この特定のターゲットに対して、「proto.target4」を使用することにしました。
The following is an example of an iSCSI name string from a storage service provider:
以下は、ストレージサービスプロバイダからのiSCSI名の文字列の例です。
Organization String
Naming Defined by Org.
Type Date Authority Naming Authority
+-+ +-----+ +-------------+ +----------------------+
| | | | | | | |
iqn.1995-11.com.example.ssp:customers.4567.disks.107
In this case, a storage service provider (ssp.example.com) has decided to re-name the targets from the manufacturer, to provide the flexibility to move the customer's data to a different storage subsystem should the need arise.
この場合、ストレージサービスプロバイダ（ssp.example.com）は、必要が生じた場合、異なるストレージ・サブシステムへの顧客のデータを移動するための柔軟性を提供するために、メーカーからの目標を再指名することを決定しました。
The Storage Service Provider (SSP) has configured the iSCSI Name on this particular target for one of its customers, and has determined that it made the most sense to track these targets by their Customer ID number and a disk number. This target was created for use by customer #4567, and is the 107th target configured for this customer.
ストレージサービスプロバイダ（SSP）は、顧客のいずれかのこの特定のターゲットのiSCSI名を設定している、それは彼らの顧客ID番号とディスク番号によってこれらの目標を追跡するために、最も理にかなっていることを決定しました。この目標は、顧客＃4567で使用するために作成され、この顧客のために構成された第107回の目標ですました。
Note that when reversing these domain names, the first component (after the "iqn.") will always be a top-level domain name, which includes "com", "edu", "gov", "org", "net", "mil", or one of the two-letter country codes. The use of anything else as the first component of these names is not allowed. In particular, companies generating these names must not eliminate their "com." from the string.
これらのドメイン名を逆に、最初のコンポーネントがあります（後の「IQN。」）常に「COM」、「EDU」、「GOV」が含まれるトップレベルドメイン名になります、「組織」、「ネット」 、「ミル」、または2文字の国コードのいずれか。これらの名前の最初のコンポーネントとして、何か他の使用が許可されていません。特に、これらの名前を生成する企業は、「COM」を排除してはなりません文字列から。
Again, these iSCSI names are NOT addresses. Even though they make use of DNS domain names, they are used only to specify the naming authority. An iSCSI name contains no implications of the iSCSI target or initiator's location. The use of the domain name is only a method of re-using an already ubiquitous name space.
ここでも、これらのiSCSI名は、アドレスではありません。彼らはDNSドメイン名を利用するにもかかわらず、それらが命名機関を指定するためにのみ使用されます。 iSCSI名は、iSCSIターゲットまたはイニシエータの場所のない意味合いが含まれていません。ドメイン名の使用は、すでにユビキタスネームスペースを再利用する方法です。
The iSCSI eui. naming format allows a naming authority to use IEEE EUI-64 identifiers in constructing iSCSI names. The details of constructing EUI-64 identifiers are specified by the IEEE Registration Authority (see [EUI64]).
iSCSI EUI。命名フォーマットは、iSCSI名を構築する上でIEEE EUI-64識別子を使用するネーミング権限を許可します。 EUI64識別子を構築するの詳細はIEEE登録機関によって指定されます（[EUI64]を参照）。
Example iSCSI name:
例iSCSI名：
Type EUI-64 identifier (ASCII-encoded hexadecimal)
+--++--------------+
| || |
eui.02004567A425678D
The iSCSI alias is a UTF-8 text string that may be used as an additional descriptive name for an initiator and target. This may not be used to identify a target or initiator during login, and does not have to follow the uniqueness or other requirements of the iSCSI name. The alias strings are communicated between the initiator and target at login, and can be displayed by a user interface on either end, helping the user tell at a glance whether the initiators and/or targets at the other end appear to be correct. The alias must NOT be used to identify, address, or authenticate initiators and targets.
iSCSIエイリアスは、イニシエータとターゲットのための追加の記述名として使用することができるUTF-8文字列です。これは、ログイン時にターゲットまたはイニシエータを識別するために使用することはできません、とiSCSI名の一意性やその他の要件に従う必要はありません。エイリアスの文字列は、ログイン時に、イニシエータとターゲットの間で通信され、他端にイニシエータおよび/またはターゲットが正しいように見えるかどうかをユーザーが一目でわかり支援し、どちらかの端に、ユーザインターフェースで表示することができます。エイリアスは、アドレスを識別するために使用される、またはイニシエータとターゲットを認証してはいけません。
The alias is a variable length string, between 0 and 255 characters, and is terminated with at least one NULL (0x00) character, as defined in [RFC3720]. No other structure is imposed upon this string.
エイリアスは、0〜255文字、可変長文字列であり、[RFC3720]で定義されるように、少なくとも一つのNULL（0x00の）文字で終端されています。他の構造は、この文字列に課されていません。
Initiators and targets are uniquely identified by an iSCSI Name. These identifiers may be assigned by a hardware or software manufacturer, a service provider, or even the customer. Although these identifiers are nominally human-readable, they are likely to be assigned from a point of view different from that of the other side of the connection. For instance, a target name for a disk array may be built from the array's serial number, and some sort of internal target ID. Although this would still be human-readable and transcribable, it offers little assurance to someone at a user interface who would like to see "at-a-glance" whether this target is really the correct one.
イニシエータおよびターゲットは一意のiSCSI名で識別されます。これらの識別子は、ハードウェアまたはソフトウェアの製造元、サービスプロバイダ、あるいは顧客によって割り当てることもできます。これらの識別子は、名目上、人間が読めるが、それらは、接続の反対側のものとは異なる観点から割り当てられる可能性があります。例えば、ディスクアレイのターゲット名は、アレイのシリアル番号、および内部のターゲットIDのいくつかの並べ替えから構築することができます。これはまだ、人間が読めると転写可能だろうが、それはこのターゲットが本当に正しいものであるかどうか「が一目でわかる」見たいユーザーインターフェースで誰かに少し保証を提供しています。
The use of an alias helps solve that problem. An alias is simply a descriptive name that can be assigned to an initiator or target, that is independent of the name, and does not have to be unique. Since it is not unique, the alias must be used in a purely informational way. It may not be used to specify a target at login, or used during authentication.
エイリアスの使用は、その問題を解決するのに役立ちます。エイリアスは、単に名前から独立しており、ユニークである必要はありません、イニシエータまたはターゲットに割り当てることができ、わかりやすい名前です。それは一意ではないので、別名は純粋に情報提供の方法で使用する必要があります。ログイン時にターゲットを指定するために使用される、または認証の際に使用することはできません。
Both targets and initiators may have aliases.
ターゲットとイニシエータの両方が別名を持つことができます。
To show the utility of an alias, here is an example using an alias for an iSCSI target.
エイリアスの有用性を示すために、ここでのiSCSIターゲットのエイリアスを使用した例があります。
Imagine sitting at a desktop station that is using some iSCSI devices over a network. The user requires another iSCSI disk, and calls the storage services person (internal or external), giving any authentication information that the storage device will require for the host. The services person allocates a new target for the host, and sends the Target Name for the new target, and probably an address, back to the user. The user then adds this Target Name to the configuration file on the host, and discovers the new device.
ネットワーク上の一部のiSCSIデバイスを使用しているデスクトップ・ステーションの前に座って想像してみてください。ユーザーは、他のiSCSIディスクを必要とし、ストレージデバイスは、ホストのために必要となる任意の認証情報を与えるストレージサービス担当者（内部または外部）を呼び出します。サービス担当者は、ホストのための新しいターゲットを割り当て、ユーザに戻って、新しいターゲット、そしておそらくアドレスのためのターゲット名を送信します。ユーザーは、ホスト上の設定ファイルにこのターゲット名を追加し、新しいデバイスを検出します。
Without an alias, a user managing an iSCSI host would click on some sort of management "show targets" button to show the targets to which the host is currently connected.
エイリアスがなければ、iSCSIホストを管理するユーザーは、ホストが現在接続しているターゲットを表示するために経営「ショー目標」ボタンのいくつかの並べ替えをクリックします。
+--Connected-To-These-Targets----------------------
|
| Target Name
|
| iqn.1995-04.com.example:sn.5551212.target.450
| iqn.1995-04.com.example:sn.5551212.target.489
| iqn.1995-04.com.example:sn.8675309
| iqn.2001-04.com.example.storage:tape.sys1.xyz
| iqn.2001-04.com.example.storage.tape:sys1.xyz
|
+--------------------------------------------------
In the above example, the user sees a collection of iSCSI Names, but with no real description of what they are for. They will, of course, map to a system-dependent device file or drive letter, but it's not easy looking at numbers quickly to see if everything is there.
上記の例では、ユーザーは、iSCSI名のコレクションを見て、彼らはのためにあるものの無い本当の記述と。彼らは、当然のことながら、システム依存のデバイスファイルやドライブ文字にマップされますが、それはすべてのものがあるかどうかを確認するために迅速に数字を見て簡単ではありません。
If a storage administrator configures an alias for each target name, the alias can provide a more descriptive name. This alias may be sent back to the initiator as part of the login response, or found in the iSCSI MIB. It then might be used in a display such as the following:
ストレージ管理者は、各ターゲット名の別名を設定した場合、別名はより説明的な名前を提供することができます。このエイリアスは、ログイン応答の一部としてイニシエータに送り返され、またはiSCSI MIBに見出すことができます。それから、次のような表示に使用されることがあります。
+--Connected-To-These-Targets----------------------
|
| Alias Target Name
|
| Oracle 1 iqn.1995-04.com.example:sn.5551212.target.450
| Local Disk iqn.1995-04.com.example:sn.5551212.target.489
| Exchange 2 iqn.1995-04.com.example:sn.8675309
|
+--------------------------------------------------
This would give the user a better idea of what's really there.
これは、ユーザーが実際にそこに何の良いアイデアを与えるだろう。
In general, flexible, configured aliases will probably be supported by larger storage subsystems and configurable gateways. Simpler devices will likely not keep configuration data around for things such as an alias. The TargetAlias string could be either left unsupported (not given to the initiator during login) or could be returned as whatever the "next best thing" that the target has that might better describe it. Since it does not have to be unique, it could even return SCSI inquiry string data.
一般的に、柔軟に構成エイリアスは、おそらく、より大きなストレージサブシステム及び構成ゲートウェイによってサポートされます。よりシンプルなデバイスは、おそらく、このような別名としてもののために周りの構成データを保持しません。 targetAliasの文字列は、サポートされていない左のいずれかである（ログイン時にイニシエータに与えられていない）か、ターゲットがそれが良いことを説明するかもしれない持っていることを何でも「次善の策」として返されることがあります。それはユニークである必要はありませんので、それもSCSI照会文字列データを返すことができます。
Note that if a simple initiator does not wish to keep or display alias information, it can be simply ignored if seen in the login response.
シンプルなイニシエータは、エイリアス情報を維持するか、表示したくない場合は、ログイン応答で見た場合、それは単に無視されることに注意してください。
An initiator alias can be used in the same manner as a target alias. An initiator may send the alias in a login request, when it sends its iSCSI Initiator Name. The alias is not used for authentication, but may be kept with the session information for display through a management Graphical User Interface (GUI) or command-line interface (for a more complex subsystem or gateway), or through the iSCSI MIB.
イニシエータエイリアスは、ターゲットエイリアスと同様に使用することができます。それはそのiSCSIイニシエータ名を送信すると、イニシエータは、ログイン要求にエイリアスを送信することができます。エイリアスは、認証のために使用されず、管理グラフィカルユーザインタフェース（GUI）または（より複雑なサブシステムまたはゲートウェイの）コマンド・ライン・インターフェースを介して、またはiSCSI MIBを介して表示するためのセッション情報を保持することができます。
Note that a simple target can just ignore the Initiator Alias if it has no management interface on which to display it.
それはそれを表示するには、管理インターフェースを持っていない場合は、単純なターゲットはちょうどイニシエータエイリアスを無視することができることに注意してください。
Usually just the hostname would be sufficient for an initiator alias, but a custom alias could be configured for the sake of the service provider if needed. Even better would be a description of what the machine was used for, such as "Exchange Server 1", or "User Web Server".
通常、単にホスト名は、イニシエータの別名のために十分であるが、必要に応じてカスタムエイリアスは、サービスプロバイダのために構成することができます。さらに良いことに、このような「のExchange Server 1」、または「ユーザーのWebサーバー」のような機械が使われた内容の説明、だろう。
Here's an example of a management interface showing a list of sessions on an iSCSI target network entity. For this display, the targets are using an internal target number, which is a fictional field that has purely internal significance.
ここでは、iSCSIターゲットネットワークエンティティ上のセッションのリストを示す管理インターフェイスの例を示します。この表示のために、ターゲットは純粋に内部的意義を有する架空のフィールドである内部目標数を使用しています。
+--Connected-To-These-Initiators-------------------
|
| Target Initiator Name
|
| 450 iqn.1995-04.com.example.sw:cd.12345678-OEM-456
| 451 iqn.1995-04.com.example.os:hostid.A598B45C
| 309 iqn.1995-04.com.example.sw:cd.87654321-OEM-259
|
+--------------------------------------------------
And with the initiator alias displayed:
そして、イニシエーターの別名で表示：
+--Connected-To-These-Initiators-------------------
|
| Target Alias Initiator Name
|
| 450 Web Server 4 iqn.1995-04.com.example.sw:cd.12...
| 451 scsigw.example.com iqn.1995-04.com.example.os:hosti...
| 309 Exchange Server iqn.1995-04.com.example.sw:cd.87...
|
+--------------------------------------------------
This gives the storage administrator a better idea of who is connected to their targets. Of course, one could always do a reverse DNS lookup of the incoming IP address to determine a host name, but simpler devices really don't do well with that particular feature due to blocking problems, and it won't always work if there is a firewall or iSCSI gateway involved.
これは、ストレージ管理者に彼らのターゲットに接続しているユーザーのより良いアイデアを提供します。もちろん、人は常にホスト名を決定するために、着信IPアドレスのDNSの逆引きを行うことができますが、単純なデバイスは実際に起因する問題を阻止するために、その特定の機能とうまくやっていない、とがある場合、それは常に動作しません。ファイアウォールまたはiSCSIゲートウェイが関与します。
Again, these are purely informational and optional and require a management application.
ここでも、これらは純粋に情報およびオプションであり、管理アプリケーションが必要です。
Aliases are extremely easy to implement. Targets just send a TargetAlias whenever they send a TargetName. Initiators just send an InitiatorAlias whenever they send an InitiatorName. If an alias is received that does not fit, or seems invalid in any way, it is ignored.
エイリアスは、実装が非常に簡単です。彼らはTargetNameはを送信するたびにターゲットはちょうどtargetAliasのを送信します。彼らはInitiatorNameを送るたび開始剤は、ちょうどInitiatorAliasを送信します。エイリアスが合う、またはいずれかの方法で無効思わない受信された場合、それは無視されます。
The goal of iSCSI discovery is to allow an initiator to find the targets to which it has access, and at least one address at which each target may be accessed. This should generally be done using as little configuration as possible. This section defines the discovery mechanism only; no attempt is made to specify central management of iSCSI devices within this document. Moreover, the iSCSI discovery mechanisms listed here only deal with target discovery and one still needs to use the SCSI protocol for LUN discovery.
iSCSI検出の目標は、イニシエータが各ターゲットにアクセスすることができるでそれがアクセス先のターゲット、及び少なくとも1つのアドレスを見つけることができるようにすることです。これは、一般的に可能な限り少ない構成を使用して行われるべきです。このセクションでは、検出メカニズムのみを定義しています。何の試みは、この文書内のiSCSIデバイスの集中管理を指定するために行われません。また、ここに記載されているiSCSI検出メカニズムは、ターゲットの発見に対処し、一つはまだLUN発見のためのSCSIプロトコルを使用する必要があります。
In order for an iSCSI initiator to establish an iSCSI session with an iSCSI target, the initiator needs the IP address, TCP port number and iSCSI target name information. The goal of iSCSI discovery mechanisms are to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups. Thus, there are several methods that may be used to find targets ranging from configuring a list of targets and addresses on each initiator and doing no discovery at all, to configuring nothing on each initiator, and allowing the initiator to discover targets dynamically. The various discovery mechanisms differ in their assumptions about what information is already available to the initiators and what information needs to be still discovered.
iSCSIターゲットとiSCSIセッションを確立するために、iSCSIイニシエータためには、イニシエータは、IPアドレス、TCPポート番号およびiSCSIターゲット名の情報を必要とします。 iSCSI検出メカニズムの目標は、小さなiSCSIのセットアップ、および大企業のセットアップのためのスケーラブルな発見・ソリューションのための低オーバーヘッドのサポートを提供することです。このように、各イニシエータにターゲットとアドレスのリストを設定し、各イニシエータには何も設定していないし、まったく発見をやっていない、とイニシエータが動的にターゲットを検出できるようにするに至るまでの目標を見つけるために使用することができるいくつかの方法があります。様々な検出メカニズムは、すでにイニシエータに利用可能であり、まだ発見する必要があるものについてどのような情報についての彼らの前提が異なります。
iSCSI supports the following discovery mechanisms:
iSCSIは、次の検出メカニズムをサポートしています。
a. Static Configuration: This mechanism assumes that the IP address, TCP port and the iSCSI target name information are already available to the initiator. The initiators need to perform no discovery in this approach. The initiator uses the IP address and the TCP port information to establish a TCP connection, and it uses the iSCSI target name information to establish an iSCSI session. This discovery option is convenient for small iSCSI setups.
A。静的構成：このメカニズムは、IPアドレス、TCPポートとiSCSIターゲット名情報がすでにイニシエータに利用可能であることを前提としています。開始剤は、このアプローチには検出を実行しないようにする必要があります。イニシエータは、TCPコネクションを確立するために、IPアドレスとTCPポート情報を使用し、それがiSCSIセッションを確立するために、iSCSIターゲット名情報を使用しています。この発見オプションは、小規模なiSCSIのセットアップに便利です。
b. SendTargets: This mechanism assumes that the target's IP address and TCP port information are already available to the initiator. The initiator then uses this information to establish a discovery session to the Network Entity. The initiator then subsequently issues the SendTargets text command to query information about the iSCSI targets available at the particular Network Entity (IP address). SendTargets command details can be found in the iSCSI document [RFC3720]. This discovery option is convenient for iSCSI gateways and routers.
B。 SendTargets：このメカニズムは、ターゲットのIPアドレスおよびTCPポート情報がすでにイニシエータに利用可能であることを前提としています。イニシエータは、[ネットワークエンティティに検出セッションを確立するために、この情報を使用しています。イニシエータは、その後、特定のネットワーク・エンティティ（IPアドレス）で使用可能なiSCSIターゲットに関する情報を照会するSendTargetsテキストコマンドを発行します。 SendTargetsコマンドの詳細は、iSCSIのドキュメント[RFC3720]で見つけることができます。この発見オプションは、iSCSIゲートウェイやルータに便利です。
c. Zero-Configuration: This mechanism assumes that the initiator does not have any information about the target. In this option, the initiator can either multicast discovery messages directly to the targets or it can send discovery messages to storage name servers. Currently, there are many general purpose discovery frameworks available such as Salutation [John], Jini [John], UPnP [John], SLP [RFC2608] and iSNS [iSNS]. However, with respect to iSCSI, SLP can clearly perform the needed discovery functions [iSCSI-SLP], while iSNS [iSNS] can be used to provide related management functions including notification, access management, configuration, and discovery management. iSCSI equipment that need discovery functions beyond SendTargets should at least implement SLP, and then consider iSNS when extended discovery management capabilities are required such as in larger storage networks. It should be noted that since iSNS will support SLP, iSNS can be used to help manage the discovery information returned by SLP.
C。ゼロコンフィギュレーション：このメカニズムは、イニシエータがターゲットに関する情報を持っていないことを前提としています。このオプションでは、イニシエータは、ターゲットへの直接のいずれかのマルチキャストディスカバリメッセージは、それがストレージネームサーバにディスカバリメッセージを送ることができますすることができますか。現在、敬称[ジョン]、ジニ[ジョン]、UPnPの[ジョン]、SLP [RFC2608]とiSNSの[iSNSの]として利用可能な多くの汎用発見のフレームワークがあります。 iSNSのは、[iSNSの】通知、アクセス管理、構成、およびディスカバリ管理を含む関連する管理機能を提供するために使用することができるがしかし、iSCSIのに対して、SLPは明らかに必要なディスカバリ機能[iSCSIの-SLP]を実行することができます。 SendTargetsを超えて発見機能を必要としたiSCSI機器は、少なくともSLPを実装して、拡張検出管理機能は、このような大規模ストレージ・ネットワークのように必要とされるときにiSNSを検討すべきです。 iSNSは、SLPをサポートするために、iSNSのは、SLPによって返された発見情報の管理を支援するために使用できることに留意すべきです。
Most security issues relating to iSCSI naming are discussed in the main iSCSI document [RFC3720] and the iSCSI security document [RFC3723].
iSCSIの命名に関連するほとんどのセキュリティ上の問題は、メインのiSCSIドキュメント[RFC3720]とiSCSIセキュリティドキュメント[RFC3723]で議論されています。
In addition, Appendix B discusses naming and discovery issues when gateways, proxies, and firewalls are used to solve security or discovery issues in some situations where iSCSI is deployed.
ゲートウェイ、プロキシ、ファイアウォールがiSCSIのが配備されているいくつかの状況ではセキュリティや発見の問題を解決するために使用されている場合また、付録Bは、ネーミングと発見の問題について説明します。
iSCSI allows several different authentication methods to be used. For many of these methods, an authentication identifier is used, which may be different from the iSCSI node name of the entity being authenticated. This is discussed in more detail in Appendix C.
iSCSIは、いくつかの異なる認証方法を使用することができます。これらの方法の多くは、認証識別子は、認証されるエンティティのiSCSIノード名と異なっていてもよく、使用されます。これは、付録Cで詳しく説明されて
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、メタ、K.、Sapuntzakis、C. Chadalapaka、M.およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[EUI64] EUI - "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority, http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html
[EUI64] EUI - 「64ビットのグローバル識別子（EUI64）登録機関のガイドライン、http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html
[SAM2] R. Weber et al, INCITS T10 Project 1157-D revision 24, "SCSI Architectural Model - 2 (SAM-2)", Section 4.7.6 "SCSI device name", September 2002.
[SAM2] R.ウェーバーら、INCITS T10プロジェクト1157-D改定24、 "SCSIアーキテクチャモデル - 2（SAM2）"、セクション4.7.6 "SCSIデバイス名"、2002年9月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "SLP Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "SLPバージョン2"、RFC 2608、1999年6月。
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
"URLの中にリテラルIPv6アドレスのフォーマット" [RFC2732] HindenとR.、大工、B.およびL. Masinter、RFC 2732、1999年12月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]フリード、N.、 "の行動とインターネットファイアウォールの要件"、RFC 2979、2000年10月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox Communication Architecture and Framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.とA. Rayhan、 "ミドル通信アーキテクチャとフレームワーク"、RFC 3303、2002年8月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 Addressing Architecture", RFC 3513, April 2003.
[RFC3513] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6アドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.とF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[iSCSI-SLP] Bakke, M., et al., "Finding iSCSI Targets and Name Servers using SLP", Work in Progress, March 2003.
[iSCSIの-SLP] Bakke、M.ら、 "検索iSCSIターゲットおよびSLPを使用してネームサーバ"、進歩、2003年3月での作業。
[iSNS] Tseng, J., et al., "Internet Storage Name Service (iSNS)", Work in Progress, January 2003.
[iSNSの]ツェン、J.ら、 "インターネットストレージネームサービス（iSNS）"、進歩、2003年1月の作業。
[John] R. John, "UPnP, Jini and Salutation- A look at some popular coordination frameworks for future networked devices", http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999.
[ジョン] R.ジョンは、1999年6月17日、「http://www.cswl.com/whiteppr/tech/upnp.html、「UPnPの、ジニとSalutation- Aは、将来のネットワークデバイスのためのいくつかの人気のコーディネートのフレームワークを見て」 。
Joe Czap (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (SANRAD), Larry Lamers (Adaptec), Josh Tseng (Nishan Systems), and Todd Sperry (Adaptec) have participated and made contributions during development of this document.
ジョー・Czap（IBM）、ハワード・ホール（Pirus）、ジャック・ハーウッド（EMC）、ヤロン・クライン（SANRAD）、ラリー・Lamers（アダプテック）、ジョシュ・ツェン（ニシャンシステム）、およびトッド・スペリー（アダプテック）が参加し、開発中の貢献を行ってきましたこのドキュメントの。
Appendix A: iSCSI Naming Notes
付録A：iSCSIの命名ノート
Some iSCSI Name Examples for Targets
ターゲットのためのいくつかのiSCSI名例
- Assign to a target based on controller serial number
- コントローラのシリアル番号に基づいて、ターゲットへの割り当て
iqn.2001-04.com.example:diskarray.sn.8675309
iqn.2001-04.com.example：diskarray.sn.8675309
- Assign to a target based on serial number
- シリアル番号に基づいてターゲットへの割り当て
iqn.2001-04.com.example:diskarray.sn.8675309.oracle-db-1
iqn.2001-04.com.example：diskarray.sn.8675309.oracle-DB-1
Where oracle-db-1 might be a target label assigned by a user.
オラクル-DB-1は、ユーザが割り当てられたターゲットラベルであるかもしれないところ。
This would be useful for a controller that can present different logical targets to different hosts.
これは、異なるホストに異なる論理ターゲットを提示することができる制御装置に有用であろう。
Obviously, any naming authority may come up with its own scheme and hierarchy for these names, and be just as valid.
明らかに、任意の命名機関は、これらの名前のために、独自の方式と階層を思い付く、と同じように有効です。
A target iSCSI Name should never be assigned based on interface hardware, or other hardware that can be swapped and moved to other devices.
ターゲットのiSCSI名はインターフェイスのハードウェア、またはスワップおよびその他のデバイスに移動することができる他のハードウェアに基づいて割り当ててはいけません。
Some iSCSI Name Examples for Initiators
イニシエータのためのいくつかのiSCSI名例
- Assign to the OS image by fully qualified host name
- 完全修飾ホスト名でOSイメージへの割り当て
iqn.2001-04.com.example.os:dns.com.customer1.host-four
iqn.2001-04.com.example.os：dns.com.customer1.host-4
Note the use of two FQDNs - that of the naming authority and also that of the host that is being named. This can cause problems, due to limitations imposed on the size of the iSCSI Name.
命名されているホストの命名機関のものともその - 2つのFQDNの使用を注意してください。これは、iSCSI名のサイズに課せられた制限のために、問題を引き起こす可能性があります。
- Assign to the OS image by OS install serial number
- シリアル番号をインストールするOSによって、OSイメージに割り当て
iqn.2001-04.com.example.os:newos5.12345-OEM-0067890-23456
iqn.2001-04.com.example.os：newos5.12345-OEM-0067890から23456
Note that this breaks if an install CD is used more than once. Depending on the O/S vendor's philosophy, this might be a feature.
インストールCDが複数回使用されている場合、これが壊れることに注意してください。 O / S・ベンダーの哲学に応じて、これは機能かもしれません。
- Assign to the Raid Array by a service provider
- サービスプロバイダによってRAIDアレイに割り当て
iqn.2001-04.com.example.myssp:users.mbakke05657
iqn.2001-04.com.example.myssp：users.mbakke05657
Appendix B: Interaction with Proxies and Firewalls
付録B：プロキシやファイアウォールとの相互作用
iSCSI has been designed to allow SCSI initiators and targets to communicate over an arbitrary IP network. This means that in theory, making some assumptions about authentication and security, the whole internet could be used as one giant storage network.
iSCSIは、SCSIイニシエータとターゲットは、任意のIPネットワーク上で通信できるようにするために設計されています。これは理論的には、認証とセキュリティに関するいくつかの仮定を作る、インターネット全体が1つの巨大なストレージ・ネットワークとして使用することができることを意味しています。
However, there are many access and scaling problems that would come up when this is attempted.
しかし、これが試みられたときに出てくるだろう多くのアクセスとスケーリング問題があります。
1. Most iSCSI targets may only be meant to be accessed by one or a few initiators. Discovering everything would be unnecessary.
1.ほとんどのiSCSIターゲットは、1つまたは少数のイニシエータによってアクセスされることを意図することができます。すべてのものを発見することは不要になります。
2. The initiator and target may be owned by separate entities, each with their own directory services, authentication, and other schemes. An iSCSI-aware proxy may be required to map between these things.
2.イニシエータとターゲットは、独自のディレクトリサービス、認証、および他のスキームとのそれぞれは、別々のエンティティが所有することができます。 iSCSIの対応のプロキシは、これらのものの間でマッピングするために必要な場合があります。
3. Many environments use non-routable IP addresses, such as the "10." network.
3.多くの環境では、「10」などの非ルーティング可能なIPアドレスを使用します通信網。
For these and other reasons, various types of firewalls [RFC2979] and proxies will be deployed for iSCSI, similar in nature to those already handling protocols such as HTTP and FTP.
これら及び他の理由のために、ファイアウォール[RFC2979]とプロキシの様々なタイプは、すでにそのようなHTTPやFTPなどのプロトコルを扱うものと本質的に類似のiSCSIのために展開されます。
B.1. Port Redirector
B.1。ポートリダイレクタ
A port redirector is a stateless device that is not aware of iSCSI. It is used to do Network Address Translation (NAT), which can map IP addresses between routable and non-routable domains, as well as map TCP ports. While devices providing these capabilities can often filter based on IP addresses and TCP ports, they generally do not provide meaningful security, and are used instead to resolve internal network routing issues.
ポートリダイレクターは、iSCSIを認識していないステートレスデバイスです。ルーティング可能と非ルーティング可能なドメイン間のIPアドレスをマッピングすることができ、ネットワークアドレス変換（NAT）、だけでなく、マップのTCPポートを行うために使用されます。これらの機能を提供するデバイスは、多くの場合、IPアドレスとTCPポートに基づいてフィルタリングすることができますが、それらは一般的に意味のあるセキュリティを提供していない、と内部ネットワークのルーティングの問題を解決するために代わりに使用されています。
Since it is entirely possible that these devices are used as routers and/or aggregators between a firewall and an iSCSI initiator or target, iSCSI connections must be operable through them.
それは、これらのデバイスは、ファイアウォールとiSCSIイニシエータまたはターゲットとの間のルータおよび/またはアグリゲータとして使用されることが完全に可能であるため、iSCSI接続は、それらを介して動作可能でなければなりません。
Effects on iSCSI:
iSCSIのへの影響：
- iSCSI-level data integrity checks must not include information from the TCP or IP headers, as these may be changed in between the initiator and target.
- これらは、イニシエータとターゲットとの間で変更することができるようにiSCSIのレベルのデータの整合性チェックは、TCPまたはIPヘッダからの情報を含んではなりません。
- iSCSI messages that specify a particular initiator or target, such as login requests and third party requests, should specify the initiator or target in a location-independent manner. This is accomplished using the iSCSI Name.
- そのようなログイン要求および第三者の要求のような特定のイニシエータまたはターゲットを指定したiSCSIメッセージは、位置に依存しない方法で、イニシエータまたはターゲットを特定すべきです。これは、iSCSI名を使用して達成されます。
- When an iSCSI discovery connection is to be used through a port redirector, a target will have to be configured to return a domain name instead of an IP address in a SendTargets response, since the port redirector will not be able to map the IP address(es) returned in the iSCSI message. It is a good practice to do this anyway.
- iSCSI検出の接続がポートリダイレクタを介して使用する場合、ポートリダイレクターは、IPアドレスをマッピングすることはできませんから、ターゲットは、SendTargets応答のIPアドレスの代わりにドメイン名を返すように設定する必要があります（ES）のiSCSIメッセージで返さ。このとにかくを行うことをお勧めします。
B.2. SOCKS server
B.2。 SOCKSサーバー
A SOCKS server can be used to map TCP connections from one network domain to another. It is aware of the state of each TCP connection.
SOCKSサーバを別のネットワークドメインからのTCP接続をマッピングするために使用することができます。これは、各TCPコネクションの状態を認識しています。
The SOCKS server provides authenticated firewall traversal for applications that are not firewall-aware. Conceptually, SOCKS is a "shim-layer" that exists between the application (i.e., iSCSI) and TCP.
SOCKSサーバーは、ファイアウォールを意識していないアプリケーションのための認証済みファイアウォールトラバーサルを提供します。概念的に、SOCKSは、アプリケーション（すなわち、iSCSIの）とTCPとの間に存在する「シム層」です。
To use SOCKS, the iSCSI initiator must be modified to use the encapsulation routines in the SOCKS library. The initiator then opens up a TCP connection to the SOCKS server, typically on the canonical SOCKS port 1080. A sub-negotiation then occurs, during which the initiator is either authenticated or denied the connection request. If authenticated, the SOCKS server then opens a TCP connection to the iSCSI target using addressing information sent to it by the initiator in the SOCKS shim. The SOCKS server then forwards iSCSI commands, data, and responses between the iSCSI initiator and target.
SOCKSを使用するには、iSCSIイニシエータは、SOCKSライブラリにカプセル化ルーチンを使用するように変更する必要があります。イニシエータは、イニシエータが認証または接続要求を拒否されるか、その間、サブ交渉はその後発生し、通常、標準的なSOCKSポート1080上で、SOCKSサーバへのTCP接続を開きます。認証された場合、SOCKSサーバーは、SOCKSシムで、イニシエータから送信されたアドレス情報を使用してiSCSIターゲットへのTCP接続を開きます。 SOCKSサーバは、転送したiSCSIは、iSCSIイニシエータとターゲットの間で、データ、および応答コマンド。
Use of the SOCKS server requires special modifications to the iSCSI initiator. No modifications are required to the iSCSI target.
SOCKSサーバーを使用すると、iSCSIイニシエータに特別な変更を必要とします。改造は、iSCSIターゲットに必要ありません。
As a SOCKS server can map most of the addresses and information contained within the IP and TCP headers, including sequence numbers, its effects on iSCSI are identical to those in the port redirector.
SOCKSサーバーは、シーケンス番号を含む、IPおよびTCPヘッダに含まれるアドレスや情報のほとんどをマッピングすることができるため、iSCSIの上のその効果は、ポートリダイレクタと同一です。
B.3. SCSI gateway
B.3。 SCSIゲートウェイ
This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to SCSI targets as it chooses. The initiator sees this gateway as a real iSCSI target, and is unaware of any proxy or gateway behavior. The gateway may manufacture its own iSCSI Names, or map the iSCSI names using information provided by the physical SCSI devices. It is the responsibility of the gateway to ensure the uniqueness of any iSCSI name it manufactures. The gateway may have to account for multiple gateways having access to a single physical device. This type of gateway is used to present parallel SCSI, Fibre Channel, SSA, or other devices as iSCSI devices.
このゲートウェイは、イニシエータへの論理ターゲット（iSCSIの名前）を提示し、それを選択したとしてSCSIターゲットにマッピングします。イニシエータは、実際のiSCSIターゲットとしてこのゲートウェイを見て、任意のプロキシまたはゲートウェイの動作を認識しません。ゲートウェイは、独自のiSCSI名を製造、または物理的なSCSIデバイスによって提供される情報を使用してiSCSI名をマップすることができます。メーカー任意のiSCSI名の一意性を保証するために、ゲートウェイの責任です。ゲートウェイは、単一の物理デバイスへのアクセスを有する複数のゲートウェイを考慮するために有していてもよいです。ゲートウェイこのタイプのパラレルSCSI、ファイバチャネル、SSA、またはiSCSIデバイスなど他のデバイスを提示するために使用されます。
Effects on iSCSI:
iSCSIのへの影響：
- Since the initiator is unaware of any addresses beyond the gateway, the gateway's own address is for all practical purposes the real address of a target. Only the iSCSI Name needs to be passed. This is already done in iSCSI, so there are no further requirements to support SCSI gateways.
- イニシエータは、ゲートウェイを越えたアドレスを認識しないので、ゲートウェイ自身のアドレスは、すべての実用的な目的のために、ターゲットの実アドレスです。唯一のiSCSI名を渡す必要があります。これは、すでにiSCSIの中で行われているので、SCSIゲートウェイをサポートするために、それ以上の要件はありません。
B.4. iSCSI Proxy
B.4。 iSCSIのプロキシ
An iSCSI proxy is a gateway that terminates the iSCSI protocol on both sides, rather than translate between iSCSI and some other transport. The proxy functionality is aware that both sides are iSCSI, and can take advantage of optimizations, such as the preservation of data integrity checks. Since an iSCSI initiator's discovery or configuration of a set of targets makes use of address-independent iSCSI names, iSCSI does not have the same proxy addressing problems as HTTP, which includes address information into its URLs. If a proxy is to provide services to an initiator on behalf of a target, the proxy allows the initiator to discover its address for the target, and the actual target device is discovered only by the proxy. Neither the initiator nor the iSCSI protocol needs to be aware of the existence of the proxy. Note that a SCSI gateway may also provide iSCSI proxy functionality when mapping targets between two iSCSI interfaces.
iSCSIのプロキシは、iSCSIおよびいくつかの他のトランスポート間の変換ではなく、両側にiSCSIプロトコルを終端するゲートウェイです。プロキシ機能は、両側がiSCSIであり、そのようなデータの整合性チェックの保存などの最適化の利点を取ることができることを知っています。一連のターゲットのiSCSIイニシエータの発見や設定はアドレスに依存しないiSCSI名を使用するので、iSCSIはそのURLの中のアドレス情報を含んでいるHTTPなどの問題に対処同じプロキシがありません。プロキシがターゲットに代わってイニシエータにサービスを提供する場合、プロキシは、イニシエータがターゲットのためにそのアドレスを発見することを可能にする、と実際のターゲットデバイスのみがプロキシによって発見されました。イニシエータやiSCSIプロトコルはいずれも、プロキシの存在を意識する必要があります。 2つのiSCSIインターフェイス間ターゲットをマッピングする際SCSIゲートウェイもiSCSIのプロキシ機能を提供することができることに留意されたいです。
Effects on iSCSI:
iSCSIのへの影響：
- Same as a SCSI gateway. The only other effect is that iSCSI must separate data integrity checking on iSCSI headers and iSCSI data, to allow the data integrity check on the data to be propagated end-to-end through the proxy.
- SCSIのゲートウェイと同じ。唯一の他の効果は、iSCSIは、プロキシを経由して、エンドツーエンドを伝播するデータ上のデータの整合性チェックを可能にし、iSCSIのヘッダおよびiSCSIデータにチェックし、データの整合性を分離しなければならないということです。
B.5. Stateful Inspection Firewall (stealth iSCSI firewall)
B.5。ステートフルインスペクションファイアウォール（ステルスのiSCSIファイアウォール）
The stealth model would exist as an iSCSI-aware firewall, that is invisible to the initiator, but provides capabilities found in the iSCSI proxy.
ステルスモデルは、イニシエータには見えないですが、iSCSIのプロキシで見つかった機能を提供したiSCSI対応のファイアウォール、として存在します。
Effects on iSCSI:
iSCSIのへの影響：
- Since this is invisible, there are no additional requirements on the iSCSI protocol for this one.
- これは目に見えないので、この1のためのiSCSIプロトコルには、追加の要件はありません。
This one is more difficult in some ways to implement, simply because it has to be part of a standard firewall product, rather than part of an iSCSI-type product.
この1は、それが標準のファイアウォール製品の一部ではなく、iSCSIのタイプの製品の一部でなければならないという理由だけで、実装するためのいくつかの点でより困難です。
Also note that this type of firewall is only effective in the outbound direction (allowing an initiator behind the firewall to connect to an outside target), unless the iSCSI target is located in a DMZ (De-Militarized Zone) [RFC3303]. It does not provide adequate security otherwise.
また、ファイアウォールのこのタイプは、アウトバウンド方向（外部ターゲットに接続するにはファイアウォールの背後にあるイニシエータを可能にする）、iSCSIターゲットは、DMZ（非武装地帯）に配置されていない限り、[RFC3303]でのみ有効です。これは、そうでない場合は、十分なセキュリティを提供しません。
Appendix C: iSCSI Names and Security Identifiers
付録C：のiSCSI名前やセキュリティ識別子
This document has described the creation and use of iSCSI Node Names. There will be trusted environments where this is a sufficient form of identification. In these environments the iSCSI Target may have an Access Control List (ACL), which will contain a list of authorized entities that are permitted to access a restricted resource (in this case a Target Storage Controller). The iSCSI Target will then use that ACL to permit (or not) certain iSCSI Initiators to access the storage at the iSCSI Target Node. This form of ACL is used to prevent trusted initiators from making a mistake and connecting to the wrong storage controller.
この文書では、iSCSIノード名の作成と使用を記載しています。これは識別の十分な形で信頼できる環境があります。これらの環境でiSCSIターゲットは、（この場合はターゲットストレージコントローラに）制限されたリソースへのアクセスが許可される権限のエンティティのリストが含まれますアクセス制御リスト（ACL）を有していてもよいです。 iSCSIターゲットは、iSCSIターゲット・ノードでストレージにアクセスするために、特定のiSCSIイニシエータを許可（またはしない）することACLを使用します。 ACLのこの形式は間違いを作り、間違ったストレージ・コントローラに接続するから、信頼できるイニシエータを防ぐために使用されます。
It is also possible that the ACL and the iSCSI Initiator Node Name can be used in conjunction with the SCSI layer for the appropriate SCSI association of LUNs with the Initiator. The SCSI layer's use of the ACL will not be discussed further in this document.
ACLとiSCSIイニシエータノード名がイニシエータとのLUNの適切なSCSI関連のSCSI層と組み合わせて使用することができることも可能です。 ACLのSCSI層の使用は、この文書でさらに議論されることはありません。
There will be situations where the iSCSI Nodes exist in untrusted environments. That is, some iSCSI Initiator Nodes may be authorized to access an iSCSI Target Node, however, because of the untrusted environment, nodes on the network cannot be trusted to give the correct iSCSI Initiator Node Names.
iSCSIのノードが信頼されていない環境でも存在する状況があるでしょう。つまり、いくつかのiSCSIイニシエータノードがあるため、信頼できない環境では、しかし、iSCSIターゲット・ノードにアクセスすることを許可することができる、ネットワーク上のノードが正しいiSCSIイニシエータノード名を与えることを信頼することはできません。
In untrusted environments an additional type of identification is required to assure the target that it really knows the identity of the requesting entity.
信頼されていない環境では識別の追加的なタイプはそれが本当に要求しているエンティティの身元を知っているターゲットを確保するために必要とされます。
The authentication and authorization in the iSCSI layer is independent of anything that IPSec might handle, underneath or around the TCP layer. This means that the initiator node needs to pass some type of security related identification information (e.g., userid) to a security authentication process such as SRP, CHAP, Kerberos etc. (These authentication processes will not be discussed in this document.)
iSCSI層での認証と承認は、TCP層の下や周りに、IPSecが扱うかもしれないものとは無関係です。これは、（これらの認証プロセスは本書では説明しない。）イニシエータノードがセキュリティ関連の識別情報（例えば、ユーザID）は、SRPなどのセキュリティ認証プロセスに、CHAP、ケルベロスなどのいくつかのタイプを渡す必要があることを意味します
Upon the completion of the iSCSI security authentication, the installation knows "who" sent the request for access. The installation must then check to ensure that such a request, from the identified entity, is permitted/authorized. This form of Authorization is generally accomplished via an Access Control List (ACL) as described above. Using this authorization process, the iSCSI target will know that the entity is authorized to access the iSCSI Target Node.
iSCSIセキュリティ認証が完了すると、インストールがアクセス要求を送信し、「誰が」知っています。インストールは、そのような要求は、特定されたエンティティから、許可/許可されていることを確認するためにチェックしなければなりません。認可のこの形態は、一般的に上記のように、アクセス制御リスト（ACL）を介して達成されます。この認証プロセスを使用して、iSCSIターゲットは、エンティティがiSCSIターゲット・ノードにアクセスすることを許可されていることを知っているだろう。
It may be possible for an installation to set a rule that the security identification information (e.g., UserID) be equal to the iSCSI Initiator Node Name. In that case, the ACL approach described above should be all the authorization that is needed.
インストールは、セキュリティ識別情報（例えば、ユーザID）がiSCSIイニシエータノード名に等しくなるルールを設定することが可能であってもよいです。その場合には、上述したACLのアプローチが必要とされるすべての許可がなければなりません。
If, however, the iSCSI Initiator Node Name is not used as the security identifier there is a need for more elaborate ACL functionality. This means that the target requires a mechanism to map the security identifier (e.g., UserID) information to the iSCSI Initiator Node Name. That is, the target must be sure that the entity requesting access is authorized to use the name, which was specified with the Login Keyword "InitiatorName=". For example, if security identifier 'Frank' is authorized to access the target via iSCSI InitiatorName=xxxx, but 'Frank' tries to access the target via iSCSI InitiatorName=yyyy, then this login should be rejected.
しかし、iSCSIイニシエータノード名は、セキュリティ識別子として使用されていない場合は、より精巧なACL機能の必要性があります。これは、ターゲットは、iSCSIイニシエータノード名にセキュリティ識別子（例えば、ユーザID）情報をマッピングするための機構を必要とすることを意味します。これは、ターゲットがアクセスを要求しているエンティティは、ログインキーワード「InitiatorName =」で指定された名前を、使用を許可されていることを確認する必要があり、です。セキュリティ識別子「フランク」がiSCSIのInitiatorName = XXXX経由でターゲットにアクセスする権限はなく、iSCSIのInitiatorName = YYYY経由でターゲットにアクセスするには、「フランク試行されている場合、このログインは拒否されなければなりません。
On the other hand, it is possible that 'Frank' is a roaming user (or a Storage Administrator) that "owns" several different systems, and thus, could be authorized to access the target via multiple different iSCSI initiators. In this case, the ACL needs to have the names of all the initiators through which 'Frank' can access the target.
一方、いくつかの異なるシステムを「所有」し、従って、複数の異なるiSCSIイニシエータ経由でターゲットにアクセスすることを許可することができることを「フランク」は、ローミングユーザー（またはストレージ管理者）であることも可能です。この場合、ACLは「フランク」は、ターゲットにアクセスするためのすべてのイニシエータの名前を持っている必要があります。
There may be other more elaborate ACL approaches, which can also be deployed to provide the installation/user with even more security with flexibility.
また、柔軟性と、さらにセキュリティをインストール/ユーザに提供するために展開することができ、他のより精巧なACLのアプローチがあるかもしれません。
The above discussion is trying to inform the reader that, not only is there a need for access control dealing with iSCSI Initiator Node Names, but in certain iSCSI environments there might also be a need for other complementary security identifiers.
上記の議論は、iSCSIイニシエータノード名を扱うアクセス制御の必要性があるだけでなく、読者に通知しようとしているが、特定のiSCSIにも、他の補完的なセキュリティ識別子の必要があるかもしれない環境。さ
Authors' Addresses
著者のアドレス
Kaladhar Voruganti IBM Almaden Research Center 650 Harry Road San Jose, CA 95120
Kaladhar Voruganti IBMアルマデン研究センター650ハリー・ロードサンノゼ、CA 95120
EMail: kaladhar@us.ibm.com
メールアドレス：kaladhar@us.ibm.com
Mark Bakke Cisco Systems, Inc. 6450 Wedgwood Road Maple Grove, MN 55311
マークBakkeシスコシステムズ株式会社6450ウェッジウッド道路メープルグローブ、MN 55311
Phone: +1 763 398-1054 EMail: mbakke@cisco.com
電話：+1 763 398-1054 Eメール：mbakke@cisco.com
Jim Hafner IBM Almaden Research Center 650 Harry Road San Jose, CA 95120
ジム・ハフナーIBMアルマデン研究センター650ハリー・ロードサンノゼ、CA 95120
Phone: +1 408 927-1892 EMail: hafner@almaden.ibm.com
電話：+1 408 927-1892 Eメール：hafner@almaden.ibm.com
John L. Hufferd IBM Storage Systems Group 5600 Cottle Road San Jose, CA 95193
ジョン・L. Hufferd IBMストレージ・システムズ・グループ5600コトル道路サンノゼ、CA 95193
Phone: +1 408 256-0403 EMail: hufferd@us.ibm.com
電話：+1 408 256-0403 Eメール：hufferd@us.ibm.com
Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville, CA 95747-5668, USA
マージョリー・クルーガーヒューレット・パッカード株式会社8000山麓ブールバードローズ、CA 95747から5668、USA
Phone: +1 916 785-2656 EMail: marjorie_krueger@hp.com
電話：+1 916 785-2656 Eメール：marjorie_krueger@hp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。