摘要

  • RFC 9962 让参与的 xTR 共同维持 LISP 的 EID-to-RLOC 映射；推送方案借组播复制登记，拉取方案借一致算法与 DNS 发现 Map-Server 集合。
  • 映射表、认证登记和处理回执只证明各自有限的控制平面事件。RFC 9301 明确指出，RLOC 状态可表达可达性，却不表达请求方视角的路径可达性。

先要把对象说清。LISP 把 Endpoint Identifier（EID）与 Routing Locator（RLOC）分开：前者标示叠加网络中被寻址的端点，后者是承载封装流量的定位信息。两者之间需要映射系统。传统安排中，独立的 Mapping System Provider 经营 Map-Resolver 和 Map-Server，数据平面 xTR 向其登记或检索。RFC 9962 并没有把“映射”变成一个无主的事实；它改变的是谁参与保存和提供这个有限的记录。使用映射的 xTR 也可以成为维护映射的成员。

这是一种依赖结构的变化，不是一项关于现实世界的总证明。RFC 9301 中，ETR 的 Map-Register 把 EID 前缀及相关 RLOC 提交给 Map-Server；请求 Map-Notify 时，后者确认该登记已被接收并处理。这里的“接收”“处理”“确认”都不能被压缩成“流量必然成功”。它们说明某一控制平面服务对一份登记做了特定动作。它们并不说明每一个请求方都能走到该 RLOC，也不说明该 RLOC 后的服务仍适合当前业务。

RFC 9301 把关键限制写得很直白：RLOC 的状态可传达可达性，却不传达从请求方视角看到的路径可达性；路径仍需独立测试。这不是一个可被忽略的脚注。不同请求地点、封装方式、过滤规则、回程、拥塞、故障切换和服务策略，会让同一条映射在不同情境下有不同结果。即使映射记录没有错，路径也可能不可用；即使数据包抵达一个地址，服务也可能不应被接受。控制平面记录与运营判断之间，仍然有一段必须由真正承担风险的一方完成的工作。

RFC 9962 的两种方案正好使边界更清楚。推送式系统中，xTR 加入同一组播组，Map-Register 可被送往组内所有 Map-Server，成员保存同一份已登记状态。这带来冗余，却要求组播底座。拉取式系统中，EID 经一致的转换函数产生 DNS 名称，从而找到特定 Map-Server 集合；它少复制状态，但要求参与者对算法、名称、模数和扩容安排保持一致。两者不是可以随意拼接的“更大去中心化”。RFC 9962 要求二选一；若两者并存，它们仍是彼此离散的映射系统，并不承诺同另一个映射系统兼容。

认证也有自己的边界。RFC 9962 指向 RFC 9301 及 ECDSA-AUTH 来建立 xTR 之间的信任关系。RFC 9301 为 Map-Register 的来源和完整性提供保护，并用 nonce 处理重放；Map-Server 可以拒绝未通过认证或策略的登记。这能提高“谁提交了哪一份登记、系统是否处理它”的可追责性。它不能把密钥持有证明扩展成对终点身份、业务授权、客户关系、路径质量或未来交付的证明。被认证的是一项协议行为，不是所有后果。

从陆恒关于最小共同机制与本地后续决定的视角看，RFC 9962 的价值在于把一项协调功能放回参与者身边，而不是让协调层替参与者承担本应由他们承担的判断。一个共享映射可以降低发现和登记的成本；它不应在没有明确授权的情况下，取得决定流量、客户暴露、故障容忍或退出路径的权力。真正重要的问题不是“去中心化”这个词是否好听，而是：哪种依赖被移除了，哪份记录可被审计，以及哪项决定仍必须留给承担损失的人。

来源