一句话概括版本：极空间的防火墙阻断了 DHCPv6（Stateful 模式）通信，导致 Solicit 报文可发出但无法接收路由器返回的 Advertise 报文（UDP, 546），最终导致设备 IPv6 地址分配失败。
一、极空间防火墙
极空间防火墙提供通用规则与网卡规则两种类型，匹配优先级依次为通用规则优先，其次为网卡规则；在同一类型中，规则排序越靠前，优先级越高。网卡规则相较通用规则，支持配置默认行为（允许或拒绝访问），更适合作为底层规则。按照常规防火墙使用习惯，采用白名单放行策略：将网卡规则默认设置为“拒绝访问”，并在通用规则中放行公网常用端口。
二、IPv6 地址丢失与分析
在完成极空间防火墙配置后不久，设备出现了 IPv6 地址异常丢失的情况。家庭内网环境采用 DHCPv6 有状态分配（Stateful DHCPv6）并结合 DHCPv6 白名单模式。
初步排查外围设备后，问题指向极空间本地网络故障：
sudo dhclient -6 -v bond0 |
日志持续输出 XMT: Forming Solicit, ... ms elapsed.，表明极空间能够正常发送 DHCPv6 Solicit 请求，排除发送路径异常。然而未见任何 RCV: 开头的日志，说明未接收到来自路由器的 Advertise 响应报文，初步判断响应包在入栈前已被拦截。
进一步检查防火墙规则，在 INPUT_ZFIREWALL 链末尾发现如下条目：
DROP all bond0 * ::/0 ::/0 |
该规则明确丢弃所有从 bond0 接口进入的数据包，正是由网卡规则中的默认拒绝策略生成，症结所在。
值得注意的是，极空间 NAS 同时启用了两套防火墙系统：INPUT_ZFIREWALL 与 ufw6-*，形成“双重过滤”。尽管在 ufw6-* 链中存在如下规则：
ACCEPT udp * * fe80::/10 fe80::/10 udp spt:547 dpt:546 |
用于放行 DHCPv6 通信，但由于 INPUT_ZFIREWALL 链优先执行，路由器返回的 DHCPv6 响应包在到达系统网络栈前已被丢弃。通常，合理的防火墙设计应包含有状态检测（Stateful Inspection）机制，允许已建立连接及相关连接（ESTABLISHED, RELATED）流量通过。而极空间当前规则体系缺乏此机制。
三、解决方案
为解决该问题，需手动添加一条静态放行规则，以确保 DHCPv6 响应包能够顺利入栈。
协议：“UDP”；
端口类型：“目标端口”；
端口：“546”；
发起端 IP：“所有” or ”
:: ~ ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff”。