RFC4174 日本語訳
4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option forthe Internet Storage Name Service. C. Monia, J. Tseng, K. Gibbons. September 2005. (Format: TXT=29485 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Monia
Request for Comments: 4174 Consultant
Category: Standards Track J. Tseng
Riverbed Technology
K. Gibbons
McDATA Corporation
September 2005
Moniaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 4174年のコンサルタントカテゴリ: 標準化過程J.ツェン川床技術K.テナガザルMcDATA社の2005年9月
The IPv4 Dynamic Host Configuration Protocol (DHCP) Option
for the Internet Storage Name Service
インターネットストレージ名前サービスのためのIPv4Dynamic Host Configuration Protocol(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは、インターネットStorage Name Service(iSNS)クライアントがDHCPのIPv4の使用で自動的にiSNSサーバの位置を発見するのを許容するためにDynamic Host Configuration Protocol(DHCP)オプションについて説明します; iSNSは企業スケールIPストレージネットワークでインターネットSCSI(iSCSI)とインターネットFibre Channelプロトコル(iFCP)記憶装置に発見と管理能力を提供します。iSNSはFibre Channelネットワークで見つけられたものに匹敵する知的なストレージ経営指導を提供します、商品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
1. 序論… 2 1.1. このドキュメントで中古のコンベンション… 2 2. DHCPのためのiSNSオプション… 3 機能がさばく2.1iSNS… 5 2.2. 発見ドメインアクセス分野… 6 2.3. 管理旗の分野… 7 2.4iSNSサーバセキュリティビットマップ… 8 3. セキュリティ問題… 9 4. IANA問題… 11
Monia, et al. Standards Track [Page 1] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[1ページ]。
5. Normative References ......................................... 11 6. Informative References ....................................... 11
5. 標準の参照… 11 6. 有益な参照… 11
1. Introduction
1. 序論
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のためのDynamic Host Configuration Protocolは設定情報をホストに渡すのにフレームワークを提供します。 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デバイスの自動化された発見、管理、および構成にフレームワークを提供します。 それはFibre Channelネットワークで見つけられたそれと同様の機能性を提供します、iSNSがIPネットワークの文脈の中で働いているのを除いて。その結果、iSNSは既存のFibre Channelネットワークで標準であることのIPネットワークに必要なストレージ知性を提供します。
Existing DHCP options cannot be used to find iSNS servers for the following reasons:
以下の理由でiSNSにサーバを見つけるのに既存のDHCPオプションを使用できません:
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オプションを使用することで明瞭に異なっています。 明確に、DNSなどの典型的な名前解決プロトコルと比べて、iSNSは能力の重要なスーパーセットを提供します。 それは、自分たちを許容するクライアントデバイスが構成されているとサポートするように設計されていて、主要な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サーバの位置と役割を発見して、iSNSのためにIANAによって割り当てられたDHCPオプション番号は83です。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
iSNS refers to the Internet Storage Name Service framework, which consists of the storage network model and associated services.
iSNSはインターネットStorage Name Serviceフレームワークについて言及します。(それは、ストレージネットワークモデルと関連サービスから成ります)。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
All frame formats are in big-endian network byte order. RESERVED fields SHOULD be set to zero.
ビッグエンディアンネットワークバイトオーダーにはすべてのフレーム形式があります。 RESERVEDはSHOULDをさばきます。ゼロに、用意ができています。
Monia, et al. Standards Track [Page 2] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[2ページ]。
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 Client"--iSNSクライアントは、iSCSIで居住しているプロセスとiSNSサーバがiSNSプロトコルを使用しているトランザクションを開始する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 Server"--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はゲートウェイからゲートウェイへのTCP/IPを使用することで既存のFibre Channelデバイスとインタコネクトするように設計されたプロトコルです。「iFCP(インターネットFibre Channelプロトコル)」--iFCPはTCP/IPに対するFibre Channel輸送と骨組みのサービスを写像します。
2. iSNS Option for DHCP
2. DHCPのためのiSNSオプション
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 |
| . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=83| 長さ| iSNS機能| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DDアクセス| 管理旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | iSNSサーバセキュリティビットマップ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a1| a2| a3| a4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | b1| b2| b3| b4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . | | 追加セカンダリiSNSサーバ| | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. iSNS Server Option
図1 iSNSサーバオプション
Monia, et al. Standards Track [Page 3] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[3ページ]。
The iSNS Option specifies a list of IP addresses used by iSNS servers. The option contains the following parameters:
iSNS OptionはiSNSサーバによって使用されるIPアドレスのリストを指定します。 オプションは以下のパラメタを含んでいます:
Length: The number of bytes that follow the Length field.
長さ: Length野原に続くバイト数。
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サーバによってサポートされた機能を定義するbitmapped分野。 この分野の形式はセクション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.
発見ドメインアクセス: ディスカバリーDomainsを変更できる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: Administrative Flags分野(セクション2.3を見る)でHeartbeatビットの設定によって、この分野はiSNS鼓動が起因する([iSNS]を見ます)IPアドレスかプライマリiSNSサーバのIPアドレスのどちらかを含んでいます。
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: Administrative Flags分野(セクション2.3を見る)で噛み付かれたHeartbeatの設定によって、この分野はプライマリiSNSサーバのIPアドレスかセカンダリiSNSサーバのもののどちらかを含んでいます。
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質問へのあらゆる応答で存在していなければなりません。 したがって、Length分野には、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.
HeartbeatビットがAdministrative Flags分野に設定されるなら(セクション2.3を見てください)、そして、b1です。また、b4も存在していなければなりません。 この場合、Length分野の最小値は18です。
The inclusion of Additional Secondary iSNS Servers in the response MUST be indicated by increasing the Length field accordingly.
それに従って、Length分野を増強することによって、応答でのAdditional Secondary iSNS Serversの包含を示さなければなりません。
Monia, et al. Standards Track [Page 4] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[4ページ]。
2.1. iSNS Functions Field
2.1. 機能がさばく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 Functions FieldはiSNSサーバの操作上の役割(iSNSサーバはすなわち、どう使用されているかことである)を定義します。 iSNSサーバの役割は、簡単な発見情報を提供するのと同じくらい基本的であるか、iSCSIとiFCPデバイスの使用のためのIKE/IPSec安全保障政策と証明書を提供するのとまたは同じくらい重要であることができます。 iSNS Functions分野の書式は図2に示されます。
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |S|A|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|S|A|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. iSNS Functions Field
iSNS機能がさばく図2
Bit Field Significance
--------- ------------
15 Function Fields Enabled
14 DD-Based Authorization
13 Security Policy Distribution
噛み付いている分野意味--------- ------------ 15 機能分野は14のDDベースの承認13安全保障政策分配を可能にしました。
The following are iSNS Functions Field definitions:
↓これはiSNS Functions Field定義です:
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.
機能フィールズSpecifies、残っているEnabledの正当性: iSNS Function分野。 それが1つに設定されるなら、他のすべてのiSNS Function分野の内容は有効です。 それがゼロに設定されるなら、他のすべてのiSNS Function分野のコンテンツを無視しなければなりません。
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ベースのIndicates、一般的なAuthorizationのデバイス: 発見Domain(DD)がお互いにアクセスするのがそれとなく認可されます。 ディスカバリーDomainsはデバイス発見の範囲を制御しますが、彼らは、ドメインメンバーが発見されたデバイスにアクセスするのに権限を与えられるかどうかを必ず示すというわけではありません。 このビットが1つに設定されるなら、互いへのアクセスは自動的に一般的なディスカバリーDomainのデバイスに許されています(首尾よく認証されるなら)。 このビットがゼロに設定されるなら、アクセス認可をドメイン会員資格によって含意されないで、各デバイスで明らかに実行しなければなりません。 どちらの場合ではも、デバイスは一般的な発見ドメインで互いにアクセスできます。
Monia, et al. Standards Track [Page 5] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[5ページ]。
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.
セキュリティPolicy Indicates、DistributionにはiSNSクライアントがいるか否かに関係なく: iSNSサーバで保存された安全保障政策構成を、ダウンロードして、使用してください。それが1つに設定されるなら、方針をiSNSサーバで保存されて、iSNSクライアントはそれ自身の安全保障政策に使用しなければなりません。 それがゼロに設定されるなら、iSNSクライアントは他の手段で安全保障政策構成を得なければなりません。
2.2. Discovery Domain Access Field
2.2. 発見ドメインアクセス分野
The format of the DD Access bit field is shown in Figure 3.
DD Accessビット分野の書式は図3に示されます。
0 1 1 1 1 1 1
0 ... 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+
| RESERVED | if| tf| is| ts| C | E |
+---+---+---+---+---+---+---+---+---+
0 1 1 1 1 1 1 0 ... 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+ | 予約されます。| if| tf| あります。| t| 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
噛み付いている分野意味--------- ------------ 15 可能にされた14規制ノード13iSCSI目標12iSCSI創始者11iFCP目標ポート10iFCP創始者ポート
The following are Discovery Domain Access Field definitions:
↓これはディスカバリーDomain Access Field定義です:
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 Accessビット分野の正当性を指定します。 それが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サーバが、ディスカバリーDomainsがControl Nodesによって加えられるか、変更されるか、または削除されるのを許容するかどうか指定します。 それが1つに設定されるなら、Control NodesはディスカバリーDomain構成を変更できます。 それがゼロに設定されるなら、Control NodesはディスカバリーDomain構成を変更できません。
Monia, et al. Standards Track [Page 6] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[6ページ]。
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 Target、それぞれのiSCSI Initiator、登録されたiSNSクライアント(iSCSI Node TypeかiFCP Port Roleによる断固としたiFCP Target Port)iFCP Initiatorが許容されているか否かに関係なく、DetermineはPortを加えるか、削除するか、または変更します: 発見ドメイン。 それらが1つに設定されるなら、指定されたクライアントタイプによる変更は許されています。 それらがゼロに設定されるなら、指定されたクライアントタイプによる変更は許されていません。
(A node may implement multiple node types.)
(ノードは複数のノード種別を実装するかもしれません。)
2.3. Administrative Flags Field
2.3. 管理旗の分野
The format of the Administrative Flags bit field is shown in Figure 4.
Administrative Flagsビット分野の書式は図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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|D|M|H|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Administrative Flags
図4。 管理旗
Bit Field Significance
--------- ------------
15 Enabled
14 Heartbeat
13 Management SCNs
12 Default Discovery Domain
噛み付いている分野意味--------- ------------ 15 可能にされた14鼓動13管理SCNs12デフォルト発見ドメイン
The following are Administrative Flags Field definitions:
↓これはAdministrative Flags Field定義です:
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.
可能にされる: Administrative Flags分野の残りの正当性を指定します。 それが1つに設定されるなら、残っているAdministrative Flagsの内容は有効です。 それがゼロに設定されるなら、残っているコンテンツを無視しなければなりません、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
鼓動: 最初のIPアドレスがiSNS鼓動メッセージが送られるマルチキャストアドレスであるか否かに関係なく、示します。 それが1つに設定されるなら、a1-a4はアドレスとb1-b4がIPアドレスを含む鼓動マルチキャストを含んでいます。
Monia, et al. Standards Track [Page 7] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[7ページ]。
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.
どんなバックアップサーバ(図1を見る)のIPアドレス(es)もあとに続いたプライマリiSNSサーバ。 それがそうなら、ゼロへのセット、当時のa1-a4はプライマリiSNSサーバのIPアドレスを含んでいます、どんなバックアップサーバのIPアドレス(es)もあとに続いていて。
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: 規制ノードが受信Management州Change Notifications(SCNs)に登録するのが認可されるか否かに関係なく、示します。 管理SCNsは範囲が全体のiSNSデータベースである州Change Notificationの特別なクラスです。 このビットが1つに設定されるなら、規制ノードがManagement SCNsを受けるために登録するのが認可されます。 それがゼロに設定されるなら、規制ノードがManagement SCNsを受け取るのが認可されません(彼らは正常なSCNsを受けるかもしれませんが)。
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.
デフォルトディスカバリーIndicates、aが新たにDomainを登録したか否かに関係なく: 明らかにディスカバリーDomain(DD)とディスカバリーDomain Set(DDS)に置かれないデバイスは自動的にデフォルトDDとDDSに置かれるべきです。 それが1つに設定されるなら、デフォルトDDはiSNSデータベースのiSNSクライアントによって明らかにDDに置かれていないすべてのデバイスを含むものとします。 それがゼロに設定されるなら、明らかにDDに置かれなかったデバイスはどんなDDのメンバーではありません。
2.4. iSNS Server Security Bitmap
2.4. iSNSサーバセキュリティビットマップ
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サーバセキュリティBitmap分野の書式は図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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|T|X|P|A|M|S|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. iSNS Server Security Bitmap
図5 iSNSサーバセキュリティビットマップ
Monia, et al. Standards Track [Page 8] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[8ページ]。
Bit Field Significance
--------- ----------------
31 Enabled
30 IKE/IPSec
29 Main Mode
28 Aggressive Mode
27 PFS
26 Transport Mode
25 Tunnel Mode
噛み付いている分野意味--------- ---------------- 31 可能にされた30IKE/IPSec29の主なモード28の攻撃的なモード27PFS26交通機関25トンネル・モード
The following are iSNS Server Security Bitmap definitions:
↓これはiSNS Server Security Bitmap定義です:
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 主なModeが可能にした=。 0は主なMode身体障害者と等しいです。
Aggressive Mode: 1 = Aggressive Mode enabled;
0 = Aggressive Mode disabled.
攻撃的なモード: 1 攻撃的なModeが可能にした=。 0は攻撃的なMode身体障害者と等しいです。
PFS: 1 = PFS enabled; 0 = PFS disabled.
Pfs: 1 PFSが可能にした=。 0はPFS身体障害者と等しいです。
Transport Mode: 1 = Transport Mode preferred; 0 = No
preference.
モードを輸送してください: 1はModeが好んだ輸送と等しいです。 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セッションのためのIPSecキーをこのiSNSサーバに構成するために利用可能でないことを示します。それは、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は有効にされます、そして、それぞれのビットの組の<Main ModeとAggressive Mode>と<Transport Mode、トンネル・モード>2ビットの1つを1に設定しなければならなくて、0にもう片方を設定しなければならないなら。
3. Security Considerations
3. セキュリティ問題
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
iSNSオプションを保護するために、[RFC3118]の指定されるとしてのDHCP AuthenticationセキュリティオプションはDHCP認証の限られた実装と展開のため問題を提示するかもしれません。
Monia, et al. Standards Track [Page 9] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[9ページ]。
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自身のためのIPsecセキュリティー対策は、機密情報がiSNSを通して分配されるとき、秘密性を提供するために[iSNS]で指定されます。 IPsecの実装のための詳細と決められた一定の要求に関して[iSNS]のSecurity Considerations部を見てください。
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を通して分配されていて、EntityがiSNSを通して発見されるなら、認証と承認は終点がiSNSを通して発見されるIP Storageプロトコルによって扱われます。 明確に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 SHOULD、これであるときに、リスクは重要な関心です。使用されてください(RFC3723で指定されるように)。 例えば、攻撃者が間違ってiSCSI終点を特定する発見情報を分配するのにDHCPとiSNSを使用すると、その終点は、首尾よくIKE認証を終了するのに必要な資格証明書を欠いて、したがって、間違ってiSCSIトラフィックを送るか、または受けるのが防がれるでしょう。 いつ、誤った発見情報のこのリスクが重要な関心であるか、そして、IPsecはiSNS、IPsec SAs SHOULDのために実装されます、また、使用されて、iSNSトラフィックは誤ったiSNSサーバの使用を防いでください。 これは誤った発見情報を検出するためにIP Storageプロトコルだけを当てにするより強健です。
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交渉の開始を引き起こす情報を誤った発見の繰り返された使用に基礎づけたという否定のリスクがあります。 これのための対策は、認証するそれがコミュニケートしても構わないと思っている(すなわち、IPアドレスの範囲、そして/または、DNSドメインのそばで)同輩を制限するそれぞれのiSNS Entityの管理構成と、失敗するiSNS Entityに連絡する繰り返して避ける否定的認証キャッシュのメインテナンスです。 このDHCPオプションが使用されているとき、これらの3つの政策(すなわち、IPアドレスレンジ限界、DNSドメイン限界、否定的認証キャッシュ)がiSNS実体のために実施されなければなりません。 類似の議論はRFC3723で議論するようにiSNSを通して発見できるIPストレージプロトコルに適用されます。
Monia, et al. Standards Track [Page 10] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[10ページ]。
In addition, use of the techniques described in [RFC2827] and [RFC3833] may also be relevant to reduce denial-of-service attacks.
また、さらに、[RFC2827]と[RFC3833]で説明されたテクニックの使用も、サービス不能攻撃を抑えるために関連しているかもしれません。
4. IANA Considerations
4. IANA問題
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-割り当てられた値が全くありません。
5. Normative References
5. 引用規格
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[DHCP] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、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.、Duレーニー、C.、およびJ.スザ、「インターネット格納名前サービス(iSNS)」、RFC4171 2005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3118] DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、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)を連結します」、RFC3720、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の上に保証します」、RFC3723(2004年4月)。
6. Informative References
6. 有益な参照
[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.エドワーズ、「iFCP--インターネット繊維のためのプロトコルは格納ネットワークを向けます」、RFC4172、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を使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
Monia, et al. Standards Track [Page 11] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Kevin Gibbons McDATA Corporation 4555 Great America Parkway Santa Clara, CA 95054-1208
グレート・アメリカParkwayサンタクララ、ケビンギボンズMcDATA社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
チャールズMonia7553Morevern円のサンノゼ、カリフォルニア 95135
EMail: charles_monia@yahoo.com
メール: charles_monia@yahoo.com
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107
第2通り、ジョッシュツェン川床技術501Suite410サンフランシスコ、カリフォルニア 94107
Phone: (650)274-2109 EMail: joshtseng@yahoo.com
以下に電話をしてください。 (650)274-2109 メールしてください: joshtseng@yahoo.com
Monia, et al. Standards Track [Page 12] RFC 4174 DHCP Option Number for iSNS September 2005
Monia、他 規格は2005年9月にiSNSのRFC4174DHCPオプション番号を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは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機能のための基金は現在、インターネット協会によって提供されます。
Monia, et al. Standards Track [Page 13]
Monia、他 標準化過程[13ページ]
一覧
スポンサーリンク
