[要約] RFC 3721は、iSCSIの命名と検出に関する標準仕様であり、iSCSIデバイスの識別と接続のための方法を提供します。このRFCの目的は、iSCSIネットワークでのデバイスの一意の識別と自動検出を可能にすることです。
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
インターネットスモールコンピューターシステムインターフェイス（ISCSI）命名と発見
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）The Internet Society（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イニシエーターによるISCSIリソース（ターゲット）の発見に関するインターネットスモールコンピューターシステムインターフェイス（ISCSI;またはTCPを介したSCSI）の名前の構築と議論の例を提供します。このドキュメントは、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:
ここで、<domain-name>は次の1つです。
- 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アドレス。名前がドット（。）で区切られた正確な4つの数値が含まれている場合、各数値は0..255の範囲にあります。
- IPv6 address, in colon-separated hexadecimal notation, as specified in [RFC3513] and enclosed in "[" and "]" characters, as specified in [RFC2732].
- [RFC3513]で指定され、[RFC2732]で指定されている「[""および "]文字に囲まれた、[RFC3513]で指定されているコロン分離された16進表記のIPv6アドレス）。
- Fully Qualified Domain Name (host name). Assumed if the <domain-name> is neither an IPv4 nor an IPv6 address.
- 完全資格のドメイン名（ホスト名）。<domain-name>が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ポートです。<port>が指定されていない場合、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
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
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
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.
この例では、Robertの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 '：'に続いて、割り当てられた組織の選択の文字列が続きます。
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-SN-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.
「ディスカレイ」は、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
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 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.
IQN.2001-04.com.example.storage.tape：sys1.xyz '：'セパレーターを除き、両方の名前は同一であることに注意してください。1つ目は、サブドメイン「Storage.example.com」の所有者によって割り当てられました。2番目は、「teap.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のコンピューターサイエンス部門では、各ユーザーが「ユーザー。<UserName>」を添付して、このタイプの作業の命名当局として自分のユーザー名を使用できるようにします。ユーザーの選択（ユーザーは、このパートを一意にする責任があります）。オークス教授は、この特定のターゲットに「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）は、顧客の1人に対してこの特定のターゲットに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」、「org」、「net」を含むトップレベルのドメイン名になることに注意してください。、「Mil」、または2文字の国コードの1つ。これらの名前の最初のコンポーネントとして他のものを使用することは許可されていません。特に、これらの名前を生成する企業は、「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。命名形式を使用すると、命名権限がIEEE EUI-64識別子を使用してISCSI名を作成できます。EUI-64識別子の構築の詳細は、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.
エイリアスは、[RFC3720]で定義されているように、0〜255文字の可変長文字列であり、少なくとも1つの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.
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.
一般に、柔軟な構成されたエイリアスは、おそらくより大きなストレージサブシステムと構成可能なゲートウェイによってサポートされます。よりシンプルなデバイスは、エイリアスなどのものについて構成データを維持しない可能性があります。ターゲットリアス文字列は、サポートされていないままにすることができます（ログイン中にイニシエーターに与えられません）か、ターゲットがそれをよりよく説明する可能性のある「次の最高のもの」として返される可能性があります。一意である必要はないため、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を送信するたびにターゲットリアを送信するだけです。イニシエーターは、イニシアチャトルナームを送信するたびにイニシアタリアを送信するだけです。適合しない、または何らかの形で無効と思われるエイリアスが受信された場合、それは無視されます。
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ターゲット名情報がイニシエーターがすでに利用できることを前提としています。イニシエーターは、このアプローチで発見を行う必要はありません。イニシエーターは、IPアドレスとTCPポート情報を使用して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ポート情報がイニシエーターがすでに利用できると想定しています。その後、イニシエーターはこの情報を使用して、ネットワークエンティティにディスカバリーセッションを確立します。その後、イニシエーターは、SendTargetsテキストコマンドを発行して、特定のネットワークエンティティ（IPアドレス）で利用可能なISCSIターゲットに関する情報を照会します。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. ゼロ構成：このメカニズムは、イニシエーターにターゲットに関する情報がないことを前提としています。このオプションでは、イニシエーターはターゲットに直接マルチキャストディスカバリーメッセージを送信するか、ストレージ名サーバーにディスカバリーメッセージを送信できます。現在、Sallutation [John]、Jini [John]、UPNP [John]、SLP [RFC2608]、ISNS [ISNS]など、多くの汎用発見フレームワークが利用可能です。ただし、ISCSIに関しては、SLPは必要な発見関数[ISCSI-SLP]を明確に実行できますが、ISNS [ISNS]を使用して、通知、アクセス管理、構成、および発見管理などの関連する管理機能を提供できます。SendTargetsを超えて発見機能を必要とするISCSI機器は、少なくともSLPを実装する必要があります。その後、より大きなストレージネットワークなどの拡張ディスカバリー管理機能が必要な場合はISNを考慮する必要があります。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.
さらに、付録Bでは、ISCSIが展開されている状況でセキュリティまたは発見の問題を解決するためにゲートウェイ、プロキシ、およびファイアウォールが使用される場合、命名と発見の問題について説明します。
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.、Meth、K.、Sapuntzakis、C。Chadalapaka、M。およびE. Zeidner、「Internet Small Computer Systems Interface（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ビットグローバル識別子（EUI-64）登録局のガイドライン、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. Weberら、T10プロジェクト1157-Dリビジョン24、「SCSI Architectural Model-2（SAM-2）」、セクション4.7.6「SCSIデバイス名」、2002年9月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "SLP Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、 "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.
[RFC2732] Hinden、R.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、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.、Rosenberg、J.、Molitor、A。and A. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、2002年8月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン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.、Tseng、J.、Walker、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.、et al。、「SLPを使用したISCSIターゲットと名前サーバーの検索」、2003年3月、進行中の作業。
[iSNS] Tseng, J., et al., "Internet Storage Name Service (iSNS)", Work in Progress, January 2003.
[ISNS] Tseng、J.、et al。、「インターネットストレージ名サービス（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.ジョン、「UPNP、ジニ、挨拶 - 将来のネットワークデバイス用の一般的な調整フレームワークを見てください」、http：//www.cswl.com/whiteppr/tech/upnp.html」、1999年6月17日。
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.
Joe Czap（IBM）、Howard Hall（Pirus）、Jack Harwood（EMC）、Yaron Klein（Sanrad）、Larry Lamers（Adaptec）、Josh Tseng（Nishan Systems）、Todd Sperry（Adaptec）は、開発中に参加し、寄付を行っており、このドキュメントの。
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.
ここで、Oracle-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-four
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-AWAREプロキシが必要になる場合があります。
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用に展開されます。
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を認識していないステートレスデバイスです。これは、ネットワークアドレス変換（NAT）を実行するために使用されます。これは、ルーティング可能なドメインと非ルート可能なドメインの間でIPアドレスをマッピングできます。また、MAP 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メッセージで返されます。とにかくこれを行うことは良い習慣です。
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.
ソックスサーバーを使用して、あるネットワークドメインから別のネットワークドメインに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サーバーは、ファイアウォール認識ではないアプリケーションに認証されたファイアウォールトラバーサルを提供します。概念的には、ソックスは、アプリケーション（つまり、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.
靴下を使用するには、ISCSIイニシエーターを変更して、ソックスライブラリのカプセル化ルーチンを使用する必要があります。その後、イニシエーターはソックスサーバーへのTCP接続を開きます。通常は標準的なソックスポート1080で開きます。その後、サブ交渉が発生し、その間にイニシエーターが認証されるか、接続要求を拒否されます。認証された場合、ソックスサーバーは、ソックスシムのイニシエーターから送信されたアドレス指定情報を使用して、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に対するその効果はポートリダイレクターの効果と同じです。
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名の独自性を確保することは、ゲートウェイの責任です。ゲートウェイは、単一の物理デバイスにアクセスできる複数のゲートウェイを考慮する必要がある場合があります。このタイプのゲートウェイは、ISCSIデバイスとして並列SCSI、ファイバーチャネル、SSA、またはその他のデバイスを提示するために使用されます。
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ゲートウェイをサポートするためのさらなる要件はありません。
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にはHTTPと同じプロキシのアドレス指定問題はありません。プロキシがターゲットに代わってイニシエーターにサービスを提供する場合、プロキシはイニシエーターがターゲットのアドレスを発見することを許可し、実際のターゲットデバイスはプロキシによってのみ発見されます。イニシエーターもISCSIプロトコルも、プロキシの存在を認識する必要はありません。SCSIゲートウェイは、2つのISCSIインターフェイス間でターゲットをマッピングするときに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データのデータ整合性チェックを分離して、プロキシを通じてデータのデータ整合性チェックをエンドツーエンドに伝播できるようにする必要があることです。
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-AWAREファイアウォールとして存在しますが、ISCSIプロキシに見られる機能を提供します。
Effects on iSCSI:
ISCSIへの影響：
- Since this is invisible, there are no additional requirements on the iSCSI protocol for this one.
- これは目に見えないため、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.
これは、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ターゲットは、そのACLを使用して、特定のISCSIイニシエーターがISCSIターゲットノードのストレージにアクセスできる（または）許可します（またはそうではない）ことができます。この形式の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の使用についてはこれ以上説明しません。
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.) 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層の認証と承認は、IPSECがTCP層の下または周辺で処理する可能性のあるものとは無関係です。つまり、イニシエーターノードは、SRP、CHAP、Kerberosなどのセキュリティ認証プロセスに何らかのタイプのセキュリティ関連識別情報（ユーザーID）を渡す必要があることを意味します（これらの認証プロセスは、このドキュメントでは説明されません。）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機能が必要です。これは、ターゲットがセキュリティ識別子（ユーザーID）情報をISCSIイニシエーターノード名にマッピングするメカニズムを必要とすることを意味します。つまり、ターゲットは、アクセスを要求するエンティティが、ログインキーワード「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.
一方、「Frank」はいくつかの異なるシステムを「所有」するローミングユーザー（またはストレージ管理者）である可能性があり、したがって、複数の異なる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 Almaden Research Center 650 Harry Road San Jose、CA 95120
EMail: kaladhar@us.ibm.com
Mark Bakke Cisco Systems, Inc. 6450 Wedgwood Road Maple Grove, MN 55311
Mark Bakke Cisco Systems、Inc。6450 Wedgwood Road Maple Grove、MN 55311
Phone: +1 763 398-1054
EMail: mbakke@cisco.com
Jim Hafner IBM Almaden Research Center 650 Harry Road San Jose, CA 95120
ジムハフナーIBMアルマデンリサーチセンター650ハリーロードサンノゼ、カリフォルニア95120
Phone: +1 408 927-1892
EMail: hafner@almaden.ibm.com
John L. Hufferd IBM Storage Systems Group 5600 Cottle Road San Jose, CA 95193
John L. Hufferd IBM Storage Systems Group 5600 Cottle Road San Jose、CA 95193
Phone: +1 408 256-0403
EMail: hufferd@us.ibm.com
Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville, CA 95747-5668, USA
Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville、CA 95747-5668、米国
Phone: +1 916 785-2656
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。