IPv6 et DNSSEC ont 20 et 19 ans. Même combat et mêmes défis !?

IPv6 et DNSSEC ont 20 ans. Leur parcours, les défis auxquels ils font face et leurs perspectives d’évolution les rendent si proches à bien des égards… Ce billet leur est dédié.

Il y a quelques semaines, je suis tombé sur une ancienne interview de moi par ITespresso.fr (ex-VNUnet) datant d’il y a tout juste 10 ans et intitulée « IPv6 libère l’imagination humaine ». J’y parlais à l’époque des apports attendus d’IPv6 et des défis auxquels il devait faire face. En relisant l’article, je constate qu’il a pris pas mal de poussière (et la personne interviewée s’y retrouve de surcroît avec une photo floutée « à l’insu de son plein gré » :-)).

Mais ce qui a attiré le plus mon attention dans l’interview, c’est cette assertion : « Si IPv6 ne s’impose pas en 2006, il y a fort à parier que cela se fera en 2007. » Wow ! Quelle précision ! Depuis, même si les choses ont évolué, on est encore loin de l’objectif.

J’ai trouvé dans cette interview revisitée et dans cette prédiction entièrement ratée une première motivation pour partager, dix ans plus tard, des éléments de réflexions et d’analyse, avec la promesse de ne plus m’aventurer dans des prédictions de ce genre 😉 Cependant, cette motivation n’était pas suffisante pour franchir le pas et le hasard du calendrier a fait qu’une « fenêtre d’opportunité » se trouve ouverte pendant quelques semaines : IPv6 vient de souffler sa 20^e bougie en décembre 2015 ! Et puis, il y a une autre coïncidence : DNSSEC 19 ans en janvier 2016. Voilà donc autant d’éléments motivants, qui m’ont incité à élargir le champ de ce billet au-delà d’IPv6, en intégrant des réflexions sur le passé et le devenir/avenir de DNSSEC, une technologie qui a eu jusqu’ici un parcours tellement similaire, en plus d’avoir un âge très proche.

Me voilà enfin plume clavier en mains, prêt à affronter le billet qui m’attend. Au boulot !

Partager un retour d’expérience sous forme d’un exercice d’analogie des parcours respectifs d’IPv6 et de DNSSEC et des défis auxquels ces technologies font face, tel est l’objectif du présent billet. Je prendrai ainsi le parti de me focaliser sur ce qui rapproche IPv6 et DNSSEC plutôt que de m’attarder sur ce qui les sépare, d’autant que ces deux technologies sont issues de couches fonctionnelles/protocolaires fondamentalement différentes.

Un tel exercice d’analogie ne peut être abordé sérieusement qu’en ayant pris une distance et une hauteur suffisantes par rapport au sujet, tout en capitalisant sur tant d’années d’observation. J’espère que ce billet sera donc à la hauteur de cette exigence.

Après plusieurs années de gestation, 20 ans de maturation déjà !

Dans le contexte du développement des standards de l’Internet, par excellence au sein de l’Internet Engineering Task Force (IETF), la naissance d’un concept/protocole/technologie se matérialise par la publication d’un « Request For Comments » (RFC). En l’occurrence, rappelons que la première spécification d’IPv6 [RFC 1883] a été publiée en décembre 1995  et que la première spécification de DNSSEC [RFC 2065] a été publiée¹ en janvier 1997 (ceux qui désirent en savoir plus sur la genèse d’IPv6 ou de DNSSEC peuvent visiter cette page par exemple pour IPv6 ou cette page pour DNSSEC, où l’on note que les premières initiatives remontent bien plus loin).

Avec du recul, et indépendamment de l’état de déploiement d’IPv6 et de DNSSEC aujourd’hui, j’ai la chance d’avoir vu grandir ces deux technologies, celle de m’être impliqué dans la durée, et surtout celle de témoigner, depuis près de 18 ans, des premiers tests, des premiers déploiements en production (notamment à l’Afnic dès 2003), des efforts de sensibilisation et même des multiples obstacles et difficultés de déploiement rencontrés par les communautés respectives. J’écris « communautés respectives », mais celles-ci sont en fait loin d’être disjointes, puisqu’une bonne partie des pionniers de ces technologies s’est longtemps mobilisée sur les deux fronts à la fois.

