Mise à jour du 13 octobre 2005

Ces notes sont issues de l'expérience de TBS INTERNET¹ lors de l'ajout d'IPv6 à notre serveur principal (http://www.tbs-internet.com/) fin septembre 2005.

Rendre un serveur IPv4 compatible IPv6 nécessite quelques actions et vérifications bien ordonnées afin de rendre l'opération transparente.

Pour se faire il faut éviter quelques pièges :

• Ne pas ajouter de record AAAA sur le ou les FQDN associés au serveur avant d'avoir vérifier que tous les services utilisés via ce nom sont bien compatible IPv6.

• Se méfier du reverse DNS IPv6 (de nombreuses version de la glibc 2.3 ont été livrées avec une résolution reverse qui commencait par tester la syntaxe bitstring (expérimentale) au lieu de la syntaxe nibble, créant des lenteurs. A partir de la glibc 2.3.4, le souci ne doit plus se poser. De plus, depuis Sep 2005, ip6.int est obsolete et ne doit plus être utilisé.²)

On considère dans ce document que la partie réseau IPv6 de la machine est opérationnelle. Sinon voir :

http://www.tbs-internet.com/lab/ipv6/initscripts_srv_ipv6.html

Ou pour avoit toutes les bases :

http://mb.ioflow.co/howto-ipv6-linux/

ou en anglais :

http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/

1. Faire un inventaire des ports écoutés avant migration

1.1. Tableau d'inventaire

Utilisez netstat -ltnp et -lunp pour recueillir les données. Voici un extrait.

Ici notez que " :: " correspond à une adresse globale v4+v6 et que " 0.0.0.0 " correspond à l'adresse globale v4.

Utilisez ensuite un tableau de cette forme :

Ajoutez autant de colonnes sur la gauche que de services présents sur la machine. Si la machine dispose de plusieurs IP publiques, ajoutez également des lignes par le bas. Utilisez un code de couleur pour indiquer visuellement le niveau d'avancement.

Il est judicieux de décomposer les services en 2 catégories : ceux qui écoutent un port loopback (bouclage) uniquement (et qui n'ont pas besoin d'être v6-fiés immédiatement) et ceux qui écoutent sur un port externe au serveur.

Ce tableau vous donnera ainsi la feuille de route : où vous en êtes, ce qu'il reste à faire.

Vous pouvez voir le résultat d'un travail d'audit sur un de nos serveurs (qui dispose de plusieurs adresses IP publiques) ici :

http://www.tbs-internet.com/lab/ipv6/ovh2-ports-v4v6.sxc.pdf

1.2. Prévoir le firewall

Cet inventaire et son tableau ont aussi d'autres vertues...

C'est l'occasion de vérifier que votre firewall v4 est bien en concordance avec les ports ouverts. Nous recommandons l'utilisation d'un firewall directement sur le serveur, même si vous avez déjà un firewall global au niveau de votre organisation. Sous Linux, nous utilisons Shorewall.

Prévoyez dès maintenant de firewall v6. Encore plus que pour v4, nous recommandons la mise en place d'un firewall en local sur la machine, afin de contrôler au mieux les accès, et de prendre en compte les droits finement (IPv6 a une notion de lien-local). Nous pensons qu'avec IPv6, la décentralisation des firewall sur chaque poste est une évidence, afin de ne pas brider les communications sur une passerelle d'entreprise avec des règles aussi restrictives que celles appliquées de nos jours avec le NAT.

Nous militons pour une architecture décentralisée (filtrage sur chaque poste) pilotée depuis une plateforme d'administration d'entreprise (think global, act local). En soit, c'est probablement l'une des révolutions les plus importantes d'IPv6 pour les architectes réseau.

Sous Linux, il n'existe que peu de choix de firewall actuellement³. Nous utilisons 6wall : un clone de Shorewall qui permet la mise en place facile d'un firewall stateless⁴.

2. Migrer les applications

Grace au travail de l'étape 1, vous connaissez les logiciels ou services à v6-fier.

Evidement, c'est spécifique à chaque application, mais le plus souvent il s'agit simplement d'upgrader vers la version la plus récente, et si ce n'est pas le défaut, activer l'IPv6. On pourra se référer à ce tableau de l'état de compatibilité des applications :

http://www.deepspace6.net/docs/ipv6_status_page_apps.html

Voici quelques notes résultant de notre expérience.

2.1. Apache 2

Si vous passez de Apache 1 à Apache 2, il suffira de rajouter des lignes Listen pour binder l'IPv6 et de rajouter dans votre déclaration de VirtualHost l'adresse IPv6 à coté de l'adresse IPv4. Exemple :

Il faudra également mettre à jour les ServerAlias de vos VirtualHost pour y ajouter les nouveaux FQDN correspondants à l'accès IPv6, si vous en créez. Voir la fin du document.

ATTENTION : si vous utilisez " HostnameLookupsOn " en global, vérifiez que votre reverse DNS IPv6 fonctionne bien (voir point en introduction). Sachez aussi que sauf glibc récent, le reverse IPv6 fait deux requêtes reverse au lieu d'une en IPv4 : la première sur ip6.arpa et la seconde sur ip6.int⁵.

Pensez aussi à mettre à jour vos règles d'accès basées sur des IP (dans votre configuration ou dans des .htaccess). Vous voudrez probablement rajouter les entrées correspondantes.

Notez aussi qu'en terme de performances, si vous utilisez des règles d'accès basés sur des noms tld, gtld ou tout autre FQDN, que cela entraînera une résolution DNS reverse, même si vous avez " HostnameLookups Off ". Attention donc aux :

