Résumé

  • RFC 3152 choisissait IP6.ARPA, en demandait la délégation sous instruction de l’IAB et alignait les sous-délégations sur l’attribution des adresses IPv6 ; il ne remplissait pas chaque zone inverse et ne mettait pas à jour chaque client.
  • La dépréciation d’IP6.INT visait d’abord les nouvelles implémentations et annonçait une extinction ordonnée. La date de retrait fixée en 2005 montre que le consensus de 2001 n’était pas un basculement instantané.
  • Un constat vérifiable sépare statut du RFC, délégations parent et enfant, PTR, suffixe interrogé, cache, réponse DNS, validation et décision applicative. Un nom inverse n’est pas une identité authentifiée.

Un consensus commun, plusieurs horloges

Avant RFC 3152, le besoin existait déjà : transformer une adresse IPv6 en clé DNS afin d’obtenir éventuellement un nom. Des textes plus anciens désignaient IP6.INT. En parallèle, l’IAB voulait réserver .ARPA aux espaces d’identifiants nécessaires à l’infrastructure Internet. Le nouveau BCP réunit ces deux trajectoires en peu de pages.

Il déprécia les références à IP6.INT dans cinq RFC, demanda à l’IANA de déléguer IP6.ARPA selon les instructions de l’IAB et prescrivit une hiérarchie conforme à l’attribution des adresses. Les registres régionaux devaient recevoir les portions correspondant aux ressources qui leur étaient confiées.

Le mot important est pourtant « déprécier ». RFC 3152 l’expliquait : l’ancien usage ne convenait plus aux nouvelles implémentations et serait probablement éliminé progressivement. Une bibliothèque déjà installée pouvait encore former une requête sous IP6.INT. Une zone pouvait rester publiée. Un cache pouvait conserver une réponse. Le standard indiquait la destination sans prétendre que tous les acteurs l’avaient atteinte le même jour.

La délégation n’était pas un commutateur unique

La gouvernance de l’arbre suivait une chaîne. L’IETF fixait la convention technique. L’IAB encadrait l’usage du domaine d’infrastructure. L’IANA exploitait la délégation supérieure. Les RIR recevaient des sous-arbres calés sur les allocations IPv6. Les détenteurs de ressources et leurs opérateurs DNS administraient ensuite les délégations plus fines et les enregistrements PTR.

RFC 3172 décrivit .ARPA comme un domaine à usage limité dont la fiabilité conditionnait des services Internet. Il confirma que IP6.ARPA suivait le même principe que IN-ADDR.ARPA : délégation à l’IANA, puis aux registres selon l’espace d’adresses.

Cette symétrie institutionnelle ne fusionnait pas les preuves. Une allocation d’adresses n’établit pas qu’une délégation inverse fonctionne. Une référence parent peut pointer vers un serveur enfant mal configuré. Une zone autoritative peut être vide. Un PTR peut exister tout en désignant un nom dont l’adresse directe est différente.

La maîtrise était donc distribuée, mais pas confuse : chaque acteur contrôlait une partie observable. Pour savoir ce qui s’était produit, il fallait conserver les reçus de chaque partie.

Interroger le bon arbre ne garantissait pas une réponse

RFC 3596 incorpora ensuite le résultat stable. L’adresse IPv6 est décomposée en chiffres hexadécimaux, renversés et séparés en étiquettes sous IP6.ARPA. Construire correctement cette clé prouve que le logiciel a demandé le bon espace de noms.

Cela ne prouve ni la délégation du préfixe, ni l’autorité du serveur atteint, ni l’existence d’un PTR. La même requête peut rencontrer un renvoi, NXDOMAIN, SERVFAIL, une expiration, une réponse en cache ou un RRset signé. Ces états ne sont pas des variantes d’une seule valeur booléenne.

Le PTR lui-même est une donnée publiée par l’opérateur de zone. Il ne certifie pas la propriété de la machine, sa disponibilité ou son droit d’accès. Il ne démontre pas non plus que la recherche directe du nom renvoie l’adresse de départ. Une application qui affiche ce nom et une application qui s’en sert pour autoriser une session font deux opérations radicalement différentes.

Le succès de la migration exigeait donc deux avances indépendantes : les logiciels devaient choisir le nouveau suffixe et la chaîne de délégation devait fournir les données attendues.

