摘要

  • 一个稳定的 EID 只有同时满足 ETR 获授权登记、Mapping System 正确解析、ITR 的 Map-Cache 尚未过期、RLOC 选择符合策略、底层网络可达、ETR 完成内层交付，才会成为可用路径。
  • David Meyer 是 LISP 原始与现行数据平面 RFC 的多位共同作者之一。他的意义不在于让位置从网络中消失，而在于见证一个架构想法如何被写成带有时钟、权限、失败状态与回退边界的运行制度。

从一条没有改地址的故障说起

设想一个端点的 EID 始终没有变化。监控系统仍能在资产表中找到它，配置库也显示其状态正常，可数据包却到不了。原因可能是 ETR 的登记已经超时，也可能是远端 ITR 仍缓存旧 RLOC；底层路由或许不再到达被选中的位置，甚至外层封装已经抵达 ETR，而目标站点内部的最后一段转发失败。

这类故障正是 LISP 的思想边界。它没有把一个地址变成不受基础设施约束的身份，而是把“叫什么”和“现在在哪里”拆成不同事实。EID 可以不变，关于位置的其他事实却可能分别失效。

2006 年的 IAB 路由与寻址研讨会曾追问：同一个 IP 地址既承担标识、又承担定位，是否会把边缘的多宿主与流量工程变化不断推入全球路由表。RFC 4984 记录了与会者的判断——标识符与定位符的重载是扩展压力的一部分，某种分离似乎必要。但报告没有给出完整架构，也不是 IAB 的正式解决方案。问题被确认，不等于答案已经运行。

RFC 9299 描述了 LISP 的做法。EID 与 RLOC 在形式上仍像 IPv4 或 IPv6 地址，语义却不同：EID 标识端点，不包含跨域拓扑位置；RLOC 标识底层网络的附着点。Mapping System 保存两者关系，隧道路由器根据该关系封装数据包。于是，原本藏在地址里的定位责任被移到一张可写、可查、可缓存的表里。

一张表包含多少个真相

RFC 9300 对 EID 的要求很克制。用于公共互联网的 EID 必须像其他公共 IP 地址一样唯一，并从与站点关联的 EID 前缀中分配。唯一性只是避免冲突。它不是所有权凭证，不验证人或组织身份，不保证跨运营商可携带，也不证明 Mapping System 中已有对应记录。

真正的路径至少包含六个状态：

  1. ETR 配置了 EID 前缀与一个或多个 RLOC，并有权提交这项关系；
  2. Map-Server 接受登记，Mapping System 能向 Map-Resolver 提供相关记录；
  3. 发送端 ITR 通过最长前缀匹配找到尚未过期的 Map-Cache 条目；
  4. Priority 与 Weight 允许并选定某个 RLOC；
  5. 底层网络确实能把外层数据包送到该 RLOC；
  6. ETR 解封装后，目的站点内部还能把内层数据包送到 EID。

任何一项为假，稳定的 EID 都可能指向不可用服务。反过来，一次成功也不永久证明六项成立，因为登记、缓存、路由与站内状态拥有不同的更新时间。

ITR 的查询过程把这种时间性写进了协议。它先在本地按最长前缀查找 Map-Cache；命中后得到 Locator-Set，未命中则通过 RFC 9301 的控制平面解析。等待期间，是丢包还是缓存数据包由部署者决定。两家都“支持 LISP”的设备，因此可能表现出完全不同的首包时延与故障模式。

解析结果带 TTL。零要求立即删除，特殊的全一值则允许接收端自行决定保存期限。缓存还包含 EID 与 RLOC 的可达状态。“权威记录刚更新”与“这台 ITR 当前使用了新记录”不能画成同一个绿色方块。

Locator-Set 也不是普通地址列表。较小的 Priority 优先，255 表示不得用于转发；同一优先级下，Weight 决定负载份额。无需改变 EID，运营者只修改权重就能移动流量。位置被拆出后，同时成了流量工程政策。

谁可以声称端点在这里

RFC 9301 将写入与读取分开。ETR 周期性地向 Map-Server 发送 Map-Register，列出 EID 前缀和可到达它的 RLOC。ITR 则把 Map-Request 交给 Map-Resolver，由后者通过 Mapping System 查找。

