Network Working Group                                           M. Bakke
Request for Comments: 4018                                         Cisco
Category: Standards Track                                     J. Hufferd
                                                            K. Voruganti
                                                              M. Krueger
                                                               T. Sperry
                                                              April 2005

Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)

Service Location Protocolバージョン2(SLPv2)を使用してインターネットスモールコンピューターシステムインターフェイス(iSCSI)ターゲットとネームサーバーを見つける

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.

このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」(STD 1)の最新版を参照してください。 このメモの配布は無制限です。

Copyright Notice


Copyright (C) The Internet Society (2005).




The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide.

iSCSIプロトコルは、ホストがIPネットワークを介してSCSIデバイスにアクセスする方法を提供します。 このドキュメントでは、iSCSIホスト、デバイス、および管理サービスによるService Location Protocol(SLP)の使用と、提供するサービスを説明するSLPサービスタイプテンプレートを定義しています。

Table of Contents


    1.  Introduction................................................   2
    2.  Notation Conventions........................................   2
    3.  Terminology.................................................   3
    4.  Using SLP for iSCSI Service Discovery.......................   4
    5.  iSCSI SLP Templates.........................................  11
    6.  Security Considerations.....................................  18
    7.  IANA Considerations.........................................  19
    8.  Summary.....................................................  19
    9.  Normative References........................................  19
   10.  Informative References......................................  20
   11.  Acknowledgements............................................  21
1. Introduction
1. はじめに

iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands, data, and status across an IP network. This protocol is connection-oriented and is currently defined over TCP. iSCSI uses a client-server relationship. The client end of the connection is an initiator, and it sends SCSI commands; the server end of the connection is called a target, and it receives and executes the commands.

iSCSI [RFC3720]は、IPネットワークを介してSCSI [SAM2]コマンド、データ、およびステータスを転送するために使用されるプロトコルです。 このプロトコルは接続指向であり、現在TCP上で定義されています。 iSCSIは、クライアントとサーバーの関係を使用します。 接続のクライアント側はイニシエーターであり、SCSIコマンドを送信します。 接続のサーバー側はターゲットと呼ばれ、コマンドを受信して実行します。

There are several methods an iSCSI initiator can use to find the targets to which it should connect. Two of these methods can be accomplished without the use of SLP:

iSCSIイニシエーターは、接続するターゲットを見つけるために使用できるいくつかの方法があります。 これらの方法のうち2つは、SLPを使用せずに実行できます。

- Each target and its address can be statically configured on the initiator.


- Each address providing targets can be configured on the initiator; iSCSI provides a mechanism by which the initiator can query the address for a list of targets.

-ターゲットを提供する各アドレスは、イニシエーターで構成できます。 iSCSIは、イニシエーターがターゲットのリストのアドレスを照会できるメカニズムを提供します。

The above methods are further defined in "iSCSI Naming and Discovery Requirements" [RFC3721].


Each of the above methods requires a small amount of configuration to be done on each initiator. The ability to discover targets and name services without having to configure initiators is a desirable feature. The Service Location Protocol (SLP) [RFC2608] is an IETF standards track protocol providing several features that will simplify locating iSCSI services. This document describes how SLP can be used in iSCSI environments to discover targets, addresses providing targets, and storage management servers.

上記の各方法では、各イニシエーターで少量の構成を行う必要があります。 イニシエーターを構成しなくてもターゲットとネームサービスを検出できる機能は望ましい機能です。 Service Location Protocol(SLP)[RFC2608]は、iSCSIサービスの検索を簡素化するいくつかの機能を提供するIETF標準トラックプロトコルです。 このドキュメントでは、iSCSI環境でSLPを使用してターゲット、ターゲットを提供するアドレス、およびストレージ管理サーバーを検出する方法について説明します。

2. Notation Conventions

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].

このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 [RFC2119]で説明されているように解釈されます。

3. Terminology

Here are some definitions that may aid readers who are unfamiliar with SLP, SCSI, or iSCSI. Some of these definitions have been reproduced from [RFC2608] and "Finding an RSIP Server with SLP" [RFC3105].

以下は、SLP、SCSI、またはiSCSIに不慣れな読者に役立ついくつかの定義です。 これらの定義の一部は、[RFC2608]および「SLPを使用したRSIPサーバーの検索」[RFC3105]から複製されています。

User Agent (UA) A process working on the client's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents.

ユーザーエージェント(UA)何らかのサービスとの接続を確立するためにクライアントに代わって動作するプロセス。 UAは、サービスエージェントまたはディレクトリエージェントからサービス情報を取得します。

Service Agent (SA) A process working on behalf of one or more services to advertise the services and their capabilities.


Directory Agent (DA) A process that collects service advertisements. There can only be one DA present per given host.

ディレクトリエージェント(DA)サービスアドバタイズメントを収集するプロセス。 特定のホストごとに存在できるDAは1つだけです。

Scope A named set of services, typically making up a logical administrative group.


Service Advertisement A URL, attributes, and a lifetime (indicating how long the advertisement is valid) providing service access information and capabilities description for a particular service.


Initiator A logical entity, typically within a host, that sends SCSI commands to targets to be executed. An initiator is usually present in the form of a device driver.

イニシエーター実行するターゲットにSCSIコマンドを送信する、通常はホスト内の論理エンティティ。 通常、イニシエーターはデバイスドライバーの形で存在します。

Target A logical entity, typically within a storage controller or gateway that receives SCSI commands from an initiator and executes them. A target includes one or more Logical Units (LUs); each LU is a SCSI device, such as a disk or tape drive.

ターゲット通常、ストレージコントローラまたはゲートウェイ内の論理エンティティで、SCSIコマンドをイニシエータから受信して実行します。 ターゲットには、1つ以上の論理ユニット(LU)が含まれます。 各LUは、ディスクやテープドライブなどのSCSIデバイスです。

iSCSI Name A UTF-8 character string that serves as a unique identifier for iSCSI initiators and targets. Its format and usage is further defined in [RFC3721].

iSCSI名iSCSIイニシエーターおよびターゲットの一意の識別子として機能するUTF-8文字列。 その形式と使用法は、[RFC3721]でさらに定義されています。

iSCSI Client A logical entity, typically a host that includes at least one iSCSI Initiator.


iSCSI Server A logical entity, typically a storage controller or gateway that includes at least one iSCSI Target.


Storage Management Server An addressable entity that provides management services that benefit an iSCSI environment. "Storage management server" is used as a generic term and does not indicate a specific protocol or service.

ストレージ管理サーバーiSCSI環境に役立つ管理サービスを提供するアドレス可能なエンティティ。 「ストレージ管理サーバー」は一般的な用語として使用され、特定のプロトコルまたはサービスを示すものではありません。

