RIPE NCC et l'économie du pouvoir d'adresse des fournisseurs cloud

Résumé

• Le pouvoir d'adresse des fournisseurs cloud se crée lorsque l'identité IP publique devient liée au compte, gérée par la plateforme et médiée par l'approvisionnement, plutôt que simplement détenue dans un registre.
• La région de service du RIPE NCC, sa large base de LIR, son pool IPv4 libre épuisé et ses services de registre font de ses enregistrements une preuve importante pour la portabilité, mais pas un mandat pour une intervention sur le marché du cloud.
• Les produits BYOIP et de préfixes annoncés peuvent préserver l'identité publique détenue par le client, mais les contrôles d'admission, les règles d'origine de route, les preuves d'autorisation et l'approbation de la plateforme conditionnent la portabilité.
• Le DNS inverse, les RPKI/ROA, l'acceptation des routes, l'historique de réputation, les listes blanches et le couplage aux services de sécurité sont désormais des surfaces de contrôle commerciales dans la migration et la sortie du cloud.
• Les achats du secteur public et des clients réglementés peuvent involontairement renforcer la dépendance aux pools détenus par les fournisseurs lorsque les appels d'offres valorisent la commodité opérationnelle mais sous-spécifient les preuves de sortie.
• Le RIPE NCC doit rester un registre léger et précis, mais améliorer la valeur de portabilité des preuves de registre afin que la rareté ne puisse pas être trop facilement convertie en dépendance client.

La réunion de sortie où le pouvoir d'adresse devient visible

La réunion cloud la plus révélatrice n'est souvent pas celle où une entreprise décide initialement de déplacer ses charges de travail. C'est celle où elle tente de partir. Les schémas au mur peuvent montrer des clusters de calcul, des bases de données gérées, des équilibreurs de charge, des pare-feu et des outils d'observabilité. La discussion budgétaire peut commencer par les frais d'abonnement, la capacité réservée, les frais de sortie et la reconversion du personnel. Mais rapidement, la discussion se tourne souvent vers les détails moins glamour de l'identité d'adresse publique: quelles plages IPv4 sont utilisées, qui les contrôle, combien de systèmes externes les reconnaissent, quels clients les ont mises en liste blanche, quels systèmes de messagerie et de fraude se souviennent de leur comportement, si le DNS inverse changera, si une autorisation d'origine de route existe, et si le prochain fournisseur acceptera même le préfixe.

C'est là qu'apparaît le pouvoir d'adresse des fournisseurs cloud. Il n'exige pas qu'un fournisseur possède chaque adresse rare. Il ne dépend pas non plus uniquement de la taille de l'inventaire IPv4 public d'une plateforme. Le pouvoir se crée lorsque l'identité de réseau public est intégrée au compte cloud du client, puis rendue opérationnellement pratique à l'intérieur de ce compte. Une adresse détenue par le fournisseur est émise par API, attachée à un service, protégée par un produit de sécurité, décrite dans une architecture de conformité, inscrite dans les listes blanches de l'entreprise et observée par les systèmes de risque tiers. Elle devient partie intégrante du visage externe du client. Le client peut ne pas la considérer comme un actif. Il peut la considérer comme une configuration. C'est exactement le propos.

L'économie est simple mais facile à manquer. Les ressources IPv4 rares sont devenues coûteuses et administrativement denses. Les entreprises et les organismes publics veulent des services cloud parce que les plateformes simplifient les opérations. Un fournisseur qui fournit des adresses publiques dans le cadre du service géré peut transformer cette commodité en une position de négociation. Le client reçoit rapidité, automatisation et support. Il accepte également qu'une partie de son identité publique soit médiée par la plateforme. S'il veut plus tard la déplacer, le coût ne se limite pas à réhéberger les charges de travail. Il doit convaincre les clients, les régulateurs, les partenaires, les systèmes anti-fraude, les filtres de messagerie et les équipes de sécurité de faire confiance à un visage public différent. L'adresse n'est qu'un numéro, mais les preuves qui l'entourent sont ce qui la rend coûteuse.

Le RIPE NCC se situe près de la racine de ces preuves dans sa région. Sa région de service couvre l'Europe, le Moyen-Orient et certaines parties de l'Asie centrale, et englobe plus de 75 pays. Ses membres comprennent plus de 20 000 organisations de registre Internet local. Son pool IPv4 libre a été épuisé en novembre 2019. Ses services incluent les enregistrements de registre, la base de données RIPE, RPKI, le DNS inverse et des informations de routage et de mesure. Ces faits ne font pas du RIPE NCC un régulateur du cloud. Ils en font un registre dont les enregistrements sont utilisés à maintes reprises par d'autres parties pour décider si une revendication d'adresse publique est crédible. Dans un marché où les fournisseurs cloud médient davantage l'expérience d'adresse publique, la qualité et la portabilité de ces preuves comptent.

La question pour un registre Internet régional est donc étroite mais importante. Il ne doit pas tenter de combattre directement le pouvoir de marché du cloud. Il ne doit pas devenir un propriétaire de la rareté ou un bureau de licence discrétionnaire pour l'architecture cloud. Son devoir est plus mince et plus durable: protéger l'unicité, l'exactitude et la continuité, et rendre les enregistrements suffisamment utiles pour que les détenteurs d'adresses puissent prouver ce qu'ils contrôlent. Un registre commun réduit les coûts de changement lorsque ses preuves se transfèrent proprement d'une plateforme à l'autre. Un registre faible ou ambigu permet aux intermédiaires puissants de convertir la rareté des adresses en dépendance.

Deux types d'identité d'adresse publique

Les clients cloud opèrent désormais avec deux formes superposées d'identité d'adresse publique. La première est l'identité détenue par le fournisseur. Un client lance un service et reçoit des adresses du pool du fournisseur. Ces adresses peuvent être statiques au sein d'un compte, réservées via un produit régional, liées à un équilibreur de charge ou attachées à un point de terminaison géré. L'Internet public voit l'adresse, mais le contrôle commercial et opérationnel se trouve à l'intérieur de la plateforme du fournisseur. Le client a un accès contractuel, pas un contrôle indépendant. La plateforme peut automatiser l'attachement, le détachement, les règles de pare-feu, la protection DDoS, la gestion du DNS inverse dans certains cas, la surveillance et les événements de cycle de vie. L'adresse semble native parce qu'elle est native de la machinerie du fournisseur.

La seconde forme est l'identité portable détenue par le client. Le client apporte un préfixe qu'il contrôle déjà, demande à un fournisseur cloud de l'annoncer, et utilise cette plage publique pour les charges de travail dans la plateforme. Les principaux fournisseurs cloud ont développé des formes de ce modèle, souvent décrites comme bring-your-own-IP, préfixe IP personnalisé ou services de préfixe public annoncé. Le langage produit varie, et les détails changent avec le temps, mais le schéma général est commun: le client doit prouver le contrôle ou l'autorisation, satisfaire les conditions de taille et de registre, aligner les preuves d'origine de route, passer les contrôles de la plateforme et accepter les contraintes opérationnelles du fournisseur. La plateforme ne fait pas que router un numéro. Elle décide si les preuves de registre du client sont suffisamment bonnes pour admettre ce numéro dans le tissu cloud.

L'identité détenue par le fournisseur est efficace au départ. Le client évite les marchés de transfert, les formalités administratives de registre et la coordination avec les équipes réseau. Il peut construire à partir de modèles. Il peut détruire et recréer des systèmes. Il peut utiliser des contrôles de sécurité natifs du cloud. Il peut laisser les achats acquérir la « connectivité publique » comme partie d'un service plutôt que d'acquérir et d'exploiter des ressources Internet. Pour les startups, les petites entreprises de logiciels et les équipes numériques du secteur public, cela est souvent rationnel. L'alternative peut être lente, coûteuse et peu familière. La rareté IPv4 a rendu les portefeuilles d'adresses indépendants plus difficiles à justifier lorsqu'un fournisseur peut fournir une adresse par API.

