Résumé

  • Les pages de ressources de numéros actuelles de l’IANA apportent des preuves publiques importantes: registres d’allocation IPv4 et IPv6 avec dates de dernière mise à jour, formats CSV, XML, HTML et texte disponibles, plages de numéros AS, références aux RIR, aux politiques globales et procédures de demande. C’est un registre public solide, mais principalement un état des lieux avec des dates limitées, et non une piste d’audit externe complète.
  • La RFC 7020 décrit le rôle de l’IANA comme la gestion du sommet des hiérarchies d’allocation d’adresses IP et de numéros AS, avec l’exactitude de l’enregistrement et l’unicité comme exigences fondamentales. Ces exigences impliquent plus qu’un tableau final visible. Elles nécessitent un historique suffisant pour qu’un observateur externe puisse vérifier si une modification était autorisée, opportune, sans chevauchement et conforme à la politique globale applicable.
  • La procédure de demande publique identifie les preuves que les RIR fournissent pour les allocations IPv6, de numéros AS et d’IPv4 récupérées. Une grande partie de ces preuves démontre l’éligibilité, mais le registre public n’expose pas chaque dossier de demande, étape de validation, horodatage, état d’approbation, correction, restitution, remplacement ou identité du signataire. Une certaine confidentialité est légitime; une dépendance totale à la confiance ne l’est pas.
  • Une meilleure piste d’audit des allocations publierait des instantanés de registre signés, des empreintes cryptographiques, des enregistrements de modifications datés, des références de classe de demande, des états avant/après, des notes de correction réversibles et des accusés de réception des RIR. L’objectif n’est pas de politiser l’IANA, mais de rendre le registre mondial d’unicité reconstituable de manière indépendante.

Un registre n’est pas une piste d’audit

Le système de ressources de numéros Internet s’est longtemps appuyé sur la visibilité publique des registres. N’importe qui peut ouvrir le registre d’espace d’adressage IPv4 de l’IANA et voir un tableau de blocs /8, désignations, dates, références WHOIS et RDAP, valeurs d’état et notes. N’importe qui peut ouvrir le registre d’espace d’adressage unicast global IPv6 et voir les préfixes alloués, les désignations de RIR et les dates. N’importe qui peut ouvrir le registre des numéros de systèmes autonomes et voir les plages administrées par les RIR. La nature publique de ces pages est l’un des succès discrets de la coordination Internet.

Pourtant, un tableau actuel et une piste d’audit sont des choses différentes. Un tableau indique ce que le registre dit maintenant. Une piste d’audit permet à un observateur externe de reconstituer comment il en est arrivé là. Elle répond à quand un changement a été demandé, qui l’a demandé, quelle règle d’éligibilité s’appliquait, quelles preuves ont été vérifiées, quel était l’état antérieur, ce qui a changé, qui a approuvé le changement, quand l’enregistrement public a été mis à jour, si une correction ultérieure a modifié l’entrée, et si le changement peut être vérifié par rapport à un enregistrement indépendant.

Cette distinction est importante parce que l’IANA se situe au sommet d’une hiérarchie. La plupart des décisions d’adressage et de numéros AS ont lieu au niveau des RIR. Le nombre de transactions directes de l’IANA peut être faible par rapport aux registres régionaux. Mais l’enregistrement de premier niveau établit le pool à partir duquel découle l’autorité régionale. Si une entrée du pool mondial est ambiguë, toute la chaîne de dépendance ultérieure hérite de cette ambiguïté.

Si une date d’allocation, une désignation ou un statut de premier niveau change sans historique visible, les utilisateurs en aval peuvent voir le résultat mais pas la preuve.

La thèse de cet article est donc étroite. Elle ne prétend pas que les registres actuels de l’IANA ne sont pas fiables. Elle ne prétend pas qu’un conflit caché existe derrière une entrée particulière. Elle affirme que la réputation institutionnelle ne devrait pas être la principale méthode de preuve pour les modifications du pool mondial. Un système qui coordonne des numéros uniques au niveau mondial devrait permettre aux observateurs externes de reconstituer sa propre histoire avec le même sérieux que celui que les opérateurs appliquent aux données de routage, de certificats et de registres.

Le sommet de la hiérarchie des numéros

La RFC 7020 est un point de départ utile car elle énonce la structure sans l’idéaliser. La hiérarchie des registres Internet est ancrée dans la fonction d’allocation d’adresses de l’IANA, qui dessert les registres Internet régionaux. Les RIR desservent ensuite les registres locaux et d’autres clients. Le document décrit des objectifs qui incluent la gestion du pool d’allocation, l’allocation hiérarchique et l’exactitude de l’enregistrement. L’objectif d’exactitude de l’enregistrement est particulièrement important: l’unicité garantit que les adresses IP et les numéros AS ne sont pas alloués à plus d’une entité en même temps.

La même RFC limite également le rôle du registre. Le fait que les adresses soient effectivement annoncées sur l’Internet et la manière dont elles sont annoncées sont des considérations opérationnelles qui ne relèvent pas du système de registre. Cette limite est saine. L’IANA ne doit pas devenir une police du routage, un régulateur de marché ou un juge de chaque conflit en aval. Mais cette limite clarifie aussi ce que l’IANA doit bien faire. Si le travail de l’IANA est le registre de premier niveau, alors la qualité probante des modifications du registre de premier niveau est au cœur de ce travail.

