Geekfault

IPv6 en pratique

Dans la vraie vie, tout le monde est plus ou moins égal face à IPv6. Les plus chanceux (abonnés Nerim, FDN, Free dans une moindre mesure) ont de l’IPv6 natif (ou presque) directement sur leur interface WAN (fût-elle xDSL ou FTTH). Pour les autres, il faudra utiliser des méthodes basées sur les tunnels, comme le 6to4 ou Teredo (article à venir …).

Quoi qu’il en soit, un abonné recevra de son FAI (ou de son fournisseur de tunnel) un préfixe de la forme 2001:7a8:b285::/48. Le FAI se charge de router tout ce préfixe vers la ligne de l’abonné, et ce dernier se débrouille pour faire le reste. Comme il n’y a en général qu’une seule ligne chez l’abonné, par laquelle passe tout le trafic, il faut un routeur.

Fabuleux, vous en avez probablement déjà un. Mais est-il seulement IPv6-aware ? À moins d’avoir une FreeBox, la réponse est probablement “non” : le support IPv6 dans ce genre de matériels est pour le moins anecdotique. Le geek IPv6-friendly va donc se monter une petite bécane sous Linux (ou flasher son WRT54GL par exemple) avec le support IPv6 compilé dedans. On peut certainement faire pareil avec *BSD, mais je ne parle pas de ce que je ne connais pas 🙂

Le routeur fait en général au moins trois choses chez un particulier, quatre si on a du bol :

• il fournit la connexion au WAN, fût-ce par ADSL, câble, fibre ou autre ;
• il route les paquets, c’est quand même pas banal, avouez-le ;
• il aide à se configurer les postes clients ;
• en option, il fait du filtrage.

Pour la connexion au WAN, le plus facile reste l’IPv6 natif. En effet, en ajoutant simplement une ligne contenant ipv6 , à son /etc/ppp/options, pppd se charge de négocier une IPv6 link-local avec le pair d’en face.

Pour le routage, c’est là encore désarmant de simplicité :

Félicitations : le routeur est maintenant capable de relayer les paquets à qui de droit. Bien sûr, libre à vous d’ajouter ça au sysctl.conf pour faciliter les choses.

Il faut ensuite informer les postes clients de la disponibilité d’IPv6 et à les configurer. On peut bien sûr utiliser l’auto-configuration stateful, avec DHCPv6, ou stateless, dont on a parlé au chapitre précédent. Cette dernière méthode requiert l’utilisation sur le routeur de radvd, pour Router ADVertisement Daemon. Après l’avoir installé selon la méthode de votre choix (apt-get, emerge, tar …), il vous faudra éditer le fichier de configuration (en général /etc/radvd.conf ou approchant), dont voici un example :

Le fichier comporte au moins une définition d’interface ; ici, il s’agit de l’interface br-lan d’un WRT54GL sous OpenWRT. Dans l’ordre, les 4 premières options servent à indiquer que le service doit envoyer des RA et répondre aux sollicitations sur l’interface, les RA sont au maximum espacés de 60 secondes, et le MTU annoncé sur le lien est fixé à 1492 (option désactivée ici, mais très utile si vous êtes en PPPoE sur l’interface WAN). Vient ensuite une définition de préfixe, ici de longueur 64, qui ne contient ici aucune option particulière : les options par défaut conviendront parfaitement.

Enfin, pour le filtrage, il existe sous Linux le pendant IPv6 d’iptables, tout simplement nommé ip6tables. Tout comme en IPv4, il est possible de faire du conntrack en IPv6, moyennant un kernel “pas trop vieux” (ça ne marchera pas avec un 2.4 par exemple). La principale différence avec l’IPv4 est bien sûr l’absence du NAT : tout ou presque se passera directement dans la table FORWARD 🙂

Nous n’avons pas encore parlé de la configuration des postes clients, et il y a une raison très simple à cela : par défaut, il n’y a rien à faire. Du moment que le routeur est configuré correctement, l’OS client saura s’auto-configurer comme nous l’avons vu au chapitre précédent. Comme IPv6 est utilisé en priorité chaque fois que c’est possible, l’accès aux services disponibles se fera automatiquement et de façon transparente pour l’utilisateur final.