摘要

  • draft-dong-sidrops-rpki-rtr-moa-pdu 的 revision 01 于 2026 年 9 月 9 日发布，新增分拆消息下的全部撤销与部分撤销、刷新/重试/过期计时及序列号处理。它仍是活跃的个人 Internet-Draft，不是 SIDROPS 工作组文稿，更不是 IETF 已批准标准。
  • 文稿明确说，MOA 与 IPv6 ROA 的验证顺序和回退行为属于一份预计配套发布的验证规范。最小补丁不是再加一个传输字段，而是公开一张“双平面结果矩阵”，让相同输入为何得出某项本地动作可以重建。

假设一个地址持有者签发的 MOA，把一个 IPv6 映射前缀授权给三个 IPv4 前缀。缓存为了适应传输长度，把前两个前缀装进一条消息，把第三个装进另一条。后来持有者只撤销第一个和第三个前缀。撤销时是否必须复刻原来的分包方式？

revision 01 给出的答案是不必。若全部撤销，缓存既可以发送一条包含全部前缀的 Withdrawal PDU，也可以沿用此前的若干子集。若部分撤销，一条或多条消息的并集必须恰好等于被撤销的前缀，不能多也不能少。路由器按这个并集删除本地 MOV 数据库中的对应授权，不要求撤销消息数量与原始公告数量相同。

这不是单纯节省报文的写法。它把“授权是什么”与“某次传输如何装箱”分开了。一次临时的分包选择不会变成日后撤销授权必须依赖的永久状态。

revision 00 没有这些规则。官方 00→01 对比 还显示，新稿增加了 IPv4 前缀的规范排序、缓存生命周期处理，以及把组合验证排除在本文范围之外的明确说明。

文件名不能替代程序状态

对这份文稿的制度地位也要逐项辨认。Datatracker 页面与文档 API都把它列为活跃的个人提交：没有 IETF stream，没有负责的 Area Director，没有 shepherd，也没有目标标准等级。历史记录记载了 Guozhen Dong 在 9 月 9 日上传的新版本；提交 API保存了作者、文稿日期与提交日期。

名称里出现 sidrops，只能说明作者希望在哪个技术社群讨论，不能证明工作组已经接管。与它相连的 MOA profile 的确是 SIDROPS 工作组文稿，但这种状态不会顺着引用自动传递。本稿申请的 IANA PDU Type 也仍是 TBD，申请本身不是分配结果。

五种对象，五段权力

要看清缺口，首先不能把整条链压缩成“RPKI 已验证”。

第一段是地址持有者签发的 MOA。MOA profile revision 04让一个 IPv6 映射前缀可以获准为一个或多个 IPv4 前缀发起映射。若要让多个 IPv6 前缀映射同一组 IPv4 前缀，持有者需要签发多个 MOA。这个对象表达授权范围，不是 BGP 路由，也不是转发命令。

第二段由 relying party 软件验证签名对象。它先执行 RFC 6488 的通用检查，再确认 MOA 中每个 IPv4 前缀都落在 EE 证书的 IP 地址委派扩展范围内。profile 还特别说明：这里的 PKI 给出 authorization，不给出个人身份认证，也不承诺不可否认性。

第三段是缓存。缓存从已验证的 MOA 提取映射前缀和 IPv4 集合，生成规范排序的 PDU。PDU 是签名仓库内容面向路由器的派生投影；缓存—路由器会话的完整性或认证，并不会把这条投影变回原始签名对象。

第四段是路由器的本地 MOV 数据库。revision 01 沿用 RFC 8210 的 Session ID 与 Serial Number 体系。RFC 8210 说得很窄：序列号是一台缓存的逻辑版本，不同缓存、不同协议版本之间不可直接比较，缓存重置后也不保证延续。协议版本、会话标识与序列号一起说明两份缓存状态能否比较；任何一个都不能单独证明持有者的授权意图。

第五段才是 4map6 BGP 公告。4map6 revision 06描述路由器检查 IPv6 映射前缀是否可达、更新 Mapping rule Database，并按照本地控制处理分发。即使前四段都存在，最终采用何种路由动作仍是另一个本地决定。

ROA 也不能与 MOA 混称。RFC 9582中的 ROA 授权某个自治系统为地址前缀发起路由；MOA 则拟授权某个 IPv6 映射前缀为 IPv4 前缀发起映射。两者使用相似的 RPKI 基础设施，却治理不同动作。