4. Using SLP for iSCSI Service Discovery
4. iSCSIサービス検出にSLPを使用する

Two entities are involved in iSCSI discovery. The end result is that an iSCSI initiator (e.g., a host) discovers iSCSI targets, usually provided by storage controllers or gateways.

iSCSIディスカバリーには2つのエンティティーが関係しています。 最終結果として、iSCSIイニシエーター(ホストなど)は、通常はストレージコントローラーまたはゲートウェイによって提供されるiSCSIターゲットを検出します。

iSCSI targets are registered with SLP as a set of service URLs, one for each address on which the target may be accessed. Initiators discover these targets by using SLP service requests. Targets that do not directly support SLP or that are under the control of a management service may be registered by a proxy service agent as part of the software providing this service.

iSCSIターゲットは、サービスURLのセットとして、ターゲットにアクセスできるアドレスごとに1つずつ、SLPに登録されます。 イニシエーターは、SLPサービス要求を使用してこれらのターゲットを検出します。 SLPを直接サポートしないターゲット、または管理サービスの制御下にあるターゲットは、このサービスを提供するソフトウェアの一部としてプロキシサービスエージェントによって登録される場合があります。

iSCSI entities may also use SLP to discover higher-level management services when these are needed.


This section first describes the use of SLP for discovery of targets by iSCSI initiators, it then describes the use of SLP to discover storage management servers.


This document assumes that SLPv2 will be used for discovering iSCSI-related services; no attempt is made to include support for SLPv1.

このドキュメントでは、iSCSI関連サービスの検出にSLPv2が使用されることを想定しています。 SLPv1のサポートを含める試みは行われません。

4.1. Discovering iSCSI Targets with SLP
4.1. SLPを使用したiSCSIターゲットの検出

The following diagram shows the relationship among iSCSI clients, servers, initiators, and targets. An iSCSI client includes at least one iSCSI initiator, and an SLP user agent (UA). An iSCSI server includes at least one iSCSI target an SLP service agent (SA). Some entities, such as extended copy engines, include both initiators and targets. These include both an SA, for its targets to be discovered, and a UA, for its initiator(s) to discover other targets.

次の図は、iSCSIクライアント、サーバー、イニシエーター、およびターゲット間の関係を示しています。 iSCSIクライアントには、少なくとも1つのiSCSIイニシエーターとSLPユーザーエージェント(UA)が含まれます。 iSCSIサーバーには、SLPサービスエージェント(SA)に少なくとも1つのiSCSIターゲットが含まれます。 拡張コピーエンジンなどの一部のエンティティには、イニシエーターとターゲットの両方が含まれます。 これには、ターゲットを検出するためのSAと、イニシエーターが他のターゲットを検出するためのUAの両方が含まれます。

              |          iSCSI Client           |
              |         +-----------+           |
              |         | iSCSI     |           |
              |         | initiator |           |
              |         | "myhost"  |           |
              |         +-----------+           |
              |                                 |
              | iSCSI Driver             |  UA  |
              |           TCP/UDP/IP            |
              |  Interface 1   |   Interface 2  |
                       |               |
     +------------+    |               |    +------------+
     |   SLP DA   |    |               |    |  SLP DA    |
     | (optional) |----+  IP Networks  +----| (optional) |
     +------------+    |               |    +------------+
                       |               |
              |   Interface 1   |   Interface 2   |
              |   |    |
              |            TCP/UDP/IP             |
              |       iSCSI Driver        |  SA   |
              |                                   |
              | +--------+ +--------+ +---------+ |
              | | iSCSI  | | iSCSI  | |  iSCSI  | |
              | | target | | target | |  target | |
              | | "one"  | | "two"  | | "three" | |
              | +--------+ +--------+ +---------+ |
              |            iSCSI Server           |

In the above drawing, the iSCSI server has three iSCSI targets that the client could discover, named "one", "two" and "three". The iSCSI client has an iSCSI initiator with the name "myhost". The iSCSI client may use the initiator name in its SLP Service Requests as a filter to discover only targets that are configured to accept iSCSI connections from "myhost".

上記の図では、iSCSIサーバーには、クライアントが「1」、「2」、「3」と名付けた3つのiSCSIターゲットがあります。 iSCSIクライアントには、「myhost」という名前のiSCSIイニシエーターがあります。 iSCSIクライアントは、SLPサービス要求のイニシエーター名をフィルターとして使用して、「myhost」からのiSCSI接続を受け入れるように構成されているターゲットのみを検出する場合があります。

Each iSCSI target and initiator has a unique name, called an iSCSI Name. This identifier is the same regardless of the network path (through adapter cards, networks, and interfaces on the storage device) over which the target is discovered and accessed. For this example, the iSCSI names "one", "two", and "three" are used for the targets; the initiator uses the name "myhost". An actual iSCSI name would incorporate more structure, including a naming authority, and is not described here.

各iSCSIターゲットおよびイニシエーターには、iSCSI名と呼ばれる一意の名前があります。 この識別子は、ターゲットが検出およびアクセスされるネットワークパス(ストレージカード上のアダプターカード、ネットワーク、およびインターフェイスを経由)に関係なく同じです。 この例では、iSCSI名「1」、「2」、および「3」がターゲットに使用されます。 イニシエーターは「myhost」という名前を使用します。 実際のiSCSI名には、命名機関を含むより多くの構造が組み込まれるため、ここでは説明しません。

Each of the iSCSI targets in the drawing can appear at two addresses, since two network interfaces are present. Each target would have two service URLs, unless a single service URL included a DNS host name mapping to both addresses.

図面内の各iSCSIターゲットは、2つのネットワークインターフェイスが存在するため、2つのアドレスに表示できます。 1つのサービスURLに両方のアドレスへのDNSホスト名マッピングが含まれていない限り、各ターゲットには2つのサービスURLがあります。

An iSCSI target URL consists of its fully qualified host name or IP address, the TCP port on which it is listening, and its iSCSI name. An iSCSI server must register each of its individual targets at each of its network addresses.

iSCSIターゲットURLは、完全修飾ホスト名またはIPアドレス、リッスンしているTCPポート、およびそのiSCSI名で構成されます。 iSCSIサーバーは、ネットワークアドレスごとに個々のターゲットを登録する必要があります。

The iSCSI server constructs a service advertisement of the type "service:iscsi:target" for each of the service URLs it wishes to register. The advertisement contains a lifetime, along with other attributes that are defined in the service template.

iSCSIサーバーは、登録するサービスURLごとに「service:iscsi:target」タイプのサービスアドバタイズメントを構築します。 アドバタイズメントには、サービステンプレートで定義されている他の属性とともにライフタイムが含まれます。

If the server in the above drawing is listening at TCP port 3260 for both network addresses, the service URLs registered would be














The remainder of the discovery procedure is identical to that used by any client/server pair implementing SLP:


1. If an SLP DA is found, the SA contacts the DA and registers the service advertisement. Whether or not one or more SLPv2 DAs are discovered, the SA maintains the advertisement itself and answers multicast UA queries directly.

1. SLP DAが見つかった場合、SAはDAに接続し、サービスアドバタイズメントを登録します。 1つ以上のSLPv2 DAが検出されたかどうかにかかわらず、SAは広告自体を維持し、マルチキャストUAクエリに直接応答します。

2. When the iSCSI initiator requires contact information for an iSCSI target, the UA either contacts the DA by using unicast or the SA by using multicast. If a UA is configured with the address of the SA, it may avoid multicast and may contact an SA by using unicast. The UA includes a query based on the attributes to indicate the characteristics of the target(s) it requires.

2. iSCSIイニシエーターがiSCSIターゲットの連絡先情報を必要とする場合、UAはユニキャストを使用してDAに接続するか、マルチキャストを使用してSAに接続します。 UAがSAのアドレスで構成されている場合、マルチキャストを回避し、ユニキャストを使用してSAに接続する場合があります。 UAには、属性に基づいて、必要なターゲットの特性を示すクエリが含まれています。

3. Once the UA has the host name or address of the iSCSI server, as well as the port number and iSCSI Target Name, it can begin the normal iSCSI login to the target.

3. UAがiSCSIサーバーのホスト名またはアドレス、およびポート番号とiSCSIターゲット名を取得すると、ターゲットへの通常のiSCSIログインを開始できます。

As information contained in the iSCSI target template may exceed common network datagram sizes, the SLP implementation for both UAs and SAs supporting this template MUST implement SLP over TCP.


4.1.1. Finding Targets Based on Initiator Credentials
4.1.1. イニシエーターの資格情報に基づいたターゲットの検索

To be allowed access to an iSCSI target, an initiator must be authenticated. The initiator may be required by the target to produce one or more of the following credentials:

iSCSIターゲットへのアクセスを許可するには、イニシエーターを認証する必要があります。 ターゲットは、イニシエーターに以下の1つ以上の資格情報を生成するよう要求する場合があります。

- An iSCSI Initiator Name


- An IP address


- A CHAP, SRP, or Kerberos credential


- Any combination of the above


Most iSCSI targets allow access to only one or two initiators. In the ideal discovery scenario, an initiator would send an SLP request and receive responses ONLY for targets to which the initiator is guaranteed a successful login. To achieve this goal, the iSCSI target template contains the following attributes, each of which allows a list of values:

ほとんどのiSCSIターゲットでは、1つまたは2つのイニシエーターのみにアクセスできます。 理想的な検出シナリオでは、イニシエーターはログインの成功が保証されているターゲットに対してのみSLP要求を送信し、応答を受信します。 この目標を達成するために、iSCSIターゲットテンプレートには次の属性が含まれており、それぞれが値のリストを許可します。

1. auth-name: This attribute contains the list of initiator names allowed to access this target, or the value "any", indicating that no specific initiator name is required.

1. auth-name:この属性には、このターゲットへのアクセスが許可されているイニシエーター名のリスト、または特定のイニシエーター名が不要であることを示す値「any」が含まれます。

2. auth-addr: This attribute contains the list of host names and/or IP addresses that will be allowed access to this target, or the value "any", indicating that no specific address or host name is required. If a large number of addresses is to be allowed (perhaps a subnet), this attribute may contain the value "any".

2. auth-addr:この属性には、このターゲットへのアクセスが許可されるホスト名やIPアドレスのリスト、または特定のアドレスやホスト名が不要であることを示す値「any」が含まれます。 多数のアドレス(おそらくサブネット)を許可する場合、この属性には値「any」が含まれる場合があります。

3. auth-cred: This attribute contains a list of "method/identifier" credentials that will be allowed access to the target, provided they can produce the correct password or other verifier during the login process. If no specific credentials are required, the value "any" is used.

3. auth-cred:この属性には、ログインプロセス中に正しいパスワードまたは他の検証者を生成できる場合、ターゲットへのアクセスを許可される「メソッド/識別子」資格情報のリストが含まれます。 特定の資格情報が必要ない場合、値「any」が使用されます。

The list of valid method strings for auth-cred are defined in [RFC3720], section 11.1, "AuthMethod". The identifier used after the "/" is defined by the specific AuthMethod, also in [RFC3720]. Examples showing initiator searches based on auth-xxxx attributes are shown in the target-specific template section below.

auth-credの有効なメソッド文字列のリストは、[RFC3720]、セクション11.1、「AuthMethod」で定義されています。 「/」の後に使用される識別子は、[RFC3720]の特定のAuthMethodによって定義されます。 auth-xxxx属性に基づいたイニシエーター検索の例を、以下のターゲット固有のテンプレートセクションに示します。

Also note that the auth-xxxx attributes are considered security policy information. If these attributes are distributed, IPsec MUST be implemented as specified in the Security Implementation section below.

また、auth-xxxx属性はセキュリティポリシー情報と見なされることに注意してください。 これらの属性が配布される場合、以下の「セキュリティ実装」セクションで指定されているようにIPsecを実装する必要があります。

4.1.2. Supporting Access by Multiple Identities to the Same Target
4.1.2. 同じターゲットへの複数のIDによるアクセスのサポート

If a target is to allow access to multiple host identities, more than one combination of auth-xxxx attributes will have to be allowed. In some of these cases, it is not possible to express the entire set of valid combinations of auth-xxxx attributes within a single registered service URL. For example, if a target can be addressed by

ターゲットが複数のホストIDへのアクセスを許可する場合、auth-xxxx属性の複数の組み合わせを許可する必要があります。 これらのケースのいくつかでは、単一の登録済みサービスURL内でauth-xxxx属性の有効な組み合わせのセット全体を表現することはできません。 たとえば、ターゲットが

auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)

auth-name = myhost1 AND auth-cred = CHAP / user1(identity1)



auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)

auth-name-myhost2 AND auth-cred = CHAP / user2(identity2)

the above cannot be specified in a single registered service URL, since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1, auth-cred=CHAP/user2) would allow either auth-name to be used with either auth-cred. This necessitates the ability to register a target and address under more than one service URL; one for (identity1) and one for (identity2).

(auth-name = myhost1、auth-name = myhost2、auth-cred = CHAP / user1、auth-cred = CHAP / user2)はいずれかのauth-nameを許可するため、上記を単一の登録済みサービスURLで指定することはできません auth-credとともに使用されます。 これには、複数のサービスURLでターゲットとアドレスを登録する機能が必要です。 1つは(identity1)用で、もう1つは(identity2)用です。

Because service URLs must be unique, (identity1) and (identity2) must each be registered under a unique service URL. For systems that support the configuration of multiple identities to access a target, the service URL must contain an additional, opaque string defining the identity. This appears after the iSCSI name in the URL string and is separated by a "/". Each registered (target-address, target-name, initiator-identity) tuple can then register a set of auth-xxxx attributes.

サービスURLは一意である必要があるため、(identity1)および(identity2)はそれぞれ一意のサービスURLで登録する必要があります。 ターゲットにアクセスするために複数のIDの構成をサポートするシステムの場合、サービスURLにはIDを定義する追加の不透明な文字列が含まれている必要があります。 これは、URL文字列のiSCSI名の後に表示され、「/」で区切られます。 登録された(ターゲットアドレス、ターゲット名、イニシエータID)タプルは、auth-xxxx属性のセットを登録できます。

4.1.3. Using SLP in a Non-multicast Environment
4.1.3. 非マルチキャスト環境でのSLPの使用

In some networks, the use of multicast for discovery purposes is either unavailable or not allowed. These include public or service-provider networks that are placed between an iSCSI client and a server. These are probably most common between two iSCSI gateways, one at a storage service provider site, and one at a customer site.

一部のネットワークでは、発見目的でのマルチキャストの使用が利用できないか、許可されていません。 これらには、iSCSIクライアントとサーバーの間に配置されるパブリックネットワークまたはサービスプロバイダーネットワークが含まれます。 これらはおそらく、ストレージサービスプロバイダーサイトと顧客サイトの2つのiSCSIゲートウェイ間で最も一般的です。

In these networks, an initiator may allow the addresses of one or more SAs to be configured instead of or in addition to its DA configuration. The initiator would then make unicast SLP service requests directly to these SAs, without the use of multicast to discover them first.

これらのネットワークでは、イニシエーターにより、DA構成の代わりに、またはDA構成に加えて、1つ以上のSAのアドレスを構成できます。 次に、イニシエータは、マルチキャストを使用して最初にそれらを検出することなく、これらのSAにユニキャストSLPサービス要求を直接行います。

This functionality is well within the scope of the current SLP protocol. The main consequence for implementors is that an initiator configured to make direct unicast requests to an SA will have to add this to the SLP API, if it is following the service location API defined in [RFC2614].

この機能は、現在のSLPプロトコルの範囲内です。 実装者の主な結果は、[RFC2614]で定義されたサービスロケーションAPIに従っている場合、SAに直接ユニキャスト要求を行うように構成されたイニシエーターがこれをSLP APIに追加する必要があることです。

4.2. Discovering Storage Management Services with SLP
4.2. SLPを使用したストレージ管理サービスの検出

Storage management servers can be built to manage and control access to targets in a variety of ways. They can provide extended services beyond discovery, which could include storage allocation and management. None of these services are defined here; the intent of this document is to allow these services to be discovered by both clients and servers, in addition to the target discovery already being performed.

ストレージ管理サーバーを構築して、さまざまな方法でターゲットへのアクセスを管理および制御できます。 ストレージの割り当てと管理を含む、発見を超えた拡張サービスを提供できます。 ここではこれらのサービスは定義されていません。 このドキュメントの目的は、既に実行されているターゲット検出に加えて、これらのサービスをクライアントとサーバーの両方で検出できるようにすることです。

The following drawing shows an iSCSI client, an iSCSI server, and a storage management server. To simplify the drawing, the second IP network is not shown but is assumed to exist. The storage management server would use its own protocol (smsp) to provide capabilities to iSCSI clients and servers; these clients and servers can both use SLP to discover the storage management server.

次の図は、iSCSIクライアント、iSCSIサーバー、およびストレージ管理サーバーを示しています。 図面を簡略化するために、2番目のIPネットワークは表示されていませんが、存在すると想定されています。 ストレージ管理サーバーは、独自のプロトコル(smsp)を使用して、iSCSIクライアントおよびサーバーに機能を提供します。 これらのクライアントとサーバーはどちらもSLPを使用してストレージ管理サーバーを検出できます。

      |         iSCSI Client      |
      |                           |
      |       +-----------+       |
      |       | iSCSI     |       |
      |       | initiator |       |
      |       +-----------+       |
      |                           |
      +---------------+------+----+      +------------+
      | iSCSI Driver  | smsp | UA |      |  SLP DA    |
      +---------------+------+----+      |            |
      |        TCP/UDP/IP         |      | (optional) |
      +---------------+------+----+      +------------+
               |                               |
               |   IP Network                  |
               |                          |
               |                          |
      +---------------+-----------+     +---------------------+
      |        TCP/UDP/IP         |     | TCP/UDP/IP          |
      +---------------+------+----+     +---------------------+
      | iSCSI Driver  | smsp | UA |     |   SA    |   smsp    |
      +---------------+------+----+     +---------------------+
      |                           |     |                     |
      | +--------+ +--------+     |     | storage mgmt server |
      | | iSCSI  | | iSCSI  |     |     |                     |
      | | target | | target |     |     +---------------------+
      | |   1    | |   2    |     |
      | +--------+ +--------+     |
      |                           |
      |     iSCSI Server          |

Note the difference between the storage management server model and the previously defined target discovery model. When target discovery was used, the iSCSI Server implemented an SA, to be discovered by the initiator's UA. In the storage management server model, the iSCSI clients and servers both implement UAs, and the management server implements the SA.

ストレージ管理サーバーモデルと以前に定義されたターゲット検出モデルの違いに注意してください。 ターゲット検出が使用されると、iSCSIサーバーは、イニシエーターのUAによって検出されるSAを実装しました。 ストレージ管理サーバーモデルでは、iSCSIクライアントとサーバーの両方がUAを実装し、管理サーバーがSAを実装します。

A storage management server's URL contains the domain name or IP address and TCP or UDP port number. No other information is required.

ストレージ管理サーバーのURLには、ドメイン名またはIPアドレスとTCPまたはUDPポート番号が含まれています。 他の情報は必要ありません。

The storage management server constructs a service advertisement of the type "service:iscsi:sms" for each of the addresses at which it appears. The advertisement contains the URL and a lifetime, along with other attributes that are defined in the service template.

ストレージ管理サーバーは、表示されるアドレスごとに「service:iscsi:sms」タイプのサービスアドバタイズメントを構築します。 アドバタイズメントには、サービステンプレートで定義されている他の属性とともに、URLとライフタイムが含まれます。

The remainder of the discovery procedure is identical to that used to discover iSCSI targets, except that both initiators and targets would normally be "clients" of the storage management service.


Targets that support a storage management service implement a UA in addition to the SA. A target may alternatively just implement the UA and allow the storage management service to advertise its targets appropriately by providing an SA and registering the appropriate service:iscsi:target registrations on the target's behalf: The target device would not have to advertise its own targets. This has no impact on the initiator.

