Je me mets ça de côté parce que j'en ai marre de le retrouver de tête à chaque fois (et d'oublier des règles à chaque fois) :

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment RA -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m comment --comment NS -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m comment --comment NA -j ACCEPT
-A INPUT -p udp --sport 546 --dport 547 -m comment --comment DHCPv6 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m comment --comment ping6 -j ACCEPT
COMMIT

Un jeu de règles de filtrage minimaliste pour IPv6, au format ip6tables-save (restaurable au boot avec netfilter-persistent).

Il est nécessaire d'autoriser les messages ICMPv6 Router Advertisement (RA) afin de prendre connaissance du ou des routeurs de sortie du réseau car cette information n'est plus distribuée via DHCP comme c'était le cas en IPv4.

Il est nécessaire d'autoriser les messages ICMPv6 Neighbor Solicitation (NS) afin de répondre aux demandes de résolution IP->MAC d'une de nos adresses IPv6, prérequis à tout échange réseau. Équivalent d'une requête ARP en IPv4.

Il est nécessaire d'autoriser les messages ICMPv6 Neighbor Advertisement (NA), qui sont les réponses aux NS afin de :

• Gérer les cas de redondance VRRP/CARP du routeur de sortie. Lors d'un basculement d'un routeur physique à un autre, il y aura émission de messages NA non sollicités donc sans état dans Netfilter donc qui ne passeront pas la première règle du jeu de règles ci-dessus ;

• Gérer le cache des associations MAC<->IPv6. En effet, pour établir une communication vers l'extérieur, il y aura un échange (RS-)RA afin de prendre connaissance des routeurs de sortie. L'adresse locale au lien et la MAC du routeur de sortie sont incluses dans le message RA. L'information sera mise en cache sur ta machine. Le cache expire. Ta machine enverra des messages NS afin de prendre connaissance de la MAC du routeur. Le routeur répondra. Ces messages RA ne sont pas reconnus/attrapés/mappés par Netfilter comme faisant partie d'une communication déjà établie ou relative à une communication déjà établie (probablement car les IP source et destination ne correspondent pas entre la question et la réponse à cause de l'utilisation du multicast et qu'il ne semble ne rien y avoir d'autre dans ICMPv6 pour créer un état) donc ils n'entreront pas sur notre machine via la première règle du jeu de règles ci-dessus. Donc la communication sera interrompue pendant plusieurs 10aines de secondes… … … jusqu'à ce que le routeur de sortie, ayant son cache qui expire, n'émette un NS (qui est autorisé à entrer sur notre machine par notre 4e règle de filtrage) qui permettra de renouveler notre cache (puisqu'il y a IP source et MAC source du routeur dans ce message ICMPv6 ;) ), permettant ainsi à la communication de reprendre jusqu'à la prochaine expiration et ainsi de suite.

  • Ces coupures imprévisibles et récurrentes peuvent faire croire à une perte de paquets quelque part sur le réseau alors qu'il n'en est rien ! Quelques éléments pour identifier ce problème de configuration du pare-feu : 1) un ping6 retourne un message de la forme « From icmp_seq=1 Destination unreachable: Address unreachable » ; 2) une capture réseau montrera une très forte proportion de message NS-NA entre ta machine et le routeur ; 3) un watch ip -6 n sh montrera un cycle anormal du cache MAC<->IPv6 c'est-à-dire beaucoup de longs passages par les états « INCOMPLETE », « FAILED » et « PROBE ».

Autoriser DHCPv6 permet de récupérer des informations complémentaires (serveurs DNS récursifs suggérés, serveurs NTP suggérés, etc.) aux RA sur les réseaux qui sont équipés d'un serveur DHCPv6.