Network Working Group D. McPherson
Request for Comments: 4277 Arbor Networks
Category: Informational K. Patel
Cisco Systems
January 2006
Network Working Group D. McPherson
Request for Comments: 4277 Arbor Networks
Category: Informational K. Patel
Cisco Systems
January 2006
Experience with the BGP-4 Protocol
使用BGP-4协议的经验
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
本备忘录旨在记录边境网关协议第4版（BGP-4）如何满足将路由协议发布为互联网标准草案的要求。
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard.
本报告满足RFC 1264第6.0节所述的“第二份报告”要求。为了满足要求，本报告对RFC 1773进行了扩充，并描述了在协议制定为标准草案和提交标准期间获得的额外知识和理解。
Table of Contents
目录
1. Introduction ................................................. 3
2. BGP-4 Overview ............................................... 3
2.1. A Border Gateway Protocol .............................. 3
3. Management Information Base (MIB) ............................ 3
4. Implementation Information ................................... 4
5. Operational Experience ....................................... 4
6. TCP Awareness ................................................ 5
7. Metrics ...................................................... 5
7.1. MULTI_EXIT_DISC (MED) .................................. 5
7.1.1. MEDs and Potatoes .............................. 6
7.1.2. Sending MEDs to BGP Peers ...................... 7
7.1.3. MED of Zero Versus No MED ...................... 7
7.1.4. MEDs and Temporal Route Selection .............. 7
8. Local Preference ............................................. 8
9. Internal BGP In Large Autonomous Systems ..................... 9
10. Internet Dynamics ............................................ 9
11. BGP Routing Information Bases (RIBs) ......................... 10
12. Update Packing ............................................... 10
13. Limit Rate Updates ........................................... 11
13.1. Consideration of TCP Characteristics ................... 11
14. Ordering of Path Attributes .................................. 12
15. AS_SET Sorting ............................................... 12
16. Control Over Version Negotiation ............................. 13
17. Security Considerations ...................................... 13
17.1. TCP MD5 Signature Option ............................... 13
17.2. BGP Over IPsec ......................................... 14
17.3. Miscellaneous .......................................... 14
18. PTOMAINE and GROW ............................................ 14
19. Internet Routing Registries (IRRs) ........................... 15
20. Regional Internet Registries (RIRs) and IRRs, A Bit
of History ................................................... 15
21. Acknowledgements ............................................. 16
22. References ................................................... 17
22.1. Normative References ................................... 17
22.2. Informative References ................................. 17
1. Introduction ................................................. 3
2. BGP-4 Overview ............................................... 3
2.1. A Border Gateway Protocol .............................. 3
3. Management Information Base (MIB) ............................ 3
4. Implementation Information ................................... 4
5. Operational Experience ....................................... 4
6. TCP Awareness ................................................ 5
7. Metrics ...................................................... 5
7.1. MULTI_EXIT_DISC (MED) .................................. 5
7.1.1. MEDs and Potatoes .............................. 6
7.1.2. Sending MEDs to BGP Peers ...................... 7
7.1.3. MED of Zero Versus No MED ...................... 7
7.1.4. MEDs and Temporal Route Selection .............. 7
8. Local Preference ............................................. 8
9. Internal BGP In Large Autonomous Systems ..................... 9
10. Internet Dynamics ............................................ 9
11. BGP Routing Information Bases (RIBs) ......................... 10
12. Update Packing ............................................... 10
13. Limit Rate Updates ........................................... 11
13.1. Consideration of TCP Characteristics ................... 11
14. Ordering of Path Attributes .................................. 12
15. AS_SET Sorting ............................................... 12
16. Control Over Version Negotiation ............................. 13
17. Security Considerations ...................................... 13
17.1. TCP MD5 Signature Option ............................... 13
17.2. BGP Over IPsec ......................................... 14
17.3. Miscellaneous .......................................... 14
18. PTOMAINE and GROW ............................................ 14
19. Internet Routing Registries (IRRs) ........................... 15
20. Regional Internet Registries (RIRs) and IRRs, A Bit
of History ................................................... 15
21. Acknowledgements ............................................. 16
22. References ................................................... 17
22.1. Normative References ................................... 17
22.2. Informative References ................................. 17
The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
本备忘录旨在记录边境网关协议第4版（BGP-4）如何满足将路由协议发布为互联网标准草案的要求。
This report satisfies the requirement for "the second report", as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [RFC1773] and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard.
如[RFC1264]第6.0节所述，本报告满足“第二份报告”的要求。为了满足要求，本报告对[RFC1773]进行了补充，并描述了在协议制定为标准草案和提交标准期间获得的额外知识和理解。
BGP is an inter-autonomous system routing protocol designed for TCP/IP internets. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability, from which routing loops may be pruned and some policy decisions, at the AS level, may be enforced.
BGP是一种为TCP/IP互联网设计的自治系统间路由协议。BGP语音系统的主要功能是与其他BGP系统交换网络可达性信息。该网络可达性信息包括可达性信息所遍历的自治系统（ASE）列表上的信息。这些信息足以为这种可达性构建AS连接图，从中可以修剪路由循环，并在AS级别强制执行一些策略决策。
The initial version of the BGP protocol was published in [RFC1105]. Since then, BGP Versions 2, 3, and 4 have been developed and are specified in [RFC1163], [RFC1267], and [RFC1771], respectively. Changes to BGP-4 after it went to Draft Standard [RFC1771] are listed in Appendix N of [RFC4271].
BGP协议的初始版本发布在[RFC1105]中。从那时起，BGP版本2、3和4已经开发出来，并分别在[RFC1163]、[RFC1267]和[RFC1771]中指定。BGP-4进入标准草案[RFC1771]后的变更列于[RFC4271]的附录N中。
The initial version of the BGP protocol was published in [RFC1105]. BGP version 2 is defined in [RFC1163]. BGP version 3 is defined in [RFC1267]. BGP version 4 is defined in [RFC1771] and [RFC4271]. Appendices A, B, C, and D of [RFC4271] provide summaries of the changes between each iteration of the BGP specification.
BGP协议的初始版本发布在[RFC1105]中。BGP版本2在[RFC1163]中定义。BGP版本3在[RFC1267]中定义。BGP版本4在[RFC1771]和[RFC4271]中定义。[RFC4271]的附录A、B、C和D提供了BGP规范每次迭代之间的变更摘要。
The BGP-4 Management Information Base (MIB) has been published [BGP-MIB]. The MIB was updated from previous versions, which are documented in [RFC1657] and [RFC1269], respectively.
BGP-4管理信息库（MIB）已发布[BGP-MIB]。MIB是从[RFC1657]和[RFC1269]中分别记录的先前版本更新而来的。
Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table.
除了几个系统变量外，BGP MIB被分为两个表：BGP对等表和BGP接收路径属性表。
The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table.
对等表反映有关BGP对等连接的信息，例如它们的状态和当前活动。接收到的路径属性表包含在应用本地路由策略之前从所有对等方接收到的所有属性。用于确定路由的实际属性是所接收属性表的子集。
There are numerous independent interoperable implementations of BGP currently available. Although the previous version of this report provided an overview of the implementations currently used in the operational Internet, at that time it has been suggested that a separate BGP Implementation Report [RFC4276] be generated.
目前有许多可互操作的BGP独立实现。尽管本报告的前一版本概述了当前在运营互联网中使用的实施情况，但当时有人建议生成一份单独的BGP实施报告[RFC4276]。
It should be noted that implementation experience with Cisco's BGP-4 implementation was documented as part of [RFC1656].
应该注意的是，Cisco的BGP-4实施经验记录为[RFC1656]的一部分。
For all additional implementation information please reference [RFC4276].
有关所有其他实施信息，请参考[RFC4276]。
This section discusses operational experience with BGP and BGP-4.
本节讨论BGP和BGP-4的运行经验。
BGP has been used in the production environment since 1989; BGP-4 has been used since 1993. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter-autonomous system routing protocol, is highly heterogeneous. In terms of link bandwidth, it varies from 56 Kbps to 10 Gbps. In terms of the actual routers that run BGP, they range from relatively slow performance, general purpose CPUs to very high performance RISC network processors, and include both special purpose routers and the general purpose workstations that run various UNIX derivatives and other operating systems.
自1989年以来，BGP已用于生产环境；BGP-4自1993年开始使用。BGP的生产使用包括利用协议的所有重要功能。目前的生产环境是高度异构的，其中BGP被用作自治系统间的路由协议。就链路带宽而言，它从56 Kbps到10 Gbps不等。就运行BGP的实际路由器而言，它们的范围从性能相对较慢的通用CPU到性能非常高的RISC网络处理器，包括运行各种UNIX衍生产品和其他操作系统的专用路由器和通用工作站。
In terms of the actual topologies, it varies from very sparse to quite dense. The requirement for full-mesh IBGP topologies has been largely remedied by BGP Route Reflection, Autonomous System Confederations for BGP, and often some mix of the two. BGP Route Reflection was initially defined in [RFC1966] and was updated in [RFC2796]. Autonomous System Confederations for BGP were initially defined in [RFC1965] and were updated in [RFC3065].
就实际拓扑而言，它从非常稀疏到非常密集不等。BGP路由反射、BGP的自治系统联合，以及通常两者的混合，在很大程度上弥补了对全网格IBGP拓扑的需求。BGP路由反射最初在[RFC1966]中定义，并在[RFC2796]中更新。BGP的自治系统联盟最初在[RFC1965]中定义，并在[RFC3065]中更新。
At the time of this writing, BGP-4 is used as an inter-autonomous system routing protocol between all Internet-attached autonomous systems, with nearly 21k active autonomous systems in the global Internet routing table.
在撰写本文时，BGP-4被用作所有互联网连接自治系统之间的自治系统间路由协议，全球互联网路由表中有近21k个活动自治系统。
BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. There is no protocol distinction between sites historically considered "backbones" versus "regional" or "edge" networks.
BGP用于公交和存根自治系统之间的路由信息交换，以及多个公交自治系统之间的路由信息交换。历史上被认为是“主干网”的站点与“区域”或“边缘”网络之间没有协议区别。
The full set of exterior routes carried by BGP is well over 170,000 aggregate entries, representing several times that number of connected networks. The number of active paths in some service provider core routers exceeds 2.5 million. Native AS path lengths are as long as 10 for some routes, and "padded" path lengths of 25 or more autonomous systems exist.
BGP承载的全套外部路由总计超过170000条，相当于连接网络数量的几倍。某些服务提供商核心路由器中的活动路径数超过250万条。对于某些路由，本地AS路径长度长达10，并且存在25个或更多自治系统的“填充”路径长度。
BGP employs TCP [RFC793] as it's Transport Layer protocol. As such, all characteristics inherent to TCP are inherited by BGP.
BGP采用TCP[RFC793]作为其传输层协议。因此，TCP固有的所有特性都由BGP继承。
For example, due to TCP's behavior, bandwidth capabilities may not be realized because of TCP's slow start algorithms and slow-start restarts of connections, etc.
例如，由于TCP的行为，带宽能力可能无法实现，因为TCP的慢启动算法和连接的慢启动重启等。
This section discusses different metrics used within the BGP protocol. BGP has a separate metric parameter for IBGP and EBGP. This allows policy-based metrics to overwrite the distance-based metrics; this allows each autonomous system to define its independent policies in Intra-AS, as well as Inter-AS. BGP Multi Exit Discriminator (MED) is used as a metric by EBGP peers (i.e., inter-domain), while Local Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
本节讨论BGP协议中使用的不同指标。BGP对IBGP和EBGP有一个单独的度量参数。这允许基于策略的度量覆盖基于距离的度量；这允许每个自治系统在内部AS和内部AS中定义其独立的策略。BGP多出口鉴别器（MED）被EBGP对等方（即域间）用作度量，而本地偏好（Local_PREF）被IBGP对等方（即域内）用作度量。
BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_DISC (MED). This value may be used in the tie-breaking process when selecting a preferred path to a given address space, and provides BGP speakers with the capability of conveying the optimal entry point into the local AS to a peer AS.
BGP版本4将旧的AS间指标重新定义为多出口光盘（MED）。当选择到给定地址空间的首选路径时，该值可用于断开连接过程，并为BGP扬声器提供将最佳入口点传送到本地AS到对等AS的能力。
Although the MED was meant to only be used when comparing paths received from different external peers in the same AS, many implementations provide the capability to compare MEDs between different autonomous systems.
虽然MED仅在比较从不同外部对等方接收的路径时使用，但许多实现提供了在不同自治系统之间比较MED的功能。
Though this may seem a fine idea for some configurations, care must be taken when comparing MEDs of different autonomous systems. BGP
尽管对于某些配置来说这似乎是个好主意，但在比较不同自治系统的MED时必须小心。BGP
speakers often derive MED values by obtaining the IGP metric associated with reaching a given BGP NEXT_HOP within the local AS. This allows MEDs to reasonably reflect IGP topologies when advertising routes to peers. While this is fine when comparing MEDs of multiple paths learned from a single adjacent AS, it can result in potentially bad decisions when comparing MEDs of different autonomous systems. This is most typically the case when the autonomous systems use different mechanisms to derive IGP metrics, BGP MEDs, or perhaps even use different IGP protocols with vastly contrasting metric spaces.
说话人通常通过获得与在本地AS内到达给定BGP下一跳相关的IGP度量来获得MED值。这使得MED在向对等方宣传路线时能够合理地反映IGP拓扑。当比较从单个相邻AS学习的多条路径的MED时，这是很好的，但当比较不同自治系统的MED时，可能会导致潜在的错误决策。这是最典型的情况，当自治系统使用不同的机制来推导IGP度量、BGP MED，或者甚至可能使用不同的IGP协议，并且度量空间存在巨大差异时。
Another MED deployment consideration involves the impact of the aggregation of BGP routing information on MEDs. Aggregates are often generated from multiple locations in an AS to accommodate stability, redundancy, and other network design goals. When MEDs are derived from IGP metrics associated with said aggregates, the MED value advertised to peers can result in very suboptimal routing.
MED部署的另一个考虑因素涉及BGP路由信息聚合对MED的影响。聚合通常从AS中的多个位置生成，以适应稳定性、冗余和其他网络设计目标。当MED来自与所述聚合相关联的IGP度量时，向对等方公布的MED值可能导致非常次优的路由。
The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was to ensure that peers could not "shed" or "absorb" traffic for networks they advertise.
MED被故意设计成一个“弱”指标，只能在最佳路径决策过程的后期使用。BGP工作组担心，远程操作员指定的任何指标只会影响本地路由，就好像没有指定其他首选项一样。MED设计的首要目标是确保对等网络不能为其广告的网络“甩”或“吸收”流量。
Where traffic flows between a pair of destinations, each is connected to two transit networks, each of the transit networks has the choice of sending the traffic to the peering closest to another transit provider or passing traffic to the peering that advertises the least cost through the other provider. The former method is called "hot potato routing" because, like a hot potato held in bare hands, whoever has it tries to get rid of it quickly. Hot potato routing is accomplished by not passing the EBGP-learned MED into the IBGP. This minimizes transit traffic for the provider routing the traffic. Far less common is "cold potato routing", where the transit provider uses its own transit capacity to get the traffic to the point in the adjacent transit provider advertised as being closest to the destination. Cold potato routing is accomplished by passing the EBGP-learned MED into IBGP.
当业务在一对目的地之间流动时，每个目的地连接到两个中转网络，每个中转网络都可以选择将业务发送到距离另一个中转提供商最近的对等网络，或者将业务传递到通过另一个提供商宣传最小成本的对等网络。前一种方法被称为“烫手山芋路由”，因为就像赤手空拳抓着一个烫手山芋一样，不管谁拥有它，都会试图很快把它扔掉。烫手山芋路由是通过不将EBGP传入IBGP来完成的。这将最大限度地减少提供商路由流量的传输流量。较不常见的是“冷土豆路线”，即公交服务提供商使用其自身的公交能力将交通量运送到邻近公交服务提供商广告中距离目的地最近的地点。冷土豆路由是通过将EBGP传入IBGP来完成的。
If one transit provider uses hot potato routing and another uses cold potato routing, traffic between the two tends to be symmetric. Depending on the business relationships, if one provider has more capacity or a significantly less congested transit network, then that provider may use cold potato routing. The NSF-funded NSFNET backbone
如果一个公交服务提供商使用热土豆路由，而另一个使用冷土豆路由，那么两者之间的流量往往是对称的。根据业务关系，如果一家提供商的容量更大或交通网络拥挤程度明显降低，则该提供商可能会使用冷土豆路线。NSF资助的NSFNET主干网
and NSF-funded regional networks are examples of widespread use of cold potato routing in the mid 1990s.
NSF资助的区域网络是20世纪90年代中期广泛使用冷土豆路由的例子。
In some cases, a provider may use hot potato routing for some destinations for a given peer AS, and cold potato routing for others. The different treatment of commercial and research traffic in the NSFNET in the mid 1990s is an example of this. However, this might best be described as 'mashed potato routing', a term that reflects the complexity of router configurations in use at the time.
在某些情况下，提供者可能对给定对等AS的某些目的地使用热土豆路由，而对其他目的地使用冷土豆路由。20世纪90年代中期，NSFNET对商业和研究流量的不同处理就是一个例子。然而，最好将其描述为“土豆泥路由”，这一术语反映了当时使用的路由器配置的复杂性。
Seemingly more intuitive references, which fall outside the vegetable kingdom, refer to cold potato routing as "best exit routing", and hot potato routing as "closest exit routing".
看似更直观的参考文献（不属于蔬菜王国）将冷土豆路线称为“最佳出口路线”，将热土豆路线称为“最近的出口路线”。
[RFC4271] allows MEDs received from any EBGP peers by a BGP speaker to be passed to its IBGP peers. Although advertising MEDs to IBGP peers is not a required behavior, it is a common default. MEDs received from EBGP peers by a BGP speaker SHOULD NOT be sent to other EBGP peers.
[RFC4271]允许BGP演讲者从任何EBGP对等方接收的MED传递给其IBGP对等方。尽管向IBGP同行宣传药物不是必需的行为，但这是常见的默认行为。BGP发言人从EBGP对等方收到的MED不应发送给其他EBGP对等方。
Note that many implementations provide a mechanism to derive MED values from IGP metrics to allow BGP MED information to reflect the IGP topologies and metrics of the network when propagating information to adjacent autonomous systems.
注意，许多实现提供了一种从IGP度量中导出MED值的机制，以允许BGP MED信息在向相邻自治系统传播信息时反映网络的IGP拓扑和度量。
[RFC4271] requires an implementation to provide a mechanism that allows MED to be removed. Previously, implementations did not consider a missing MED value the same as a MED of zero. [RFC4271] now requires that no MED value be equal to zero.
[RFC4271]需要一个实现来提供一种允许删除MED的机制。以前，实现没有考虑缺失的MED值与零的MED相同。[RFC4271]现在要求没有中值等于零。
Note that many implementations provide a mechanism to explicitly define a missing MED value as "worst", or less preferable than zero or larger values.
请注意，许多实现提供了一种机制，将缺少的MED值显式定义为“最差”，或者不如零或更大的值。
Some implementations have hooks to apply temporal behavior in MED-based best path selection. That is, all things being equal up to MED consideration, preference would be applied to the "oldest" path, without preference for the lower MED value. The reasoning for this is that "older" paths are presumably more stable, and thus preferable. However, temporal behavior in route selection results in non-deterministic behavior, and as such, may often be undesirable.
一些实现具有挂钩，可以在基于MED的最佳路径选择中应用时间行为。也就是说，在所有条件都等于MED的情况下，优先权将应用于“最早的”路径，而不优先于较低的MED值。其原因是“旧”路径可能更稳定，因此更可取。然而，路由选择中的时间行为导致非确定性行为，因此，通常可能是不可取的。
The LOCAL_PREF attribute was added to enable a network operator to easily configure a policy that overrides the standard best path determination mechanism without independently configuring local preference policy on each router.
添加了LOCAL_PREF属性，使网络运营商能够轻松配置覆盖标准最佳路径确定机制的策略，而无需在每个路由器上独立配置本地首选策略。
One shortcoming in the BGP-4 specification was the suggestion that a default value of LOCAL_PREF be assumed if none was provided. Defaults of zero or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL_PREF is a local administration attribute, there is no interoperability drawback across AS boundaries).
BGP-4规范中的一个缺点是，如果没有提供本地_PREF，则建议假定默认值为LOCAL_PREF。默认值为零或最大值都有范围限制，因此通用默认值将有助于与相同的多供应商路由器的互操作（因为LOCAL_PREF是一个本地管理属性，因此没有跨AS边界的互操作性缺陷）。
[RFC4271] requires that LOCAL_PREF be sent to IBGP Peers and not to EBGP Peers. Although no default value for LOCAL_PREF is defined, the common default value is 100.
[RFC4271]要求将本地_PREF发送给IBGP对等方，而不是EBGP对等方。虽然未定义本地_PREF的默认值，但通用默认值为100。
Another area where exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup.
另一个需要勘探的领域是一种方法，根据该方法，原始AS可能会影响最佳路径选择过程。例如，双连接站点可以选择一个作为主要公交服务提供商，并选择一个作为备份。
/---- transit B ----\
end-customer transit A----
/---- transit C ----\
/---- transit B ----\
end-customer transit A----
/---- transit C ----\
In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider. There is no mechanism to indicate a preference should the third provider wish to respect that preference.
在两个公交服务提供商连接到第三个提供商的拓扑中，真正的决策由第三个提供商执行。如果第三方希望尊重该优先权，则没有任何机制表明该优先权。
A general purpose suggestion has been the possibility of carrying an optional vector, corresponding to the AS_PATH, where each transit AS may indicate a preference value for a given route. Cooperating autonomous systems may then choose traffic based upon comparison of "interesting" portions of this vector, according to routing policy.
一般用途的建议是可能携带与AS_路径相对应的可选向量，其中每个公交AS可能表示给定路线的偏好值。然后，协作自治系统可以根据路由策略，基于该向量的“感兴趣”部分的比较来选择流量。
While protecting a given autonomous systems routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols.
虽然保护给定的自治系统路由策略是最重要的问题，但在未来类似BGP的协议中，需要更仔细地研究避免路由策略的大量手动配置。
While not strictly a protocol issue, another concern has been raised by network operators who need to maintain autonomous systems with a large number of peers. Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by establishing internal BGP connections to all transit and border routers in the local AS.
虽然严格来说这不是一个协议问题，但网络运营商提出了另一个问题，他们需要维护具有大量对等点的自治系统。与外部路由器进行对等的每个说话人负责将可达性和路径信息传播到该AS内的所有其他过境和边界路由器。这通常通过建立与本地AS中所有过境和边界路由器的内部BGP连接来实现。
Note that the number of BGP peers that can be fully meshed depends on a number of factors, including the number of prefixes in the routing system, the number of unique paths, stability of the system, and, perhaps most importantly, implementation efficiency. As a result, although it's difficult to define "a large number of peers", there is always some practical limit.
请注意，可以完全网格化的BGP对等点的数量取决于许多因素，包括路由系统中前缀的数量、唯一路径的数量、系统的稳定性，以及可能最重要的实现效率。因此，尽管很难定义“大量对等点”，但总有一些实际限制。
In a large AS, this leads to a full mesh of TCP connections (n * (n-1)) and some method of configuring and maintaining those connections. BGP does not specify how this information is to be propagated. Therefore, alternatives, such as injecting BGP routing information into the local IGP, have been attempted, but turned out to be non-practical alternatives (to say the least).
在大型AS中，这将导致TCP连接的完整网格（n*（n-1））以及一些配置和维护这些连接的方法。BGP未指定如何传播此信息。因此，已经尝试了替代方案，例如将BGP路由信息注入本地IGP，但结果证明是不实用的替代方案（至少可以这么说）。
To alleviate the need for "full mesh" IBGP, several alternatives have been defined, including BGP Route Reflection [RFC2796] and AS Confederations for BGP [RFC3065].
为了缓解对“全网格”IBGP的需求，已经定义了几种替代方案，包括BGP路由反射[RFC2796]和BGP联盟[RFC3065]。
As discussed in [RFC4274], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet. As the Internet has grown, the frequency of route changes per second has increased.
如[RFC4274]所述，CPU和带宽利用率的驱动力是互联网路由的动态特性。随着互联网的发展，每秒更改路由的频率也在增加。
We automatically get some level of damping when more specific NLRI is aggregated into larger blocks; however, this is not sufficient. In Appendix F of [RFC4271], there are descriptions of damping techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations.
当更具体的NLRI聚合成更大的块时，我们自动获得一定程度的阻尼；然而，这是不够的。在[RFC4271]的附录F中，有应用于广告的阻尼技术的说明。在类似BGP协议的未来规范中，应考虑在兼容实现中强制包含阻尼方法。
BGP Route Flap Damping is defined in [RFC2439]. BGP Route Flap Damping defines a mechanism to help reduce the amount of routing information passed between BGP peers, which reduces the load on these peers without adversely affecting route convergence time for relatively stable routes.
BGP路线襟翼阻尼在[RFC2439]中定义。BGP Route Flap阻尼定义了一种有助于减少BGP对等点之间传递的路由信息量的机制，该机制可以减少这些对等点上的负载，而不会对相对稳定路由的路由收敛时间产生不利影响。
None of the current implementations of BGP Route Flap Damping store route history by unique NRLI or AS Path, although RFC 2439 lists this as mandatory. A potential result of failure to consider each AS Path separately is an overly aggressive suppression of destinations in a densely meshed network, with the most severe consequence being suppression of a destination after a single failure. Because the top tier autonomous systems in the Internet are densely meshed, these adverse consequences are observed.
虽然RFC 2439将此列为强制要求，但BGP路由的当前实现均未按唯一NRLI或AS Path存储路由历史。单独考虑每个路径失败的潜在结果是在密集网状网络中过度地抑制目的地，最严重的后果是在单个故障之后抑制目的地。由于互联网中的顶级自治系统密不可分，因此可以观察到这些不利后果。
Route changes are announced using BGP UPDATE messages. The greatest overhead in advertising UPDATE messages happens whenever route changes to be announced are inefficiently packed. Announcing routing changes that share common attributes in a single BGP UPDATE message helps save considerable bandwidth and reduces processing overhead, as discussed in Section 12, Update Packing.
使用BGP更新消息宣布路由更改。广告更新消息的最大开销发生在将要宣布的路由更改被无效打包时。宣布在单个BGP更新消息中共享公共属性的路由更改有助于节省大量带宽并减少处理开销，如第12节“更新打包”中所述。
Persistent BGP errors may cause BGP peers to flap persistently if peer dampening is not implemented, resulting in significant CPU utilization. Implementors may find it useful to implement peer dampening to avoid such persistent peer flapping [RFC4271].
如果未实施对等抑制，持续的BGP错误可能会导致BGP对等点持续抖动，从而导致显著的CPU利用率。实现者可能会发现，实现对等抑制以避免这种持续的对等抖动非常有用[RFC4271]。
[RFC4271] states "Any local policy which results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table, is outside the scope of this document".
[RFC4271]声明“任何导致路由添加到Adj RIB Out而未添加到本地BGP演讲者转发表的本地策略不在本文件范围内”。
However, several well-known implementations do not confirm that Loc-RIB entries were used to populate the forwarding table before installing them in the Adj-RIB-Out. The most common occurrence of this is when routes for a given prefix are presented by more than one protocol, and the preferences for the BGP-learned route is lower than that of another protocol. As such, the route learned via the other protocol is used to populate the forwarding table.
然而，在Adj RIB Out中安装Loc RIB条目之前，一些著名的实现没有确认Loc RIB条目用于填充转发表。最常见的情况是，给定前缀的路由由多个协议表示，且BGP学习路由的首选项低于另一个协议的首选项。因此，通过其他协议学习的路由用于填充转发表。
It may be desirable for an implementation to provide a knob that permits advertisement of "inactive" BGP routes.
可能希望实现提供允许广告“非活动”BGP路由的旋钮。
It may be also desirable for an implementation to provide a knob that allows a BGP speaker to advertise BGP routes that were not selected in the decision process.
对于一种实现来说，可能还希望提供一个旋钮，该旋钮允许BGP扬声器通告在决策过程中未选择的BGP路由。
Multiple unfeasible routes can be advertised in a single BGP Update message. In addition, one or more feasible routes can be advertised in a single Update message, as long as all prefixes share a common attribute set.
在一条BGP更新消息中可以公布多条不可行的路由。此外，只要所有前缀共享一个公共属性集，就可以在单个更新消息中公布一个或多个可行路由。
The BGP4 protocol permits advertisement of multiple prefixes with a common set of path attributes in a single update message, which is commonly referred to as "update packing". When possible, update packing is recommended, as it provides a mechanism for more efficient behavior in a number of areas, including:
BGP4协议允许在单个更新消息中公布具有一组公共路径属性的多个前缀，通常称为“更新打包”。如果可能，建议使用更新打包，因为它提供了一种机制，可在多个领域实现更高效的行为，包括：
o Reduction in system overhead due to generation or receipt of fewer Update messages.
o 由于生成或接收的更新消息较少，因此减少了系统开销。
o Reduction in network overhead as a result of less packets and lower bandwidth consumption.
o 由于更少的数据包和更低的带宽消耗，减少了网络开销。
o Reduction in frequency of processing path attributes and looking for matching sets in the AS_PATH database (if you have one). Consistent ordering of the path attributes allows for ease of matching in the database, as different representations of the same data do not exist.
o 减少处理路径属性和在AS_路径数据库（如果有）中查找匹配集的频率。由于不存在相同数据的不同表示形式，因此路径属性的一致顺序便于在数据库中进行匹配。
The BGP protocol suggests that withdrawal information should be packed in the beginning of an Update message, followed by information about reachable routes in a single UPDATE message. This helps alleviate excessive route flapping in BGP.
BGP协议建议在更新消息的开头打包提取信息，然后在单个更新消息中打包关于可到达路由的信息。这有助于缓解BGP中过度的路由抖动。
The BGP protocol defines different mechanisms to rate limit Update advertisement. The BGP protocol defines a MinRouteAdvertisementInterval parameter that determines the minimum time that must elapse between the advertisement of routes to a particular destination from a single BGP speaker. This value is set on a per-BGP-peer basis.
BGP协议定义了不同的机制来限制更新播发的速率。BGP协议定义了一个MinRoutedVertisementInterval参数，该参数确定从单个BGP扬声器到特定目的地的路由播发之间必须经过的最短时间。此值是基于每个BGP对等机设置的。
Because BGP relies on TCP as the Transport protocol, TCP can prevent transmission of data due to empty windows. As a result, multiple updates may be spaced closer together than was originally queued. Although it is not common, implementations should be aware of this occurrence.
由于BGP依赖TCP作为传输协议，TCP可以防止由于空窗口而导致的数据传输。因此，多个更新的间隔可能比最初排队的间隔更近。尽管这种情况并不常见，但实现应该意识到这种情况。
If either a TCP receiver is processing input more slowly than the sender, or if the TCP connection rate is the limiting factor, a form of backpressure is observed by the TCP sending application. When the TCP buffer fills, the sending application will either block on the write or receive an error on the write. In early implementations or naive new implementations, setting options to block on the write or setting options for non-blocking writes are common errors. Such implementations treat full buffer related errors as fatal.
如果TCP接收方处理输入的速度比发送方慢，或者如果TCP连接速率是限制因素，则TCP发送应用程序会观察到一种形式的背压。当TCP缓冲区填满时，发送应用程序将在写入时阻塞，或在写入时收到错误。在早期的实现或幼稚的新实现中，将选项设置为写入时阻塞或设置非阻塞写入的选项是常见的错误。此类实现将与完整缓冲区相关的错误视为致命错误。
Having recognized that full write buffers are to be expected, additional implementation pitfalls exist. The application should not attempt to store the TCP stream within the application itself. If the receiver or the TCP connection is persistently slow, then the buffer can grow until memory is exhausted. A BGP implementation is required to send changes to all peers for which the TCP connection is not blocked, and is required to send those changes to the remaining peers when the connection becomes unblocked.
认识到预期会出现完整的写缓冲区后，还存在其他实现缺陷。应用程序不应尝试在应用程序本身中存储TCP流。如果接收器或TCP连接持续缓慢，则缓冲区可能会增长，直到内存耗尽。BGP实现需要将更改发送到TCP连接未被阻止的所有对等方，并且需要在连接解除阻止时将这些更改发送到其余对等方。
If the preferred route for a given NLRI changes multiple times while writes to one or more peers are blocked, only the most recent best route needs to be sent. In this way, BGP is work conserving [RFC4274]. In cases of extremely high route change, a higher volume of route change is sent to those peers that are able to process it more quickly; a lower volume of route change is sent to those peers that are not able to process the changes as quickly.
如果给定NLRI的首选路由多次更改，而对一个或多个对等方的写入被阻止，则只需要发送最近的最佳路由。这样，BGP就节省了工作[RFC4274]。在极高的路由更改情况下，向能够更快地处理路由更改的对等方发送更大的路由更改量；将较低数量的路由更改发送给那些无法尽快处理更改的对等方。
For implementations that handle differing peer capacities to absorb route change well, if the majority of route change is contributed by a subset of unstable NRLI, the only impact on relatively stable NRLI that makes an isolated route change is a slower convergence, for which convergence time remains bounded, regardless of the amount of instability.
对于处理不同对等容量以很好地吸收路由变化的实现，如果大部分路由变化是由不稳定的NRLI子集造成的，则对相对稳定的NRLI造成孤立路由变化的唯一影响是较慢的收敛，收敛时间保持有界，不管有多不稳定。
The BGP protocol suggests that BGP speakers sending multiple prefixes per an UPDATE message sort and order path attributes according to Type Codes. This would help their peers quickly identify sets of attributes from different update messages that are semantically different.
BGP协议建议BGP说话者在每次更新消息时发送多个前缀，并根据类型代码对路径属性进行排序和排序。这将有助于他们的对等方从语义不同的不同更新消息中快速识别属性集。
Implementers may find it useful to order path attributes according to Type Code, such that sets of attributes with identical semantics can be more quickly identified.
实现者可能会发现根据类型代码对路径属性进行排序很有用，这样可以更快地识别具有相同语义的属性集。
AS_SETs are commonly used in BGP route aggregation. They reduce the size of AS_PATH information by listing AS numbers only once, regardless of the number of times it might appear in the process of aggregation. AS_SETs are usually sorted in increasing order to facilitate efficient lookups of AS numbers within them. This optimization is optional.
AS_集通常用于BGP路由聚合。它们通过只以数字形式列出一次来减少AS_路径信息的大小，而不管它在聚合过程中出现的次数。AS_集合通常按递增顺序排序，以便于有效查找其中的AS编号。此优化是可选的。
Because pre-BGP-4 route aggregation can't be supported by earlier versions of BGP, an implementation that supports versions in addition to BGP-4 should provide the version support on a per-peer basis. At the time of this writing, all BGP speakers on the Internet are thought to be running BGP version 4.
由于早期版本的BGP不支持BGP-4之前的路由聚合，因此支持BGP-4之外版本的实现应基于每个对等方提供版本支持。在撰写本文时，互联网上的所有BGP扬声器都被认为运行的是BGP版本4。
BGP provides a flexible and extendable mechanism for authentication and security. The mechanism allows support for schemes with various degrees of complexity. BGP sessions are authenticated based on the IP address of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer.
BGP为身份验证和安全性提供了灵活且可扩展的机制。该机制允许支持具有不同复杂度的方案。BGP会话基于对等方的IP地址进行身份验证。此外，所有BGP会话都基于对等方公布的自治系统号进行身份验证。
Because BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP.
由于BGP在TCP和IP上运行，BGP的身份验证方案可以通过TCP或IP提供的任何身份验证或安全机制来增强。
[RFC2385] defines a way in which the TCP MD5 signature option can be used to validate information transmitted between two peers. This method prevents a third party from injecting information (e.g., a TCP Reset) into the datastream, or modifying the routing information carried between two BGP peers.
[RFC2385]定义了使用TCP MD5签名选项验证两个对等方之间传输的信息的方式。此方法可防止第三方将信息（例如TCP重置）注入数据流，或修改两个BGP对等方之间的路由信息。
At the moment, TCP MD5 is not ubiquitously deployed, especially in inter-domain scenarios, largely because of key distribution issues. Most key distribution mechanisms are considered to be too "heavy" at this point.
目前，TCP MD5还没有广泛部署，特别是在域间场景中，这主要是因为密钥分发问题。在这一点上，大多数密钥分发机制被认为过于“沉重”。
Many have naively assumed that an attacker must correctly guess the exact TCP sequence number (along with the source and destination ports and IP addresses) to inject a data segment or reset a TCP transport connection between two BGP peers. However, recent observation and open discussion show that the malicious data only needs to fall within the TCP receive window, which may be quite large, thereby significantly lowering the complexity of such an attack.
许多人天真地认为，攻击者必须正确猜测准确的TCP序列号（以及源和目标端口和IP地址），才能在两个BGP对等方之间插入数据段或重置TCP传输连接。然而，最近的观察和公开讨论表明，恶意数据只需要落在TCP接收窗口内，该窗口可能相当大，从而大大降低了此类攻击的复杂性。
As such, it is recommended that the MD5 TCP Signature Option be employed to protect BGP from session resets and malicious data injection.
因此，建议使用MD5 TCP签名选项来保护BGP免受会话重置和恶意数据注入的影响。
BGP can run over IPsec, either in a tunnel or in transport mode, where the TCP portion of the IP packet is encrypted. This not only prevents random insertion of information into the data stream between two BGP peers, but also prevents an attacker from learning the data being exchanged between the peers.
BGP可以在IPsec上运行，可以在隧道中运行，也可以在传输模式下运行，其中IP数据包的TCP部分是加密的。这不仅可以防止在两个BGP对等方之间的数据流中随机插入信息，还可以防止攻击者了解对等方之间交换的数据。
However, IPsec does offer several options for exchanging session keys, which may be useful on inter-domain configurations. These options are being explored in many deployments, although no definitive solution has been reached on the issue of key exchange for BGP in IPsec.
但是，IPsec确实提供了几个用于交换会话密钥的选项，这在域间配置中可能很有用。尽管在IPsec中BGP密钥交换问题上尚未达成最终解决方案，但在许多部署中都在探索这些选项。
Because BGP runs over TCP and IP, it should be noted that BGP is vulnerable to the same denial of service and authentication attacks that are present in any TCP based protocol.
由于BGP通过TCP和IP运行，因此应注意，BGP易受任何基于TCP的协议中存在的相同拒绝服务和身份验证攻击的攻击。
Another routing protocol issue is providing evidence of the validity and authority of routing information carried within the routing system. This is currently the focus of several efforts, including efforts to define threats that can be used against this routing information in BGP [BGPATTACK], and efforts to develop a means of providing validation and authority for routing information carried within BGP [SBGP] [soBGP].
另一个路由协议问题是提供路由系统中所携带的路由信息的有效性和权威性的证据。这是目前几项工作的重点，包括努力定义可用于BGP[BGPATTACK]中该路由信息的威胁，以及努力开发一种方法，为BGP[SBGP][soBGP]中的路由信息提供验证和授权。
In addition, the Routing Protocol Security Requirements (RPSEC) working group has been chartered, within the Routing Area of the IETF, to discuss and assist in addressing issues surrounding routing protocol security. Within RPSEC, this work is intended to result in feedback to BGP4 and future protocol enhancements.
此外，已在IETF的路由领域内成立了路由协议安全要求（RPSEC）工作组，以讨论并协助解决路由协议安全相关问题。在RPSEC中，这项工作旨在向BGP4和未来的协议增强提供反馈。
The Prefix Taxonomy (PTOMAINE) working group, recently replaced by the Global Routing Operations (GROW) working group, is chartered to consider and measure the problem of routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, GROW will also document the operational aspects of measurement, policy, security, and VPN infrastructures.
前缀分类（PtoMac）工作组，最近取代了全球路由操作（GROW）工作组，特许考虑和测量路由表增长的问题，内部和外部路由协议之间的相互作用的影响，以及地址分配策略和实践对全局路由系统的影响。最后，在适当的情况下，GROW还将记录度量、策略、安全和VPN基础设施的操作方面。
GROW is currently studying the effects of route aggregation, and also the inability to aggregate over multiple provider boundaries due to inadequate provider coordination.
GROW目前正在研究路由聚合的影响，以及由于提供商协调不足而无法在多个提供商边界上聚合的问题。
Within GROW, this work is intended to result in feedback to BGPv4 and future protocol enhancements.
在GROW中，这项工作旨在向BGPv4和未来的协议增强提供反馈。
Many organizations register their routing policy and prefix origination in the various distributed databases of the Internet Routing Registry. These databases provide access to information using the RPSL language, as defined in [RFC2622]. While registered information may be maintained and correct for certain providers, the lack of timely or correct data in the various IRR databases has prevented wide spread use of this resource.
许多组织在Internet路由注册表的各种分布式数据库中注册其路由策略和前缀来源。这些数据库使用[RFC2622]中定义的RPSL语言提供对信息的访问。虽然某些提供者可以维护和更正注册信息，但各种IRR数据库中缺乏及时或正确的数据妨碍了这一资源的广泛使用。
The NSFNET program used EGP, and then BGP, to provide external routing information. It was the NSF policy of offering different prices and providing different levels of support to the Research and Education (RE) and the Commercial (CO) networks that led to BGP's initial policy requirements. In addition to being charged more, CO networks were not able to use the NSFNET backbone to reach other CO networks. The rationale for higher prices was that commercial users of the NSFNET within the business and research entities should subsidize the RE community. Recognition that the Internet was evolving away from a hierarchical network to a mesh of peers led to changes away from EGP and BGP-1 that eliminated any assumptions of hierarchy.
NSFNET程序使用EGP，然后使用BGP来提供外部路由信息。正是国家科学基金会为研究与教育（RE）和商业（CO）网络提供不同价格和不同级别支持的政策导致了BGP最初的政策要求。除收取更多费用外，CO网络无法使用NSFNET主干网连接其他CO网络。提高价格的理由是，商业和研究实体内NSFNET的商业用户应补贴RE社区。认识到互联网正在从一个分层网络演变为一个对等网络网，这导致了从EGP和BGP-1的变化，消除了任何分层假设。
Enforcement of NSF policy was accomplished through maintenance of the NSF Policy Routing Database (PRDB). The PRDB not only contained each networks designation as CO or RE, but also contained a list of the preferred exit points to the NSFNET to reach each network. This was the basis for setting what would later be called BGP LOCAL_PREF on the NSFNET. Tools provided with the PRDB generated complete router configurations for the NSFNET.
NSF策略的实施是通过维护NSF策略路由数据库（PRDB）完成的。PRDB不仅包含每个网络的CO或RE名称，还包含NSFNET到达每个网络的首选出口点列表。这是在NSFNET上设置后来称为BGP LOCAL_PREF的基础。PRDB提供的工具为NSFNET生成了完整的路由器配置。
Use of the PRDB had the fortunate consequence of greatly improving reliability of the NSFNET, relative to peer networks of the time. PRDB offered more optimal routing for those networks that were sufficiently knowledgeable and willing to keep their entries current.
PRDB的使用带来了幸运的结果，相对于当时的对等网络，NSFNET的可靠性大大提高。PRDB为那些知识渊博且愿意保持其条目最新的网络提供了更优化的路由。
With the decommission of the NSFNET Backbone Network Service in 1995, it was recognized that the PRDB should be made less single provider centric, and its legacy contents, plus any further updates, should be made available to any provider willing to make use of it. The European networking community had long seen the PRDB as too US-centric. Through Reseaux IP Europeens (RIPE), the Europeans created an open format in RIPE-181 and maintained an open database used for
随着NSFNET主干网服务于1995年退役，人们认识到PRDB应减少以单一提供商为中心，其遗留内容以及任何进一步的更新应提供给任何愿意使用它的提供商。欧洲网络共同体长期以来一直认为PRDB过于以美国为中心。通过Reseaux IP Europeen（RIME），欧洲人在RIME-181中创建了一种开放格式，并维护了一个用于
address and AS registry more than policy. The initial conversion of the PRDB was to RIPE-181 format, and tools were converted to make use of this format. The collection of databases was termed the Internet Routing Registry (IRR), with the RIPE database and US NSF-funded Routing Arbitrator (RA) being the initial components of the IRR.
地址和作为注册表而不是策略。PRDB的初始转换为RIME-181格式，并对工具进行了转换以使用该格式。数据库集合被称为互联网路由注册（IRR），成熟的数据库和美国国家科学基金会资助的路由仲裁器（RA）是IRR的初始组成部分。
A need to extend RIPE-181 was recognized and RIPE agreed to allow the extensions to be defined within the IETF in the RPS WG, resulting in the RPSL language. Other work products of the RPS WG provided an authentication framework and a means to widely distribute the database in a controlled manner and synchronize the many repositories. Freely available tools were provided, primarily by RIPE, Merit, and ISI, the most comprehensive set from ISI. The efforts of the IRR participants has been severely hampered by providers unwilling to keep information in the IRR up to date. The larger of these providers have been vocal, claiming that the database entry, simple as it may be, is an administrative burden, and some acknowledge that doing so provides an advantage to competitors that use the IRR. The result has been an erosion of the usefulness of the IRR and an increase in vulnerability of the Internet to routing based attacks or accidental injection of faulty routing information.
认识到需要扩展RIME-181，并同意允许在RPS工作组的IETF中定义扩展，从而产生RPSL语言。RPS工作组的其他工作产品提供了一个身份验证框架和一种以受控方式广泛分发数据库并同步多个存储库的方法。提供了免费可用的工具，主要由CREATE、BRITE和ISI提供，ISI是ISI中最全面的工具集。由于供应商不愿意将IRR中的信息保持最新，IRR参与者的努力受到了严重阻碍。这些供应商中较大的一家一直表示，尽管数据库条目可能很简单，但它是一种管理负担，一些人承认这样做为使用IRR的竞争对手提供了优势。结果是IRR的实用性受到侵蚀，互联网更容易受到基于路由的攻击或错误路由信息的意外注入。
There have been a number of cases in which accidental disruption of Internet routing was avoided by providers using the IRR, but this was highly detrimental to non-users. Filters have been forced to provide less complete coverage because of the erosion of the IRR; these types of disruptions continue to occur infrequently, but have an increasingly widespread impact.
在许多情况下，使用IRR的提供商避免了意外中断互联网路由，但这对非用户非常有害。由于IRR的侵蚀，过滤器被迫提供较少的完整覆盖范围；这些类型的破坏仍然很少发生，但影响越来越广泛。
We would like to thank Paul Traina and Yakov Rekhter for authoring previous versions of this document and providing valuable input on this update. We would also like to acknowledge Curtis Villamizar for providing both text and thorough reviews. Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich, and Jude Ballard for supplying their usual keen eyes.
我们要感谢Paul Traina和Yakov Rekhter编写了本文件的早期版本，并就本更新提供了宝贵的意见。我们还要感谢Curtis Villamizar提供文本和全面审查。感谢罗斯·怀特、杰弗里·哈斯、肖恩·门策、米切尔·埃尔布里奇和裘德·巴拉德，感谢他们一如既往的敏锐目光。
Finally, we'd like to think the IDR WG for general and specific input that contributed to this document.
最后，我们希望IDR工作组能够为本文档提供一般和具体的输入。
[RFC1966] Bates, T. and R. Chandra, "BGP Route Reflection An alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC1966]Bates，T.和R.Chandra，“BGP路线反射是全网IBGP的替代方案”，RFC 1966，1996年6月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439]Villamizar，C.，Chandra，R.，和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，1998年11月。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC2796]Bates，T.，Chandra，R.，和E.Chen，“BGP路线反射-全网格IBGP的替代品”，RFC 2796，2000年4月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3065]Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 3065，2001年2月。
[RFC4274] Meyer, D. and K. Patel, "BGP-4 Protocol Analysis", RFC 4274, January 2006.
[RFC4274]Meyer，D.和K.Patel，“BGP-4协议分析”，RFC 4274，2006年1月。
[RFC4276] Hares, S. and A. Retana, "BGP 4 Implementation Report", RFC 4276, January 2006.
[RFC4276]Hares，S.和A.Retana，“BGP 4实施报告”，RFC 4276，2006年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares编辑，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC1657] Willis, S., Burruss, J., Chu, J., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994.
[RFC1657]Willis，S.，Burruss，J.，Chu，J.，“使用SMIv2的第四版边界网关协议（BGP-4）的托管对象定义”，RFC 1657，1994年7月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1105，1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163]Lougheed，K.和Y.Rekhter，“边界网关协议（BGP）”，RFC1163，1990年6月。
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC1264]Hinden，R.，“互联网工程任务组互联网路由协议标准化标准”，RFC 1264，1991年10月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267]Lougheed，K.和Y.Rekhter，“边境网关协议3（BGP-3）”，RFC 1267，1991年10月。
[RFC1269] Willis, S. and J. Burruss, "Definitions of Managed Objects for the Border Gateway Protocol: Version 3", RFC 1269, October 1991.
[RFC1269]Willis，S.和J.Burruss，“边界网关协议的托管对象定义：第3版”，RFC 1269，1991年10月。
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, July 1994.
[RFC1656]Traina，P.，“BGP-4协议文件路线图和实施经验”，RFC1656，1994年7月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995.
[RFC1773]Traina，P.，“BGP-4协议的经验”，RFC 1773，1995年3月。
[RFC1965] Traina, P., "Autonomous System Confederations for BGP", RFC 1965, June 1996.
[RFC1965]Traina，P.，“BGP自治系统联合会”，RFC1965，1996年6月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 26221999年6月。
[BGPATTACK] Convery, C., "An Attack Tree for the Border Gateway Protocol", Work in Progress.
[BGPATTACK]Convery，C.，“边界网关协议的攻击树”，工作正在进行中。
[SBGP] "Secure BGP", Work in Progress.
[SBGP]“安全BGP”，正在进行中。
[soBGP] "Secure Origin BGP", Work in Progress.
[soBGP]“安全原产地BGP”，工作正在进行中。
Authors' Addresses
作者地址
Danny McPherson Arbor Networks
丹尼·麦克弗森阿伯网络公司
EMail: danny@arbor.net
EMail: danny@arbor.net
Keyur Patel Cisco Systems
科尤尔帕特尔思科系统公司
EMail: keyupate@cisco.com
EMail: keyupate@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。