Les statuts de l’ICANN font écho à la restriction de la mission. Ils décrivent le rôle de l’ICANN dans la coordination de l’allocation et de l’attribution au plus haut niveau des numéros IP et des numéros AS, la fourniture de services d’enregistrement et d’un accès ouvert aux registres de numéros mondiaux à la demande de l’IETF et des RIR, et la facilitation des politiques de registre de numéros mondiaux par la communauté concernée et les tâches connexes convenues. Il ne s’agit pas d’un pouvoir général sur tous les réseaux. Il s’agit d’une fonction d’enregistrement et de coordination.

Une fonction restreinte devrait être facile à auditer précisément parce que ses limites sont limitées.

C’est pourquoi une piste d’audit des allocations n’est pas une demande de nouveau pouvoir politique. C’est une exigence que le registre public corresponde à l’importance du pouvoir existant. Si l’IANA modifie le statut d’un bloc, alloue un préfixe IPv6, enregistre une plage de numéros AS, accepte une restitution ou modifie un titulaire nommé, l’événement doit être prouvable de l’extérieur à un niveau approprié au risque. Plus le registre est élevé, moins il est acceptable de dire simplement que le tableau final semble correct.

Ce que l’IANA expose aujourd’hui

Le registre public actuel présente plusieurs atouts. Le registre de l’espace d’adressage IPv4 indique une date de dernière mise à jour au 10 octobre 2025. Il énumère la procédure d’enregistrement: les allocations aux RIR sont effectuées dans le cadre des politiques globales, tandis que les autres attributions nécessitent un examen par l’IETF. Il explique que l’IANA gérait à l’origine tout l’espace d’adressage IPv4 directement et que des parties ont ensuite été allouées à d’autres registres à des fins spécifiques ou pour des zones régionales. Il renvoie à la RFC 7249 et propose des formats CSV, XML, HTML et texte brut.

Le registre unicast global IPv6 indique également une date de dernière mise à jour au 10 octobre 2025, renvoie à la politique globale pour les allocations aux RIR et à l’examen par l’IETF pour les autres attributions, et explique que l’espace unicast global attribuable est le bloc 2000::/3, l’espace non répertorié dans ce bloc étant réservé par l’IANA pour une allocation future. Il propose également des formats CSV, XML, HTML et texte brut. Le tableau comprend des entrées où une allocation ultérieure intègre une allocation précédente, rendant visible au moins une certaine consolidation historique.

Le registre des numéros AS indique une date de dernière mise à jour au 1er juin 2026. Il explique que les numéros AS sont utilisés par les protocoles de routage, que l’IANA alloue des numéros AS aux RIR et que les RIR les allouent ou les attribuent ensuite aux opérateurs de réseau conformément aux politiques des RIR. Il énumère les cinq RIR et fournit plusieurs formats publics. La page des ressources de numéros renvoie également aux données d’allocation des RIR, aux procédures de demande, aux politiques globales et à la documentation technique.

Ce ne sont pas des divulgations anodines. Elles rendent les registres utilisables. Elles prennent en charge les vérifications automatisées. Elles permettent aux chercheurs et aux opérateurs de comparer les désignations de premier niveau avec les données des RIR. Elles créent une base de référence publique par rapport à laquelle les registres en aval peuvent être compris. Les formats disponibles sont particulièrement importants car un registre qui peut être téléchargé et comparé est plus responsable qu’un tableau uniquement accessible sur le Web.

La lacune réside dans ce que le registre public ne montre pas. Une date de dernière mise à jour indique que le registre a été modifié ou republié à cette date. Elle ne montre pas chaque événement qui a conduit à l’état actuel. Une colonne de date peut indiquer un mois ou un jour d’allocation pour une entrée. Elle ne montre pas nécessairement la réception de la demande, la validation, l’approbation, la publication, la correction ou la modification ultérieure. Un fichier CSV permet au public de comparer deux versions si le public a conservé les deux. Il ne fournit pas en lui-même une chaîne de versions complète.

L’IPv4 après épuisement a encore besoin d’historique

La réponse facile est que le pool libre IPv4 de l’IANA est épuisé, de sorte que le problème d’audit est en grande partie historique. Cette réponse est trop superficielle. L’épuisement n’a pas mis fin à la nécessité de savoir ce qui est arrivé aux enregistrements IPv4. Il a changé la nature des preuves. Les questions restantes concernent l’espace récupéré, les désignations héritées, la clarté des statuts, les restitutions, les entrées à usage spécial, les références aux RIR et la relation entre le tableau de l’IANA et les registres régionaux.

La procédure de demande de l’IANA pour l’espace IPv4 récupéré montre pourquoi. Lorsqu’un RIR dispose de moins de la moitié d’un /8 en inventaire, il doit informer l’IANA de commencer les allocations à tous les RIR à partir du pool IPv4 récupéré. La page indique qu’il s’agit d’un événement unique, réalisé selon un calendrier plutôt qu’en réponse à des demandes distinctes de chaque RIR, et qu’un seul RIR doit faire la demande pour que l’allocation à tous les RIR commence. Cette conception rend les preuves procédurales importantes.

L’avis de déclenchement, l’état de l’inventaire, le calendrier, la formule et le résultat de l’allocation font tous partie de la légitimité publique de l’événement du pool récupéré.

