Location IPv4 AFRINIC: le problème du contrôle divisé

Le premier signe de problème dans un bail IPv4 n'est souvent pas un procès, un document de politique ou un débat public sur la gouvernance régionale. C'est un ticket à 02h17 un dimanche matin. Un hébergeur a déplacé un client bancaire sur un /22 administré par AFRINIC en location. Le trafic est en direct. Les règles de pare-feu, les relais de messagerie, les contrôles antifraude, les scripts de surveillance et les listes d'autorisation des partenaires pointent désormais vers des adresses que le client considère comme une infrastructure de production stable.

Deux fournisseurs amont ont accepté la route après avoir vu une lettre d'autorisation du titulaire enregistré. Le DNS inverse devait suivre le basculement. Une autorisation d'origine de route était attendue mais n'est pas apparue. La boîte aux lettres d'abus est toujours transmise à l'équipe réseau du bailleur. Un fournisseur de géolocalisation place une partie du bloc dans un pays qui ne correspond pas au document de vente. Les rappels de paiement commencent à échouer, et le client demande si le fournisseur contrôle réellement les adresses qu'il a vendues dans le cadre du service.

La salle d'exploitation découvre alors que chaque réponse se trouve à un endroit différent. L'enregistrement du registre nomme une organisation. Le bail en nomme une autre. L'AS d'origine appartient à l'hébergeur. La délégation du DNS inverse est toujours contrôlée par le bailleur. L'objet IRR a été créé par un contact technique d'un courtier. La modification du RPKI nécessite l'accès à un compte de registre que le bailleur dit retardé par une vérification de compte.

Le contrat du client promet une continuité, tandis que le bail d'adresses permet le retrait d'utilisation si le preneur déclenche des plaintes d'abus ou si le registre remet en cause l'arrangement. La banque ne se soucie pas de la clause qui a échoué. Elle sait seulement qu'une plage d'adresses achetée dans le cadre 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 IPv4 permet à un opérateur d'utiliser des adresses rares sans effectuer un 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é est acquise en déplaçant le risque du registre comptable vers 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.

AFRINIC est un cas test pertinent car l'écart entre le registre, la politique et la demande opérationnelle est devenu particulièrement visible. L'organisation administre les ressources numériques pour l'Afrique et une partie de l'océan Indien et fournit les services qui rendent l'utilisation des adresses compréhensible: les relevés WHOIS et RDAP, le DNS inverse, un registre de routage Internet, la certification des ressources et le RPKI, la publication des contacts d'abus, l'administration des membres et les processus de gestion des ressources.

Les documents publics sur l'épuisement indiquent qu'AFRINIC est entré dans la phase 2 d'atterrissage en douceur en janvier 2020, ce qui limite les nouvelles allocations ou affectations ordinaires d'IPv4 à de petites tailles. Son manuel de politique traite de l'exactitude des enregistrements, de la justification des besoins, de l'utilisation régionale et des conditions de transfert comme des éléments centraux du système.

Les rapports publics ont également décrit des allégations de vol d'adresses, le conflit Cloud Innovation sur l'utilisation, la location et le service hors région, un gel des ressources en 2021 et une bataille judiciaire, des années sans fonctionnement normal du conseil d'administration, une mise sous séquestre à partir de 2023, des tentatives d'élection perturbées en 2025, une élection du conseil d'administration en septembre 2025 et des questions continues de litige et de rétablissement en 2026.

Ces faits sont des pièces à conviction de fond, pas un verdict sur chaque bail. Ils importent parce que chacun modifie le coût de la contractualisation privée.

Le preneur veut savoir s'il peut annoncer des routes, si le DNS inverse et le RPKI seront sous contrôle rapide, qui répond en cas d'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 en cas de litige, si la sous-location est autorisée, comment les faits d'utilisation régionale et de géolocalisation sont traités, et si l'accord privé rend la réalité opérationnelle plus visible ou la cache à toutes les personnes qui se fient à l'enregistrement d'adresses. La location n'est pas une échappatoire à la gouvernance.

C'est une gouvernance par contrat où le registre public est trop mince pour décrire l'utilisation.

La thèse est étroite. AFRINIC n'est pas ici principalement un exemple de risque de libération de paiement, d'opacité des prix, de pratique d'inspection des titres ou de remise sur le financement des adresses, bien que chacun puisse apparaître en marge d'une transaction. C'est un test pour savoir combien de risques opérationnels et institutionnels peuvent être repoussés dans un accord privé lorsque le transfert reconnu par le registre ne peut pas satisfaire la demande assez rapidement, à moindre coût ou avec suffisamment de confiance. Un marché locatif peut aider les réseaux à survivre à la rareté.

