Network Working Group J. Abley
Request for Comments: 4786 Afilias Canada
BCP: 126 K. Lindqvist
Category: Best Current Practice Netnod Internet Exchange
December 2006
Network Working Group J. Abley
Request for Comments: 4786 Afilias Canada
BCP: 126 K. Lindqvist
Category: Best Current Practice Netnod Internet Exchange
December 2006
Operation of Anycast Services
选播服务的运作
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.
随着互联网的发展，以及企业内的系统和网络服务变得越来越普及，出现了许多具有高可用性需求的服务。这些要求增加了对这些服务所依赖的基础设施可靠性的要求。
Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast.
已采用各种技术来提高部署在因特网上的服务的可用性。本文件提供了使用anycast分发服务的评论和建议。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Anycast Service Distribution ....................................5
3.1. General Description ........................................5
3.2. Goals ......................................................5
4. Design ..........................................................6
4.1. Protocol Suitability .......................................6
4.2. Node Placement .............................................7
4.3. Routing Systems ............................................8
4.3.1. Anycast within an IGP ...............................8
4.3.2. Anycast within the Global Internet ..................9
4.4. Routing Considerations .....................................9
4.4.1. Signalling Service Availability .....................9
4.4.2. Covering Prefix ....................................10
4.4.3. Equal-Cost Paths ...................................10
4.4.4. Route Dampening ....................................12
4.4.5. Reverse Path Forwarding Checks .....................13
4.4.6. Propagation Scope ..................................13
4.4.7. Other Peoples' Networks ............................14
4.4.8. Aggregation Risks ..................................14
4.5. Addressing Considerations .................................15
4.6. Data Synchronisation ......................................15
4.7. Node Autonomy .............................................16
4.8. Multi-Service Nodes .......................................17
4.8.1. Multiple Covering Prefixes .........................17
4.8.2. Pessimistic Withdrawal .............................17
4.8.3. Intra-Node Interior Connectivity ...................18
4.9. Node Identification by Clients ............................18
5. Service Management .............................................19
5.1. Monitoring ................................................19
6. Security Considerations ........................................19
6.1. Denial-of-Service Attack Mitigation .......................19
6.2. Service Compromise ........................................20
6.3. Service Hijacking .........................................20
7. Acknowledgements ...............................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................21
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Anycast Service Distribution ....................................5
3.1. General Description ........................................5
3.2. Goals ......................................................5
4. Design ..........................................................6
4.1. Protocol Suitability .......................................6
4.2. Node Placement .............................................7
4.3. Routing Systems ............................................8
4.3.1. Anycast within an IGP ...............................8
4.3.2. Anycast within the Global Internet ..................9
4.4. Routing Considerations .....................................9
4.4.1. Signalling Service Availability .....................9
4.4.2. Covering Prefix ....................................10
4.4.3. Equal-Cost Paths ...................................10
4.4.4. Route Dampening ....................................12
4.4.5. Reverse Path Forwarding Checks .....................13
4.4.6. Propagation Scope ..................................13
4.4.7. Other Peoples' Networks ............................14
4.4.8. Aggregation Risks ..................................14
4.5. Addressing Considerations .................................15
4.6. Data Synchronisation ......................................15
4.7. Node Autonomy .............................................16
4.8. Multi-Service Nodes .......................................17
4.8.1. Multiple Covering Prefixes .........................17
4.8.2. Pessimistic Withdrawal .............................17
4.8.3. Intra-Node Interior Connectivity ...................18
4.9. Node Identification by Clients ............................18
5. Service Management .............................................19
5.1. Monitoring ................................................19
6. Security Considerations ........................................19
6.1. Denial-of-Service Attack Mitigation .......................19
6.2. Service Compromise ........................................20
6.3. Service Hijacking .........................................20
7. Acknowledgements ...............................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................21
This document is addressed to network operators who are considering whether to deploy or operate a distributed service using anycast. It describes the best current practice for doing so, but does not recommend whether any particular service should or should not be deployed using anycast.
本文档面向正在考虑是否使用anycast部署或操作分布式服务的网络运营商。它描述了当前执行此操作的最佳实践，但不建议是否应使用anycast部署任何特定服务。
To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes. Various techniques for anycast deployment of services are discussed in [RFC1546], [ISC-TN-2003-1], and [ISC-TN-2004-1].
要使用选播分发服务，首先将服务与一组稳定的IP地址相关联，并在路由系统中从多个独立的服务节点通告对这些地址的可达性。[RFC1546]、[ISC-TN-2003-1]和[ISC-TN-2004-1]中讨论了服务选播部署的各种技术。
The techniques and considerations described in this document apply to services reachable over both IPv4 and IPv6.
本文档中描述的技术和注意事项适用于可通过IPv4和IPv6访问的服务。
Anycast has in recent years become increasingly popular for adding redundancy to DNS servers to complement the redundancy that the DNS architecture itself already provides. Several root DNS server operators have distributed their servers widely around the Internet, and both resolver and authority servers are commonly distributed within the networks of service providers. Anycast distribution has been used by commercial DNS authority server operators for several years. The use of anycast is not limited to the DNS, although the use of anycast imposes some additional limitations on the nature of the service being distributed, including transaction longevity, transaction state held on servers, and data synchronisation capabilities.
近年来，Anycast在向DNS服务器添加冗余以补充DNS体系结构本身已经提供的冗余方面变得越来越流行。几个根DNS服务器运营商已经在Internet上广泛分布了他们的服务器，而解析器服务器和授权服务器通常都分布在服务提供商的网络中。商业DNS授权服务器运营商已经使用Anycast发行版好几年了。anycast的使用不限于DNS，尽管anycast的使用对正在分发的服务的性质施加了一些额外的限制，包括事务寿命、服务器上保持的事务状态以及数据同步能力。
Although anycast is conceptually simple, its implementation introduces some pitfalls for operation of services. For example, monitoring the availability of the service becomes more difficult; the observed availability changes according to the location of the client within the network, and the population of clients using individual anycast nodes is neither static, nor reliably deterministic.
尽管anycast在概念上很简单，但它的实现为服务的操作引入了一些陷阱。例如，监控服务的可用性变得更加困难；所观察到的可用性根据客户端在网络中的位置而变化，并且使用单个选播节点的客户端的数量既不是静态的，也不是可靠的确定性的。
This document will describe the use of anycast for both local scope distribution of services using an Interior Gateway Protocol (IGP) and global distribution using the Border Gateway Protocol (BGP) [RFC4271]. Many of the issues for monitoring and data synchronisation are common to both, but deployment issues differ substantially.
本文档将描述使用内部网关协议（IGP）在本地范围内分发服务和使用边界网关协议（BGP）在全球范围内分发服务时使用选播的情况[RFC4271]。监控和数据同步的许多问题对两者都是共同的，但部署问题有很大的不同。
Service Address: an IP address associated with a particular service (e.g., the destination address used by DNS resolvers to reach a particular authority server).
服务地址：与特定服务关联的IP地址（例如，DNS解析程序用于到达特定授权服务器的目标地址）。
Anycast: the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations.
选播：使一个特定的服务地址在多个离散的自治位置可用的做法，这样发送的数据报就被路由到几个可用位置之一。
Anycast Node: an internally-connected collection of hosts and routers that together provide service for an anycast Service Address. An Anycast Node might be as simple as a single host participating in a routing system with adjacent routers, or it might include a number of hosts connected in some more elaborate fashion; in either case, to the routing system across which the service is being anycast, each Anycast Node presents a unique path to the Service Address. The entire anycast system for the service consists of two or more separate Anycast Nodes.
选播节点：内部连接的主机和路由器集合，共同为选播服务地址提供服务。一个选播节点可以像一个单独的主机与相邻的路由器一起参与一个路由系统一样简单，或者它可以包括多个以某种更复杂的方式连接的主机；在任何一种情况下，对于服务正通过其进行选播的路由系统，每个选播节点都提供到服务地址的唯一路径。服务的整个选播系统由两个或多个独立的选播节点组成。
Catchment: in physical geography, an area drained by a river, also known as a drainage basin. By analogy, as used in this document, the topological region of a network within which packets directed at an Anycast Address are routed to one particular node.
集水区：在自然地理学中，由河流排水的区域，也称为流域。通过类比，如本文所用，网络的拓扑区域，其中指向选播地址的数据包被路由到一个特定节点。
Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system.
局部作用域选播：选播服务地址的可达性信息通过路由系统传播，其方式是特定的选播节点仅对整个路由系统的子集可见。
Local Node: an Anycast Node providing service using a Local-Scope Anycast Address.
本地节点：使用本地作用域选播地址提供服务的选播节点。
Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system.
全局作用域选播：选播服务地址的可达性信息通过路由系统传播，从而使特定的选播节点对整个路由系统可能可见。
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
全局节点：使用全局作用域选播地址提供服务的选播节点。
Anycast is the name given to the practice of making a Service Address available to a routing system at Anycast Nodes in two or more discrete locations. The service provided by each node is generally consistent regardless of the particular node chosen by the routing system to handle a particular request (although some services may benefit from deliberate differences in the behaviours of individual nodes, in order to facilitate locality-specific behaviour; see Section 4.6).
Anycast是指在两个或多个离散位置的Anycast节点上使路由系统可以使用服务地址的实践。无论路由系统选择哪个节点来处理特定请求，每个节点提供的服务通常是一致的（尽管某些服务可能会受益于各个节点行为的故意差异，以促进特定于位置的行为；参见第4.6节）。
For services distributed using anycast, there is no inherent requirement for referrals to other servers or name-based service distribution ("round-robin DNS"), although those techniques could be combined with anycast service distribution if an application required it. The routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates.
对于使用anycast分发的服务，不存在向其他服务器或基于名称的服务分发（“循环DNS”）提交的固有要求，尽管如果应用程序需要，这些技术可以与anycast服务分发相结合。路由系统根据路由系统的拓扑设计和网络中发出请求的点来决定每个请求使用哪个节点。
The Anycast Node chosen to service a particular query can be influenced by the traffic engineering capabilities of the routing protocols that make up the routing system. The degree of influence available to the operator of the node depends on the scale of the routing system within which the Service Address is anycast.
选择为特定查询提供服务的选播节点可能会受到组成路由系统的路由协议的流量工程能力的影响。节点的操作员可用的影响程度取决于路由系统的规模，其中服务地址为选播。
Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load). Distribution of load between nodes for the purposes of reliability, and coarse-grained distribution of load for the purposes of making popular services scalable, can often be achieved, however.
选播节点之间的负载平衡通常很难实现（节点之间的负载分布在请求和流量负载方面通常是不平衡的）。然而，为了可靠性的目的在节点之间分配负载，为了使流行服务具有可伸缩性的目的而进行粗粒度的负载分配，通常是可以实现的。
The scale of the routing system through which a service is anycast can vary from a small Interior Gateway Protocol (IGP) connecting a small handful of components, to the Border Gateway Protocol (BGP) [RFC4271] connecting the global Internet, depending on the nature of the service distribution that is required.
根据所需服务分发的性质，服务选播的路由系统的规模可能会有所不同，从连接少量组件的小型内部网关协议（IGP）到连接全球互联网的边界网关协议（BGP）[RFC4271]。
A service may be anycast for a variety of reasons. A number of common objectives are:
服务可以是任意广播，原因有多种。一些共同目标是：
1. Coarse ("unbalanced") distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks;
1. 节点间负载的粗略（“不平衡”）分布，以允许基础设施扩展到增加的查询数量，并适应瞬时查询峰值；
2. Mitigation of non-distributed denial-of-service attacks by localising damage to single Anycast Nodes;
2. 通过定位对单个选播节点的破坏来缓解非分布式拒绝服务攻击；
3. Constraint of distributed denial-of-service attacks or flash crowds to local regions around Anycast Nodes. Anycast distribution of a service provides the opportunity for traffic to be handled closer to its source, perhaps using high-performance peering links rather than oversubscribed, paid transit circuits;
3. 将分布式拒绝服务攻击或flash群组限制到选播节点周围的本地区域。服务的选播分发提供了接近其来源处理流量的机会，可能使用高性能对等链路，而不是过度订阅的付费传输电路；
4. To provide additional information to help identify the location of traffic sources in the case of attack (or query) traffic which incorporates spoofed source addresses. This information is derived from the property of anycast service distribution that the selection of the Anycast Node used to service a particular query may be related to the topological source of the request.
4. 在攻击（或查询）流量（包含伪造源地址）的情况下，提供附加信息以帮助识别流量源的位置。此信息源自选播服务分发的属性，即用于服务特定查询的选播节点的选择可能与请求的拓扑源相关。
5. Improvement of query response time, by reducing the network distance between client and server with the provision of a local Anycast Node. The extent to which query response time is improved depends on the way that nodes are selected for the clients by the routing system. Topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases, response times may see no reduction, and may increase.
5. 通过提供本地选播节点来缩短客户端和服务器之间的网络距离，从而提高查询响应时间。查询响应时间的改善程度取决于路由系统为客户端选择节点的方式。通常，路由系统内的拓扑接近度与网络上的往返性能无关；在某些情况下，响应时间可能不会减少，也可能会增加。
6. To reduce a list of servers to a single, distributed address. For example, a large number of authoritative nameservers for a zone may be deployed using a small set of anycast Service Addresses; this approach can increase the accessibility of zone data in the DNS without increasing the size of a referral response from a nameserver authoritative for the parent zone.
6. 将服务器列表缩减为单个分布式地址。例如，可以使用一小组选播服务地址来部署一个区域的大量权威名称服务器；这种方法可以增加DNS中区域数据的可访问性，而不会增加来自父区域权威名称服务器的引用响应的大小。
When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably.
当服务在两个或多个节点之间进行选播时，路由系统代表客户端做出节点选择决策。由于通常要求在事务期间在客户机和同一服务器节点之间执行单个客户机-服务器交互，因此路由系统的节点选择决策应在远长于预期事务时间的时间内保持稳定，如果要可靠地提供服务。
Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply (e.g., DNS transactions over UDP transport). Other services involve
某些服务的事务时间非常短，甚至可以使用单个数据包请求和单个数据包回复（例如，UDP传输上的DNS事务）来执行。其他服务包括
far longer-lived transactions (e.g., bulk file downloads and audio-visual media streaming).
寿命更长的事务（例如，批量文件下载和视听媒体流）。
Services may be anycast within very predictable routing systems, which can remain stable for long periods of time (e.g., anycast within a well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7).
服务可以是非常可预测的路由系统中的选播，可以长时间保持稳定（例如，在管理良好且拓扑简单的IGP中的选播，其中节点选择更改仅作为对节点故障的响应发生）。其他部署的可预测性要差得多（参见第4.4.7节）。
The stability of the routing system, together with the transaction time of the service, should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase that is handled by anycast servers, and a sustained phase that is provided by non-anycast servers, perhaps chosen during the initialisation phase.
在决定服务是否适合使用选播进行分发时，应仔细比较路由系统的稳定性以及服务的事务时间。在某些情况下，对于新协议，将大型事务分为由选播服务器处理的初始化阶段和由非选播服务器提供的持续阶段（可能在初始化阶段选择）是可行的。
This document deliberately avoids prescribing rules as to which protocols or services are suitable for distribution by anycast; to attempt to do so would be presumptuous.
本文件故意避免规定适用于anycast分发的协议或服务的规则；试图这样做是自以为是的。
Operators should be aware that, especially for long running flows, there are potential failure modes using anycast that are more complex than a simple 'destination unreachable' failure using unicast.
运营商应该意识到，特别是对于长时间运行的流，使用选播的潜在故障模式比使用单播的简单“目标不可到达”故障更复杂。
Decisions as to where Anycast Nodes should be placed will depend to a large extent on the goals of the service distribution. For example:
关于选播节点应放置在何处的决策将在很大程度上取决于服务分发的目标。例如：
o A DNS recursive resolver service might be distributed within an ISP's network, one Anycast Node per site. o A root DNS server service might be distributed throughout the Internet; Anycast Nodes could be located in regions with poor external connectivity to ensure that the DNS functions adequately within the region during times of external network failure. o An FTP mirror service might include local nodes located at exchange points, so that ISPs connected to that exchange point could download bulk data more cheaply than if they had to use expensive transit circuits.
o DNS递归解析器服务可能分布在ISP的网络中，每个站点一个选播节点。o根DNS服务器服务可能分布在整个互联网上；选播节点可以位于外部连接较差的区域，以确保DNS在外部网络故障期间在该区域内充分运行。o FTP镜像服务可能包括位于交换点的本地节点，因此连接到该交换点的ISP可以比使用昂贵的传输线路更便宜地下载批量数据。
In general, node placement decisions should be made with consideration of likely traffic requirements, the potential for flash crowds or denial-of-service traffic, the stability of the local routing system, and the failure modes with respect to node failure or local routing system failure.
一般来说，做出节点放置决策时应考虑可能的流量需求、闪存拥挤或拒绝服务流量的可能性、本地路由系统的稳定性以及与节点故障或本地路由系统故障相关的故障模式。
There are several common motivations for the distribution of a Service Address within the scope of an IGP:
在IGP范围内分发服务地址有几种常见的动机：
1. to improve service response times by hosting a service close to other users of the network;
1. 通过在网络的其他用户附近托管服务来提高服务响应时间；
2. to improve service reliability by providing automatic fail-over to backup nodes; and
2. 通过向备份节点提供自动故障切换来提高服务可靠性；和
3. to keep service traffic local in order to avoid congesting wide-area links.
3. 保持本地服务流量，以避免广域链路拥塞。
In each case, the decisions as to where and how services are provisioned can be made by network engineers without requiring such operational complexities as regional variances in the configuration of client computers, or deliberate DNS incoherence (causing DNS queries to yield different answers depending on where the queries originate).
在每种情况下，网络工程师都可以做出关于在何处以及如何提供服务的决定，而不需要诸如客户端计算机配置中的区域差异或故意的DNS不一致（导致DNS查询根据查询的来源产生不同的答案）之类的操作复杂性。
When a service is anycast within an IGP, the routing system is typically under the control of the same organisation that is providing the service, and hence the relationship between service transaction characteristics and network stability are likely to be well-understood. This technique is consequently applicable to a larger number of applications than Internet-wide anycast service distribution (see Section 4.1).
当服务是IGP内的选播时，路由系统通常在提供服务的同一组织的控制下，因此服务事务特征和网络稳定性之间的关系可能得到很好的理解。因此，与互联网范围的选播服务分发相比，该技术适用于更多的应用程序（见第4.1节）。
An IGP will generally have no inherent restriction on the length of prefix that can be introduced to it. In this case, there is no need to construct a covering prefix for particular Service Addresses; host routes corresponding to the Service Address can instead be introduced to the routing system. See Section 4.4.2 for more discussion of the requirement for a covering prefix.
IGP通常对可以引入的前缀长度没有固有的限制。在这种情况下，不需要为特定服务地址构造覆盖前缀；相反，可以将与服务地址对应的主机路由引入路由系统。有关覆盖前缀要求的更多讨论，请参见第4.4.2节。
IGPs often feature little or no aggregation of routes, partly due to algorithmic complexities in supporting aggregation. There is little motivation for aggregation in many networks' IGPs in many cases, since the amount of routing information carried in the IGP is small enough that scaling concerns in routers do not arise. For discussion of aggregation risks in other routing systems, see Section 4.4.8.
IGP通常很少或没有路由聚合，部分原因是支持聚合的算法复杂。在许多情况下，在许多网络的IGP中几乎没有聚合的动机，因为IGP中承载的路由信息量足够小，因此不会出现路由器中的扩展问题。有关其他路由系统中聚合风险的讨论，请参见第4.4.8节。
By reducing the scope of the IGP to just the hosts providing service (together with one or more gateway routers), this technique can be applied to the construction of server clusters. This application is discussed in some detail in [ISC-TN-2004-1].
通过将IGP的范围缩小到仅提供服务的主机（以及一个或多个网关路由器），该技术可以应用于服务器集群的构建。[ISC-TN-2004-1]对该应用进行了详细讨论。
Service Addresses may be anycast within the global Internet routing system in order to distribute services across the entire network. The principal differences between this application and the IGP-scope distribution discussed in Section 4.3.1 are that:
服务地址可以是全球因特网路由系统内的任意广播，以便在整个网络上分发服务。本应用与第4.3.1节中讨论的IGP范围分布之间的主要区别在于：
1. the routing system is, in general, controlled by other people;
1. 路由系统通常由其他人控制；
2. the routing protocol concerned (BGP), and commonly-accepted practices in its deployment, impose some additional constraints (see Section 4.4).
2. 相关路由协议（BGP）及其部署中普遍接受的实践施加了一些额外的限制（见第4.4节）。
When a routing system is provided with reachability information for a Service Address from an individual node, packets addressed to that Service Address will start to arrive at the node. Since it is essential for the node to be ready to accept requests before they start to arrive, a coupling between the routing information and the availability of the service at a particular node is desirable.
当为路由系统提供来自单个节点的服务地址的可达性信息时，发往该服务地址的包将开始到达该节点。由于节点必须在请求开始到达之前准备好接受请求，因此路由信息和特定节点处的服务可用性之间的耦合是可取的。
Where a routing advertisement from a node corresponds to a single Service Address, this coupling might be such that availability of the service triggers the route advertisement, and non-availability of the service triggers a route withdrawal. This can be achieved using routing protocol implementations on the same server. These implementations provide the service being distributed and are configured to advertise and withdraw the route advertisement in conjunction with the availability (and health) of the software on the host that processes service requests. An example of such an arrangement for a DNS service is included in [ISC-TN-2004-1].
在来自节点的路由公告对应于单个服务地址的情况下，该耦合可以使得服务的可用性触发路由公告，并且服务的不可用性触发路由撤回。这可以通过在同一服务器上使用路由协议实现来实现。这些实现提供正在分发的服务，并配置为与处理服务请求的主机上的软件的可用性（和运行状况）一起公布和收回路由公布。[ISC-TN-2004-1]中包括DNS服务的这种安排的示例。
Where a routing advertisement from a node corresponds to two or more Service Addresses, it may not be appropriate to trigger a route withdrawal due to the non-availability of a single service. Another approach in the case where the service is down at one Anycast Node is to route requests to a different Anycast Node where the service is working normally. This approach is discussed in Section 4.8.
当来自节点的路由公告对应于两个或多个服务地址时，由于单个服务的不可用性，可能不适合触发路由撤回。在服务在一个选播节点关闭的情况下，另一种方法是将请求路由到服务正常工作的另一个选播节点。第4.8节讨论了这种方法。
Rapid advertisement/withdrawal oscillations can cause operational problems, and nodes should be configured such that rapid oscillations are avoided (e.g., by implementing a minimum delay following a withdrawal before the service can be re-advertised). See Section 4.4.4 for a discussion of route oscillations in BGP.
快速公布/撤回振荡可能导致操作问题，并且节点的配置应确保避免快速振荡（例如，通过在服务可以重新公布之前实施撤回后的最小延迟）。关于BGP中线路振荡的讨论，请参见第4.4.4节。
In some routing systems (e.g., the BGP-based routing system of the global Internet), it is not possible, in general, to propagate a host route with confidence that the route will propagate throughout the network. This is a consequence of operational policy, and not a protocol restriction.
在某些路由系统（例如，全球互联网基于BGP的路由系统）中，通常不可能在确信路由将在整个网络中传播的情况下传播主机路由。这是操作策略的结果，而不是协议限制。
In such cases it is necessary to propagate a route that covers the Service Address, and that has a sufficiently short prefix that it will not be discarded by commonly-deployed import policies. For IPv4 Service Addresses, this is often a 24-bit prefix, but there are other well-documented examples of IPv4 import polices that filter on Regional Internet Registry (RIR) allocation boundaries, and hence some experimentation may be prudent. Corresponding import policies for IPv6 prefixes also exist. See Section 4.5 for more discussion of IPv6 Service Addresses and corresponding anycast routes.
在这种情况下，如果导入的前缀足够短，则通常不会被丢弃。对于IPv4服务地址，这通常是一个24位前缀，但也有其他详细记录的IPv4导入策略示例，这些策略会在区域Internet注册表（RIR）分配边界上进行过滤，因此一些实验可能是谨慎的。还存在IPv6前缀的相应导入策略。有关IPv6服务地址和相应选播路由的更多讨论，请参见第4.5节。
The propagation of a single route per service has some associated scaling issues, which are discussed in Section 4.4.8.
每个服务的单个路由的传播有一些相关的扩展问题，这些问题在第4.4.8节中讨论。
Where multiple Service Addresses are covered by the same covering route, there is no longer a tight coupling between the advertisement of that route and the individual services associated with the covered host routes. The resulting impact on signalling availability of individual services is discussed in Section 4.4.1 and Section 4.8.
在多个服务地址被同一覆盖路由覆盖的情况下，该路由的广告和与覆盖的主机路由相关联的各个服务之间不再存在紧密耦合。第4.4.1节和第4.8节讨论了对单个服务的信令可用性产生的影响。
Some routing systems support equal-cost paths to the same destination. Where multiple, equal-cost paths exist and lead to different Anycast Nodes, there is a risk that different request packets associated with a single transaction might be delivered to more than one node. Services provided over TCP [RFC0793] necessarily involve transactions with multiple request packets, due to the TCP setup handshake.
一些路由系统支持到同一目的地的等成本路径。如果存在多个等成本路径并导致不同的选播节点，则存在将与单个事务相关联的不同请求数据包传递到多个节点的风险。由于TCP设置握手，通过TCP[RFC0793]提供的服务必然涉及具有多个请求数据包的事务。
For services that are distributed across the global Internet using BGP, equal-cost paths are normally not a consideration: BGP's exit selection algorithm usually selects a single, consistent exit for a
对于使用BGP分布在全球互联网上的服务，通常不考虑同等成本路径：BGP的出口选择算法通常为一个服务选择一个单一、一致的出口
single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however.
单个目标，无论是否存在多个候选路径。然而，存在支持多路径出口选择的BGP实现。
Equal-cost paths are commonly supported in IGPs. Multi-node selection for a single transaction can be avoided in most cases by careful consideration of IGP link metrics, or by applying equal-cost multi-path (ECMP) selection algorithms, which cause a single node to be selected for a single multi-packet transaction. For an example of the use of hash-based ECMP selection in anycast service distribution, see [ISC-TN-2004-1].
IGP中通常支持等成本路径。在大多数情况下，通过仔细考虑IGP链路度量，或通过应用等成本多路径（ECMP）选择算法，可以避免单个事务的多节点选择，这会导致为单个多数据包事务选择单个节点。有关在选播服务分发中使用基于哈希的ECMP选择的示例，请参阅[ISC-TN-2004-1]。
Other ECMP selection algorithms are commonly available, including those in which packets from the same flow are not guaranteed to be routed towards the same destination. ECMP algorithms that select a route on a per-packet basis rather than per-flow are commonly referred to as performing "Per Packet Load Balancing" (PPLB).
其他ECMP选择算法通常可用，包括那些不保证来自相同流的数据包路由到相同目的地的算法。基于每个包而不是每个流选择路由的ECMP算法通常被称为执行“每个包负载平衡”（PPLB）。
With respect to anycast service distribution, some uses of PPLB may cause different packets from a single multi-packet transaction sent by a client to be delivered to different Anycast Nodes, effectively making the anycast service unavailable. Whether this affects specific anycast services will depend on how and where Anycast Nodes are deployed within the routing system, and on where the PPLB is being performed:
关于选播服务分布，PPLB的一些使用可能导致来自客户端发送的单个多分组事务的不同分组被传送到不同的选播节点，从而有效地使选播服务不可用。这是否会影响特定的选播服务将取决于选播节点在路由系统中的部署方式和位置，以及执行PPLB的位置：
1. PPLB across multiple, parallel links between the same pair of routers should cause no node selection problems;
1. 在同一对路由器之间跨越多个并行链路的PPLB不应导致节点选择问题；
2. PPLB across diverse paths within a single autonomous system (AS), where the paths converge to a single exit as they leave the AS, should cause no node selection problems;
2. 单个自治系统（AS）内不同路径之间的PPLB（路径在离开AS时汇聚到单个出口）应不会导致节点选择问题；
3. PPLB across links to different neighbour ASes, where the neighbour ASes have selected different nodes for a particular anycast destination will, in general, cause request packets to be distributed across multiple Anycast Nodes. This will have the effect that the anycast service is unavailable to clients downstream of the router performing PPLB.
3. PPLB跨到不同邻居ASE的链路，其中邻居ASE为特定选播目的地选择了不同的节点，通常会导致请求数据包分布在多个选播节点上。这将导致执行PPLB的路由器下游的客户端无法使用选播服务。
The uses of PPLB that have the potential to interact badly with anycast service distribution can also cause persistent packet reordering. A network path that persistently reorders segments will degrade the performance of traffic carried by TCP [Allman2000]. TCP, according to several documented measurements, accounts for the bulk of traffic carried on the Internet ([McCreary2000], [Fomenkov2004]). Consequently, in many cases, it is reasonable to consider networks making such use of PPLB to be pathological.
PPLB的使用有可能与选播服务分发严重交互，也可能导致持久的数据包重新排序。持续重新排列网段的网络路径将降低TCP承载的流量性能[Allman2000]。根据一些记录在案的测量数据，TCP占据了互联网上传输的大部分流量（[McCreary2000]，[Fomenkov2004]）。因此，在许多情况下，合理地考虑使PPLB使用这样的网络是病态的。
Frequent advertisements and withdrawals of individual prefixes in BGP are known as flaps. Rapid flapping can lead to CPU exhaustion on routers quite remote from the source of the instability, and for this reason rapid route oscillations are frequently "dampened", as described in [RFC2439].
BGP中频繁的广告和单个前缀的撤销称为flaps。快速摆动可能会导致远离不稳定源的路由器上的CPU耗尽，因此，如[RFC2439]所述，快速路由振荡通常会被“抑制”。
A dampened path will be suppressed by routers for an interval that increases according to the frequency of the observed oscillation; a suppressed path will not propagate. Hence, a single router can prevent the propagation of a flapping prefix to the rest of an autonomous system, affording other routers in the network protection from the instability.
阻尼路径将被路由器抑制一段时间间隔，该时间间隔根据观察到的振荡频率而增加；被抑制的路径将不会传播。因此，单个路由器可以防止摆动前缀传播到自治系统的其余部分，从而为网络中的其他路由器提供不稳定性保护。
Some implementations of flap dampening penalise oscillating advertisements based on the observed AS_PATH, and not on Network Layer Reachability Information (NLRI; see [RFC4271]). For this reason, network instability that leads to route flapping from a single Anycast Node, will not generally cause advertisements from other nodes (which have different AS_PATH attributes) to be dampened by these implementations.
襟翼阻尼的一些实现基于观察到的AS_路径而不是网络层可达性信息（NLRI；参见[RFC4271]）惩罚振荡广告。因此，导致来自单个选播节点的路由抖动的网络不稳定性通常不会导致来自其他节点（具有不同AS_路径属性）的广告被这些实现抑制。
To limit the opportunity of such implementations to penalise advertisements originating from different Anycast Nodes in response to oscillations from just a single node, care should be taken to arrange that the AS_PATH attributes on routes from different nodes are as diverse as possible. For example, Anycast Nodes should use the same origin AS for their advertisements, but might have different upstream ASes.
为了限制此类实现惩罚源自不同选播节点的广告的机会，以响应来自单个节点的振荡，应注意安排来自不同节点的路由上的AS_路径属性尽可能不同。例如，选播节点应使用与其播发相同的源，但可能具有不同的上游ASE。
Where different implementations of flap dampening are prevalent, individual nodes' instability may result in stable nodes becoming unavailable. In mitigation, the following measures may be useful:
当襟翼阻尼的不同实现普遍存在时，单个节点的不稳定性可能导致稳定节点变得不可用。在缓解措施中，以下措施可能有用：
1. Judicious deployment of Local Nodes in combination with especially stable Global Nodes (with high inter-AS path splay, redundant hardware, power, etc.) may help limit oscillation problems to the Local Nodes' limited regions of influence;
1. 明智地部署本地节点和特别稳定的全局节点（具有高的内部AS路径扩展、冗余硬件、电源等）可能有助于将振荡问题限制在本地节点的有限影响区域；
2. Aggressive flap-dampening of the service prefix close to the origin (e.g., within an Anycast Node, or in adjacent ASes of each Anycast Node) may also help reduce the opportunity of remote ASes to see oscillations at all.
2. 靠近原点（例如，在选播节点内，或在每个选播节点的相邻ASE中）的服务前缀的积极衰减也可能有助于减少远程ASE看到振荡的机会。
Reverse Path Forwarding (RPF) checks, first described in [RFC2267], are commonly deployed as part of ingress interface packet filters on routers in the Internet in order to deny packets whose source addresses are spoofed (see also RFC 2827 [RFC2827]). Deployed implementations of RPF make several modes of operation available (e.g., "loose" and "strict").
[RFC2267]中首次描述的反向路径转发（RPF）检查通常作为互联网路由器上入口接口包过滤器的一部分部署，以拒绝源地址被欺骗的包（另请参见RFC 2827[RFC2827]）。RPF的部署实现提供了几种操作模式（例如，“松散”和“严格”）。
Some modes of RPF can cause non-spoofed packets to be denied when they originate from multi-homed sites, since selected paths might legitimately not correspond with the ingress interface of non-spoofed packets from the multi-homed site. This issue is discussed in [RFC3704].
当从多个站点选择数据包时，可能会导致不合法地拒绝来自多个站点的数据包进入。[RFC3704]中讨论了此问题。
A collection of Anycast Nodes deployed across the Internet is largely indistinguishable from a distributed, multi-homed site to the routing system, and hence this risk also exists for Anycast Nodes, even if individual nodes are not multi-homed. Care should be taken to ensure that each Anycast Node is treated as a multi-homed network, and that the corresponding recommendations in [RFC3704] with respect to RPF checks are heeded.
如果在Internet上部署了多个主节点，那么多个主节点到多个主节点的路由在很大程度上也是不可区分的。应注意确保将每个选播节点视为多宿网络，并注意[RFC3704]中关于RPF检查的相应建议。
In the context of anycast service distribution across the global Internet, Global Nodes are those that are capable of providing service to clients anywhere in the network; reachability information for the service is propagated globally, without restriction, by advertising the routes covering the Service Addresses for global transit to one or more providers.
在全球互联网上任意广播服务分布的上下文中，全球节点是那些能够向网络中任何位置的客户端提供服务的节点；服务的可达性信息通过向一个或多个提供商公布覆盖全球传输的服务地址的路由而不受限制地进行全球传播。
More than one Global Node can exist for a single service (and indeed this is often the case, for reasons of redundancy and load-sharing).
单个服务可以存在多个全局节点（事实上，出于冗余和负载共享的原因，这种情况经常发生）。
In contrast, it is sometimes desirable to deploy an Anycast Node that only provides services to a local catchment of autonomous systems, and that is deliberately not available to the entire Internet; such nodes are referred to in this document as Local Nodes. An example of circumstances in which a Local Node may be appropriate are nodes designed to serve a region with rich internal connectivity but unreliable, congested, or expensive access to the rest of the Internet.
相比之下，有时需要部署仅向自治系统的本地集水区提供服务的选播节点，而该节点故意不可用于整个互联网；此类节点在本文档中称为本地节点。本地节点可能适合的情况的一个示例是，节点被设计为服务于具有丰富内部连接但对互联网其余部分的访问不可靠、拥挤或昂贵的区域。
Local Nodes advertise covering routes for Service Addresses in such a way that their propagation is restricted. This might be done using well-known community string attributes such as NO_EXPORT [RFC1997] or NOPEER [RFC3765], or by arranging with peers to apply a conventional
本地节点以限制其传播的方式公布服务地址的覆盖路由。这可以通过使用众所周知的社区字符串属性（如NO_EXPORT[RFC1997]或NOPEER[RFC3765]）来实现，也可以通过与对等方安排应用常规字符串来实现
"peering" import policy instead of a "transit" import policy, or some suitable combination of measures.
“对等”进口政策，而不是“过境”进口政策，或一些适当的措施组合。
Advertising reachability to Service Addresses from Local Nodes should ideally be done using a routing policy that requires presence of explicit attributes for propagation, rather than relying on implicit (default) policy. Inadvertent propagation of a route beyond its intended horizon can result in capacity problems for Local Nodes, which might degrade service performance network-wide.
理想情况下，从本地节点到服务地址的广告可达性应该使用路由策略来实现，该策略要求存在用于传播的显式属性，而不是依赖于隐式（默认）策略。路由的无意传播超出其预期范围可能会导致本地节点的容量问题，这可能会降低整个网络的服务性能。
When anycast services are deployed across networks operated by others, their reachability is dependent on routing policies and topology changes (planned and unplanned), which are unpredictable and sometimes difficult to identify. Since the routing system may include networks operated by multiple, unrelated organisations, the possibility of unforeseen interactions resulting from the combinations of unrelated changes also exists.
当选播服务跨其他人运营的网络部署时，其可达性取决于路由策略和拓扑更改（计划内和计划外），这些更改不可预测，有时难以识别。由于路由系统可能包括由多个不相关组织运营的网络，因此也存在由不相关变更组合导致的不可预见交互的可能性。
The stability and predictability of such a routing system should be taken into consideration when assessing the suitability of anycast as a distribution strategy for particular services and protocols (see also Section 4.1).
在评估选播作为特定服务和协议的分发策略的适用性时，应考虑此类路由系统的稳定性和可预测性（另见第4.1节）。
By way of mitigation, routing policies used by Anycast Nodes across such routing systems should be conservative, individual nodes' internal and external/connecting infrastructure should be scaled to support loads far in excess of the average, and the service should be monitored proactively from many points in order to avoid unpleasant surprises (see Section 5.1).
作为缓解措施，选播节点在此类路由系统中使用的路由策略应该是保守的，单个节点的内部和外部/连接基础设施应该扩展以支持远远超过平均水平的负载，并且应该从多个点主动监控服务，以避免令人不快的意外（见第5.1节）。
The propagation of a single route for each anycast service does not scale well for routing systems in which the load of routing information that must be carried is a concern, and where there are potentially many services to distribute. For example, an autonomous system that provides services to the Internet with N Service Addresses covered by a single exported route would need to advertise (N+1) routes, if each of those services were to be distributed using anycast.
对于路由系统，每个选播服务的单一路由的传播不能很好地扩展，其中必须承载的路由信息的负载是一个问题，并且可能有许多服务要分发。例如，如果一个自治系统向互联网提供服务，其中N个服务地址由一个导出的路由覆盖，那么如果这些服务中的每一个都要使用选播进行分发，则需要公布（N+1）个路由。
The common practice of applying minimum prefix-length filters in import policies on the Internet (see Section 4.4.2) means that for a route covering a Service Address to be usefully propagated the prefix length must be substantially less than that required to advertise just the host route. Widespread advertisement of short prefixes for
在Internet上的导入策略中应用最小前缀长度筛选器的常见做法（参见第4.4.2节）意味着，要有效传播覆盖服务地址的路由，前缀长度必须大大小于仅播发主机路由所需的长度。广泛宣传短前缀用于
individual services, hence, also has a negative impact on address conservation.
因此，个别服务对地址保护也有负面影响。
Both of these issues can be mitigated to some extent by the use of a single covering prefix to accommodate multiple Service Addresses, as described in Section 4.8. This implies a de-coupling of the route advertisement from individual service availability (see Section 4.4.1), however, with attendant risks to the stability of the service as a whole (see Section 4.7).
如第4.8节所述，通过使用单个覆盖前缀来容纳多个服务地址，可以在一定程度上缓解这两个问题。这意味着线路广告与单个服务可用性的分离（见第4.4.1节），但是，伴随着服务整体稳定性的风险（见第4.7节）。
In general, the scaling problems described here prevent anycast from being a useful, general approach for service distribution on the global Internet. It remains, however, a useful technique for distributing a limited number of Internet-critical services, as well as in smaller networks where the aggregation concerns discussed here do not apply.
总的来说，这里描述的扩展问题阻止了anycast成为全球Internet上服务分发的一种有用的、通用的方法。然而，对于分发数量有限的Internet关键服务，以及在这里讨论的聚合问题不适用的较小网络中，它仍然是一种有用的技术。
Service Addresses should be unique within the routing system that connects all Anycast Nodes to all possible clients of the service. Service Addresses must also be chosen so that corresponding routes will be allowed to propagate within that routing system.
在将所有选播节点连接到服务的所有可能客户端的路由系统中，服务地址应该是唯一的。还必须选择服务地址，以便允许相应的路由在该路由系统中传播。
For an IPv4-numbered service deployed across the Internet, for example, an address might be chosen from a block where the minimum RIR allocation size is 24 bits, and reachability to that address might be provided by originating the covering 24-bit prefix.
例如，对于跨Internet部署的IPv4编号服务，可以从最小RIR分配大小为24位的块中选择地址，并且可以通过发起覆盖24位前缀来提供对该地址的可达性。
For an IPv4-numbered service deployed within a private network, a locally-unused [RFC1918] address might be chosen, and reachability to that address might be signalled using a (32-bit) host route.
对于部署在专用网络中的IPv4编号的服务，可以选择本地未使用的[RFC1918]地址，并且可以使用（32位）主机路由来通知对该地址的可达性。
For IPv6-numbered services, Anycast Addresses are not scoped differently from unicast addresses. As such, the guidelines for address suitability presented for IPv4 follow for IPv6. Note that historical prohibitions on anycast distribution of services over IPv6 have been removed from the IPv6 addressing specification in [RFC4291].
对于IPv6编号的服务，选播地址的作用域与单播地址没有区别。因此，IPv4地址适用性指南遵循IPv6。请注意，[RFC4291]中的IPv6寻址规范中已删除了对IPv6上服务的选播分发的历史禁令。
Although some services have been deployed in localised form (such that clients from particular regions are presented with regionally-relevant content), many services have the property that responses to client requests should be consistent, regardless of where the request originates. For a service distributed using anycast, that implies that different Anycast Nodes must operate in a consistent manner and,
尽管有些服务已经以本地化的形式部署（例如，来自特定地区的客户机可以看到与地区相关的内容），但许多服务的特性是，对客户机请求的响应应该是一致的，而不管请求来自何处。对于使用选播分发的服务，这意味着不同的选播节点必须以一致的方式运行，
where that consistent behaviour is based on a data set, the data concerned be synchronised between nodes.
如果一致性行为基于数据集，则相关数据应在节点之间同步。
The mechanism by which data is synchronised depends on the nature of the service; examples are zone transfers for authoritative DNS servers and rsync for FTP archives. In general, the synchronisation of data between Anycast Nodes will involve transactions between non-anycast addresses.
数据同步的机制取决于服务的性质；例如，用于权威DNS服务器的区域传输和用于FTP存档的rsync。通常，选播节点之间的数据同步将涉及非选播地址之间的事务。
Data synchronisation across public networks should be carried out with appropriate authentication and encryption.
跨公共网络的数据同步应通过适当的身份验证和加密进行。
For an anycast deployment whose goals include improved reliability through redundancy, it is important to minimise the opportunity for a single defect to compromise many (or all) nodes, or for the failure of one node to provide a cascading failure that brings down additional successive nodes until the service as a whole is defeated.
对于目标包括通过冗余提高可靠性的选播部署，重要的是最大限度地减少单个缺陷危害多个（或所有）节点的机会，或减少一个节点出现级联故障的机会，从而导致其他连续节点停机，直到整个服务失败。
Co-dependencies are avoided by making each node as autonomous and self-sufficient as possible. The degree to which nodes can survive failure elsewhere depends on the nature of the service being delivered, but for services which accommodate disconnected operation (e.g., the timed propagation of changes between master and slave servers in the DNS) a high degree of autonomy can be achieved.
通过使每个节点尽可能自治和自给自足，避免了相互依赖。节点能够在其他地方经受住故障的程度取决于所交付服务的性质，但对于适应断开连接操作的服务（例如，DNS中主服务器和从服务器之间的更改的定时传播），可以实现高度自治。
The possibility of cascading failure due to load can also be reduced by the deployment of both Global and Local Nodes for a single service, since the effective fail-over path of traffic is, in general, from Local Node to Global Node; traffic that might sink one Local Node is unlikely to sink all Local Nodes, except in the most degenerate cases.
由于流量的有效故障转移路径通常是从本地节点到全局节点，因此，通过为单个服务部署全局和本地节点，还可以减少由于负载而导致级联故障的可能性；可能接收一个本地节点的流量不太可能接收所有本地节点，但在最退化的情况下除外。
The chance of cascading failure due to a software defect in an operating system or server can be reduced in many cases by deploying nodes running different implementations of operating system, server software, routing protocol software, etc., such that a defect that appears in a single component does not affect the whole system.
在许多情况下，通过部署运行操作系统、服务器软件、路由协议软件等不同实现的节点，可以减少由于操作系统或服务器中的软件缺陷而导致级联故障的可能性，从而使单个组件中出现的缺陷不会影响整个系统。
It should be noted that these approaches to increase node autonomy are, to varying degrees, contrary to the practical goals of making a deployed service straightforward to operate. A service that is overly complex is more likely to suffer from operator error than a service that is more straightforward to run. Careful consideration should be given to all of these aspects so that an appropriate balance may be found.
应该注意的是，这些增加节点自治性的方法在不同程度上与使部署的服务易于操作的实际目标相反。过于复杂的服务比更容易运行的服务更容易出现操作员错误。应仔细考虑所有这些方面，以便找到适当的平衡。
For a service distributed across a routing system where covering prefixes are required to announce reachability to a single Service Address (see Section 4.4.2), special consideration is required in the case where multiple services need to be distributed across a single set of nodes. This results from the requirement to signal availability of individual services to the routing system so that requests for service are not received by nodes that are not able to process them (see Section 4.4.1).
对于分布在路由系统上的服务，如果需要覆盖前缀来宣布对单个服务地址的可达性（参见第4.4.2节），则需要特别考虑多个服务需要分布在单个节点集上的情况。这是因为需要向路由系统发送单个服务的可用性信号，以便无法处理服务请求的节点无法接收服务请求（参见第4.4.1节）。
Several approaches are described in the following sections.
以下部分介绍了几种方法。
Each Service Address is chosen such that only one Service Address is covered by each advertised prefix. Advertisement and withdrawal of a single covering prefix can be tightly coupled to the availability of the single associated service.
选择每个服务地址时，每个播发前缀只覆盖一个服务地址。单个覆盖前缀的公布和撤销可以与单个关联服务的可用性紧密耦合。
This is the most straightforward approach. However, since it makes very poor utilisation of globally-unique addresses, it is only suitable for use for a small number of critical, infrastructural services such as root DNS servers. General Internet-wide deployment of services using this approach will not scale.
这是最直接的方法。但是，由于它对全球唯一地址的利用率非常低，因此它仅适用于少数关键的基础设施服务，如根DNS服务器。使用此方法在Internet范围内部署服务不会扩展。
Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawal of the single covering prefix is coupled to the availability of all associated services; if any individual service becomes unavailable, the covering prefix is withdrawn.
选择多个服务地址，以便它们由单个前缀覆盖。单个覆盖前缀的公布和撤销与所有相关服务的可用性相耦合；如果任何单个服务变得不可用，覆盖前缀将被撤销。
The coupling between service availability and advertisement of the covering prefix is complicated by the requirement that all Service Addresses must be available -- the announcement needs to be triggered by the presence of all component routes, and not just a single covered route.
服务可用性和覆盖前缀广告之间的耦合因所有服务地址必须可用的要求而变得复杂——公告需要由所有组件路由的存在而触发，而不仅仅是单个覆盖路由。
The fact that a single malfunctioning service causes all deployed services in a node to be taken off-line may make this approach unsuitable for many applications.
单个故障服务会导致节点中所有已部署的服务离线，这一事实可能使此方法不适用于许多应用程序。
Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawal of the single covering prefix is coupled to the availability of any one service. Nodes have interior connectivity, e.g., using tunnels. Host routes for Service Addresses are distributed using an IGP that extends to include routers at all nodes.
选择多个服务地址，以便它们由单个前缀覆盖。单个覆盖前缀的公布和撤销与任何一项服务的可用性相耦合。节点具有内部连接，例如使用隧道。服务地址的主机路由使用IGP分发，IGP扩展到包括所有节点上的路由器。
In the event that a service is unavailable at one node, but available at other nodes, a request may be routed over the interior network from the receiving node towards some other node for processing.
在服务在一个节点不可用但在其他节点可用的情况下，请求可以通过内部网络从接收节点路由到另一个节点进行处理。
In the event that some local services in a node are down and the node is disconnected from other nodes, continued advertisement of the covering prefix might cause requests to become black-holed.
如果某个节点中的某些本地服务关闭，并且该节点与其他节点断开连接，则覆盖前缀的持续播发可能会导致请求变成黑洞。
This approach allows reasonable address utilisation of the netblock covered by the announced prefix, at the expense of reduced autonomy of individual nodes; the IGP in which all nodes participate can be viewed as a single point of failure.
这种方法允许合理利用公布的前缀所覆盖的netblock地址，但牺牲了单个节点的自治性；所有节点都参与的IGP可视为单点故障。
From time to time, all clients of deployed services experience problems, and those problems require diagnosis. A service distributed using anycast imposes an additional variable on the diagnostic process over a simple, unicast service -- the particular Anycast Node that is handling a client's request.
有时，部署服务的所有客户端都会遇到问题，这些问题需要诊断。使用anycast分发的服务通过简单的单播服务（处理客户端请求的特定anycast节点）在诊断过程中施加额外的变量。
In some cases, common network-level diagnostic tools such as traceroute may be sufficient to identify the node being used by a client. However, the use of such tools may be beyond the abilities of users at the client side of a transaction, and, in any case, network conditions at the time of the problem may change by the time such tools are exercised.
在某些情况下，常用的网络级诊断工具（如traceroute）可能足以识别客户端正在使用的节点。然而，此类工具的使用可能超出了交易客户端用户的能力，并且在任何情况下，出现问题时的网络条件可能会在使用此类工具时发生变化。
Troubleshooting problems with anycast services is greatly facilitated if mechanisms to determine the identity of a node are designed into the protocol. Examples of such mechanisms include the NSID option in DNS [NSID] and the common inclusion of hostname information in SMTP servers' initial greeting at session initiation [RFC2821].
如果在协议中设计了确定节点身份的机制，则可以大大方便地排除选播服务的问题。此类机制的示例包括DNS[NSID]中的NSID选项，以及在会话启动时SMTP服务器的初始问候语[RFC2821]中通常包含主机名信息。
Provision of such in-band mechanisms for node identification is strongly recommended for services to be distributed using anycast.
强烈建议为使用选播分发的服务提供此类带内节点标识机制。
Monitoring a service that is distributed is more complex than monitoring a non-distributed service, since the observed accuracy and availability of the service is, in general, different when viewed from clients attached to different parts of the network. When a problem is identified, it is also not always obvious which node served the request, and hence which node is malfunctioning.
监视分布式服务比监视非分布式服务更复杂，因为从连接到网络不同部分的客户端查看时，观察到的服务的准确性和可用性通常是不同的。当确定问题时，也不总是很明显哪个节点为请求提供服务，因此哪个节点出现故障。
It is recommended that distributed services are monitored from probes distributed representatively across the routing system, and, where possible, the identity of the node answering individual requests is recorded along with performance and availability statistics. The RIPE NCC DNSMON service [DNSMON] is an example of such monitoring for the DNS.
建议从代表性地分布在整个路由系统中的探测器监视分布式服务，并且在可能的情况下，记录响应单个请求的节点的标识以及性能和可用性统计信息。成熟的NCC DNSMON服务[DNSMON]就是这种DNS监控的一个例子。
Monitoring the routing system (from a variety of places, in the case of routing systems where perspective is relevant) can also provide useful diagnostics for troubleshooting service availability. This can be achieved using dedicated probes, or public route measurement facilities on the Internet such as the RIPE NCC Routing Information Service [RIS] and the University of Oregon Route Views Project [ROUTEVIEWS].
监控路由系统（在与透视图相关的路由系统的情况下，从多个位置）还可以为服务可用性故障排除提供有用的诊断。这可以通过使用专用探针或因特网上的公共路由测量设施来实现，例如成熟的NCC路由信息服务[RIS]和俄勒冈大学路由查看项目[RouTeVIEW]。
Monitoring the health of the component devices in an anycast deployment of a service (hosts, routers, etc.) is straightforward, and can be achieved using the same tools and techniques commonly used to manage other network-connected infrastructure, without the additional complexity involved in monitoring anycast Service Addresses.
在服务（主机、路由器等）的选播部署中监视组件设备的健康状况是简单的，并且可以使用通常用于管理其他网络连接基础设施的相同工具和技术来实现，而不需要监视选播服务地址所涉及的额外复杂性。
This document describes mechanisms for deploying services on the Internet that can be used to mitigate vulnerability to attack:
本文档描述了在Internet上部署服务的机制，这些服务可用于缓解攻击漏洞：
1. An Anycast Node can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from having to deal with that traffic;
1. 选播节点可以充当其影响范围内发起的攻击流量的接收器，防止其他节点不得不处理该流量；
2. The task of dealing with attack traffic whose sources are widely distributed is itself distributed across all the nodes that contribute to the service. Since the problem of sorting between legitimate and attack traffic is distributed, this may lead to better scaling properties than a service that is not distributed.
2. 处理来源广泛分布的攻击流量的任务本身就分布在服务的所有节点上。由于合法流量和攻击流量之间的排序问题是分布式的，因此与未分布式的服务相比，这可能会导致更好的扩展特性。
The distribution of a service across several (or many) autonomous nodes imposes increased monitoring as well as an increased systems administration burden on the operator of the service, which might reduce the effectiveness of host and router security.
跨多个（或多个）自治节点分发服务会增加服务运营商的监控和系统管理负担，这可能会降低主机和路由器安全性的有效性。
The potential benefit of being able to take compromised servers off-line without compromising the service can only be realised if there are working procedures to do so quickly and reliably.
只有在有快速可靠的工作程序的情况下，才能实现在不影响服务的情况下使受损服务器离线的潜在好处。
It is possible that an unauthorised party might advertise routes corresponding to anycast Service Addresses across a network, and by doing so, capture legitimate request traffic or process requests in a manner that compromises the service (or both). A rogue Anycast Node might be difficult to detect by clients or by the operator of the service.
未经授权的一方可能会在网络上公布与选播服务地址对应的路由，并通过这样做捕获合法的请求流量或以损害服务（或两者）的方式处理请求。恶意选播节点可能很难被客户端或服务运营商检测到。
The risk of service hijacking by manipulation of the routing system exists regardless of whether a service is distributed using anycast. However, the fact that legitimate Anycast Nodes are observable in the routing system may make it more difficult to detect rogue nodes.
无论是否使用选播分发服务，都存在通过操纵路由系统劫持服务的风险。然而，在路由系统中可以观察到合法的选播节点这一事实可能使检测恶意节点变得更加困难。
Many protocols that incorporate authentication or integrity protection provide those features in a robust fashion, e.g., using periodic re-authentication within a single session, or integrity protection at either the channel (e.g., [RFC2845], [RFC3207]) or message (e.g., [RFC4033], [RFC2311]) levels. Protocols that are less robust may be more vulnerable to session hijacking. Given the greater opportunity for undetected session hijack with anycast services, the use of robust protocols is recommended for anycast services that require authentication or integrity protection.
许多包含身份验证或完整性保护的协议以健壮的方式提供这些功能，例如，在单个会话中使用定期重新身份验证，或者在信道（例如，[RFC2845]、[RFC3207]）或消息（例如，[RFC4033]、[RFC2311]）级别上使用完整性保护。健壮性较差的协议可能更容易被会话劫持。由于选播服务存在更大的未被检测到的会话劫持机会，建议对需要身份验证或完整性保护的选播服务使用健壮的协议。
The authors gratefully acknowledge the contributions from various participants of the grow working group, and in particular Geoff Huston, Pekka Savola, Danny McPherson, Ben Black, and Alan Barrett.
作者衷心感谢grow工作组各参与者的贡献，特别是Geoff Huston、Pekka Savola、Danny McPherson、Ben Black和Alan Barrett。
This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
这项工作得到了美国国家科学基金会（研究资助SCIO 0427 144）和DNS OARC的支持。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997]Chandrasekeran，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439]Villamizar，C.，Chandra，R.，和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，1998年11月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[Allman2000] Allman, M. and E. Blanton, "On Making TCP More Robust to Packet Reordering", January 2000, <http:// www.icir.org/mallman/papers/tcp-reorder-ccr.ps>.
[Allman2000]Allman，M.和E.Blanton，“关于使TCP对数据包重新排序更具鲁棒性”，2000年1月，<http://www.icir.org/mallman/papers/TCP-reorder-ccr.ps>。
[DNSMON] "RIPE NCC DNS Monitoring Services", <http://dnsmon.ripe.net/>.
[DNSMON]“成熟的NCC DNS监控服务”<http://dnsmon.ripe.net/>.
[Fomenkov2004] Fomenkov, M., Keys, K., Moore, D., and k. claffy, "Longitudinal Study of Internet Traffic from 1999- 2003", January 2004, <http://www.caida.org/ outreach/papers/2003/nlanr/nlanr_overview.pdf>.
[Fomenkov 2004]Fomenkov，M.，Keys，K.，Moore，D.，和K。claffy，“1999-2003年互联网流量纵向研究”，2004年1月<http://www.caida.org/ 外展/papers/2003/nlanr/nlanr_overview.pdf>。
[ISC-TN-2003-1] Abley, J., "Hierarchical Anycast for Global Service Distribution", March 2003, <http://www.isc.org/pubs/tn/isc-tn-2003-1.html>.
[ISC-TN-2003-1]Abley，J.“全球服务分布的分层选播”，2003年3月<http://www.isc.org/pubs/tn/isc-tn-2003-1.html>.
[ISC-TN-2004-1] Abley, J., "A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD", March 2004, <http://www.isc.org/pubs/tn/isc-tn-2004-1.html>.
[ISC-TN-2004-1]Abley，J.“使用GNU Zebra、ISC BIND 9和FreeBSD分发DNS服务请求的软件方法”，2004年3月<http://www.isc.org/pubs/tn/isc-tn-2004-1.html>.
[McCreary2000] McCreary, S. and k. claffy, "Trends in Wide Area IP Traffic Patterns: A View from Ames Internet Exchange", September 2000, <http://www.caida.org/ outreach/papers/2000/AIX0005/AIX0005.pdf>.
[McCreary2000]McCreary，S.和k。claffy，“广域IP流量模式的趋势：来自Ames Internet Exchange的观点”，2000年9月<http://www.caida.org/ 外展/papers/2000/AIX0005/AIX0005.pdf>。
[NSID] Austein, R., "DNS Name Server Identifier Option (NSID)", Work in Progress, June 2006.
[NSID]Austein，R.，“DNS名称服务器标识符选项（NSID）”，正在进行的工作，2006年6月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[RFC2267]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，RFC 2267，1998年1月。
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2311]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.，和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004.
[RFC3765]Huston，G.“用于边界网关协议（BGP）路由范围控制的NOPEER社区”，RFC 3765，2004年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RIS] "RIPE NCC Routing Information Service (RIS)", <http://ris.ripe.net>.
[RIS]“成熟的NCC路由信息服务（RIS）”<http://ris.ripe.net>.
[ROUTEVIEWS] "University of Oregon Route Views Project", <http://www.routeviews.org/>.
[ROUTEVIEWS]“俄勒冈大学路线视图项目”<http://www.routeviews.org/>.
Authors' Addresses
作者地址
Joe Abley Afilias Canada, Corp. 204 - 4141 Yonge Street Toronto, ON M2P 2A8 Canada
Joe Abley Afilias Canada，公司地址：加拿大M2P 2A8多伦多Yonge街204-4141号
Phone: +1 416 673 4176
EMail: jabley@ca.afilias.info
URI: http://afilias.info/
Phone: +1 416 673 4176
EMail: jabley@ca.afilias.info
URI: http://afilias.info/
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden
瑞典斯德哥尔摩Kurt Erik Lindqvist Netnod互联网交换电话30 118 47
EMail: kurtis@kurtis.pp.se
URI: http://www.netnod.se/
EMail: kurtis@kurtis.pp.se
URI: http://www.netnod.se/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。