Internet Engineering Task Force (IETF) J. Durand
Request for Comments: 7454 Cisco Systems, Inc.
BCP: 194 I. Pepelnjak
Category: Best Current Practice NIL
ISSN: 2070-1721 G. Doering
SpaceNet
February 2015
Internet Engineering Task Force (IETF) J. Durand
Request for Comments: 7454 Cisco Systems, Inc.
BCP: 194 I. Pepelnjak
Category: Best Current Practice NIL
ISSN: 2070-1721 G. Doering
SpaceNet
February 2015
BGP Operations and Security
BGP运营与安全
Abstract
摘要
The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.
边界网关协议（BGP）几乎是互联网上唯一用于在网络域之间交换路由信息的协议。由于这一中心性质，了解可以而且应该部署的安全措施以防止意外或故意的路由干扰非常重要。
This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.
本文档描述了保护BGP会话本身的措施，如生存时间（TTL）、TCP身份验证选项（TCP-AO）和控制平面过滤。它还描述了使用前缀过滤和前缀过滤器自动化、最大前缀过滤、自治系统（AS）路径过滤、路由瓣抑制和BGP社区清除来更好地控制路由信息流的措施。
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/rfc7454.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7454.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope of the Document . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Protection of the BGP Speaker . . . . . . . . . . . . . . . . 5
5. Protection of BGP Sessions . . . . . . . . . . . . . . . . . 6
5.1. Protection of TCP Sessions Used by BGP . . . . . . . . . 6
5.2. BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . . 6
6. Prefix Filtering . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Definition of Prefix Filters . . . . . . . . . . . . . . 7
6.1.1. Special-Purpose Prefixes . . . . . . . . . . . . . . 7
6.1.2. Unallocated Prefixes . . . . . . . . . . . . . . . . 8
6.1.3. Prefixes That Are Too Specific . . . . . . . . . . . 12
6.1.4. Filtering Prefixes Belonging to the Local AS and
Downstreams . . . . . . . . . . . . . . . . . . . . . 12
6.1.5. IXP LAN Prefixes . . . . . . . . . . . . . . . . . . 12
6.1.6. The Default Route . . . . . . . . . . . . . . . . . . 13
6.2. Prefix Filtering Recommendations in Full Routing Networks 14
6.2.1. Filters with Internet Peers . . . . . . . . . . . . . 14
6.2.2. Filters with Customers . . . . . . . . . . . . . . . 16
6.2.3. Filters with Upstream Providers . . . . . . . . . . . 16
6.3. Prefix Filtering Recommendations for Leaf Networks . . . 17
6.3.1. Inbound Filtering . . . . . . . . . . . . . . . . . . 17
6.3.2. Outbound Filtering . . . . . . . . . . . . . . . . . 17
7. BGP Route Flap Dampening . . . . . . . . . . . . . . . . . . 17
8. Maximum Prefixes on a Peering . . . . . . . . . . . . . . . . 18
9. AS Path Filtering . . . . . . . . . . . . . . . . . . . . . . 18
10. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . 20
11. BGP Community Scrubbing . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. IXP LAN Prefix Filtering - Example . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope of the Document . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Protection of the BGP Speaker . . . . . . . . . . . . . . . . 5
5. Protection of BGP Sessions . . . . . . . . . . . . . . . . . 6
5.1. Protection of TCP Sessions Used by BGP . . . . . . . . . 6
5.2. BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . . 6
6. Prefix Filtering . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Definition of Prefix Filters . . . . . . . . . . . . . . 7
6.1.1. Special-Purpose Prefixes . . . . . . . . . . . . . . 7
6.1.2. Unallocated Prefixes . . . . . . . . . . . . . . . . 8
6.1.3. Prefixes That Are Too Specific . . . . . . . . . . . 12
6.1.4. Filtering Prefixes Belonging to the Local AS and
Downstreams . . . . . . . . . . . . . . . . . . . . . 12
6.1.5. IXP LAN Prefixes . . . . . . . . . . . . . . . . . . 12
6.1.6. The Default Route . . . . . . . . . . . . . . . . . . 13
6.2. Prefix Filtering Recommendations in Full Routing Networks 14
6.2.1. Filters with Internet Peers . . . . . . . . . . . . . 14
6.2.2. Filters with Customers . . . . . . . . . . . . . . . 16
6.2.3. Filters with Upstream Providers . . . . . . . . . . . 16
6.3. Prefix Filtering Recommendations for Leaf Networks . . . 17
6.3.1. Inbound Filtering . . . . . . . . . . . . . . . . . . 17
6.3.2. Outbound Filtering . . . . . . . . . . . . . . . . . 17
7. BGP Route Flap Dampening . . . . . . . . . . . . . . . . . . 17
8. Maximum Prefixes on a Peering . . . . . . . . . . . . . . . . 18
9. AS Path Filtering . . . . . . . . . . . . . . . . . . . . . . 18
10. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . 20
11. BGP Community Scrubbing . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. IXP LAN Prefix Filtering - Example . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
The Border Gateway Protocol (BGP), specified in RFC 4271 [2], is the protocol used in the Internet to exchange routing information between network domains. BGP does not directly include mechanisms that control whether the routes exchanged conform to the various guidelines defined by the Internet community. This document intends to both summarize common existing guidelines and help network administrators apply coherent BGP policies.
RFC 4271[2]中规定的边界网关协议（BGP）是互联网中用于在网络域之间交换路由信息的协议。BGP不直接包括控制交换的路由是否符合互联网社区定义的各种准则的机制。本文档旨在总结现有的通用指南，并帮助网络管理员应用一致的BGP策略。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The guidelines defined in this document are intended for generic Internet BGP peerings. The nature of the Internet is such that Autonomous Systems can always agree on exceptions to a common framework for relevant local needs, and therefore configure a BGP session in a manner that may differ from the recommendations provided in this document. While this is perfectly acceptable, every configured exception might have an impact on the entire inter-domain routing environment, and network administrators SHOULD carefully appraise this impact before implementation.
本文档中定义的指南适用于通用互联网BGP对等。互联网的性质是，自治系统始终可以就相关本地需求的通用框架的例外情况达成一致，因此，以不同于本文件中提供的建议的方式配置BGP会话。虽然这是完全可以接受的，但每个配置的异常都可能对整个域间路由环境产生影响，网络管理员应该在实施之前仔细评估这种影响。
o ACL: Access Control List
o 访问控制列表
o ASN: Autonomous System Number
o ASN：自治系统编号
o IRR: Internet Routing Registry
o 互联网路由注册
o IXP: Internet Exchange Point
o 互联网交换点
o LIR: Local Internet Registry
o 本地互联网注册
o PMTUD: Path MTU Discovery
o PMTUD：路径MTU发现
o RIR: Regional Internet Registry
o RIR：区域互联网注册处
o Tier 1 transit provider: an IP transit provider that can reach any network on the Internet without purchasing transit services.
o Tier 1 transit provider：一家IP transit provider，无需购买transit服务即可访问Internet上的任何网络。
o uRPF: Unicast Reverse Path Forwarding
o uRPF：单播反向路径转发
In addition to the list above, the following terms are used with a specific meaning.
除上述列表外，以下术语具有特定含义。
o Downstream: any network that is downstream; it can be a provider or a customer network.
o 下游：下游的任何网络；它可以是提供商或客户网络。
o Upstream: any network that is upstream.
o 上游：上游的任何网络。
The BGP speaker needs to be protected from attempts to subvert the BGP session. This protection SHOULD be achieved by an Access Control List (ACL) that would discard all packets directed to TCP port 179 on the local device and sourced from an address not known or permitted to become a BGP neighbor. Experience has shown that the natural protection TCP should offer is not always sufficient, as it is sometimes run in control-plane software. In the absence of ACLs, it is possible to attack a BGP speaker by simply sending a high volume of connection requests to it.
需要保护BGP扬声器，防止其试图破坏BGP会话。这种保护应该通过访问控制列表（ACL）来实现，ACL将丢弃指向本地设备上TCP端口179的所有数据包，这些数据包来自未知或不允许成为BGP邻居的地址。经验表明，TCP应提供的自然保护并不总是足够的，因为它有时在控制平面软件中运行。在没有ACL的情况下，只需向BGP说话者发送大量连接请求，就可以攻击BGP说话者。
If supported, an ACL specific to the control plane of the router SHOULD be used (receive-ACL, control-plane policing, etc.), to avoid configuration of data-plane filters for packets transiting through the router (and therefore not reaching the control plane). If the hardware cannot do that, interface ACLs can be used to block packets addressed to the local router.
如果支持，应使用特定于路由器控制平面的ACL（接收ACL、控制平面监控等），以避免为通过路由器传输的数据包配置数据平面过滤器（因此不会到达控制平面）。如果硬件不能做到这一点，则可以使用接口ACL来阻止发往本地路由器的数据包。
Some routers automatically program such an ACL upon BGP configuration. On other devices, this ACL should be configured and maintained manually or using scripts.
一些路由器根据BGP配置自动编程这样的ACL。在其他设备上，应手动或使用脚本配置和维护此ACL。
In addition to strict filtering, rate-limiting MAY be configured for accepted BGP traffic. Rate-limiting BGP traffic consists in permitting only a certain quantity of bits per second (or packets per second) of BGP traffic to the control plane. This protects the BGP router control plane in case the amount of BGP traffic surpasses platform capabilities.
除了严格过滤外，还可以为接受的BGP流量配置速率限制。速率限制BGP流量包括仅允许控制平面每秒一定数量的BGP流量比特（或每秒数据包）。这将在BGP流量超过平台能力的情况下保护BGP路由器控制平面。
Filtering and rate-limiting of control-plane traffic is a wider topic than "just for BGP". (If a network administrator brings down a router by overloading one of the other protocols remotely, BGP is harmed as well.) For a more detailed recommendation on how to protect the router's control plane, see RFC 6192 [11].
控制平面流量的过滤和速率限制是比“仅针对BGP”更广泛的主题。（如果网络管理员通过远程过载其他协议之一使路由器停机，BGP也会受到损害。）有关如何保护路由器控制平面的更详细建议，请参阅RFC 6192[11]。
Current security issues of TCP-based protocols (therefore including BGP) have been documented in RFC 6952 [14]. The following subsections list the major points raised in this RFC and give the best practices related to TCP session protection for BGP operation.
基于TCP的协议（因此包括BGP）的当前安全问题已记录在RFC 6952[14]中。以下小节列出了本RFC中提出的要点，并给出了与BGP操作的TCP会话保护相关的最佳实践。
Attacks on TCP sessions used by BGP (aka BGP sessions), for example, sending spoofed TCP RST packets, could bring down a BGP peering. Following a successful ARP spoofing attack (or other similar man-in-the-middle attack), the attacker might even be able to inject packets into the TCP stream (routing attacks).
对BGP使用的TCP会话（也称为BGP会话）的攻击，例如，发送伪造的TCP RST数据包，可能导致BGP对等中断。在成功的ARP欺骗攻击（或其他类似的中间人攻击）之后，攻击者甚至可以将数据包注入TCP流（路由攻击）。
BGP sessions can be secured with a variety of mechanisms. MD5 protection of the TCP session header, described in RFC 2385 [7], was the first such mechanism. It has been obsoleted by the TCP Authentication Option (TCP-AO; RFC 5925 [4]), which offers stronger protection. While MD5 is still the most used mechanism due to its availability in vendors' equipment, TCP-AO SHOULD be preferred when implemented.
BGP会话可以通过多种机制进行保护。RFC 2385[7]中描述的TCP会话头的MD5保护是第一个这样的机制。TCP身份验证选项（TCP-AO；RFC 5925[4]）已将其淘汰，该选项提供了更强的保护。虽然MD5仍然是最常用的机制，因为它在供应商的设备中可用，但在实现时，TCP-AO应该是首选。
IPsec could also be used for session protection. At the time of publication, there is not enough experience of the impact of using IPsec for BGP peerings, and further analysis is required to define guidelines.
IPsec也可用于会话保护。在出版时，对于使用IPsec进行BGP对等的影响还没有足够的经验，需要进一步分析以确定指导原则。
The drawback of TCP session protection is additional configuration and management overhead for the maintenance of authentication information (for example, MD5 passwords). Protection of TCP sessions used by BGP is thus NOT REQUIRED even when peerings are established over shared networks where spoofing can be done (like IXPs), but operators are RECOMMENDED to consider the trade-offs and to apply TCP session protection where appropriate.
TCP会话保护的缺点是为维护身份验证信息（例如，MD5密码）增加了额外的配置和管理开销。因此，即使在可以进行欺骗（例如IXPs）的共享网络上建立对等点时，也不需要保护BGP所使用的TCP会话，但建议运营商考虑权衡，并在适当的时候应用TCP会话保护。
Furthermore, network administrators SHOULD block spoofed packets (packets with a source IP address belonging to their IP address space) at all edges of their network (see RFC 2827 [8] and RFC 3704 [9]). This protects the TCP session used by Internal BGP (IBGP) from attackers outside the Autonomous System.
此外，网络管理员应在其网络的所有边缘阻止伪造数据包（源IP地址属于其IP地址空间的数据包）（参见RFC 2827[8]和RFC 3704[9]）。这可以保护内部BGP（IBGP）使用的TCP会话免受自治系统之外的攻击者的攻击。
BGP sessions can be made harder to spoof with the Generalized TTL Security Mechanisms (GTSM aka TTL security), defined in RFC 5082 [3]. Instead of sending TCP packets with TTL value of 1, the BGP speakers send the TCP packets with TTL value of 255, and the receiver checks
使用RFC 5082[3]中定义的通用TTL安全机制（GTSM又名TTL安全机制），BGP会话更难欺骗。BGP扬声器不发送TTL值为1的TCP数据包，而是发送TTL值为255的TCP数据包，接收器进行检查
that the TTL value equals 255. Since it's impossible to send an IP packet with TTL of 255 to an IP host that is not directly connected, BGP TTL security effectively prevents all spoofing attacks coming from third parties not directly connected to the same subnet as the BGP-speaking routers. Network administrators SHOULD implement TTL security on directly connected BGP peerings.
TTL值等于255。由于无法将TTL为255的IP数据包发送到未直接连接的IP主机，BGP TTL安全性可有效防止来自与BGP路由器未直接连接到同一子网的第三方的所有欺骗攻击。网络管理员应在直接连接的BGP对等上实施TTL安全。
GTSM could also be applied to multi-hop BGP peering as well. To achieve this, TTL needs to be configured with a proper value depending on the distance between BGP speakers (using the principle described above). Nevertheless, it is not as effective because anyone inside the TTL diameter could spoof the TTL.
GTSM也可以应用于多跳BGP对等。为了实现这一点，TTL需要根据BGP扬声器之间的距离配置一个合适的值（使用上述原理）。然而，它并没有那么有效，因为在TTL直径内的任何人都可能欺骗TTL。
Like MD5 protection, TTL security has to be configured on both ends of a BGP session.
与MD5保护一样，必须在BGP会话的两端配置TTL安全性。
The main aspect of securing BGP resides in controlling the prefixes that are received and advertised on the BGP peerings. Prefixes exchanged between BGP peers are controlled with inbound and outbound filters that can match on IP prefixes (as described in this section), AS paths (as described in Section 9) or any other attributes of a BGP prefix (for example, BGP communities, as described in Section 11).
保护BGP的主要方面在于控制在BGP对等上接收和播发的前缀。BGP对等方之间交换的前缀由入站和出站筛选器控制，这些筛选器可以匹配IP前缀（如本节所述）、路径（如第9节所述）或BGP前缀的任何其他属性（例如，如第11节所述的BGP社区）。
This section lists the most commonly used prefix filters. The following sections will clarify where these filters should be applied.
本节列出了最常用的前缀过滤器。以下章节将阐明这些过滤器应应用于何处。
The IANA IPv4 Special-Purpose Address Registry [23] maintains the list of IPv4 special-purpose prefixes and their routing scope, and it SHOULD be used for prefix-filter configuration. Prefixes with value "False" in column "Global" SHOULD be discarded on Internet BGP peerings.
IANA IPv4专用地址注册表[23]维护IPv4专用前缀及其路由范围的列表，该列表应用于前缀筛选器配置。应在Internet BGP对等上丢弃列“全局”中值为“False”的前缀。
The IANA IPv6 Special-Purpose Address Registry [24] maintains the list of IPv6 special-purpose prefixes and their routing scope, and it SHOULD be used for prefix-filter configuration. Only prefixes with value "False" in column "Global" SHOULD be discarded on Internet BGP peerings.
IANA IPv6专用地址注册表[24]维护IPv6专用前缀及其路由范围的列表，该列表应用于前缀筛选器配置。在Internet BGP对等上，只应丢弃“全局”列中值为“False”的前缀。
IANA allocates prefixes to RIRs that in turn allocate prefixes to LIRs (Local Internet Registries). It is wise not to accept routing table prefixes that are not allocated by IANA and/or RIRs. This section details the options for building a list of allocated prefixes at every level. It is important to understand that filtering unallocated prefixes requires constant updates, as prefixes are continually allocated. Therefore, automation of such prefix filters is key for the success of this approach. Network administrators SHOULD NOT consider solutions described in this section if they are not capable of maintaining updated prefix filters: the damage would probably be worse than the intended security policy.
IANA将前缀分配给RIR，而RIR又将前缀分配给LIR（本地互联网注册中心）。明智的做法是不接受IANA和/或RIR未分配的路由表前缀。本节详细介绍了在每个级别构建已分配前缀列表的选项。重要的是要理解，过滤未分配的前缀需要不断更新，因为前缀是不断分配的。因此，这种前缀过滤器的自动化是这种方法成功的关键。如果网络管理员不能维护更新的前缀过滤器，则不应考虑本节中描述的解决方案：损坏可能比预期的安全策略更差。
IANA has allocated all the IPv4 available space. Therefore, there is no reason why network administrators would keep checking that prefixes they receive from BGP peers are in the IANA-allocated IPv4 address space [25]. No specific filters need to be put in place by administrators who want to make sure that IPv4 prefixes they receive in BGP updates have been allocated by IANA.
IANA已分配所有IPv4可用空间。因此，网络管理员没有理由不停地检查他们从BGP对等方收到的前缀是否在IANA分配的IPv4地址空间中[25]。如果管理员希望确保在BGP更新中收到的IPv4前缀已由IANA分配，则无需设置特定的筛选器。
For IPv6, given the size of the address space, it can be seen as wise to accept only prefixes derived from those allocated by IANA. Administrators can dynamically build this list from the IANA-allocated IPv6 space [26]. As IANA keeps allocating prefixes to RIRs, the aforementioned list should be checked regularly against changes, and if they occur, prefix filters should be computed and pushed on network devices. The list could also be pulled directly by routers when they implement such mechanisms. As there is delay between the time a RIR receives a new prefix and the moment it starts allocating portions of it to its LIRs, there is no need for doing this step quickly and frequently. However, network administrators SHOULD ensure that all IPv6 prefix filters are updated within a maximum of one month after any change in the list of IPv6 prefixes allocated by IANA.
对于IPv6，考虑到地址空间的大小，只接受来自IANA分配的前缀是明智的。管理员可以从IANA分配的IPv6空间动态构建此列表[26]。由于IANA不断将前缀分配给RIR，应定期检查上述列表是否有变化，如果发生变化，应计算前缀过滤器并将其推送到网络设备上。当路由器实现这种机制时，也可以直接拉取列表。由于RIR收到新前缀和开始将其部分分配给其LIR之间存在延迟，因此无需快速频繁地执行此步骤。但是，网络管理员应确保在IANA分配的IPv6前缀列表发生任何更改后的最长一个月内更新所有IPv6前缀筛选器。
If the process in place (whether manual or automatic) cannot guarantee that the list is updated regularly, then it's better not to configure any filters based on allocated networks. The IPv4 experience has shown that many network operators implemented filters for prefixes not allocated by IANA but did not update them on a regular basis. This created problems for the latest allocations, and required extra work for RIRs that had to "de-bogonize" the newly allocated prefixes. (See [18] for information on de-bogonizing.)
如果现有流程（手动或自动）不能保证定期更新列表，那么最好不要根据分配的网络配置任何过滤器。IPv4的经验表明，许多网络运营商对IANA未分配的前缀实施了过滤器，但没有定期更新前缀。这给最新的分配带来了问题，并且需要为RIR做额外的工作，RIR必须“去bogonize”新分配的前缀。（有关脱硼的信息，请参见[18]）
A more precise check can be performed when one would like to make sure that prefixes they receive are being originated or transited by Autonomous Systems (ASes) entitled to do so. It has been observed in the past that an AS could easily advertise someone else's prefix (or more specific prefixes) and create black holes or security threats. To partially mitigate this risk, administrators would need to make sure BGP advertisements correspond to information located in the existing registries. At this stage, two options can be considered: short- and long-term options. They are described in the following subsections.
当人们希望确保他们收到的前缀是由有权这样做的自治系统（ASE）发起或传输时，可以执行更精确的检查。过去有人观察到AS很容易宣传其他人的前缀（或更具体的前缀），并造成黑洞或安全威胁。为了部分缓解这一风险，管理员需要确保BGP广告与现有注册中心中的信息相对应。在这个阶段，可以考虑两种选择：短期选择和长期选择。以下各小节对其进行了描述。
6.1.2.2.1. Prefix Filters Created from Internet Routing Registries (IRRs)
6.1.2.2.1. 从Internet路由注册表（IRR）创建的前缀筛选器
An Internet Routing Registry (IRR) is a database containing Internet routing information, described using Routing Policy Specification Language objects as described in RFC 4012 [10]. Network administrators are given privileges to describe routing policies of their own networks in the IRR, and that information is published, usually publicly. A majority of Regional Internet Registries do also operate an IRR and can control whether registered routes conform to the prefixes that are allocated or directly assigned. However, it should be noted that the list of such prefixes is not necessarily a complete list, and as such the list of routes in an IRR is not the same as the set of RIR-allocated prefixes.
Internet路由注册表（IRR）是包含Internet路由信息的数据库，使用RFC 4012[10]中描述的路由策略规范语言对象进行描述。网络管理员有权在IRR中描述他们自己网络的路由策略，这些信息通常是公开发布的。大多数区域互联网注册中心也运行IRR，可以控制注册的路由是否符合分配或直接分配的前缀。然而，应当注意的是，这些前缀的列表不一定是完整的列表，因此，IRR中的路由列表与分配给RIR的前缀集不同。
It is possible to use the IRR information to build, for a given neighbor AS, a list of originated or transited prefixes that one may accept. This can be done relatively easily using scripts and existing tools capable of retrieving this information from the registries. This approach is exactly the same for both IPv4 and IPv6.
可以使用IRR信息为给定的邻居AS建立一个可以接受的原始前缀或转换前缀列表。使用能够从注册中心检索此信息的脚本和现有工具可以相对轻松地完成这项工作。对于IPv4和IPv6，这种方法完全相同。
The macro-algorithm for the script is as follows. For the peer that is considered, the distant network administrator has provided the AS and may be able to provide an AS-SET object (aka AS-MACRO). An AS-SET is an object that contains AS numbers or other AS-SETs. An operator may create an AS-SET defining all the AS numbers of its customers. A Tier 1 transit provider might create an AS-SET describing the AS-SET of connected operators, which in turn describe the AS numbers of their customers. Using recursion, it is possible to retrieve from an AS-SET the complete list of AS numbers that the peer is likely to announce. For each of these AS numbers, it is also easy to look in the corresponding IRR for all associated prefixes. With these two mechanisms, a script can build, for a given peer, the
脚本的宏算法如下所示。对于所考虑的对等方，远程网络管理员已提供AS，并且可能能够提供AS-SET对象（又名AS-MACRO）。AS-SET是包含AS编号或其他AS集的对象。运营商可以创建一个AS集，定义其客户的所有AS编号。一级运输提供商可能会创建一个AS集，描述连接运营商的AS集，进而描述其客户的AS编号。使用递归，可以从AS集合中检索对等方可能宣布的AS编号的完整列表。对于这些数字中的每一个，在相应的IRR中查找所有相关前缀也很容易。通过这两种机制，脚本可以为给定的对等方构建
list of allowed prefixes and the AS number from which they should be originated. One could decide not use the origin information and only build monolithic prefix filters from fetched data.
允许的前缀列表以及它们应来自的AS编号。人们可以决定不使用源信息，而只从获取的数据构建单片前缀过滤器。
As prefixes, AS numbers, and AS-SETs may not all be under the same RIR authority, it is difficult to choose for each object the appropriate IRR to poll. Some IRRs have been created and are not restricted to a given region or authoritative RIR. They allow RIRs to publish information contained in their IRR in a common place. They also make it possible for any subscriber (probably under contract) to publish information too. When doing requests inside such an IRR, it is possible to specify the source of information in order to have the most reliable data. One could check a popular IRR containing many sources (such as RADb [27], the Routing Assets Database) and only select as sources some desired RIRs and trusted major ISPs (Internet Service Providers).
由于前缀、数字和集合可能并不都在同一RIR权限下，因此很难为每个对象选择适当的IRR进行轮询。一些内部收益率已经创建，并且不限于给定的区域或权威的内部收益率。它们允许RIR在公共场所发布其IRR中包含的信息。它们还使得任何订阅者（可能根据合同）也可以发布信息。当在这样的IRR内进行请求时，可以指定信息来源，以获得最可靠的数据。可以检查包含许多来源（如RADb[27]，路由资产数据库）的流行IRR，并仅选择一些所需的RIR和受信任的主要ISP（互联网服务提供商）作为来源。
As objects in IRRs may frequently vary over time, it is important that prefix filters computed using this mechanism are refreshed regularly. Refreshing the filters on a daily basis SHOULD be considered because routing changes must sometimes be done in an emergency and registries may be updated at the very last moment. Note that this approach significantly increases the complexity of the router configurations, as it can quickly add tens of thousands of configuration lines for some important peers. To manage this complexity, network administrators could use, for example, IRRToolSet [30], a set of tools making it possible to simplify the creation of automated filter configuration from policies stored in an IRR.
由于IRR中的对象可能随时间频繁变化，因此定期刷新使用此机制计算的前缀过滤器非常重要。应该考虑每天刷新过滤器，因为路由更改有时必须在紧急情况下进行，并且注册表可能在最后一刻更新。请注意，这种方法显著增加了路由器配置的复杂性，因为它可以为一些重要的对等点快速添加数万条配置线。为了管理这种复杂性，网络管理员可以使用IRRToolSet[30]，这是一组工具，可以简化从存储在IRR中的策略创建自动筛选器配置的过程。
Last but not least, network administrators SHOULD publish and maintain their resources properly in the IRR database maintained by their RIR, when available.
最后但并非最不重要的一点是，网络管理员应在其RIR维护的IRR数据库中适当发布和维护其资源（如果可用）。
An infrastructure called SIDR (Secure Inter-Domain Routing), described in RFC 6480 [12], has been designed to secure Internet advertisements. At the time of writing this document, many documents have been published and a framework with a complete set of protocols is proposed so that advertisements can be checked against signed routing objects in RIRs. There are basically two services that SIDR offers:
RFC 6480[12]中描述的一种称为SIDR（安全域间路由）的基础设施被设计用于保护互联网广告。在编写本文档时，已经发布了许多文档，并提出了一个包含完整协议集的框架，以便可以根据RIR中的签名路由对象检查广告。SIDR基本上提供两种服务：
o Origin validation, described in RFC 6811 [5], seeks to make sure that attributes associated with routes are correct. (The major point is the validation of the AS number originating a given route.) Origin validation is now operational (Internet
o RFC 6811[5]中描述的原产地验证旨在确保与路线相关的属性是正确的。（主要的一点是验证源自给定路线的AS编号。）原点验证现在可以运行（互联网）
registries, protocols, implementations on some routers), and in theory it can be implemented knowing that the number of signed resources is still low at the time of writing this document.
注册中心、协议、某些路由器上的实现），理论上，在编写本文档时，在知道已签名资源的数量仍然很低的情况下，可以实现它。
o Path validation provided by BGPsec [29] seeks to make sure that no one announces fake/wrong BGP paths that would attract traffic for a given destination; see RFC 7132 [16]. BGPsec is still an ongoing work item at the time of writing this document and therefore cannot be implemented.
o BGPsec[29]提供的路径验证旨在确保没有人宣布会吸引给定目的地流量的伪造/错误BGP路径；参见RFC 7132[16]。在编写本文件时，BGPsec仍然是一个正在进行的工作项目，因此无法实施。
Implementing SIDR mechanisms is expected to solve many of the BGP routing security problems in the long term, but it may take time for deployments to be made and objects to become signed. Also, note that the SIDR infrastructure is complementing (not replacing) the security best practices listed in this document. Therefore, network administrators SHOULD implement any SIDR proposed mechanism (for example, route origin validation) on top of the other existing mechanisms even if they could sometimes appear to be targeting the same goal.
从长远来看，实现SIDR机制有望解决许多BGP路由安全问题，但部署和对象签名可能需要时间。另外，请注意，SIDR基础设施是对本文档中列出的安全最佳实践的补充（而不是替代）。因此，网络管理员应在其他现有机制的基础上实施任何SIDR建议的机制（例如，路由来源验证），即使它们有时可能以相同的目标为目标。
If route origin validation is implemented, the reader SHOULD refer to the rules described in RFC 7115 [15]. In short, each external route received on a router SHOULD be checked against the Resource Public Key Infrastructure (RPKI) data set:
如果实施了路线起点验证，读者应参考RFC 7115[15]中描述的规则。简言之，应根据资源公钥基础设施（RPKI）数据集检查路由器上接收的每个外部路由：
o If a corresponding ROA (Route Origin Authorization) is found and is valid, then the prefix SHOULD be accepted.
o 如果找到相应的ROA（路由来源授权）且该ROA有效，则应接受前缀。
o If the ROA is found and is INVALID, then the prefix SHOULD be discarded.
o 如果找到ROA且该ROA无效，则应丢弃前缀。
o If a ROA is not found, then the prefix SHOULD be accepted, but the corresponding route SHOULD be given a low preference.
o 如果未找到ROA，则应接受前缀，但应给予相应路由较低的优先权。
In addition to this, network administrators SHOULD sign their routing objects so their routes can be validated by other networks running origin validation.
除此之外，网络管理员还应该对其路由对象进行签名，以便运行源验证的其他网络可以验证其路由。
One should understand that the RPKI model brings new, interesting challenges. The paper "On the Risk of Misbehaving RPKI Authorities" [31] explains how the RPKI model can impact the Internet if authorities don't behave as they are supposed to. Further analysis is certainly required on RPKI, which carries part of BGP security.
我们应该理解，RPKI模型带来了新的、有趣的挑战。“关于RPKI当局行为不端的风险”一文[31]解释了如果当局不按照他们的预期行事，RPKI模型会如何影响互联网。当然需要对RPKI进行进一步的分析，它承载了BGP安全的一部分。
Most ISPs will not accept advertisements beyond a certain level of specificity (and in return, they do not announce prefixes they consider to be too specific). That acceptable specificity is decided for each peering between the two BGP peers. Some ISP communities have tried to document acceptable specificity. This document does not make any judgement on what the best approach is, it just notes that there are existing practices on the Internet and recommends that the reader refer to them. As an example, the RIPE community has documented that, at the time of writing of this document, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet [20] [21]. These values may change in the future.
大多数ISP不会接受超过一定水平的广告（作为回报，他们不会公布他们认为过于具体的前缀）。对于两个BGP对等点之间的每个对等点，确定可接受的特异性。一些ISP社区试图记录可接受的特定性。本文件并未对最佳方法作出任何判断，只是指出互联网上存在一些现有做法，并建议读者参考这些做法。例如，成熟社区已证明，在撰写本文件时，互联网上通常既没有公布也没有接受长度超过/24的IPv4前缀和长度超过/48的IPv6前缀[20][21]。这些值将来可能会改变。
A network SHOULD filter its own prefixes on peerings with all its peers (inbound direction). This prevents local traffic (from a local source to a local destination) from leaking over an external peering, in case someone else is announcing the prefix over the Internet. This also protects the infrastructure that may directly suffer if the backbone's prefix is suddenly preferred over the Internet.
网络应该在与所有对等方的对等上过滤自己的前缀（入站方向）。这可以防止本地通信（从本地源到本地目标）通过外部对等泄漏，以防其他人通过Internet宣布前缀。这还可以保护基础设施，如果骨干网的前缀突然成为首选，那么基础设施可能会直接受到影响。
In some cases, for example, multihoming scenarios, such filters SHOULD NOT be applied, as this would break the desired redundancy.
在某些情况下，例如，在多主场景中，不应应用此类过滤器，因为这会破坏所需的冗余。
To an extent, such filters can also be configured on a network for the prefixes of its downstreams in order to protect them, too. Such filters must be defined with caution as they can break existing redundancy mechanisms. For example, when an operator has a multihomed customer, it should keep accepting the customer prefix from its peers and upstreams. This will make it possible for the customer to keep accessing its operator network (and other customers) via the Internet even if the BGP peering between the customer and the operator is down.
在某种程度上，也可以在网络上为其下游的前缀配置这样的过滤器，以保护它们。必须谨慎定义此类过滤器，因为它们可能会破坏现有的冗余机制。例如，当运营商拥有多址客户时，它应该继续接受来自其对等方和上游的客户前缀。这将使客户能够通过互联网继续访问其运营商网络（和其他客户），即使客户和运营商之间的BGP对等已关闭。
When a network is present on an IXP and peers with other IXP members over a common subnet (IXP LAN prefix), it SHOULD NOT accept more-specific prefixes for the IXP LAN prefix from any of its external BGP peers. Accepting these routes may create a black hole for connectivity to the IXP LAN.
当网络存在于IXP上并且通过公共子网（IXP LAN前缀）与其他IXP成员对等时，它不应接受来自任何外部BGP对等的IXP LAN前缀的更具体前缀。接受这些路由可能会为IXP LAN的连接创建一个黑洞。
If the IXP LAN prefix is accepted as an "exact match", care needs to be taken to prevent other routers in the network from sending IXP traffic towards the externally learned IXP LAN prefix (recursive route lookup pointing into the wrong direction). This can be achieved by preferring IGP routes over External BGP (EBGP), or by using "BGP next-hop-self" on all routes learned on that IXP.
如果IXP LAN前缀被接受为“精确匹配”，则需要注意防止网络中的其他路由器向外部学习的IXP LAN前缀发送IXP流量（指向错误方向的递归路由查找）。这可以通过优先选择IGP路由而不是外部BGP（EBGP）来实现，或者通过在该IXP上学习的所有路由上使用“BGP下一跳自”来实现。
If the IXP LAN prefix is accepted at all, it SHOULD only be accepted from the ASes that the IXP authorizes to announce it -- this will usually be automatically achieved by filtering announcements using the IRR database.
如果IXP LAN前缀完全被接受，那么它应该只从IXP授权发布它的ASE接受——这通常会通过使用IRR数据库过滤发布来自动实现。
In order to have PMTUD working in the presence of loose uRPF, it is necessary that all the networks that may source traffic that could flow through the IXP (i.e., IXP members and their downstreams) have a route for the IXP LAN prefix. This is necessary as "packet too big" ICMP messages sent by IXP members' routers may be sourced using an address of the IXP LAN prefix. In the presence of loose uRPF, this ICMP packet is dropped if there is no route for the IXP LAN prefix or a less specific route covering IXP LAN prefix.
为了使PMTUD在松散的uRPF存在的情况下工作，所有可能产生可能流经IXP的流量的网络（即IXP成员及其下游）都必须具有IXP LAN前缀的路由。这是必要的，因为IXP成员路由器发送的“数据包太大”ICMP消息可能使用IXP LAN前缀的地址来源。在存在松散uRPF的情况下，如果没有用于IXP LAN前缀的路由或覆盖IXP LAN前缀的不太具体的路由，则丢弃此ICMP数据包。
In that case, any IXP member SHOULD make sure it has a route for the IXP LAN prefix or a less specific prefix on all its routers and that it announces the IXP LAN prefix or the less specific route (up to a default route) to its downstreams. The announcements done for this purpose SHOULD pass IRR-generated filters described in Section 6.1.2.2.1 as well as "prefixes that are too specific" filters described in Section 6.1.3. The easiest way to implement this is for the IXP itself to take care of the origination of its prefix and advertise it to all IXP members through a BGP peering. Most likely, the BGP route servers would be used for this, and the IXP would send its entire prefix, which would be equal to or less specific than the IXP LAN prefix.
在这种情况下，任何IXP成员应确保其所有路由器上都有IXP LAN前缀或不太特定的前缀的路由，并向其下游宣布IXP LAN前缀或不太特定的路由（最多为默认路由）。为此目的所做的公告应通过第6.1.2.2.1节所述IRR生成的过滤器以及第6.1.3节所述的“过于具体的前缀”过滤器。实现这一点的最简单方法是IXP本身负责其前缀的起源，并通过BGP对等将其通告给所有IXP成员。最有可能的情况是，BGP路由服务器将用于此目的，而IXP将发送其整个前缀，该前缀将等于或低于IXP LAN前缀。
Appendix A gives an example of guidelines regarding IXP LAN prefix.
附录A给出了有关IXP LAN前缀的指南示例。
Typically, the 0.0.0.0/0 prefix is not intended to be accepted or advertised except in specific customer/provider configurations; general filtering outside of these is RECOMMENDED.
通常，0.0.0.0/0前缀不打算被接受或公布，除非在特定的客户/提供商配置中；建议在这些范围之外进行常规过滤。
Typically, the ::/0 prefix is not intended to be accepted or advertised except in specific customer/provider configurations; general filtering outside of these is RECOMMENDED.
通常，除非在特定的客户/提供商配置中，否则不接受或公布：：/0前缀；建议在这些范围之外进行常规过滤。
For networks that have the full Internet BGP table, some policies should be applied on each BGP peer for received and advertised routes. It is RECOMMENDED that each Autonomous System configures rules for advertised and received routes at all its borders, as this will protect the network and its peer even in case of misconfiguration. The most commonly used filtering policy is proposed in this section and uses prefix filters defined in Section 6.1.
对于具有完整的Internet BGP表的网络，对于接收和公布的路由，应在每个BGP对等方上应用一些策略。建议每个自治系统在其所有边界处为广告和接收的路由配置规则，因为这样即使在配置错误的情况下也能保护网络及其对等方。本节提出了最常用的过滤策略，并使用第6.1节中定义的前缀过滤器。
There are basically two options -- the loose one where no check will be done against RIR allocations and the strict one where it will be verified that announcements strictly conform to what is declared in routing registries.
基本上有两种选择——松散的一种是不对RIR分配进行检查，严格的一种是验证公告是否严格符合路由注册中声明的内容。
In this case, the following prefixes received from a BGP peer will be filtered:
在这种情况下，将过滤从BGP对等方接收的以下前缀：
o prefixes that are not globally routable (Section 6.1.1)
o 不可全局路由的前缀（第6.1.1节）
o prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1)
o IANA未分配的前缀（仅限IPv6）（第6.1.2.1节）
o routes that are too specific (Section 6.1.3)
o 过于具体的路线（第6.1.3节）
o prefixes belonging to the local AS (Section 6.1.4)
o 属于本地AS的前缀（第6.1.4节）
o IXP LAN prefixes (Section 6.1.5)
o IXP LAN前缀（第6.1.5节）
o the default route (Section 6.1.6)
o 默认路线（第6.1.6节）
In this case, filters are applied to make sure advertisements strictly conform to what is declared in routing registries (Section 6.1.2.2). Warning is given as registries are not always
在这种情况下，应用过滤器以确保广告严格符合路由注册表中声明的内容（第6.1.2.2节）。由于注册表并不总是
accurate (prefixes missing, wrong information, etc.). This varies across the registries and regions of the Internet. Before applying a strict policy, the reader SHOULD check the impact on the filter and make sure the solution is not worse than the problem.
准确（前缀丢失、信息错误等）。这在互联网的不同注册处和地区有所不同。在应用严格的策略之前，读者应该检查对过滤器的影响，并确保解决方案不会比问题更糟。
Also, in case of script failure, each administrator may decide if all routes are accepted or rejected depending on routing policy. While accepting the routes during that time frame could break the BGP routing security, rejecting them might re-route too much traffic on transit peers, and could cause more harm than what a loose policy would have done.
此外，在脚本失败的情况下，每个管理员可以根据路由策略决定是否接受或拒绝所有路由。虽然在该时间段内接受路由可能会破坏BGP路由安全性，但拒绝它们可能会在公交节点上重新路由过多的流量，并可能造成比宽松策略更大的伤害。
In addition to this, network administrators could apply the following filters beforehand in case the routing registry that's used as the source of information by the script is not fully trusted:
除此之外，如果脚本用作信息源的路由注册表不完全受信任，网络管理员可以预先应用以下筛选器：
o prefixes that are not globally routable (Section 6.1.1)
o 不可全局路由的前缀（第6.1.1节）
o routes that are too specific (Section 6.1.3)
o 过于具体的路线（第6.1.3节）
o prefixes belonging to the local AS (Section 6.1.4)
o 属于本地AS的前缀（第6.1.4节）
o IXP LAN prefixes (Section 6.1.5)
o IXP LAN前缀（第6.1.5节）
o the default route (Section 6.1.6)
o 默认路线（第6.1.6节）
The configuration should ensure that only appropriate prefixes are sent. These can be, for example, prefixes belonging to both the network in question and its downstreams. This can be achieved by using BGP communities, AS paths, or both. Also, it may be desirable to add the following filters before any policy to avoid unwanted route announcements due to bad configuration:
配置应确保只发送适当的前缀。例如，这些前缀可以是属于所讨论的网络及其下游的前缀。这可以通过使用BGP社区、作为路径或两者都使用来实现。此外，可能需要在任何策略之前添加以下过滤器，以避免由于错误配置而导致不必要的路线公告：
o Prefixes that are not globally routable (Section 6.1.1)
o 不可全局路由的前缀（第6.1.1节）
o Routes that are too specific (Section 6.1.3)
o 过于具体的路线（第6.1.3节）
o IXP LAN prefixes (Section 6.1.5)
o IXP LAN前缀（第6.1.5节）
o The default route (Section 6.1.6)
o 默认路线（第6.1.6节）
If it is possible to list the prefixes to be advertised, then just configuring the list of allowed prefixes and denying the rest is sufficient.
如果可以列出要公布的前缀，那么只需配置允许的前缀列表并拒绝其余前缀就足够了。
The inbound policy with end customers is pretty straightforward: only customer prefixes SHOULD be accepted, all others SHOULD be discarded. The list of accepted prefixes can be manually specified, after having verified that they are valid. This validation can be done with the appropriate IP address management authorities.
针对最终客户的入站策略非常简单：只接受客户前缀，而放弃所有其他前缀。可接受的前缀列表可以在验证其有效性后手动指定。此验证可通过适当的IP地址管理机构完成。
The same rules apply when the customer is a network connecting other customers (for example, a Tier 1 transit provider connecting service providers). An exception is when the customer network applies strict inbound/outbound prefix filtering, and there are too many prefixes announced by that network to list them in the router configuration. In that case, filters as in Section 6.2.1.1 can be applied.
当客户是连接其他客户的网络时（例如，连接服务提供商的一级运输提供商），同样的规则也适用。例外情况是，当客户网络应用严格的入站/出站前缀过滤，并且该网络宣布的前缀太多，无法在路由器配置中列出它们时。在这种情况下，可使用第6.2.1.1节中的过滤器。
The outbound policy with customers may vary according to the routes the customer wants to receive. In the simplest possible scenario, the customer may want to receive only the default route; this can be done easily by applying a filter with the default route only.
与客户的出站策略可能因客户希望接收的路线而异。在最简单的情况下，客户可能只希望接收默认路线；这可以通过仅应用带有默认路由的筛选器轻松完成。
In case the customer wants to receive the full routing (if it is multihomed or if it wants to have a view of the Internet table), the following filters can be applied on the BGP peering:
如果客户希望接收完整路由（如果是多址路由或如果希望查看Internet表），则可以在BGP对等上应用以下筛选器：
o prefixes that are not globally routable (Section 6.1.1)
o 不可全局路由的前缀（第6.1.1节）
o routes that are too specific (Section 6.1.3)
o 过于具体的路线（第6.1.3节）
o the default route (Section 6.1.6)
o 默认路线（第6.1.6节）
In some cases, the customer may desire to receive the default route in addition to the full BGP table. This can be done by the provider simply by removing the filter for the default route. As the default route may not be present in the routing table, network administrators may decide to originate it only for peerings where it has to be advertised.
在某些情况下，客户可能希望接收完整BGP表之外的默认路由。提供程序只需删除默认路由的筛选器即可完成此操作。由于默认路由可能不在路由表中，网络管理员可能会决定仅在需要公布的对等网络中发起默认路由。
If the full routing table is desired from the upstream, the prefix filtering to apply is the same as the one for peers Section 6.2.1.1 with the exception of the default route. Sometimes, the default
如果需要从上游获得完整的路由表，则要应用的前缀过滤与第6.2.1.1节中针对对等方的过滤相同，但默认路由除外。有时，默认值
route (in addition to the full BGP table) can be desired from an upstream provider. If the upstream provider is supposed to announce only the default route, a simple filter will be applied to accept only the default prefix and nothing else.
可以从上游提供商处获得路由（除了完整的BGP表）。如果上游提供者应该只宣布默认路由，那么将应用一个简单的过滤器，只接受默认前缀，而不接受其他内容。
The filters to be applied would most likely not differ much from the ones applied for Internet peers (Section 6.2.1.2). However, different policies could be applied if a particular upstream should not provide transit to all the prefixes.
应用的过滤器很可能与应用于互联网对等方的过滤器差别不大（第6.2.1.2节）。但是，如果某个特定的上游不应向所有前缀提供中转，则可以应用不同的策略。
The leaf network will deploy the filters corresponding to the routes it is requesting from its upstream. If a default route is requested, a simple inbound filter can be applied to accept only the default route (Section 6.1.6). If the leaf network is not capable of listing the prefixes because there are too many (for example, if it requires the full Internet routing table), then it should configure the following filters to avoid receiving bad announcements from its upstream:
叶网络将根据其从上游请求的路由部署过滤器。如果请求默认路由，可以应用简单的入站筛选器，以仅接受默认路由（第6.1.6节）。如果叶网络由于前缀太多而无法列出前缀（例如，如果它需要完整的Internet路由表），则应配置以下筛选器以避免从其上游接收坏消息：
o prefixes not routable (Section 6.1.1)
o 前缀不可路由（第6.1.1节）
o routes that are too specific (Section 6.1.3)
o 过于具体的路线（第6.1.3节）
o prefixes belonging to local AS (Section 6.1.4)
o 属于本地AS的前缀（第6.1.4节）
o the default route (Section 6.1.6) depending on whether or not the route is requested
o 默认路由（第6.1.6节）取决于是否请求路由
A leaf network will most likely have a very straightforward policy: it will only announce its local routes. It can also configure the prefix filters described in Section 6.2.1.2 to avoid announcing invalid routes to its upstream provider.
leaf网络很可能有一个非常简单的策略：它只会宣布其本地路由。它还可以配置第6.2.1.2节中描述的前缀过滤器，以避免向其上游提供商宣布无效路由。
The BGP route flap dampening mechanism makes it possible to give penalties to routes each time they change in the BGP routing table. Initially, this mechanism was created to protect the entire Internet from multiple events that impact a single network. Studies have shown that implementations of BGP route flap dampening could cause
BGP路由襟翼阻尼机制可以在每次路由在BGP路由表中更改时对其进行惩罚。最初，创建此机制是为了保护整个互联网免受影响单个网络的多个事件的影响。研究表明，BGP路由襟翼阻尼的实现可能导致
more harm than benefit; therefore, in the past, the RIPE community has recommended against using BGP route flap dampening [19]. Later, studies were conducted to propose new route flap dampening thresholds in order to make the solution "usable"; see RFC 7196 [6] and [22] (in which RIPE reviewed its recommendations). This document RECOMMENDS following IETF and RIPE recommendations and using BGP route flap dampening with the adjusted configured thresholds.
弊大于利；因此，在过去，成熟社区建议不要使用BGP路由襟翼阻尼[19]。后来，进行了研究，提出了新的路线襟翼阻尼阈值，以使解决方案“可用”；参见RFC 7196[6]和[22]（其中RIME审查了其建议）。本文件建议遵循IETF和CREAME建议，并使用BGP路由襟翼阻尼和调整后的配置阈值。
It is RECOMMENDED to configure a limit on the number of routes to be accepted from a peer. The following rules are generally RECOMMENDED:
建议配置对从对等方接受的路由数量的限制。一般建议遵循以下规则：
o From peers, it is RECOMMENDED to have a limit lower than the number of routes in the Internet. This will shut down the BGP peering if the peer suddenly advertises the full table. Network administrators can also configure different limits for each peer, according to the number of routes they are supposed to advertise, plus some headroom to permit growth.
o 对于同行，建议其限制低于Internet中的路由数。如果BGP对等方突然播发整个表，则会关闭BGP对等方。网络管理员还可以根据他们应该公布的路由数量以及允许增长的净空，为每个对等点配置不同的限制。
o From upstreams that provide full routing, it is RECOMMENDED to have a limit higher than the number of routes in the Internet. A limit is still useful in order to protect the network (and in particular, the routers' memory) if too many routes are sent by the upstream. The limit should be chosen according to the number of routes that can actually be handled by routers.
o 对于提供完整路由的上游，建议具有高于Internet中路由数的限制。如果上游发送的路由过多，则限制仍然有用，以保护网络（尤其是路由器的内存）。限制应该根据路由器实际可以处理的路由数量来选择。
It is important to regularly review the limits that are configured as the Internet can quickly change over time. Some vendors propose mechanisms to have two thresholds: while the higher number specified will shut down the peering, the first threshold will only trigger a log and can be used to passively adjust limits based on observations made on the network.
定期检查配置的限制非常重要，因为Internet会随着时间的推移快速变化。一些供应商建议采用两个阈值的机制：虽然指定的阈值越高，对等网络将关闭，但第一个阈值只会触发日志，并可用于根据在网络上进行的观察被动调整限制。
This section lists the RECOMMENDED practices when processing BGP AS paths.
本节列出了将BGP作为路径处理时的推荐做法。
o Network administrators SHOULD accept from customers only 2-byte or 4-byte AS paths containing ASNs belonging to (or authorized to transit through) the customer. If network administrators cannot build and generate filtering expressions to implement this, they SHOULD consider accepting only path lengths relevant to the type of customer they have (as in, if these customers are a leaf or have customers of their own) and SHOULD try to discourage excessive prepending in such paths. This loose policy could be
o 网络管理员应仅接受来自客户的2字节或4字节路径，作为包含属于（或授权通过）客户的ASN的路径。如果网络管理员不能建立和生成过滤表达式来实现这一点，那么他们应该考虑只接受与他们拥有的客户类型相关的路径长度（如，如果这些客户是一片叶子或有自己的客户），并且应该设法阻止在这样的路径中过度的提前准备。这种宽松的政策可能是错误的
combined with filters for specific 2-byte or 4-byte AS paths that must not be accepted if advertised by the customer, such as upstream transit providers or peer ASNs.
与特定2字节或4字节AS路径的过滤器相结合，这些路径在客户发布广告时不得被接受，如上游运输提供商或对等ASN。
o Network administrators SHOULD NOT accept prefixes with private AS numbers in the AS path unless the prefixes are from customers. An exception could occur when an upstream is offering some particular service like black-hole origination based on a private AS number: in that case, prefixes SHOULD be accepted. Customers should be informed by their upstream in order to put in place ad hoc policy to use such services.
o 网络管理员不应接受AS路径中带有专用AS编号的前缀，除非前缀来自客户。当上游基于私有AS编号提供某些特定服务（如黑洞起源）时，可能会发生异常：在这种情况下，应接受前缀。上游应通知客户，以便制定使用此类服务的特别政策。
o Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path is not the one of the peer's unless the peering is done toward a BGP route server [17] (for example, on an IXP) with transparent AS path handling. In that case, this verification needs to be deactivated, as the first AS number will be the one of an IXP member, whereas the peer AS number will be the one of the BGP route server.
o 当AS路径中的第一个AS编号不是对等方的AS编号时，网络管理员不应接受前缀，除非使用透明AS路径处理朝BGP路由服务器[17]（例如，在IXP上）进行对等。在这种情况下，需要停用此验证，因为第一个as编号将是IXP成员的编号，而对等as编号将是BGP路由服务器的编号。
o Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless they intend to provide transit for these prefixes.
o 网络管理员不应使用非空AS路径播发前缀，除非他们打算为这些前缀提供传输。
o Network administrators SHOULD NOT advertise prefixes with upstream AS numbers in the AS path to their peering AS unless they intend to provide transit for these prefixes.
o 除非网络管理员打算为这些前缀提供传输，否则不应在其对等AS的AS路径中公布带有上游AS编号的前缀。
o Private AS numbers are conventionally used in contexts that are "private" and SHOULD NOT be used in advertisements to BGP peers that are not party to such private arrangements, and they SHOULD be stripped when received from BGP peers that are not party to such private arrangements.
o 私人AS号码通常用于“私人”的上下文中，不应用于向未参与此类私人安排的BGP对等方发布的广告中，并且当从未参与此类私人安排的BGP对等方收到这些号码时，应将其删除。
o Network administrators SHOULD NOT override BGP's default behavior, i.e., they should not accept their own AS number in the AS path. When considering an exception, the impact (which may be severe on routing) should be studied carefully.
o 网络管理员不应覆盖BGP的默认行为，即，他们不应在AS路径中接受自己的AS编号。在考虑例外情况时，应仔细研究影响（可能对路由造成严重影响）。
AS path filtering should be further analyzed when ASN renumbering is done. Such an operation is common, and mechanisms exist to allow smooth ASN migration [28]. The usual migration technique, local to a router, consists in modifying the AS path so it is presented to a peer with the previous ASN, as if no renumbering was done. This makes it possible to change the ASN of a router without reconfiguring all EBGP peers at the same time (as that operation would require synchronization with all peers attached to that router). During this renumbering operation, the rules described above may be adjusted.
ASN重新编号时，应进一步分析AS路径过滤。这种操作很常见，并且存在允许ASN平滑迁移的机制[28]。路由器本地的常见迁移技术包括修改AS路径，以便将其呈现给具有先前ASN的对等方，就好像没有进行重新编号一样。这使得在不同时重新配置所有EBGP对等点的情况下更改路由器的ASN成为可能（因为该操作需要与连接到该路由器的所有对等点同步）。在该重新编号操作期间，可以调整上述规则。
If peering on a shared network, like an IXP, BGP can advertise prefixes with a third-party next hop, thus directing packets not to the peer announcing the prefix but somewhere else.
如果在共享网络（如IXP）上进行对等，BGP可以向第三方下一跳播发前缀，从而将数据包定向到其他地方，而不是向宣布前缀的对等方。
This is a desirable property for BGP route-server setups [17], where the route server will relay routing information but has neither the capacity nor the desire to receive the actual data packets. So, the BGP route server will announce prefixes with a next-hop setting pointing to the router that originally announced the prefix to the route server.
这是BGP路由服务器设置的理想属性[17]，其中路由服务器将中继路由信息，但既没有容量也不希望接收实际数据包。因此，BGP路由服务器将使用指向最初向路由服务器宣布前缀的路由器的下一跳设置来宣布前缀。
In direct peerings between ISPs, this is undesirable, as one of the peers could trick the other one into sending packets into a black hole (unreachable next hop) or to an unsuspecting third party who would then have to carry the traffic. Especially for black-holing, the root cause of the problem is hard to see without inspecting BGP prefixes at the receiving router of the IXP.
在ISP之间的直接对等中，这是不可取的，因为其中一个对等方可能会欺骗另一个，使其将数据包发送到黑洞（下一跳无法到达）或发送给一个毫无戒心的第三方，而该第三方随后将不得不承载流量。特别是对于黑洞，如果不检查IXP接收路由器上的BGP前缀，很难发现问题的根本原因。
Therefore, an inbound route policy SHOULD be applied on IXP peerings in order to set the next hop for accepted prefixes to the BGP peer IP address (belonging to the IXP LAN) that sent the prefix (which is what "next-hop-self" would enforce on the sending side).
因此，应在IXP对等上应用入站路由策略，以便将接受前缀的下一跳设置为发送前缀的BGP对等IP地址（属于IXP LAN）（这是“下一跳自我”将在发送端强制执行的）。
This policy SHOULD NOT be used on route-server peerings or on peerings where network administrators intentionally permit the other side to send third-party next hops.
此策略不应用于路由服务器对等或网络管理员有意允许另一方发送第三方下一跳的对等。
This policy also SHOULD be adjusted if the best practice of Remote Triggered Black Holing (aka RTBH as described in RFC 6666 [13]) is implemented. In that case, network administrators would apply a well-known BGP next hop for routes they want to filter (if an Internet threat is observed from/to this route, for example). This well-known next hop will be statically routed to a null interface. In combination with a unicast RPF check, this will discard traffic from and toward this prefix. Peers can exchange information about black holes using, for example, particular BGP communities. Network administrators could propagate black-hole information to their peers using an agreed-upon BGP community: when receiving a route with that community, a configured policy could change the next hop in order to create the black hole.
如果实施远程触发黑洞（RFC 6666[13]中所述的RTBH）的最佳实践，也应调整该政策。在这种情况下，网络管理员将为他们想要筛选的路由应用一个众所周知的BGP下一跳（例如，如果观察到来自/到该路由的互联网威胁）。这个众所周知的下一跳将静态路由到空接口。结合单播RPF检查，这将丢弃来自和朝向该前缀的通信量。对等方可以使用特定的BGP社区交换有关黑洞的信息。网络管理员可以使用商定的BGP社区将黑洞信息传播给他们的对等方：当接收到该社区的路由时，配置的策略可以更改下一跳以创建黑洞。
Optionally, we can consider the following rules on BGP AS paths:
可选地，我们可以在BGP上考虑以下规则作为路径：
o Network administrators SHOULD scrub inbound communities with their number in the high-order bits, and allow only those communities that customers/peers can use as a signaling mechanism
o 网络管理员应将入站社区的编号保留在高位，并仅允许客户/对等方将这些社区用作信令机制
o Networks administrators SHOULD NOT remove other communities applied on received routes (communities not removed after application of the previous statement). In particular, they SHOULD keep original communities when they apply a community. Customers might need them to communicate with upstream providers. In particular, network administrators SHOULD NOT (generally) remove the no-export community, as it is usually announced by their peer for a certain purpose.
o 网络管理员不应删除已接收路由上应用的其他社区（在应用上一条语句后未删除的社区）。特别是，他们在申请社区时应保留原始社区。客户可能需要他们与上游供应商沟通。特别是，网络管理员不应该（通常）删除no export社区，因为它通常是由他们的对等方出于某种目的宣布的。
This document is entirely about BGP operational security. It depicts best practices that one should adopt to secure BGP infrastructure: protecting BGP router and BGP sessions, adopting consistent BGP prefix and AS path filters, and configuring other options to secure the BGP network.
本文档完全是关于BGP操作安全的。它描述了保护BGP基础设施应采用的最佳实践：保护BGP路由器和BGP会话，采用一致的BGP前缀和AS路径筛选器，以及配置其他选项以保护BGP网络。
This document does not aim to describe existing BGP implementations, their potential vulnerabilities, or ways they handle errors. It does not detail how protection could be enforced against attack techniques using crafted packets.
本文档的目的不是描述现有BGP实施、潜在漏洞或处理错误的方式。它没有详细说明如何使用特制的数据包对攻击技术实施保护。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月<http://www.rfc-editor.org/info/rfc2119>.
[2] Rekhter,, Y., Li,, T., and S. Hares,, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[2] Rekhter，Y.，Li，，T.，和S.Hares，，“边境网关协议4（BGP-4）”，RFC 42712006年1月<http://www.rfc-editor.org/info/rfc4271>.
[3] Gill, V., Heasley, J., Meyer, D., Savola,, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[3] Gill，V.，Heasley，J.，Meyer，D.，Savola，，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月<http://www.rfc-editor.org/info/rfc5082>.
[4] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[4] Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月<http://www.rfc-editor.org/info/rfc5925>.
[5] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013, <http://www.rfc-editor.org/info/rfc6811>.
[5] Mohapatra，P.，Scudder，J.，Ward，D.，Bush，R.，和R.Austein，“BGP前缀来源验证”，RFC 68112013年1月<http://www.rfc-editor.org/info/rfc6811>.
[6] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. Maennel, "Making Route Flap Damping Usable", RFC 7196, May 2014, <http://www.rfc-editor.org/info/rfc7196>.
[6] Pelsser，C.，Bush，R.，Patel，K.，Mohapatra，P.，和O.Maennel，“使路线襟翼阻尼可用”，RFC 71962014年5月<http://www.rfc-editor.org/info/rfc7196>.
[7] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998, <http://www.rfc-editor.org/info/rfc2385>.
[7] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月<http://www.rfc-editor.org/info/rfc2385>.
[8] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[8] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，RFC 2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", RFC 3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[9] Baker，F.和P.Savola，“多址网络的入口过滤”，RFC 37042004年3月<http://www.rfc-editor.org/info/rfc3704>.
[10] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005, <http://www.rfc-editor.org/info/rfc4012>.
[10] Blunk，L.，Damas，J.，Parent，F.，和A.Robachevsky，“下一代路由策略规范语言（RPSLng）”，RFC4012，2005年3月<http://www.rfc-editor.org/info/rfc4012>.
[11] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.
[11] Dugal，D.，Pignataro，C.，和R.Dunn，“保护路由器控制平面”，RFC 61922011年3月<http://www.rfc-editor.org/info/rfc6192>.
[12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[12] Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 64802012年2月<http://www.rfc-editor.org/info/rfc6480>.
[13] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", RFC 6666, August 2012, <http://www.rfc-editor.org/info/rfc6666>.
[13] Hilliard，N.和D.Freedman，“IPv6的丢弃前缀”，RFC 66662012年8月<http://www.rfc-editor.org/info/rfc6666>.
[14] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[14] Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月<http://www.rfc-editor.org/info/rfc6952>.
[15] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", RFC 7115, January 2014, <http://www.rfc-editor.org/info/rfc7115>.
[15] Bush，R.，“基于资源公钥基础设施（RPKI）的来源验证操作”，RFC 7115，2014年1月<http://www.rfc-editor.org/info/rfc7115>.
[16] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, February 2014, <http://www.rfc-editor.org/info/rfc7132>.
[16] Kent，S.和A.Chi，“BGP路径安全的威胁模型”，RFC 71322014年2月<http://www.rfc-editor.org/info/rfc7132>.
[17] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange Route Server", Work in Progress, draft-ietf-idr-ix-bgp-route-server-06, December 2014.
[17] Jasinska，E.，Hilliard，N.，Raszuk，R.，和N.Bakker，“互联网交换路由服务器”，正在进行的工作，草稿-ietf-idr-ix-bgp-Route-Server-062014年12月。
[18] Karrenberg, D., "RIPE-351 - De-Bogonising New Address Blocks", October 2005.
[18] Karrenberg，D.，“RIMME-351-去Bogonising新地址块”，2005年10月。
[19] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working Group Recommendations On Route-flap Damping", May 2006.
[19] Smith，P.和C.Panigl，“RIME-378-RIME路由工作组关于路由襟翼阻尼的建议”，2006年5月。
[20] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation", December 2006.
[20] Smith，P.，Evans，R.，和M.Hughes，“RIME-399-RIME路由工作组关于路由聚合的建议”，2006年12月。
[21] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation", November 2011.
[21] Smith，P.和R.Evans，“RIME-532-RIME路由工作组关于IPv6路由聚合的建议”，2011年11月。
[22] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE Routing Working Group Recommendations On Route-flap Damping", January 2013.
[22] Smith，P.，Bush，R.，Kuhne，M.，Pelsser，C.，Maennel，O.，Patel，K.，Mohapatra，P.，和R.Evans，“RIME-580-RIME路由工作组关于路由襟翼阻尼的建议”，2013年1月。
[23] IANA, "IANA IPv4 Special-Purpose Address Registry", <http://www.iana.org/assignments/iana-ipv4-special-registry>.
[23] IANA，“IANA IPv4专用地址注册表”<http://www.iana.org/assignments/iana-ipv4-special-registry>.
[24] IANA, "IANA IPv6 Special-Purpose Address Registry", <http://www.iana.org/assignments/iana-ipv6-special-registry>.
[24] IANA，“IANA IPv6专用地址注册表”<http://www.iana.org/assignments/iana-ipv6-special-registry>.
[25] IANA, "IANA IPv4 Address Space Registry", <http://www.iana.org/assignments/ipv4-address-space>.
[25] IANA，“IANA IPv4地址空间注册表”<http://www.iana.org/assignments/ipv4-address-space>.
[26] IANA, "Internet Protocol Version 6 Address Space", <http://www.iana.org/assignments/ipv6-address-space>.
[26] IANA，“互联网协议版本6地址空间”<http://www.iana.org/assignments/ipv6-address-space>.
[27] Merit Network Inc., "Merit RADb", <http://www.radb.net>.
[27] 美德网络公司，“美德无线电广播公司”<http://www.radb.net>.
[28] George, W. and S. Amante, "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Work in Progress, draft-ga-idr-as-migration-03, January 2014.
[28] George，W.和S.Amante，“自主系统（AS）迁移特征及其对BGP AS_路径属性的影响”，正在进行的工作，草稿-ga-idr-AS-Migration-03，2014年1月。
[29] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, August 2014, <http://www.rfc-editor.org/info/rfc7353>.
[29] Bellovin，S.，Bush，R.，和D.Ward，“BGP路径验证的安全要求”，RFC 73532014年8月<http://www.rfc-editor.org/info/rfc7353>.
[30] "IRRToolSet project page", <http://irrtoolset.isc.org>.
[30] “IRRToolSet项目页面”<http://irrtoolset.isc.org>.
[31] Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S. Goldberg, "On the Risk of Misbehaving RPKI Authorities", <http://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf>.
[31] Cooper，D.，Heilman，E.，Brogle，K.，Reyzin，L.，和S.Goldberg，“关于RPKI当局行为不端的风险”<http://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf>。
An IXP in the RIPE region is allocated an IPv4 /22 prefix by RIPE NCC (X.Y.0.0/22 in this example) and uses a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP LAN prefix is the one used by IXP members to configure EBGP peerings. The IXP could also be allocated an AS number (AS64496 in our example).
成熟区域中的IXP由成熟NCC（本例中为X.Y.0.0/22）分配IPv4/22前缀，并将此/22的a/23用于IXP LAN（假设为X.Y.0.0/23）。这个IXP LAN前缀是IXP成员用来配置EBGP对等的前缀。IXP也可以分配一个AS号（在我们的示例中是AS64496）。
Any IXP member SHOULD make sure it filters prefixes more specific than X.Y.0.0/23 from all its EBGP peers. If it received X.Y.0.0/24 or X.Y.1.0/24 this could seriously impact its routing.
任何IXP成员都应该确保从其所有EBGP对等方过滤比X.Y.0.0/23更具体的前缀。如果收到X.Y.0.0/24或X.Y.1.0/24，则可能会严重影响其路由。
The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members through an EBGP peering (most likely from its BGP route servers, configured with AS64496).
IXP应发起X.Y.0.0/22，并通过EBGP对等向其成员发布（最有可能来自其BGP路由服务器，配置为AS64496）。
The IXP members SHOULD accept the IXP prefix only if it passes the IRR generated filters (see Section 6.1.2.2.1)
只有通过IRR生成的过滤器时，IXP成员方应接受IXP前缀（见第6.1.2.2.1节）
IXP members SHOULD then advertise X.Y.0.0/22 prefix to their downstreams. This announce would pass IRR based filters as it is originated by the IXP.
然后，IXP成员应在其下游发布X.Y.0.0/22前缀。该公告将通过基于IRR的过滤器，因为它是由IXP发起的。
Acknowledgements
致谢
The authors would like to thank the following people for their comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues, Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger, and Matsuzaki Yoshinobu.
作者要感谢以下人士的评论和支持：马克·布兰切特、罗恩·博尼卡、兰迪·布什、大卫·弗里德曼、韦斯利·乔治、丹尼尔·金斯堡、大卫·格罗夫斯、迈克·胡格斯、乔尔·贾格利、蒂姆·克莱法斯、沃伦·库马里、雅克·拉图尔、莱昂内尔·莫兰、杰罗姆·尼科尔、哈根·保罗·普费弗、托马斯·皮诺德、卡洛斯·皮格纳塔罗、，Jean Rebiffe、Donald Smith、Kotikalapudi Sriram、Matjaz Straus、Tony Tauber、Gunter Van de Velde、Sebastian Wiesinger和Matsuzaki Yoshinobu。
The authors would like to thank once again Gunter Van de Velde for presenting the document at several IETF meetings in various working groups, indeed helping dissemination of this document and gathering of precious feedback.
作者要再次感谢Gunter Van de Velde在各个工作组的几次IETF会议上介绍了该文件，确实帮助了本文件的传播和宝贵反馈的收集。
Authors' Addresses
作者地址
Jerome Durand Cisco Systems, Inc. 11 rue Camille Desmoulins Issy-les-Moulineaux 92782 CEDEX France
Jerome Durand Cisco Systems，Inc.法国西德克斯卡米尔德斯穆林街11号
EMail: jerduran@cisco.com
EMail: jerduran@cisco.com
Ivan Pepelnjak NIL Data Communications Tivolska 48 Ljubljana 1000 Slovenia
Ivan Pepelnjak NIL数据通信Tivolska 48卢布尔雅那1000斯洛文尼亚
EMail: ip@ipspace.net
EMail: ip@ipspace.net
Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14 Muenchen D-80807 Germany
Gert Doering SpaceNet AG Joseph Dollinger Bogen 14 Muenchen D-80807德国
EMail: gert@space.net
EMail: gert@space.net