RTR 会话与事务契约

实现基线为 RFC 8210 和实验性 8210bis-27，另有显式历史 8210bis-10 与 8210bis-13 profile。本页是实施映射，不替代规范原文。v2 由配置显式启用；v0 不实现。未另行说明的 v2 规则指默认 -27；历史 profile 差异见下节，不从相同的 wire version=2 自动猜测。

显式历史 profile

RtrSourceConfig.v2_profile 首批值为 8210bis-27（默认）、8210bis-10 与 8210bis-13。-10 以已发布 StayRTR 0.5.1 为互通对象；-13 对应固定 NIST-BRIO C 测试服务端的实际线格式（不是生产验证器，也不采用其 README 不符实际的 -15/-17 声明）。profile 进入来源身份、原始 metadata、完整恢复与录制；修改属于来源替换，不能在旧 session/serial 上偷偷改解释。每次查询在分配或发送前固定 profile 与资源配置。编解码入口同样显式传入 profile；不因 PDU 长度或 AFI 位自动尝试另一布局。

三个 profile 都以有效 EOD 原子提交，保留原始期限；-10 的同族 ASPA announcement 一次替换旧集合，不能跨 AFI 删除另一集合。完整 -10 EOD 声明两个 AFI 均已同步，无记录的族为 ready_empty。未知或未同步能力不能伪装为空授权。

-13 以16+4N字节布局保留 flags、reserved、uint16 count、customer；reserved（含原AFI字节）接收必须忽略，afi=None 明确表示双族共同授权。count/撤销/资源上限/timer/排序/停滞与上表 -10 相同；但 §13 将 Error4 改为非致命，0–8之外仍未定义。-13 引用 aspa-profile-18，ASPA对象内部排序是上游缓存责任，不能把对象ASN.1约束误写成旧RTR线格式的新增排序错误。

历史 -10/-13 的撤销忽略列表规则不适用于 -27。ASPA 同(customer, AFI)的重复变更与非最小 ANN→WD/WD→ANN 仍按本库固定事务策略拒绝；不为上游错误地先加新集合再撤销旧集合的差分实现恢复旧 provider 匹配语义。该错误应记录为产品互通限制，而非新草案 profile。早于 -10 或 -11/-12 及其他不同字段版本不自动纳入；新增时先固定原文、模型表达与独立证据。

PDU 矩阵

仅接受合法方向和状态中的 PDU。固定长度、内部长度、ASN/前缀长度、文本 UTF-8 和配置上限均检查；不先按不可信 Length 分配任意大缓冲。保留字段发送为零，接收按规范忽略，不能用“严格模式”拒绝协议要求忽略的字段。未使用的 flag 位按该版本规则处理，只以最低位解释 announce/withdraw。

v2 -27 Length 不超过 65,535；ASPA 帧长度须与 4 字节 provider 对齐。v1 和 v2 -10/-13 没有相同的规范硬上限，分别受 max_pdu_bytes_v1 与 max_pdu_bytes_v2_legacy 限制。-10/-13 ASPA announcement 的 uint16 count 必须等于实际 provider 数；最多 65,535 个，总长 262,156。-10/-13 withdrawal 仅要求完整的 16 字节固定部分，依据 §5.12 忽略 count 与后续列表字节，不用这些被忽略的值推导记录或否定撤销；重新编码时 count 为零、列表为空。PduDecoder 支持任意分片与多个连包，finish 时残余字节为截断输入。接收未知 type 不猜长度结构或静默跳过。

编解码层独立于会话：冻结 PDU 模型以显式 version 和关键字参数构造，announce 必须为 bool，ASN、session、serial、计时字段不接受 bool 冒充整数。prefix 保存严格规范网络，providers 保存不可变且已校验的 tuple；-27 要求升序，-10/-13 保留原始顺序且不要求升序，均不通过去重掩盖重复。AspaPdu.afi 为 None 表示双族载荷，显式 Afi.IPV4 或 Afi.IPV6 表示 -10。AspaPdu.v2_profile 构造参数省略时按明确模型字段推导 -27/ -10，运行时规范化为profile字符串；-13必须显式提供以区分其16字节无AFI布局。编码入口的 profile 必须与模型profile匹配，不能自动探测或提升为双族。pdu_type 和 length 是派生只读字段，length 表示规范重新编码后的长度；旧撤销忽略的尾部不保存在模型，接收资源预算仍使用原始帧长。EndOfData 的 codec 只检查计时字段能以 32 位无符号整数承载；§6 范围、expire 大于 refresh/retry、方向、协商、session、serial、事务和排序由会话层在提交前检查。

