Fusion-acquisition : assurer la reprise des adresses IP et des ASN

Racheter une entreprise ne transfère pas nécessairement les adresses IP qu’elle utilise. Il faut d’abord examiner :

• la structure de l’opération ;
• l’entité juridique qui subsistera ;
• l’enregistrement initial des ressources ;
• le registre Internet régional (RIR) concerné ;
• la détention directe ou l’attribution par un prestataire ;
• les pièces justifiant le changement.

Une opération peut nécessiter la mise à jour des éléments suivants :

• enregistrements IPv4 et IPv6 ;
• numéros de système autonome (ASN) ;
• comptes auprès des RIR ;
• contacts administratifs ;
• routage BGP ;
• ROA dans la RPKI ;
• objets de routage IRR ;
• DNS inverse ;
• documentation interne.

Une transaction peut modifier les relations juridiques et administratives sans modifier immédiatement le réseau en fonctionnement.

L’audit d’acquisition doit donc examiner séparément les registres, les documents, les autorisations et le routage observé.

Pas toujours. Dans un rachat de titres, l’entité qui détient les ressources peut subsister. Un achat d’actifs peut les faire passer à une autre entité. Une fusion peut laisser subsister l’une des deux sociétés. Une restructuration peut déplacer les ressources entre entités liées. Ces situations n’ont pas les mêmes conséquences.

ARIN, APNIC et le RIPE NCC prévoient des procédures pour les fusions, acquisitions, restructurations et changements associés. APNIC indique qu’un changement de structure peut imposer l’enregistrement d’une autre organisation comme gestionnaire des adresses et ASN, avec des justificatifs juridiques. ARIN dispose également d’une procédure propre à ces opérations.

Un changement de contrôle commercial de l’entreprise ou du réseau ne suffit pas à établir que les ressources ont été transférées.

Avant la réalisation de l’opération, l’acquéreur doit connaître précisément les ressources concernées :

• allocations et attributions IPv4 ;
• allocations et attributions IPv6 ;
• ASN ;
• identifiants des comptes RIR ;
• identifiants des objets du registre ;
• contacts administratifs ;
• accès RPKI ;
• objets IRR ;
• zones DNS inverses ;
• annonces BGP actuelles.

Cet inventaire doit précéder toute conclusion sur les ressources comprises dans la transaction. Voir aussi l’audit des ressources de numérotation d’une entreprise.

RDAP permet de consulter l’état actuel du registre, notamment :

• la plage enregistrée ;
• les informations sur l’organisation ;
• le nom du réseau ;
• le statut ;
• les contacts ;
• le registre compétent.

Ces données ne répondent pas, à elles seules, aux questions suivantes :

• Qui annonce la ressource ?
• Le routage actuel est-il autorisé ?
• Quelle entreprise en assure réellement le contrôle interne ?
• Les pièces relatives aux sociétés sont-elles complètes ?

Pour interpréter les champs, consulter notre guide de lecture d’un enregistrement RDAP.

Il faut être précis dans les conclusions d’un audit. Le registre peut documenter :

• l’organisation enregistrée ;
• les modalités d’administration ;
• les contacts actuels ;
• l’historique des relations liées à la ressource.

Ces données techniques ne constituent pas automatiquement une détermination complète de la propriété juridique. Selon l’opération, il faut aussi examiner :

• les documents initiaux d’allocation ou d’attribution ;
• les actes de transfert ;
• les accords d’acquisition ;
• les contrats historiques ;
• les résolutions du conseil ;
• les contrats de services ;
• les documents applicables du RIR ;
• le droit applicable.

Les audits technique et juridique doivent se compléter.

Une opération peut être conclue commercialement tout en échouant sur le plan opérationnel si personne ne peut utiliser le compte RIR. Vérifier :

• les personnes capables de se connecter ;
• les adresses électroniques associées ;
• l’activation de l’authentification multifacteur ;
• la présence d’anciens salariés parmi les contacts ;
• l’actualité des données de facturation ;
• la validité des contacts administratifs et techniques.

Cette vérification concerne notamment :

• ARIN Online ;
• le LIR Portal du RIPE NCC ;
• MyAPNIC ;
• les autres portails de registre.

L’accès ne doit pas dépendre d’un seul salarié. L’organisation doit pouvoir reprendre la main après un départ, une restructuration ou une acquisition.

ARIN prévoit une catégorie de transfert pour les fusions, acquisitions et réorganisations. Une organisation qui acquiert des actifs utilisant des adresses ou ASN, ou le réseau ou l’organisation dans son ensemble, peut demander le transfert des ressources correspondantes.

ARIN peut demander la preuve de cette acquisition. Avant de préparer l’opération, consulter directement les exigences actuelles d’ARIN pour le transfert d’adresses et d’ASN.

La transaction entre entreprises et le transfert auprès du registre sont liés, mais restent deux procédures distinctes.

APNIC traite spécifiquement les transferts résultant :

• d’une fusion ;
• d’une acquisition ;
• d’une réorganisation.

Si l’organisation gestionnaire change, le destinataire peut devoir disposer d’un compte APNIC vers lequel transférer les ressources. Des justificatifs juridiques peuvent être demandés. APNIC met ensuite à jour le Whois pour identifier la nouvelle organisation. Voir la procédure APNIC relative aux fusions, acquisitions et réorganisations.

La mise à jour du registre traduit le résultat administratif de la transaction ; elle ne réalise pas la migration du réseau.

La documentation du RIPE NCC couvre notamment :

• les fusions ;
• les ventes ;
• les prises de contrôle ;
• les restructurations.

Le RIPE NCC peut demander de préciser l’opération et de fournir des informations et documents juridiques. Il examine également la situation des ressources détenues par les organisations concernées. L’article renvoie à sa documentation sur les ressources de numérotation.

La procédure dépend notamment des situations suivantes :

• le LIR existant reste ouvert ;
• un LIR en reprend un autre ;
• une organisation qui n’est pas LIR acquiert un LIR ;
• l’entité juridique change ;
• seul le nom de l’entreprise change.

Il faut donc établir la structure exacte de l’opération avant de choisir la démarche applicable.

Prenons un changement de dénomination :

Avant :
Example Networks Ltd.

Après :
Example Infrastructure Ltd.

Si la même entité juridique subsiste, les formalités peuvent différer de celles d’un transfert à une autre entité. En revanche :

Société A
        ↓
actifs acquis par
        ↓
Société B

peut nécessiter un transfert de ressources. Avant toute demande, distinguer le changement de nom du changement d’entité titulaire ou administratrice.

Toutes les adresses publiques utilisées par l’entreprise ne proviennent pas directement d’un RIR. Certaines peuvent être :

• attribuées par un fournisseur ;
• fournies par un opérateur cloud ;
• fournies par un hébergeur ;
• fournies par un prestataire de connectivité.

La société A utilise :
198.51.100.0/24

Cette plage peut en réalité être attribuée par le FAI B. Après l’acquisition de A, elle ne sera pas nécessairement utilisable chez le nouveau prestataire de l’acquéreur. Il faut établir :

• qui détient réellement la ressource ;
• si elle peut être déplacée ;
• si son usage dépend d’un contrat de services ;
• si une renumérotation sera nécessaire.

Cette distinction peut avoir des conséquences opérationnelles majeures après la réalisation de l’opération.

Dans la mesure du possible, l’audit doit répondre à ces questions :

• Quand la ressource a-t-elle été attribuée à l’origine ?
• À quelle entité ?
• A-t-elle déjà été transférée ?
• La société actuelle a-t-elle changé de nom ?
• Y a-t-il eu une acquisition antérieure ?
• Le registre correspond-il aux documents actuels de la société ?
• Manque-t-il des pièces ?

Cette recherche est particulièrement importante pour les anciens blocs IPv4, parfois attribués depuis des décennies et passés par plusieurs restructurations. Plus l’historique est long, plus une chaîne documentaire claire est nécessaire.

Une acquisition peut concerner plusieurs ASN. Adresses IP et ASN ne suivront pas forcément le même parcours. L’acquéreur peut :

• conserver l’ASN acquis ;
• continuer à utiliser l’organisation réseau du vendeur ;
• migrer les préfixes vers son propre ASN ;
• exploiter temporairement les deux ;
• retirer un ASN ultérieurement.

Voir la différence entre ASN et adresse IP. Pour chaque réseau de production important, documenter :

Préfixe → ASN actuel → ASN cible

Il se peut que rien ne change immédiatement. La transaction peut être réalisée alors que BGP reste identique à la veille :

Avant l’acquisition :

203.0.113.0/24 → AS64500

Le lendemain, l’entreprise peut toujours annoncer :

203.0.113.0/24 → AS64500

Le contrôle de la société a changé, mais cette continuité technique peut être voulue. L’acquéreur pourra ensuite migrer vers :

203.0.113.0/24 → AS64501

La réalisation juridique de l’opération et la migration réseau ne sont donc pas un même événement.

Pendant l’opération et après sa réalisation, observer BGP pour vérifier :

• les préfixes visibles ;
• les ASN d’origine observés ;
• la présence de routes plus spécifiques ;
• la présence de plusieurs origines ;
• la conformité avec le plan de migration.

La méthode est détaillée dans notre guide de vérification des annonces BGP. L’article reprend ici une distinction attribuée à Heng.lu :

Le registre peut changer sans changement du routage, et le routage peut changer avant la mise à jour de tous les enregistrements administratifs.

Il faut connaître les deux états et les coordonner.

Si les préfixes sont protégés par la RPKI, examiner chaque ROA concerné avant de modifier le routage de production. Le RFC 9582 définit le ROA comme un objet signé permettant de vérifier l’autorisation donnée à un AS d’annoncer des préfixes d’un bloc.

Supposons l’autorisation suivante :

ROA :
203.0.113.0/24 → AS64500

L’acquéreur modifie BGP ainsi :

203.0.113.0/24 → AS64501

Sans modification de l’autorisation, la nouvelle route pourtant légitime peut devenir RPKI Invalid. Les réseaux qui appliquent la validation de l’origine (ROV) peuvent alors rencontrer des problèmes de joignabilité.

Documenter d’abord l’état actuel :

Préfixe → ASN actuel → ROA actuel

Puis l’état cible :

Préfixe → ASN cible → ROA nécessaire

Le plan doit couvrir :

• le nouvel ASN d’origine ;
• l’ancien ASN d’origine ;
• les longueurs de préfixe autorisées ;
• la période de coexistence ;
• le calendrier des changements de ROA ;
• le retrait des autorisations devenues inutiles.

Voir la couverture des ROA et le déploiement de la ROV en 2026.

Un réseau acquis peut avoir un objet comme celui-ci :

route: 203.0.113.0/24
origin: AS64500

S’il migre vers :

AS64501

les données IRR correspondantes peuvent devoir être actualisées. Les objets périmés posent problème aux réseaux qui construisent leurs filtres à partir des registres de routage. Après l’acquisition, vérifier que les objets reflètent bien l’état souhaité.

L’opération peut concerner :

• les zones in-addr.arpa pour IPv4 ;
• les zones ip6.arpa pour IPv6 ;
• la configuration DNSSEC ;
• l’accès aux serveurs de noms ;
• le pouvoir de gérer les délégations.

Modifier le registre ne donne pas nécessairement accès à tous les outils du DNS inverse. Tester ces accès avant le départ des équipes historiques ou l’arrêt de leurs systèmes.

Un ingénieur clé peut détenir les accès à :

• l’espace RIR ;
• la RPKI ;
• l’IRR ;
• le DNS ;
• la configuration BGP ;
• la supervision ;
• les contacts chez les fournisseurs amont.

S’il part trop tôt, l’acquéreur peut contrôler juridiquement l’entreprise sans pouvoir administrer ses fonctions réseau essentielles. Vérifier l’accès de l’organisation à chaque système critique avant le départ.

La capacité à annoncer des adresses peut dépendre d’accords amont. Examiner :

• les contrats de transit ;
• les sessions BGP ;
• les lettres d’autorisation (LOA) ;
• les accords de protection DDoS ;
• la colocation ;
• l’hébergement ;
• les services de routage administré.

Un préfixe enregistré au nom de A peut être annoncé par B dans le cadre d’un accord valable. Le rachat de A par C ne recrée pas automatiquement cette relation au bénéfice de C. La continuité contractuelle mérite sa propre vérification.

Une LOA sert souvent à attester qu’une partie en autorise une autre à effectuer une opération réseau précise. Par exemple :

Administrateur de la ressource
        ↓
autorise
        ↓
le fournisseur de transit ou l’hébergeur
        ↓
à annoncer le préfixe

Elle peut prouver une relation opérationnelle, sans remplacer :

• les enregistrements du registre ;
• la RPKI ;
• les contrats ;
• les documents de transfert ;
• l’audit juridique.

Après l’acquisition, vérifier si les LOA existantes restent valables et s’il faut en établir de nouvelles.

Les bases de tiers peuvent encore associer le bloc à :

• l’ancienne société ;
• l’ancien pays ;
• d’anciens noms de réseau ;
• des signalements d’abus passés ;
• des données de réputation périmées.

Les équipes peuvent devoir revoir :

• la géolocalisation ;
• les contacts pour les abus ;
• les listes de blocage ;
• les données des fournisseurs de sécurité ;
• les services de réputation.

C’est particulièrement utile lorsque les adresses sont transférées ou redéployées dans un nouvel environnement réseau.

L’achat des éléments suivants appelle une vigilance particulière :

• serveurs ;
• contrats clients ;
• routeurs ;
• infrastructures de centre de données.

Il n’implique pas que tous les IP et ASN utilisés suivent le même transfert. Déterminer si les ressources sont :

• enregistrées directement au nom du vendeur ;
• attribuées par un prestataire ;
• comprises dans la transaction ;
• documentées séparément ;
• soumises à une procédure de transfert RIR.

L’accord d’acquisition doit correspondre à la réalité technique.

Si l’entité juridique subsiste, les relations avec le registre peuvent rester attachées à celle-ci. Cela ne dispense pas de vérifier :

• les contacts ;
• les identifiants ;
• les accords ;
• la facturation ;
• les accès RPKI ;
• la documentation interne ;
• les plans de routage.

Même sans transfert formel de ressources, le contrôle opérationnel peut nécessiter une réorganisation importante.

Les ressources peuvent être déplacées entre :

• filiales ;
• sociétés mères ;
• entités régionales ;
• sociétés nouvellement créées.

Le groupe peut se considérer comme une seule organisation alors que le RIR distingue plusieurs personnes morales. Cette différence peut cacher des dépendances. Les enregistrements doivent identifier correctement l’organisation responsable selon le cadre applicable.

Examiner chaque domaine avant de conclure :

Dans la mesure du possible, résoudre les incohérences inexpliquées avant la réalisation.

Répéter l’audit technique après la transaction, en vérifiant les points suivants.

Les informations de l’organisation attendue sont-elles correctes ?

L’acquéreur peut-il effectivement y accéder ?

Les préfixes restent-ils visibles depuis les ASN attendus ?

Les routes importantes sont-elles Valid ?

Les objets correspondent-ils au routage souhaité ?

Le DNS direct et inverse fonctionne-t-il toujours ?

Les relations de routage amont sont-elles toujours actives ?

La nouvelle équipe reçoit-elle les alertes ?

La réalisation de l’opération ouvre une phase de vérification ; elle ne clôt pas la gestion du réseau.

Voici une grille de lecture utile :

Transaction entre entreprises
        ↓
Documents juridiques et contractuels
        ↓
Enregistrements du registre
        ↓
Autorisations de routage
        ↓
BGP observé
        ↓
Services opérationnels

Ces couches s’influencent sans se mettre à jour automatiquement. Un accord d’acquisition signé ne modifie pas BGP ; une modification du registre ne réécrit pas un ROA ; un ROA ne modifie pas le DNS ; une annonce BGP ne prouve pas un transfert de société. Une procédure solide vérifie chaque couche séparément.

Des registres exacts sont précieux : les opérateurs indépendants ont besoin d’informations fiables. Mais ils ne décrivent qu’une partie de la réalité opérationnelle. Le modèle de gouvernance doit permettre :

• des enregistrements exacts ;
• des autorisations vérifiables ;
• la continuité ;
• l’auditabilité ;
• la récupération des accès administratifs ;
• la stabilité du routage ;
• une responsabilité organisationnelle claire.

Chaque système a son rôle. Il faut les maintenir suffisamment cohérents pour comprendre et rétablir les relations réseau dont dépend l’organisation.

Une démarche distincte auprès du registre peut être nécessaire.

Un ASN peut être aussi essentiel que le bloc d’adresses.

Un ROA périmé peut rendre Invalid le routage après migration.

Toutes les adresses ne sont pas portables.

Des identifiants essentiels peuvent disparaître avec elle.

Les registres ne décrivent pas tout le routage en service.

BGP ne prouve ni pouvoir administratif ni droit juridique.

Les transitions administrative et opérationnelle demandent chacune un plan.

La gestion des IP lors d’une acquisition ne se réduit pas à savoir qui en est « propriétaire ». Il faut examiner les effets sur :

• l’entité juridique ;
• les registres ;
• les comptes RIR ;
• les ressources IPv4 et IPv6 ;
• les ASN ;
• BGP ;
• la RPKI ;
• l’IRR ;
• le DNS inverse ;
• les fournisseurs ;
• la documentation interne.

Qui est enregistré ? Qui dispose des accès administratifs ? Qui est autorisé à annoncer le préfixe ? Qui l’annonce effectivement ? Que prévoient les documents de la transaction ? La nouvelle organisation pourra-t-elle récupérer et exploiter la ressource après la réalisation ?

Une acquisition bien conduite met ces réponses en cohérence. C’est ainsi qu’elle protège la continuité opérationnelle.

Non. Les démarches dépendent de la structure de l’opération, de l’entité juridique, des enregistrements et des procédures du RIR concerné.

Oui. Il faut cependant vérifier les exigences de registre et de transfert : l’acquisition commerciale ne met pas automatiquement les enregistrements à jour.

Il peut rester en service, être transféré lorsque c’est applicable ou être remplacé ultérieurement. L’acquéreur doit l’examiner indépendamment des préfixes IP.

Cela peut être nécessaire. Les procédures de fusion, acquisition, réorganisation ou changement de dénomination varient selon le RIR et la structure de l’opération.

Non. La mise à jour du registre et le routage BGP sont des processus distincts.