ストレージ管理サービスをサポートするターゲットは、SAに加えてUAを実装します。 あるいは、ターゲットはUAを実装するだけで、ストレージ管理サービスがSAを提供し、適切なサービスを登録することにより、ターゲットを適切にアドバタイズできるようにします:iscsi:ターゲット登録をターゲットに代わって登録します:ターゲットデバイスは、自身のターゲットをアドバタイズする必要はありません。 これは、イニシエーターに影響を与えません。

This allows the initiators' discovery of targets to be completely interoperable regardless of which storage management service is used, or whether one is used at all, or whether the target registrations are provided directly by the target or by the management service.


4.3. Internationalization Considerations
4.3. 国際化に関する考慮事項

SLP allows internationalized strings to be registered and retrieved. Attributes in the template that are not marked with an 'L' (literal) will be registered in a localized manner. An "en" (English) localization MUST be registered, and others MAY be registered.

SLPでは、国際化された文字列を登録および取得できます。 'L'(リテラル)でマークされていないテンプレートの属性は、ローカライズされた方法で登録されます。 「en」(英語)のローカライズを登録する必要があり、他のローカライズも登録する必要があります。

Attributes that include non-ASCII characters will be encoded by using UTF-8, as discussed in [RFC3722] and [RFC3491].


5. iSCSI SLP Templates
5. iSCSI SLPテンプレート

Three templates are provided: an iSCSI target template, a management service template, and an abstract template to encapsulate the two.


5.1. The iSCSI Abstract Service Type Template
5.1. iSCSI抽象サービスタイプテンプレート

This template defines the abstract service "service:iscsi". It is used as a top-level service to encapsulate all other iSCSI-related services.

このテンプレートは、抽象サービス「service:iscsi」を定義します。 他のすべてのiSCSI関連サービスをカプセル化するためのトップレベルサービスとして使用されます。

Name of submitter: Mark Bakke Language of service template: en Security Considerations: See section 6.

提出者の名前:Mark Bakkeサービステンプレートの言語:jaセキュリティに関する考慮事項:セクション6を参照してください。

   Template Text:
   -------------------------template begins here-----------------------


template-description =

This is an abstract service type. The purpose of the iscsi service type is to encompass all of the services used to support the iSCSI protocol.

これは抽象サービスタイプです。 iscsiサービスタイプの目的は、iSCSIプロトコルをサポートするために使用されるすべてのサービスを網羅することです。

template-url-syntax= url-path= ; Depends on the concrete service type.

template-url-syntax = url-path =; 具体的なサービスの種類に依存します。

   --------------------------template ends here------------------------
5.2. The iSCSI Target Concrete Service Type Template
5.2. iSCSIターゲットの具象サービスタイプテンプレート

This template defines the service "service:iscsi:target". An entity containing iSCSI targets that wishes them discovered via SLP would register each of them, with each of their addresses, as this service type.

このテンプレートは、サービス「service:iscsi:target」を定義します。 SLPを介して検出されることを希望するiSCSIターゲットを含むエンティティは、このサービスタイプとして、各アドレスを各アドレスに登録します。

Initiators (and perhaps management services) wishing to discover targets in this way will generally use one of the following queries:


1. Find a specific target, given its iSCSI Target Name:

