Stratégie IPv4 pour les fournisseurs de cloud, d'IA et d'hébergement

Les plateformes cloud, les opérateurs d’infrastructures d’IA et les fournisseurs d’hébergement sont confrontés à une réalité réseau complexe : la demande de connectivité publique continue d’augmenter, mais l’offre d’adresses IPv4, elle, n’augmente pas.

L’Internet Assigned Numbers Authority confirme que son stock général d’adresses IPv4 est épuisé. Pourtant, les clients, les intégrations d’entreprise, les applications existantes, les outils de sécurité, les API et les équipements réseau dépendent encore de la connectivité IPv4. L’adoption d’IPv6 est essentielle, mais elle ne supprime pas le besoin immédiat de prendre en charge l’Internet IPv4.

Pour les fournisseurs d’infrastructure, IPv4 représente donc bien plus qu’un simple besoin en adresses. Il s’agit d’un enjeu de capacité, de continuité, de sécurité et d’expérience client.

Une stratégie IPv4 durable doit répondre à cinq questions :

1. De quelle capacité IPv4 publique la plateforme a-t-elle réellement besoin ?
2. Quelles charges de travail nécessitent des adresses IPv4 dédiées ?
3. Comment obtenir de nouvelles capacités sans ralentir les déploiements ?
4. Qui est responsable du routage, de la réputation, du traitement des abus et des renouvellements ?
5. Comment IPv4 et IPv6 fonctionneront-ils ensemble à long terme ?

Ce guide explique comment les fournisseurs de cloud, d’IA et d’hébergement peuvent élaborer cette stratégie.

Pourquoi IPv4 reste essentiel pour les fournisseurs d’infrastructure

IPv4 utilise un espace d’adressage de 32 bits. Cette limitation technique ne permet pas une croissance indéfinie des services connectés à Internet. L’espace d’adressage disponible est désormais géré au moyen des allocations existantes, des transferts, de la location, de la récupération et d’une utilisation plus efficace.

La demande reste néanmoins forte dans plusieurs marchés d’infrastructure.

Plateformes cloud

Les services de cloud public peuvent nécessiter des adresses IPv4 pour :

- Les machines virtuelles et les instances bare-metal
- Les répartiteurs de charge publics
- Les bases de données gérées et les passerelles d’applications
- Les passerelles de traduction d’adresses réseau
- Les pare-feu contrôlés par les clients
- Les services VPN et d’accès à distance
- La connectivité multi-cloud et cloud hybride

Les clients s’attendent souvent à disposer d’un point de terminaison IPv4 lorsqu’ils lancent un service. Si la capacité d’adressage ne suit pas la capacité de calcul, IPv4 devient une contrainte pour les infrastructures génératrices de revenus.

Infrastructure d’IA

Les plateformes d’IA génèrent leurs propres besoins en IPv4. Les clusters de GPU peuvent utiliser un adressage privé en interne, mais des adresses publiques restent souvent nécessaires pour :

- Les API d’inférence
- Les points de terminaison de mise à disposition des modèles
- Les environnements de développement IA
- Les tableaux de bord clients
- Les passerelles d’ingestion de données
- L’accès administratif sécurisé
- L’intégration avec des systèmes tiers
- Les services distribués de traitement des données

Les cycles de déploiement rapides associés à l’IA rendent la vitesse d’approvisionnement particulièrement importante. Une plateforme ne devrait pas disposer de capacité de calcul inutilisée simplement parce que son équipe réseau attend un espace d’adressage public exploitable.

Services d’hébergement et de centres de données

L’hébergement dédié, les VPS, la colocation, les infrastructures gérées et l’hébergement d’applications restent fortement dépendants d’IPv4. De nombreux clients attendent au moins une adresse IPv4 publique utilisable, tandis que des services tels que les pare-feu gérés, la haute disponibilité, la terminaison SSL et certains équipements spécialisés peuvent nécessiter des capacités supplémentaires.

La disponibilité des adresses IPv4 peut donc avoir un impact sur la structuration des offres, l’acquisition de clients, l’expansion vers de nouveaux sites et la rentabilité de chaque serveur ou machine virtuelle.

Considérer IPv4 comme un portefeuille d’infrastructure

La première étape consiste à ne plus considérer toutes les adresses comme interchangeables.

Un portefeuille efficace distingue les besoins IPv4 en fonction de la charge de travail, de la durée, de la valeur client et de l’impact d’une défaillance. Les fournisseurs peuvent classer la demande en quatre grandes catégories :

- **Capacité de production principale :** adresses prenant en charge des services de longue durée, des points de terminaison critiques, des infrastructures clients et des charges de travail coûteuses à renuméroter.
- **Capacité de croissance :** adresses réservées à l’expansion prévue, aux nouvelles régions, aux serveurs supplémentaires ou aux lancements de produits.
- **Capacité élastique :** adresses utilisées pour des besoins variables ou à plus court terme.
- **Capacité de transition :** adresses utilisées pour les migrations, acquisitions, renumérotations ou déploiements dual-stack.

Cette classification aide l’entreprise à déterminer où elle a besoin d’une continuité maximale et où elle peut accepter davantage de flexibilité opérationnelle.

Une adresse de production prenant en charge des centaines de charges de travail clients ne devrait pas être obtenue avec les mêmes contrôles qu’une capacité temporaire de développement. Le coût d’un dispositif IPv4 doit être comparé au coût d’une défaillance, et pas uniquement au prix mensuel par adresse.

Prévoir la demande IPv4 à partir des moteurs de croissance de l’entreprise

Les fournisseurs d’infrastructure devraient relier leurs prévisions IPv4 à des activités commerciales mesurables.

Les données utiles comprennent :

- Le nombre de serveurs, d’instances, de locataires ou de clusters déployés
- La croissance attendue des clients et leur taux de désabonnement
- La consommation moyenne d’adresses par produit
- Les projets d’expansion régionale
- Le ratio entre produits avec IP dédiée et IP partagée
- La capacité requise pour la haute disponibilité
- L’utilisation et la fragmentation des blocs existants
- Les adresses réservées au réseau, au broadcast, aux passerelles ou aux besoins opérationnels
- La durée de quarantaine avant la réattribution d’une adresse
- La capacité nécessaire aux migrations et aux situations de secours

Les prévisions devraient couvrir plusieurs horizons. Une prévision opérationnelle glissante sur 90 jours facilite l’approvisionnement, tandis qu’un modèle sur 12 à 24 mois aide la direction à évaluer la location, l’achat, l’optimisation des adresses et les investissements IPv6.

Les équipes devraient également maintenir une réserve de capacité. Attendre que le pool disponible atteigne zéro transforme une croissance normale en situation d’approvisionnement d’urgence.

Déterminer quand louer, acheter ou optimiser

Il n’existe pas de modèle d’approvisionnement unique adapté à tous les fournisseurs. La plupart des grands opérateurs tirent avantage d’une combinaison de plusieurs approches.

Louer des IPv4 pour une croissance évolutive et efficace en capital

La location peut être appropriée lorsqu’un fournisseur doit :

- Ajouter de la capacité d’adressage sans achat initial important
- Lancer rapidement une nouvelle région ou un nouveau service
- Adapter les engagements IPv4 à la demande des clients
- Préserver le capital pour le calcul, le stockage, les GPU et l’expansion du réseau
- Éviter de gérer une chaîne fragmentée de fournisseurs d’adresses
- Conserver de la flexibilité lorsque la demande à long terme reste incertaine

Toutefois, une location IPv4 doit être évaluée comme une dépendance d’infrastructure. La propriété ou le contrôle des adresses par le fournisseur, les conditions de renouvellement, le support de routage, la position auprès du registre et les capacités opérationnelles sont des éléments importants.

LARUS propose une location IPv4 directe depuis son propre pool d’adresses contrôlé. Sa structure de services actuelle permet aux clients de choisir une location de capacité uniquement ou d’ajouter des contrôles de continuité couvrant notamment la validité du routage, la préparation RPKI/ROA, le DNS inversé, les processus de traitement des abus, l’assistance en matière de géolocalisation, les engagements de réponse et la prévisibilité des renouvellements.

Acheter lorsque la propriété correspond à la stratégie de capital

L’achat peut convenir aux organisations ayant des besoins prévisibles et permanents ainsi que les ressources nécessaires pour gérer les transferts, les registres, la conformité, le routage, la sécurité et les obligations liées au cycle de vie.

Le prix d’achat ne constitue qu’un élément de la décision. Les acheteurs doivent évaluer :

- Les exigences du registre Internet régional
- Les documents de propriété et de transfert
- L’historique et la réputation des adresses
- L’autorisation de routage
- Les responsabilités continues auprès du registre
- La gouvernance interne
- Le coût futur de la détention d’un espace sous-utilisé

La propriété peut offrir une valeur économique à long terme, mais elle concentre également les responsabilités administratives et liées au registre au sein de l’entreprise exploitante.

Optimiser l’espace existant avant d’ajouter de la capacité
Les fournisseurs devraient régulièrement auditer leurs allocations existantes afin d’identifier :

- Les attributions clients inutilisées
- Les sous-réseaux surdimensionnés
- Les environnements de développement abandonnés
- Les adresses conservées après la résiliation d’un service
- Les réservations en double
- Les enregistrements d’allocation insuffisants
- La fragmentation empêchant une réattribution efficace

L’optimisation est utile, mais elle a ses limites. Une réutilisation trop agressive des adresses peut augmenter la charge opérationnelle et créer des problèmes de réputation si les adresses passent d’un client à un autre sans examen ni période de quarantaine appropriés.

Les organisations disposant de plus d’IPv4 qu’elles n’en ont besoin peuvent également envisager de vendre leurs ressources inutilisées. LARUS agit comme un acheteur direct de premier niveau d’espaces d’adresses IPv4 et prend en charge des structures permettant à une organisation de vendre un bloc puis de relouer la capacité dont elle a encore besoin.

Intégrer la continuité dans le processus d’approvisionnement

La simple disponibilité des adresses ne rend pas un bloc prêt pour la production.

Avant de mettre en service un espace IPv4 loué ou acquis, un fournisseur devrait confirmer que :

- La partie fournissant les adresses est autorisée à le faire
- L’utilisation autorisée est clairement documentée
- Le préfixe requis peut être annoncé depuis l’ASN du fournisseur
- Les Route Origin Authorizations peuvent être créées et maintenues
- Le DNS inversé peut être délégué ou géré
- Les données de géolocalisation peuvent être corrigées si nécessaire
- Les signalements d’abus disposent d’un processus de traitement défini
- Les conditions de renouvellement et de résiliation correspondent à la charge de travail
- Le processus de restitution ou de renumérotation des adresses est compris
- Les procédures d’escalade du support et les attentes en matière de réponse sont documentées

L’objectif est de réduire le nombre de dépendances entre le contrat et le réseau opérationnel.

C’est l’une des raisons pour lesquelles l’approvisionnement direct est important. Louer via plusieurs intermédiaires peut créer des incertitudes concernant la propriété, l’autorisation, le renouvellement et la responsabilité lorsqu’un problème opérationnel survient. LARUS positionne son modèle de location comme une relation directe de premier niveau, LARUS restant responsable de la ressource sous-jacente et de la couche de continuité.

Protéger le routage avec RPKI et les ROA

Un accord commercial valide ne crée pas automatiquement une configuration de routage sécurisée.

La Resource Public Key Infrastructure, ou RPKI, permet au détenteur d’une ressource d’autoriser un système autonome à annoncer un préfixe. La Route Origin Authorization qui en résulte identifie l’ASN d’origine autorisé et la longueur maximale du préfixe. Le rôle technique des ROA est décrit dans les spécifications RPKI de l’IETF.

Pour les fournisseurs de cloud, d’IA et d’hébergement, le processus d’intégration devrait comprendre :

1. La confirmation de l’ASN d’origine
2. La création ou la mise à jour de la ROA applicable
3. La vérification de la longueur de préfixe autorisée
4. La validation de la route avant son utilisation en production
5. La surveillance des annonces invalides ou inattendues
6. La mise à jour de l’autorisation avant toute migration de routage
7. La suppression des autorisations obsolètes après la désactivation du service

RPKI devrait être associé à la surveillance des routes, aux filtres de préfixes, à une gestion documentée des changements et à une vérification multipartite des modifications de routage sensibles.

Gérer la réputation comme un actif opérationnel

Une adresse IPv4 peut être techniquement routable mais commercialement inutilisable si sa réputation est mauvaise.

Les environnements cloud et d’hébergement sont fréquemment ciblés par le spam, les abus d’identifiants, les logiciels malveillants, les analyses de réseau, le phishing et d’autres activités interdites. Les plateformes d’IA peuvent être confrontées à des risques supplémentaires liés à la création automatisée de comptes, à l’utilisation abusive de proxys, au scraping ou à des activités massives non autorisées.

Les fournisseurs doivent évaluer à la fois l’historique de l’espace d’adressage entrant et le comportement des nouveaux clients.

Un programme pratique de gestion de la réputation comprend :

- Des contrôles avant déploiement auprès de sources de réputation pertinentes
- Des politiques d’utilisation acceptable clairement définies
- Des contrôles d’identité et de risque des clients
- Une détection automatisée du trafic anormal
- Des contacts dédiés au traitement des abus
- Une gestion des incidents fondée sur des preuves
- Une période de quarantaine des adresses avant leur réattribution
- Des DNS direct et inversé correctement configurés
- Des processus de correction des données de géolocalisation et de réputation
- Une documentation des mesures correctives prises

La réputation n’est pas un simple contrôle effectué lors de l’intégration. Elle doit être gérée tout au long du cycle de vie de l’adresse.

Utiliser les IPv4 partagées de manière sélective

Le NAT et le NAT de niveau opérateur peuvent réduire la consommation d’adresses publiques, mais ils doivent être utilisés en fonction de la charge de travail.

Les IPv4 partagées peuvent convenir au trafic sortant des clients, aux services internes, aux environnements de développement et aux charges de travail ne nécessitant pas de point de terminaison entrant unique. L’espace d’adressage partagé réservé au NAT de niveau opérateur est défini dans la [RFC 6598].

Une IPv4 publique dédiée peut toutefois rester nécessaire lorsque les clients ont besoin de :

- Connexions entrantes
- Listes d’autorisation stables
- DNS contrôlé par le client
- Réputation indépendante pour les e-mails
- Protocoles fonctionnant mal via NAT
- Administration directe des serveurs
- Séparation du trafic imposée par des exigences de conformité
- Un point de terminaison unique pour un service hébergé

L’objectif ne devrait pas être de maximiser le partage d’adresses à tout prix. Les fournisseurs doivent utiliser l’architecture offrant à chaque produit un équilibre acceptable entre efficacité d’adressage, observabilité, facilité de support et expérience client.

Adopter IPv6 sans supposer qu’IPv4 disparaîtra

IPv6 constitue la réponse à long terme à la rareté des adresses. Chaque fournisseur de cloud, d’IA et d’hébergement devrait disposer d’une feuille de route IPv6 active.

Cette feuille de route peut inclure :

- La gestion dual-stack et les réseaux clients dual-stack
- La prise en charge d’IPv6 pour les répartiteurs de charge et les API
- Kubernetes et les plateformes de conteneurs compatibles IPv6
- La surveillance, la journalisation et les contrôles de sécurité IPv6
- La documentation client et les outils de migration
- Le DNS compatible IPv6 et le provisionnement automatisé
- La prise en charge d’IPv6 dans les systèmes de facturation et de gestion des adresses

Toutefois, le dual-stack peut accroître la complexité opérationnelle, car les équipes doivent sécuriser, surveiller, dépanner et documenter les deux protocoles. L’adoption d’IPv6 doit donc être considérée comme un programme d’ingénierie, et non comme un simple exercice d’allocation d’adresses.

Dans un avenir prévisible, de nombreux fournisseurs auront besoin d’une stratégie intégrée : IPv6 pour l’évolutivité et la modernisation de l’architecture, combiné à un IPv4 fiable pour assurer une accessibilité universelle et la compatibilité avec les clients.

Construire un plan de contrôle IPv4

À mesure qu’un fournisseur se développe, les feuilles de calcul et les processus informels basés sur des tickets deviennent risqués. La capacité IPv4 doit être gérée au moyen d’un plan de contrôle intégré ou d’un système de gestion des adresses IP.

Au minimum, le système devrait suivre :

- L’inventaire des préfixes et des adresses
- Les informations sur le propriétaire ou le bailleur
- La région et le RIR
- L’ASN et le statut de routage
- Le statut ROA
- L’attribution au client ou à la charge de travail
- L’autorité du DNS inversé
- La géolocalisation
- Les événements liés à la réputation
- Les dates de début, de renouvellement et de fin de location
- Le taux d’utilisation
- L’historique de quarantaine et de réattribution

Les données commerciales et réseau doivent être cohérentes. Une date de renouvellement présente uniquement dans la boîte de réception de l’équipe achats constitue un risque opérationnel.

Des alertes doivent être générées bien avant que les seuils de capacité, les échéances contractuelles, les expirations de ROA, les changements de routage ou les migrations de clients n’exigent une intervention.

Liste pratique pour élaborer une stratégie IPv4

Les fournisseurs de cloud, d’IA et d’hébergement peuvent utiliser la liste suivante lors de l’élaboration de leur stratégie d’adressage :

- Segmenter la demande d’adresses selon la charge de travail et l’impact d’une défaillance
- Maintenir des prévisions de capacité sur 90 jours et à long terme
- Définir des seuils minimums de réserve
- Auditer l’utilisation actuelle et récupérer les espaces réellement inutilisés
- Choisir entre location et achat en fonction de la durée, du capital et du risque
- Vérifier l’autorité du fournisseur et la chaîne commerciale
- Documenter les conditions de renouvellement, de résiliation et de renumérotation
- Valider la réputation avant le déploiement
- Créer et surveiller les ROA appropriées
- Définir les responsabilités relatives au rDNS, à la géolocalisation et au traitement des abus
- Adapter les engagements de support au coût d’une défaillance du service
- Introduire IPv6 de manière systématique tout en préservant la compatibilité IPv4
- Maintenir synchronisés les inventaires réseau, clients et commerciaux
- Réexaminer la stratégie chaque fois que l’entreprise lance une nouvelle région, un nouveau produit ou un déploiement majeur pour un client

La capacité IPv4 doit soutenir la croissance, et non la limiter

Pour les fournisseurs de cloud, d’IA et d’hébergement, la rareté d’IPv4 ne peut pas être résolue par un achat unique, une location temporaire ou une simple annonce IPv6. Elle nécessite un modèle opérationnel reliant la planification des capacités, l’approvisionnement, le routage, la réputation, la sécurité, les renouvellements et la modernisation des protocoles.

La stratégie la plus solide est celle dans laquelle l’entreprise sait de combien d’IPv4 elle a besoin, quels services en ont réellement besoin, d’où proviennent les adresses, comment elles sont protégées et ce qui se passe si la demande ou les fournisseurs évoluent.

LARUS accompagne les fournisseurs d’infrastructure avec la location directe d’IPv4 et Continuity Assurance. Les options Capacity Only, Production, Enterprise et Critical permettent aux organisations d’adapter leurs contrôles opérationnels à l’importance de chaque déploiement.

Pour discuter de la taille des blocs, de la zone géographique de déploiement, des exigences ASN, du routage, de la continuité ou des besoins de renouvellement, contactez LARUS ou envoyez un e-mail à : sales@larus.net.

Questions fréquemment posées

1. Pourquoi les fournisseurs de cloud ont-ils encore besoin d’IPv4 ?

Les fournisseurs de cloud ont besoin d’IPv4 parce que de nombreux utilisateurs, réseaux d’entreprise, applications, équipements et intégrations tierces ne sont pas encore accessibles uniquement via IPv6. Les points de terminaison IPv4 publics préservent la compatibilité avec l’ensemble de l’Internet.

2. La location d’IPv4 convient-elle aux infrastructures de production ?

Oui, à condition que le contrat de location comprenne les autorisations appropriées, le support du routage, des conditions de renouvellement, des contrôles de réputation et des responsabilités opérationnelles clairement définies. Les charges de travail de production doivent être associées à un niveau de continuité correspondant au coût potentiel d’une défaillance.

3. Comment les plateformes d’IA utilisent-elles les adresses IPv4 publiques ?

Les plateformes d’IA peuvent utiliser des IPv4 publiques pour les API d’inférence, les tableaux de bord, les environnements de développement, les passerelles de données, les intégrations avec des partenaires et l’administration sécurisée. Le trafic GPU interne peut souvent rester sur des réseaux privés ou IPv6.

4. Une entreprise d’hébergement devrait-elle louer ou acheter des IPv4 ?

La réponse dépend de la durée de la demande, de la disponibilité du capital, de l’expertise interne et du niveau de flexibilité recherché. La location peut favoriser une croissance rapide et efficace en capital, tandis que l’achat peut convenir à des besoins stables et à long terme. De nombreux fournisseurs utilisent les deux approches.

5. IPv6 supprime-t-il le besoin d’une stratégie IPv4 ?

Pas encore. IPv6 est essentiel pour assurer l’évolutivité à long terme, mais les fournisseurs doivent continuer à prendre en charge les clients et les systèmes dépendants d’IPv4. Une stratégie dual-stack combine la préparation pour l’avenir avec la compatibilité actuelle.

6. Que doit prendre en charge un fournisseur IPv4 en plus de la capacité d’adressage ?

Les fournisseurs destinés aux environnements de production devraient prendre en compte l’autorisation de routage, les opérations RPKI/ROA, le DNS inversé, la géolocalisation, la réputation, la réponse aux abus, les engagements de support, la prévisibilité du renouvellement et des procédures d’escalade clairement définies.