Vous avez dit « nouvelles technologies » ?

La première prise de recul est celle par rapport aux termes employés. Je trouve plutôt amusant que nous continuions (moi compris, rassurez-vous !) à employer « nouveau protocole », « nouvelle technologie », « nouvelles extensions » ou « nouvelle version » quand on parle de IPv6 et/ou DNSSEC alors que leur âge est significativement long par rapport à l’échelle de temps de l’ère numérique où nous vivons. Sans doute abusons-nous du terme « nouveauté » en pensant au (toujours) maigre niveau de déploiement de ces deux technologies à l’échelle mondiale. Mais cet abus de langage me paraît encore tout à fait tolérable, et personnellement je ne m’en voudrai pas les prochaines fois que je le commettrai, tant que les rapports de force ne sont toujours pas inversés.

IPv6 et DNSSEC : deux parcours si proches !

Les évolutions et extensions de technologies standardisées au sein de la communauté IETF sont rarement des phénomènes de rupture, et ce, souvent par souci d’interopérabilité/rétrocompatibilité. En effet, dans la « culture de standardisation IETF », en cas de tension, l’arbitrage se fait souvent au profit de l’objectif/principe de stabilité et de continuité de service (celui de l’Internet globalement), au détriment de celui d’introduire un saut significatif de fonctionnalités et/ou de performances. Cette culture IETF se traduit souvent en principes architecturaux, comme on peut le lire par exemple en section 3 de [RFC 6709].

En mettant ces principes au regard des critères qui font d’un protocole un « succès fou » (« wild success » ) [RFC 5218], et au vu de la difficulté d’IPv6 et de DNSSEC à s’imposer chacun dans son milieu, le constat est sévère pour ces deux technologies. En effet, si IPv4 et le DNS (sans les extensions de sécurité) sont considérés comme un succès, et peuvent même être considérés dans certaines mesures comme un « succès fou », IPv6 et les extensions de sécurité du DNS (DNSSEC) sont encore loin de prétendre au (simple) grade de « succès ».

Rassurons-nous en nous rappelant que l’objectif initial recherché pour IPv6 et DNSSEC était le succès, simplement, pas un « succès fou ». Mais rappelons-nous également que même ce « simple succès » n’est pas acquis ; il est souvent le fruit de la persévérance, rarement celui du hasard ou d’une longue attente (mutuelle) passive. En effet, c’est un exercice difficile que de prédire et de réaliser le succès pour une nouvelle technologie dont le bénéfice est a priori collectif, comme c’est le cas pour IPv6 et DNSSEC. Ce bénéfice collectif est surtout le résultat de l’effet réseau, souvent expliqué par la « loi de Metcalfe ».

Qu’est-ce qui les rapproche au juste ?

Tout d’abord, ils sont nées dans un contexte où la technologie à « remplacer » (à terme) ou à « étendre » était déjà très largement déployée et cela représentait manifestement un premier frein. Ainsi, toute stratégie de déploiement de l’une ou de l’autre des deux « nouvelles technologies », devait être progressive (pas de jour J) et préserver l’interopérabilité et la continuité du fonctionnement global de l’Internet. S’agissant d’IPv6, il fallait par exemple éviter à tout prix une certaine partition (« balkanisation ») de l’Internet, donnant lieu à des réseaux ne pouvant communiquer qu’en IPv4 et d’autres, ne pouvant communiquer qu’en IPv6. Pour DNSSEC, il fallait surtout s’assurer que le contenu des zones signées DNSSEC continue à être servie comme un contenu « ordinaire » (non-DNSSEC) pour les résolveurs qui n’annoncent pas la compatibilité DNSSEC (« DNSSEC OK »).