Il peut aussi créer une allocation parallèle si les contrats ne répartissent pas le contrôle, la responsabilité et les preuves avec précision.

La location commence là où le transfert reconnu par le registre ne peut pas répondre à la demande

La location est souvent décrite comme un substitut de second choix à 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 tente d'aligner le titulaire enregistré, le propriétaire commercial, le réseau d'exploitation et le futur porteur de risque. Un bail les sépare délibérément.

Le titulaire reste dans l'enregistrement du registre; le preneur exploite les adresses; les clients comptent sur le preneur; les systèmes de routage, les systèmes de réputation et les bureaux d'abus observent une utilisation qui peut ne pas correspondre à la lecture simple de l'enregistrement.

Cette séparation apparaît parce que la demande n'attend pas une mobilité administrative parfaite. La rareté du pool libre d'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 bénéficiaire doit justifier le besoin, devenir membre d'AFRINIC, signer l'accord de services d'enregistrement et accepter les politiques en vigueur. Les ressources héritées transférées ne bénéficient plus du traitement hérité. Les entités sources sont soumises à des conditions de refroidissement.

Ces règles peuvent servir des objectifs de conservation, d'équité et de lutte contre la spéculation, mais elles font également du transfert un événement institutionnel plus élaboré qu'un 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 à un examen politique, la location devient commercialement attractive.

La location apparaît également là où le titulaire valorise une optionnalité future. Un titulaire peut ne pas vouloir vendre un bloc parce qu'il s'attend à 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 qui pourrait être contesté. Un bail transforme la capacité dormante ou excédentaire en rendement tout en gardant le nom du titulaire dans l'enregistrement du registre. Pour le preneur, l'échange est différent. Il reçoit une utilisation immédiate mais pas le même contrôle durable qu'un transfert.

Le contrat n'est donc pas une facture de location avec annexes techniques. C'est une constitution privée pour un contrôle divisé.

L'histoire récente d'AFRINIC augmente la demande pour de telles constitutions. Les récits publics du conflit Cloud Innovation décrivent un désaccord sur la question de savoir si l'utilisation réelle, le service client hors région et la location commerciale étaient compatibles avec les représentations antérieures, les attentes politiques et les obligations contractuelles. Le litige ne portait pas seulement sur les adresses. Il s'agissait de savoir si une réalité opérationnelle modifiée pouvait devenir un défaut de reconnaissance par le registre. Cette question est exactement ce qui inquiète un preneur.

Si le registre conteste plus tard le titulaire, le réseau du preneur peut en souffrir même si le preneur n'était pas le demandeur initial, n'a pas signé la justification plus ancienne et n'a peut-être aucun intérêt direct dans le compte du registre.

Le contrat doit donc répondre à une question que le registre ne répond pas par lui-même: qu'est-ce que le preneur obtient réellement? Il ne peut pas promettre raisonnablement des « adresses » dans l'abstrait. Il doit définir un ensemble de droits et de services: permission d'origine de route, utilisation exclusive ou partagée, durée minimale, obligations de support, gestion du DNS inverse, modifications du RPKI et de l'IRR, routage des abus, remédiation de la réputation, coopération en matière de géolocalisation, obligations de notification des clients, continuité en cas de litige et assistance à la sortie.

Sans cet ensemble, le preneur a payé pour une chaîne de nombres et un espoir.

Un bail est un ensemble de contrôle, pas un échéancier de loyer

La forme commerciale d'un bail IPv4 est trompeusement familière. Une partie paie un loyer périodique. L'autre donne accès à un bloc défini. Le client peut fournir un dépôt, fournir des informations sur le cas d'utilisation, accepter des règles d'abus et accepter de ne pas sous-louer sans consentement. Cela fait ressembler l'arrangement à une location d'équipement ou 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 l'enregistrement du registre mais donne au preneur l'utilisation opérationnelle, le preneur a besoin d'une garantie qu'aucune autre partie n'annoncera, ne vendra, ne louera, ne gagera, ne réservera ou ne routtera le même préfixe pendant la durée. Une utilisation en double peut créer des conflits de route, des fuites, des problèmes de filtrage et des pannes clients. Un bailleur avec plusieurs courtiers, revendeurs ou clients historiques peut accidentellement créer des revendications qui se chevauchent.

Un enregistrement de registre nommant le 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 preuves que le bailleur peut accorder l'utilisation. Ces preuves peuvent inclure les enregistrements actuels du registre, l'autorité de l'entreprise, l'accès au compte, l'absence de litiges connus, le contrôle historique de la route, les enregistrements de délégations passées et une autorisation écrite pour l'AS d'origine du preneur.