本库对两个版本均拒绝前缀中的非零主机位；v2 是 §5.9/5.10 的要求，v1 是本库的规范化接纳策略，不声称 RFC 8210 已包含后来新增的 MUST。zero 字段和未使用 flag 位接收时忽略、发送时置零，公开模型仅保留 announce 的最低位含义。Router Key 保留 20 字节 SKI 与非空可变长度 SPKI，不借“可承载的字节”宣称密钥密码学有效。

接收错误通过 ProtocolError 的 details.wire_error_code 区分：未知版本为 4，未知或该版本不支持的 type 为 5，长度、前缀、错误文本 UTF-8 与其他结构损坏为 0。v2 -27 ASPA 的空 announcement、乱序、重复、自身 provider、混合 AS0 使用 9；customer=0 属于 customer 字段损坏，使用 0；withdrawal 带 provider 或帧长度不对齐使用 0。customer=0 与自身 provider 的具体 wire code 是本库依 §12 错误类别作出的实验性选择，载荷合法性依据 aspa-profile-29。-27 announcement 最多承载 16,380 个 providers（总长 65,532）。-10/-13 没有错误码 9；空 announcement、重复、自身 provider、混合 AS0 按本库原始载荷安全接纳策略拒绝为 0，不能声称这是旧草案新增的 provider-list 错误码；旧草案 zero-or-more 与 aspa-profile-07/18 的非空集合差异不被解释为隐式撤销。这不解决下文会话事务排序的草案冲突。

错误报告中的 encapsulated_pdu 是可截断的不透明字节，不递归解码；v2 -27 非空封装至少包含前四字节，v1/-10/-13 无此新增下界。ErrorReport 构造器校验 v1 0–8、v2 0–13 的候选范围，encode/decode 再按显式 profile 检查允许的错误码和封装下界；text 严格使用 UTF-8。RouterKey/ErrorReport 构造器检查 uint32 总长，-27 的 65,535 上限在 encode/decode 检查。ProtocolError 与解码侧 ResourceLimitError 的 details 另含 received_type 和 reply_allowed；收到 type=10 时 reply_allowed 恒为 false，包括短头、错误长度、未知版本或错误码，避免再次回送 ErrorReport。此标记只限制能否回错，不替代会话的撤销和清理。

构造参数或编码 profile 不匹配报 InputError，线上字节损坏报 ProtocolError，配置的字节防护上限报 ResourceLimitError。encode_pdu/decode_pdu 以及 PduDecoder 接受显式 limits 与 v2_profile；后者默认 8210bis-27，另允许显式 8210bis-10 与 8210bis-13，非法 profile 为 InputError，包括处理 v1 时。profile 是调用方已知的协议契约，线上不协商它。decode_pdu 要求恰好一帧。PduDecoder 只保存一帧的未完成部分，取得八字节头后先检查长度再接纳正文，不复制整个连包到内部缓冲；一次 feed 中任意帧失败，该调用不返回先前帧。finish 成功或任何失败后解码器关闭，之后 feed 报 ClosedError；重复成功 finish 幂等，失败后的 finish 报 ClosedError。每个新传输流建立新解码器。协商期忽略其他版本 SerialNotify 的例外由会话分帧入口处理，独立 codec 仍只接受 v1/v2。

TLS 传输与资源归属

RFC 8210 §9.2 和 8210bis-27 §9.2 要求双向 TLS。内置传输发送配置的客户端证书，并使用缓存 DNS 名作为 reference identifier，校验可信链及服务器 SAN dNSName；禁止 CN-ID 回退和以连接 IP 代替 DNS 身份。客户端证书须包含 SAN iPAddress；宿主提供与源 IP 匹配的证书，缓存 MUST 核对连接 IP，SHOULD 拒绝不匹配。服务端核对不属于本库客户端的实现职责。自定义 SSLContext 的责任与文件配置互斥规则见 配置契约。

首版允许省略 ca_file 并使用 Python/OpenSSL 默认 CA 路径（可能受 SSL_CERT_FILE / SSL_CERT_DIR 影响），也允许显式 ca_file 或宿主 SSLContext。显式信任不会自动合并默认路径。默认上下文的其他环境行为见配置契约；trust_profile_id 仅标识信任策略，不能加载或替代 CA 配置。

connect_timeout 覆盖 DNS、TCP 和 TLS 握手的整个连接尝试，失败或取消不得交付半开连接；尚未成功返回的资源由工厂关闭。成功返回的字节流由会话关闭。内置流关闭时发起 TLS close_notify，并在有限等待后关闭底层套接字；关闭清理屏蔽外层取消，不能无限等待对端关闭握手。连接失败保持底层异常链，但公开错误信息不包含证书、私钥或密码。

TransportFactory 只要求 async connect(endpoint)，每次成功交付一个新连接，不要求自定义工厂提供额外属性。ConnectedTransport 包装已有 ByteStream，仅允许交付一次，reconnectable=False；交付的包装流 aclose 尊重 owns_stream，借用流只关闭本次使用权，原流留给宿主。停止后不能把同一个既有流伪装成新连接。两种关闭均幂等，不把关闭借用流的责任转交给会话。

SSH 传输与资源归属

SSH 按 RFC 8210 §9.1 及各固定 8210bis profile 的 §9.1：建立 SSH v2、完成用户认证后打开 session channel，再请求固定 rpki-rtr subsystem。公钥和密码认证通过显式配置启用；即使服务器接受无认证也拒绝连接。底层使用可选 AsyncSSH，不把 SSH 会话字节或 stderr 交给 PDU 解码器。仅 stdout 是 RTR 字节流；stderr 直接丢弃，接收窗口有界，不为调试输出创建无限队列。规范仍独立决定 RTR 版本、事务与 End of Data 接纳规则。

connect_timeout 覆盖 DNS、TCP、SSH 握手、用户认证和 subsystem 开通。准备凭据先于网络；失败或取消的未交付连接由工厂关闭，成功交付后由会话拥有。关闭屏蔽外层取消，有限等待后中止连接并等待本地关闭完成，不依赖对端发送退出状态。EOF、半关闭、发送背压遵循 AnyIO ByteStream 约定；同一流可并行读写，同向并发操作拒绝。重连创建全新 SSH 连接，旧流不可再次交付。凭据加载、后端限制及热配置见 配置契约。

公开 TransportError 码为 ssh_host_key_error（主机身份）、ssh_auth_error（认证）、ssh_subsystem_error（channel/subsystem 拒绝）、ssh_error（其他 SSH 连接失败）和 connect_timeout。本库生成的公开消息、状态、日志不复制远端错误文本或秘密；配置/依赖错误在启动时报 ConfigurationError / MissingExtraError。录制包装器只记录解密后的 RTR 应用数据及非敏感协议参数，不录制 SSH 握手、认证或配置。

状态转换

会话状态与数据可用性分开：连接失败不天然表示数据不可用，数据是否保留由具体事件和期限决定。

Cache Response 之外的载荷、重复 Cache Response、无事务的 EOD、来自服务器的客户端查询，均为非法序列。Notify 在已有查询时合并为“需要再检查”，不并发发送多条查询；完成当前事务后对照 serial 决定是否再查。

两版本 §8.1、§8.3、§8.4 允许首次恢复 Serial Query 收到 Cache Reset，也允许首次 Reset Query 收到 No Data Available；不能因尚处 negotiating 把它们当成非法序列。响应仍须检查对应查询、版本和错误结构，不能因此允许任意状态中的 Cache Reset。本库以有效 Cache Response 作为协商完成的观察点；此前这些响应不授予会话载荷或刷新期限，Serial Notify 继续忽略。重试等待须同时保存查询类型、协商状态和截止时间，不在等待期间并发发送查询。

Error4 已明确选定允许的低版本、但对端立即关闭连接时，下一传输连接续接同一次低版本协商，保留已失败版本，允许一次立即重连；此后的普通连接失败仍按 retry，不忙循环。成功 Cache Response 后结束该协商记录，未来新的独立协商仍从配置最高版本开始。该续接遵循 RFC8210/-10 §7 的跨连接降级说明，并将 -27 的“收到Error4后采用C”解释为同一次协商的继续，而非永久缓存低版本。

