摘要

  • RFC 10040 是 IETF 流的 Experimental RFC，经过 IETF 共识、公开审阅与 IESG 批准，但它明确不是 Internet Standards Track 规范；正文还特别说明，Experimental 描述的是技术成熟度，并不代表正在进行一项有假设、有样本和有成败指标的部署实验。
  • IANA 当前注册表仍保留 type 5，并标为 Geo-Coordinates (DEPRECATED)；type 17 则另列为 Geo-Location。弃用不是删除，分配也不是实现、协商、发送、解析或实际使用的证明。
  • 可核验的迁移记录必须分别保存文档状态、旧新 codepoint、实现和对端能力、实际报文、未知类型处理、双编码与回退窗口、位置精度和访问政策、失败、纠正与退出条件。

一次发布不是一次端到端切换

RFC Editor 在 2026 年 9 月 15 日发布了 RFC 10040。它更新 RFC 8060，弃用第 4.3 节以 LCAF type 5 表示的 Geo-Coordinates 编码，并把新的紧凑 Geo-Location 格式放在 type 17 下。

这条新闻至少包含六种状态。LISP 工作组形成了文档结果；IESG 在 3 月 15 日批准发布；RFC Editor 半年后发布最终文本；IANA 协调两个编号的状态；某个软件版本可能支持或不支持 type 17；一对真实节点也可能成功或失败地交换并使用它。

前四项已有公开记录，后两项必须从运行系统取得证据。它们不能互相借用证明力。

RFC 10040 的状态说明把边界写得很清楚：文档代表 IETF 社区共识，经过公开审阅并获 IESG 批准；同一段又说明它不是 Internet Standards Track 规范，并非所有 IESG 批准的文档都会成为任何级别的 Internet Standard。

因此，共识回答的是程序来源：哪一份文本完成了 IETF 流的审阅和批准。它没有回答运营商是否部署 type 17、两个实现是否互通，也没有回答旧发送端何时可以退出。

没有实验假设的 Experimental

正文最关键的一句话是：这项工作并非某个“experiment”的组成部分，因为并非所有 Experimental RFC 都必然属于一项实验；这里说的是技术成熟度。

这同时阻止两种相反误读。Experimental 不等于“安全性天然较低”，也不等于“一项可测量的现场试验已经启动”。它是文档类别。RFC 7841 的标准表述是：供检验、实验性实现和评估。它没有替特定部署提供假设、群组、遥测、期限或成功门槛。

成熟度标签很容易复制，迁移证据却昂贵。公告可以重复“Experimental”；迁移方案必须写明软件版本、对端能力、报文路径、回退、观察窗口和决策责任。若把标签当成方案，最便宜的证据就会冒充最困难的工作。

也不能用最终共识抹去审阅历史。公开记录曾提出旧 RFC 8060 编码是否存在实现与部署、位置精度、隐私以及“实验”定义等问题。最终 RFC 是获批结果；历史表明这些不确定性接受过审查，却不能证明每个问题已经得到运行层答案。

Deprecated 不等于消失

IANA LISP 参数注册表 仍列出 type 5：Geo-Coordinates (DEPRECATED)，并同时引用 RFC 8060 与 RFC 10040。type 17 另列为 Geo-Location。

这是一项首选协议词汇变化，不是删除事件。RFC 10040 没有说 type 5 已从注册表消失，没有要求所有接收端立刻拒绝它，也没有声称所有发送端已经迁移。旧编号被保留，正是因为已部署代码和历史报文不能靠重用编号来抹掉。

弃用由此开始工作，而不是结束工作。仅发送 type 17 的一方需要知道接收方是否能用。接收方可能支持新格式的 RLOC-Record，却缺少 EID-Record 注册与查询所需行为。一套系统也可能同时存在多个软件版本；控制器会序列化新格式，但观察工具、导出链或下游校验器仍按 type 5 解读。

RFC 10040 没有为此次迁移定义一种通用能力协商报文。因此，运营方必须记录自己如何确认支持：版本盘点、双边配置档、测试交换、受控放量或其他有边界的方法。沉默不是能力证明。

