mjhjmtu

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 "normal" unicast ping (ping 2001:470:20::2) working in both cases?