摘要

  • LSI 借用了 IPv4 或 IPv6 接口的形状，却只在本机映射表中代表某个 Host Identity；把同一串比特交给另一台机器，不会连同映射语义一起搬过去。
  • 应分别保留本地分配、HIT 绑定、定位符发现、路径选择、HIP 关联、受保护流量、应用结果和审计关联的凭据。

兼容成功掩盖了作用域变化

设想一套多年未改的 IPv4 应用。它调用解析器，得到一个四字节值，再把这个值交给 connect()。HIP 感知的操作系统在下面查到对应的 Host Identity，找到可用定位符，建立连接。对应用来说，一切与过去相同。

随后，应用把这个“地址”写进任务记录，或者作为回调地址发给另一台服务器。问题此时才出现。第一台机器拿到的是自己分配的 Local Scope Identifier；第二台机器没有那张 LSI 到 HIT 的表。比特可以完整复制，意义却没有跨越边界。

RFC 5338 特意区分地址在旧应用中的多种用途：短时本地句柄、长期关联、回调、转介和身份比较。兼容机制在“解析后立即交还本机协议栈”这个场景中可以正确工作，并不意味着它适合其余用途。接口形状相同，权威范围不同。

LSI 是映射表索引，不是缩短版路由

RFC 5338 将 LSI 定义为在 IPv4 或 IPv6 API 上本地代表 Host Identity 的 32 位或 128 位量。后来的 RFC 9063 说得更直接：常见的 32 位 LSI 由 HIP 层或套接字处理器与 HIT 相互转换，不会作为定位地址在线路上传输。

因此，解释一个 LSI 至少需要三项坐标：由哪台主机分配、属于哪一代映射、绑定哪个 Host Identity。缺少这些坐标，它就像一张没有数据库名称和版本号的行号。另一台主机可能完全不认识，也可能恰好把相同数值分给另一个身份。

把 LSI 称为“特殊 IP”会诱使系统寻找一条到它的路由。更准确的说法是：它是旧接口能够容纳的本地名字。真正的网络路径要在其后另行解析；真正的对端身份要在 HIP 交换中另行验证；真正的业务完成要由应用响应证明。

DNS 返回的是本机入口，不是全球委托

RFC 5338 描述了一个 HIP 感知的本地 DNS 代理。代理发现域名存在 HIP 身份信息时，可向不懂 HIP 的应用返回 LSI 或 HIT，并在本地保存映射。应用继续把值当作地址，系统调用边界以下完成转换。

这里至少有六个不同事实：域名查询到了资料；本机选择了 HIP 表示；句柄被分配；当前定位符被找到；某条连接路径获胜；应用操作完成。把第一或第三个事实写成“连接已由目标身份接收”，就把发现凭据升级成了结果凭据。

排序也不能证明实际路径。解析器可能把 HIP 标识符放在普通地址之前，但有些应用会并发尝试多个结果。普通连接可能先成功。列表顺序只表达本地偏好，不是运行时判决。如果政策要求必须使用 HIP，系统必须限制候选或观察实际获胜路径，不能只审计 getaddrinfo() 的返回顺序。

诊断工具还可能需要真实 IP，而不是兼容句柄。对所有程序无差别劫持解析，会让 ping、日志和路径分析看见一种与线上包不同的“地址”。兼容层必须记录自己改变了什么语义。

转介把数值送出去了，却把解释器留在原地

在三方场景中，B 把 A 的地址交给 C，C 再联系 A。若 B 交出的是自己本机用于 A 的 LSI，C 得到的只是 B 表中的索引。C 不具备 B 的解释权。

最容易发现的是立即失败。更危险的是貌似成功：C 把该数值当作普通 IPv4，或者自己的 LSI 表中恰好存在同一数值。请求于是抵达另一个对象，而字段检查、长度检查和格式检查全部通过。

修复的重点不是让 LSI 变成全球可路由。应用协议应携带接收方有能力解析的名字，并明确作用域。可以是 HIT 与对应的定位机制，也可以是 DNS 名称与安全规则，或包含 Host Identity、签发方和有效期的对象。若因观测需要保留 LSI，必须同时保留分配节点和映射代际。

RFC 9063 将这种层次违规与 NAT 类比。许多把本地地址嵌入应用协议的程序本来就会在地址转换环境中出错。HIP 不是凭空制造问题，而是迫使系统承认：旧字段曾把位置、身份和本地引用混成一个概念。

缓存会把临时句柄伪装成历史身份

旧应用可能长时间缓存解析结果，HIP 系统却希望回收 LSI。RFC 5338 指出，这使垃圾回收时机很难判断。回收太早，仍持有旧值的进程可能在复用后连接到另一个身份；永不回收，又会累积状态。

审计系统面临同样问题。上午 LSI 42 绑定身份 X，下午重启后绑定身份 Y。如果日志只有“42”，事后用当前表关联，就会把上午事件错误归给 Y。这不是近似误差，而是改变了事件主体。

RFC 5338 建议 HIP 软件同时记录 HIT、LSI、对应 IP 地址和 FQDN 相关信息。实际运营还应加入时间、本地主机、启动或映射代际、进程、套接字与策略决定。这样的元组能够说明兼容层当时如何解释输入。

它仍然不能代替应用结果。映射日志说明“本机把这个句柄理解为谁”；关联日志说明“HIP 交换进行到哪一步”；数据日志说明“哪些受保护包通过”；业务日志说明“用户请求是否完成”。各层必须允许彼此核对，而不能互相冒充。

显式 HIT 加强命名意图，但没有包办结果

RFC 5338 对比普通 connect(ip) 与显式连接 HIT。前者的可靠解释可能只是“连接当前在这个 IP 可达的系统”。本地政策可以尝试 HIP，但应用提出的地址本身未必强绑定某个 Host Identity，而且这种绑定对应用不可见。

显式 HIT 更强，因为它直接指定密码学主机名字，而不是普通可路由地址。然而强名字仍需解析定位符、完成基础交换、建立保护状态、发送数据并取得应用响应。HIT 本身也不证明当前私钥持有、账户授权或服务可用。

这个边界与既有 HIP 文章不同。这里不讨论 RVS 是否转发 I1、DNS 记录是否新鲜、移动定位符是否验证或 ESP 是否穿过防火墙。这里讨论的是更早的一步：旧应用看见的值究竟由谁授权解释，以及它离开本机后是否仍然指向同一个主体。

通配监听仍把身份选择藏在应用下方

服务器端也存在同类问题。旧服务常绑定通配地址；一个主机却可能拥有多个 Host Identity。若应用没有指定某个 HIT，本地策略就要选择身份。RFC 5338 举出 UDP 情形：recvfrom() 收到请求后，sendto() 可能使用与客户端预期不同的服务器 HIT，客户端因套接字访问控制而丢弃回应。

“端口正在监听”只是接入状态，不是身份连续性凭据。运营需要记录数据报到达哪个本地身份、回应选择哪个身份、哪条策略作出选择。如果应用无法处理多身份，发布层就应只宣告与默认出站身份一致的那一个。

兼容设计并不要求每个旧应用立刻重写，但要求隐藏的选择可被观察。否则，网络可达、密码学交换和应用进程各自看似正常，真正断裂的身份衔接却没有任何凭据。

来源与证据边界

这些来源证明规范文本、架构说明和历史实验总结，不证明当前产品、部署规模、具体机构、已发生事件或故障概率。