L'identité portable détenue par le client est coûteuse au départ mais précieuse à la fin. Elle permet à une entreprise de préserver le visage public d'un service lorsqu'elle change d'hébergement. Elle peut garder les listes blanches des partenaires stables. Elle peut préserver la réputation de messagerie et d'abus, le cas échéant. Elle peut permettre à une entreprise réglementée de montrer la continuité des points de terminaison externes lors d'exercices de résilience. Elle peut également supporter des conceptions multi-cloud ou hybrides dans lesquelles la même identité publique n'est pas uniquement ancrée au pool d'un seul fournisseur. Le client abandonne une certaine simplicité mais conserve une part de pouvoir de négociation.

La distinction n'est pas morale. Les pools détenus par les fournisseurs ne sont pas intrinsèquement abusifs. Le BYOIP n'est pas intrinsèquement libérateur. Un client peut mal utiliser un préfixe portable, ne pas maintenir les données de registre, créer un risque de routage ou traiter la portabilité comme un badge tout en restant opérationnellement dépendant d'autres manières. Un fournisseur peut fournir des adresses honnêtement et rendre la migration plus facile que de nombreux réseaux privés ne l'ont jamais fait. Mais la question institutionnelle demeure: quelle partie peut prouver le contrôle, quelle partie peut changer la route, quelle partie peut mettre à jour la délégation inverse, quelle partie peut survivre à un litige, et quelle partie supporte le coût commercial de rétablir la confiance lorsque la relation de compte prend fin?

En ce sens, le pouvoir d'adresse est un ensemble de frictions. Il réside dans l'écart entre le contrôle légal, les preuves de registre, la politique de plateforme et la reconnaissance opérationnelle par les tiers. Un fournisseur avec un grand pool d'adresses et une automatisation mature peut rendre le chemin le plus facile le moins portable. Un client avec un préfixe propre et bien documenté peut encore faire face à des contrôles d'admission, des délais et des limites d'acceptation de route. Le registre ne choisit pas le gagnant commercial. Pourtant, les enregistrements de registre façonnent les preuves que les deux parties utilisent lorsqu'elles négocient.

La rareté rend le registre précieux, pas souverain

L'épuisement IPv4 est parfois décrit comme s'il transférait automatiquement l'autorité à quiconque se trouve près du registre. C'est la mauvaise conclusion. La rareté rend les enregistrements précis plus précieux. Elle ne transforme pas un greffier en propriétaire. L'épuisement du pool IPv4 libre du RIPE NCC en novembre 2019 est un fait de marché et un jalon administratif, pas une raison pour que le registre alloue un avantage cloud selon une politique industrielle. Le rôle utile n'est pas de rationner la concurrence cloud. C'est de s'assurer que les enregistrements montrant qui détient, maintient, délègue et autorise les ressources de numérotation restent suffisamment cohérents pour réduire l'incertitude.

La région RIPE NCC est particulièrement exposée à ce problème parce qu'elle est à la fois vaste et commercialement variée. Elle inclut des marchés cloud denses d'Europe occidentale, des centres financiers réglementés, des économies numériques émergentes, des programmes cloud du secteur public, des écosystèmes de points d'échange Internet, des sociétés d'hébergement, des opérateurs télécoms, des réseaux de recherche et des entreprises qui ont acquis des adresses bien avant que la migration cloud ne devienne normale. La région de service s'étend sur l'Europe, le Moyen-Orient et certaines parties de l'Asie centrale. Plus de 20 000 organisations LIR interagissent avec le système de registre. Un seul modèle commercial ne les décrira pas tous. Certains ont des équipes réseau professionnelles et une hygiène de registre mature. D'autres traitent les adresses comme un détail administratif hérité.

Les fournisseurs cloud opèrent dans cette diversité avec des produits standardisés. La standardisation est leur force. Elle permet à une plateforme d'admettre un préfixe, de vérifier un signal cryptographique ou de registre, d'appliquer la politique de route, d'exposer une API et d'exécuter le même processus dans de nombreuses juridictions. C'est efficace, mais cela signifie aussi que la politique de plateforme peut devenir une couche de traduction privée entre le registre et le client. Si l'enregistrement de registre est ambigu, périmé ou difficile à interpréter, le fournisseur peut demander plus de preuves, retarder l'approbation ou refuser la plage. Si le client manque de connaissances internes, la réponse du fournisseur devient la loi pratique de la portabilité.

C'est pourquoi le registre compte même lorsqu'il est léger. Un registre léger n'est pas passif. C'est un dispositif institutionnel pour réduire les disputes. Il enregistre l'unicité, la gestion et l'autorisation d'une manière sur laquelle de nombreux systèmes en aval peuvent s'appuyer sans demander au registre d'approuver chaque utilisation commerciale. Lorsque les preuves sont claires, le détenteur peut s'adresser à plusieurs fournisseurs, fournisseurs de sécurité et opérateurs réseau avec la même preuve de base. Lorsque les preuves sont faibles, chaque plateforme peut créer son propre rituel d'admission, et les plateformes les plus fortes peuvent faire de ce rituel une partie de la dépendance du client.

Le danger n'est pas que le RIPE NCC devienne hors de propos. C'est que ses preuves restent centrales mais soient consommées via des interfaces privées que les clients ne peuvent pas facilement contester. Un fournisseur peut dire qu'un préfixe ne satisfait pas les exigences du produit. Un autre peut exiger un format d'autorisation différent. Une équipe d'approvisionnement peut ne pas comprendre la différence entre une adresse détenue par le fournisseur et un préfixe portable. Une équipe de sécurité peut accepter les paramètres par défaut de la plateforme parce qu'ils réduisent le risque immédiat. L'enregistrement de registre est toujours là, mais il ne fait pas assez de travail pour la partie qui a le plus besoin de portabilité.

La réponse constructive n'est pas un registre plus lourd. C'est une meilleure preuve de portabilité. Le registre ne doit pas décider quel fournisseur cloud doit accepter quel client. Il doit aider à rendre lisibles les revendications des détenteurs de ressources, le statut de délégation inverse, l'intention d'origine de route et les signaux de continuité. Si un client a maintenu des enregistrements précis et peut montrer une chaîne d'autorité propre, ces preuves doivent être faciles à utiliser sur toutes les plateformes. La rareté devient alors une raison d'améliorer la preuve, pas un prétexte pour un excès de registre ou une discrétion de plateforme.

Le BYOIP comme marché d'admission

Le bring-your-own-IP ressemble à un produit de portabilité. C'est aussi un marché d'admission. Un client arrive avec un préfixe et demande à un fournisseur cloud de le transporter. Le fournisseur doit protéger son système de routage, ses autres clients, sa réputation auprès des réseaux en amont et sa posture de sécurité. Il ne peut pas simplement accepter n'importe quelle plage revendiquée. Il demande donc au client de prouver le contrôle, de satisfaire les conditions de registre et d'origine de route, de créer des signaux d'autorisation, et d'attendre l'examen. C'est sensé. C'est aussi là qu'une adresse publique est soumise au jugement de la plateforme.

AWS, Microsoft Azure, Google Cloud et d'autres grandes plateformes publient des documents produits pour les préfixes publics fournis par le client. Ces documents sont des pièces factuelles utiles, pas une théorie complète du marché. Les documents tendent à montrer un schéma commun: la plateforme exige la preuve que le client contrôle la plage ou est autorisé à l'utiliser; le préfixe doit satisfaire des attentes techniques de taille et d'enregistrement; l'information d'origine de route ou l'autorisation doit être compatible avec l'annonce du fournisseur; le fournisseur se réserve la discrétion d'approuver, de rejeter ou de limiter l'utilisation; et le client doit intégrer le préfixe admis dans le cycle de vie propre de la plateforme. Les détails diffèrent et les règles de produit évoluent, mais la structure d'admission est suffisamment stable pour avoir de l'importance.