Ensuite, IPv6 et DNSSEC ont connu chacun une longue période de test à l’échelle locale, nationale et mondiale, avec une coopération plus ou moins étroite entre acteurs et une évaluation plus ou moins rigoureuse. Ainsi, pour IPv6, le réseau 6bone, lancé en 1996 par trois acteurs (Uni-C – Danemark, G6 – France et WIDE – Japon) et s’appuyant sur des tunnels (encapsulation d’IPv6 dans IPv4), a rapidement évolué pour servir de plateforme l’expérimentation mondiale des fonctionnalités essentielles du nouveau protocole (2 plans d’adressage IPv6 testés et à son apogée, le 6bone comptait plus de 1000 sites dans plus 50 pays participants). Grâce aux résultats probants obtenus, les pionniers d’IPv6 ont déployé des réseaux pilotes, puis de véritables réseaux en production fin des années 90 – début des années 2000. Plusieurs acteurs ont suivi le modèle au point que le réseau 6bone, interconnecté avec les réseaux en production, était devenu le « maillon faible » en matière de stabilité et de performance et provoquait de plus en plus de dégradation au niveau global. Son démantèlement s’était alors imposé, et la fin de sa mission (d’expérimentation) annoncée le 6/6/6 (pour le symbole !).

Pour DNSSEC, les pionniers se sont tout d’abord battus pour obtenir ou développer chacun les outils nécessaires à la signature de leurs zones, avant d’aller mettre la pression collectivement sur l’ICANN pour signer la zone racine, à l’instar de la communauté RIPE en 2007 ou de cet atelier organisé par le .se en 2008, premier ccTLD à avoir déployé DNSSEC. En attendant, une technique de contournement a été adoptée à l’IETF, DNSSEC Lookaside Validation (DLV) [RFC 5074],  et déployée assez largement en s’appuyant sur le registre mis à disposition par l’ISC. La zone racine ayant été signée DNSSEC en 2010, les gestionnaires de zones de premier niveau (TLD) signées ont progressivement retiré leurs clés du registre DLV après avoir crée le maillon les reliant à la racine dans la chaîne de confiance DNSSEC. Ainsi, le registre DLV de l’ISC a commencé à perdre de son intérêt et l’ISC a par conséquent annoncé le démantèlement progressif de ce registre à l’horizon de 2017.

Chacun de ces deux dispositifs d’expérimentation (6bone et DLV) aura donc duré près de 10 ans et c’est en soi assez symptomatique de la dynamique et de l’implication très faibles chez les acteurs menant des expérimentations, et ce « retard de croissance » explique en partie celui de la maturité des deux technologies.

Par ailleurs, pendant de ces longues périodes de test, les communautés IPv6 et DNSSEC vivait chacune dans l’obsession de trouver un ou plusieurs facteurs (cumulés) pouvant accélérer significativement l’adoption et le déploiement de ces technologies. Ainsi, parmi les idées les plus récurrentes on avait :

1. trouver l’« application qui tue » (« killer application »), une sorte d’usage qui devient indispensable mais qui nécessite le déploiement de la technologie concernée ;
2. un ou plusieurs gros acteurs décident de déployer massivement et entrainent les autres ;
3. un ou plusieurs gouvernements se mettent à imposer le déploiement par décret et/ou instaurer des mesures d’incitation/dissuasion financières/fiscale (bonus/malus) pour pousser acteurs concernés à adopter ces technologies ;
4. une menace importante survient, entraine un risque majeur de discontinuité/perturbation des services existants et met alors les acteurs concernés au pied du mur en ne leur laissant d’autre choix que de déployer la technologie en question dans l’urgence.

Sans vouloir passer en revue piste par piste la liste ci-dessus, on peut noter aujourd’hui qu’aussi bien pour IPv6 que pour DNSSEC, l’idée d’une « application qui tue » a fini par être tuée ! Il y avait peu d’espoir et il valait mieux investir l’énergie collective ailleurs… En particulier, on aura tout essayé dans la (sur)vente du potentiel d’IPv6, sans jamais arriver à démontrer aux plus « résistants » la réalité de sa supériorité par rapport à IPv4. Pour DNSSEC, la recherche par certains de « l’application qui tue » a fini par être caricaturée par d’autres en une phrase : « DNSSEC serait une solution à la recherche d’un problème » 🙂

