Internet Engineering Task Force (IETF) T. Manderson
Request for Comments: 6907 ICANN
Category: Informational K. Sriram
ISSN: 2070-1721 US NIST
R. White
Verisign
March 2013
Internet Engineering Task Force (IETF) T. Manderson
Request for Comments: 6907 ICANN
Category: Informational K. Sriram
ISSN: 2070-1721 US NIST
R. White
Verisign
March 2013
Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties
发行人和依赖方的资源公钥基础设施（RPKI）对象的用例和解释
Abstract
摘要
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.
本文档描述了在公共RPKI中创建或遇到资源公钥基础设施（RPKI）对象场景时，组织和依赖方的一些用例以及说明和解释。这里讨论的所有这些项目都与Internet路由系统有关。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6907.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6907.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Documentation Prefixes .....................................4
1.3. Definitions ................................................4
2. Overview ........................................................6
2.1. General Interpretation of RPKI Object Semantics ............6
3. Origination Use Cases ...........................................7
3.1. Single Announcement ........................................8
3.2. Aggregate with a More Specific .............................8
3.3. Aggregate with a More Specific from a Different ASN ........9
3.4. Sub-Allocation to a Multi-Homed Customer ...................9
3.5. Restriction of a New Allocation ...........................10
3.6. Restriction of New ASN ....................................11
3.7. Restriction of a Part of an Allocation ....................11
3.8. Restriction of Prefix Length ..............................12
3.9. Restriction of Sub-Allocation Prefix Length ...............13
3.10. Aggregation and Origination by an Upstream Provider ......15
3.11. Rogue Aggregation and Origination by an Upstream
Provider .................................................16
4. Adjacency or Path Validation Use Cases .........................17
5. Partial Deployment Use Cases ...................................18
5.1. Parent Does Not Participate in RPKI .......................18
5.2. Only Some Children Participate in RPKI ....................18
5.3. Grandchild Does Not Participate in RPKI ...................19
6. Transfer Use Cases .............................................20
6.1. Transfer of In-Use Prefix and Autonomous System Number ....20
6.2. Transfer of In-Use Prefix .................................21
6.3. Transfer of Unused Prefix .................................22
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Documentation Prefixes .....................................4
1.3. Definitions ................................................4
2. Overview ........................................................6
2.1. General Interpretation of RPKI Object Semantics ............6
3. Origination Use Cases ...........................................7
3.1. Single Announcement ........................................8
3.2. Aggregate with a More Specific .............................8
3.3. Aggregate with a More Specific from a Different ASN ........9
3.4. Sub-Allocation to a Multi-Homed Customer ...................9
3.5. Restriction of a New Allocation ...........................10
3.6. Restriction of New ASN ....................................11
3.7. Restriction of a Part of an Allocation ....................11
3.8. Restriction of Prefix Length ..............................12
3.9. Restriction of Sub-Allocation Prefix Length ...............13
3.10. Aggregation and Origination by an Upstream Provider ......15
3.11. Rogue Aggregation and Origination by an Upstream
Provider .................................................16
4. Adjacency or Path Validation Use Cases .........................17
5. Partial Deployment Use Cases ...................................18
5.1. Parent Does Not Participate in RPKI .......................18
5.2. Only Some Children Participate in RPKI ....................18
5.3. Grandchild Does Not Participate in RPKI ...................19
6. Transfer Use Cases .............................................20
6.1. Transfer of In-Use Prefix and Autonomous System Number ....20
6.2. Transfer of In-Use Prefix .................................21
6.3. Transfer of Unused Prefix .................................22
7. Relying Party Use Cases ........................................22
7.1. Prefix-Origin Validation Use Cases ........................22
7.1.1. Covering ROA Prefix, maxLength Satisfied,
and AS Match .......................................23
7.1.2. Covering ROA Prefix, maxLength Exceeded,
and AS Match .......................................23
7.1.3. Covering ROA Prefix, maxLength Satisfied,
and AS Mismatch ....................................23
7.1.4. Covering ROA Prefix, maxLength Exceeded,
and AS Mismatch ....................................24
7.1.5. Covering ROA Prefix Not Found ......................24
7.1.6. Covering ROA Prefix and the ROA Is an AS 0 ROA .....24
7.1.7. Covering ROA Prefix Not Found but ROAs
Exist for a Covering Set of More Specifics .........25
7.1.8. AS_SET in Route and Covering ROA Prefix Not Found ..25
7.1.9. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Match ..................26
7.1.10. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Mismatch ..............26
7.1.11. Multiple ASs in AS_SET (in the Route) and
Covering ROA Prefix ...............................26
7.1.12. Multiple ASs in AS_SET (in the Route) and
ROAs Exist for a Covering Set of More Specifics ...27
7.2. ROA Expiry or Receipt of a CRL Revoking a ROA .............27
7.2.1. ROA of Parent Prefix Is Revoked ....................27
7.2.2. ROA of Prefix Revoked while Parent Prefix
Has Covering ROA Prefix with Different ASN .........28
7.2.3. ROA of Prefix Revoked while That of Parent
Prefix Prevails ....................................28
7.2.4. ROA of Grandparent Prefix Revoked while
That of Parent Prefix Prevails .....................28
7.2.5. Expiry of ROA of Parent Prefix .....................29
7.2.6. Expiry of ROA of Prefix while Parent Prefix
Has Covering ROA with Different ASN ................29
7.2.7. Expiry of ROA of Prefix while That of
Parent Prefix Prevails .............................29
7.2.8. Expiry of ROA of Grandparent Prefix while
That of Parent Prefix Prevails .....................29
8. Acknowledgements ...............................................30
9. Security Considerations ........................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................30
7. Relying Party Use Cases ........................................22
7.1. Prefix-Origin Validation Use Cases ........................22
7.1.1. Covering ROA Prefix, maxLength Satisfied,
and AS Match .......................................23
7.1.2. Covering ROA Prefix, maxLength Exceeded,
and AS Match .......................................23
7.1.3. Covering ROA Prefix, maxLength Satisfied,
and AS Mismatch ....................................23
7.1.4. Covering ROA Prefix, maxLength Exceeded,
and AS Mismatch ....................................24
7.1.5. Covering ROA Prefix Not Found ......................24
7.1.6. Covering ROA Prefix and the ROA Is an AS 0 ROA .....24
7.1.7. Covering ROA Prefix Not Found but ROAs
Exist for a Covering Set of More Specifics .........25
7.1.8. AS_SET in Route and Covering ROA Prefix Not Found ..25
7.1.9. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Match ..................26
7.1.10. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Mismatch ..............26
7.1.11. Multiple ASs in AS_SET (in the Route) and
Covering ROA Prefix ...............................26
7.1.12. Multiple ASs in AS_SET (in the Route) and
ROAs Exist for a Covering Set of More Specifics ...27
7.2. ROA Expiry or Receipt of a CRL Revoking a ROA .............27
7.2.1. ROA of Parent Prefix Is Revoked ....................27
7.2.2. ROA of Prefix Revoked while Parent Prefix
Has Covering ROA Prefix with Different ASN .........28
7.2.3. ROA of Prefix Revoked while That of Parent
Prefix Prevails ....................................28
7.2.4. ROA of Grandparent Prefix Revoked while
That of Parent Prefix Prevails .....................28
7.2.5. Expiry of ROA of Parent Prefix .....................29
7.2.6. Expiry of ROA of Prefix while Parent Prefix
Has Covering ROA with Different ASN ................29
7.2.7. Expiry of ROA of Prefix while That of
Parent Prefix Prevails .............................29
7.2.8. Expiry of ROA of Grandparent Prefix while
That of Parent Prefix Prevails .....................29
8. Acknowledgements ...............................................30
9. Security Considerations ........................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................30
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.
本文档描述了在公共RPKI中创建或遇到资源公钥基础设施（RPKI）对象场景时，组织和依赖方的一些用例以及说明和解释。这里讨论的所有这些项目都与Internet路由系统有关。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile for X.509 PKIX Resource Certificates" [RFC6487], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A Profile for Route Origin Authorizations (ROAs)" [RFC6482], "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)" [RFC6483], and "BGP Prefix Origin Validation" [RFC6811].
假设读者熟悉“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]、“X.509 PKIX资源证书配置文件”[RFC6487]、“用于IP地址和作为标识符的X.509扩展”[RFC3779]中描述的术语和概念，“路由起始授权（ROA）的配置文件”[RFC6482]、“使用资源证书公钥基础设施（PKI）和路由起始授权（ROA）验证路由起始”[RFC6483]和“BGP前缀起始验证”[RFC6811]。
The documentation prefixes recommended in [RFC5737] are insufficient for use as example prefixes in this document. Therefore, this document uses RFC 1918 [RFC1918] address space for constructing example prefixes.
[RFC5737]中推荐的文档前缀不足以用作本文档中的示例前缀。因此，本文使用RFC1918[RFC1918]地址空间来构造示例前缀。
For all of the use cases in this document, it is assumed that RPKI objects (e.g., resource certificates, ROAs) validate in accordance with [RFC6487] and [RFC6480]. In other words, we assume that corrupted RPKI objects, if any, have been detected and eliminated.
对于本文档中的所有用例，假设RPKI对象（例如资源证书、ROA）根据[RFC6487]和[RFC6480]进行验证。换句话说，我们假设已经检测到并消除了损坏的RPKI对象（如果有的话）。
The following definitions are in use in this document. Some of these definitions are reused or adapted from [RFC6811] with authors' permission.
本文件中使用了以下定义。其中一些定义在作者许可的情况下被重用或改编自[RFC6811]。
Resource: An IP address prefix (simply called prefix or subnet) or an Autonomous System Number (ASN).
资源：IP地址前缀（简称前缀或子网）或自治系统号（ASN）。
Allocation: A set of resources provided to an entity or organization for its use.
分配：提供给实体或组织供其使用的一组资源。
Sub-allocation: A set of resources subordinate to an allocation assigned to another entity or organization.
子分配：从属于分配给另一实体或组织的分配的一组资源。
Prefix: A prefix consists of a pair (IP address, prefix length), interpreted as is customary (see [RFC4632]).
前缀：前缀由一对（IP地址、前缀长度）组成，按照惯例进行解释（参见[RFC4632]）。
Route: Data derived from a received BGP update, as defined in [RFC4271], Section 1.1. The route includes one prefix and an AS_PATH, among other things.
路由：根据[RFC4271]第1.1节的定义，从接收到的BGP更新中获得的数据。路由包括一个前缀和一个AS_路径等。
ROA: Route Origin Authorization (ROA) is an RPKI object signed by a prefix holder authorizing origination of said prefix from an origin AS specified in said ROA.
ROA:Route Origin Authorization（ROA）是由前缀持有者签署的RPKI对象，授权从所述ROA中指定的原点发起所述前缀。
AS 0 ROA: A ROA with ASN value 0 (zero) in the AS ID field. AS 0 ROA is an attestation by a prefix holder that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context [RFC6483].
AS 0 ROA：AS ID字段中ASN值为0（零）的ROA。因为0 ROA是前缀持有者的证明，即ROA中描述的前缀以及任何更具体的前缀不应在路由上下文中使用[RFC6483]。
ROA prefix: The prefix from a ROA.
ROA前缀：来自ROA的前缀。
ROA ASN: The origin ASN from a ROA.
ROA ASN：来源于ROA的ASN。
maxLength: The maximum length up to which more specific prefixes of a ROA prefix may be originated from the corresponding ROA ASN. The maxLength is specified in the ROA.
maxLength：ROA前缀的更多特定前缀可以从相应的ROA ASN发起的最大长度。maxLength在ROA中指定。
Route prefix: A prefix derived from a route.
路由前缀：从路由派生的前缀。
Route origin ASN: The origin AS number derived from a route. The origin AS number is:
路由原点ASN：从路由派生的原点AS编号。原始编号为：
o the rightmost AS in the final segment of the AS_PATH attribute in the route if that segment is of type AS_SEQUENCE, or
o 路线中AS_路径属性的最后一段中最右边的AS，如果该段类型为AS_序列，或
o the BGP speaker's own AS number if that segment is of type AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, or
o BGP扬声器自己的AS编号，如果该段属于AS_-CONFED_序列或AS_-CONFED_集类型，或者AS_路径为空，或者
o the distinguished value "NONE" if the final segment of the AS_PATH attribute is of any other type.
o 如果AS_路径属性的最后一段为任何其他类型，则可分辨值为“无”。
Covering ROA prefix: A ROA prefix that is an exact match or a less specific when compared to the route prefix under consideration. In other words, the route prefix is said to have a covering ROA prefix when there exists a ROA such that the ROA prefix length is less than or equal to the route prefix length and the ROA prefix address matches the route prefix address for all bits specified by the ROA prefix length.
覆盖ROA前缀：与考虑中的路由前缀相比，完全匹配或不太具体的ROA前缀。换句话说，当存在ROA使得ROA前缀长度小于或等于路由前缀长度并且ROA前缀地址与由ROA前缀长度指定的所有比特的路由前缀地址匹配时，路由前缀被称为具有覆盖ROA前缀。
Covering ROA: If a ROA contains a covering ROA prefix for a route prefix under consideration, then the ROA is said to be a covering ROA for the route prefix.
覆盖ROA：如果ROA包含考虑中的路由前缀的覆盖ROA前缀，则该ROA称为路由前缀的覆盖ROA。
No covering ROA: No covering ROA exists for a route prefix under consideration.
无覆盖ROA：考虑中的路由前缀不存在覆盖ROA。
No other covering ROA: No other covering ROA exists (besides what is (are) already cited) for a route prefix under consideration.
无其他覆盖ROA：考虑中的路由前缀不存在其他覆盖ROA（除了已经引用的内容）。
Multi-homed prefix or subnet: A prefix (i.e., subnet) for which a route is originated through two or more autonomous systems.
多宿前缀或子网：通过两个或多个自治系统发起路由的前缀（即子网）。
Matched: A route's {prefix, origin AS} pair is said to be matched by a ROA when the route prefix has a covering ROA, and in addition, the route prefix length is less than or equal to the maxLength in said covering ROA and the route origin ASN is equal to the ASN in said covering ROA.
匹配：当路由前缀具有覆盖ROA时，称路由的{prefix，origin AS}对与ROA匹配，此外，路由前缀长度小于或等于所述覆盖ROA中的maxLength，且路由原点ASN等于所述覆盖ROA中的ASN。
Given these definitions, any given BGP route will be found to have one of the following "validation states":
根据这些定义，任何给定的BGP路由将被发现具有以下“验证状态”之一：
o NotFound: The route prefix has no covering ROA.
o NotFound:路由前缀没有覆盖ROA。
o Valid: The route's {prefix, origin AS} pair is matched by at least one ROA.
o 有效：路由的{prefix，origin AS}对至少由一个ROA匹配。
o Invalid: The route prefix has at least one covering ROA and the route's {prefix, origin AS} pair is not matched by any ROA.
o 无效：路由前缀至少有一个覆盖ROA，并且路由的{prefix，origin AS}对未与任何ROA匹配。
It is to be noted that no ROA can have the value "NONE" as its ROA ASN. Thus, a route whose origin ASN is "NONE" cannot be matched by any ROA. Similarly, no valid route can have an origin ASN of zero [AS0-PROC]. Thus, no route can be matched by a ROA whose ASN is zero (i.e., an AS 0 ROA) [RFC6483].
需要注意的是，任何ROA都不能将值“NONE”作为其ROA ASN。因此，源ASN为“无”的路由不能与任何ROA匹配。类似地，任何有效路由的原点ASN都不能为零[AS0-PROC]。因此，ASN为零的ROA（即AS 0 ROA）无法匹配任何路由[RFC6483]。
In the interpretation of relying parties (RPs), or relying party routing software, it is important that a 'make before break' operational policy be applied. In part, this means that an RP should implement a routing decision process where a route is assumed to be intended (i.e., considered unsuspicious) unless proven otherwise by the existence of a valid RPKI object that explicitly invalidates the route (see Section 7.1 for examples). Also, especially in cases when a prefix is newly acquired by allocation/sub-allocation or due to
在解释依赖方（RPs）或依赖方路由软件时，重要的是应用“先制造后破坏”的操作策略。在某种程度上，这意味着RP应实施一个路由决策过程，在该过程中，除非存在明确使路由无效的有效RPKI对象（示例见第7.1节），否则假定路由是预期的（即，被认为是不可疑的）。此外，尤其是在通过分配/子分配或由于以下原因新获取前缀的情况下：
prefix-ownership transfer, a ROA should be registered in RPKI prior to advertisement of the prefix in BGP. This is highly recommended for the following reasons. Observe that in the transfer case (considering a prefix transfer from Org A to Org B), even though Org A's resource cert would be revoked before issuing a resource cert to Org B, there may be some latency before all relying parties discard the previously received ROA of Org A for that prefix. The latency may be due to CRL propagation delay in the RPKI system or due to periodic polling by RPs, etc. Also, observe that in the sub-allocation case (from parent Org A to child Org B), there may be an existing ROA registered by Org A (with their own origin ASN) for a covering aggregate prefix relative to the prefix in consideration. If the new prefix owner (Org B) has not already registered their own ROA (i.e., ROA with their origin ASN), then the presence of a different covering ROA (i.e., one with a different origin ASN) belonging to Org A would result in invalid assessment for the route advertised by the new owner (Org B). Thus, in both cases (transfer or sub-allocation), it is prudent for the new owner (Org B) to ensure that its route for the prefix will be valid by proactively issuing a ROA before advertising the route. The ROA should be issued with sufficient lead time taking into consideration the RPKI propagation delays.
前缀所有权转让，在BGP中公布前缀之前，应在RPKI中注册ROA。出于以下原因，强烈建议这样做。请注意，在转移案例中（考虑从组织a到组织B的前缀转移），即使组织a的资源证书在向组织B颁发资源证书之前会被撤销，但在所有依赖方放弃之前收到的组织a对该前缀的ROA之前，可能会有一些延迟。延迟可能是由于RPKI系统中的CRL传播延迟或由于RPs的定期轮询等造成的。此外，请注意，在子分配情况下（从父组织A到子组织B），可能存在由组织A注册的覆盖聚合前缀的现有ROA（其自身来源为ASN），该覆盖聚合前缀相对于所考虑的前缀。如果新前缀所有者（组织B）尚未注册其自己的ROA（即，具有其来源ASN的ROA），则存在属于组织a的不同覆盖ROA（即具有不同来源ASN的ROA）将导致对新所有者（组织B）公布的路线的无效评估。因此，在这两种情况下（转移或再分配），新所有者（组织B）在公布路由之前，通过主动发布ROA来确保其前缀路由有效是谨慎的。考虑到RPKI传播延迟，ROA应具有足够的前置时间。
As stated earlier in Section 1.3, for all of the use cases in this document, it is assumed that RPKI objects (e.g., resource certificates, ROAs) validate in accordance with [RFC6487] and [RFC6480]. In other words, we assume that corrupted RPKI objects, if any, have been detected and eliminated.
如前所述，对于本文档中的所有用例，假设RPKI对象（例如资源证书、ROA）按照[RFC6487]和[RFC6480]进行验证。换句话说，我们假设已经检测到并消除了损坏的RPKI对象（如果有的话）。
While many of the examples provided here illustrate organizations using their own autonomous system numbers to originate routes, it should be recognized that a prefix holder need not necessarily be the holder of the autonomous system number used for the route origination.
虽然这里提供的许多示例说明了组织使用其自己的自治系统号来发起路由，但应该认识到前缀持有者不一定是用于路由发起的自治系统号的持有者。
This section deals with the various use cases where an organization has Internet resources and will announce routes to the Internet. It is based on operational observations of the existing routing system. In the following use cases, the phrase "relying parties interpret the route as intended" is generally meant to indicate that "relying parties interpret an announced route as having a valid origination AS".
本节讨论组织拥有Internet资源并将宣布到Internet的路由的各种用例。它基于对现有路由系统的操作观察。在以下用例中，“依赖方将路线解释为预期路线”通常意味着“依赖方将公布的路线解释为具有有效的原始路线”。
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.2.0/24. It wishes to announce the /24 prefix from ASN 64496 such that relying parties interpret the route as intended.
已将前缀10.1.2.0/24分配给组织（ASN为64496的组织A）。它希望宣布ASN 64496中的/24前缀，以便依赖方按照预期解释路线。
The desired announcement (and organization) would be:
预期的公告（和组织）将是：
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.2.0/24 | AS 64496 | Org A |
+----------------------------------------------+
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.2.0/24 | AS 64496 | Org A |
+----------------------------------------------+
The issuing party should create a ROA containing the following:
签发方应创建包含以下内容的居留权：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. It wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64496 as well as the aggregate route such that relying parties interpret the routes as intended.
已为组织（ASN为64496的组织A）分配前缀10.1.0.0/16。它希望公布ASN 64496中更具体的前缀10.1.0.0/20以及总路线，以便依赖方按照预期解释路线。
The desired announcements (and organization) would be:
所需的公告（和组织）将是：
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
+----------------------------------------------+
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
+----------------------------------------------+
The issuing party should create a ROA containing the following:
签发方应创建包含以下内容的居留权：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
An organization (Org A with ASN 64496 and ASN 64511) has been allocated the prefix 10.1.0.0/16. It wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64511 as well as the aggregate route from ASN 64496 such that relying parties interpret the routes as intended.
一个组织（ASN 64496和ASN 64511的组织A）已分配前缀10.1.0.0/16。它希望公布ASN 64511中更具体的前缀10.1.0.0/20以及ASN 64496中的总路线，以便依赖方按照预期解释路线。
The desired announcements (and organization) would be:
所需的公告（和组织）将是：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64511 | Org A |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64511 | Org A |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
签发方应创建包含以下内容的ROA：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16; it wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to a customer (Org B with ASN 64511) who is multi-homed and will originate the prefix route from ASN 64511. ASN 64496 will also announce the aggregate route such that relying parties interpret the routes as intended.
已将前缀10.1.0.0/16分配给组织（ASN为64496的组织A）；它希望宣布ASN 64496中更具体的前缀10.1.0.0/20。它还将10.1.16.0/20委托给了一个客户（具有ASN 64511的组织B），该客户是多宿的，将从ASN 64511发起前缀路由。ASN 64496还将公布总路线，以便依赖方按照预期解释路线。
The desired announcements (and organizations) would be:
所需的公告（和组织）将是：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
| 10.1.16.0/20 | AS 64511 | Org B |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
| 10.1.16.0/20 | AS 64511 | Org B |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
签发方应创建包含以下内容的ROA：
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
An organization has recently been allocated the prefix 10.1.0.0/16. Its network deployment is not yet ready to announce the prefix and wishes to restrict all possible announcements of 10.1.0.0/16 and more specifics in routing using RPKI.
最近为一个组织分配了前缀10.1.0.0/16。其网络部署尚未准备好宣布前缀，并希望限制10.1.0.0/16的所有可能公告，以及使用RPKI路由的更多细节。
The following announcements would be considered undesirable:
下列公告将被视为不可取：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | ANY AS | ANY |
| 10.1.0.0/20 | ANY AS | ANY |
| 10.1.17.0/24 | ANY AS | ANY |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | ANY AS | ANY |
| 10.1.0.0/20 | ANY AS | ANY |
| 10.1.17.0/24 | ANY AS | ANY |
+---------------------------------------------+
The issuing party should create a ROA containing the following:
签发方应创建包含以下内容的居留权：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.0.0/16 | 32 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.0.0/16 | 32 |
+----------------------------------------------+
This is known as an AS 0 ROA [RFC6483]. Also, please see the definition and related comments in Section 1.3.
这被称为as 0 ROA[RFC6483]。此外，请参见第1.3节中的定义和相关注释。
An organization has recently been allocated an additional ASN 64511. Its network deployment is not yet ready to use this ASN and wishes to restrict all possible uses of ASN 64511 using RPKI.
最近为一个组织分配了额外的ASN 64511。其网络部署尚未准备好使用此ASN，并希望使用RPKI限制ASN 64511的所有可能使用。
The following announcement would be considered undesirable:
以下公告将被视为不可取：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| ANY | AS 64511 | ANY |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| ANY | AS 64511 | ANY |
+---------------------------------------------+
It is currently not possible to restrict use of autonomous system numbers.
目前无法限制使用自主系统编号。
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. Its network topology permits the announcement of 10.1.0.0/17. Org A wishes to restrict any possible announcement of 10.1.128.0/17 or more specifics of that /17 using RPKI.
已为组织（ASN为64496的组织A）分配前缀10.1.0.0/16。其网络拓扑允许发布10.1.0.0/17。Org A希望限制使用RPKI发布10.1.128.0/17或更详细的10.1.128.0/17。
The desired announcement (and organization) would be:
预期的公告（和组织）将是：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/17 | AS 64496 | Org A |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/17 | AS 64496 | Org A |
+---------------------------------------------+
The following announcements would be considered undesirable:
下列公告将被视为不可取：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.128.0/17 | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.128.0/17 | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
签发方应创建包含以下内容的ROA：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/17 | 17 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/17 | 17 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.128.0/17 | 32 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.128.0/17 | 32 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16; it wishes to announce the aggregate and any or all more specific prefixes up to and including a maximum length of /20, but never any more specific than a /20.
已将前缀10.1.0.0/16分配给组织（ASN为64496的组织A）；它希望公布聚合和任何或所有更具体的前缀，最大长度为/20，但决不能超过a/20。
Examples of the desired announcements (and organization) would be:
所需公告（和组织）的示例如下：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/17 | AS 64496 | Org A |
| ... | AS 64496 | Org A |
| 10.1.128.0/20 | AS 64496 | Org A |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/17 | AS 64496 | Org A |
| ... | AS 64496 | Org A |
| 10.1.128.0/20 | AS 64496 | Org A |
+---------------------------------------------+
The following announcements would be considered undesirable:
下列公告将被视为不可取：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/21 | ANY AS | ANY |
| 10.1.0.0/22 | ANY AS | ANY |
| ... | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/21 | ANY AS | ANY |
| 10.1.0.0/22 | ANY AS | ANY |
| ... | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+
The issuing party should create a ROA containing the following:
签发方应创建包含以下内容的居留权：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 20 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 20 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. It sub-allocates several /20 prefixes to its multi-homed customers: Org B with ASN 64501 and Org C with ASN 64499, respectively. It wishes to restrict those customers from advertising any corresponding routes more specific than a /22.
已为组织（ASN为64496的组织A）分配前缀10.1.0.0/16。它将几个/20前缀分配给它的多宿客户：分别是带有ASN 64501的组织B和带有ASN 64499的组织C。它希望限制这些客户宣传比a/22更具体的任何相应路线。
The desired announcements (and organizations) would be:
所需的公告（和组织）将是：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64501 | Org B |
| 10.1.128.0/20 | AS 64499 | Org C |
| 10.1.4.0/22 | AS 64501 | Org B |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64501 | Org B |
| 10.1.128.0/20 | AS 64499 | Org C |
| 10.1.4.0/22 | AS 64501 | Org B |
+---------------------------------------------+
The following example announcements (and organizations) would be considered undesirable:
以下示例公告（和组织）将被视为不可取的：
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/24 | AS 64501 | Org B |
| 10.1.128.0/24 | AS 64499 | Org C |
| ..... | ... | ... |
| 10.1.0.0/23 | ANY AS | ANY |
+---------------------------------------------+
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/24 | AS 64501 | Org B |
| 10.1.128.0/24 | AS 64499 | Org C |
| ..... | ... | ... |
| 10.1.0.0/23 | ANY AS | ANY |
+---------------------------------------------+
The issuing party (Org A) should create ROAs containing the following:
签发方（组织A）应创建包含以下内容的ROA：
For Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64501 | 10.1.0.0/20 | 22 |
+----------------------------------------------+
For Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64501 | 10.1.0.0/20 | 22 |
+----------------------------------------------+
For Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.128.0/20 | 22 |
+----------------------------------------------+
For Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.128.0/20 | 22 |
+----------------------------------------------+
Consider four organizations with the following resources, which were acquired independently from any transit provider.
考虑四个具有下列资源的组织，它们是独立于任何转接提供者获得的。
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64505 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64505 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit X (ASN 64497) that originates an aggregate of these prefixes with the permission of all four organizations.
这些组织共享一个通用的上游提供商Transit X（ASN 64497），该提供商在所有四个组织的许可下生成这些前缀的集合。
The desired announcements (and organizations) would be:
所需的公告（和组织）将是：
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64505 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64505 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+
It is currently not possible for an upstream provider to make a valid aggregate announcement of independent prefixes. However, the issuing parties should create ROAs containing the following:
目前，上游提供商不可能对独立前缀进行有效的聚合声明。但是，签发方应创建包含以下内容的ROA：
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Consider four organizations with the following resources that were acquired independently from any transit provider.
考虑以下四个组织，这些资源是独立于任何运输商获得的。
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64503 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64503 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit X (ASN 64497) that originates an aggregate of these prefixes where possible. In this situation, Org B (ASN 64503, 10.1.3.0/24) does not wish for its prefix to be aggregated by the upstream provider.
这些组织共享一个通用的上游提供商Transit X（ASN 64497），该提供商尽可能生成这些前缀的集合。在这种情况下，组织B（ASN 64503，10.1.3.0/24）不希望上游提供商聚合其前缀。
The desired announcements (and organizations) would be:
所需的公告（和组织）将是：
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64503 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/23 | AS 64497 | Transit X |
+----------------------------------------------+
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64503 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/23 | AS 64497 | Transit X |
+----------------------------------------------+
The following announcement would be considered undesirable:
以下公告将被视为不可取：
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+
It is currently not possible for an upstream provider to make a valid aggregate announcement of independent prefixes. However, the issuing parties should create ROAs containing the following:
目前，上游提供商不可能对独立前缀进行有效的聚合声明。但是，签发方应创建包含以下内容的ROA：
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64503 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64503 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Use cases pertaining to adjacency or path validation are beyond the scope of this document and would be addressed in a separate document.
与邻接或路径验证相关的用例超出了本文档的范围，将在单独的文档中讨论。
An organization (Org A with ASN 64511) is multi-homed and has been assigned the prefix 10.1.0.0/20 from its upstream (Transit X with ASN 64496). Org A wishes to announce the prefix 10.1.0.0/20 from ASN 64511 to its other upstream(s). Org A also wishes to create RPKI statements about the resource; however, Transit X (ASN 64496), which announces the aggregate 10.1.0.0/16, has not yet adopted RPKI.
组织（具有ASN 64511的组织A）是多宿组织，并且已从其上游（具有ASN 64496的运输X）分配前缀10.1.0.0/20。组织A希望将前缀10.1.0.0/20从ASN 64511发布到其其他上游。ORGA还希望创建关于资源的RPKI语句；然而，宣布总量为10.1.0.0/16的Transit X（ASN 64496）尚未采用RPKI。
The desired announcements (and organization with RPKI adoption) would be:
预期的公告（以及采用RPKI的组织）将是：
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/20 | AS 64511 | Org A | Yes |
| 10.1.0.0/16 | AS 64496 | Transit X | No |
+----------------------------------------------------+
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/20 | AS 64511 | Org A | Yes |
| 10.1.0.0/16 | AS 64496 | Transit X | No |
+----------------------------------------------------+
RPKI is strictly hierarchical; therefore, if Transit X does not participate in RPKI, Org A is unable to validly issue RPKI objects.
RPKI是严格等级的；因此，如果Transit X不参与RPKI，则组织A无法有效地发布RPKI对象。
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16 and participates in RPKI; it wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and Org C with ASN 64502 (respectively), who are multi-homed. Org B (ASN 64511) does not participate in RPKI. Org C (ASN 64502) participates in RPKI.
一个组织（ASN为64496的组织A）已分配前缀10.1.0.0/16并参与RPKI；它希望宣布ASN 64496中更具体的前缀10.1.0.0/20。它还将10.1.16.0/20和10.1.32.0/20分别委托给ASN为64511的客户组织B和ASN为64502的客户组织C，这两个客户都是多宿客户。组织B（ASN 64511）不参与RPKI。组织C（ASN 64502）参与RPKI。
The desired announcements (and organizations with RPKI adoption) would be:
预期的公告（以及采用RPKI的组织）将是：
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
+----------------------------------------------------+
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
发行方应创建包含以下内容的ROA：
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
Consider the previous example, with an extension by which Org B, who does not participate in RPKI, further allocates 10.1.17.0/24 to Org X with ASN 64505. Org X does not participate in RPKI.
考虑前面的例子，ORG B不参与RPKI的扩展，用ASN 64505进一步分配到ORG X的101.170/24。OrgX不参与RPKI。
The desired announcements (and organizations with RPKI adoption) would be:
预期的公告（以及采用RPKI的组织）将是：
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
| 10.1.17.0/24 | AS 64505 | Org X | No |
+----------------------------------------------------+
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
| 10.1.17.0/24 | AS 64505 | Org X | No |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
发行方应创建包含以下内容的ROA：
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B's customer Org X:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.17.0/24 | 24 |
+----------------------------------------------+
Org A issues for Org B's customer Org X:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.17.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
For transfer use cases, based on the preceding sections, it should be easy to deduce what new ROAs need to be created and what existing ROAs need to be maintained (or revoked). The resource transfer and timing of revocation/creation of the ROAs need to be performed based on the make-before-break principle and using suitable Regional Internet Registry (RIR) procedures (see Section 2.1).
对于转移用例，基于前面的部分，应该很容易推断出需要创建哪些新的ROA以及需要维护（或撤销）哪些现有ROA。资源转移和撤销/创建ROA的时间需要基于先创造后破坏原则，并使用合适的区域互联网注册（RIR）程序进行（见第2.1节）。
Org A holds the resource 10.1.0.0/20, and it is currently in use and originated from AS 64496 with valid RPKI objects in place. Org B has acquired both the prefix and ASN and desires an RPKI transfer on a particular date and time without adversely affecting the operational use of the resource.
OrgA拥有资源10.1.0.0/20，它目前正在使用中，源于AS 64496，并具有有效的RPKI对象。组织B已获得前缀和ASN，并希望在特定日期和时间进行RPKI转让，而不会对资源的运营使用产生不利影响。
The following RPKI objects would be created/revoked:
将创建/撤销以下RPKI对象：
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
For Org B, add the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
For Org B, add the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A holds the resource 10.1.0.0/16, and it is currently in use and originated from AS 64496 with valid RPKI objects in place. Org A has agreed to transfer the entire /16 address block to Org B and will no longer originate the prefix or more specifics of it. Consequently, Org B desires an RPKI transfer of this resource on a particular date and time. This prefix will be originated by AS 64511 as a result of this transfer.
OrgA保存着资源10.1.0.0/16，它目前正在使用中，并且源于AS 64496，并具有有效的RPKI对象。组织A已同意将整个/16地址块转移到组织B，并且不再产生前缀或其更多细节。因此，组织B希望在特定日期和时间对该资源进行RPKI传输。此前缀将由AS 64511作为此传输的结果而产生。
The following RPKI objects would be created/revoked:
将创建/撤销以下RPKI对象：
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B, add the following ROA when the resource certificate for 10.1.0.0/16 is issued to them (Org B):
对于组织B，在向其颁发10.1.0.0/16的资源证书（组织B）时添加以下ROA：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
Org A holds the resources 10.1.0.0/16 and AS 64507 (with RPKI objects). Org A currently announces 10.1.0.0/16 from AS 64507. Org B has acquired an unused portion (10.1.4.0/24) of the prefix from Org A and desires an RPKI transfer on a particular date and time. Org B will originate a route 10.1.4.0/24 from AS 64496.
ORGA保存资源10.1.0.0/16和AS 64507（带有RPKI对象）。OrgA目前从AS 64507发布10.1.0.0/16。组织B已从组织A获得前缀的未使用部分（10.1.4.0/24），并希望在特定日期和时间进行RPKI传输。组织B将从AS 64496发起路线10.1.4.0/24。
The following RPKI objects would be created/sustained:
将创建/维持以下RPKI对象：
For Org A, leave the following ROA unchanged:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64507 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org A, leave the following ROA unchanged:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64507 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B, add the following ROA when the resource certificate for 10.1.4.0/24 is issued to them (Org B):
对于组织B，在向其颁发10.1.4.0/24的资源证书（组织B）时，添加以下ROA：
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+
Org A may optionally provide ROA coverage for Org B by creating the following ROA preceding the RPKI transfer. The ROA itself is then naturally revoked when 10.1.4.0/24 is transferred to Org B's resource certificate.
组织A可以通过在RPKI转移之前创建以下ROA，选择性地为组织B提供ROA覆盖范围。当10.1.4.0/24传输到组织B的资源证书时，ROA本身自然被撤销。
Org A adds the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+
Org A adds the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+
These use cases try to systematically enumerate the situations a relying party may encounter while receiving a BGP update and making use of ROA information to interpret the validity of the prefix-origin information in the routes derived from the update. We enumerate the situations or scenarios and include a recommendation for the expected
这些用例试图系统地列举依赖方在接收BGP更新时可能遇到的情况，并利用ROA信息解释从更新派生的路由中前缀来源信息的有效性。我们列举了各种情况或场景，并为预期结果提供了建议
outcome of prefix-origin validation. For a description of prefix-origin validation algorithms, see [RFC6483] and [RFC6811]. We use the terms Valid, Invalid, and NotFound as defined in [RFC6811] and summarized earlier in Section 1.3. Also see [RFC6472] for a recommendation to deprecate AS_SETs in BGP updates. The use cases described here can be potentially used as test cases for testing and evaluation of prefix-origin validation in router implementations; see, for example, [BRITE].
前缀来源验证的结果。有关前缀来源验证算法的说明，请参阅[RFC6483]和[RFC6811]。我们使用[RFC6811]中定义的术语Valid、Invalid和NotFound，并在前面的第1.3节中进行了总结。另请参阅[RFC6472]以了解在BGP更新中弃用AS_集合的建议。这里描述的用例可以潜在地用作路由器实现中前缀源验证的测试和评估的测试用例；例如，见[BRITE]。
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
Route has {10.1.0.0/17, Origin = AS 64496}
Route has {10.1.0.0/17, Origin = AS 64496}
Recommended RPKI prefix-origin validation interpretation: Route is Valid.
建议RPKI前缀来源验证解释：路由有效。
Comment: The route prefix has a covering ROA prefix, and the route origin ASN matches the ROA ASN. This is a straightforward prefix-origin validation use case; it follows from the primary intention of creation of the ROA by a prefix holder.
注释：路由前缀具有覆盖ROA前缀，路由源ASN与ROA ASN匹配。这是一个简单的前缀源验证用例；它源于前缀持有人创建居留权的主要意图。
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
Route has {10.1.0.0/22, Origin = AS 64496}
Route has {10.1.0.0/22, Origin = AS 64496}
No other covering ROA
没有其他保障居留权
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
建议的RPKI前缀源验证解释：路由无效。
Comment: In this case, the maxLength specified in the ROA is exceeded by the route prefix.
注释：在这种情况下，路由前缀超出了ROA中指定的maxLength。
ROA: {10.1.0.0/16, maxLength = 24, AS 64496}
ROA: {10.1.0.0/16, maxLength = 24, AS 64496}
Route has {10.1.88.0/24, Origin = AS 64511}
Route has {10.1.88.0/24, Origin = AS 64511}
No other covering ROA
没有其他保障居留权
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
建议的RPKI前缀源验证解释：路由无效。
Comment: In this case, an AS other than the one specified in the ROA is originating the route. This may be a prefix or subprefix hijack situation.
注释：在这种情况下，ROA中指定的AS以外的AS发起路由。这可能是前缀或子前缀劫持情况。
ROA: {10.1.0.0/16, maxLength = 22, AS 64496}
ROA: {10.1.0.0/16, maxLength = 22, AS 64496}
Route has {10.1.88.0/24, Origin = AS 64511}
Route has {10.1.88.0/24, Origin = AS 64511}
No other covering ROA
没有其他保障居留权
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
建议的RPKI前缀源验证解释：路由无效。
Comment: In this case, the maxLength specified in the ROA is exceeded by the route prefix, and also an AS other than the one specified in the ROA is originating the route. This may be a subprefix hijack situation.
注释：在这种情况下，路由前缀超出了ROA中指定的maxLength，并且发起路由的AS不是ROA中指定的AS。这可能是一个次级劫持事件。
Route has {10.1.3.0/24, Origin = AS 64511}
Route has {10.1.3.0/24, Origin = AS 64511}
No covering ROA
无掩护居留权
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
建议的RPKI前缀源验证解释：未找到路由的验证状态。
Comment: In this case, there is no covering ROA for the route prefix. It could be a prefix or subprefix hijack situation, but this announcement does not contradict any existing ROA. During partial deployment, there would be some legitimate prefix-origin announcements for which ROAs may not have been issued yet.
备注：在这种情况下，路由前缀没有覆盖ROA。这可能是一个前缀或子前缀劫持情况，但这一宣布并不与任何现有的居留权相矛盾。在部分部署期间，可能会有一些合法的前缀来源公告，但这些公告可能尚未发布ROA。
ROA: {10.1.0.0/16, maxLength = 32, AS 0}
ROA: {10.1.0.0/16, maxLength = 32, AS 0}
Route has {10.1.5.0/24, Origin = AS 64511}
Route has {10.1.5.0/24, Origin = AS 64511}
Recommended RPKI prefix-origin validation interpretation: Route's validation status is Invalid.
建议的RPKI前缀源验证解释：路由的验证状态无效。
Comment: An AS 0 ROA implies by definition that the prefix listed in it and all of the more specifics of that prefix should not be used in a routing context [RFC6483] [AS0-PROC]. Also, please see related comments in Section 1.3.
注释：根据定义，AS 0 ROA意味着其中列出的前缀以及该前缀的所有更多细节不应在路由上下文[RFC6483][AS0-PROC]中使用。此外，请参见第1.3节中的相关评论。
7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set of More Specifics
7.1.7. 未找到覆盖ROA前缀，但存在一组更详细的覆盖ROA
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64496}
ROA: {10.1.128.0/18, maxLength = 20, AS 64496}
ROA: {10.1.128.0/18, maxLength = 20, AS 64496}
ROA: {10.1.192.0/18, maxLength = 20, AS 64496}
ROA: {10.1.192.0/18, maxLength = 20, AS 64496}
Route has {10.1.0.0/16, Origin = AS 64496}
Route has {10.1.0.0/16, Origin = AS 64496}
No covering ROA
无掩护居留权
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
建议的RPKI前缀源验证解释：未找到路由的验证状态。
Comment: In this case, the route prefix is an aggregate (/16), and it turns out that there exist ROAs for more specifics (/18s) that, if combined, can help support validation of the announced prefix-origin pair. But it is very hard in general to break up an announced prefix into constituent more specifics and check for ROA coverage for those more specifics, and hence this type of accommodation is not recommended.
注释：在这种情况下，路由前缀是一个聚合（/16），结果表明存在更多细节的ROA（/18s），如果组合起来，可以帮助支持对已宣布前缀源对的验证。但一般来说，很难将已公布的前缀分解为更具体的成分，并检查这些更具体的成分的居留权覆盖范围，因此不建议采用这种类型的住宿。
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
路由有{10.1.0.0/16，AS_SET[AS 64496，AS 64497，AS 64498，AS 64499]出现在AS_路径的最右侧位置}
No covering ROA
无掩护居留权
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
建议的RPKI前缀源验证解释：未找到路由的验证状态。
Comment: An extremely small percentage (~0.1%) of external BGP (eBGP) updates are seen to have an AS_SET in them; this is known as proxy aggregation. In this case, the route with the AS_SET does not conflict with any ROA (i.e., the route prefix has no covering ROA prefix). Therefore, the route gets NotFound validation status.
注释：极少数（约0.1%）的外部BGP（eBGP）更新被视为设置了AS_；这称为代理聚合。在这种情况下，具有AS_集的路由不会与任何ROA冲突（即，路由前缀没有覆盖ROA前缀）。因此，路由将获得NotFound验证状态。
7.1.9. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and AS Match
7.1.9. AS_集合（路由中）中的单例，覆盖ROA前缀，以及AS匹配
Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost position in the AS_PATH}
路由有{10.1.0.0/24，AS_SET[AS 64496]出现在AS_路径的最右边位置}
ROA: {10.1.0.0/22, maxLength = 24, AS 64496}
ROA: {10.1.0.0/22, maxLength = 24, AS 64496}
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
建议的RPKI前缀源验证解释：路由无效。
Comment: In the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). If the route contains an AS_SET and a covering ROA prefix exists for the route prefix, then the route should get an Invalid status. (Note: AS match or mismatch consideration does not apply.)
注释：根据[RFC6472]的精神，任何设置了AS_的路由都不应被视为有效（通过基于ROA的验证）。如果路由包含AS_集合，且路由前缀存在覆盖ROA前缀，则路由应获得无效状态。（注：匹配或不匹配考虑不适用。）
7.1.10. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and AS Mismatch
7.1.10. AS_集合（路由中）中的单例，覆盖ROA前缀，以及AS不匹配
Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost position in the AS_PATH}
路由有{10.1.0.0/24，AS_SET[AS 64496]出现在AS_路径的最右边位置}
ROA: {10.1.0.0/22, maxLength = 24, AS 64511}
ROA: {10.1.0.0/22, maxLength = 24, AS 64511}
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
建议的RPKI前缀源验证解释：路由无效。
Comment: If the route contains an AS_SET and a covering ROA prefix exists for the route prefix, then the route should get an Invalid status. (Note: AS match or mismatch consideration does not apply.)
注释：如果路由包含AS_集合，并且路由前缀存在覆盖ROA前缀，则路由应获得无效状态。（注：匹配或不匹配考虑不适用。）
Route has {10.1.0.0/22, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
路由的{10.1.0.0/22，AS_SET[AS 64496，AS 64497，AS 64498，AS 64499]出现在AS_路径的最右侧位置}
ROA: {10.1.0.0/22, maxLength = 24, AS 64509}
ROA: {10.1.0.0/22, maxLength = 24, AS 64509}
No other covering ROA
没有其他保障居留权
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
建议的RPKI前缀源验证解释：路由无效。
Comment: If the route contains an AS_SET and a covering ROA prefix exists for the route prefix, then the route should get an Invalid status.
注释：如果路由包含AS_集合，并且路由前缀存在覆盖ROA前缀，则路由应获得无效状态。
7.1.12. Multiple ASs in AS_SET (in the Route) and ROAs Exist for a Covering Set of More Specifics
7.1.12. 在AS_集合（路线中）中存在多个ASs和ROA，以覆盖更多细节
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64497}
ROA: {10.1.64.0/18, maxLength = 20, AS 64497}
ROA: {10.1.128.0/18, maxLength = 20, AS 64498}
ROA: {10.1.128.0/18, maxLength = 20, AS 64498}
ROA: {10.1.192.0/18, maxLength = 20, AS 64499}
ROA: {10.1.192.0/18, maxLength = 20, AS 64499}
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
路由有{10.1.0.0/16，AS_SET[AS 64496，AS 64497，AS 64498，AS 64499]出现在AS_路径的最右侧位置}
No covering ROA
无掩护居留权
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
建议的RPKI前缀源验证解释：未找到路由的验证状态。
Comment: In this case, the aggregate of the prefixes in the ROAs is a covering prefix (i.e., exact match or less specific) relative to the route prefix. The ASs in each of the contributing ROAs together form a set that matches the AS_SET in the route. But it is very hard in general to break up an announced prefix into constituent more specifics and check for ROA coverage for those more specifics. In any case, it may be noted once again that in the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). In fact, the route under consideration would have received an Invalid status if the route prefix had at least one covering ROA prefix.
注释：在这种情况下，ROA中前缀的聚合是相对于路由前缀的覆盖前缀（即，精确匹配或不太具体）。每个参与ROA中的ASs一起形成一个集合，该集合与路由中的AS_集合相匹配。但一般来说，很难将公布的前缀分解为更多细节，并检查这些细节的居留权覆盖范围。在任何情况下，可以再次指出，根据[RFC6472]的精神，任何设置了AS_的路由都不应被视为有效（通过基于ROA的验证）。事实上，如果路由前缀至少有一个覆盖ROA前缀，则考虑中的路由将收到无效状态。
Here we enumerate use cases corresponding to router actions when RPKI objects expire or are revoked. In the cases that follow, the terms "expired ROA" or "revoked ROA" are shorthand and describe the expiry or revocation of the End Entity (EE) or resource certificate that causes a relying party to consider the corresponding ROA to have expired or been revoked, respectively.
这里我们列举了当RPKI对象过期或被撤销时与路由器操作相对应的用例。在随后的情况下，术语“过期的ROA”或“撤销的ROA”是速记，并描述终止实体或EE证书的到期或撤销，这使得依赖方考虑相应的ROA已经过期或被撤销。
A certificate revocation list (CRL) is received that reveals that the ROA {10.1.0.0/22, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. In the absence of said revoked ROA, no covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24).
接收到一个证书撤销列表（CRL），该列表显示ROA{10.1.0.0/22，maxLength=24，ASN 64496}被撤销。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。在没有所述撤销的ROA的情况下，路由前缀（即10.1.3.0/24）不存在覆盖ROA前缀。
The Relying Party interpretation would be: Route's validation status is NotFound.
依赖方的解释是：未找到路由的验证状态。
7.2.2. ROA of Prefix Revoked while Parent Prefix Has Covering ROA Prefix with Different ASN
7.2.2. 撤销前缀的ROA，而父前缀具有不同ASN的覆盖ROA前缀
A CRL is received that reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64511}. No other covering ROA exists for the 10.1.3.0/24 prefix.
接收到一个CRL，表明ROA{10.1.3.0/24，maxLength=24，ASN 64496}被撤销。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。此外，对于父前缀10.1.0.0/22存在有效的ROA，并且所述ROA是{10.1.0.0/22，maxLength=24，ASN 64511}。10.1.3.0/24前缀不存在其他覆盖ROA。
The Relying Party interpretation would be: Route is Invalid.
依赖方的解释是：路线无效。
A CRL is received that reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
接收到一个CRL，表明ROA{10.1.3.0/24，maxLength=24，ASN 64496}被撤销。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。此外，对于父前缀10.1.0.0/22存在有效的ROA，并且所述ROA是{10.1.0.0/22，maxLength=24，ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
依赖方的解释是：路线有效。
(Clarification: Perhaps the revocation of the ROA for prefix 10.1.3.0/24 was initiated just to eliminate redundancy.)
（澄清：撤销前缀10.1.3.0/24的居留权可能只是为了消除冗余。）
7.2.4. ROA of Grandparent Prefix Revoked while That of Parent Prefix Prevails
7.2.4. 撤销祖父母前缀的居留权，以父母前缀的居留权为准
A CRL is received that reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
接收到一个CRL，该CRL显示ROA{10.1.0.0/20，maxLength=24，ASN 64496}被撤销。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。此外，对于父前缀10.1.0.0/22存在有效的ROA，并且所述ROA是{10.1.0.0/22，maxLength=24，ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
依赖方的解释是：路线有效。
(Clarification: The ROA for less specific grandparent prefix 10.1.0.0/20 was revoked or withdrawn.)
（澄清：不太具体的祖父母前缀10.1.0.0/20的居留权被撤销或撤销。）
A scan of the ROA list reveals that the ROA {10.1.0.0/22, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. In the absence of said expired ROA, no covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24).
扫描ROA列表显示ROA{10.1.0.0/22，maxLength=24，ASN 64496}已过期。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。在没有所述过期ROA的情况下，路由前缀（即10.1.3.0/24）不存在覆盖ROA前缀。
The Relying Party interpretation would be: Route's validation status is NotFound.
依赖方的解释是：未找到路由的验证状态。
7.2.6. Expiry of ROA of Prefix while Parent Prefix Has Covering ROA with Different ASN
7.2.6. 前缀的ROA到期，而父前缀具有不同ASN的覆盖ROA
A scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64511}. No other covering ROA exists for the prefix (i.e., 10.1.3.0/24).
扫描ROA列表显示ROA{10.1.3.0/24，maxLength=24，ASN 64496}已过期。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。此外，对于父前缀10.1.0.0/22存在有效的ROA，并且所述ROA是{10.1.0.0/22，maxLength=24，ASN 64511}。前缀不存在其他覆盖ROA（即10.1.3.0/24）。
The Relying Party interpretation would be: Route is Invalid.
依赖方的解释是：路线无效。
A scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
扫描ROA列表显示ROA{10.1.3.0/24，maxLength=24，ASN 64496}已过期。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。此外，对于父前缀10.1.0.0/22存在有效的ROA，并且所述ROA是{10.1.0.0/22，maxLength=24，ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
依赖方的解释是：路线有效。
7.2.8. Expiry of ROA of Grandparent Prefix while That of Parent Prefix Prevails
7.2.8. 祖父母前缀的居留权到期，而父母前缀的居留权到期
A scan of the ROA list reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
扫描ROA列表显示ROA{10.1.0.0/20，maxLength=24，ASN 64496}已过期。此外，在源自ASN 64496的10.1.3.0/24的互联网路由系统中存在路由。此外，对于父前缀10.1.0.0/22存在有效的ROA，并且所述ROA是{10.1.0.0/22，maxLength=24，ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
依赖方的解释是：路线有效。
The authors are indebted to both Sandy Murphy and Sam Weiler for their guidance. Further, the authors would like to thank Steve Kent, Warren Kumari, Randy Bush, Curtis Villamizar, and Danny McPherson for their technical insight and review. The authors also wish to thank Elwyn Davies, Stephen Farrell, Barry Leiba, Stewart Bryant, Alexey Melnikov, and Russ Housley for their review and comments during the IESG review process.
作者感谢桑迪·墨菲和萨姆·韦勒的指导。此外，作者还要感谢Steve Kent、Warren Kumari、Randy Bush、Curtis Villamizar和Danny McPherson的技术见解和评论。作者还要感谢Elwyn Davies、Stephen Farrell、Barry Leiba、Stewart Bryant、Alexey Melnikov和Russ Housley在IESG审查过程中的审查和评论。
This memo requires no security considerations.
这份备忘录不需要考虑安全问题。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的配置文件”，RFC 64822012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，2012年2月。
[AS0-PROC] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 processing", Work in Progress, August 2012.
[AS0-PROC]Kumari，W.，Bush，R.，Schiller，H.，和K.Patel，“AS 0处理的编目”，正在进行的工作，2012年8月。
[BRITE] NIST, "BRITE - BGPSEC / RPKI Interoperability Test & Evaluation", Developed by the National Institute of Standards and Technology (NIST), Gaithersburg, Maryland, 2011, <http://brite.antd.nist.gov/statics/about>.
[BRITE]NIST，“BRITE-BGPSEC/RPKI互操作性测试与评估”，由国家标准与技术研究所（NIST）开发，马里兰州盖瑟斯堡，2011年<http://brite.antd.nist.gov/statics/about>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.
[RFC6472]Kumari，W.和K.Sriram，“在BGP中不使用AS_集和AS_CONFED_集的建议”，BCP 172，RFC 6472，2011年12月。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
[RFC6483]Huston，G.和G.Michaelson，“使用资源证书公钥基础设施（PKI）和路由起源授权（ROA）验证路由起源”，RFC 6483，2012年2月。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
[RFC6811]Mohapatra，P.，Scudder，J.，Ward，D.，Bush，R.，和R.Austein，“BGP前缀来源验证”，RFC 6811，2013年1月。
Authors' Addresses
作者地址
Terry Manderson ICANN
特里·曼德森
EMail: terry.manderson@icann.org
EMail: terry.manderson@icann.org
Kotikalapudi Sriram US NIST
美国国家标准与技术研究所
EMail: ksriram@nist.gov
EMail: ksriram@nist.gov
Russ White Verisign
罗斯怀特威瑞辛
EMail: russ@riw.us
EMail: russ@riw.us