Le premier signe de problème dans une location IPv4 n'est souvent pas un procès, un document de politique ou une dispute publique sur la gouvernance régionale. C'est un ticket à 02h17 un dimanche matin. Un fournisseur d'hébergement a transféré un client bancaire sur un /22 loué et administré par l'AFRINIC. Le trafic est en ligne. Les règles de pare-feu, les relais de messagerie, les contrôles anti-fraude, les scripts de surveillance et les listes blanches des partenaires pointent désormais vers des adresses que le client considère comme une infrastructure de production stable. Deux fournisseurs de transit ont accepté la route après avoir vu une lettre d'autorisation du titulaire enregistré. Le DNS inverse devait suivre la bascule. Une autorisation d'origine de route était attendue mais n'est pas apparue. La boîte aux lettres abuse@ redirige toujours vers l'équipe réseau du bailleur. Un fournisseur de géolocalisation place une partie du bloc dans un pays qui ne correspond pas au dossier commercial. Les rappels de paiement commencent à échouer, et le client demande si le fournisseur contrôle réellement les adresses qu'il a vendues comme faisant partie du service.
La salle d'opérations découvre alors que chaque réponse se trouve à un endroit différent. Le registre désigne une organisation. Le bail en nomme une autre. L'AS d'origine appartient au fournisseur d'hébergement. La délégation du DNS inverse est toujours contrôlée par le bailleur. L'objet IRR a été créé par le contact technique d'un courtier. Le changement RPKI nécessite l'accès à un compte de registre dont le bailleur dit qu'il est retardé par une révision de compte. Le contrat client promet la continuité, tandis que le bail d'adresses permet le retrait de l'utilisation si le preneur déclenche des plaintes pour abus ou si le registre remet en question l'arrangement. La banque ne se soucie pas de la clause qui a échoué. Elle sait seulement qu'une plage d'adresses achetée comme faisant partie d'un service fiable se comporte désormais comme une chaîne de promesses privées.
C'est le problème du contrat de location. La location d'IPv4 permet à un opérateur d'utiliser des adresses rares sans effectuer de transfert reconnu par le registre. L'arrangement peut être efficace. Un titulaire disposant d'un espace inutilisé ou sous-utilisé génère des revenus sans abandonner le contrôle à long terme. Un réseau qui a besoin d'adresses pour un lancement de produit, une migration, un client de centre de données, un service de sécurité ou une expansion temporaire obtient une capacité utilisable sans le coût en capital, le délai ou l'incertitude politique d'un achat. Mais l'efficacité s'achète en transférant le risque hors du registre public et dans le contrat. Le registre enregistre un titulaire. Le réseau a besoin d'une réalité opérationnelle. Le bail doit expliquer comment ces deux faits coexistent.
L'AFRINIC est un cas d'école aigu car l'écart entre le registre, la politique et la demande opérationnelle est devenu exceptionnellement visible. L'organisation administre les ressources de numérotage pour l'Afrique et certaines parties de la région de l'océan Indien et fournit les services qui rendent l'utilisation des adresses lisible: enregistrements WHOIS et RDAP, DNS inverse, un registre de routage Internet, certification des ressources et RPKI, publication des contacts abuse, administration des membres et processus de gestion des ressources. Les documents publics sur l'épuisement indiquent que l'AFRINIC est entrée en phase 2 de la politique de fin de vie en janvier 2020, limitant les nouvelles allocations ou assignations IPv4 ordinaires à de petites tailles. Son manuel de politique traite l'exactitude de l'enregistrement, la justification des besoins, l'utilisation régionale et les conditions de transfert comme des caractéristiques essentielles du système. Des rapports publics ont également décrit des allégations de vol d'adresses, le litige Cloud Innovation concernant l'utilisation, la location et le service hors région, un gel des ressources en 2021 et une bataille juridique, des années sans fonctionnement normal du conseil d'administration, une mise sous séquestre à partir de 2023, des tentatives d'élection troublées en 2025, une élection du conseil en septembre 2025 et des litiges et questions de rétablissement en cours en 2026.
Ces faits sont des pièces de contexte, pas un verdict sur chaque contrat de location. Ils importent parce que chacun modifie le coût de la contractualisation privée. Le preneur veut savoir s'il peut originer des routes, si le DNS inverse et le RPKI seront sous contrôle en temps voulu, qui répond aux abus, qui absorbe les dommages de réputation, ce qui se passe à la fin du contrat, ce qui se passe si la reconnaissance du registre change, comment les clients sont protégés pendant un litige, si la sous-location est autorisée, comment les faits d'utilisation régionale et de géolocalisation sont gérés, et si l'accord privé rend la réalité opérationnelle plus visible ou la cache à tous ceux qui se fient à l'enregistrement d'adresse. La location n'est pas une échappatoire à la gouvernance. C'est une gouvernance par contrat là où le registre public est trop mince pour décrire l'utilisation.
La thèse est étroite. L'AFRINIC n'est pas ici principalement un exemple de risque de déblocage de paiement, d'opacité des prix, de pratiques d'inspection des titres ou d'actualisation du financement d'adresses, bien que chacun puisse apparaître en marge d'une transaction. C'est un test de la quantité de risque opérationnel et institutionnel qui peut être transférée dans un accord privé lorsque le transfert reconnu par le registre ne peut satisfaire la demande assez rapidement, à moindre coût ou avec suffisamment de confiance. Un marché de la location peut aider les réseaux à survivre à la rareté. Il peut aussi créer une allocation fantôme si les contrats n'allouent pas le contrôle, la responsabilité et les preuves avec précision.
La location commence là où le transfert reconnu par le registre ne répond pas à la demande
La location est souvent décrite comme un substitut de second rang à la propriété. Cela manque la distinction la plus importante sur les marchés IPv4: le contrôle reconnu par le registre par rapport à l'utilisation opérationnelle. Un transfert complet essaie d'aligner le titulaire enregistré, le propriétaire commercial, le réseau exploitant et le futur porteur de risque. Un bail les sépare délibérément. Le titulaire reste dans le registre; le preneur exploite les adresses; les clients dépendent du preneur; les systèmes de routage, de réputation et les services anti-abus observent une utilisation qui peut ne pas correspondre à la simple lecture du registre.
Cette séparation apparaît parce que la demande n'attend pas une mobilité administrative parfaite. La rareté du pool libre de l'AFRINIC limite ce qu'un réseau en croissance peut obtenir par allocation ordinaire. Ses règles de transfert sont basées sur les besoins et encadrées régionalement: le destinataire doit justifier son besoin, devenir membre de l'AFRINIC, signer l'accord de services d'enregistrement et accepter les politiques en vigueur. Les ressources héritées transférées perdent leur traitement d'héritage. Les entités sources sont soumises à des conditions de délai de carence. Ces règles peuvent servir des objectifs de conservation, d'équité et de lutte contre la spéculation, mais elles font aussi du transfert un événement institutionnel plus élaboré qu'un simple bon de commande privé. Si un opérateur de centre de données a besoin d'adresses ce trimestre, et si un transfert reconnu prendrait un temps incertain ou exposerait les parties à une révision de politique, un bail devient commercialement attractif.
La location apparaît également lorsque le titulaire valorise l'optionalité future. Un titulaire peut ne pas vouloir vendre un bloc parce qu'il prévoit une demande interne ultérieure, veut une réserve stratégique, craint de perdre son pouvoir de négociation, ou ne veut pas convertir une position reconnue en un dossier de transfert susceptible d'être remis en question. Un bail transforme une capacité dormante ou excédentaire en rendement tout en gardant le nom du titulaire dans le registre. Pour le preneur, le compromis est différent. Il reçoit une utilisation immédiate mais pas le même contrôle durable que dans un transfert. Le contrat n'est donc pas une facture de location avec des annexes techniques. C'est une constitution privée pour un contrôle partagé.
L'histoire récente de l'AFRINIC accroît la demande pour de telles constitutions. Les comptes rendus publics du litige Cloud Innovation décrivent un désaccord sur la compatibilité de l'utilisation réelle, du service à des clients hors région et de la location commerciale avec les déclarations antérieures, les attentes de la politique et les obligations contractuelles. Le litige ne portait pas seulement sur les adresses. Il portait sur la question de savoir si une réalité opérationnelle modifiée pouvait devenir un défaut de reconnaissance du registre. Cette question est exactement ce qui inquiète un preneur. Si le registre conteste ultérieurement le titulaire, le réseau du preneur peut souffrir même si le preneur n'était pas le demandeur initial, n'avait pas signé l'ancienne justification et peut n'avoir aucun lien direct avec le compte du registre.
Le contrat doit donc répondre à une question à laquelle le registre ne répond pas lui-même: qu'obtient réellement le preneur? Il ne peut pas promettre raisonnablement des « adresses » dans l'abstrait. Il doit définir un ensemble de droits et de services: autorisation d'origine de route, utilisation exclusive ou partagée, durée minimale, obligations de support, gestion du DNS inverse, modifications RPKI et IRR, cheminement des abus, remédiation de la réputation, coopération sur la géolocalisation, obligations d'avis aux clients, continuité pendant les litiges et assistance à la sortie. Sans cet ensemble, le preneur a payé pour une chaîne de chiffres et un espoir.
Un bail est un ensemble de contrôles, pas un échéancier de loyer
La forme commerciale d'un bail IPv4 est trompeusement familière. Une partie paie un loyer périodique. Une autre fournit l'accès à un bloc défini. Le client peut verser une caution, fournir des informations sur le cas d'usage, accepter des règles anti-abus et convenir de ne pas sous-louer sans consentement. Cela fait ressembler l'arrangement à une location d'équipement ou d'espace de bureau. Ce n'en est pas un. Un bloc d'adresses loué est un objet de coordination qui dépend de systèmes indépendants acceptant une histoire sur le contrôle.
Le premier contrôle est l'exclusivité. Si le bailleur conserve le registre mais donne l'usage opérationnel au preneur, celui-ci a besoin de l'assurance qu'aucune autre partie n'annoncera, vendra, louera, nantira, réservera ou routera le même préfixe pendant la durée. Une utilisation en double peut créer des conflits de routage, des fuites, des problèmes de filtrage et des pannes pour les clients. Un bailleur avec plusieurs courtiers, revendeurs ou clients historiques peut accidentellement créer des revendications qui se chevauchent. Un enregistrement de registre au nom du bailleur ne dira pas au preneur si un autre accord privé existe.
Le deuxième contrôle est l'autorité. Le preneur a besoin de la preuve que le bailleur peut accorder l'usage. Cette preuve peut inclure les enregistrements actuels du registre, l'autorité de l'entreprise, l'accès au compte, l'absence de litige connu, le contrôle historique des routes, les enregistrements de délégation passée et une autorisation écrite pour l'AS d'origine du preneur. Cela ressemble à la diligence dans un transfert, mais la question est plus opérationnelle qu'archivistique: cette partie peut-elle soutenir l'usage du preneur aujourd'hui et maintenir les contrôles nécessaires liés au registre pendant la durée? La preuve d'autorité est une entrée de continuité, pas l'objet central de l'article.
Le troisième contrôle est la coopération. Un bailleur peut garder son nom dans le WHOIS et rendre néanmoins le bail inutile en ne publiant pas les ROA, en ne mettant pas à jour le DNS inverse, en n'approuvant pas les objets IRR, en ne répondant pas aux escalades d'abus, en ne signant pas les lettres pour les fournisseurs de transit, en n'aidant pas aux corrections de géolocalisation ou en ne donnant pas de préavis lorsque le registre pose une question. De nombreux échecs dans un bail sont des échecs de coopération après que la première route est montée. Le contrat doit transformer la coopération de courtoisie en obligation, avec des fenêtres de service, des contacts autorisés, des chemins d'urgence et des conséquences en cas de retard.
Le quatrième contrôle est l'allocation des risques. Si des abus proviennent du client du preneur, qui absorbe les dommages de filtrage et de mise en liste noire? Si une base de géolocalisation assigne le bloc au mauvais pays, qui poursuit la correction? Si le registre demande au titulaire d'expliquer l'usage, qui prépare les preuves et qui en supporte le coût? Si une action en justice ou du registre interrompt le service, le loyer est-il suspendu, le bailleur fournit-il un espace de remplacement, le preneur reçoit-il un temps de transition, et qu'advient-il des clients en aval? Ce ne sont pas des cas limites exotiques. Ce sont les risques ordinaires créés par la séparation entre la reconnaissance du registre et l'utilisation opérationnelle.
Le loyer importe, mais seulement une fois l'ensemble de contrôle visible. Un bail avec une autorité de route claire, de longues périodes de préavis, un RPKI utilisable, une réputation propre et des conditions de continuité solides a une économie différente d'un bail qui n'offre que l'autorisation de route et une boîte aux lettres. Le prix ne peut pas être évalué indépendamment de l'ensemble de contrôle caché. Un bail bon marché avec des promesses opérationnelles faibles peut être le plan d'adressage le plus cher de la pièce.
Les faits d'usage régional doivent figurer dans l'accord
Chaque RIR est confronté au problème de faire correspondre la région du registre à la géographie opérationnelle. La version de l'AFRINIC est exceptionnellement lourde de conséquences car les arguments sur l'usage régional sont passés du texte de politique au contentieux et aux pratiques de marché. Le contexte est assez simple. La région de service de l'AFRINIC couvre l'Afrique et certaines parties de l'océan Indien. Ses règles d'épuisement et de transfert sont conçues autour de la rareté régionale et de la distribution basée sur les besoins. Son manuel de politique contient des exigences d'enregistrement et des règles de gestion des ressources qui supposent que le registre peut demander où et pourquoi les adresses sont utilisées. Des analyses publiques du litige Cloud Innovation rapportent que l'AFRINIC a contesté des divergences entre l'utilisation déclarée et les pays d'utilisation réels, la cohérence avec le besoin déclaré et l'exigence que les services soient originaires de la région définie.
Pour un bail, cela crée un problème de rédaction. Supposons que le titulaire enregistré soit dans la région AFRINIC, que le preneur soit constitué ailleurs, que l'AS d'origine soit exploité depuis un centre de données européen, que les clients soient mondiaux, que le bloc d'adresses prenne en charge des services tournés vers l'Afrique via une plateforme de contenu, et que les bases de géolocalisation montrent plusieurs pays en fonction du routage et des ensembles de données commerciaux. S'agit-il d'une utilisation régionale conforme, d'une utilisation offshore interdite, d'un service mondial ordinaire ou d'un enregistrement incomplet? Le bail ne peut pas trancher la question de politique pour l'AFRINIC. Mais il peut décider quels faits doivent être divulgués, qui représente quoi, et ce qui se passe si le registre ou une contrepartie conteste l'arrangement.
Un contrat faible évite la question avec un langage vague: « le client se conformera aux politiques du registre applicables » ou « les adresses ne doivent pas être utilisées à mauvais escient ». Cela peut satisfaire un formulaire, mais cela n'alloue pas le risque. Le preneur a besoin de savoir si l'origination hors région est autorisée, si l'usage doit soutenir la connectivité africaine, si la géographie des clients est restreinte, si le bailleur a fait des déclarations à l'AFRINIC qui limitent l'usage, et si le bailleur fournira des copies ou des résumés des contraintes pertinentes. Le bailleur a besoin de savoir si le déploiement du preneur l'exposera à une révision de ressources, à des dommages de réputation ou à un risque de résiliation.
La meilleure architecture traite les faits d'usage régional comme des données contractuelles. Le preneur doit indiquer où les services sont exploités, quels ASN origineront les routes, quelles catégories de clients utiliseront l'espace, si une partie est destinée à des services tournés vers l'Afrique, si des revendications de géolocalisation seront faites, et si une sous-délégation est prévue. Le bailleur doit indiquer si le bloc fait l'objet d'une correspondance de politique connue, d'un statut de litige, de déclarations passées, de restrictions de transfert, de conditions de révision de ressources ou d'engagements d'utilisation qui pourraient affecter le bail. Ces divulgations n'ont pas besoin de rendre public chaque secret commercial. Entre les parties, elles doivent être suffisamment spécifiques pour éviter des surprises ultérieures.
Ce n'est pas un argument pour que les contrats privés contournent la politique régionale. C'est le contraire. Un contrat de location qui nomme honnêtement la géographie opérationnelle donne aux parties, aux fournisseurs de transit et éventuellement au registre une image plus précise que celui qui prétend que le titulaire et l'opérateur sont les mêmes. Lorsque la politique interdit une utilisation, le contrat ne doit pas masquer l'interdiction. Lorsque la politique est peu claire, le contrat doit dire qui supporte l'incertitude. Le pire résultat n'est pas la location commerciale en soi. C'est un marché de la location qui survit en cachant les faits que tout le monde prétendra plus tard avoir besoin.
L'origination de la route est le premier droit de contrôle
L'acte le plus visible dans un bail est l'annonce de route. Jusqu'à ce qu'un préfixe soit originé, le preneur n'a pas de service. Une fois qu'il est originé, le reste de l'Internet commence à se faire une opinion sur qui contrôle le bloc. Les fournisseurs de transit, les pairs, les serveurs de route, les collecteurs de route, les systèmes de surveillance et les clients observent l'AS d'origine. Certains demandent une lettre d'autorisation. Certains vérifient les objets de route IRR. Certains s'appuient sur le RPKI. Certains appliquent des filtres locaux. La route est le point où l'autorisation privée devient un comportement public.
Un contrat de location doit donc définir l'autorité d'origine de route avant toute chose. Il doit identifier le ou les AS d'origine autorisés, si la multi-origine est autorisée, si les annonces plus spécifiques sont permises, quelles longueurs de préfixe peuvent être annoncées, quels fournisseurs de transit ou IXP peuvent recevoir la route, et si le preneur peut déplacer le préfixe entre réseaux pendant la durée. Il doit définir qui signe les lettres d'autorisation, qui peut les révoquer, à quelle vitesse la révocation peut avoir lieu en cas de véritable urgence, et quel préavis est requis avant que le bailleur ne retire l'autorisation ordinaire. Un bail qui dit simplement que le preneur peut « utiliser » le bloc est dangereusement incomplet.
L'autorité de route est aussi le premier endroit où la continuité client rencontre le contrôle du bailleur. Un bailleur peut vouloir des droits de suspension immédiate si le preneur viole les règles anti-abus, ne paie pas, sous-loue sans consentement ou crée un risque juridique. Le preneur a besoin de périodes de remédiation et de recours proportionnés car un retrait brutal peut interrompre les services clients, les flux de paiement, les VPN, les systèmes de messagerie et les listes blanches de sécurité. Le contrat doit distinguer les urgences des défauts ordinaires. Un détournement, une campagne de fraude active ou une ordonnance judiciaire peut justifier une action rapide. Un litige de facturation ou un retard administratif ne devrait généralement pas le faire. Sans cette distinction, le bailleur détient un coupe-circuit privé sur les clients du preneur.
Le cadre institutionnel de l'AFRINIC rend la question de la route plus que technique. Si le registre conteste l'utilisation du titulaire, ou si un litige modifie le statut du compte du titulaire, les fournisseurs de transit peuvent hésiter à accepter l'autorisation du preneur. Le preneur ne peut pas résoudre cela en montrant le bail seul; les réseaux peuvent encore demander si le titulaire reconnu par le registre soutient la route et si les objets de sécurité liés au registre sont à jour. Un contrat doit anticiper cela en obligeant le bailleur à maintenir une preuve continue d'autorisation et à notifier le preneur dans un délai défini de tout événement de registre, de justice ou de compte qui pourrait affecter l'acceptation de la route.
L'origination de route sépare également la délégation légitime du transfert caché. Un bail propre peut dire que le titulaire reste le détenteur enregistré des ressources; le preneur peut originer des routes spécifiées pour des services spécifiés pendant une durée définie; les contacts du registre et les objets de sécurité identifieront ou soutiendront cette délégation opérationnelle lorsque cela est faisable; et aucun transfert de type propriété n'est revendiqué. Un arrangement fantôme en dit peu, route par des intermédiaires et laisse les tiers deviner si le preneur est autorisé ou exploite simplement un enregistrement périmé. La différence n'est pas un langage moral. C'est une preuve.
Le DNS inverse, le RPKI et l'IRR transforment l'autorisation en accessibilité
L'espace IPv4 loué échoue silencieusement lorsque les contrôles adjacents sont en retard sur le routage. Une route BGP peut monter alors que le DNS inverse pointe encore vers une utilisation antérieure, que le RPKI autorise encore l'ancienne origine du bailleur, que les objets IRR sont manquants ou périmés, et que les contacts abuse arrivent dans une boîte aux lettres que personne du côté du preneur ne lit. Les ingénieurs traitent parfois cela comme des tâches d'entretien. Dans un bail, elles font partie de l'actif.
Le DNS inverse est l'exemple le plus clair. De nombreux services utilisent les enregistrements PTR pour la réputation du courrier, la journalisation, les diagnostics, le support client et le confort institutionnel. Le manuel de politique de l'AFRINIC traite la délégation inverse comme un service de registre lié aux assignations ou sous-allocations enregistrées et au statut de membre. Si le bailleur reste en contrôle du DNS inverse, le preneur doit savoir comment les mises à jour seront demandées, quelle politique de nommage s'applique, combien de temps les changements prennent, si les clients peuvent recevoir un contrôle délégué pour leurs plages, et ce qui se passe à la résiliation. Si le DNS inverse ne peut pas être mis à jour parce que le compte du bailleur est en litige ou non à jour, le client du preneur peut rencontrer des problèmes de délivrabilité ou de confiance qui ressemblent à une panne de service.
Le RPKI est encore plus lourd de conséquences car il peut transformer l'autorité en filtrage automatisé. Si un ROA valide autorise la mauvaise origine, ou si aucun ROA n'est présent là où le fournisseur de transit en attend un, le preneur peut subir des pannes partielles d'accessibilité. Si le bailleur peut révoquer ou modifier les ROA sans préavis, le réseau du preneur est exposé à une action administrative privée aux effets globaux. Le contrat doit préciser qui demande ou crée les ROA, quelles valeurs d'AS d'origine et de maxLength sont autorisées, comment les changements d'urgence sont gérés, si le preneur peut recevoir un contrôle de certification délégué si disponible, et quel préavis est requis avant la révocation. Il doit aussi exiger des tests avant la bascule, pas après que les clients se plaignent.
Les objets IRR se situent entre le contrat et l'habitude de routage. De nombreux réseaux continuent de filtrer à l'aide d'objets de route même lorsque le RPKI est disponible. Un bail doit identifier quelle base de données IRR sera utilisée, qui maintient les objets route et route6, quel mainteneur les contrôle, si le bailleur authentifiera les objets créés par le preneur, et comment les objets périmés seront supprimés à la fin. Des données IRR périmées peuvent faire paraître une route autorisée après la fin du bail, ou faire paraître suspecte une route légitime pendant le bail. Les deux cas créent du risque.
Ces services sont le point d'intersection entre le registre public, le contrat privé et l'Internet opérationnel. Les documents de service de l'AFRINIC énumèrent le DNS inverse, l'IRR, le RPKI, le WHOIS et le RDAP car le seul enregistrement du titulaire ne suffit pas. Un contrat de location qui ignore ces contrôles laisse le preneur dépendant de la bonne volonté. Un contrat sérieux les traite comme des livrables avec des délais, des preuves, des chemins de repli et des conséquences visibles pour le client.
La gestion des abus détermine si le risque suit le client ou le préfixe
L'abus est le vocabulaire moral récurrent de la location IPv4. Les critiques pointent le spam, la fraude, l'infrastructure de botnet, l'hameçonnage et l'hébergement évasif. Les défenseurs répondent que l'abus peut survenir sur n'importe quel réseau et que des contacts transparents valent mieux qu'une utilisation cachée. Les deux affirmations peuvent être vraies. La question contractuelle est plus pratique: lorsque du trafic ou du contenu nuisible provient d'un bloc loué, qui reçoit l'avis, qui enquête, qui agit, qui rend compte et qui supporte le coût de réputation?
Le manuel de politique de l'AFRINIC reconnaît un objet contact abuse dédié comme un moyen d'acheminer les plaintes vers le bon contact réseau. Il note également le problème bien connu d'exactitude des données. Dans un bail, l'exactitude devient plus difficile car le titulaire reconnu par le registre peut ne pas être le réseau qui exploite les clients. Si les plaintes d'abus ne parviennent qu'au bailleur, le preneur peut apprendre trop tard. Si elles ne parviennent qu'au preneur, le bailleur peut subir des conséquences du registre ou des fournisseurs de transit sans visibilité. Si elles parviennent à un courtier ou revendeur, les deux parties principales peuvent être isolées de la réalité opérationnelle. Le contrat doit exiger des chemins d'escalade directs, des références de tickets partagées et des délais de réponse définis.
Les clauses sur les abus doivent aussi être proportionnées. Un bailleur ne peut tolérer un preneur qui brûle sa réputation, ignore les plaintes et expose le bloc au filtrage. Un preneur ne peut pas opérer si le bailleur peut résilier tout le préfixe pour un seul signalement non vérifié. Le contrat doit classer les événements: plaintes ordinaires, plaintes répétées non résolues, abus graves vérifiés, avis des forces de l'ordre ou de justice, menaces de suspension de la part de fournisseurs de transit, enquêtes du registre et urgences de réputation. Chaque classe doit avoir un remède: avis, remédiation, isolation du client, null-routage temporaire, prélèvement sur la caution, plage de remplacement, suspension d'un sous-réseau ou résiliation. Le remède doit correspondre au préjudice opérationnel.
Les cas les plus difficiles concernent les clients en aval. Une société d'hébergement peut louer un bloc et assigner des adresses à des centaines de clients. Un client envoie du spam ou héberge du contenu d'hameçonnage. Le bailleur exige la résiliation de tout le bail. La société d'hébergement dit qu'elle peut isoler le client. Les fournisseurs de transit menacent de filtrer. Le registre demande qui est responsable. Sans contrat, tout le monde pointe ailleurs. Avec un bon contrat, le preneur doit maintenir des dossiers d'identité des clients, des règles d'utilisation acceptable, des fichiers d'enquête et une capacité de confinement rapide; le bailleur doit éviter une perturbation plus large que nécessaire; et les deux parties ont un dossier de preuves pour une escalade externe.
La gestion des abus influence aussi le fait que les accords privés révèlent ou cachent la réalité. Si le bail fournit des contacts opérationnels exacts et enregistre la responsabilité en aval, les plaintes parviennent à la partie qui peut agir. Si le bail cache le preneur derrière le titulaire, le dossier public paraît propre jusqu'à ce qu'il échoue. La location devient alors associée à l'évasion même lorsque de nombreux baux sont des arrangements de capacité ordinaires. Le moyen de défendre la location légitime n'est pas la rhétorique. C'est la joignabilité.
La réputation doit être fournie, maintenue et restituée
La réputation IPv4 n'est pas stockée dans une seule base de données. Elle s'accumule dans les listes noires, les systèmes de messagerie, les fournisseurs de géolocalisation, les passerelles de paiement, les historiques des hébergeurs, les moteurs de fraude, les enregistrements de routage, les mémoires des clients et le jugement informel des opérateurs de réseau. Un bail crée une exposition conjointe à cette réputation. Le preneur peut endommager le bloc par le comportement de ses clients. Le bailleur peut nuire au service du preneur en fournissant un bloc avec un historique non divulgué. Le registre peut affecter les deux en associant le bloc à un litige ou à une incertitude de politique. Aucun enregistrement unique ne raconte toute l'histoire.
Un bail doit donc traiter la réputation à la fois comme une condition de livraison et comme un engagement continu. À la livraison, le bailleur doit divulguer le statut connu des listes noires, l'historique récent d'abus, les catégories de clients antérieures, les anomalies de géolocalisation, les problèmes d'historique de routage, les résidus de DNS inverse et tout litige de registre ou public susceptible d'affecter l'intégration. Le preneur doit tester le bloc avant la production et l'accepter ou le rejeter dans un délai défini. Si le preneur accepte une condition connue, il ne doit pas traiter ultérieurement cette condition comme une violation. Si le bailleur cache une condition matérielle, une réduction de loyer ne compensera probablement pas les échecs de migration des clients.
Pendant la durée, la réputation doit être maintenue. Le preneur doit mettre en œuvre des contrôles d'usage acceptable, conserver les dossiers clients, répondre aux plaintes, éviter un roulement rapide qui ressemble à de l'hébergement évasif et coopérer à la remédiation. Le bailleur doit soutenir le déréférencement lorsque son statut de titulaire est nécessaire, maintenir les contacts du registre et éviter de louer un espace adjacent ou chevauchant de manière à contaminer la réputation. Les deux parties doivent conserver des enregistrements des mesures correctives. La réputation se rétablit souvent par des preuves, pas par des affirmations.
La période de résiliation est particulièrement risquée. Un preneur sortant peut avoir des clients utilisant encore des enregistrements DNS, des listes blanches ou des API liées aux adresses. Un bailleur se préparant à louer à nouveau le bloc a besoin de l'assurance que les anciens clients sont partis, que les abus sont corrigés et que les résidus de DNS inverse ou d'IRR sont supprimés. Un nouveau preneur ne veut pas hériter de la réputation de messagerie ou des erreurs de géolocalisation du preneur précédent. Le contrat doit prévoir un processus de restitution de la réputation: analyse finale, rapport de listes noires, clôture des tickets d'abus, nettoyage des objets de route, réinitialisation du DNS inverse, statut de géolocalisation et modifications de certification. C'est l'équivalent opérationnel de la restitution des locaux en bon état.
Le contexte de l'AFRINIC renforce ce point car les histoires publiques de la région incluent à la fois des allégations de manipulation des enregistrements et des utilisations commerciales contestées. Cette combinaison peut amener les tiers à considérer l'espace loué administré par l'AFRINIC comme plus risqué même lorsqu'un bloc particulier est propre. Un contrat ne peut pas réparer la réputation institutionnelle à lui seul. Mais il peut empêcher les parties d'ajouter de l'opacité privée à l'incertitude publique.
La résiliation est difficile car les adresses deviennent une mémoire client
La plupart des baux sont rédigés comme si la fin de la durée ramenait le monde à son état antérieur. La location IPv4 fonctionne rarement ainsi. Les adresses deviennent intégrées dans les systèmes des clients. Elles apparaissent dans le DNS, les pare-feux, les listes blanches d'API, les configurations VPN, les en-têtes de messagerie, les modèles de fraude, les processeurs de paiement, les outils de surveillance, les certificats, les politiques de sécurité et la documentation des fournisseurs. Un client peut ne pas savoir que son fournisseur a loué l'espace. Il sait seulement que l'adresse fonctionne. Lorsque le bail se termine, retirer une route peut devenir une panne commerciale.
Les droits de résiliation exigent donc plus de soin que les clauses de paiement. Le bailleur veut une protection contre le non-paiement, les abus, la sous-location non autorisée, la violation de politique, la perte de reconnaissance du registre et les dommages de réputation. Le preneur veut un préavis prévisible, des droits de remédiation, une assistance à la migration et une continuité client. Un contrat qui donne au bailleur une résiliation immédiate pour « préoccupation de politique » ou « risque de réputation » large peut être commercialement inutilisable. Un contrat qui piège le bailleur pendant des mois pendant que l'abus continue peut être imprudent. Le problème de rédaction est de distinguer les types de défaut et de les assortir de périodes de transition.
Un non-paiement ordinaire peut généralement être traité par un préavis, de courtes périodes de remédiation, des cautions et une suspension progressive. Un abus grave peut exiger le confinement immédiat d'un client ou d'un sous-réseau, mais pas nécessairement le retrait de tout le bloc. Une sous-location non autorisée peut justifier la suspension de la partie non autorisée tout en préservant le service client innocent. Une contestation du registre peut nécessiter une réponse avec preuves et un plan d'urgence plutôt qu'une résiliation automatique. Les ordonnances judiciaires peuvent primer sur le contrat mais doivent néanmoins déclencher des obligations de coopération et des processus d'avis aux clients. Chaque événement a un profil de continuité différent.
La couche client est la raison pour laquelle la résiliation ne peut pas être un duel privé. Si un preneur dessert des entreprises, des banques, des agences publiques, des hôpitaux, des plateformes de contenu ou des réseaux d'accès, un retrait brutal peut nuire à des parties qui n'ont jamais négocié le bail. Le contrat doit obliger le preneur à maintenir un inventaire des clients à un niveau de confidentialité approprié, à identifier les services critiques lorsque cela est légalement possible et faisable, et à préparer des plans de migration. Le bailleur n'a pas à devenir responsable de chaque client en aval, mais il ne devrait pas être autorisé à ignorer un préjudice prévisible lorsqu'un remède moins perturbateur est disponible.
La résiliation affecte également les preuves après coup. Des routes périmées, des ROA périmés, d'anciens objets IRR, des DNS inverses résiduels et des enregistrements DNS clients peuvent faire paraître un bloc restitué détourné, sale ou contesté. Le bail doit exiger une liste de vérification de restitution et une attestation que le contrôle opérationnel a cessé. Cela protège le bailleur, le prochain preneur et le réseau dans son ensemble. Une sortie propre est l'un des signes les plus forts que la location est une délégation ordonnée plutôt qu'un transfert caché.
Les événements du registre nécessitent leurs propres clauses
Le risque le plus spécifique à l'AFRINIC est que la reconnaissance du registre peut ne pas rester une hypothèse de fond tranquille. Un bailleur peut être le titulaire reconnu au moment de la signature du bail. Plus tard, le registre peut contester l'usage, suspendre un service, rejeter une mise à jour, refuser un transfert, changer l'interprétation d'une politique, recevoir une plainte, être soumis à une ordonnance judiciaire, ou faire face à ses propres contraintes opérationnelles. Le contrat du preneur avec le titulaire ne lie pas le registre. C'est l'asymétrie fondamentale de la location.
L'histoire récente de l'AFRINIC donne à ce risque une forme concrète. Les rapports publics décrivent une action de ressource en 2021 contre Cloud Innovation, un litige qui a affecté les comptes bancaires du registre, des années de dysfonctionnement du conseil d'administration et de la direction, une mise sous séquestre, des tentatives d'élection annulées et répétées, une élection du conseil en septembre 2025, des déclarations en 2026 sur le rétablissement et les budgets, et d'autres litiges autour de la liquidation, des publications et des déclarations liées à la location. Ces faits ne décident d'aucun bail privé. Ils montrent pourquoi un preneur ne peut pas supposer que les services du registre seront toujours administrativement routiniers.
Le contrat doit donc définir des clauses d'événement de registre. Un événement de registre peut inclure la perte de la bonne tenue, une révision de ressource, une correspondance défavorable, le rejet d'une mise à jour technique demandée, un drapeau de litige, une ordonnance judiciaire, une contrainte de la mise sous séquestre, un changement de politique affectant le bail, ou une déclaration publique qui altère matériellement l'acceptation de la route ou la confiance des clients. Le bailleur doit avoir le devoir de notifier le preneur sans délai, de fournir des informations non privilégiées, de coopérer à une réponse et d'éviter de faire des admissions unilatérales qui préjudicient l'exploitation du preneur. Le preneur doit avoir le devoir de fournir les faits de déploiement et les informations d'impact client nécessaires à la réponse.
Le traitement du loyer doit être secondaire mais clair. Si une action du registre empêche l'usage, le loyer peut être suspendu ou des avoirs peuvent s'appliquer. Une caution ou un loyer payé d'avance peut garantir l'exécution ou les obligations de transition. Mais la question centrale n'est pas la mécanique de paiement. C'est qui supporte les conséquences opérationnelles lorsque la reconnaissance publique et l'utilisation privée divergent. Un preneur qui a déplacé des clients sur le préfixe a besoin de preuves, de niveaux de service et de droits de transition plus que d'un ajustement comptable ultérieur.
Les clauses d'événement de registre doivent aussi éviter de prétendre que toute préoccupation du registre est illégitime. Si le déploiement du preneur viole une contrainte de politique claire et divulguée, le preneur doit supporter ce risque. Si le bailleur n'a pas divulgué une correspondance ou des restrictions antérieures, le bailleur doit le supporter. Si l'environnement politique change de manière imprévisible, les parties peuvent partager le risque par des droits de résiliation, un espace de remplacement, des périodes de transition ou un ajustement du loyer. L'objectif est d'allouer l'incertitude avant que le ticket n'arrive.
La sous-location transforme la délégation en opacité
La sous-location est le point où un arrangement de capacité efficace peut se transformer en marché fantôme. Un titulaire loue un bloc à un réseau. Ce réseau loue des morceaux à des clients d'hébergement, des revendeurs, des opérateurs VPN, des locataires de cloud ou des fournisseurs de services gérés. Certains de ces clients assignent à nouveau des adresses. Après deux ou trois couches, la partie nommée dans le registre peut avoir peu d'idée de qui origine le trafic, qui reçoit les plaintes d'abus, qui contrôle le DNS inverse pour une tranche, ou quel client sera lésé par une résiliation. Le registre public voit un titulaire; l'Internet vit une chaîne.
Toute délégation en aval n'est pas abusive. De nombreux services réseau l'exigent. Un centre de données peut assigner des adresses à des clients de colocation. Un FAI peut fournir des adresses statiques à des entreprises. Un fournisseur d'hébergement géré peut allouer des adresses aux serveurs des clients. Le problème n'est pas la délégation en soi. C'est la délégation incontrôlée sans preuves, sans contacts et sans obligations en cascade. Une politique de registre qui condamne toute délégation peut la pousser sous terre. Un contrat qui permet toute délégation sans contrôles invite les abus et les préjudices aux clients.
Un bon contrat de location distingue l'assignation ordinaire aux clients de la sous-location commerciale. L'assignation ordinaire aux clients peut être autorisée dans le cadre du service du preneur, sous réserve de règles d'utilisation acceptable et d'enregistrements d'abus. La sous-location commerciale, où le client peut revendre, router indépendamment, contrôler le DNS inverse ou se présenter comme fournisseur des adresses, doit exiger un consentement écrit, des vérifications d'identité, des conditions en cascade et une divulgation opérationnelle. Le bailleur doit savoir si le preneur est un opérateur réseau utilisant des adresses pour ses propres services ou un intermédiaire construisant un second marché de location.
Les obligations en cascade importent car le bailleur ne peut pas faire appliquer ce que le client en aval n'a jamais accepté. La réponse aux abus, les engagements de non-détournement, les limites de routage, les revendications de géolocalisation, l'assistance à la résiliation, la conservation des dossiers clients, la coopération avec les enquêtes du registre et les règles d'interdiction de sous-location ultérieure doivent suivre les adresses. Si elles s'arrêtent au premier preneur, la chaîne se brise exactement là où les preuves sont nécessaires. Le preneur doit rester responsable des actes en aval, mais la responsabilité sans enregistrements est théâtrale.
La sous-location affecte également les revendications d'utilisation régionale. Un preneur peut être conforme régionalement dans son propre déploiement mais permettre à un revendeur en aval d'utiliser l'espace ailleurs. Ou il peut revendiquer un service tourné vers l'Afrique alors que la plupart de l'utilisation en aval est mondiale. Si le bail ne suit pas cette distinction, le titulaire peut faire des déclarations inexactes au registre ou aux contreparties. La transparence ne signifie pas la divulgation publique de chaque client. Cela signifie que le contrat préserve suffisamment de vérité pour répondre à la prochaine question sérieuse.
La géolocalisation transforme des faits concurrents en risque contractuel
La géolocalisation est souvent traitée comme un problème de base de données externe. Dans la location, elle devient un problème contractuel parce que l'usage de l'adresse, la localisation du titulaire enregistré, l'AS d'origine, la localisation du client et le but commercial peuvent pointer dans des directions différentes. Un bloc administré par l'AFRINIC peut être détenu par un membre africain ou de l'océan Indien, routé depuis un centre de données européen, utilisé par des clients sur plusieurs continents et étiqueté par les fournisseurs de géolocalisation commerciaux dans un autre pays encore. Aucun de ces signaux seul ne prouve le mauvais usage ou la légitimité. Ensemble, ils créent un risque d'inférence.
Un projet de recherche de 2026, WHEREIS, est un contexte utile car il traite la cohérence géographique de l'enregistrement comme un problème de mesure plutôt que comme un slogan. Les chercheurs ont construit une méthode pour comparer la localisation mesurée des préfixes avec la région du RIR et la localisation de l'organisation enregistrée. Ils ont constaté que la plupart des préfixes étaient cohérents dans l'ensemble, mais que la variation selon les RIR importait et que l'AFRINIC était une étude de cas. Ils ont également montré que les incohérences peuvent apparaître dans les bases de données de géolocalisation commerciales et que des problèmes structurels, pas seulement l'épuisement IPv4, façonnent le problème. Pour la location, la leçon n'est pas que tout signal hors région prouve une violation. La leçon est que la réalité opérationnelle est plus difficile à inférer lorsque le registre, la route et le récit client divergent.
Les contrats ne doivent pas externaliser ce problème aux fournisseurs de géolocalisation. Ils doivent préciser qui est responsable des corrections de géolocalisation, quelles revendications de pays ou de région peuvent être faites, quelles preuves le preneur peut soumettre aux bases de données, et si le bailleur doit soutenir les demandes de correction. Si le service est vendu comme de la connectivité africaine, cette revendication doit être soutenue par des faits opérationnels réels. Si le service est un hébergement mondial utilisant de l'espace administré par l'AFRINIC, les parties ne doivent pas prétendre le contraire entre elles. Une géolocalisation inexacte peut casser les licences de contenu, les contrôles de fraude, l'accès bancaire, la localisation fiscale, les portails du secteur public et les analyses clients. Ces pertes ne doivent pas être laissées à un langage d'indemnisation générique.
Les revendications d'utilisation régionale exigent aussi de l'humilité. Une catégorie de politique peut ne pas correspondre proprement à l'architecture réseau. Un service de diffusion de contenu hors Afrique peut améliorer l'expérience des utilisateurs africains. Un service anti-abus mondial peut utiliser des adresses dans plusieurs régions. Un client cloud peut être constitué dans un pays, servir des utilisateurs dans un autre et router via un troisième. Un registre peut se concentrer sur l'origine des services. Un client peut se concentrer sur la localisation des utilisateurs. Une base de données de géolocalisation peut se concentrer sur la latence. Le bail ne peut pas éliminer ces définitions, mais il peut empêcher les parties de changer de définition de manière opportuniste.
C'est là que les accords privés peuvent soit améliorer soit dégrader la compréhension publique. Un bail qui enregistre la géographie du déploiement, la catégorie de client et la responsabilité des contacts peut aider à expliquer pourquoi la localisation mesurée diffère de la localisation du titulaire enregistré. Un bail qui cache ces faits fait que la même différence ressemble à de l'évasion. Dans une région où l'utilisation hors région a été judiciarisée et politisée, l'opacité n'est pas neutre. Elle devient une preuve dans le récit de quelqu'un d'autre.
Le registre public et le contrat privé doivent se rencontrer au niveau du contrôle
Le choix institutionnel le plus important dans la location IPv4 est de savoir si les contrats rendent la réalité opérationnelle plus lisible. Un bail peut révéler la réalité en documentant le titulaire, le preneur, l'origine de route, les contacts techniques, le bureau anti-abus, les arrangements DNS inverse, les responsabilités RPKI, les catégories de clients, les règles de sous-délégation, les faits d'usage régional et le plan de résiliation. Il peut enterrer la réalité en ne nommant que le titulaire, en routant via des intermédiaires, en laissant les contacts périmés, en utilisant des autorisations génériques, en cachant les sous-locations et en traitant chaque enquête comme un acte hostile. Les deux structures peuvent produire du trafic. Une seule produit de la confiance.
La politique du registre peut involontairement décider quelle structure prévaut. Si le registre fournit un moyen sûr d'enregistrer la délégation opérationnelle sans traiter chaque location comme un transfert interdit, les parties responsables ont une raison d'être franches. Si le registre traite la franchise comme un déclencheur pour une large révision du modèle d'affaires, les parties divulgueront moins. La base de données devient alors moins précise, et le registre peut citer l'inexactitude comme raison d'un contrôle accru. Ce cycle n'est pas propre à l'AFRINIC, mais la crise de l'AFRINIC le rend visible.
Le registre public n'a pas besoin de publier chaque terme commercial. Le loyer, les marges, les listes de clients, les cautions, les frais de résiliation et la stratégie commerciale peuvent rester privés. Mais certains faits opérationnels sont des faits d'infrastructure. Qui peut originer le préfixe? Qui reçoit les signalements d'abus? Qui peut changer les ROA? Qui contrôle le DNS inverse? Le titulaire enregistré est-il aussi le réseau exploitant? Y a-t-il un litige connu? Existe-t-il un plan d'impact client si la reconnaissance change? Ces faits affectent les tiers. Ils ne sont pas simplement des points de négociation privés.
Il existe des moyens de respecter la confidentialité tout en améliorant la lisibilité. Le bailleur peut fournir une déclaration d'autorisation opérationnelle limitée aux fournisseurs de transit et aux clients. Le preneur peut publier des contacts anti-abus exacts. Les parties peuvent conserver des dossiers clients disponibles dans des conditions juridiques ou de registre définies. Les objets techniques peuvent identifier les mainteneurs sans divulguer d'éléments économiques sensibles. Le statut de litige peut être enregistré sans déclarer de culpabilité. Le bail peut exiger des réponses véridiques aux opérateurs, banques, acheteurs publics et enquêtes du registre. Le principe de conception est simple: cachez les prix si nécessaire; ne cachez pas le contrôle.
L'accord doit aussi préserver des preuves versionnées. Les baux IPv4 durent souvent assez longtemps pour que le personnel, la politique de routage, les clients, les fournisseurs de transit et la pratique du registre changent. Une lettre d'autorisation émise au début peut ne pas expliquer une migration ultérieure d'AS. Une délégation DNS inverse faite pour une catégorie de client peut ne pas expliquer un produit d'hébergement ultérieur. Une correction de géolocalisation soumise un trimestre peut être contredite par un nouveau routage le trimestre suivant. Le bail doit exiger un dossier de preuves qui évolue avec le déploiement: les ASN d'origine actuels, les contacts techniques actuels, les catégories d'utilisation en aval actuelles, les migrations clients matérielles, les événements d'abus significatifs, la correspondance avec le registre, les changements de ROA, les changements IRR et les avis de résiliation. Ce n'est pas de la bureaucratie pour elle-même. C'est la mémoire qui permet aux parties de prouver la continuité lorsqu'un fournisseur de transit, un tribunal, un client ou un registre demande pourquoi la route mérite encore confiance.
La lisibilité est aussi une défense contre l'opportunisme entre les parties. Un preneur qui tient des registres exacts ne peut pas facilement affirmer plus tard qu'il n'a jamais eu connaissance d'une contrainte d'usage régional divulguée. Un bailleur qui signe une autorité de route spécifique ne peut pas facilement nier que l'origine du preneur était autorisée. Un client en aval qui reçoit des conditions en cascade ne peut pas facilement traiter le bloc comme un inventaire de revente si le service n'était qu'une assignation. Le contrat agit donc moins comme un mur contre les tiers que comme une base de faits partagée. Sur un marché où la mémoire est fragmentée entre des tickets, des objets WHOIS, des collecteurs BGP, des fils de courriels et des factures privées, cette base de faits a une valeur économique.
Cette distinction est critique pour l'AFRINIC parce que les arguments publics autour de la location sont devenus très chargés. Si la location est défendue par des affirmations exagérées selon lesquelles les tribunaux ont approuvé tous les modèles commerciaux, elle invite à la correction et à la méfiance. Si la location est attaquée comme intrinsèquement illégitime malgré une demande opérationnelle réelle, elle pousse l'utilisation vers des formes moins visibles. Une meilleure culture contractuelle ferait des affirmations modestes: ce titulaire autorise cet opérateur pour cet usage, sous ces contrôles, avec ces contacts, pour cette durée, sous réserve de ces contraintes divulguées. Ce n'est pas un manifeste politique. C'est de l'hygiène d'infrastructure.
La tentation dans un environnement de registre troublé est de rendre les contrats plus bruyants. Un bailleur promet un contrôle ininterrompu. Un preneur exige des indemnités générales. Un courtier assure à tout le monde que le registre n'aura pas d'importance. Les clients reçoivent des descriptions de service polies qui omettent la différence entre espace transféré et espace loué. Rien de cela ne réduit le risque. Cela ne fait que convertir l'incertitude en violation future.
Un bail IPv4 viable lié à l'AFRINIC devrait faire le contraire. Il devrait réduire l'incertitude. Il devrait indiquer exactement ce que le bailleur peut fournir et ce qu'il ne peut pas. Il devrait reconnaître que l'enregistrement du registre reste avec le titulaire à moins et jusqu'à ce qu'un transfert reconnu ait lieu. Il devrait définir les droits opérationnels du preneur sans prétendre que ces droits sont une propriété. Il devrait répartir les responsabilités de route, de DNS inverse, de RPKI, d'IRR, d'abus, de réputation, de géolocalisation, de sous-location, d'usage régional et de résiliation. Il devrait créer des obligations de coopération pour les événements de registre. Il devrait protéger les clients par des préavis, des remédiations et une planification de migration lorsque c'est possible. Il devrait réserver les recours d'urgence aux vraies urgences.
Cette architecture profite autant au bailleur qu'au preneur. Un bailleur avec des contrats clairs peut montrer qu'il contrôle qui utilise son espace, que les abus sont acheminés vers le bon bureau, que la délégation en aval est gouvernée, que les faits d'usage régional sont connus, et que les objets techniques correspondent à la réalité opérationnelle. Cela rend le bailleur moins vulnérable à l'accusation que la location est indiscernable de l'abandon ou de l'évasion. Cela protège aussi la valeur du bloc en réduisant les dommages de réputation et les sorties chaotiques.
Cela profite au preneur parce que cela convertit une dépendance fragile en une dépendance gérée. Le preneur ne possède toujours pas la position au registre. Il fait toujours face au risque si l'AFRINIC, un tribunal, un fournisseur de transit, un fournisseur de géolocalisation ou un client conteste l'arrangement. Mais il a des preuves, des niveaux de service, des droits de préavis et un plan. Pour de nombreux opérateurs, cela peut être suffisant pour justifier la location pendant la rareté IPv4. Pour d'autres, l'achat, les adresses du fournisseur, la transition IPv6, le CGNAT ou la renumérotation peuvent être plus rationnels. Le travail du contrat n'est pas d'imposer une réponse. C'est de rendre le compromis visible.
Cela profite aussi au système de registre, si le système est disposé à en tirer des leçons. Un registre ne peut pas satisfaire toutes les demandes opérationnelles par de nouvelles allocations. Il peut ne pas vouloir approuver chaque transfert. Il peut avoir des raisons légitimes de s'inquiéter des fuites régionales, de la fraude, des abus et de la spéculation. Mais supprimer la location responsable sans offrir un chemin de délégation lisible n'élimine pas la demande. Cela pousse la demande dans des documents privés, des contournements de routage et des enregistrements incomplets. Le résultat est une moindre visibilité sur la réalité opérationnelle même que le registre dit devoir comprendre.
Le test de l'AFRINIC est donc une économie institutionnelle en miniature. La rareté crée la demande. La politique restreint le transfert. Les opérateurs recherchent la continuité. Les contrats privés comblent le vide. La qualité de ces contrats détermine si la location devient une forme disciplinée de délégation opérationnelle ou un marché d'allocation fantôme. Le registre peut dire qui est reconnu. Il ne peut pas, à lui seul, décider qui répond à 02h17 lorsque la panne client commence. Cette réponse doit être écrite avant que le préfixe ne soit routé.