Par ailleurs, des acteurs « de taille » avaient fait des annonces pendant près de 10 ans sur leur intention de mettre en œuvre/déployer IPv6 et/ou DNSSEC, annonces qui ont été assez largement médiatisées mais dont le bilan était mitigé. C’était le cas par exemple de la sortie de Microsoft Windows Vista avec son « support natif » d’IPv6, ou des décisions du gouvernement américain de d’intégrer, tour à tour, IPv6 et DNSSEC, dans les réseaux de toutes les agences fédérales, avec mises à jour, évaluation et revues régulières de l’atteinte des objectifs fixés, ou encore l’annonce de Comcast de déployer DNSSEC pour leurs millions de clients. Enfin, en Europe, souvenons-nous du communiqué de presse de la Commission européenne en 2008 annonçant un objectif fixé par la CE : « […] en 2010, 25 % des entreprises, des administrations publiques et des particuliers européens utilisent IPv6 ». Seulement, la CE avait omis de définir les indicateurs et les paramètres de mesures servant à évaluer / surveiller le niveau de déploiement / utilisation d’IPv6 jusqu’à l’échéance, et à assurer le suivi au-delà. C’est en avril 2010 que l’OCDE est venu combler cette lacune. Son rapport intitulé « INTERNET ADDRESSING: MEASURING DEPLOYMENT OF IPv6 », reste à ce jour une référence reconnue pour la diversité des indicateurs et paramètres de mesures IPv6 traités et  ainsi que pour la rigueur de leur définition.

Outre ces annonces, un sentiment d’urgence a été créé à plusieurs occasions, mobilisant de nombreux acteurs à l’échelle mondiale. Comme on peut le lire dans un dossier thématique publié par l’Afnic en 2011 (« IPv6,  passeport  pour l’Internet  du Futur »), parmi les occasions les plus significatives pour IPv6, on peut citer les prévisions alarmantes (alarmistes ?) de Geoff Huston annoncées en 2007 pour une fin du monde IPv4 en 2011, puis l’épuisement effectif du stock IPv4 de IANA en 2011, qui a mobilisé dans la foulée un grand nombre d’acteurs autour du « World IPv6 Day » (08/06/2011), avant de les voir encore plus nombreux un an plus tard (à partir du 6/6/12) autour d’un objectif de déploiement pérenne, le « World IPv6 Launch ». Pour DNSSEC, c’était surtout la découverte de la faille dite « Kaminsky » qui a dû rallier la communauté DNS mondiale autour de DNSSEC comme seule solution permettant de contrer dans la durée les attaques par empoisonnement de cache.

Bien entendu, beaucoup pariaient sur le fait que l’adoption d’IPv6 et/ou DNSSEC par les « géants de l’Internet » et le sentiment d’urgence créé à l’échelle mondiale allait susciter un phénomène d’entrainement résultant en un déploiement massif de ces technologies, et faire rattraper ainsi le temps perdu. Si ces évènements ont permis de faire décoller le déploiement d’IPv6/DNSSEC, force est de constater qu’on est loin du raz-de-marée espéré et ce, même plusieurs années plus tard.

Défis et perspectives

IPv6 et DNSSEC font face à des défis de nature similaire quant à leur adoption massive. Présentés parfois comme de « nouvelles normes » auxquelles « il faut de toute façon se conformer tôt ou tard », cela laisse le choix aux acteurs directement concernés et surtout, ceux qui ne le sont pas directement, de reporter autant que possible la décision de s’y mettre.

Les acteurs du réseau semblent ainsi se trouver depuis longtemps au milieu du gué. En effet,  d’une part, ceux qui ont déployé peinent/tardent à avoir le retour sur investissement attendu et connaissent une frustration grandissante de ne toujours pas pouvoir bénéficier pleinement de ces « nouvelles technologies », et d’autre part,  ceux qui n’ont toujours pas déployé, peuvent encore s’acheter du temps et ne « sauter dans le train » que lorsque cela deviendra impératif et urgent pour tout le monde.

En attendant, la frustration des premiers ne doit surtout pas se transformer en perte de motivation ou en désespoir. Dans d’autres contextes, la non atteinte d’objectifs peut inciter légitimement  à « faire une pause », à « arrêter les frais » et/ou à « actionner un (hypothétique) plan B ». Cependant, dans le cas précis d’IPv6 et de DNSSEC, la communauté Internet est unanime : « il faut y aller ! » En effet, même si cela prend nettement plus de temps que prévu, au vu de la croissance continue du taux de pénétration de ces technologies au niveau mondial, force est de constater que la persévérance paie. Il suffit pour s’en convaincre de visiter quelques-uns des nombreux sites web qui proposent des statistiques globales ou par pays et qui montrent l’évolution dans le temps du niveau de déploiement. Pour IPv6, le portail du programme « Deploy360 » de l’ISOC répertorie par exemple le site de google  qui montre l’évolution du taux de pénétration d’IPv6 dans les navigateurs des utilisateurs interrogeant le moteur de recherche, ou le site de 6lab (Cisco), qui intègre des indicateurs d’infrastructure (préfixes, transit, AS)² et de contenu, ou encore, le site de l’Observatoire de la résilience de l’Internet en France où l’évolution d’indicateurs IPv6 (routage et DNS) sont suivis depuis 2011. D’autre part, le même programme Deploy 360 (ISOC) compile plusieurs références en matière de statistiques DNSSEC, mondiales ou par pays.

Les perspectives d’évolution pour IPv6 se trouvent de plus en plus prometteuses malgré le retard accusé et bien que cette technologie ne soit plus citée parmi les tendances du moment (comme le montrent les éditions récentes du « Gartner Hype Cycle for Emerging Technologies », alors qu’IPv6 était au sommet en 2006). En effet, maintenant que tout le monde a bien compris qu’IPv6 n’est ni un produit, ni un usage en soi, l’attention est désormais concentrée sur ses pouvoirs d’activation des nouveaux usages, une fois déployé.

En parlant par exemple de l’Internet des objets, qui est désormais doté de son propre « Gartner Hype Cycle », IPv6 est souvent mentionné comme allié logique de l’IoT, voire un prérequis. Mais il faut se méfier des confusions et raccourcis assez fréquents ! Tout d’abord, si l’immense espace d’adressage IPv6 peut en effet attribuer une adresse à chaque objet de la planète, y compris les dizaines de milliards d’objets connectés (de 20 à 50 milliards selon les prévisions), qui vont peut-être « nous envahir » dans les 5 années à venir, seuls ceux qui auront la faculté de « parler IP » en « mériteront » une ! Je vois déjà venir la question : « Oui, d’accord, mais ça fera quand même des milliards d’objets à connecter en IP, non ? Et dans ce cas-là, l’espace le résidu IPv4 ne pourra pas le faire l’affaire, à l’inverse d’IPv6, n’est ce pas ? » En fait, la réponse n’est pas si simple. Il suffit d’observer les déploiements actuels qui sont quasi-uniquement en IPv4. Au risque de décevoir le lecteur, l’adressage privé d’IPv4 peut (continuer à) répondre aux besoins d’adressage des opérateurs pour les 20 années à venir si ceux-là continuent à faire des choix d’architectures de réseaux fermés, avec contrôle et gestion centralisés (à la minitel). En revanche, IPv4 n’est clairement pas une solution durable quand on pense au besoin de rendre possible des communications de bout-en-bout entre objets connectés, typiquement selon des architectures ouvertes et interopérables. En effet, dans cette perspective d’IPv6 qui favorise l’innovation, notamment celle sans permission (« permissionless innovation »), le qualificatif d’activateur d’usages (« enabler ») prend tout son sens.