Cela ressemble à une diligence raisonnable dans un transfert, mais la question est plus opérationnelle qu'archivistique: cette partie peut-elle soutenir l'utilisation du preneur aujourd'hui et maintenir les contrôles nécessaires liés au registre pendant la durée? La preuve d'autorité est un intrant pour la continuité, pas l'objet central de l'article.

Le troisième contrôle est la coopération. Un bailleur peut garder son nom dans WHOIS et rendre 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 amont, en ne soutenant pas les corrections de géolocalisation ou en ne donnant pas de préavis lorsque le registre soulève une question. De nombreux échecs dans un bail sont des échecs de coopération après la première mise en route de la route.

Le contrat devrait convertir la coopération de courtoisie en devoir, avec des fenêtres de service, des contacts autorisés, des voies d'urgence et des conséquences en cas de retard.

Le quatrième contrôle est l'allocation des risques. Si l'abus provient du client du preneur, qui absorbe les dommages de filtrage et de liste noire? Si une base de données de géolocalisation attribue le bloc au mauvais pays, qui poursuit la correction? Si le registre demande au titulaire d'expliquer l'utilisation, qui prépare les preuves et qui supporte les coûts? Si une action judiciaire ou une action de 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'arrive-t-il aux clients en aval? Ce ne sont pas des cas limites exotiques.

Ce sont les risques ordinaires créés par la séparation de la reconnaissance du registre de l'utilisation opérationnelle.

Le loyer compte, mais seulement une fois que l'ensemble de contrôle est visible. Un bail avec une autorité de route claire, de longs délais de préavis, un RPKI utilisable, une réputation propre et de fortes conditions de continuité a une économie différente d'un bail qui n'offre qu'une permission 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'adresses le plus coûteux de la pièce.

Les faits d'utilisation régionale appartiennent à l'accord

Chaque RIR est confronté au problème de faire correspondre la région du registre à la géographie opérationnelle. La version d'AFRINIC est particulièrement importante car les arguments sur l'utilisation régionale sont passés du texte politique au contentieux et à la pratique du marché. Le contexte est assez clair. La région de service d'AFRINIC couvre l'Afrique et une partie 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. Les analyses publiques du conflit Cloud Innovation rapportent qu'AFRINIC a remis en question les écarts entre l'utilisation enregistrée et les pays réels d'utilisation, la cohérence avec le besoin déclaré et l'exigence que les services proviennent de la région définie.

Pour un bail, cela crée un problème de rédaction. Supposons que le titulaire enregistré se trouve dans la région AFRINIC, que le preneur soit constitué ailleurs, que l'AS d'origine soit exploitée depuis un centre de données européen, que les clients soient mondiaux, que le bloc d'adresses soutienne des services tournés vers l'Afrique via une plateforme de contenu, et que les bases de données de géolocalisation montrent plusieurs pays en fonction du routage et des ensembles de données commerciaux. Est-ce une utilisation régionale conforme, une utilisation offshore interdite, un service mondial ordinaire, ou un enregistrement incomplet?

Le bail ne peut pas décider de la question politique pour 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 le problème avec un langage vague: « le client doit se conformer à la politique applicable du registre » 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'utilisation doit soutenir la connectivité africaine, si la géographie des clients est restreinte, si le bailleur a fait des représentations à AFRINIC qui limitent l'utilisation, 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 à un examen des ressources, à des dommages de réputation ou à un risque de résiliation.

La meilleure architecture traite les faits d'utilisation régionale comme des données contractuelles. Le preneur doit indiquer où les services sont exploités, quels ASN annonceront les routes, quelles catégories de clients utiliseront l'espace, si une partie est destinée à un service tourné vers l'Afrique, si des réclamations de géolocalisation seront faites, et si une sous-délégation est prévue.

Le bailleur doit indiquer si le bloc est soumis à une correspondance politique connue, à un statut de litige, à des représentations passées, à des restrictions de transfert, à des conditions d'examen des ressources ou à des 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 une surprise ultérieure.

Ce n'est pas un argument en faveur de contrats privés pour contourner 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 amont et éventuellement au registre une image plus précise qu'un contrat qui prétend que le titulaire et l'opérateur sont identiques. Lorsque la politique interdit une utilisation, le contrat ne doit pas dissimuler l'interdiction. Lorsque la politique n'est pas claire, le contrat doit dire qui supporte l'incertitude. Le pire résultat n'est pas la location commerciale elle-même.

C'est un marché locatif qui survit en cachant les faits que tout le monde prétend avoir besoin plus tard.

L'origination de route est le premier droit de contrôle

L'acte le plus visible dans un bail est l'annonce de route. Tant qu'un préfixe n'est pas originaire, le preneur n'a pas de service. Une fois qu'il est originaire, 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 se fient au RPKI. Certains appliquent des filtres locaux. La route est l'endroit où l'autorisation privée devient un comportement public.

Un contrat de location doit donc définir l'autorité d'origine de route avant tout. Il doit identifier l'AS ou les AS d'origine autorisés, savoir si une multi-origine est autorisée, si des annonces plus spécifiques sont autorisées, quelles longueurs de préfixe peuvent être annoncées, quels fournisseurs amont ou IXP peuvent recevoir la route, et si le preneur peut déplacer le préfixe entre les 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 se produire en cas d'urgence réelle, et quel préavis est requis avant qu'un 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 également le premier endroit où la continuité client rencontre le contrôle du bailleur. Un bailleur peut vouloir des droits de suspension immédiats si le preneur enfreint les règles d'abus, ne paie pas, sous-loue sans consentement ou crée un risque juridique. Le preneur a besoin de délais de guérison 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 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 peuvent justifier une action rapide. Un litige de facturation ou un retard de paperasse ne le devrait généralement pas. Sans cette distinction, le bailleur détient un interrupteur de mise à mort privé sur les clients du preneur.

Le cadre institutionnel d'AFRINIC rend la question de 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 amont peuvent hésiter à accepter l'autorisation du preneur. Le preneur peut ne pas résoudre ce problème en montrant le seul bail; les réseaux peuvent toujours 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 exigeant que le bailleur maintienne une preuve continue d'autorisation et qu'il notifie le preneur dans un délai défini de tout événement de registre, judiciaire 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 titulaire enregistré de la ressource; le preneur peut annoncer 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 dans la mesure du possible; et aucun transfert de type propriété n'est revendiqué. Un arrangement parallèle en dit peu, route par des intermédiaires et laisse les étrangers deviner si le preneur est autorisé ou s'il exploite simplement un enregistrement obsolète.

La différence n'est pas un langage moral. C'est une preuve.

DNS inverse, RPKI et IRR transforment la permission en joignabilité

L'espace IPv4 loué échoue silencieusement lorsque les contrôles adjacents sont en retard sur le routage. Une route BGP peut être mise en place tandis que le DNS inverse pointe toujours vers une utilisation précédente, que le RPKI autorise toujours l'ancienne origine du bailleur, que les objets IRR sont manquants ou obsolètes, et que les contacts d'abus atterrissent encore dans une boîte aux lettres que personne côté preneur ne lit. Les ingénieurs traitent parfois ces tâches comme des tâches de maintenance. 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 d'AFRINIC traite la délégation inverse comme un service de registre lié aux affectations ou sous-affectations 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 prennent les changements, 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 pas à jour, le client du preneur peut rencontrer des problèmes de délivrabilité ou de confiance qui ressemblent à une défaillance de service.

Le RPKI est encore plus important 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 amont en attend un, le preneur peut faire face à des échecs de joignabilité partiels. 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 avec des effets mondiaux.

Le contrat doit spécifier qui demande ou crée les ROA, quelles valeurs d'AS d'origine et de maxLength sont autorisées, comment les changements urgents sont traité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 également exiger des tests avant le basculement, 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 filtrent encore en utilisant des 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 de route et route6, quel mainteneur les contrôle, si le bailleur authentifiera les objets créés par le preneur, et comment les objets obsolètes seront supprimés à la fin. Des données IRR obsolètes peuvent maintenir une route semblant autorisée après la fin du bail, ou rendre une route légitime suspecte pendant le bail. Les deux cas créent du risque.

Ces services sont l'endroit où le registre comptable, le contrat privé et l'Internet opérationnel se croisent. Les documents de service d'AFRINIC listent le DNS inverse, l'IRR, le RPKI, WHOIS et RDAP car l'enregistrement du titulaire seul 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 pour le client.

La gestion des abus décide 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 des botnets, le hameçonnage et l'hébergement évasif. Les défenseurs répondent que l'abus peut se produire 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 fait rapport et qui supporte le coût de réputation?

Le manuel de politique d'AFRINIC reconnaît un objet de contact d'abus dédié comme un moyen de router les plaintes vers le bon contact réseau. Il note également le problème familier de l'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 exploitant les clients. Si les plaintes d'abus vont uniquement au bailleur, le preneur peut apprendre trop tard. Si elles vont uniquement au preneur, le bailleur peut faire face à des conséquences de registre ou en amont sans visibilité.

