Maintenant que le HTTPS est presque partout, qu’en est-il de l’IPv6 ?

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Let’s Encrypt a été lancé le 12 avril 2016 dans le but d’aider et d’encourager les sites à activer HTTPS partout (on parle parfois de SSL partout, même si le Web adopte progressivement TLS comme protocole de prédilection). Fin février 2017, l’EFF (à l’origine de l’initiative) estimait que la moitié du Web était désormais chiffrée. Bien entendu, tout cela n’est pas uniquement imputable à l’EFF et à Let’s Encrypt. Après tout, je dispose de données bien antérieures à cette date indiquant qu’une majorité des clients de F5, de l’ordre de 70 %, avaient activé HTTPS sur leurs services destinés aux utilisateurs. Il est donc évident que HTTPS était déjà pris en charge avant le lancement de l’initiative de l’EFF, mais compte tenu du nombre considérable de certificats* émis, cette initiative a indéniablement obtenu des résultats mesurables.

Le 11 septembre 2006, l’ICANN « a ratifié une politique mondiale relative à l’attribution des adresses IPv6 par l’Internet Assigned Numbers Authority (IANA) ». Bien que la norme elle-même ait été ratifiée de nombreuses années auparavant (une dizaine d’années), elle n’avait pas vraiment de portée significative en l’absence d’une politique régissant l’attribution de ces adresses. Mais dès 2006, la transition vers IPv6 était prise au sérieux. Après tout, le Web se développait, l’usage du mobile explosait et les adresses IPv4 disponibles étaient en voie d’épuisement.

Nous avions besoin d’IPv6, sinon pour sa sécurité renforcée, du moins pour son espace d’adressage étendu, qui nous permettrait de prendre en charge des milliards d’appareils et d’objets connectés.

Et pourtant, le taux d’adoption est catastrophique. Songez que le « cloud » est né à une époque où IPv6 était déjà disponible. Malgré cela, il a fallu attendre la fin de l’année 2016 pour qu’Amazon AWS et Microsoft Azure activent IPv6 dans leurs offres cloud d’instances de calcul.

Cela a conduit certains à déplorer que, si nous pouvons déployer le HTTPS presque partout en si peu de temps, pourquoi le pourcentage de sites prenant en charge l’IPv6 reste-t-il aussi faible ? Google estime que 16,06 % des utilisateurs ont accès à l’IPv6 (ce qui est intéressant à comparer à la prise en charge par les fournisseurs de services, telle que suivie par le World IPv6 Launch) alors que seuls 10 % des sites web (selon W3C Techs) le prennent en charge.

Pour être tout à fait honnête, HTTPS n’était pas une nouveauté. L’EFF se contentait d’encourager les gens à activer ce qui était déjà à leur portée et de leur en donner les moyens. HTTPS bénéficie d’une large prise en charge, est bien compris et parfaitement éprouvé. Il serait donc peut-être plus juste de le comparer à une norme plus récente présentant des inconvénients similaires, comme l’incompatibilité avec les normes antérieures, à l’image de HTTP/2.

En mai 2015, une nouvelle version d’un standard incontournable du Web a été ratifiée : HTTP/2. Comme IPv6, elle est incompatible avec les versions précédentes. Contrairement à l’initiative « SSL Everywhere », la prise en charge d’IPv6 ou de HTTP/2 ne se résume pas à obtenir un certificat et à activer HTTPS sur vos serveurs web ou votre infrastructure. S’il est vrai que le passage de HTTP à HTTPS peut être perturbant — notamment pour votre infrastructure réseau —, il ne l’est pas autant que le passage à IPv6 ou à HTTP/2.

La migration vers de nouveaux protocoles fondamentaux nécessite une approche transitoire, qui consiste à prendre en charge simultanément les anciens et les nouveaux protocoles jusqu’à une date ultérieure. Cela implique une « double pile » pour chaque appareil susceptible d’acheminer du trafic. Pour certaines organisations, il s’agit d’un travail herculéen ; pour d’autres, d’un véritable cauchemar architectural. Tout comme les logiciels accumulent une dette technique, les réseaux accumulent une dette architecturale, et il est probable que les « intérêts » de cette dette architecturale rendent difficile l’élaboration d’un argumentaire solide en faveur de l’adoption d’IPv6. Après tout, ce n’est pas comme s’il s’agissait d’une obligation. Les activités se poursuivront même si vous ne prenez pas en charge IPv6.

Mais est-ce vraiment le cas ?

Rappelons qu’à l’origine, HTTP/2 devait obligatoirement utiliser TLS/SSL. Cela a suscité quelques protestations et cette exigence a finalement été rendue facultative. Les éditeurs de navigateurs n’en ont toutefois tenu aucun compte et n’ont pris en charge HTTP/2 que via TLS/SSL, imposant ainsi de fait cette exigence à tout le monde. Fin 2015, Google a commencé à favoriser les sites compatibles HTTPS dans les résultats de recherche. Puis, en 2016, Apple a pris des mesures similaires en imposant à toutes les applications natives d’utiliser App Transport Security, contraignant là encore, dans les faits, à passer au HTTPS.

En résumé, la prise en charge du protocole HTTPS a été imposée par les acteurs côté client.

Pour l’instant, il n’existe aucune exigence similaire concernant IPv6. Nous avons tous assisté à l’épuisement des adresses IPv4, mais cela n’a eu que peu ou pas d’impact. Personne ne ressent donc (encore) de réelle urgence à entreprendre une transition potentiellement perturbatrice et coûteuse. Mais à mesure que de nouveaux objets apparaissent, il est tout à fait possible qu’ils finissent par être commercialisés avec une prise en charge exclusive d’IPv6. Les objets sont de petite taille et leur puissance de traitement est limitée. Dans l’Internet des objets, la simplicité est de mise. C’est l’une des raisons pour lesquelles de nombreux appareils IoT délaissent HTTP au profit de MQTT : ce protocole est plus léger, plus rapide et plus efficace que son encombrant cousin du Web. Il en va de même pour la prise en charge simultanée d’IPv4 et d’IPv6. Comme ces deux protocoles sont incompatibles, la plupart des appareils prennent en charge l’un ou l’autre. Et tôt ou tard, ils en choisiront un, et tout le monde s’empressera de le prendre en charge.

Même si ce n’est pas le cas, les adresses IPv4 disponibles aujourd’hui permettent de prendre en charge moins de 20 % des 20 milliards d’appareils qui, selon les prévisions, devaient être utilisés d’ici 2020 (Gartner). IPv6 peut en prendre en charge bien plus encore que les prévisions plus ambitieuses de Cisco, qui tablaient sur 50 milliards d’appareils. Et cela ne concerne que l’IoT.

Le cloud pose lui aussi problème, car il ne peut pas acheter suffisamment d’adresses IPv4 pour répondre aux besoins de sa clientèle croissante. Si l’IaaS doit se développer comme prévu, les fournisseurs de cloud doivent impérativement passer à l’IPv6. C’est sans doute en partie ce qui a poussé Amazon et Microsoft à franchir le pas.

Tout cela signifie qu’un facteur contraignant finira inévitablement par imposer la prise en charge d’IPv6. Il pourrait s’agir de l’IoT ou du cloud lui-même. Il pourrait aussi s’agir de l’effet combiné et extrêmement perturbateur des deux sur votre entreprise. Quoi qu’il en soit, nous devrons effectuer cette transition à un moment ou à un autre, et mieux vaut toujours ne pas avoir à le faire dans l’urgence. Nous avons eu largement le temps de résoudre les problèmes liés à IPv6, et il existe aujourd’hui sur le marché plus qu’assez de solutions prenant en charge une approche à double pile pour amorcer la transition. Si ce n’est pas encore fait, il est donc temps d’envisager sérieusement d’activer IPv6, avant d’y être contraint par les objets dont les entreprises ont besoin pour poursuivre leur croissance.

* Oui, nous pourrions nous pencher sur le nombre de certificats apparemment frauduleux et sur les risques qu’il y a à les distribuer aveuglément comme des bonbons, mais c’est un autre sujet, que nous aborderons une autre fois.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie