环境
- ImmortalWrt 25.12-SNAPSHOT，x86_64，内核 6.12.92
- 双 WAN + mwan3 负载均衡，OpenClash fake-ip，NAT6 (masq6=1)
- 局域网 ULA 地址，NAT6 转换成原生 IPv6 出口
现象
局域网设备用 IPv6 访问国内站点（淘宝、B站、百度等真实 IPv6 地址）完全卡住，收不到任何响应数据。关闭 oaf 应用过滤后恢复。
路由器自身用原生 IPv6 访问同样的站点一切正常。国外站点也正常（走 OpenClash tproxy，不经过 NAT6）。IPv4 不受影响。
排查过程
怀疑过 NAT6、mwan3、PMTU 黑洞、conntrack，最后定位到 oaf。
conntrack 对比：
oaf 开启时：
mark=4001 下行 18 包 15.6KB 后停止 → CLOSE_WAIT
mark=3014 同上
oaf 关闭后：
mark=1024 下行 89 包 106KB → TIME_WAIT
1024 是 mwan3 正常的 0x400，4001/3014 是 oaf 在上面又写了低位。oaf.ko 里有 ct->mark = %x 的逻辑。
每个失败连接下行都精确卡在 18 包 / 15.6KB 左右，刚好是 TLS 握手的数据量。TCP 握手和 TLS 握手的小包能过，之后的数据段过不去，上行一直重传，最后服务器超时发 FIN。
排除其他因素：关 fullcone6 无效，客户端 MTU 降到 1280 无效，ICMPv6 PTB 没被防火墙挡，IPv4 完全正常。
分析
oaf.ko 注册了 NFPROTO_IPV6 的 netfilter hooks，对 IPv6 转发包做 DPI 检查并写 ct->mark，这个过程干扰了 NAT6 转发流量，导致 TLS 握手后的数据段无法正常通过。
期望
修复 IPv6 NAT6 转发流量的处理问题。
环境
现象
局域网设备用 IPv6 访问国内站点（淘宝、B站、百度等真实 IPv6 地址）完全卡住，收不到任何响应数据。关闭 oaf 应用过滤后恢复。
路由器自身用原生 IPv6 访问同样的站点一切正常。国外站点也正常（走 OpenClash tproxy，不经过 NAT6）。IPv4 不受影响。
排查过程
怀疑过 NAT6、mwan3、PMTU 黑洞、conntrack，最后定位到 oaf。
conntrack 对比：
oaf 开启时：
oaf 关闭后：
1024 是 mwan3 正常的 0x400，4001/3014 是 oaf 在上面又写了低位。oaf.ko 里有
ct->mark = %x的逻辑。每个失败连接下行都精确卡在 18 包 / 15.6KB 左右，刚好是 TLS 握手的数据量。TCP 握手和 TLS 握手的小包能过，之后的数据段过不去，上行一直重传，最后服务器超时发 FIN。
排除其他因素：关 fullcone6 无效，客户端 MTU 降到 1280 无效，ICMPv6 PTB 没被防火墙挡，IPv4 完全正常。
分析
oaf.ko 注册了 NFPROTO_IPV6 的 netfilter hooks，对 IPv6 转发包做 DPI 检查并写 ct->mark，这个过程干扰了 NAT6 转发流量，导致 TLS 握手后的数据段无法正常通过。
期望
修复 IPv6 NAT6 转发流量的处理问题。