Aujourd'hui, on me fait remarquer que la règle ip6tables suivante ne fonctionne pas (elle ne laisse pas passer les paquets que l'on pense avoir désignés) : ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m state --state NEW -m comment --comment RA -j ACCEPT. Évidemment, aucune erreur n'apparaît quand on pousse cette règle et il n'y a rien dans les logs lorsqu'elle est censée être activée par un paquet reçu. La même règle sans état (pas de -m state --state NEW) fonctionne.

En regardant une partie du code source (http://lxr.free-electrons.com/source/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c ), on constate que :

• Seuls les messages ICMP Echo Request et Node Information Query peuvent avoir un état NEW (lignes 120 et suivantes). En conséquence, seuls les messages ICMP Echo Reply et Node Information Reply auront un état ESTABLISHED (lignes 74 et suivantes). Donc, on peut les désigner avec une règle ip6tables comportant l'instruction -m state --state NEW,ESTABLISHED.
  
  
• Les messages ICMP Router Solicitation/Advertisement, Neighbor Solicitation/Advertisement, Multicast Listener Query/Report/Done, Multicast Listener Report v2 n'ont pas d'état dans Netfilter (lignes 63 et 225), ils ne sont pas suivis. Une règle ip6tables les concernant et comportant -m state --state XXXX ne capturera donc aucun paquet.
  
  
• J'imagine que les autres messages ICMP à but informatif comme ceux associés à la mobilité IPv6 sont gérés par les modules adéquats…
  
  
• Les autres messages ICMP (exemples : Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem, etc.) sont des messages d'erreur dixit les RFC. Ils doivent avoir un type compris entre 1 et 127 (lignes 232-233) et ils doivent être liés (relatifs) à une connexion (TCP, UDP, SCTP, etc.) en cours suivie par Netfilter (lignes 158 et 179). Donc, on peut les désigner avec une règle ip6tables comportant l'instruction -m state --state RELATED.