Aux alentours de Noêl (2012 hein :P), j'ai décidé de passer mes "serveurs" en IPv6. Ce billet est donc une sorte de retour d'expérience/un avis et surtout pas un tutoriel. Il y a suffisamment de tutoriels sur les sujets que je vais aborder. Il n'y aura pas non plus trop d'explications théoriques ni de prêches "pourquoi il est temps de se bouger pour IPv6" (il est évident que c'est uniquement pour voir la tortue dansante sur http://www.kame.net/).
Table des matières
Ressources
Si vous débutez avec IPv6, je vous recommande la lecture suivante : Yet Another Reference for Delivering IPv6 to the Next Generation.
Vous y trouverez, entre autres, des explications détaillées des notions que je vais employer dans ce billet sans forcement les expliciter.
Passer à IPv6
Utiliser IPv6, ce n'est pas difficile, ça ne nécessite pas des connaissances d'un niveau extraordinaire en réseaux informatiques. Il n'y a même pas besoin de comprendre tout ce que je vais raconter ici car c'est de la garniture. Pour débuter par la pratique, il y a une montagne de tutoriels sur Internet, il suffit de les suivre et, ensuite, si l'intérêt vient, de se documenter pour comprendre petit à petit.
Pour moi, il y a clairement deux étapes :
- Fournir une connectivité v6 à une machine. Cette étape est, comme je me tue à le répéter depuis le début de ce billet, facile. Sauf si comme moi, vous étudiez les différents "modes de fourniture", "for ze lulz".
- Dans le cas d'un serveur, il convient également de vérifier que les services (httpd, dnsd, smtpd, ...) soient bien disponibles sur IPv6 comme sur IPv4. Cette étape est juste de la rigolade : la documentation de tous les logiciels serveurs sérieux indiquent, clairement et de manière évidente, la directive de configuration "kivabien". La palme revient à Dovecot (serveur POP/IMAP) dont la directive de configuration pour du dual-stack est indiquée dans le fichier de configuration lui-même, il n'y a plus qu'à décommenter la ligne.
La connectivité
Différence entre les méthodes de transition
Il y a plusieurs modes de fourniture d'adresses v6 : natif (votre opérateur réseau vous alloue un bloc), 6in4 (typiquement un tunnel chez Hurricane Electric), 6to4 (passerelles qui encapsulent de l'IPv6 dans de l'IPv4), Teredo (encapsulation au niveau UDP), ... En terme de qualité du service, il est souvent admis que l'on a : natif > 6in4 > 6to4 > Teredo.
Certaines sont obsolètes ou sur le point de l'être (6to4), d'autres méthodes existent mais ne conviennent pas à ma situation (je veux une connectivité IPv6 sur mes serveurs disposant d'une connectivité v4 uniquement).
Dans la suite, je ne parlerai que de natif, de 6in4 et de 6to4.
Natif
Bon, on va faire ça rapidement car ça se configure le plus simplement du monde. Chez OVH, il suffit de regarder quel bloc vous a été attribué dans le manager et ensuite d'ajouter quelque chose comme ça dans votre /etc/network/interfaces :
iface eth0 inet6 static
address 2001:41d0:1:2345::1
netmask 64
up ip -6 r a 2001:41d0:1:23FF:FF:FF:FF:FF dev eth0 && ip -6 r a default via 2001:41D0:1:23FF:FF:FF:FF:FF
|
address doit avoir pour valeur une des IPs dans le bloc qui vous a été attribué. Le masque est fixe : /64. La passerelle est celle du /56 qui englobe votre /64. Donc réseau /56 complété par « ff ». Pour pouvoir l'ajouter, comme elle est hors de votre /64, il faut ajouter une route (première partie de la commande passée à « up ») puis ensuite ajouter la définition de la passerelle par défaut elle-même (deuxième partie de la commande). Attention : le guide OVH concernant l'IPv6 n'est pas à jour. Voir ce post sur le forum OVH anglais.
Bien sûr, si vous avez un bridge (LXC, tout ça), la première ligne sera "iface br0 inet6 static" 😉 .
ÉDIT du 03/08/2013 à 18h45 : mise à jour de cette sous-partie pour apporter quelques précisions. Fin de l'édit
Pour appliquer les modifications :
service networking restart |
Ici les avantages et inconvénients sont vite vus : c'est tout pareil que d'avoir une IPv4.
6in4
Là aussi, c'est plutôt simple : il suffit de se créer un compte chez un tunnel broker (Hurricane Electric, SixXS, Freenet6, ...) et d'utiliser les paramètres qu'il nous donne pour configurer notre réseau. Vu le plus grand bien que j'ai entendu d'Hurricane Electric, j'ai décidé de prendre mon tunnel chez eux.
Pour la configuration, je vous recommande : Tunnelled IPv6 via Hurricane Electric on Ubuntu.
Dans mon cas, avec le bloc qui m'a été attribué et en utilisant le POP de Londres, ça donne ça dans mon /etc/network/interfaces :
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:1f08:751::2
netmask 64
remote 216.66.80.26
local 87.98.183.12
endpoint any
up ip -6 route add 2000::/3 via ::216.66.80.26 dev he-ipv6
up ip -6 addr add 2001:470:1f09:751::1/128 dev he-ipv6
down ip -6 route flush dev he-ipv6
|
he-ipv6 est un label choisi arbitrairement.
Le piège bateau qui peut vous arriver est de confondre l'adresse v6 de sortie du tunnel, qu'il faut mettre dans addresss et l'adresse que vous allez réellement attribuer à la machine, qui doit être prise dans le bloc qui vous a été attribué. Le débbogage n'est pas évident : une inversion semblera fonctionner, surtout depuis d'autres tunnels HE mais cela ne fonctionnera pas depuis partout, tout le temps.
Pour appliquer les modifications :
service networking restart |
Au niveau des avantages et des inconvénients :
Cela ajoute un saut de réseau et une dépendance supplémentaire. Quand le POP d'Hurricane Electric sur lequel vous êtes tombe en rade, comme en septembre/octobre dernier pour celui de Paris, votre connectivité IPv6 tombe. On nuancera en disant qu'HE semble sérieux (donc les pannes n'arrivent pas tous les jours) et qu'après tout, il ne s'agit que d'une solution de transition librement consentie.
Ce qui me dérange plus, c'est la centralisation du réseau que cela induit. Rappelez-vous : Internet est un réseau acentré : il n'y a jamais eu de centre ni dans la technique ni dans les usages. Pour les usages, c'est loupé (Google, Facebook, ...) donc si l'on se met aussi à le faire techniquement ... Tout le monde se concentre chez un, deux, maximum trois fournisseurs de tunnels qui accumulent mécaniquement du pouvoir.
Avant, je dégainais aussi l'argument "vie privée" mais j'ai dû retrousser chemin. Certes, nos données (votre demande et la réponse de mon serveur) passent chez HE mais, même sans HE, et même en v4, nos données transitent par quelques fournisseurs de connectivité avant d'atteindre leur destination. C'est le principe d'Internet. Les a-t-on choisi ? Certainement pas : cela dépend des accords passés par notre opérateur réseau et par des choix automatiques de la route optimale. Au moins, HE est un choix librement consenti. Pour la protection de la vie privée, il faut utiliser le chiffrement.
6to4
Là,je pense qu'on atteint des sommets de simplicité : pas d'allocation à avoir ni de compte à créer chez un tiers.
Pour la mise en pratique, on cherche notre bloc préfixé par 2002. Dans mon cas, avec mon IPv4 (ipv6calc se trouve dans le package Debian du même nom) :
ipv6calc --action conv6to4 87.98.183.12 No input type specified, try autodetection...found type: ipv4addr No output type specified, try autodetection...found type: ipv6addr 2002:5762:b70c:: |
Ensuite, on édite le fichier /etc/network/interfaces. Dans mon cas, cela donne :
auto tun6to4
iface tun6to4 inet6 v4tunnel
address 2002:5762:b70c::1
netmask 48
local 87.98.183.12
endpoint any
gateway ::192.88.99.1
|
tun6to4 est un label choisi arbitrairement. La gateway et le netmask sont fixe. L'adresse est choisie dans le bloc. Attention, il y a des morceaux de configuration erronées qui traînent sur le web et comme pour un tunnel, le débbogage n'est pas forcement évident.
Pour appliquer les modifications :
service networking restart |
Au niveau des avantages et des inconvénients :
Le préfixe 2002::/16 et l'adresse 192.88.99.1 sont anycastés. Donc on ne sait jamais sur quelle instance on va atterrir. Et cela peut varier d'un échange réseau à un autre. L'effet de concentration visible avec les tunnels 6in4 est moins accentué. C'est cela qui m'a intéressé dans cette solution.
La conséquence du point précédent est que la connectivité dépend d'une infrastructure qu'on ne maîtrise pas : le relai n'est-il pas malveillant ? Ne va-t-il pas mettre en danger ma vie privée ? Et si un opérateur fait, volontairement ou non, une fausse annonce des préfixes alors qu'il n'a pas de relai 6to4 opérationnel ? Et si le relai choisi automatiquement est victime de congestion, quid de ma connectivité ?
Une autre conséquence est que le trafic est asymétrique. À l'aller, vos paquets passent par le relai le plus proche de vous (au sens réseau). Au retour, ils passeront par le relai le plus proche de la destination. Ces relais peuvent donc être différents et de qualité inégale. Le chemin ne sera donc pas optimal : s'il n'y a pas de relai proche de la destination ? Et si ce relai n'est pas également le plus proche de vous ?
J'ai remarqué que l'initialisation d'une communication en utilisant 6to4 est clairement plus longue qu'avec de l'IPv6 natif ou qu'avec un tunnel. J'ai aussi remarqué que la qualité est toute relative. J'ai testé ma connectivité sur le top 10 des sites web les plus fréquentés (donc pas sur des infrastructures isolées/possiblement mal-configurées) sans tenter le diable : des pertes de paquets surviennent à une fréquence relativement haute.
En 2011, les RFC décrivant 6to4 ont fait l'objet d'une demande de passage à un statut "historique". Même si cette demande n'a pas aboutie, cela montre un désintérêt certain pour cette méthode de transition. De ce fait, on peut estimer qu'aucun nouveau relai 6to4 ne sera mis en place, que les relais en place ne seront plus la priorité de leurs administrateurs donc ils ne seront plus maintenus "au top". On peut supposer aussi que le nombre de relais à même déjà diminué et qu'il y a donc autant de concentration de trafic avec 6to4 qu'avec un tunnel 6in4.
J'ai aussi remarqué que le préfixe 2002::/16 ne semble pas prioritaire. Soit une machine source qui sélectionne l'adresse de destination de la cible qu'elle veut atteindre. Si elle a le choix entre une IPv6 6to4 et une IPv4, elle choisira l'IPv4. Je ne dis pas que mes tests et mon panel sont représentatifs mais du coup, ça me jette tout de même un froid vis-à-vis de 6to4. Après, il y a sûrement moyen de prioriser le choix du préfixe 6to4 (dans le fichier /etc/gai.conf pour la libc sous GNU/Linux, par exemple) mais cela se fait sur le client. Comme la masse n'éditera pas ce fichier, l'intérêt de 6to4 en prend un coup.
Question de découpage
On pourrait se demander pourquoi je n'ai pas utilisé une partie de mon bloc IPv6 natif by OVH pour adresser le serveur de ce blog. La réponse se fait en plusieurs temps.
D'une part, j'ai plusieurs domaines différents, qui n'ont pas grand chose en commun. On considère qu'un /64 est le minimum syndical pour un utilisateur final. Je considère chacun de mes domaines comme un utilisateur final. Chacun doit donc avoir son bloc v6. Une autre manière de le formuler est de dire que cela préserve un minimum de cohérence entre l'adressage des domaines si l'on considère, qu'un /64 v6 est l'équivalent d'un /32 v4. Même si l'autoconfiguration (qui ne marche plus au délà d'un /64) n'est pas activée chez OVH, ne pas découper au delà d'un /64 permet de former son esprit aux bonnes pratiques.
D'autre part, cela met en place une sorte de "redondance" (je ne sais pas comment qualifier ça, en fait) : chez OVH, j'ai déjà eu des problèmes sur un bloc précis (un bloc plus joignable ou partiellement). Néanmoins, cela dure très peu de temps. En utilisant des IPv4 dans des blocs différents, on peut diminuer le risque. En utilisant des bloc v6 différents, c'est le même principe.
Enfin : tester les différentes méthodes pour de vrai "for ze fun". Les labos (Netkit ou autres) ne permettent pas de se rendre compte de tous les aspects d'une méthode. Et surtout car si l'on doit attendre un déploiement natif pour se former en pratique, on ne s'en sortira pas !
Configuration des services
Pour vous montrer que la configuration pour un usage en double pile des grands logiciels serveurs massivement utilisés est facile, je vais vous donner quelques directives de configuration :
- OpenSSHd : AddressFamily any;
- BIND : listen-on { interface v4/toute interface v4; }; listen-on-v6 { interface v6/toute interface v6; };
- Unbound : interface: interface-v4 interface: interface-v6
- Apache HTTPD : Listen 80 / Listen 443 par défaut suffisent.
- Postfix : inet_protocols = ipv4,ipv6 dans main.cf
- Dovecot : listen = *, [::]
- Ngnix : listen [::]:80 default_server ipv6only=off;
- ejabberd : inet6, dans les blocs ejabberd_c2s et ejabberd_s2s_in,
Il faudra redémarrer le service pour prendre en compte la modification.
Pensez au DNS
La première chose à faire est d'indiquer que vous utilisez IPv6. Cela se fait en ajoutant les enregistrements AAAA qui vont bien dans votre zone. Ces enregistrements fonctionnent pareil que les A mais pour IPv6. Si le serveur faisant autorité sur votre zone passe aussi en v6, et que son nom fait partie de la zone (exemple : ns1.guiguishow.info fait partie de la zone guiguishow.info), pensez à soumettre un glue record AAAA à votre zone parente sinon une résolution totalement en v6 de votre zone sera impossible.
Reverse v6
La deuxième chose sera d'affecter la bonne valeur à vos reverse. Vous savez, le truc qui dit que 87.98.183.12 c'est viki.guiguishow.info (et qui est bien différent de la requête qui dit viki.guiguishow.info c'est 87.98.183.12). Il faut le faire aussi en v6. C'est surtout utile pour les vérifications faites par les serveurs SMTP mais c'est une bonne pratique en général.
Tunnel 6in4
Pour les tunnels Hurricane Electric, HE vous délègue la zone reverse qui correspond au bloc qu'ils vous ont attribué. Pour la mise en œuvre, tout est expliqué ici : Reversing IPv6 Addresses to Names.
Pour vous aider à trouver votre zone reverse/vos enregistrements PTR, je vous conseille l'usage d'ipv6calc (package du même nom sous Debian). Exemple :
ipv6calc --addr2ip6_arpa 2001:470:1f09:751::1 No input type specified, try autodetection...found type: ipv6addr 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.5.7.0.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. |
Là, c'est un enregistrement complet. Pour votre zone, comme HE vous attribue, pour simplifier, un /64, il s'agira des 4 derniers groupes de 4 chiffres (64 bits pour la partie réseau de l'adresse donc 4 groupes de 4 chiffres hexadécimaux). Ici : 1.5.7.0.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. est la zone reverse.
6to4
Pour le 6to4, vous pouvez aussi obtenir une délégation de la zone reverse, ce que je trouve "énorme" ! Il suffit d'aller à l'adresse suivante : https://6to4.nro.net/, qui est gérée par les différents RIR. On remarquera tout de suite que le certificat x509 a expiré en juillet 2012, ce qui tend à confirmer 6to4 comme une solution de seconde zone.
Pour obtenir la délégation, il faut aller sur ce site avec une IPv6 préfixée par 2002::. Sur un serveur, on pourra donc avoir recours à du bon vieux ssh port forwarding :P.
Vous devez remplir le formulaire en indiquant, entre autres, l'adresse d'au moins 2 serveurs de noms qui distribue la zone indiquée. Pour la suite, je ne peux pas vous aider plus puisque j'ai été confronté à une erreur aléatoire : soit je n'avais aucun message en retour, soit une erreur m'informant que je n'ai pas l'autorisation pour effectuer l'opération demandée ... Dommage car j'ai trouvé le concept formidable.
IPv6, ce futur
Je reste dubitatif sur le déploiement massif d'IPv6 dans les années à venir ... Après tout, les vieux routards vous diront que cela fait déjà quasiment 10 ans qu'on leur dit qu'IPv6 c'est demain.
Je vais tenter d'argumenter (peu de noms car je fais des statistiques, pas une distribution de blâmes) :
- Les principaux FAI commerciaux français ne sont pas prêts (pour les particuliers). Orange ne prévoit rien avant mi-2014. Bouygues devait proposer du v6 sur son offre ADSL fin 2012 mais ça semble encore repoussé. Free fait du 6rd (évolution 6to4) sur l'ADSL et du natif sur la fibre. Dans les 2 cas, il s'agit d'un /64. Autrement dit, mettre la freebox en bridge serait impossible sans manipulations crades (proxy NDP, tout ça) et cela amène d'autres problématiques (contrôle du terminal vers Internet, liberté, ...). SFR propose aussi du v6 encapsulé (un /64). FDN fournit un /48. Pour les autres, je vous laisse chercher.
- Les opérateurs en général, pas seulement les FAI, sont-ils prêts ? Pour me donner une idée, j'aime bien regarder la table de routage des Internets et comparer le nombre d'annonces v4/v6, le nombre d'AS v4/v6, la moyenne du nombre d'annonces v4/v6 par AS, ... C'est par ici que ça se passe. Normalement, ça se passe de commentaires.
- Les services ne sont pas disponibles en IPv6. Et là, je ne parle pas du top 10 des sites web les plus visités mais de la réalité, des sites que je visite très régulièrement. Faisons un tour rapide : les sites web des 3 banques que je connais : raté ; les sites web principaux des 3 universités que je connais et qui ont une formation orientée réseaux informatiques : raté ; les serveurs de mails que j'utilise : 1/5 = raté ; Parmi la centaine de flux RSS que je consulte tous les jours (et j'ai un profil atypique de passionné d'informatique qui consulte des sites de passionnés donc il y a un biais statistique ...) : 1/4 = raté. Et parmi ces sites web disponibles en IPv6, environ 3/4 le sont par un tunnel 6in4 comme Hurricane Electric. Note : pour les calculs relatifs aux flux RSS, je n'ai pas pris en compte les sites utilisant feedburner mais n'ayant pas une v6 pour leur site. Les contenus n'ayant rien en commun mais étant hébergés sur une même plateforme (Blogger, Twitter, ...) ne sont pris en compte qu'une seule fois.
- Mais IPv6, c'est aussi des gens pour le déployer et le maintenir. Je ne suis pas compétent pour estimer les personnes compétentes "en IPv6" sur le marché du travail. Par contre, je suis compétent pour "évaluer" l'offre de formation française. Une école d'ingénieurs en informatique ne le fait toujours pas étudier au niveau bac+4. Au-delà, je ne sais pas. Un IUT informatique ne le fait pas étudier en DUT Informatique. Une fac ne le fait toujours pas étudier au niveau bac+4 d'une formation informatique, au-delà, je ne sais pas. Une autre fac le fait étudier au niveau bac+4. Une dernière fac le fait étudier en M2 d'une formation orientée réseaux informatiques. Je n'ai pas eu de retour sur les formations professionnelles de type L3 Pro/Master Pro. Je sais que certains nuanceront ce point en disant que l'enseignement supérieur donne les bases et que c'est à l'étudiant de faire sa veille technologique. Je n'ai pas de problèmes avec ça. Juste pourquoi ne pas donner les bases v6 ?
J'ai du oublier des paramètres et des biais statistiques mais ça me semble toujours aussi mal parti pour qu'Internet soit majoritairement IPv6 demain. Au moins je ne suis pas tout seul à penser ça dans mon coin : IPv6, je t’aime mais tout le monde s’en fout chez iMil.