Gérer les ressources IPv4 de l’entreprise dans la durée

Gérer des actifs IPv4 consiste à identifier, documenter, protéger, utiliser et gouverner les ressources pendant toute leur vie opérationnelle. L’entreprise doit savoir de quels blocs elle dispose, quels systèmes en dépendent, quel ASN les annonce, qui peut les administrer et si elle en aura encore besoin demain.

En 2026, IPv4 reste présent dans les applications clientes, les API, les services cloud, la messagerie, les VPN, les listes d’autorisation des partenaires, l’hébergement, les équipements de sécurité, les centres de données et les systèmes anciens. Les mécanismes traditionnels d’allocation ne fournissent plus de nouvelles adresses sans limite. La question devient donc : comment les ressources existantes serviront-elles l’entreprise dans cinq, dix ou quinze ans ?

Un bloc a une valeur marchande, mais aussi une valeur pour l’exploitation, la continuité, le routage, l’accès des clients, la sécurité et les migrations. Remplacer un /20 déjà inscrit dans de nombreuses listes d’autorisation, règles de pare-feu, API, configurations DNS et systèmes partenaires peut coûter bien plus que son prix de vente. La gestion commence par ces dépendances, pas par une cotation.

Pour chaque préfixe, consignez les informations vérifiables à l’extérieur et ce que seule l’entreprise connaît : son usage, les applications concernées, son responsable et les besoins à venir. Une liste issue du registre, sans contexte opérationnel, n’est pas un inventaire complet.

N’oubliez pas les réserves de reprise après sinistre, de migration ou de croissance. Conservez aussi l’historique et les justificatifs qui pourront servir lors d’un transfert, d’une location ou d’une acquisition. Pour élargir ce travail, consultez l’audit des ressources de numérotation de l’entreprise.

• Registre et RDAP : à quelle organisation la ressource est-elle associée dans les données enregistrées ?
• BGP : quel ASN annonce effectivement le préfixe ?
• RPKI : quel ASN est autorisé à être à l’origine de l’annonce ?
• IRR : quelles informations de routage sont déclarées ?
• CMDB et IPAM : quel usage l’entreprise attribue-t-elle à la ressource dans ses propres outils ?

Ces informations doivent se conforter sans être confondues. Une fiche de registre ne prouve pas le routage actuel. Une annonce BGP ne prouve pas un droit juridique ou contractuel. Une ROA ne décrit pas toute la topologie du réseau.

Étape 3 — Contrôler le registre et RDAP

Vérifiez l’organisation, la plage d’adresses, le statut, les contacts, les liens avec une ressource parente et le RIR concerné. Des données périmées compliquent les transferts, les acquisitions, la récupération de compte, les migrations de fournisseur, les litiges et la réponse aux incidents. Le registre constitue une preuve importante, mais ne tranche pas à lui seul toutes les questions de propriété.

Méthode détaillée : lire un enregistrement RDAP pour une adresse IP.

Étape 4 — Observer les annonces BGP réelles

203.0.113.0/24 → AS64500

Définissez l’origine attendue de chaque préfixe important, puis comparez-la aux observations : le préfixe est-il visible ? L’ASN est-il celui prévu ? Des routes plus spécifiques ou plusieurs ASN d’origine apparaissent-ils ? Une ressource correctement enregistrée peut tout de même faire l’objet d’une annonce inattendue.

Pour mener la vérification : identifier qui annonce un préfixe dans BGP.

Étape 5 — Tenir les autorisations RPKI à jour

Préfixe : 203.0.113.0/24
ASN autorisé : AS64500

Une ROA précise quel ASN est autorisé à être à l’origine d’un préfixe. L’original renvoie à la RFC 9582 pour son format. Dans l’exploitation quotidienne, contrôlez l’ASN, la longueur du préfixe, maxLength, les autorisations arrivées à expiration ou devenues inutiles et le calendrier des migrations.

Un changement d’ASN ou de fournisseur, l’acquisition d’un réseau, le recours à un service de protection DDoS ou une refonte du réseau nécessitent une coordination avec RPKI. Sans mise à jour des anciennes ROA, une nouvelle route pourtant légitime peut devenir RPKI Invalid.

