Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 6382 R. Donnelly
BCP: 169 F. Scalzo
Category: Best Current Practice Verisign, Inc.
ISSN: 2070-1721 October 2011
Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 6382 R. Donnelly
BCP: 169 F. Scalzo
Category: Best Current Practice Verisign, Inc.
ISSN: 2070-1721 October 2011
Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
全局任意广播服务的每个节点的唯一源自治系统编号（ASN）
Abstract
摘要
This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment.
本文件就全球选播关键基础设施服务中每个节点使用唯一源自治系统号（ASN）提出建议，以便为给定的选播前缀提供路由系统鉴别器。网络管理和监控技术或其他操作机制可以以最适合其操作环境的任何方式使用这种新的鉴别器。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc6382.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6382.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Recommendation for Unique Origin ASNs ...........................5
4. Additional Recommendations for Globally Anycasted Services ......6
5. Security Considerations .........................................7
6. Deployment Considerations .......................................7
7. Acknowledgements ................................................9
8. IANA Considerations .............................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Recommendation for Unique Origin ASNs ...........................5
4. Additional Recommendations for Globally Anycasted Services ......6
5. Security Considerations .........................................7
6. Deployment Considerations .......................................7
7. Acknowledgements ................................................9
8. IANA Considerations .............................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
IP anycasting [RFC4786] has been deployed for an array of network services since the early 1990s. It provides a mechanism for a given network resource to be available in a more distributed manner, locally and/or globally, with a more robust and resilient footprint, commonly yielding better localization and absorption of systemic query loads, as well as better protections in the face of distributed denial-of-service (DDoS) attacks, network partitions, and other similar incidents. A large part of the Internet root DNS infrastructure, as well as many other resources, has been anycasted for nearly a decade.
自20世纪90年代初以来，IP选播[RFC4786]已部署用于一系列网络服务。它提供了一种机制，使给定的网络资源以更分散的方式在本地和/或全球可用，具有更强健和更具弹性的覆盖范围，通常可以更好地定位和吸收系统查询负载，并在面对分布式拒绝服务（DDoS）攻击时提供更好的保护，网络分区和其他类似事件。近十年来，互联网根DNS基础设施的很大一部分，以及许多其他资源，都已经进行了任意广播。
While the benefits realized by anycasting network services is proven, some issues do emerge with asserting routing system reachability for a common network identifier from multiple locations. Specifically, anycasting in BGP requires injection of reachability information in the routing system for a common IP address prefix from multiple locations. These anycasted prefixes and network services have traditionally employed a common origin autonomous system number (ASN) in order to preserve historically scarce 16-bit AS number space utilized by BGP for routing domain identifiers in the global routing system. Additionally, a common origin AS number was used in order to ease management overhead of resource operations associated with acquiring and maintaining multiple discrete AS numbers as well as to avoid triggering various operations-oriented reporting functions aimed at identifying "inconsistent origin AS announcements" observed in the routing system. As a result, the representation of routing system path attributes associated with those service instances, and that anycasted prefix itself, typically bear no per-instance discriminators in the routing system (i.e., within the network control plane itself).
虽然通过任意广播网络服务实现的好处已被证明，但在断言来自多个位置的公共网络标识符的路由系统可达性时确实出现了一些问题。具体地说，BGP中的任意广播要求在路由系统中为来自多个位置的公共IP地址前缀注入可达性信息。这些选播前缀和网络服务传统上采用共同起源自治系统编号（ASN），以保留BGP在全球路由系统中用于路由域标识符的历史上稀缺的16位AS编号空间。此外，为了减轻与获取和维护多个离散AS编号相关的资源操作的管理开销，并避免触发各种面向操作的报告功能，以识别“不一致的AS编号”在路由系统中观察到。结果，与这些服务实例相关联的路由系统路径属性的表示，以及任意广播前缀本身，通常在路由系统中（即，在网络控制平面本身内）不具有每实例鉴别器。
Service-level query capabilities may or may not provide a mechanism to identify which anycast node responded to a particular query, although this is likely both service (e.g., DNS or NTP) and implementation dependent. For example, Name Server Daemon (NSD), Unbound, and BIND all provide 'hostname.bind or hostname.id' [RFC4892] [RFC5001] query support that enables service-level identification of a given server. Tools such as traceroute are also used to determine to which location a given query is being routed, although it may not reveal local-scope anycast instances, or if there are multiple servers within a given anycast node, which of the servers responded to a given query, in particular, when multiple servers within an anycast node are connected to a single IP router. When utilizing these service-level capabilities, query responses are typically both deterministic and inherently topology dependent; however, these service-level identifiers at the data plane provide no control plane (routing system) uniqueness.
服务级别查询功能可能提供也可能不提供一种机制来识别哪个选播节点响应了特定查询，尽管这可能取决于服务（例如DNS或NTP）和实现。例如，Name Server Daemon（NSD）、Unbound和BIND都提供“hostname.BIND或hostname.id”[RFC4892][RFC5001]查询支持，支持对给定服务器进行服务级别标识。traceroute等工具也用于确定给定查询路由到哪个位置，尽管它可能不会显示本地作用域选播实例，或者如果给定选播节点中有多个服务器，那么哪些服务器响应给定查询，尤其是，当一个选播节点中的多个服务器连接到一个IP路由器时。当使用这些服务级别功能时，查询响应通常既具有确定性，又具有内在的拓扑依赖性；但是，数据平面上的这些服务级别标识符不提供控制平面（路由系统）唯一性。
As more services are globally anycasted, and existing anycasted services realize wider deployment of anycast nodes for a given service address in order to accommodate growing system loads, the difficulty of providing safeguards and controls to better protect those resources expands. Intuitively, the more widely distributed a given anycasted service address is, the more difficult it becomes for network operators to detect operational and security issues that affect that service. Some examples of such security and operational issues include BGP route leaks affecting the anycasted service, rogue anycast nodes appearing for the service, or the emergence of other aberrant behavior in either the routing system, the forward query datapath, or query response datapath. Diagnosis of the routing system issues is complicated by the fact that no unique discriminators exist in the routing system to identify a given local or global anycast node. Furthermore, both datapath and routing system problem identification is compounded by the fact that these incident types can be topologically dependent, and only observable between a given client-server set.
随着更多的服务被全局选播，并且现有的选播服务实现了为给定服务地址更广泛地部署选播节点，以适应不断增长的系统负载，提供保护和控制以更好地保护这些资源的难度也随之增加。直观地说，给定的任意广播服务地址分布得越广，网络运营商就越难以检测影响该服务的操作和安全问题。此类安全和操作问题的一些示例包括影响选播服务的BGP路由泄漏、服务出现的恶意选播节点，或路由系统、前向查询数据路径或查询响应数据路径中出现的其他异常行为。由于路由系统中不存在唯一的鉴别器来识别给定的本地或全局选播节点，因此路由系统问题的诊断变得复杂。此外，数据路径和路由系统问题识别由于以下事实而变得复杂：这些事件类型可以是拓扑依赖的，并且只能在给定的客户机-服务器集之间观察到。
Additionally, while it goes without saying that many anycasted services strive for exact synchronization across all instances of an anycasted service address, if local policies or data plane response manipulation techniques were to "influence" responses within a given region in such a way that those responses are no longer authentic or that they diverge from what other nodes within an anycasted service were providing, then it should be an absolute necessity that those modified resources only be utilized by service consumers within that region or influencer's jurisdiction.
此外，如果本地策略或数据平面响应操纵技术要“影响”的话，尽管许多选播服务都会努力在选播服务地址的所有实例之间实现精确同步，但这是不言而喻的给定区域内的响应不再真实，或者与任意广播服务内的其他节点所提供的响应不同，那么这些修改后的资源必须仅由该区域或影响者管辖范围内的服务消费者使用。
Mechanisms should exist at both the network- and service-layer to make it abundantly apparent to operators and users alike whether any of the query responses are not authentic. For DNS, DNSSEC [RFC4033] provides this capability at the service layer with object-level integrity, assuming validation is being performed by recursive name servers, and DNSSEC deployment at the root and top-level domain (TLD) levels is well underway [DNSSEC-DEPLOY]. Furthermore, control plane discriminators should exist to enable operators to know toward which of a given set of instances a query is being directed, and to enable detection and alerting capabilities when this changes. Such discriminators may also be employed to enable anycast node preference or filtering keys, should local operational policy require it.
网络层和服务层都应该存在机制，以使运营商和用户清楚地知道任何查询响应是否真实。对于DNS，DNSSEC[RFC4033]在具有对象级完整性的服务层提供此功能，假设验证由递归名称服务器执行，并且根和顶级域（TLD）级别的DNSSEC部署正在顺利进行[DNSSEC-DEPLOY]。此外，应存在控制平面鉴别器，以使操作员能够知道查询将指向给定实例集中的哪一个实例，并在发生变化时启用检测和警报功能。如果本地操作策略需要，这种鉴别器还可用于启用选播节点偏好或过滤键。
This document employs much of the following terminology, which was taken in full from Section 2 of [RFC4786].
本文件采用了以下术语，这些术语全部取自[RFC4786]第2节。
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 Node: an Anycast Node providing service using a Global-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.
全局作用域选播：选播服务地址的可达性信息通过路由系统传播，从而使特定的选播节点对整个路由系统可能可见。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In order to be able to better detect changes to routing information associated with critical anycasted resources, globally anycasted services with partitioned origin ASNs SHOULD utilize a unique origin ASN per node where possible, if appropriate in their operating environment and service model.
为了能够更好地检测与关键选播资源相关的路由信息的更改，具有分区源ASN的全局选播服务应尽可能在每个节点上使用唯一的源ASN，如果在其操作环境和服务模型中合适的话。
Discrete origin ASNs per node provide a discriminator in the routing system that would enable detection of leaked or hijacked instances more quickly and would enable operators that so choose to proactively develop routing policies that express preferences or avoidance for a given node or set of nodes associated with an anycasted service. This is particularly useful when it is observed that local policy or known issues exist with the performance or authenticity of responses returned from a specific anycast node, or that enacted policies meant to affect service within a particular region are affecting users outside of that region as a result of a given anycast catchment expanding beyond its intended scope.
每个节点的离散源ASN在路由系统中提供了一个鉴别器，该鉴别器能够更快地检测泄漏或劫持的实例，并使选择主动制定路由策略的运营商能够表达对给定节点或与任意广播服务相关联的一组节点的偏好或避免。当观察到从特定选播节点返回的响应的性能或真实性存在本地策略或已知问题时，这尤其有用，或者，由于给定的选播范围超出其预期范围，旨在影响特定区域内服务的已颁布政策正在影响该区域以外的用户。
Furthermore, inconsistent origin AS announcements associated with anycasted services for critical infrastructure SHOULD NOT be deemed undesirable by routing system reporting functions, but should instead be embraced in order to better identify the connectedness and footprint of a given anycasted service.
此外，路由系统报告功能不应认为与关键基础设施的任意广播服务相关联的不一致的来源作为公告是不可取的，而应予以采纳，以便更好地识别给定任意广播服务的连通性和覆盖范围。
While namespace conservation and reasonable use of AS number resources should always be a goal, the introduction of 32-bit ASNs significantly lessens concerns in this space. Globally anycasted resources, in particular, those associated with critical infrastructure-enabling services such as root and TLD name servers, SHOULD warrant special consideration with regard to AS number allocation practices during policy development by the constituents of
虽然名称空间保护和AS编号资源的合理使用应该始终是一个目标，但32位ASN的引入大大减少了这一领域的担忧。在全球范围内，任何类型的资源，特别是那些与关键基础设施支持服务（如根服务器和TLD名称服务器）相关的资源，都应在由组织成员制定政策期间，特别考虑as数量分配实践
those responsible organizations (e.g., the Regional Internet Registries). Additionally, defining precisely what constitutes "critical infrastructure services" or "special consideration" (e.g., some small range of 32-bit AS numbers might be provided) is left to the constituents of those organizations. Additionally, critical infrastructure employment of 32-bit ASNs for new nodes might well help to foster more rapid adoption of native 32-bit ASN support by network operators.
负责组织（如区域互联网登记处）。此外，准确定义什么构成“关键基础设施服务”或“特殊考虑”（例如，可能提供的一些小范围32位数字）留给这些组织的成员。此外，为新节点使用32位ASN的关键基础设施可能有助于促进网络运营商更快地采用本机32位ASN支持。
One additional benefit of unique origin AS numbers per anycast node is that Resource Public Key Infrastructure (RPKI) Secure Inter-domain Routing [SIDR] machinery, and, in particular, that of Route Origin Authorizations (ROAs), and routing policies that may be derived based on those ROAs, can be employed with per-anycast-node resolution, rather than relying on a single ROA and common origin AS to cover all instantiations of an anycasted prefix (possibly hundreds) within the global routing system. For example, in the case of deployments that incorporate partitioned ASN anycast models that have a single ASN bound to all nodes but crossing organizational or political boundaries, a situation may arise where nobody would be deemed appropriate to hold the key for the ROA. Additionally, a globally anycasted service within a given IP prefix that shares a common ASN might be taken totally offline because of the revocation of an ROA for that origin ASN. Today's RPKI model already inherently accommodates issuance of multiple ROAs with unique origins for a given prefix.
每个选播节点的唯一源AS号的另一个好处是，资源公钥基础设施（RPKI）安全域间路由[SIDR]机制，特别是路由源授权（ROA）机制，以及基于这些ROA派生的路由策略，可用于每个选播节点的解析，而不是依赖一个ROA和公共来源来覆盖全局路由系统中任意广播前缀（可能有数百个）的所有实例。例如，在包含分区ASN选播模型的部署中，单个ASN绑定到所有节点，但跨越组织或政治边界，可能会出现这样的情况：没有人会被认为适合持有ROA的密钥。此外，在给定IP前缀内共享公共ASN的全局选播服务可能会完全脱机，因为该源ASN的ROA被撤销。今天的RPKI模型已经内在地适应了为给定前缀颁发具有唯一来源的多个ROA。
Two additional recommendations for globally anycasted critical infrastructure services are related to publication of information associated with a given node's physical location, and with which adjacent upstream ASNs an origin AS interconnects. The former would allow operators to better define and optimize preferences associated with a given node to align with local policy and service optimizations. The latter would allow expression through policy such as Routing Policy Specification Language [RFC4012] specified in Internet Routing Registries (IRRs) in a manner that illustrates a discrete set of upstream ASNs for each anycast node, rather than the current model where all upstream ASNs associated with a common origin AS may or may not be expressed. This information would provide an additional level of static routing policy or monitoring and detection models by network operators and perhaps explicit network-layer source address validation in the datapath.
关于全球选播关键基础设施服务的另外两项建议涉及发布与给定节点的物理位置相关的信息，以及与之相邻的上游ASN作为互连起点的信息。前者允许运营商更好地定义和优化与给定节点关联的首选项，以与本地策略和服务优化保持一致。后者将允许通过策略进行表达，例如在互联网路由注册中心（IRR）中指定的路由策略规范语言[RFC4012]，其方式说明了每个选播节点的一组离散的上游ASN，而不是当前的模型，其中所有上游ASN与一个共同来源相关，可能表示也可能不表示。该信息将提供额外级别的静态路由策略或网络运营商的监控和检测模型，并可能在数据路径中提供明确的网络层源地址验证。
The recommendations made in this memo aim to provide more flexibility for network operators hoping to better monitor and prevent issues related to globally anycasted critical infrastructure resources. Anycast itself provides considerable benefit in the face of certain attacks; yet, if a given instance of a service can appear at many points in the routing system and legitimate instances are difficult to distinguish from malicious ones, then anycast expands the service's attack surface rather than reducing it.
本备忘录中提出的建议旨在为网络运营商提供更大的灵活性，以便更好地监控和防止与全球任何关键基础设施资源相关的问题。Anycast本身在面对某些攻击时提供了相当大的好处；然而，如果服务的给定实例可以出现在路由系统的多个点上，并且很难区分合法实例和恶意实例，那么anycast将扩展服务的攻击面，而不是减少它。
The recommendations made in this document are expressed to assist with visibility and policy specification capabilities in order to improve the availability of critical Internet resources. Use cases, where the recommendations outlined in this memo may have helped to more easily detect or scope the impact of a particular incident, are illustrated in [RENESYS-BLOG].
本文件中提出的建议旨在帮助提高可见性和政策规范能力，以提高关键互联网资源的可用性。[RENESYS-BLOG]中说明了使用案例，其中本备忘录中概述的建议可能有助于更容易地检测或确定特定事件的影响范围。
Furthermore, while application-layer protection mechanisms such as DNS security extensions (DNSSEC) provide object-level integrity and authentication, they often do so at the cost of introducing more failure conditions. For example, if a recursive name server is performing DNSSEC validator functions and receives a bogus response to a given query as a result of a man-in-the-middle (MITM) or injected spoofed response packet such as a cache-poisoning attempt, the possibility might exist that the response packet is processed by the server and results in some temporal or persistent DoS condition on the recursive name server and for its client set. The unique origin AS mechanism outlined in this document provides the capability for network operators to expressly avoid anycast node catchments known to regularly elicit bogus responses, while allowing the anycasted service address to remain available otherwise.
此外，虽然DNS安全扩展（DNSSEC）等应用层保护机制提供了对象级完整性和身份验证，但它们这样做往往以引入更多故障条件为代价。例如，如果递归名称服务器正在执行DNSSEC验证程序功能，并且由于中间人（MITM）或注入的伪造响应数据包（如缓存中毒尝试）而接收到对给定查询的虚假响应，可能存在这样的可能性，即响应数据包由服务器处理，并导致递归名称服务器及其客户机集出现某种暂时或持久的DoS情况。本文档中概述的独特起源机制为网络运营商提供了明确避免任意广播节点捕获的能力，该节点捕获通常会引发虚假响应，同时允许任意广播服务地址在其他情况下保持可用。
Maintenance of unique ASNs for each node within an anycasted service may be challenging for some critical infrastructure service operators initially, but for globally anycasted resources, there needs to be some type of per-node discriminator in the control plane to enable detection, remediation, and optimally, preventative controls for dealing with routing system anomalies that are intensified by the application of IP anycasting. Additionally, this technique sets the stage to employ RPKI-enabled machinery and more secure and explicit routing policies, which all network operators should be considering.
对于一些关键的基础设施服务运营商来说，为任意广播服务中的每个节点维护唯一的ASN最初可能是一个挑战，但对于全球任意广播资源，需要在控制平面中有某种类型的每节点鉴别器，以实现检测、修复和优化，用于处理因IP选播应用而加剧的路由系统异常的预防性控制。此外，该技术为采用支持RPKI的机制和更安全、更明确的路由策略奠定了基础，所有网络运营商都应该考虑到这一点。
The granularity of data publication related to anycast node location should be left to the devises of each services operator, and the value of this mechanism in each operator's unique environment, but some reasonable level of detail to enable operators and service consumers to make informed decisions that align with their security and operational objectives as outlined herein should be provided by each critical services operator.
与选播节点位置相关的数据发布粒度应留给每个服务运营商的设计，以及该机制在每个运营商独特环境中的价值，但是，每个关键服务运营商都应提供一些合理的详细信息，以使运营商和服务消费者能够根据本文概述的安全和运营目标做出明智的决策。
Adjacent AS information for a given origin AS can already be obtained through careful routing system analysis when prefixes are advertised via a given set of AS adjacencies, and therefore, should present no new threat. However, network interconnection and peering policies may well present some challenges in this area. For example, if a technique such as unique origin AS per node is employed, then a single organization may no longer have a single AS for interconnection at each location, and interconnection policies should expressly consider this. That said, interconnection with networks that provide critical infrastructure services should certainly be given due consideration as such by network operators when evaluating interconnection strategies.
当前缀通过一组给定的AS邻接进行广告时，可以通过仔细的路由系统分析获得给定源AS的相邻AS信息，因此，不会出现新的威胁。然而，网络互连和对等策略可能会在这方面带来一些挑战。例如，如果采用诸如每个节点的独特起源的技术，那么单个组织可能不再有单一的用于每个位置的互连，互连策略应该明确地考虑这一点。这就是说，网络运营商在评估互连策略时，当然应该适当考虑与提供关键基础设施服务的网络的互连。
Today, some root and TLD operators identify erroneous anycast prefix announcements by detecting prefix announcements with an origin AS other than the common origin AS shared via all nodes. This detection model would need to be expanded to account for unique origin ASNs per node if a given service operator chooses to employ such a model. Given that AS paths are trivial to manipulate in the current system, the above technique would only assist in the event of unintentional configuration errors that reoriginate the route (e.g., it does not detect leaks that preserve the initial path elements). In that case, work underway on routing security origin and path validation in the SIDR working group and beyond should be consulted.
今天，一些root和TLD操作员通过检测前缀通知，识别错误的选播前缀通知，其来源不是通过所有节点共享的公共来源。如果给定的服务运营商选择使用这种模型，则需要扩展此检测模型，以考虑每个节点的唯一源ASN。鉴于在当前系统中，路径很容易操作，因此上述技术仅在发生意外配置错误时才有助于重新确定路径的顺序（例如，它不会检测到保留初始路径元素的泄漏）。在这种情况下，应咨询SIDR工作组及其以外正在进行的路由安全源和路径验证工作。
While local policy based on any BGP attributes, to include AS path information, can influence policy within a local administrative domain and possibly downstream, there exists a possibility that upstream nodes continue to use a route deemed undesirable by the local administrator once data packets reach that network. Network operators must understand the implications of this property in their operating environment, as it is inherent in all Internet routing.
虽然基于任何BGP属性（包括作为路径信息）的本地策略可以影响本地管理域内的策略，并且可能影响下游，但一旦数据包到达该网络，上游节点就有可能继续使用本地管理员认为不需要的路由。网络运营商必须了解该属性在其运营环境中的含义，因为它是所有互联网路由中固有的。
Finally, anycast node presence at exchange points that employ route servers may make enumeration of adjacent ASNs for a given node challenging. While this is understood, service operators should make every effort to enumerate the set of adjacent ASNs associated with a given anycast node's origin AS. Without express understanding of legitimate AS interconnection and authorized origin AS information, more secure routing is difficult to achieve.
最后，在使用路由服务器的交换点上存在的选播节点可能会对给定节点的相邻ASN的枚举造成挑战。虽然这是可以理解的，但服务运营商应该尽一切努力枚举与给定选播节点的源节点关联的相邻ASN集。如果不明确理解作为互连的合法性和作为信息的授权来源，就很难实现更安全的路由。
Thanks to David Conrad, Steve Kent, Mark Kosters, Andrei Robachevsky, Paul Vixie, Brad Verd, Andrew Herrmann, Gaurab Raj Upadhaya, Joe Abley, Benson Schliesser, Shane Amante, Hugo Salgado, and Randy Bush for review and comments on this concept.
感谢David Conrad、Steve Kent、Mark Kosters、Andrei Robachevsky、Paul Vixie、Brad Verd、Andrew Herrmann、Gaurab Raj Upadhaya、Joe Abley、Benson Schliesser、Shane Amante、Hugo Salgado和Randy Bush对这一概念的回顾和评论。
This document requires no direct IANA actions, although it does provide general guidance to number resource allocation and policy development organizations, and, in particular, Regional Internet Registries, regarding allocation of AS numbers for globally anycasted services.
本文件不要求IANA采取直接行动，尽管它确实为数字资源分配和政策制定组织，特别是区域互联网注册机构，就全球任意广播服务的AS数字分配提供了一般指导。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[DNSSEC-DEPLOY]
"Root DNSSEC", <http://www.root-dnssec.org/>
[DNSSEC-DEPLOY]
"Root DNSSEC", <http://www.root-dnssec.org/>
[RENESYS-BLOG]
Zmijewski, E., "Accidentally Importing Censorship",
Renesys Blog, March 30, 2010.
<http://www.renesys.com/blog/2010/03/
fouling-the-global-nest.shtml>
[RENESYS-BLOG]
Zmijewski, E., "Accidentally Importing Censorship",
Renesys Blog, March 30, 2010.
<http://www.renesys.com/blog/2010/03/
fouling-the-global-nest.shtml>
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005.
[RFC4012]Blunk，L.，Damas，J.，Parent，F.，和A.Robachevsky，“下一代路由策略规范语言（RPSLng）”，RFC4012，2005年3月。
[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月。
[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月。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.
[RFC5001]Austein，R.，“DNS名称服务器标识符（NSID）选项”，RFC 50012007年8月。
[SIDR] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in Progress, May 2011.
[SIDR]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，正在进行的工作，2011年5月。
Authors' Addresses
作者地址
Danny McPherson Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
Danny McPherson Verisign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345 20166电话：+1 703.948.3200
EMail: dmcpherson@verisign.com
EMail: dmcpherson@verisign.com
Ryan Donnelly Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
Ryan Donnelly Verisign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345 20166电话：+1 703.948.3200
EMail: rdonnelly@verisign.com
EMail: rdonnelly@verisign.com
Frank Scalzo Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
Frank Scalzo Verisign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345 20166电话：+1 703.948.3200
EMail: fscalzo@verisign.com
EMail: fscalzo@verisign.com