Si elles vont à un courtier ou revendeur, les deux parties principales peuvent être isolées de la réalité opérationnelle. Le contrat doit exiger des voies d'escalade directes, des références de tickets partagées et des temps de réponse définis.

Les clauses d'abus ont également besoin de proportionnalité. Un bailleur ne peut pas tolérer un preneur qui brûle la réputation, ignore les plaintes et expose le bloc au filtrage. Un preneur ne peut pas fonctionner si le bailleur peut résilier tout le préfixe pour un seul rapport non vérifié. Le contrat doit classer les événements: plaintes ordinaires, plaintes non résolues répétées, abus graves vérifiés, notifications des forces de l'ordre ou du tribunal, menaces de suspension des fournisseurs amont, demandes de registre et urgences de réputation.

Chaque classe doit avoir un recours: préavis, guérison, isolement du client, route nulle temporaire, retrait de dépôt, plage de remplacement, suspension d'un sous-réseau ou résiliation. Le recours doit correspondre au préjudice opérationnel.

Les cas les plus difficiles impliquent des clients en aval. Une société d'hébergement peut louer un bloc et attribuer des adresses à des centaines de clients. Un client envoie du spam ou héberge du contenu de 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 amont menacent de filtrage. Le registre demande qui est responsable. Sans contrat, tout le monde pointe ailleurs.

Avec un bon contrat, le preneur doit tenir des registres d'identité des clients, des règles d'utilisation acceptable, des dossiers d'enquête et une capacité de confinement rapide; le bailleur doit éviter une perturbation plus large que nécessaire; et les deux côtés ont un dossier de preuves pour l'escalade externe.

La gestion des abus influence également si les accords privés révèlent ou cachent la réalité. Si le bail fournit des contacts opérationnels précis et enregistre la responsabilité en aval, les plaintes atteignent la partie qui peut agir. Si le bail cache le preneur derrière le titulaire, le dossier public semble propre jusqu'à ce qu'il échoue. La location devient alors associée à l'évasion même si de nombreux baux sont des arrangements de capacité ordinaires. La façon de défendre la location légitime n'est pas la rhétorique. C'est la joignabilité.

La réputation doit être livrée, 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 fournisseurs d'hébergement, 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 du client. Le bailleur peut endommager le 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 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 des abus, les catégories de clients antérieurs, les anomalies de géolocalisation, les problèmes d'historique de route, les résidus de DNS inverse et tout litige de registre ou public qui pourrait 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 plus tard traiter cette condition comme une violation.

Si le bailleur cache une condition matérielle, un crédit de loyer ne suffit probablement pas à compenser les migrations de clients échouées.

Pendant la durée, la réputation doit être maintenue. Le preneur doit exploiter des contrôles d'utilisation acceptable, conserver les enregistrements des clients, répondre aux plaintes, éviter un roulement rapide qui ressemble à un hébergement évasif, et coopérer à la remédiation. Le bailleur doit soutenir le délistage 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 est souvent récupérée 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 qui utilisent encore des enregistrements DNS, des listes d'autorisation ou des API liés aux adresses. Un bailleur se préparant à louer à nouveau le bloc a besoin d'être sûr que les anciens clients sont partis, que les abus ont été 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 précédent preneur.

Le contrat doit prévoir un processus de restitution de la réputation: analyse finale, rapport de liste noire, 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 d'AFRINIC renforce le point car les histoires publiques de la région incluent à la fois des allégations de manipulation de registres et d'utilisation commerciale contestée. Cette combinaison peut amener les étrangers à considérer l'espace loué administré par AFRINIC comme plus risqué même lorsqu'un bloc particulier est propre. Un contrat ne peut pas réparer la réputation institutionnelle par lui-même. 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 la mémoire du client

La plupart des baux sont rédigés comme si la fin du terme 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-feu, les listes d'autorisation d'API, les configurations VPN, les en-têtes de courrier, 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 prend fin, retirer une route peut devenir une panne commerciale.

Les droits de résiliation nécessitent donc plus de soin que les clauses de paiement. Le bailleur veut une protection contre le non-paiement, l'abus, la sous-location non autorisée, la violation de la politique, la perte de reconnaissance du registre et le préjudice de réputation. Le preneur veut un préavis prévisible, des droits de guérison, une assistance à la migration et une continuité client. Un contrat qui donne au bailleur une résiliation immédiate pour un large « souci politique » ou « risque de réputation » peut être commercialement inutilisable.