Étape 6 — Entretenir les objets IRR

route: 203.0.113.0/24
origin: AS64500

Certains réseaux construisent leurs filtres à partir de l’IRR : un ancien objet de route peut donc avoir des conséquences bien réelles. Comparez régulièrement les intentions de routage, les annonces BGP, RPKI et l’IRR. Il ne s’agit pas de rendre ces systèmes artificiellement identiques, mais d’expliquer leurs écarts.

Étape 7 — Distinguer usage, réserve et surplus

L’absence de trafic significatif ne suffit pas à justifier une vente. Le bloc peut servir à la reprise après sinistre, à une migration de clients, à une bascule régionale, à une extension prévue, à un engagement contractuel ou à l’architecture de sécurité.

• En service : il soutient actuellement la production.
• Réservé : son usage futur ou son rôle de secours est identifié, même sans annonce active.
• Sous-utilisé : il est employé, mais l’allocation pourrait être plus efficace.
• Récupérable en interne : aucune dépendance opérationnelle claire ne subsiste.
• Candidat au transfert ou à la location : il dépasse les besoins à long terme, sous réserve des vérifications techniques, contractuelles et de registre.

Étape 8 — Rechercher les dépendances qui ne se voient pas dans le trafic

Une adresse peut être inscrite dans des règles de pare-feu, des politiques VPN, des listes d’autorisation clientes, des intégrations SaaS, l’authentification d’API, le DNS, des configurations SSL/TLS, la supervision, des passerelles de paiement ou des systèmes de prestataires. Avant de transférer ou de louer un bloc, il faut savoir ce que son remplacement implique.

Étape 9 — Conserver, récupérer en interne, transférer ou louer

• Conserver une ressource qui garde un rôle stratégique ou opérationnel.
• Récupérer en interne de la capacité en regroupant des allocations inefficaces.
• Transférer une ressource dont l’entreprise ne prévoit plus l’usage, dans le respect des conditions applicables.
• Louer une capacité excédentaire lorsque les conditions techniques, contractuelles et de registre le permettent, en maintenant une relation durable avec la ressource.

L’article sur la valorisation des ressources IP excédentaires, en anglais, aborde l’aspect commercial. La première question reste opérationnelle : renoncer à ce bloc crée-t-il un risque pour les années à venir ?

Étape 10 — Ne pas réduire la décision à la valeur de marché

Une vente libère des fonds aujourd’hui. Retrouver plus tard des adresses équivalentes peut être difficile et coûteux, sans restaurer les anciennes listes d’autorisation ni la conception du réseau. Il faut mettre le produit de la vente en regard de l’utilité à long terme : négocier un actif et gérer du capital d’infrastructure ne sont pas la même démarche.

Étape 11 — Intégrer IPv4 aux vérifications d’une fusion-acquisition

Avant une acquisition, une cession ou une restructuration, identifiez les ressources, l’entité enregistrée, le compte RIR qui les administre, les conditions de détention, les ASN qui les annoncent, l’état RPKI et les justificatifs disponibles. Le contrôle des ressources relève de l’audit technique avant la conclusion de l’opération, pas d’un problème à découvrir ensuite.

Pour approfondir : le devenir des adresses IP lors d’une fusion ou d’une acquisition.

Étape 12 — Ne pas faire dépendre la continuité d’une seule personne

Si une seule personne connaît les comptes RIR, RPKI, IRR, DNS, BGP, les contacts fournisseurs et l’historique des transferts, son départ devient un risque d’infrastructure. Prévoyez un accès durable au niveau de l’organisation, des procédures écrites de récupération de compte et de MFA, plusieurs administrateurs autorisés et des contacts à jour.

Étape 13 — Préserver l’histoire des ressources

Documentez l’allocation initiale, les attributions ultérieures, les transferts, les changements de raison sociale, les acquisitions, les modifications de routage et de RPKI ainsi que les migrations de fournisseur. Ces traces pourront expliquer une incohérence, établir une continuité, faciliter une opération ou permettre de retrouver un accès.

Étape 14 — Surveiller la réputation