登记不是“收到报文就相信”。ETR 与 Map-Server 必须预先配置共享秘密，用来派生认证密钥；服务器还应保存每个 ETR 有权登记的前缀清单。RFC 明确警告，若不核对前缀授权，Mapping System 会暴露在最简单的 EID 前缀劫持之下。

登记通常按分钟刷新，长时间收不到有效更新便可被移除。没有 RLOC 的 Negative Map-Reply 也不只有一种含义：可能未登记、被策略拒绝或认证失败；动作可以是原生转发、重新查询、不采取动作或丢弃。这些差异决定了事故应交给路由、权限还是控制平面团队。

ETR 改变映射时，Solicit-Map-Request 可以提示近期缓存过该记录的 ITR 重新查询。发送与响应都需要限速；没有相关缓存的 ITR 不应无谓刷新。这不是“一处更新，全球瞬间一致”，而是针对活跃读者的有限收敛。

RFC 9302 为受控、可信环境提供了可选的十二位 Map-Version。增加或删除 RLOC、调整 Priority 或 Weight、改变本地可达性，都可能推进版本。由于版本号循环，太老的值可能在回绕后看似较新；部署者需要至少等待上一条记录的 TTL，或确认活跃流量已使用最新状态。公共互联网的规则更严格：RFC 9300 禁止把 Map-Versioning、gleaning、Locator-Status-Bits 或 Echo-Nonce 当作映射更新或 RLOC 可达性的捷径，必须依赖控制平面。

受保护的是关系，不是数字本身

伪造的 EID-RLOC 关系能够把流量导向攻击者。RFC 9301 因此先声明三个前提：Mapping System 安全且可信，ETR 与它已有预置信任关系，系统知道某个 ETR 可以公告哪些 EID。密钥与映射权利如何建立，不在该 RFC 的范围之内。协议不能替机构完成授权。

RFC 9303 的 LISP-SEC 为查询过程加入来源认证、完整性、抗重放与 EID 前缀权利验证，防止中间人篡改和过度声称更大前缀。但它同样保留假设：Mapping System 会把请求送往预期 ETR，Map-Server 能在登记时核验权利。安全机制保护的是映射关系，并未把 EID 变成密码学身份。

长期稳定还有隐私代价。RFC 9301 指出，若 EID 长期不变而对应 RLOC 可被观察，外部可能把多次位置变化串联成拓扑轨迹。少改地址与少被追踪，并非同一政策目标。

David Meyer 的位置也需要准确标注

RFC 9300 的作者包括 Dino Farinacci、Vince Fuller、Dave Meyer、Darrel Lewis 以及编辑 Albert Cabellos；Meyer 也参与了早期 RFC 6830。把 LISP 归功于他一人既不准确，也会遮住 IETF 共识、实现者和运营者的权力。

他更适合作为时间轴上的观察点。ONUG 的历史人物页记载了他曾在 Cisco、Brocade 工作，参与 IAB 与 NANOG 项目委员会，并在俄勒冈大学参与 RouteViews。这些是有年代的背景，不能当作当前职位。它们说明 Meyer 长期处于“控制平面应该如何被观察”与“抽象如何落地”之间。

本站已有一篇 Meyer 文章讨论 RouteViews、RPSL 与 OpenDaylight，主题是公共路由可见性。本文的对象不同：谁能写入身份到位置的关系，读者可以相信多久，以及解析成功之后还缺哪些运行证据。两篇文章的人物相同，开场、机制与证据面完全不同。

RFC 7215 的实验性部署指南给出了一份很好的反证清单。它要求核对设备版本、配置、MTU、前缀分配、RLOC 可达性、登记与认证密钥、代理缓存、BGP 策略、外部可见性和真实流量。清单反映 2014 年的迁移环境，却揭示了不会过时的原则：标准、配置和登记都不能代替端到端验证。

所以，LISP 所谓的稳定并不是 EID 摆脱了网络，而是多方愿意持续维护一张有权写入、按时失效、可以审计的位置表。地址只负责不变；可用性由整条托管链共同完成。

来源