Network Working Group C. Villamizar
Request for Comments: 2725 Avici
Category: Standards Track C. Alaettinoglu
ISI
D. Meyer
Cisco
S. Murphy
TIS
December 1999
Network Working Group C. Villamizar
Request for Comments: 2725 Avici
Category: Standards Track C. Alaettinoglu
ISI
D. Meyer
Cisco
S. Murphy
TIS
December 1999
Routing Policy System Security
路由策略系统安全
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
成熟的数据库规范和RPSL语言定义了在路由策略系统中作为表示信息基础的语言。路由策略系统信息的存储库称为路由注册表。路由注册表提供了一种交换信息的方法，这些信息是解决许多对Internet运行非常重要的问题所必需的。路由策略系统的实施和部署必须保持一定程度的完整性，才能用于任何操作。本文档通过提供身份验证和授权模型来满足确保数据完整性的需要。
Table of Contents
目录
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Implicit Policy Assumptions . . . . . . . . . . . . . . . . 5
4 Scope of Security Coverage . . . . . . . . . . . . . . . . 5
5 Organization of this Document . . . . . . . . . . . . . . 6
6 Goals and Requirements . . . . . . . . . . . . . . . . . . 6
7 Data Representation . . . . . . . . . . . . . . . . . . . . 10
8 Authentication Model . . . . . . . . . . . . . . . . . . . 10
9 Authorization Model . . . . . . . . . . . . . . . . . . . . 12
9.1 Maintainer Objects . . . . . . . . . . . . . . . . . . 12
9.2 as-block and aut-num objects . . . . . . . . . . . . . 13
9.3 inetnum objects . . . . . . . . . . . . . . . . . . . 13
9.4 route objects . . . . . . . . . . . . . . . . . . . . 14
9.5 reclaim and no-reclaim attributes . . . . . . . . . . 14
9.6 Other Objects . . . . . . . . . . . . . . . . . . . . 15
9.7 Objects with AS Hierarchical Names . . . . . . . . . . 16
9.8 Query Processing . . . . . . . . . . . . . . . . . . . 16
9.9 Adding to the Database . . . . . . . . . . . . . . . . 17
9.10 Modifying or Deleting Database Objects . . . . . . . . 19
10 Data Format Summaries . . . . . . . . . . . . . . . . . . 20
10.1 Changes to the RIPE/RPSL Schema . . . . . . . . . . . 20
Appendicies
A Core and Non-Core Functionality . . . . . . . . . . . . . . 23
B Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23
C Technical Discussion . . . . . . . . . . . . . . . . . . . 26
C.1 Relaxing requirements for ease of registry . . . . . 27
C.2 The address lending issue . . . . . . . . . . . . . . 28
C.3 Dealing with non-conformant or questionable older
data . . . . . . . . . . . . . . . . . . . . . . . . . 29
D Common Operational Cases . . . . . . . . . . . . . . . . . 30
D.1 simple hierarchical address allocation and route
allocation . . . . . . . . . . . . . . . . . . . . . . 31
D.2 aggregation and multihomed more specific routes . . . 32
D.3 provider independent addresses and multiple origin
AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
D.4 change in Internet service provider . . . . . . . . . 32
D.5 renumbering grace periods . . . . . . . . . . . . . . 32
E Deployment Considerations . . . . . . . . . . . . . . . . . 33
F Route Object Authorization Pseudocode . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Security Considerations . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Implicit Policy Assumptions . . . . . . . . . . . . . . . . 5
4 Scope of Security Coverage . . . . . . . . . . . . . . . . 5
5 Organization of this Document . . . . . . . . . . . . . . 6
6 Goals and Requirements . . . . . . . . . . . . . . . . . . 6
7 Data Representation . . . . . . . . . . . . . . . . . . . . 10
8 Authentication Model . . . . . . . . . . . . . . . . . . . 10
9 Authorization Model . . . . . . . . . . . . . . . . . . . . 12
9.1 Maintainer Objects . . . . . . . . . . . . . . . . . . 12
9.2 as-block and aut-num objects . . . . . . . . . . . . . 13
9.3 inetnum objects . . . . . . . . . . . . . . . . . . . 13
9.4 route objects . . . . . . . . . . . . . . . . . . . . 14
9.5 reclaim and no-reclaim attributes . . . . . . . . . . 14
9.6 Other Objects . . . . . . . . . . . . . . . . . . . . 15
9.7 Objects with AS Hierarchical Names . . . . . . . . . . 16
9.8 Query Processing . . . . . . . . . . . . . . . . . . . 16
9.9 Adding to the Database . . . . . . . . . . . . . . . . 17
9.10 Modifying or Deleting Database Objects . . . . . . . . 19
10 Data Format Summaries . . . . . . . . . . . . . . . . . . 20
10.1 Changes to the RIPE/RPSL Schema . . . . . . . . . . . 20
Appendicies
A Core and Non-Core Functionality . . . . . . . . . . . . . . 23
B Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23
C Technical Discussion . . . . . . . . . . . . . . . . . . . 26
C.1 Relaxing requirements for ease of registry . . . . . 27
C.2 The address lending issue . . . . . . . . . . . . . . 28
C.3 Dealing with non-conformant or questionable older
data . . . . . . . . . . . . . . . . . . . . . . . . . 29
D Common Operational Cases . . . . . . . . . . . . . . . . . 30
D.1 simple hierarchical address allocation and route
allocation . . . . . . . . . . . . . . . . . . . . . . 31
D.2 aggregation and multihomed more specific routes . . . 32
D.3 provider independent addresses and multiple origin
AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
D.4 change in Internet service provider . . . . . . . . . 32
D.5 renumbering grace periods . . . . . . . . . . . . . . 32
E Deployment Considerations . . . . . . . . . . . . . . . . . 33
F Route Object Authorization Pseudocode . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Security Considerations . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
1 Overview
1概述
The Internet Routing Registry (IRR) has evolved to meet a need for Internet-wide coordination. This need was described in RFC-1787, an informational RFC prepared on behalf of the IAB [14]. The following summary appears in Section 7 of RFC-1787.
Internet路由注册中心（IRR）已经发展到满足Internet范围内协调的需要。RFC-1787中描述了这种需求，这是一份代表IAB编制的信息性RFC[14]。以下总结见RFC-1787第7节。
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.
虽然确保互联网范围内的协调可能越来越困难，但随着互联网的不断发展，如果能够跨组织边界共享有关各组织路由要求的信息，那么互联网范围路由的稳定性和一致性将大大受益。此类信息可用于各种情况，从故障排除到检测和消除冲突的路由要求。互联网的规模意味着信息应该被分发。目前正在开展工作，以建立该信息的保管处（路由登记处），以及开发分析和利用该信息的工具。
A routing registry must maintain some degree of integrity to be of any use. The degree of integrity required depends on the usage of the routing policy system.
路由注册表必须保持一定程度的完整性才能发挥任何作用。所需的完整性程度取决于路由策略系统的使用情况。
An initial intended usage of routing policy systems such as the RIPE database had been in an advisory capacity, documenting the intended routing policies for the purpose of debugging. In this role a very weak form of authentication was deemed sufficient.
路由策略系统（如成熟数据库）最初的预期用途是以咨询的身份，记录预期的路由策略，以便进行调试。在这个角色中，一种非常弱的身份验证形式被认为是足够的。
The IRR is increasingly used for purposes that have a stronger requirement for data integrity and security. This document addresses issues of data integrity and security that is consistent with the usage of the IRR and which avoids compromising data integrity and security even if the IRR is distributed among less trusted repositories.
IRR越来越多地用于对数据完整性和安全性有更高要求的目的。本文档解决了与IRR使用一致的数据完整性和安全性问题，即使IRR分布在不太可信的存储库中，也可以避免损害数据完整性和安全性。
2 Background
2背景
An early routing policy system used in the NSFNET, the policy routing database (PRDB), provided a means of determining who was authorized to announce specific prefixes to the NSFNET backbone. The need for a policy database was recognized as far back as 1989 [6, 4]. By 1991 the database was in place [5]. Authentication was accomplished by requiring confirmation and was a manually intensive process. This solved the problem for the NSFNET, but was oriented toward holding the routing policy of a single organization.
NSFNET中使用的早期路由策略系统，即策略路由数据库（PRDB），提供了一种确定谁有权向NSFNET主干宣布特定前缀的方法。早在1989年就认识到需要一个政策数据库[6,4]。到1991年，数据库已经建立[5]。身份验证是通过要求确认来完成的，是一个手动密集的过程。这解决了NSFNET的问题，但面向保持单个组织的路由策略。
The problem since has become more difficult. New requirements have emerged.
自那以后，这个问题变得更加困难。出现了新的要求。
1. There is a need to represent the routing policies of many organizations.
1. 需要表示许多组织的路由策略。
2. CIDR and overlapping prefixes and the increasing complexity of routing policies and the needs of aggregation have introduced new requirements.
2. CIDR和重叠前缀以及路由策略的日益复杂和聚合需求引入了新的需求。
3. There is a need to assure integrity of the data and delegate authority for the data representing specifically allocated resources to multiple persons or organizations.
3. 需要确保数据的完整性，并将代表特定分配资源的数据授权给多个人或多个组织。
4. There is a need to assure integrity of the data and distribute the storage of data subsets to multiple repositories.
4. 需要确保数据的完整性，并将数据子集的存储分发到多个存储库。
The RIPE effort specificly focused on the first issue and needs of the European community. Its predecessor, the PRDB, addressed the needs of a single organization, the NSF. The RIPE database formats as described in [2] were the basis of the original IRR.
成熟的努力具体侧重于第一个问题和欧洲共同体的需要。其前身PRDB解决了单一组织NSF的需求。[2]中描述的成熟数据库格式是原始IRR的基础。
Routing protocols themselves provide no assurance that the origination of a route is legitimate and can actually reach the stated destination. The nature of CIDR allows more specific prefixes to override less specific prefixes [9, 15, 8]. Even with signed route origination, there is no way to determine if a more specific prefix is legitimate and should override a less specific route announcement without a means of determining who is authorized to announce specific prefixes. Failing to do so places no assurance of integrity of global routing information and leaves an opportunity for a very effective form of denial of service attack.
路由协议本身不能保证路由的发起是合法的，并且实际上可以到达指定的目的地。CIDR的性质允许更具体的前缀覆盖不太具体的前缀[9,15,8]。即使是有签名的路由发起，也无法确定更具体的前缀是否合法，是否应该覆盖不太具体的路由通知，而无需确定谁有权宣布特定前缀。如果不这样做，则无法保证全局路由信息的完整性，并为一种非常有效的拒绝服务攻击留下了机会。
The Routing Policy System Language (RPSL) [1, 13] was a fairly substantial evolutionary step in the data representation which was largely targeted at addressing the second group of needs. The PRDB accommodated CIDR in 1993 [12] and the RIPE database accommodated the entry of CIDR prefixes from inception, but RPSL provides many needed improvements including explicit support for aggregation.
路由策略系统语言（RPSL）[1，13]是数据表示的一个相当重要的进化步骤，其主要目标是满足第二组需求。PRDB在1993年适应了CIDR[12]，成熟的数据库从一开始就适应了CIDR前缀的输入，但RPSL提供了许多需要的改进，包括对聚合的显式支持。
This document addresses the third group of needs identified above.
本文件涉及上述第三类需求。
While the current implementation supporting weak authentication doesn't guarantee integrity of the data, it does provide extensive mechanisms to make sure that all involved parties get notified when a change is made to the database, whether the change was malicious or intended. This provides inadequate protection against additions. Since the software is increasingly used to configure the major parts
虽然当前支持弱身份验证的实现不能保证数据的完整性，但它确实提供了广泛的机制，以确保在对数据库进行更改时通知所有相关方，无论更改是恶意的还是有意的。这不足以防止添加。由于软件越来越多地用于配置主要部件
of the Internet infrastructure, it is not considered to be adequate anymore to know about and have the ability roll back unintended changes. Therefore, more active security mechanisms need to be developed to prevent such problems before they happen.
在互联网基础设施中，了解并有能力回滚意外更改已不再足够。因此，需要建立更积极的安全机制，在此类问题发生之前加以预防。
A separate document will be needed to address the fourth group of needs.
需要一份单独的文件来解决第四类需要。
3 Implicit Policy Assumptions
3隐含的政策假设
The authorization model encodes certain policies for allocation of address numbers, AS numbers, and for the announcement of routes. Implicit to the authorization model is a very limited number of policy assumptions.
授权模型将地址号码分配的特定策略编码为号码，并用于路由公告。授权模型隐含的是数量非常有限的策略假设。
1. Address numbers are allocated hierarchically. The IANA delegates portions of the address space to the regional registries (currently ARIN, APNIC and RIPE), which in turn delegate address space to their members, who can assign addresses to their customers.
1. 地址号是按层次分配的。IANA将地址空间的一部分委托给区域注册中心（目前为ARIN、APNIC和RIME），区域注册中心又将地址空间委托给其成员，这些成员可以为其客户分配地址。
2. AS numbers are allocated either singly or in small blocks by registries. Registries are allocated blocks of AS numbers, thereby making the allocation hierarchical.
2. AS号码由登记处单独分配或分块分配。注册表被分配为数字块，从而使分配具有层次性。
3. Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space.
3. 只有在获得作为公告编号的始发地持有人的同意以及地址空间持有人的同意后，方可公布路线。
4. AS numbers and IP address registries may be different entities from routing registries.
4. AS号码和IP地址注册表可能与路由注册表是不同的实体。
For subsets of any of these three allocation spaces, network addresses, AS numbers, and routes, these restrictions may be loosened or disabled by specifying a very weak authorization method or an authentication method of "none". However, even when no authentication mechanism is used, all involved parties can be notified about the changes that occurred through use of the existing "notify" attribute.
对于这三个分配空间、网络地址、AS号码和路由中的任何一个的子集，可以通过指定非常弱的授权方法或“无”的身份验证方法来放松或禁用这些限制。但是，即使没有使用身份验证机制，也可以通过使用现有的“notify”属性将发生的更改通知所有相关方。
4 Scope of Security Coverage
4安全保障范围
This document is intended only to provide an authentication and authorization model to insure the integrity of the policy data in a registry. Only authetication and authorization of additions, deletions, and changes to the database are within the scope of this document. Authentication and authorization of database queries is
本文档仅用于提供身份验证和授权模型，以确保注册表中策略数据的完整性。只有对数据库的添加、删除和更改的授权和授权才在本文档的范围内。数据库查询的身份验证和授权是必需的
explicitly out of scope. Mutual authentication of queries, that is authenticating both the origin of the query and the repository from which query results are obtained, is also out of scope.
明显超出范围。查询的相互身份验证（即对查询的来源和获取查询结果的存储库进行身份验证）也不在范围之内。
5 Organization of this Document
5本文件的组织
Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this document. Goals are described in Section 6. Section 7 through Section 9 provide descriptions of the changes and discussion. Section 10 provides a concise summary of data formats and semantics. Appendix C through Appendix E provide additional technical discussion, examples, and deployment considerations.
在本文件中，假设您熟悉CRIPE-181[2]和RPSL[1]。第6节描述了目标。第7节至第9节提供了变更和讨论的说明。第10节简要介绍了数据格式和语义。附录C至附录E提供了额外的技术讨论、示例和部署注意事项。
Goals and Requirements Section 6 provides a more detailed description of the issues and identifies specific problems that need to be solved, some of which require a degree of cooperation in the Internet community.
目标和要求第6节对问题进行了更详细的描述，并确定了需要解决的具体问题，其中一些问题需要在互联网社区进行一定程度的合作。
Data Representation Section 7 provides some characteristics of RPSL and formats for external representations of information.
数据表示部分7提供了RPSL的一些特征和信息的外部表示格式。
Authentication Model Section 8 describes current practice, proposes additional authentication methods, and describes the extension mechanism if additional methods are needed in the future.
认证模型第8节描述了当前的实践，提出了额外的认证方法，并描述了将来需要额外方法时的扩展机制。
Authorization Model Section 9 describes the means of determining whether a transaction contains the authorization needed to add, modify, or delete specific data objects, based on stated authentication requirements in related data objects.
授权模型第9节描述了根据相关数据对象中声明的身份验证要求，确定事务是否包含添加、修改或删除特定数据对象所需的授权的方法。
Data Format Summaries Section 10 provides a concise reference to the data formats and steps in transaction processing.
数据格式摘要第10节简要介绍了交易处理中的数据格式和步骤。
Technical Discussion Section C contains some discussion of technical tradeoffs.
技术讨论C部分包含一些关于技术权衡的讨论。
Common Operational Cases Section D provides some examples drawn from past operational experience with the IRR.
常见操作案例D部分提供了一些从IRR过去操作经验中得出的示例。
Deployment Considerations Section E describes some deployment issues and discusses possible means of resolution.
部署注意事项E部分描述了一些部署问题，并讨论了可能的解决方法。
6 Goals and Requirements
6目标和要求
The Internet is an open network. This openness and the large scale of the Internet can present operational problems. Technical weaknesses that allow misconfiguration or errant operation in part of
互联网是一个开放的网络。互联网的这种开放性和大规模可能会带来运营问题。技术缺陷，允许在部分设备中进行错误配置或错误操作
the network to propagate globally or which provide potentials for simple denial of service attacks should be eliminated to the extent that it is practical. The integrity of routing information is critical in assuring that traffic goes where it is supposed to.
应在可行的范围内消除可能在全球传播或提供简单拒绝服务攻击的网络。路由信息的完整性对于确保通信量达到预期目的至关重要。
An accidental misconfiguration can direct traffic toward routers that cannot reach a destination for which they are advertising reachability. This is commonly caused by misconfigured static routes though there are numerous other potential causes. Static routes are often used to provide constant apparent reachability to single homed destinations. Some of the largest ISPs literally have thousands of static routes in their networks. These are often entered manually by operators. Mistyping can divert traffic from a completely unrelated destination to a router with no actual reachability to the advertised destination. This can happen and does happen somewhat regularly. In addition, implementation bugs or severe misconfigurations that result in the loss of BGP AS path information or alteration of prefix length can result in the advertisement of large sets of routes. Though considerably more rare, on a few occasions where this has occurred the results were catastrophic.
意外的错误配置可能会将流量导向无法到达其宣传可达性的目的地的路由器。这通常是由错误配置的静态路由引起的，尽管还有许多其他潜在原因。静态路由通常用于提供到单宿目的地的恒定明显可达性。一些最大的ISP在其网络中有数千条静态路由。这些通常由操作员手动输入。输入错误会将流量从完全无关的目的地转移到路由器，而实际上无法到达播发的目的地。这可能发生，而且确实有一定的规律性。此外，导致丢失BGP作为路径信息或更改前缀长度的实现错误或严重错误配置可能会导致公布大量路由。虽然这种情况更为罕见，但在发生这种情况的少数情况下，结果却是灾难性的。
Where there is the potential for an accidental misconfiguration in a remote part of the Internet affecting the global Internet there is also the potential for malice. For example, it has been demonstrated by accident that multiple hour outages at a major institution can be caused by a laptop and a dial account if proper precautions are not taken. The dial account need not be with the same provider used by the major institution.
如果互联网的远程部分可能会出现意外的错误配置，从而影响全球互联网，那么也可能存在恶意。例如，事故证明，如果不采取适当的预防措施，大型机构的多小时停机可能是由笔记本电脑和拨号帐户引起的。拨号帐户不必与主要机构使用的同一个提供商使用。
The potential for error is increased by the CIDR preference for more specific routes [8]. If an institution advertises a single route of a given length and a distant router advertises a more specific route covering critical hosts, the more specific route, if accepted at all, is preferred regardless of administrative weighting or any routing protocol attributes.
CIDR对更具体路线的偏好增加了出错的可能性[8]。如果机构公布给定长度的单一路由，而远程路由器公布覆盖关键主机的更具体路由，则无论管理权重或任何路由协议属性如何，更具体的路由（如果被接受）都是首选的。
There is a need to provide some form of checks on whether a route advertisement is valid. Today checks are typically made against the border AS advertising the route. This prevents accepting routes from the set of border AS that could not legitimately advertise the route. Theses checks rely on the use of information registered in the IRR to generate lists of prefixes that could be advertised by a specific border AS. Checks can also be made against the origin AS. If policy information were sufficiently populated, checks could be made against the entire AS path, but this is not yet feasible.
需要对路线广告是否有效提供某种形式的检查。今天，在宣传路线时，通常会对边境进行检查。这将阻止接受来自边界集的路由，因为它无法合法地公布路由。这些检查依赖于使用IRR中注册的信息来生成前缀列表，这些前缀可以通过特定的边界作为标记发布。也可以根据原产地进行检查。如果策略信息已充分填充，则可以对整个AS路径进行检查，但这还不可行。
The use of a routing registry can also make it more difficult for prefixes to be used without authorization such as unallocated prefixes or prefixes allocated to another party.
使用路由注册表还可能使未经授权使用前缀变得更加困难，例如未分配的前缀或分配给另一方的前缀。
In summary, some of the problems being addressed are:
总之，正在解决的一些问题是：
o Localizing the impact of accidental misconfiguration made by Internet Providers to that provider's networks only.
o 将互联网提供商意外错误配置的影响仅局限于该提供商的网络。
o Eliminating the potential for an Internet provider's customer to use malicious misconfiguration of routing as a denial of service attack if the provider route filters their customers. Localizing the denial of service to that Internet provider only if the immediate Internet service provider does not route filter their customers but other providers route filter the route exchange at the interprovider peering.
o 消除互联网提供商的客户在提供商路由过滤其客户时，将恶意错误配置路由作为拒绝服务攻击的可能性。仅当直接Internet服务提供商未对其客户进行路由筛选，但其他提供商在interprovider对等点对路由交换进行路由筛选时，才将拒绝服务本地化到该Internet提供商。
o Eliminating the unauthorized use of address space.
o 消除未经授权的地址空间使用。
If the data within a routing registry is critical, then the ability to change the data must be controlled. Centralized authorities can provide control but centralization can lead to scaling problems (and is politically distasteful).
如果路由注册表中的数据至关重要，则必须控制更改数据的能力。中央集权可以提供控制，但中央集权可能导致规模问题（在政治上令人厌恶）。
Address allocation and name allocation is already delegated. Since delegation can be to outside registries it is at least somewhat distributed [11]. Autonomous System (AS) numbers are allocated by the same authorities. It makes sense to delegate the routing number space in a manner similar to the address allocation and AS number allocation. The need for this delegation of authority to numerous registries increases the difficulty of maintaining the integrity of the body of information as a whole.
地址分配和名称分配已委派。由于委托可以是到外部注册中心的，所以它至少在某种程度上是分布式的[11]。自治系统（AS）编号由相同的机构分配。以类似于地址分配和AS号码分配的方式委派路由号码空间是有意义的。将权力下放给许多登记处的需要增加了维护整个信息体系完整性的难度。
As a first step, the database can be somewhat centrally administered with authority granted to many parties to change the information. This is the case with the current IRR. There are a very small number of well trusted repositories and a very large number of parties authorized to make changes. Control must be exercised over who can make changes and what changes they can make. The distinction of who vs what separates authentication from authorization.
作为第一步，可以在某种程度上集中管理数据库，并授予许多方面更改信息的权限。目前的内部收益率就是这样。只有极少数的受信任的存储库和大量授权进行更改的各方。必须控制谁可以做出改变以及他们可以做出什么改变。身份验证与授权之间的区别。
o Authentication is the means to determine who is attempting to make a change.
o 身份验证是确定谁试图进行更改的手段。
o Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.
o 授权是确定是否允许通过特定身份验证检查的事务执行给定的操作。
Different portions of the database will require different methods of authentication. Some applications will require authentication based on strong encryption. In other cases software supporting strong encryption may not be necessary or may not be legally available. For this reason multiple authentication methods must be supported, selected on a per object basis through the specification of authentication methods in the maintainer object "auth" attribute. The authentication methods may range from very weak data integrity checks to cryptographicly strong signatures. The authorization model must sure that the use of weak integrity checks in parts of the database does not compromise the overall integrity of the database.
数据库的不同部分将需要不同的身份验证方法。某些应用程序需要基于强加密的身份验证。在其他情况下，支持强加密的软件可能不是必需的，也可能不是合法可用的。因此，必须支持多个身份验证方法，通过在maintainer对象“auth”属性中指定身份验证方法，根据每个对象选择。认证方法的范围从非常弱的数据完整性检查到加密强签名。授权模型必须确保在部分数据库中使用弱完整性检查不会损害数据库的整体完整性。
Additional requirements are placed on the authorization model if the database is widely distributed with delegations made to parties that may not be trustworthy or whose security practices may be lacking. This problem must be addressed in the authorization model in order to enable later evolution to a more distributed routing registry.
如果数据库被广泛分发，并向不可信或缺乏安全做法的当事方授权，则对授权模型提出了额外要求。必须在授权模型中解决此问题，以便以后能够发展到更分布式的路由注册表。
Autonomous system numbers can be delegated in blocks and subdelegated as needed and then individual AS numbers assigned. Address allocation is a simple numeric hierarchy. Route allocation is somewhat more complicated. The key attributes in a route object (key with regard to making it unique) contain both an address prefix and an AS number, known as the origin AS. The addition of a route object must be validated against the authorization criteria for both the AS and the address prefix. Route objects may exist for the same prefix with multiple origin AS values due to a common multihoming practice that does not require a unique origin AS. There is often no correlation between the origin AS of a prefix and the origin AS of overlapping more specific prefixes.
自治系统编号可以分块委派，并根据需要再委派，然后作为分配的编号单独委派。地址分配是一个简单的数字层次结构。路线分配稍微复杂一些。路由对象中的键属性（关于使其唯一的键）包含地址前缀和AS编号，称为原点AS。必须根据AS和地址前缀的授权标准验证路由对象的添加。由于不需要唯一原点作为值的常见多原点实践，可能存在具有多个原点作为值的同一前缀的管线对象。前缀的原点和重叠的更具体前缀的原点之间通常没有相关性。
There are numerous operational cases that must be accommodated. Some of the more common are listed below. These are explored in greater detail in Appendix D with discussion of technical tradeoffs in Appendix C.
有许多操作案例必须考虑。下面列出了一些更常见的方法。附录D对这些问题进行了更详细的探讨，附录C对技术权衡进行了讨论。
o simple hierarchical address allocation and route allocation
o 简单的分层地址分配和路由分配
o aggregation and multihomed more specific routes
o 聚合和多址更具体的路由
o provider independent addresses and multiple origin AS
o 独立于提供程序的地址和多个源地址
o changing Internet service providers
o 改变互联网服务供应商
o renumbering grace periods
o 重新编号宽限期
The authorization model must accommodate a variety of policies regarding the allocation of address space and cannot mandate the use of any one model. There is no standardization of address allocation policies though guidelines do exist [11, 16]. Whether authorization allows the recovery of address space must be selectable on a per object basis and may differ in parts of the database. This issue is discussed further in Appendix C.
授权模型必须适应有关地址空间分配的各种策略，并且不能强制使用任何一种模型。地址分配策略没有标准化，尽管存在指导原则[11,16]。授权是否允许恢复地址空间必须根据每个对象进行选择，并且在数据库的某些部分可能有所不同。附录C进一步讨论了该问题。
7 Data Representation
7数据表示
RPSL provides a complete description of the contents of a routing repository [1]. Many RPSL data objects remain unchanged from the RIPE specifications and RPSL references the RIPE-181 specification as recorded in RFC-1786 [2]. RPSL provides external data representation. Data may be stored differently internal to a routing registry.
RPSL提供路由存储库内容的完整描述[1]。许多RPSL数据对象与RIME规范保持不变，RPSL参考了RFC-1786[2]中记录的RIME-181规范。RPSL提供外部数据表示。数据可能以不同的方式存储在路由注册表内部。
Some database object types or database attributes must be added to RPSL to record the delegation of authority and to improve the authentication and authorization mechanisms. These additions are very few and are described in Section 8 and Section 9.
必须将某些数据库对象类型或数据库属性添加到RPSL中，以记录授权委托并改进身份验证和授权机制。这些新增内容非常少，第8节和第9节对此进行了描述。
Some form of encapsulation must be used to exchange data. The defacto encapsulation has been the one which the RIPE tools accept, a plain text file or plain text in the body of an RFC-822 formatted mail message with information needed for authentication derived from the mail headers or the body of the message. Merit has slightly modified this using the PGP signed portion of a plain text file or PGP signed portion of the body of a mail message. These very simple forms of encapsulation are suitable for the initial submission of a database transaction.
必须使用某种形式的封装来交换数据。事实上的封装是成熟的工具所接受的，即RFC-822格式邮件消息体中的纯文本文件或纯文本，其中包含从邮件头或邮件体派生的身份验证所需的信息。Merit使用纯文本文件的PGP签名部分或邮件消息正文的PGP签名部分稍微修改了这一点。这些非常简单的封装形式适用于数据库事务的初始提交。
The encapsulation of registry transaction submissions, registry queries and registry responses and exchanges between registries is outside the scope of this document. The encapsulation of registry transaction submissions and exchanges between registries is outside the scope of this document.
注册表事务提交、注册表查询和注册表响应以及注册表之间的交换的封装不在本文件的范围内。注册表事务提交和注册表间交换的封装不在本文件的范围之内。
8 Authentication Model
8认证模型
The maintainer objects serve as a container to hold authentication filters. A reference to a maintainer within another object defines authorization to perform operations on the object or on a set of related objects. The maintainer is typically referenced by name in mnt-by attributes of objects. Further details on the use of maintainers are provided in Section 9.1.
maintainer对象用作保存身份验证筛选器的容器。对另一个对象中的维护者的引用定义了对该对象或一组相关对象执行操作的授权。在mnt中，维护者通常通过对象属性的名称引用。第9.1节提供了有关使用维护器的更多详细信息。
The maintainer contains one or more "auth" attributes. Each "auth" attribute begins with a keyword identifying the authentication method followed by the authentication information needed to enforce that method. The PGPKEY method is slightly syntactically different in that the method PGPKEY is a substring.
维护程序包含一个或多个“auth”属性。每个“auth”属性都以标识身份验证方法的关键字开头，后跟强制该方法所需的身份验证信息。PGPKEY方法在语法上稍有不同，因为PGPKEY方法是一个子字符串。
Authentication methods currently supported include the following. Note that pgp-from is being replaced by the pgpkey (see Section 10 and [18]).
当前支持的身份验证方法包括以下内容。请注意，pgp由pgpkey取代（见第10节和[18]）。
mail-from This is a very weak authentication check and is discouraged. The authentication information is a regular expression over ASCII characters. The maintainer is authenticated if the from or reply-to fields in RFC-822 mail headers are matched by this regular expression. Since mail forgery is quite easy, this is a very weak form of authentication.
来自此站点的邮件是非常弱的身份验证检查，不鼓励使用。身份验证信息是ASCII字符上的正则表达式。如果RFC-822邮件头中的“发件人”或“回复”字段与此正则表达式匹配，则对维护者进行身份验证。由于邮件伪造非常容易，这是一种非常弱的身份验证形式。
crypt-pw This is another weak form of authentication. The authentication information is a fixed encrypted password in UNIX crypt format. The maintainer is authenticated if the transaction contains the clear text password of the maintainer. Since the password is in clear text in transactions, it can be captured by snooping. Since the encrypted form of the password is exposed, it is subject to password guessing attacks.
crypt pw这是另一种弱身份验证形式。身份验证信息是UNIX crypt格式的固定加密密码。如果事务包含维护者的明文密码，则对维护者进行身份验证。因为密码在事务中是明文的，所以可以通过窥探来捕获。由于密码的加密形式是公开的，因此会受到密码猜测攻击。
pgp-from This format is being replaced by the "pgpkey" so that the public key certificate will be available to remote repositories. This is Merit's PGP extension. The authentication information is a signature identity pointing to an external public key ring. The maintainer is authenticated if the transaction (currently PGP signed portion of a mail message) is signed by the corresponding private key.
此格式的pgp将替换为“pgpkey”，以便公钥证书可用于远程存储库。这是Merit的PGP扩展。认证信息是指向外部公钥环的签名标识。如果事务（当前邮件消息的PGP签名部分）由相应的私钥签名，则维护者将通过身份验证。
pgpkey This keyword takes the form "PGPKEY-hhhhhhhh", where "hhhhhhhh" is the hex representation of the four byte id of the PGP public key used for authentication. The public key certificate is stored in a separate object as described in [18].
pgpkey此关键字的形式为“pgpkey-hhhhhhh”，其中“hhhhhhhhh”是用于身份验证的PGP公钥的四字节id的十六进制表示形式。公钥证书存储在单独的对象中，如[18]所述。
Repositories may elect to disallow the addition of "auth" attributes specifying weaker forms of authentication and/or disallow their use in local transaction submissions. Repositories are encouraged to disallow the addition of "auth" attributes with the deprecated "pgp-from" method.
存储库可以选择不允许添加指定较弱身份验证形式的“auth”属性和/或不允许在本地事务提交中使用这些属性。建议存储库禁止使用不推荐的“pgp from”方法添加“auth”属性。
Any digital signature technique can in principle be used for authentication. Transactions should be signed using multiple digital signature techniques to allow repositories or mirrors that only use a
原则上，任何数字签名技术都可以用于认证。应使用多种数字签名技术对事务进行签名，以允许仅使用
subset of the techniques to verify at least one of the signatures. The selection of digital signature techniques is not within the scope of this document.
验证至少一个签名的技术子集。数字签名技术的选择不在本文件的范围内。
9 Authorization Model
9授权模型
The authorization model must accommodate the requirements outlined in Section 6. A key feature of the authorization model is the recognition that authorization for the addition of certain types of data objects must be derived from related data objects.
授权模型必须符合第6节中概述的要求。授权模型的一个关键特征是认识到添加某些类型数据对象的授权必须来自相关数据对象。
With multiple repositories, objects not found in RPSL are needed to control AS delegations and new attributes are needed in existing objects to control subdelegation. The definition of RPSL objects used to implement a distrubuted routing registry system is not within the scope of this document.
对于多个存储库，RPSL中未找到的对象需要作为委托进行控制，而现有对象中需要新属性来控制子委托。用于实现分布式路由注册表系统的RPSL对象的定义不在本文档的范围内。
The maintainer objects serve as a container to hold authentication filters. The authentication methods are described in Section 8. The maintainer can be referenced by name in other objects, most notably in the mnt-by attributes of those objects.
maintainer对象用作保存身份验证筛选器的容器。第8节描述了认证方法。在其他对象中，可以通过名称引用维护者，尤其是在mnt中，可以通过这些对象的属性引用维护者。
Maintainers themselves contain mnt-by attributes. In some cases the mnt-by in a maintainer will reference the maintainer itself. In this case, authorization to modify the maintainer is provided to a (usually very limited) set of identities. A good practice is to create a maintainer containing a long list of identities authorized to make specific types of changes but have the maintainer's mnt-by attribute reference a far more restrictive maintainer more tightly controlling changes to the maintainer object itself.
维护者本身包含mnt属性。在某些情况下，维修人员的mnt by将引用维修人员本身。在这种情况下，修改维护者的授权被提供给一组（通常非常有限的）身份。一个好的做法是创建一个维护者，其中包含一长串授权进行特定类型更改的身份，但让维护者的属性引用mnt成为限制性更强的维护者，更严格地控制对维护者对象本身的更改。
The mnt-by attribute is mandatory in all objects. Some data already exists without mnt-by attributes. A missing mnt-by attribute is interpreted as the absence of any control over changes. This is highly inadvisable and most repositories will no longer allow this.
mnt by属性在所有对象中都是必需的。某些数据已存在，但属性中没有mnt。缺少mnt by属性被解释为对更改缺乏任何控制。这是非常不可取的，大多数存储库将不再允许这样做。
An additional maintainer reference can occur through a new attribute, "mnt-routes", and is used in aut-num, inetnum and route objects. The "mnt-routes" attribute is an extension to RPSL and is described in detail in Section 10.
可以通过一个新属性“mnt routes”进行额外的维护人员引用，并在aut num、inetnum和route对象中使用。“mnt routes”属性是RPSL的扩展，在第10节中有详细描述。
A mnt-routes attribute in an aut-num object allows addition of route objects with that AS number as the origin to the maintainers listed. A mnt-routes attribute in an inetnum object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute in a route object allows addition of route objects with
aut num对象中的mnt routes属性允许将编号为原点的路由对象添加到列出的维护者。inetnum对象中的mnt routes属性允许添加具有精确匹配或更特定前缀的路由对象。route对象中的mnt routes属性允许添加具有
exact matching or more specific prefixes. A mnt-routes attribute does not allow changes to the aut-num, inetnum, or route object where it appears. A mnt-routes may optionally be constrained to only apply to a subset of more specific routes.
精确匹配或更具体的前缀。mnt routes属性不允许更改其出现的aut num、inetnum或route对象。mnt路由可以选择性地约束为仅应用于更特定路由的子集。
Where "mnt-routes" or "mnt-lower" are applicable, any maintainer referenced in the "mnt-by" still apply. The set of applicable maintainers for whatever check is being made is the union of the "mnt-routes" or "mnt-lower" and the "mnt-by". For example, when authorizing a route object software would look at "mnt-routes", if it does not exist, look at "mnt-lower", if that does not exist look at "mnt-by".
如果“mnt路线”或“mnt较低路线”适用，“mnt路线”中引用的任何维修人员仍然适用。正在进行的任何检查的适用维护人员集是“mnt路线”或“mnt较低”和“mnt by”的并集。例如，当授权路由对象时，软件将查看“mnt路由”，如果不存在，请查看“mnt较低”，如果不存在，请查看“mnt较低”。
An "as-block" object is needed to delegate a range of AS numbers to a given repository. This is needed for authorization and it is needed to avoid having to make an exhaustive search of all repositories to find a specific AS. This search would not be an issue now but would be if a more distributed routing repository is used. Distributed registry issues are not within the scope of this document.
需要一个“as block”对象来将一系列as编号委托给给定的存储库。这是授权所必需的，并且需要避免对所有存储库进行彻底搜索以找到特定的AS。这种搜索现在不会成为问题，但如果使用更分布式的路由存储库，就会成为问题。分布式注册表问题不在本文档的范围内。
The "as-block" object also makes it possible to separate AS number allocation from registration of AS routing policy.
“as block”对象还可以将as号码分配与as路由策略的注册分开。
as-block: AS1321 - AS1335
as模块：AS1321-AS1335
The "aut-num" describes the routing policy for an AS and is critical for router configuration of that AS and for analysis performed by another AS. For the purpose of this document it is sufficient to consider the aut-num solely as a place holder identifying the existence of an AS and providing a means to associate authorization with that AS when adding "route" objects.
“aut num”描述AS的路由策略，对于该AS的路由器配置以及由另一AS执行的分析至关重要。就本文件而言，将AUT NUM视为一个标识As的存在的位置持有者是足够的，并提供一种将授权与该授权相关联的方法，如添加“路由”对象时。
The "as-block" object is proposed here solely as a means of recording the delegation of blocks of AS numbers to alternate registries and in doing so providing a means to direct queries and a means to support hierarchical authorization across multiple repositories.
此处提出的“as block”对象仅作为记录as编号的块到备用注册中心的委托的一种方法，并在这样做时提供了一种指导查询的方法和一种支持跨多个存储库的分层授权的方法。
The "inetnum" exists to support address allocation. For external number registries, such as those using "[r]whoisd[++]" the "inet-num" can serve as a secondary record that is added when an address allocation is made in the authoritative database. Such records could be added by a address registry such as ARIN as a courtesy to the corresponding routing registry.
“inetnum”的存在是为了支持地址分配。对于外部号码注册中心，例如使用“[r]whoisd[+]”的注册中心，“inet num”可以用作在权威数据库中进行地址分配时添加的辅助记录。这些记录可以由地址注册中心（如ARIN）添加，作为对相应路由注册中心的礼遇。
inetnum: 193.0.0.0 - 193.0.0.255 source: IANA
inetnum:193.0.0.0-193.0.0.255来源：IANA
Currently there are a quite few route objects in more than one registry. Quite a few are registered with an origin AS for which they have never been announced. There is a legitimate reason to be in more than one origin AS.
目前，在多个注册表中有相当多的路由对象。有相当一部分注册的原产地从未公布过。有一个合法的理由可以作为一个以上的来源。
The "route" object is used to record routes which may appear in the global routing table. Explicit support for aggregation is provided. Route objects exist both for the configuration of routing information filters used to isolate incidents of erroneous route announcements (Section 6) and to support network problem diagnosis.
“路由”对象用于记录可能出现在全局路由表中的路由。提供了对聚合的显式支持。路由对象既用于配置路由信息过滤器，用于隔离错误路由公告事件（第6节），也用于支持网络问题诊断。
A reclaim attribute is needed in as-block, inetnum and route objects. The reclaim attribute allows a control to be retained over more specific AS, IP address or route space by allowing modify and delete privileges regardless of the mnt-by in the object itself.
as block、inetnum和route对象中需要回收属性。通过允许修改和删除特权（无论对象本身中的mnt是什么），Recall属性允许在更具体的AS、IP地址或路由空间上保留控件。
The reclaim attribute provides the means to enforce address lending. It allows cleanup in cases where entities cease to exist or as a last presort means to correct errors such as parties locking themselves out of access to their own objects. To specify all more specific objects the reclaim attribute value should be "ALL". To allow finer control a set of prefixes can be specified.
回收属性提供了强制地址借出的方法。它允许在实体不存在的情况下进行清理，或者作为最后一种预排序手段来纠正错误，例如各方将自己锁定在无法访问自己的对象的位置。要指定所有更具体的对象，回收属性值应为“全部”。为了允许更精细的控制，可以指定一组前缀。
A no-reclaim attribute can be used to provide explicit exceptions. A reclaim attribute can only be added to an existing object if the addition of the reclaim attribute does not remove autonomy of existing more specific objects that are covered by the new reclaim attribute.
无回收属性可用于提供显式异常。如果添加回收属性不会移除新回收属性所涵盖的现有更特定对象的自治性，则只能将回收属性添加到现有对象。
1. A reclaim attribute can be added to an existing object if there are no existing exact matches or more specific objects overlapped by the new reclaim attribute, or
1. 如果没有现有的精确匹配项或新的回收属性重叠的更多特定对象，则可以将回收属性添加到现有对象，或者
2. if the submitter is listed in the maintainer pointed to by the mnt-by of the objects which are overlapped, or
2. 如果提交者被列在mnt指定的维护者中，则为重叠对象的一个，或
3. if any overlapped object is listed in a no-reclaim attribute in the object where the reclaim is being added.
3. 如果添加回收的对象中的“无回收”属性中列出了任何重叠对象。
Similarly, a submitter may delete a no-reclaim attribute from an object only when that submitter is the only maintainer listed in the mnt-by attributes of any overlapped objects. If the submitter is not listed in any of the maintainers pointed to by the mnt-by attributes for one or more overlapped object, then the submitter is not permitted to delete the no-reclaim attribute.
类似地，仅当提交者是mnt中按任何重叠对象的属性列出的唯一维护者时，提交者才可以从对象中删除“无回收”属性。如果提交者未在mnt针对一个或多个重叠对象的属性指向的任何维护者中列出，则不允许提交者删除“无回收”属性。
If neither a reclaim or no-reclaim attribute is present, then more specific objects of a given object cannot be modified by the maintainer of the less specified object unless the maintainer is also listed as a maintainer in the more specific object. However, the addition of a new route or inetnum object must pass authentication of the largest less specific prefix as part of the authentication check described in Section 9.9.
如果既不存在回收属性，也不存在回收属性，则指定对象的维护者无法修改给定对象的更特定对象，除非该维护者也被列为更特定对象中的维护者。但是，添加新路由或inetnum对象必须通过最大不太特定前缀的身份验证，作为第9.9节所述身份验证检查的一部分。
See Section 10 for a full description of the reclaim and no-reclaim attributes.
有关回收和无回收属性的完整描述，请参见第10节。
Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes do have a numeric hierarchy. Some examples are "maintainers", "people" and "role" objects. For these objects, lack of any hierarchy leads to two problems.
许多RPSL辅助对象没有自然的层次结构，就像数字、Internet地址和路由有数字层次结构一样。例如“维护者”、“人员”和“角色”对象。对于这些对象，缺少层次结构会导致两个问题。
1. There is no hierarchy that can be exploited to direct queries to alternate registries. At some point the query strategy of searching all known registries becomes impractical.
1. 没有可以利用的层次结构将查询定向到备用注册表。在某种程度上，搜索所有已知注册表的查询策略变得不切实际。
2. There is no hierarchy on which authorizations of additions can be based.
2. 没有可用于添加授权的层次结构。
The first problem can be addressed by considering the name space for each of the ancillary objects to be unique only within the local database and to use explicit references to an external repository where needed. To specify an external repository reference, the object key is preceded by the name of the repository and the delimiter "::". For example a NIC handle may take the form "RIPE::CO19". Currently there is a desire to keep NIC handles unique so the naming convention of appending a dash and the repository name is used. Prepending the repository name provides the unique name space since an object in the RIPE database referencing "CO19" would be interpreted as "RIPE::CO19" by default, but it would still be possible to query or reference "IANA::CO19". There is no possibility of accidentally forgetting to adhere to the conventions when making an addition and the existing objects are accommodated, including cases where name conflicts have already occurred.
第一个问题可以通过考虑每个辅助对象的名称空间仅在本地数据库中是唯一的，并在需要时使用对外部存储库的显式引用来解决。要指定外部存储库引用，对象键前面会有存储库的名称和分隔符“：”。例如，NIC句柄可以采用“crime:：CO19”的形式。目前，人们希望保持NIC句柄的唯一性，以便使用附加破折号和存储库名称的命名约定。在存储库名称前加前缀提供了唯一的名称空间，因为在成熟数据库中引用“CO19”的对象默认情况下会被解释为“成熟：：CO19”，但仍然可以查询或引用“IANA：：CO19”。在进行添加时，不可能意外忘记遵守约定，并且现有对象已被容纳，包括已经发生名称冲突的情况。
The second problem can be partially addressed by using a referral system for the addition of maintainers and requiring that any other object be submitted by a registered maintainer or by IANA. The referral system would allow any existing maintainer to add another maintainer. This can be used in parallel with the addition of other object types to support the maintenance of those objects. For example, when adding a subdomain to the "domain" hierarchy (in the RIPE repository where domains are also handled), even when adding a new domain to a relatively flat domain such as "com", there is already a maintainer for the existing domain. The existing maintainer can add the maintainer that will be needed for the new domain in addition to adding the new domain and giving the new maintainer the right to modify it.
第二个问题可以通过使用推荐系统添加维护人员并要求注册维护人员或IANA提交任何其他对象来部分解决。推荐系统将允许任何现有的维护者添加另一个维护者。这可以与添加其他对象类型并行使用，以支持这些对象的维护。例如，在将子域添加到“域”层次结构（在成熟的存储库中，域也在其中处理）时，即使在将新域添加到相对平坦的域（如“com”）时，现有域也已经有了维护者。现有的维护人员可以添加新域所需的维护人员，此外还可以添加新域并赋予新维护人员修改该域的权利。
An organization gaining a presence on the Internet for the first time would be given a maintainer. This maintainer may list a small number of very trusted employees that are authorized to modify the maintainer itself. The organization itself can then add another maintainer listing a larger set of employees but listing the more restrictive maintainer in the mnt-by attributes of the maintainers themselves. The organization can then add people and role objects as needed and any other objects as needed and as authorization permits.
第一次在互联网上出现的组织将获得一名维护人员。该维护者可能会列出少数非常值得信任的员工，他们有权修改维护者本身。然后，组织本身可以添加另一个维护者，列出更多的员工，但在mnt中根据维护者本身的属性列出限制性更强的维护者。然后，组织可以根据需要添加人员和角色对象，以及根据需要和授权许可添加任何其他对象。
Many RPSL objects do not have a natural hierarchy of their own but allow hierarchical names. Some examples are the object types "as-set" and "route-set". An as-set may have a name corresponding to no naming hierarchy such as "AS-Foo" or it may have a hierarchical name of the form "AS1:AS-Bar".
许多RPSL对象没有自己的自然层次结构，但允许使用层次结构名称。一些示例是对象类型“as set”和“route set”。as集合可能具有与非命名层次结构（如“as Foo”）对应的名称，也可能具有“AS1:as Bar”形式的层次结构名称。
When a hierarchical name is not used, authorization for objects such as "as-set" and "route-set" correspond to the rules for objects with no hierarchy described in Section 9.6.
当不使用分层名称时，对诸如“as set”和“route set”等对象的授权与第9.6节中描述的无分层对象的规则相对应。
If hierarchical names are used, then the addition of an object must be authorized by the aut-num whose key is named by everything to the left of the rightmost colon in the name of the object being added. Authorization is determined by first using the mnt-lower maintainer reference, or if absent, using the mnt-by reference.
如果使用分层名称，则添加对象必须由aut num授权，aut num的键由添加对象名称中最右边冒号左侧的所有内容命名。授权是通过首先使用mnt下级维修人员参考来确定的，如果没有，则使用mnt逐参考来确定。
A query may have to span multiple repositories. All queries should be directed toward a local repository which may mirror the root repository and others. Currently each IRR repository mirrors all other repositories. In this way, the query may be answered by the local repository but draw data from others.
一个查询可能必须跨越多个存储库。所有查询都应指向本地存储库，该存储库可能镜像根存储库和其他存储库。当前，每个IRR存储库镜像所有其他存储库。这样，查询可以由本地存储库回答，但可以从其他存储库提取数据。
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
当应用于多个存储库时，下面的机制假设存在用于遍历存储库的属性。此属性的定义被视为分布式注册表问题，超出了本文档的范围。
For object types that have a natural hierarchy, such as aut-num, inet-num, and route, the search begins at the root database and follows the hierarchy. For objects types that have no natural hierarchy, such as maintainer, person, and role objects, the search is confined to a default database unless a database is specified. The default database is the same database as an object from which a reference is made if the query is launched through the need to follow a reference. Otherwise the default is generally the local database or a default set by the repository. The default can be specified in the query itself as described in Section 9.7.
对于具有自然层次结构的对象类型，例如aut num、inet num和route，搜索从根数据库开始，并遵循层次结构。对于没有自然层次结构的对象类型，如maintainer、person和role对象，除非指定了数据库，否则搜索仅限于默认数据库。如果查询是通过需要跟随引用而启动的，则默认数据库与从中进行引用的对象的数据库相同。否则，默认值通常是本地数据库或存储库设置的默认值。可以在查询本身中指定默认值，如第9.7节所述。
In the absense of attributes to traverse multiple registries a search of all repositories is needed. With such attributes the search would proceed as follows. In searching for an AS, the delegation attribute in AS blocks can be consulted, moving the search to data from other repositories. Eventually the AS is either found or the search fails. The search for an inetnum is similar. Less specific inetnums may refer the search to other databases. Eventually the most specific inetnum is found and its status (assigned or not assigned) can be determined. The definition of attributes for traversal of repositories is considered a distrbiuted registry issue and is not within the scope of this document.
在缺少遍历多个注册中心的属性的情况下，需要搜索所有存储库。有了这些属性，搜索将按如下方式进行。在搜索AS时，可以参考AS块中的委托属性，将搜索移动到其他存储库中的数据。最终，AS要么被找到，要么搜索失败。对inetnum的搜索类似。不太具体的inetnums可能会将搜索引用到其他数据库。最终找到最具体的inetnum，并确定其状态（已分配或未分配）。用于遍历存储库的属性的定义被视为分布式注册表问题，不在本文档的范围内。
The search for a route in the presence of attributes for the traversal of multiple registries is similar except the search may branch to more than one repository. The most specific route in one repository may be more specific than the most specific in another. In looking for a route object it makes sense to return the most specific route that is not more specific than the query requests regardless of which repository that route is in rather than return one route from each repository that contains a less specific overlap.
在存在用于遍历多个注册中心的属性的情况下搜索路由与此类似，只是搜索可能会分支到多个存储库。一个存储库中最具体的路由可能比另一个存储库中最具体的路由更具体。在查找route对象时，无论路由位于哪个存储库中，返回不比查询请求更具体的最具体路由都是有意义的，而不是从每个存储库返回一条包含不太具体重叠的路由。
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
当应用于多个存储库时，下面的机制假设存在用于遍历存储库的属性。此属性的定义被视为分布式注册表问题，超出了本文档的范围。
The root repository must be initially populated at some epoch with a few entries. An initial maintainer is needed to add more maintainers. The referral-by attribute can be set to refer to itself in this special case (Section 10 describes the referral-by). When
根存储库最初必须在某个时间段填充一些条目。需要一个初始的维护人员来添加更多的维护人员。在这种特殊情况下，可将“参照方式”属性设置为参照自身（第10节描述了参照方式）。什么时候
adding an inetnum or a route object an existing exact match or a less specific overlap must exist. A route object may be added based on an exact match or a less specific inetnum. The root repository must be initially populated with the allocation of an inetnum covering the prefix 0/0, indicating that some address allocation authority exists. Similarly an initial as-block is needed covering the full AS number range.
添加inetnum或管线对象时，必须存在现有的精确匹配或不太特定的重叠。可以基于精确匹配或不太具体的inetnum添加路由对象。根存储库最初必须使用包含前缀0/0的inetnum的分配来填充，这表示存在某些地址分配权限。同样，需要一个初始as块来覆盖整个as编号范围。
When adding an object with no natural hierarchy, the search for an existing object follows the procedure outlined in Section 9.8.
添加没有自然层次结构的对象时，对现有对象的搜索遵循第9.8节中概述的过程。
When adding an aut-num (an AS), the same procedure used in a query is used to determine the appropriate repository for the addition and to determine which maintainer applies. The sequence of AS-block objects and repository delegations is followed. If the aut-num does not exist, then the submission must match the authentication specified in the maintainer for the most specific AS-block in order to be added.
添加aut num（AS）时，使用查询中使用的相同过程确定添加的适当存储库，并确定应用哪个维护程序。遵循AS块对象和存储库委托的顺序。如果aut num不存在，则提交必须与维护程序中为最特定的AS块指定的身份验证相匹配，才能添加。
The procedure for adding an inetnum is similar. The sequence of inet-num blocks is followed until the most specific is found. The submission must match the authentication specified in the maintainer for the most specific inetnum overlapping the addition.
添加inetnum的过程与此类似。遵循inet num块的顺序，直到找到最具体的块。提交必须与维护程序中为添加的最具体的inetnum指定的身份验证相匹配。
Adding a route object is somewhat more complicated. The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or if no applicable route object is found, then an inetnum.
添加管线对象稍微复杂一些。路由对象提交必须满足两个身份验证标准。它必须匹配aut num中指定的身份验证和路由对象中指定的身份验证，或者如果未找到适用的路由对象，则匹配inetnum。
An addition is submitted with an AS number and prefix as its key. If the object already exists, then the submission is treated as a modify (see Section 9.10). If the aut-num does not exist on a route add, then the addition is rejected (see Section C for further discussion of tradeoffs). If the aut-num exists then the submission is checked against the applicable maintainer. A search is then done for the prefix first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds it will return one or more route objects. The submission must match an applicable maintainer in at least one of these route objects for the addition to succeed. If the search for a route object fails, then a search is performed for an inetnum that exactly matches the prefix or for the most specific inetnum that is less specific than the route object submission. The search for an inetnum should never fail but it may return an unallocated or reserved range. The inetnum status must be "allocated" and the submission must match the maintainer.
以AS编号和前缀作为密钥提交加法。如果对象已经存在，则提交将被视为修改（参见第9.10节）。如果路线添加上不存在aut num，则拒绝添加（有关权衡的进一步讨论，请参阅第C节）。如果aut num存在，则根据适用的维护人员检查提交。然后对前缀进行搜索，首先查找完全匹配的前缀。如果对精确匹配的搜索失败，将搜索比指定前缀更不具体的最长前缀匹配。如果此搜索成功，它将返回一个或多个路由对象。提交必须在至少一个路由对象中与适用的维护人员匹配，添加才能成功。如果对路由对象的搜索失败，则会对与前缀完全匹配的inetnum或比路由对象更不具体的最具体inetnum执行搜索。对inetnum的搜索永远不会失败，但它可能返回未分配或保留的范围。inetnum状态必须为“已分配”，提交内容必须与维护人员匹配。
Having found the AS and either a route object or inetnum, the authorization is taken from these two objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt-by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects.
找到AS和路由对象或inetnum后，将从这两个对象获取授权。适用的maintainer对象是mnt routes属性引用的任何对象。如果对象中存在一个或多个mnt路由属性，则不考虑mnt by属性。如果给定对象中没有mnt routes属性，则该对象将使用mnt by属性。身份验证必须与两个对象中的每个对象中的一个授权相匹配。
If the addition of a route object or inetnum contains a reclaim attribute, then any more specific objects of the same type must be examined. The reclaim attribute can only be added if there are no more specific overlaps or if the authentication on the addition is present in the authorization of a less specific object that already has a reclaim attribute covering the prefix range, or if the authentication on the addition is authorized for the modification of all existing more specific prefixes covered by the addition.
如果添加的路由对象或inetnum包含回收属性，则必须检查相同类型的任何其他特定对象。只有在没有更具体的重叠，或者在已具有覆盖前缀范围的回收属性的不太具体的对象的授权中存在添加的身份验证时，才能添加回收属性，或者，如果加法上的身份验证被授权修改加法中包含的所有现有更具体的前缀。
When modifying or deleting any existing object a search for the object is performed as described in Section 9.8. If the submission matches an applicable maintainer for the object, then the operation can proceed. An applicable maintainer for a modification is any maintainer referenced by the mnt-by attribute in the object. For route and inet-num objects an applicable maintainer may be listed in a less specific object with a reclaim attribute.
修改或删除任何现有对象时，将按照第9.8节所述搜索该对象。如果提交匹配对象的适用维护者，则操作可以继续。修改的适用维护者是对象中mnt by属性引用的任何维护者。对于route和inet num对象，可能会在不太特定的对象中列出一个具有回收属性的适用维护者。
If the submission is for a route object, a search is done for all less specific route objects and inetnums. If the submission is for an inetnum, a search is done for all less specific inetnums. If the submission fails the authorization in the object itself but matches the reclaim attribute in any of the less specific objects, then the operation can proceed. Section C contains discussion of the rationale behind the use of the reclaim attribute.
如果提交的是路由对象，则会搜索所有不太特定的路由对象和inetnum。如果提交的是inetnum，则会搜索所有不太特定的inetnum。如果提交未通过对象本身中的授权，但与任何不太特定的对象中的“回收”属性匹配，则操作可以继续。第C节讨论了使用回收属性背后的基本原理。
A modification to an inetnum object that adds a reclaim attribute or removes a no-reclaim attribute must be checked against all existing inetnums that are more specific. The same check of the reclaim attribute that is made during addition must be made when a reclaim attribute is added by a modification (see Section 9.9).
必须对照所有更具体的现有inetnum检查对inetnum对象的修改，该修改添加了回收属性或删除了不回收属性。当通过修改添加回收属性时，必须对添加期间的回收属性进行相同的检查（参见第9.9节）。
A deletion is considered a special case of the modify operation. The deleted object may remain in the database with a "deleted" attribute in which case the mnt-by can still be consulted to remove the "deleted" attribute.
删除被认为是修改操作的一种特殊情况。删除的对象可能保留在具有“已删除”属性的数据库中，在这种情况下，仍然可以咨询mnt by以删除“已删除”属性。
10 Data Format Summaries
10数据格式摘要
RIPE-181 [2] and RPSL [1] data is represented externally as ASCII text. Objects consist of a set of attributes. Attributes are name value pairs. A single attribute is represented as a single line with the name followed by a colon followed by whitespace characters (space, tab, or line continuation) and followed by the value. Within a value all whitespace is equivalent to a single space. Line continuation is supported by a backslash at the end of a line or the following line beginning with whitespace. When transferred, externally attributes are generally broken into shorter lines using line continuation though this is not a requirement. An object is externally represented as a series of attributes. Objects are separated by blank lines.
RIME-181[2]和RPSL[1]数据在外部表示为ASCII文本。对象由一组属性组成。属性是名称-值对。单个属性表示为一行，其名称后面跟一个冒号，后跟空格字符（空格、制表符或换行符）和值。在一个值中，所有空白都相当于一个空格。行尾或以空格开头的下一行的反斜杠支持行继续。在传输时，外部属性通常使用行连续性拆分为较短的行，尽管这不是一个要求。对象外部表示为一系列属性。对象由空行分隔。
There are about 80 attribute types in the current RIPE schema and about 15 object types. Some of the attributes are mandatory in certain objects. Some attributes may appear multiple times. One or more attributes may form a key. Some attributes or sets of attributes may be required to be unique across all repositories. Some of the attributes may reference a key field in an object type and may be required to be a valid reference. Some attributes may be used in inverse lookups.
当前模式中大约有80种属性类型和15种对象类型。某些对象中的某些属性是必需的。某些属性可能会出现多次。一个或多个属性可以形成一个键。某些属性或属性集可能需要在所有存储库中都是唯一的。某些属性可能引用对象类型中的键字段，并且可能需要是有效引用。某些属性可用于反向查找。
A review of the entire RIPE or RPSL schema would be too lengthy to include here. Only the differences in the schema are described.
对整个成熟模式或RPSL模式的审查太长，无法包含在这里。只描述了模式中的差异。
One new object type and several attributes are added to the RIPE/RPSL schema. There are significant changes to the rules which determine if the addition of an object is authorized.
一个新的对象类型和几个属性被添加到RIME/RPSL模式中。确定是否授权添加对象的规则有重大更改。
The new object type is listed below. The first attribute listed is the key attribute and also serves as the name of the object type.
下面列出了新的对象类型。列出的第一个属性是键属性，也是对象类型的名称。
as-block key mandatory single unique descr optional multiple remarks optional multiple admin-c mandatory multiple tech-c mandatory multiple notify optional multiple mnt-by mandatory multiple changed mandatory multiple source mandatory single
as块键强制单个唯一描述可选多个备注可选多个管理员c强制多个技术c强制多个通知可选多个mnt由强制多个更改强制多个源强制单个
In the above object type only the key attribute "as-block" is new:
在上述对象类型中，只有键属性“as block”是新的：
as-block This attribute provides the AS number range for an "as-block" object. The format is two AS numbers including the sub-string "AS" separated by a "-" delimiter and optional whitespace before and after the delimiter.
as block此属性为“as block”对象提供as编号范围。格式为两个AS数字，包括子字符串“AS”，由“-”分隔符分隔，以及分隔符前后的可选空白。
In order to support stronger authentication, the following keywords are added to the "auth" attribute:
为了支持更强的身份验证，在“auth”属性中添加了以下关键字：
pgp-from The remainder of the attribute gives the string identifying a PGP identity whose public key is held in an external keyring. The use of this method is deprecated in favor of the "pgpkey" method.
属性剩余部分中的pgp给出了标识pgp标识的字符串，该标识的公钥保存在外部密钥环中。不赞成使用此方法，而赞成使用“pgpkey”方法。
pgpkey See [18].
pgpkey见[18]。
In order to disable authentication and give permission to anyone, the authentication method "none" is added. It has no arguments.
为了禁用身份验证并向任何人授予权限，添加了身份验证方法“无”。它没有任何论据。
An additional change is the "auth" attribute is allowed to exist in a "person" or "role" object. The "auth" method "role" or "person" can be used to refer to a role or person object and take the "auth" fields from those objects. Care must be taken in implementations to detect circular references and terminate expansion or the references already visited.
另一个变化是允许“person”或“role”对象中存在“auth”属性。“auth”方法“role”或“person”可用于引用角色或person对象，并从这些对象获取“auth”字段。在实现中必须注意检测循环引用并终止扩展或已访问的引用。
A few attributes are added to the schema. These are:
一些属性被添加到模式中。这些是：
mnt-routes The mnt-routes attribute may appear in an aut-num, inet-num, or route object. This attribute references a maintainer object which is used in determining authorization for the addition of route objects. After the reference to the maintainer, an optional list of prefix ranges (as defined in RPSL) inside of curly braces or the keyword "ANY" may follow. The default, when no additional set items are specified is "ANY" or all more specifics. The mnt-routes attribute is optional and multiple. See usage details in Section 9.1.
mnt路由mnt路由属性可能出现在aut num、inet num或路由对象中。此属性引用一个maintainer对象，该对象用于确定添加路由对象的授权。在引用maintainer之后，可能会出现一个可选的前缀范围列表（如RPSL中定义的），其中包含花括号或关键字“ANY”。当未指定其他集合项目时，默认值为“任何”或所有更多详细信息。mnt routes属性是可选的，并且是多个属性。请参阅第9.1节中的用法详细信息。
mnt-lower The mnt-lower attribute may appear in an inetnum, route, as-block or aut-num object. This attribute references a maintainer object. When used in an inetnum or route object the effect is the same as a "mnt-routes" but applies only to prefixes more specific than the prefix of the object in which it is contained. In an as block object, mnt-lower allows addition of more specific as-block objects or aut-num objects. In an aut-num
mnt lower mnt lower属性可能出现在inetnum、route、as block或aut num对象中。此属性引用维护器对象。在inetnum或route对象中使用时，效果与“mnt routes”相同，但仅适用于比包含它的对象的前缀更具体的前缀。在as块对象中，mnt lower允许添加更具体的as块对象或aut num对象。在一个aut num中
object the mnt-lower attribute specifies a maintainer that can be used to add objects with hierarchical names as described in Section 9.7.
对象mnt lower属性指定可用于添加具有层次名称的对象的维护者，如第9.7节所述。
reclaim The reclaim attribute may appear in as-block, aut-num, inet-num, or route objects. Any object of the same type below in the hierarchy may be modified or deleted by the maintainer of the object containing a reclaim attribute. The value of the attribute is a set or range of objects of the same type where the syntax of the set or range is as defined in RPSL. See Section 9.5 for restrictions on adding reclaim attributes.
回收回收属性可以显示为块、aut num、inet num或路由对象。包含回收属性的对象的维护者可以修改或删除层次结构中下面相同类型的任何对象。该属性的值是同一类型的对象集或对象范围，其中该集或对象范围的语法如RPSL中所定义。有关添加回收属性的限制，请参见第9.5节。
no-reclaim The no-reclaim attribute is used with the reclaim attribute. The no-reclaim attribute negates any reclaim attribute it overlaps. See Section 9.5 for restrictions on deleting no-reclaim attributes.
不回收不回收属性与回收属性一起使用。“无回收”属性否定其重叠的任何回收属性。有关删除无回收属性的限制，请参见第9.5节。
referral-by This attribute is required in the maintainer object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. It may be multiple if more than one signature appeared on the transaction creating the object.
maintainer对象中需要通过此属性进行引用。在添加维护人员后，不得对其进行更改。此属性指创建此维护程序的维护程序。如果在创建对象的事务上出现多个签名，则可能是多个签名。
auth-override An auth-override attribute can be added, deleted, or changed by a transaction submitted by maintainer listed in the referral-by. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The auth-override attribute itself contains only the date when the attribute will go into effect which must be at least 60 days from the current date unless there is already authorization to modify the maintainer. After the date in the auth-override is reached, those identified by the maintainer in the referral-by have authorization to modify the maintainer. This attribute exists as a means to clean up should the holder of a maintainer become unresponsive and can only take effect if that maintainer does not remove the auth-override in response to the automatic notification that occurs on changes.
身份验证覆盖身份验证覆盖属性可以由“引用人”中列出的维护者提交的事务添加、删除或更改。只有在维护人员在前60天内处于非活动状态时，才能将身份验证覆盖添加到该维护人员。auth override属性本身仅包含属性生效的日期，该日期必须至少为当前日期的60天，除非已获得修改维护者的授权。达到授权覆盖的日期后，由维修人员在参考中识别的人员有权修改维修人员。如果维护者的持有者没有响应，则该属性作为一种清除方法存在，并且只有在该维护者没有移除auth覆盖以响应更改时发生的自动通知时，该属性才能生效。
The existing "mnt-by" attribute references the "maintainer" object type. The "mnt-by" attribute is now mandatory in all object types. A new maintainer may be added by any existing maintainer. The "referral-by" attribute is now mandatory in the "maintainer" object to keep a record of which maintainer made the addition and can never be changed. Maintainers cannot be deleted as long as they are referenced by a "referral-by" attribute elsewhere.
现有的“mntby”属性引用“maintainer”对象类型。“mntby”属性现在在所有对象类型中都是必需的。任何现有的维护人员都可以添加新的维护人员。“maintainer”对象中的“referral by”属性现在是必需的，以保留由哪个维护者添加的记录，并且永远不能更改。只要维护者在其他地方被“reference by”属性引用，就不能删除它们。
A Core and Non-Core Functionality
A核心和非核心功能
Most of the objects and attributes described in this document are essential to the authorization framework. These are referred to as being part of the "core" functionality. A few attributes listed here are considered "non-core".
本文档中描述的大多数对象和属性都是授权框架所必需的。这些被称为“核心”功能的一部分。此处列出的一些属性被视为“非核心”。
The "reclaim" and "no-reclaim" attributes are a convenience to support flexibility in the implementation of address lending.
“回收”和“不回收”属性便于支持地址借出实现的灵活性。
The "auth-override" attribute is a convenience to facilitate recovery in an environment where repository data is redistributed in any way.
“auth override”属性便于在存储库数据以任何方式重新分布的环境中进行恢复。
The "referal-by" attribute is a "core" feature. An individual registry may express its sutonomy by creating a self-referencing maintainer, one whose "referal-by" points to itslef. Other registries can decide on a case by case basis whether to consider such an entry valid. A registry may only allow the "referal-by" to refer to a specific maintainer under the control of the registry. This further restriction is an issue that is purely local to the registry.
“referel by”属性是一个“核心”特性。单个注册表可以通过创建一个自引用维护器来表示其sutonomy，该维护器的“referealby”指向itslef。其他注册机构可以根据情况逐一决定是否考虑该项有效。注册表只允许“referel by”引用注册表控制下的特定维护者。这一进一步的限制纯粹是注册处的一个问题。
B Examples
B例子
The examples below leave out some required attributes that are not needed to illustrate the use of the objects and attributes described in this document. Missing are admin-c, tech-c, changed, source. Also missing are attributes such as mnt-nfy, whose use are a good practice but are not strictly required.
下面的示例省略了一些说明本文档中所述对象和属性的使用时不需要的必需属性。缺少管理员c、技术c、更改、来源。还缺少一些属性，如mnt nfy，它们的使用是一种良好的实践，但不是严格要求的。
To do anything at all a maintainer is needed. At some epoch a a single maintainer is populated in one repository and that maintianer has a referal-by pointing to itself. All others referal-by references can be traced back to that maintainer. At the epoch the as-block AS0- AS65535 and the inetnum 0.0.0.0-255.255.255.255 are also allocated. Other ancilliary object may also be needed to bootstrap.
要想做任何事情，都需要一名维护人员。在某个时期，单个维护人员被填充到一个存储库中，并且该维护人员通过指向自身拥有一个引用。所有其他引用都可以追溯到该维护人员。在历元处，as块AS0-AS65535和inetnum 0.0.0-255.255.255.255也被分配。其他辅助对象也可能需要引导。
mntner: ROOT-MAINTAINER auth: pgpkey-12345678
mntner:ROOT-MAINTAINER身份验证：pgpkey-12345678
mnt-by: ROOT-MAINTAINER referal-by: ROOT-MAINTAINER
mnt作者：ROOT-mainter参考作者：ROOT-mainter
This root maintainer might add a top level maintainer for some organization.
此根维护者可能会为某些组织添加顶级维护者。
mntner: WIZARDS descr: High level Technical Folks auth: pgpkey-23456789 auth: pgpkey-3456789a mnt-by: WIZARDS referal-by: ROOT-MAINTAINER
mntner:WIZARDS descr:High-level Technical peops auth:pgpkey-23456789 auth:pgpkey-3456789a mnt by:WIZARDS refereal by:ROOT-MAINTAINER
That maintainer might add another who have more limited capabilities.
该维护人员可能会添加另一个能力更有限的人员。
mntner: MORTALS descr: Maintain day to day operations auth: pgpkey-456789ab auth: pgpkey-56789abc auth: pgpkey-6789abcd mnt-by: WIZARDS referal-by: WIZARDS
mntner:凡人描述：维护日常操作授权：pgpkey-4567889AB授权：pgpkey-56789abc授权：pgpkey-6789ABC授权：pgpkey-6789ABC mnt授权人：向导参考人：向导
Note that the WIZARDS can change their own maintainer object and the MORTALS maintainer object but MORTALS cannot.
请注意，向导可以更改自己的维护者对象和凡人维护者对象，但凡人不能。
At some point an as-block is allocated and broken down. In the example below, private number space is used.
在某个点上，as块被分配和分解。在下面的示例中，使用了专用号码空间。
as-block: AS65500-AS65510 mnt-by: SOME-REGISTRY mnt-lower: WIZARDS
as块：AS65500-AS65510 mnt by:SOME-REGISTRY mnt lower:向导
Note that a registry has control over the object that they have created representing the allocation, but have given the party to which the allocation was made the ability to create more specific objects. Below this as-block, an aut-num is added. Note that import and export are normally required for a aut-num but are not shown here.
请注意，注册中心可以控制他们创建的表示分配的对象，但已赋予分配对象创建更具体对象的能力。在该as块下面，添加了一个aut num。请注意，aut num通常需要导入和导出，但此处未显示。
aut-num: AS65501 mnt-by: WIZARDS mnt-lower: MORTALS
aut num:AS65501 mnt by:巫师mnt低级：凡人
In aut-num above the WIZARDS maintainer can modify the aut-num itself. The MORTALS maintainer can add route objects using this AS as the origin if they also have authorization for the IP number space in a less specific route or inetnum.
在上面的aut num中，向导维护人员可以修改aut num本身。凡人维护者可以使用此作为源添加路由对象，前提是他们还拥有对不太特定的路由或inetnum中的IP号码空间的授权。
We also need an inetnum allocation. In this example the inetnum is allocated to a completely different organization. Again attributes are omited which would normally be needed in an inetnum.
我们还需要一个inetnum分配。在本例中，inetnum被分配给一个完全不同的组织。同样，省略了inetnum中通常需要的属性。
inetnum: 192.168.144.0-192.168.151.255 mnt-by: SOME-REGISTRY mnt-lower: ISP reclaim: ALL
inetnum:192.168.144.0-192.168.151.255 mnt by:SOME-REGISTRY mnt lower:ISP recall:ALL
The maintainer ISP can add more specific inetnums or routes with this address space. Note that the registry has declared their ability to reclaim the address space.
维护者ISP可以使用此地址空间添加更具体的INETNUM或路由。请注意，注册表已声明其回收地址空间的能力。
If ISP wished to reclaim all allocations but some suballocation of theirs resisted, we might get something like the following in which they will reclaim only the top half of an allocation (possibly if it remains unused).
如果ISP希望回收所有分配，但他们的一些子分配遭到了抵制，我们可能会得到如下结果，即他们将只回收分配的上半部分（如果它仍然未使用的话）。
inetnum: 192.168.144.0-192.168.147.255
mnt-by: ISP
mnt-lower: EBG-COM
reclaim: 192.168.146/23+
inetnum: 192.168.144.0-192.168.147.255
mnt-by: ISP
mnt-lower: EBG-COM
reclaim: 192.168.146/23+
If we assume that the maintainer EBG-COM and the maintainer MORTALS want to add a route object, one way to do it is for both parties to sign. If EBG-COM for some reason couldn't aggregate an allocate a single top level route (which is inexcusable these days) or there was a preference for some reason to avoid the joint signature approach on a submission either party could give the other permission to make the addition. A mnt-routes could be added to the aut-num or a mnt-lower could be added to an inetnum.
如果我们假设维护人员EBG-COM和维护人员想要添加一个路由对象，那么一种方法是双方签字。如果EBG-COM因某种原因无法聚合一条或分配一条顶级路线（这在当今是不可原谅的），或者出于某种原因，倾向于避免在提交物上采用联合签名方法，则任何一方都可以给予另一方进行添加的许可。可以将mnt路由添加到aut num，也可以将mnt lower添加到inetnum。
aut-num: AS65501
mnt-by: WIZARDS
mnt-lower: MORTALS
mnt-routes: EBG-COM {192.168.144/23}
aut-num: AS65501
mnt-by: WIZARDS
mnt-lower: MORTALS
mnt-routes: EBG-COM {192.168.144/23}
With this change to the aut-num the maintainer EBG-COM could add a route with origin AS65501, but only with a limited address range.
通过对aut num的更改，维护人员EBG-COM可以添加一条起始地址为65501的路由，但地址范围有限。
route: 192.168.144/24
origin: AS65501
descr: These boneheads don't aggregate
mnt-by: EBG-COM
mnt-by: FICTION::MORTALS
route: 192.168.144/24
origin: AS65501
descr: These boneheads don't aggregate
mnt-by: EBG-COM
mnt-by: FICTION::MORTALS
Note that while the maintainer EBG-COM added the object they allowed the maintainer MORTALS the ability to modify it.
注意，虽然维护人员EBG-COM添加了该对象，但他们允许维护人员修改该对象。
If an object ended up in another repository, a single maintainer could still be used. In the example above the notation FICTION::MORTALS indicates that the route object is in a different repository and rather than duplicate the maintainer, a reference is made to the repository in which the MORTALS object resides.
如果一个对象最终位于另一个存储库中，那么仍然可以使用单个维护者。在上面的示例中，表示法Frient:：Vertines表示路由对象位于不同的存储库中，而不是复制维护者，而是引用Vertines对象所在的存储库。
In the example below, a pair of route-sets are added and hierarchical names are used.
在下面的示例中，添加了一对路由集，并使用了分层名称。
route-set: AS65501:Customers mnt-by: WIZARDS mnt-lower: MORTALS
路线集：AS65501:客户mnt发件人：向导mnt下级：凡人
route-set: AS65501:Customers:EBG-COM
mnt-by: MORTALS
mnt-lower: EBG-COM
route-set: AS65501:Customers:EBG-COM
mnt-by: MORTALS
mnt-lower: EBG-COM
Suppose in the 192.168.144/24 object above, only the EBG-COM maintainer is listed. If EBG-COM goes bankrupt, no longer needs address space, and stops responding, it could be difficult to delete this object. The maintainer listed in the EBG-COM referral-by attribute could be contacted. They could add a auth-override attribute to the EBG-COM object. Later they could modify the EBG-COM object and then any objects with EBG-COM in the mnt-by.
假设在上面的192.168.144/24对象中，只列出了EBG-COM维护程序。如果EBG-COM破产，不再需要地址空间，并且停止响应，则可能很难删除此对象。可以联系EBG-COM“按属性引用”中列出的维护人员。他们可以向EBG-COM对象添加auth override属性。之后，他们可以修改EBG-COM对象，然后修改mnt中带有EBG-COM的任何对象。
mntner: EBG-COM mnt-by: EBG-COM auth-override: 19990401
mntner:EBG-COM mnt by:EBG-COM身份验证覆盖：19990401
The examples above stray significantly from realism. They do provide simple illustrations of the usage of the objects type and attributes described in this document and hopefully in doing some are of some value.
上面的例子明显偏离了现实。它们确实提供了本文档中描述的对象类型和属性的使用的简单说明，希望在执行某些操作时具有一定的价值。
C Technical Discussion
C技术讨论
A few design tradeoffs exist. Some of these tradeoffs, the selected solution, and the alternatives are discussed here. Some of the issues are listed below.
存在一些设计权衡。这里讨论了其中的一些折衷方案、选定的解决方案和备选方案。下面列出了一些问题。
1. Whether to err on the side of permissiveness and weaken authorization controls or risk the possibility of erecting barriers to registering information.
1. 是否在许可方面犯了错误，削弱了授权控制，或者冒着为注册信息设置障碍的风险。
2. Whether to support enforcible address lending or provide the smaller or end user with ultimate control over the registration of the prefixes they are using.
2. 是支持可强制执行的地址借用，还是为较小的用户或最终用户提供对其使用的前缀注册的最终控制。
3. What to do with older objects that either don't conform to newer requirements regarding minimum authorization, authentication, and accountability, or are of questionable validity.
3. 如何处理不符合有关最低授权、身份验证和责任的较新要求，或者有效性有问题的较旧对象。
If the requirement that an aut-num exists is relaxed, then it is possible for anyone to make use of an unassigned AS number or make use of an assigned AS number for which the aut-num has not been entered. Placing requirements on the entry of aut-num presumes cooperation of the Internet address allocation authority (if separate from the routing registry). The address allocation authority must be willing to field requests to populate skeleton aut-nums from the party for which the allocation has been made. These aut-num must include a reference to a maintainer. A request to the address allocation authority must therefore include a reference to an existing maintainer.
如果放宽了aut num存在的要求，则任何人都可以使用未分配的AS编号或未输入aut num的分配AS编号。对aut num条目的要求假定互联网地址分配机构的合作（如果与路由注册表分离）。地址分配机构必须愿意填写已进行分配的一方提出的填充框架aut NUM的请求。这些aut num必须包括对维护人员的引用。因此，对地址分配机构的请求必须包括对现有维护人员的引用。
The ability to add route objects is also tied to the existence of less specific route objects or inetnums. The Internet address allocation authority (if separate from the routing registry) must also be willing to field requests to add inetnum records for the party already allocated the address space.
添加管线对象的能力还与不太特定的管线对象或inetnum的存在有关。Internet地址分配机构（如果与路由注册表分离）还必须愿意为已分配地址空间的一方提交添加inetnum记录的请求。
The Internet address allocation authority should also add inetnums and aut-nums for new allocations. In order to do so, a maintainer must exist. If a party is going to connect to the Internet, they can get a maintainer by making a request to the Internet service provider they will be connecting to. Once they have a maintainer they can make a request for address space or an AS number. The maintainer can contain a public key for a cryptographicly strong authorization method or could contain a "crypt-key" or "mail-to" authorization check if that is considered adequate by the registering party. Furthermore an address allocation authority should verify that the request for an AS number or for address space matches the authorization criteria in the maintainer.
Internet地址分配机构还应为新分配添加INETNUM和aut NUM。为了做到这一点，维护人员必须存在。如果一方要连接到Internet，他们可以通过向将要连接的Internet服务提供商发出请求来获得维护者。一旦有了维护人员，他们就可以请求地址空间或AS号码。维护者可以包含加密强授权方法的公钥，也可以包含“加密密钥”或“邮件发送”授权检查（如果注册方认为这是足够的）。此外，地址分配机构应验证AS编号或地址空间的请求是否符合维护者的授权标准。
Currently only the registries themselves may add maintainers. This becomes a problem for the registry, particularly in verifying public keys. This requirement is relaxed by allowing existing maintainers to add maintainers. Unfortunately the accountability trail does not exist for existing maintainers. The requirement then should be relaxed such that existing maintainers may remain but only existing maintainers that have a "referral-by" attribute can add maintainers. The "referral-by" cannot be modified. This requirement can be relaxed slightly so that a "referral-by" can be added to a maintainer
目前只有注册中心本身可以添加维护者。这成为注册表的一个问题，特别是在验证公钥时。通过允许现有的维护人员添加维护人员，这一要求得到了放宽。不幸的是，现有的维护人员不存在责任追踪。然后，应该放松需求，以便现有的维护人员可以保留，但只有具有“reference by”属性的现有维护人员才能添加维护人员。“推荐人”不能修改。这个要求可以稍微放宽，这样就可以向维护人员添加“推荐人”
by an existing maintainer with a "referral-by". This will allow the accountability trail to be added to existing maintainers and these maintainers can then add new maintainers.
由具有“推荐人”的现有维护人员提供。这将允许将责任跟踪添加到现有的维护人员中，然后这些维护人员可以添加新的维护人员。
Verifying that a party is who they claim to be on initial addition, is one of the problems that currently falls upon the AS number and address registry. This problem is reduced by allowing existing maintainers to add maintainers. This may actually make it easier to get maintainers and therefore easier to register. The number authority still must verify that the AS or address space is actually needed by the party making a request.
核实一方是否是他们在初次添加时声称的人，是目前AS号码和地址登记处面临的问题之一。通过允许现有维护人员添加维护人员，可以减少此问题。这实际上可能会使获得维护人员变得更容易，从而更容易注册。号码管理机构仍然必须验证发出请求的一方是否确实需要AS或地址空间。
Authorization checks made during the addition of route objects that refer to AS objects and inetnums strongly rely on the cooperation of the Internet address allocation authorities. The number authorities must register as-blocks, aut-nums, or inetnums as AS numbers or address space is allocated. If only a subset of the number authorities cooperate, then either an inetnum or as-block can be created covering the space that registry allocates and essentially requiring null allocation (for example a "crypt-pw" authentication where the password is given in the remarks in the object or its maintainer) or those obtaining addresses from that number authority will have trouble registering in the routing registry. The authorization model supports either option, though it would be preferable if the number authorities cooperated and the issue never surfaced in practice.
在添加称为对象和inetnums的路由对象期间进行的授权检查强烈依赖于Internet地址分配机构的合作。分配数字或地址空间时，数字授权机构必须注册为块、aut NUM或INETNUM。如果只有数字权限的一个子集合作，则可以创建inetnum或as块，覆盖注册表分配的空间，基本上需要空分配（例如“crypt pw”身份验证，其中在对象或其维护程序的备注中给出密码）或者，那些从该号码管理机构获得地址的人将难以在路由注册表中注册。授权模型支持这两种选择，但如果授权机构进行合作，并且问题在实践中从未出现，则更可取。
The maintainer requirements can be relaxed slightly for existing maintainers making it easier to register. Relaxing requirements on other objects may defeat the authorization model, hence is not an option.
对于现有的维护人员，可以稍微放宽对维护人员的要求，以便于注册。放宽对其他对象的要求可能会破坏授权模型，因此不是一种选择。
The issue of whether lending contracts should be enforcible is an issue of who should ultimately be able to exercise control over allocations of address space. The routing registry would be wise to stay as neutral as possible with regard to disputes between third parties. The "reclaim" and "no-reclaim" are designed to allow either outcome to the decision as to whether the holder of a less specific inetnum or route object can exercise control over suballocations in the registry. The routing registry itself must decide whether to retain control themselves and if so, should very clearly state under what conditions the registry would intervene. A registry could even go to the extreme of stating that they will intervene in such a dispute only after the dispute has been resolved in court and a court order has been issued.
借贷合同是否可执行的问题是谁最终能够控制地址空间的分配。对于第三方之间的争端，路由登记处应尽可能保持中立。“回收”和“不回收”的设计目的是允许决定是否由不太具体的inetnum或route对象的持有者控制注册表中的子分配。路由注册表本身必须决定是否保留自己的控制权，如果是，则应非常清楚地说明注册表将在何种条件下进行干预。书记官处甚至可能走到极端，声称只有在法庭解决争议并发布法庭命令后，他们才会介入此类争议。
When an allocation is made by a registry, the registry should keep a "reclaim" attribute in the less specific object and make a strong policy statement that the reclaim privilege will not be used except under very clearly defined special circumstances (which at the very minimum would include a court order). If the allocation is further subdivided the party subdividing the allocation and the party accepting the suballocation must decide whether a "reclaim" can be kept by the holder of the less specific allocation or whether a "no-reclaim" must be added transferring control to the holder of the more specific. The registry is not involved in that decision. Different pairs of third parties may reach different decisions regarding the "reclaim" and any contractual restrictions on its use that may be expressed outside of the registry in the form of a legal contract and ultimately resolved by the courts in the event of a bitter dispute.
当登记处进行分配时，登记处应在不太具体的对象中保留“收回”属性，并作出强有力的政策声明，即除非在非常明确定义的特殊情况下（至少包括法院命令），否则不得使用收回特权。如果分配进一步细分，则细分分配的一方和接受子分配的一方必须决定是否可以由不太具体分配的持有人保留“收回”，或者是否必须添加“不收回”，以将控制权转移给更具体分配的持有人。书记官处不参与这项决定。不同的第三方对可能在登记处以外以法律合同的形式表达的关于“收回”及其使用的任何合同限制达成不同的决定，并在发生激烈争议时最终由法院解决。
By retaining "reclaim" rights the registry retains the ability to abide by a court order. This may only truly become an issue in a distributed registry environment where registries will be rechecking the authorization of transactions made elsewhere and may fail to process the attempt of another registry to abide by a court order by overriding normal authorization to change the registry contents if a reclaim is not present.
通过保留“收回”权利，登记处保留了遵守法院命令的能力。这只有在分布式注册中心环境中才可能真正成为一个问题，在这种环境中，注册中心将重新检查在其他地方进行的交易的授权，并且可能无法处理另一个注册中心遵守法院命令的企图，如果不存在收回请求，则可能会覆盖更改注册中心内容的正常授权。
Some of the newer requirements include requiring that all objects reference a maintainer object responsible for the integrity of the object and requiring accountability for the creation of maintainers to be recorded in the maintainer objects so that accountability can be traced back from an unresponsive maintainer. In the event that contact information is absent or incorrect from objects and there is any question regarding the validity of the objects, the maintainer can be contacted. If the maintainer is unresponsive, the maintainer that authorized the addition of that maintainer can be contacted to either update the contact information on the maintainer or confirm that the entity no longer exists or is no longer actively using the Internet or the registry.
一些较新的需求包括要求所有对象引用负责对象完整性的维护者对象，并要求在维护者对象中记录维护者创建的责任，以便从无响应的维护者追溯责任。如果对象中缺少或不正确的联系信息，并且存在关于对象有效性的任何问题，可以联系维护人员。如果维修人员没有反应，可以联系授权添加该维修人员的维修人员，以更新维修人员的联系信息，或确认该实体不再存在或不再积极使用互联网或注册表。
Many route objects exist for which there are no maintainers and for which inetnum and AS objects do not exist. Some contain the now obsoleted guardian attribute rather than a mnt-by.
存在许多路由对象，这些对象没有维护程序，并且inetnum和AS对象不存在。有些包含现在已经过时的guardian属性，而不是mnt属性。
It is not practical to unconditionally purge old data that does not have maintainers or does not conform to the authorization hierarchy. New additions must be required to conform to the new requirements (otherwise the requirements are meaningless). New requirements can be phased in by requiring modifications to conform to the new requirements.
无条件清除没有维护者或不符合授权层次结构的旧数据是不实际的。必须要求新添加的内容符合新的要求（否则这些要求毫无意义）。通过要求修改以符合新需求，可以分阶段引入新需求。
A great deal of questionable data exists in the current registry. The requirement that all objects have maintainers and the requirements for improved accountability in the maintainers themselves may make it easier to determine contact information even where the objects are not updated to reflect contact information changes.
当前注册表中存在大量可疑数据。所有对象都有维护者的要求以及维护者自身改进责任的要求可能会使确定联系信息变得更容易，即使对象没有更新以反映联系信息的变化。
It is not unreasonable to require valid contact information on existing data. A great deal of data appears to be unused, such as route objects for which no announcement has been seen in many months or years. An attempt should be made to contact the listed contacts in the object, in the maintainer if there is one, then up the maintainer referral-by chain if there is one, and using the number registry or origin AS contact information if there is no maintainer accountability trail to follow. Experience so far indicates that the vast majority of deletions identified by comparing registered prefixes against route dumps will be positively confirmed (allowing the deletion) or there will be no response due to invalid contact information (in many cases the IRR contact information points to nsfnet-admin@merit.edu).
要求现有数据的有效联系信息并非不合理。大量数据似乎未被使用，例如路由对象，这些对象在数月或数年内都没有发布任何公告。应尝试联系对象中列出的联系人，如果有，则联系维修人员中的联系人，如果有，则联系维修人员推荐链，如果没有维修人员责任跟踪，则使用号码注册或来源作为联系信息。迄今为止的经验表明，通过将注册前缀与路由转储进行比较确定的绝大多数删除将得到肯定确认（允许删除），或者由于无效的联系信息（在许多情况下，IRR联系信息指向nsfnet）而没有响应-admin@merit.edu).
By allowing the registry to modify (or delete) any objects which are disconnected from the maintainer accountability trail, cleanup can be made possible (though mail header forging could in many cases have the same effect it is preferable to record the fact that the registry itself made the cleanup). Similarly, a mechanism may be needed in the future to allow the maintainer in the referral-by to override maintainer privileges in a referred maintainer if all contacts have become unresponsive for a maintainer. The referral-by maintainer is allowed to add an "auth-override" attribute which becomes usable as an "auth" within 60 days from the time of addition. The maintainer themselves would be notified of the change and could remove the "auth-override" attribute before it becomes effective and inquire as to why it was added and correct whatever problem existed. This can be supported immediately or added later if needed.
通过允许注册表修改（或删除）与维护者责任跟踪断开连接的任何对象，可以进行清理（尽管邮件头伪造在许多情况下可能具有相同的效果，但最好记录注册表本身进行清理的事实）。类似地，将来可能需要一种机制，允许转介中的维护人员在所有联系人对维护人员无响应的情况下，覆盖转介维护人员中的维护人员权限。允许维护人员引用添加“auth override”属性，该属性在添加后60天内可用作“auth”。维护人员自己将收到更改通知，并且可以在“auth override”属性生效之前删除该属性，并询问添加该属性的原因并纠正存在的任何问题。如果需要，可以立即支持或稍后添加。
D Common Operational Cases
D一般业务情况
In principle, address allocation and route allocation should be hierarchical with the hierarchy corresponding to the physical topology. In practice, this is often not the case for numerous reasons. The primary reasons are the topology is not strictly tree structured and the topology can change. More specificly:
原则上，地址分配和路由分配应该是分层的，层次与物理拓扑相对应。实际上，由于许多原因，情况往往并非如此。主要原因是拓扑结构不是严格的树结构，拓扑结构可能会发生变化。更具体地说：
1. The Internet topology is not strictly tree structured.
1. Internet拓扑结构不是严格的树结构。
o At the top level the network more closely resembles a moderately dense mesh.
o 在顶层，网络更像一个中等密度的网格。
o Near the bottom level many attachments to the Internet are multi-homed to more than one Internet provider.
o 在最底层，许多连接到Internet的附件都由多个Internet提供商托管。
2. The Internet topology can and does change.
2. 互联网拓扑结构可以而且确实会发生变化。
o Many attachments switch providers to obtain better service or terms.
o 许多附件切换提供商以获得更好的服务或条款。
o Service providers may modify adjacencies to obtain better transit service or terms.
o 服务提供商可以修改相邻区域以获得更好的交通服务或条款。
o Service providers may disappear completely scattering attachments or they may merge.
o 服务提供商可能会完全消失或合并附件。
Renumbering is viewed as a practical means to maintain a strict numeric hierarchy [16]. It is also acknowledged that renumbering IPv4 networks can be difficult [16, 3, 17]. We examine first the simple case where hierarchy still exists. We then examine the operational cases where either initial topology is not tree structured or cases where topology changes.
重新编号被视为维持严格数字层次结构的一种实用方法[16]。人们还承认，对IPv4网络重新编号可能很困难[16、3、17]。我们首先检查层次结构仍然存在的简单情况。然后，我们检查初始拓扑不是树结构或拓扑发生变化的操作情况。
This is the simplest case. Large ranges of inetnums are assigned to address registries. These registries in turn assign smaller ranges for direct use or to topologically large entities where allocations according to topology can reduce the amount of routing information needed (promote better route aggregation).
这是最简单的情况。将大范围的inetnum分配给地址注册表。这些注册表依次分配较小的范围供直接使用，或分配给拓扑上较大的实体，其中根据拓扑进行分配可以减少所需的路由信息量（促进更好的路由聚合）。
AS objects are allocated as topology dictates the need for additional AS [10]. Route objects can be registered by those with authorization given by the AS and by the address owner. This is never an issue where the maintainer of the AS and the inetnum are the same. Where they differ, either the provider can give permission to add route objects for their AS, or the party allocated the address space can give the provider permission to add route objects for their address space, or both parties can sign the transaction. Permission is provided by adding to maintainer attributes.
由于对象被分配为拓扑，因此需要额外的AS[10]。路由对象可以由具有AS和地址所有者授权的用户注册。当AS和inetnum的维护者相同时，这绝不是一个问题。如果它们不同，提供者可以授予为其AS添加路由对象的权限，或者分配地址空间的一方可以授予提供者为其地址空间添加路由对象的权限，或者双方可以签署事务。权限是通过添加到维护者属性来提供的。
Aggregation is normally not a problem if a provider is aggregating address space allocated to the provider and then suballocated internally and/or to customers. In fact, the provider would be expected to do so. This is not a problem even if the route object for the aggregation is added after the more specific route objects since only less specific objects are considered.
如果提供程序聚合分配给提供程序的地址空间，然后在内部和/或向客户子分配，则聚合通常不是问题。事实上，供应商应该这样做。即使在更具体的路由对象之后添加聚合的路由对象，这也不是问题，因为只考虑不太具体的对象。
Aggregation is potentially a problem if a provider or a set of providers plan to aggregate address space that was never explicitly allocated as a block to those providers but rather remains the allocation of a address registry. These large aggregations can be expected to be uncommon, but relatively easily dealt with. Superaggregates of this type will generally be formed by topologically close entities who have also managed to draw adjacent address allocations. In effect, the registry must give permission to form such a superaggregate by either giving permission to do so in the mnt-routes of an inetnum or by signing the submission along with the other parties.
如果提供程序或一组提供程序计划聚合从未作为块显式分配给这些提供程序但仍然是地址注册表分配的地址空间，则聚合可能会出现问题。这些大型聚合可能并不常见，但相对容易处理。这种类型的超级聚合通常由拓扑关系密切的实体组成，这些实体还设法绘制相邻的地址分配。实际上，注册处必须通过在inetnum的mnt路线上授予组建超级集合体的许可，或与其他各方一起签署提交文件，授予组建超级集合体的许可。
Provider independent addresses and multihoming arrangement using multiple origin AS present a similar problem to multihoming. The maintainer of the address space and the maintainer of the AS is not the same. Permission can be granted using mnt-routes or multiple signatures can appear on the submission.
独立于提供者的地址和使用多个源的多归属安排与多归属存在类似的问题。地址空间的维护者和AS的维护者是不同的。可以使用mnt路由授予权限，也可以在提交上显示多个签名。
A change in Internet service providers is similar to multihoming. A minor difference is that the AS for the more specific route will be the AS of the new provider rather than the AS of the multihomed customer. Permission can be granted using mnt-routes or multiple signatures can appear on the submission.
互联网服务提供商的变化类似于多主机。一个微小的区别是，对于更具体的路线，AS将是新提供商的AS，而不是多址客户的AS。可以使用mnt路由授予权限，也可以在提交上显示多个签名。
Renumbering grace periods allow a provider who wants to keep an address allocation intact to allow a customer who has chosen to go to another provider to renumber their network gradually and then return the address space after renumbering is completed. The issue of whether to require immediate renumbering or offer renumbering grace periods and how long they should be or whether they should be indefinite has been topic of bitter disputes. The authorization model can support no renumbering grace period, a finite renumbering
重新编号宽限期允许希望保持地址分配完整的提供商允许选择转到其他提供商的客户逐渐重新编号其网络，然后在重新编号完成后返回地址空间。是要求立即重新编号，还是提供重新编号的宽限期，以及宽限期应该多长，还是应该无限期，一直是激烈争论的话题。授权模型可以支持无重新编号宽限期，即有限的重新编号
grace period, or an indefinite renumbering grace period. The "reclaim" attribute described in Section 9.1 provides a means to end the grace period.
宽限期，或无限期重新编号的宽限期。第9.1节中描述的“回收”属性提供了结束宽限期的方法。
E Deployment Considerations
E.部署注意事项
This section describes deployment considerations. The intention is to raise issues and discuss approaches rather than to provide a deployment plan.
本节介绍部署注意事项。目的是提出问题和讨论方法，而不是提供部署计划。
The use of routing registries is not yet universally accepted. There still remain Internet providers who see no reason to provide the added assurance of accurate routing information described in Section 6. More accurately, these benefits are viewed as being insufficient to justify the cost. This has been largely caused an inability of a very major router vendor up until recently to handle prefix lists of the size needed to specify routing policy on a per prefix basis.
路由注册中心的使用还没有被普遍接受。仍然有互联网提供商认为没有理由提供第6节所述的准确路由信息的额外保证。更准确地说，这些好处被认为不足以证明成本的合理性。这在很大程度上是因为直到最近，一家非常主要的路由器供应商还无法处理前缀列表，该列表的大小需要在每个前缀的基础上指定路由策略。
Another reason cited is that filtering on a prefix basis in an environment where routing registry information is incomplete or inaccurate can interfere with connectivity.
引用的另一个原因是，在路由注册表信息不完整或不准确的环境中，基于前缀进行过滤可能会干扰连接。
There clearly is a critical mass issue with regard to the use of routing registries. A minority of providers use the existing IRR to filter on a per prefix basis. Another minority of providers do not support the IRR and generally fail to register prefixes until connectivity problems are reported. The majority of providers register prefixes but do not implement strict prefix filtering.
显然，在路由注册中心的使用方面存在着一个关键的大规模问题。少数提供商使用现有IRR按前缀进行过滤。另外少数提供商不支持IRR，通常在报告连接问题之前无法注册前缀。大多数提供程序注册前缀，但不实现严格的前缀过滤。
Deploying new authentication mechanisms has no adverse consequences. This has been proven with Merit's deployment of PGP.
部署新的身份验证机制不会产生不良后果。这已通过Merit的PGP部署得到证明。
In deploying new authorization mechanisms, a major issue is dealing with existing data of very questionable origin. A very large number of route objects refer to prefixes that have not been announced for many years. Other route objects refer to prefixes that are no longer announced with the origin AS that they are registered with (some were incorrectly registered to start with). There are many causes for this.
在部署新的授权机制时，一个主要问题是处理来源非常可疑的现有数据。大量route对象引用的前缀已多年未公布。其他路由对象指的是不再与源站一起声明的前缀，因为它们是注册到的（有些前缀一开始就注册不正确）。原因很多。
1. During the transition from the NSFNET PRDB to the RADB a large number of prefixes were registered with an origin AS corresponding to the border AS at which the NSFNET had once heard the route announcements. The PRDB did not support origin AS, so border AS was used. Many of these routes were no longer in use at the time and are now routed with a submitter listed as "nsfnet-admin@merit.edu".
1. 在从NSFNET PRDB过渡到RADB的过程中，大量前缀被注册为与NSFNET曾经听到路线公告的边界相对应的原点。PRDB不支持原始AS，因此使用了边界AS。其中许多路由在当时已不再使用，现在与列为“nsfnet”的提交者一起路由-admin@merit.edu".
2. As CIDR was deployed, aggregates replaced previously separately announced more specific prefixes. The route objects for the more specific prefixes were never withdrawn from the routing registries.
2. 随着CIDR的部署，先前单独发布的更为具体的前缀取代了聚合。更具体前缀的路由对象从未从路由注册表中撤回。
3. Some prefixes are simply no longer in use. Some networks have been renumbered. Some network no longer exist. Often the routing registry information is not withdrawn.
3. 有些前缀已不再使用。一些网络已经重新编号。有些网络已经不存在了。通常不会撤回路由注册表信息。
4. As provider AS adjacencies changed and as end customers switched providers often the actual origin AS changed. This was often not reflected by a change in the routing registry.
4. 由于供应商的邻接关系发生了变化，以及最终客户更换了供应商，因此，实际的原产地往往也发生了变化。路由注册表中的更改通常不会反映这一点。
Inaccuracies will continue to occur due to the reasons above, except the first. The hierarchical authorization provides greater accountability. In the event that the contacts for specific objects become unresponsive traversal up the authorization hierarchy should help identify the parties having previous provided authorization. These contacts may still have sufficient authorization to perform the necessary cleanup. This issue is discussed in Section C.
由于上述原因，不准确的情况将继续发生，但第一个原因除外。分级授权提供了更大的责任。如果特定对象的联系人变得无响应，则向上遍历授权层次结构应有助于识别以前提供过授权的各方。这些联系人可能仍有足够的权限执行必要的清理。这一问题将在C节中讨论。
A great deal of information is currently missing in the IRR. Quite a few AS have no aut-num. Quite a lot of data has no maintainer and the vast majority of maintainers use only the weakest of authentication methods. Very little can be done by the registries to correct this. The defaults in the cases of missing objects needed for authorization has to be to make no authentication checks at all.
IRR中目前缺少大量信息。相当多的AS没有aut-num。相当多的数据没有维护者，绝大多数维护者只使用最薄弱的身份验证方法。登记处几乎无法纠正这一点。在缺少授权所需对象的情况下，默认情况是根本不进行身份验证检查。
The transition can be staged as follows:
过渡可分为以下阶段：
1. Add and make use of stronger authorization models.
1. 添加并使用更强大的授权模型。
2. Make schema modifications necessary to support delegations.
2. 进行必要的模式修改以支持委派。
3. Add delegation attributes needed for query traversal. 4. Base query traversal on delegations rather than a search of all known registries.
3. 添加查询遍历所需的委派属性。4.基于委托的查询遍历，而不是对所有已知注册表的搜索。
5. Obtain the cooperation of the address registries for the purpose of populating the "inetnum" entries on an ongoing basis.
5. 获得地址注册中心的合作，以便持续填充“inetnum”条目。
6. Add hierarchical authorization support for critical object types, "aut-num", "inetnum" and "route".
6. 为关键对象类型“aut num”、“inetnum”和“路由”添加分层授权支持。
7. Add the requirement that database object either be in use or have valid contact information and if queries are made by the registry a response from a contact indicating that the object serves a purpose if it is not clear what its use is.
7. 添加数据库对象正在使用或具有有效联系信息的要求，如果注册表进行了查询，则联系人会做出响应，如果不清楚该对象的用途，则表明该对象有用途。
8. Begin to purge data which is clearly not in use and for which there is no valid contact information or no response from the contacts.
8. 开始清除明显未使用且没有有效联系信息或联系人没有响应的数据。
Deployment of hierarchical authorization requires cooperation among the existing routing registries. New code will have to be deployed. In some cases minimal development resources are available and substantial inertia exists due to the reliance on the current repository and the need to avoid disruption.
分层授权的部署需要现有路由注册中心之间的合作。必须部署新代码。在某些情况下，由于对当前存储库的依赖和避免中断的需要，可用的开发资源很少，并且存在很大的惯性。
If hierarchical authorization of route objects depends on the existence of address registration information, minimal cooperation of the currently separate address registries is required. The extent of the cooperation amounts to sending cryptographically signed transactions from the address registry to the number registry as address allocations are made or providing equivalent access to new address allocations.
如果路由对象的分层授权取决于地址注册信息的存在，则需要当前独立地址注册中心的最小协作。合作的范围相当于在进行地址分配时将加密签名的事务从地址注册中心发送到号码注册中心，或提供对新地址分配的同等访问。
Currently most registries return query results from all of the known repositories using their mirrored copies. Cross registry authorizations are not yet implemented. Minimal schema changes have to be made to support the ability to delegate objects for which there is an authorization hierarchy and to support queries and references to other repositories. In the case of AS delegations, "as-block" need to be created solely for the purpose of traversal.
目前，大多数注册中心使用其镜像副本从所有已知存储库返回查询结果。跨注册表授权尚未实施。必须进行最小的模式更改，以支持委托具有授权层次结构的对象的能力，并支持对其他存储库的查询和引用。在AS委托的情况下，“AS块”的创建仅用于遍历。
F Route Object Authorization Pseudocode
F路由对象授权伪码
The following list provides a brief review of basic concepts.
以下列表简要回顾了基本概念。
1. The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or if no applicable route object is found, then an inetnum.
1. 路由对象提交必须满足两个身份验证标准。它必须匹配aut num中指定的身份验证和路由对象中指定的身份验证，或者如果未找到适用的路由对象，则匹配inetnum。
2. When checking for prefix authorization, an exact route object prefix match is checked for first. If there is not an exact match then a longest prefix match that is less specific than the prefix is searched for. If the route prefix search fails, then a search is performed for an inetnum that exactly matches the prefix or for the most specific inetnum that is less specific than the route object submission.
2. 在检查前缀授权时，首先检查确切的路由对象前缀匹配。如果没有精确匹配，则搜索比前缀更不具体的最长前缀匹配。如果路由前缀搜索失败，则会对与前缀完全匹配的inetnum或比路由对象提交更不具体的最具体inetnum执行搜索。
The search for an inetnum should never fail but it may return an unallocated or reserved range. The inetnum status must be "allocated" and the submission must pass it's maintainer
对inetnum的搜索永远不会失败，但它可能返回未分配或保留的范围。inetnum状态必须为“已分配”，提交必须通过其维护程序
authorization in order to get authorization from an inetnum. So an unallocated or reserved range inetnum will cause the route object submission to fail.
授权，以便从inetnum获取授权。因此，未分配或保留的范围inetnum将导致路由对象提交失败。
3. A route object must pass authorization from both the referenced aut-num object and the route or inetnum object. Authorization shall be tested using the maintainer(s) referenced in the "mnt-routes" attribute(s) first. If that check fails, the "mnt-lower" attributes are checked. If that check fails the "mnt-by" attributes are used for the authorization check.
3. 路由对象必须同时从引用的aut num对象和路由或inetnum对象传递授权。授权应首先使用“mnt路线”属性中引用的维修人员进行测试。如果该检查失败，将检查“mnt lower”属性。如果该检查失败，“mnt by”属性将用于授权检查。
4. The "reclaim" attribute can appear in inetnum, route and as-block objects and provides a means to support address lending. "reclaim" gives authorization over more specific objects, regardless of the "mnt-by" in the object. The value of a "reclaim" attribute can be a list or set of objects to provide finer grain control.
4. “回收”属性可以显示在inetnum、route和as块对象中，并提供支持地址借出的方法。“回收”提供对更特定对象的授权，而不考虑对象中的“mnt by”。“回收”属性的值可以是一个列表或一组对象，以提供更细粒度的控制。
The "reclaim" attribute is important to this discussion since it affects prefix/origin authentication when a new route object is submitted.
“回收”属性对于本讨论非常重要，因为它会在提交新路由对象时影响前缀/源身份验证。
The "no-reclaim" attribute is used to provide explicit exceptions.
“无回收”属性用于提供显式异常。
The following pseudocode outlines the algorithm used to check for proper authorization of a route object submission.
以下伪代码概述了用于检查路由对象提交的正确授权的算法。
Case #1. Route object add (ie, no exact prefix/origin match exists).
案例1。管线对象添加（即，不存在精确的前缀/原点匹配）。
/* first check the aut-num authorization */
/* first check the aut-num authorization */
if ( the referenced aut-num object does not exist or the aut-num authorization fails ) authorization fails
如果（引用的aut num对象不存在或aut num授权失败）授权失败
/* next we check for prefix authorization */
/* next we check for prefix authorization */
if ( a less specific route(s) with the longest prefix is found ) [ if ( authorization does not pass for at least one of the less specific route(s) ) authorization fails
如果（找到前缀最长的非特定路由）[如果（至少一条非特定路由的授权未通过）]授权失败
/* now check for a "reclaim" attr */
/* now check for a "reclaim" attr */
if ( the object has a "reclaim" attribute ) [ if ( no more-specifics exist OR a less specific exists which passes authorization and has a "reclaim" attribute
if（对象有一个“回收”属性）[if（不存在更多的细节，或者存在一个通过授权并具有“回收”属性的不太具体的细节
OR all more specifics routess pass modify authorization ) authorization passes else authorization fails ] else authorization passes ]
或所有更多详细信息routess pass modify authorization）授权通过其他授权失败]其他授权通过]
/* there are no less specific routes to check for prefix
authentication, so we need to try and get authorization from an
inetnum object */
/* there are no less specific routes to check for prefix
authentication, so we need to try and get authorization from an
inetnum object */
if ( ( an inetnum is found that is an exact match OR is less specific and it's status is "allocated" ) AND a maintainer referenced by the inetnum passes authorization ) authorization succeeds
如果（（发现inetnum完全匹配或不太具体，且其状态为“已分配”），且inetnum引用的维护人员通过了授权），则授权成功
/* if there is no inetnum or route object then then
authorization fails. This should never happen if
the DB is initialized properly. */
/* if there is no inetnum or route object then then
authorization fails. This should never happen if
the DB is initialized properly. */
authorization fails.
授权失败。
Case #2. Route object modify/delete (ie, exact prefix/origin match exists).
案例2。路由对象修改/删除（即，存在精确的前缀/原点匹配）。
if ( the mnt-by passes authorization ) authorization succeeds
如果（mnt旁路授权）授权成功
/* if the authorization did not pass from the matched object,
we can still get authorization from a less specific route if it
has a "reclaim" attribute and we pass authorization */
/* if the authorization did not pass from the matched object,
we can still get authorization from a less specific route if it
has a "reclaim" attribute and we pass authorization */
if ( a less specific route or inetnum object passes authorization AND has a "reclaim" attribute applicable to the object to be modified ) authorization succeeds else authorization fails
如果（不太特定的路由或inetnum对象通过了授权，并且具有适用于要修改的对象的“回收”属性），则授权成功，否则授权失败
Acknowledgments
致谢
This document draws ideas from numerous discussions and contributions of the IETF Routing Policy System Work Group and RIPE Routing Work Group. Earlier drafts of this document listed Carol Orange as a co-author. Carol Orange made contributions to this document while at RIPE.
本文件从IETF路由策略系统工作组和成熟路由工作组的大量讨论和贡献中得出了一些想法。这份文件的早期草稿将卡罗尔·奥兰治列为合著者。卡罗尔·奥兰治（Carol Orange）在成熟时为本文件做出了贡献。
Gerald Winters provided the pseudocode in an email message to the RIPE dbsec mailing list that was the basis of the pseudocode found in appendix F. Susan Harris provided comments and numerous editorial corrections.
杰拉尔德·温特斯（Gerald Winters）在给成熟的dbsec邮件列表的电子邮件中提供了伪代码，该邮件列表是附录F中伪代码的基础。苏珊·哈里斯（Susan Harris）提供了评论和大量编辑更正。
Intellectual Property Notice
知识产权公告
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
References
工具书类
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra M. and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[1] Alaettinoglu，C.，Bates，T.，Gerich，E.，Karrenberg，D.，Meyer，D.，Terpstra M.和C.Villamizar，“路由策略规范语言（RPSL）”，RFC 2280，1998年1月。
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
[2] Bates，T.，Gerich，E.，Joncheray，L.，Jouanigot，J-M.，Karrenberg，D.，Terpstra，M.和J.Yu，“路由注册表中IP路由策略的表示（RIME-81++）”，RFC 17861995年3月。
[3] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[3] Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[4] Braun, H-W., "Models of policy based routing", RFC 1104, June 1989.
[4] 布劳恩，H-W，“基于策略的路由模型”，RFC1104，1989年6月。
[5] Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing architecture", RFC 1222, May 1991.
[5] Braun，H-W.和Y.Rekhter，“推进NSFNET路由架构”，RFC1222，1991年5月。
[6] Clark, D., "Policy routing in Internet protocols", RFC 1102, May 1989.
[6] Clark，D.，“因特网协议中的策略路由”，RFC1102，1989年5月。
[7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[7] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[8] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[8] Fuller，V.，Li，T.，Yu，J.和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[9] Internet Engineering Steering Group and R. Hinden, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
[9] 互联网工程指导小组和R.Hinden，“实施无类别域间路由（CIDR）的适用性声明”，RFC 1517，1993年9月。
[10] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[10] 霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，RFC 1930，1996年3月。
[11] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[11] 哈伯德，K.，科斯特斯，M.，康拉德，D.，卡伦伯格，D.和J.波斯特尔，“互联网注册IP分配指南”，BCP 12，RFC 2050，1996年11月。
[12] Knopper, M. and S. Richardson, "Aggregation Support in the NSFNET Policy-Based Routing Database", RFC 1482, June 1993.
[12] Knopper，M.和S.Richardson，“基于NSFNET策略的路由数据库中的聚合支持”，RFC 1482，1993年6月。
[13] Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol Orange, "Using RPSL in Practice", RFC 2650, August 1999.
[13] Meyer，D.，Prior，M.，Alaettinoglu，C.，Schmitz，J.和Carol Orange，“在实践中使用RPSL”，RFC 2650，1999年8月。
[14] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[14] Rekhter，Y.，“多提供商互联网中的路由”，RFC 1787，1995年4月。
[15] Rekhter Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[15] Rekhter Y.和T.Li，“使用CIDR的IP地址分配架构”，RFC 1518，1993年9月。
[16] Rekhter Y. and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", RFC 2008, October 1996.
[16] Rekhter Y.和T.Li，“各种地址分配策略对互联网路由的影响”，RFC 2008，1996年10月。
[17] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, January 1997.
[17] Rekhter，Y.，Lothberg，P.，Hinden，R.，Deering，S.和J.Postel，“基于IPv6提供商的单播地址格式”，RFC 2073，1997年1月。
[18] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC 2726, December 1999.
[18] Zsako，J.，“成熟数据库更新的PGP认证”，RFC2726，1999年12月。
Security Considerations
安全考虑
This document primarily addresses authorization rules for making additions, deletions, and changes to routing policy information repositories. The authentication of these transactions through strong cryptographic means are addressed by [18], referenced thorughout this document. The authorization rules are designed such that the integrity of any transaction can be verified independently by any party mirroring a repository to insure that rules are adhered to. To accomplish this the mirror must contain data already known to be properly authorized. In other words, the mirror must be complete and authentication and authorization checks must be made continuously as changes to the repository are recieved and processed in order.
本文档主要介绍对路由策略信息存储库进行添加、删除和更改的授权规则。通过强加密手段对这些交易进行的身份验证由本文件中引用的[18]解决。授权规则的设计使得镜像存储库的任何一方都可以独立地验证任何事务的完整性，以确保遵守规则。要完成此操作，镜像必须包含已知已正确授权的数据。换句话说，镜像必须是完整的，并且在接收到存储库的更改并按顺序进行处理时，必须持续进行身份验证和授权检查。
Authentication alone does not provide a complete security model. Current practice specifies authorization for deletions and changes only, not for additions. The authorization rules provide here complete the security model for additions, deletions, and changes by very explicitly defining rules for addition and clarifying procedures for handling exception cases such as organizations which have ceased to exist and therefore become entirely unresponsive.
仅身份验证并不能提供完整的安全模型。目前的做法规定仅授权删除和更改，不授权添加。授权规则通过非常明确地定义添加规则并澄清处理异常情况（如已不复存在并因此变得完全无响应的组织）的程序，在这里提供了完整的添加、删除和更改安全模型。
Authentication and authorization of queries is explicitly stated to be out of scope of this document.
查询的身份验证和授权明确规定不在本文件范围内。
Authors' Addresses
作者地址
Curtis Villamizar Avici Systems EMail: curtis@avici.com
Curtis Villamizar Avici系统电子邮件：curtis@avici.com
Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU
Cengiz Alaettinoglu ISI电子邮件：cengiz@ISI.EDU
David M. Meyer Cisco EMail: dmm@cisco.com
David M.Meyer Cisco电子邮件：dmm@cisco.com
Sandy Murphy Trusted Information Systems EMail: sandy@tis.com
Sandy Murphy可信信息系统电子邮件：sandy@tis.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。