Le public ne devrait pas avoir à se contenter de croire que l’événement s’est déroulé correctement. Il devrait pouvoir voir, à un niveau approprié, que le déclencheur était valide, que le calendrier a été appliqué, que l’état du pool avant et après la distribution a été préservé et que chaque accusé de réception des RIR correspondait aux entrées finales. La correspondance opérationnelle sensible peut être protégée, mais la preuve de l’événement doit rester visible.

Les désignations IPv4 historiques sont également importantes dans les contextes économiques et juridiques. Les blocs hérités, les blocs à usage spécial et les blocs administrés par les RIR peuvent apparaître dans les vérifications diligentes de transfert, les décisions de sécurité de routage, les dossiers de prêteurs, les examens d’approvisionnement et les archives judiciaires. Le tableau de l’IANA n’est pas la preuve complète des droits d’un titulaire, mais il fait partie de la chaîne qui indique aux lecteurs quel registre est responsable d’un espace.

Si une entrée a été corrigée ou reclassée, l’historique de cette correction peut être important. Un simple tableau actuel ne suffit pas pour une chaîne contestée.

Les entrées IPv6 montrent la valeur et les limites des dates visibles

L’IPv6 paraît plus propre parce que le tableau public répertorie des préfixes plus grands et une architecture d’allocation plus récente. La page unicast global IPv6 identifie l’espace 2000::/3, indique que l’espace non répertorié dans le bloc reste réservé par l’IANA et énumère les préfixes alloués aux RIR avec des références WHOIS et RDAP. Certaines entrées incluent des notes sur une allocation ultérieure intégrant une précédente. Cela est précieux car cela avertit le lecteur que le préfixe actuel visible n’est pas toute l’histoire.

Mais le même exemple montre la limite. Si une allocation ultérieure intègre une précédente, le lecteur a besoin de connaître l’état antérieur, le nouvel état, pourquoi la consolidation a eu lieu, si des enregistrements en aval ont changé, et quelle demande ou condition de politique a soutenu la mise à jour. Une note est utile; un historique d’événement reconstituable est préférable.

La procédure de demande de l’IANA pour l’IPv6 exige que les RIR qui demandent de l’espace supplémentaire fournissent des résumés d’utilisation et de fragmentation ou des données d’allocation récentes, selon la voie d’éligibilité. Cela signifie qu’une entrée d’allocation publique repose sur des preuves sous-jacentes. Le public n’a pas besoin de tous les détails opérationnels de la planification d’un RIR, mais il devrait voir la classe de demande, la règle d’éligibilité invoquée, la date à laquelle la demande a été acceptée comme complète, la date d’approbation, l’allocation effectuée et la version de la politique globale appliquée.

Sinon, un lecteur externe peut voir le résultat mais ne peut pas tester pleinement le cheminement.

L’IPv6 a également un horizon temporel long. Le fait qu’une grande partie de 2000::/3 reste réservée pour une allocation future signifie que les décisions prises maintenant peuvent façonner l’avenir pendant des décennies. Une piste historique faible peut ne pas nuire lorsque les événements sont peu nombreux et incontestés. Elle devient coûteuse lorsqu’un conflit institutionnel ultérieur demande pourquoi une allocation a eu lieu, si une autre a été retardée ou si les critères de politique ont été appliqués de manière cohérente entre les RIR.

Les numéros AS rendent les changements de limites visibles mais pas complets

Les numéros AS sont souvent considérés comme plus simples que les adresses, car ce sont des identifiants pour les systèmes de routage plutôt que des blocs d’adresses avec taille et géographie. Le registre des numéros AS reste un enregistrement d’allocation de premier niveau. Il indique au public quelles plages sont administrées par quels RIR et distingue les plages réservées ou à usage spécial par référence. Les RIR allouent ou attribuent ensuite des ASN aux opérateurs de réseau conformément aux politiques régionales.

La procédure de demande de numéros AS montre le besoin de preuves. Un RIR demandant des numéros AS supplémentaires parce qu’il a attribué ou alloué plus de quatre-vingts pour cent de son dernier bloc doit fournir un résumé des attributions ou allocations. Si le RIR demande plus d’un bloc, il doit fournir un résumé d’utilisation sur six mois. Une autre voie s’applique lorsque les numéros AS libres sont inférieurs à deux mois de besoin. Ce sont des déclencheurs quantitatifs. Les déclencheurs quantitatifs ne sont auditables que si les preuves, l’horodatage et le calcul sont conservés.

Le registre public n’a pas besoin de publier chaque demande d’opérateur de réseau derrière les numéros du RIR. Il devrait publier suffisamment de preuves de premier niveau pour prouver que la demande du RIR appartenait à la classe d’éligibilité déclarée. Cela pourrait signifier un identifiant de demande, une étiquette de classe, une date de réception, une date de validation, une mesure du pool avant/après exprimée à un niveau sûr, le bloc attribué et une signature de l’opérateur responsable. Le tableau final des plages de numéros AS est la fin de l’événement, pas l’événement lui-même.

La conséquence de preuves faibles peut être pratique. Si un conflit ultérieur survient quant à savoir si un RIR a épuisé une plage, si la limite d’une plage a changé ou si une réservation à usage spécial a été respectée, les opérateurs ont besoin de plus que de mémoire. Ils ont besoin d’un historique qui peut être cité, reproduit et vérifié. C’est la différence entre une institution de confiance et un enregistrement fiable.

