Mon blog

Maintenant que de nombreux FAI, dans le monde, ont déployé IPv6 et l'offrent comme service à leurs clients, il est temps de regarder ce qu'ils ont fait et de le documenter. Les auteurs de ce RFC ont donc commis un questionnaire début 2010 sur le thème « comment avez-vous déployé IPv6 », et l'ont envoyé à un certain nombres de FAI. Notre RFC 6036 résume les réponses.

Pendant longtemps, la décision de passer à IPv6 ou pas semblait ouverte. On déployait IPv6 quand, comme Nerim, on avait une clientèle techniquement exigeante, et on ne le déployait pas lorsqu'il n'y avait pas de demande des clients (le cas le plus fréquent). Mais, aujourd'hui, le business ne peut plus continuer comme avant, les adresses IPv4 étant presque épuisées. Cela laisse trois choix aux FAI (section 1 du RFC) :

• Essayer d'économiser à l'extrême les adresses IPv4, en en allouant de moins en moins aux clients (ce qui est difficile pour l'accès individuel, où il n'y a déjà qu'une seule adresse par foyer) et en essayant d'acheter des adresses IPv4 sur les marchés gris ou noirs.
• Installer de plus en plus de traduction d'adresse en étages successifs et laisser les clients déboguer les problèmes qui en résulteront.
• Déployer IPv6.

Que font aujourd'hui les FAI ? L'enquête va essayer de répondre à cette question, en se focalisant sur ce qui est de la responsabilité directe des FAI, l'adressage, le routage, la gestion, le DNS, et en excluant les applications (qui sont souvent un des freins à la migration vers IPv6).

Plusieurs RFC couvrent ce champ. Par exemple, le RFC 4029 parle du déploiement chez un FAI, et prévoit la « double pile » (v4 et v6) sur tous les équipements. Compte-tenu du retard pris et de l'épuisement des adresses v4, cela ne sera sans doute pas possible et il faut aujourd'hui envisager la cohabitation et la communication entre des machines purement v4 et d'autres purement v6. Le RFC 5211 est une vision plus générale du déploiement d'IPv6, les FAI étant juste un cas particulier. Le RFC 4779 documente le déploiement de IPv6 dans des réseaux d'accès courants comme le câble TV ou l'ADSL. Les RFC 5181 et RFC 5121 traitent, eux, des accès 802.16. Les questions de sécurité sont abordées dans le RFC 4942 ainsi que dans le RFC 4864, ce dernier se focalisant sur la protection du réseau local du client.

Les normes IPv6 de base sont assez stables (la plupart des RFC récents n'ont touché qu'aux détails) mais le travail continue activement à l'IETF, par exemple dans des domaines comme la traduction d'adresses.

Place maintenant à l'étude elle-même (section 2). Le questionnaire figure dans l'annexe B. Il a été expédié à des listes d'opérateurs comme NANOG. 31 réponses ont été reçues. Seuls les volontaires répondaient, ce qui biaise évidemment les résultats (une liste - incomplète car certains ont demandé l'anonymat - des répondants figure en section 7). Les auteurs du RFC notent que les FAI qui ont déployé IPv6 étaient probablement plus prompts à répondre. Les réponses étaient confidentielles. Les réponses agrégées figurent dans l'annexe A.

Que trouve t-on dans ces réponses ? Les répondants fournissent de l'accès à l'Internet par un grand nombre de moyens (section 2.2), xDSL, DOCSIS, Ethernet, WiMAX et bien d'autres. Sur les adresses IP utilisées, plusieurs répondants poussent le négationnismes jusqu'à dire qu'ils n'auront jamais d'épuisement des adresses IPv4, les autres répondants citant, pour leur propre pénurie, des dates entre 2010 et 2015. En 2010, plusieurs FAI en Asie - 19 % des répondants - n'ont déjà plus une seule adresse IP publique et allouent du RFC 1918 à leurs clients ; ceux-ci n'ont donc pas un vrai accès Internet. 39 % des répondants utilisent des adresses privées en interne.

42 % des répondants ont déjà une offre IPv6 (section 2.4), mais moins d'1 % de clients l'utilise. 48 % des répondants ont une telle offre en travaux, avec l'idée d'ouvrir entre 2010 et 2013 (rappelez-vous que les réponses n'ont pas été vérifiées...) Donc, 10 % des répondants, en 2010, moins d'un an avant l'épuisement de la réserve IANA, ne font rien... Le pronostic sur le dépassement d'IPv4 par IPv6 en terme de trafic varie évidemment mais tourne autour de 2015.

Quelle technique de déploiement ? 94 % des répondants ont une épine dorsale en double-pile (section 2.5). 39 % ont ou bien vont avoir un relais 6to4 (je n'ai pas vérifié si cela incluait les relais 6rd comme ceux de Free) et 16 % du Teredo. Une des questions portait sur « les systèmes qui ne gèrent pas IPv6 ». Si les gros routeurs de l'épine dorsale sont évidemment tous prêts pour IPv6 depuis très longtemps, le maillon faible concerne plutôt des systèmes plus discrets : les CPE sont le plus souvent cités mais aussi les DSLAM, les répartiteurs de charge ou des logiciels comme celui de gestion des adresses IP des clients ou bien le système de facturation. À la question de savoir si des engins comme les CPE pourraient être mis à jour, beaucoup de réponses étaient « nous l'espérons »...

Parmi ceux qui allouent des adresses IPv6, les préfixes existants vont d'un /19 à un /48 (!) et celui alloué au client va de /48 à /64 en passant par plusieurs /56 (le RFC 6177 donne des recommandations à ce sujet). Pour déléguer le préfixe du client à la CPE, les méthodes vont de la configuration manuelle à DHCPv6 et SLAAC (StateLess Address AutoConfiguration). Certains utilisent Radius ou PPPoE bien qu'ils n'aient pas de moyen standard de déléguer un préfixe.

La moitié des répondants gèrent déjà des serveurs double-pile (SMTP, HTTP, IMAP). Des systèmes internes comme la surveillance du réseau semblent également v6isés à 50 % alors que les systèmes de facturation et de compatibilité, dejà cités, ne le sont qu'à 23 %.

Comment gérer la coexistence d'IPv4 et IPv6 ? 58 % des FAI ne croient pas aux clients « fixes » purement v6. Interrogés sur la date où la dernière application purement v4 disparaitra, les réponses sont souvent du type « au moins dix ans ». Il faudra donc gérer la coexistence. Sur ce point, la section 2.5 ne montre aucun consensus sur les solutions : un traducteur du genre NAT, par exemple, ou bien d'autres mécanismes pas forcément précisés.

Certains FAI ont IPv6 en production depuis des années. Quelles expériences peuvent-ils en tirer ? La section 3 fait le point. Ceux qui ont fait le choix de la double pile native (c'est le cas de Nerim en France) en sont contents. Mais ceux ceux qui utilisent 6to4 ou 6rd aussi. La plupart des répondants estiment a posteriori que le passage à IPv6 était plutôt facile, une opération qu'ils classent dans la catégorie « comment arriver à manger un éléphant ? » (la réponse est « une bouchée à la fois »). Les difficultés rencontrées portaient sur la difficulté à convaincre certains (il existe encore des négationnistes qui, cherchant à justifier leur inaction, prétendent que l'épuisement des adresses IPv4 est un faux problème) et, naturellement, sur le fait que, comme tous les changements d'infrastructure qui n'apportent pas un bénéfice immédiat et visible, le passage à IPv6 est difficile à justifier auprès de la direction, qui ne voit que l'intérêt financier immédiat. Des problèmes moins connus sont aussi soulevés, comme l'importance d'impliquer les gens qui font le support utilisateur, puisque certaines applications mal écrites ne se rabattront pas sur IPv4 si une connexion IPv6 échoue, ce qui peut entraîner des protestations des clients.

Puisqu'on parle des problèmes, quels sont les principaux manques à l'heure actuelle, pour le FAI qui veut passer à IPv6 ? La section 4 liste les réponses faites à ce sujet :

• Les produits « bas de gamme » qui ne gèrent pas IPv6 (CPE, appliances SIP, IDS, ...). Sans compter ceux chez qui IPv6 est bogué, ou incomplet (un répondant cite le cas d'un CPE théoriquement IPv6 mais dont les fonctions de shaping ne marchaient qu'en IPv4) ou bien plus lent qu'IPv4. Dans le domaine du logiciel, si le logiciel libre n'est pas trop mal placé, beaucoup de logiciels commerciaux ne gèrent toujours pas IPv6.
• L'offre de protocoles n'est pas encore complète (et, contrairement au point précédent, celui-ci est sous la responsabilité directe de l'IETF). La section 4.2 note que les répondants estiment qu'il n'existe pas de protocoles satisfaisants pour la délégation d'un préfixe v6 à la CPE, pour les mécanismes de contrôle des pare-feux comme UPnP, pour l'allocation d'adresses IP avec PPPoE ou Radius. (À noter que les réponses sont parfois mal informées ; ainsi, la demande d'un VRRP v6 a été satisfaite dans le RFC 5798 et celle d'une indication des serveurs DNS dans les Router Advertisement dans le RFC 6106. Le problème est donc en réalité désormais un problème de mise en œuvre et de déploiement, plus de protocole. Le cas inverse arrive aussi, où le FAI qui envisage de déployer v6 n'est pas conscient des limites de certains protocoles, voir la section 4.3.)
• Enfin, des gros problèmes qui ne peuvent pas être résolus par les programmeurs ou par l'IETF demeurent : difficulté à trouver un vendeur de transit IPv6 en Amérique du Nord ou en Asie, problèmes de PMTU persistants, ...