RPKI 与 ROA：如何保护 IP 前缀并确保路由安全
RPKI（资源公钥基础设施）是一套安全框架，允许 IP 地址持有者发布经过加密签名的声明，说明哪些主体有权通过 BGP 宣告其地址空间。ROA（路由起源授权）就是这种签名声明，其中包含前缀、获准发起该前缀宣告的 ASN，以及允许宣告的最具体前缀长度。两者结合后，全球路由器便能在流量开始传输之前，拒绝有关您前缀的虚假宣告。
目录
RPKI 已不再是一项可选配置。越来越多的大型网络开始执行路由起源验证，并丢弃与已发布 ROA 冲突的宣告。这意味着 RPKI 是一把双刃剑。正确的 ROA 是保护前缀免遭我们在 BGP 劫持指南中介绍的起源伪造型劫持时，最有效的一项记录。错误的 ROA 甚至比没有 ROA 更糟：它会使您自己的合法宣告在所有执行验证的网络中被判定为 Invalid，从而引发一种看似处处异常、却又难以定位的网络中断。
对于租赁或收购地址空间的任何一方而言，这还涉及一个至关重要的控制权问题。只有前缀的登记持有者才能为其创建 ROA。承租方无法自行发布 ROA，其整个 RPKI 配置都依赖持有者的配合。因此，ROA 的处理方式必须作为租赁条款以书面形式确认，而不能留到以后作为技术细节临时解决。本文将说明 RPKI 和 ROA 是什么、验证如何运作、如何正确配置、哪些错误会破坏网络可达性，以及在租赁或购买 IPv4 地址空间前应当明确确认哪些 ROA 事项。
什么是 RPKI？
RPKI 是面向互联网号码资源的公钥基础设施。它允许 IP 地址空间和 ASN 的持有者通过加密方式证明其授权，使路由决策能够建立在可验证的记录之上，而不再仅仅依赖信任。
它采用一套与地址分配方式相对应的证书层级体系。各区域互联网注册管理机构（RIPE NCC、ARIN、APNIC、LACNIC 和 AFRINIC）向持有地址空间的组织签发资源证书，证明每个持有者控制哪些前缀。随后，持有者可以使用该证书为有关自身资源的声明签名，其中最重要的就是 ROA。互联网上的任何网络都可以获取这些签名对象，依据 RIR 的证书层级验证签名，并信任验证结果，因为其真实性由密码学机制保证，而不是依赖宣告方的一面之词。
RPKI 带来的根本变化值得明确说明。正如我们在 BGP 工作原理指南中所解释的，基础路由协议基于信任接受宣告。RPKI 在其上增加了一层证明机制，使合法持有者能够对自己的地址空间作出机器可验证的声明，供各地路由器检查。RPKI 不会取代 BGP，而是为 BGP 提供可供验证的依据。
什么是 ROA？
ROA 是一条经过加密签名的记录，声明某个特定 ASN 有权发起某个特定前缀的宣告，并规定允许的最大前缀长度。它是 RPKI 的核心对象，也是您实际创建以保护前缀的记录。每条 ROA 都包含三项信息，而每一项都会直接影响网络运行：
前缀。 授权所涵盖的地址块，例如 203.0.113.0/24。签名方必须确实持有该前缀，RIR 证书会对此加以约束。
起源 ASN。 获准在 BGP 中发起该前缀宣告的自治系统编号。由其他 ASN 发起的该前缀宣告都会被判定为 RPKI-Invalid。
最大长度（maxLength）。 授权允许的最具体前缀长度。例如，针对 203.0.113.0/24 且 maxLength 为 /24 的 ROA 只授权该完整的 /24；如果设为 /25，则还会授权其中的两个 /25。该字段决定哪些更具体的前缀宣告属于有效宣告，也是运营人员最容易配置错误的设置。
ROA 有一个特性是 IP 地址租赁得以运作的技术关键，因此有必要准确理解：ROA 中的前缀必须由签署方持有，但其中指定的起源 ASN 不必属于该签署方。持有者可以发布 ROA，授权他人的 ASN——例如承租方或承租方上游服务商的 ASN——发起其前缀的宣告。正是这一机制，使租赁的地址空间能够从承租方的路由环境中得到合法宣告：持有者负责签名，但授权指向实际宣告方。没有这种设计，租赁地址空间将永远无法通过路由起源验证。有了它，只要持有者确实发布了正确的 ROA，租赁前缀就能获得与自有地址空间同等的 RPKI 保护。
路由起源验证（ROV）如何运作
路由起源验证是网络利用 ROA 执行的操作：路由器将每条 BGP 宣告与已发布的 ROA 数据进行比对，并将其标记为 Valid、Invalid 或 NotFound，随后决定如何处理每种状态。
该机制分为两个部分，二者缺一不可，RPKI 才能发挥保护作用。首先，持有者创建 ROA。其次，网络部署验证器，获取所有已发布的 ROA，依据 RIR 证书层级进行验证，再将生成的授权数据提供给路由器，由路由器评估收到的每一条宣告。验证结果分为三种：
路由起源验证（ROV）如何运作
状态
含义
执行验证的网络通常如何处理
Valid（有效）
该前缀存在 ROA，且宣告的起源 ASN 和具体程度均与其匹配
正常接受
Invalid（无效）
该前缀存在 ROA，但起源 ASN 错误，或宣告的前缀比 maxLength 允许的更具体
拒绝并丢弃该路由
NotFound（未找到）
没有任何 ROA 涵盖该前缀
接受，但不受 RPKI 保护；这是传统的默认状态
有两点需要特别强调。第一，Invalid 会导致主动拒绝，而不仅仅是发出警告。在执行 ROV 的网络中，Invalid 宣告会像根本不存在一样被丢弃。正因为如此，RPKI 能够阻止劫持者使用自己的 ASN 宣告您的前缀；同样也正因为如此，配置错误的 ROA 会让您自己的合法路由失效。
第二，验证执行尚未覆盖所有网络。发布 ROA 并不能保证每个网络都会拒绝关于您地址空间的 Invalid 宣告，只能保证执行 ROV 的网络会这样做。目前验证覆盖率已经大幅提高，并包括许多规模最大的运营商，但仍未实现全面覆盖。ROA 会把伪造宣告在整个互联网中被拒绝的概率从“很少”提升至“通常”，但无法保证所有网络都会拒绝。RPKI 的作用应当放在这种覆盖范围虽不完整、但已相当广泛的现实中理解。
RPKI 能防范什么，又不能防范什么
RPKI 验证的是路由的起源，而不是路由路径，也无法处理路由中可能出现的所有问题。了解这一边界，既能避免忽视它的价值，也能防止产生虚假的安全感。
ROA 和 ROV 能够可靠应对的情况是常见的路由劫持：未经授权的 ASN 宣告您的前缀或其更具体的子前缀，并声称自己是路由起源。执行验证的网络会发现起源不匹配并拒绝该宣告。这是路由事件中最大的一类，而路由起源验证是目前部署最广泛的防御手段。因此，即使 ROA 无法提供全面保护，也仍然值得发布。
RPKI 无法做到以下几点：
它不会验证 AS 路径。 RPKI 检查谁声称发起一条路由，而不检查宣告所声称经过的网络序列。技术更成熟的攻击者可以伪造一条路径，并让路径末端显示您的合法起源 ASN，从而通过路由起源验证。ASPA 等路径授权机制旨在解决这一问题及相关的路由泄漏问题，但目前仍处于采用初期。2026 年的独立分析直接指出了这一缺口：即使路由起源覆盖率达到历史最高水平，伪造起源劫持、路由泄漏等多类路由攻击仍能直接绕过路由起源验证。
它不会加密任何内容。 这是一个常见误解。RPKI 是针对路由宣告的授权框架，与流量加密无关。数据保密性由 TLS 等协议单独提供。
它不会取代 IRR 路由对象或 LOA。 这些记录的功能有所重叠，但各不相同。许多服务商仍根据 IRR 数据构建过滤规则，而授权书（LOA）仍然是路由宣告获得实际批准流程的一部分。一个前缀通常需要 ROA、路由对象和 LOA 三种授权记录保持一致；RPKI 是其中之一，并非其他记录的替代品。我们另有专门的指南介绍 LOA。
正确的做法是发布 ROA，以抵御最常见的攻击，同时保持 IRR 对象准确、选择执行过滤的上游服务商，并监控未被这些措施拦截的问题。这正是 BGP 劫持防范部分所介绍的分层防御方法。
托管式 RPKI 与委托式 RPKI
RPKI 有两种运行方式：托管式 RPKI，由 RIR 运营证书颁发机构，并通过网页门户代表您签署 ROA；委托式 RPKI，则由您自行运行证书颁发机构基础设施。两者之间的选择主要取决于规模和控制需求。
托管式 RPKI 与委托式 RPKI
项目
托管式 RPKI
委托式 RPKI
谁运营 CA
RIR
您的组织
如何创建 ROA
通过 RIR 的门户或 API
通过您自己的 CA 软件和存储库
运维负担
最低，由 RIR 负责密钥、签名和发布
较高，需要自行维护基础设施、密钥和可用性
最适合
绝大多数持有者，包括多数企业和出租方
超大型运营商，以及需要大规模管理 ROA 或实现自动化的平台
对大多数组织来说，托管式 RPKI 是正确选择：它无需组织自行运营证书基础设施，同时仍能提供完整的保护效果。委托式 RPKI 主要适用于大型网络和需要管理大量前缀授权的平台，其中包括某些 IPv4 租赁运营商。这些平台需要自动创建和撤销 ROA，例如在租赁开始时迅速授权承租方的 ASN，并在租赁结束时彻底撤销授权。从客户的角度看，出租方采用哪种模式并不如其处理 ROA 的速度和可靠性重要。
正确设置 maxLength
maxLength 应当与您实际计划宣告的最具体前缀长度相匹配，既不能过宽，也不能过窄。在 RPKI 中，这个字段造成的自身配置故障比任何其他设置都多，而且两个方向都可能出错：
设置过严会破坏您自己的宣告。 假设 /22 前缀的 ROA 将 maxLength 设为 /22，但您需要宣告其中的 /24——无论是用于流量工程、特定服务，还是在发生劫持时通过紧急反向宣告夺回流量——该 /24 都比 ROA 允许的前缀更具体，因此会被判定为 Invalid，并被执行验证的网络拒绝。换言之，您封锁了自己。这也会直接限制 BGP 劫持指南中介绍的应对策略：只有当 ROA 的 maxLength 允许时，宣告更具体的前缀才能奏效。
设置过宽则会帮助劫持者。 如果 /22 前缀的 ROA 将 maxLength 设为 /24，但您实际上只宣告 /22，那么您已经预先授权 ROA 中指定的 ASN 宣告更具体的 /23 和 /24。更关键的是，您扩大了地址空间中被视为 Valid 的范围，而这些范围并未被实际使用。安全方面的最佳实践是只授权您确实会宣告的具体程度，不多也不少。这样，任何未经计划的更具体宣告都会明显显示为 Invalid，而不会混入 Valid 宣告中。
避免这两类错误的规则是：列出您实际宣告或计划宣告的所有前缀长度，并通过设置 maxLength 或创建额外的 ROA，只覆盖这些长度。如果您会宣告一个 /22，并偶尔宣告其中某个特定的 /24，那么 ROA 数据应明确授权该 /22 和该 /24。这应是一项有记录的审慎决定，而不是为了省事而随意选择的宽泛范围。
破坏网络可达性的常见 RPKI 错误
破坏性最强的 RPKI 事件通常并非劫持，而是运营人员将自己的合法路由变成 Invalid。执行验证的网络会丢弃 Invalid 路由，因此这类错误会产生一种特别且令人困惑的现象：部分网络无法访问，看起来与普通故障无异。您的服务器仍在运行，本地路由器仍在宣告前缀，一个传输服务商仍能看到该路由，但另一个网络却将其丢弃。于是，互联网的一部分能够访问您，另一部分却完全看不到您。常见原因包括：
更换服务商或改变宣告方式后，ROA 仍指定旧 ASN。 您迁移到新的上游服务商，或开始从不同 ASN 宣告，但 ROA 仍授权原来的 ASN。此时，所有执行验证的网络都会拒绝您的合法宣告。这是意外产生 Invalid 状态最常见的原因，在租赁地址空间中尤其容易发生，因为 ROA 和路由宣告由不同的主体控制。
maxLength 未覆盖实际宣告。 您合法宣告的更具体路由会因为超出 ROA 允许的长度而被拒绝。
遗漏某个前缀。 您为大部分地址空间发布了 ROA，却漏掉一个地址块，使其处于 NotFound 状态且不受保护；或者当相邻前缀都有 ROA 覆盖时，您宣告了一个没有任何 ROA 覆盖的前缀，造成配置不一致。
到期和续期疏漏。 ROA 及其背后的证书都有有效期。如果 ROA 到期或证书未及时续期，保护就会消失，而且路由状态可能根据配置发生变化，成为 Invalid 或退回 NotFound。托管式 RPKI 会自动处理其中许多事项，但保持记录有效的责任并不会因此消失。
仍在宣告时删除或撤销 ROA。 删除正在使用的前缀 ROA，会使其从 Valid 变为 NotFound，从而失去保护；如果仍存在相互冲突的 ROA，也可能变为 Invalid，从而失去网络可达性。对生产环境前缀执行 ROA 变更，应采用与其他路由变更相同的变更管理规范。
有一点虽然令人稍感安心，但并不意味着可以放松警惕：2026 年的研究发现，全球观测到的绝大多数 RPKI-Invalid 前缀源于错误配置，而不是攻击；前往这些前缀的流量通常会改走不那么具体的路由或不执行验证的路径，因此某些情况下损害有限。但“损害通常有限”并不等于“安全”。如果某家企业的特定服务因过时 ROA 而无法从某家大型运营商访问，无论总体统计数据如何，这都是一次真实的网络中断。
租赁 IPv4 地址空间中的 RPKI
对于租赁地址空间而言，决定性的事实是：只有登记持有者才能发布 ROA。因此，承租方能否获得 RPKI 保护，完全取决于租赁安排。承租方使用自己或其上游服务商的 ASN 宣告前缀，持有者则必须发布 ROA 授权该 ASN。任何一方都无法单独完成整个过程，而且双方各自只控制其中一半。
这正是前面介绍的“ROA 可以指定任意 ASN”这一特性在实际操作中如此重要的原因：它允许持有者合法授权承租方的 ASN。但只有持有者在整个租赁期间及时、正确地使用这一机制，它才能真正发挥作用。因此，在签订协议前，以下事项必须作为租赁条款以书面形式确认，而不能留作日后解决的运维细节：
明确的 ROA 权限和承诺。 租约是否要求持有者为租赁前缀发布 ROA，并指定您或您上游服务商的起源 ASN？这方面的模糊约定，可能使原本应为 Valid 的路由在接入第一天就变成 Invalid。
处理时限服务等级协议。 无论是常规变更还是紧急情况，持有者需要多长时间创建、更新或撤销 ROA？如果更换服务商或应对劫持时，需要等待数天才能更新 ROA，那么网络可达性事故已经发生。明确的处理时限承诺，例如常规请求在规定时间内完成、紧急请求更快处理，是区分能够支持实际生产运营的租赁服务和只能维持静态环境的租赁服务的关键。
maxLength 约定。 ROA 将授权哪些前缀长度？这必须与您计划宣告的前缀一致，包括用于流量工程或劫持应对的任何更具体前缀。前文所述的 maxLength 管理规范，需要由租赁双方共同协商确定。
租赁开始、变更和结束时的完整生命周期。 在开始宣告前创建并验证 ROA，以免接入期间出现 NotFound 空窗；如果 ASN 或宣告方式发生变化，应正确更新；租赁结束时则应适当撤销，使地址空间以干净状态归还持有者。成熟的租赁运营会将这一生命周期自动化，非正式安排则往往对此没有明确规定。
结构完善的租赁安排正是为了解决这些协调问题。托管式 IPv4 租赁平台应当把 ROA 发布、处理时限、maxLength 和生命周期管理作为明确的服务组成部分。因为对于租赁地址空间而言，无论承租方自己的网络团队能力多强，都无法独自实现 RPKI 保护。收购地址空间时也需要进行同样的协调：购买 IPv4 地址后，应当在完成转移的过程中将正确 ROA 的发布权纳入自身控制，并与路由和反向 DNS 配置一并完成，让地址空间在交付时就受到保护，而不是处于 NotFound 状态。
为什么 RPKI 已不再是可选项
RPKI 已经从一项专业安全实践发展为互联网主流运维要求，而且这一趋势只会继续加强。截至 2026 年年中，根据 Hurricane Electric 的采用情况报告，大约 67% 的已路由前缀拥有签名 ROA，其中 IPv6 的覆盖率高于 IPv4。仅仅两年前，IPv4 覆盖率首次突破一半还曾被视为一个值得庆祝的里程碑，此后覆盖率仍在持续稳定增长。
2026 年的两项发展体现了这种势头。中国的国家级注册管理机构在数周内使该国路由的 RPKI 覆盖率从接近于零提升到绝大多数。分析还表明，前往 RPKI-Valid 路由的互联网流量占比，已经显著高于获得 RPKI 覆盖的路由占比，因为规模最大、流量最高的网络更有可能同时发布签名并执行验证。对任何运营商而言，其实际影响是：互联网中会悄无声息地拒绝有关您地址空间之 Invalid 宣告的部分正在不断扩大。无论该 Invalid 来自劫持者的伪造宣告，还是您自己过时的 ROA，随着采用率上升，这两种影响都会越来越明显。
服务商和监管机构的要求也在朝相同方向发展。大型传输服务商越来越多地将 ROV 作为默认措施，路由安全倡议把发布 ROA 视为基本良好实践，一些司法管辖区的监管机构也开始推动服务商采用由 RPKI 支持的路由安全措施。对于运营公共 IPv4 地址空间的企业来说，问题已经从“我们是否应该发布 ROA”转变为“我们的 ROA 是否准确且保持最新”。在执行验证的互联网环境中，没有 ROA 会使您暴露于风险，而错误的 ROA 则会让您掉线。
实用检查清单
如果您持有自己的前缀
- 为您宣告的每个前缀发布 ROA，也应覆盖您持有但尚未宣告的前缀，因为闲置地址空间同样是劫持目标。
- 将 maxLength 精确设置为您实际宣告的具体程度，包括计划使用的更具体前缀，不要设置得更宽。
- 除非有明确的规模或自动化需求，否则应使用托管式 RPKI。
- 每次更换服务商、更改 ASN 或增加新宣告后，都要确保 ROA 与实际情况保持一致。
- 监控所有前缀的 RPKI 状态，以便在客户发现之前识别意外产生的 Invalid。
- 对生产环境前缀的 ROA 变更执行完整的变更管理流程。
如果您租赁前缀
- 以书面形式确认持有者会为租赁前缀发布 ROA，并指定您的起源 ASN。
- 以书面形式取得创建、更新和撤销 ROA 的处理时限服务等级协议，同时覆盖常规和紧急请求。
- 就 maxLength 达成一致，确保其覆盖您计划宣告的每种前缀长度。
- 在开始宣告前确认 ROA 已发布并处于 Valid 状态，避免接入期间出现 NotFound 空窗。
- 确认租赁期间更换 ASN 或上游服务商时，如何处理 ROA 更新。
- 确认租赁结束时如何撤销 ROA。
来自 i.lease 的实务说明
RPKI 具有一种容易被运营人员忽视的不对称特性：同一套机制既会保护配置正确的前缀，也会主动切断配置错误的前缀。发布准确的 ROA 后，互联网中范围庞大且持续扩大的网络会自动拒绝针对您地址空间的伪造宣告。但如果发布了错误的 ROA——例如更换服务商后仍使用旧 ASN，或者 maxLength 未涵盖您的 /24——互联网中的同一批网络也会拒绝您。其表现往往像是一个原因不明的局部网络中断，而不是记录配置问题。该技术会完全按照收到的指令在全球范围内执行，这既是它的优势，也是它的陷阱。
在租赁地址空间中，这种不对称性贯穿整个租赁关系，因为宣告前缀的人和能够修复 ROA 的人并不是同一方。即使承租方的网络配置毫无问题，也可能因为一条自己无权修改且指定了错误 ASN 的 ROA，而在半个互联网中被判定为 Invalid。因此，签约前需要解决的问题本质上并不只是技术问题，而是权限和速度问题：持有者是否会发布您的配置所需的 ROA？情况发生变化时，他们能否迅速更新？租赁结束时又会如何处理？结构完善的安排会以书面形式回答这些问题，并将整个生命周期自动化。非正式安排则会让承租方承担一条只有他人才能创建和维护之记录的责任。无论您以何种方式持有地址空间，RPKI 与其他路由安全机制所要求的都是同一件事：由具备相应权限和维护动力的人，持续保持记录准确、有效和最新。
结语
RPKI 将路由授权从信任问题转变为证明问题：RIR 认证谁持有哪些资源；持有者发布经过签名的 ROA，声明哪个 ASN 可以发起每个前缀的宣告，以及宣告可以具体到什么程度；执行验证的网络则拒绝不符合授权的宣告。ROA 是一个前缀能够拥有的最具影响力的记录，也是目前部署最广泛的常见起源伪造型劫持防御措施。在大多数已路由地址空间都开始受到 ROA 覆盖、验证执行范围持续扩大的互联网环境中，发布准确的 ROA 已成为基本运维规范，而不再是高级安全措施。
RPKI 要求的是精确性。它拒绝虚假宣告的能力，也同样会在起源 ASN 错误或 maxLength 未覆盖实际路由时拒绝您自己的宣告。因此，真正的工作在于确保 ROA 在每次变更后仍然准确且保持最新。对于租赁地址空间，这项工作由双方共同完成：只有持有者能够发布 ROA，只有承租方负责宣告前缀，而保护只会在双方的协议明确支持时存在。理解起源验证与路径验证之间的边界，正确设置 maxLength，使记录与实际宣告保持一致；如果使用租赁地址空间，则应在首次宣告前，将 ROA 权限、处理时限和生命周期写入协议。做到这些，RPKI 才会发挥其设计目的：让全球路由器保护您的前缀，无论该前缀由您拥有还是租赁。
常见问题
RPKI 是什么的缩写？
RPKI 是 Resource Public Key Infrastructure（资源公钥基础设施）的缩写。它是一套加密框架，允许 IP 地址和 ASN 持有者发布可验证的声明，说明谁有权通过 BGP 宣告其资源。
网络中的 ROA 是什么？
ROA（Route Origin Authorization，路由起源授权）是一条经过加密签名的记录，声明某个特定 ASN 有权发起某个特定 IP 前缀的宣告，并规定允许的最大前缀长度。它是资源持有者在 RPKI 中创建的对象，用于保护前缀免遭未经授权的宣告。
谁可以创建 ROA？
只有前缀的登记持有者，也就是经 RIR 认证为控制该地址空间的一方，才能为其创建 ROA。承租方无法自行发布租赁地址空间的 ROA，必须由持有者代为发布。因此，ROA 的处理方式应作为租赁条款以书面形式确认。
RPKI 会加密我的流量吗？
不会。这是一个常见误解。RPKI 是针对路由宣告的授权框架，控制谁可以宣告您的前缀，而不负责保护数据的机密性。流量加密由 TLS 等协议提供，与 RPKI 完全独立。
ROA 中的 maxLength 是什么？
maxLength 是 ROA 授权的最具体前缀长度。一个针对 /22 且 maxLength 为 /22 的 ROA 只授权该完整的 /22；如果设置为 /24，则也会授权更具体的 /23 和 /24。它应当与您实际宣告的具体程度精确匹配：设置过严会封锁您自己的更具体前缀，设置过宽则会扩大劫持者可以作为 Valid 路由宣告的范围。
RPKI 中的“Invalid”是什么意思？
如果某个前缀存在 ROA，但宣告的起源 ASN 错误，或者宣告的前缀比 maxLength 允许的更具体，该宣告就会被判定为 RPKI-Invalid。执行路由起源验证的网络会拒绝 Invalid 宣告。这可以阻止路由劫持，但如果 Invalid 是由错误配置的 ROA 引起的，也会使您自己的路由在这些网络中下线。
RPKI 是强制性的吗？
RPKI 尚未在所有地方受到强制要求，但实际上已经成为普遍预期。截至 2026 年，大多数已路由前缀都拥有 ROA，许多大型运营商会拒绝 Invalid 路由，服务商和监管机构也在继续推动采用基于 RPKI 的路由安全措施。在实际运营中，发布准确的 ROA 已成为基本规范。
ROA 可以指定一个不属于我的 ASN 吗？
可以，而且这一点对地址租赁至关重要。ROA 中的前缀必须属于签名的持有者，但其授权的起源 ASN 不必属于持有者。这样，持有者就能发布 ROA，授权承租方或其上游服务商的 ASN 合法宣告自己的前缀。
谁为租赁的 IP 地址创建 ROA？
由登记持有者，即出租方或其指定的一方创建 ROA，并在其中指定承租方的起源 ASN。承租方负责宣告前缀，但无法自行发布 ROA。租赁协议应明确承诺由持有者发布并维护正确的 ROA，同时规定变更的处理时限。
如果我的 ROA 到期，会发生什么？
ROA 及其底层证书都有有效期。如果 ROA 到期或证书未及时续期，前缀将失去保护，其 RPKI 状态也可能发生变化：可能退回 NotFound；如果仍存在冲突的 ROA，也可能变为 Invalid，并被执行验证的网络丢弃。托管式 RPKI 会自动处理许多续期事项，但保持记录有效仍然是持有者的责任。
RPKI 会取代 LOA 吗？
不会。RPKI ROA 和授权书（LOA）的作用有所重叠，但并不相同，许多服务商仍会使用 IRR 路由对象。一个前缀通常需要保持 ROA、路由对象和 LOA 三者一致。RPKI 可以增强路由安全，但无法独自取代其他授权记录。
延伸阅读
- 什么是 BGP 劫持？路由劫持的工作原理、著名事件及网络防范方式
- 什么是 BGP？边界网关协议如何让 IP 地址对应的服务可被访问
- IPv4 转移期间如何防止地址劫持：10 项安全措施
- DDoS 缓解如何运作：流量清洗、BGP 引流、任播，以及网络运营商应做的准备
