I was playing arround with the Multicast feature of IPv6.

$ ping ff02::2%wlp3s0

This should normally result in an echo-reply from all the routers on your local network segment (Wikipedia - IPv6). So in my case my home router.

However, I found out that my original nftables rules where blocking the echo-replies:

Original nftables rules preventing echo-reply

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;
    }
}

With this setup no reply came through.

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

Fixed nftables rules which allowed echo-reply

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;
    }
}

With this setting it worked:

$ 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 state invalid is the culprit

You might have figured out by yourself that the only difference is that once ct state invalid drop comes before ip6 nexthdr ipv6-icmp accept and once afterwards.

Thus, the echo reply to ping ff02::2%wlp3s0 seems to have the ct state invalid. (I even checked this with a more specific rule and logging just to make sure)

My Question

Shouldn't the ct state of the echo-reply be "related" ore "established", since it's a direct result of my echo-request?

If not: Why is a a "normal" unicast ping (ping 2001:470:20::2) working in both cases?