Résumé

  • La méthode Reg-RWS actuelle d’ARIN autorise une adresse IPv4 ou IPv6 dans la demande d’un rapport WhoWas, tandis que le ReadMe prévoit une plage IPv6 ; ni l’une ni l’autre ne démontre le contenu historique réellement livré.
  • Les suggestions ACSP 2025.4 et 2026.5 réclamaient encore cet historique. ARIN les a closes après renvoi vers sa priorisation interne, sans date de livraison ni identifiant de version commun avec la documentation présente.
  • Un reçu de capacité, fondé sur une adresse IPv6 de test et dépourvu de données client, pourrait relier acceptation, ticket achevé, horizon de conservation, classes d’objets, lacunes connues et version corrigée.

Le doute apparaît après une réponse qui semble pourtant rassurante. Un opérateur autorisé envoie une adresse IPv6 à la méthode WhoWas d’ARIN. Le paramètre est conforme, le service ouvre un ticket et l’appel ne s’arrête pas au contrôle de syntaxe. À cet instant, l’interface a bien fait son travail. Mais le travail de l’archive n’a pas encore été observé.

Le rapport attaché au ticket pourrait restituer une suite riche de modifications. Il pourrait aussi être vide parce que la ressource n’a jamais changé de titulaire public. Il pourrait commencer après l’événement recherché, ou ne pas comporter une ancienne association entre réseau, organisation et POC. Enfin, il se peut que le support historique d’IPv6 soit incomplet. L’acceptation de l’adresse ne permet pas de choisir entre ces explications.

C’est précisément la confusion que produit aujourd’hui le dossier public. La page des méthodes Reg-RWS dit que le champ IPADDRESS d’une demande WhoWas NET doit contenir une adresse IPv4 ou IPv6. Le ReadMe du rapport définit une « Net Range » composée d’adresses IPv4 ou IPv6. La présentation générale du service affirme qu’un utilisateur autorisé peut demander l’historique d’une adresse IP ou d’un ASN et qualifie le résultat d’histoire publique entière de la ressource.

Deux fiches ACSP racontent cependant que des utilisateurs ont encore demandé l’ajout d’IPv6 en 2025 puis en 2026. ARIN a jugé l’amélioration utile et l’a renvoyée vers la priorisation et la planification de mise en œuvre. Les fiches ont ensuite été closes. Aucun lien daté ne dit si la documentation actuelle décrit une livraison intervenue depuis, une interface en avance sur ses données, ou une capacité partielle.

L’hypothèse d’un déploiement récent est parfaitement plausible. Celle d’un format générique couvrant plus de cas que l’archive effectivement peuplée l’est aussi. Cet article ne dispose pas d’un accès WhoWas approuvé et n’a exécuté aucune demande. Il ne tranche donc pas le fonctionnement réel. Il examine une question plus étroite : pourquoi ARIN ne publie-t-elle pas le reçu minimal qui permettrait de relier la grammaire de la requête, la structure du rapport et la couverture historique ?

Une demande née d’une rupture de continuité

La suggestion 2025.4, déposée le 9 mai, ne cherchait pas à embellir une API. Son auteur expliquait qu’une entité en aval avait perdu la bonne allocation d’une ressource IPv6 et qu’il voulait retrouver les renseignements d’enregistrement antérieurs. D’après son expérience, WhoWas ne prenait en charge que les préfixes IPv4. Il demandait une parité entre les deux familles.

Le contexte donne sa valeur au service. Un Whois ou un RDAP courant présente l’état que le registre publie maintenant. Lorsque l’allocation a disparu, été révoquée, réattribuée ou rattachée à une autre organisation, cet instantané ne reconstruit pas la chaîne. L’enquête dépend alors des dates, des objets qui ont changé et des relations conservées entre eux.

Le 21 mai 2025, ARIN a répondu que l’ajout d’informations IPv6 serait utile. La demande serait ajoutée à la liste des améliorations proposées en attente de priorisation et transmise au processus interne de planification. La fiche a été marquée « Closed ». Le mot ne doit pas être séparé de l’explication. Il indique la fin du traitement public de la suggestion, pas une attestation de mise en production. Aucun calendrier n’était demandé, et ARIN n’en a promis aucun.

Le 31 mars 2026, une deuxième suggestion a repris le besoin. Cette fois, l’auteur parlait explicitement d’entités confrontées à la révocation d’espace IPv6 et souhaitait obtenir les mêmes détails que pour IPv4 et les ASN. Le 2 avril, ARIN a rappelé la demande de 2025 et dit que sa répétition compterait dans l’évaluation de la priorité de développement. La fiche a, elle aussi, été renvoyée au processus interne puis close.

La répétition prouve une demande persistante ; elle ne constitue pas un test de disponibilité. Un utilisateur peut ignorer une mise à jour silencieuse. Un droit d’accès manquant peut ressembler à une absence de fonction. Une fonction peut être ouverte dans l’interface web mais pas dans un rapport précis, ou l’inverse. Même la réponse d’ARIN ne définit pas quelle composante devait être développée. C’est pourquoi un identifiant de version commun serait plus instructif qu’une nouvelle interprétation du mot « Closed ».

La requête n’est pas le rapport

La première couche, celle de l’entrée, est documentée avec une précision appréciable. La méthode « Request WhoWas NET Report » attend une adresse, non un handle ni un préfixe CIDR. Elle fournit un exemple IPv4 et un exemple IPv6. En cas de succès, elle renvoie un Ticket Payload ; l’utilisateur interroge ensuite le ticket et télécharge la pièce jointe.

Cette séparation temporelle est essentielle. Le succès de l’appel initial concerne la création de la demande. Le rapport est un produit ultérieur. L’adresse peut être admise par le parseur alors que la génération ne trouve aucun événement ; le ticket peut se terminer correctement avec un fichier pauvre ; le fichier peut être complet pour les objets réseau récents et plus mince pour des associations anciennes. La grammaire de l’entrée ne prouve aucune de ces propriétés.

La deuxième couche est le format. Le ReadMe peut représenter une plage IPv6 et décrit des actions telles que création, modification ou suppression d’enregistrement. Il montre que le modèle de rapport possède le vocabulaire nécessaire pour raconter une trajectoire IPv6. Il ne donne pas le nombre de dossiers peuplés, leur ancienneté, ni les exceptions héritées d’une migration. Une colonne prévue dans un export n’est pas un décompte des valeurs présentes.

La troisième couche est la donnée historique. La page de présentation promet un accès à l’histoire publique d’une adresse IP ou d’un ASN. Elle explique qu’une même adresse a pu faire partie de plusieurs réseaux, attribués à plusieurs organisations et associés à plusieurs contacts. C’est justement ce qui rend WhoWas utile et complexe. Mais la page ne publie pas de matrice séparant IPv4 et IPv6, pas de date minimale de conservation, pas de cas de test dont l’histoire attendue serait connue.

Confondre ces couches entraîne deux conclusions opposées et également fragiles. La première consiste à dire : « l’exemple IPv6 est accepté, donc l’historique existe ». La seconde : « une suggestion de 2026 réclame IPv6, donc le service ne le fournit pas ». L’une traite un parseur comme une archive ; l’autre traite un état administratif comme une sonde de production. La bonne discipline consiste à faire correspondre chaque affirmation à son test.

L’absence a besoin d’un code de raison

Une archive historique se juge surtout lorsqu’elle ne renvoie rien. L’absence d’événement peut être une vérité sur la ressource. Elle peut aussi refléter une limite de conservation, une frontière de plage qui a changé, un objet parent que la requête ne retrouve pas, une relation organisationnelle non migrée, ou une autorisation insuffisante. Pour un utilisateur, ces résultats se ressemblent. Pour une décision, ils ne se valent pas.

Une équipe de lutte contre les abus cherche le responsable au moment d’un incident, pas seulement aujourd’hui. Un conseiller en transfert veut vérifier la continuité entre ancien et nouveau titulaire. Un opérateur doit comprendre la disparition d’une allocation client. Un juriste peut avoir besoin de dater l’état public d’un registre. Dans chacun de ces métiers, « aucun événement » et « aucun événement conservé » conduisent à des actions différentes.

L’expression « entire public history » ne doit donc pas être lue comme une promesse sans limites. « Public » exclut les éléments protégés. « History » commence à un point de conservation ou de migration. « Entire » peut raisonnablement signifier tous les événements publics conservés, non toute la réalité opérationnelle. Dire où se situent ces limites rendrait la promesse plus solide, pas plus faible.

À défaut, les organisations fabriquent leur propre doctrine. Elles retiennent qu’avant telle année les résultats sont incertains, que telle classe de POC manque souvent, ou qu’une recherche IPv6 vide doit être escaladée. Cette connaissance privée n’est ni versionnée ni comparable. Elle peut exagérer une lacune déjà corrigée autant qu’elle peut masquer une vraie limite.

Les pages de planification ne sont pas un journal d’exécution

La page « Planned Functionality » d’ARIN se présente comme un aperçu général. Pour 2026, elle cite la haute disponibilité, la réduction de dette technique, les changements liés aux politiques et aux tarifs, les améliorations des sites, la conformité SOC 2 Type 2 et la sécurité du routage. WhoWas IPv6 n’apparaît pas comme ligne distincte.

La page des versions rappelle le lancement du service WhoWas en mars 2012, puis la disponibilité des rapports WhoWas via Reg-RWS en mai 2012. Les résumés visibles pour 2025 et 2026 ne nomment pas une extension de l’historique IPv6. Plusieurs versions regroupent néanmoins des améliorations mineures et des corrections sans les détailler.

Il serait incorrect de transformer ce silence en preuve de non-déploiement. Un aperçu n’est pas un backlog exhaustif ; un résumé n’est pas un diff logiciel. Une petite amélioration peut être incluse dans une livraison plus large. La documentation peut aussi être mise à jour entre deux entrées datées.

Ce silence permet seulement une observation : aucune des sources conservées ne fournit le raccord public. Si le support est déjà livré, un lien de la suggestion vers la version suffirait à modifier le dossier. Si le support est partiel, une matrice d’horizon et de classes d’objets éviterait le faux choix entre oui et non. Si la syntaxe a été documentée avant les données, la page pourrait le dire sans annoncer de calendrier.

Le bon témoin serait synthétique

Un exemple réel est mal adapté à une attestation publique, car WhoWas contient des renseignements historiques sur des organisations et des contacts. ARIN contrôle l’accès pour de bonnes raisons. Le test devrait donc utiliser une ressource IPv6 réservée à la documentation ou à un environnement d’évaluation, avec une suite d’événements conçue et publiable : création d’un réseau, changement d’organisation, évolution d’un POC, puis retrait ou remplacement de l’enregistrement.

Le reçu n’aurait pas besoin de reproduire la pièce jointe. Il indiquerait la version, la date, l’adresse soumise, l’acceptation de la demande, l’achèvement du ticket, la présence du rapport, l’événement le plus ancien attendu et les classes effectivement observées. Une rubrique énumérerait les lacunes connues : cohortes non migrées, relations absentes, périodes non conservées. Une autre porterait la date de correction et le lien vers les pages ACSP.

La provenance de ce test pourrait être fixée par un hash du scénario et du résultat attendu. L’objectif n’est pas de donner une allure cryptographique à une assertion éditoriale ; il est d’empêcher qu’un exemple soit modifié sans que sa relation au résultat change également. L’URL de l’API peut rester stable pendant que la génération de données évolue. Le reçu doit identifier cette génération.

Une telle attestation serait volontairement limitée. Elle ne garantirait pas que chaque adresse réelle possède une histoire. Elle ne certifierait pas chaque ligne du registre et n’autoriserait pas des requêtes massives. Elle prouverait une seule chose utile : sous une version donnée, l’entrée IPv6, le ticket, le format et une histoire attendue ont fonctionné ensemble.

L’institution est la seule à pouvoir lever le doute sans l’aggraver

ARIN possède les données, gère les droits d’accès, produit le rapport, publie la documentation et tient le registre ACSP. L’opérateur autorisé possède son motif de recherche et les preuves extérieures. L’entité anciennement associée à la ressource peut subir les conséquences d’une interprétation, sans pouvoir définir la conservation ni le résultat.

Cette répartition rend difficile une preuve communautaire propre. Un utilisateur ne devrait pas publier un rapport client pour montrer que la fonction marche. Plusieurs captures anonymisées ne disent rien si les adresses n’avaient pas d’histoire connue ou si les droits différaient. ARIN, en revanche, peut utiliser un cas contrôlé et ne divulguer que les contrôles réussis.

La fragmentation documentaire est également compréhensible. L’équipe API entretient la syntaxe ; l’équipe données gère la génération ; l’équipe ACSP ferme une fiche lorsqu’elle passe dans un autre processus ; les notes de version sélectionnent les changements les plus visibles. Chaque document peut être juste localement. L’utilisateur, lui, traverse toutes ces responsabilités dans une seule enquête.

Une conclusion sans verdict technique

Les sources ne permettent pas d’affirmer que WhoWas refuse IPv6 : la méthode actuelle l’accepte comme entrée. Elles ne permettent pas davantage de certifier la totalité de l’histoire IPv6, car aucun résultat contrôlé n’est publié ici et aucun rapport autorisé n’a été examiné. Il n’existe pas de retard démontrable, puisque les réponses ACSP n’ont promis aucune date. Enfin, la fermeture des suggestions ne signifie pas mise en service.

Le constat défendable est plus précis. Deux utilisateurs ont demandé une capacité historique ; ARIN l’a jugée utile et l’a envoyée vers la priorisation ; la documentation actuelle couvre déjà IPv6 au niveau de l’entrée et du format ; aucune identité de version ne relie publiquement ces éléments.

Un reçu de capacité est proportionné à ce manque. Si IPv6 est déjà livré, il le prouve sans exposer de données réelles. Si l’amélioration reste en cours, il fournit un critère de fin plutôt qu’une date inventée. Si la couverture est partielle, il rend les limites exploitables. Surtout, il empêche qu’un ticket correctement créé soit pris pour la preuve de toute une archive.

Sources