摘要

  • RFC 5380 让远端继续使用稳定的 RCoA，把本地移动收敛为 MAP 内部的 RCoA—LCoA 更新。
  • 绑定确认是控制面回执；真正的连续性还要分别证明缓存、拦截、封装、路径、MTU、解封装与应用结果。

一块绿色面板遮住了两次移动

假设运营面板用一个 IPv6 地址代表会话。移动节点换了接入路由器，面板上的地址没有变化；它又在同一 MAP 域内移动一次，远端仍然看见同一个地址。于是系统把“地址稳定”写成“业务连续”。

第二句话并不是第一句话的同义表达。

在 RFC 5380 的 HMIPv6 设计里，节点同时持有两类临时地址。Regional Care-of Address（RCoA）位于 Mobility Anchor Point 的链路上，对 home agent 和 correspondent node 保持稳定；on-link Care-of Address（LCoA）来自当前接入链路，会随着本地移动改变。MAP 把前者映射到后者，拦截发往 RCoA 的包，再封装并送往当前 LCoA。

远端之所以不必观察本地移动，不是因为移动消失了，而是因为 MAP 承担了把稳定地址“做实”的责任。

绑定成功只回答了一个问题

节点向 MAP 发送本地 Binding Update，请求建立 RCoA 与 LCoA 的对应关系。MAP 接受后写入缓存，并返回 Binding Acknowledgement。规范要求节点最好等到这份确认，再把 RCoA 注册给其他节点；外层绑定的寿命也不得超过 MAP 内层绑定的寿命。

这份确认很重要。它证明 MAP 接受了请求。它没有同时证明后续每一步。

真正交付一个入站数据包，MAP 还要拦截 RCoA 流量，命中当前缓存，使用正确 LCoA 作为隧道终点，并让路由把封装后的包送到那里。移动节点要接收、解封装并交给上层。出站方向也要经过相应的隧道路径。安全关联、路径 MTU 和应用状态都可能在绑定已成功时仍然失败。

因此，事件记录至少要区分：更新已发出、更新已接受、缓存仍有效、首包已转发、首包已收到、首个应用事务已成功。把它们压成一个“registered”状态，会让自动化在错误的层反复重试。

稳定标识产生了映射债务

RCoA 越稳定，远端越安静；远端越安静，本地映射就越重要。每次 LCoA 变化，MAP 都必须及时替换状态。若缓存仍指向旧链路，RCoA 依旧格式正确、寿命也可能尚未结束，但它所代表的可达性已经变成陈旧承诺。

这就是映射债务：一个长期可见的标识依赖短期、可变且不被远端看见的实现状态。债务本身并非错误。缺少清偿凭据才是风险。

运营系统应当能回答：当前 RCoA 由哪个 MAP 承担，映射到哪一个 LCoA，Binding Acknowledgement 的序列和时间是什么，寿命还剩多久，最近一次双向数据包在何时被观测，应用何时确认连续。缺少其中任何一项，都不应借用“地址没变”来填空。

Preference 不是健康分

MAP 信息通过 Router Advertisement 传播，包含全局地址、前缀、距离、运营者 preference 和有效期。移动节点保存这些选项，并依据规则选择至少一个 MAP。

Preference 表达政策优先级，不是实时容量。Distance 不一定是数据路径的真实跳数。非零有效期表示广告尚未声明失败，不是隧道探测结果。规范给零有效期定义了明确动作：不得再选择该 MAP，既有绑定可以视为丢失，必须改选其他 MAP；若没有替代者，就不得继续使用 HMIPv6。

“收到零就退出”不能反推成“没有零就健康”。后者需要独立的数据面证据。

旧 MAP 在切换后仍有责任

跨越 MAP 域时，RCoA 也会改变。为了减少在途包损失，节点可以向旧 MAP 更新新位置，请它把旧 RCoA 的流量转往新的 care-of address。管理员可以限制向域外转发，不过规范在一定条件下建议允许相邻域之间的过渡。

这段窗口里，连续性由多方共同承担：旧 MAP 保存临时转发状态，新 MAP 保存当前绑定，home agent 和各 correspondent node 可能尚在不同时间更新。单一“handover complete”时间戳无法描述这一过程。

需要记录旧路径最后一个包、新路径第一个包、外层绑定更新完成时间、旧转发撤销时间，以及撤销依据。旧状态撤得太早会丢包；留得太久会增加过期依赖和攻击面。退出条件必须以新路径实际工作为依据，而不是只看计时器。

小控制包通过，不代表业务包能通过

RFC 5380 明确提醒隧道对 MTU 的影响。节点与 MAP 之间双向封装；若还经过远端 home agent，可能出现双重封装。上层可用 MTU 必须扣除这些开销。

因此，Binding Update 和确认这样的小包可以成功，而更大的应用包可能失败。问题可能出在 MTU 计算、Packet Too Big 信号、过滤策略或实际路由。规范没有宣称某个生产事故已经发生，但它明确暴露了这一依赖。

只测控制面会产生“绑定完好、业务中断”的盲区。验证必须使用能代表真实负载的数据包，并保留两端和 MAP 的观测。

认证不能替代结果证明

移动节点与 MAP 的关系必须具有双向认证、完整性保护和抗重放能力。MAP 还可以配置允许的本地前缀，对来自域外的 LCoA 拒绝绑定。这些措施限定了谁能写什么状态。

它们没有证明写入后的状态已经产生业务效果。一个经过认证的 LCoA 可能不可达；一个完整性正确的更新可能遇到错误 MTU；一个合法 MAP 也可能容量不足。安全让控制回执可信，但不会自动扩大回执的语义。

身份、授权、状态接受、转发与交付必须分别记录。

多锚点仍然需要一份当前真相

RFC 7429 后来把 HMIPv6 放进分布式移动性管理的讨论中。MAP 把本地移动从远端 home agent 收回来，降低了一部分中心化信令；同时，动态锚点分配、迁移、发现、选择与上下文转移仍是需要解决的缺口。

RFC 5380 允许节点同时使用多个 MAP，给不同 correspondent node 群组分配不同 RCoA。它也禁止把一个 MAP 的 RCoA 再作为另一个 MAP 的 care-of address，因为嵌套封装会降低效率。选项增多不会自然产生一致性，反而要求每个会话明确知道当前锚点。

真正的系统记录不是“存在多个可用 MAP”，而是“这个会话、这个 RCoA、这个时刻由哪个 MAP 和哪个 LCoA 实现”。

Running-Code Primacy 的检查方法

Heng Lu 的运行代码优先原则要求把文档中的可行性与正在发生的操作结果分开。RCoA 是稳定契约；MAP 缓存、隧道与端点处理是当前实现。只有后者的观测才能证明前者此刻成立。

一条完整证据链包括 MAP 发现、选择、地址形成、绑定接受、缓存持续、数据拦截、隧道路径、端点解封装和应用结果。任何较早回执都不能冒用较晚结果的名字。

地址没有变。组织仍要证明让它成立的每一层没有失效。

来源