摘要

  • RFC 5121 要求移动终端与基站在一条链路上至多协商一种 IPv6 会聚子层；这个结果证明封装选择，不证明完整链路已经正确建立。
  • 同一终端与基站之间可以存在多个 CID；三层链路由这些传输连接以及必要时逐终端或逐业务流的隧道共同构成。
  • 可靠控制面必须分别保存能力、选择、业务流、CID、隧道、前缀、路由器通告、休眠与组播状态、MTU 和实际数据包结果。

假设监控屏上出现四个活跃 CID。最省事的模型会画出四条 IPv6 链路，再为它们分别计算利用率、健康度和地址状态。问题是，这个图可能从一开始就画错了对象。

RFC 5121 把 CID 定义为 IEEE 802.16 MAC 传输连接的标识。同一移动终端与同一基站之间可以存在多条这样的连接。IPv6 链路则是三层概念，由会递减 Hop Limit 的路由器界定，不能直接套用 IEEE 二层“链路”的含义。可计数的底层对象，并不自动拥有上层对象的语义。

一次选择只消除一种歧义

IEEE 802.16 可以通过 IP 专用的分组会聚子层承载 IPv6，也可以走 802.3/Ethernet 相关路径。终端与基站在注册阶段交换能力，建立动态业务连接时再注明该连接采用的会聚子层。RFC 5121 的范围仅限 IP CS。

双方都支持 IP CS 时，它是默认方式；双方同时支持 IP CS 与 Ethernet CS 时，规范要求使用 IP CS。无论如何，一条链路上的 IPv6 至多协商一种会聚子层。如果找不到共同方式，传输连接无法建立，主机也就不能沿该路径收发 IPv6。

这是必要的互操作规则，但它的证明范围很窄。软件包含某项能力，不等于配置启用了它；配置启用，不等于这次协商选择了它；协商选择，不等于业务流建立成功；业务流存在，也不等于分类器把某个数据包送进了正确 CID。把这些状态压成“IPv6 supported”，实际上是在删除故障归属。

规范还要求基站实现支持 IETF 为 802.16 定义的 Standards Track 封装，但允许某些模式被配置关闭。这一句已经足以否定单一“支持”字段的权威：实现能力、现场可用性、会话选择和包级使用必须分开记录。

CID 是连接凭据，不是链路身份证

IPv6 包进入 Packet CS 后，MAC 分类器根据源/目的地址、Next Header、流量类别或端口范围等属性，把它映射到具体业务流和传输连接。通用 MAC 头本身并没有一个能单独说明载荷类型的字段。换言之，实际路径依赖当时生效的分类规则与关联关系。

当接入路由器与基站共置时，面向某台终端的全部传输连接合起来构成一条链路。当二者分离时，RFC 5121 建议建立粒度不粗于逐终端或逐业务流的隧道。终端的传输连接与这些隧道合起来，才形成终端到接入路由器的点到点链路。

因此，正确的账本要能完成两种查询。给定一条终端—路由器链路，应能列出所有业务流、CID 和隧道；给定一个被抓到的 CID，又应能唯一回溯到预期终端、分类器和接入路由器上下文。如果只能数 CID，控制系统掌握的是组件数量，不是链路事实。

共用基站不产生共用前缀

多个终端可以连接同一基站，但在 RFC 5121 的点到点模型中，每台终端属于不同 IPv6 链路。每条终端/主机链路必须分配唯一前缀或前缀组，通常建议使用一个或多个 /64，并在路由器通告中设置 on-link 标志。终端若是服务多个内网主机的 CPE，也不会因此把邻近订户并入同一子网。

前缀记录必须带着链路上下文。仅仅在 IPAM 中看到一个 /64，不足以证明它给了谁。需要知道由哪个接入路由器通告、送到哪个终端上下文、携带哪些标志和有效期，并在数据包路径上验证其没有跨入别的终端。DHCP 或 AAA 前缀委派只是不同的交付方式，不改变“前缀属于哪条链路”这一问题。

重复地址检测的条件更能说明这一点。规范认为，在两个条件都成立时，对特定全局地址执行 DAD 可能是多余的：通告的前缀对该链路唯一，而且终止该链路的接入路由器没有从同一前缀为自己配置全局地址。“点到点”标签本身不是证据。如果自动化只看标签就跳过 DAD，它保存了结论，却丢掉了结论成立的前提。

地址生成规则可以变，链路事实不必跟着变

原始 RFC 要求以终端的 48 位 MAC 地址生成 modified EUI-64 接口标识，同时允许隐私扩展产生的随机标识。后来 RFC 8064 更新了 RFC 5121，建议不要把稳定链路层地址嵌入稳定 IPv6 接口标识。

这不是对点到点链路模型的撤销。它更新的是地址中 IID 的生成策略，而不是前缀与链路的归属。把设备身份、接口标识、IPv6 地址、CID 和链路主键合并为同一个字段，会让正常标准演进变成数据迁移危机。分层保存，才能在不伪造历史的前提下采用新策略。

休眠时的沉默不是健康证明

移动终端可以进入 idle 状态，此时无线链路被拆除，需要 paging 才能重新触达。频繁路由器通告会唤醒设备并消耗空口资源，因此 RFC 5121 允许远长于通常预期的通告间隔；对休眠终端，接入路由器也不应周期发送 MLD 查询。

正确的省电行为和状态丢失，从错误观察点看都可能是“没有包”。监控必须带上休眠进入事件、paging 状态、最近一次有效通告、组播成员关系及其重新确认触发器。只以控制包频率判断，会把正常休眠报成故障，也可能把失联误报为安静健康。

MTU 至少有三种现实

规范建议 IPv6 默认 MTU 为 1500 字节。若使用不同值，接入路由器必须通过 Neighbor Discovery 的 MTU 选项进行通告；Path MTU Discovery 又可能发现端到端路径上的更小限制。因此配置值、通告值和实际可通过值是三份不同凭据。

RFC 文本还留下一个值得保留状态的争议。它说 11 位 Len 字段使 MAC PDU 总长达到 2048 字节；Errata 1768 指出 11 位全一的最大值应为 2047。该勘误状态是 “Held for Document Update”，不是 Verified。严谨做法不是悄悄改数字，也不是无条件重复原文，而是同时记录原文、算术意见和程序状态。

最终判断仍由数据包给出：受控大小的探测、Packet Too Big 消息、基站与路由器边界的抓包，以及服务结果。配置表里的 1500 不会自己穿过网络。

最小共同规则，完整可追溯凭据

这套方法不要求一个中央系统统管所有层。共同部分可以很薄：选了什么封装，三层链路的两个端点是谁，哪些稳定标识把业务流、CID、隧道和前缀连接起来，以及如何导出证据让数据包验证。局部的分类策略、节能策略和自动化可以保持可替换。

关键是拒绝把早期凭据升级成后期事实。能力声明回答“可能做什么”；协商回答“双方选了什么”；业务流与 CID 回答“创建了什么”；通告与前缀回答“配置了什么”；抓包回答“发生了什么”；用户结果回答“服务是否有效”。RFC 5121 的克制不是让控制面更弱，而是让每项权力只能对自己观察到的现实负责。

来源