Network Working Group C. Monia
Request for Comments: 4174 Consultant
Category: Standards Track J. Tseng
Riverbed Technology
K. Gibbons
McDATA Corporation
September 2005
The IPv4 Dynamic Host Configuration Protocol (DHCP) Option
for the Internet Storage Name Service
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network.
この文書は、インターネットストレージネームサービス（iSNS）クライアントは自動的にIPv4のDHCPを使用してiSNSサーバーの場所を発見できるようにする動的ホスト構成プロトコル（DHCP）オプションを説明します。 ISNは、エンタープライズ規模のIPストレージ・ネットワーク内のインターネットSCSI（iSCSIの）とインターネットファイバチャネルプロトコル（iFCPゲート）ストレージデバイスの検出と管理機能を提供します。 ISNはコモディティIPネットワークがストレージ・エリア・ネットワークと同様に機能できるようになり、ファイバチャネルネットワークに見られるものに匹敵するインテリジェントなストレージ管理サービスを提供しています。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 2
2. iSNS Option for DHCP ......................................... 3
2.1. iSNS Functions Field ................................... 5
2.2. Discovery Domain Access Field .......................... 6
2.3. Administrative Flags Field ............................. 7
2.4. iSNS Server Security Bitmap ............................ 8
3. Security Considerations ...................................... 9
4. IANA Considerations .......................................... 11
5. Normative References ......................................... 11
6. Informative References ....................................... 11
The Dynamic Host Configuration Protocol for IPv4 provides a framework for passing configuration information to hosts. Its usefulness extends to hosts and devices using the iSCSI and iFCP protocols to connect to block level storage assets over a TCP/IP network.
IPv4のための動的ホスト構成プロトコル、ホストに設定情報を渡すためのフレームワークを提供します。その有用性は、TCP / IPネットワーク上のレベルのストレージ資産をブロックするように接続するためにiSCSIとのiFCPプロトコルを使用して、ホストとデバイスに及びます。
The iSNS Protocol provides a framework for automated discovery, management, and configuration of iSCSI and iFCP devices on a TCP/IP network. It provides functionality similar to that found on Fibre Channel networks, except that iSNS works within the context of an IP network. iSNS thereby provides the requisite storage intelligence to IP networks that are standard on existing Fibre Channel networks.
iSNSのプロトコルは、TCP / IPネットワーク上のiSCSIおよびiFCPゲートデバイスの自動検出、管理、および設定のためのフレームワークを提供します。これは、iSNSは、IPネットワークのコンテキスト内で動作することを除いて、ファイバチャネルネットワーク上で見られるものと同様の機能を提供します。 ISNは、それによって既存のファイバチャネルネットワークに標準装備されてIPネットワークに必要なストレージ・インテリジェンスを提供します。
Existing DHCP options cannot be used to find iSNS servers for the following reasons:
既存のDHCPオプションには、以下の理由により、iSNSサーバーを見つけるために使用することはできません。
a) iSNS functionality is distinctly different from other protocols using DHCP options. Specifically, iSNS provides a significant superset of capabilities compared to typical name resolution protocols such as DNS. It is designed to support client devices that allow themselves to be configured and managed from a central iSNS server.
A）のiSNS機能は、DHCPオプションを使用して他のプロトコルとは明確に異なっています。具体的には、ISNはDNSなどの一般的な名前解決プロトコルと比較して機能の有意なスーパーセットを提供します。それ自体は、中央のiSNSサーバから設定および管理することを可能にするクライアントデバイスをサポートするように設計されています。
b) iSNS requires a DHCP option format that provides more than the location of the iSNS server. The DHCP option has to specify the subset of iSNS services that may be actively used by the iSNS client.
B）ISNは、iSNSサーバの場所よりも多くを提供してDHCPオプションのフォーマットが必要です。 DHCPオプションは、積極的にiSNSクライアントが使用することができるのiSNSサービスのサブセットを指定する必要があります。
The DHCP option number for iSNS is used by iSCSI and iFCP devices to discover the location and role of the iSNS server. The DHCP option number assigned for iSNS by IANA is 83.
iSNSのためのDHCPオプション番号は、iSNSサーバの位置と役割を発見するためにiSCSIとのiFCPデバイスで使用されます。 IANAによってiSNSのに割り当てられたDHCPオプション番号は83です。
iSNS refers to the Internet Storage Name Service framework, which consists of the storage network model and associated services.
ISNは、ストレージネットワークモデルおよび関連サービスで構成され、インターネットストレージネームサービスフレームワークを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
All frame formats are in big-endian network byte order. RESERVED fields SHOULD be set to zero.
すべてのフレームフォーマットは、ビッグエンディアンネットワークバイト順です。 RESERVEDフィールドはゼロに設定する必要があります。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
"iSNS Client" - iSNS clients are processes resident in iSCSI and iFCP devices that initiate transactions with the iSNS server using the iSNS Protocol.
「iSNSクライアント」 - iSNSクライアントは、iSNSプロトコルを使用してiSNSサーバーとのトランザクションを開始iSCSIとのiFCPデバイス内のプロセスに常駐しています。
"iSNS Server" - The iSNS server responds to iSNS protocol query and registration messages and initiates asynchronous notification messages. The iSNS server stores information registered by iSNS clients.
「iSNSのサーバ」 - iSNSサーバーは、iSNSプロトコルクエリと登録メッセージに応答して、非同期通知メッセージを開始します。 iSNSサーバーは、iSNSクライアントが登録した情報を格納します。
"iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a new generation of storage devices interconnected with TCP/IP.
「iSCSIの（インターネットSCSI）は、」 - iSCSIはTCP / IPで相互接続されたストレージデバイスの新世代のためのSCSIのカプセル化したものです。
"iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to-gateway protocol designed to interconnect existing Fibre Channel devices using TCP/IP. iFCP maps the Fibre Channel transport and fabric services to TCP/IP.
「のiFCP（インターネットファイバチャネルプロトコル）」 - のiFCPは、TCP / IPを使用して、既存のファイバチャネルデバイスを相互接続するために設計されたゲートウェイ間のプロトコルです。 iFCPゲートは、TCP / IPにファイバ・チャネル・トランスポートとファブリックサービスをマッピングします。
This option specifies the location of the primary and backup iSNS servers and the iSNS services available to an iSNS client.
このオプションは、プライマリおよびバックアップiSNSサーバーとiSNSクライアントが利用できるのiSNSサービスの場所を指定します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code = 83 | Length | iSNS Functions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD Access | Administrative FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| iSNS Server Security Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a1 | a2 | a3 | a4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b1 | b2 | b3 | b4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . |
| Additional Secondary iSNS Servers |
| . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. iSNS Server Option
図1のiSNSサーバオプション
The iSNS Option specifies a list of IP addresses used by iSNS servers. The option contains the following parameters:
iSNSのオプションは、iSNSサーバが使用するIPアドレスのリストを指定します。オプションには、次のパラメータが含まれています。
Length: The number of bytes that follow the Length field.
長さ：長さフィールドに続くバイト数。
iSNS Functions: A bitmapped field defining the functions supported by the iSNS servers. The format of this field is described in section 2.1.
iSNSの機能：iSNSサーバーでサポートされている関数を定義するビットマップフィールド。このフィールドのフォーマットは、セクション2.1に記載されています。
Discovery Domain Access: A bit field indicating the types of iSNS clients that are allowed to modify Discovery Domains. The field contents are described in section 2.2.
ディスカバリードメインアクセス：検出ドメインを変更することが許可されているiSNSクライアントの種類を示すビットフィールド。フィールドの内容は、セクション2.2に記載されています。
Administrative Flags field: Contains the administrative settings for the iSNS servers discovered through the DHCP query. The contents of this field are described in section 2.3.
行政Flagsフィールド：DHCPクエリーによって発見されたのiSNSサーバの管理設定が含まれています。このフィールドの内容は、セクション2.3で説明されています。
iSNS Server Security Bitmap: Contains the iSNS server security settings specified in section 2.4.
iSNSサーバーのセキュリティのビットマップ：セクション2.4で指定されたiSNSサーバーのセキュリティ設定が含まれています。
a1...a4: Depending on the setting of the Heartbeat bit in the Administrative Flags field (see section 2.3), this field contains either the IP address from which the iSNS heartbeat originates (see [iSNS]) or the IP address of the primary iSNS server.
A1 ... A4は：管理フラグ欄にハートビートビット（セクション2.3を参照）の設定によっては、このフィールドは、iSNSが発信ハートビート、そこからIPアドレス（[iSNSの]参照）、またはIPアドレスのいずれかが含まれています主iSNSサーバー。
b1...b4: Depending on the setting of Heartbeat bit in the Administrative Flags field (see section 2.3), this field contains either the IP address of the primary iSNS server or that of a secondary iSNS server.
B1 ... B4：管理フラグ欄にハートビートビットの設定に応じて、このフィールドには、IPプライマリiSNSサーバーのアドレスまたはセカンダリiSNSサーバーのいずれかが含まれています（セクション2.3を参照してください）。
Additional Secondary iSNS Servers: Each set of four octets specifies the IP address of a secondary iSNS server.
追加のセカンダリiSNSサーバー：4つのオクテットの各セットは、セカンダリiSNSサーバーのIPアドレスを指定します。
The Code field through IP address field a1...a4 MUST be present in every response to the iSNS query; therefore the Length field has a minimum value of 14.
CodeフィールドIPアドレスフィールドA1を通じ... A4は、iSNSクエリへのすべての応答中に存在しなければなりません。したがって、長さフィールドは14の最小値を有します。
If the Heartbeat bit is set in the Administrative Flags field (see section 2.3), then b1...b4 MUST also be present. In this case, the minimum value of the Length field is 18.
ハートビートビットが管理Flagsフィールドに設定されている場合（セクション2.3を参照）、その後、B1 ... B4も存在しなければなりません。この場合、長さフィールドの最小値は18です。
The inclusion of Additional Secondary iSNS Servers in the response MUST be indicated by increasing the Length field accordingly.
応答内の追加セカンダリiSNSサーバーを含めることは、それに応じて長さフィールドを増加させることによって示されなければなりません。
The iSNS Functions Field defines the iSNS server's operational role (i.e., how the iSNS server is to be used). The iSNS server's role can be as basic as providing simple discovery information, or as significant as providing IKE/IPSec security policies and certificates for the use of iSCSI and iFCP devices. The format of the iSNS Functions field is shown in Figure 2.
iSNSの機能フィールドは、iSNSサーバの運用役割を定義する（すなわち、iSNSサーバがどのように使用されますか）。 iSNSサーバーの役割は、単純な発見情報、またはiSCSIとのiFCPデバイスの使用のためのIKE / IPSecセキュリティポリシーおよび証明書を提供するほど重要なの提供などといった基本的なことができます。 iSNSの関数フィールドのフォーマットは、図2に示されています。
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |S|A|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. iSNS Functions Field
図2のiSNS機能フィールド
Bit Field Significance
--------- ------------
15 Function Fields Enabled
14 DD-Based Authorization
13 Security Policy Distribution
The following are iSNS Functions Field definitions:
以下は、iSNS機能フィールドの定義です：
Function Fields Specifies the validity of the remaining Enabled: iSNS Function fields. If it is set to one, then the contents of all other iSNS Function fields are valid. If it is set to zero, then the contents of all other iSNS Function fields MUST be ignored.
iSNSの機能分野：機能フィールドは、残りの有効の妥当性を指定します。それが1に設定されている場合、他のすべてのiSNS機能フィールドの内容が有効です。それがゼロに設定されている場合は、他のすべてのiSNS機能フィールドの内容は無視しなければなりません。
DD-based Indicates whether devices in a common Authorization: Discovery Domain (DD) are implicitly authorized to access one another. Although Discovery Domains control the scope of device discovery, they do not necessarily indicate whether a domain member is authorized to access discovered devices. If this bit is set to one, then devices in a common Discovery Domain are automatically allowed access to each other (if successfully authenticated). If this bit is set to zero, then access authorization is not implied by domain membership and must be explicitly performed by each device. In either case, devices not in a common discovery domain are not allowed to access each other.
DDベースの共通認証内のデバイスかどうかを示します：ディスカバリードメイン（DD）は、暗黙的にお互いにアクセスすることを許可されています。検出ドメインは、デバイス検出の範囲を制御するが、それらは必ずしもドメインメンバーは、デバイスを発見したアクセスを許可されているかどうかを示すものではありません。このビットが1に設定されている場合（認証に成功した場合）、そして共通検出ドメイン内のデバイスは、互いへのアクセスを自動的に許可されています。このビットがゼロに設定されている場合、アクセス許可は、ドメインメンバシップによって暗示されていないと明示的に各デバイスによって実行されなければなりません。いずれの場合も、一般的なディスカバリドメイン内のデバイスではないが、互いへのアクセスが許可されていません。
Security Policy Indicates whether the iSNS client is to Distribution: download and use the security policy configuration stored in the iSNS server. If it is set to one, then the policy is stored in the iSNS server and must be used by the iSNS client for its own security policy. If it is set to zero, then the iSNS client must obtain its security policy configuration by other means.
iSNSサーバーに保存されたセキュリティポリシーの設定をダウンロードして使用します。セキュリティポリシーは、iSNSクライアントが配布しているかどうかを示します。それが1に設定されている場合は、そのポリシーは、iSNSサーバに格納されており、独自のセキュリティポリシーのためにiSNSクライアントによって使用されなければなりません。それがゼロに設定されている場合は、iSNSクライアントは、他の手段によって、そのセキュリティポリシーの設定を取得する必要があります。
The format of the DD Access bit field is shown in Figure 3.
DDアクセス・ビット・フィールドのフォーマットが図3に示されています。
0 1 1 1 1 1 1
0 ... 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+
| RESERVED | if| tf| is| ts| C | E |
+---+---+---+---+---+---+---+---+---+
Figure 3. Discovery Domain Access Field
図3.ディスカバリードメインアクセスフィールド
Bit Field Significance
--------- ------------
15 Enabled
14 Control Node
13 iSCSI Target
12 iSCSI Initiator
11 iFCP Target Port
10 iFCP Initiator Port
The following are Discovery Domain Access Field definitions:
以下のディスカバリードメインアクセスフィールドの定義です：
Enabled: Specifies the validity of the remaining DD Access bit field. If it is set to one, then the contents of the remainder of the DD Access field are valid. If it is set to zero, then the contents of the remainder of this field MUST be ignored.
有効：残りDDアクセスビットフィールドの有効性を指定します。それが1に設定されている場合、DD Accessフィールドの残りの部分の内容が有効です。それがゼロに設定されている場合、このフィールドの残りの内容は無視しなければなりません。
Control Node: Specifies whether the iSNS server allows Discovery Domains to be added, modified, or deleted by means of Control Nodes. If it is set to one, then Control Nodes are allowed to modify the Discovery Domain configuration. If it is set to zero, then Control Nodes are not allowed to modify Discovery Domain configurations.
制御ノードは：iSNSサーバは、制御ノードにより、追加、変更、または削除する検出ドメインを許可するかどうかを指定します。それが1に設定されている場合は、[コントロールノードを検出ドメインの設定を変更することが許可されています。それがゼロに設定されている場合は、[コントロールノードを検出ドメインの設定を変更することはできません。
iSCSI Target, Determine whether the respective iSCSI Initiator, registered iSNS client (determined iFCP Target Port, by iSCSI Node Type or iFCP Port Role) iFCP Initiator is allowed to add, delete, or modify Port: Discovery Domains. If they are set to one, then modification by the specified client type is allowed. If they are set to zero, then modification by the specified client type is not allowed.
検出ドメインを：iSCSIターゲットは、イニシエータのiFCP（iSCSIのノードタイプかのiFCPポートロールでのiFCPターゲットポート、決定）登録されたiSNSクライアントは、追加、削除、またはポートを変更することが許可されているそれぞれのiSCSIイニシエータかどうかを確認します。彼らが1に設定されている場合は、指定したクライアントのタイプによって変更が許可されます。それらはゼロに設定されている場合、指定されたクライアントの種類によって変更が許可されていません。
(A node may implement multiple node types.)
（ノードは、複数のノードタイプを実装してもよいです。）
The format of the Administrative Flags bit field is shown in Figure 4.
管理フラグビットフィールドのフォーマットは、図4に示されています。
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|M|H|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Administrative Flags
図4.管理国旗
Bit Field Significance
--------- ------------
15 Enabled
14 Heartbeat
13 Management SCNs
12 Default Discovery Domain
The following are Administrative Flags Field definitions:
以下は、管理フラグフィールドの定義です：
Enabled: Specifies the validity of the remainder of the Administrative Flags field. If it is set to one, then the contents of the remaining Administrative Flags are valid. If it is set to zero, then the remaining contents MUST be ignored, indicating that iSNS administrative settings are obtained through means other than DHCP.
有効：管理Flagsフィールドの残りの部分の有効性を指定します。それが1に設定されている場合は、残りの行政フラグの内容が有効です。それがゼロに設定されている場合は、残りのコンテンツは、iSNS管理設定がDHCP以外の手段を介して得られることを示し、無視しなければなりません。
Heartbeat: Indicates whether the first IP address is the multicast address to which the iSNS heartbeat message is sent. If it is set to one, then a1-a4 contains the heartbeat multicast address and b1-b4 contains the IP address of the primary iSNS server, followed by the IP address(es) of any backup servers (see Figure 1). If it is set to zero, then a1-a4 contain the IP address of the primary iSNS server, followed by the IP address(es) of any backup servers.
ハートビートは：最初のIPアドレスは、iSNSのハートビートメッセージが送信されるマルチキャストアドレスであるかどうかを示します。それが1に設定されている場合、A1〜A4は、ハートビートマルチキャストアドレスとB1〜B4を含む任意のバックアップサーバのIPアドレス（複数可）（図1を参照）に続いて、プライマリiSNSサーバーのIPアドレスが含まれています。それがゼロに設定されている場合は、A1〜A4は、すべてのバックアップサーバのIPアドレス（複数可）に続いて、主要iSNSサーバーのIPアドレスが含まれています。
Management SCNs: Indicates whether control nodes are authorized to register for receiving Management State Change Notifications (SCNs). Management SCNs are a special class of State Change Notification whose scope is the entire iSNS database. If this bit is set to one, then control nodes are authorized to register for receiving Management SCNs. If it is set to zero, then control nodes are not authorized to receive Management SCNs (although they may receive normal SCNs).
経営のSCN：制御ノードが管理状態変更通知（SCNの）を受信するために登録することが許可されているかどうかを示します。管理化SCNは、スコープ全体のiSNSデータベースである状態変更通知の特殊なクラスです。このビットが1に設定されている場合、制御ノードは、管理のSCNを受信するために登録することを許可されています。 （それらは正常化SCNを受信してもよいが）、それがゼロに設定されている場合、制御ノードは、管理のSCNを受信する権限がありません。
Default Discovery Indicates whether a newly registered Domain: device that is not explicitly placed into a Discovery Domain (DD) and Discovery Domain Set (DDS) should be automatically placed into a default DD and DDS. If it is set to one, then a default DD shall contain all devices in the iSNS database that have not been explicitly placed into a DD by an iSNS client. If it is set to zero, then devices not explicitly placed into a DD are not members of any DD.
デフォルトのディスカバリーは、新たに登録されたドメインかどうかを示します：明示的にディスカバリードメイン（DD）とディスカバリードメインセット（DDS）に配置されていないデバイスが自動的にデフォルトDDとDDSに配置する必要があります。それが1に設定されている場合、デフォルトのDDは、明示的にiSNSクライアントによってDDに配置されていないのiSNSデータベース内のすべてのデバイスを含まなければなりません。それがゼロに設定されている場合は、明示的にDDに配置されていないデバイスは、任意のDDのメンバーではありません。
The format of the iSNS server security Bitmap field is shown in Figure 5. If valid, this field communicates to the DHCP client the security settings that are required to communicate with the indicated iSNS server.
iSNSサーバーのセキュリティビットマップフィールドのフォーマットが有効な場合、このフィールドはDHCPクライアントに示されたiSNSサーバーと通信するために必要とされるセキュリティ設定を通信し、図5に示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |T|X|P|A|M|S|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. iSNS Server Security Bitmap
図5のiSNSサーバーセキュリティのビットマップ
Bit Field Significance
--------- ----------------
31 Enabled
30 IKE/IPSec
29 Main Mode
28 Aggressive Mode
27 PFS
26 Transport Mode
25 Tunnel Mode
The following are iSNS Server Security Bitmap definitions:
以下は、iSNSサーバーのセキュリティビットマップの定義です：
Enabled: Specifies the validity of the remainder of the iSNS server security bitmap. If it is set to one, then the contents of the remainder of the field are valid. If it is set to zero, then the contents of the rest of the field are undefined and MUST be ignored.
有効：のiSNSサーバーのセキュリティビットマップの残りの部分の有効性を指定します。それが1に設定されている場合は、そのフィールドの残りの部分の内容が有効です。それがゼロに設定されている場合は、そのフィールドの残りの内容は不定であり、無視しなければなりません。
IKE/IPSec: 1 = IKE/IPSec enabled; 0 = IKE/IPSec disabled.
IKE / IPSecの：1 = IKE / IPSecが有効になって。 0 = IKE / IPSecの無効化。
Main Mode: 1 = Main Mode enabled; 0 = Main Mode disabled.
メインモード：1 =メインモードが有効になります。 0 =メインモードは無効。
Aggressive Mode: 1 = Aggressive Mode enabled; 0 = Aggressive Mode disabled.
アグレッシブモード：1 =アグレッシブモードが有効になります。 0 =アグレッシブモードは無効。
PFS: 1 = PFS enabled; 0 = PFS disabled.
PFS：1 = PFSが有効になって。 0 = PFSは無効。
Transport Mode: 1 = Transport Mode preferred; 0 = No preference.
トランスポートモード：1 =転送モードが好ましいです。 0 =問わない。
Tunnel Mode: 1 = Tunnel Mode preferred; 0 = No preference.
トンネルモード：1 =トンネルモードが好ましいです。 0 =問わない。
If IKE/IPSec is disabled, this indicates that the Internet Key Exchange (IKE) Protocol is not available to configure IPSec keys for iSNS sessions to this iSNS server. It does not necessarily preclude other key exchange methods (e.g., manual keying) from establishing an IPSec security association for the iSNS session.
IKE / IPSecが無効になっている場合、これは、インターネット鍵交換（IKE）プロトコルは、このiSNSサーバーへのiSNSセッション用のIPSecキーを設定することができないことを示しています。必ずしもiSNSのセッションのためのIPSecセキュリティアソシエーションを確立する他の鍵交換方法（例えば、手動キーイング）を排除するものではありません。
If IKE/IPsec is enabled, then for each of the bit pairs <Main Mode, Aggressive Mode> and <Transport Mode, Tunnel Mode>, one of the two bits MUST be set to 1, and the other MUST be set to 0.
IKE / IPsecのが有効である場合、ビット対<メインモード、アグレッシブモード>と<トランスポートモード、トンネルモード>の各々に対して、2ビットのいずれかが1に設定しなければなりません、そして他方が0に設定しなければなりません。
For protecting the iSNS option, the DHCP Authentication security option as specified in [RFC3118] may present a problem due to the limited implementation and deployment of the DHCP authentication option. The IPsec security mechanisms for iSNS itself are specified in [iSNS] to provide confidentiality when sensitive information is distributed via iSNS. See the Security Considerations section of [iSNS] for details and specific requirements for implementation of IPsec.
iSNSのオプション、[RFC3118]で指定されるようにDHCP認証のセキュリティオプションを保護するためによりDHCP認証オプションの限られた実装と展開に問題を提示してもよいです。機密情報は、iSNSのを介して配信されたときにそれ自体が[たiSNS]で指定されたiSNSのIPsecセキュリティメカニズムは、機密性を提供します。詳細とIPsecの実装のための具体的な要件については、[iSNSの]のセキュリティの考慮事項のセクションを参照してください。
In addition, [iSNS] describes an authentication block that provides message integrity for multicast or broadcast iSNS messages (i.e., for heartbeat/discovery messages only). See [RFC3723] for further discussion of security for these protocols.
また、[iSNSの（すなわち、唯一のハートビート/ディスカバリメッセージの）マルチキャストまたはブロードキャストのiSNSメッセージのメッセージ完全性を提供する認証ブロックを記述する。これらのプロトコルのためのセキュリティのさらなる議論のための[RFC3723]を参照してください。
If no sensitive information, as described in [iSNS], is being distributed via iSNS, and an Entity is discovered via iSNS, authentication and authorization are handled by the IP Storage protocols whose endpoints are discovered via iSNS; specifically, iFCP [iFCP] and iSCSI [RFC3720]. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service does not compromise their security.
【のiSNS]で説明されるように機密情報が、iSNSのを介して配信されていない、およびエンティティがiSNSのを経由して発見された場合、認証と認可は、そのエンドポイントのiSNSを介して発見されるIPストレージプロトコルによって処理されます。具体的には、のiFCP【のiFCP]およびiSCSI [RFC3720]。不適切に宣伝や発見サービスは、セキュリティが損なわれないことを保証するために、これらのサービスの提供者の責任です。
When no DHCP security is used, there is a risk of distribution of false discovery information (e.g., via the iSNS DHCP option identifying a false iSNS server that distributes the false discovery information). The primary countermeasure for this risk is authentication by the IP storage protocols discovered through iSNS. When this risk is a significant concern, IPsec SAs SHOULD be used (as specified in RFC 3723). For example, if an attacker uses DHCP and iSNS to distribute discovery information that falsely identifies an iSCSI endpoint, that endpoint will lack the credentials necessary to complete IKE authentication successfully, and therefore will be prevented from falsely sending or receiving iSCSI traffic. When this risk of false discovery information is a significant concern and IPsec is implemented for iSNS, IPsec SAs SHOULD also be used for iSNS traffic to prevent use of a false iSNS server; this is more robust than relying only on the IP Storage protocols to detect false discovery information.
何DHCPセキュリティを使用しない場合、（偽発見情報を配信する偽iSNSサーバを特定のiSNS DHCPオプションを介して、例えば、）偽発見情報の配信の危険性があります。このリスクの主な対策は、iSNSによって発見されたIPストレージプロトコルによる認証です。このリスクは重大な関心事である場合には（RFC 3723で指定されるように）、IPsecのSAを使用する必要があります。攻撃者が誤ってiSCSIのエンドポイントを識別し、発見情報を配布するためにDHCPとのiSNSを使用した場合、そのエンドポイントが正常にIKE認証を完了するために必要な資格情報が不足しますので、誤ってiSCSIトラフィックを送信または受信することが防止されます。偽発見情報のこのリスクは重大な関心事であるとIPsecは、iSNSのために実装され、IPsecのSAはまた、偽のiSNSサーバーの使用を防止するためのiSNSトラフィックに使用する必要がある場合。これは、偽発見情報を検出するために、IPストレージプロトコルにのみ頼るよりも堅牢です。
When IPsec is implemented for iSNS, there is a risk of a denial-of-service attack based on repeated use of false discovery information that will cause initiation of IKE negotiation. The countermeasures for this are administrative configuration of each iSNS Entity to limit the peers it is willing to communicate with (i.e., by IP address range and/or DNS domain), and maintenance of a negative authentication cache to avoid repeatedly contacting an iSNS Entity that fails to authenticate. These three measures (i.e., IP address range limits, DNS domain limits, negative authentication cache) MUST be implemented for iSNS entities when this DHCP option is used. An analogous argument applies to the IP storage protocols that can be discovered via iSNS as discussed in RFC 3723.
IPsecはiSNSのために実装されている場合、IKEネゴシエーションの開始を引き起こします偽発見情報の繰り返し使用に基づいて、サービス拒否攻撃の危険性があります。この対策は、iSNSのエンティティを接触させ、繰り返しを避けるために、負の認証キャッシュのメンテナンス（IPアドレスの範囲および/またはDNSドメインによって、すなわち）と通信するために喜んで仲間を制限するために、各のiSNSエンティティの管理上の設定であること認証に失敗します。このDHCPオプションを使用する場合、これら3回の測定値（すなわち、IPアドレス範囲の制限、DNSドメインの制限、負の認証キャッシュ）は、iSNSのエンティティのために実装しなければなりません。類似した引数は、RFC 3723で説明したようにiSNSを経由して発見することができますIPストレージプロトコルに適用されます。
In addition, use of the techniques described in [RFC2827] and [RFC3833] may also be relevant to reduce denial-of-service attacks.
また、[RFC2827]及び[RFC3833]に記載された技術の使用はまた、サービス拒否攻撃を軽減するために関連し得ます。
In accordance with the policy defined in [DHCP], IANA has assigned a value of 83 for this option.
[DHCP]で定義されたポリシーに従って、IANAは、このオプションの83の値を割り当てました。
There are no other IANA-assigned values defined by this specification.
この仕様で定義された他のIANAによって割り当てられた値はありません。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[iSNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
【のiSNS]ツェン、J.、ギボンズ、K.、Travostino、F.、デュレイニー、C.、およびJ. Souzaの、 "インターネットストレージネームサービス（iSNSの）"、RFC 4171、2005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.
[iFCPゲート]モニア、C.、Mullendore、R.、Travostino、F.、チョン、W.、およびM.エドワーズ、 "のiFCP - インターネットファイバチャネルストレージネットワーキングのための議定書"、RFC 4172、2005年9月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
Authors' Addresses
著者のアドレス
Kevin Gibbons McDATA Corporation 4555 Great America Parkway Santa Clara, CA 95054-1208
ケビン・ギボンズマクデータ・コーポレーション4555グレートアメリカパークウェイサンタクララ、カリフォルニア州95054から1208
Phone: (408) 567-5765 EMail: kevin.gibbons@mcdata.com
電話：（408）567-5765 Eメール：kevin.gibbons@mcdata.com
Charles Monia 7553 Morevern Circle San Jose, CA 95135
チャールズ・モニア7553 Morevernサークルサンノゼ、CA 95135
EMail: charles_monia@yahoo.com
メールアドレス：charles_monia@yahoo.com
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107
ジョシュ・ツェンリバーベッドテクノロジー501第二ストリート、スイート410サンフランシスコ、CA 94107
Phone: (650)274-2109 EMail: joshtseng@yahoo.com
電話：(650)274-2109 Eメール：joshtseng@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。