Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 6810 Internet Initiative Japan
Category: Standards Track R. Austein
ISSN: 2070-1721 Dragon Research Labs
January 2013
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 6810 Internet Initiative Japan
Category: Standards Track R. Austein
ISSN: 2070-1721 Dragon Research Labs
January 2013
The Resource Public Key Infrastructure (RPKI) to Router Protocol
资源公钥基础设施（RPKI）到路由器协议
Abstract
摘要
In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers.
为了可验证地验证BGP公告的源自治系统，路由器需要一种简单但可靠的机制来从可信缓存接收资源公钥基础设施（RFC 6480）前缀源数据。本文档描述了一种将验证的前缀源数据传送到路由器的协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6810.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6810.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 4
4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 6
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . . 9
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Error Report . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 14
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 15
6.3. No Incremental Update Available . . . . . . . . . . . . . 15
6.4. Cache Has No Data Available . . . . . . . . . . . . . . . 16
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 19
7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 19
8. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . . 20
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 21
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 4
4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 6
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . . 9
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Error Report . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 14
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 15
6.3. No Incremental Update Available . . . . . . . . . . . . . 15
6.4. Cache Has No Data Available . . . . . . . . . . . . . . . 16
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 19
7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 19
8. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . . 20
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 21
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 26
In order to verifiably validate the origin Autonomous Systems (ASes) of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RPKI) [RFC6480] cryptographically validated prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The design is intentionally constrained to be usable on much of the current generation of ISP router platforms.
为了可验证地验证BGP公告的源自治系统（ASes），路由器需要一种简单但可靠的机制来从可信缓存接收资源公钥基础设施（RPKI）[RFC6480]加密验证的前缀源数据。本文档描述了一种将验证的前缀源数据传送到路由器的协议。该设计被有意限制为可用于当前大多数ISP路由器平台。
Section 3 describes the deployment structure, and Section 4 then presents an operational overview. The binary payloads of the protocol are formally described in Section 5, and the expected PDU sequences are described in Section 6. The transport protocol options are described in Section 7. Section 8 details how routers and caches are configured to connect and authenticate. Section 9 describes likely deployment scenarios. The traditional security and IANA considerations end the document.
第3节介绍了部署结构，第4节介绍了操作概述。第5节正式描述了协议的二进制有效载荷，第6节描述了预期的PDU序列。第7节介绍了传输协议选项。第8节详细介绍了如何配置路由器和缓存以进行连接和身份验证。第9节描述了可能的部署场景。传统的安全和IANA考虑结束了文档。
The protocol is extensible in order to support new PDUs with new semantics, if deployment experience indicates they are needed. PDUs are versioned should deployment experience call for change.
如果部署经验表明需要新的PDU，则该协议是可扩展的，以支持具有新语义的新PDU。如果部署经验需要更改，PDU将进行版本控制。
For an implementation (not interoperability) report, see [RTR-IMPL]
有关实现（非互操作性）报告，请参见[RTR-IMPL]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without special meaning.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”仅当出现在所有大写字母中时，才能按照RFC 2119[RFC2119]中的描述进行解释。它们也可能出现在小写或混用英语单词中，没有特殊意义。
The following terms are used with special meaning.
下列术语具有特殊含义。
Global RPKI: The authoritative data of the RPKI are published in a distributed set of servers at the IANA, Regional Internet Registries (RIRs), National Internet Registry (NIRs), and ISPs; see [RFC6481].
全球RPKI：RPKI的权威数据发布在IANA、区域互联网注册中心（RIR）、国家互联网注册中心（NIRs）和ISP的分布式服务器集中；见[RFC6481]。
Cache: A coalesced copy of the RPKI, which is periodically fetched/ refreshed directly or indirectly from the Global RPKI using the [RFC5781] protocol/tools. Relying party software is used to gather and validate the distributed data of the RPKI into a cache. Trusting this cache further is a matter between the provider of the cache and a relying party.
缓存：RPKI的合并副本，使用[RFC5781]协议/工具直接或间接地从全局RPKI定期获取/刷新。依赖方软件用于将RPKI的分布式数据收集并验证到缓存中。进一步信任此缓存是缓存提供者和依赖方之间的问题。
Serial Number: A 32-bit strictly increasing unsigned integer that wraps from 2^32-1 to 0. It denotes the logical version of a cache. A cache increments the value when it successfully updates its data from a parent cache or from primary RPKI data. As a cache is receiving, new incoming data and implicit deletes are associated with the new serial but MUST NOT be sent until the fetch is complete. A Serial Number is not commensurate between caches, nor need it be maintained across resets of the cache server. See [RFC1982] on DNS Serial Number Arithmetic for too much detail on the topic.
序列号：从2^32-1到0的32位严格递增的无符号整数。它表示缓存的逻辑版本。当缓存从父缓存或主RPKI数据成功更新其数据时，该值将递增。缓存接收时，新的传入数据和隐式删除与新的串行数据关联，但在提取完成之前不得发送。序列号在缓存之间不相称，也不需要在缓存服务器的重置过程中保持序列号。有关此主题的详细信息，请参阅DNS序列号算法[RFC1982]。
Session ID: When a cache server is started, it generates a session identifier to uniquely identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a failed session knowing that the Serial Number it is using is commensurate with that of the cache.
会话ID：启动缓存服务器时，它会生成一个会话标识符，以唯一标识缓存实例，并将其绑定到缓存实例将生成的序列号序列。这允许路由器在知道其使用的序列号与缓存的序列号相称的情况下重新启动失败的会话。
Deployment of the RPKI to reach routers has a three-level structure as follows:
将RPKI部署到reach路由器具有如下三级结构：
Global RPKI: The authoritative data of the RPKI are published in a distributed set of servers, RPKI publication repositories, e.g., the IANA, RIRs, NIRs, and ISPs, see [RFC6481].
全球RPKI：RPKI的权威数据发布在一组分布式服务器、RPKI发布库中，如IANA、RIRs、NIRs和ISP，请参见[RFC6481]。
Local Caches: A local set of one or more collected and verified caches. A relying party, e.g., router or other client, MUST have a trust relationship with, and a trusted transport channel to, any authoritative cache(s) it uses.
本地缓存：一个或多个收集和验证的缓存的本地集。依赖方（例如路由器或其他客户端）必须与它使用的任何权威缓存具有信任关系，并具有可信的传输通道。
Routers: A router fetches data from a local cache using the protocol described in this document. It is said to be a client of the cache. There MAY be mechanisms for the router to assure itself of the authenticity of the cache and to authenticate itself to the cache.
路由器：路由器使用本文档中描述的协议从本地缓存获取数据。据说它是缓存的客户端。路由器可能有机制来确保缓存的真实性，并向缓存验证自身。
A router establishes and keeps open a connection to one or more caches with which it has client/server relationships. It is configured with a semi-ordered list of caches, and establishes a connection to the most preferred cache, or set of caches, which accept the connections.
路由器建立并保持与一个或多个具有客户机/服务器关系的缓存的连接。它配置有一个半有序的缓存列表，并建立到最首选缓存或一组缓存的连接，这些缓存接受连接。
The router MUST choose the most preferred, by configuration, cache or set of caches so that the operator may control load on their caches and the Global RPKI.
路由器必须根据配置选择最首选的缓存或缓存集，以便操作员可以控制其缓存和全局RPKI的负载。
Periodically, the router sends to the cache the Serial Number of the highest numbered data it has received from that cache, i.e., the router's current Serial Number. When a router establishes a new connection to a cache, or wishes to reset a current relationship, it sends a Reset Query.
路由器定期向缓存发送从该缓存接收到的编号最高的数据的序列号，即路由器的当前序列号。当路由器建立到缓存的新连接，或希望重置当前关系时，它会发送重置查询。
The Cache responds with all data records that have Serial Numbers greater than that in the router's query. This may be the null set, in which case the End of Data PDU is still sent. Note that 'greater' must take wrap-around into account, see [RFC1982].
缓存使用序列号大于路由器查询中序列号的所有数据记录进行响应。这可能是空集，在这种情况下，仍然发送数据结束PDU。请注意，“更大”必须考虑环绕，请参见[RFC1982]。
When the router has received all data records from the cache, it sets its current Serial Number to that of the Serial Number in the End of Data PDU.
当路由器从缓存中接收到所有数据记录时，它将其当前序列号设置为数据PDU末尾的序列号。
When the cache updates its database, it sends a Notify message to every currently connected router. This is a hint that now would be a good time for the router to poll for an update, but is only a hint. The protocol requires the router to poll for updates periodically in any case.
当缓存更新其数据库时，它会向每个当前连接的路由器发送通知消息。这是一个提示，现在是路由器轮询更新的好时机，但这只是一个提示。协议要求路由器在任何情况下定期轮询更新。
Strictly speaking, a router could track a cache simply by asking for a complete data set every time it updates, but this would be very inefficient. The Serial Number based incremental update mechanism allows an efficient transfer of just the data records that have changed since last update. As with any update protocol based on incremental transfers, the router must be prepared to fall back to a full transfer if for any reason the cache is unable to provide the necessary incremental data. Unlike some incremental transfer protocols, this protocol requires the router to make an explicit request to start the fallback process; this is deliberate, as the cache has no way of knowing whether the router has also established sessions with other caches that may be able to provide better service.
严格地说，路由器只需在每次更新时请求一个完整的数据集就可以跟踪缓存，但这将是非常低效的。基于序列号的增量更新机制只允许有效传输自上次更新以来更改的数据记录。与任何基于增量传输的更新协议一样，如果缓存因任何原因无法提供必要的增量数据，路由器必须准备好退回到完全传输。与某些增量传输协议不同，该协议要求路由器发出显式请求以启动回退过程；这是故意的，因为缓存无法知道路由器是否也与其他缓存建立了会话，这些缓存可能能够提供更好的服务。
As a cache server must evaluate certificates and ROAs (Route Origin Attestations; see [RFC6480]), which are time dependent, servers' clocks MUST be correct to a tolerance of approximately an hour.
由于缓存服务器必须评估证书和ROA（路由来源证明；请参见[RFC6480]），它们与时间有关，因此服务器的时钟必须正确到大约一小时的容差。
The exchanges between the cache and the router are sequences of exchanges of the following PDUs according to the rules described in Section 6.
根据第6节中描述的规则，高速缓存和路由器之间的交换是以下PDU的交换序列。
Fields with unspecified content MUST be zero on transmission and MAY be ignored on receipt.
未指定内容的字段在传输时必须为零，在接收时可以忽略。
PDUs contain the following data elements:
PDU包含以下数据元素：
Protocol Version: An eight-bit unsigned integer, currently 0, denoting the version of this protocol.
协议版本：一个8位无符号整数，当前为0，表示此协议的版本。
PDU Type: An eight-bit unsigned integer, denoting the type of the PDU, e.g., IPv4 Prefix, etc.
PDU类型：一个8位无符号整数，表示PDU的类型，例如IPv4前缀等。
Serial Number: The Serial Number of the RPKI Cache when this set of PDUs was received from an upstream cache server or gathered from the Global RPKI. A cache increments its Serial Number when completing a rigorously validated update from a parent cache or the Global RPKI.
序列号：从上游缓存服务器接收此PDU集或从全局RPKI收集此PDU集时，RPKI缓存的序列号。从父缓存或全局RPKI完成严格验证的更新时，缓存会增加其序列号。
Session ID: When a cache server is started, it generates a Session ID to identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a failed session knowing that the Serial Number it is using is commensurate with that of the cache. If, at any time, either the router or the cache finds the value of the session identifier is not the same as the other's, they MUST completely drop the session and the router MUST flush all data learned from that cache.
会话ID：启动缓存服务器时，它会生成一个会话ID来标识缓存实例，并将其绑定到缓存实例将生成的序列号序列。这允许路由器在知道其使用的序列号与缓存的序列号相称的情况下重新启动失败的会话。如果在任何时候，路由器或缓存发现会话标识符的值与另一个不相同，则它们必须完全删除会话，并且路由器必须刷新从该缓存获取的所有数据。
Should a cache erroneously reuse a Session ID so that a router does not realize that the session has changed (old session ID and new session ID have same numeric value), the router may become confused as to the content of the cache. The time it takes the router to discover it is confused will depend on whether the Serial Numbers are also reused. If the Serial Numbers in the old and new sessions are different enough, the cache will respond to the router's Serial Query with a Cache Reset, which will solve the problem. If, however, the Serial Numbers are close, the cache may respond with a Cache Response, which may not be enough to bring the router into sync. In such cases, it's likely but not certain that the router will detect some discrepancy between the state that the cache expects and its own state. For example, the Cache
如果缓存错误地重用会话ID，以致路由器没有意识到会话已更改（旧会话ID和新会话ID具有相同的数值），路由器可能会对缓存的内容感到困惑。路由器发现混淆所需的时间将取决于序列号是否也被重用。如果新旧会话中的序列号差异很大，缓存将通过缓存重置响应路由器的串行查询，从而解决问题。但是，如果序列号接近，缓存可能会响应缓存响应，这可能不足以使路由器同步。在这种情况下，路由器很可能会检测到缓存期望的状态与其自身状态之间的差异，但这并不确定。例如，缓存
Response may tell the router to drop a record that the router does not hold, or may tell the router to add a record that the router already has. In such cases, a router will detect the error and reset the session. The one case in which the router may stay out of sync is when nothing in the Cache Response contradicts any data currently held by the router.
响应可能会告诉路由器删除路由器没有保存的记录，或者告诉路由器添加路由器已经拥有的记录。在这种情况下，路由器将检测到错误并重置会话。路由器可能保持不同步的一种情况是，缓存响应中的任何内容都与路由器当前持有的任何数据不一致。
Using persistent storage for the session identifier or a clock-based scheme for generating session identifiers should avoid the risk of session identifier collisions.
使用会话标识符的持久存储或基于时钟的方案来生成会话标识符应避免会话标识符冲突的风险。
The Session ID might be a pseudo-random value, a strictly increasing value if the cache has reliable storage, etc.
会话ID可能是一个伪随机值，如果缓存有可靠的存储，则它是一个严格递增的值，等等。
Length: A 32-bit unsigned integer that has as its value the count of the bytes in the entire PDU, including the eight bytes of header that end with the length field.
长度：一个32位无符号整数，其值为整个PDU中的字节数，包括以长度字段结尾的头的八个字节。
Flags: The lowest order bit of the Flags field is 1 for an announcement and 0 for a withdrawal, whether this PDU announces a new right to announce the prefix or withdraws a previously announced right. A withdraw effectively deletes one previously announced IPvX (IPv4 or IPv6) Prefix PDU with the exact same Prefix, Length, Max-Len, and Autonomous System Number (ASN).
标志：标志字段的最低顺序位为1表示宣布，0表示撤回，无论此PDU宣布新的权利以宣布前缀还是撤回以前宣布的权利。撤回有效地删除了一个先前宣布的IPvX（IPv4或IPv6）前缀PDU，其前缀、长度、最大长度和自主系统号（ASN）完全相同。
Prefix Length: An 8-bit unsigned integer denoting the shortest prefix allowed for the prefix.
前缀长度：8位无符号整数，表示前缀允许的最短前缀。
Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the prefix. This MUST NOT be less than the Prefix Length element.
最大长度：一个8位无符号整数，表示前缀允许的最长前缀。这不能小于前缀长度元素。
Prefix: The IPv4 or IPv6 prefix of the ROA.
前缀：ROA的IPv4或IPv6前缀。
Autonomous System Number: ASN allowed to announce this prefix, a 32-bit unsigned integer.
自治系统号：允许ASN宣布此前缀，一个32位无符号整数。
Zero: Fields shown as zero or reserved MUST be zero. The value of such a field MUST be ignored on receipt.
零：显示为零或保留的字段必须为零。接收时必须忽略此字段的值。
The cache notifies the router that the cache has new data.
缓存通知路由器缓存有新数据。
The Session ID reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not been changed.
会话ID向路由器保证序列号是相称的，即缓存会话没有更改。
Serial Notify is the only message that the cache can send that is not in response to a message from the router.
串行通知是缓存可以发送的唯一一条不响应路由器消息的消息。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
Serial Query: The router sends Serial Query to ask the cache for all payload PDUs that have Serial Numbers higher than the Serial Number in the Serial Query.
串行查询：路由器发送串行查询，以询问缓存中序列号高于串行查询中序列号的所有有效负载PDU。
The cache replies to this query with a Cache Response PDU (Section 5.5) if the cache has a, possibly null, record of the changes since the Serial Number specified by the router. If there have been no changes since the router last queried, the cache sends an End Of Data PDU.
如果缓存具有自路由器指定的序列号以来的更改记录（可能为空），缓存将使用缓存响应PDU（第5.5节）响应此查询。如果自上次查询路由器以来未发生任何更改，缓存将发送数据结束PDU。
If the cache does not have the data needed to update the router, perhaps because its records do not go back to the Serial Number in the Serial Query, then it responds with a Cache Reset PDU (Section 5.9).
如果缓存没有更新路由器所需的数据，可能是因为其记录没有返回到串行查询中的序列号，那么它会使用缓存重置PDU（第5.9节）进行响应。
The Session ID tells the cache what instance the router expects to ensure that the Serial Numbers are commensurate, i.e., the cache session has not been changed.
会话ID告诉缓存路由器希望哪个实例确保序列号相称，即缓存会话未更改。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
Reset Query: The router tells the cache that it wants to receive the total active, current, non-withdrawn database. The cache responds with a Cache Response PDU (Section 5.5).
重置查询：路由器告诉缓存它想要接收全部活动的、当前的、未撤消的数据库。缓存使用缓存响应PDU进行响应（第5.5节）。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
Cache Response: The cache responds with zero or more payload PDUs. When replying to a Serial Query request (Section 5.3), the cache sends the set of all data records it has with Serial Numbers greater than that sent by the client router. When replying to a Reset Query, the cache sends the set of all data records it has; in this case, the withdraw/announce field in the payload PDUs MUST have the value 1 (announce).
缓存响应：缓存使用零个或多个有效负载PDU进行响应。当响应串行查询请求（第5.3节）时，缓存发送其拥有的所有数据记录集，其序列号大于客户端路由器发送的序列号。当响应重置查询时，缓存发送其拥有的所有数据记录集；在这种情况下，有效负载PDU中的撤回/宣布字段必须具有值1（宣布）。
In response to a Reset Query, the new value of the Session ID tells the router the instance of the cache session for future confirmation. In response to a Serial Query, the Session ID being the same reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not changed.
作为对重置查询的响应，会话ID的新值告诉路由器缓存会话的实例，以供将来确认。作为对串行查询的响应，相同的会话ID向路由器保证序列号是相称的，即高速缓存会话没有改变。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 4 | |
+-------------------------------------------+
| |
| Length=20 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..32 | 0..32 | |
+-------------------------------------------+
| |
| IPv4 Prefix |
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 4 | |
+-------------------------------------------+
| |
| Length=20 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..32 | 0..32 | |
+-------------------------------------------+
| |
| IPv4 Prefix |
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
The lowest order bit of the Flags field is 1 for an announcement and 0 for a withdrawal.
标志字段的最低顺序位为1表示公告，0表示撤回。
In the RPKI, nothing prevents a signing certificate from issuing two identical ROAs. In this case, there would be no semantic difference between the objects, merely a process redundancy.
在RPKI中，没有任何东西可以阻止签名证书颁发两个相同的ROA。在这种情况下，对象之间没有语义差异，只是一个过程冗余。
In the RPKI, there is also an actual need for what might appear to a router as identical IPvX PDUs. This can occur when an upstream certificate is being reissued or there is an address ownership transfer up the validation chain. The ROA would be identical in the
在RPKI中，还需要一个路由器可能认为相同的IPvX PDU。当重新颁发上游证书或验证链上存在地址所有权转移时，可能会发生这种情况。在这方面，居留权是相同的
router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but a different validation path in the RPKI. This is important to the RPKI, but not to the router.
路由器感知，即，在RPKI中具有相同的{Prefix，Len，Max Len，ASN}，但验证路径不同。这对RPKI很重要，但对路由器不重要。
The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, ASN} at any one point in time. Should the router client receive an IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error.
缓存服务器必须确保它已通知路由器客户端在任何时间点为唯一的{Prefix，Len，Max Len，ASN}使用一个且仅一个IPvX PDU。如果路由器客户端接收到一个IPvX PDU，其{Prefix，Len，Max Len，ASN}与其已激活的IPvX PDU相同，则应发出重复的公告接收错误。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..128 | 0..128 | |
+-------------------------------------------+
| |
+--- ---+
| |
+--- IPv6 Prefix ---+
| |
+--- ---+
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..128 | 0..128 | |
+-------------------------------------------+
| |
+--- ---+
| |
+--- IPv6 Prefix ---+
| |
+--- ---+
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.
与IPv4前缀PDU类似，它多了96位，没有魔力。
End of Data: The cache tells the router it has no more data for the request.
数据结束：缓存告诉路由器它没有更多的请求数据。
The Session ID MUST be the same as that of the corresponding Cache Response that began the, possibly null, sequence of data PDUs.
会话ID必须与启动数据PDU序列（可能为空）的相应缓存响应的会话ID相同。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 7 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 7 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
The cache may respond to a Serial Query informing the router that the cache cannot provide an incremental update starting from the Serial Number specified by the router. The router must decide whether to issue a Reset Query or switch to a different cache.
高速缓存可以响应串行查询，通知路由器高速缓存不能提供从路由器指定的序列号开始的增量更新。路由器必须决定是发出重置查询还是切换到其他缓存。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
This PDU is used by either party to report an error to the other.
任何一方使用此PDU向另一方报告错误。
Error reports are only sent as responses to other PDUs.
错误报告仅作为响应发送给其他PDU。
The Error Code is described in Section 10.
第10节描述了错误代码。
If the error is generic (e.g., "Internal Error") and not associated with the PDU to which it is responding, the Erroneous PDU field MUST be empty and the Length of Encapsulated PDU field MUST be zero.
如果错误是一般性的（例如，“内部错误”），并且与它所响应的PDU不相关，则错误PDU字段必须为空，且封装PDU字段的长度必须为零。
An Error Report PDU MUST NOT be sent for an Error Report PDU. If an erroneous Error Report PDU is received, the session SHOULD be dropped.
不得为错误报告PDU发送错误报告PDU。如果收到错误的错误报告PDU，则应放弃会话。
If the error is associated with a PDU of excessive length, i.e., too long to be any legal PDU other than another Error Report, or a possibly corrupt length, the Erroneous PDU field MAY be truncated.
如果错误与长度过大的PDU相关，即长度太长而不是其他错误报告以外的任何合法PDU，或者可能是损坏的长度，则错误的PDU字段可能会被截断。
The diagnostic text is optional; if not present, the Length of Error Text field MUST be zero. If error text is present, it MUST be a string in UTF-8 encoding (see [RFC3269]).
诊断文本是可选的；如果不存在，则错误文本字段的长度必须为零。如果存在错误文本，则它必须是UTF-8编码的字符串（请参见[RFC3269]）。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 0 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Copy of Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 0 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Copy of Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
The sequences of PDU transmissions fall into three conversations as follows:
PDU传输序列分为以下三种对话：
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
When a transport session is first established, the router MAY send a Reset Query and the cache responds with a data sequence of all data it contains.
当第一次建立传输会话时，路由器可以发送重置查询，高速缓存以其包含的所有数据的数据序列作出响应。
Alternatively, if the router has significant unexpired data from a broken session with the same cache, it MAY start with a Serial Query containing the Session ID from the previous session to ensure the Serial Numbers are commensurate.
或者，如果路由器具有来自具有相同缓存的中断会话的大量未过期数据，则它可以从包含来自前一会话的会话ID的串行查询开始，以确保序列号是相称的。
This Reset Query sequence is also used when the router receives a Cache Reset, chooses a new cache, or fears that it has otherwise lost its way.
当路由器接收到缓存重置、选择新缓存或担心丢失路径时，也会使用此重置查询序列。
To limit the length of time a cache must keep the data necessary to generate incremental updates, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour. This also acts as a keep-alive at the application layer.
为了限制缓存必须保留生成增量更新所需数据的时间长度，路由器必须至少每小时发送一次串行查询或重置查询。这也在应用层起到了保持活动的作用。
As the cache MAY not keep updates for little more than one hour, the router MUST have a polling interval of no greater than once an hour.
由于缓存的更新时间可能不会超过一小时，路由器的轮询间隔必须不超过每小时一次。
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
The cache server SHOULD send a notify PDU with its current Serial Number when the cache's serial changes, with the expectation that the router MAY then issue a Serial Query earlier than it otherwise might. This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate limit Serial Notifies to no more frequently than one per minute.
当缓存的序列号发生变化时，缓存服务器应发送一个带有其当前序列号的通知PDU，并期望路由器随后可以比其他情况更早地发出串行查询。这类似于[RFC1996]中的DNS通知。缓存必须将串行通知的频率限制为每分钟不超过一次。
When the transport layer is up and either a timer has gone off in the router, or the cache has sent a Notify, the router queries for new data by sending a Serial Query, and the cache sends all data newer than the serial in the Serial Query.
当传输层启动且路由器中的计时器已关闭，或缓存已发送通知时，路由器通过发送串行查询查询新数据，缓存发送串行查询中比串行查询中的串行数据更新的所有数据。
To limit the length of time a cache must keep old withdraws, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour.
为了限制缓存必须保留旧取款的时间长度，路由器必须至少每小时发送一次串行查询或重置查询。
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ------- Cache Reset ------> | C cannot supply update
| | from specified serial
| <------ Reset Query ------- | R requests new data
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ------- Cache Reset ------> | C cannot supply update
| | from specified serial
| <------ Reset Query ------- | R requests new data
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
The cache may respond to a Serial Query with a Cache Reset, informing the router that the cache cannot supply an incremental update from the Serial Number specified by the router. This might be because the cache has lost state, or because the router has waited too long between polls and the cache has cleaned up old data that it no longer believes it needs, or because the cache has run out of storage space and had to expire some old data early. Regardless of how this state arose, the cache replies with a Cache Reset to tell the router that it cannot honor the request. When a router receives this, the router SHOULD attempt to connect to any more preferred caches in its cache list. If there are no more preferred caches, it MUST issue a Reset Query and get an entire new load from the cache.
高速缓存可通过高速缓存重置响应串行查询，通知路由器高速缓存无法从路由器指定的序列号提供增量更新。这可能是因为缓存已丢失状态，或者是因为路由器在轮询之间等待的时间太长，并且缓存已清除了它认为不再需要的旧数据，或者是因为缓存已耗尽存储空间，并且必须提前终止一些旧数据。不管这种状态是如何出现的，缓存都会以缓存重置的方式回复，告诉路由器它无法接受请求。当路由器收到此消息时，路由器应尝试连接到其缓存列表中的任何其他首选缓存。如果没有更多首选缓存，则必须发出重置查询并从缓存中获取整个新加载。
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
Cache Router
~ ~
| <----- Reset Query ------- | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
Cache Router
~ ~
| <----- Reset Query ------- | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
The cache may respond to either a Serial Query or a Reset Query informing the router that the cache cannot supply any update at all. The most likely cause is that the cache has lost state, perhaps due to a restart, and has not yet recovered. While it is possible that a cache might go into such a state without dropping any of its active sessions, a router is more likely to see this behavior when it initially connects and issues a Reset Query while the cache is still rebuilding its database.
缓存可以响应串行查询或重置查询，通知路由器缓存根本无法提供任何更新。最可能的原因是缓存已丢失状态（可能是由于重新启动），并且尚未恢复。虽然缓存可能会进入这种状态，而不会删除其任何活动会话，但路由器在缓存仍在重建其数据库时最初连接并发出重置查询时，更可能会看到这种行为。
When a router receives this kind of error, the router SHOULD attempt to connect to any other caches in its cache list, in preference order. If no other caches are available, the router MUST issue periodic Reset Queries until it gets a new usable load from the cache.
当路由器收到此类错误时，路由器应尝试按优先顺序连接到其缓存列表中的任何其他缓存。如果没有其他缓存可用，路由器必须定期发出重置查询，直到从缓存获得新的可用负载。
The transport-layer session between a router and a cache carries the binary PDUs in a persistent session.
路由器和缓存之间的传输层会话在持久会话中承载二进制PDU。
To prevent cache spoofing and DoS attacks by illegitimate routers, it is highly desirable that the router and the cache be authenticated to each other. Integrity protection for payloads is also desirable to protect against monkey-in-the-middle (MITM) attacks. Unfortunately, there is no protocol to do so on all currently used platforms. Therefore, as of the writing of this document, there is no mandatory-to-implement transport that provides authentication and integrity protection.
为了防止非法路由器的缓存欺骗和DoS攻击，非常希望路由器和缓存相互验证。有效负载的完整性保护也有助于防止中间猴子（MITM）攻击。不幸的是，在所有当前使用的平台上都没有这样做的协议。因此，在编写本文档时，没有强制要求实现提供身份验证和完整性保护的传输。
To reduce exposure to dropped but non-terminated sessions, both caches and routers SHOULD enable keep-alives when available in the chosen transport protocol.
为了减少对已丢弃但未终止会话的暴露，缓存和路由器应在所选传输协议中可用时启用keep alives。
It is expected that, when the TCP Authentication Option (TCP-AO) [RFC5925] is available on all platforms deployed by operators, it will become the mandatory-to-implement transport.
预计，当TCP认证选项（TCP-AO）[RFC5925]在运营商部署的所有平台上可用时，将强制实施传输。
Caches and routers MUST implement unprotected transport over TCP using a port, rpki-rtr (323); see Section 12. Operators SHOULD use procedural means, e.g., access control lists (ACLs), to reduce the exposure to authentication issues.
缓存和路由器必须使用端口rpki rtr（323）通过TCP实现无保护传输；见第12节。运营商应使用程序手段，例如访问控制列表（ACL），以减少认证问题的暴露。
Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec transport.
缓存和路由器应使用TCP-AO、SSHv2、TCP MD5或IPsec传输。
If unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network.
如果传输的是不受保护的TCP，则缓存和路由器必须位于同一个受信任和受控制的网络上。
If available to the operator, caches and routers MUST use one of the following more protected protocols.
如果操作员可用，缓存和路由器必须使用以下更受保护的协议之一。
Caches and routers SHOULD use TCP-AO transport [RFC5925] over the rpki-rtr port.
缓存和路由器应通过rpki rtr端口使用TCP-AO传输[RFC5925]。
Caches and routers MAY use SSHv2 transport [RFC4252] using a the normal SSH port. For an example, see Section 7.1.
缓存和路由器可以使用SSHv2传输[RFC4252]，并使用正常SSH端口。有关示例，请参见第7.1节。
Caches and routers MAY use TCP MD5 transport [RFC2385] using the rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO [RFC5925].
缓存和路由器可以使用rpki rtr端口使用TCP MD5传输[RFC2385]。请注意，TCP MD5已被TCP-AO[RFC5925]淘汰。
Caches and routers MAY use IPsec transport [RFC4301] using the rpki-rtr port.
缓存和路由器可以使用rpki rtr端口使用IPsec传输[RFC4301]。
Caches and routers MAY use TLS transport [RFC5246] using a port, rpki-rtr-tls (324); see Section 12.
缓存和路由器可以使用端口rpki rtr TLS（324）使用TLS传输[RFC5246]；见第12节。
To run over SSH, the client router first establishes an SSH transport connection using the SSHv2 transport protocol, and the client and server exchange keys for message integrity and encryption. The client then invokes the "ssh-userauth" service to authenticate the application, as described in the SSH authentication protocol [RFC4252]. Once the application has been successfully authenticated, the client invokes the "ssh-connection" service, also known as the SSH connection protocol.
要在SSH上运行，客户端路由器首先使用SSHv2传输协议建立SSH传输连接，客户端和服务器交换消息完整性和加密密钥。然后，客户端调用“ssh userauth”服务对应用程序进行身份验证，如ssh身份验证协议[RFC4252]中所述。一旦应用程序成功通过身份验证，客户端将调用“ssh连接”服务，也称为ssh连接协议。
After the ssh-connection service is established, the client opens a channel of type "session", which results in an SSH session.
建立ssh连接服务后，客户端将打开一个类型为“session”的通道，这将导致ssh会话。
Once the SSH session has been established, the application invokes the application transport as an SSH subsystem called "rpki-rtr". Subsystem support is a feature of SSH version 2 (SSHv2) and is not included in SSHv1. Running this protocol as an SSH subsystem avoids the need for the application to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up.
一旦建立了SSH会话，应用程序将调用应用程序传输作为名为“rpki rtr”的SSH子系统。子系统支持是SSH版本2（SSHv2）的一项功能，不包含在SSHv1中。将此协议作为SSH子系统运行可以避免应用程序需要识别shell提示或跳过无关信息，例如在shell启动时发送的系统消息。
It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means.
假定路由器和缓存通过某种合理安全的方式在带外交换密钥。
Cache servers supporting SSH transport MUST accept RSA and Digital Signature Algorithm (DSA) authentication and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) authentication. User authentication MUST be supported; host authentication MAY be supported. Implementations MAY support password authentication. Client routers SHOULD verify the public key of the cache to avoid monkey-in-the-middle attacks.
支持SSH传输的缓存服务器必须接受RSA和数字签名算法（DSA）身份验证，并且应该接受椭圆曲线数字签名算法（ECDSA）身份验证。必须支持用户身份验证；可能支持主机身份验证。实现可能支持密码身份验证。客户端路由器应验证缓存的公钥，以避免中间猴攻击。
Client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache in order to allow the cache to manage the load by rejecting connections from unauthorized routers. In principle, any type of certificate and certificate authority (CA) may be used; however, in general, cache operators will wish to create their own small-scale CA and issue certificates to each authorized router. This simplifies credential rollover; any unrevoked, unexpired certificate from the proper CA may be used.
使用TLS传输的客户端路由器必须提供客户端证书以向缓存进行身份验证，以便允许缓存通过拒绝来自未经授权路由器的连接来管理负载。原则上，可以使用任何类型的证书和证书颁发机构（CA）；不过，一般来说，缓存运营商希望创建自己的小型CA，并向每个授权路由器颁发证书。这简化了凭证滚动；可以使用来自适当CA的任何未撤销、未过期的证书。
Certificates used to authenticate client routers in this protocol MUST include a subjectAltName extension [RFC5280] containing one or more iPAddress identities; when authenticating the router's certificate, the cache MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match the connection.
用于验证此协议中客户端路由器的证书必须包括subjectAltName扩展[RFC5280]，其中包含一个或多个IP地址标识；在验证路由器的证书时，缓存必须根据这些IP地址标识检查TLS连接的IP地址，如果没有一个IP地址标识与连接匹配，则应拒绝连接。
Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid monkey-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:
路由器还必须使用[RFC6125]中描述的subjectAltName dNSName身份验证缓存的TLS服务器证书，以避免中间猴攻击。[RFC6125]中定义的规则和指南适用于此处，并考虑以下因素：
Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations that use TLS. Certification authorities that issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates.
在使用TLS的rpki rtr服务器和客户端实现中，需要支持DNS-ID标识符类型（即subjectAltName扩展名中的dNSName标识）。颁发rpki rtr服务器证书的证书颁发机构必须支持DNS-ID标识符类型，并且DNS-ID标识符类型必须存在于rpki rtr服务器证书中。
DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*".
rpki rtr服务器证书中的DNS名称不应包含通配符“*”。
rpki-rtr implementations that use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125].
使用TLS的rpki rtr实现不得使用CN-ID标识符；服务器证书的使用者名称中可能存在CN字段，但不得在[RFC6125]中描述的规则内用于身份验证。
The client router MUST set its "reference identifier" to the DNS name of the rpki-rtr cache.
客户端路由器必须将其“参考标识符”设置为rpki rtr缓存的DNS名称。
If TCP MD5 is used, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits.
如果使用TCP MD5，根据[RFC2385]第4.5节，实现必须支持至少80个可打印ASCII字节的密钥长度。实现还必须支持至少32个字符的十六进制序列，即128位。
Key rollover with TCP MD5 is problematic. Cache servers SHOULD support [RFC4808].
使用TCP MD5进行密钥翻转是有问题的。缓存服务器应支持[RFC4808]。
Implementations MUST support key lengths of at least 80 printable ASCII bytes. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. MAC (Message Authentication Code) lengths of at least 96 bits MUST be supported, per Section 5.1 of [RFC5925].
实现必须支持至少80个可打印ASCII字节的密钥长度。实现还必须支持至少32个字符的十六进制序列，即128位。根据[RFC5925]第5.1节，必须支持至少96位的MAC（消息认证码）长度。
The cryptographic algorithms and associated parameters described in [RFC5926] MUST be supported.
必须支持[RFC5926]中描述的加密算法和相关参数。
A cache has the public authentication data for each router it is configured to support.
缓存具有配置为支持的每个路由器的公共身份验证数据。
A router may be configured to peer with a selection of caches, and a cache may be configured to support a selection of routers. Each must have the name of, and authentication data for, each peer. In addition, in a router, this list has a non-unique preference value for each server. This preference merely denotes proximity, not trust, preferred belief, etc. The client router attempts to establish a session with each potential serving cache in preference order, and then starts to load data from the most preferred cache to which it can connect and authenticate. The router's list of caches has the following elements:
路由器可被配置为与缓存的选择对等，并且缓存可被配置为支持路由器的选择。每个节点必须具有每个对等节点的名称和身份验证数据。此外，在路由器中，此列表对每个服务器都有一个非唯一的首选项值。此首选项仅表示接近性，而不是信任、首选信念等。客户端路由器尝试按首选项顺序与每个潜在服务缓存建立会话，然后开始从其可以连接和验证的最首选缓存加载数据。路由器的缓存列表包含以下元素：
Preference: An unsigned integer denoting the router's preference to connect to that cache; the lower the value, the more preferred.
首选项：一个无符号整数，表示路由器连接到该缓存的首选项；值越低，首选项越多。
Name: The IP address or fully qualified domain name of the cache.
名称：缓存的IP地址或完全限定的域名。
Key: Any needed public key of the cache.
密钥：缓存所需的任何公钥。
MyKey: Any needed private key or certificate of this client.
MyKey：此客户端所需的任何私钥或证书。
Due to the distributed nature of the RPKI, caches simply cannot be rigorously synchronous. A client may hold data from multiple caches but MUST keep the data marked as to source, as later updates MUST affect the correct data.
由于RPKI的分布式特性，缓存不能严格同步。客户机可以保存来自多个缓存的数据，但必须将数据标记为源，因为以后的更新必须影响正确的数据。
Just as there may be more than one covering ROA from a single cache, there may be multiple covering ROAs from multiple caches. The results are as described in [RFC6811].
正如一个缓存可能有多个覆盖ROA一样，多个缓存也可能有多个覆盖ROA。结果如[RFC6811]所述。
If data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation.
如果保存了来自多个缓存的数据，则在执行验证时，实现不得区分数据源。
When a more preferred cache becomes available, if resources allow, it would be prudent for the client to start fetching from that cache.
如果资源允许，当一个更首选的缓存可用时，客户机开始从该缓存获取数据是明智的。
The client SHOULD attempt to maintain at least one set of data, regardless of whether it has chosen a different cache or established a new connection to the previous cache.
客户机应尝试维护至少一组数据，无论它选择了不同的缓存还是建立了到以前缓存的新连接。
A client MAY drop the data from a particular cache when it is fully in sync with one or more other caches.
当数据与一个或多个其他缓存完全同步时，客户端可能会从特定缓存中删除数据。
A client SHOULD delete the data from a cache when it has been unable to refresh from that cache for a configurable timer value. The default for that value is twice the polling period for that cache.
当客户端无法从缓存中刷新可配置的计时器值时，它应该从缓存中删除数据。该值的默认值是该缓存轮询周期的两倍。
If a client loses connectivity to a cache it is using, or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. Note that this may already be true at the point of connection loss if the client has connections to more than one cache.
如果客户端与正在使用的缓存失去连接，或者决定切换到新缓存，则应保留以前缓存中的数据，直到它拥有来自一个或多个其他缓存的完整数据集。请注意，如果客户端连接到多个缓存，则在连接丢失时可能已经是这样。
For illustration, we present three likely deployment scenarios.
为了进行说明，我们提供了三种可能的部署场景。
Small End Site: The small multihomed end site may wish to outsource the RPKI cache to one or more of their upstream ISPs. They would exchange authentication material with the ISP using some out-of-band mechanism, and their router(s) would connect to the cache(s) of one or more upstream ISPs. The ISPs would likely deploy caches intended for customer use separately from the caches with which their own BGP speakers peer.
小型终端站点：小型多主机终端站点可能希望将RPKI缓存外包给一个或多个上游ISP。他们将使用带外机制与ISP交换身份验证材料，并且他们的路由器将连接到一个或多个上游ISP的缓存。ISP可能会分别部署供客户使用的缓存，而不是与他们自己的BGP扬声器对等的缓存。
Large End Site: A larger multihomed end site might run one or more caches, arranging them in a hierarchy of client caches, each fetching from a serving cache that is closer to the Global RPKI. They might configure fall-back peerings to upstream ISP caches.
大型终端站点：大型多主机终端站点可能运行一个或多个缓存，将它们排列在客户端缓存的层次结构中，每个缓存都从更接近全局RPKI的服务缓存获取。他们可能会将回退对等配置到上游ISP缓存。
ISP Backbone: A large ISP would likely have one or more redundant caches in each major point of presence (PoP), and these caches would fetch from each other in an ISP-dependent topology so as not to place undue load on the Global RPKI.
ISP主干网：大型ISP可能在每个主要存在点（PoP）中有一个或多个冗余缓存，这些缓存将在依赖ISP的拓扑中相互提取，以避免对全局RPKI造成过度负载。
Experience with large DNS cache deployments has shown that complex topologies are ill-advised as it is easy to make errors in the graph, e.g., not maintain a loop-free condition.
大型DNS缓存部署的经验表明，复杂拓扑是不明智的，因为它很容易在图中出错，例如，无法保持无循环状态。
Of course, these are illustrations and there are other possible deployment strategies. It is expected that minimizing load on the Global RPKI servers will be a major consideration.
当然，这些都是说明，还有其他可能的部署策略。预计最大限度地减少全局RPKI服务器上的负载将是一个主要考虑因素。
To keep load on Global RPKI services from unnecessary peaks, it is recommended that primary caches that load from the distributed Global RPKI not do so all at the same times, e.g., on the hour. Choose a random time, perhaps the ISP's AS number modulo 60 and jitter the inter-fetch timing.
为了避免全局RPKI服务的负载出现不必要的峰值，建议从分布式全局RPKI加载的主缓存不要在同一时间（例如，在小时）加载。选择一个随机时间，可能是ISP的模数为60的数字，并抖动取间时间。
This section contains a preliminary list of error codes. The authors expect additions to the list this section during development of the initial implementations. There is an IANA registry where valid error codes are listed; see Section 12. Errors that are considered fatal SHOULD cause the session to be dropped.
本节包含错误代码的初步列表。作者希望在初始实现的开发过程中在本节中增加列表。有一个IANA注册表，其中列出了有效的错误代码；见第12节。被认为是致命的错误应导致会话被删除。
0: Corrupt Data (fatal): The receiver believes the received PDU to be corrupt in a manner not specified by other error codes.
0：损坏的数据（致命）：接收器认为收到的PDU以其他错误代码未指定的方式损坏。
1: Internal Error (fatal): The party reporting the error experienced some kind of internal error unrelated to protocol operation (ran out of memory, a coding assertion failed, et cetera).
1：内部错误（致命）：报告错误的一方遇到与协议操作无关的某种内部错误（内存不足、编码断言失败等）。
2: No Data Available: The cache believes itself to be in good working order, but is unable to answer either a Serial Query or a Reset Query because it has no useful data available at this time. This is likely to be a temporary error, and most likely indicates that the cache has not yet completed pulling down an initial current data set from the Global RPKI system after some kind of event that invalidated whatever data it might have previously held (reboot, network partition, et cetera).
2：无可用数据：缓存认为自己处于良好的工作状态，但无法回答串行查询或重置查询，因为此时没有可用的有用数据。这很可能是一个临时错误，并且很可能表示缓存尚未完成从全局RPKI系统中提取初始当前数据集的操作，因为发生了某种事件，使其先前保存的任何数据无效（重新启动、网络分区等）。
3: Invalid Request (fatal): The cache server believes the client's request to be invalid.
3：无效请求（致命）：缓存服务器认为客户端的请求无效。
4: Unsupported Protocol Version (fatal): The Protocol Version is not known by the receiver of the PDU.
4：不支持的协议版本（致命）：PDU的接收器不知道协议版本。
5: Unsupported PDU Type (fatal): The PDU Type is not known by the receiver of the PDU.
5：不支持的PDU类型（致命）：PDU的接收器不知道PDU类型。
6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 but a record for the {Prefix, Len, Max-Len, ASN} tuple does not exist in the receiver's database.
6:撤消未知记录（致命）：接收到的PDU具有标志=0，但接收方数据库中不存在{Prefix，Len，Max Len，ASN}元组的记录。
7: Duplicate Announcement Received (fatal): The received PDU has an identical {Prefix, Len, Max-Len, ASN} tuple as a PDU that is still active in the router.
7：接收到重复通知（致命）：接收到的PDU具有与路由器中仍处于活动状态的PDU相同的{Prefix，Len，Max Len，ASN}元组。
As this document describes a security protocol, many aspects of security interest are described in the relevant sections. This section points out issues that may not be obvious in other sections.
由于本文档描述了安全协议，因此在相关章节中描述了安全利益的许多方面。本节指出了在其他章节中可能不明显的问题。
Cache Validation: In order for a collection of caches as described in Section 9 to guarantee a consistent view, they need to be given consistent trust anchors to use in their internal validation process. Distribution of a consistent trust anchor is assumed to be out of band.
缓存验证：为了保证第9节中描述的缓存集合具有一致的视图，需要为它们提供一致的信任锚，以便在其内部验证过程中使用。假设一致信任锚的分布在带外。
Cache Peer Identification: The router initiates a transport session to a cache, which it identifies by either IP address or fully qualified domain name. Be aware that a DNS or address spoofing attack could make the correct cache unreachable. No session would be established, as the authorization keys would not match.
缓存对等标识：路由器启动到缓存的传输会话，通过IP地址或完全限定的域名进行标识。请注意，DNS或地址欺骗攻击可能使正确的缓存无法访问。不会建立会话，因为授权密钥不匹配。
Transport Security: The RPKI relies on object, not server or transport, trust. That is, the IANA root trust anchor is distributed to all caches through some out-of-band means, and can then be used by each cache to validate certificates and ROAs all the way down the tree. The inter-cache relationships are based on this object security model; hence, the inter-cache transport can be lightly protected.
传输安全性：RPKI依赖于对象信任，而不是服务器或传输信任。也就是说，IANA根信任锚点通过一些带外方式分布到所有缓存，然后每个缓存都可以使用IANA根信任锚点来验证证书和树下的ROA。缓存间关系基于此对象安全模型；因此，缓存间传输可以得到轻微的保护。
But, this protocol document assumes that the routers cannot do the validation cryptography. Hence, the last link, from cache to router, is secured by server authentication and transport-level security. This is dangerous, as server authentication and transport have very different threat models than object security.
但是，本协议文件假设路由器无法进行验证加密。因此，从缓存到路由器的最后一条链路是由服务器身份验证和传输级安全保护的。这是很危险的，因为服务器身份验证和传输与对象安全具有非常不同的威胁模型。
So, the strength of the trust relationship and the transport between the router(s) and the cache(s) are critical. You're betting your routing on this.
因此，信任关系的强度以及路由器和缓存之间的传输至关重要。你把你的路线押在这上面了。
While we cannot say the cache must be on the same LAN, if only due to the issue of an enterprise wanting to off-load the cache task to their upstream ISP(s), locality, trust, and control are very critical issues here. The cache(s) really SHOULD be as close, in the sense of controlled and protected (against DDoS, MITM) transport, to the router(s) as possible. It also SHOULD be topologically close so that a minimum of validated routing data are needed to bootstrap a router's access to a cache.
虽然我们不能说缓存必须在同一个LAN上，但如果只是由于企业希望将缓存任务卸载到其上游ISP的问题，那么本地性、信任和控制是非常关键的问题。从受控和受保护（防止DDoS、MITM）传输的角度来看，缓存应该尽可能靠近路由器。它还应该在拓扑上是封闭的，这样就需要最少的经过验证的路由数据来引导路由器对缓存的访问。
The identity of the cache server SHOULD be verified and authenticated by the router client, and vice versa, before any data are exchanged.
在交换任何数据之前，路由器客户端应验证和验证缓存服务器的身份，反之亦然。
Transports that cannot provide the necessary authentication and integrity (see Section 7) must rely on network design and operational controls to provide protection against spoofing/ corruption attacks. As pointed out in Section 7, TCP-AO is the long-term plan. Protocols that provide integrity and authenticity SHOULD be used, and if they cannot, i.e., TCP is used as the transport, the router and cache MUST be on the same trusted, controlled network.
无法提供必要的身份验证和完整性（见第7节）的传输必须依靠网络设计和操作控制来提供防欺骗/破坏攻击的保护。如第7节所述，TCP-AO是一项长期计划。应使用提供完整性和真实性的协议，如果不能，即使用TCP作为传输，则路由器和缓存必须位于同一受信任的受控网络上。
IANA has assigned 'well-known' TCP Port Numbers to the RPKI-Router Protocol for the following, see Section 7:
IANA已为RPKI路由器协议分配了“众所周知的”TCP端口号，具体如下，请参见第7节：
rpki-rtr rpki-rtr-tls
rpki rtr rpki rtr tls
IANA has created a registry for tuples of Protocol Version / PDU Type, each of which may range from 0 to 255. The name of the registry is "rpki-rtr-pdu". The policy for adding to the registry is RFC Required per [RFC5226], either Standards Track or Experimental. The initial entries are as follows:
IANA已经为协议版本/PDU类型的元组创建了一个注册表，每个元组的范围从0到255。注册表的名称为“rpki rtr pdu”。根据[RFC5226]，添加到注册表的策略是RFC要求，可以是标准轨道，也可以是实验性的。初始条目如下：
Protocol PDU
Version Type Description
-------- ---- ---------------
0 0 Serial Notify
0 1 Serial Query
0 2 Reset Query
0 3 Cache Response
0 4 IPv4 Prefix
0 6 IPv6 Prefix
0 7 End of Data
0 8 Cache Reset
0 10 Error Report
0 255 Reserved
Protocol PDU
Version Type Description
-------- ---- ---------------
0 0 Serial Notify
0 1 Serial Query
0 2 Reset Query
0 3 Cache Response
0 4 IPv4 Prefix
0 6 IPv6 Prefix
0 7 End of Data
0 8 Cache Reset
0 10 Error Report
0 255 Reserved
IANA has created a registry for Error Codes 0 to 255. The name of the registry is "rpki-rtr-error". The policy for adding to the registry is Expert Review per [RFC5226], where the responsible IESG Area Director should appoint the Expert Reviewer. The initial entries should be as follows:
IANA已为错误代码0到255创建了注册表。注册表名为“rpki rtr error”。根据[RFC5226]的规定，添加到登记册的政策是专家评审，负责的IESG区域总监应任命专家评审员。初始条目应如下所示：
Error
Code Description
----- ----------------
0 Corrupt Data
1 Internal Error
2 No Data Available
3 Invalid Request
4 Unsupported Protocol Version
5 Unsupported PDU Type
6 Withdrawal of Unknown Record
7 Duplicate Announcement Received
255 Reserved
Error
Code Description
----- ----------------
0 Corrupt Data
1 Internal Error
2 No Data Available
3 Invalid Request
4 Unsupported Protocol Version
5 Unsupported PDU Type
6 Withdrawal of Unknown Record
7 Duplicate Announcement Received
255 Reserved
IANA has added an SSH Connection Protocol Subsystem Name, as defined in [RFC4250], of 'rpki-rtr'.
IANA添加了一个SSH连接协议子系统名称，如[RFC4250]中所定义的“rpki rtr”。
The authors wish to thank Steve Bellovin, Rex Fernando, Paul Hoffman, Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Scudder, Ruediger Volk, and David Ward. Particular thanks go to Hannes Gredler for showing us the dangers of unnecessary fields.
作者希望感谢史蒂夫·贝洛文、雷克斯·费尔南多、保罗·霍夫曼、罗斯·霍斯利、普拉多什·莫哈帕特拉、凯尔·帕特尔、桑迪·墨菲、罗伯特·拉祖克、约翰·斯卡德尔、鲁迪格·沃尔克和大卫·沃德。特别感谢Hannes Gredler向我们展示了不必要领域的危险。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269]Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]Lehtinen，S.和C.Lonvick，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252]Ylonen，T.和C.Lonvick，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年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月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926]Lebovitz，G.和E.Rescorla，“TCP认证选项（TCP-AO）的加密算法”，RFC 5926，2010年6月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[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月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808]Bellovin，S.，“TCP-MD5的关键变化策略”，RFC 4808，2007年3月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781]Weiler，S.，Ward，D.，和R.Housley，“rsync URI方案”，RFC 57812010年2月。
[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月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 64812012年2月。
[RTR-IMPL] Bush, R., Austein, R., Patel, K., Gredler, H., and M. Waehlisch, "RPKI Router Implementation Report", Work in Progress, January 2012.
[RTR-IMPL]Bush，R.，Austein，R.，Patel，K.，Gredler，H.，和M.Waehlisch，“RPKI路由器实施报告”，正在进行的工作，2012年1月。
Authors' Addresses
作者地址
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 US
兰迪·布什互联网倡议日本5147水晶泉班布里奇岛，华盛顿98110美国
EMail: randy@psg.com
EMail: randy@psg.com
Rob Austein Dragon Research Labs
Rob Austein Dragon研究实验室
EMail: sra@hactrn.net
EMail: sra@hactrn.net