Le marché d'admission crée une asymétrie. Une grande entreprise avec une équipe réseau, un conseil juridique interne, des contacts de registre établis et plusieurs fournisseurs peut préparer les preuves. Elle peut créer ou ajuster des ROA, mettre à jour les données de contact, coordonner le DNS inverse et solliciter les équipes de compte. Une plus petite entreprise peut savoir seulement qu'elle a un préfixe dans de vieux documents ou qu'un partenaire d'hébergement a autrefois organisé la connectivité. Un organisme public peut dépendre d'un intégrateur de systèmes qui traite l'adressage public comme un détail d'implémentation. Le fournisseur cloud devient alors l'interprète expert de l'identité propre du client. C'est un support utile, mais c'est aussi un levier.

Le levier est accru par le temps. Une admission BYOIP échouée est rarement un litige de politique abstrait. Elle peut retarder une fenêtre de migration, un test de reprise après sinistre, un engagement d'appel d'offres ou un lancement de produit. Si l'alternative détenue par le fournisseur est disponible immédiatement, la pression du projet favorise le pool de plateforme. Le client peut avoir l'intention de revenir plus tard et de réparer la portabilité. Plus tard signifie souvent jamais. Une fois que le service a été lancé sur des adresses détenues par le fournisseur, les tiers commencent à se souvenir de ces adresses. La décision bon marché devient intégrée dans les listes blanches, les journaux de sécurité, les intégrations clients et les preuves d'audit.

Le BYOIP n'est donc pas simplement une fonctionnalité à compter. La question plus profonde est de savoir s'il fonctionne comme une infrastructure de sortie pratique. Un fournisseur peut annoncer une option de portabilité tout en maintenant des critères d'éligibilité étroits, des examens lents, des exigences de preuve complexes ou des contraintes opérationnelles qui amènent de nombreux clients à choisir les pools natifs. Cela peut refléter un contrôle de risque légitime. Cela peut également préserver la position commerciale du fournisseur. Les tiers ne peuvent pas évaluer l'équilibre à moins que les preuves de portabilité ne soient plus claires et plus standardisées.

Le rôle du RIPE NCC est indirect. Il ne doit pas dire à une plateforme comment concevoir son réseau. Il ne doit pas forcer un fournisseur à transporter une route qui crée un risque de sécurité ou opérationnel. Mais il peut rendre le côté client du processus d'admission moins opaque. Les enregistrements de registre, les contacts maintenus, les données d'origine de route, la délégation inverse et les preuves connexes doivent être suffisamment cohérents pour qu'un détenteur puisse s'adresser à un fournisseur sans reconstruire sa propre histoire à partir d'archives. Moins il y a de mystères dans le registre public, moins il y a de place pour que l'admission cloud devienne un veto privé sur la portabilité.

Limites de compte et automatisation API

Les plateformes cloud rendent l'adressage public moderne en le transformant en une ressource de compte. C'est pratique parce que les utilisateurs d'entreprise veulent une infrastructure programmable. Une adresse publique peut être réservée, étiquetée, attachée à un équilibreur de charge, déplacée entre instances, surveillée, protégée, journalisée et facturée. Elle peut apparaître dans des modèles d'infrastructure en tant que code. Elle peut être soumise à des règles d'identité et d'accès. Elle peut être créée par une équipe plateforme plutôt que par un ingénieur réseau. C'est le génie opérationnel du cloud. C'est aussi le mécanisme par lequel l'identité d'adresse publique devient liée au compte.

Les limites de compte comptent parce qu'elles définissent qui peut agir. Si une adresse provient d'un pool de fournisseur, le client ne peut généralement pas l'emporter hors du fournisseur. Il peut être capable de la réserver dans une région, de la conserver entre les redémarrages de service, ou de la déplacer entre produits à l'intérieur de la même plateforme. Mais le compte est la clôture. Le client peut automatiser à l'intérieur de cette clôture et devient dépendant de la clôture pour la continuité d'identité. Une réorganisation d'entreprise, un litige de compte, une facture impayée, un verrouillage de conformité ou une migration échouée peut alors affecter non seulement l'accès au calcul mais le visage public du service.

Le BYOIP change la limite mais ne la supprime pas. Une fois qu'un préfixe détenu par le client est admis dans une plateforme cloud, il est encore généralement opéré via les API et le modèle de compte de la plateforme. Le client peut conserver le contrôle du registre, mais son utilisation quotidienne est médiée par la couche de routage et de service du fournisseur. Déprovisionner le préfixe, le déplacer vers un autre compte, ajuster l'annonce, changer l'utilisation régionale ou le combiner avec des services de sécurité peut nécessiter des étapes spécifiques à la plateforme. En ce sens, la portabilité n'est pas une propriété binaire. C'est une chaîne d'actes opérationnels qui doivent être possibles sous pression.

La commodité de l'automatisation peut cacher la perte de pratique indépendante. Les équipes réseau qui géraient autrefois les sessions BGP, les délégations inverses et la coordination avec les fournisseurs peuvent être remplacées par des équipes plateforme dont l'expertise est la politique cloud. Cela peut être efficace et même plus sûr pour de nombreuses charges de travail. Pourtant, cela signifie que moins de personnes à l'intérieur du client peuvent distinguer entre une adresse que l'entreprise peut transporter ailleurs et une adresse que la plateforme loue simplement dans le cadre de la prestation de service. Les achats peuvent voir les deux comme une « IP statique ». Les développeurs peuvent voir les deux comme une configuration de point de terminaison. Les auditeurs peuvent demander si le service est résilient sans demander si l'identité publique est portable.

Ce flou sémantique est commercialement utile pour le fournisseur. Plus le client expérimente l'adressage public comme une fonctionnalité de plateforme, moins il est susceptible d'évaluer le coût de sortie au départ. Au moment où la sortie est envisagée, l'adresse est enchevêtrée avec les rôles IAM du compte, la journalisation, les politiques DDoS, les groupes de pare-feu, les certificats d'équilibreur de charge, l'automatisation DNS, la surveillance tierce et la documentation client. Le chemin de sortie n'est pas impossible. Il est fastidieux, risqué et politiquement peu attrayant. La lassitude est une forme de verrouillage.

Un registre léger ne peut contrer cela qu'en rendant la différence lisible. Les preuves de registre doivent aider les clients, les auditeurs et les équipes d'approvisionnement à poser de meilleures questions. Cette identité publique est-elle détenue par le fournisseur ou contrôlée par le client? Si elle est contrôlée par le client, où le contrôle est-il enregistré? Les autorisations d'origine de route sont-elles alignées sur l'origine cloud prévue? Qui contrôle le DNS inverse? Que doit-on changer si la relation de compte prend fin? Ce ne sont pas des questions pour un dossier de concurrence cloud. Ce sont des questions de continuité. Les enregistrements du registre doivent les rendre répondables avant une crise, pas après.

DNS inverse, RPKI et acceptation de route comme preuves de portabilité

L'identité d'adresse publique n'est pas portée par l'adresse seule. Elle est portée par des preuves justificatives. Le DNS inverse indique aux autres systèmes comment une adresse se nomme. RPKI et les ROA aident les systèmes de validation d'origine de route à déterminer si un système autonome est autorisé à originer un préfixe. L'acceptation de route par les réseaux et les plateformes détermine si le trafic atteindra le nouvel emplacement. Les données de registre et de contact aident à établir qui est responsable de la ressource de numérotation. Chaque couche est technique. Chacune a aussi une signification commerciale dans une migration cloud.

