Network Working Group E. Guttman
Request for Comments: 3111 Sun Microsystems
Category: Standards Track May 2001
Service Location Protocol Modifications for IPv6
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor.
このドキュメントでは、サービスロケーションプロトコルバージョン2の（SLPv2の）IPv6ネットワーク上で使用を定義します。このプロトコルはUDPとTCPに依存しているため、IPv6を介し、その使用をサポートするための変更は軽微なものです。
This document does not describe how to use SLPv1 over IPv6 networks. There is at the time of this publication no implementation or deployment of SLPv1 over IPv6. It is RECOMMENDED that SLPv2 be used in general, and specifically on networks which support IPv6.
この文書は、IPv6ネットワーク上でSLPv1を使用する方法については説明しません。 IPv6を介しSLPv1の一切の実装や展開は、この発表時点ではありません。 SLPv2のが一般的で、具体的にIPv6をサポートするネットワーク上で使用することを推奨されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Eliminating support for broadcast SLP requests . . . . . 3
3. Address Specification for IPv6 Addresses in URLs . . . . 3
4. SLP multicast behavior over IPv6 . . . . . . . . . . . . 4
4.1. SLPv2 Multicast Group-IDs for IPv6 . . . . . . . . . . 4
4.2. SLPv2 Scoping Rules for IPv6 . . . . . . . . . . . . . 5
4.2.1 Joining SLPv2 Multicast Groups . . . . . . . . . . . . 5
4.2.2 Sending SLPv2 Multicast Messages . . . . . . . . . . . 6
4.2.3 Rules for Message Processing . . . . . . . . . . . . . 6
4.2.4 SLPv2 Agents with multiple interfaces . . . . . . . . 7
4.2.4.1 General Rules . . . . . . . . . . . . . . . . . . . . 7
4.2.4.2 Multihomed UA . . . . . . . . . . . . . . . . . . . . 8
4.2.4.3 Multihomed SA . . . . . . . . . . . . . . . . . . . . 8
4.2.4.4 Multihomed DA . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . 13
The Service Location Protocol (SLP) provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using IP based networks no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant of or less able to fulfill the demands of network administration.
サービスロケーションプロトコル（SLP）ネットワークサービスの発見と選択のためのスケーラブルなフレームワークを提供します。このプロトコルを使用して、IPベースのネットワークを使用するコンピュータは、もはやネットワークベースのアプリケーションのためのネットワークサービスのそんなに静的な構成を必要としません。これは、コンピュータがよりポータブルになると特に重要であり、利用者の少ないトレラントやネットワーク管理の要求を満たすことが少ないこと。
The following are changes required to have the Service Location Protocol work over IPv6. These changes include:
以下では、IPv6を超えるサービスロケーションプロトコルの仕事を持っているために必要な変更です。これらの変更は、次のとおりです。
- Eliminating support for broadcast SLP requests
- ブロードキャストSLP要求のためのサポートを排除
- Address Specification for IPv6 Addresses in URLs
- URL内のIPv6アドレスのアドレスの指定
- Use of IPv6 multicast addresses and IPv6 address scopes
- IPv6マルチキャストアドレスとIPv6アドレスのスコープの使用
- Restricted Propagation of Service Advertisements
- サービス広告の制限伝播
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[4]で説明されるように解釈されます。
Service Location over IPv4 allows broadcasts to send Service Location request messages. IPv6 makes use of link-local multicast in place of broadcast. Broadcast-only configuration for SLP is not supported under IPv6. If a User Agent wishes to make a request to discover Directory Agents or make a request of multiple Service Agents, the User Agent must multicast the request to the appropriate multicast address.
IPv4のオーバーサービスの場所は、ブロードキャストがサービスロケーション要求メッセージを送信することができます。 IPv6は、放送の代わりに、リンクローカルマルチキャストを利用します。 SLPのためのブロードキャストのみの構成では、IPv6ではサポートされていません。ユーザーエージェントはディレクトリエージェントを発見したり、複数のサービスエージェントの要求を行うための要求を行いたい場合、ユーザエージェントは、適切なマルチキャストアドレスに要求をマルチキャストする必要があります。
This change modifies the requirements described in Section 6.1 (Use of Ports, UDP and Multicast) of the Service Location Protocol [2].
この変更は、[2]サービスロケーションプロトコルのセクション6.1（ポート、UDPおよびマルチキャストの使用）で説明した要件を変更します。
Whenever possible the DNS [5] name of the service should be used rather than the numerical representation described in this section.
可能な限りサービスのDNS [5]名は、このセクションに記載される数値表現ではなく、使用されるべきです。
Service Location allows the use of the protocol without the benefit of DNS. This is relevant when a group of systems is connected to build a network without any previous configuration of servers to support this network. When Service Location is used in this manner, numerical addresses must be used to identify the location of services.
サービスの場所は、DNSの恩恵なしでプロトコルの使用を可能にします。システムのグループは、このネットワークをサポートするためのサーバーのいずれかの以前の構成せずにネットワークを構築するために接続されたとき、これは関連しています。サービスロケーションは、このように使用される場合、数値アドレスは、サービスの位置を特定するために使用されなければなりません。
The format of a "service:" URL is defined in [6]. This URL is an "absolute URI" as defined by [7].
URLは、[6]で定義されている：「サービス」の形式。 [7]で定義されるように、このURLは、「絶対URI」です。
A numerical IPv6 address, such as may be used in a "service:" URL, is specified as in [8]. The textual representation defined for literal IPv6 addresses in [9]:
「サービス：」で使用することができるような数値IPv6アドレス、URLは、[8]のように指定されています。 [9]にリテラルのIPv6アドレス用に定義されたテキスト表現
ipv6-addr = "[" num-addr "]" num-addr = ; Text represented IPv6 address syntax is as ; specified in RFC 2373 [8], Section 2.2,
IPv6-ADDR = "[" NUM-ADDR "]" NUM-ADDR =。テキスト表現IPv6アドレスの構文はようです。 RFC 2373 [8]、セクション2.2で指定され、
Examples:
例：
This is a site-local scoped address, as could be used in a SLP DAAdvert message.
SLP DAAdvertメッセージで使用することができ、これは、サイトローカルスコープのアドレスです。
service:directory-agent://[FEC0::323:A3F9:25ff:fe91:109D]
サービス：ディレクトリエージェント：// [FEC0 :: 323：A3F9：25ff：fe91：109D]
This is a link-local scoped address, as could be used by a SA to advertise its service on a IPv6 network with no routers or DNS service.
なしルータやDNSサービスでIPv6ネットワーク上でそのサービスを宣伝するためにSAが使用することができ、これは、リンクローカルスコープのアドレスです。
service:printer:ipp://[FE80::a15A:93ff:fe5D:B098]:8080/path
サービス：プリンタ：IPP：// [FE80 :: a15A：93ff：fe5D：B098]：8080 /パス
Section 4.1 describes how different multicast addresses are used for transmitting and receiving SLPv2 messages over IPv6. Section 4.2 defines rules for the use of these addresses and covers scoped address issues in general.
4.1節では、マルチキャストアドレスはIPv6を介しSLPv2のメッセージを送受信するために使用されている方法を異なる説明しています。 4.2節では、これらのアドレスを使用するためのルールを定義し、一般的にはスコープのアドレスの問題をカバーしています。
SLPv2 for IPv4 specifies only one multicast address, relative to an Administratively Scoped Address range [11]. The reason only one address was used is that there are only 256 relative assignments available for this purpose. IPv6, on the other hand, has scoped addresses and enough space for a range of assignments.
IPv4のSLPv2のは管理用スコープアドレス範囲[11]に対してのみ1つのマルチキャストアドレスを指定します。 1つのアドレスのみを使用した理由は、この目的のために利用できる唯一の256相対的な割り当てがあるということです。 IPv6は、他の一方で、割り当ての範囲のアドレスと十分なスペースをスコープしています。
SLPv2 for IPv6 uses the following multicast group-id assignments:
IPv6のSLPv2のは、次のマルチキャストグループIDの割り当てを使用しています。
FF0X:0:0:0:0:0:0:116 SVRLOC FF0X:0:0:0:0:0:0:123 SVRLOC-DA FF0X:0:0:0:0:0:1:1000 Service Location -FF0X:0:0:0:0:0:1:13FF
FF0X：0：0：0：0：0：0：116 SVRLOC FF0X：0：0：0：0：0：0：123 SVRLOC-DA FF0X：0：0：0：0：0：1：1000サービス場所-FF0X：0：0：0：0：0：1：13FF
These group-ids are combined with the scope prefix of the scope to which the multicast message is to be sent.
これらのグループIDは、マルチキャストメッセージが送信されるべきスコープのスコーププレフィックスと組み合わされます。
The SVRLOC group-id is used for the following messages: Service Type Request and Attribute Request messages.
サービスタイプ要求と属性要求メッセージ：SVRLOCグループ-idは、次のメッセージに使用されます。
The SVRLOC-DA group-id is used for multicast Service Requests for the "service:directory-agent" service type. Also, DAs send unsolicited DA Advert messages to the SVRLOC-DA multicast group-id.
サービスタイプ：SVRLOC-DAグループ-idは、「ディレクトリエージェントサービス」のためのマルチキャストサービス要求のために使用されています。また、DAがSVRLOC-DAマルチキャストグループIDに迷惑DA広告メッセージを送信します。
All other multicast Service Request messages are sent to the appropriate Service Location multicast group-id. SAs join the groups which correspond to the Service Types of the services they advertise. The group-id is determined using the algorithm provided in SLPv1 [3]. The Service Type string used in the SrvRqst is hashed to a value from 0-1023. This determines the offset into the FF0X::1:1000-13FF range.
他のすべてのマルチキャストサービス・リクエスト・メッセージは、適切なサービス場所マルチキャストグループIDに送信されます。 SAは、彼らが宣伝サービスのサービスタイプに対応してグループに参加します。グループIDはSLPv1の[3]に設けられたアルゴリズムを用いて決定されます。 SrvRqstで使用されるサービスタイプ文字列は、0から1023の値にハッシュされます。 1000-13FF範囲：これはFF0X :: 1へのオフセットを決定します。
The hash algorithm is defined as follows:
次のようにハッシュアルゴリズムが定義されています。
An unsigned 32 bit value V is initialized to 0. Each byte of the Service Type UTF-8 [12] encoded string value is considered consecutively. The current value V is multiplied by 33, then the value of the current string byte is added. Each byte in the Service Type string is processed in this manner. The result is contained in the low order 10 bits of V. For example, the following code implements this algorithm:
符号なし32ビット値サービスタイプUTF-8のVを0に初期化される各バイト[12]エンコードされた文字列の値が連続であると考えられます。電流値Vが33で乗算され、その後、現在の文字列のバイトの値が加算されます。サービスタイプ文字列内の各バイトは、この方法で処理されます。これは、例えば下位Vの10ビットに含まれ、次のコードは、このアルゴリズムを実装します。
unsigned long slp_hash(const char *pc, unsigned int len) {
unsigned long h = 0;
while (len-- != 0) {
h *= 33;
h += *pc++;
}
return (0x3FF & h); /* round to a range of 0-1023 */
}
IPv6 provides different scopes for interface address configuration and multicast addresses. A SLPv2 Agent might discover services that it cannot use or not discover services which it could use unless rules are given to prevent this.
IPv6は、インターフェイスアドレスの設定およびマルチキャストアドレスに対して異なるスコープを提供します。 SLPv2のエージェントは、それが使用できないサービスを発見するか、ルールはこれを防ぐために与えられている場合を除き、それは使用することができ、サービスを発見しない場合があります。
Say a SLPv2 UA, for example, could request a service using site-local scope multicast and obtain a service: URL containing a link-local literal address. If the service referred to were not on the same link as the SLPv2 UA, the service could not be reached.
SLPv2のUAは、例えば、サイトローカルスコープのマルチキャストを使ってサービスを要求し、サービスを得ることができたと言う：URLリンクローカルリテラルアドレスを含みます。サービスはSLPv2のUAと同じリンク上でなかったために呼ばれた場合、サービスが到達することができませんでした。
A SLPv2 Agent MAY send a multicast message using any scope which it is allowed to (see section 4.2.2). A SA and a DA MUST join all groups to which a SLPv2 Agent may send a message. This ensures that the SA or DA will be able to receive all multicast messages.
SLPv2のエージェントは、（セクション4.2.2を参照）が許可されている任意のスコープを使用してマルチキャストメッセージを送信することができます。 SAとDAはSLPv2のエージェントがメッセージを送ることができているすべてのグループに参加する必要があります。これは、SAやDAは、すべてのマルチキャストメッセージを受信できるようになります。
Specifically, a SLPv2 Agent MUST NOT join a multicast group which has greater scope for an interface than it is configured with for use with unicast. For example, an interface which is only configured with a link-local address joins groups in scopes with FF01 and FF02. If the interface is configured with a site-local or global address, the scope of all multicast groups joined can be no greater than scope FF05. In this case, SLPv2 SAs and DAs MUST join multicast groups in all the following scopes: FF01 - FF05.
具体的には、SLPv2のエージェントは、それがユニキャストで使用するためで構成されているよりもインターフェースのためのより大きな範囲を有するマルチキャストグループに参加してはいけません。例えば、唯一のリンクローカルアドレスが設定されているインタフェースは、FF01及びFF02とスコープ内のグループに参加します。インタフェースはサイトローカルまたはグローバルアドレスが設定されている場合、すべてのマルチキャストグループの範囲は、範囲FF05よりも大きくなることはできません参加しました。 - FF05 FF01：この場合、SLPv2ののSAおよびDASは、以下のすべてのスコープでのマルチキャストグループに参加する必要があります。
A DA MUST join the SVRLOC-DA group to receive SrvRqst messages requesting DAAdverts.
DAはDAAdvertsを要求SrvRqstメッセージを受信するSVRLOC-DAグループに参加する必要があります。
A SA MUST join the SVRLOC-DA group to receive DAAdvert messages.
SAはDAAdvertメッセージを受信するSVRLOC-DAグループに参加する必要があります。
A SA MUST join the groups from the Service Location range of group-ids to receive SrvRqst messages. The SA only joins those groups corresponding to services it advertises. For example, a service agent which responds to requests for "service:service-agent" (used for SA discovery), would join groups with the group-id derived from the hash function defined in section 4.1:
SAはSrvRqstメッセージを受信するには、グループIDのサービスの場所の範囲からグループに参加する必要があります。 SAは、それがアドバタイズサービスに対応し、それらのグループに参加します。例えば、「サービス：サービスエージェント」の要求に応答するサービス・エージェント（SA発見のために使用される）は、セクション4.1で定義されたハッシュ関数に由来するグループIDとグループに参加することになります。
group-id to join = slp_hash("service:service-agent") + base address = 0x01d8 + FF0X:0:0:0:0:0:1:1000 = FF0X:0:0:0:0:0:1:11d8
+ベースアドレス= 0x01d8 + FF0X 0：0：0：0：0：0：1：1000 = FF0X：0：0：0：0：= slp_hash（ "サービスエージェントサービス"）を参加するグループID 1：11d8
The SA MAY join the SVRLOC group in order to receive SrvTypeRqst and AttrRqst messages; these features are OPTIONAL for the SA to implement.
SAはSrvTypeRqstとAttrRqstメッセージを受信するために、SVRLOCグループに参加することができます。これらの機能は、SAを実装するためのオプションです。
A UA MAY join the SVRLOC-DA group at any or all of these scopes in order to receive DAAdvert messages.
UAはDAAdvertメッセージを受信するために、これらのスコープのいずれか、またはすべてでSVRLOC-DAグループに参加することができます。
The maximum scope for a SLPv2 multicast message is site-local (FF05).
SLPv2のマルチキャストメッセージの最大範囲は、サイトローカル（FF05）です。
Multicast SLPv2 messages are sent using a particular scope. An SLPv2 agent MUST issue this request using a source address with a scope no less than the scope of the multicast group.
マルチキャストSLPv2のメッセージは、特定のスコープを使用して送信されます。 SLPv2のエージェントは、マルチキャストグループの範囲を下回らない範囲での送信元アドレスを使用して、このリクエストを発行しなければなりません。
This prevents, for example, a site-local multicast message being sent from a link-local source address.
これは、例えば、リンクローカル送信元アドレスから送信されるサイトローカルマルチキャストメッセージを防止します。
A SLPv2 UA with an interface configured with at least one global address could multicast a SrvRqst to any scope up to and including site-local, for instance.
少なくとも一つのグローバル・アドレスで構成されたインタフェースとSLPv2のUAは、例えば、最大およびサイトローカル含む任意のスコープにSrvRqstをマルチキャストすることができました。
SLPv2 SAs and DAs MUST determine which scope a service: URL address is in. This may be possible by examining the URL if it contains a numerical IPv6 address. If the URL contains a host name, the SA or DA MUST resolve that name to a set of addresses.
それは、数値のIPv6アドレスが含まれている場合、これはURLを調べることによって可能かもしれないURLアドレスがである：。SLPv2のSASおよびDAがどの範囲のサービスを決定しなければなりません。 URLは、ホスト名が含まれている場合は、SAやDAは、アドレスのセットにその名前を解決する必要があります。
A SLPv2 SA or DA MUST NOT respond to a SrvRqst with a service: URL for a service with an address scope less than the request's source address scope. The rules are given in Figure 1, below.
SLPv2のSAやDAはサービスとSrvRqstに応じてはいけません：アドレス範囲を持つサービスのURLより少なく、リクエストの送信元アドレスのスコープより。ルールは、以下、図1に示されています。
Request Source Address Scope
+------------+------------+---------+
| Link-Local | Site-Local | Global |
+-------------+------------+------------+---------+
Service | Link-Local | Respond | Drop | Drop |
Address +-------------+------------+------------+---------+
Scope | Site-Local | Respond | Respond | Drop |
+-------------+------------+------------+---------+
| Global | Respond | Respond | Respond |
+-------------+------------+------------+---------+
Figure 1: Out-of-Scope Rules
図1：範囲外のルール
This prevents UAs from being able discover service: URLs for services which cannot be accessed.
アクセスすることができないサービスのURL：これは、サービスを発見することができることから、UAのを防ぐことができます。
A scope zone, or a simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routers within a particular site, and the interfaces attached to those links, comprise a single zone of site-local scope. To understand the distinction between scopes and zones, observe that the topological regions within two different sites are considered to be two DIFFERENT zones, but of the SAME scope.
スコープゾーン、または単にゾーンは、所与の範囲のトポロジの接続領域です。例えば、特定のサイト内のルータ、およびそれらのリンクに取り付けられたインターフェースで接続されたリンクのセットは、サイトローカルスコープの単一のゾーンを含みます。スコープとゾーンの違いを理解するには、2つの異なるサイト内のトポロジカルな領域はなく、同じスコープの、二つの異なるゾーンであると考えられていることを確認します。
A host which has multiple interfaces attached to different links is by definition is attached to two link-local zones. A host may also be attached to multiple zones of other scopes.
異なるリンクに取り付けられた複数のインタフェースを持つホストは、定義により、2つのリンクローカルゾーンに取り付けられています。ホストは、他のスコープの複数のゾーンに取り付けられてもよいです。
A SLPv2 Agent MUST NOT propagate service advertisements from one zone to another. Another way of saying this is a SLPv2 SA or DA MUST NOT respond to a request from one zone with service information associated with a service in a different zone.
SLPv2のエージェントは、別のゾーンからサービス通知を伝播してはなりません。これを別の言い方ではSLPv2のSAやDAは、別のゾーンでのサービスに関連するサービスの情報を一つのゾーンからの要求に応じてはいけませんです。
The specific implication of these rules is discussed in the sections which follow.
これらのルールの具体的な意味は、以下の節で議論されています。
Service Locations (in SrvReg, SrvRply, AttrRst, SAAdvert or DAAdvert messages) whose locations are literal addresses MUST only be sent to SLP agents located on the same zone.
場所であるリテラルアドレスのみ同一のゾーンに配置さSLPエージェントに送信されなければならない（のSrvReg、SrvRply、AttrRst、SAAdvert又はDAAdvertメッセージで）サービスの場所。
For example, a service: URL containing a link-local address on link A may be sent in a SLPv2 message on link A, to a link-local destination address only.
例えば、サービス：リンクAのリンクローカルアドレスを含むURLは、リンクローカル宛先アドレスに、リンクA上SLPv2のメッセージで送信されてもよいです。
Each interface of a multihomed device is potentially on a separate link. It is often difficult to determine whether two interfaces are connected to the same link. For that reason a prudent implementation strategy is to not issue SLP messages containing link-local service locations except on the interface where the service is known to reside.
マルチホームデバイスの各インターフェースは、別々のリンクを潜在的にあります。 2つのインタフェースが同じリンクに接続されているかどうかを決定することはしばしば困難です。そのため、慎重な実装戦略は、サービスが存在することが知られているインターフェイスを除いて、リンクローカルサービス拠点を含むSLPメッセージを発行しないことです。
+----+ +----+ +----+
| SA |--------| UA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
(Zone 1) (Zone 2)
（ゾーン1）（ゾーン2）
Figure 2: Multihomed UA
図2：マルチホームUA
In Figure 2 the UA is multihomed. The UA can issue a service request in Zone 1 and discover services on the SA or in Zone 2 and discover services advertised by the DA. For example, if the request is issued from a link-local source address, the SA will only reply with a service available on link 1, the DA only with a service available on link 2.
図2にUAがマルチホームです。 UAは、ゾーン1内のサービス要求を発行し、SA上またはゾーン2でサービスを発見し、DAによって広告サービスを発見することができます。要求は、リンクローカル送信元アドレスから発行されている場合、SAはリンクのみ2で利用可能なサービスとのリンク1で利用可能なサービス、DAで返信します。
The UA MUST use active discovery to detect DAs before issuing multicast requests, as per SLPv2 [2]. The UA MUST issue requests using increasing multicast scopes starting at FF01 and increasing to a maximum scope of FF05, to solicit DAAdvertisements. Note the restrictions in Section 4.2.2.
UAはSLPv2の通り、マルチキャスト要求を発行する前に、DAを検出する能動的検出を使用しなければなりません[2]。 UAはDAAdvertisementsを勧誘するために、FF01から始まり、FF05の最大範囲に増加マルチキャストスコープを増やす使用して要求を発行しなければなりません。セクション4.2.2での制限に注意してください。
If the UA is unable to discover any DAs using multicast discovery, it may issue site-local scope (FF05) or less multicast requests. (Note that the source address of the request must be of at least the scope of the multicast, as described in section 4.2.2.)
UAがマルチキャスト探索を使用して、任意のDAを発見できない場合は、サイトローカルスコープ（FF05）以下マルチキャスト要求を発行することができます。 （セクション4.2.2で説明したように、要求の送信元アドレスは、マルチキャストの少なくともスコープのものでなければならないことに注意してください。）
If the UA wishes to discover all services, it must issue requests into both Zone 1 and 2.
UAは、すべてのサービスを発見したい場合は、ゾーン1と2の両方にリクエストを発行する必要があります。
+----+ +----+ +----+
| UA |--------| SA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
(Zone 1) (Zone 2)
（ゾーン1）（ゾーン2）
Figure 3: Multihomed SA
図3：マルチホームSA
In Figure 3, the SA is multihomed. The SA may receive a request from the UA on Link 1 (Zone 1). The SA MUST NOT return service information for services offered on a different zone as a request. For example, the UA could discover services offered in Zone 1 not Zone 2.
図3において、SAは、マルチホームされています。 SAは、リンク1上のUA（ゾーン1）からの要求を受信することができます。 SAは、要求として別のゾーンに提供されるサービスのためのサービス情報を返してはなりません。例えば、UAはゾーン1ないゾーン2で提供されるサービスを発見することができます。
The SA may receive a DAAdvert on Link 2 (Zone 2). The SA MUST NOT send a service registration to the DA for a service which is present in Zone 1. The SA MUST register a service with the DA which is present in Zone 2.
SAは、リンク2（ゾーン2）にDAAdvertを受けることができます。 SAはSAがゾーン2に存在しているDAにサービスを登録する必要がありますゾーン1に存在しているサービスのためにDAにサービス登録を送ってはいけません。
The SA MUST NOT include an address in a SAAdvert message which is sent on a zone where the address is not valid. For example, the SA MUST NOT send a SAAdvert onto link 2, if the SAADvert contains a service: URL with a literal link-local scoped IPv6 address for Link 1.
SAは、アドレスが有効でないゾーンに送られるSAAdvertメッセージ内のアドレスを含んではいけません。リンク1のリテラルリンクローカルスコープのIPv6アドレスを持つURLを：SAADvertサービスが含まれている場合たとえば、SAは、リンク2にSAAdvertを送ってはいけません。
The SA performs active DA discovery, as described in SLPv2 [2]. The SA MUST issue requests using multicast scope FF02 to solicit DAAdvertisements. If the SA has a site-local or global source address, it MUST reissue the request with increasing scopes up to a maximum scope of FF05. Active DA discovery must be attempted in both Zone 1 and 2. This ensures that the SA will discover as many DAs in its scope as possible.
SLPv2の[2]に記載のようにSAは、アクティブDA検出を行います。 SAはDAAdvertisementsを勧誘するマルチキャストスコープのFF02を使用して要求を発行しなければなりません。 SAはサイトローカルまたはグローバル送信元アドレスを持っている場合、それはFF05の最大範囲までスコープの増加に伴って、要求を再発行する必要があります。アクティブDAの発見は、このSAは、可能な限りその範囲内など、多くのDAを発見することを保証し、ゾーン1と2の両方で試みなければなりません。
+----+ +----+ +----+
| UA |--------| DA |--------| SA |
+----+ Link 1 +----+ Link 2 +----+
(Zone 1) (Zone 2)
（ゾーン1）（ゾーン2）
Figure 4: Multihomed DA
図4：マルチホームDA
In Figure 4, the DA is multihomed. The DA MUST keep track of which interface registrations were made on. The DA MUST prevent a registration from the SA which contains a service information valid in one zone from being discovered in another zone. For example, services registered by the SA in Zone 2 would not be discoverable by the UA in Zone 1.
図4において、DAがマルチホームです。 DAは、インタフェースの登録がオンに行われたを追跡する必要があります。 DAは、別のゾーンで発見されてから1ゾーンに有効なサービス情報が含まれているSAからの登録を防止しなければなりません。例えば、ゾーン2にSAによって登録されたサービスは、ゾーン1内UAによって発見ではないでしょう。
Care must be taken when issuing DAAdverts. The DA must respond to active DA discovery requests using the same scope as the request. For instance, if the SA issues a SrvRqst message for service type "service:directory" from a link-local source address, the DA MUST respond with a link-local (link 2) source address.
DAAdvertsを発行する際には注意する必要があります。 DAは、要求と同じスコープを使用して、アクティブDAディスカバリー要求に応答しなければなりません。 「サービス：ディレクトリ」SAはサービスタイプのSrvRqstメッセージ発行した場合たとえば、リンクローカル送信元アドレスからの、DAはリンクローカル（リンク2）ソースアドレスで応じなければなりません。
The DA MUST multicast unsolicited DAAdverts on each interface using link-local and site-local source addresses, unless it is only configured with a link-local address. In that case, the DA MUST issue DAAdverts with link-local scope only.
それが唯一のリンクローカルアドレスで構成されていない限り、DAは、リンクローカルとサイトローカル送信元アドレスを使用して、各インターフェイスに迷惑DAAdvertsをマルチキャストしなければなりません。その場合には、DAは、リンクローカルスコープでDAAdvertsを発行しなければなりません。
The DA URL MUST contain the address of the greatest scope the DA is configured with in the zone. For instance, if the DA is configured with a link-local, site-local and global address in Zone 2, it would use the global address in the DA URL (as a literal IPv6 address).
DAのURLは、DAがゾーン内で設定されている最大のスコープのアドレスを含まなければなりません。 DAは、ゾーン2で、リンクローカル、サイトローカルおよびグローバルアドレスで構成されている場合たとえば、それは（リテラルIPv6アドレスとして）DAのURLにグローバルアドレスを使用します。
The IPv6 multicast group-id range FF05::1:1000 - FF05::1:13FF was previously assigned by IANA in RFC 2375 for use by SLP [10].
IPv6マルチキャストグループID範囲FF05 :: 1：1000 - FF05 :: 1：13FFは、以前SLP [10]による使用のためにRFC 2375にIANAによって割り当てられました。
This document defines how the range of addresses FF0X::1:1000 - FF0X::1:13FF is used. IANA has assigned this range of addresses for use by Service Location Protocol.
FF0X :: 1から1000：13FFが使用されている。この文書では、アドレスFF0Xのどの範囲:: 1を定義します。 IANAは、サービスロケーションプロトコルで使用するためにこのアドレス範囲が割り当てられています。
This document fully defines the multicast addresses that this protocol will use. There is no requirement for the IANA to establish a registry to assign additional addresses.
この文書では、完全にこのプロトコルが使用するマルチキャストアドレスを定義します。 IANAが追加アドレスを割り当てるために、レジストリを確立するための要件はありません。
User Agents and Directory Agents MAY ignore all unauthenticated Service Location messages when a valid IPSec association exists.
有効なIPSecアソシエーションが存在する場合、ユーザーエージェントとディレクトリエージェントは、すべての認証されていないサービスロケーションメッセージを無視してもよい（MAY）。
Service Agents and Directory Agents MUST be able to use the IP Authentication and IP Encapsulating Security Payload for issuing and processing Service Location messages whenever an appropriate IPSec Security Association exists [13].
サービスエージェントとディレクトリエージェントは、[13]適切なのIPSecセキュリティアソシエーションが存在する時はいつでもサービスロケーションメッセージを発行し、処理するためにIP認証とIPカプセル化セキュリティペイロードを使用することができなければなりません。
SLP allows digital signatures to be produced to allow the verification of the contents of messages. There is nothing in the Modifications for IPv6 document which weakens or strengthens this technique.
SLPは、デジタル署名は、メッセージの内容の検証を可能にするように生成されることを可能にします。この技術を弱めたり強めのIPv6文書の変更には何もありません。
Acknowledgments
謝辞
Thanks to Dan Harrington, Jim Wood and Alain Durand, Thomas Narten, Dave Thaler and Erik Nordmark for their reviews of this document. John Veizades contributed to the original version of this document. The hash function is modified from a code fragment attributed to Chris Torek. Text on Scope Zones is taken from writing by Steve Deering, Brian Haberman and Brian Zill.
このドキュメントの彼らのレビューのためのダン・ハリントン、ジム・ウッドとアラン・デュラン、トーマスNarten氏、デーブターラーとエリックNordmarkとに感謝します。ジョンVeizadesは、このドキュメントのオリジナルバージョンに貢献しました。ハッシュ関数は、クリスTorekに起因するコードフラグメントから変更されています。スコープゾーン上のテキストは、スティーブデアリング、ブライアンハーバーマンとブライアンZillによる書き込みから取られています。
References
リファレンス
[1] Bradner, S., "The Internet Standards Process -- Version 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - バージョン3"、BCP 9、RFC 2026、1996年10月。
[2] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[2]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[3] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997.
[3] Veizades、J.、ガットマン、E.、パーキンス、C.及びS.カプラン、 "サービス・ロケーション・プロトコル"、RFC 2165、1997年6月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[5] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[6] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and URLs", RFC 2609, July 1999.
[6]ガットマン、E.、パーキンス、C.及びJ.ケンプ、 "サービステンプレートとURLを"、RFC 2609、1999年7月。
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[8] Hinden, R. and B. Carpenter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[8] HindenとR.とB.カーペンター、 "URLの中にリテラルIPv6アドレスのフォーマット"、RFC 2732、1999年12月。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[9] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[10] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1997.
[10] HindenとR.とS.デアリング、 "IPv6マルチキャストアドレスの割り当て"、RFC 2375、1997年7月。
[11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[11]マイヤー、D.、 "管理スコープのIPマルチキャスト"、RFC 2365、1998年7月。
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[12] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
Author's Address
著者のアドレス
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt, Germany
エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタット、ドイツ
Phone: +49 7263 911701 EMail: Erik.Guttman@germany.sun.com
電話：+49 7263 911701 Eメール：Erik.Guttman@germany.sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。