摘要

  • APNIC 于 8 月 24 日转载的一篇家用路由器指南称，WAN 口只要出现私网 IPv4，就“必然”是 CGNAT；这比界面读数能够支持的结论多走了一步。
  • RFC 1918 私网、RFC 6598 共享地址、家中双重 NAT 和 DS-Lite 的控制边界各不相同。可靠判断至少要同时记录地址类别、公网出口、上游网关和 IPv6 接入方式。

屏幕显示的是近邻，不是整条路径

PublicNow 留存的页面显示，这是一篇面向 MikroTik 家用用户的客座文章。文章建议读者查看路由器 WAN 状态，并把该地址与外部网站看到的公网地址作比较。这一步本身合理。问题出在随后那句绝对判断：WAN 口的私网 IPv4“永远意味着 CGNAT”。

路由器只能报告自己这一跳获得了什么地址。若该地址属于私网范围，可以确认它不会以原样在公共 IPv4 互联网上路由，也说明数据包出网前还会经过转换或封装。但这一项观察无法回答三个关键问题：边界在哪里、由谁控制，以及这到底是普通 IPv4 转换，还是以 IPv6 为承载的过渡机制。

最常见的反例就在用户家里。运营商提供的光猫或网关仍处于路由模式，自己持有公网 IPv4，再向用户的第二台路由器分配 192.168.1.2。第二台设备的 WAN 读数确实是私网地址，但这只能证明本地双重 NAT，不能证明运营商网络内存在 CGNAT。把前一台设备切换为桥接模式，结果就可能改变。

不同地址，只能支持不同强度的判断

RFC 1918 指定 10/8、172.16/12 和 192.168/16 用于私有网络。这些地址可以出现在运营商转换设备之后，也可以出现在住宅、园区或托管网络内部。它们说明地址不具备全球唯一性，却不说明谁执行了转换。

RFC 6598 则为服务提供商共享地址设置了 100.64/10。WAN 口落入这一网段，是比 RFC 1918 更强的运营商级共享线索；但单张状态页仍不会展示用户到公网地址的映射、端口行为、日志保留期，也不能证明被检查的接口就是接入服务的实际交界点。

DS-Lite 又是另一条路径。RFC 6333 描述了把 IPv4 流量通过 IPv6 隧道送往 AFTR 的部署方式。用户同样可能无法直接接受 IPv4 入站连接，但决定性证据是 IPv6 隧道与 AFTR 配置，不是某一个 IPv4 字段看起来像私网。

因此，一份可复核的最小诊断记录应包含：WAN IPv4 的完整数值及所属地址段；同一时刻由外部端点看到的公网 IPv4；被检查路由器之前是否还有网关；原生 IPv6、隧道与 AFTR 状态；注明协议、端口和时间的受控入站测试；以及与工单或产品编号相连的运营商说明。RFC 6888 对运营商级 NAT 的映射和过滤行为提出了要求，也再次说明：CGN 不是靠一个地址字段就能完整描述的设备类别。

区域注册管理机构的转载会放大确定性

独立存档页面 标明文章为客座投稿，观点不必然代表发布方。这能厘清作者归属，却不会自动修正技术表述。读者在区域互联网注册管理机构的信息环境中看到这句判断，往往会给予它高于个人博客的可信度。

Heng Lu 提出的最小初始规范方法正适用于此：先只固定证据能够支撑的最小结论，再把下一项判断条件写清楚。他对运行代码和可观察行为的强调，也要求把界面读数变成一次测试的起点，而不是终点。

原指南的实用提醒并没有因此失效：不少共享地址用户确实无法按通常方式开放 IPv4 入站服务。尚未确定的是原因。更严谨的一句话应当是：“私网 WAN 地址说明上游还有一道地址边界；CGNAT 是需要进一步验证的一种可能。”

信源