Le DNS inverse est un bon exemple parce qu'il est souvent traité comme un entretien mineur jusqu'à ce qu'il devienne un obstacle. Les systèmes de messagerie, les bureaux d'abus, les outils de sécurité d'entreprise et les contrôles de conformité peuvent inspecter les noms inverses. Un passage d'adresses détenues par le fournisseur à un autre pool de fournisseur peut changer l'identité inverse d'une manière qui affecte la confiance. Un passage utilisant un préfixe détenu par le client peut préserver ou contrôler cette identité si la délégation et les opérations sont correctement organisées. Si le client n'a jamais su qui contrôlait le DNS inverse, il découvre la dépendance au pire moment. Le coût n'est pas l'enregistrement DNS. C'est la perte de continuité que l'enregistrement représentait.

RPKI et les ROA sont tout aussi importants, bien que d'une manière différente. Dans les paramètres BYOIP cloud, la compatibilité d'origine de route peut décider si un fournisseur annoncera un préfixe client et si d'autres réseaux accepteront la route. Un client peut avoir besoin d'un ROA qui autorise le système autonome du fournisseur à originer le préfixe, ou peut avoir besoin de supprimer ou d'ajuster des autorisations conflictuelles. L'exigence précise dépend du fournisseur et du modèle de déploiement, et les détails de produit changent. Le point économique est stable: la preuve d'origine de route est devenue une pièce d'admission. Une plateforme qui aide les clients à naviguer cela fournit de la valeur. Une plateforme qui contrôle le processus gagne également un levier temporel.

L'acceptation de route ajoute une autre couche de pouvoir de marché. Même si un enregistrement de registre est exact et qu'un ROA est techniquement valide, la route doit être acceptée par les réseaux qui filtrent les préfixes, imposent des tailles minimales ou appliquent leurs propres politiques. Les fournisseurs cloud ont l'échelle et les relations opérationnelles pour gérer cela à grand volume. Les plus petits fournisseurs peuvent être plus exposés aux disputes de filtrage, aux problèmes de réputation ou à une propagation lente. Les clients observent cela comme une fiabilité. Ils peuvent conclure qu'une grande plateforme est le seul endroit pratique pour transporter certaines identités publiques, même lorsque le registre ne le dit pas. L'échelle de plateforme convertit alors la capacité de coordination technique en avantage commercial.

La leçon de politique n'est pas que chaque route devrait être acceptée ou que chaque délégation inverse devrait être sans friction. Les mauvaises données et le mauvais routage peuvent nuire à l'Internet plus large. La leçon est que la portabilité dépend de preuves qui peuvent être transportées à travers les environnements. Si le contrôle du DNS inverse, les contacts de registre, l'autorisation d'origine de route et l'intention de routage sont dispersés ou peu clairs, le client ne peut pas facilement comparer les fournisseurs. Il doit demander à chaque plateforme d'interpréter les preuves pour lui. La plateforme avec la meilleure équipe produit devient le juge pratique de l'avenir d'adresse du client.

Le RIPE NCC opère déjà des parties clés de cet environnement de preuves via les enregistrements de registre, la base de données RIPE, RPKI, le DNS inverse et les informations de routage ou de mesure. La direction utile est de rendre ces signaux plus faciles à auditer pour la portabilité sans en faire des laissez-passer pour chaque mouvement commercial. Un client devrait pouvoir produire un paquet clair de preuves: voici le détenteur, voici le mainteneur autorisé, voici le statut inverse, voici l'intention d'origine de route actuelle, voici l'historique de route pertinent, et voici les contacts responsables du changement. Si ce paquet est portable, l'admission cloud reste un processus produit plutôt qu'un piège de dépendance.

Mémoire de réputation et listes blanches d'entreprise

La rareté IPv4 donne un prix aux adresses. La réputation leur donne une mémoire. L'Internet public se souvient de quelles adresses ont envoyé du courrier, hébergé des services, attiré des plaintes d'abus, figuré dans des systèmes de fraude, passé des tests de pénétration, servi des API ou été intégrées dans des intégrations partenaires. Une partie de cette mémoire est formelle. Une partie est informelle. Une partie réside dans des produits commerciaux de renseignement sur les menaces. Une partie réside dans les propres listes blanches d'un client ou dans les documents de contrôle des modifications de ses partenaires. Un fournisseur cloud qui fournit l'adresse fournit également une partie de l'historique du client.

La mémoire de réputation compte parce que la sortie force un client à choisir entre transporter son identité publique existante et recommencer. Si le client utilisait des adresses détenues par le fournisseur, il peut ne pas être en mesure de transporter cette identité vers un autre fournisseur. Il doit demander aux partenaires de mettre à jour les listes blanches, convaincre les systèmes de sécurité d'accepter de nouvelles plages, surveiller les faux positifs, expliquer les changements aux régulateurs, réexécuter des tests et gérer des incidents de support. Pour un site Web grand public, cela peut être gérable. Pour le traitement des paiements, l'administration publique, les intégrations de santé, les systèmes industriels, les portails de chaîne d'approvisionnement ou les rapports réglementés, le changement peut être lent et politiquement coûteux.

Les entreprises sous-estiment souvent cela parce que les listes blanches sont décentralisées. Une équipe d'architecture centrale peut connaître les points de terminaison publics. Elle peut ne pas connaître chaque partenaire qui a épinglé une adresse, chaque système hérité qui manque de flexibilité DNS, chaque règle de pare-feu écrite par une filiale, ou chaque plateforme du secteur public qui nécessite un ticket pour mettre à jour l'accès. L'adresse du fournisseur cloud est donc reproduite silencieusement à l'extérieur du fournisseur. Le client n'utilise pas simplement le pool du fournisseur. Il entraîne son écosystème à reconnaître le pool du fournisseur comme son propre visage.

C'est une forme puissante de levier de négociation. Le fournisseur n'a pas besoin de menacer le client. Il lui suffit d'être la source par défaut d'une identité publique que les tiers ont appris à faire confiance. Les négociations de renouvellement se déroulent alors sous l'ombre de la perturbation opérationnelle. Le coût du changement n'est pas seulement la facture de migration du fournisseur. Il comprend la réinitialisation de la réputation du client avec des centaines de contreparties. Plus le client est grand et réglementé, plus cette réinitialisation devient coûteuse.

Les préfixes portables peuvent réduire ce problème, mais seulement s'ils sont préparés tôt. Si le client apporte sa propre plage d'adresses dans le cloud dès le départ, il peut préserver l'identité externe à travers les changements d'hébergement. Les partenaires peuvent encore avoir besoin d'ajuster les routes, les certificats, le DNS ou les attentes de sécurité, mais l'adresse de base peut rester. Cela rend le client moins dépendant du pool d'un fournisseur. Cela donne également au client une position plus forte dans les négociations de prix et de service. La capacité crédible de partir est souvent plus importante que l'acte de partir.

Le RIPE NCC ne peut pas gérer la mémoire de réputation. Il ne doit pas décider si une adresse est digne de confiance pour une banque, un fournisseur de messagerie ou une passerelle du secteur public. Mais il peut aider à rendre les revendications de continuité plus crédibles. Un enregistrement précis, des dossiers de contact propres, une délégation inverse stable et des informations d'origine de route cohérentes peuvent soutenir l'affirmation du client selon laquelle une identité publique est véritablement sous son contrôle et peut être déplacée de manière responsable. Dans un marché rare, cette preuve fait partie de la résilience économique du client.

Couplage de sécurité et le prix d'un trafic propre

