Résumé

  • LACNIC a mis en œuvre LAC-2024-4 afin de publier les micro-attributions, récupérations et restitutions de sa réserve IPv4 critique; le risque d'un faux IXP constitue le scénario motivant, non la preuve d'un cas réel.
  • La copie du 16 juin conservée par Common Crawl remplit une vraie fonction d'inventaire, mais ses huit champs décrivent l'état registral. Ils n'identifient ni l'événement, ni l'état précédent, ni la règle, le motif borné ou la correction.
  • Il faut garder l'instantané et lui adjoindre un flux minimal, versionné et cumulatif de transitions, sans rendre publics les dossiers de demande ni les indices antifraude.

Ce que tait une ligne réservée

Le fichier commence par cette grammaire :

rir|pais|tipo|recurso|cantidad|fecha|estado|orgid

Huit champs suffisent à représenter beaucoup de choses. Une ligne attribuée donne un pays, une adresse de départ, une quantité, une date, un état assigned ou allocated et un OrgID. Une ligne disponible donne généralement 256 adresses, l'état reserved et des cases finales vides.

Le lecteur sait ce que le registre montre à cet instant. Il ne connaît pas la transition qui a produit cette image.

Une plage réservée peut n'avoir jamais été attribuée. Dans d'autres circonstances possibles, le même état final pourrait suivre une restitution volontaire, une récupération, une entrée en quarantaine, une correction ou une nouvelle découpe des lignes. Ces possibilités ne décrivent aucune plage précise. Elles démontrent seulement qu'un état ne contient pas sa propre causalité.

Il serait abusif d'en tirer un soupçon envers un titulaire. Un champ vide n'est pas une preuve de fraude; une ligne attribuée n'est pas une preuve d'activité de routage; une ligne réservée n'est pas une sanction. L'enjeu est documentaire : où le producteur du registre peut-il nommer le mouvement qu'il affirme ?

Une capture de LAC-2024-4 conservée par Common Crawl le 7 mars 2026 rend la question légitime sans dépendre de l'interface vivante du registre. Elle garde le statut Implemented du 25 avril 2025 et la demande d'un journal des micro-attributions, récupérations et restitutions. Ses auteurs évoquent le risque qu'un faux IXP franchisse les contrôles; WHOIS donnait déjà l'état courant, mais ils voulaient aussi consolider l'histoire.

Le texte atteste un modèle de menace. Il n'atteste ni faux échange, ni attribution indue, ni échec opérationnel.

La politique porte des verbes; le fichier, des états

La proposition archivée suffit à fixer le test sémantique. Sa phrase opératoire exige un journal public détaillant micro-attributions, récupérations et restitutions du pool spécial. Elle ne définit ni schéma de ligne, ni vocabulaire d'événements, identifiant stable, règle d'horodatage, chaîne de correction ou méthode d'intégrité. Cela ne prouve pas une mauvaise implémentation; cela impose de distinguer si l'objet publié représente l'état, la transition ou les deux.

La restitution et la récupération n'ont pas le même acteur initial. La quarantaine n'est pas une disponibilité immédiate. La correction d'une donnée n'est pas nécessairement un changement de contrôle. L'attribution crée une relation publique. La politique emploie des verbes parce que ces différences ont une portée pour le titulaire, le registre et l'observateur.

Le fichier public, lui, condense les chemins dans une destination.

L'inventaire est exact dans son propre domaine

La copie du 16 juin conservée indépendamment par Common Crawl compte 423 lignes de données : 39 assigned, deux allocated et 382 reserved. Son en-tête de huit champs ne contient ni event_id, event_type, previous_status, effective_at, observed_at, reason_class, policy_version, quarantine_until, decision_reference ou correction_reference.

Cette constatation ne prouve pas que les données sont erronées. Elle ne prouve pas non plus l'absence d'un historique interne. Le fichier peut être une projection parfaitement fidèle du présent. C'est précisément pourquoi le mot juste est instantané.

Un observateur peut conserver une copie ultérieure et la comparer à celle du 16 juin. Il verra éventuellement une représentation changer, mais ce calcul restera extérieur au schéma de l'éditeur. Dans un autre système, RFC 8182 sépare une photographie RPKI de deltas sérialisés sous une identité de session. Il ne gouverne pas cette réserve et ne doit pas être copié mécaniquement; il montre que l'état courant et le changement déclaré sont deux objets.

Notons S_t(p) l'état affiché pour l'intervalle p dans la photographie observée au temps t. Un tiers peut calculer :

Δ(p,t1,t2) = S_t2(p) - S_t1(p).

Si l'état passe visiblement de assigned à reserved, le calcul démontre un changement de représentation. Il ne permet pas d'attribuer à la source une restitution volontaire plutôt qu'une récupération, une quarantaine, une correction ou une modification d'agrégation. Un changement d'OrgID peut modifier la ligne sans déplacer une seule adresse.

