Internet Architecture Board (IAB) D. McPherson
Request for Comments: 7094 Verisign, Inc.
Category: Informational D. Oran
ISSN: 2070-1721 Cisco Systems
D. Thaler
Microsoft Corporation
E. Osterweil
Verisign, Inc.
January 2014
Internet Architecture Board (IAB) D. McPherson
Request for Comments: 7094 Verisign, Inc.
Category: Informational D. Oran
ISSN: 2070-1721 Cisco Systems
D. Thaler
Microsoft Corporation
E. Osterweil
Verisign, Inc.
January 2014
Architectural Considerations of IP Anycast
IP选播的体系结构考虑
Abstract
摘要
This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.
本备忘录讨论了IP选播的架构含义，并提供了各种IETF协议使用选播的一些历史分析。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7094.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7094.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Overview ........................................................2
2. Background ......................................................3
2.1. Anycast History ............................................3
2.2. Anycast in IPv6 ............................................6
2.3. DNS Anycast ................................................6
2.4. BCP 126 on Operation of Anycast Services ...................8
3. Principles ......................................................8
3.1. Layering and Resiliency ....................................8
3.2. Anycast Addresses as Destinations ..........................9
3.3. Anycast Addresses as Sources ..............................10
3.4. Service Discovery .........................................10
4. Analysis .......................................................11
4.1. Regarding Widespread Anycast Use ..........................11
4.2. Transport Implications ....................................11
4.3. Stateful Firewalls, Middleboxes, and Anycast ..............12
4.4. Security Considerations ...................................12
4.5. Deployment Considerations .................................15
5. Conclusions ....................................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................16
Appendix A. IAB Members at the Time of Approval ...................21
1. Overview ........................................................2
2. Background ......................................................3
2.1. Anycast History ............................................3
2.2. Anycast in IPv6 ............................................6
2.3. DNS Anycast ................................................6
2.4. BCP 126 on Operation of Anycast Services ...................8
3. Principles ......................................................8
3.1. Layering and Resiliency ....................................8
3.2. Anycast Addresses as Destinations ..........................9
3.3. Anycast Addresses as Sources ..............................10
3.4. Service Discovery .........................................10
4. Analysis .......................................................11
4.1. Regarding Widespread Anycast Use ..........................11
4.2. Transport Implications ....................................11
4.3. Stateful Firewalls, Middleboxes, and Anycast ..............12
4.4. Security Considerations ...................................12
4.5. Deployment Considerations .................................15
5. Conclusions ....................................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................16
Appendix A. IAB Members at the Time of Approval ...................21
IP anycast is a technique with a long legacy and interesting engineering challenges. However, at its core, it is a relatively simple concept. As described in BCP 126 [RFC4786], the general form of IP anycast is 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.
IP选播是一项具有悠久历史和有趣工程挑战的技术。然而，它的核心是一个相对简单的概念。如BCP 126[RFC4786]中所述，IP选播的一般形式是使特定服务地址在多个离散的自主位置可用的实践，从而将发送的数据报路由到多个可用位置之一。
IP anycast is used for at least one critical Internet service: that of the Domain Name System [RFC1035] root servers. By late 2007, at least 10 of the 13 root name servers were already using IP anycast [RSSAC29]. Use of IP anycast is growing for other applications as well. It has been deployed for over a decade for DNS resolution services and is currently used by several DNS Top Level Domain (TLD) operators. IP anycast is also used for other services in operational environments, including Network Time Protocol (NTP) [RFC5905] services.
IP选播至少用于一个关键的Internet服务：域名系统[RFC1035]根服务器的服务。到2007年底，13个根名称服务器中至少有10个已经在使用IP选播[RSSAC29]。IP选播在其他应用程序中的使用也在增长。它已经部署了十多年用于DNS解析服务，目前由几个DNS顶级域（TLD）运营商使用。IP选播还用于操作环境中的其他服务，包括网络时间协议（NTP）[RFC5905]服务。
Anycast addresses are syntactically indistinguishable from unicast addresses. Anycast addressing is equivalent to that of unicast in multiple locations. Destination-based routing does best-effort delivery of a packet to one interface among the set of interfaces asserting reachability for the address. The expectation of delivery
选播地址在语法上与单播地址无法区分。选播寻址相当于多个位置的单播寻址。基于目的地的路由尽最大努力将数据包传递到一组接口中，这些接口断言地址的可达性。交货期
is to the "closest" instance as determined by unicast routing topology metric(s), and there is also a possibility that various load-balancing techniques (e.g., per-packet, per-microflow) may be used among multiple equal-cost routes to distribute load for an anycasted prefix.
是由单播路由拓扑度量确定的“最近”实例，并且还可能在多个等成本路由之间使用各种负载平衡技术（例如，每个分组、每个微流），以分配任意广播前缀的负载。
Unlike IP unicast, it is not considered an error to assert the same anycast address on multiple interfaces within the same or multiple systems.
与IP单播不同，在同一个或多个系统中的多个接口上断言相同的选播地址不被视为错误。
When IP anycast is employed, many pitfalls and subtleties exist with applications and transports as well as for routing configuration and operation. In this document, we aim to capture many of the architectural implications of IP anycast.
当采用IP选播时，应用程序和传输以及路由配置和操作都存在许多陷阱和微妙之处。在本文档中，我们旨在捕获IP选播的许多架构含义。
BCP 126 [RFC4786] discusses several different deployment models with IP anycast. Two additional distinctions beyond that document involve "off-link anycast" and "on-link anycast". "Off-link anycast" takes advantage of routing protocol preferences and the IP hop-by-hop destination-based forwarding paradigm in order to direct packets to the "closest" destination. This is the traditional method of anycast largely considered in BCP 126 [RFC4786] and can be used for IPv4 and IPv6. "On-link anycast" is the formal support of anycast in the address resolution (duplicate address detection) protocol and is only standardized for IPv6, with the introduction of designated anycast addresses on the anycasted hosts, and the Override flag in Neighbor Discovery (ND) Neighbor Advertisements (NAs) [RFC4861]. There is no standardized mechanism for this in IPv4.
BCP 126[RFC4786]讨论了几种不同的IP选播部署模型。除该文件外，还有两个区别涉及“非链接选播”和“链接选播”。“离线选播”利用路由协议首选项和基于IP逐跳目的地的转发范例，将数据包定向到“最近”的目的地。这是BCP 126[RFC4786]中主要考虑的选播的传统方法，可用于IPv4和IPv6。“链路上选播”是地址解析（重复地址检测）协议中对选播的正式支持，仅针对IPv6标准化，在选播主机上引入指定的选播地址，并在邻居发现（ND）邻居播发（NAs）中引入覆盖标志[RFC4861]。IPv4中没有用于此的标准化机制。
As of this writing, the term "anycast" appears in 176 RFCs and 144 active Internet-Drafts. The following sections capture some of the key appearances and discussion of anycasting within the IETF over the years.
在撰写本文时，“任意广播”一词出现在176份RFC和144份活跃的互联网草稿中。以下各节介绍了近年来IETF中任意广播的一些关键表现和讨论。
The first formal specification of anycast was provided in "Host Anycasting Service" [RFC1546]. The authors of this document did a good job of capturing most of the issues that exist with IP anycast today.
“主机选播服务”[RFC1546]中提供了选播的第一个正式规范。本文的作者很好地捕获了当前IP anycast存在的大多数问题。
One of the first documented uses of anycast was in 1994 for a "Video Registry" experiment [IMR9401]. In the experiment, a UDP query was transmitted to an anycasted address to locate the topologically closest "supposedly equivalent network resource":
anycast最早被记录的用途之一是1994年的“视频注册”实验[IMR9401]。在实验中，UDP查询被传输到任意广播地址，以定位拓扑上最接近的“假定等效网络资源”：
A video resource (for example, a catalog server that lists available video clips) sends an anycast UDP datagram to locate the nearest video registry. At most one registry responds with a unicast UDP datagram containing the registry's IP address. Said resource then opens a TCP connection to that [the received registry address] address and sends a request to register itself. Every 5 minutes or so, each registry multicasts to all other registries all of the resources it knows from local registration requests. It also immediately announces newly registered resources. Remotely registered resources not heard about for 20 minutes are dropped.
视频资源（例如，列出可用视频剪辑的目录服务器）发送任意广播UDP数据报以查找最近的视频注册表。最多有一个注册表响应包含注册表IP地址的单播UDP数据报。然后，所述资源打开到该[接收的注册表地址]地址的TCP连接，并发送注册自身的请求。每5分钟左右，每个注册中心就会向所有其他注册中心多播它从本地注册请求中知道的所有资源。它还立即宣布新注册的资源。20分钟内未听到的远程注册资源将被丢弃。
There is also discussion that ISPs began using anycast for DNS resolution services around the same time, although no public references to support this are available.
也有人讨论说，ISP大约在同一时间开始为DNS解析服务使用anycast，尽管没有支持这一点的公开参考资料。
In 1997, the IAB clarified that IPv4 anycast addresses were pure "locators" and could never serve as "identifiers" of hosts or interfaces [RFC2101].
1997年，IAB澄清IPv4选播地址是纯粹的“定位器”，永远不能作为主机或接口的“标识符”[RFC2101]。
In 1998, the IAB conducted a routing workshop [RFC2902]. Of the conclusions and output action items from the report, an Anycast section is contained in Section 2.10.3. Specifically called out is the need to describe the advantages and disadvantages of anycast and the belief that local-scoped well-known anycast addresses will be useful to some applications. In the subsequent section, an action item was outlined that suggested a BOF should be held to plan work on anycast, and if a working group forms, a paper on the advantages and the disadvantages of anycast should be included as part of the charter.
1998年，IAB举办了一次路由研讨会[RFC2902]。在报告的结论和输出行动项目中，第2.10.3节包含了选播部分。特别指出的是需要描述选播的优点和缺点，以及相信本地范围内的众所周知的选播地址将对某些应用程序有用。在随后的章节中，概述了一个行动项目，该项目建议成立一个BOF来规划anycast的工作，如果成立了一个工作组，则应将一份关于anycast利弊的文件作为章程的一部分。
As a result of the recommendation in [RFC2902], an Anycast BOF [ANYCASTBOF] was held at IETF 46 in November of 1999. A number of uses for anycast were discussed. No firm conclusion was reached regarding use of TCP with anycasted services. However, it was observed that anycasting was useful for DNS, although it did introduce some new complexities. The use of global anycast was not expected to scale (see Section 4.1 below for more discussion) and, hence, was expected to be limited to a small number of key uses.
根据[RFC2902]中的建议，1999年11月在IETF 46举行了选播BOF[ANYCASTBOF]。讨论了anycast的一些用途。关于TCP在任何广播服务中的使用，没有得出明确的结论。然而，有人观察到，任意广播对于DNS是有用的，尽管它确实引入了一些新的复杂性。全球选播的使用预计不会扩大规模（更多讨论见下文第4.1节），因此预计仅限于少数关键用途。
In 2001, the Multicast and Anycast Group Membership [MAGMA] WG was chartered to address host-to-router signaling, including initial authentication and access control issues for multicast and anycast group membership, but other aspects of anycast, including architecture and routing, were outside the group's scope.
2001年，特许多播和选播组成员资格[MAGMA]工作组解决主机到路由器的信令问题，包括多播和选播组成员资格的初始身份验证和访问控制问题，但选播的其他方面，包括架构和路由，不在该组的范围之内。
Simple Network Time Protocol (SNTP) Version 4 [RFC2030] defined how to use SNTP anycast for server discovery. This was extended in [RFC4330] as an NTP-specific "manycast" service, in which anycast was used for the discovery part.
简单网络时间协议（SNTP）第4版[RFC2030]定义了如何使用SNTP选播进行服务器发现。这在[RFC4330]中作为NTP特定的“manycast”服务进行了扩展，在该服务中，发现部分使用了anycast。
IPv6 defined some reserved subnet anycast addresses [RFC2526] and assigned one to "Mobile IPv6 Home-Agents" [RFC3775] (obsoleted by [RFC6275]).
IPv6定义了一些保留子网选播地址[RFC2526]，并将其分配给“移动IPv6主代理”[RFC3775]（已被[RFC6275]淘汰）。
The original IPv6 transition mechanism [RFC2893] made use of IPv4 anycast addresses as tunnel endpoints for IPv6 encapsulated in IPv4, but this was later removed [RFC4213]. The 6to4 tunneling protocol [RFC3056] was augmented by a 6to4 relay anycast prefix [RFC3068] in a move aimed at simplifying the configuration of 6to4 routers. Incidentally, 6to4 deployment has shown a fair number of operational and security issues [RFC3964] that result from using anycast as a discovery mechanism. Specifically, one inference is that operational consideration is needed to ensure that anycast addresses get advertised and/or filtered in a way that produces the intended scope (e.g., only advertise a route for your 6to4 relay to Autonomous Systems (ASes) that conform to your own acceptable usage policy), an attribute that can easily become quite operationally expensive.
最初的IPv6转换机制[RFC2893]使用IPv4选播地址作为封装在IPv4中的IPv6的隧道端点，但后来被删除[RFC4213]。6to4隧道协议[RFC3056]通过6to4中继选播前缀[RFC3068]进行了扩充，旨在简化6to4路由器的配置。顺便说一句，6to4部署显示了大量的操作和安全问题[RFC3964]，这些问题是使用anycast作为发现机制所导致的。具体地说，一种推论是，需要考虑操作因素，以确保以产生预期范围的方式公布和/或过滤选播地址（例如，仅公布符合您自己可接受使用策略的6to4中继到自治系统（ASE）的路由），一种很容易在操作上变得非常昂贵的属性。
In 2002, DNS' use of anycast was first specified in "Distributing Authoritative Name Servers via Shared Unicast Addresses" [RFC3258]. It is notable that it used the term "shared unicast address" rather than "anycast address" for the service. This distinction was made due to the IPv6 differentiation in the on-link model. "Shared unicast" addresses are unicast (not multicast) in the IPv6 model and, therefore, support the off-link anycast model (described earlier) but not the on-link anycast model. At the same time, site-local-scoped well-known addresses began being used for recursive resolvers [DNS-DISC], but this use was never standardized (see below in Section 3.4 for more discussion).
2002年，“通过共享单播地址分发权威名称服务器”[RFC3258]中首次规定了DNS对选播的使用。值得注意的是，它对服务使用了术语“共享单播地址”而不是“选播地址”。这种区别是由于链路模型中的IPv6差异造成的。“共享单播”地址在IPv6模型中是单播（不是多播），因此，支持断开链路的选播模型（如前所述），但不支持链路上的选播模型。同时，站点本地范围的已知地址开始用于递归解析程序[DNS-DISC]，但这种使用从未标准化（更多讨论见下文第3.4节）。
Anycast was used for routing to rendezvous points (RPs) for PIM [RFC4610].
Anycast用于PIM[RFC4610]的会合点（RPs）路由。
"Operation of Anycast Services" BCP 126 [RFC4786] deals with how the routing system interacts with anycast services and the operation of anycast services.
“选播服务的操作”BCP 126[RFC4786]涉及路由系统如何与选播服务交互以及选播服务的操作。
"Requirements for a Mechanism Identifying a Name Server Instance" [RFC4892] cites the use of anycast with DNS as a motivation to identify individual name server instances, and the Name Server ID (NSID) option was defined for this purpose [RFC5001]. One could view
“对识别名称服务器实例的机制的要求”[RFC4892]引用了将anycast与DNS结合使用作为识别单个名称服务器实例的动机，并为此定义了名称服务器ID（NSID）选项[RFC5001]。可以看到
the addition of NSID as an incarnation of locator and identifier separation (where the anycast address is a locator and the NSID is an identifier).
添加NSID作为定位器和标识符分离的化身（其中选播地址是定位器，NSID是标识符）。
The IAB's "Reflections on Internet Transparency" [RFC4924] briefly mentions how violating transparency can also damage global services that use anycast.
IAB的“关于互联网透明度的思考”[RFC4924]简要提到违反透明度也会损害使用anycast的全球服务。
Originally, the IPv6 addressing architecture [RFC1884] [RFC2373] [RFC3513] severely restricted the use of anycast addresses. In particular, the architecture provided that anycast addresses must not be used as source addresses and must not be assigned to IPv6 hosts (i.e., only routers). These restrictions were later lifted in 2006 [RFC4291].
最初，IPv6寻址体系结构[RFC1884][RFC2373][RFC3513]严格限制了选播地址的使用。特别是，该体系结构规定，选播地址不得用作源地址，也不得分配给IPv6主机（即，仅路由器）。这些限制后来在2006年被取消[RFC4291]。
In fact, the more recent "IPv6 Transition/Co-existence Security Considerations" [RFC4942] overview now recommends:
事实上，最近的“IPv6过渡/共存安全注意事项”[RFC4942]概述现在建议：
To avoid exposing knowledge about the internal structure of the network, it is recommended that anycast servers now take advantage of the ability to return responses with the anycast address as the source address if possible.
为了避免暴露有关网络内部结构的知识，建议选播服务器现在利用以选播地址作为源地址返回响应的能力（如果可能）。
As discussed in the Overview, "on-link anycast" is employed expressly in IPv6 via ND NAs; see Section 7.2.7 of [RFC4861] for additional information.
如概述中所述，“链路上选播”在IPv6中通过ND NAs明确使用；更多信息，请参见[RFC4861]第7.2.7节。
"Distributed Authoritative Name Servers via Shared Unicast Addresses" [RFC3258] described how to reach authoritative name servers using multiple unicast addresses, each one configured on a different set of servers. It stated in Section 2.3:
“通过共享单播地址的分布式权威名称服务器”[RFC3258]描述了如何使用多个单播地址访问权威名称服务器，每个地址配置在不同的服务器集上。第2.3节中规定：
This document presumes that the usual DNS failover methods are the only ones used to ensure reachability of the data for clients. It does not advise that the routes be withdrawn in the case of failure; it advises instead that the DNS process shutdown so that servers on other addresses are queried. This recommendation reflects a choice between performance and operational complexity. While it would be possible to have some process withdraw the route for a specific server instance when it is not available, there is considerable operational complexity involved in ensuring that this occurs reliably. Given the existing DNS failover methods, the marginal improvement in performance will not be sufficient to justify the additional complexity for most uses.
本文档假定通常的DNS故障切换方法是唯一用于确保客户端数据可访问性的方法。它不建议在发生故障时撤回路线；相反，它建议DNS进程关闭，以便查询其他地址上的服务器。本建议反映了性能和操作复杂性之间的选择。虽然可以让某些进程在特定服务器实例不可用时为其撤消路由，但要确保可靠地执行此操作，需要相当复杂的操作。考虑到现有的DNS故障切换方法，性能上的微小改进不足以证明大多数应用的额外复杂性。
In anycast more generally, most anycast benefits cannot be realized without route withdrawals, since traffic will continue to be directed to the link with the failed server. When multiple unicast addresses are used with different sets of servers, a client can still fail over to using a different server address and, hence, a different set of servers. There can still be reliability problems, however, when each set contains a failed server. If all servers in the same set are on the same subnet, such problems could be minimized where address resolution within the subnet will cause traffic to go to an available server.
在anycast中，更一般地说，大多数anycast的好处在没有路由撤回的情况下是无法实现的，因为通信量将继续定向到与故障服务器的链路。当多个单播地址用于不同的服务器集时，客户端仍然可以故障转移到使用不同的服务器地址，从而使用不同的服务器集。但是，当每个集合包含一个发生故障的服务器时，仍然可能存在可靠性问题。如果同一组中的所有服务器都位于同一子网上，则可以将此类问题降至最低，因为子网上的地址解析将导致流量流向可用的服务器。
Other assertions included:
其他断言包括：
o It asserted (as an advantage) that no routing changes were needed.
o 它断言（作为优势）不需要更改路由。
o It recommended stopping DNS processes rather than withdrawing routes to deal with failures, data synchronization issues, and failover, as provided in the quoted text above. The spirit of this advice was that DNS resolvers may (indeed) reach out and query unavailable DNS name servers, but as their queries time out, they will elect to pin themselves to other server addresses and, hence, different servers.
o 它建议停止DNS进程，而不是像上面引用的文本中所提供的那样撤消路由以处理故障、数据同步问题和故障转移。该建议的精神是DNS解析程序可能（实际上）接触并查询不可用的DNS名称服务器，但随着查询超时，他们将选择将自己锁定到其他服务器地址，从而锁定到不同的服务器。
o It argued that failure modes involving state were not serious, because:
o 它认为涉及状态的故障模式并不严重，因为：
* the vast majority of DNS queries are UDP
* 绝大多数DNS查询都是UDP查询
* large routing metric disparity among authoritative server instances would localize queries to a single instance for most clients
* 权威服务器实例之间存在较大的路由度量差异，这将使大多数客户端的查询局限于单个实例
* when the resolver tries TCP and it breaks, the resolver will try to move to a different server address. In order to ensure that this is possible, it is important that the DNS zone be configured with multiple server addresses for different sets of name servers. The advice given in Section 3.3 of [DNS-DISC] describes, in more detail, why using multiple addresses is important.
* 当冲突解决程序尝试TCP并中断时，冲突解决程序将尝试移动到其他服务器地址。为了确保这是可能的，必须为DNS区域配置不同名称服务器集的多个服务器地址。[DNS-DISC]第3.3节中给出的建议更详细地描述了为什么使用多个地址很重要。
"Unique Per-Node Origin ASNs for Globally Anycasted Services" [RFC6382] makes recommendations regarding the use of per-node unique origin Autonomous System Numbers (ASNs) for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. The object was to allow network management and monitoring techniques, or other operational
“全球任意广播服务的唯一每节点源ASN”[RFC6382]就全球任意广播关键基础设施服务使用每节点唯一源自主系统号（ASN）提出建议，以便为给定任意广播前缀提供路由系统鉴别器。其目的是允许使用网络管理和监控技术，或其他操作系统
mechanisms to employ this new origin AS as a discriminator in whatever manner fits their operating environment, either for detection or policy associated with a given anycasted node.
以适合其操作环境的任何方式将此新来源用作鉴别器的机制，用于与给定选播节点关联的检测或策略。
"Operation of Anycast Services" BCP 126 [RFC4786] was a product of the IETF's GROW working group. The primary design constraint considered was that routing "be stable" for significantly longer than a "transaction time", where "transaction time" is loosely defined as "a single interaction between a single client and a single server". It takes no position on what applications are suitable candidates for anycast usage.
“任意广播服务的运行”BCP 126[RFC4786]是IETF成长工作组的产品。考虑的主要设计约束是路由“稳定”的时间明显长于“事务时间”，其中“事务时间”被松散地定义为“单个客户端和单个服务器之间的单个交互”。它不确定哪些应用程序适合任播使用。
Furthermore, it views anycast service disruptions as an operational problem: "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".
此外，它将选播服务中断视为一个操作问题：“运营商应该意识到，特别是对于长时间运行的流，使用选播的潜在故障模式比使用单播的简单“无法到达目的地”故障更为复杂”。
The document primarily deals with global Internet-wide services provided by anycast. Where internal topology issues are discussed, they're mostly regarding routing implications rather than application design implications. BCP 126 also views networks employing per-packet load balancing on equal cost paths as "pathological". This was also discussed in [RFC2991].
本文件主要涉及anycast提供的全球互联网范围的服务。在讨论内部拓扑问题时，它们主要涉及路由问题，而不是应用程序设计问题。BCP 126还将在等成本路径上采用每包负载平衡的网络视为“病态的”。[RFC2991]中也讨论了这一点。
Preserving the integrity of a modular layered design for IP protocols on the Internet is critical to its continued success and flexibility. One such consideration is that of whether an application should have to adapt to changes in the routing system.
保持互联网上IP协议模块化分层设计的完整性对于其持续成功和灵活性至关重要。其中一个考虑因素是应用程序是否必须适应路由系统中的变化。
Applications should make minimal assumptions about routing stability, just as they should make minimal assumptions about congestion and packet loss. When designing applications, it would perhaps be safe to assume that the routing system may deliver each anycast packet to a different service instance, in any pattern, with temporal reordering being a not-so-rare phenomenon.
应用程序应该对路由稳定性做出最小的假设，就像它们应该对拥塞和数据包丢失做出最小的假设一样。在设计应用程序时，可以安全地假设路由系统可以以任何模式将每个选播数据包交付给不同的服务实例，时间重新排序是一种并不罕见的现象。
Most stateful transport protocols (e.g., TCP), without modification, do not understand the properties of anycast; hence, they will fail probabilistically, but possibly catastrophically, when using anycast addresses in the presence of "normal" routing dynamics. Specifically, if datagrams associated with a given active transaction
大多数有状态传输协议（如TCP）未经修改，不了解选播的属性；因此，当在存在“正常”路由动态的情况下使用选播地址时，它们可能会失败，但可能是灾难性的。具体来说，如果与给定活动事务关联的数据报
are routed to a new anycasted end system and that end system lacks state data associated with the active transaction, the session will be reset; hence, it will need to be reinitiated. As another example, different networks have different routing properties and therefore will experience problems under different conditions. This can lead to a protocol working fine in, say, a test lab but not in the global Internet.
被路由到新的选播终端系统，并且该终端系统缺少与活动事务相关的状态数据，会话将被重置；因此，它需要重新初始化。另一个例子是，不同的网络具有不同的路由属性，因此在不同的条件下会遇到问题。这可能导致协议在测试实验室中正常工作，但在全球互联网中却无法正常工作。
When an anycast address is used as a destination address, different packets with the same destination IP address may reach different destination hosts, even if the packets are generated by the same source host. Anycast addresses are thus "safe" to use as destination addresses for an application if the following design points are all met:
当选播地址用作目的地地址时，具有相同目的地IP地址的不同数据包可能到达不同的目的地主机，即使这些数据包是由相同的源主机生成的。因此，如果满足以下设计点，则选播地址可以“安全”地用作应用程序的目标地址：
o A request message or "one shot" message is self-contained in a single transport packet.
o 请求消息或“一次性”消息自包含在单个传输包中。
o A stateless transport (e.g., UDP) is used for the above.
o 无状态传输（如UDP）用于上述目的。
o Replies are always sent to a unicast address; these can be multipacket since the unicast destination is presumed to be associated with a single "stable" end system and not an anycasted source address. Note that this constrains the use of anycast as source addresses in request messages, since reply messages sent back to that address may reach a device that was not the source that initially triggered it.
o 回复总是发送到单播地址；这些可以是多数据包，因为单播目的地被假定与单个“稳定”终端系统相关联，而不是任意广播的源地址。请注意，这限制了在请求消息中使用anycast作为源地址，因为发送回该地址的回复消息可能到达最初触发该地址的源以外的设备。
o The server side of the application keeps no hard state across requests.
o 应用程序的服务器端在请求之间不保持硬状态。
o Retries are idempotent; in addition to not assuming server state, they do not encode any assumptions about loss of requests versus loss of replies.
o 重试次数是幂等的；除了不假设服务器状态外，它们也不编码任何关于请求丢失与回复丢失的假设。
It is noteworthy, though, that even under the above circumstances ICMP messages against packets with anycast source addresses may be routed to servers other than those expected. In addition, Path Maximum Transmission Unit Discovery (PMTUD) can encounter complications when employed against anycast addresses, since iterations in the PMTU discovery process may have packets routed to different anycast service instances.
然而，值得注意的是，即使在上述情况下，针对具有选播源地址的数据包的ICMP消息也可能路由到预期之外的服务器。此外，路径最大传输单元发现（PMTUD）在针对选播地址使用时可能会遇到复杂问题，因为PMTU发现过程中的迭代可能会将数据包路由到不同的选播服务实例。
When an anycast address is used as a source address, the source address does not uniquely identify the source host; hence, replies might be sent to a different host. As noted earlier, this concept is sometimes referred to (e.g., in [RFC3258]) as a "shared unicast address". Anycast addresses are "safe" to use as source addresses for an application if all of the following design points are met:
当选播地址用作源地址时，源地址不唯一标识源主机；因此，可能会将答复发送到其他主机。如前所述，该概念有时被称为“共享单播地址”（例如，[RFC3258]）。如果满足以下所有设计点，则选播地址可以“安全”用作应用程序的源地址：
o No response message is generated by the receiver with the anycast source used as a destination unless the application has some private state synchronization that allows for the response message arriving at a different instance.
o 除非应用程序具有允许响应消息到达不同实例的私有状态同步，否则接收端不会生成任何响应消息，并将选播源用作目的地。
o The source anycast address is reachable via the interface address if unicast reverse path forwarding (RPF) [RFC4778] checking is on, or the service address is explicitly provisioned to bypass RPF checks. In addition to the application defined in [RFC4778], Section 4.4.5 of BCP 126 [RFC4786] gives explicit consideration to RPF checks in anycasting operations.
o 如果启用了单播反向路径转发（RPF）[RFC4778]检查，或者明确设置了服务地址以绕过RPF检查，则可以通过接口地址访问源选播地址。除了[RFC4778]中定义的应用外，BCP 126[RFC4786]第4.4.5节明确考虑了选播操作中的RPF检查。
Applications able to tolerate an extra round-trip time (RTT) to learn a unicast destination address for multipacket exchanges might safely use anycast destination addresses for service instance discovery. For example, "instance discovery" messages are sent to an anycast destination address, and a reply is subsequently sent from the unique unicast source address of the interface that received the discovery message, or a reply is sent from the anycast source address of the interface that received the message, containing the unicast address to be used to invoke the service. Only the latter of these will avoid potential NAT binding and stateful firewall issues.
能够容忍额外的往返时间（RTT）来学习多数据包交换的单播目的地地址的应用程序可以安全地使用选播目的地地址进行服务实例发现。例如，“实例发现”消息被发送到选播目标地址，并且随后从接收到发现消息的接口的唯一单播源地址发送应答，或者从接收到消息的接口的选播源地址发送应答，包含用于调用服务的单播地址。只有后者才能避免潜在的NAT绑定和有状态防火墙问题。
[DNS-DISC] discussed several options to address the need to configure DNS servers, including the use of a "Well-known Anycast Address" for recursive DNS service configuration in clients to ease configuration and allow those systems to ship with these well-known addresses configured "from the beginning, as, say, factory default". The proposal was later dropped, but the analysis was used in publishing [RFC4339].
[DNS-DISC]讨论了几种解决DNS服务器配置需求的选项，包括在客户端递归DNS服务配置中使用“众所周知的选播地址”，以简化配置，并允许这些系统“从一开始就配置这些众所周知的地址，如出厂默认值”。该提案后来被撤销，但该分析被用于出版[RFC4339]。
After the final round of revisions to [DNS-DISC] was made, [RFC4339] was published with a very similar focus and overlapping content. The difference was that the writing in [RFC4339] focused on analysis, while [DNS-DISC] covered both the analysis and a specific proposal. The proposal details were removed in what became [RFC4339] although Section 3.3 of that RFC still discusses the approach of using a
在对[DNS-DISC]进行最后一轮修订后，[RFC4339]以非常相似的焦点和重叠的内容发布。不同之处在于，[RFC4339]中的文字侧重于分析，而[DNS-DISC]涵盖了分析和具体提案。虽然RFC第3.3节仍然讨论了使用
well-known anycast address in this scenario. During publication, the IESG requested that the following "IESG Note" be contained in the document:
此场景中的著名选播地址。在出版过程中，IESG要求在文件中包含以下“IESG注释”：
This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts.
本文档描述了在IPv6主机中配置DNS名称解析服务器信息的三种不同方法。
There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus.
对于首选哪种方法，IETF没有一致意见。本文件中的分析由每种方法的支持者制定，并不代表IETF共识。
The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future.
本文件中描述的“RA选项”和“众所周知的选播”方法未标准化。因此，对这些方法的分析可能不完全适用于将来可能提出的任何具体提案。
Widespread use of anycast for global Internet-wide services or inter-domain services has some scaling challenges. Similar in ways to multicast, each service generates at least one unique route in the global BGP routing system. As a result, additional anycast instances result in additional paths for a given prefix, which scales super-linearly as a function of denseness of inter-domain interconnection within the routing system (i.e., more paths result in more resources, more network interconnections result in more paths).
在全球互联网范围服务或域间服务中广泛使用anycast会带来一些扩展挑战。与多播方式类似，每个服务在全局BGP路由系统中至少生成一个唯一路由。结果，额外的选播实例导致给定前缀的额外路径，其作为路由系统内域间互连的密度的函数超线性扩展（即，更多路径导致更多资源，更多网络互连导致更多路径）。
This is why the Anycast BOF concluded that "the use of global anycast addresses was not expected to scale and hence was expected to be limited to a small number of key uses".
这就是为什么选播BOF得出结论，“全球选播地址的使用预计不会扩大，因此预计仅限于少数关键用途”。
However, one interesting note is that multiple anycast services can share a route if they are all located in a single announced prefix and if all the servers of all the services are always collocated. If the announced prefix is aggregated differently in different locations though, longest-match routing might result in some anycast locations being unreachable. Hence, extra precaution must be taken when aggregating prefixes used by anycast services.
然而，一个有趣的注意事项是，如果多个选播服务都位于一个宣布的前缀中，并且如果所有服务的所有服务器总是并置，则多个选播服务可以共享一条路由。但是，如果宣布的前缀在不同的位置聚合不同，则最长匹配路由可能会导致无法访问某些选播位置。因此，在聚合选播服务使用的前缀时，必须采取额外的预防措施。
UDP is the "lingua franca" for anycast today. Stateful transports could be enhanced to be more anycast friendly. This was anticipated in Host Anycasting Services [RFC1546], specifically:
UDP是今天anycast的“通用语言”。有状态传输可以得到增强，使其更为选播友好。这在主机选播服务[RFC1546]中是预期的，具体来说：
The solution to this problem is to only permit anycast addresses as the remote address of a TCP SYN segment (without the ACK bit set). A TCP can then initiate a connection to an anycast address. When the SYN-ACK is sent back by the host that received the anycast segment, the initiating TCP should replace the anycast address of its peer, with the address of the host returning the SYN-ACK. (The initiating TCP can recognize the connection for which the SYN-ACK is destined by treating the anycast address as a wildcard address, which matches any incoming SYN-ACK segment with the correct destination port and address and source port, provided the SYN-ACK's full address, including source address, does not match another connection and the sequence numbers in the SYN-ACK are correct.) This approach ensures that a TCP, after receiving the SYN-ACK is always communicating with only one host.
这个问题的解决方案是只允许选播地址作为TCP SYN段的远程地址（不设置ACK位）。然后，TCP可以启动到选播地址的连接。当接收到选播段的主机发回SYN-ACK时，启动TCP应使用返回SYN-ACK的主机的地址替换其对等方的选播地址。（如果SYN-ACK的完整地址（包括源地址）与另一个连接不匹配，则发起TCP可以通过将选播地址视为通配符地址来识别SYN-ACK的目的地连接，该通配符地址将任何传入的SYN-ACK段与正确的目标端口、地址和源端口相匹配SYN-ACK中的序列号正确。）此方法确保TCP在接收到SYN-ACK后始终仅与一台主机通信。
The reason for such considerations can be illustrated through an example: one operationally observed shortcoming of using the Transmission Control Protocol (TCP) [RFC0793] and anycast nodes in DNS is that even during the TCP connection establishment, IP control packets from a DNS client may initially be routed to one anycast instance, but subsequent IP packets may be delivered to a different anycast instance if (for example) a route has changed. In such a case, the TCP connection will likely elicit a connection reset but will certainly result in the disruption of the connection.
这种考虑的原因可以通过一个例子来说明：在DNS中使用传输控制协议（TCP）[RFC0793]和选播节点的一个操作上观察到的缺点是，即使在TCP连接建立期间，来自DNS客户端的IP控制包最初也可以路由到一个选播实例，但是，如果（例如）路由已经改变，则随后的IP分组可以被传送到不同的选播实例。在这种情况下，TCP连接可能会导致连接重置，但肯定会导致连接中断。
Multi-address transports (e.g., SCTP) might be more amenable to such extensions than TCP.
多地址传输（例如，SCTP）可能比TCP更适合这种扩展。
The features needed for address discovery when doing multihoming in the transport layer are similar to those needed to support anycast.
在传输层中进行多宿主时，地址发现所需的功能与支持选播所需的功能类似。
Middleboxes (e.g., NATs) and stateful firewalls cause problems when used in conjunction with some ways to use anycast. In particular, a server-side transition from an anycast source IP address to a unique unicast address may require new or additional session state, and this may not exist in the middlebox, as discussed previously in Section 3.4.
当与某些使用anycast的方法结合使用时，中间盒（如NAT）和有状态防火墙会导致问题。特别是，从选播源IP地址到唯一单播地址的服务器端转换可能需要新的或额外的会话状态，而这可能不存在于中间盒中，如前面第3.4节所述。
Anycast is often deployed to mitigate or at least localize the effects of distributed denial-of-service (DDoS) attacks. For example, with the Netgear NTP fiasco [RFC4085] anycast was used in a distributed sinkhole model [RFC3882] to mitigate the effects of embedded globally routed Internet addresses in network elements.
Anycast通常用于减轻或至少本地化分布式拒绝服务（DDoS）攻击的影响。例如，随着Netgear NTP的失败[RFC4085]，在分布式天坑模型[RFC3882]中使用了任意广播，以减轻网络元件中嵌入的全局路由互联网地址的影响。
"Internet Denial-of-Service Considerations" [RFC4732] notes that: "A number of the root nameservers have since been replicated using anycast to further improve their resistance to DoS".
“Internet拒绝服务注意事项”[RFC4732]指出：“此后，使用anycast复制了许多根名称服务器，以进一步提高它们对DoS的抵抗力”。
"Operation of Anycast Services" BCP 126 [RFC4786] cites DoS mitigation, constraining DoS to localized regions, and identifying attack sources using spoofed addresses as some motivations to deploy services using anycast. Multiple anycast service instances such as those used by the root name servers also add resiliency when network partitioning occurs (e.g., as the result of transoceanic fiber cuts or natural disasters).
“任意广播服务的操作”BCP 126[RFC4786]引用了DoS缓解、将DoS限制在本地化区域以及使用伪造地址识别攻击源作为使用任意广播部署服务的一些动机。多个选播服务实例（如根名称服务器使用的实例）也会在发生网络分区时（例如，由于越洋光纤中断或自然灾害）增加恢复能力。
When using anycast, care must be taken not to simply withdraw an anycast route in the presence of a sustained DoS attack, since the result would simply move the attack to another service instance, potentially causing a cascaded failure. Anycast adds resiliency when such an attack is instead constrained to a single service instance.
在使用选播时，必须注意不要在持续的DoS攻击存在的情况下简单地撤回选播路由，因为结果只会将攻击转移到另一个服务实例，从而可能导致级联故障。当此类攻击被约束到单个服务实例时，Anycast增加了恢复能力。
It should be noted that there is a significant man-in-the-middle (MITM) exposure in either variant of anycast discovery (see Section 3.4) that, in many applications, may necessitate the need for end-to-end security models (e.g., using IPsec [RFC6071] or even DNSSEC [RFC4033]) that enable end systems to authenticate one another, or the data itself.
应该注意的是，在任意广播发现的任何一种变体（见第3.4节）中都存在一个重要的中间人（MITM）风险，在许多应用中，可能需要端到端安全模型（例如，使用IPsec[RFC6071]甚至DNSSEC[RFC4033]），以使端系统能够相互验证或验证数据本身。
However, when considering the above suggestion of enabling end systems to authenticate each other, a potential complication can arise. If the service nodes of an anycast deployment are administered by separate authorities, any server-side authentication credentials that are used must (necessarily) be shared across the administrative boundaries in the anycast deployment. This would likely also be the case with Secure Neighbor Discovery, described in [RFC5909].
然而，当考虑到上述使终端系统能够相互认证的建议时，可能会出现潜在的复杂性。如果选播部署的服务节点由单独的机构管理，则所使用的任何服务器端身份验证凭据必须（必要）在选播部署中跨管理边界共享。[RFC5909]中描述的安全邻居发现也可能是这种情况。
Furthermore, as discussed earlier in this document, operational consideration needs to be given to ensure that anycast addresses get advertised and/or filtered in a way that produces intended scope (for example, only advertise a route to your 6to4 relay to ASes that conform to your own Acceptable Use Policy (AUP)). This seems to be operationally expensive, and is often vulnerable to errors outside of the local routing domain, in particular when anycasted services are deployed with the intent to scope associated announcements within some local or regional boundary.
此外，如本文件前面所述，需要考虑运营问题，以确保以产生预期范围的方式公布和/或过滤选播地址（例如，仅公布到符合您自己的可接受使用策略（AUP）的ASE的6to4中继的路由）。这在操作上似乎很昂贵，并且经常容易受到本地路由域之外的错误的影响，特别是当部署anycasted服务的目的是在某些本地或区域边界内范围相关的公告时。
As previously discussed, [RFC6382] makes recommendations regarding the use of per-node unique origin ASNs for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and
如前所述，[RFC6382]建议在全球选播关键基础设施服务中使用每节点唯一源ASN，以便为给定的选播前缀提供路由系统鉴别器。网络管理与应用
monitoring techniques, or other operational mechanisms, may then employ this new discriminator in whatever manner fits their operating environment, for either detection or policy associated with a given anycasted node.
然后，监控技术或其他操作机制可以以适合其操作环境的任何方式使用这种新的鉴别器，用于与给定任意广播节点相关联的检测或策略。
Moreover, the use of per-node unique origin ASNs has the additional benefit of overcoming complications that might arise with the potential deployment of the Resource Public Key Infrastructure (RPKI) [RFC6480]. Without per-node unique origin ASNs, the cryptographic certificates needed to attest to the Route Origin Authorizations (ROAs) of a multi-administrative deployment of anycast would need to be shared. However, if each service instance has a separate ASN, then those ASNs can be managed separately in the RPKI.
此外，使用每节点唯一源ASN还具有克服资源公钥基础设施（RPKI）的潜在部署可能带来的复杂性的额外好处[RFC6480]。如果没有每个节点唯一的源ASN，则需要共享用于证明anycast的多管理部署的路由源授权（ROA）的加密证书。但是，如果每个服务实例都有一个单独的ASN，那么这些ASN可以在RPKI中单独管理。
Unlike multicast (but like unicast), anycast allows traffic stealing. That is, with multicast, joining a multicast group doesn't prevent anyone else who was receiving the traffic from continuing to receive the traffic. With anycast, adding an anycasted node to the routing system can prevent a previous recipient from continuing to receive traffic because it may now be delivered to the new node instead. As such, if an unauthorized anycast node can inject a route into the network, or be resolved using ARP/Neighbor Discovery on a link with an authorized anycast node, traffic can be diverted thereby triggering DoS or other attacks. Section 6.3 of BCP 126 [RFC4786] provides expanded discussion on "Service Hijacking" and "traffic stealing", and [FanInfocom13] discusses measured instances of anycast nodes and "benign masquerading or hostile hijacking of anycast services", by unauthorized nodes.
与多播不同（但与单播类似），anycast允许流量窃取。也就是说，对于多播，加入多播组不会阻止接收流量的其他任何人继续接收流量。使用anycast，将anycasted节点添加到路由系统可以防止以前的接收者继续接收流量，因为它现在可能会被传递到新节点。因此，如果未经授权的选播节点可以将路由注入网络，或者在与经授权的选播节点的链路上使用ARP/邻居发现来解决，则可以转移流量，从而触发DoS或其他攻击。BCP 126[RFC4786]第6.3节对“服务劫持”和“流量盗窃”进行了扩展讨论，[FanInfocom13]讨论了任意广播节点的测量实例和未经授权节点对任意广播服务的“良性伪装或恶意劫持”。
Unlike unicast (but like multicast), the desire is to allow applications to cause route injection. In multicast, one often allows arbitrary applications on hosts to join multicast groups, resulting in multicast routing state. Trying to apply that same model to anycast would present new security concerns, which is why [MAGMA] only got so far. The security concerns include:
与单播不同（但与多播类似），其目的是允许应用程序引起路由注入。在多播中，通常允许主机上的任意应用程序加入多播组，从而导致多播路由状态。尝试将同样的模型应用到anycast会带来新的安全问题，这就是为什么[MAGMA]才走到这一步的原因。安全问题包括：
1. Allowing route injection can cause DOS to a legitimate address owner.
1. 允许路由注入可能会导致对合法地址所有者的拒绝。
2. Allowing route injection consumes routing resources and can hence cause DOS to the routing system and impact legitimate communications as a result.
2. 允许路由注入会消耗路由资源，因此会导致路由系统拒绝服务，从而影响合法通信。
These are two of the core issues that were part of the discussion during [RFC1884], the [ANYCASTBOF], and the MAGMA [MAGMA] chartering.
这是[RFC1884]、[ANYCASTBOF]和岩浆[MAGMA]租船期间讨论的两个核心问题。
Additional security considerations are scattered throughout the list of references provided herein.
其他安全注意事项分散在本文提供的参考文献列表中。
BCP 126 [RFC4786] provides some very solid guidance related to operations of anycasted services and, in particular, the operations of DNS.
BCP 126[RFC4786]提供了一些与任意广播服务的操作相关的非常可靠的指导，特别是DNS的操作。
This document covers issues associated with the architectural implications of anycast. This document does not address, in any depth, the fact that there are deployed services with TCP transport using anycast today. Evidence exists to suggest that such practice is not "safe" in the traditional and architectural sense (as described in Section 4.2). These sorts of issues are indeed relative, and we recognize sometimes unpredictability in the routing system beyond the local administrative domain can be manageable. That is, despite the inherent architectural problems in the use of anycast with stateful transport and connection-oriented protocols, there is expanding deployment (e.g., for content distribution networks) and situations exist where it may make sense (e.g., such as with service discovery, short-lived transactions, or in cases where dynamically directing traffic to topologically optimal service instances is required). In general, operators should consider the content and references provided herein and evaluate the benefits and implications of anycast in their specific environments and applications.
本文档涵盖了与anycast的架构含义相关的问题。本文档没有深入讨论目前使用anycast的TCP传输已部署服务这一事实。有证据表明，这种做法在传统和建筑意义上并不“安全”（如第4.2节所述）。这类问题确实是相对的，我们认识到，有时路由系统中的不可预测性超出了本地管理域是可以管理的。也就是说，尽管在使用有状态传输和面向连接的协议时存在固有的体系结构问题，但仍存在不断扩展的部署（例如，对于内容分发网络）和可能有意义的情况（例如，使用服务发现、短期事务，或在需要将流量动态定向到拓扑优化服务实例的情况下）一般而言，操作员应考虑本文提供的内容和引用，并评估选播在其特定环境和应用中的益处和影响。
In addition, (as noted in Section 2.3) the issue of whether to withdraw anycast routes when there is a service failure is only briefly broached in [RFC3258]. The advice given is that routes should not be withdrawn, in order to reduce operational complexity. However, the issue of route advertisements and service outages deserves greater attention.
此外，（如第2.3节所述，[RFC3258]中仅简要讨论了在出现服务故障时是否撤回选播路由的问题。给出的建议是，不应撤销路线，以降低运营复杂性。然而，路线广告和服务中断问题值得更多关注。
There is an inherent trade-off that exists between the operational complexity of matching service outages with anycast route withdrawals, and allowing anycast routes to persist for services that are no longer available. [RFC3258] maintains that DNS' inherent failure recovery mechanism is sufficient to overcome failed nodes, but even this advice enshrines the notion that these decisions are both application-specific and subject to the operational needs of each deployment. For example, the routing system plays a larger role in DNS when services are anycast. Therefore, operational consideration must be given to the fact that relying on anycast for DNS deployment optimizations means that there are operational trade-offs related to keeping route advertisements (and withdrawals) symmetric with service availability. For example, in order to ensure that the DNS resolvers in a failed anycast instance's catchment [RFC4786] are able to fail over and reach a non-failed catchment, a route withdrawal is almost certainly required. On the other hand,
在将服务中断与选播路由撤回相匹配的操作复杂性与允许选播路由为不再可用的服务保留之间存在一种内在的权衡。[RFC3258]认为DNS固有的故障恢复机制足以克服故障节点，但即使是这一建议也包含了这样一个概念，即这些决策都是特定于应用程序的，并且取决于每个部署的操作需要。例如，当服务是选播时，路由系统在DNS中扮演更大的角色。因此，运营方面必须考虑到这样一个事实，即依赖anycast进行DNS部署优化意味着存在与保持路由播发（和撤回）与服务可用性对称相关的运营权衡。例如，为了确保故障选播实例的集水区[RFC4786]中的DNS解析程序能够故障转移并到达非故障集水区，几乎肯定需要路由撤回。另一方面
instability of a DNS process that triggers frequent route advertisement and withdrawal might result in suppression of legitimate paths to available nodes, e.g., as a result of route flap damping [RFC2439].
DNS进程的不稳定性会触发频繁的路由公告和退出，这可能会导致抑制到可用节点的合法路径，例如，由于路由抖动阻尼[RFC2439]。
Rather than prescribing advice that attempts to befit all situations, it should simply be recognized that when using anycast with network services that provide redundancy or resilience capabilities at other layers of the protocol stack, operators should carefully consider the optimal layer(s) at which to provide said functions.
与其规定试图满足所有情况的建议，不如简单地认识到，当在网络协议栈的其他层中使用提供冗余或恢复能力的网络服务时，运营商应仔细考虑提供所述功能的最佳层。
As noted in Section 2.3, use of anycast within a subnet does not necessarily suffer from the potential issues with route withdrawals. As such, use of anycast to reach servers that reside in the same subnet can be made more reliable than use of anycast to reach topologically disparate server instances. Within a subnet, however, care must be taken as stated in Section 5.4 of [RFC4862], "Duplicate Address Detection MUST NOT be performed on anycast addresses"; hence, the servers must be configured appropriately.
如第2.3节所述，在子网内使用选播不一定会遇到路由撤回的潜在问题。因此，使用anycast访问驻留在同一子网中的服务器比使用anycast访问拓扑上不同的服务器实例更可靠。但是，在子网内，必须注意[RFC4862]第5.4节中所述的“不得对选播地址执行重复地址检测”；因此，必须正确配置服务器。
In summary, operators and application vendors alike should consider the benefits and implications of anycast in their specific environments and applications and also give forward consideration to how new network protocols and application functions may take advantage of anycast or how they may be negatively impacted if anycasting is employed.
总而言之，运营商和应用供应商都应该考虑在其特定环境和应用中的任播的好处和影响，并且还考虑新的网络协议和应用功能如何利用选播，或者如果采用任何播播，它们可能受到负面影响。
Many thanks to Kurtis Lindqvist for his early review and feedback on this document. Thanks to Brian Carpenter, Alfred Hoenes, and Joe Abley for their usual careful review and feedback, as well as Mark Smith, Lixia Zhang, Stephane Bortzmeyer, Masataka Ohta, and S. Moonesamy for their detailed reviews. Helpful feedback was also received from others including Edward Lewis, Jean-Michel Combes, Wolfgang Nagele, Mark Townsley, and Abdussalam Baryun.
非常感谢Kurtis Lindqvist对本文件的早期审查和反馈。感谢Brian Carpenter、Alfred Hoenes和Joe Abley通常进行的仔细审查和反馈，以及Mark Smith、Lixia Zhang、Stephane Bortzmeyer、Masataka Ohta和S.Moonesamy的详细审查。其他人也提供了有益的反馈，包括爱德华·刘易斯、让·米歇尔·库姆斯、沃尔夫冈·纳格尔、马克·汤斯利和阿卜杜萨兰国的巴伦。
[ANYCASTBOF] Deering, S., "IAB Anycast BOF Announcement", October 1999, <http://www.ietf.org/mail-archive/web/ietf/current/ msg11182.html>.
[ANYCASTBOF]Deering，S.，“IAB Anycast BOF公告”，1999年10月<http://www.ietf.org/mail-archive/web/ietf/current/ msg1182.html>。
[DNS-DISC] Durand, A., Hagino, J., and D. Thaler, "Well known site local unicast addresses for DNS resolver", Work in Progress, September 2002.
[DNS-DISC]Durand，A.，Hagino，J.，和D.Thaler，“DNS解析程序的知名站点本地单播地址”，正在进行的工作，2002年9月。
[FanInfocom13] Fan, X., Heidemann, J., and R. Govindan, "Evaluating Anycast in the Domain Name System", Proceedings of the IEEE Infocom 2013, April 2013.
[FanInfocom13]Fan，X.，Heidemann，J.，和R.Govindan，“评估域名系统中的任意广播”，IEEE Infocom 2013年会议记录，2013年4月。
[IMR9401] RFC Editor, "INTERNET MONTHLY REPORT", January 1994, <ftp://ftp.rfc-editor.org/in-notes/museum/imr/ imr9401.txt>.
[IMR9401]RFC编辑，“互联网月报”，1994年1月<ftp://ftp.rfc-editor.org/in-notes/museum/imr/ imr9401.txt>。
[MAGMA] MAGMA (concluded), "Multicast and Anycast Group Membership (MAGMA)", April 2006, <http://www.ietf.org/wg/concluded/magma>.
[MAGMA]MAGMA（总结），“多播和选播组成员资格（MAGMA）”，2006年4月<http://www.ietf.org/wg/concluded/magma>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1884]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 18841995年12月。
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101]Carpenter，B.，Crowcroft，J.，和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[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月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 2893，2000年8月。
[RFC2902] Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.
[RFC2902]Deering，S.，Hares，S.，Perkins，C.，和R.Perlman，“1998年IAB路由研讨会概述”，RFC 2902，2000年8月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 29912000年11月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3258]Hardie，T.，“通过共享单播地址分发权威名称服务器”，RFC 3258，2002年4月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[RFC3882]Turk，D.，“配置BGP以阻止拒绝服务攻击”，RFC 3882，2004年9月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
[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月。
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, June 2005.
[RFC4085]Plonka，D.，“嵌入被认为有害的全球可路由互联网地址”，BCP 105，RFC 4085，2005年6月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[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月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339]Jeong，J.，“DNS服务器信息方法的IPv6主机配置”，RFC 4339，2006年2月。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610]Farinaci，D.和Y.Cai，“使用协议独立多播（PIM）的任意广播RP”，RFC 46102006年8月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007.
[RFC4778]Kaeo，M.，“互联网服务提供商环境中的运营安全当前实践”，RFC 4778，2007年1月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，2006年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism Identifying a Name Server Instance", RFC 4892, June 2007.
[RFC4892]Woolf，S.和D.Conrad，“识别名称服务器实例的机制要求”，RFC 48922007年6月。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924]Aboba，B.和E.Davies，“关于互联网透明度的思考”，RFC 49242007年7月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 49422007年9月。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.
[RFC5001]Austein，R.，“DNS名称服务器标识符（NSID）选项”，RFC 50012007年8月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing Neighbor Discovery Proxy: Problem Statement", RFC 5909, July 2010.
[RFC5909]Combes，J-M.，Krishnan，S.和G.Daley，“保护邻居发现代理：问题声明”，RFC 59092010年7月。
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011.
[RFC6071]Frankel，S.和S.Krishnan，“IP安全（IPsec）和互联网密钥交换（IKE）文档路线图”，RFC 60712011年2月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6382] McPherson, D., Donnelly, R., and F. Scalzo, "Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services", BCP 169, RFC 6382, October 2011.
[RFC6382]McPherson，D.，Donnelly，R.，和F.Scalzo，“全球任意广播服务的每个节点的唯一源自治系统编号（ASN）”，BCP 169，RFC 6382，2011年10月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RSSAC29] "RSSAC 29 Meeting Minutes", December 2007, <http://www.icann.org/en/groups/rssac/meetings/ rssac-29-en.pdf>.
[RSSAC29]“RSSAC29会议记录”，2007年12月<http://www.icann.org/en/groups/rssac/meetings/ rssac-29-en.pdf>。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
Authors' Addresses
作者地址
Danny McPherson Verisign, Inc. 12061 Bluemont Way Reston, VA USA
Danny McPherson Verisign，Inc.美国弗吉尼亚州布鲁蒙特路莱斯顿12061号
EMail: dmcpherson@verisign.com
EMail: dmcpherson@verisign.com
Dave Oran Cisco Systems USA
美国思科系统公司
EMail: oran@cisco.com
EMail: oran@cisco.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA USA
Dave Thaler微软公司美国华盛顿州雷德蒙微软大道一号
EMail: dthaler@microsoft.com
EMail: dthaler@microsoft.com
Eric Osterweil Verisign, Inc. 12061 Bluemont Way Reston, VA USA
Eric Osterweil Verisign，Inc.美国弗吉尼亚州布鲁蒙特路莱斯顿12061号
EMail: eosterweil@verisign.com
EMail: eosterweil@verisign.com