不容忽视的 IPv6 安全考量

人们很容易把 IPv6 看作 IPv4 的直接替代品，只是地址空间更大而已。但从安全角度看，有几处真实存在的差异值得弄清楚，而不能想当然地认为 IPv4 的一切都原封不动地适用。

拦截名单必须单独构建，而不只是更长

IPv6 有自己的私有、环回和链路本地地址段，其结构与 IPv4 中对应的地址段不同。如果某项安全检查只会解析和过滤 IPv4 地址段，那么 IPv6 一侧的这些地址会被悄无声息地全部放行。这并不是因为 IPv6 不够安全，而是因为针对它的等效防护根本就没有被构建出来。

IPv4 映射地址：容易忽略的盲区

IPv6 有一种把 IPv4 地址嵌入 IPv6 地址的写法，例如 ::ffff:127.0.0.1，它指向的环回地址与普通的 127.0.0.1 相同，只是用 IPv6 形式书写。如果一项检查能正确过滤 IPv4 环回地址，却不会展开这种嵌入形式，就会放行一个在功能上与本应被直接拦截的地址完全等同的地址。

• 任何依据拦截名单检查解析结果的系统，都需要为 IPv6 单独编写完整的逻辑，而不能假设 IPv4 的规则会自动适用。
• IPv4 映射的 IPv6 地址需要先展开，并专门按 IPv4 规则检查，而不能把它们当作不透明的 IPv6 地址来评估。
• 双栈系统（大多数现代系统都是）需要对两种检查一视同仁地应用，因为攻击者只会选用检查较弱的那个地址族。

这并不是回避 IPv6 的理由：更广泛的采用总体上是好事，IPv6 特有的攻击面本身也并不比 IPv4 更大。真正要做的，是确保处理地址的安全逻辑确实针对两个地址族构建并测试过，而不是只针对其中一个，把另一个当作事后补上的附属品。

NAT64 引入了值得了解的第二层转换

一些纯 IPv6 网络使用 NAT64 和 DNS64，让其客户端仍能访问只支持 IPv4 的互联网：DNS64 会为只有 A 记录的域名动态合成一条 AAAA 记录，把 IPv4 地址嵌入一个特殊前缀（64:ff9b::/96 是众所周知的默认值），而 NAT64 则在网络边缘把发往该合成地址的流量转换回真实的 IPv4。这是一种合理且有用的机制，但这意味着，落在这个特定范围内的地址并不是一个可以单独评估的原始 IPv6 地址，而是“披着 IPv6 外衣的 IPv4”，需要像 IPv4 映射地址一样先展开，再按 IPv4 规则检查。

测试安全逻辑，实际上就是要测试两个地址族

自动化测试很容易在不知不觉中偏向 IPv4：大多数示例域名、大多数测试数据、大多数快速的手动检查，都默认使用 IPv4，而没有人有意做出这个决定。对任何需要解析并过滤地址的功能来说，测试套件的可信度只取决于它对 IPv6 的覆盖程度：针对上述私有、环回和链路本地地址段的用例，针对 IPv4 映射地址的用例，以及针对 NAT64 式合成地址的用例，都应当有各自明确的断言，而不是只靠“它大概也是一样的”。地址处理类的安全代码，恰恰属于这样一类逻辑：未经测试的代码路径和有缺陷的代码路径无法区分，直到攻击者先一步发现其中的差别。