[要約] RFC 3111は、IPv6に対応したサービス位置プロトコル（SLP）の変更点を説明しています。このRFCの目的は、IPv6ネットワークでのサービスの発見と広告を効果的に行うためのガイドラインを提供することです。
Network Working Group E. Guttman
Request for Comments: 3111 Sun Microsystems
Category: Standards Track May 2001
Service Location Protocol Modifications for IPv6
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、IPv6ネットワークを介して使用するサービスロケーションプロトコルバージョン2（SLPV2）を定義しています。このプロトコルは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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、ブロードキャストの代わりにLink-Local Multicastを利用しています。SLPのブロードキャストのみの構成は、IPv6ではサポートされていません。ユーザーエージェントがディレクトリエージェントの発見を要求したり、複数のサービスエージェントのリクエストを行うことを希望する場合、ユーザーエージェントは適切なマルチキャストアドレスにリクエストをマルチキャストする必要があります。
This change modifies the requirements described in Section 6.1 (Use of Ports, UDP and Multicast) of the Service Location Protocol [2].
この変更は、サービスロケーションプロトコルのセクション6.1（ポート、UDP、マルチキャストの使用）で説明されている要件を変更します[2]。
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].
「サービス：」の形式は[6]で定義されています。このURLは、[7]で定義されている「絶対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アドレスは、[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]
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.
これは、SAが使用してルーターやDNSサービスを伴わないIPv6ネットワークでサービスを宣伝するために使用できるように、Link-Local Scopedアドレスです。
service:printer:ipp://[FE80::a15A:93ff:fe5D:B098]:8080/path
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
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 Group-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 Group-IDは、「Service：Directory-Agent」サービスタイプのマルチキャストサービス要求に使用されます。また、DASは、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に送信されます。SASは、宣伝するサービスのサービスタイプに対応するグループに参加します。Group-IDは、SLPV1で提供されるアルゴリズムを使用して決定されます[3]。SRVRQSTで使用されるサービスタイプの文字列は、0-1023の値にハッシュされます。これにより、FF0X :: 1：1000-13FF範囲へのオフセットが決まります。
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ビット値Vは0に初期化されています。サービスタイプの各バイトUTF-8 [12]エンコードされた文字列値は連続して見られます。現在の値vに33を掛け、現在の文字列バイトの値が追加されます。サービスタイプの文字列の各バイトは、この方法で処理されます。結果は、Vの10ビットの低い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エージェントは、ユニキャストで使用するために構成されているよりも、インターフェイスの範囲が大きいマルチキャストグループに参加してはなりません。たとえば、Link-Localアドレスでのみ構成されたインターフェイスは、FF01とFF02のスコープでグループに結合されます。インターフェイスがサイトローカルまたはグローバルアドレスで構成されている場合、結合されたすべてのマルチキャストグループの範囲は、Scope FF05よりも大きくない場合があります。この場合、SLPV2 SASとDASは、次のすべてのスコープでマルチキャストグループに参加する必要があります：FF01 -FF05。
A DA MUST join the SVRLOC-DA group to receive SrvRqst messages requesting DAAdverts.
DAはSVRLOC-DAグループに参加して、DAADVERTSを要求するSRVRQSTメッセージを受信する必要があります。
A SA MUST join the SVRLOC-DA group to receive DAAdvert messages.
SAは、SVRLOC-DAグループに参加して、DaAdvertメッセージを受信する必要があります。
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:
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
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.
少なくとも1つのグローバルアドレスで構成されたインターフェイスを備えた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.
SLPV2 SASとDASは、サービスのスコープ：URLアドレスが入っているかを決定する必要があります。これは、数値IPv6アドレスが含まれている場合、URLを調べることで可能です。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に応答してはなりません。Requestのソースアドレススコープよりも低いアドレススコープを持つサービス用の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.
これにより、UASがサービスを発見できることを防ぎます。アクセスできないサービス用のURL。
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つの異なるサイト内のトポロジー領域は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.
場所（SRVREG、SRVREG、SRVRPLY、ATTRRST、SAADVERTメッセージ、またはDAADVERTメッセージ）であるサービスの場所は、文字通りのアドレスである場合、同じゾーンにあるSLPエージェントにのみ送信する必要があります。
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によって宣伝されているサービスを発見できます。たとえば、リクエストがLink-Local Sourceアドレスから発行された場合、SAはリンク1で利用可能なサービスでのみ返信します。DAは、リンク2で利用可能なサービスのみです。
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 [2]に従って、マルチキャストリクエストを発行する前に、アクティブディスカバリーを使用してDASを検出する必要があります。UAは、FF01から始まり、FF05の最大範囲に増加するマルチキャストスコープの増加を使用して、DaAdvertisementsを求めてリクエストを発行する必要があります。セクション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がマルチキャストディスカバリーを使用してDASを発見できない場合、サイトローカルスコープ（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（ゾーン1）のUAからリクエストを受信する場合があります。SAは、リクエストとして別のゾーンで提供されるサービスのサービス情報を返してはなりません。たとえば、UAはゾーン2ではなくゾーン1で提供されるサービスを発見できます。
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は、ゾーン1に存在するサービスのためにDAにサービス登録を送信してはなりません。SAは、ゾーン2に存在する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メッセージにアドレスを含めるべきではありません。たとえば、SAADVERTにサービスが含まれている場合、SAはリンク2にSaAdvertを送信してはなりません。リンク1にリテラルリンクローカルスコープIPv6アドレスを備えたURL。
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.
SAは、SLPV2 [2]に記載されているように、アクティブなDA発見を実行します。SAは、マルチキャストスコープFF02を使用してリクエストを発行して、DAADVERTISEMENTSを求めなければなりません。SAがサイトローカルまたはグローバルソースアドレスを持っている場合、FF05の最大スコープまでスコープを増やすと、リクエストを再発行する必要があります。ゾーン1と2の両方でアクティブなDAディスカバリーを試みる必要があります。これにより、SAはできるだけ多くのDAを発見できるようになります。
+----+ +----+ +----+
| 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は、あるゾーンで有効なサービス情報が別のゾーンで発見されないようにする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は、リンクローカルアドレスでのみ構成されていない限り、リンクローカルおよびサイトローカルのソースアドレスを使用して、各インターフェイスに未承諾のDAADVERTをマルチキャストする必要があります。その場合、DAはLink-Localスコープのみで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のリンクローカル、サイトローカル、グローバルアドレスで構成されている場合、DA URLのグローバルアドレス（リテラルIPv6アドレスとして）を使用します。
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は、以前にRFC 2375でIANAによってSLPが使用するために割り当てられていました[10]。
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 -FF0X :: 1：13FFがどのように使用されるかを定義します。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 Associationが存在する場合、すべての認証されていないサービスロケーションメッセージを無視する場合があります。
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].
サービスエージェントとディレクトリエージェントは、適切なIPSECセキュリティ協会が存在する場合はいつでも、サービスの位置メッセージを発行および処理するために、IP認証とIPカプセルのセキュリティペイロードを使用できる必要があります[13]。
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.
この文書のレビューをしてくれたダン・ハリントン、ジム・ウッド、アラン・デュランド、トーマス・ナルテン、デイブ・サラー、エリック・ノードマークに感謝します。John Veizadesは、このドキュメントの元のバージョンに貢献しました。ハッシュ関数は、Chris Torekに起因するコードフラグメントから変更されます。スコープゾーンに関するテキストは、スティーブディアリング、ブライアンハーバーマン、ブライアンジルによる執筆から取られています。
References
参考文献
[1] Bradner, S., "The Internet Standards Process -- Version 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol、Version 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.、Guttman、E.、Perkins、C。and S. Kaplan、「Service Location Protocol」、RFC 2165、1997年6月。
[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] 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.
Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[6] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and URLs", RFC 2609, July 1999.
[6] Guttman、E.、Perkins、C。and J. Kempf、「サービステンプレートと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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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。and B. Carpenter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[9] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[10] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1997.
[10] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレスの割り当て」、RFC 2375、1997年7月。
[11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[11] Meyer、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
Author's Address
著者の連絡先
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt, Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadt、ドイツ
Phone: +49 7263 911701
EMail: Erik.Guttman@germany.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エディター機能の資金は現在、インターネット協会によって提供されています。