La coexistence protégeait la migration et brouillait l’observation

Maintenir temporairement deux arbres réduisait le coût d’une coordination mondiale. Les nouvelles versions pouvaient préférer IP6.ARPA tandis que les anciennes continuaient à demander IP6.INT. Des opérateurs pouvaient publier les deux. Ce chevauchement évitait une rupture totale.

Il pouvait aussi masquer la provenance. Si un résolveur appliquait un repli silencieux, un nom affiché ne disait pas quel suffixe avait répondu. Si les arbres divergeaient, deux réponses positives ne prouvaient pas une identité commune. Une entrée négative conservée en cache pouvait cacher une nouvelle délégation pourtant correcte.

L’audit doit donc conserver le QNAME exact, le résolveur, l’état du cache, les références successives, le serveur autoritatif, le code de réponse, le TTL et l’état de validation. Le numéro de version de la bibliothèque qui a choisi le suffixe appartient au même dossier.

La chronologie ultérieure confirme cette lecture. RFC 3596 consolida en 2003 IP6.ARPA dans la spécification IPv6 sur la voie des normes. RFC 4159 indiqua qu’à partir du 1er septembre 2005 les implémentations conformes ne devaient plus employer IP6.INT et demanda aux RIR d’organiser la fin de leur service d’enregistrement avec leurs communautés. Quatre années séparaient la direction commune de cette nouvelle étape de retrait.

Un RFC obsolète pouvait laisser une infrastructure vivante

RFC 3596 rendit RFC 3152 obsolète en absorbant sa modification dans un texte plus complet. Le terme ne signifiait pas que IP6.ARPA était abandonné. Au contraire, le nouvel arbre devenait la forme consolidée.

D’autres surfaces continuaient d’évoluer. RFC 3363 relégua A6 et les Bitstring Labels au statut expérimental en privilégiant AAAA. RFC 5855 fixa plus tard un schéma stable de noms pour les serveurs des zones inverses. RFC 9121 consigna IP6.INT parmi les domaines d’infrastructure historiques retirés de .INT.

Ces étapes portaient sur des objets différents : type d’enregistrement, racine de l’arbre, hébergement des serveurs, puis retrait de l’ancien domaine. Les confondre produirait un récit artificiellement instantané.

L’absence de nouvelle menace n’était pas une garantie

RFC 3152 rappelait que l’usurpation des correspondances adresse-nom avait déjà été exploitée en IPv4, puis concluait que la délégation d’IP6.ARPA ne créait pas de nouvelle menace. Cette affirmation bornée ne transformait pas le DNS inverse en système d’identité.

RFC 3596 précisait que les informations DNS restaient dangereuses sans mécanismes de sécurité appropriés. Une validation DNSSEC peut établir que la donnée appartient à une chaîne de confiance DNS. Elle ne prouve pas l’interprétation humaine du nom, la garde actuelle du terminal ou l’autorisation accordée par une application.

Avant toute décision sensible, il faut distinguer réponse reçue, validation, corrélation directe éventuelle et règle d’application. Le PTR peut enrichir un journal ; il ne doit pas recevoir par glissement le pouvoir d’un justificatif d’identité.

Le comportement exécuté mesurait la migration réelle

Imaginons un préfixe correctement délégué et un PTR publié. Un ancien client interroge encore IP6.INT et ne trouve rien. Un second demande IP6.ARPA, mais son cache négatif précède la création de la zone. Un troisième obtient le nouveau nom. Le consensus technique est identique ; les résultats sont différents.

La primauté du code en fonctionnement ne contredit pas RFC 3152. Le BCP détermine la racine et le modèle de délégation voulus. Les traces d’exécution révèlent le suffixe réellement utilisé, l’autorité atteinte, les données obtenues et l’action prise.

La spécification initiale minimale rendait la migration possible : choisir une racine commune, demander sa délégation, suivre l’attribution des adresses et décourager l’ancien nom. Elle évitait d’exiger une mise à jour atomique mondiale. En échange, aucune couche ne devait prétendre représenter à elle seule l’état de la migration.

IP6.ARPA pouvait donc être la bonne destination avant que le dernier logiciel ne l'utilise. IP6.INT pouvait être déprécié avant la disparition de sa dernière trace. C’est moins propre qu’une flèche dans un schéma, mais beaucoup plus fidèle à l’histoire d’Internet.

Sources