Les fournisseurs cloud vendent rarement l'adressage public seul. Ils le vendent avec des pare-feu, une protection DDoS, un filtrage d'applications Web, une gestion des abus, une journalisation, des contrôles d'identité, des rapports de conformité et des produits réseau gérés. Ce lot peut améliorer la sécurité. Les grandes plateformes voient les attaques tôt, opèrent à grande échelle et peuvent absorber un trafic qui submergerait de plus petits réseaux. Pour de nombreux clients, les adresses publiques détenues par le fournisseur sont accompagnées d'une posture de sécurité qu'ils ne pourraient pas reproduire seuls. Le lot est précieux, et sa valeur est une des raisons pour lesquelles les clients acceptent le contrôle de plateforme.

Le couplage de sécurité devient une source de pouvoir d'adresse lorsque l'identité publique propre d'un service dépend de rester à l'intérieur du système protecteur du fournisseur. Un client qui s'en va doit non seulement déplacer une adresse ou changer d'adresse. Il doit recréer la capacité d'atténuation, les preuves de journalisation, les procédures d'incident, les contacts d'abus, les attestations de conformité et les assurances clients. Si l'ancienne adresse appartient au fournisseur, le client peut perdre à la fois le numéro et l'historique de sécurité qui y est attaché. Si l'adresse est portable mais le service de sécurité ne l'est pas, le client doit coordonner un transfert prudent. Dans les deux cas, le chemin de sortie est plus complexe qu'un changement de routage.

La protection DDoS illustre la logique économique. Un fournisseur peut offrir une atténuation toujours active profondément intégrée à sa périphérie publique. Un client peut ne pas savoir combien de sa disponibilité dépend de cette intégration jusqu'à ce qu'il teste une autre option. Si l'identité d'adresse du client est détenue par le fournisseur, un fournisseur rival ne peut pas simplement hériter du point de terminaison de confiance. Si le client utilise le BYOIP, le rival doit encore admettre le préfixe, aligner les preuves d'origine de route et fournir une atténuation comparable. L'adresse, la route et l'enveloppe de sécurité deviennent un seul paquet commercial.

Ce paquet peut être pro-concurrentiel lorsqu'il abaisse les coûts d'entrée pour les clients. Une petite entreprise peut se déployer mondialement avec une forte protection sans négocier le transit, les centres de nettoyage et les détails de registre. Un service public peut se lancer rapidement. Un fournisseur de logiciels peut standardiser les opérations. Pourtant, le même paquet peut devenir anti-portable lorsque les achats le traitent comme un service cloud indivisible. Si l'appel d'offres demande disponibilité et protection DDoS mais pas les preuves de sortie, le fournisseur gagnant peut fournir un service techniquement excellent qui laisse l'acheteur dépendant de l'identité publique détenue par le fournisseur.

Le remède est une meilleure séparation dans les preuves, pas une séparation artificielle dans l'ingénierie. Il serait absurde de dire aux plateformes qu'elles ne peuvent pas intégrer adresses et sécurité. L'intégration fait partie de la valeur qu'elles fournissent. Mais les clients doivent pouvoir voir quelles parties du lot sont portables, lesquelles sont liées au compte et lesquelles nécessitent une nouvelle preuve à la sortie. Une évaluation de résilience doit distinguer entre « le service peut être reconstruit » et « l'identité publique peut être transportée avec un risque acceptable ». Ce sont des affirmations différentes.

Pour le RIPE NCC, le problème pertinent est à nouveau l'intégrité de la couche de preuves publique. Si un préfixe détenu par le client est utilisé derrière un produit de sécurité cloud, les données de registre et RPKI doivent rendre clair le contrôle du client. Si le DNS inverse ou l'historique de routage sera utilisé pour soutenir les revendications de continuité, ces preuves doivent être faciles à récupérer et à comprendre. Le registre ne certifie pas le produit de sécurité. Il préserve les preuves de ressource qui permettent à un client d'éviter de confondre commodité de sécurité et captivité permanente.

Achats publics et clients réglementés

Les achats du secteur public et des clients réglementés peuvent amplifier le pouvoir d'adresse des fournisseurs cloud parce que ces acheteurs formalisent souvent les choix opérationnels dans des contrats longs. Un ministère, un système hospitalier, une université, une banque, un assureur ou un service public peut se procurer des services cloud via un cadre qui valorise la sécurité, la résilience, l'auditabilité et la capacité du fournisseur. Ce sont des préoccupations légitimes. Les grands fournisseurs y répondent souvent bien. Mais si le langage d'approvisionnement traite l'adressage public comme un service groupé sans exiger de preuves de portabilité, le contrat peut renforcer la dépendance avant que quiconque ne le remarque.

Le problème n'est pas la négligence. Les équipes d'approvisionnement essaient généralement de réduire le risque. Les adresses détenues par le fournisseur peuvent sembler plus sûres que les ressources détenues par le client parce que le fournisseur assume la responsabilité de l'approvisionnement, du routage et du support opérationnel. Le BYOIP peut ressembler à une exception spécialisée qui ralentit la livraison. Dans un calendrier d'appel d'offres, la commodité a une valeur politique. Un projet qui se lance à temps avec des pools de fournisseur peut être célébré. Le problème de sortie apparaît des années plus tard, lorsque le contrat est à renouveler, qu'un régulateur demande une analyse du risque de concentration, ou qu'un exercice de résilience nécessite un mouvement de charge de travail.

Les entreprises réglementées font face à un problème similaire. Les superviseurs financiers, les autorités de protection des données, les organismes d'audit public et les régulateurs sectoriels demandent de plus en plus aux entreprises de gérer la concentration de l'externalisation, la résilience et la sortie. Ces discussions se concentrent souvent sur la localisation des données, les droits contractuels, la récupération opérationnelle et les services critiques. L'identité d'adresse publique est moins visible. Pourtant, pour de nombreux services, elle fait partie de la résilience. Si une API de paiement, un portail de réclamations public ou un tableau de bord opérationnel n'est accessible que via des adresses détenues par le fournisseur que des centaines de contreparties reconnaissent, la capacité de reconstruire le calcul ailleurs peut ne pas équivaloir à la capacité de restaurer le service en pratique.

Les achats cloud publics peuvent également influencer le marché privé. Lorsque de grands acheteurs gouvernementaux acceptent l'identité détenue par le fournisseur comme normale, les intégrateurs, les consultants et les fournisseurs reproduisent cette norme. Les modèles se propagent. Les documents de sécurité décrivent les plages d'adresses du fournisseur comme acceptables. Les procédures de liste blanche supposent le pool de plateforme. Les petites entreprises servant des clients gouvernementaux suivent alors le modèle pour réduire les frictions. Une décision d'approvisionnement devient une convention de marché, et la convention augmente le pouvoir de négociation de la plateforme.

Tout cela ne signifie pas que les appels d'offres doivent exiger que chaque charge de travail utilise des préfixes détenus par le client. Cela serait un gaspillage et parfois impossible. La meilleure question est la proportionnalité. Les services à forte dépendance doivent identifier si leur identité publique est portable, quelles preuves le prouvent, qui contrôle le DNS inverse, quels changements d'origine de route sont nécessaires, quelles contreparties ont des listes blanches et combien de temps un changement d'adresse prendrait. Les services à moindre risque peuvent utiliser des pools détenus par le fournisseur avec une acceptation consciente du coût de sortie. La question n'est pas que chaque adresse doit être portable. C'est que les services importants ne doivent pas découvrir la non-portabilité seulement lorsqu'ils essaient de partir.

Le RIPE NCC peut soutenir cela par des preuves publiques plus claires et de l'éducation sans devenir un régulateur des achats. Il peut aider les acheteurs à comprendre que les enregistrements de registre ne sont pas décoratifs. Ils sont une infrastructure de continuité. Le fait que la région RIPE NCC comprenne plus de 75 pays rend cela particulièrement important. La maturité du secteur public varie largement. Des preuves communes et compréhensibles du contrôle des ressources aideraient les acheteurs et les auditeurs à poser les bonnes questions même lorsqu'ils manquent d'équipes réseau approfondies.

