Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8210 Internet Initiative Japan
Updates: 6810 R. Austein
Category: Standards Track Dragon Research Labs
ISSN: 2070-1721 September 2017
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8210 Internet Initiative Japan
Updates: 6810 R. Austein
Category: Standards Track Dragon Research Labs
ISSN: 2070-1721 September 2017
The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
资源公钥基础设施（RPKI）到路由器协议，版本1
Abstract
摘要
In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.
为了可验证地验证BGP公告的源自治系统和自治系统路径，路由器需要一种简单但可靠的机制来从可信缓存接收资源公钥基础设施（RFC 6480）前缀源数据和路由器密钥。本文档描述了交付它们的协议。
This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.
本文档介绍RPKI路由器协议的版本1。RFC 6810描述了版本0。本文档更新了RFC 6810。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8210.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8210.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Changes from RFC 6810 . . . . . . . . . . . . . . . . . . 4
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 5
4. Operational Overview . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 7
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 7
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 14
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 15
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 16
5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16
5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17
6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 18
7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 20
8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 21
8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 21
8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 22
8.3. No Incremental Update Available . . . . . . . . . . . . . 23
8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 23
9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 25
9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 26
9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 26
9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 27
10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 27
11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 28
12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Changes from RFC 6810 . . . . . . . . . . . . . . . . . . 4
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 5
4. Operational Overview . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 7
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 7
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 14
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 15
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 16
5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16
5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17
6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 18
7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 20
8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 21
8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 21
8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 22
8.3. No Incremental Update Available . . . . . . . . . . . . . 23
8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 23
9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 25
9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 26
9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 26
9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 27
10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 27
11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 28
12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
In order to verifiably validate the origin Autonomous Systems (ASes) and AS paths of BGP announcements, routers need a simple but reliable mechanism to receive cryptographically validated Resource Public Key Infrastructure (RPKI) [RFC6480] prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. The design is intentionally constrained to be usable on much of the current generation of ISP router platforms.
为了以可验证的方式验证原始自治系统（ASes）和BGP公告的路径，路由器需要一种简单但可靠的机制来从可信缓存接收加密验证的资源公钥基础设施（RPKI）[RFC6480]前缀原始数据和路由器密钥。本文档描述了交付它们的协议。该设计被有意限制为可用于当前大多数ISP路由器平台。
This document updates [RFC6810].
本文件更新了[RFC6810]。
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 Protocol Data Unit (PDU) sequences are described in Section 8. The transport protocol options are described in Section 9. Section 10 details how routers and caches are configured to connect and authenticate. Section 11 describes likely deployment scenarios. The traditional security and IANA considerations end the document.
第3节介绍了部署结构，第4节介绍了操作概述。第5节正式描述了协议的二进制有效载荷，第8节描述了预期的协议数据单元（PDU）序列。第9节介绍了传输协议选项。第10节详细介绍了如何配置路由器和缓存以进行连接和身份验证。第11节描述了可能的部署场景。传统的安全和IANA考虑结束了文档。
The protocol is extensible in order to support new PDUs with new semantics, if deployment experience indicates that they are needed. PDUs are versioned should deployment experience call for change.
如果部署经验表明需要新的PDU，则该协议是可扩展的，以支持具有新语义的新PDU。如果部署经验需要更改，PDU将进行版本控制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This section summarizes the significant changes between [RFC6810] and the protocol described in this document.
本节总结了[RFC6810]与本文件所述协议之间的重大变化。
o New Router Key PDU type (Section 5.10) added.
o 增加了新的路由器密钥PDU类型（第5.10节）。
o Explicit timing parameters (Section 5.8, Section 6) added.
o 增加了明确的定时参数（第5.8节，第6节）。
o Protocol version number incremented from 0 (zero) to 1 (one).
o 协议版本号从0（零）增加到1（一）。
o Protocol version number negotiation (Section 7) added.
o 增加协议版本号协商（第7节）。
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 Registries (NIRs), and ISPs; see [RFC6481].
全球RPKI：RPKI的权威数据发布在IANA、区域互联网注册中心（RIR）、国家互联网注册中心（NIR）和ISP的分布式服务器集中；见[RFC6481]。
Cache: A cache is a coalesced copy of the published Global RPKI data, periodically fetched or refreshed, directly or indirectly, using the rsync protocol [RFC5781] or some successor. 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数据的合并副本，使用rsync协议[RFC5781]或某些后续协议直接或间接地定期获取或刷新。依赖方软件用于将RPKI的分布式数据收集并验证到缓存中。进一步信任此缓存是缓存提供者和依赖方之间的问题。
Serial Number: "Serial Number" is a 32-bit strictly increasing unsigned integer which 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. While a cache is receiving updates, 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 different caches or different protocol versions, 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.
序列号：“序列号”是一个32位严格递增的无符号整数，它从2^32-1包装为0。它表示缓存的逻辑版本。当缓存从父缓存或主RPKI数据成功更新其数据时，该值将递增。当缓存接收更新时，新的传入数据和隐式删除与新序列相关联，但在提取完成之前不得发送。序列号在不同缓存或不同协议版本之间不相称，也不需要在缓存服务器的重置过程中保持序列号。有关此主题的详细信息，请参阅DNS序列号算法[RFC1982]。
Session ID: When a cache server is started, it generates a Session ID 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：启动缓存服务器时，它会生成一个会话ID，以唯一标识缓存实例，并将其绑定到缓存实例将生成的序列号序列。这允许路由器在知道其使用的序列号与缓存的序列号相称的情况下重新启动失败的会话。
Payload PDU: A payload PDU is a protocol message which contains data for use by the router, as opposed to a PDU which conveys the control mechanisms of this protocol. Prefixes and Router Keys are examples of payload PDUs.
有效负载PDU：有效负载PDU是一种协议消息，它包含路由器使用的数据，而不是传递此协议控制机制的PDU。前缀和路由器密钥是有效负载PDU的示例。
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 at the IANA, RIRs, NIRs, and ISPs (see [RFC6481]).
全球RPKI：RPKI的权威数据发布在IANA、RIRs、NIRs和ISP的分布式服务器集中（见[RFC6481]）。
Local Caches: Local caches are a local set of one or more collected and verified caches of RPKI data. A Relying Party, e.g., router or other client, MUST have a trust relationship with, and a trusted transport channel to, any cache(s) it uses.
本地缓存：本地缓存是由一个或多个收集和验证的RPKI数据缓存组成的本地集。依赖方（例如路由器或其他客户端）必须与所使用的任何缓存建立信任关系，并具有可信的传输通道。
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 (see Section 9).
路由器：路由器使用本文档中描述的协议从本地缓存获取数据。据说它是缓存的客户端。路由器可能有机制来确保缓存的真实性，并向缓存验证自身（参见第9节）。
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 most recent Serial Number for which it has received data from that cache, i.e., the router's current Serial Number, in the form of a Serial Query. When a router establishes a new session with a cache or wishes to reset a current relationship, it sends a Reset Query.
路由器以串行查询的形式周期性地向缓存发送其已从该缓存接收数据的最新序列号，即路由器的当前序列号。当路由器使用缓存建立新会话或希望重置当前关系时，它会发送重置查询。
The cache responds to the Serial Query with all data changes which took place since the given Serial Number. This may be the null set, in which case the End of Data PDU (Section 5.8) is still sent. Note that the Serial Number comparison used to determine "since the given Serial Number" MUST take wrap-around into account; see [RFC1982].
缓存使用自给定序列号以来发生的所有数据更改响应串行查询。这可能是空集，在这种情况下，仍然发送数据结束PDU（第5.8节）。注意，用于确定“自给定序列号”的序列号比较必须考虑环绕；见[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 received End of Data PDU.
当路由器从缓存中接收到所有数据记录时，它将其当前序列号设置为数据PDU接收端的序列号。
When the cache updates its database, it sends a Notify PDU 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 it is only a hint. The protocol requires the router to poll for updates periodically in any case.
当缓存更新其数据库时，它会向每个当前连接的路由器发送一个Notify PDU。这是一个提示，现在是路由器轮询更新的好时机，但这只是一个提示。协议要求路由器在任何情况下定期轮询更新。
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 which have changed since the 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 Authorizations; 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 8.
根据第8节中描述的规则，高速缓存和路由器之间的交换是以下PDU的交换序列。
Reserved fields (marked "zero" in PDU diagrams) MUST be zero on transmission and MUST be ignored on receipt.
保留字段（在PDU图表中标记为“零”）在传输时必须为零，在接收时必须忽略。
PDUs contain the following data elements:
PDU包含以下数据元素：
Protocol Version: An 8-bit unsigned integer, currently 1, denoting the version of this protocol.
协议版本：一个8位无符号整数，当前为1，表示此协议的版本。
PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, e.g., IPv4 Prefix.
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: A 16-bit unsigned integer. 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 after the protocol version has been negotiated (Section 7), either the router or the cache finds that the value of the Session ID is not
会话ID：一个16位无符号整数。当启动缓存服务器时，它会生成一个会话ID来标识缓存实例，并将其绑定到缓存实例将生成的序列号序列。这允许路由器在知道其使用的序列号与缓存的序列号相称的情况下重新启动失败的会话。如果在协议版本协商后的任何时候（第7节），路由器或缓存发现会话ID的值不正确
the same as the other's, the party which detects the mismatch MUST immediately terminate the session with an Error Report PDU with code 0 ("Corrupt Data"), and the router MUST flush all data learned from that cache.
与另一方一样，检测到不匹配的一方必须立即终止会话，并使用代码为0的错误报告PDU（“损坏数据”），路由器必须刷新从该缓存中获取的所有数据。
Note that sessions are specific to a particular protocol version. That is, if a cache server supports multiple versions of this protocol, happens to use the same Session ID value for multiple protocol versions, and further happens to use the same Serial Number values for two or more sessions using the same Session ID but different Protocol Version values, the Serial Numbers are not commensurate. The full test for whether Serial Numbers are commensurate requires comparing Protocol Version, Session ID, and Serial Number. To reduce the risk of confusion, cache servers SHOULD NOT use the same Session ID across multiple protocol versions, but even if they do, routers MUST treat sessions with different Protocol Version fields as separate sessions even if they do happen to have the same Session ID.
请注意，会话特定于特定的协议版本。也就是说，如果缓存服务器支持此协议的多个版本，恰好对多个协议版本使用相同的会话ID值，并且恰好对使用相同会话ID但不同协议版本值的两个或多个会话使用相同的序列号值，则序列号是不相称的。序列号是否相称的完整测试需要比较协议版本、会话ID和序列号。为了减少混淆的风险，缓存服务器不应在多个协议版本中使用相同的会话ID，但即使它们使用相同的会话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 the same numeric value), the router may become confused as to the content of the cache. The time it takes the router to discover that 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 Response may tell the router to drop a record which the router does not hold or may tell the router to add a record which 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.
如果缓存错误地重用会话ID，以致路由器没有意识到会话已更改（旧会话ID和新会话ID具有相同的数值），路由器可能会对缓存的内容感到困惑。路由器发现混淆的时间取决于序列号是否也被重用。如果新旧会话中的序列号差异很大，缓存将通过缓存重置响应路由器的串行查询，从而解决问题。但是，如果序列号接近，缓存可能会响应缓存响应，这可能不足以使路由器同步。在这种情况下，路由器很可能会检测到缓存期望的状态与其自身状态之间的差异，但这并不确定。例如，高速缓存响应可以告诉路由器丢弃路由器不持有的记录，或者可以告诉路由器添加路由器已经拥有的记录。在这种情况下，路由器将检测到错误并重置会话。路由器可能保持不同步的一种情况是，缓存响应中的任何内容都与路由器当前持有的任何数据不一致。
Using persistent storage for the Session ID or a clock-based scheme for generating Session IDs should avoid the risk of Session ID collisions.
使用会话ID的持久存储或基于时钟的方案生成会话ID应该避免会话ID冲突的风险。
The Session ID might be a pseudorandom value, a strictly increasing value if the cache has reliable storage, et cetera. A seconds-since-epoch timestamp value such as the POSIX time() function makes a good Session ID value.
会话ID可能是一个伪随机值，如果缓存具有可靠的存储，则该值将严格递增，等等。自epoch起的秒时间戳值（如POSIX time（）函数）是一个良好的会话ID值。
Length: A 32-bit unsigned integer which has as its value the count of the bytes in the entire PDU, including the 8 bytes of header which includes the length field.
长度：一个32位无符号整数，其值为整个PDU中的字节数，包括包含长度字段的8字节头。
Flags: The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or IPv6), the flag indicates whether this PDU announces a new right to announce the prefix or withdraws a previously announced right; a withdraw effectively deletes one previously announced Prefix PDU with the exact same Prefix, Length, Max-Len, and Autonomous System Number (ASN). Similarly, for a Router Key PDU, the flag indicates whether this PDU announces a new Router Key or deletes one previously announced Router Key PDU with the exact same AS Number, subjectKeyIdentifier, and subjectPublicKeyInfo.
标志：标志字段的最低顺序位为1表示公告，0表示撤回。对于前缀PDU（IPv4或IPv6），该标志指示该PDU是宣布新的前缀权利还是撤销先前宣布的权利；撤回有效地删除了一个先前公布的前缀PDU，该前缀具有完全相同的前缀、长度、最大长度和自治系统编号（ASN）。类似地，对于路由器密钥PDU，该标志指示该PDU是宣布一个新的路由器密钥，还是删除一个先前宣布的与Number、subjectKeyIdentifier和subjectPublicKeyInfo完全相同的路由器密钥PDU。
The remaining bits in the Flags field are reserved for future use. In protocol version 1, they MUST be zero on transmission and MUST be ignored on receipt.
标志字段中的剩余位保留供将来使用。在协议版本1中，它们在传输时必须为零，在接收时必须忽略。
Prefix Length: An 8-bit unsigned integer denoting the shortest prefix allowed by the Prefix element.
前缀长度：8位无符号整数，表示前缀元素允许的最短前缀。
Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. This MUST NOT be less than the Prefix Length element.
最大长度：一个8位无符号整数，表示prefix元素允许的最长前缀。这不能小于前缀长度元素。
Prefix: The IPv4 or IPv6 prefix of the ROA.
前缀：ROA的IPv4或IPv6前缀。
Autonomous System Number: A 32-bit unsigned integer representing an ASN allowed to announce a prefix or associated with a router key.
自治系统号：一个32位无符号整数，表示允许宣布前缀或与路由器密钥关联的ASN。
Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value of a router key, as described in [RFC6487].
主题密钥标识符：路由器密钥的20个八位组主题密钥标识符（SKI）值，如[RFC6487]所述。
Subject Public Key Info: A router key's subjectPublicKeyInfo value, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
Subject公钥信息：路由器密钥的subjectPublicKeyInfo值，如[RFC8208]中所述。这是subjectPublicKeyInfo的完整ASN.1顺序编码，包括subjectPublicKeyInfo序列的ASN.1标记和长度值。
Refresh Interval: Interval between normal cache polls. See Section 6.
刷新间隔：正常缓存轮询之间的间隔。见第6节。
Retry Interval: Interval between cache poll retries after a failed cache poll. See Section 6.
重试间隔：缓存轮询失败后，缓存轮询重试之间的间隔。见第6节。
Expire Interval: Interval during which data fetched from a cache remains valid in the absence of a successful subsequent cache poll. See Section 6.
Expire Interval：在没有成功的后续缓存轮询的情况下，从缓存获取的数据保持有效的时间间隔。见第6节。
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向路由器保证序列号是相称的，即缓存会话没有更改。
Upon receipt of a Serial Notify PDU, the router MAY issue an immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) without waiting for the Refresh Interval timer (see Section 6) to expire.
收到串行通知PDU后，路由器可立即发出串行查询（第5.3节）或重置查询（第5.4节），而无需等待刷新间隔计时器（见第6节）过期。
Serial Notify is the only message that the cache can send that is not in response to a message from the router.
串行通知是缓存可以发送的唯一一条不响应路由器消息的消息。
If the router receives a Serial Notify PDU during the initial startup period where the router and cache are still negotiating to agree on a protocol version, the router MUST simply ignore the Serial Notify PDU, even if the Serial Notify PDU is for an unexpected protocol version. See Section 7 for details.
如果路由器在初始启动期间收到串行通知PDU，其中路由器和缓存仍在协商协议版本，则路由器必须忽略串行通知PDU，即使串行通知PDU用于意外的协议版本。详见第7节。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
The router sends a Serial Query to ask the cache for all announcements and withdrawals which have occurred since the Serial Number specified in the Serial Query.
路由器发送一个串行查询，向缓存请求自串行查询中指定的序列号之后发生的所有通知和取款。
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, followed by zero or more payload PDUs and an End Of Data PDU (Section 5.8).
如果缓存具有自路由器指定的序列号以来的更改记录（可能为空），则缓存使用缓存响应PDU（第5.5节）响应此查询，然后是零个或多个有效负载PDU和数据结束PDU（第5.8节）。
When replying to a Serial Query, the cache MUST return the minimum set of changes needed to bring the router into sync with the cache. That is, if a particular prefix or router key underwent multiple changes between the Serial Number specified by the router and the cache's current Serial Number, the cache MUST merge those changes to present the simplest possible view of those changes to the router. In general, this means that, for any particular prefix or router key, the data stream will include at most one withdrawal followed by at most one announcement, and if all of the changes cancel out, the data stream will not mention the prefix or router key at all.
当响应串行查询时，缓存必须返回使路由器与缓存同步所需的最小更改集。也就是说，如果特定前缀或路由器密钥在路由器指定的序列号和缓存的当前序列号之间经历了多次更改，则缓存必须合并这些更改，以向路由器提供这些更改的最简单视图。通常，这意味着，对于任何特定前缀或路由器密钥，数据流将包括最多一次撤销，然后最多一次公告，并且如果所有更改都取消，则数据流将根本不提及前缀或路由器密钥。
The rationale for this approach is that the entire purpose of the RPKI-Router protocol is to offload work from the router to the cache, and it should therefore be the cache's job to simplify the change set, thus reducing work for the router.
这种方法的基本原理是，RPKI路由器协议的全部目的是将工作从路由器转移到缓存，因此，缓存的工作应该是简化更改集，从而减少路由器的工作。
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 |
| 1 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
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), followed by zero or more payload PDUs and an End of Data PDU (Section 5.8).
路由器告诉缓存它想要接收全部活动的、当前的、未撤消的数据库。缓存使用缓存响应PDU（第5.5节）进行响应，然后是零个或多个有效负载PDU和数据结束PDU（第5.8节）。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
The cache responds to queries with zero or more payload PDUs. When replying to a Serial Query (Section 5.3), the cache sends the set of announcements and withdrawals that have occurred since the Serial Number sent by the client router. When replying to a Reset Query (Section 5.4), 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节）时，缓存发送自客户端路由器发送序列号以来发生的一组通知和取款。当回复重置查询（第5.4节）时，缓存发送其拥有的所有数据记录集；在这种情况下，有效负载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 been changed.
作为对重置查询的响应，会话ID的新值告诉路由器缓存会话的实例，以供将来确认。作为对串行查询的响应，相同的会话ID向路由器保证序列号是相称的，即高速缓存会话没有改变。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 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 | zero |
| 1 | 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 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it would have a different validation path in the RPKI. This is important to the RPKI but not to the router.
在RPKI中，还需要一个路由器可能认为相同的IPvX PDU。当重新颁发上游证书或验证链上存在地址所有权转移时，可能会发生这种情况。ROA在路由器意义上是相同的，即具有相同的{Prefix，Len，Max Len，ASN}，但在RPKI中具有不同的验证路径。这对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 | zero |
| 1 | 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 | zero |
| 1 | 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位，没有魔力。
The cache tells the router it has no more data for the request.
缓存告诉路由器它没有更多的请求数据。
The Session ID and Protocol Version MUST be the same as that of the corresponding Cache Response which began the (possibly null) sequence of payload PDUs.
会话ID和协议版本必须与启动有效负载PDU序列（可能为空）的相应缓存响应的会话ID和协议版本相同。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 7 | |
+-------------------------------------------+
| |
| Length=24 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
+-------------------------------------------+
| |
| Refresh Interval |
| |
+-------------------------------------------+
| |
| Retry Interval |
| |
+-------------------------------------------+
| |
| Expire Interval |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 7 | |
+-------------------------------------------+
| |
| Length=24 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
+-------------------------------------------+
| |
| Refresh Interval |
| |
+-------------------------------------------+
| |
| Retry Interval |
| |
+-------------------------------------------+
| |
| Expire Interval |
| |
`-------------------------------------------'
The Refresh Interval, Retry Interval, and Expire Interval are all 32-bit elapsed times measured in seconds. They express the timing parameters which the cache expects the router to use in deciding when to send subsequent Serial Query or Reset Query PDUs to the cache. See Section 6 for an explanation of the use and the range of allowed values for these parameters.
刷新间隔、重试间隔和过期间隔都是以秒为单位的32位运行时间。它们表示缓存期望路由器在决定何时向缓存发送后续串行查询或重置查询PDU时使用的定时参数。有关这些参数的用途和允许值范围的说明，请参见第6节。
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 | zero |
| 1 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | | |
| Version | Type | Flags | zero |
| 1 | 9 | | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
+--- ---+
| Subject Key Identifier |
+--- ---+
| |
+--- ---+
| (20 octets) |
+--- ---+
| |
+-------------------------------------------+
| |
| AS Number |
| |
+-------------------------------------------+
| |
| Subject Public Key Info |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | | |
| Version | Type | Flags | zero |
| 1 | 9 | | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
+--- ---+
| Subject Key Identifier |
+--- ---+
| |
+--- ---+
| (20 octets) |
+--- ---+
| |
+-------------------------------------------+
| |
| AS Number |
| |
+-------------------------------------------+
| |
| Subject Public Key Info |
| |
`-------------------------------------------'
The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal.
标志字段的最低顺序位为1表示公告，0表示撤回。
The cache server MUST ensure that it has told the router client to have one and only one Router Key PDU for a unique {SKI, ASN, Subject Public Key} at any one point in time. Should the router client receive a Router Key PDU with a {SKI, ASN, Subject Public Key} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error.
缓存服务器必须确保它已通知路由器客户端在任何时间点为唯一的{SKI，ASN，Subject Public Key}拥有一个且仅一个路由器密钥PDU。如果路由器客户端接收到一个路由器密钥PDU，其{SKI，ASN，Subject Public Key}与其已激活的密钥相同，则它应引发一个重复的公告接收错误。
Note that a particular ASN may appear in multiple Router Key PDUs with different Subject Public Key values, while a particular Subject Public Key value may appear in multiple Router Key PDUs with different ASNs. In the interest of keeping the announcement and withdrawal semantics as simple as possible for the router, this protocol makes no attempt to compress either of these cases.
注意，特定ASN可能出现在具有不同主题公钥值的多个路由器密钥pdu中，而特定主题公钥值可能出现在具有不同ASN的多个路由器密钥pdu中。为了使路由器的公告和撤回语义尽可能简单，该协议不试图压缩这两种情况。
Also note that it is possible, albeit very unlikely, for multiple distinct Subject Public Key values to hash to the same SKI. For this reason, implementations MUST compare Subject Public Key values as well as SKIs when detecting duplicate PDUs.
还请注意，多个不同的主题公钥值散列到同一SKI是可能的，尽管可能性很小。因此，在检测重复的PDU时，实现必须比较主题公钥值以及SKI。
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, not to report errors in Error Report PDUs.
错误报告仅作为响应发送到其他PDU，而不是在错误报告PDU中报告错误。
Error codes are described in Section 12.
第12节描述了错误代码。
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 [RFC3629]).
诊断文本是可选的；如果不存在，则错误文本字段的长度必须为零。如果存在错误文本，则它必须是UTF-8编码的字符串（请参阅[RFC3629]）。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 1 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 1 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
Since the data the cache distributes via the RPKI-Router protocol are retrieved from the Global RPKI system at intervals which are only known to the cache, only the cache can really know how frequently it makes sense for the router to poll the cache, or how long the data are likely to remain valid (or, at least, unchanged). For this reason, as well as to allow the cache some control over the load placed on it by its client routers, the End Of Data PDU includes three values that allow the cache to communicate timing parameters to the router:
由于缓存通过RPKI路由器协议分发的数据以只有缓存知道的间隔从全局RPKI系统中检索，因此只有缓存才能真正知道路由器轮询缓存的频率，或者数据可能保持有效（或至少保持不变）的时间。出于这个原因，以及为了允许缓存对其客户端路由器施加在其上的负载进行某种控制，数据结束PDU包括三个值，这些值允许缓存将定时参数传送到路由器：
Refresh Interval: This parameter tells the router how long to wait before next attempting to poll the cache and between subsequent attempts, using a Serial Query or Reset Query PDU. The router SHOULD NOT poll the cache sooner than indicated by this parameter. Note that receipt of a Serial Notify PDU overrides this interval
刷新间隔：此参数告诉路由器在下一次尝试轮询缓存之前以及在后续尝试之间等待多长时间，使用串行查询或重置查询PDU。路由器轮询缓存的时间不应早于此参数指示的时间。请注意，收到串行通知PDU会覆盖此间隔
and suggests that the router issue an immediate query without waiting for the Refresh Interval to expire. Countdown for this timer starts upon receipt of the containing End Of Data PDU.
并建议路由器在不等待刷新间隔过期的情况下立即发出查询。此计时器的倒计时在接收到包含数据PDU结尾时开始。
Minimum allowed value: 1 second.
允许的最小值：1秒。
Maximum allowed value: 86400 seconds (1 day).
最大允许值：86400秒（1天）。
Recommended default: 3600 seconds (1 hour).
推荐默认值：3600秒（1小时）。
Retry Interval: This parameter tells the router how long to wait before retrying a failed Serial Query or Reset Query. The router SHOULD NOT retry sooner than indicated by this parameter. Note that a protocol version mismatch overrides this interval: if the router needs to downgrade to a lower protocol version number, it MAY send the first Serial Query or Reset Query immediately. Countdown for this timer starts upon failure of the query and restarts after each subsequent failure until a query succeeds.
重试间隔：此参数告诉路由器在重试失败的串行查询或重置查询之前要等待多长时间。路由器不应在该参数指示的时间之前重试。请注意，协议版本不匹配会覆盖此间隔：如果路由器需要降级到较低的协议版本号，它可能会立即发送第一个串行查询或重置查询。此计时器的倒计时在查询失败时开始，并在每次后续失败后重新启动，直到查询成功。
Minimum allowed value: 1 second.
允许的最小值：1秒。
Maximum allowed value: 7200 seconds (2 hours).
最大允许值：7200秒（2小时）。
Recommended default: 600 seconds (10 minutes).
推荐默认值：600秒（10分钟）。
Expire Interval: This parameter tells the router how long it can continue to use the current version of the data while unable to perform a successful subsequent query. The router MUST NOT retain the data past the time indicated by this parameter. Countdown for this timer starts upon receipt of the containing End Of Data PDU.
Expire Interval：此参数告诉路由器在无法执行成功的后续查询时，可以继续使用当前版本的数据多长时间。路由器不得保留超过此参数指示时间的数据。此计时器的倒计时在接收到包含数据PDU结尾时开始。
Minimum allowed value: 600 seconds (10 minutes).
最小允许值：600秒（10分钟）。
Maximum allowed value: 172800 seconds (2 days).
最大允许值：172800秒（2天）。
Recommended default: 7200 seconds (2 hours).
建议默认值：7200秒（2小时）。
If the router has never issued a successful query against a particular cache, it SHOULD retry periodically using the default Retry Interval, above.
如果路由器从未对特定缓存发出过成功的查询，它应该使用上面的默认重试间隔定期重试。
Caches MUST set Expire Interval to a value larger than either Refresh Interval or Retry Interval.
缓存必须将过期间隔设置为大于刷新间隔或重试间隔的值。
A router MUST start each transport connection by issuing either a Reset Query or a Serial Query. This query will tell the cache which version of this protocol the router implements.
路由器必须通过发出重置查询或串行查询来启动每个传输连接。此查询将告诉缓存路由器实现的协议版本。
If a cache which supports version 1 receives a query from a router which specifies version 0, the cache MUST downgrade to protocol version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection.
如果支持版本1的缓存从指定版本0的路由器接收到查询，则缓存必须降级到协议版本0[RFC6810]，或发送错误代码为4的版本1错误报告PDU（“不支持的协议版本”），并终止连接。
If a router which supports version 1 sends a query to a cache which only supports version 0, one of two things will happen:
如果支持版本1的路由器向仅支持版本0的缓存发送查询，则会发生以下两种情况之一：
1. The cache may terminate the connection, perhaps with a version 0 Error Report PDU. In this case, the router MAY retry the connection using protocol version 0.
1. 缓存可能会终止连接，可能会使用版本0错误报告PDU。在这种情况下，路由器可以使用协议版本0重试连接。
2. The cache may reply with a version 0 response. In this case, the router MUST either downgrade to version 0 or terminate the connection.
2. 缓存可能会以版本0响应进行回复。在这种情况下，路由器必须降级到版本0或终止连接。
In any of the downgraded combinations above, the new features of version 1 will not be available, and all PDUs will have 0 in their version fields.
在上述任何降级组合中，版本1的新功能将不可用，所有PDU的版本字段中都将有0。
If either party receives a PDU containing an unrecognized Protocol Version (neither 0 nor 1) during this negotiation, it MUST either downgrade to a known version or terminate the connection, with an Error Report PDU unless the received PDU is itself an Error Report PDU.
如果任何一方在此协商期间收到包含无法识别的协议版本（既不是0也不是1）的PDU，则必须降级到已知版本或终止连接，并提供错误报告PDU，除非收到的PDU本身是错误报告PDU。
The router MUST ignore any Serial Notify PDUs it might receive from the cache during this initial startup period, regardless of the Protocol Version field in the Serial Notify PDU. Since Session ID and Serial Number values are specific to a particular protocol version, the values in the notification are not useful to the router. Even if these values were meaningful, the only effect that processing the notification would have would be to trigger exactly the same Reset Query or Serial Query that the router has already sent as part of the not-yet-complete version negotiation process, so there is nothing to be gained by processing notifications until version negotiation completes.
无论串行通知PDU中的协议版本字段如何，路由器都必须忽略在此初始启动期间可能从缓存接收到的任何串行通知PDU。由于会话ID和序列号值特定于特定的协议版本，因此通知中的值对路由器没有用处。即使这些值是有意义的，处理通知的唯一效果将是触发路由器作为尚未完成的版本协商过程的一部分已经发送的完全相同的重置查询或串行查询，因此，在版本协商完成之前，处理通知不会带来任何好处。
Caches SHOULD NOT send Serial Notify PDUs before version negotiation completes. Routers, however, MUST handle such notifications (by ignoring them) for backwards compatibility with caches serving protocol version 0.
在版本协商完成之前，缓存不应发送串行通知PDU。但是，路由器必须处理此类通知（通过忽略它们），以便与服务于协议版本0的缓存向后兼容。
Once the cache and router have agreed upon a Protocol Version via the negotiation process above, that version is stable for the life of the session. See Section 5.1 for a discussion of the interaction between Protocol Version and Session ID.
一旦缓存和路由器通过上述协商过程商定了协议版本，该版本在会话生命周期内是稳定的。有关协议版本和会话ID之间交互的讨论，请参见第5.1节。
If either party receives a PDU for a different Protocol Version once the above negotiation completes, that party MUST drop the session; unless the PDU containing the unexpected Protocol Version was itself an Error Report PDU, the party dropping the session SHOULD send an Error Report with an error code of 8 ("Unexpected Protocol Version").
如果任一方在上述协商完成后收到不同协议版本的PDU，则该方必须放弃会话；除非包含意外协议版本的PDU本身是错误报告PDU，否则丢弃会话的一方应发送错误代码为8的错误报告（“意外协议版本”）。
The sequences of PDU transmissions fall into four conversations as follows:
PDU传输序列分为以下四个对话：
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key PDUs
| ------- End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
When a transport connection is first established, the router MUST send either a Reset Query or a Serial Query. A Serial Query would be appropriate if the router has significant unexpired data from a broken session with the same cache and remembers the Session ID of that session, in which case a Serial Query containing the Session ID from the previous session will allow the router to bring itself up to date while ensuring that the Serial Numbers are commensurate and that the router and cache are speaking compatible versions of the protocol. In all other cases, the router lacks the necessary data for fast resynchronization and therefore MUST fall back to a Reset Query.
首次建立传输连接时，路由器必须发送重置查询或串行查询。如果路由器具有来自具有相同缓存的中断会话的大量未过期数据，并且记住该会话的会话ID，则串行查询是合适的，在这种情况下，包含前一会话会话ID的串行查询将允许路由器更新自身，同时确保序列号相称，并且路由器和缓存使用的是协议的兼容版本。在所有其他情况下，路由器缺少快速重新同步所需的数据，因此必须返回到重置查询。
The 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.
当路由器接收到缓存重置、选择新缓存或担心丢失路径时，也会使用重置查询序列。
See Section 7 for details on version negotiation.
有关版本协商的详细信息，请参见第7节。
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 periodically. This also acts as a keep-alive at the application layer. See Section 6 for details on the required polling frequency.
为了限制缓存必须保留生成增量更新所需数据的时间长度，路由器必须定期发送串行查询或重置查询。这也在应用层起到了保持活动的作用。有关所需轮询频率的详细信息，请参见第6节。
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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 PDU, 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.
当传输层启动且路由器中的计时器已关闭或缓存已发送Notify PDU时，路由器通过发送串行查询来查询新数据，并且缓存发送串行查询中比串行查询中的串行数据更新的所有数据。
To limit the length of time a cache must keep old withdraws, a router MUST send either a Serial Query or a Reset Query periodically. See Section 6 for details on the required polling frequency.
为了限制缓存必须保留旧取款的时间长度，路由器必须定期发送串行查询或重置查询。有关所需轮询频率的详细信息，请参见第6节。
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
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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 which 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 14. Operators SHOULD use procedural means, e.g., access control lists (ACLs), to reduce the exposure to authentication issues.
缓存和路由器必须使用端口rpki rtr（323）通过TCP实现无保护传输；见第14节。运营商应使用程序手段，例如访问控制列表（ACL），以减少认证问题的暴露。
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:
如果操作员可用，缓存和路由器必须使用以下更受保护的协议之一：
o Caches and routers SHOULD use TCP-AO transport [RFC5925] over the rpki-rtr port.
o 缓存和路由器应通过rpki rtr端口使用TCP-AO传输[RFC5925]。
o Caches and routers MAY use Secure Shell version 2 (SSHv2) transport [RFC4252] using the normal SSH port. For an example, see Section 9.1.
o 缓存和路由器可以使用普通SSH端口使用Secure Shell版本2（SSHv2）传输[RFC4252]。有关示例，请参见第9.1节。
o 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].
o 缓存和路由器可以使用rpki rtr端口使用TCP MD5传输[RFC2385]。请注意，TCP MD5已被TCP-AO[RFC5925]淘汰。
o Caches and routers MAY use TCP over IPsec transport [RFC4301] using the rpki-rtr port.
o 缓存和路由器可以使用rpki rtr端口使用TCP over IPsec传输[RFC4301]。
o Caches and routers MAY use Transport Layer Security (TLS) transport [RFC5246] using port rpki-rtr-tls (324); see Section 14.
o 缓存和路由器可以使用端口rpki rtr TLS（324）使用传输层安全（TLS）传输[RFC5246]；见第14节。
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 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 startup.
一旦建立了SSH会话，应用程序将调用应用程序传输作为名为“rpki rtr”的SSH子系统。子系统支持是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 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 MITM attacks.
支持SSH传输的缓存服务器必须接受RSA身份验证，并且应该接受椭圆曲线数字签名算法（ECDSA）身份验证。必须支持用户身份验证；可能支持主机身份验证。实现可能支持密码身份验证。客户端路由器应验证缓存的公钥，以避免MITM攻击。
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 Certification 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 MITM attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:
路由器还必须使用[RFC6125]中描述的subjectAltName dNSName标识验证缓存的TLS服务器证书，以避免MITM攻击。[RFC6125]中定义的规则和指南适用于此处，并考虑以下因素：
o Support for the DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which 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.
o 在使用TLS的rpki rtr服务器和客户端实现中，需要支持DNS-ID标识符类型（即subjectAltName扩展中的dNSName标识）。颁发rpki rtr服务器证书的证书颁发机构必须支持DNS-ID标识符类型，并且DNS-ID标识符类型必须存在于rpki rtr服务器证书中。
o DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*".
o rpki rtr服务器证书中的DNS名称不应包含通配符“*”。
o rpki-rtr implementations which use TLS MUST NOT use Common Name (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].
o 使用TLS的rpki rtr实现不得使用通用名称（CN-ID）标识符；CN字段可能出现在服务器证书的使用者名称中，但不得在[RFC6125]中描述的规则内用于身份验证。
o The client router MUST set its "reference identifier" to the DNS name of the rpki-rtr cache.
o 客户端路由器必须将其“参考标识符”设置为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. Message Authentication Code (MAC) 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, et cetera. 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地址或完全限定的域名。
Cache Credential(s): Any credential (such as a public key) needed to authenticate the cache's identity to the router.
缓存凭据：向路由器验证缓存身份所需的任何凭据（如公钥）。
Router Credential(s): Any credential (such as a private key or certificate) needed to authenticate the router's identity to the cache.
路由器凭据：向缓存验证路由器身份所需的任何凭据（如私钥或证书）。
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 of BGP announcements.
如果保存了来自多个缓存的数据，则在执行BGP公告验证时，实现不得区分数据源。
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.
当数据与一个或多个其他缓存完全同步时，客户端可能会从特定缓存中删除数据。
See Section 6 for details on what to do when the client is not able to refresh from a particular cache.
有关客户端无法从特定缓存刷新时的操作的详细信息，请参见第6节。
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 which is closer to the Global RPKI. They might configure fallback 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 which 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 during development of the initial implementations. There is an IANA registry where valid error codes are listed; see Section 14. Errors which are considered fatal MUST cause the session to be dropped.
本节包含错误代码的初步列表。作者希望在初始实现的开发过程中添加到列表中。有一个IANA注册表，其中列出了有效的错误代码；见第14节。被认为是致命的错误必须导致会话被删除。
0: Corrupt Data (fatal): The receiver believes the received PDU to be corrupt in a manner not specified by another error code.
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 matching record ({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a Router Key PDU) does not exist in the receiver's database.
6：撤消未知记录（致命）：接收到的PDU具有标志=0，但接收方数据库中不存在匹配的记录（IPvX PDU的{Prefix，Len，Max Len，ASN}元组或路由器密钥PDU的{SKI，ASN，Subject Public Key}元组）。
7: Duplicate Announcement Received (fatal): The received PDU has Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a Router Key PDU) is already active in the router.
7：接收到重复公告（致命）：接收到的PDU具有标志=1，但匹配记录（IPvX PDU的{Prefix，Len，Max Len，ASN}元组或路由器密钥PDU的{SKI，ASN，Subject Public Key}元组）已在路由器中处于活动状态。
8: Unexpected Protocol Version (fatal): The received PDU has a Protocol Version field that differs from the protocol version negotiated in Section 7.
8：意外协议版本（致命）：收到的PDU具有与第7节中协商的协议版本不同的协议版本字段。
As this document describes a security protocol, many aspects of security interest are described in the relevant sections. This section points out issues which may not be obvious in other sections.
由于本文档描述了安全协议，因此在相关章节中描述了安全利益的许多方面。本节指出了在其他章节中可能不明显的问题。
Cache Validation: In order for a collection of caches as described in Section 11 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.
缓存验证：为了保证第11节中描述的缓存集合具有一致的视图，需要为它们提供一致的信任锚，以便在其内部验证过程中使用。假设一致信任锚的分布在带外。
Cache Peer Identification: The router initiates a transport connection 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。缓存间关系基于此对象安全模型；因此，缓存间传输可以得到轻微的保护。
However, 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 offload 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 which cannot provide the necessary authentication and integrity (see Section 9) must rely on network design and operational controls to provide protection against spoofing/ corruption attacks. As pointed out in Section 9, TCP-AO is the long-term plan. Protocols which 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.
无法提供必要的身份验证和完整性（见第9节）的传输必须依靠网络设计和操作控制来提供防欺骗/破坏攻击的保护。如第9节所述，TCP-AO是一项长期计划。应使用提供完整性和真实性的协议，如果不能，即使用TCP作为传输，则路由器和缓存必须位于同一受信任的受控网络上。
This section only discusses updates required in the existing IANA protocol registries to accommodate version 1 of this protocol. See [RFC6810] for IANA considerations from the original (version 0) protocol.
本节仅讨论现有IANA协议注册表中需要的更新，以适应本协议的版本1。有关原始（版本0）协议的IANA注意事项，请参见[RFC6810]。
All existing entries in the IANA "rpki-rtr-pdu" registry remain valid for protocol version 0. All of the PDU types allowed in protocol version 0 are also allowed in protocol version 1, with the addition of the new Router Key PDU. To reduce the likelihood of confusion, the PDU number used by the Router Key PDU in protocol version 1 is hereby registered as reserved (and unused) in protocol version 0.
IANA“rpki rtr pdu”注册表中的所有现有条目对于协议版本0仍然有效。协议版本0中允许的所有PDU类型在协议版本1中也允许，并添加了新的路由器密钥PDU。为了减少混淆的可能性，协议版本1中的路由器密钥PDU使用的PDU编号在此注册为协议版本0中的保留（和未使用）。
The policy for adding to the registry is RFC Required per [RFC8126]; the document must be either Standards Track or Experimental.
添加到注册表的策略是[RFC8126]要求的RFC；文档必须是标准跟踪或实验性的。
The "rpki-rtr-pdu" registry has been updated as follows:
“rpki rtr pdu”注册表已更新如下：
Protocol PDU
Version Type Description
-------- ---- ---------------
0-1 0 Serial Notify
0-1 1 Serial Query
0-1 2 Reset Query
0-1 3 Cache Response
0-1 4 IPv4 Prefix
0-1 6 IPv6 Prefix
0-1 7 End of Data
0-1 8 Cache Reset
0 9 Reserved
1 9 Router Key
0-1 10 Error Report
0-1 255 Reserved
Protocol PDU
Version Type Description
-------- ---- ---------------
0-1 0 Serial Notify
0-1 1 Serial Query
0-1 2 Reset Query
0-1 3 Cache Response
0-1 4 IPv4 Prefix
0-1 6 IPv6 Prefix
0-1 7 End of Data
0-1 8 Cache Reset
0 9 Reserved
1 9 Router Key
0-1 10 Error Report
0-1 255 Reserved
All existing entries in the IANA "rpki-rtr-error" registry remain valid for all protocol versions. Protocol version 1 adds one new error code:
IANA“rpki rtr error”注册表中的所有现有条目对于所有协议版本仍然有效。协议版本1添加了一个新的错误代码：
Error
Code Description
----- ---------------------------
8 Unexpected Protocol Version
Error
Code Description
----- ---------------------------
8 Unexpected Protocol Version
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，DOI 10.17487/RFC1982，1996年8月<https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，DOI 10.17487/RFC2385，1998年8月<https://www.rfc-editor.org/info/rfc2385>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4252]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，DOI 10.17487/RFC4252，2006年1月<https://www.rfc-editor.org/info/rfc4252>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<https://www.rfc-editor.org/info/rfc4301>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<https://www.rfc-editor.org/info/rfc5925>.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, <https://www.rfc-editor.org/info/rfc5926>.
[RFC5926]Lebovitz，G.和E.Rescorla，“TCP认证选项（TCP-AO）的加密算法”，RFC 5926，DOI 10.17487/RFC5926，2010年6月<https://www.rfc-editor.org/info/rfc5926>.
[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, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，DOI 10.17487/RFC6487，2012年2月<https://www.rfc-editor.org/info/rfc6487>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
[RFC6810]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议”，RFC 6810，DOI 10.17487/RFC6810，2013年1月<https://www.rfc-editor.org/info/rfc6810>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811]Mohapatra，P.，Scudder，J.，Ward，D.，Bush，R.，和R.Austein，“BGP前缀来源验证”，RFC 6811，DOI 10.17487/RFC6811，2013年1月<https://www.rfc-editor.org/info/rfc6811>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <http://www.rfc-editor.org/info/rfc8208>.
[RFC8208]Turner，S.和O.Borchert，“BGPsec算法、密钥格式和签名格式”，RFC 8208，DOI 10.17487/RFC8208，2017年9月<http://www.rfc-editor.org/info/rfc8208>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，DOI 10.17487/RFC1996，1996年8月<https://www.rfc-editor.org/info/rfc1996>.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, DOI 10.17487/RFC4808, March 2007, <https://www.rfc-editor.org/info/rfc4808>.
[RFC4808]Bellovin，S.，“TCP-MD5的关键变革战略”，RFC 4808，DOI 10.17487/RFC4808，2007年3月<https://www.rfc-editor.org/info/rfc4808>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <https://www.rfc-editor.org/info/rfc5781>.
[RFC5781]Weiler，S.，Ward，D.，和R.Housley，“rsync URI方案”，RFC 5781，DOI 10.17487/RFC5781，2010年2月<https://www.rfc-editor.org/info/rfc5781>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，DOI 10.17487/RFC6480，2012年2月<https://www.rfc-editor.org/info/rfc6480>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 6481，DOI 10.17487/RFC6481，2012年2月<https://www.rfc-editor.org/info/rfc6481>.
Acknowledgements
致谢
The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels, Rex Fernando, Richard Hansen, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas C. Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward. Particular thanks go to Hannes Gredler for showing us the dangers of unnecessary fields.
作者希望感谢尼尔斯·巴尔斯、史蒂夫·贝洛文、蒂姆·布鲁伊泽尔斯、雷克斯·费尔南多、理查德·汉森、保罗·霍夫曼、法比安·霍勒、鲁斯·霍斯利、普拉多什·莫哈帕特拉、凯尔·帕特尔、大卫·曼德尔伯格、桑迪·墨菲、罗伯特·拉祖克、安德烈亚斯·路透社、托马斯·施密特、约翰·斯卡德尔、鲁迪格·沃尔克、马蒂亚斯·韦利什和大卫·沃德。特别感谢Hannes Gredler向我们展示了不必要领域的危险。
No doubt this list is incomplete. We apologize to any contributor whose name we missed.
毫无疑问，这份清单是不完整的。我们向我们遗漏姓名的任何贡献者道歉。
Authors' Addresses
作者地址
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America
兰迪·布什互联网倡议日本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