IPv4 a un cycle de vie : ce que les données des registres peuvent et ne peuvent pas montrer
Un guide accessible du cycle de vie d’IPv4 : transferts, réutilisation, routage, RPKI, location, historique et limites des données des registres.
Le titulaire inscrit, l’utilisateur opérationnel, la route et l’historique offrent des vues différentes d’une même ressource d’adressage. Aucun enregistrement ne raconte à lui seul toute l’histoire.
La rareté d’IPv4 ne suffit plus à décrire la situation. La question la plus utile est ce qui arrive à un bloc d’adresses une fois qu’il a été alloué.
Un bloc peut être transféré, divisé, annoncé par un autre réseau, couvert par une autre autorisation de routage, loué à un autre opérateur, puis transféré de nouveau. Le numéro peut rester identique alors que les organisations, les réseaux, la géographie et les éléments de preuve qui l’entourent changent.
Cet article propose une manière de lire ces changements. Il distingue quatre questions souvent confondues : qui est inscrit dans le registre, qui exploite la ressource, quel ASN est à l’origine de l’annonce de sa route et quels éléments de preuve permettent de déterminer si l’état actuel est autorisé et s’inscrit dans une continuité.
Commencer par quatre questions distinctes
Un enregistrement dans un registre répond à une question de registre : quelle organisation est reconnue pour cette ressource selon les règles du registre ? À lui seul, il n’indique pas qui utilise la ressource aujourd’hui, où le trafic est routé ni quel réseau est autorisé à être à l’origine de ses annonces.
- État du registre : le titulaire inscrit et sa relation avec la ressource.
- État opérationnel : l’organisation, le fournisseur ou le client qui utilise réellement le bloc.
- État du routage : l’ASN actuellement observé comme origine du préfixe dans BGP.
- Autorisation et historique : les ROA, les objets IRR, les enregistrements de transfert et l’historique des changements qui expliquent cet état.
Ces couches peuvent évoluer ensemble, mais ce n’est pas obligatoire. Les distinguer est la première étape pour comprendre les données.
Ce que montrent les données de 2026
Les chiffres de 2026 présentés dans cet article sont des observations cumulées depuis le début d’une année encore incomplète. Les chiffres mensuels publiés par le RIPE NCC de janvier à juillet totalisent environ 16,72 millions d’adresses IPv4 transférées dans sa région de service. Un seul mois de forte activité peut modifier le total : ces données témoignent donc de la poursuite des mouvements, sans constituer une prévision pour l’année entière.
La perspective de long terme est tout aussi importante. L’analyse par l’APNIC des données mondiales des RIR a recensé 33,4 millions d’adresses IPv4 dans 5 619 opérations de transfert enregistrées en 2025. Elle estimait qu’environ 342 millions d’adresses étaient apparues dans les journaux de transfert des RIR depuis 2012. Certaines adresses apparaissent plus d’une fois, ce qui montre en soi qu’une adresse peut connaître plusieurs transitions enregistrées.
Les enregistrements de transfert racontent donc une histoire de mouvement après l’épuisement. Ils ne racontent pas toute l’histoire de l’usage actuel.
L’allocation a cédé la place à la réutilisation
Lorsqu’il était facile d’obtenir de l’espace inutilisé, le schéma était simple : un registre allouait un bloc et un réseau le déployait. Dans un marché IPv4 mature, un bloc existant peut plutôt passer d’une organisation à une autre et commencer une nouvelle vie opérationnelle.
Un préfixe vieux de vingt ans peut désormais avoir un titulaire, un fournisseur, un ASN d’origine, un dispositif de DNS inverse, un contact chargé des abus et une configuration RPKI différents de ceux de son allocation initiale. Le numéro de l’adresse est stable, mais l’infrastructure qui l’entoure ne l’est pas.
Voilà pourquoi l’enregistrement actuel a besoin de son historique. Le titulaire présent est important, mais il n’est qu’un point dans la vie de la ressource.
Un grand bloc peut donner naissance à plusieurs historiques
Les transferts peuvent aussi modifier l’unité gérée. Un bloc qui était à l’origine un /16 peut ensuite être représenté par des ressources plus petites, telles que /18, /18, /19 et /20. Chaque préfixe qui en résulte peut acquérir son propre titulaire, sa route, son ROA, son DNS inverse, son utilisateur opérationnel et son historique ultérieur de transferts.
Les journaux de transfert publiés sont utiles parce qu’ils conservent la ressource enregistrée et sa transition. Ils doivent être lus comme un historique de changements d’état, sans y voir la promesse que l’allocation d’origine reste la seule unité opérationnelle pertinente.
La géographie du registre n’est pas celle du routage
Une adresse peut passer d’une région de registre à une autre sans que les paquets ne soient immédiatement acheminés vers un nouveau pays. Un transfert dans le registre modifie la relation administrative reconnue. BGP décrit la manière dont la joignabilité est annoncée. La géolocalisation IP relève encore d’une autre déduction.
Ces trois descriptions peuvent pointer dans des directions différentes sans qu’aucune soit erronée. Traiter comme interchangeables le pays indiqué dans un registre, le siège d’une entreprise, l’emplacement d’un centre de données et l’origine d’une route crée de fausses certitudes.
La location et la délégation ajoutent une autre couche
Une location ou une délégation opérationnelle peut permettre à une autre organisation d’utiliser et d’annoncer un bloc sans changement du titulaire inscrit. Un journal de transfert peut ne faire apparaître aucun nouveau titulaire alors que l’utilisateur opérationnel, le fournisseur, le DNS inverse, les contacts et la réputation ont changé.
C’est pourquoi les données de transfert mesurent les transitions consignées dans les registres, et non chaque changement d’usage. Une enquête complète doit réunir l’enregistrement du registre, l’autorisation opérationnelle et les éléments de preuve de routage.
RPKI donne à la route son propre état de sécurité
Lorsque l’ASN d’origine prévu change, les autorisations d’origine de route concernées doivent être réexaminées. Un registre peut consigner correctement un titulaire alors que le ROA pertinent reflète encore une ancienne autorisation de routage. À l’inverse, un ROA valide ne prouve pas que la route est actuellement annoncée.
Lisez les couches dans l’ordre : le registre énonce la relation reconnue, RPKI énonce une autorisation et BGP montre la route observée par les réseaux. Chacun répond à une question différente.
Ce que les données des registres ne peuvent pas prouver
Un enregistrement de transfert ne révèle ni le prix de la transaction, ni le motif commercial du changement, ni toutes les locations, ni toutes les délégations, ni l’historique complet du routage. Les RIR publient aussi leurs données selon des définitions et des calendriers différents.
La conclusion rigoureuse est donc plus limitée, mais aussi plus solide : les données des registres offrent une vue vérifiée de transitions d’état importantes qui ont été consignées. BGP, RPKI, les enregistrements IRR, les contrats et les journaux opérationnels offrent d’autres vues. La confiance naît de leur comparaison, et non de la volonté de faire répondre un seul jeu de données à toutes les questions.
Un dossier pratique du cycle de vie
Pour un préfixe important pour une activité en cours, tenez un dossier qu’un autre opérateur peut vérifier :
- titulaire actuel dans le registre et historique pertinent des transferts ;
- utilisateur opérationnel, fournisseur et contacts actuels ;
- ASN d’origine et historique des changements de route ;
- ROA, objets IRR et responsabilité du DNS inverse ;
- changements importants, approbations et preuves de contrôle ; et
- plan de continuité ou de sortie si la relation change de nouveau.
C’est cela, la gestion du cycle de vie. C’est la réponse pratique à un Internet où d’anciens identifiants continuent de circuler entre de nouvelles organisations et de nouveaux réseaux.
Poursuivre à travers les trois couches
L’article suivant suit la couche du registre au-delà des frontières entre RIR. Le troisième suit un autre type de changement : un préfixe conserve son numéro alors que son ASN d’origine BGP change.