Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 7682 Verisign, Inc.
Category: Informational S. Amante
ISSN: 2070-1721 Apple, Inc.
E. Osterweil
Verisign, Inc.
L. Blunk
Merit Network, Inc.
D. Mitchell
Singularity Networks
December 2015
Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 7682 Verisign, Inc.
Category: Informational S. Amante
ISSN: 2070-1721 Apple, Inc.
E. Osterweil
Verisign, Inc.
L. Blunk
Merit Network, Inc.
D. Mitchell
Singularity Networks
December 2015
Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration
Internet路由注册表（IRR）和路由策略配置的注意事项
Abstract
摘要
The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.
本文件的目的是对过去二十年来影响互联网路由注册中心（IRR）在全球路由系统中域间路由策略规范和应用的有效性的问题进行分类。此外，本文还讨论了这些问题中哪些在实践中仍然存在问题，哪些只是不再适用的工件，但至今仍在扼杀基于提供商间策略的过滤采用和IRR实用性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc7682.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7682.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3
4. Accuracy and Integrity of Data Contained within the IRR . . . 4
4.1. Lack of Resource Certification . . . . . . . . . . . . . 4
4.2. Incentives to Maintain Data within the IRR . . . . . . . 5
4.3. Inability for Third Parties to Remove (Stale) Information
from the IRRs . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7
4.5. Client-Side Considerations . . . . . . . . . . . . . . . 8
4.6. Conclusions with Respect to Data in the IRR . . . . . . . 8
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8
5.1. Replication of Resources among IRRs . . . . . . . . . . . 8
5.2. Updating Routing Policies from Updated IRR Resources . . 10
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11
7. Historical Limitations of Routers . . . . . . . . . . . . . . 13
7.1. Incremental Updates to Policy on Routers . . . . . . . . 13
7.2. Storage Requirements for Policy on Routers . . . . . . . 13
7.3. Updating Configuration on Routers . . . . . . . . . . . . 14
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3
4. Accuracy and Integrity of Data Contained within the IRR . . . 4
4.1. Lack of Resource Certification . . . . . . . . . . . . . 4
4.2. Incentives to Maintain Data within the IRR . . . . . . . 5
4.3. Inability for Third Parties to Remove (Stale) Information
from the IRRs . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7
4.5. Client-Side Considerations . . . . . . . . . . . . . . . 8
4.6. Conclusions with Respect to Data in the IRR . . . . . . . 8
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8
5.1. Replication of Resources among IRRs . . . . . . . . . . . 8
5.2. Updating Routing Policies from Updated IRR Resources . . 10
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11
7. Historical Limitations of Routers . . . . . . . . . . . . . . 13
7.1. Incremental Updates to Policy on Routers . . . . . . . . 13
7.2. Storage Requirements for Policy on Routers . . . . . . . 13
7.3. Updating Configuration on Routers . . . . . . . . . . . . 14
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The purpose of this document is to catalog issues influencing the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues still pose problems in practice, and which are no longer obstacles, but whose perceived drawbacks continue to stifle inter-provider policy-based filtering support and IRR utility to this day.
本文件的目的是对过去二十年来影响互联网路由注册中心（IRR）在全球路由系统中用于域间路由策略规范和应用的有效性的问题进行分类。此外，它还讨论了这些问题中哪些在实践中仍然存在问题，哪些不再是障碍，但其感知的缺点至今仍在扼杀基于提供商间策略的过滤支持和IRR效用。
IRRs can be used to express a multitude of Internet number bindings and policy objectives, i.e., to include bindings between 1) an origin AS and a given prefix, 2) a given AS and its AS and community import and export policies, as well as 3) a given AS and the AS macros (as-sets in Routing Policy Specification Language (RPSL)) that convey the set of ASes that it intends to include in some common group.
IRR可用于表示多种Internet号码绑定和策略目标，即包括1）源AS和给定前缀之间的绑定，2）给定AS及其AS和社区导入导出策略，以及3）给定AS和AS宏（路由策略规范语言（RPSL）中的AS集）之间的绑定这传达了它打算包含在某个公共组中的一组ASE。
As quoted from Section 7 of "Routing in a Multi-Provider Internet" [RFC1787]:
引用“多提供商互联网中的路由”第7节[RFC1787]：
While ensuring Internet-wide coordination may be more and more difficult, as the Internet continues to grow, stability and consistency of the Internet-wide routing could significantly benefit if the information about routing requirements of various organizations could be shared across organizational boundaries. Such information could be used in a wide variety of situations ranging from troubleshooting to detecting and eliminating conflicting routing requirements. The scale of the Internet implies that the information should be distributed. Work is currently underway to establish depositories of this information (Routing Registries), as well as to develop tools that analyze, as well as utilize this information.
虽然确保互联网范围内的协调可能越来越困难，但随着互联网的不断发展，如果能够跨组织边界共享有关各组织路由要求的信息，那么互联网范围路由的稳定性和一致性将大大受益。此类信息可用于各种情况，从故障排除到检测和消除冲突的路由要求。互联网的规模意味着信息应该被分发。目前正在开展工作，以建立该信息的保管处（路由登记处），以及开发分析和利用该信息的工具。
The term IRR is often used, incorrectly, as a broad catch-all term to categorize issues related to the accuracy of data in the IRR, RPSL, and the operational deployment of policy (derived from RPSL contained within the IRR) to routers. It is important to classify these issues into distinct categories so that the reader can understand which categories of issues are historical artifacts that are no longer applicable and which categories of issues still exist and might be addressed by the IETF.
术语IRR经常被错误地用作一个笼统的术语，用于对与IRR、RPSL中数据的准确性以及策略（源自IRR中包含的RPSL）到路由器的操作部署相关的问题进行分类。将这些问题划分为不同的类别是很重要的，以便读者能够理解哪些类别的问题是不再适用的历史工件，哪些类别的问题仍然存在，并且可能由IETF解决。
The following sections will separate out challenges related to the IRR into the following categories: first, accuracy and integrity of data contained within the IRR; second, operation of the IRR infrastructure, i.e., synchronization of resources from one IRR to other IRRs; and finally, this document covers the methods related to extraction of policy from the IRR and the input, plus activation of that policy within routers.
以下章节将与内部收益率相关的挑战分为以下几类：第一，内部收益率中包含的数据的准确性和完整性；第二，内部收益率基础设施的运作，即从一个内部收益率到其他内部收益率的资源同步；最后，本文介绍了从IRR和输入中提取策略的相关方法，以及在路由器中激活该策略的相关方法。
The following section will examine issues related to accuracy and integrity of data contained within the IRR.
下一节将探讨与内部收益率中所含数据的准确性和完整性相关的问题。
Internet number resources include IPv4 addresses, IPv6 addresses, Autonomous System Numbers (ASNs), and more. While these resources are generally allocated by hierarchical authorities, a general mechanism for formally verifying (such as through cryptographic mechanisms) when parties have been allocated resources remains an open challenge. We generally call such a system a Resource Certification System, and we note that some candidate examples of how such a general system might be implemented and deployed exist -- [TASRS], [RC_HotNetsX], and [RFC6480].
Internet号码资源包括IPv4地址、IPv6地址、自治系统号码（ASN）等。虽然这些资源通常由分级机构分配，但当各方已分配资源时，正式验证（如通过加密机制）的一般机制仍然是一个公开的挑战。我们通常将这样一个系统称为资源认证系统，并且我们注意到存在一些关于如何实现和部署这样一个通用系统的候选示例--[TASRS]、[RC_HotNetsX]和[RFC6480]。
One of the largest weaknesses often cited with the IRR system is that the data contained within the IRRs is out of date or lacks integrity. This is largely attributable to the fact that existing IRR mechanisms do not provide ways for a relying party to (cryptographically) verify the validity of an IRR object. That is, there has never existed a resource certification infrastructure that enables a resource holder to authorize a particular autonomous system to originate network-layer reachability advertisements for a given IPv4 or IPv6 prefix. It should be noted that this is not a weakness of the underlying RPSL [RFC2622], but rather, was largely the result of no clear demand by the operator community for Internet Number Resource Registries to provide sufficient resource certification infrastructure that would enable a resource holder to develop a cryptographic binding between, for example, a given AS number and an IP prefix.
IRR系统经常提到的最大弱点之一是IRR中包含的数据过时或缺乏完整性。这主要是由于现有的IRR机制没有为依赖方提供（加密）验证IRR对象有效性的方法。也就是说，从来没有一个资源认证基础设施能够使资源持有者授权特定的自治系统为给定的IPv4或IPv6前缀发起网络层可达性广告。应该注意的是，这并不是基础RPSL[RFC2622]的弱点，而是运营商社区没有明确要求互联网号码资源注册中心提供足够的资源认证基础设施，使资源持有者能够在，例如，给定的AS编号和IP前缀。
Another noteworthy (but slightly different) deficiency in the IRR system is the absence of a tangible tie between the resource and the resource holder. That is, generally there is no assurance of the validity of objects at their creation time (except for a subset of, for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE address holders and RIPE ASN holders). If a resource holder's authorization cannot be certified, then consumers cannot verify attestations made. In effect, without resource certification,
IRR系统中另一个值得注意（但略有不同）的缺陷是资源和资源持有者之间缺乏有形联系。也就是说，通常无法保证对象在创建时的有效性（例如，RPS[RFC2725]证明成熟地址持有者和成熟ASN持有者的成熟IRR子集除外）。如果资源持有者的授权无法认证，则使用者无法验证所做的认证。实际上，没有资源认证，
consumers are basically only certifying the assertions that the creator/maintainer of the resource object has made (not if that assertion is valid).
消费者基本上只验证资源对象的创建者/维护者所做的断言（如果该断言有效则不验证）。
The RIPE community addressed this last issue by putting in a foundation policy [RIPE638], which requires a contractual link between the RIPE NCC and the end user in direct assignment + ASN assignment cases, which weren't previously covered by Local Internet Registry (LIR) contracts for address allocations. There were a couple of intentions with this policy:
成熟的社区通过提出一个基础策略来解决最后一个问题[RIPE638 ]，这需要成熟的NCC和最终用户在直接指派+ ASN分配案例之间的契约链接，而以前的地址不被本地因特网注册（LIR）合同地址分配所覆盖。这项政策有几个目的：
1. There was an encumbrance placed in the policy for the LIR to charge the end user for provider-independent (PI) resources. This action created a collection mechanism for PI address resources (IPv4/IPv6 space, ASNs).
1. LIR向最终用户收取独立于提供商（PI）资源的费用的策略中存在一个产权负担。此操作创建了PI地址资源（IPv4/IPv6空间，ASN）的收集机制。
2. It guaranteed that all RIPE NCC allocated/assigned space would be subject to a contractual link, and that this contractual chain might end up actually meaning something when it came to the issue of who made what claim about what number resource.
2. 它保证了所有成熟的NCC分配/分配的空间都将受到合同链接的约束，并且当涉及到谁对什么数量的资源提出了什么索赔的问题时，这个合同链可能最终具有实际意义。
3. It tied into the RIPE NCC's object grandfathering policy that ties the registration details of the end user to the object registered in the IRR database.
3. 它与成熟的NCC对象grandfathering策略相关联，该策略将最终用户的注册详细信息与IRR数据库中注册的对象相关联。
While this policy specifically addressed PI/portable space holders, other regions address this issue, too. Further, a tangible tie between the resource and the resource holder is indeed a prerequisite for resource certification, though it does not directly address the IRR deficiencies.
虽然该政策专门针对PI/便携式空间持有者，但其他地区也解决了这一问题。此外，资源和资源持有者之间的有形联系确实是资源认证的先决条件，尽管它不能直接解决内部收益率不足的问题。
One of the central observations of this policy was that without a chain-of-ownership functionality in IRR databases, the discussion of certifying their contents becomes moot.
这项政策的一个中心观察结果是，如果IRR数据库中没有所有权链功能，关于认证其内容的讨论就变得毫无意义。
A second problem with data contained in the IRRs is that the incentives for resource holders to maintain both accurate and up-to-date information in one or more IRRs (including deletion of out-of-date or stale data from the IRRs) can diminish rapidly when changing their peering policies (such as switching transit providers). Specifically, there is a very strong incentive for an ISP's customers to register new routing information in the IRR, because some ISPs enforce a strict policy that they will only build or update a customer's prefix-lists applied to the customer's inbound eBGP sessions based off information found within the IRRs. Unfortunately, there is little incentive for an ISP's customers to remove out-of-
IRR中包含的数据的第二个问题是，资源持有者在一个或多个IRR中保持准确和最新信息的动机（包括从IRR中删除过时或过时的数据）可能会在更改其对等策略（如切换公交提供商）时迅速减弱。具体而言，ISP的客户在IRR中注册新路由信息的动机非常强烈，因为一些ISP强制执行严格的政策，即他们仅根据IRR中找到的信息构建或更新应用于客户入站eBGP会话的客户前缀列表。不幸的是，对于ISP的客户来说，几乎没有什么动机将其从网络中删除-
date information from an IRR, most likely attributed to the fact that some ISPs do not use, or enforce use of, data contained within the IRRs to automatically build incoming policy applied to the customer's eBGP sessions. For example, if a customer is terminating service from one ISP that requires use of IRR data to build incoming policy and, at the same time, enabling service with another ISP that does not require use of IRR data, then that customer will likely let the data in the IRR become stale or inaccurate.
IRR中的日期信息，很可能是由于某些ISP不使用或强制使用IRR中包含的数据来自动构建应用于客户eBGP会话的传入策略。例如，如果客户终止某个ISP的服务，而该ISP需要使用IRR数据来构建传入策略，同时启用与另一个ISP的服务，而该ISP不需要使用IRR数据，则该客户可能会让IRR中的数据变得陈旧或不准确。
Further, policy filters are almost exclusively generated based on the origin AS information contained within IRR route objects and used by providers to filter downstream transit customers. Since providers only look for route objects containing the origin AS of their downstream customer(s), stale route objects with historical and, possibly, incorrect origin AS information are ignored. Assuming that the downstream customer(s) do not continue to announce those routes with historical, or incorrect, origin AS information in BGP to the upstream provider, there is no significant incentive to remove them as they do not impact offline policy filter generation nor routing on the Internet. On the other hand, the main incentive that causes the Service Provider to work with downstream customer(s) is when the resultant filter list becomes so large that it is difficult for it to be stored on PE routers; however, this is more practically an operational issue with very old, legacy PE routers, not more modern PE router hardware with more robust control-plane engines.
此外，政策过滤器几乎完全基于IRR路线对象中包含的来源信息生成，并由提供商用于过滤下游公交客户。由于供应商仅查找包含其下游客户的来源的路由对象，因此忽略具有历史和可能不正确来源信息的陈旧路由对象。假设下游客户不会继续向上游供应商公布BGP中包含历史或不正确来源信息的路由，则不会有重大动机删除这些路由，因为它们不会影响离线策略过滤器生成或互联网上的路由。另一方面，导致服务提供商与下游客户合作的主要激励因素是当结果过滤器列表变得如此之大以至于难以存储在PE路由器上时；然而，对于非常古老的传统PE路由器，这实际上是一个操作问题，而不是具有更强大控制平面引擎的更现代的PE路由器硬件。
4.3. Inability for Third Parties to Remove (Stale) Information from the IRRs
4.3. 第三方无法从IRR中删除（过时）信息
A third challenge with data contained in IRRs is that it is not possible for IRR operators, and ISPs who use them, to proactively remove (perceived) out-of-date or "stale" resources in an IRR, on behalf of resource holders who may not be diligent in maintaining this information themselves. The reason is that, according to the RPSL [RFC2622], only the resource holder ('mntner') specified in a 'mnt-by' value field of an RPSL resource is authorized to add, modify, or delete their own resources within the IRR. To address this issue, the 'auth-override' mechanism [RFC2725] was later developed that would have enabled a third party to update and/or remove "stale" resources from the IRR. While it is unclear if this was ever implemented or deployed, it does provide language semantics needed to overcome this obstacle.
IRR中包含的数据的第三个挑战是，IRR运营商和使用IRR的ISP不可能代表资源所有者主动移除（感知）IRR中的过时或“过时”资源，因为资源所有者可能不努力维护这些信息。原因是，根据RPSL[RFC2622]，只有在RPSL资源的“mnt by”值字段中指定的资源持有者（“mntner”）有权在IRR中添加、修改或删除自己的资源。为了解决这个问题，后来开发了“身份验证覆盖”机制[RFC2725]，使第三方能够更新和/或删除IRR中的“过时”资源。虽然还不清楚这是否曾经实现或部署过，但它确实提供了克服这一障碍所需的语言语义。
Nevertheless, with such a mechanism in place, there is still a risk that the original RPSL resource holder would not receive notifications (via the 'notify' attribute in various RPSL resources) about the pending or actual removal of a resource from the IRR in time to halt that action if those resources were still being used.
尽管如此，有了这样一种机制，仍然存在一种风险，即原始RPSL资源持有者将不会收到（通过各种RPSL资源中的“notify”属性）关于从IRR中暂停或实际删除资源的通知，从而在这些资源仍在使用的情况下停止该行动。
In this case, if the removal of a resource was not suspended, it could potentially result in an unintentional denial of service for the RPSL resource holder when, for example, ISPs automatically generated and deployed a new policy based on the newly removed resources from the IRR, thus dropping any reachability announcement for the removed resource in eBGP.
在这种情况下，如果资源的删除未暂停，则可能会导致RPSL资源持有者的无意拒绝服务，例如，ISP根据IRR中新删除的资源自动生成并部署新策略，因此，将删除eBGP中已删除资源的任何可达性声明。
According to [RFC2622], within an RPSL resource "the source attribute specifies the registry where the object is registered." Note that this source attribute only exists within the RPSL resource itself. Unfortunately, given a specific resource (e.g., a specific IPv4 or IPv6 prefix), most of the time it is impossible to determine a priori the authoritative IRR where to query and retrieve an authoritative copy of that resource.
根据[RFC2622]，在RPSL资源中，“源属性指定注册对象的注册表”。请注意，此源属性仅存在于RPSL资源本身中。不幸的是，给定特定的资源（例如，特定的IPv4或IPv6前缀），在大多数情况下，无法事先确定权威IRR，在何处查询和检索该资源的权威副本。
This makes it difficult for consumers of data from the IRR to automatically know the authoritative IRR of a resource holder that will contain the most up-to-date set of resources. This is typically not a problem for an ISP that has a direct (customer) relationship with the resource holder, because the ISP will ask the resource holder which (authoritative) IRR to pull their resources from on, for example, a "Customer BGP Order Form". However, third parties that do not have a direct relationship with the resource holder have a difficult time attempting to infer the authoritative IRR, preferred by the resource holder, that likely contains the most up-to-date set of resources. As a result, it would be helpful for third parties if there were a robust referral mechanism so that a query to one IRR would be automatically redirected toward the authoritative IRR for the most up-to-date and authoritative copy of that particular resource. This problem is worked around by individual IRR operators storing a local copy of other IRRs' resources, through periodic mirroring, which allows the individual IRR to respond to a client's query with all registered instances of a particular IRR resource that exist in both the local IRR and all other IRRs. Of course, the problem with this approach is that an individual IRR operator is under no obligation to mirror all other IRRs and, in practice, some IRRs do not mirror the resources from all other IRRs. This could lead to the false impression that a particular resource is not registered or maintained at a particular IRR. Furthermore, the authentication process of accepting updates by any given IRR may or may not be robust enough to overcome impersonation attacks. As a result, there is no rigorous assurance that a mirrored RPSL statement was actually made by the authorized resource holder.
这使得IRR数据的使用者很难自动了解包含最新资源集的资源持有者的权威IRR。对于与资源持有者有直接（客户）关系的ISP来说，这通常不是问题，因为ISP会要求资源持有者（权威）IRR从例如“客户BGP订单”上提取他们的资源。然而，与资源持有人没有直接关系的第三方很难推断出资源持有人首选的权威内部收益率，该内部收益率可能包含最新的资源集。因此，如果有一个强大的转介机制，那么对一个IRR的查询将自动重定向到该特定资源的最新权威副本的权威IRR，这将有助于第三方。该问题由各个IRR运营商通过定期镜像存储其他IRR资源的本地副本来解决，这允许各个IRR使用本地IRR和所有其他IRR中存在的特定IRR资源的所有注册实例响应客户端的查询。当然，这种方法的问题在于，单个内部收益率运营商没有义务反映所有其他内部收益率，而且在实践中，一些内部收益率没有反映所有其他内部收益率的资源。这可能导致错误的印象，即某一特定资源未在特定的内部收益率中注册或维护。此外，接受任何给定IRR更新的认证过程可能足够健壮，也可能不够健壮，无法克服模拟攻击。因此，无法严格保证镜像的RPSL语句实际上是由授权的资源持有者进行的。
There are no provisions in the IRR mode for ensuring the confidentiality component for clients issuing queries. The overall Confidentiality, Integrity, and Availability (CIA) model of the system does lack this component, because the interface to IRRs is over an unencrypted TCP connection to port 43. This leaves the transaction open to inspection such that an adversary could be able to inspect the query and the response. However, the IRR system is intended to be composed of public policy information, and protection of queries was not part of the protection calculus when it was designed, though the use of Transport Layer Security (TLS) [RFC5246] would address protections of query information.
IRR模式中没有规定确保客户发出查询时的保密性。系统的整体机密性、完整性和可用性（CIA）模型确实缺少此组件，因为IRRs的接口通过未加密的TCP连接连接到端口43。这使得事务可以接受检查，以便对手能够检查查询和响应。然而，IRR系统旨在由公共政策信息组成，在设计时，查询保护不是保护演算的一部分，尽管使用传输层安全性（TLS）[RFC5246]将解决查询信息的保护问题。
All of the aforementioned issues related to integrity and accuracy of data within the IRR stem from a distinct lack of resource certification for resources contained within the IRR. Only now is an experimental testbed that reports to provide this function (under the auspices of the Resource PKI [RFC6480]) being formally discussed; this could also aid in certification of resources within the IRR. It should be noted that the RPKI is only currently able to support signing of Route Origin Authorization (ROA) resources that are the equivalent of 'route' resources in the IRR. There has been some sentiment that the RPKI currently is not scoped to address the same set of issues and the nuanced policy applications that providers leverage in RPSL. It is unclear if, in the future, the RPKI will be extended to support additional resources that already exist in the IRR, e.g., aut-num, as-net, route-set, etc. Finally, a seemingly equivalent resource certification specification for all resources in the IRR has already been developed [RFC2725]; however, it is unclear how widely it was ever implemented or deployed.
上述所有与IRR内数据的完整性和准确性相关的问题都源于IRR内所含资源明显缺乏资源认证。直到现在，才正式讨论了一个实验性的测试平台，该平台报告提供此功能（在资源PKI[RFC6480]的支持下）；这也有助于对内部收益率内的资源进行认证。需要注意的是，RPKI目前只能支持与IRR中的“路由”资源等效的路由来源授权（ROA）资源的签名。有人认为，RPKI目前的范围不足以解决提供商在RPSL中利用的同一组问题和细微差别的政策应用。不清楚未来是否会扩展RPKI以支持IRR中已经存在的额外资源，例如aut num、as net、路由集等。最后，已经为IRR中的所有资源制定了一个看似等效的资源认证规范[RFC2725]；然而，目前尚不清楚它的实施或部署范围有多广。
Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring (NRTM) protocol to replicate each other's contents. However, this protocol has several weaknesses. Namely, there is no way to validate that the copy of mirrored source is correct, and synchronization issues have often resulted. Furthermore, the NRTM protocol does not employ any security mechanisms. The NRTM protocol relies on a pull mechanism and is generally configured with a poll interval of 5 to 10 minutes. There is currently no mechanism to notify an IRR when an update has occurred in a mirrored IRR so that an immediate update can be made.
目前，一些IRR[IRR_LIST]使用近实时镜像（NRTM）协议来复制彼此的内容。然而，该协议有几个弱点。也就是说，无法验证镜像源的副本是否正确，并且经常会导致同步问题。此外，NRTM协议不采用任何安全机制。NRTM协议依赖于拉机制，通常配置为5到10分钟的轮询间隔。当前没有机制在镜像IRR中发生更新时通知IRR，以便立即进行更新。
Some providers employ a process of mirroring an instance of an IRR that involves downloading a flat text file copy of the IRR that is made available via FTP [RFC959]. These FTP files are exported at regular intervals of typically anywhere between 2 and 24 hours by the IRRs. When a provider fetches those text files, it will process them to identify any updates and reflect changes within its own internally maintained database. The use of an internally maintained database is out of scope for this document but is generally used to assist with more straightforward access to or modification of data by the IRR operator. Providers typically employ a 24-hour cycle to pull updated resources from IRRs. Thus, depending on when resource holders submitted their changes to an IRR, it may take up to 24 hours for those changes to be reflected in their policy configurations. In practice, it appears that the RPKI will also employ a 24-hour cycle whereby changes in resources are pushed out to other RPKI caches [RPKI_SIZING].
一些提供商采用镜像IRR实例的过程，该过程涉及下载通过FTP[RFC959]提供的IRR的平面文本文件副本。这些FTP文件通常由IRR以2到24小时的固定间隔导出。当提供者获取这些文本文件时，它将对其进行处理，以识别任何更新，并在其内部维护的数据库中反映更改。使用内部维护的数据库不在本文件范围内，但通常用于帮助IRR操作员更直接地访问或修改数据。提供商通常采用24小时周期从IRR中提取更新的资源。因此，根据资源持有者向内部收益率提交变更的时间，这些变更可能需要24小时才能反映在其保单配置中。实际上，RPKI似乎也将采用24小时循环，从而将资源的更改推送到其他RPKI缓存[RPKI_size]。
IRRs originated from Section 7 of [RFC1787], specifically: "The scale of the Internet implies that the [routing requirements] information should be distributed." Regardless, the practical effect of an organization maintaining its own local cache of IRR resources is an increase in resource resiliency (due to multiple copies of the same resource being geographically distributed), a reduction in query time for resources, and, likely, a reduction in inter-domain bandwidth consumption and associated costs. This is particularly beneficial when, for example, an ISP is evaluating resources in an IRR just to determine if there are any modifications to those resources that will ultimately be reflected in a new routing policy that will get propagated to (edge) routers in the ISP's network. Cache locality results in reduced inter-domain bandwidth utilization for each round trip.
IRR源于[RFC1787]第7节，具体而言：“互联网的规模意味着[路由要求]信息应该被分发。”无论如何，一个组织维护自己的IRR资源本地缓存的实际效果是资源弹性的增加（由于同一资源的多个副本在地理上分布），减少了资源的查询时间，并且可能减少了域间带宽消耗和相关成本。例如，当ISP评估IRR中的资源只是为了确定这些资源是否有任何修改最终将反映在新的路由策略中时，这尤其有益t将被传播到ISP网络中的（边缘）路由器。缓存位置会降低每次往返的域间带宽利用率。
On the other hand, it is unclear from where the current provider replication interval of 24 hours originated or even whether it still provides enough freshness in the face of available resources, particularly in today's environment where a typical IRR system consists of a (multi-core) multi-GHz CPU connected to a network via a physical connection of 100 Mbps or, more likely, higher bandwidth. In addition, due to demand for bandwidth, circuit sizes used by ISPs have increased to 10 Gbps, thus eliminating bandwidth as a significant factor in the transfer of data between IRRs. Furthermore, it should be noted that Merit's Internet Routing Registry Daemon (IRRd) [MERIT-IRRD] uses 10 minutes as its default for "irr_mirror_interval".
另一方面，目前24小时的提供商复制间隔起源于何处，甚至在面对可用资源时是否仍能提供足够的新鲜度，这一点尚不清楚，特别是在今天的环境中，典型的IRR系统由（多核）组成多GHz CPU通过100 Mbps或更高带宽的物理连接连接到网络。此外，由于对带宽的需求，ISP使用的电路大小已增加到10 Gbps，从而消除了带宽作为IRR之间数据传输的一个重要因素。此外，应该注意的是，Merit的Internet路由注册表守护程序（IRRd）[Merit-IRRd]使用10分钟作为“irr_镜像_间隔”的默认值。
Lastly, it should be noted that "Routing Policy System Replication" [RFC2769] attempted to offer a more methodical solution for distributed replication of resources between IRRs. It is unclear why
最后，应该注意的是，“路由策略系统复制”[RFC2769]试图为IRR之间的资源分布式复制提供一个更系统化的解决方案。原因不明
that RFC failed to gain traction, but it is suspected that this was due to its reliance on "Routing Policy System Security" [RFC2725], which addressed "the need to assure integrity of the data by providing an authentication and authorization model." Indeed, [RFC2725] attempts to add an otherwise absent security model to the integrity of policy statements made in RPSL. Without formal protections, it is possible for anyone to author a policy statement about an arbitrary set of resources, and publish it (as discussed above in Section 4.1.
该RFC未能获得支持，但怀疑这是由于其依赖于“路由策略系统安全性”[RFC2725]，该安全性解决了“通过提供身份验证和授权模型来确保数据完整性的需要”。事实上，[RFC2725]尝试向RPSL中的策略语句的完整性添加其他方面不存在的安全模型。在没有正式保护的情况下，任何人都有可能编写关于任意资源集的策略声明，并将其发布（如上文第4.1节所述）。
Ultimately, the length of time it takes to replicate resources among IRRs is, generally, the dominant factor in reflecting changes to resources in policy that is eventually applied within the control plane of routers. The length of time to update network elements will vary considerably depending on the size of the ISP and the number of IRR resources that were updated during any given interval. However, there are a variety of common techniques, that are outside the scope of this document, that allow for this automated process to be optimized to considerably reduce the length of time it takes to update policies in the ISP's network.
最终，在IRR之间复制资源所需的时间长度通常是反映策略中资源变化的主要因素，该策略最终应用于路由器的控制平面内。根据ISP的大小和在任何给定时间间隔内更新的IRR资源的数量，更新网元的时间长度会有很大的不同。然而，有许多不在本文档范围内的通用技术，允许对该自动化过程进行优化，以大大缩短ISP网络中更新策略所需的时间。
An ISP will begin the process of updating the policy in its network, first by fetching IRR resources associated with, for example, a customer ASN attached to its network. Next, the ISP constructs a new policy associated to that customer and then evaluates if that new policy is different from existing policy associated with that same customer. If there are no changes between the new and existing policy associated with that customer, then the ISP does not make any changes to the policy in their routers specific to that customer. On the other hand, if the new policy does reflect changes from the existing policy for that customer, then the ISP begins a process of uploading the new policy to the routers attached to that customer.
ISP将开始在其网络中更新策略的过程，首先获取与连接到其网络的客户ASN相关联的IRR资源。接下来，ISP构建一个与该客户关联的新策略，然后评估该新策略是否不同于与该客户关联的现有策略。如果与该客户关联的新策略和现有策略之间没有任何更改，则ISP不会对其路由器中特定于该客户的策略进行任何更改。另一方面，如果新策略确实反映了对该客户现有策略的更改，则ISP开始将新策略上载到连接到该客户的路由器的过程。
The process of constructing a new policy involves use of a set of programs, e.g., IRRtoolset, that performs recursive expansion of an RPSL aut-num resource that comprises an arbitrary combination of other RPSL aut-num, as-set, route, and route-set resources, according to procedures defined by RPSL. The end result of this process is, traditionally, a vendor-dependent configuration snippet that defines the routing policy for that customer. This routing policy may consist of the set of IPv4 or IPv6 prefixes, associated prefix lengths, and AS_PATHs that are supposed to be accepted from a customer's eBGP session. However, if indicated in the appropriate RPSL resource, the policy may also set certain BGP Attributes, such
构造新策略的过程涉及使用一组程序，例如IRRtoolset，该程序根据RPSL定义的过程对RPSL aut num资源执行递归扩展，该资源包括其他RPSL aut num、as set、route和route set资源的任意组合。传统上，此过程的最终结果是定义该客户的路由策略的依赖于供应商的配置片段。此路由策略可能包括一组IPv4或IPv6前缀、相关前缀长度以及假定从客户的eBGP会话接受的AS_路径。但是，如果在适当的RPSL资源中指示，策略还可以设置某些BGP属性，例如
as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the incoming eBGP session from the customer or on static routes that are originated by the resource holder.
as MED、as_PATH prepend value、LOCAL_PREF等，在来自客户的传入eBGP会话或资源持有者发起的静态路由上。
An ISP's customers may not adequately plan for pre-planned maintenance, or, more likely, they may need to rapidly begin announcing a new IP prefix as a result of, for example, an emergency turn-up of the ISP customer's new downstream customer. Unfortunately, the routine, automated process employed by the ISP means that it may not begin updating its routing policy on its network for up to 24 hours, because the ISP or the IRRs the ISP uses might only mirror changes to IRR resources once every 24 hours. The time interval for the routine/automated process is not responsive to the needs of directly paying customer(s) who need rapid changes in their policy in rare situations. In these situations, when a customer has an urgent need for updates to take effect immediately, they will call the Network Operations Center (NOC) of their ISP and request that the ISP immediately fetch new IRR objects and push those changes out to its network. This is often accomplished in as little as 5 minutes from the time a customer contacts their ISP's NOC to the time a new filtering policy is pushed out to the Provider Edge (PE) routers that are attached to that customer's Attachment Circuits (ACs). It is conceivable that some ISPs automate this using out-of-band mechanisms as well, although the authors are unaware of any existing mechanisms that support this.
ISP的客户可能无法充分计划预先计划的维护，或者更可能的是，由于ISP客户的新下游客户出现紧急情况，他们可能需要迅速开始宣布新的IP前缀。不幸的是，ISP采用的例行自动化过程意味着它可能在24小时内不会开始更新其网络上的路由策略，因为ISP或ISP使用的IRR可能每24小时只镜像一次对IRR资源的更改。常规/自动化流程的时间间隔不响应直接付款客户的需求，这些客户在极少数情况下需要快速更改其政策。在这些情况下，当客户迫切需要更新立即生效时，他们将致电其ISP的网络运营中心（NOC），要求ISP立即获取新的IRR对象，并将这些更改推送到其网络上。从客户联系其ISP的NOC到将新的过滤策略推出到连接到该客户连接电路（ACs）的提供商边缘（PE）路由器，这通常只需5分钟即可完成。可以想象，一些ISP也会使用带外机制实现自动化，尽管作者不知道有任何现有机制支持这一点。
Ultimately, the aforementioned latency with respect to "emergency changes" in IRR resources that need to be reflected in near-real-time in the network is compounded if the IRR resources were being used by third-party ISPs to perform filtering on their peering circuits, where typically no such policies are employed today for this very reason. It is likely that the length of time that it takes IRRs to mirror changes will have to be dramatically reduced. There will need to be a corresponding reduction in the time required by ISPs to evaluate whether those changes should be recompiled and reflected in router policies that would then get pushed out to Autonomous System Border Routers (ASBRs) connected to peering circuits on their network.
最终，如果第三方ISP使用IRR资源在其对等电路上执行过滤，则需要在网络中近实时反映的IRR资源中的“紧急变化”的上述延迟将变得复杂，而目前通常由于这个原因没有采用此类策略。内部收益率反映变化所需的时间很可能必须大幅缩短。ISP需要相应减少所需时间，以评估这些更改是否应重新编译并反映在路由器策略中，然后将其推送到连接到其网络上对等电路的自治系统边界路由器（ASBR）。
As mentioned previously, after a resource holder made changes to their resources in an IRR, those changes would automatically be distributed to other IRRs, ISPs would then learn of those changes, generate new BGP policies, and then apply those to the appropriate subset of routers in their ASes. However, in the past, one additional step is necessary in order to have any of those new BGP policies take effect in the control plane and to allow/deny the
如前所述，资源持有者在IRR中对其资源进行更改后，这些更改将自动分发给其他IRR，然后ISP将了解这些更改，生成新的BGP策略，然后将这些更改应用于其ASE中适当的路由器子集。然而，在过去，为了使这些新的BGP策略中的任何一个在控制平面中生效，并允许/拒绝该策略，还需要另外一个步骤
updated resource from a customer to their ISP and from their immediately upstream ISP to the ISP's peers. It was necessary (often manually) to actually induce BGP on each router to apply the new policy within the control plane, thus learning of a newly announced/ changed IP prefix (or, dropping a deleted IP prefix). Unfortunately, most of these methods not only were highly impactful operationally, but they also affected traffic forwarding to IP destinations that were unrelated to the most recent changes to the BGP policy.
从客户到其ISP以及从其直接上游ISP到ISP对等方的更新资源。有必要（通常是手动）实际诱导每个路由器上的BGP在控制平面内应用新策略，从而了解新宣布/更改的IP前缀（或删除删除的IP前缀）。不幸的是，这些方法中的大多数不仅在操作上具有很高的影响力，而且还影响了到IP目的地的流量转发，这些目的地与BGP策略的最新更改无关。
Historically, a customer would have to (re-)announce the new IP prefix toward their ISP, but only after the ISP had put the new BGP policies into effect. Alternatively, the ISP would have to reset the entire eBGP session from Provider Edge to Customer Edge either by: a) bouncing the entire interface toward the customer (e.g., shutdown / no shutdown) or b) clearing the eBGP session toward the customer (e.g., clear ip bgp neighbor <IP address of CE router>, where <IP address of CE router> represents a specific IP address). The latter two cases were, of course, the most highly impactful impact and thus could generally only be performed off-hours during a maintenance window.
历史上，客户必须（重新）向其ISP宣布新的IP前缀，但只有在ISP实施新的BGP策略之后。或者，ISP必须通过以下方式将整个eBGP会话从提供商边缘重置到客户边缘：a）将整个接口反弹到客户（例如，关闭/不关闭）或b）清除到客户的eBGP会话（例如，清除ip bgp邻居<CE路由器的ip地址>，其中<CE路由器的ip地址>表示一个特定的ip地址）。当然，后两种情况是影响最大的，因此通常只能在维护时段的非工作时间执行。
Once the new IP prefix has been successfully announced by the customer and permitted by the newly updated policy at the ISP's PEs (attached to that customer), it would be propagated to that ISP's ASBRs, attached to peers, at the perimeter of the ISP network. Unfortunately, if those peers had either not yet learned of the changes to resources in the IRR or pushed out new BGP policies (and, reset their BGP sessions immediately afterward) incorporating those changes, then the newly announced route would also get dropped at the ingress ASBRs of the peers.
一旦客户成功地宣布了新的IP前缀，并且ISP的PEs（连接到该客户）的最新更新策略允许，它将传播到ISP网络周边连接到对等方的ISP ASBR。不幸的是，如果这些对等方尚未了解到IRR中资源的变化，或者推出了包含这些变化的新BGP策略（并在随后立即重置其BGP会话），那么新宣布的路由也将在对等方的入口ASBR处被丢弃。
Ultimately, either of the two scenarios above further lengthens the effective time it would take for changes in IRR resources to take effect within BGP in the network. Fortunately, BGP has been enhanced over the last several years in order that changes within BGP policy will take effect without requiring a service-impacting reset of BGP sessions. Specifically, BGP soft-reconfiguration (Section 1 of [RFC2918]) and, later, Route Refresh Capability for BGP-4 [RFC2918] were developed so that ISPs, or their customers, could induce BGP to apply a new policy while leaving both the existing eBGP session active as well as (unaffected) routes active in both the Loc-RIB and, more importantly, FIB of the router. Thus, using either of these mechanisms, an ISP or its peers currently will deploy a newly generated BGP policy, based on changes to resources within the IRR, and immediately trigger a notification -- which does not impact service -- to the BGP process to have those changes take effect in their control plane, either allowing a new IP prefix to be announced or an old IP prefix to be dropped. This dramatically reduces the
最终，上述两种情况中的任何一种都会进一步延长内部收益率资源变化在网络BGP内生效所需的有效时间。幸运的是，BGP在过去几年中得到了增强，以便BGP策略中的更改能够生效，而不需要影响BGP会话重置的服务。具体而言，BGP软重新配置（第1节[RFC2918]）以及随后BGP-4[RFC2918]的路由刷新功能的开发，使ISP或其客户能够诱导BGP应用新策略，同时使现有eBGP会话和（未受影响的）路由在Loc RIB和更重要的是，路由器的FIB。因此，使用这两种机制中的任何一种，ISP或其对等方当前将基于IRR内资源的更改部署新生成的BGP策略，并立即向BGP进程触发通知（不影响服务），以使这些更改在其控制平面中生效，允许宣布新的IP前缀或删除旧的IP前缀。这大大降低了成本
length of time from when changes are propagated throughout the IRRs to when those changes are actually operational within BGP policy in an ISP's network.
从更改在IRR中传播到这些更改在ISP网络的BGP策略中实际运行的时间长度。
Routers in the mid 1990s rarely supported incrementally updatable prefix filters for BGP; therefore, if new information was received from a policy or internal configuration database that would impact a policy applied to a given eBGP peer, the entire prefix list or access list would need to be deleted and rewritten, compiled, and installed. This was very tedious and commonly led to leaked routes during the time when the policy was being rewritten, compiled, and applied on a router. Furthermore, application of a new policy would not automatically result in new ingress or egress reachability advertisements from that new policy, because routers at the time would require a reset of the eBGP sessions for routing information to be evaluated by the new policy. Of course, resetting of an eBGP session had implications on traffic forwarding during the time the eBGP session was reestablished and new routing information was learned.
20世纪90年代中期的路由器很少支持BGP的可增量更新前缀过滤器；因此，如果从策略或内部配置数据库接收到的新信息会影响应用于给定eBGP对等方的策略，则需要删除并重写、编译和安装整个前缀列表或访问列表。这是非常乏味的，通常会导致在重写、编译策略并将其应用于路由器期间泄漏路由。此外，新策略的应用不会自动导致来自该新策略的新入口或出口可达性广告，因为当时的路由器将需要重新设置eBGP会话，以便由新策略评估路由信息。当然，在重新建立eBGP会话和学习新的路由信息期间，重新设置eBGP会话会对流量转发产生影响。
Routers now support the ability to perform incremental, and in situ, updates to filter lists consisting of IP prefixes and/or AS_PATHs that are used within an ingress or egress BGP policy. In addition, routers also can apply those incremental updates to policy, with no traffic disruption, using BGP soft-reconfiguration or BGP Route Refresh, as discussed in the previous section.
路由器现在支持对由IP前缀和/或在入口或出口BGP策略中使用的AS_路径组成的筛选器列表执行增量和就地更新。此外，路由器还可以使用BGP软重新配置或BGP路由刷新将这些增量更新应用于策略，而不会造成流量中断，如前一节所述。
Historically, routers had very limited storage capacity and would have difficulty in storing an extremely large BGP policy on-board. This was typically the result of router hardware vendors using an extremely limited amount of NVRAM for storage of router configurations.
从历史上看，路由器的存储容量非常有限，很难在板上存储非常大的BGP策略。这通常是由于路由器硬件供应商使用非常有限的NVRAM存储路由器配置。
Another challenge with historical router hardware was that writing to NVRAM was extremely slow. For example, when the router configuration had changed as a result of updating a BGP policy that needed to accommodate changes in IRR resources, this would result in extremely long times to write out these configuration changes. Sometimes, due to bugs, this would result in loss of protocol keep-alives. This would cause an impact to routing or forwarding of packets through the platform.
历史路由器硬件的另一个挑战是写入NVRAM的速度非常慢。例如，当路由器配置因更新需要适应IRR资源变化的BGP策略而发生变化时，这将导致写入这些配置变化的时间非常长。有时，由于错误，这将导致协议保持有效性丢失。这将对通过平台的数据包路由或转发造成影响。
The above limitations have largely been resolved with equipment from the last few years that ships with increasing amounts of non-volatile storage such as PCMCIA or USB flash cards, hard disk drives, or solid-state disk drives.
在过去几年中，随着非易失性存储器（如PCMCIA或USB闪存卡、硬盘驱动器或固态磁盘驱动器）数量的不断增加，上述限制已在很大程度上得到解决。
However, as capacities and technologies have evolved on modern routing hardware, so have some of the scaling requirements of the data. In some large networks, configuration growth has begun to "pose challenges" [IEPG89_NTT]. While the enhancements of hardware have overcome some historical limitations, evidence suggests that further optimizations in configuration processing may be needed in some cases. Some of the more recent operational issues include scheduler slips and protracted commit times. This suggests that even though many historical hurdles have been overcome, there are still motivations to optimize and modernize IRR technologies.
然而，随着容量和技术在现代路由硬件上的发展，数据的一些扩展需求也在发展。在一些大型网络中，配置增长已开始“构成挑战”[IEPG89\u NTT]。虽然硬件的增强克服了一些历史局限性，但有证据表明，在某些情况下可能需要进一步优化配置处理。最近的一些操作问题包括调度程序错误和提交时间过长。这表明，尽管许多历史障碍已被克服，但仍有优化和现代化内部收益率技术的动机。
Historically, there has not been a standardized modeling language for network configuration or an associated method to update router configurations. When an ISP detected a change in resources within the IRR, it would fashion a vendor-dependent BGP policy and upload that to the router usually via the following method.
历史上，还没有一种标准化的网络配置建模语言或更新路由器配置的相关方法。当ISP检测到IRR内的资源发生变化时，它将形成依赖于供应商的BGP策略，并通常通过以下方法将其上传到路由器。
First, an updated BGP policy configuration snippet is generated via processes running on an out-of-band server. Next, the operator uses either telnet or SSH [RFC4253] to log in to the CLI of a target router and issue vendor-dependent CLI commands that will trigger the target router to fetch the new configuration snippet via TFTP, FTP, or Secure Copy (SCP) stored on the out-of-band server. The target router will then perform syntax checking on that configuration snippet and, if that passes, merge that configuration snippet into the running configuration of the router's control software. At this point, the new BGP policy configuration snippet is active within the control plane of the router. One last step remains -- the operator will issue a CLI command to induce the router to perform a "soft reset", via BGP soft-reconfiguration or BGP Route Refresh, of the associated BGP session in order to trigger the router to apply the new policy to routes learned from that BGP session without disrupting traffic forwarding.
首先，通过带外服务器上运行的进程生成更新的BGP策略配置代码段。接下来，运营商使用telnet或SSH[RFC4253]登录到目标路由器的CLI，并发出依赖于供应商的CLI命令，该命令将触发目标路由器通过存储在带外服务器上的TFTP、FTP或安全副本（SCP）获取新配置片段。然后，目标路由器将对该配置代码段执行语法检查，如果检查通过，则将该配置代码段合并到路由器控制软件的运行配置中。此时，新的BGP策略配置片段在路由器的控制平面内处于活动状态。最后一步仍然存在——操作员将发出CLI命令，通过BGP软重新配置或BGP路由刷新，诱导路由器对相关BGP会话执行“软重置”，以触发路由器将新策略应用于从该BGP会话学到的路由，而不中断流量转发。
More recently, operators have the ability to use NETCONF [RFC6241] / SSH (or, TLS) from an out-of-band server to push a BGP configuration snippet from an out-of-band server toward a target router that has that capability. However, this activity is still dependent on generating, via the out-of-band server, a vendor-dependent XML configuration snippet that would get uploaded via SSH or TLS to the target router.
最近，运营商能够从带外服务器使用NETCONF[RFC6241]/SSH（或TLS）将BGP配置片段从带外服务器推送到具有该功能的目标路由器。但是，此活动仍然依赖于通过带外服务器生成依赖于供应商的XML配置片段，该片段将通过SSH或TLS上传到目标路由器。
In the future, the ability to upload new Route Origin Authorization (ROA) information may be provided from the RPKI to routers via the RPKI-RTR [RFC6810] protocol. However, this will not allow operators the ability to upload other configuration information such as BGP policy information (AS_PATHs, BGP communities, etc.) that might be associated with that ROA information, as they can from IRR-generated BGP policies.
将来，可以通过RPKI-RTR[RFC6810]协议从RPKI向路由器提供上传新路由来源授权（ROA）信息的能力。但是，这将不允许运营商上传可能与该ROA信息相关的其他配置信息，如BGP策略信息（如路径、BGP社区等），因为他们可以从IRR生成的BGP策略上传这些信息。
As discussed above, many of the problems that have traditionally stifled IRR deployment have, themselves, become historical. However, there are still real operational considerations that limit IRR usage from realizing its full effectiveness. The potential for IRRs to express inter-domain routing policy, and to allow relying parties to learn policy, has always positioned them as a strong candidate to aid the security postures of operators. However, while routing density and complexity have grown, so have some of the challenges facing IRRs (even today). Because of this state increase, the potential to model all policies for all ASes in all routers may still remain illusive. In addition, without an operationally deployed resource certification framework that can tie policies to resource holders, there is a fundamental limitation that still exists.
如上所述，许多传统上阻碍内部收益率部署的问题本身已经成为历史。然而，仍然存在一些实际的操作考虑因素，这些因素限制了内部收益率的使用，使其无法充分发挥效力。IRR表达域间路由策略的潜力，以及允许依赖方学习策略的潜力，始终将其定位为帮助运营商的安全姿态的有力候选。然而，随着路由密度和复杂性的增加，IRR面临的一些挑战也在增加（即使在今天）。由于这种状态的增加，为所有路由器中的所有ASE建模所有策略的可能性可能仍然是幻想。此外，如果没有一个可将政策与资源持有者联系起来的可操作部署的资源认证框架，则仍然存在一个根本性的限制。
One of the central concerns with IRRs is the ability of an IRR operator to remotely influence the routing operations of an external consumer. Specifically, if the processing of IRR contents can become burdensome, or if the policy statements can be crafted to introduce routing problems or anomalies, then operators may want to be circumspect about ingesting contents from external parties. A resource certification framework should be used to address the authorization of IRR statements to make attestations and assertions (as mentioned in Section 4.1, and discussed in Section 5.1).
IRR的核心问题之一是IRR运营商远程影响外部消费者路由操作的能力。具体而言，如果IRR内容的处理可能会变得繁重，或者如果策略声明可能会导致路由问题或异常，那么运营商可能希望在接收外部方的内容时谨慎行事。应使用资源认证框架来处理IRR声明的授权，以进行认证和断言（如第4.1节所述，并在第5.1节中讨论）。
Additionally, the external and systemic dependencies introduced by IRRs and other such systems employed to inform routing policy, and how tightly or loosely coupled those systems are to the global routing system and operational networks, introduce additional vectors that operators and system architects should consider when evaluating attack surface and service dependencies associated with those elements. These attributes and concerns are certainly not unique to IRRs, and operators should evaluate the implications of external systems and the varying degrees of coupling and operational buffers that might be installed in their environments.
此外，IRR和其他用于通知路由策略的此类系统引入的外部和系统依赖性，以及这些系统与全球路由系统和运营网络的紧密或松散耦合程度，在评估与这些元素相关联的攻击表面和服务依赖性时，引入操作符和系统架构师应该考虑的附加向量。这些属性和问题肯定不是IRR独有的，运营商应该评估外部系统的影响以及可能安装在其环境中的不同程度的耦合和操作缓冲区。
[IEPG89_NTT] Mauch, J., "NTT BGP Configuration Size and Scope", IEPG meeting before IETF 89, March 2014, <http://iepg.org/2014-03-02-ietf89/ ietf89_iepg_jmauch.pdf>.
[IEPG89_NTT]Mauch，J.，“NTT BGP配置规模和范围”，IEPG在IETF 89之前的会议，2014年3月<http://iepg.org/2014-03-02-ietf89/ ietf89_iepg_jmauch.pdf>。
[IRR_LIST] Merit Network, Inc., "List of Routing Registries", <http://www.irr.net/docs/list.html>.
[IRR_列表]美德网络公司，“路由注册表列表”<http://www.irr.net/docs/list.html>.
[MERIT-IRRD] Merit, "IRRd - Internet Routing Registry Daemon", <http://www.irrd.net>.
[MERIT-IRRD]MERIT，“IRRD-Internet路由注册表守护程序”<http://www.irrd.net>.
[RC_HotNetsX] Osterweil, E., Amante, S., Massey, D., and D. McPherson, "The Great IPv4 Land Grab: Resource Certification for the IPv4 Grey Market", DOI 10.1145/2070562.2070574, <http://dl.acm.org/citation.cfm?id=2070574>.
[RC_HotNetsX]Osterweil，E.，Amante，S.，Massey，D.，和D.McPherson，“IPv4大抢夺：IPv4灰色市场的资源认证”，DOI 10.1145/2070562.2070574<http://dl.acm.org/citation.cfm?id=2070574>.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>.
[RFC959]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，DOI 10.17487/RFC0959，1985年10月<http://www.rfc-editor.org/info/rfc959>.
[RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, DOI 10.17487/RFC1787, April 1995, <http://www.rfc-editor.org/info/rfc1787>.
[RFC1787]Rekhter，Y，“多提供商互联网中的路由”，RFC 1787，DOI 10.17487/RFC1787，1995年4月<http://www.rfc-editor.org/info/rfc1787>.
[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, DOI 10.17487/RFC2622, June 1999, <http://www.rfc-editor.org/info/rfc2622>.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 2622，DOI 10.17487/RFC2622，1999年6月<http://www.rfc-editor.org/info/rfc2622>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <http://www.rfc-editor.org/info/rfc2725>.
[RFC2725]Villamizar，C.，Alaettinoglu，C.，Meyer，D.，和S.Murphy，“路由策略系统安全”，RFC 2725，DOI 10.17487/RFC27252999年12月<http://www.rfc-editor.org/info/rfc2725>.
[RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. Meyer, "Routing Policy System Replication", RFC 2769, DOI 10.17487/RFC2769, February 2000, <http://www.rfc-editor.org/info/rfc2769>.
[RFC2769]Villamizar，C.，Alaettinoglu，C.，Govindan，R.，和D.Meyer，“路由策略系统复制”，RFC 2769，DOI 10.17487/RFC2769，2000年2月<http://www.rfc-editor.org/info/rfc2769>.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, <http://www.rfc-editor.org/info/rfc2918>.
[RFC2918]Chen，E.“BGP-4的路由刷新能力”，RFC 2918，DOI 10.17487/RFC2918，2000年9月<http://www.rfc-editor.org/info/rfc2918>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<http://www.rfc-editor.org/info/rfc4253>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，DOI 10.17487/RFC6480，2012年2月<http://www.rfc-editor.org/info/rfc6480>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <http://www.rfc-editor.org/info/rfc6810>.
[RFC6810]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议”，RFC 6810，DOI 10.17487/RFC6810，2013年1月<http://www.rfc-editor.org/info/rfc6810>.
[RIPE638] RIPE NCC, "Autonomous System (AS) Number Assignment Policies", March 2015, <https://www.ripe.net/publications/docs/ripe-638>.
[RIPE638]成熟的NCC，“自主系统（AS）编号分配政策”，2015年3月<https://www.ripe.net/publications/docs/ripe-638>.
[RPKI_SIZING] Osterweil, E., Manderson, T., White, R., and D. McPherson, "Sizing Estimates for a Fully Deployed RPKI", Verisign Labs Technical Report 1120005 version 2, December 2012, <http://techreports.verisignlabs.com/ tr-lookup.cgi?trid=1120005&rev=2>.
[RPKI_尺寸]Osterweil，E.，Manderson，T.，White，R.，和D.McPherson，“完全部署RPKI的尺寸估算”，Verisign实验室技术报告1120005第2版，2012年12月<http://techreports.verisignlabs.com/ tr lookup.cgi？trid=1120005&rev=2>。
[TASRS] Osterweil, E., Amante, S., and D. McPherson, "TASRS: Towards a Secure Routing System Through Internet Number Resource Certification", Verisign Labs Technical Report 1130009, February 2013, <http://techreports.verisignlabs.com/ tr-lookup.cgi?trid=1130009&rev=1>.
[TASRS]Osterweil，E.，Amante，S.，和D.McPherson，“TASRS：通过互联网号码资源认证实现安全路由系统”，Verisign实验室技术报告1130009，2013年2月<http://techreports.verisignlabs.com/ tr lookup.cgi？trid=1130009&rev=1>。
Acknowledgements
致谢
The authors would like to acknowledge and thank Chris Morrow, Jeff Haas, Wes George, and John Curran for their help and constructive feedback.
作者要感谢Chris Morrow、Jeff Haas、Wes George和John Curran的帮助和建设性反馈。
Authors' Addresses
作者地址
Danny McPherson Verisign, Inc.
丹尼·麦克弗森公司。
Email: dmcpherson@verisign.com
Email: dmcpherson@verisign.com
Shane Amante Apple, Inc.
夏恩·阿曼特苹果公司。
Email: amante@apple.com
Email: amante@apple.com
Eric Osterweil Verisign, Inc.
Eric Osterweil Verisign公司。
Email: eosterweil@verisign.com
Email: eosterweil@verisign.com
Larry J. Blunk Merit Network, Inc.
拉里·J·布伦克价值网络公司。
Email: ljb@merit.edu
Email: ljb@merit.edu
Dave Mitchell Singularity Networks
戴夫·米切尔奇点网络
Email: dave@singularity.cx
Email: dave@singularity.cx