Un contrat qui piège le bailleur pendant des mois alors que l'abus continue peut être imprudent. Le problème de rédaction est de distinguer les types de défaut et de les faire correspondre à des périodes de transition.

Le non-paiement ordinaire peut généralement être traité par un préavis, de courtes périodes de guérison, des dépôts et une suspension progressive. L'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. La sous-location non autorisée peut justifier la suspension de la partie non autorisée tout en préservant le service des clients innocents. La contestation du registre peut nécessiter une réponse en preuves et un plan de contingence plutôt qu'une résiliation automatique.

Les ordonnances judiciaires peuvent primer sur le contrat mais doivent toujours déclencher des obligations de coopération et des processus de notification des 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 sert 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 blesser des parties qui n'ont jamais négocié le bail. Le contrat doit exiger du preneur qu'il tienne un inventaire des clients à un niveau de confidentialité approprié, identifie les services critiques lorsque la loi et la faisabilité le permettent, et prépare des plans de migration.

Le bailleur n'a pas besoin de devenir responsable de chaque client en aval, mais il ne doit pas être autorisé à ignorer les préjudices prévisibles lorsqu'un recours moins perturbateur est disponible.

La résiliation affecte également les preuves après coup. Des routes obsolètes, des ROA obsolètes, de vieux objets IRR, un DNS inverse persistant et des enregistrements DNS clients peuvent donner l'impression qu'un bloc restitué a été détourné, sali ou contesté. Le bail doit exiger une liste de vérification de restitution et une attestation que le contrôle opérationnel a pris fin. 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 de registre nécessitent leurs propres clauses

Le risque le plus spécifique à AFRINIC est que la reconnaissance du registre peut ne pas rester une hypothèse de fond silencieuse. Un bailleur peut être le titulaire reconnu lorsque le bail est signé. Plus tard, le registre peut contester l'utilisation, suspendre un service, rejeter une mise à jour, refuser un transfert, modifier l'interprétation 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 d'AFRINIC donne à ce risque une forme concrète. Les rapports publics décrivent une action sur les ressources 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 d'administration en septembre 2025, des déclarations en 2026 sur le rétablissement et les budgets, et d'autres litiges concernant la liquidation, les publications et les représentations 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 bonne réputation, l'examen des ressources, la correspondance défavorable, le rejet d'une mise à jour technique demandée, le signalement d'un litige, une ordonnance judiciaire, une contrainte de 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 du client.

Le bailleur doit avoir l'obligation d'informer 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 l'obligation de fournir des faits de déploiement et des informations sur l'impact client nécessaires à la réponse.

Le traitement du loyer doit être secondaire mais clair. Si une action de registre empêche l'utilisation, le loyer peut être réduit ou des crédits peuvent s'appliquer. Un dépôt ou un loyer prépayé peut garantir l'exécution ou les obligations de transition. Mais la question centrale n'est pas la mécanique du 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 également éviter de prétendre que toute préoccupation du registre est illégitime. Si le déploiement du preneur viole une contrainte politique clairement 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 le biais de droits de résiliation, d'espace de remplacement, de périodes de transition ou d'ajustement du loyer. Le but est de répartir l'incertitude avant que le ticket n'arrive.

La sous-location est l'endroit où la délégation devient opacité

La sous-location est le point auquel un arrangement de capacité efficace peut se transformer en marché parallèle. Un titulaire loue un bloc à un réseau. Ce réseau loue des parties à des clients d'hébergement, des revendeurs, des opérateurs VPN, des locataires cloud ou des fournisseurs de services gérés. Certains de ces clients attribuent à nouveau des adresses. Après deux ou trois couches, la partie nommée dans le registre peut avoir peu d'idée de qui originaire 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 la résiliation.

Le registre public voit un titulaire; l'Internet expérimente 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 attribuer 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 clients. Le problème n'est pas la délégation en soi. C'est la délégation incontrôlée sans preuves, contacts ou obligations de répercussion. Une politique de registre qui condamne toute délégation peut la pousser dans la clandestinité. Un contrat qui permet toute délégation sans contrôles invite à l'abus et au préjudice client.

Un bon contrat de location distingue l'attribution client ordinaire de la sous-location commerciale. L'attribution client ordinaire peut être autorisée dans le cadre du service du preneur, sous réserve des règles d'utilisation acceptable et des 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 nécessiter un consentement écrit, des vérifications d'identité, des conditions de répercussion 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é locatif.

