Network Working Group E. Guttman
Request for Comments: 3111 Sun Microsystems
Category: Standards Track May 2001
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.
版权所有（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.
本文档定义了在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
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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使用链路本地多播代替广播。IPv6下不支持SLP的仅广播配置。如果用户代理希望请求发现目录代理或请求多个服务代理，则用户代理必须将请求多播到适当的多播地址。
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].
[6]中定义了“服务：”URL的格式。此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]:
在[8]中指定了一个数字IPv6地址，例如可用于“服务：”URL的地址。[9]中为文字IPv6地址定义的文本表示形式：
ipv6-addr = "[" num-addr "]" num-addr = ; Text represented IPv6 address syntax is as ; specified in RFC 2373 [8], Section 2.2,
ipv6地址=“[“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 DAAD消息中使用。
service:directory-agent://[FEC0::323:A3F9:25ff:fe91:109D]
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网络上公布其服务。
service:printer:ipp://[FE80::a15A:93ff:fe5D:B098]:8080/path
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]。之所以只使用一个地址，是因为只有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 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组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用于“服务：目录代理”服务类型的多播服务请求。此外，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。SA将加入与其播发的服务的服务类型相对应的组。使用SLPv1[3]中提供的算法确定组id。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位中。例如，以下代码实现了该算法：
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 */
}
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。在这种情况下，SLPv2 SAs和DAs必须加入以下所有作用域中的多播组：FF01-FF05。
A DA MUST join the SVRLOC-DA group to receive SrvRqst messages requesting DAAdverts.
DA必须加入SVRLOC-DA组才能接收请求DAAD的SrvRqst消息。
A SA MUST join the SVRLOC-DA group to receive DAAdvert messages.
SA必须加入SVRLOC-DA组才能接收DAAD消息。
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必须从组ID的服务位置范围加入组才能接收SrvRqst消息。SA只加入与其广告服务相对应的组。例如，响应“service:service agent”（用于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
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可以加入SVRLOC组以接收SrvTypeRqst和Attrqst消息；这些功能是SA实现的可选功能。
A UA MAY join the SVRLOC-DA group at any or all of these scopes in order to receive DAAdvert messages.
UA可以在任何或所有这些作用域加入SVRLOC-DA组，以便接收DAAD消息。
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.
SLPv2 SAs和DAs必须确定服务的作用域：URL地址所在。如果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不得使用地址范围小于请求源地址范围的服务的service:URL响应SrvRqst。下面的图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 |
+-------------+------------+------------+---------+
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.
作用域区域，或简称为区域，是给定作用域拓扑的连接区域。例如，由特定站点内的路由器连接的链路集，以及连接到这些链路的接口，包括站点本地范围的单个区域。要理解范围和分区之间的区别，请注意两个不同站点内的拓扑区域被视为两个不同的分区，但范围相同。
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.
根据定义，具有多个连接到不同链接的接口的主机连接到两个链接本地区域。主机还可以连接到其他作用域的多个区域。
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、SrvRply、ATRRST、SAAdvert或DAAD消息中）只能发送给位于同一区域上的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.
多宿设备的每个接口都可能位于单独的链路上。通常很难确定两个接口是否连接到同一链路。因此，谨慎的实施策略是不发出包含链路本地服务位置的SLP消息，除非在已知服务驻留的接口上。
+----+ +----+ +----+
| SA |--------| UA |--------| DA |
+----+ Link 1 +----+ Link 2 +----+
+----+ +----+ +----+
| 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将仅使用链路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.
根据SLPv2[2]，UA必须在发出多播请求之前使用主动发现来检测DAs。UA必须使用从FF01开始增加多播作用域并增加到FF05的最大作用域来发出请求，以请求DAD广告。注意第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 +----+
+----+ +----+ +----+
| 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可以发现在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）上接收DAAD。SA不得向DA发送区域1中存在的服务的服务注册。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包含一个service:URL，且该URL具有链接1的文本链接本地作用域IPv6地址，则SA不得将SAAdvert发送到链接2。
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执行主动DA发现，如SLPv2[2]所述。SA必须使用多播作用域FF02发出请求以请求DAB广告。如果SA具有站点本地或全局源地址，则必须重新发出请求，并将作用域增加到FF05的最大作用域。必须在区域1和2中尝试活动DA发现。这确保SA将在其范围内发现尽可能多的DAs。
+----+ +----+ +----+
| UA |--------| DA |--------| SA |
+----+ Link 1 +----+ Link 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必须防止在另一个区域中发现来自SA的注册，该注册包含在一个区域中有效的服务信息。例如，SA在2区注册的服务将不会被UA在1区发现。
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.
发布广告时必须小心。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必须使用链路本地和站点本地源地址在每个接口上多播未经请求的DAAD，除非它仅配置了链路本地地址。在这种情况下，DA必须仅发布链接本地范围的DAAD。
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先前由IANA在RFC 2375中分配给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关联时，用户代理和目录代理可能会忽略所有未经验证的服务位置消息。
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.
感谢Dan Harrington、Jim Wood和Alain Durand、Thomas Narten、Dave Thaler和Erik Nordmark对本文件的审阅。John Veizades对本文件的原始版本做出了贡献。哈希函数是从Chris Torek的代码片段修改而来的。关于范围区域的文本摘自Steve Deering、Brian Haberman和Brian Zill的著作。
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.和M.Day，“服务位置协议，版本2”，RFC 26081999年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.和S.Kaplan，“服务位置协议”，RFC 21651997年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 10351987年11月。
[6] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and URLs", RFC 2609, July 1999.
[6] Guttman，E.，Perkins，C.和J.Kempf，“服务模板和URL”，RFC 26091999年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.和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.Carpenter，“URL中文字IPv6地址的格式”，RFC27321999年12月。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[9] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[10] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1997.
[10] Hinden，R.和S.Deering，“IPv6多播地址分配”，RFC 23751997年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] “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
埃里克·古特曼太阳微系统公司。7 74915德国威伯斯塔特
Phone: +49 7263 911701
EMail: Erik.Guttman@germany.sun.com
Phone: +49 7263 911701
EMail: 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编辑功能的资金目前由互联网协会提供。