多播 ICMPv6 返回 conntrack 状态无效

Question

我在玩 IPv6 的多播功能。

$ ping ff02::2%wlp3s0

这通常会导致来自本地网段（维基百科 - IPv6）上的所有路由器的回声回复。所以就我而言，我的家用路由器。

但是，我发现我原来的 nftables 规则阻止了回声回复：

防止回声回复的原始 nftables 规则

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state { established, related } accept
        ct state invalid drop
        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept        
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

有了这个设置，没有回复通过。

$ ping ff02::2%wlp3s0
PING ff02::2%wlp3s0(ff02::2%wlp3s0) 56 data bytes

修复了允许回显回复的 nftables 规则

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state { established, related } accept
        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept
        ct state invalid drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

使用此设置，它起作用了：

$ ping ff02::2%wlp3s0
PING ff02::2%wlp3s0(ff02::2%wlp3s0) 56 data bytes
64 bytes from fe80::----:----:----:----%wlp3s0: icmp_seq=1 ttl=64 time=1.82 ms

CT状态无效是罪魁祸首

您可能自己已经发现，唯一的区别是一次ct state invalid drop出现在之前，一次出现在ip6 nexthdr ipv6-icmp accept之后。

因此，回声回复ping ff02::2%wlp3s0似乎有ct state invalid. （我什至用更具体的规则检查了这个并记录只是为了确保）

我的问题

回声回复的 ct 状态不应该是“相关”或“已建立”，因为它是我的回声请求的直接结果？

如果不是：为什么“正常”单播 ping ( ping 2001:470:20::2) 在这两种情况下都有效？