向后兼容条款其实是一则运行警告

第 8 节规定了不对称边界。带 Geo-Location 的 EID-Record，只有支持该格式的 LISP 节点才能进行注册和查询；带 Geo-Location 的 RLOC-Record 可以返回给不理解它的节点，但后者会忽略该记录。

忽略未知类型可以是正确且安全的协议行为，同时仍构成服务失败。发送端可能产生完全合法的 type 17，映射系统可能正确携带，接收端也可能依规则正确忽略；每个组件都“没有犯错”，但依赖位置的功能并没有发生。

这击穿三种捷径。干净的注册表项不能证明解析器存在；发送成功不能证明接收端使用；解析成功也不能证明应用选择了路由、回答了查询或做出了位置相关决定。

迁移证据必须有方向。记录应说明哪个组件发出哪一种 type，哪个对端收到，如何分类，是使用还是忽略，以及什么回退保住服务。“支持 RFC 10040”太宽，无法诊断混合版本系统。

更精细的字段不会自动产生真实位置

type 17 的变化不只在编号。它增加显式 Location Uncertainty，以毫秒表示经纬度细分，注明高度单位，并用半径区分 Geo-Point 与 Geo-Prefix。这些规则让实现可以更一致地表达信息。

它们不会认证坐标来源。拥有厘米粒度字段的位置，仍可能来自过期资产台账、手工错误、粗略估计，或真实精度远低于字段粒度的设备。Uncertainty 字段可以承载一个精度声明，却不是外部测量形成的真值证书。

权限也一样。RFC 10040 讨论了谁能访问映射记录的本地政策、Mapping Service Provider 的代理执行、签名或加密回复、用 Geo-Prefix 降低精度以及短 TTL。文档还说典型用途是公共建筑、地点与地标，而不是人员、车辆与设备。

这些措施必须被配置并接受观察。报文出现坐标既不证明主体同意，也不证明请求者获授权。有效签名可以在特定机制下认证或授权回复者，却不能证明底层位置准确、披露得到同意，或下游接收者按政策保留数据。

一份成熟度与迁移回执

最小有用记录不是一个合规开关，而是一份把三层连接起来、又不混为一谈的版本化回执。

第一层是文档来源：IETF 流、Experimental 类别、IESG 批准日、RFC 发布日、被更新的 RFC 8060 第 4.3 节、被弃用的 type 5 和新分配的 type 17。未来若出现状态调整或 errata，应新增带日期的事实，而不是回写历史。

第二层是兼容与迁移：实现与版本、支持的记录角色、确认对端能力的方法、实际发送和解析的编码、未知类型结果、双编码或回退窗口、测试范围、失败数量、纠正责任、回滚和退役门槛。若一段时间同时接受两种 type，还要说明只是能解析、已用于生产，还是只作主动回退。

第三层是位置数据使用：坐标来源、声明精度与测量精度、Geo-Point 或 Geo-Prefix、访问控制、授权机制、TTL 或保留期、观察范围、下游消费者、纠错渠道，以及允许或拒绝运行使用的决定。

回执不得把没有证据自动染成红色。“未观察”“未测试”“不支持”“已忽略”和“解析失败”是不同状态；“deprecated”“已禁用”“从某一批系统退役”和“从注册表删除”也完全不同。

这里需要的只是朴素的 running-code 纪律。发布形成共同协调文档；实现采用、对端互通并由运营方接受后果，才改变现实。注册表可以协调编号，却不能制造这个编号所要识别的报文。

来源与边界

主要证据包括 RFC 10040、RFC Editor 发布公告、Datatracker 历史、IANA LISP 参数注册表、RFC 8060、RFC 7841 与 RFC 6973。截至 2026 年 9 月 21 日，RFC 10040 errata 查询没有匹配记录。

这些来源可以证明文档、注册表与协议语义，却没有提供完整实现支持矩阵、部署普查、报文轨迹、迁移排期、位置准确性审计或同意记录。本文未找到这些证据，是结论边界；不能反推世界上不存在任何实现或部署。