Les preuves de demande ne devraient pas disparaître dans la correspondance

La procédure publique de demande de ressources de numéros de l’IANA est exceptionnellement claire sur ce que les RIR doivent fournir. Elle identifie les conditions de déclenchement du pool IPv4 récupéré, les demandes d’allocation IPv6, les demandes d’allocation de numéros AS et les modifications de titulaire nommé. Elle nomme même les boîtes aux lettres de demande pertinentes et indique que les titulaires actuels et nouveaux sont contactés pour confirmer ou rejeter un changement de titulaire nommé avant que l’enregistrement ne soit mis à jour.

Cela suffit à montrer que les décisions d’allocation ne sont pas arbitraires. Elles sont liées à des seuils, des résumés, des modèles et des confirmations. Mais le registre public n’expose pas une piste d’événement complète de la demande à la mise à jour du registre. Il ne montre pas d’horodatage de réception public, d’état de validation, de signature d’approbation, de résumé des preuves, d’horodatage de publication ou de note publique lorsqu’une demande est rejetée, retirée, corrigée ou remplacée.

Une partie de cette absence est défendable. Les demandes des RIR peuvent inclure des détails de planification non publics. Un changement de titulaire nommé peut impliquer une validation de contact qui ne devrait pas révéler de données personnelles ou de pratiques de sécurité. Les communications sensibles en matière de sécurité ne devraient pas être rendues publiques simplement pour satisfaire la curiosité. L’objectif n’est pas de tout publier. L’objectif est de publier une preuve publique de la décision tout en protégeant les détails sensibles.

Une conception simple séparerait les preuves de la preuve publique. Le dossier de preuves privé reste entre les parties. L’enregistrement de preuve publique indique la classe de demande, la version de la politique, le résultat de la validation, l’état du registre avant/après, l’heure de publication et un engagement cryptographique envers le dossier de preuves privé. Si une contestation sérieuse survient ultérieurement, un examinateur autorisé peut comparer les preuves privées à l’engagement public sans demander au monde de faire confiance à une affirmation après coup.

C’est du bon sens dans d’autres systèmes d’enregistrement. Un registre foncier public peut ne pas exposer intégralement tous les documents justificatifs, mais il conserve les numéros d’acte, les dates et les états antérieurs. Un dépositaire de titres peut ne pas montrer chaque dossier client, mais les événements de règlement laissent des traces. Les ressources de numéros Internet n’ont pas besoin de copier exactement ces champs. Elles ont besoin de la même idée: la finalité publique appuyée par un historique vérifiable.

Les dates de dernière mise à jour sont trop grossières

La ligne « Dernière mise à jour » sur les pages de registre de l’IANA est utile car elle indique aux lecteurs à quel point la page est actuelle. Elle n’est pas suffisante car elle se situe au niveau de la page, pas au niveau de l’événement. Un registre peut être republié pour un petit changement, une correction de formatage, une mise à jour de référence, un changement de statut ou une allocation. Une seule date ne peut pas indiquer quel événement s’est produit. Elle ne peut pas non plus dire si plusieurs événements se sont produits entre les captures publiques.

La reconstitution externe repose actuellement fortement sur la comparaison. Si un chercheur a enregistré le CSV d’hier et celui d’aujourd’hui, la différence révèle un changement. Si personne n’a enregistré le fichier précédent, le public peut s’appuyer sur les archives Web, les miroirs privés ou la mémoire institutionnelle. C’est une faiblesse évitable. L’opérateur de registre faisant autorité devrait publier l’historique des versions, et non forcer le public à le reconstituer à partir de captures aléatoires.

Des dates au niveau de l’événement aideraient également à distinguer plusieurs moments importants. La demande reçue n’est pas la même chose que la demande complète. Complète n’est pas la même chose qu’approuvée. Approuvée n’est pas la même chose que tableau public mis à jour. Tableau public mis à jour n’est pas la même chose que toutes les références des RIR en aval alignées. Si un conflit concerne un retard, chaque moment compte. Si un conflit concerne l’exactitude, les états avant/après comptent. Si un conflit concerne l’autorité, l’identité du signataire et la version de la politique comptent.

Le public n’a pas besoin d’un flux d’événements écrasant. Les événements de ressources de numéros de premier niveau sont relativement peu nombreux. Cela rend une meilleure piste d’audit plus pratique, pas moins. Un petit nombre d’événements importants peut être documenté avec soin sans créer une couche de publication lourde. La rareté des événements est un argument en faveur de la précision.

La leçon de l’épuisement de 2011

L’épuisement du pool libre IPv4 de l’IANA en 2011 est souvent rappelé comme une cérémonie et un jalon de rareté. Il devrait également être rappelé comme une leçon d’audit. L’allocation finale des blocs IPv4 /8 aux cinq RIR était visible mondialement, dictée par les politiques et institutionnellement significative. Elle a fait passer l’IANA d’une allocation IPv4 nouvelle ordinaire à un monde d’espace récupéré, de transferts, de rareté régionale et de marchés en aval.

Pour ce type d’événement, la preuve publique est importante. La question n’est pas seulement de savoir qui a reçu les derniers blocs. Il s’agit de savoir quelle politique a régi la distribution, quel était l’état du pool juste avant l’événement, quand l’événement a été exécuté, comment les entrées finales ont été enregistrées et quelles preuves permettraient à un lecteur ultérieur de reconstituer la transition. Si les seules preuves durables sont un tableau et un compte rendu de presse, l’enregistrement est plus faible que ce que l’événement mérite.