Les obligations de répercussion comptent car le bailleur ne peut pas faire respecter ce que le client en aval n'a jamais accepté. La réponse aux abus, les clauses de non-détournement, les limites de routage, les réclamations de géolocalisation, l'assistance à la résiliation, la conservation des enregistrements clients, la coopération aux demandes du registre et l'interdiction de sous-location supplémentaire doivent suivre les adresses. Si elles s'arrêtent au premier preneur, la chaîne se brise exactement là où des 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 des utilisations en aval sont mondiales. Si le bail ne suit pas cette distinction, le titulaire peut faire des déclarations inexactes au registre ou aux contreparties. La transparence ne doit pas signifier la divulgation publique de chaque client.

Elle 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 car l'utilisation des adresses, l'emplacement du titulaire enregistré, l'AS d'origine, l'emplacement du client et l'objectif commercial peuvent pointer dans des directions différentes. Un bloc administré par AFRINIC peut être détenu par un membre de la région Afrique ou océan Indien, routé depuis un centre de données européen, utilisé par des clients sur plusieurs continents et étiqueté par des fournisseurs de géolocalisation commerciaux dans un autre pays.

Aucun de ces signaux ne prouve à lui seul un abus ou une 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 des enregistrements comme un problème de mesure plutôt que comme un slogan. Les chercheurs ont construit un moyen de comparer l'emplacement mesuré du préfixe avec la région du RIR et l'emplacement de l'organisation enregistrée. Ils ont constaté que la plupart des préfixes étaient cohérents dans l'ensemble, mais que les variations entre RIR importent et qu'AFRINIC était une étude de cas.

Ils ont également montré que des incohérences peuvent apparaître dans les bases de données de géolocalisation commerciales et que des problèmes structurels, et pas seulement l'épuisement de l'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 à déduire lorsque l'enregistrement, la route et l'histoire du client divergent.

Les contrats ne doivent pas externaliser ce problème aux fournisseurs de géolocalisation. Ils doivent spécifier qui est responsable de la correction de la 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 une connectivité africaine, cette affirmation doit être étayée par des faits opérationnels réels. Si le service est un hébergement mondial utilisant un espace administré par AFRINIC, les parties ne doivent pas prétendre le contraire entre elles.

Une géolocalisation inexacte peut briser les licences de contenu, les contrôles de fraude, l'accès bancaire, la localisation fiscale, les portails du secteur public et l'analyse client. Ces pertes ne doivent pas être laissées à un langage d'indemnisation générique.

Les revendications d'utilisation régionale exigent également de l'humilité. Une catégorie politique peut ne pas correspondre proprement à l'architecture réseau. Un service de diffusion de contenu en dehors de l'Afrique peut améliorer l'expérience utilisateur africaine. Un service mondial anti-abus 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 tiers. Un registre peut se concentrer sur l'origine des services. Un client peut se concentrer sur l'emplacement 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 améliorer ou dégrader la compréhension publique. Un bail qui enregistre la géographie de déploiement, la catégorie de client et la responsabilité de contact peut aider à expliquer pourquoi l'emplacement mesuré diffère de l'emplacement du titulaire enregistré. Un bail qui cache ces faits fait ressembler la même différence à une évasion. Dans une région où l'utilisation hors région a été litigieuse et politisée, l'opacité n'est pas neutre. Elle devient une preuve dans l'histoire de quelqu'un d'autre.

Le registre public et le contrat privé devraient se rencontrer au 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 la route, les contacts techniques, le bureau des abus, les arrangements de DNS inverse, les responsabilités RPKI, les catégories de clients, les règles de sous-délégation, les faits d'utilisation régionale et le plan de résiliation.

Il peut enterrer la réalité en ne nommant que le titulaire, en routant par des intermédiaires, en laissant les contacts obsolètes, en utilisant des autorisations génériques, en cachant les sous-locations et en traitant chaque demande 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 offre un moyen sûr d'enregistrer la délégation opérationnelle sans traiter chaque bail comme un transfert interdit, les parties responsables ont une raison d'être franches. Si le registre traite la franchise comme un déclencheur pour un examen large du modèle commercial, les parties divulgueront moins. La base de données devient alors moins précise, et le registre peut citer l'imprécision comme une raison pour plus de contrôle. Ce cycle n'est pas unique à AFRINIC, mais la crise d'AFRINIC le rend visible.

Le registre public n'a pas besoin de publier chaque condition commerciale. Le loyer, les marges, les listes de clients, les dépôts, 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 annoncer le préfixe? Qui reçoit les rapports d'abus? Qui peut modifier les ROA? Qui contrôle le DNS inverse? Le titulaire enregistré est-il également le réseau d'exploitation? Y a-t-il un litige connu? Y a-t-il un plan d'impact client si la reconnaissance change? Ces faits affectent des 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 amont et aux clients. Le preneur peut publier des contacts d'abus précis. Les parties peuvent conserver des enregistrements clients disponibles dans des conditions définies par la loi ou le registre. Les objets techniques peuvent identifier les mainteneurs sans divulguer des données économiques sensibles. Le statut du litige peut être enregistré sans déclarer la culpabilité.