已有仍有效的 v1 数据在重连试探 v2 后再次选回 v1，继续保留原 session/serial 和增量资格，不发出 VRP/RouterKey unavailable。真正从已提交 v2 降到 v1 时立即撤销 ASPA 当前能力，VRP/RouterKey 仅在原期限内保留；旧数据元信息仍描述原 v2 EOD，不能伪装成刚完成的 v1 数据。恢复资格撤销，下一请求为 Reset，直到完整 v1 EOD 才替换原格式与原时间。管理层保留视图可从当前 dataset 删除已撤销 ASPA 及其 present/families，保留其余原始记录与期限、原 v2 格式，并以 metadata.rtr.incremental_usable=False 标记不可增量恢复；这种视图不是新的完整 v1 EOD。即使错误地保留了完整载荷，该 false 标记仍禁止增量恢复。持久化恢复这种保留视图时仍须校验来源身份、原 profile、原 EOD 计时范围、expires_at = last_sync_at + expire_interval、完整且无重复的 VRP/RouterKey 记录及资源限制；记录不得具有独立有效窗，ASPA 记录和 families 必须为空、能力必须 unsupported。校验通过仅允许按原期限保留视图，不安装 RTR 增量状态或授予 session/serial 恢复资格。

serial 使用 RFC 1982 的 32 位序列数算术；相等不表示新数据，回绕不当作普通整数倒退。相差恰好半空间不能擅自判定新旧，重新完整同步。Serial Notify、Cache Response、EOD 的 session/version 一致性按 §5.1 检查。

仅在来源身份、协议、session、serial、全部启用载荷和期限都可恢复时用 Serial Query。Reset Query 暂存从空开始，增量暂存以完整提交状态为基础；不能以已经按时间过滤的索引替代可恢复原始数据。

载荷事务规则

IPv4/IPv6 的唯一键为 prefix、prefix length、max length、ASN；Router Key 为 SKI、ASN、SPKI。相同来源重复 announcement 使用 Error 7，不存在记录的 withdrawal 使用 Error 6，来源之间不互相抵消。

v2 ASPA 按 §5.12：一个来源同 customer 只有一条活动 provider 集合。announcement 替换已有集合；withdrawal 长度必须为 12 且没有 provider，删除整个 customer。announcement 至少一个 provider；providers 严格递增、唯一、customer 不为零且不在 providers 中，AS0 不能与其他 provider 同帧出现。错误列表使用 Error 9。

ASPA 同 customer 的合法替换不能被通用“重复键”逻辑误判为 Error 7。同一增量事务重复发送相同 customer announcement 与“对已提交旧值进行一次替换”分开记录，前者按 §5.3 的重复变化检查。

同一事务中对同 customer 重复 announcement 或重复 withdrawal 使用 Error 7；首次撤销未知 customer 使用 Error 6。因为 §5.12 的一次 announcement 已完整替换旧值，同 customer 的 announcement/withdrawal 混合变化不属于 §5.3 要求的最小变化集合，本库拒绝而不按最后一帧猜测最终状态：announce→withdraw 使用 Error 0；withdraw→announce 在启用排序检查时先触发 Error 11，关闭排序检查后仍使用 Error 0。不同 customer 的合法变化不受此规则影响。这是固定草案的明确实验性解释，独立服务端验证及上游冲突状态须随互操作报告保留。

EOD 接纳前检查 session/version、serial、全部暂存载荷、计时参数和资源上限。成功即使载荷为空，也完整发布相应版本的能力；v1 的 ASPA 为 unsupported，v2 的空 ASPA 为 ready_empty。Router Key 未开放查询不影响协议接纳、撤销与恢复。

v2 排序

v2 缓存按 §11.2 排序；本库默认 check_order=True 采用 §11.4 允许的客户端检查。违规发送 Error 11 并结束会话。check_order=False 只关闭可选排序检查，仍须 EOD 原子提交和所有字段/事务检查；v1 不强加 v2 的排序要求。

排序以网络字段的数值或原始字节解释，不能使用小端整数或字符串 IP 比较。比较范围是一个 Cache Response/EOD 事务内的载荷序列。

定时器和失败

两版本 §6 的 refresh 范围 1–86400 秒，默认 3600；retry 范围 1–7200，默认 600；expire 范围 600–172800，默认 7200，且 expire 大于 refresh 和 retry。参数不合法的 EOD 不提交，本库作为 Corrupt Data 处理；不偷偷钳位后延长寿命。

refresh 和 expire 从有效 EOD 接收时刻起算，retry 从失败时刻起算。新 Notify 可提前查询，版本协商可按规范立即重试；其他重试不早于协议 retry。短连接重试不能形成忙循环。

