[要約] 要約：RFC 3105は、Service Location Protocol（SLP）を使用してRSIPサーバーを見つけるための手法を提案しています。 目的：このRFCの目的は、ネットワーク上のRSIPサーバーを効率的に見つけるための標準化された方法を提供することです。
Network Working Group J. Kempf
Request for Comments: 3105 NTT DoCoMo USA Labs
Category: Experimental G. Montenegro
Sun Microsystems
October 2001
Finding an RSIP Server with SLP
SLPでRSIPサーバーを見つける
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
IESG Note
IESGノート
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of the RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESGは、RSIPテクノロジーを説明するドキュメントのセットが、完全な実装のために重要なホストとゲートウェイの変更を暗示していることを指摘しています。さらに、ポート番号が浮かんでいると、一部のアプリケーションに問題が発生する可能性があり、RSIP対応のホストが既存のアプリケーションと透過的に相互運用することを防ぐことができます（例えば、IPSEC）。最後に、RSIPの使用に関連する重要な運用上の複雑さがある場合があります。これらおよびその他の合併症のいくつかは、RFC 3102のセクション6およびRFC 3104の付録に概説されています。したがって、RSIPを使用するコストと利点は、住所不足を解放する他の手段と慎重に計量する必要があります。
Abstract
概要
This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. Service Location Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP (Realm Specific IP) clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The service type template is the basis for an Internet Assigned Numbers Authority (IANA) standard definition of the advertisements offered by RSIP servers, an important step toward interoperability.
このドキュメントには、RSIPサーバーがサービスのために作成した広告を説明するSLPサービスタイプテンプレートが含まれています。Service Location Protocol（SLP）は、クライアントが特定のサービスを提供するサーバーを見つけるように特別に設計されたIETF標準トラックプロトコルです。RSIP（Realm固有のIP）クライアントは、RSIPサーバーを発見するためのメカニズムが必要なため、SLPはソリューションに自然に一致します。サービスタイプのテンプレートは、インターネット割り当てされた数字局（IANA）の基礎となります。RSIPサーバーが提供する広告の標準定義は、相互運用性に向けた重要なステップです。
Table of Contents
目次
1. Introduction ............................................... 2
2. Notation Conventions ....................................... 2
3. Terminology ................................................ 2
4. Using SLP for RSIP Service Discovery ....................... 3
5. Using Scopes for Server Provisioning ....................... 4
6. Load Balancing ............................................. 6
7. The RSIP Service Type Template ............................. 7
8. Security Considerations .................................... 9
9. Summary .................................................... 9
References ..................................................... 9
Authors' Addresses ............................................. 10
Full Copyright Statement ....................................... 11
Realm Specific IP (RSIP) [7] enables an RSIP client in one realm to borrow addresses and other resources from another realm. It does so by engaging in an RSIP protocol [1] exchange with an RSIP server. The RSIP protocol requires the RSIP server to have a permanent presence on both realms.
レルム固有のIP（RSIP）[7]は、ある領域のRSIPクライアントを別の領域からアドレスやその他のリソースを借りることができます。RSIPプロトコル[1]をRSIPサーバーと交換することにより、これを行います。RSIPプロトコルでは、RSIPサーバーが両方の領域に永続的な存在感を与える必要があります。
There are a variety of traditional ways an RSIP client could go about locating the appropriate RSIP server. However, Service Location Protocol (SLP) [2][11] is an IETF standards track protocol specifically designed to facilitate location of services and their servers by clients. SLP provides a number of features that simplify locating RSIP servers. In this document, we describe how RSIP clients can use SLP to discover RSIP servers.
RSIPクライアントが適切なRSIPサーバーを見つけることができる伝統的な方法はさまざまです。ただし、Service Location Protocol（SLP）[2] [11]は、クライアントによるサービスとそのサーバーの位置を促進するために特別に設計されたIETF標準トラックプロトコルです。SLPは、RSIPサーバーの位置を簡素化する多くの機能を提供します。このドキュメントでは、RSIPクライアントがSLPを使用してRSIPサーバーを発見する方法について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[4]で説明されているように解釈される。
We reproduce here some SLP terminology from [2] for readers unfamiliar with SLP.
ここでは、SLPに不慣れな読者のために[2]のSLP用語を複製します。
User Agent (UA)
ユーザーエージェント（UA）
A process working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents.
一部のサービスとの連絡を確立するために、ユーザーに代わって取り組んでいるプロセス。UAは、サービスエージェントまたはディレクトリエージェントからサービス情報を取得します。
Service Agent (SA)
サービスエージェント（SA）
A process working on behalf of one or more services to advertise the services and their capabilities.
サービスとその機能を宣伝するための1つ以上のサービスに代わって作業するプロセス。
Directory Agent (DA)
ディレクトリエージェント（DA）
A process which collects service advertisements. There can only be one DA present per given host.
サービス広告を収集するプロセス。指定されたホストごとに存在するDAは1つしかありません。
Scope
範囲
A 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.
URL、属性、および生涯（広告が有効な時間を示す）。特定のサービスのサービスアクセス情報と機能の説明を提供します。
SLP provides the framework in which RSIP clients and servers make contact. Here is a description of how an RSIP server and client find each other using SLP:
SLPは、RSIPクライアントとサーバーが連絡するフレームワークを提供します。RSIPサーバーとクライアントがSLPを使用してお互いを見つける方法の説明を次に示します。
1. The RSIP server implements a SLP SA while the RSIP client implements an SLP UA.
1. RSIPサーバーはSLP SAを実装し、RSIPクライアントはSLP UAを実装します。
2. The RSIP SA constructs a service advertisement consisting of a service URL, attributes and a lifetime. The URL has service type "service:rsip", and attributes defined according to the template in Section 7.
2. RSIP SAは、サービスURL、属性、および生涯で構成されるサービス広告を構築します。URLにはサービスタイプ「サービス：RSIP」があり、セクション7のテンプレートに従って定義された属性があります。
3. If an SLP DA is found, the SA contacts the DA and registers the advertisement. If no DA is found, the SA maintains the advertisement itself, answering multicast UA queries directly.
3. SLP DAが見つかった場合、SAはDAに接触し、広告を登録します。DAが見つからない場合、SAは広告自体を維持し、マルチキャストUAクエリに直接回答します。
4. When the RSIP client requires contact information for an RSIP server, the UA either contacts the DA using unicast or the SA using multicast. The UA includes a query based on the attributes to indicate the characteristics of the server it requires.
4. RSIPクライアントがRSIPサーバーの連絡先情報を必要とする場合、UAはUnicastを使用してDAに連絡するか、マルチキャストを使用してSAに連絡します。UAには、必要なサーバーの特性を示す属性に基づくクエリが含まれています。
5. Once the UA has the host name or address of the RSIP server as well as the port number, it can begin negotiation using the RSIP protocol.
5. UAにRSIPサーバーのホスト名またはアドレスとポート番号があると、RSIPプロトコルを使用してネゴシエーションを開始できます。
This procedure is exactly the same for any client/server pair implementing SLP and is not specific to RSIP.
この手順は、SLPを実装するクライアント/サーバーペアでまったく同じであり、RSIPに固有のものではありません。
Many protocols use a variety of traditional methods for service discovery. These methods include static configuration, purpose-build protocols for discovery, special features in the protocol itself, DNS SRV RRs [5], or DHCP [6]. SLP provides a number of advantages over these traditional methods:
多くのプロトコルは、サービス発見にさまざまな従来の方法を使用しています。これらの方法には、静的構成、発見のための専用プロトコル、プロトコル自体の特別な機能、DNS SRV RRS [5]、またはDHCP [6]が含まれます。SLPは、これらの従来の方法よりも多くの利点を提供します。
1. Discovery of services using SLP is dynamic, whereas many of the traditional methods only allow static or weakly dynamic (i.e., difficult to update) discovery. Clients only discover services that are actually active with SLP. Furthermore, if subsequent to initial discovery a server goes down, the client can reissue an SLP query and obtain a new server. On the server side, no databases must be updated to provide dynamic discovery, the servers advertise themselves.
1. SLPを使用したサービスの発見は動的ですが、従来の方法の多くは静的または弱い動的（つまり、更新が困難）の発見のみを許可します。クライアントは、実際にSLPでアクティブなサービスのみを発見します。さらに、サーバーが最初に発見された後にダウンすると、クライアントはSLPクエリを再発行して新しいサーバーを取得できます。サーバー側では、動的な発見を提供するためにデータベースを更新する必要はありません。サーバーは自分で宣伝しています。
2. SLP requires no third party configuration. Only the server offering the service and the client seeking it are required to know the details for the particular service type.
2. SLPはサードパーティの構成を必要としません。サービスを提供するサーバーとそれを求めているクライアントのみが、特定のサービスタイプの詳細を知る必要があります。
3. SLP allows clients to specify the attributes describing the desired server. A client discovers servers that meet a set of specific requirements. This reduces the amount of network traffic involved in selecting a server when many possible choices are available.
3. SLPを使用すると、クライアントは目的のサーバーを説明する属性を指定できます。クライアントは、一連の特定の要件を満たすサーバーを発見します。これにより、多くの可能な選択肢が利用可能な場合、サーバーの選択に伴うネットワークトラフィックの量が減少します。
4. SLP contains a number of scaling mechanisms (DAs, scopes, multicast convergence algorithm), that facilitate deployment in large enterprise networks as well as in smaller networks.
4. SLPには、大規模なエンタープライズネットワークと小規模なネットワークでの展開を容易にする多くのスケーリングメカニズム（DAS、スコープ、マルチキャスト収束アルゴリズム）が含まれています。
One particular design feature of SLP that is useful for RSIP is scopes. Scopes in SLP are a mechanism for provisioning access to particular service advertisements. An administrator assigns UAs and SAs to particular scopes to assure that UAs only find SAs in those scopes. Scopes are not an access control mechanism for the service itself, however. UAs from outside the scope can still access services in a particular scope (unless the service itself provides for access control), they just won't be able to find the services using SLP.
RSIPに役立つSLPの特定の設計機能の1つは、スコープです。SLPのスコープは、特定のサービス広告へのアクセスをプロビジョニングするメカニズムです。管理者は、UASとSASを特定のスコープに割り当て、UASがこれらのスコープでSASのみを見つけることを保証します。ただし、スコープはサービス自体のアクセス制御メカニズムではありません。スコープ外からのUASは、特定のスコープでサービスにアクセスできます（サービス自体がアクセス制御を提供しない限り）、SLPを使用してサービスを見つけることができません。
Scopes are useful for RSIP service advertisement provisioning because they allow a system administrator to tie particular RSIP clients to specific RSIP servers. For example, consider the network architecture described in Section 4.2.1 of [7]. RSIP clients are recommended to find "the nearest" RSIP server, but exactly how that should be arranged is left unspecified. SLP provides a way for system administrators to precisely specify which realm an RSIP client resides in, by tying the realm to an SLP scope. The diagram from Section 14.1 is reproduced here, with SLP scopes included to illustrate how clients could be directed to the right RSIP servers.
スコープは、システム管理者が特定のRSIPクライアントを特定のRSIPサーバーに結び付けることができるため、RSIPサービス広告プロビジョニングに役立ちます。たとえば、[7]のセクション4.2.1で説明したネットワークアーキテクチャを検討してください。RSIPクライアントは、「最も近い」RSIPサーバーを見つけることをお勧めしますが、それをどのように配置するかは正確には不特定のままです。SLPは、システム管理者が、RSIPクライアントがどの領域に存在するかを正確に指定する方法を提供します。セクション14.1の図はここで再現されており、クライアントを適切なRSIPサーバーにどのように向けることができるかを示すためにSLPスコープが含まれています。
+-----------+
| |
| RSIP |
| server +---- 10.0.0.0/8
| B | SLP Scope: B
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ server | SLP Scope: A
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| server +---- 10.0.0.0/8
| C | SLP Scope: C
| |
+-----------+
Clients on the upper 10.0.0.0/8 network are configured to use SLP scope B, while clients on the lower 10.0.0.0/8 network are configured to use SLP scope C. RSIP servers B and C (as clients of server A) use SLP to locate RSIP server A, as do other RSIP clients on the 10.0.1.0/24 and 10.0.2.0/24 subnets. Within these two subnets, all clients have their scopes configured to be A.
アッパー10.0.0.0/8ネットワークのクライアントはSLPスコープBを使用するように構成され、下位10.0.0.0/8ネットワークのクライアントはSLPスコープC. RSIPサーバーBおよびC（サーバーAのクライアントとして）を使用するように構成されます。RSIPサーバーAを見つけるSLP 10.0.1.0/24および10.0.2.0/24サブネットの他のRSIPクライアントと同様に。これら2つのサブネット内で、すべてのクライアントがAに設定されたスコープを持っています。
Note that specifying a particular SLP scope for RSIP clients does not restrict the SLP scope for other services advertised by SLP. SLP UAs can be configured for multiple scopes, so the scope configured for printing may be different from the scope configured for RSIP service.
RSIPクライアントの特定のSLPスコープを指定しても、SLPが宣伝する他のサービスのSLPスコープは制限されないことに注意してください。SLP UAは複数のスコープ用に構成できます。そのため、印刷用に構成されたスコープは、RSIPサービス用に構成されたスコープとは異なる場合があります。
Since SLP scopes are configured through a DHCP option [8], along with the IP address, system administrators can easily switch a cluster of machines from one realm to another by simply changing the scope and IP address assignments on the DHCP server. For example, in the above architecture, suppose a system administrator wanted to remove RSIP server B so that clients on the upper 10.0.0.0/8 subnet were directly on subnet 10.0.1.0/24. These clients now communicate with RSIP server A. By simply changing the address assignments and scope configuration of these clients on the DHCP server, the realm can be effectively switched.
SLPスコープはDHCPオプション[8]を介して設定されているため、IPアドレスとともに、システム管理者は、DHCPサーバーのスコープとIPアドレスの割り当てを変更するだけで、あるマシンのクラスターをある領域から別の領域に簡単に切り替えることができます。たとえば、上記のアーキテクチャでは、システム管理者がRSIPサーバーBを削除して、上位10.0.0.0/8サブネットのクライアントがサブネット10.0.1.0/24に直接登場するようにしたとします。これらのクライアントは、RSIPサーバーAと通信します。DHCPサーバー上のこれらのクライアントのアドレス割り当てとスコープ構成を変更するだけで、レルムを効果的に切り替えることができます。
While SLP itself contains no specific provision for load balancing, load balancing can easily be implemented using SLP. The only requirement is that the service type template specify an attribute indicating server load. In the case of RSIP, the service type template in Section 7 contains such an attribute. The attribute indicates the number of RSIP client sessions currently being supported by the server.
SLP自体には負荷分散のための特定の規定は含まれていませんが、SLPを使用して負荷分散を簡単に実装できます。唯一の要件は、サービスタイプテンプレートがサーバーの負荷を示す属性を指定することです。RSIPの場合、セクション7のサービスタイプテンプレートにはそのような属性が含まれています。属性は、現在サーバーによってサポートされているRSIPクライアントセッションの数を示します。
In order to perform load balancing, the RSIP server must update its service advertisement periodically as new connections are accepted. An RSIP client seeking to find the server having the lightest load performs the following series of SLP operations.
ロードバランシングを実行するために、RSIPサーバーは、新しい接続が受け入れられるにつれて、サービス広告を定期的に更新する必要があります。最も軽い負荷を持っているサーバーを見つけようとするRSIPクライアントは、次のSLP操作のシリーズを実行します。
1. As in Section 4, the client issues an SLP service request and collects all the returned service URLs.
1. セクション4のように、クライアントはSLPサービス要求を発行し、返されたすべてのサービスURLを収集します。
2. For each service URL, the client performs an SLP attribute request for the attribute LOAD. The integer load figures are returned.
2. 各サービスURLについて、クライアントは属性負荷に対してSLP属性要求を実行します。整数負荷数値が返されます。
3. The client sorts through the returned load figures and selects the URL having the least number of connections. The client establishes its RSIP session with that server.
3. クライアントは、返された負荷数値を並べ替え、接続の数が少ないURLを選択します。クライアントは、そのサーバーとのRSIPセッションを確立します。
Because of network delays, this procedure does not guarantee that a client will always obtain a connection with the lightest loaded server, but it does provide a high probability that the selected server is more lightly loaded.
ネットワークの遅延のため、この手順は、クライアントが常に最も軽いロードサーバーとの接続を取得することを保証するものではありませんが、選択したサーバーがより軽くロードされる可能性が高いことを提供します。
A similar procedure is used in [9] to load balance access to TN3270E telnet servers.
[9]で同様の手順を使用して、TN3270E Telnetサーバーへのバランスアクセスをロードします。
Name of submitters: James Kempf <james@docomolabs-usa.com>
Gabriel Montenegro <gab@sun.com>
Language of service template: en
サービステンプレートの言語：en
Security Considerations: RSIP clients can use Service Location Protocol to find RSIP servers having particular security characteristics. If secure access to such information is required, SLP security should be used.
セキュリティ上の考慮事項：RSIPクライアントは、サービスロケーションプロトコルを使用して、特定のセキュリティ特性を持つRSIPサーバーを見つけることができます。そのような情報への安全なアクセスが必要な場合は、SLPセキュリティを使用する必要があります。
Template text:
----------------------template begins here -------------------------
template-type = rsip
template-version = 0.0
テンプレートversion = 0.0
template-description= The service:rsip type provides advertisements for clients seeing realm-specific IP (RSIP) servers. RSIP servers use the Realm Specific IP protocol to manage addresses and other resources from one realm on behalf of a client in another realm.
Template-description =サービス：RSIPタイプは、Realm固有のIP（RSIP）サーバーを見るクライアントに広告を提供します。RSIPサーバーは、レルム固有のIPプロトコルを使用して、別の領域のクライアントに代わって1つの領域からアドレスやその他のリソースを管理します。
template-url-syntax=
;No additional URL path information required. An example service
;URL for an RSIP server is: service:rsip://gateway.mydomain:4455
ipsec-support = BOOLEAN O #True if the server supports IPSEC as per [10]
ipsec-support = boolean o #trueサーバーがipsecをサポートしている場合[10]
ike-support = BOOLEAN O #True if the server supports IKE as per [10]
ike-support = boolean o #trueサーバーがikeをサポートしている場合[10]
tunnel-type = STRING L M O IP-IP #The tunneling methods supported by the RSIP server. Clients #should include this attribute in a query so that they obtain a #server offering a tunneling method for which they have #support. Default is IP-IP. The values are currently #restricted to IP-IP, L2TP, GRE and NONE. A server can support #multiple tunnel types. IP-IP,L2TP,GRE,NONE
Tunnel-Type = String L M O IP-IP＃RSIPサーバーでサポートされているトンネルメソッド。クライアント＃は、この属性をクエリに含めて、#Supportがあるトンネリング方法を提供する#Serverを取得するようにする必要があります。デフォルトはIP-IPです。値は現在、IP-IP、L2TP、GRE、およびなしに#RSTIRESTENSTERSTENTです。サーバーは#Multipleトンネルタイプをサポートできます。IP-IP、L2TP、GRE、なし
transport = STRING L M O TCP #Transport used by the RSIP protocol itself. TCP,UDP
Transport = String L M O TCP #Transport RSIPプロトコル自体が使用します。TCP、UDP
load = INTEGER O
#If the server supports load balancing, this attribute should be
#set to an integer from 0 to 100. 0 is the lowest indication of
#load and 100 the highest. Clients can query for this attribute
#and obtain load information, from which they can make an
#intelligent decision about which server to use.
----------------------template ends here ---------------------------
8. Security Considerations
Service type templates provide information that is used to interpret information obtained by clients through SLP. If the RSIP template is modified or if a false template is distributed, RSIP servers may not correctly register themselves, or RSIP clients may not be able to interpret service information.
サービスタイプテンプレートは、SLPを介してクライアントが取得した情報を解釈するために使用される情報を提供します。RSIPテンプレートが変更されている場合、または偽のテンプレートが分散されている場合、RSIPサーバーが正しく登録されない場合、またはRSIPクライアントがサービス情報を解釈できない場合があります。
SLP provides an authentication mechanism for UAs to assure that service advertisements only come from trusted SAs [2]. If trust is an issue, particularly with respect to the information sought by the client about IPSEC and IKE support, then SLP authentication should be enabled in the network.
SLPは、サービス広告が信頼できるSASからのみ提供されることを保証するために、UASに認証メカニズムを提供します[2]。特にIPSECおよびIKEサポートについてクライアントが求めている情報に関して、信頼が問題である場合、ネットワークでSLP認証を有効にする必要があります。
This document describes how SLP can be used by RSIP clients to find RSIP servers. A service type template for an RSIP SLP service type is presented. In addition, a few techniques for provisioning access to service advertisements for particular gateway servers, and for load balancing using SLP were provided. The result should allow RSIP service provisioning that is considerably more dynamic and robust than when traditional service discovery mechanisms are used.
このドキュメントでは、RSIPクライアントがSLPを使用してRSIPサーバーを見つける方法について説明します。RSIP SLPサービスタイプのサービスタイプテンプレートが表示されます。さらに、特定のゲートウェイサーバーのサービス広告へのアクセスをプロビジョニングするためのいくつかの手法、およびSLPを使用した負荷分散のための手法が提供されました。その結果、従来のサービス発見メカニズムが使用される場合よりもかなり動的で堅牢なRSIPサービスプロビジョニングが可能になるはずです。
References
参考文献
[1] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, April 2001.
[1] Borella、M.、Grabelsky、D.、Lo、J。およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、2001年4月。
[2] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
[2] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年7月。
[3] Guttman, E, Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
[3] Guttman、E、Perkins、C。およびJ. Kempf、「サービステンプレートとサービス：スキーム」、RFC 2609、1999年7月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[5] Gulbrandsen、A。およびP. Vixie、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2052、1996年10月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[6] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[7] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[7] Borella、M.、Lo、J.、Grabelsky、D。およびG. Montenegro、「Realm固有のIP：フレームワーク」、RFC 3102、2001年10月。
[8] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, July 1999.
[8] Perkins、C。and E. Guttman、「サービスロケーションプロトコルのDHCPオプション」、RFC 2610、1999年7月。
[9] Naugle, J., Kasthurirangan, K. and G. Ledford, "TN3270E Service Location and Session Balancing", RFC 3049, January 2001.
[9] Naugle、J.、Kasthurirangan、K。およびG. Ledford、「TN3270Eサービスの場所とセッションのバランス」、RFC 3049、2001年1月。
[10] Montenegro, G. and M. Borella, "RSIP Support for End-to-end IPSEC", RFC 3104, October 2001.
[10] モンテネグロ、G。およびM.ボレラ、「エンドツーエンドIPSECのRSIPサポート」、RFC 3104、2001年10月。
[11] E. Guttman, "Service Location Protocol: Automatic Discovery of IP Network Services," IEEE Internet Computing, July/August 1999. Available at: http://computer.org/internet/ic1999/w4toc.htm
[11] E. Guttman、「サービスロケーションプロトコル：IPネットワークサービスの自動発見」、IEEEインターネットコンピューティング、1999年7月/8月。http：//computer.org/internet/ic1999/w4toc.htmで入手可能
Authors' Addresses
著者のアドレス
Questions about this document may be directed to:
このドキュメントに関する質問は、次のように向けられます。
James Kempf NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110
James Kempf NTT Docomo USA Labs 181 Metro Drive、Suite 300 San Jose、CA 95110
Phone: 408-451-4711 Email: james@docomolabs-usa.com
電話：408-451-4711メール：james@docomolabs-usa.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサンマイクロシステムズラボラトリーズ、ヨーロッパ29、ケミンデュヴィューチェーン38240メイランフランス
Phone: +33 476 18 80 45
EMail: gab@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。