RFC3111 日本語訳
3111 Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT=25543 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Guttman Request for Comments: 3111 Sun Microsystems Category: Standards Track May 2001
Guttmanがコメントのために要求するワーキンググループE.をネットワークでつないでください: 3111年のサン・マイクロシステムズカテゴリ: 標準化過程2001年5月
Service Location Protocol Modifications for IPv6
IPv6のためのサービス位置のプロトコル変更
Status of this Memo
この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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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ネットワークの上のService Locationプロトコルバージョン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をサポートするネットワークで使用されるのは、RECOMMENDEDです。
Guttman Standards Track [Page 1] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[1ページ]RFC3111サービス位置のプロトコル変更
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . 2 2。 放送SLPのサポートを排除すると、.3 3は要求されます。 URL. . . . 3 4のIPv6アドレスのための仕様を扱ってください。 IPv6. . . . . . . . . . . . 4 4.1の上のSLPマルチキャストの振舞い。 IPv6. . . . . . . . . . 4 4.2のためのSLPv2マルチキャストグループID。 IPv6. . . . . . . . . . . . . 5 4.2.1Joining SLPv2 Multicast Groups. . . . . . . . . . . . 5 4.2.2Sending SLPv2 Multicast MessagesのためのSLPv2 Scoping Rules、Message Processingのための.64.2.3Rules、.64.2、.4人のSLPv2エージェント、複数のインタフェースで; . . . . . . . 7 4.2.4.1 総則. . . . . . . . . . . . . . . . . . . . 7 4.2.4.2Multihomed UA. . . . . . . . . . . . . . . . . . . . 8 4.2.4.3Multihomed SA. . . . . . . . . . . . . . . . . . . . 8 4.2.4.4Multihomed DA. . . . . . . . . . . . . . . . . . . . 9 5。 IANA問題. . . . . . . . . . . . . . . . . . . 10 6。 セキュリティ問題. . . . . . . . . . . . . . . . . 10承認. . . . . . . . . . . . . . . . . . . . . 10参照. . . . . . . . . . . . . . . . . . . . . . . 11作者のアドレスの.12の完全な著作権宣言文. . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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.
Service Locationプロトコル(SLP)はネットワーク・サービスの発見と品揃えにスケーラブルなフレームワークを提供します。 このプロトコルを使用して、IPのベースのネットワークを使用するコンピュータがもうとても多量の静電気を必要としないので、ネットワークのためのネットワーク・サービスの構成はアプリケーションを基礎づけました。 コンピュータが、より携帯用になるのでこれが特に重要であり、ユーザは、ネットワーク管理でそれほど許容性がないか、または要求をより実現させることができません。
The following are changes required to have the Service Location Protocol work over IPv6. These changes include:
↓これはService Locationプロトコルが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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[4]で説明されるように本書では解釈されることであるべきですか?
Guttman Standards Track [Page 2] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[2ページ]RFC3111サービス位置のプロトコル変更
2. Eliminating support for broadcast SLP requests
2. 放送SLP要求のサポートを排除します。
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の上のサービスLocationは放送に要求メッセージをService Locationに送らせます。 IPv6は放送に代わってリンク地方のマルチキャストを利用します。 SLPのための放送だけ構成はIPv6の下でサポートされません。 Userエージェントがディレクトリエージェントを発見するという要求をしたいか、または複数のServiceエージェント、Userエージェント必須マルチキャストの要求を適切なマルチキャストアドレスへの要求にしたいと思うなら。
This change modifies the requirements described in Section 6.1 (Use of Ports, UDP and Multicast) of the Service Location Protocol [2].
この変化はService Locationプロトコル[2]のセクション6.1(Ports、UDP、およびMulticastの使用)で説明された要件を変更します。
3. Address Specification for IPv6 Addresses in URLs
3. URLのIPv6アドレスのためのアドレス指定
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.
サービスLocationはDNSの利益なしでプロトコルの使用を許します。 システムのグループがこのネットワークをサポートするためにサーバの少しも前の構成なしでネットワークを造るために接続されるとき、これは関連しています。 Service Locationがこの様に使用されるとき、サービスの位置を特定するのに数字のアドレスを使用しなければなりません。
The format of a "service:" URL is defined in [6]. This URL is an "absolute URI" as defined by [7].
aの形式は「以下を修理します」。 URLは[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アドレス。(そのアドレスは「以下を修理してください」というaで使用されて、ことであるかもしれません)。 URLは[8]のように指定されています。 原文の表現は文字通りのIPv6のために[9]でアドレスを定義しました:
ipv6-addr = "[" num-addr "]"
num-addr = ; Text represented IPv6 address syntax is as
; specified in RFC 2373 [8], Section 2.2,
「["num-addr"]」というipv6-addr=num-addr=。 表されたIPv6アドレス構文があるテキスト。 RFC2373[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.
これはリンクローカルの見られたアドレスです、SAがIPv6ネットワークにルータもDNSサービスなしでサービスの広告を出すのに使用できたように。
service:printer:ipp://[FE80::a15A:93ff:fe5D:B098]:8080/path
サービス:プリンタ:ipp://[FE80: : a15A:93ff:fe5D:B098]: 8080/経路
Guttman Standards Track [Page 3] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[3ページ]RFC3111サービス位置のプロトコル変更
4. SLP multicast and unicast behavior over IPv6
4. SLPマルチキャストとIPv6の上のユニキャストの振舞い
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は異なったマルチキャストアドレスがSLPv2メッセージをIPv6の上に送って、受け取るのにどう使用されるかを説明します。 セクション4.2はこれらのアドレスの使用のための規則を定義します、そして、カバーは一般に、アドレス問題を見ました。
4.1 SLPv2 Multicast Group-IDs for IPv6
4.1 IPv6のためのSLPv2マルチキャストグループID
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はAdministratively Scoped Address範囲[11]に比例して1つのマルチキャストアドレスだけを指定します。 1つのアドレスだけが使用された理由はこの目的に利用可能な256の相対的な課題しかないということです。 他方では、IPv6はさまざまな課題に関してアドレスと十分なスペースを見ました。
SLPv2 for IPv6 uses the following multicast group-id assignments:
IPv6のためのSLPv2は以下のマルチキャストグループイド課題を使用します:
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.
これらのグループイドは送られるマルチキャストメッセージがことである範囲の範囲接頭語に結合されます。
The SVRLOC group-id is used for the following messages: Service Type Request and Attribute Request messages.
SVRLOCグループイドは以下のメッセージに使用されます: Type RequestとAttribute Requestメッセージを調整してください。
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グループイドは「: ディレクトリエージェントにサービスを提供してください」というサービスタイプのためのマルチキャストService Requestsに使用されます。 また、DAsはSVRLOC-DAマルチキャストグループイドに求められていないDA Advertメッセージを送ります。
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.
他のすべてのマルチキャストService Requestメッセージを適切なService Locationマルチキャストグループイドに送ります。 SAsはそれらが広告を出すサービスのService Typesに一致しているグループに加わります。 グループイドは、SLPv1[3]に提供されたアルゴリズムを使用することで決定しています。 SrvRqstで使用されるService Typeストリングは0-1023からの値に論じ尽くされます。 これはオフセットをFF0Xに決定します:、:1: 1000-13 FFは及びます。
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に初期化されます。 各バイト単位で、[12]がコード化したService Type UTF-8では、ストリング値は連続して考えられます。 33は現行価値Vに掛けられて、次に、現在のストリングバイトの価値は高められます。 Service Typeストリングの各バイトはこの様に処理されます。 結果はV.Forの例の下位10ビットに含まれていて、以下のコードはこのアルゴリズムを実装します:
Guttman Standards Track [Page 4] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[4ページ]RFC3111サービス位置のプロトコル変更
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 */
}
未署名の長いslp_ハッシュ(const炭*pc、未署名のint len){(len--=0)h*=33である(h+=*pc++)間の未署名の長いh=0は(0x3FFとh)を返します; さまざまな0-1023*/に丸い/*}
4.2 SLPv2 Scoping Rules for IPv6
4.2 IPv6に関して規則を見るSLPv2
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と同じリンクの上に言及されたサービスがないなら、サービスに達することができないでしょうに。
4.2.1 Joining SLPv2 Multicast Groups
4.2.1 SLPv2マルチキャストグループに加わること。
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 MUSTは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以下であるかもしれません。 この場合、SLPv2 SAsとDAsは以下のすべての範囲でマルチキャストグループに加わらなければなりません: FF01--FF05。
A DA MUST join the SVRLOC-DA group to receive SrvRqst messages requesting DAAdverts.
DA MUSTは、DAAdvertsを要求するSrvRqstメッセージを受け取るためにSVRLOC-DAグループに加わります。
A SA MUST join the SVRLOC-DA group to receive DAAdvert messages.
SA MUSTは、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 MUSTは、SrvRqstメッセージを受け取るためにグループイドのService Location範囲からのグループに加わります。 SAはそれが広告を出すサービスに対応するそれらのグループに加わるだけです。 「サービス: サービスエージェント」(SA発見のために、使用される)は接合するでしょう、例えば、したがって、要求に応じるサービスエージェントはセクション4.1で定義されたハッシュ関数から得られたグループイドで分類します:
Guttman Standards Track [Page 5] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[5ページ]RFC3111サービス位置のプロトコル変更
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
接合するグループイドはslp_ハッシュ(「サービス: サービスエージェント」)+ ベースアドレス=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 MAYはSrvTypeRqstとAttrRqstメッセージを受け取るためにSVRLOCグループに加わります。 これらの特徴は道具へのSAのためのOPTIONALです。
A UA MAY join the SVRLOC-DA group at any or all of these scopes in order to receive DAAdvert messages.
UA MAYは、DAAdvertメッセージを受け取るためにこれらの範囲のいずれかすべてでSVRLOC-DAグループに加わります。
4.2.2 Sending SLPv2 Multicast Messages
4.2.2 送付SLPv2マルチキャストメッセージ
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はそうすることができました。例えば、サイトローカルを含めたどんな範囲へのマルチキャストa SrvRqst。
4.2.3 Rules for Message Processing
4.2.3 メッセージ処理のための規則
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 MUSTが1セットのアドレスにその名前を決議します。
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 MUST NOTがサービスでSrvRqstに応じます: アドレスの範囲が要求のソースアドレス範囲より少ないサービスのためのURL。 以下の図1で規則を与えます。
Guttman Standards Track [Page 6] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[6ページ]RFC3111サービス位置のプロトコル変更
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。
4.2.4 SLPv2 Agents with multiple interfaces
4.2.4 複数のインタフェースをもっているSLPv2エージェント
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つのDIFFERENTゾーンであると考えられますが、SAME範囲について考えられるのを観測してください。
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エージェントは1つのゾーンから別のゾーンまでのサービス広告を伝播してはいけません。 これを言う別の方法はSLPv2 SAであるかDA MUST NOTが異なったゾーンでのサービスに関連しているサービス情報で1つのゾーンから要求に応じます。
The specific implication of these rules is discussed in the sections which follow.
従うセクションでこれらの規則の特定の含意について議論します。
4.2.4.1 General rules
4.2.4.1 総則
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.
位置が文字通りのアドレスであるサービスLocations(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.
例えば、サービス: SLPv2メッセージでリンクAの上にリンクローカルアドレスを含むURLをリンクAに送るかもしれません、リンクローカルの送付先アドレスだけに。
Guttman Standards Track [Page 7] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[7ページ]RFC3111サービス位置のプロトコル変更
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.
「マルチ-家へ帰」っているデバイスの各インタフェースはaで潜在的にリンクを切り離すことです。 2つのインタフェースが同じリンクに接続されるかどうか決定するのはしばしば難しいです。 その理由で、慎重な実装戦略はサービスが住んでいるのが知られているインタフェースを除いて、リンク地方のサービス位置を含むメッセージをSLPに発行しないことです。
4.2.4.2 Multihomed UA
4.2.4.2 Multihomed UA
+----+ +----+ +----+
| SA |--------| UA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
+----+ +----+ +----+ | SA|--------| Ua|--------| DA| +----+ リンク1+----+ リンク2+----+
(Zone 1) (Zone 2)
(ゾーン1)(ゾーン2)
Figure 2: Multihomed UA
図2: Multihomed 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はZone1でサービスのリクエストを発行して、SAの上、または、Zone2でサービスを発見して、DAによって広告に掲載されたサービスを発見できます。 例えば、要求がリンク地元筋アドレスから出される場合にだけ、サービスが利用可能な状態でSAはリンク1の上に返答するでしょう、リンク2で利用可能なサービスだけがある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[2]に従ってマルチキャスト要求を出す前にDAsを検出するのに活発な発見を使用しなければなりません。 DAAdvertisementsに請求するのにFF01で始まって、FF05の最大の範囲に増加する増加するマルチキャスト範囲を使用して、Uaは要求を出さなければなりません。 セクション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がすべてのサービスを発見したいと思うなら、それはZone1と2の両方に要求を出さなければなりません。
4.2.4.3 Multihomed SA
4.2.4.3 Multihomed SA
+----+ +----+ +----+
| UA |--------| SA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
+----+ +----+ +----+ | Ua|--------| SA|--------| DA| +----+ リンク1+----+ リンク2+----+
(Zone 1) (Zone 2)
(ゾーン1)(ゾーン2)
Figure 3: Multihomed SA
図3: Multihomed SA
Guttman Standards Track [Page 8] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[8ページ]RFC3111サービス位置のプロトコル変更
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はLink1(ゾーン1)の上のUAから要求を受け取るかもしれません。 SA MUST NOTは要求として異なったゾーンで提供されたサービスのためのサービス情報を返します。 例えば、UAは、サービスがZone1でどんなZone2も提供しなかったと発見できました。
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はLink2(ゾーン2)の上のDAAdvertを受けるかもしれません。 SA MUST NOTはZone1に存在しているサービスのためにサービス登録をDAに送ります。 SA MUSTはZone2に存在している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 MUST NOTはアドレスが有効でないゾーンで送られるSAAdvertメッセージにアドレスを含んでいます。 例えば、SAADvertがサービスを含んでいるなら、SA MUST NOTはリンク2にSAAdvertを送ります: Link1のための文字通りのリンクローカルの見られた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 MUSTは、DAAdvertisementsに請求するのにマルチキャスト範囲FF02を使用することで要求を出します。 SAにサイト地方の、または、グローバルなソースアドレスがあるなら、それは増加する範囲で要求をFF05の最大の範囲まで再発行しなければなりません。 Zone1と2の両方で活発なDA発見を試みなければなりません。 これは、SAが範囲のできるだけ多くのDAsを発見するのを確実にします。
4.2.4.4 Multihomed DA
4.2.4.4 Multihomed DA
+----+ +----+ +----+
| UA |--------| DA |--------| SA |
+----+ Link 1 +----+ Link 2 +----+
+----+ +----+ +----+ | Ua|--------| DA|--------| SA| +----+ リンク1+----+ リンク2+----+
(Zone 1) (Zone 2)
(ゾーン1)(ゾーン2)
Figure 4: Multihomed DA
図4: Multihomed 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 MUSTは動向をおさえます。 DA MUSTは、1つのゾーンで有効なサービス情報を含むSAからの登録が別のゾーンで発見されるのを防ぎます。 例えば、Zone2にSAによって登録されたサービスはUAがZone1で発見可能でないでしょう。
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 MUSTはリンクローカル(リンク2)のソースアドレスで応じます。
Guttman Standards Track [Page 9] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[9ページ]RFC3111サービス位置のプロトコル変更
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 MUSTマルチキャストの求められていないDAAdvertsはリンク地方で使用して、サイト地元筋アドレスを連結します、それがリンクローカルアドレスによって構成されるだけではないなら。 その場合、DA MUSTはリンク地方の範囲だけがある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 MUSTはDAがゾーンで構成される最も大きい範囲のアドレスを含んでいます。 例えば、DAがリンク地方の、そして、サイト地方であることのaとZone2のグローバルアドレスによって構成されるなら、それはDA URL(文字通りのIPv6アドレスとしての)でグローバルアドレスを使用するでしょう。
5. IANA Considerations
5. IANA問題
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マルチキャストグループイド範囲FF05:、:1: 1000--FF05、:、:1: 13FFは以前に、使用のためにRFC2375でSLP[10]によって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--FF0X、:、:1: 13FFは使用されています。 IANAはService Locationプロトコルで使用のためのこの範囲のアドレスを割り当てました。
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が追加アドレスを割り当てるために登録を確立するという要件が全くありません。
6. Security Considerations
6. セキュリティ問題
User Agents and Directory Agents MAY ignore all unauthenticated Service Location messages when a valid IPSec association exists.
有効なIPSec協会が存在すると、ユーザエージェントとディレクトリエージェントはすべてのunauthenticated Service Locationメッセージを無視するかもしれません。
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 Security Associationが存在しているときはいつも、Service Locationメッセージを発行して、処理するためのIP Authenticationを使用できて、IP Encapsulating Security有効搭載量が[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ドキュメントのためのModificationsにありません。
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.
彼らのこのドキュメントのレビューをダン・ハリントン、ジムWood、アラン・ジュランド、トーマスNarten、デーヴThaler、およびエリックNordmarkをありがとうございます。 ジョンVeizadesはこのドキュメントのオリジナルバージョンに貢献しました。 ハッシュ関数はクリスTorekの結果と考えられたコード断片から変更されます。 スティーブ・デアリング、ブライアン・ハーバーマン、およびブライアンZillで書くのからScope Zonesに関するテキストを取ります。
Guttman Standards Track [Page 10] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[10ページ]RFC3111サービス位置のプロトコル変更
References
参照
[1] Bradner, S., "The Internet Standards Process -- Version 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「バージョン3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[2] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[3] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
Location Protocol", RFC 2165, June 1997.
[3]VeizadesとJ.とGuttmanとE.とパーキンスとC.とS.キャプラン、「サービス位置のプロトコル」、RFC2165、1997年6月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[5]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[6] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
URLs", RFC 2609, July 1999.
[6] Guttman(E.、パーキンス、C.、およびJ.ケンフ)が「テンプレートとURLを調整する」、RFC2609、7月1999日
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[8] Hinden, R. and B. Carpenter, "Format for Literal IPv6 Addresses
in URL's", RFC 2732, December 1999.
Hinden、R.、およびB.大工が「URLの文字通りのIPv6アドレスのためにフォーマットする」[8]、RFC2732、1999年12月。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[9]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[10] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments",
RFC 2375, July 1997.
[10]HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、1997年7月。
[11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998.
[11] マイヤー、D.、「行政上見られたIPマルチキャスト」、RFC2365、1998年7月。
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[12]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[13] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Guttman Standards Track [Page 11] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[11ページ]RFC3111サービス位置のプロトコル変更
Author's Address
作者のアドレス
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt, Germany
エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadt、ドイツ
Phone: +49 7263 911701 EMail: Erik.Guttman@germany.sun.com
以下に電話をしてください。 +49 7263 911701はメールされます: Erik.Guttman@germany.sun.com
Guttman Standards Track [Page 12] RFC 3111 Service Location Protocol Modifications for IPv6 May 2001
IPv6 May 2001のためのGuttman標準化過程[12ページ]RFC3111サービス位置のプロトコル変更
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Guttman Standards Track [Page 13]
Guttman標準化過程[13ページ]
一覧
スポンサーリンク