La différence est produite par l'analyste. L'événement doit être publié par l'autorité responsable de l'assertion. Sinon, chaque collecteur devient auteur d'une histoire différente.

Le mérite de la photographie

Une capture Common Crawl du 16 juillet de la page d'épuisement IPv4 conserve hors de l'interface vivante l'affirmation du registre : le pool ordinaire s'est épuisé en août 2020, tandis que ressources rendues ou récupérées et réserve critique restent des pièces distinctes. C'est une déclaration de partie sous garde extérieure, non l'audit de chaque adresse.

Dans un tel environnement, la visibilité du stock réduit l'asymétrie. Le lecteur peut connaître les plages actuellement émises, l'identité affichée et le reliquat réservé sans interroger chaque objet séparément.

Une capture Common Crawl du 17 juin d'une analyse sur les IXP IPv6-only conserve le calcul de l'auteur : au 9 mai 2026, 390 des 512 blocs /24 restaient réservés, soit 99 840 adresses, environ 76 % du /15. Il s'en servait comme mesure datée et concluait qu'il n'existait pas de crise immédiate d'épuisement.

La copie du 16 juin contient ensuite 382 lignes reserved, et non les 390 de mai. L'écart ne prouve ni huit attributions ni un événement précis : agrégation et représentation peuvent varier. Il prouve que le cliché répond efficacement à une question de quantité, pas à la question « que s'est-il passé ? ».

Seize champs, pas un dossier public

L'autre question appelle un flux de transitions. Chaque ligne d'événement pourrait contenir :

  1. Un ID stable d'événement. Référence durable et rectifiable.
  2. La version du schéma. Grammaire d'interprétation.
  3. L'identité de la ressource. Famille et intervalle exact.
  4. L'état précédent. État et identité de l'instantané source.
  5. Le nouvel état. État et identité de l'instantané résultant.
  6. La classe d'événement. Attribution, restitution volontaire, récupération, entrée ou sortie de quarantaine, réattribution ou correction.
  7. Le temps effectif. Horodatage et fuseau de la transition affirmée.
  8. Le temps de publication. Date à laquelle elle devient observable.
  9. La règle applicable. Version et section du manuel.
  10. L'identité d'implémentation. Proposition ou profil appliqué.
  11. Le périmètre du registre. LACNIC, NIC.br ou NIC México.
  12. La référence publique du titulaire. Lorsque sa divulgation est déjà permise.
  13. La classe de finalité critique. Vocabulaire borné, sans dossier détaillé.
  14. La classe de motif. Code respectueux de la vie privée et lien public éventuel.
  15. L'état de quarantaine. Échéance ou condition de disponibilité suivante.
  16. La chaîne de révision. Remplacement, correction, recours ou retour arrière.

Ce modèle ne réclame pas les contrats, plans de réseau, listes de participants, preuves détaillées d'utilisation, signaux de fraude, avis juridiques ou notes internes. Le public a besoin du sens officiel de la transition, pas de chaque élément qui a nourri la décision.

RFC 3339 fournit un profil temporel interopérable; RFC 5848 montre comment chaîner des messages ordonnés pour leur intégrité; et le modèle PROV du W3C sépare entités, activités et agents. Aucun ne gouverne LACNIC. Ensemble, ils montrent que temps, ordre, provenance et correction peuvent être représentés sans publier le dossier privé.

La Note 64 de HENG.LU fournit une frontière utile. Une spécification commune minimale doit être mince, mais déterministe. L'identifiant, la version, la transition, la règle, la correction et la portabilité sont nécessaires à la vérification partagée. Le modèle commercial, la topologie et l'appréciation discrétionnaire restent locaux tant qu'ils ne modifient pas un invariant commun.

Le flux proposé n'accorde aucun pouvoir nouveau sur les IXP. Il empêche seulement qu'une table publique laisse à des tiers le soin d'inventer les verbes manquants.

Sources

Limites de la preuve

Sont vérifiés les trois mouvements nommés par la proposition conservée, l'absence d'une classe d'événement dans l'en-tête du 16 juin et l'usage du cliché pour un calcul daté dans l'analyse conservée.

Est inférée l'impossibilité pour un simple écart entre photographies de fixer le sens officiel d'une transition.

Est recommandée la conservation de l'instantané, complété par un flux versionné, un dictionnaire, des métadonnées d'intégrité et des vecteurs de test.

Restent inconnus l'existence d'un historique interne complet, l'attribution éventuelle à un faux IXP, les lignes qui correspondraient réellement à une restitution ou récupération, le motif du schéma, son éventuel changement après le 16 juin et le solde exact actuel.