在虚拟化数据中心为 NIC 级防火墙制定 IPv6 过滤规则时，需采用白名单策略，逐项放行维持主机正常运行所必需的流量。核心结论是：必须显式处理扩展头部、ICMPv6 关键类型、邻居发现、MLD 与 DHCPv6，并针对不同地址配置方式调整规则集。
扩展头部处理：RFC 2460 定义的标准扩展头部中，除 AH 与 ESP 外，Hop-by-Hop、Routing Header、Fragment Header 与 DestOptions 均可能在链路层被滥用。RFC 6980 对 RA Guard 规避攻击的防护有限，Check Point 等厂商产品默认拦截大多数扩展头部，Antonios Atlasis 早期研究也证实多款防火墙对扩展头部的默认行为不一。为保证策略一致，建议在规则链前端显式匹配并决定放行或拒绝，避免依赖设备默认动作。
ICMPv6 与邻居发现：类型 1–4（Destination Unreachable、Packet Too Big、Time Exceeded、Parameter Problem）必须放行，否则破坏 PMTUD 与错误反馈。Echo Request/Reply（Ping）按运维需求决定。Router Advertisement 需放行以支持 SLAAC，但需结合 RA Guard 与扩展头部过滤防范伪造。Neighbor Solicitation/Advertisement 为地址解析与 NUD 必需，必须放行。ICMPv6 Redirect 仅在受信任路由器存在时放行，否则拒绝。原文未给出具体数据。
MLD 与 DHCPv6：MLDv1/v2 报文（FF02::16、FF02::2 等组播）用于组播组成员管理，主机若运行组播应用需放行。DHCPv6 客户端需允许 UDP 546 接收来自服务器（UDP 547）的 Reply、Reconfigure 等报文；若部署有状态 DHCPv6 或 PD，则必须在入向规则中显式放行。原文未给出具体数据。
对运维工程师而言，制定 IPv6 本地过滤规则不能照搬 IPv4 经验，需按协议栈依赖关系逐项建表，并在测试环境验证扩展头部处理与邻居发现交互的完整性，才能在生产环境落地一致且可审计的白名单策略。
原文: APNIC Blog（2017-07-12）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog