Maintenant que HTTPS est presque partout, qu’en est-il d’IPv6 ?

Let's Encrypt a été lancé le 12 avril 2016 dans le but de soutenir et d'encourager les sites à activer HTTPS partout (parfois appelé SSL partout, même si le Web évolue progressivement vers TLS comme protocole préféré). Fin février 2017, l’EFF (qui a lancé l’effort) estime que la moitié du Web est désormais cryptée . Mais tout cela n’est certainement pas imputable à l’EFF et à Let’s Encrypt. Après tout, j’ai des données bien antérieures à cette date qui indiquent qu’une majorité de clients F5 ont activé HTTPS sur les services orientés client, de l’ordre de 70 %. Il est clair que les gens soutenaient HTTPS avant que l’EFF ne lance ses efforts, mais étant donné le nombre important de certificats* qu’il a émis, cet effort n’est pas sans succès mesurable.

Le 11 septembre 2006, l’ICANN a « ratifié une politique mondiale pour l’attribution d’adresses IPv6 par l’Internet Assigned Numbers Authority (IANA) ». Bien que la norme elle-même ait été ratifiée de nombreuses années (comme une décennie) auparavant, sans une politique régissant l'allocation de ces adresses, elle n'était pas vraiment significative. Mais à partir de 2006, nous avons pris au sérieux notre transition vers IPv6. Après tout, le Web se développait, le mobile explosait et les adresses IPv4 disponibles diminuaient jusqu’à disparaître.

Nous avions besoin d’IPv6 non seulement pour sa sécurité renforcée, mais aussi 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 lamentable. Considérez que « le cloud » est né à une époque où IPv6 était disponible. Il a pourtant fallu attendre fin 2016 pour qu’Amazon AWS et Microsoft Azure activent IPv6 dans leurs offres cloud pour les instances de calcul.  

Cela a conduit certains à se plaindre que si nous pouvons obtenir HTTPS presque partout en si peu de temps, pourquoi voyons-nous encore un si petit pourcentage de sites prenant en charge IPv6 ? Google estime que 16,06 % des utilisateurs sont compatibles IPv6 (ce qui est intéressant lorsqu'on le compare au support des fournisseurs de services tel que suivi par le World IPv6 Launch ), mais seulement 10 % des sites Web ( selon W3C Techs ) le prennent en charge.

Pour être juste, HTTPS n’était pas une nouveauté. L’EFF encourageait simplement et autonomisait les gens pour qu’ils puissent exploiter ce qui était déjà à leur portée. HTTPS est bien pris en charge, bien compris et parfaitement conçu. Il serait peut-être plus juste de le comparer à une norme plus récente, présentant des inconvénients similaires, comme l’incompatibilité avec les normes précédentes, comme HTTP/2.

En mai 2015, une nouvelle version d’une norme Web incontournable a été ratifiée : HTTP/2 . Comme IPv6, il est incompatible avec les versions précédentes. Contrairement à « SSL Everywhere », la prise en charge d’IPv6 ou de HTTP/2 ne se résume pas simplement à l’acquisition d’un certificat et à l’activation de HTTPS sur vos serveurs ou infrastructures Web. S'il est vrai que le passage de HTTP à HTTPS peut être perturbateur (il peut avoir un impact sur votre infrastructure réseau ), il ne s'agit pas du même niveau de perturbation que celui provoqué par IPv6 ou HTTP/2.

Le passage à de nouveaux protocoles fondamentaux nécessite une approche transitoire, qui nécessite la prise en charge simultanée des anciens et des nouveaux protocoles jusqu’à un certain point futur. Cela signifie des « doubles piles » pour chaque appareil à travers lequel le trafic peut circuler. Il s’agit d’un effort herculéen pour certaines organisations et d’un cauchemar architectural pour d’autres. Tout comme les logiciels engendrent une dette technique, les réseaux engendrent une dette architecturale, et il est probable que les « paiements d’intérêts » sur cette dette architecturale rendent difficile la constitution d’un dossier valable en faveur de l’adoption d’IPv6. Après tout, ce n’est pas comme si c’était une exigence ou quoi que ce soit. Les activités continueront si vous ne prenez pas en charge IPv6.

Ou le fera-t-il ?

Rappelons qu’à l’origine, HTTP/2 devait nécessiter TLS/SSL. Il y a eu quelques grognements et finalement cela a été rendu facultatif. Les créateurs de navigateurs ont ignoré cela avec désinvolture et ont uniquement fourni la prise en charge de HTTP/2 via TLS/SSL, imposant ainsi cette exigence à tout le monde. Fin 2015, Google a commencé à donner la priorité aux sites compatibles HTTPS dans les classements de recherche. Et en 2016, Apple a pris des mesures similaires qui ont obligé toutes les applications natives à utiliser App Transport Security, forçant à nouveau efficacement le passage au HTTPS.

Fondamentalement, HTTPS a été forcé par ceux du côté client à le prendre en charge.

Pour IPv6, il n’existe actuellement aucune exigence similaire. Nous avons tous vu les adresses IPv4 disparaître, mais cela a eu relativement peu ou pas d’impact. Personne ne ressent donc (encore) de réelle motivation pour prendre une décision qui pourrait être potentiellement perturbatrice et coûteuse. Mais à mesure que de nouvelles fonctionnalités émergent, il est tout à fait possible qu'elles finissent par ne prendre en charge que l'IPv6. Les objets ont de petits facteurs de forme et leur puissance de traitement est limitée. Dans l’Internet des objets, moins c’est plus. C’est l’une des raisons pour lesquelles de nombreux appareils IoT évitent HTTP au profit de MQTT ; il est plus petit, plus rapide et plus efficace que son cousin Web plus lourd. La prise en charge d'IPv4 et d'IPv6 est similaire. Parce qu'ils sont incompatibles, la plupart des appareils prennent en charge l'un ou l'autre. Et finalement, ils vont en choisir un et tout le monde va se bousculer pour le soutenir.

Même si ce n’est pas le cas, les adresses IPv4 disponibles aujourd’hui peuvent prendre en charge moins de 20 % des 20 milliards d’appareils qui devraient être utilisés d’ici 2020 (Gartner). IPv6 prend en charge bien plus d'appareils que les prévisions les plus agressives de Cisco, qui prévoient 50 milliards d'appareils. Et ce n’est que l’IoT.

Le cloud pose également problème car il ne peut pas acheter suffisamment d’adresses IPv4 pour prendre en charge sa base de clients croissante. Si l’IaaS doit croître comme prévu, les fournisseurs de cloud doivent passer à IPv6. C'est sans doute en partie ce qui explique la décision d'Amazon et de Microsoft de procéder de la sorte.

Tout cela signifie qu’une fonction de forçage finira par arriver et nécessitera la prise en charge d’IPv6. Il peut s’agir de l’IoT ou du cloud lui-même. Il peut s’agir de la force explosive et perturbatrice combinée des deux sur votre entreprise. Quoi qu'il en soit, nous allons devoir faire la transition à un moment donné, et il est toujours préférable de ne pas se précipiter. Nous avons eu beaucoup de temps pour résoudre les problèmes liés à IPv6, et il existe aujourd’hui sur le marché plus que suffisamment de solutions pour prendre en charge l’approche à double pile afin de lancer la transition. Alors si vous ne l'avez pas encore fait, il est temps d'envisager sérieusement d'activer IPv6, avant d'y être contraint par les besoins de votre entreprise pour continuer à se développer.

* Oui, nous pourrions nous pencher sur le nombre de certificats apparemment frauduleux et sur le fait que les distribuer aveuglément comme des bonbons comporte de nombreux risques, mais c'est un autre sujet pour un autre jour.