Ce n’est pas parce que 2011 est suspect. C’est parce que 2011 est fondateur. Les événements fondateurs devraient être exceptionnellement bien documentés. Ils deviennent des points de référence pour les politiques, les finances, les litiges et la légitimité institutionnelle ultérieurs. Si de futurs événements de pool récupéré, des corrections d’allocation ou des modifications de registre deviennent controversés, le public se tournera vers la norme établie lors des transitions majeures. Un enregistrement cérémoniel ne remplace pas une chaîne d’événements auditable.

Le même raisonnement s’applique aux futurs jalons IPv6 et de numéros AS. L’offre IPv6 est bien plus large, mais les règles d’allocation déterminent toujours quand et comment les grands blocs sont transférés aux registres régionaux. La pression d’épuisement des numéros AS est différente, mais les seuils de demande et les limites de plage restent importants. Le fait que le système fonctionne tranquillement aujourd’hui devrait être utilisé pour renforcer l’enregistrement avant un événement stressant, et non après.

Ce que contiendrait une allocation reconstituable de l’extérieur

Une allocation reconstituable de l’extérieur n’a pas besoin de publier chaque message privé. Elle a besoin de suffisamment de données publiques pour qu’un observateur externe informé puisse reconstituer l’état autorisé. L’enregistrement devrait commencer par un identifiant d’événement. Il devrait indiquer le type de ressource: pool IPv4 récupéré, unicast global IPv6, plage de numéros AS, changement de titulaire, correction, restitution ou réservation. Il devrait indiquer la politique ou la voie de recours applicable et la version en vigueur.

L’enregistrement devrait montrer la date et l’heure de réception de la demande, la date et l’heure à laquelle elle est devenue complète et la date et l’heure d’approbation. Il devrait identifier le RIR demandeur ou la partie autorisée. Il devrait montrer l’état antérieur du registre et le nouvel état du registre. Il devrait enregistrer le changement de statut, le cas échéant. Il devrait inclure la catégorie de raison publique, telle que l’allocation par seuil, la distribution programmée du pool récupéré, la correction, l’espace restitué, l’attribution par examen de l’IETF ou la confirmation du titulaire nommé.

L’enregistrement devrait ensuite inclure la preuve. À tout le moins, l’IANA pourrait publier des instantanés de registre signés et des empreintes de chaque format téléchargeable. Elle pourrait publier un journal des modifications avec des lignes avant/après. Elle pourrait inclure un engagement d’empreinte envers le dossier de preuves de la demande, sans exposer de matériel sensible. Elle pourrait inclure des accusés de réception des RIR. Elle pourrait conserver les instantanés remplacés dans une archive facile à parcourir.

Le tableau de registre final devrait renvoyer aux enregistrements d’événements pertinents. Un lecteur consultant un préfixe IPv6 ou une plage de numéros AS n’aurait pas besoin de deviner à partir d’une colonne de date. Il pourrait cliquer sur l’historique des événements et voir comment l’entrée a été créée ou modifiée. C’est la différence entre un registre qui affirme l’autorité et un registre qui la prouve.

La signature n’est pas un remède en soi

Les signatures cryptographiques peuvent aider, mais elles ne résolvent pas tout le problème. Un mauvais enregistrement signé reste mauvais. Un tableau actuel signé prouve que le tableau a été émis par le signataire, pas que l’allocation était éligible, opportune ou correctement classifiée. Les signatures doivent être attachées à un enregistrement d’événement plus riche.

Le rôle approprié de la signature est l’intégrité et la non-répudiation. Elle devrait prouver qu’un instantané donné a existé à un moment donné, qu’il n’a pas été altéré et que l’opérateur responsable du registre l’a émis. Les empreintes devraient permettre aux observateurs externes de comparer les formats CSV, XML, HTML et texte téléchargés et de confirmer qu’ils représentent le même état. L’horodatage devrait empêcher une reconstitution ultérieure de modifier discrètement l’ordre des événements.

Mais les faits de gouvernance humaine comptent toujours. Quelle politique s’appliquait? Quel RIR a demandé l’allocation? Quel seuil de preuve a été atteint? Une entrée a-t-elle été corrigée en raison d’une erreur d’écriture ou parce qu’une allocation antérieure a été annulée? Un événement a-t-il remplacé un événement antérieur? Une signature ne peut répondre à ces questions que si le matériel signé les contient.

C’est pourquoi la piste d’audit devrait être conçue comme un enregistrement probant, et non comme une décoration de sécurité. Elle devrait être compréhensible par les opérateurs, les tribunaux, les auditeurs, le personnel du registre, les chercheurs et les communautés concernées. La preuve devrait rendre la décision humaine visible, pas la cacher derrière un sceau technique.

Le lien avec les RIR doit faire partie de la chaîne

L’IANA n’est que le sommet de la hiérarchie. Une allocation devient opérationnellement significative lorsque le RIR destinataire l’enregistre et l’administre. Une piste de premier niveau reconstituable devrait donc lier les événements de l’IANA aux accusés de réception des RIR et aux références publiques en aval. L’objectif n’est pas de rendre l’IANA responsable de chaque attribution des RIR. Il s’agit de montrer que le transfert a eu lieu et que les deux registres publics concordent à la frontière.

Les tableaux de l’IANA incluent déjà des références WHOIS et RDAP pour de nombreuses entrées. C’est précieux. Une piste d’audit plus solide enregistrerait l’événement de transfert: l’IANA a alloué ou mis à jour l’entrée de premier niveau; le RIR a accusé réception; le service public du RIR a reflété la plage; tout décalage ou correction connu a été noté. Si des enregistrements ultérieurs divergent, l’événement frontière indique aux lecteurs par où commencer.

Cela compte dans les scénarios de défaillance. Si un RIR est confronté à des tensions de gouvernance, des litiges, des pressions de sanctions, une panne technique ou un risque de continuité, les opérateurs peuvent avoir besoin de prouver l’origine de premier niveau d’une ressource alors que les services régionaux sont altérés. Une chaîne d’événements signée de l’IANA ne remplacerait pas le RIR. Elle fournirait un ancrage stable pour la continuité, la migration, le séquestre, l’action du syndic ou les dispositions de service temporaires.

Cela compte également dans les finances ordinaires. Les vérifications diligentes de transfert IPv4, les dossiers de prêt, les examens de location, les vérifications d’adresses BYOA (Bring Your Own Address) dans le cloud et les achats du secteur public peuvent tous demander si le chemin de registre d’une ressource est propre. L’enregistrement de premier niveau de l’IANA n’est généralement qu’une couche, mais une première couche faible affaiblit chaque certificat de confort ultérieur. Une piste d’audit de l’IANA vérifiable réduirait la prime payée pour l’incertitude.

Les corrections sont aussi importantes que les allocations

Les événements d’allocation attirent l’attention parce qu’ils déplacent des ressources dans un pool régional. Les corrections sont plus discrètes et parfois plus importantes. Une correction peut ajuster une date, un statut, une désignation, une référence de contact, un point de terminaison RDAP, une note ou une relation d’entrée antérieure. Certaines corrections sont des réparations de formatage inoffensives. D’autres peuvent affecter la façon dont un tiers comprend l’autorité, la continuité, le statut hérité ou les voies de recours disponibles.

Le registre public devrait distinguer les types de correction. Une réparation orthographique n’est pas la même chose qu’un changement de statut. Un nouveau point de terminaison RDAP n’est pas la même chose qu’un changement de registre responsable. Une note qui intègre une allocation antérieure n’est pas la même chose qu’une nouvelle allocation. Si toutes les corrections n’apparaissent que comme un nouveau tableau final, les lecteurs ne peuvent pas déterminer si un changement a modifié le fond ou la forme.

La transparence des corrections protège également l’opérateur de registre. Si une erreur est découverte et corrigée, la meilleure réponse n’est pas le silence. C’est un événement de correction visible avec l’ancienne valeur, la nouvelle valeur, la catégorie de raison et la date. Cet enregistrement montre que le registre peut réparer les erreurs sans prétendre que l’erreur n’a jamais existé. Il permet également aux utilisateurs en aval de mettre à jour leurs propres enregistrements avec précision. Dans une fonction de coordination mondiale, une correction silencieuse peut créer plus de suspicion que l’erreur d’origine.

Les restitutions nécessitent le même traitement. Si un bloc ou une plage retourne dans un pool, l’événement devrait indiquer qui l’a restitué, en vertu de quelle règle, quand l’état du registre a changé, si la ressource restituée est entrée dans un pool récupéré ou un état réservé, et quel événement ultérieur l’a déplacée à nouveau. Les ressources restituées peuvent être porteuses de réputation, d’historique de routage, de mémoire de géolocalisation et d’attentes commerciales. L’enregistrement de premier niveau ne devrait pas laisser entendre qu’un préfixe restitué est vierge de tout historique.

C’est particulièrement important pour l’IPv4. La rareté donne un poids économique à chaque bloc récupéré ou reclassé. Un bloc restitué peut être alloué ultérieurement dans le cadre d’une politique globale. Un acheteur, un prêteur, une agence publique ou un opérateur de réseau peut demander si le chemin du bloc est propre. La réponse ne devrait pas dépendre de la reconstitution d’anciennes captures Web. Elle devrait être visible à partir de la piste d’événements faisant autorité.

Les formats publics devraient porter une preuve identique

La mise à disposition par l’IANA des formats CSV, XML, HTML et texte brut est un atout majeur. Différents utilisateurs ont besoin de différents formats. Un chercheur peut préférer le CSV, un outil peut préférer le XML, un lecteur humain peut utiliser le HTML et un opérateur peut archiver le texte. La couche de preuve devrait traiter ces formats comme différentes expressions du même état faisant autorité.

Cela signifie que chaque version publiée devrait porter ou être accompagnée d’un ensemble d’empreintes. Le public devrait pouvoir vérifier que les téléchargements CSV, XML et texte représentent tous la même version du registre. Si un format est régénéré ultérieurement pour des raisons de formatage, l’enregistrement d’événement devrait indiquer si l’état du registre a changé. Cela évite une ambiguïté courante dans les systèmes de données publics: le fichier a-t-il changé parce qu’un enregistrement a changé, ou parce que la présentation a changé?