Si vous avez développé des applications qui manipulent des adresses IP, ou des bases de données qui journalisent ces IP, vérifiez qu'elles sont prêtes a accueillir des données plus longues (qu'elles soient binaires (128 bits) ou au format texte (39 caractères ou 44 avec le masque)).

Et le logo ? Vous allez sûrement vouloir faire savoir à vos utilisateurs qu'ils se connectent en IPv6. Ou afficher un message spécifique. Comment faire ? Le plus simple à notre avis est de faire exporter par apache une variable spécifique si la connexion est v6. Pour se faire utilisez :

Il faudra remplacer " 2001 " par le premier quartet de l'adresse IP de votre serveur. Ainsi si l'IP locale de votre serveur commence par ce nombre, Apache exportera la variable " IPV6 " et vous pourrez alors facilement décider de l'action à exécuter. Par exemple avec du SSI :

Ou encore avec du PHP :

Concernant PHP : l'équipe de développement a indiqué que PHP 5.0 est compatible IPv6. Mais nous n'avons pas conscience de soucis particulier sous PHP 4.3 ou 4.4 mis à part si l'on souhaite faire des connexions réseau programmées avec PHP.

2.2. OpenSSH

La mise en route de OpenSSH est des plus triviales ! Par défaut, le fichier de configuration /etc/ssh/sshd_config contient la directive :

C'est l'adresse d'écoute globale, V4 et V6. Votre OpenSSH est prêt ! Pensez tout de même à vérifier vos fichiers authorized_keys* qui pourraient comporter des ACL basés sur l'IP. Il convient de les modifier pour prendre en compte le format des IPv4 mappées. Par exemple, l'ancienne écriture :

devient après modification du format et ajout de l'IPv6 correspondante :

2.3. Bind

La mise en place d'IPv6 dans Bind est aussi triviale que pour OpenSSH. Tout du moins avec une version récente car de notre expérience, il faut Bind 9.3 ou supérieur pour avec un fonctionnement nominal. L'activation d'IPv6 se fait en ajoutant la directive :

Ceci permettra de fonctionner en mode résolveur et en mode serveur de zone en protocole IPv6.

Bind tente également d'obtenir des résolutions DNS via IPv6 dès qu'il détecte la disponibilité d'une IPv6 globale sur le serveur.

L'autre considération avec Bind sera d'ajouter des informations relatives à IPv6 dans les zones servies par votre serveur. Ceci n'a pas à être fait dès maintenant, mais à la fin de la V6-fication de votre serveur, voir la fin de ce document.

Notons que pour faire un serveur de zone IPv6, il est souhaitable que le record host de ce serveur dispose de glue IPv4 et IPv6. Ceci est disponible pour les .fr mais pas pour les .com. Vérifiez auprès de votre registrar.

2.4. Messagerie

On ne rentrera pas ici dans les détails de tel ou tel logiciel, car il en existe trop.

Pour les serveurs de messages (POP3, IMAP), il suffit d'avoir la version supportant IPv6 et de l'activer !

Pour les MTA, il convient de distinguer les 2 fonctions : la réception et l'envoi de messages. Suivant le MTA que vous utilisez, ces 2 fonctions peuvent être différenciées.

L'activation de la réception nécessite la mise en place d'au moins un record MX qui résolve en IPv6. Il conviendra de compléter les ACL basées sur des IPv4 pour par exemple autoriser les mode relais à ses propres utilisateurs, ou pour d'autres droits.

Pour l'envoi de messages, le MTA peut nécessiter une activation du mode IPv6. A partir de là, le MTA tentera de délivrer ses messages en IPv6 avec les serveurs MX compatibles.

2.5. MySQL

A ce jour⁶ MySQL n'indique pas clairement son support IPv6. Visiblement en 4.0, il n'y a pas de support IPv6. Nous n'avons pas pu déterminer clairement si la version 4.1 ou 5.0 la supporte.

3. Compléter le DNS

Avant de compléter le DNS, réfléchissons. Reprenons notre tableau et notamment les lignes " global " et correspondantes aux IP externes.

Parcourez chaque ligne. Si toutes les intersections sont vertes dans le sens entrant (IN), on peut V6-fier le DNS de la ligne en question. On va donc pouvoir ajouter une ligne à l'existant :

Nous recommandons également de créer des records spécifiques à chaque protocole afin de pouvoir configurer des clients avec l'adresse qui va bien. Cela permet de gérer les cas spécifiques, notamment les clients qui seraient gênés par l'apparition d'IPv6.

Par exemple, on configurera l'accès MySQL avec l'adresse " .ipv4. " et non pas avec l'adresse générique " nom-du-service ".

Exemple quasi réel :

Tant que les intersections de notre tableau d'audit ne sont pas verts, ne mettez pas de record AAAA sur le nom canonique du serveur, sauf à avoir modifié les clients du service non v6-fié pour utiliser un FQDN v4 only. Dans l'exemple ci-dessus avec MySQL, modification des fichiers de configuration php pour utiliser le " .ipv4. ".

Vous voici donc au terme de l'opération et votre serveur devrait être opérationnel en IPv6. Il continuera à fonctionner en IPv4 et permettra désormais aux utilisateurs IPv6, que l'on espère de plus en plus nombreux, de trouver du contenu nativement en IPv6.

Aussi nous ne saurions trop vous encourager à proposer, dès maintenant, vos sites web en IPv6, et à le faire savoir à vos visiteurs.