RÉSEAU OSIRIS
CENTRE RÉSEAU COMMUNICATION

Migration des services vers IPv6

Préambule

On ne le dira jamais assez : pour publier l'adresse IPv6 d'une machine dans le DNS, il faut que tous les services accessibles par des clients IPv6 soient v6-ifiés.

Autrement dit, si votre serveur est presque complètement v6-ifié, qu'il reste un service n'acceptant pas de connexions IPv6, et que vous avez des clients v6-ifiés, ceux-ci ne réussiront généralement pas à se connecter à votre serveur. Exemples typiques (vécus) :

vous avez un serveur Web, vous publiez son adresse IPv6, mais la configuration n'est pas actualisée pour accepter les connexions IPv6. Vos clients IPv6 n'arriveront donc pas à accéder à vos pages.
votre serveur héberge le service POP, avec une implémentation non encore v6-ifiée. Vos clients utilisant IPv6 ne pourront pas relever leur courrier.

Il importe donc que tous les services soient v6-ifiés avant que l'adresse IPv6 soit publiée dans le DNS. Une solution transitoire consiste à publier l'adresse IPv6 sous un autre nom (par exemple crc.u-strasbg.fr et crc6.u-strasbg.fr) pour tester les services IPv6 un par un, avant de supprimer définitivement le nom crc6 et d'ajouter l'adresse IPv6 au nom officiel.

Le DNS

La migration des serveurs DNS est décrite dans une page séparée.

Le relayage de messagerie

Le relayage de messagerie pour l'ensemble d'Osiris s'effectue sur deux serveurs (mailhost1.u-strasbg.fr et mailhost2.u-strasbg.fr). La configuration, basée sur le kit Jussieu, n'a été modifiée que pour inclure les deux lignes (dans un fichier d'inclusion du kit) :

O DaemonPortOptions=Family=inet
O DaemonPortOptions=Family=inet6

Attention : la première ligne est indispensable. Elle est par défaut si aucune option n'est spécifiée, mais cette valeur par défaut disparaît si une option est spécifiée. Donc, si la deuxième ligne ligne est spécifiée, il faut explicitement activer la famille inet.

Piège : Depuis le passage en IPv6 de tous les relais de messagerie Osiris, un problème est apparu. Le symptôme en est que certains clients SMTP externes ne peuvent plus nous joindre :
test@xxx.u-strasbg.fr... Connecting to ns1.u-strasbg.fr. via esmtp...
test@xxx.u-strasbg.fr... Connecting to ns2.u-strasbg.fr. via esmtp...
test@xxx.u-strasbg.fr... Deferred: No route to host
Diagnostic : cas typique d'un îlot IPv6 non connecté au reste de l'Internet IPv6. Concrètement, le client SMTP dispose d'une adresse IPv6 par défaut, et il essaye de se connecter en IPv6 sur nos relais de messagerie ns1 et ns2. N'ayant pas une adresse routée sur l'Internet, le client ne peut donc pas joindre ns1 et ns2.
Par exemple, pour désactiver ce comportement sur un système AIX, il faut créer un fichier /etc/netsvc.conf contenant :
	    hosts = local, bind4
	

La politique en vigueur sur Osiris concernant les règles anti-spam spécifie que toute machine Osiris ayant une adresse (IPv4) non enregistrée dans le DNS ne peut envoyer de courrier aux relais. Cette politique est valide avec le Kit Jussieu sans modification pour IPv6.

Amélioration du Kit Jussieu à réaliser : il faut pouvoir spécifier une adresse IPv6 dans le fichier ListeNoire afin de permettre à des sites de pouvoir autoriser des subnets entiers.

Piège : Depuis le passage en IPv6 de tous les relais de messagerie Osiris, les clients autoconfigurés en IPv6 (parfois sans le savoir) ne peuvent plus envoyer du courrier, même si leur adresse IPv4 est correctement publiée dans le DNS.

Les serveurs et VRRP

Le service DNS et le service SMTP bénéficient d'une redondance grâce au protocole VRRP, comme décrit lors des Jres 2003. La migration et ses conséquences est décrite dans une page séparée.

L'hébergement des boîtes aux lettres

Le service d'hébergement des boîtes aux lettres a été v6-ifié le vendredi 14 mai 2004. Le logiciel utilisé (courier-imap) étant compatible IPv6 depuis longtemps, l'opération s'est déroulée sans problème (ajout d'une adresse IPv6, des filtres adéquats et publication dans le DNS).

Le service de « Webmail » est compatible IPv6 depuis le 29 juillet 2004 Pour cela, le serveur Apache 2 a dû être installé.

Le serveur FTP

Le serveur FTP d'Osiris a été migré le 13 octobre 2004. Pour cela, il fallu attendre une version compatible IPv6 du logiciel proftpd.

L'adaptation de la configuration de ce logiciel pour IPv6 n'a pas été très simple, il a fallu ajouter la ligne (magique) :

SocketBindTight On

Enfin, le service HTTP d'accès aux archives a nécessité la migration vers le serveur Apache 2.

Serveur du CRC

Le serveur du CRC remplit quelques fonctions pour la communauté Osiris (serveur Web, applications pour les correspondants réseau, base de données).

Les principales applications concernées sont :

Service	Logiciel	V6-ification	Commentaire
SGBD	PostgreSQL	(depuis trop longtemps pour qu'on s'en souvienne)	Pas de problème à signaler
Web	Apache	28 octobre 2004	Étant donné la complexité des serveurs et des applications hébergées, une attention toute particulière a été portée à cette migration.
LDAP	OpenLDAP	reste à faire	Le serveur LDAP n'est pas un service ouvert à l'extérieur du CRC. Sa migration n'est pas critique tant que les clients internes (qui sont en même version) ne supportent que IPv4.
NetBIOS	Samba	reste à faire	Le serveur NetBIOS n'est pas un service ouvert à l'extérieur du CRC. Sa migration n'est pas critique tant que le système des clients Windows internes ne supporte que IPv4.
NFS	NFS	reste à faire	La version 4 de FreeBSD ne supporte pas les clients NFS. Au 29 octobre 2004, seules trois stations (en FreeBSD 5) pourraient potentiellement utiliser IPv6 pour NFS, la migration vers IPv6 n'est pas jugée critique, compte-tenu de la lourdeur de la migration du serveur vers FreeBSD 5, prévue en 2005.
Impression	CUPS	reste à faire	Le serveur CUPS n'est pas un service ouvert à l'extérieur du CRC. Sa migration n'est pas critique.
Sauvegardes	Amanda	reste à faire	Ce service n'est pas un service ouvert à l'extérieur du CRC. Sa migration n'est pas critique tant que les clients (tous dans la même version que le serveur) ne savent pas utiliser IPv6.
Messagerie	wu-imap	abandonné	Étant donné que ce logiciel ne supportait pas IPv6 à la date de la décision, les boîtes aux lettres des personnels du CRC ont été progressivement migrées (entre le 6 octobre et le 6 décembre 2004), vers la machine d'hébergement des boîtes aux lettres (voir plus haut).

Pendant la période transitoire pendant laquelle tous les services critiques n'étaient pas migrés, l'adresse IPv6 n'était pas publiée dans le DNS sous le même nom (crc) que l'adresse IPv4, mais sous un nom différent (crc6).

La publication de l'adresse IPv6 sous le nom crc est effective depuis le 6 décembre 2004.

RÉSEAU OSIRIS CENTRE RÉSEAU COMMUNICATION