Un identifiant de version serait utile. Au lieu de s’appuyer uniquement sur une date de dernière mise à jour, chaque registre pourrait avoir une version augmentant de manière monotone. Chaque événement identifierait la version antérieure et la nouvelle version. Les instantanés seraient conservés. Les utilisateurs pourraient citer « registre unicast global IPv6 version X » plutôt qu’un fichier téléchargé sans identité d’événement durable. Les tribunaux, les auditeurs et les opérateurs auraient une référence plus claire.

La même preuve devrait être disponible pour les notes et les références. Si une référence RFC change, si un lien de politique globale est mis à jour ou si l’URL RDAP d’un RIR change, il se peut que ce ne soit pas un événement d’allocation. Cela fait toujours partie du registre public. Un historique des notes versionné empêcherait que la maintenance des références ne soit confondue avec un mouvement de ressources.

Les archives Web ne sont pas un système de gouvernance

Dans la pratique, les chercheurs reconstituent souvent l’historique du registre à l’aide de fichiers sauvegardés, de miroirs et d’archives Web publiques. Ces outils sont utiles, mais ils ne devraient pas être le principal mécanisme d’audit pour un registre mondial d’identifiants. Ils sont incomplets par conception. Ils capturent à des intervalles choisis par des tiers. Ils peuvent manquer des états éphémères. Ils peuvent conserver une page après un changement de présentation mais pas après un changement de données, ou l’inverse. Ils peuvent être bloqués, retardés ou indisponibles.

Un registre faisant autorité ne devrait pas externaliser sa mémoire au hasard. Si le public dépend de miroirs privés pour savoir ce que le registre a dit le mois dernier, le registre a sous-produit des preuves. Si un conflit dépend de savoir si une archive Web a capturé le bon moment, l’enregistrement public est trop faible. Une fonction de coordination mondiale devrait préserver sa propre histoire d’une manière délibérée, durable et facile à citer.

Ce n’est pas une critique de l’archivage indépendant. Les archives indépendantes sont des vérifications précieuses de l’histoire officielle. Elles peuvent prouver qu’un enregistrement public a existé, révéler des modifications ultérieures et préserver le matériel après des défaillances institutionnelles. Mais leur valeur est plus grande lorsqu’elles peuvent être comparées à une chaîne de versions officielle. L’enregistrement officiel devrait dire ce que le registre avait l’intention de publier. Les captures indépendantes peuvent alors vérifier que la publication a eu lieu et n’a pas été réécrite ultérieurement.

La différence est subtile mais importante. Sans piste d’événements officielle, les archives extérieures deviennent la principale preuve. Avec une piste d’événements officielle, les archives extérieures deviennent une corroboration. Un système mature devrait vouloir une corroboration, pas une dépendance.

Les pistes d’audit réduisent les jeux politiques institutionnels

Certaines personnes entendent « piste d’audit » et supposent une demande de surveillance politique. Dans le domaine des ressources de numéros, c’est le contraire qui est vrai. Un enregistrement probant plus solide peut réduire les jeux politiques car il restreint les faits. Lorsque l’enregistrement montre clairement la version de la politique, la classe de demande, les horodatages, l’état antérieur, le nouvel état et les parties responsables, moins de conflits doivent être réglés par la réputation institutionnelle.

C’est particulièrement important lorsque les institutions sont sous pression. Si un RIR est contesté devant les tribunaux, soumis à des pressions de gouvernance inhabituelles, touché par des sanctions ou critiqué par ses membres, chaque enregistrement ambigu peut devenir un symbole politique. Une piste d’événements propre de l’IANA donne à toutes les parties une base de référence commune. Elle ne tranche pas le conflit régional. Elle indique ce que l’enregistrement de premier niveau a fait et n’a pas fait.

Il en va de même pour les propositions futures de concurrence ou de portabilité. Si les services de registre deviennent plus portables ou si de nouveaux fournisseurs de services cherchent à être reconnus par des preuves plutôt que par le parrainage, le registre mondial doit distinguer l’allocation en double de la migration de service. Cette distinction nécessite un historique. Un tableau d’état actuel peut montrer qu’une plage est administrée par un registre. Il ne peut pas à lui seul prouver la séquence d’avis, d’accusés de réception et de transitions d’état qui ont rendu une migration sûre. Une piste d’événements le pourrait.

Les pistes d’audit protègent également l’IANA et PTI. Lorsqu’une décision est remise en question, l’opérateur peut se référer à l’enregistrement public des événements au lieu de s’appuyer sur la confiance générale. Plus l’enregistrement prouve, moins l’opérateur doit argumenter. C’est une posture saine pour un rôle de coordination technique étroit.

Les tribunaux, les auditeurs et les opérateurs posent des questions différentes

Un tribunal peut demander si une entrée particulière existait à une date particulière. Un auditeur peut demander si un changement de registre a suivi un contrôle approuvé. Un opérateur peut demander si le registre responsable d’un préfixe est suffisamment clair pour la sécurité du routage, le DNS inverse ou la confiance des contacts abuse. Un prêteur peut demander si la chaîne d’une ressource est suffisamment propre pour soutenir un covenant ou une analyse de garantie. Un acheteur du secteur public peut demander si le plan d’adressage du fournisseur repose sur des preuves de registre stables.

