RFC3721 日本語訳
3721 Internet Small Computer Systems Interface (iSCSI) Naming andDiscovery. M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. April 2004. (Format: TXT=47564 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.バッキー要求をネットワークでつないでください: 3721年のコクチマスカテゴリ: 情報のJ.のVoruganti IBM M.クルーガーヒューレット・パッカードハーフナーJ.Hufferd K.2004年4月
Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery
インターネットの小さいコンピュータ・システムインタフェース(iSCSI)命名と発見
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントは工事というインターネットSmallコンピュータシステムズInterface(TCPの上のiSCSI or SCSI)名に関する例とiSCSI創始者によるiSCSIリソース(目標)の発見の議論を提供します。 このドキュメントはiSCSIプロトコルドキュメントの補足となります。 柔軟性はこのドキュメントの後ろの主要な指導原理です。 両方のわずかな隔離環境の需要を満たすのをすなわち、努力をしました、安全であるかスケーラブルな解決策を必要とする大きい環境と同様に。
Bakke, et al. Informational [Page 1] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[1ページ]のRFC3721iSCSI命名と発見2004年4月
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
1. iSCSI名とアドレス。 . . . . . . . . . . . . . . . . . . 3 1.1. iSCSIを組み立てると、使用はiqnと命名されます。.51.2をフォーマットしてください。 iSCSIを組み立てると、使用はeuiと命名されます。.8 2 iSCSIアリアをフォーマットしてください。 . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. 別名の目的。 . . . . . . . . . . . . . . . . . . 8 2.2. 別名. . . . . . . . . . . . . . . . . . . . . . 9 2.3を狙ってください。 創始者アリア。 . . . . . . . . . . . . . . . . . . . . 10 3iSCSI発見。 . . . . . . . . . . . . . . . . . . . . . . . 12 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 13 5. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1。 引用規格. . . . . . . . . . . . . . . . . . 13 5.2。 有益な参照. . . . . . . . . . . . . . . . . 14 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 14付録A: 注意を命名するiSCSI。 . . . . . . . . . . . . . . . . . 15 付録B: プロキシとファイアウォールとの相互作用。 . . . . . . . 16 B.1。 リダイレクタ. . . . . . . . . . . . . . . . 16B.2を移植してください。 SOCKSサーバ… 17 B.3。 SCSIゲートウェイ。 . . . . . . . . . . . . . . . . . 17 B.4iSCSIプロキシ.18B.5。 ステートフルインスペクションファイアウォール。 . . . . . . . . . 18 付録C: iSCSI名とセキュリティー識別子。 . . . . . . . . 19人の作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . 21 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 22
Bakke, et al. Informational [Page 2] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[2ページ]のRFC3721iSCSI命名と発見2004年4月
1. iSCSI Names and Addresses
1. iSCSI名とアドレス
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 Nodeです。 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州の情報(モードのページの設定内容予約など)と認可構成の損失なしでホストの間のネットワークHBAsの無料の運動を確実にするために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:
<ドメイン名>が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.
- ドット付き10進法によるIPv4アドレス。 名前がちょうどドットによって切り離された4つの番号を含んでいるなら想定される、()、各数が範囲0にあります。255.
- IPv6 address, in colon-separated hexadecimal notation, as
specified in [RFC3513] and enclosed in "[" and "]" characters, as
specified in [RFC2732].
- そして、IPv6が[RFC3513]で指定されて中の同封にされるとしてコロンで切り離された16進法で記述する、「[「」、]、」 [RFC2732]で指定されるようなキャラクタ。
- Fully Qualified Domain Name (host name). Assumed if the <domain-
name> is neither an IPv4 nor an IPv6 address.
- 完全である、Qualified 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目標において、アドレスの<ポート>は任意です。 指定されるなら、それは目標が接続の聞こうとすることであるTCPポートです。 <ポート>が指定されないと、IANAによって割り当てられたデフォルトポート3260は想定されるでしょう。 iSCSI創始者に関しては、<ポート>は省略されます。
Bakke, et al. Informational [Page 3] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[3ページ]のRFC3721iSCSI命名と発見2004年4月
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: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 Nameは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 AddressはiSCSIノードのiSCSI名だけではなく、そのノードの位置も指定します。 アドレスはノードのホスト名かIPアドレスと、TCPポートナンバー(目標のための)と、iSCSI Nameから成ります。 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: 1960年3月333-44-5555 14日に、以下に電話をしてください。 +1(763)555.1212ホームアドレス: 555 街道、ミネアポリス、ミネソタ 55444はアドレスを扱います: 222 セントポール、ミネソタ 高速道路Blvd、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.
この場合、ロバートのグローバルにユニークな名前は、Birthの本当に彼の社会保障のNumberとDateです。 「ロバート・スミス」という彼の一般名は、特有になるように保証されません。 ロバートには、連絡されるかもしれない3つの位置があります。 2つのPhysicalアドレス、および電話番号。
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 Nameに似ています、そして、(生年月日が再利用されたSSNsのあいまいさを除くのに必要です)彼の電話番号とアドレスはiSCSIノードのTCPアドレスに類似しています、そして、「ロバート・スミス」はこの人のための人間に優しいラベルでしょう。
Bakke, et al. Informational [Page 4] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[4ページ]のRFC3721iSCSI命名と発見2004年4月
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目標と創始者か、目標か創始者を含む装置により人間読み込み可能なユーザーインタフェースを供給するのを助けるのが別名を提供するかもしれません。 この別名は、iSCSIプロトコルの中で創始者か装置を特定するのにおいて簡単なUTF-8ストリングでなく、またグローバルにユニークでなく、また決して解釈されていなくて、また使用されていません。 使用はセクション2で、より詳しく説明されます。
1.1. Constructing iSCSI names using the iqn. format
1.1. iSCSIを組み立てると、iqnを使用するのは. 形式と命名されます。
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]で定義されて、(in order)を含んでいます:
- 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
+--++-----+ +---------+ +--------------------------------+
| || | | | | |
Type Date Auth Org Local Naming Authority+による組織的なSubgroup Naming Authority Naming、そして/または、ストリングDefined--+ +-----+ +---------+ +--------------------------------+ | || | | | | |
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の適切な名の使用を指定します。
Bakke, et al. Informational [Page 5] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[5ページ]のRFC3721iSCSI命名と発見2004年4月
"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、-4インチがそうである、命名権威がこの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名であり、組織的な命名権威を定義します。 "example.com"というDNS名の所有者には、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 Namesが通し番号に基づいているとちょうど仮定したかもしれませんが、それらは、恐らく後で製品が他の何かによって特定されるほうがよいと思いました。 "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
iqn.2001-04.com.example.storage.tape: sys1.xyz
Bakke, et al. Informational [Page 6] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[6ページ]のRFC3721iSCSI命名と発見2004年4月
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.
'それに注意してください、':'分離符、両方の名前は同じです。 1番目は"storage.example.com"というサブドメインの所有者によって割り当てられました。 2番目は"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
Type Date Authority Cs dept User「オーク」+++によるDefinedはDefinedを命名します。-----+ +------------+ +--------+ +-----------+ | | | | | | | | | | 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.
上記の例では、Example大学のOaks教授はiSCSI目標の研究手本を築き上げています。 '各ユーザはこのタイプの仕事に命名権威としてEUのコンピュータサイエンス部でその人のユーザ名を使用できます、後の「ユーザ<ユーザ名>」を付けることによって': '別のもの、': '続かれて、ユーザのストリングは選ばれています(ユーザはこの部分をユニークにするのに責任があります)。 Oaks教授は、「この特定の目標のための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
組織はOrgによって定義された命名を結びます。 +++と権威を命名する日付の権威をタイプしてください。-----+ +-------------+ +----------------------+ | | | | | | | | iqn.1995-11.com.example.ssp: 顧客.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.
Storage Service Provider(SSP)は、顧客のひとりのためのこの特定の目標の上のiSCSI Nameを構成して、それらのCustomer 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
これらのドメイン名を逆にするとき、最初のコンポーネント("iqn"の後の)がいつもこと"com"、"edu"が「orgに」「ネット」、「ミル」、または1つを最上位のドメイン名、どのインクルードの"govする"であるかであることに注意してください。
Bakke, et al. Informational [Page 7] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[7ページ]のRFC3721iSCSI命名と発見2004年4月
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.
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目標か創始者の位置の含意を全く含んでいません。 ドメイン名の使用は既に遍在している名前スペースを再使用する方法にすぎません。
1.2. Constructing iSCSI names using the eui. format
1.2. iSCSIを組み立てると、euiを使用するのは. 形式と命名されます。
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名を構成する際にIEEE EUI-64識別子を使用する命名権威が許容されるiSCSI eui。 EUI-64識別子を構成する詳細はIEEE Registration Authorityによって指定されます([EUI64]を見てください)。
Example iSCSI name:
例のiSCSI名:
Type EUI-64 identifier (ASCII-encoded hexadecimal)
+--++--------------+
| || |
eui.02004567A425678D
タイプEUI-64識別子(ASCIIによってコード化された16進)+--+ +--------------+ | || | eui.02004567A425678D
2. iSCSI Alias
2. iSCSIアリア
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のキャラクタであり、少なくとも1NULL(0×00)のキャラクタと共に終えられます、[RFC3720]で定義されるように。 非重要構造は全くこのストリングに課されません。
2.1. Purpose of an Alias
2.1. 別名の目的
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
創始者と目標はiSCSI Nameによって唯一特定されます。 これらの識別子はハードウェア、ソフトウェア製造業者、サービスプロバイダー、または顧客によってさえ割り当てられるかもしれません。 これらの識別子は名目上は人間読み込み可能ですが、それらは反対側のものと異なった観点から割り当てられそうです。
Bakke, et al. Informational [Page 8] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[8ページ]のRFC3721iSCSI命名と発見2004年4月
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.
接続について。 例えば、ディスクアレイへの目標名はアレイの通し番号、およびある種の内部の目標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.
目標と創始者の両方には、別名があるかもしれません。
2.2. Target Alias
2.2. アリアを狙ってください。
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ディスクを必要として、格納サービス人が(内部か外部)であると言います、記憶装置がホストのために必要とする認証情報を与えて。 サービス人は、ホストのために新しい目標を割り当てて、新しい目標、およびたぶんアドレスのためにTarget Nameを送ります、ユーザに。 ユーザは、次に、このTarget Nameをホストに関する構成ファイルに追加して、新しい装置を発見します。
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 | +--------------------------------------------------
+--これらの目標に関連づけられます。---------------------- | | 目標名| | 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| +--------------------------------------------------
Bakke, et al. Informational [Page 9] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[9ページ]のRFC3721iSCSI命名と発見2004年4月
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 Namesにもかかわらず、彼らがいることに関するどんな本当の記述でも収集を見ません。 それらがそうする、もちろん、システム依存するデバイスファイルかドライブ名への地図、しかし、すべてがそこにあるかどうか確認するためにすぐに数を見るのは簡単ではありません。
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 | +--------------------------------------------------
+--これらの目標に関連づけられます。---------------------- | | 別名目標名| | オラクル1iqn.1995-04.com.example: sn.5551212.target.450| 地方のDisk iqn.1995-04.com.example: sn.5551212.target.489| 交換2iqn.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.
純真な創始者が別名情報を保ちたくはありませんし、ログイン応答で見られて、表示したくないなら、単にそれを無視できることに注意してください。
2.3. Initiator Alias
2.3. 創始者アリア
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 Initiator Nameを送るとき、創始者はログイン要求における別名を送るかもしれません。 管理グラフィカルユーザインタフェイス(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.
それにそれを表示する管理インタフェースが全くないなら簡単な目標がただInitiatorアリア一家を無視できることに注意してください。
Bakke, et al. Informational [Page 10] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[10ページ]のRFC3721iSCSI命名と発見2004年4月
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".
通常、まさしくホスト名は創始者別名に十分でしょうが、必要であるなら、カスタム別名はサービスプロバイダーのために構成されるかもしれません。 さらに良いのは、マシンが何に使用されたかに関する記述でしょう、「交換サーバ1インチ、または「ユーザウェブサーバー」」などのように。
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 | +--------------------------------------------------
+--これらの創始者に接されます。------------------- | | 目標創始者名| | 450iqn.1995-04.com.example.sw: cd.12345678OEM456| 451iqn.1995-04.com.example.os: hostid.A598B45C| 309iqn.1995-04.com.example.sw: cd.87654321OEM259| +--------------------------------------------------
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... | +--------------------------------------------------
+--これらの創始者に接されます。------------------- | | 目標別名創始者名| | 450 ウェブServer4iqn.1995-04.com.example.sw: cd.12… | 451 scsigw.example.com iqn.1995-04.com.example.os: hosti… | 309は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.
これはだれがそれらの目標に接続されるかに関する、より良い考えを格納管理者に与えます。 もちろん、1つはホスト名を決定するためにいつも入って来る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を送ります。 別名が受け取られているなら、それは、合わないか、または何らかの方法で無効に見えて、それは無視されます。
Bakke, et al. Informational [Page 11] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[11ページ]のRFC3721iSCSI命名と発見2004年4月
3. iSCSI Discovery
3. iSCSI発見
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装置の主要な管理を指定するのを試みを全くしません。 そのうえ、ここに記載されたメカニズムが目標発見と1つに対処するだけであるという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ポート情報が既に利用可能であると仮定します。 そして、創始者は、発見セッションをNetwork Entityに証明するのにこの情報を使用します。 そして、創始者は次に、特定のNetwork Entity(IPアドレス)で利用可能なiSCSI目標の情報について質問するSendTargetsテキストコマンドを発行します。 iSCSIドキュメント[RFC3720]でSendTargetsコマンドの詳細を見つけることができます。 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
c。 無構成: このメカニズムは、創始者には目標の少しの情報もないと仮定します。 このオプション、マルチキャスト発見が直接通信する創始者缶
Bakke, et al. Informational [Page 12] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[12ページ]のRFC3721iSCSI命名と発見2004年4月
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.
目標かそれが発見メッセージをストレージネームサーバに送ることができます。 現在、Salutation[ジョン]や、ジニー[ジョン]や、UPnP[ジョン]や、SLP[RFC2608]やiSNS[iSNS]などのように利用可能な多くの汎用の発見フレームワークがあります。 しかしながら、iSCSIに関して、SLPは明確に、必要な発見機能[iSCSI-SLP]を実行できます、通知を含む関連する管理機能を提供するのに、iSNS[iSNS]を使用できて、拡張発見管理能力が、より大きいストレージネットワークなどのように必要であるときに、発見管理SendTargetsで発見機能を必要とするアクセス経営者側、構成、およびiSCSI設備はSLPを少なくとも実装して、次に、iSNSを考えるはずですが。 iSNSがSLPをサポートするので情報がSLPで戻ったという発見を管理するのを助けるのにiSNSを使用できることに注意されるべきです。
4. Security Considerations
4. セキュリティ問題
Most security issues relating to iSCSI naming are discussed in the main iSCSI document [RFC3720] and the iSCSI security document [RFC3723].
主なiSCSIドキュメント[RFC3720]とiSCSIセキュリティドキュメント[RFC3723]でiSCSI命名に関係するほとんどの安全保障問題について議論します。
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.
さらに、Appendix 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ノード名と異なっているかもしれません)。 さらに詳細にAppendix Cでこれについて議論します。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[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)を連結します」、RFC3720、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.ウェーバー他、INCITS T10 Project 1157-D改正24、「SCSIの建築モデル--、2(SAM-2)、」、セクション4.7.6「SCSI装置名」(2002年9月)
Bakke, et al. Informational [Page 13] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[13ページ]のRFC3721iSCSI命名と発見2004年4月
5.2. Informative References
5.2. 有益な参照
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "SLP
Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、パーキンス、C.、Veizades、J.、およびM.日、「SLP、バージョン2インチ、RFC2608、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.と大工とB.とL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
解放された[RFC2979]、N.、「インターネットのための振舞いと要件ファイアウォール」、RFC2979、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、および「Middlebox通信アーキテクチャとフレームワーク」、RFC3303(2002年8月)
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
Addressing Architecture", RFC 3513, April 2003.
[RFC3513] HindenとR.とS.デアリング、「インターネットプロトコルバージョン6アドレッシング体系」、RFC3513、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の上でブロックストレージがプロトコルであると機密保護します」、RFC3723、2004年4月。
[iSCSI-SLP] Bakke, M., et al., "Finding iSCSI Targets and Name
Servers using SLP", Work in Progress, March 2003.
[iSCSI-SLP] バッキー、M.、他、「SLPを使用することでiSCSI目標とネームサーバを見つける」Progress、2003年3月のWork。
[iSNS] Tseng, J., et al., "Internet Storage Name Service
(iSNS)", Work in Progress, January 2003.
[iSNS] ツェン、J.、他、「インターネットストレージ名前サービス(iSNS)」、ProgressのWork、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.
1999年6月17日の「[ジョン]R.ジョン、「UPnP、ジニー、およびSalutation未来のいくつかのポピュラーなコーディネートフレームワークへの一見はデバイスをネットワークでつなぎました」、 http://www.cswl.com/whiteppr/tech/upnp.html 。」
6. Acknowledgements
6. 承認
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)、ハワードHall(Pirus)、ジャックHarwood(EMC)、ヤロンクライン(SANRAD)、ラリーLamers(Adaptec)、ジョッシュTseng(Nishan Systems)、およびトッドスペリー(Adaptec)は、このドキュメントの開発の間、参加して、貢献をしています。
Bakke, et al. Informational [Page 14] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[14ページ]のRFC3721iSCSI命名と発見2004年4月
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 Nameは対向機器に交換して、動かすことができるインタフェースハードウェア、または他のハードウェアに基づいて決して割り当てられるべきではありません。
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.
2FQDNsの使用に注意してください--命名権威のものと命名されているホストのものも。 これはiSCSI Nameのサイズに課された制限のため問題を起こすことができます。
- 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.12345OEM0067890-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が一度より使用されるならこれが壊れることに注意してください。 OSベンダーの哲学によって、これは特徴であるかもしれません。
- Assign to the Raid Array by a service provider
- サービスプロバイダーによるRaid Arrayへの案配
iqn.2001-04.com.example.myssp:users.mbakke05657
iqn.2001-04.com.example.myssp: users.mbakke05657
Bakke, et al. Informational [Page 15] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[15ページ]のRFC3721iSCSI命名と発見2004年4月
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目標がものか数人の創始者によってアクセスされるだけであることになっているかもしれません。 すべてを発見するのは不要でしょう。
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. 多くの環境がIPが「10」などのように. ネットワークに演説する非発送可能を使用します。
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]とプロキシはiSCSIのために配布されるでしょう、既にHTTPやFTPなどのプロトコルを扱うものと同様です。
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アドレスを写像できるNetwork Address Translation(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ヘッダーからの情報を含んではいけません、創始者と目標の間でこれらを変えるとき。
Bakke, et al. Informational [Page 16] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[16ページ]のRFC3721iSCSI命名と発見2004年4月
- 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 Nameを使用するのに優れています。
- 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発見接続がポートリダイレクタを通して使用されることになっているとき、目標はSendTargets応答におけるIPアドレスの代わりにドメイン名を返すために構成されなければならないでしょう、ポートリダイレクタがiSCSIメッセージで返されたIPアドレス(es)を写像できないので。 とにかくこれをするのは、良い習慣です。
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.
1つのネットワークドメインから別のドメインまでのTCP接続を写像するのにSOCKSサーバを使用できます。 それはそれぞれの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を使用するなら、SOCKS図書館でカプセル化ルーチンを使用するようにiSCSI創始者を変更しなければなりません。 そして、創始者はSOCKSサーバと、そして、通常正準なSOCKSポート1080の上に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
このゲートウェイは、論理的な目標(iSCSI Names)を創始者に提示して、選ぶようにSCSI目標に彼らを写像します。 創始者は、本当のiSCSI目標であるとこのゲートウェイをみなして、どんなプロキシやゲートウェイの振舞いにも気づきません。 ゲートウェイは、それ自身のiSCSI Namesを製造しているか、または物理的なSCSIデバイスによって提供された情報を使用するiSCSI名を写像するかもしれません。 それはゲートウェイの責任です。
Bakke, et al. Informational [Page 17] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[17ページ]のRFC3721iSCSI命名と発見2004年4月
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名のユニークさも確実にしてください。 ゲートウェイは単一のフィジカル・デバイスに近づく手段を持っている複数のゲートウェイの原因にならなければならないかもしれません。 このタイプのゲートウェイは、iSCSIデバイスとして平行なSCSI、Fibre Channel、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 Nameだけが、通過される必要があります。 iSCSIで既にこれをするので、SCSIにゲートウェイを支えるという要件がこれ以上ありません。
B.4. iSCSI Proxy
B.4iSCSIプロキシ
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創始者の1セットの目標の発見か構成がアドレスの独立しているiSCSI名を利用するので、iSCSIは、同じプロキシがHTTPとしてその問題を訴えるのを持っていません。(HTTPはURLにアドレス情報を含んでいます)。 プロキシが目標を代表して創始者に対するサービスを提供するつもりであるなら、プロキシは創始者に目標のためのアドレスを発見させます、そして、実際の対象装置は単にプロキシによって発見されます。 創始者も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.
- これが目に見えないので、これのためのiSCSIプロトコルに関するどんな追加要件もありません。
Bakke, et al. Informational [Page 18] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[18ページ]のRFC3721iSCSI命名と発見2004年4月
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(反-Militarized Zone)[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 Node Namesの作成と使用について説明しました。 これが十分な形式の識別である環境は信じられるでしょう。 これらの環境で、iSCSI TargetはAccess Control List(ACL)を持っているかもしれません。(Access Control Listは制限されたリソース(この場合Target Storage Controller)にアクセスすることが許可されている権限のある機関のリストを含むでしょう)。 そして、iSCSI Targetは、(or not)のあるiSCSI InitiatorsがiSCSI Target Nodeでストレージにアクセスすることを許可するのにその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.
また、Initiatorと共にLUNsの適切なSCSI協会のためのSCSI層に関連してACLとiSCSI Initiator Node Nameを使用できるのも可能です。 さらに本書では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 Nodesが信頼されていない環境で存在するところにあるでしょう。 すなわちいくつかのiSCSI Initiator NodesがiSCSI Target Nodeにアクセスするのを認可するかもしれなくて、信頼されていない環境のために、しかしながら、ネットワークのノードが正しいiSCSI Initiator Node Namesに与えると信じることができません。
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.)
層かIPSecが扱うかもしれないものは何でもの如何にかかわらずTCP層の周りにiSCSI層の認証と承認があります。 これは、タイプのセキュリティを通過する創始者ノードの必要性が識別情報(例えば、ユーザID)にSRP、ケルベロスCHAPなどのセキュリティ認証過程に関連したことを意味します。 (本書ではこれらの認証過程について議論しないでしょう。)
Bakke, et al. Informational [Page 19] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[19ページ]のRFC3721iSCSI命名と発見2004年4月
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セキュリティ認証の完成のときに、インストールは、「だれ」がアクセサリーを求める要求を送ったかを知っています。 そして、インストールは、そのような要求が特定された実体から受入れられるか、または認可されているのを保証するためにチェックしなければなりません。 一般に、Authorizationのこのフォームは上で説明されるようにAccess Control List(ACL)を通して達成されます。 この承認プロセスを使用して、iSCSI目標は、実体がiSCSI Target Nodeにアクセスするのが認可されるのを知るでしょう。
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.
インストールが機密保護コード識別機構情報(例えば、UserID)がiSCSI Initiator Node Nameと等しいという規則を設定するのは、可能であるかもしれません。 その場合、上で説明された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 Initiator Node Nameがセキュリティー識別子として使用されないなら、より入念なACLの機能性の必要があります。 これは、目標がセキュリティー識別子(例えば、UserID)情報をiSCSI Initiator Node Nameに写像するためにメカニズムを必要とすることを意味します。 すなわち、目標はアクセスを要求する実体がLogin Keyword「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創始者を通して目標にアクセスするのに権限を与えることができたローミングユーザ(または、Storage Administrator)であることは可能です。 この場合、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 Initiator Node Namesに対処しながら、制御されますが、あるiSCSI環境には、また、他の補足的なセキュリティー識別子の必要があるかもしれません。
Bakke, et al. Informational [Page 20] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[20ページ]のRFC3721iSCSI命名と発見2004年4月
Authors' Addresses
作者のアドレス
Kaladhar Voruganti IBM Almaden Research Center 650 Harry Road San Jose, CA 95120
Kaladhar Voruganti IBMアルマデンリサーチセンター650ハリー・Roadサンノゼ、カリフォルニア 95120
EMail: kaladhar@us.ibm.com
メール: kaladhar@us.ibm.com
Mark Bakke Cisco Systems, Inc. 6450 Wedgwood Road Maple Grove, MN 55311
マークバッキーシスコシステムズInc.6450ウェッジウッド道路メープル・グローヴ、ミネソタ 55311
Phone: +1 763 398-1054 EMail: mbakke@cisco.com
以下に電話をしてください。 +1 763 398-1054 メールしてください: mbakke@cisco.com
Jim Hafner IBM Almaden Research Center 650 Harry Road San Jose, CA 95120
ジムハーフナーIBMアルマデンResearch Center650ハリー・Roadサンノゼ、カリフォルニア 95120
Phone: +1 408 927-1892 EMail: hafner@almaden.ibm.com
以下に電話をしてください。 +1 408 927-1892 メールしてください: hafner@almaden.ibm.com
John L. Hufferd IBM Storage Systems Group 5600 Cottle Road San Jose, CA 95193
ジョンL.Hufferd IBMストレージシステムは5600コットル・Roadサンノゼ、カリフォルニア 95193を分類します。
Phone: +1 408 256-0403 EMail: hufferd@us.ibm.com
以下に電話をしてください。 +1 408 256-0403 メールしてください: hufferd@us.ibm.com
Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville, CA 95747-5668, USA
Blvdローズビル、マージョリークルーガーヒューレット・パッカード社8000のフットヒルズカリフォルニア95747-5668(米国)
Phone: +1 916 785-2656 EMail: marjorie_krueger@hp.com
以下に電話をしてください。 +1 916 785-2656 メールしてください: marjorie_krueger@hp.com
Bakke, et al. Informational [Page 21] RFC 3721 iSCSI Naming and Discovery April 2004
バッキー、他 情報[21ページ]のRFC3721iSCSI命名と発見2004年4月
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bakke, et al. Informational [Page 22]
バッキー、他 情報[22ページ]
一覧
スポンサーリンク