撤销与过期是两条出口

revision 01 还引入 RFC 8210 的 Refresh、Retry 与 Expire 机制。Refresh 计时结束时，路由器发出 Reset Query，并在等待回复期间继续使用已安装的 MOA 数据。请求失败后按照 Retry 间隔重试。若一直无法成功刷新直至 Expire，路由器必须删除本地全部 MOA 数据，停止以 MOA 为依据执行 MOV 决定，直到重新建立缓存连接。

文稿同时要求 MOA 数据发生变化时递增序列号，让路由器在同一可比较会话里发现陈旧或失同步状态。

过期不是撤销。撤销是缓存传达“这些特定授权已改变”；过期是路由器在无法及时取得缓存完整新视图时，停止相信整批旧数据。部分撤销可能只拿走两个前缀，过期则让整套 MOA 输入暂时退出决策。

两者也都不自动证明 4map6 路由从 RIB 或 FIB 消失，更不证明数据包已经改道或业务恢复。签名对象、缓存序列、本地 MOV 条目、BGP 路由与实际包路径必须保留为不同证据。

真正的分岔仍写在“未来”里

MOA profile 自己指出了第二重风险：IPv4 持有者可能合法授权某个 IPv6 映射前缀，但第三方仍可能恶意发起这个 IPv6 前缀。profile 因而建议同时部署 IPv6 ROA validation。

新版 PDU 重申这种依赖，随即把关键问题划到范围之外。它明说，MOA 与 IPv6 ROA validation 的详细互动——包括验证顺序和 fallback 行为——将由一份预计与 MOA profile 配套的 verification specification 处理。

在本文研究截止时，对 Datatracker 公开文稿名称中的 MOA 以及标题中的 “Mapping Origin” 进行检索，只找到 MOA profile、PDU 提案与会议材料，没有找到承担上述验证功能的现行文稿。这只是对公开记录的有限观察，不证明实现者没有内部规则，也不排除下一版文稿很快出现。

缺的不是抽象口号，而是一组必然遇到的分支：MOA 为 Valid，IPv6 ROA 却为 Invalid，怎么办？若 IPv6 结果为 NotFound 呢？是拒绝安装、降低优先级、留下“未评估”状态，还是交给某版运营策略？缓存 MOA 数据仍在 Expire 窗口内，而 IPv6 路由刚刚变化，哪个观察时点优先？缓存恢复后，映射重新进入本地数据库之前需要重跑哪些检查？

序列号回答不了这些问题。它只排序一段可比较的缓存历史，不会替两个授权平面决定优先级。精确撤销解决“删什么”，并不解决“信什么”。

4map6 当前的受控环境假设可以缩小风险，却不能抹掉决策。其文稿首先面向单一运营商或少量协作运营商，并说更广部署将需要另行定义专门认证机制。小范围参与者完全可以约定本地规则；但必须把它标成该部署的规则，而不是悄悄让它冒充协议共识。

先发布一张双平面结果矩阵

最小补丁不必扩大 PDU。配套规范或公开的运营商 profile 可以提供一张双平面验证结果矩阵。

矩阵每一行应同时记录：MOA 对象结果与理由；缓存端点、协议版本、Session ID、Serial Number 和观察时间；映射前缀的 IPv6 ROA 结果；执行顺序；一个结果是否阻断、降级或令另一个不再评估；本地映射条目保留或删除；采用的运营策略版本；实际动作；以及恢复所需的复核条件。

最少要覆盖：MOA 有效且 IPv6 为 Valid、Invalid、NotFound；MOA 无效或过期；缓存陈旧但尚在 Expire 窗口；缓存已过期；部分撤销；全部撤销；缓存重置；重新连接后的同步。NotFound 不能偷换成 Valid，“没有执行”也不能显示成“通过”。

这遵循 Heng Lu 《Minimum Initial Specification》的边界：只统一互操作所需的最小结果语义，把最终路由政策留给各网络。《Running Code Primary》则提醒我们保存实际跑过哪条规则的证据。这张矩阵是我的编辑性建议，不是 IETF、SIDROPS 或作者已经提出的字段。

revision 01 值得肯定，因为它终于让授权可以按真实范围退出，而不是被历史分包绑住。下一步应该以同样精度写清：当两种证明不一致时，谁让授权重新影响路由。

来源