1. iSCSIターゲット名を指定して、特定のターゲットを見つけます。

        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   (

2. Find all of the iSCSI Target Names that may allow access to a given initiator:


        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   (

3. Find all of the iSCSI Target Names that may allow access to any initiator:


        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   (auth-name=any)

4. Find all of the iSCSI Target Names that may allow access to this initiator, or that will allow access to any initiator:


        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   &(

5. Find all of the iSCSI Target Names that may allow access to a given CHAP user name:


        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   (auth-cred=chap/my-user-name)

6. Find all of the iSCSI Target Names that may allow access to a given initiator that supports two IP addresses, a CHAP credential and SRP credential, and an initiator name:

6. 2つのIPアドレス、CHAP資格情報とSRP資格情報、およびイニシエーター名をサポートする特定のイニシエーターへのアクセスを許可するすべてのiSCSIターゲット名を検索します。

        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   &(|(

7. Find the iSCSI Target Names from which the given initiator is allowed to boot:


        Service: service:iscsi:target
        Scope:   initiator-scope-list
        Query:   (

8. In addition, a management service may wish to discover all targets:


        Service: service:iscsi:target
        Scope:   management-server-scope-list
        Query:   <empty-string>

More details on booting from an iSCSI target are defined in [BOOT].


Name of submitter: Mark Bakke Language of service template: en Security Considerations: see section 6.

提出者の名前:Mark Bakkeサービステンプレートの言語:jaセキュリティに関する考慮事項:セクション6を参照してください。

   Template Text:
   -------------------------template begins here-----------------------


template-description =

This is a concrete service type. The iscsi:target service type is used to register individual target addresses to be discovered by others. UAs will generally search for these by including one of the following:

これは具体的なサービスタイプです。 iscsi:targetサービスタイプは、他の人が発見する個々のターゲットアドレスを登録するために使用されます。 UAは通常、次のいずれかを含めてこれらを検索します。

- the iSCSI target name - iSCSI initiator identifiers (iSCSI name, credential, IP address) - the service URL


     url-path    = hostport "/" iscsi-name [ "/" identity ]
     hostport    = host [ ":" port ]
     host        = hostname / hostnumber  ; DNS name or IP address
     hostname    = *( domainlabel "." ) toplabel
     alphanum    = ALPHA / DIGIT
     domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
     toplabel    = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
     hostnumber  = ipv4-number / ipv6-addr  ; IPv4 or IPv6 address
     ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
     ipv6-addr   = "[" ipv6-number "]"
     ipv6-number =                              6( h16 ":" ) ls32
                   /                       "::" 5( h16 ":" ) ls32
                   / [               h16 ] "::" 4( h16 ":" ) ls32
                   / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                   / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                   / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                   / [ *4( h16 ":" ) h16 ] "::"              ls32
                   / [ *5( h16 ":" ) h16 ] "::"              h16
                   / [ *6( h16 ":" ) h16 ] "::"
     ls32        = ( h16 ":" h16 ) / ipv4-number
                   ; least-significant 32 bits of ipv6 address
     h16         = 1*4HEXDIG
     port        = 1*DIGIT
     iscsi-name  = iscsi-char ; iSCSI target name
     identity    = iscsi-char ; optional identity string
     iscsi-char  = ALPHA / DIGIT / escaped / ":" / "-" / "."
                   ; Intended to allow UTF-8 encoded strings
     escaped     = 1*("\" HEXDIG HEXDIG)
     ; The iscsi-name part of the URL is required and must be the iSCSI
     ; name of the target being registered.
     ; A device representing multiple targets must individually
     ; register each target/address combination with SLP.
     ; The identity part of the URL is optional, and is used to
     ; indicate an identity that is allowed to access this target.
     ; Example (split into two lines for clarity):
     ; service:iscsi:target://
     ; IPv6 addresses are also supported; they use the notation

; specified above and in [RFC3513], section 2.2

; 上記および[RFC3513]のセクション2.2で指定

iscsi-name = string # The iSCSI Name of this target. # This must match the iscsi-name in the url-path.

iscsi-name = string#このターゲットのiSCSI名。 #これは、url-pathのiscsi-nameと一致する必要があります。

portal-group = integer # The iSCSI portal group tag for this address. Addresses sharing # the same iscsi-name and portal-group tag can be used within the # same iSCSI session. Portal groups are described in [RFC3720].

portal-group = integer#このアドレスのiSCSIポータルグループタグ。 同じiSCSIセッション内で、同じiSCSI名とポータルグループタグを共有するアドレスを使用できます。 ポータルグループは[RFC3720]で説明されています。

transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. iSCSI is currently supported over TCP, # but it is anticipated that it could be supported over other # transports, such as SCTP, in the future. tcp

transports = string M L tcp#これは、登録されたエンティティがサポートするトランスポートプロトコルのリストです。 iSCSIは現在TCPでサポートされていますが、将来、SCTPなどの他のトランスポートでサポートされる可能性があります。 tcp

mgmt-entity = string O # The fully qualified domain name, or IP address in dotted-decimal # notation, of the management interface of the entity containing # this target. #

mgmt-entity = string O#このターゲットを含むエンティティの管理インターフェイスの完全修飾ドメイン名、またはドット付き10進表記のIPアドレス。 #

alias = string O # The alias string contains a descriptive name of the target.

alias = string O#エイリアス文字列には、ターゲットの説明的な名前が含まれます。

auth-name = string M X # A list of iSCSI Initiator Names that can access this target. # Normal iSCSI names will be 80 characters or less; max length # is 255. # Normally, only one or a few values will be in the list. # Using the equivalence search on this will evaluate to "true" # if any one of the items in this list matches the query. # If this list contains the default name "any", any initiator # is allowed to access this target, provided it matches # the other auth-xxx attributes. # # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented.

auth-name = string M X#このターゲットにアクセスできるiSCSIイニシエーター名のリスト。 #通常のiSCSI名は80文字以下です。 最大長#は255です。#通常、リストに含まれる値は1つまたは少数です。 #これで等価検索を使用すると、このリスト内のアイテムのいずれかがクエリに一致する場合、「true」と評価されます。 #このリストにデフォルト名「any」が含まれている場合、他のauth-xxx属性と一致する場合、イニシエーターはこのターゲットにアクセスできます。 ##この属性には、セキュリティポリシー情報が含まれています。 この属性が属性応答メッセージを介して配信される場合、IPsecを実装する必要があります。

auth-addr = string M X # A list of initiator IP addresses (or host names) which will # be allowed access to this target. If this list contains the # default name "any", any IP address is allowed access to this # target, provided it matches the other auth-xxx attributes.

auth-addr = string M X#このターゲットへのアクセスを許可されるイニシエーターIPアドレス(またはホスト名)のリスト。 このリストにデフォルト名「any」が含まれる場合、他のauth-xxx属性と一致する限り、任意のIPアドレスがこのターゲットへのアクセスを許可されます。

# # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented.

##この属性には、セキュリティポリシー情報が含まれています。 この属性が属性応答メッセージを介して配信される場合、IPsecを実装する必要があります。

auth-cred = string M X # A list of credentials which will be allowed access to the target # (provided they can provide the correct password or other # authenticator). Entries in this list are of the form # "method/identifier", where the currently defined methods are # "chap" and "srp", both of which take usernames as their # identifiers. # # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented.

auth-cred = string M X#ターゲットへのアクセスを許可される資格情報のリスト(正しいパスワードまたは他の認証#者を提供できる場合)。 このリストのエントリは、「method / identifier」という形式です。ここで、現在定義されているメソッドは「chap」と「srp」であり、どちらもユーザー名を識別子として使用します。 ##この属性には、セキュリティポリシー情報が含まれています。 この属性が属性応答メッセージを介して配信される場合、IPsecを実装する必要があります。

boot-list = string M O # A list of iSCSI Initiator Names that can boot from this target. # This list works precisely like the auth-name attribute. A name # appearing in this list must either appear in the access-list, # or the access-list must contain the initiator name "iscsi". # Otherwise, an initiator will be unable to find its boot # target. If boot-list contains the name "iscsi", any host can boot # from it, but I am not sure if this is useful to anyone. If this # attribute is not registered, this target is not "bootable". # # Note that the LUN the host boots from is not specified here; a # host will generally attempt to boot from LUN 0. # # It is quite possible that other attributes will need to be defined # here for booting as well. # # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented.

boot-list = string M O#このターゲットから起動できるiSCSIイニシエーター名のリスト。 #このリストは、auth-name属性とまったく同じように機能します。 このリストに表示される名前は、アクセスリストに表示されるか、アクセスリストにイニシエータ名「iscsi」が含まれている必要があります。 #それ以外の場合、イニシエーターはブートターゲットを見つけることができません。 boot-listに「iscsi」という名前が含まれる場合、どのホストからでも#を起動できますが、これが誰にとっても有用かどうかはわかりません。 この属性が登録されていない場合、このターゲットは「ブート可能」ではありません。 ##ホストの起動元のLUNはここでは指定されていないことに注意してください。 ホストは通常、LUN 0からの起動を試みます。##起動するために、ここで他の属性を定義する必要があります。 ##この属性には、セキュリティポリシー情報が含まれています。 この属性が属性応答メッセージを介して配信される場合、IPsecを実装する必要があります。

   --------------------------template ends here------------------------
5.3. iSCSI Storage Management Service Templates
5.3. iSCSIストレージ管理サービステンプレート

This template defines the service "service:iscsi:sms". An entity supporting one or more iSCSI management service protocols may register itself with SLP as this service type. iSCSI clients and servers wishing to discover storage management services using SLP will usually search for them by the protocol(s) they support:

このテンプレートは、サービス「service:iscsi:sms」を定義します。 1つ以上のiSCSI管理サービスプロトコルをサポートするエンティティは、このサービスタイプとして自身をSLPに登録できます。 SLPを使用してストレージ管理サービスを検出したいiSCSIクライアントおよびサーバーは、通常、サポートするプロトコルでそれらを検索します。

        Service: service:iscsi:sms
        Scope:   initiator-scope-list
        Query:   (protocols=isns)

Name of submitter: Mark Bakke Language of service template: en Security Considerations: see section 6.

提出者の名前:Mark Bakkeサービステンプレートの言語:jaセキュリティに関する考慮事項:セクション6を参照してください。

   Template Text:
   -------------------------template begins here-----------------------

template-description= This is a concrete service type. The iscsi:sms service type provides the capability for entities supporting iSCSI to discover appropriate management services.

template-description =これは具体的なサービスタイプです。 iscsi:smsサービスタイプは、iSCSIをサポートするエンティティが適切な管理サービスを検出する機能を提供します。

template-url-syntax= url-path = ; The URL of the management service [RFC2608].

template-url-syntax = url-path =; 管理サービスのURL [RFC2608]。

protocols = string M # The list of protocols supported by this name service. This # list may be expanded in the future. There is no default. # # "isns" - This management service supports the use of the iSNS # protocol for access management, health monitoring, and # discovery management services. This protocol is defined # in [ISNS]. isns

protocols = string M#このネームサービスがサポートするプロトコルのリスト。 このリストは将来拡張される可能性があります。 デフォルトはありません。 ## "isns"-この管理サービスは、アクセス管理、ヘルスモニタリング、および#発見管理サービスのためのiSNSプロトコルの使用をサポートします。 このプロトコルは[ISNS]で#定義されています。 isns

transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. tcp, udp

transports = string M L tcp#これは、登録されたエンティティがサポートするトランスポートプロトコルのリストです。 tcp、udp

server-priority = integer # The priority a client should give this server, when choosing # between multiple servers with the same protocol type. # When multiple servers are discovered for a given protocol type, # this parameter indicates their relative precedence. Server # precedence is protocol-specific; for some protocols, the primary # server may have the highest server-priority value, while for

server-priority = integer#同じプロトコルタイプの複数のサーバーから選択するときに、クライアントがこのサーバーに与える優先順位。 #特定のプロトコルタイプに対して複数のサーバーが検出された場合、このパラメーターは#相対的な優先順位を示します。 サーバー番号の優先順位はプロトコル固有です。 一部のプロトコルでは、プライマリサーバーが最高のサーバー優先度値を持つ場合がありますが、

# others it may have the lowest. For example, with iSNS, the primary # server has the lowest value (value 0).

#他の人は最低かもしれません。 たとえば、iSNSの場合、プライマリサーバーの値は最低(値0)です。

   --------------------------template ends here------------------------
6. Security Considerations

The SLPv2 security model as specified in [RFC2608] does not provide confidentiality but does provide an authentication mechanism for UAs to ensure that service advertisements only come from trusted SAs, with the exception that it does not provide a mechanism to authenticate "zero-result responses". See [RFC3723] for a discussion of the SLPv2 [RFC2608] security model.

[RFC2608]で指定されているSLPv2セキュリティモデルは機密性を提供しませんが、UAに認証メカニズムを提供して、サービスアドバタイズメントが信頼できるSAからのみ来ることを保証します。 「。 SLPv2 [RFC2608]セキュリティモデルの説明については、[RFC3723]を参照してください。

Once a target or management server is discovered, authentication and authorization are handled by the iSCSI protocol, or by the management server's protocol. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service does not compromise their security.

ターゲットまたは管理サーバーが検出されると、iSCSIプロトコルまたは管理サーバーのプロトコルによって認証と承認が処理されます。 不適切に広告または発見されたサービスがセキュリティを侵害しないようにすることは、これらのサービスのプロバイダーの責任です。

When no security is used for SLPv2, there is a risk of distribution of false discovery information. The primary countermeasure for this risk is authentication. When this risk is a significant concern, IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI traffic subject to this risk to ensure that iSCSI traffic only flows between endpoints that have participated in IKE authentication and iSCSI in-band authentication. For example, if an attacker distributes discovery information falsely claiming that it is an iSCSI target, it will lack the secret information necessary to complete IKE authentication or iSCSI in-band authentication successfully and therefore will be prevented from falsely sending or receiving iSCSI traffic.

SLPv2にセキュリティが使用されていない場合、誤った検出情報が配布されるリスクがあります。 このリスクの主な対策は認証です。 このリスクが重大な懸念事項である場合、IPsec SAおよびiSCSI帯域内認証をこのリスクの対象となるiSCSIトラフィックに使用して、IKE認証とiSCSI帯域内認証に参加したエンドポイント間のみiSCSIトラフィックが流れるようにする必要があります。 たとえば、攻撃者がiSCSIターゲットであると誤って主張する発見情報を配布した場合、IKE認証またはiSCSIインバンド認証を正常に完了するために必要な秘密情報が不足するため、iSCSIトラフィックを誤って送受信することはできません。

A risk remains 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 iSCSI Target 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 iSCSI Target that fails to authenticate. These three measures (i.e., IP address range limits, DNS domain limits, negative authentication cache) MUST be implemented.

IKEネゴシエーションの開始を引き起こす偽の発見情報の繰り返し使用に基づくサービス拒否攻撃のリスクが残っています。 これに対する対策は、通信するピアを制限する(つまり、IPアドレス範囲やDNSドメインによって)各iSCSIターゲットの管理構成、およびiSCSIターゲットに繰り返しアクセスすることを避けるためのネガティブ認証キャッシュの維持です。 認証に失敗しました。 これらの3つの手段(IPアドレス範囲の制限、DNSドメインの制限、ネガティブ認証キャッシュ)を実装する必要があります。

The auth-name, auth-addr, auth-cred, and boot-list attributes comprise security policy information. When these are distributed, IPsec MUST be implemented.

auth-name、auth-addr、auth-cred、およびboot-list属性は、セキュリティポリシー情報を構成します。 これらが配布されるとき、IPsecが実装されなければなりません。

6.1. Security Implementation
6.1. セキュリティ実装

Security for SLPv2 in an IP storage environment is specified in [RFC3723]. IPsec is mandatory-to-implement for IPS clients and servers. Thus, all IP storage clients, including those invoking SLP, can be assumed to support IPsec. SLP servers, however, cannot be assumed to implement IPsec, since there is no such requirement in standard SLP. In particular, SLP Directory Agents (DA) may be running on machines other than those running the IPS protocols.

IPストレージ環境でのSLPv2のセキュリティは、[RFC3723]で指定されています。 IPsecは、IPSクライアントおよびサーバーの実装に必須です。 したがって、SLPを呼び出すクライアントを含むすべてのIPストレージクライアントは、IPsecをサポートすると想定できます。 ただし、標準のSLPにはそのような要件がないため、SLPサーバーはIPsecの実装を想定できません。 特に、SLP Directory Agent(DA)は、IPSプロトコルを実行しているマシン以外のマシンで実行されている場合があります。

IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this includes ESP with a non-null transform to provide both authentication and confidentiality.

[RFC3723]で指定されているように、IPsecはSLPv2に実装される必要があります。 これには、認証と機密性の両方を提供する非ヌル変換を備えたESPが含まれます。

When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred, and boot-list information (see section 5.2 above), IPsec MUST be implemented, as these items are considered sensitive security policy information. If IPsec is not implemented, auth-name, auth-addr, auth-cred, and boot-list information MUST NOT be distributed via SLPv2 and MUST NOT be used if discovered via SLPv2.

SLPv2を使用してauth-name、auth-addr、auth-cred、およびboot-list情報を配布できる場合(上記のセクション5.2を参照)、これらの項目は機密性の高いセキュリティポリシー情報と見なされるため、IPsecを実装する必要があります。 IPsecが実装されていない場合、auth-name、auth-addr、auth-cred、およびboot-listの情報をSLPv2経由で配布してはならず、SLPv2経由で発見された場合は使用しないでください。

Because the IP storage services have their own authentication capabilities when located, SLPv2 authentication is OPTIONAL to implement and use (as discussed in more detail in [RFC3723]).


7. IANA Considerations
7. IANAの考慮事項

This document describes three SLP Templates. They have been reviewed and approved by the IESG and registered in the IANA's "SVRLOC Templates" registry. This process is described in the IANA Considerations section of [RFC2609].

このドキュメントでは、3つのSLPテンプレートについて説明します。 IESGによってレビューおよび承認され、IANAの「SVRLOCテンプレート」レジストリに登録されています。 このプロセスは[RFC2609]のIANA考察セクションで説明されます。

8. Summary

This document describes how SLP can be used by iSCSI initiators to find iSCSI targets and storage management servers. Service type templates for iSCSI targets and storage management servers are presented.

このドキュメントでは、iSCSIイニシエーターがSLPを使用してiSCSIターゲットとストレージ管理サーバーを見つける方法について説明します。 iSCSIターゲットおよびストレージ管理サーバーのサービスタイプテンプレートが表示されます。

9. Normative References

[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「Service Location Protocol、Version 2」、RFC 2608、1999年6月。

[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999.

[RFC2609] Guttman、E.、Perkins、C。、およびJ. Kempf、「Service Templates and Service:Schemes」、RFC 2609、1999年6月。

[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月。

[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.

[RFC3491] Hoffman、P。およびM. Blanchet、「Nameprep:国際化ドメイン名(IDN)のStringprepプロファイル」、RFC 3491、2003年3月。

[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.

[RFC3513] Hinden、R。、およびS. Deering、「インターネットプロトコルバージョン6(IPv6)アドレス指定アーキテクチャ」、RFC 3513、2003年4月。

[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.

[RFC3720] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M。、およびE. Zeidner、「Internet Small Computer Systems Interface(iSCSI)」、RFC 3720、2004年4月。

[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.

[RFC3722] Bakke、M。、「インターネットスモールコンピュータシステムインターフェイス(iSCSI)名の文字列プロファイル」、RFC 3722、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、「Securing Block Storage Protocols over IP」、RFC 3723、2004年4月。

10. Informative References

[RFC2614] Kempf, J. and E. Guttman, "An API for Service Location", RFC 2614, June 1999.

[RFC2614] Kempf、J。、およびE. Guttman、「サービスロケーションのAPI」、RFC 2614、1999年6月。

[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.

[SAM2] ANSI T10。 「SCSIアーキテクチャモデル2」、2000年3月。

[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.

[RFC3721] Bakke、M.、Hafner、J.、Hufferd、J.、Voruganti、K。、およびM. Krueger、「Internet Small Computer Systems Interface(iSCSI)Naming and Discovery」、RFC 3721、2004年4月

[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. Souza, "Internet Storage Name Service", Work in Progress, February 2004.

[ISNS] Tseng、J.、Gibbons、K.、Travostino、F.、Du Laney、C.、J。Souza、「インターネットストレージネームサービス」、Work in Progress、2004年2月。

[BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard for Bootstrapping Clients using the iSCSI Protocol", Work in Progress, March 2004.

[BOOT] Sarkar、P.、Missimer、D.およびC. Sapuntzakis、「iSCSIプロトコルを使用したクライアントのブートストラップの標準」、Work in Progress、2004年3月。

[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.

[RFC3105] Kempf、J。、およびG. Montenegro、「SLPを使用したRSIPサーバーの検索」、RFC 3105、2001年10月。

11. Acknowledgements

This document was produced by the iSCSI Naming and Discovery team, including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad), Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt Peterson (Caldera) and James Kempf (Sun) for reviewing the document from an SLP perspective.

このドキュメントは、Joe Czap、Jim Hafner、John Hufferd、Kaladhar Voruganti(IBM)、Howard Hall(Pirus)、Jack Harwood(EMC)、Yaron Klein(Sanrad)、Marjorie Krueger(iSCSI Naming and Discovery team)によって作成されました HP)、Lawrence Lamers(San Valley)、Todd Sperry(Adaptec)、およびJoshua Tseng(Nishan)。 また、iSCSIディスカバリーにSLPを使用することを提案してくれたJulian Satran(IBM)、およびSLPの観点から文書をレビューしてくれたMatt Peterson(Caldera)とJames Kempf(Sun)にも感謝します。

Authors' Addresses


Mark Bakke Cisco Systems, Inc. 7900 International Drive, Suite 400 Bloomington, MN USA 55425

Mark Bakke Cisco Systems、Inc. 7900 International Drive、Suite 400 Bloomington、MN 55425アメリカ合衆国



Kaladhar Voruganti IBM Almaden Research Center 650 Harry Road San Jose, CA 95120

Kaladhar Voruganti IBM Almaden Research Center 650 Harry Road San Jose、CA 95120



John L. Hufferd IBM Storage Systems Group 5600 Cottle Road San Jose, CA 95193

John L. Hufferd IBM Storage Systems Group 5600 Cottle Road San Jose、CA 95193

Phone: +1 408 997-6136 EMail:

電話:+1 408 997-6136電子メール

Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville, CA 95747-5668, USA

Marjorie Krueger Hewlett-Packard Corporation 8000 Foothills Blvd Roseville、CA 95747-5668、USA

Phone: +1 916 785-2656 EMail:

電話:+1 916 785-2656電子メール

Todd Sperry Adaptec, Inc. 691 South Milpitas Boulevard Milpitas, Ca. 95035

Todd Sperry Adaptec、Inc. 691 South Milpitas Boulevardミルピタス、CA 95035

Phone: +1 408 957-4980 EMail:

電話:+1 408 957-4980電子メール

Full Copyright Statement


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に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。


本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者(もしあれば)、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。

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

IETF事務局に行われた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は、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能の資金は、現在インターネット協会によって提供されています。