Petits fournisseurs et l'asymétrie de la preuve

Le pouvoir d'adresse des fournisseurs cloud n'est pas seulement un concours entre grandes plateformes et grands clients. Il affecte également les petites entreprises d'hébergement, les fournisseurs cloud régionaux, les sociétés de services gérés et les fournisseurs d'infrastructure spécialisés. Ces entreprises peuvent servir des clients qui ont besoin de support local, de confort de souveraineté des données, de connaissance sectorielle ou de flexibilité tarifaire. Elles peuvent être techniquement compétentes et proches du client. Pourtant, elles manquent souvent de la portée de route mondiale, de la profondeur de produit BYOIP automatisé, de l'échelle de sécurité et de la reconnaissance en approvisionnement des plus grandes plateformes. Les preuves de portabilité d'adresse peuvent soit les aider à concourir, soit les laisser bloquées derrière des systèmes d'admission privés.

Un client qui possède un préfixe propre et peut prouver le contrôle peut envisager un plus petit fournisseur avec moins de crainte. Il peut demander au fournisseur d'annoncer la plage, de maintenir le DNS inverse, d'aligner RPKI, de supporter des arrangements DDoS et de documenter le chemin de sortie. Le fournisseur doit encore être capable, mais l'identité publique du client n'est pas verrouillée à la plateforme en place. En revanche, un client qui s'est construit sur le pool d'adresses d'un fournisseur hyperscale peut trouver que passer à un fournisseur régional signifie une douloureuse réinitialisation d'identité publique. Le fournisseur régional est alors en concurrence non seulement sur la qualité de service mais contre la mémoire des adresses du titulaire dans l'écosystème du client.

L'asymétrie de la preuve affecte également les négociations. Les grandes plateformes ont des équipes qui peuvent interpréter les enregistrements de registre, valider le contrôle du préfixe et guider les clients à travers les changements d'origine de route. Les petits fournisseurs peuvent dépendre de processus manuels. Les clients peuvent faire plus confiance à la décision d'admission de la grande plateforme qu'à leurs propres enregistrements. Si la plateforme dit qu'un préfixe n'est pas prêt, le client peut supposer que le problème est le préfixe plutôt que les conditions de produit de la plateforme. Si un plus petit fournisseur dit que les mêmes preuves sont utilisables, le client peut s'inquiéter du risque. La norme d'admission privée de la plus grande plateforme devient une référence de marché, même là où elle reflète la conception du produit plutôt qu'une vérité de routage universelle.

Ce n'est pas un argument pour abaisser les normes de routage. Un marché où n'importe qui peut revendiquer le préfixe de n'importe qui d'autre serait insécurisé. Le point est que la preuve ne doit pas être inutilement spécifique à la plateforme. Si un détenteur de ressource a des données de registre précises, des contacts maintenus, des informations d'origine de route valides et une autorisation claire, ces preuves doivent être intelligibles pour de nombreux fournisseurs. Un plus petit fournisseur ne devrait pas avoir à rétro-concevoir la liste de contrôle privée d'une plateforme hyperscale pour convaincre un client que son propre préfixe est utilisable.

La rareté des adresses intensifie cette asymétrie parce que les clients qui ne détiennent pas déjà d'espace IPv4 peuvent n'avoir aucun chemin réaliste vers une identité publique indépendante à part les transferts ou les arrangements de location. Le coût d'obtention d'une plage portable peut être élevé. Le fardeau administratif peut être peu familier. Les pools détenus par le fournisseur apparaissent alors comme le choix rationnel. Pour de nombreux services à faible risque, ils le sont. Mais lorsque le point de terminaison public du client est stratégique, l'absence d'identité portable donne au fournisseur en place une créance sur le surplus de négociation futur. Le prix de la commodité d'adresse est payé plus tard par des options réduites.

Un environnement de preuves RIPE NCC sain ne garantirait pas le succès des petits fournisseurs. Il rendrait simplement la portabilité moins mystérieuse. Le registre ne doit pas incliner le marché vers une classe de fournisseur. Mais il doit rendre le contrôle des ressources suffisamment clair pour que les clients puissent comparer les offres sur les mérites du service plutôt que sur la crainte que leur identité publique ne puisse survivre au mouvement. En termes institutionnels, le registre doit réduire la prime d'être la plateforme qui héberge déjà l'adresse du client.

Pourquoi le pouvoir d'adresse cloud n'est pas la même chose que la thésaurisation d'adresses

Il est tentant de mesurer le pouvoir d'adresse cloud en comptant qui détient des ressources IPv4. L'inventaire compte. De grands pools permettent aux plateformes de fournir instantanément les clients, d'absorber la croissance et de maintenir des produits régionaux. Les prix IPv4 rendent ces pools précieux en tant qu'actifs de bilan même lorsqu'ils ne sont pas rapportés d'une manière qui isole l'économie des adresses. Mais l'inventaire n'est qu'une partie du pouvoir. Le pouvoir plus durable vient de la transformation de l'utilisation des adresses en une relation gérée.

Un fournisseur avec moins d'adresses mais une forte intégration de compte peut encore créer de la dépendance. Si les clients attachent les adresses du fournisseur à des services critiques, les inscrivent dans les listes blanches des partenaires, s'appuient sur les pratiques de DNS inverse du fournisseur, utilisent sa périphérie de sécurité et construisent l'automatisation autour de ses API, le fournisseur gagne en levier même sans dominer l'ensemble du marché des adresses. Inversement, un grand détenteur d'adresses qui ne médie pas l'identité du client peut avoir moins d'effet de verrouillage. La question commerciale n'est pas seulement « qui a les numéros? » C'est « qui contrôle les preuves, le timing et les rituels opérationnels qui rendent ces numéros utilisables? »

C'est pourquoi le BYOIP peut coexister avec le verrouillage. Un fournisseur peut permettre aux clients d'apporter des préfixes et toujours préserver son levier via les conditions de compte, les limitations régionales, les délais d'examen, les exigences d'origine de route, le couplage de sécurité et les procédures de sortie. Certaines de ces contraintes sont justifiées. Les réseaux cloud sont complexes, et une admission négligente de préfixe peut créer un risque de détournement, d'instabilité ou d'abus. Mais l'existence d'un produit de portabilité ne doit pas clore l'analyse. Le vrai test est de savoir si le client peut utiliser les mêmes preuves pour obtenir un service crédible de plus d'un fournisseur dans un délai commercialement pertinent.

La thésaurisation d'adresses implique également un méchant simple. Le pouvoir d'adresse cloud est plus diffus. Les clients choisissent la commodité. Les intégrateurs favorisent les conceptions répétables. Les équipes de sécurité préfèrent les plateformes connues. Les achats récompensent la livraison. Les régulateurs demandent parfois la résilience mais laissent l'identité publique vague. Les registres maintiennent des preuves mais ne les emballent peut-être pas pour la portabilité. Chaque acteur se comporte de manière sensée dans son propre domaine. Le résultat combiné peut néanmoins être une réduction du choix du client.

L'économie ressemble à d'autres marchés où une ressource commune devient intégrée dans une enveloppe de service. Un numéro de téléphone, un nom de domaine, une pièce d'identité de paiement ou un certificat d'identité peut être portable en principe, mais le changement dépend des enregistrements, des preuves, des contrats, de la propagation et de la reconnaissance par les tiers. Le détenteur ne se soucie pas qu'un droit existe en théorie si l'exercer crée des semaines de perturbation. Le fournisseur cloud qui rend la configuration initiale transparente et la sortie ultérieure complexe a gagné du pouvoir par le processus plutôt que par la seule propriété.

Pour le RIPE NCC, cette distinction est vitale. Si le problème n'était que la thésaurisation, la réponse pourrait être la redistribution ou le rationnement. Ce n'est pas la bonne voie pour un registre Internet régional dont la force réside dans la coordination neutre. Si le problème est la portabilité des preuves, la réponse est de meilleurs enregistrements, des signaux plus clairs et des outils de continuité plus fiables. Le registre ne doit pas devenir un planificateur de marché. Il doit rendre plus difficile pour la rareté et la confusion d'être monétisées comme captivité.

L'économie institutionnelle d'un registre léger

Un registre léger peut être une institution forte lorsqu'il fait bien son travail étroit. Le registre RIPE NCC n'a pas besoin de décider de l'équité économique de chaque contrat cloud pour affecter les résultats du marché. En maintenant des enregistrements précis et des systèmes de preuves connexes, il façonne le coût de la vérification. Le coût de vérification est une taxe cachée sur le changement. Lorsqu'il est bas, les clients peuvent tester les offres, déplacer les services et discipliner les fournisseurs. Lorsqu'il est élevé, les clients restent avec les titulaires parce que prouver le droit de bouger est trop lent, trop technique ou trop incertain.

C'est un problème classique d'économie institutionnelle. Les marchés fonctionnent mieux lorsque les revendications de type propriété, les responsabilités et les autorisations peuvent être vérifiées à faible coût. Les adresses IPv4 ne sont pas une propriété ordinaire, et le registre doit éviter un langage qui suggère une propriété absolue. Pourtant, les clients et les fournisseurs ont encore besoin d'attentes stables. Qui est responsable de la ressource? Qui peut autoriser une route? Qui contrôle la délégation inverse? Qui doit recevoir les contacts d'abus? Quel enregistrement est à jour? Si les réponses nécessitent une interprétation sur mesure, la partie avec le plus grand département juridique et technique gagne.

Les plateformes cloud prospèrent en abaissant de nombreux coûts de transaction. Elles réduisent le besoin de négocier le matériel, la colocation, le transit, l'atténuation DDoS et les opérations de routine. Mais elles peuvent augmenter un autre coût de transaction: le coût de partir avec l'identité publique intacte. Un registre public léger contrebalance cela en rendant les revendications indépendantes du client plus faciles à établir. Il n'abolit pas les contrats de plateforme. Il donne au client une option extérieure crédible.

La distinction entre registre et gardien n'est donc pas un slogan. Un gardien accorde la permission selon sa discrétion. Un registre enregistre des faits et des autorisations d'une manière qui permet à de nombreuses parties de se coordonner. Si le RIPE NCC essayait de dicter l'admission cloud, il affaiblirait sa neutralité et créerait de nouveaux litiges. S'il négligeait la valeur de portabilité de ses enregistrements, il laisserait les clients dépendants de gardiens privés. La voie médiane est disciplinée: garder le registre léger, mais rendre les preuves propres, à jour et faciles à transporter.

Cela protège également la continuité du réseau en fonctionnement. L'Internet n'est pas amélioré par un formalisme abrupt qui traite chaque défaut administratif comme une raison d'interrompre le service. Les clients, les fournisseurs et les réseaux ont besoin de continuité pendant que les enregistrements sont améliorés. Mais la continuité ne doit pas devenir une excuse pour des données périmées qui piègent les détenteurs dans de vieux arrangements. La tâche du registre est de soutenir un mouvement responsable: assez de stabilité pour que les services n'échouent pas, assez de clarté pour que la dépendance puisse être contestée, et assez de neutralité pour qu'il ne choisisse pas de côtés commerciaux.

Dans la région RIPE NCC, cette approche est particulièrement pertinente parce que l'adoption du cloud croise des systèmes juridiques variés, des cultures d'approvisionnement public et des historiques d'adresses héritées. Une seule règle lourde échouerait. Une meilleure couche de preuves voyagerait à travers ces différences. Elle permettrait à un hôpital dans un pays, une fintech dans un autre, un cloud régional dans un troisième et un ministère public ailleurs d'utiliser la même preuve de base pour discuter de la portabilité d'adresse. C'est le pouvoir discret d'un bon registre.

Ce qu'une norme de preuve de portabilité devrait contenir

Une norme de preuve de portabilité utile n'exigerait pas du RIPE NCC qu'il certifie qu'un fournisseur cloud doit accepter un préfixe. Elle décrirait les preuves qu'un détenteur de ressource devrait pouvoir rassembler avant, pendant et après un déploiement cloud. Elle serait pratique, pas grandiose. Elle aiderait les équipes d'approvisionnement, les auditeurs, les fournisseurs et les clients à distinguer l'identité détenue par le fournisseur de l'identité contrôlée par le client. Elle donnerait aux petits acheteurs une liste de contrôle qui ne dépend pas d'une équipe de compte hyperscale.

Le premier élément est la clarté du détenteur de ressource. Le client doit pouvoir montrer l'enregistrement de registre actuel, les contacts maintenus, l'organisation responsable et la chaîne d'autorité pour les changements. Si la ressource est détenue via un LIR parrain ou une entité apparentée, le client doit comprendre ce que cela signifie pour l'admission et la sortie cloud. Les arrangements commerciaux ambigus doivent être clarifiés avant qu'un service critique ne s'appuie sur la plage. Un nom dans une base de données n'est pas suffisant si personne ne sait qui peut autoriser le changement.

Le deuxième élément est la préparation d'origine de route. Le détenteur doit savoir quel système autonome est autorisé à originer le préfixe, comment les ROA sont maintenus, quelle longueur maximale est autorisée, et comment l'origine prévue du fournisseur cloud s'intègre à l'enregistrement. Cela ne signifie pas que chaque client doit devenir un expert en routage. Cela signifie que les preuves doivent être suffisamment accessibles pour qu'un contrôle d'admission cloud ne soit pas la première fois que le client découvre un conflit. La validation d'origine de route est devenue trop importante pour être laissée comme une réflexion après coup.

Le troisième élément est le contrôle du DNS inverse. Les clients doivent savoir qui contrôle la délégation inverse, quelles conventions de nommage sont utilisées, comment les changements sont effectués et comment ces changements affectent la messagerie, les outils de sécurité et les vérifications partenaires. Le DNS inverse n'est pas un exercice de marque. Il fait partie de la pile d'identité publique. Si une adresse détenue par le fournisseur a un nommage inverse contrôlé par le fournisseur, le client doit reconnaître cela comme un compromis de portabilité. Si un préfixe détenu par le client a un nommage inverse contrôlé par le client, il doit être documenté comme un actif de continuité.

Le quatrième élément est l'historique de route et de réputation. Un client se préparant à bouger doit pouvoir examiner où son préfixe a été vu, comment il a été originé, et si des problèmes de réputation pourraient affecter l'admission ou l'acceptation. Les informations de routage et de mesure du RIPE NCC peuvent soutenir cette analyse sans prétendre juger la qualité commerciale d'un fournisseur. L'objectif est de réduire les surprises. Une surprise concernant l'historique de route pendant une fenêtre de migration est un coût évitable.

Le cinquième élément est la procédure de sortie de compte. Si le préfixe est utilisé dans une plateforme cloud, le client doit documenter comment le retirer, le déplacer vers un autre compte, changer l'autorisation d'origine, mettre à jour les produits de sécurité, préserver les journaux et gérer l'intervalle entre les fournisseurs. Cela est en partie hors du registre. Mais les preuves de registre doivent être référencées dans la procédure. Le client doit savoir quels enregistrements publics doivent changer et lesquels doivent rester stables.

Une telle norme serait modeste mais utile. Elle ne résoudrait pas la concentration cloud. Elle ne rendrait pas IPv4 abondant. Elle n'éliminerait pas les examens de sécurité légitimes que les fournisseurs effectuent. Elle réduirait cependant le mystère privé autour de la portabilité d'adresse. Dans un marché rare, réduire le mystère est un acte concurrentiel même lorsque l'institution reste neutre.

Un agenda constructif pour le RIPE NCC

Un agenda constructif du RIPE NCC commencerait par la visibilité de la portabilité. Le registre pourrait faciliter pour les membres et les détenteurs de ressources de voir, en un seul endroit, les preuves susceptibles de compter dans un processus d'admission ou de sortie cloud: informations sur le détenteur, contacts maintenus, statut du DNS inverse, statut RPKI/ROA, origines de route observées, et avertissements opérationnels pertinents. Cela ne serait pas une certification. Ce serait une vue de préparation. Sa valeur résiderait dans la réduction du coût de poser les bonnes questions.

L'étape suivante serait des orientations écrites pour les acheteurs, pas seulement pour les spécialistes réseau. De nombreuses décisions cloud sont prises par les achats, le risque, le juridique et les équipes de livraison numérique. Elles ont besoin d'un langage qui distingue les adresses détenues par le fournisseur des préfixes contrôlés par le client sans exiger qu'elles deviennent des ingénieurs de routage. Un court guide public pourrait expliquer pourquoi l'« IP statique » n'est pas la même chose que l'identité portable, pourquoi le DNS inverse et les ROA comptent, et comment les décisions d'adresse affectent la sortie. De telles orientations seraient particulièrement utiles pour les acheteurs du secteur public et réglementés.

Le RIPE NCC pourrait également encourager des paquets de preuves standardisés pour la planification BYOIP et de sortie. Les fournisseurs resteraient libres de fixer des règles de produit, mais un paquet de preuves commun aiderait les clients à comparer les exigences. Il pourrait inclure les données de registre actuelles, les contacts d'autorisation, l'état RPKI, les ASN d'origine prévus, le contrôle du DNS inverse et les procédures de changement. Si les grands fournisseurs exigent encore des contrôles supplémentaires, c'est leur droit. Mais le client partirait d'une base de preuve commune plutôt que de l'incertitude.

La mesure peut aider aussi. Les informations de routage et de mesure du RIPE NCC peuvent éclairer comment les préfixes sont originés, où les changements se produisent et comment les routes sont visibles pendant la migration. L'objectif ne doit pas être de noter politiquement les fournisseurs. Il doit être d'aider les détenteurs à comprendre l'historique opérationnel et le risque. Un client qui peut voir son historique de route est mieux préparé à discuter de l'admission avec une plateforme cloud ou un fournisseur régional. Un client qui ne peut pas le voir doit s'appuyer sur celui qui offre l'interprétation la plus confiante.

Enfin, le RIPE NCC peut convoquer sans commander. Il peut réunir les fournisseurs cloud, les réseaux régionaux, les entreprises, les acheteurs du secteur public et les équipes de sécurité dans une discussion pratique sur les preuves de portabilité. L'ordre du jour doit être étroit: réduire l'ambiguïté évitable, améliorer la continuité et garder les preuves de registre utilisables sur toutes les plateformes. Une telle convocation serait cohérente avec un rôle de coordination. Elle n'exigerait pas du registre qu'il juge directement le pouvoir de marché.

L'objection probable est que cet agenda est trop modeste pour l'échelle de la concentration cloud. Mais la modestie est une vertu ici. Le registre ne peut pas rendre IPv4 abondant, et il ne doit pas devenir une autorité de concurrence. Ce qu'il peut faire, c'est s'assurer que la couche de preuves partagée fonctionne pour la partie la plus faible dans un litige de portabilité. Ce n'est pas tout. C'est néanmoins significatif. De nombreuses formes de pouvoir de marché survivent parce que le coût de prouver une alternative est trop élevé. Abaisser ce coût est une contribution légitime du registre.

Le registre léger et le compte cloud

Le compte cloud est une invention commerciale remarquable. Il transforme l'infrastructure en un ensemble de services programmables. Il permet aux clients de consommer des réseaux mondiaux sans les construire. Il enveloppe la complexité dans des API et des contrats de support. Il a permis à de nombreuses organisations dans la région RIPE NCC de déployer des services qui auraient autrefois nécessité bien plus de capital et d'expertise. La critique du pouvoir d'adresse des fournisseurs cloud ne doit pas obscurcir cette réalisation.

Mais le compte n'est pas la même chose que le registre public de l'Internet. Le compte est une relation avec un fournisseur. Le registre est un outil de coordination utilisé par de nombreuses parties. Lorsque l'identité d'adresse publique est trop complètement absorbée dans le compte, le client peut gagner en commodité tout en perdant son indépendance. Il peut agir rapidement à l'intérieur de la plateforme mais lutter pour se prouver à l'extérieur. C'est le compromis économique central.

La rareté IPv4 aiguise le compromis. Si les adresses publiques étaient abondantes, un client pourrait plus facilement recommencer. La rareté rend l'ancienne identité précieuse. Elle rend les historiques d'adresses collants. Elle rend les pools de fournisseur attrayants et les plages portables coûteuses. Elle rend chaque contrôle d'admission plus conséquent. La rareté ne décide pas qui devrait gagner le marché cloud, mais elle augmente la valeur de chaque institution qui peut abaisser les coûts de changement. Le RIPE NCC est une de ces institutions parce que ses enregistrements font partie de la chaîne de preuve.

La bonne conclusion n'est donc ni le fatalisme de plateforme ni l'activisme de registre. Les fournisseurs cloud continueront à fournir des adresses publiques, des produits BYOIP et des lots de sécurité. Les clients continueront à choisir la commodité. Certaines charges de travail ne justifieront pas l'identité portable. Les autorités de concurrence, les organismes d'approvisionnement et les régulateurs traiteront les questions de concentration plus larges via leurs propres outils. La responsabilité du RIPE NCC est plus étroite: garder les preuves de ressource précises, continues et utilisables pour que les clients puissent prouver leur identité publique quand cela compte.

Si le registre est fort, un client peut demander un service à un fournisseur cloud sans abandonner son avenir. Il peut apporter un préfixe, montrer le contrôle, aligner les preuves d'origine de route, gérer le DNS inverse et préserver la réputation à travers le mouvement. Il peut décider consciemment quand les pools détenus par le fournisseur valent le coût de sortie. Il peut faire en sorte que les achats comparent non seulement la disponibilité d'aujourd'hui mais la position de négociation de demain. Le résultat n'est pas une liberté parfaite. C'est un marché plus honnête.

Si le registre est faible, les fournisseurs cloud n'ont pas besoin de saisir quoi que ce soit. Ils peuvent laisser la rareté, l'incertitude et l'inertie du client faire le travail. Les pools détenus par le fournisseur deviennent le visage public par défaut. Le BYOIP reste une voie spécialisée pour ceux qui ont assez d'expertise. Les listes blanches et la mémoire de réputation s'accumulent. Les lots de sécurité approfondissent la dépendance. Les cadres du secteur public normalisent le modèle. Au renouvellement, le fournisseur vend non seulement du calcul et de la sécurité mais un soulagement de la perturbation que le départ causerait.

C'est l'économie du pouvoir d'adresse des fournisseurs cloud dans la région RIPE NCC. Ce n'est pas juste le volume d'adresses. C'est la conversion de l'identité publique rare en service lié au compte, admission privée et habitude d'approvisionnement. La réponse n'est pas de transformer le RIPE NCC en un policier du cloud. C'est de faire en sorte que le registre commun fasse son travail discret suffisamment bien pour que la portabilité soit réelle avant qu'elle ne soit urgemment nécessaire. Dans un monde IPv4 rare, ce travail discret est l'un des rares freins pratiques à la dépendance d'adresse.