容器作为“微型机”大规模部署，每个实例拥有独立网络栈与 IP 地址，天然需要海量地址空间。IPv6 的 /64 子网提供近乎无限的地址，配合无状态地址自动配置与路由通告，可消除中心化 IP 管理与 NAT 层级，实现容器间直连。但作者实测表明，三大公有云至今仍无法提供满足容器编排所需的 IPv6 能力集，导致生产落地受阻。
IPv6 与容器的原生契合：作者在生产环境运行全 IPv6 容器集群数年，从上游获取 /48 块，划分一条子网用于物理机互联，每台物理机再分得一个 /64，容器直接从中取址。路由层面仅用 radvd 发布路由通告，未来可平滑迁移至任意支持 IPv6 的标准路由协议。这种拓扑让任意两个容器直接通信，无需维护主机端口映射表，服务发现复杂度大幅降低，运维体验显著优于 IPv4+NAT 架构。
公有云 IPv6 支持的现实断层：截至 2018 年，AWS、Azure、GCP “三大厂商”均不具备面向容器的完整 IPv6 特性。支持程度从完全缺失（仍有厂商零 IPv6 支持）到“仅把 IPv4 地址换成冒号格式”不等。中小厂商同样薄弱，通常仅下发少量单个 IPv6 地址，甚至不知 IPv6 存在。原文未给出具体厂商名单与测试指标。
缺失的关键能力：DHCP 前缀委派：若云实例能通过 DHCPv6-PD 动态请求 /64 甚至更大前缀，容器编排器即可自动完成子网划分与地址分发，无需人工干预。这一标准特性在公有云控制面普遍缺位，迫使工程师退回隧道、代理或双栈 NAT 等变通方案，抵消了 IPv6 原生简化网络拓扑的核心优势。
对网络工程师而言，公有云 IPv6 能力缺口意味着：在混合云或多云场景下，容器网络仍被迫依赖 IPv4 覆盖网与 NAT，无法享受无状态自动配置、去中心化寻址与直连路由带来的运维红利。选型时需实测云厂商是否支持 DHCPv6-PD、路由通告转发及 /48 以上前缀下发，否则 IPv6 容器化将停留在实验室阶段。
原文: APNIC Blog（2018-03-22）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog