RFC4018 日本語訳
4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2(SLPv2). M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. April 2005. (Format: TXT=48498 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Bakke
Request for Comments: 4018 Cisco
Category: Standards Track J. Hufferd
K. Voruganti
IBM
M. Krueger
HP
T. Sperry
Adaptec
April 2005
コメントを求めるワーキンググループM.バッキー要求をネットワークでつないでください: 4018年のコクチマスカテゴリ: 標準化過程J.Hufferd K.Voruganti IBM M.クルーガーhp T.スペリーAdaptec2005年4月
Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
Using Service Locationプロトコルバージョン2はインターネットSmallコンピュータシステムズInterface(iSCSI)目標とName Serversを見つけます。(SLPv2)
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
要約
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デバイスにアクセスする方法を提供します。 このドキュメントはService Locationプロトコル(SLP)のiSCSIホスト、デバイス、および経営指導による使用を定義します、それらが提供するサービスについて説明する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. 序論… 2 2. 記法コンベンション… 2 3. 用語… 3 4. iSCSIにSLPを使用して、発見を修理してください… 4 5. iSCSI SLPテンプレート… 11 6. セキュリティ問題… 18 7. IANA問題… 19 8. 概要… 19 9. 標準の参照… 19 10. 有益な参照… 20 11. 承認… 21
Bakke & Hufferd Standards Track [Page 1] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[1ページ]RFC4018iSCSIとSLPv2 April 2005
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用途aクライアントサーバ関係の上で定義されます。 接続のクライアント終わりは創始者です、そして、コマンドを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創始者がそれが接続するべきである目標を見つけるのに使用できるいくつかのメソッドがあります。 SLPの使用なしでこれらの2つのメソッドを達成できます:
- 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].
上のメソッドは「iSCSI命名と発見要件」[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プロトコル(SLP)[RFC2608]はiSCSIサービスの場所を見つけるいくつかの特徴にそれを提供すると簡略化するIETF標準化過程プロトコルです。 このドキュメントは目標、目標を提供するアドレス、およびストレージ管理サーバーを発見するのにiSCSI環境でどうSLPを使用できるかを説明します。
2. Notation Conventions
2. 記法コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
Bakke & Hufferd Standards Track [Page 2] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[2ページ]RFC4018iSCSIとSLPv2 April 2005
3. Terminology
3. 用語
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)Aは、何らかのサービスで接触するようにクライアントの代理に取り組みながら、処理します。 UAはServiceエージェントかディレクトリエージェントからのサービス情報を検索します。
Service Agent (SA) A process working on behalf of one or more
services to advertise the services and
their capabilities.
1を代表して働いているプロセスか以上がサービスと彼らの能力の広告を出すためにサービスを提供するエージェント(SA)にサービスを提供してください。
Directory Agent (DA) A process that collects service
advertisements. There can only be one DA
present per given host.
サービス広告を集めるディレクトリエージェント(DA)Aプロセス。 与えられたホストあたりの現在の1DAしかあることができません。
Scope A named set of services, typically making
up a logical administrative group.
論理的な管理グループを通常構成していて、範囲Aはサービスのセットを命名しました。
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.
サービスを提供するサービスAdvertisement A URL、属性、および寿命(広告がどれくらい長い間有効であるかを示す)は特定のサービスのための情報と能力記述にアクセスします。
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を送る創始者のA論理的な実体は実行されると目標に命令します。 通常、創始者はデバイスドライバの形に出席しています。
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コマンドを受け取って、それらを実行するストレージコントローラかゲートウェイの中でA論理的な実体を狙ってください。 目標は1Logical Units(LUs)を含んでいます。 各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 Name A UTF-8文字列。 その書式と用法は[RFC3721]でさらに定義されます。
iSCSI Client A logical entity, typically a host that
includes at least one iSCSI Initiator.
iSCSI ClientのA論理的な実体、通常少なくとも1iSCSI Initiatorを含んでいるホスト。
Bakke & Hufferd Standards Track [Page 3] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[3ページ]RFC4018iSCSIとSLPv2 April 2005
iSCSI Server A logical entity, typically a storage
controller or gateway that includes at
least one iSCSI Target.
通常少なくとも1iSCSI Targetを含んでいるiSCSI ServerのA論理的な実体、ストレージコントローラまたはゲートウェイ。
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環境のためになる経営指導を提供するストレージのManagement Server Anのアドレス可能な実体。 「ストレージ管理サーバー」は、総称として利用されて、特定のプロトコルかサービスを示しません。
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.
2つの実体がiSCSI発見にかかわります。 結末は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目標は1セットのサービスURLとしてSLPに登録されます、目標がアクセスされるかもしれない各アドレスあたり1つ。 創始者は、SLPサービスのリクエストを使用することによって、これらの目標を発見します。 直接SLPをサポートしないか、または経営指導のコントロールの下にある目標はこのサービスを提供するソフトウェアの一部として代理業務エージェントによって登録されるかもしれません。
iSCSI entities may also use SLP to discover higher-level management services when these are needed.
また、iSCSI実体は、これらが必要であるときに、よりハイレベルの経営指導を発見するのにSLPを使用するかもしれません。
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.
このセクションは最初に、SLPのiSCSI創始者による目標の発見の使用について説明して、次に、それは、ストレージ管理サーバーを発見するためにSLPの使用について説明します。
This document assumes that SLPv2 will be used for discovering iSCSI- related services; no attempt is made to include support for SLPv1.
このドキュメントは、SLPv2がiSCSIがサービスを関係づけたと発見するのに使用されると仮定します。 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サーバインクルード少なくとも1iSCSIはSLPサービスエージェント(SA)を狙います。 拡張コピーエンジンなどのいくつかの実体が創始者と目標の両方を含んでいます。 発見されるべき目標のためのSAと別に発見する創始者のためのUAの両方が狙うこれらのインクルード。
Bakke & Hufferd Standards Track [Page 4] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[4ページ]RFC4018iSCSIとSLPv2 April 2005
+---------------------------------+
| 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 |
| 192.0.2.131 | 192.0.2.3 |
+-----------------+-----------------+
| TCP/UDP/IP |
+---------------------------+-------+
| iSCSI Driver | SA |
+---------------------------+-------|
| |
| +--------+ +--------+ +---------+ |
| | iSCSI | | iSCSI | | iSCSI | |
| | target | | target | | target | |
| | "one" | | "two" | | "three" | |
| +--------+ +--------+ +---------+ |
| iSCSI Server |
+-----------------------------------+
+---------------------------------+ | iSCSIクライアント| | +-----------+ | | | iSCSI| | | | 創始者| | | | "myhost"| | | +-----------+ | | | +--------------------------+------+ | iSCSIドライバー| Ua| +--------------------------+------+ | TCP/UDP/IP| +----------------+----------------+ | インタフェース1| インタフェース2| +----------------+----------------+ | | +------------+ | | +------------+ | SLP DA| | | | SLP DA| | (任意)です。 |----+ IPネットワーク+----| (任意)です。 | +------------+ | | +------------+ | | +-----------------+-----------------| | インタフェース1| インタフェース2| | 192.0.2.131 | 192.0.2.3 | +-----------------+-----------------+ | TCP/UDP/IP| +---------------------------+-------+ | iSCSIドライバー| SA| +---------------------------+-------| | | | +--------+ +--------+ +---------+ | | | iSCSI| | iSCSI| | iSCSI| | | | 目標| | 目標| | 目標| | | | 「1つ」| | 「2」| | 「3」| | | +--------+ +--------+ +---------+ | | iSCSIサーバ| +-----------------------------------+
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".
「1」、「2」、および「3」は、上の図面では、iSCSIサーバがクライアントが発見できる3個のiSCSI目標を持っていると命名しました。 iSCSIクライアントには、iSCSI創始者が"myhost"という名前と共にいます。 iSCSIクライアントは、構成される目標だけが"myhost"からiSCSI接続を受け入れると発見するのにフィルタとしてSLP Service Requestsの創始者名を使用するかもしれません。
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
iSCSI Nameは、各iSCSI目標と創始者にはユニークな名前があると呼びました。 この識別子がネットワーク経路にかかわらず同じである、(ストレージでのアダプターカード、ネットワーク、およびインタフェース
Bakke & Hufferd Standards Track [Page 5] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[5ページ]RFC4018iSCSIとSLPv2 April 2005
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.
デバイス) 目標が発見されて、アクセスされる。 この例に関しては、「1」というiSCSI名、「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.
2つのネットワーク・インターフェースが存在しているので、図面のそれぞれのiSCSI目標は2つのアドレスに現れることができます。 各目標には、2つのサービスURLがあるでしょう、ただ一つのサービスURLがDNSホスト名マッピングを両方のアドレスに含んでいなかったなら。
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のためのタイプ「サービス:iscsi:目標」レジスタのサービス広告を構成します。 広告はサービステンプレートで定義される他の属性に伴う生涯を含んでいます。
If the server in the above drawing is listening at TCP port 3260 for both network addresses, the service URLs registered would be
上の図面のサーバが両方のネットワーク・アドレスのためにTCPポート3260で聴かれているなら、URLが登録したサービスは聴いているでしょう。
- 192.0.2.131:3260/one
- 192.0.2.131 : 3260/1
- 192.0.2.131:3260/two
- 192.0.2.131 : 3260/2
- 192.0.2.131:3260/three
- 192.0.2.131 : 3260/3
- 192.0.2.3:3260/one
- 192.0.2.3 : 3260/1
- 192.0.2.3:3260/two
- 192.0.2.3 : 3260/2
- 192.0.2.3:3260/three
- 192.0.2.3 : 3260/3
The remainder of the discovery procedure is identical to that used by any client/server pair implementing SLP:
発見手順の残りは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に連絡して、サービス広告を登録します。 1SLPv2 DAsが発見されるか否かに関係なく、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
2. iSCSI創始者がiSCSI目標のための問い合わせ先を必要とするとき、マルチキャストを使用することによってユニキャストかSAを使用することによって、UAはDAに連絡します。 UAがSAのアドレスによって構成されるなら、それは、マルチキャストを避けて、SAに連絡するかもしれません。
Bakke & Hufferd Standards Track [Page 6] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[6ページ]RFC4018iSCSIとSLPv2 April 2005
by using unicast. The UA includes a query based on the
attributes to indicate the characteristics of the target(s) it
requires.
ユニキャストを使用することによって。 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 Target Nameと同様に、それは通常の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.
iSCSI目標テンプレートに含まれた情報が一般的なネットワークデータグラムサイズを超えているとき、このテンプレートを支えるUAsとSAsの両方のためのSLP実装はTCPの上でSLPを実装しなければなりません。
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
- iSCSI創始者名
- An IP address
- IPアドレス
- A CHAP, SRP, or Kerberos credential
- CHAP、SRP、またはケルベロス資格証明書
- 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-名前: この属性はどんな特定の創始者名も「いずれ」、表示ではありませんが、必要であることで、名前からこの目標、または値にアクセスした創始者のリストを含んでいます。
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アドレスは「いずれも」にこの目標、または値にアクセスします、どんな特定のアドレスもホスト名も必要でないことを示して。 多くのアドレスがそうであるなら許容されていて(恐らくサブネット)、この属性が値を含むかもしれないということになるためには「いくらか。」
Bakke & Hufferd Standards Track [Page 7] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[7ページ]RFC4018iSCSIとSLPv2 April 2005
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-信用: この属性は目標へのアクセスが許される「メソッド/識別子」資格証明書のリストを含んでいます、ログインプロセスの間、正しいパスワードか他の検証を作り出すことができるなら。 いいえなら、特定の資格証明書が必要であり、値は使用される「いずれも」です。
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-信用のための有効なメソッドストリングのリストは[RFC3720]、"AuthMethod"というセクション11.1で定義されます。 「後に使用された識別子、」 /、」 特定のAuthMethod、[RFC3720]ではも、定義されます。 創始者検索が属性を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属性が安全保障政策情報であると考えられることに注意してください。 これらの属性が分散されているなら、指定されるとして下のSecurity Implementation部でIPsecを実装しなければなりません。
4.1.2. Supporting Access by Multiple Identities to the Same Target
4.1.2. 同じ目標への複数のアイデンティティでアクセスをサポートします。
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
目標が複数のホストのアイデンティティへのアクセスを許すことであるなら、auth-xxxx属性の1つ以上の組み合わせが許されなければならないでしょう。 これらの場合のいくつかでは、ただ一つの登録されたサービスURLの中にauth-xxxx属性の全体の有効な組み合わせを表すのは可能ではありません。 目標がそうすることができるなら、例えば、扱われてください。
auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)
auth名=のmyhost1とauth-信用はCHAP/user1と等しいです。(identity1)
OR
OR
auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)
auth名前myhost2とauth-信用は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).
ただ一つの登録されたサービスURLで上記を指定できません、(auth名=のmyhost1、auth名=のmyhost2、auth-信用=CHAP/user1、auth-信用=CHAP/user2)は、どちらのauth-名前もauth-信用と共に使用されるのを許容するでしょう、したがって。 これは1つ以上のサービスURLの下で目標とアドレスを登録する能力を必要とします。 (identity1)のためのものと(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がユニークであるに違いないので、ユニークなサービスURLの下でそれぞれ(identity1)と(identity2)を登録しなければなりません。 目標にアクセスするために複数のアイデンティティの構成をサポートするシステムのために、サービスURLはアイデンティティを定義する追加していて、不透明なストリングを含まなければなりません。 「これは、iSCSIが中でURLストリングを命名した後に現れて、a」/によって切り離されます。」 そして、それぞれの登録された(あて先アドレス、目標名、創始者アイデンティティ)tupleは1セットのauth-xxxx属性を示すことができます。
Bakke & Hufferd Standards Track [Page 8] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[8ページ]RFC4018iSCSIとSLPv2 April 2005
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クライアントとサーバの間に置かれる公衆かサービスプロバイダーネットワークを含んでいます。たぶん2iSCSI門と、ストレージサービスプロバイダーサイトの1と、顧客サイトの1の間で最も一般的です。
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.
これらのネットワークでは、創始者は、1SAsのアドレスが構成かDA構成に加えて構成されるのを許すかもしれません。 そして、創始者は、最初に彼らを発見するためにマルチキャストの使用なしでユニキャストSLPサービスを直接これらのSAsへの要求にするでしょう。
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プロトコルの範囲のかなり中にこの機能性はあります。 作成者にとって、主な結果はダイレクトユニキャスト要求をSAにするように構成された創始者がSLP APIにこれを加えなければならないということです、[RFC2614]で定義されたサービス位置の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ネットワークは、示されませんが、存在すると思われます。 ストレージ管理サーバーはiSCSIクライアントとサーバに能力を提供するのに、それ自身のプロトコル(smsp)を使用するでしょう。 これらのクライアントとサーバは、ストレージ管理サーバーを発見するのにともにSLPを使用できます。
Bakke & Hufferd Standards Track [Page 9] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[9ページ]RFC4018iSCSIとSLPv2 April 2005
+---------------------------+
| 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 |
+---------------------------+
+---------------------------+ | iSCSIクライアント| | | | +-----------+ | | | iSCSI| | | | 創始者| | | +-----------+ | | | +---------------+------+----+ +------------+ | iSCSIドライバー| smsp| Ua| | SLP DA| +---------------+------+----+ | | | TCP/UDP/IP| | (任意)です。 | +---------------+------+----+ +------------+ | | | IPネットワーク| ------------------------------------------ | | | | +---------------+-----------+ +---------------------+ | TCP/UDP/IP| | TCP/UDP/IP| +---------------+------+----+ +---------------------+ | iSCSIドライバー| smsp| Ua| | SA| smsp| +---------------+------+----+ +---------------------+ | | | | | +--------+ +--------+ | | ストレージ管理サーバ| | | iSCSI| | iSCSI| | | | | | 目標| | 目標| | +---------------------+ | | 1 | | 2 | | | +--------+ +--------+ | | | | iSCSIサーバ| +---------------------------+
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.
保管管理サーバモデルと以前に定義された目標発見モデルの違いに注意してください。 目標発見が使用されたとき、創始者のUAによって発見されるように、iSCSI ServerはSAを実装しました。 保管管理サーバモデルでは、iSCSIクライアントとサーバは、UAs、および管理サーバー道具が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.
ストレージ管理サーバーはそれが載っているそれぞれのアドレスのためのタイプ「サービス:iscsi:sms」のサービス広告を構成します。 広告はサービステンプレートで定義される他の属性に伴うURLと生涯を含んでいます。
Bakke & Hufferd Standards Track [Page 10] RFC 4018 iSCSI and SLPv2 April 2005
バッキーとHufferd標準化過程[10ページ]RFC4018iSCSIとSLPv2 April 2005
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.
発見手順の残りはiSCSI目標を発見するのに使用されるそれと同じです、通常、創始者と目標の両方がストレージ経営指導の「クライアント」であるだろうというのを除いて。
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.
これは、どのストレージ経営指導が使用されているか、そして、1つを全く使用するかどうか、または直接目標か経営指導で目標登録証明書を提供するかどうかにかかわらず創始者の目標の発見が完全に共同利用できるのを許容します。
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'(リテラル)と共にマークされない属性はローカライズしている方法で示されるでしょう。 「アン」(イギリス)のローカライズを登録しなければなりません、そして、他のものは登録されるかもしれません。
Attributes that include non-ASCII characters will be encoded by using UTF-8, as discussed in [RFC3722] and [RFC3491].
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 Templates
Three templates are provided: an iSCSI target template, a management service template, and an abstract template to encapsulate the two.
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. The iSCSI Abstract Service Type Template
This template defines the abstract service "service:iscsi". It is used as a top-level service to encapsulate all other iSCSI-related services.
This template defines the abstract service "service:iscsi". It is used as a top-level service to encapsulate all other iSCSI-related services.
Name of submitter: Mark Bakke Language of service template: en Security Considerations: See section 6.
Name of submitter: Mark Bakke Language of service template: en Security Considerations: See section 6.
Template Text: -------------------------template begins here----------------------- template-type=iscsi template-version=1.0
Template Text: -------------------------template begins here----------------------- template-type=iscsi template-version=1.0
template-description=
template-description=
Bakke & Hufferd Standards Track [Page 11] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 11] RFC 4018 iSCSI and SLPv2 April 2005
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.
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.
template-url-syntax=
url-path= ; Depends on the concrete service type.
template-url-syntax= url-path= ; Depends on the concrete service type.
--------------------------template ends here------------------------
--------------------------template ends here------------------------
5.2. The iSCSI Target Concrete Service Type Template
5.2. The iSCSI Target Concrete Service Type Template
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.
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.
Initiators (and perhaps management services) wishing to discover targets in this way will generally use one of the following queries:
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. Find a specific target, given its iSCSI Target Name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (iscsi-name=iqn.2001-04.com.example:sn.456)
Service: service:iscsi:target Scope: initiator-scope-list Query: (iscsi-name=iqn.2001-04.com.example:sn.456)
2. Find all of the iSCSI Target Names that may allow access to a
given initiator:
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: (auth-name=iqn.1998-03.com.example:hostid.045A7B)
Service: service:iscsi:target Scope: initiator-scope-list Query: (auth-name=iqn.1998-03.com.example:hostid.045A7B)
3. Find all of the iSCSI Target Names that may allow access to
any initiator:
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)
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:
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: &(auth-name=iqn.1998-03.com.example:hostid.045A7B)
(auth-name=any)
Service: service:iscsi:target Scope: initiator-scope-list Query: &(auth-name=iqn.1998-03.com.example:hostid.045A7B) (auth-name=any)
Bakke & Hufferd Standards Track [Page 12] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 12] RFC 4018 iSCSI and SLPv2 April 2005
5. Find all of the iSCSI Target Names that may allow access to
a given CHAP user name:
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)
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. 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:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any)
|(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any)
|(auth-cred=chap/foo)(auth-cred=srp/my-user-name)
(auth-cred=any))
Service: service:iscsi:target Scope: initiator-scope-list Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any) |(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any) |(auth-cred=chap/foo)(auth-cred=srp/my-user-name) (auth-cred=any))
7. Find the iSCSI Target Names from which the given initiator is
allowed to boot:
7. Find the iSCSI Target Names from which the given initiator is allowed to boot:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B)
Service: service:iscsi:target Scope: initiator-scope-list Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B)
8. In addition, a management service may wish to discover all
targets:
8. In addition, a management service may wish to discover all targets:
Service: service:iscsi:target
Scope: management-server-scope-list
Query: <empty-string>
Service: service:iscsi:target Scope: management-server-scope-list Query: <empty-string>
More details on booting from an iSCSI target are defined in [BOOT].
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.
Name of submitter: Mark Bakke Language of service template: en Security Considerations: see section 6.
Template Text: -------------------------template begins here----------------------- template-type=iscsi:target template-version=1.0
Template Text: -------------------------template begins here----------------------- template-type=iscsi:target template-version=1.0
template-description=
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
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
Bakke & Hufferd Standards Track [Page 13] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 13] RFC 4018 iSCSI and SLPv2 April 2005
the following:
the following:
- the iSCSI target name
- iSCSI initiator identifiers (iSCSI name, credential, IP address)
- the service URL
- the iSCSI target name - iSCSI initiator identifiers (iSCSI name, credential, IP address) - the service URL
template-url-syntax=
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://192.0.2.3:3260/
; iqn.2001-04.com.example:sn.45678
;
; IPv6 addresses are also supported; they use the notation
template-url-syntax= 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://192.0.2.3:3260/ ; iqn.2001-04.com.example:sn.45678 ; ; IPv6 addresses are also supported; they use the notation
Bakke & Hufferd Standards Track [Page 14] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 14] RFC 4018 iSCSI and SLPv2 April 2005
; specified above and in [RFC3513], section 2.2
; specified above and in [RFC3513], section 2.2
iscsi-name = string # The iSCSI Name of this target. # This must match the iscsi-name in the url-path.
iscsi-name = string # The iSCSI Name of this target. # This must match the iscsi-name in the url-path.
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 # 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].
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 # 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
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 # The fully qualified domain name, or IP address in dotted-decimal # notation, of the management interface of the entity containing # this target. #
alias = string O # The alias string contains a descriptive name of the target.
alias = string O # The alias string contains a descriptive name of the target.
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 # 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-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 # 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.
Bakke & Hufferd Standards Track [Page 15] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 15] RFC 4018 iSCSI and SLPv2 April 2005
# # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented.
# # 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 # 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 # 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.
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 # 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.
--------------------------template ends here------------------------
--------------------------template ends here------------------------
5.3. iSCSI Storage Management Service Templates
5.3. iSCSI Storage Management Service Templates
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:
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:
Bakke & Hufferd Standards Track [Page 16] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 16] RFC 4018 iSCSI and SLPv2 April 2005
Service: service:iscsi:sms
Scope: initiator-scope-list
Query: (protocols=isns)
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.
Name of submitter: Mark Bakke Language of service template: en Security Considerations: see section 6.
Template Text: -------------------------template begins here----------------------- template-type=iscsi:sms template-version=1.0
Template Text: -------------------------template begins here----------------------- template-type=iscsi:sms template-version=1.0
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= This is a concrete service type. The iscsi:sms service type provides the capability for entities supporting iSCSI to discover appropriate management services.
template-url-syntax=
url-path = ; The URL of the management service [RFC2608].
template-url-syntax= url-path = ; The URL of the management service [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 # 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
transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. tcp, udp
transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. 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 # 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
Bakke & Hufferd Standards Track [Page 17] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 17] RFC 4018 iSCSI and SLPv2 April 2005
# others it may have the lowest. For example, with iSNS, the primary # server has the lowest value (value 0).
# others it may have the lowest. For example, with iSNS, the primary # server has the lowest value (value 0).
--------------------------template ends here------------------------
--------------------------template ends here------------------------
6. Security Considerations
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.
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.
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.
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.
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.
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.
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.
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.
The auth-name, auth-addr, auth-cred, and boot-list attributes comprise security policy information. When these are distributed, IPsec MUST be implemented.
The auth-name, auth-addr, auth-cred, and boot-list attributes comprise security policy information. When these are distributed, IPsec MUST be implemented.
Bakke & Hufferd Standards Track [Page 18] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 18] RFC 4018 iSCSI and SLPv2 April 2005
6.1. Security Implementation
6.1. Security Implementation
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.
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.
IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this includes ESP with a non-null transform to provide both authentication and confidentiality.
IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this includes ESP with a non-null transform to provide both authentication and confidentiality.
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.
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.
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]).
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 Considerations
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].
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].
8. Summary
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.
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.
9. Normative References
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., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service
Templates and Service: Schemes", RFC 2609, June 1999.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999.
Bakke & Hufferd Standards Track [Page 19] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 19] RFC 4018 iSCSI and SLPv2 April 2005
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[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., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3722] Bakke, M., "String Profile for Internet Small Computer
Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[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., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
10. Informative References
10. Informative References
[RFC2614] Kempf, J. and E. Guttman, "An API for Service Location",
RFC 2614, June 1999.
[RFC2614] Kempf, J. and E. Guttman, "An API for Service Location", RFC 2614, June 1999.
[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
[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., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[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. and J. Souza, "Internet Storage Name Service", Work in Progress, February 2004.
[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. and C. Sapuntzakis, "A Standard for Bootstrapping Clients using the iSCSI Protocol", Work in Progress, March 2004.
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
SLP", RFC 3105, October 2001.
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.
Bakke & Hufferd Standards Track [Page 20] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 20] RFC 4018 iSCSI and SLPv2 April 2005
11. Acknowledgements
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.
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.
Bakke & Hufferd Standards Track [Page 21] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 21] RFC 4018 iSCSI and SLPv2 April 2005
Authors' Addresses
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 USA 55425
EMail: mbakke@cisco.com
EMail: mbakke@cisco.com
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
EMail: kaladhar@us.ibm.com
EMail: kaladhar@us.ibm.com
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: jlhufferd@comcast.net
Phone: +1 408 997-6136 EMail: jlhufferd@comcast.net
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: marjorie_krueger@hp.com
Phone: +1 916 785-2656 EMail: marjorie_krueger@hp.com
Todd Sperry Adaptec, Inc. 691 South Milpitas Boulevard Milpitas, Ca. 95035
Todd Sperry Adaptec, Inc. 691 South Milpitas Boulevard Milpitas, Ca. 95035
Phone: +1 408 957-4980 EMail: todd_sperry@adaptec.com
Phone: +1 408 957-4980 EMail: todd_sperry@adaptec.com
Bakke & Hufferd Standards Track [Page 22] RFC 4018 iSCSI and SLPv2 April 2005
Bakke & Hufferd Standards Track [Page 22] RFC 4018 iSCSI and SLPv2 April 2005
Full Copyright Statement
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Bakke & Hufferd Standards Track [Page 23]
Bakke & Hufferd Standards Track [Page 23]
一覧
スポンサーリンク