De même, si les déploiements 3G se sont faits quasi-exclusivement en IPv4, après un rendez-vous « IPv6-UMTS » manqué (jamais rattrapé), les déploiements en 4G, plus récents, se font « injecter du v6 » par un nombre grandissant d’opérateurs mobiles (modulo quelques mécanismes de transition au niveau de l’accès), à l’instar de T-Mobile (USA) et d’Orange Pologne.  D’ailleurs, Geoff Huston le dit d’une manière assez frappante dans un exposé récent au RIPE meeting 71, « An Update on Mobility in Today’s Internet » (cf. transparent #15 et vidéo à [15:00 – 15:20]) : « […] If the mobile industry doesn’t do v6, it’s not going to happen… That’s simple. Because, the mobile industry IS the Internet […] ».

Pour DNSEC, plusieurs facteurs pourront déterminer dans les années qui viennent s’il y aura accélération du déploiement ou bien du maintien du rythme globalement lent au niveau mondial, surtout du côté des opérateurs de serveurs récursifs (résolveurs). Parmi ces facteurs, cumulables, on peut citer par exemple une éventuelle augmentation du niveau de risque d’attaques contre lesquelles seule cette technologie peut aider à lutter (telles que celles par empoisonnement de cache) ou la maturité de services applicatifs tels que DANE, qui utilisent DNSSEC comme une PKI indispensable à leur fonctionnement.

Certes, lorsqu’on s’apprête à lancer une nouvelle technologie s’appuyant pleinement sur l’effet de réseau, on prévoit forcément les interdépendances entre acteurs concernés, entrainant souvent des phénomènes d’interblocages, des cercles vicieux et autres problèmes de l’œuf et de la poule. Cependant, l’exercice le plus difficile reste celui d’élaborer une stratégie globale, collectivement (par les « pionniers ») ou individuellement (par les « suivants ») et de la mettre en œuvre. Comme conditions nécessaires (mais non suffisantes hélas), une telle stratégie doit :

• identifier à l’avance les obstacles les plus significatifs qu’il convient de lever, de préférence en ayant une idée préalable de leur intensité et de leur durée dans le temps ;
• proposer des leviers d’actions multiples (sensibilisation, incitation, renforcement de capacités…) en fonction des acteurs concernés et des obstacles à surmonter (ou à contourner à défaut) ;
• décliner les leviers stratégiques en actions concrètes et orchestrer ces dernières selon un plan d’action pluriannuel ;
• prévoir une évaluation régulière des résultats et la boucle de rétroaction pour réviser la stratégie si besoin (et c’est souvent le cas !).

En conclusion, en attendant qu’IPv6 et DNSSEC s’imposent (espérons-le toujours, mais comme promis, je ne fais plus de prédiction de date, n’est-ce pas ! :-)), il convient non seulement de continuer l’effort pédagogique et de sensibilisation, mais aussi de rappeler que chaque acteur doit d’abord « balayer devant sa porte », avant de demander aux autres (légitimement ou non) de remplir leur rôle. Mieux encore, selon la fameuse expression « Eat  your own dog food », même lorsqu’on croit avoir fait son boulot, il est important d’en vérifier la qualité, afin de montrer l’exemple.

Notes :

1 Au terme de nombreuses itérations, ces spécifications ont connu des améliorations significatives, conduisant à des standards stables depuis plusieurs années ([RFC 2460] pour IPv6, en vigueur depuis 1998 même si quelques mises à jour lui ont été apportées au fil de l’eau et [RFC 4033] [RFC 4034] [RFC 4035] pour DNSSEC, en vigueur depuis plus de 10 ans maintenant, après un passage temporaire par [RFC 2535] et autres RFC connexes).

2 Il est assez marquant que la Belgique qui était loin derrière d’autres pays européens il n’y a à peine 5 ans, occupe désormais la première place mondiale, avec un taux de pénétration combiné de 56% (au 3 janvier 2016, avec 44% côté utilisateurs, selon 6lab – Cisco). À l’inverse, la France, qui était en tête de peloton à la même époque (et devenue « célèbre pour IPv6 en plus de l’être pour son vin et son fromage »), se trouve aujourd’hui loin derrière (32% de déploiement au 3 janvier 2016, avec seulement 6,5% côté utilisateurs).