Le bail peut exiger des réponses véridiques aux transporteurs, aux banques, aux acheteurs publics et aux demandes du registre. Le principe de conception est simple: cachez les prix si nécessaire; ne cachez pas le contrôle.

L'accord doit également conserver des preuves versionnées. Les baux IPv4 durent souvent assez longtemps pour que le personnel, la politique de routage, les clients, les fournisseurs amont et la pratique du registre changent. Une lettre d'autorisation émise au début peut ne pas expliquer une migration d'AS ultérieure. Une délégation de DNS inverse faite pour une classe de clients 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: ASN d'origine actuels, contacts techniques actuels, catégories d'utilisation en aval actuelles, migrations de clients importantes, événements d'abus significatifs, correspondance avec le registre, modifications ROA, modifications IRR et 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 amont, un tribunal, un client ou le registre demande pourquoi la route mérite encore la confiance.

La lisibilité est aussi une défense contre l'opportunisme entre les parties. Un preneur qui tient des registres précis ne peut pas facilement prétendre plus tard qu'il n'a jamais eu connaissance d'une contrainte d'utilisation régionale 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 de répercussion ne peut pas facilement traiter le bloc comme un inventaire de revente si le service n'était qu'une attribution. Le contrat agit donc moins comme un mur contre les étrangers que comme une base de faits partagée.

Dans un marché où la mémoire est fragmentée entre tickets, objets WHOIS, collecteurs BGP, fils de discussion et factures privées, cette base de faits a une valeur économique.

Cette distinction est cruciale pour AFRINIC car 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 déclarations modestes: ce titulaire autorise cet opérateur pour cette utilisation, sous ces contrôles, avec ces contacts, pour cette période, sous réserve de ces contraintes divulguées. Ce n'est pas un manifeste politique. C'est l'hygiène de l'infrastructure.

La tentation dans un environnement de registre troublé est de rendre les contrats plus forts. Un bailleur promet un contrôle ininterrompu. Un preneur exige des indemnisations 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 un espace transféré et un espace loué. Rien de tout cela ne réduit le risque. Cela ne fait que convertir l'incertitude en violation future.

Un bail IPv4 lié à AFRINIC viable devrait faire le contraire. Il devrait réduire l'incertitude. Il devrait énoncer 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 tant qu'un transfert reconnu n'a pas eu 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 en matière de route, DNS inverse, RPKI, IRR, abus, réputation, géolocalisation, sous-location, utilisation régionale et résiliation.

Il devrait créer des obligations de coopération pour les événements de registre. Il devrait protéger les clients par le biais d'un préavis, d'une guérison et d'une planification de migration dans la mesure du possible. Il devrait réserver les recours d'urgence aux véritables 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 dirigés vers le bon bureau, que la délégation en aval est régie, que les faits d'utilisation régionale sont connus et que les objets techniques correspondent à la réalité opérationnelle. Cela rend le bailleur moins vulnérable à l'accusation selon laquelle la location est indiscernable de l'abandon ou de l'évasion. Cela protège également la valeur du bloc en réduisant les dommages de réputation et les sorties chaotiques.

Cela profite au preneur car cela convertit une dépendance fragile en une dépendance gérée. Le preneur ne possède toujours pas la position du registre. Il fait toujours face à un risque si AFRINIC, un tribunal, un fournisseur amont, 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 suffire à justifier la location pendant la pénurie d'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 de forcer une réponse. C'est de rendre l'échange visible.

Cela profite également au système de registre, si le système est prêt à en tirer des leçons. Un registre ne peut pas satisfaire toutes les demandes opérationnelles par une nouvelle allocation. 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 une voie de délégation lisible ne supprime pas la demande. Il pousse la demande vers des documents privés, des solutions de contournement de routage et des enregistrements incomplets.

Le résultat est moins de visibilité sur la réalité opérationnelle même que le registre dit devoir comprendre.

Le test d'AFRINIC est donc l'économie institutionnelle en miniature. La rareté crée la demande. La politique contraint le transfert. Les opérateurs recherchent la continuité. Les contrats privés comblent le vide. La qualité de ces contrats décide si la location devient une forme disciplinée de délégation opérationnelle ou un marché d'allocation parallèle. Le registre comptable peut dire qui est reconnu. Il ne peut pas, par lui-même, 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é.