宿主的资源维护让出与时钟重同步不是网络失败。维护取消候选后等待受管理线程结束、释放构建许可并关闭旧流，保留已提交数据及其原期限，随后公平重新准入，不生成来源故障或设置 retry 退避。但是，若受管理检查已确定致命协议错误，必须完成撤销并保留该错误的 retry 截止，不能被迟到的本地取消改成立即重连。时钟失信撤销后的主动重同步会唤醒 idle 或 retry 等待、丢弃旧恢复资格并请求完整 Reset；通常立即开始，但已有致命错误的退避须先结束。重复时钟重同步也不能缩短这项退避；只有新的有效 EOD 能重新提交，不延长旧数据期限。

query_timeout 限制从发出请求到 EOD 的总时间，不因收到每个字节无限续期；资源限制另计。传输停滞检测不能把 ready 状态中正常等待 refresh 当作停滞。v2 §9 的超过三倍 retry 的实际传输停滞适用 Error 10；普通 EOF 与收到明确致命 Error 10 分开处理。

v1 §12 明确要求 fatal 结束会话；本库对这些协议故障统一采取撤销该来源数据的保守策略，session 错误还受 §5.1 明确 flush 要求。v2 §12 明确要求 fatal 同时 flush。普通网络断线不是凭空收到一个致命错误码。

报告错误、到期或降级前释放已结束查询的候选准入；必要撤销由 Client 以独立维护额度完成，不能被热配置等维护请求当作来源候选抢占。若报告后需要发送接替查询，该查询重新取得额度；正常 EOD 发布仍受原查询额度保护。

错误码和草案冲突记录

v1 错误码 0–8 依次为 Corrupt Data、Internal Error、No Data Available、Invalid Request、Unsupported Protocol Version、Unsupported PDU Type、Withdrawal of Unknown Record、Duplicate Announcement Received、Unexpected Protocol Version。v2 另有 9 ASPA Provider List Error、10 Transport Error、11 Ordering Error、12 Cache Restart、13 Cache Shutdown；其中 2、4、12 在 v2 为非致命。

协商阶段 Error 4 按各版本 §7 的专门流程处理，不能仅看 v1 §12 的 fatal 标签禁止合法协商。协议确定后收到不同版本按该版的 Unexpected Protocol Version 流程结束；收到畸形或不合法 Error Report 直接结束，不再回送 Error Report，避免错误循环。

固定草案存在以下原文不一致，实施和测试必须保留对应决策记录：

• §5.9 把 Corrupt Data 写为 code 1；本库按 §12/§14 的注册定义使用 code 0，code 1 保留为 Internal Error。
• §12 的通用 duplicate 描述包含 ASPA customer，但 §5.12 明确允许替换。本库采用 §5.12 的专用替换规则。
• §5.3 的一般变化描述与 §11.2 的 announce-first 顺序文字不同。本库对 v2 使用 §11.2 的具体排序，对 ASPA 使用 §5.12 的完整替换；不以笼统文字重写载荷语义。

这些是固定 profile 的实验性解释，不声称获得正式勘误确认。2026-10-02 核对的 SIDROPS 讨论（Claudio Jeker，2023-06-08）明确采用 ASPA 专用替换规则，并指出通用 duplicate 描述中的 ASPA 文字应移除；同日 Oliver Borchert 的回复认同两种载荷操作不同。该讨论针对较早的 AFI 草案，只支持替换语义的沿革，不能充当 -27 的正式勘误或混合变化错误码的上游确认。

本库的实施结论是：合法 provider 集合更新仅需一次 announcement，按 §5.12 原子替换；载荷排序按专门定义总顺序的 §11.2。混合变化拒绝及其 Error 0/11 区分是本库对非最小变化集合的保守接收策略，不是草案明确指定的全部错误码。customer 为零使用 Error 0、customer 出现在 providers 中使用 Error 9，也分别按畸形 customer 字段和非法 provider 列表分类。以上选择不会将歧义帧的最后一个值提升为授权。

独立向量和独立服务端验证须保留版本、输入与预期错误，具体运行证据见 Issue #2 和互操作资料。使用上游服务端配合本项目合成载荷源的结果只证明该实现路径的互操作，不能声称生产服务兼容或上游共识。上述文本冲突已有明确实施结论；将来出现无法确定应接纳哪组授权的重要歧义，仍须阻断受影响实验能力的发布，不通过静默换草案、关闭其他校验或猜测授权解决。现有 IANA 镜像不能替代这些新增错误码。