[要約] RFC 4174は、IPv4のDHCPオプションを使用してインターネットストレージ名サービスを提供するためのガイドラインです。このRFCの目的は、ストレージデバイスの自動構成と名前解決を容易にすることです。
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
インターネットストレージ名サービスのIPv4動的ホスト構成プロトコル（DHCP）オプション
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、IPv4にDHCPを使用してISNSサーバーの位置を自動的に発見できるようにするための動的ホスト構成プロトコル（DHCP）オプションについて説明します。ISNSは、インターネットSCSI（ISCSI）およびインターネットファイバーチャネルプロトコル（IFCP）ストレージデバイスに、エンタープライズスケールのIPストレージネットワークで発見および管理機能を提供します。ISNSは、ファイバーチャネルネットワークに見られるものに匹敵するインテリジェントストレージ管理サービスを提供し、コモディティ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の動的ホスト構成プロトコルは、ホストに構成情報を渡すためのフレームワークを提供します。その有用性は、ISCSIおよびIFCPプロトコルを使用してホストとデバイスに拡張され、TCP/IPネットワークを介してレベルストレージアセットをブロックするために接続します。
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ネットワークのコンテキスト内で機能することを除き、ファイバーチャネルネットワークで見つかった機能と同様の機能を提供します。これにより、既存のファイバーチャネルネットワークに標準のあるIPネットワークに必要なストレージインテリジェンスを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オプションを使用して他のプロトコルとは明らかに異なります。具体的には、ISNSは、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) ISNSには、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オプション番号は、ISCSIおよびIFCPデバイスによって使用され、ISNSサーバーの位置と役割を発見します。IANAによってISNSに割り当てられたDHCPオプション番号は83です。
iSNS refers to the Internet Storage Name Service framework, which consists of the storage network model and associated services.
ISNSは、ストレージネットワークモデルと関連サービスで構成されるインターネットストレージ名サービスフレームワークを指します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
All frame formats are in big-endian network byte order. RESERVED fields SHOULD be set to zero.
すべてのフレーム形式は、ビッグエンディアンネットワークバイトの順序にあります。予約済みフィールドはゼロに設定する必要があります。
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.
管理フラグフィールド：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：管理フラグフィールドのハートビートビットの設定に応じて（セクション2.3を参照）、このフィールドには、プライマリISNSサーバーのIPアドレスまたはセカンダリISNSサーバーのIPアドレスのいずれかが含まれています。
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.
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.
ハートビートビットが管理フラグフィールドに設定されている場合（セクション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ベースは、一般的な承認：Discovery Domain（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アクセスフィールドの残りの内容が有効です。ゼロに設定されている場合、このフィールドの残りの内容は無視する必要があります。
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ターゲットは、ISCSIノードタイプまたはIFCPポートの役割で登録されているISCSIイニシエーター（ISCPターゲットポートを決定したIFCPターゲットポート）を判断します。IFCPイニシエーターは、ポートを追加、削除、または変更することができます：ディスカバリードメイン。それらが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.
有効化：管理フラグの残りのフィールドの有効性を指定します。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にはプライマリISNSサーバーのIPアドレスが含まれ、その後バックアップサーバーのIPアドレスが含まれます（図1を参照）。ゼロに設定されている場合、A1-A4にはプライマリISNSサーバーのIPアドレスが含まれ、その後バックアップサーバーの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).
管理SCNS：コントロールノードが、管理状態変更通知（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.
デフォルトの検出は、新しく登録されたドメイン：Discoveryドメイン（DD）およびディスカバリードメインセット（DD）に明示的に配置されていないデバイスを、デフォルトの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サーバーセキュリティビットマップフィールドの形式を図5に示します。有効な場合、このフィールドは、指定されたISNSサーバーと通信するために必要なセキュリティ設定をDHCPクライアントに通信します。
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 exabled;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 Enabled;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が無効になっている場合、これは、このISNSサーバーへのISNSセッション用のIPSECキーを構成するためにインターネットキーExchange（IKE）プロトコルが利用できないことを示しています。必ずしも他の重要な交換方法（たとえば、手動キーイング）が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つを1に設定する必要があり、もう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自体のIPSECセキュリティメカニズムは、[ISNS]で指定されており、ISNを介して機密情報が配布される場合の機密性を提供します。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]に記載されているように機密情報がISNを介して配布されていない場合、ISNを介してエンティティが発見されている場合、認証と承認は、ISNを介してエンドポイントが発見される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ストレージプロトコルによる認証です。このリスクが重大な懸念事項である場合、IPSEC SASを使用する必要があります（RFC 3723で指定されています）。たとえば、攻撃者がDHCPとISNを使用してISCSIエンドポイントを誤って識別する発見情報を配布する場合、そのエンドポイントはIKE認証を正常に完了するために必要な資格情報を欠いているため、ISCSIトラフィックを誤って送信または受信することができなくなります。虚偽の発見情報のこのリスクが重要な懸念であり、ISNSに対してIPSECが実装される場合、IPSEC SASも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がISNに実装されると、IKE交渉の開始を引き起こす誤検出情報の繰り返し使用に基づいて、サービス拒否攻撃のリスクがあります。これの対策は、各ISNSエンティティの管理構成であり、通信することをいとわないピア（つまり、IPアドレス範囲および/またはDNSドメインによって）を制限し、ネガティブ認証キャッシュのメンテナンスを行い、ISNSエンティティに繰り返し接触することを避けるために、ネガティブ認証キャッシュのメンテナンスです。認証に失敗します。これらの3つの測定（つまり、IPアドレス範囲制限、DNSドメイン制限、ネガティブ認証キャッシュ）は、このDHCPオプションを使用する場合はISNSエンティティに実装する必要があります。RFC 3723で説明したように、ISNを介して発見できる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] Tseng、J.、Gibbons、K.、Travostino、F.、Du Laney、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Meth、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.、Tseng、J.、Walker、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] Monia、C.、Mullendore、R.、Travostino、F.、Jeong、W。、およびM. Edwards、「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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、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メール：kevin.gibbons@mcdata.com
Charles Monia 7553 Morevern Circle San Jose, CA 95135
チャールズモニア7553モアバーンサークルサンノゼ、カリフォルニア95135
EMail: charles_monia@yahoo.com
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107
Josh Tseng Riverbed Technology 501 2nd Street、Suite 410 San Francisco、CA 94107
Phone: (650)274-2109 EMail: joshtseng@yahoo.com
電話：（650）274-2109メール：joshtseng@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。