Des adresses peuvent avoir été associées à du spam, des logiciels malveillants, des abus, des réseaux de machines compromises ou des services de proxy. Examinez les principales listes de blocage, les signalements, la géolocalisation, le DNS inverse et l’historique de routage. C’est particulièrement important lors d’une acquisition, d’une location ou de la reprise d’un bloc auparavant confié à un tiers. Valide techniquement ne signifie pas prêt pour la production.

Étape 15 — Vérifier le DNS inverse

Qui maîtrise la délégation ? Quels serveurs de noms répondent ? Des applications dépendent-elles encore des enregistrements PTR ? DNSSEC est-il concerné ? Le DNS inverse intervient dans la délivrabilité du courrier, les outils de sécurité, les journaux et les services aux clients. Il appartient à la gestion de la ressource, même si une autre équipe gère le DNS.

Gérer IPv4 ne doit pas servir de prétexte pour repousser IPv6. Celui-ci réduit la dépendance à long terme, mais ne fait pas migrer instantanément les clients, les partenaires et les systèmes anciens. Beaucoup d’entreprises exploiteront encore pendant plusieurs années des environnements à double pile ou hybrides.

Protéger les IPv4 indispensables
+ Réduire les dépendances IPv4 inutiles
+ Étendre le déploiement IPv6

Ces trois chantiers se mènent ensemble. Le but est de garder des possibilités d’évolution, ni de tout vendre immédiatement ni de faire l’impasse sur IPv6.

Au moins une fois par an, vérifiez l’inventaire, le registre, le routage, RPKI, l’IRR, le DNS, l’utilisation, la réputation, les accès et la stratégie. Une acquisition, une migration, un changement d’ASN ou une refonte du réseau justifient aussi une nouvelle revue. Chaque ressource doit avoir un responsable et une décision expliquée.

Sept pratiques qui se complètent

• Découvrir : identifier toutes les ressources.
• Documenter : conserver l’histoire, les droits, les dépendances et les responsabilités.
• Vérifier : recouper registre, BGP, RPKI et IRR.
• Protéger : sécuriser les accès et les autorisations de routage.
• Optimiser : regrouper les allocations inefficaces et identifier les véritables surplus.
• Surveiller : suivre le routage, la réputation et la situation opérationnelle.
• Réexaminer : reprendre l’analyse chaque année et lors des changements importants.

Des informations de registre périmées nuisent à la récupération de compte, aux transferts, à la réponse aux incidents, aux changements de fournisseur et aux acquisitions. Qui est enregistré, qui est autorisé, qui annonce, qui comprend l’usage interne et qui peut rétablir le contrôle sont cinq questions distinctes. Il faut pouvoir répondre à chacune.

Employer le mot « propriété » avec précision

Dans l’entreprise, ce mot peut désigner le contrôle opérationnel ou les droits associés à une ressource. La qualification juridique et contractuelle dépend toutefois de son histoire, des accords applicables et du cadre concerné. L’enregistrement, l’autorisation de routage et les droits ne se confondent pas ; conservez les éléments qui permettent de comprendre chacun d’eux.

Penser en capital d’infrastructure à long terme

Une ressource bien administrée soutient les clients, les partenariats, l’évolution du réseau et la capacité de migrer. L’article sur les adresses IP comme capital d’infrastructure, en anglais, développe cette perspective. Une gestion rigoureuse garde ouvertes les options : conserver, réorganiser, transférer ou louer, selon les besoins réels.

Huit erreurs à éviter

• Réduire IPv4 à un détail technique.
• N’y voir qu’un actif financier.
• Confondre données de registre et routage en direct.
• Déclarer des adresses inutilisées avant de vérifier leurs dépendances.
• Tout faire reposer sur une seule personne.
• Oublier RPKI pendant une migration.
• Vendre avant d’avoir achevé l’analyse des dépendances.
• Négliger IPv6.

L’objectif n’est ni de conserver chaque adresse indéfiniment ni de vendre toute capacité apparemment libre. Il est de gérer chaque ressource selon son rôle opérationnel, son histoire documentée, son usage et sa valeur d’infrastructure dans la durée.