摘要

  • Robert Moskowitz 与 Pekka Nikander 在 2006 年的 HIP 架构中，以公钥身份标识通信端点，让 IP 地址保留为分组转发所需的定位符。
  • 双方都使用 HIP 时，这种分离可以让通信关联跨地址变化延续；它不会转移地址登记，也不会自动更新所有应用的访问规则。

一台笔记本离开原来的网络，接入后拿到新的 IP 地址。分组要走的路变了，通信另一端的主机却没有变。互联网协议过去常让一个数字同时承担两个任务：标明网络拓扑位置，也代表通信端点。Robert Moskowitz 和 Pekka Nikander 在 RFC 4423 中把这种职责重叠变成了明确的架构问题。

Host Identity Protocol 在互联网层与传输层之间加入身份命名空间。在这套设计里，Host Identifier 是公钥；它代表的 Host Identity 则是抽象身份。Host Identity Tag（HIT）把标识压缩为 128 位的哈希表示，用于协议状态。IP 地址仍然不可缺少：路由器需要它来决定分组往哪里走。变化的是，地址不再必须独自定义一条传输关联究竟属于哪个主机。

由此可见，HIP 的核心不是“地址不会变”，而是改变关联所绑定的对象。RFC 4423 把传输关联绑定到 Host Identity。主机因移动、接入另一网络或重新编号而更换地址时，支持 HIP 的通信对端可以更新定位符，同时保留依附于身份的关联。一个主机也可以同时通过多块接口可达。连续性因此有一部分从固定地址转移到了双方共同维护的密码学状态。

RFC 的时间线也限定了 Moskowitz 的贡献范围。RFC 4423 于 2006 年 5 月作为 Informational 文档发布。它把自己称为作者截至 2003 年秋季的思考快照，并提醒读者架构后来可能已经演进；文档明确没有定义 Internet Standard。之后由 Moskowitz 与其他作者共同编辑的 RFC 7401 将 HIP version 2 写入 Standards Track，描述双方同意参与的主机如何建立共享 IP 层状态，并用四个分组完成密码学握手。2021 年，Moskowitz 与 Miika Komu 合著的 RFC 9063 更新架构、取代 RFC 4423，并结合 RFC 7401 实现经验讨论密码算法敏捷性、洪泛防护、访问控制与首次信任等问题。

这段规范演进能证明架构被补充和修订，不能证明互联网已摆脱地址依赖。HIP 维护的是参与协议的端点所管理的关联。防火墙可能仍只放行某个源 IP；DNS 可能仍解析到旧地址；通信对端也可能没有实现 HIP。应用还可能把地址写入配置，或把地址当成信誉线索。即使关联越过了地址变化，这些外部状态也不会自动更新。

Heng Lu 的 Note 68 提供了另一个经济视角：当客户、合作伙伴和安全团队围绕一个地址形成预期时，它可能沉淀为企业记忆。这不是对 HIP 的描述，也不是某种部署现状的证据，而是帮助我们区分两种连续性。HIP 将参与协议交换的主机身份与负责路由的定位符分开；它不会重写围绕 IP 地址积累起来的外部关系。

因此，Moskowitz 的工作更适合被理解为一条架构边界：主机可以说“我的路径可能改变，但经过认证的端点身份属于另一份状态”。这条边界有用，恰恰因为它范围有限。HIP 可以减轻移动和多宿主场景对固定地址的依赖，却不替代 DNS、路由、资源管理、应用策略或面向客户的连续性安排。

来源