Ces questions sont liées mais pas identiques. Un tableau actuel de l’IANA les aide toutes, mais n’y répond complètement à aucune. Le tribunal a besoin de preuves spécifiques dans le temps. L’auditeur a besoin de preuves de contrôle. L’opérateur a besoin de clarté des limites. Le prêteur a besoin d’un historique des défauts. L’acheteur public a besoin de preuves de continuité. Une piste d’événements riche sert tous ces publics sans faire de l’un d’eux le centre du système.

L’avantage est cumulatif. Une fois que la piste d’événements de premier niveau existe, les RIR peuvent s’y référer dans leurs propres enregistrements. Les opérateurs peuvent la citer dans les dossiers de vérification diligente. Les chercheurs peuvent l’utiliser pour séparer les événements d’allocation de premier niveau du comportement d’enregistrement en aval. Les examinateurs de politiques peuvent voir à quelle fréquence certaines classes de demandes surviennent. Les futurs examens de responsabilité peuvent mesurer les taux de correction et les délais de publication sans demander au personnel de reconstituer l’historique manuellement.

Le résultat est un registre public plus utilisable. Pas une bureaucratie plus grande, pas un bureau d’allocation politisé, et pas une divulgation publique de dossiers de demande sensibles. Juste un registre qui permet d’inspecter sa propre histoire.

Responsabilité sans surcharge opérationnelle

Une préoccupation est qu’une piste d’audit plus riche pourrait ralentir un service qui a été fiable précisément parce qu’il est simple. Ce risque doit être pris au sérieux. L’IANA ne devrait pas être contrainte à un rituel d’approbation lourd pour chaque publication. La conception devrait correspondre à la taille et à la fréquence des événements de premier niveau. Étant donné que les allocations directes de ressources de numéros de premier niveau sont relativement limitées, un enregistrement plus solide peut être généré dans le cadre de l’acte normal de publication.

La voie la plus efficace est l’automatisation couplée à un examen. Lorsqu’un changement autorisé est approuvé, le système de publication du registre peut créer un enregistrement avant/après, hacher les formats téléchargeables, horodater l’événement, joindre la référence de politique et conserver l’instantané remplacé. Le personnel n’écrirait pas un long récit à chaque fois. Il vérifierait le type d’événement et le code de raison. Le matériel justificatif sensible resterait protégé tandis que son engagement de hachage est enregistré.

Une deuxième préoccupation est que la preuve publique pourrait créer de nouvelles surfaces d’attaque. La réponse est la divulgation sélective. Le public n’a pas besoin d’identifiants, de coordonnées privées, de contrôles de sécurité ou de documents de demande confidentiels. Il a besoin des faits publics d’autorité et de changement d’état. Un enregistrement de preuve bien conçu peut révéler moins d’informations privées qu’une divulgation ponctuelle ultérieure, car il sépare les faits d’événement sûrs des preuves protégées.

Une troisième préoccupation est qu’une trop grande précision pourrait inviter à des litiges sur des différences de temps insignifiantes. C’est possible, mais l’opacité est pire. Lorsque des enregistrements importants manquent d’horodatage, les conflits deviennent plus larges et plus spéculatifs. Une piste d’audit précise réduit les conflits. Elle indique aux parties ce qui s’est passé et quand. Si un retard était sans conséquence, l’enregistrement peut aussi le montrer.

Limites des sources et affirmations prudentes

Les sources examinées pour cet article montrent la structure du système de registre, les pages de registre public de l’IANA, les procédures de demande, les dates de dernière mise à jour et les références aux politiques globales. Elles ne fournissent pas un historique caché de chaque allocation. Elles n’établissent pas qu’une entrée actuelle particulière est erronée. Elles ne prouvent pas que l’IANA a perdu des preuves ou qu’un RIR a reçu une allocation inappropriée. La critique porte sur la vérifiabilité, pas sur l’affirmation d’une faute connue.

Les sources publiques ne révèlent pas non plus chaque demande privée, calcul d’éligibilité, confirmation ou correction. Cette absence peut refléter une confidentialité appropriée, une pratique opérationnelle ordinaire ou simplement le format public choisi pour les registres. L’article évite donc les statistiques exactes sur les demandes non divulguées, les taux de rejet, le nombre de corrections ou les délais de publication. Lorsque le registre public donne des dates de dernière mise à jour exactes ou des procédures déclarées, celles-ci sont utilisées.

Lorsque le registre public ne fournit pas de dénominateur, aucun dénominateur n’est inventé.

La limite des sources renforce le point central. Si un observateur externe ne peut pas reconstituer la chaîne d’événements à partir de documents publics, le système ne devrait pas répondre en demandant à l’observateur de faire confiance que tout va bien. Il devrait répondre en publiant une meilleure chaîne d’événements.

Conclusion

Les registres de ressources de numéros de l’IANA sont précieux parce qu’ils sont publics, structurés et mondialement reconnus. Ils ne suffisent pas parce que l’état actuel public n’est pas la même chose qu’un historique reconstituable. La norme plus forte est simple: chaque changement du pool mondial devrait laisser un enregistrement de preuve public montrant ce qui a changé, quand cela a changé, pourquoi cela a été autorisé et comment les états avant/après peuvent être vérifiés.

Cette norme ne transformerait pas l’IANA en une autorité politique. Elle ferait le contraire. Elle maintiendrait le rôle de l’IANA étroit en rendant le rôle étroit prouvable. Un registre mondial d’unicité ne devrait pas dépendre de la réputation quand il peut publier des preuves.

Sources examinées