Arrendamento IPv4 da AFRINIC e o problema do controle dividido

O primeiro sinal de problema em um arrendamento IPv4 geralmente não é um processo judicial, um documento de política ou uma discussão pública sobre governança regional. É um ticket às 02:17 em uma manhã de domingo. Um provedor de hospedagem moveu um cliente bancário para um /22 arrendado administrado pela AFRINIC. O tráfego está ativo. Regras de firewall, relays de email, controles de fraude, scripts de monitoramento e listas de permissão de parceiros agora apontam para endereços que o cliente trata como infraestrutura de produção estável. Dois upstreams aceitaram a rota após ver uma carta de autorização do titular registrado.

O DNS reverso deveria seguir a migração. Uma autorização de origem de rota era esperada, mas não apareceu. A caixa de correio de abuso ainda encaminha para a equipe de rede do arrendador. Um fornecedor de geolocalização coloca parte do bloco em um país que não corresponde ao material de vendas. Callbacks de pagamento começam a falhar, e o cliente pergunta se o provedor realmente controla os endereços que vendeu como parte do serviço.

A sala de operações então descobre que cada resposta está em um lugar diferente. O registro nomeia uma organização. O arrendamento nomeia outra. O AS de origem pertence ao provedor de hospedagem. A delegação de DNS reverso ainda é controlada pelo arrendador. O objeto do IRR foi criado pelo contato técnico de um corretor. A mudança de RPKI requer acesso a uma conta de registro que o arrendador diz estar atrasada devido a uma revisão de conta. O contrato do cliente promete continuidade, enquanto o arrendamento de endereços permite a retirada de uso se o arrendatário provocar reclamações de abuso ou se o registro questionar o acordo.

O banco não se importa qual cláusula falhou. Ele só sabe que uma faixa de endereços comprada como parte de um serviço confiável agora se comporta como uma cadeia de promessas privadas.

Esse é o problema do contrato de arrendamento. O arrendamento IPv4 permite que um operador use endereços escassos sem completar uma transferência reconhecida pelo registro. O acordo pode ser eficiente. Um titular com espaço não utilizado ou subutilizado ganha receita sem abrir mão do controle de longo prazo. Uma rede que precisa de endereços para um lançamento de produto, migração, cliente de data center, serviço de segurança ou expansão temporária obtém capacidade utilizável sem o custo de capital, atraso ou incerteza política de uma compra. Mas a eficiência é obtida movendo o risco do livro-razão do registro para o contrato.

O livro-razão registra um titular. A rede precisa de uma realidade operacional. O arrendamento deve explicar como esses dois fatos coexistem.

A AFRINIC é um caso de teste claro porque a lacuna entre livro-razão, política e demanda operacional se tornou extraordinariamente visível. A organização administra recursos numéricos para a África e partes do Oceano Índico e fornece os serviços que tornam o uso de endereços legível: registros WHOIS e RDAP, DNS reverso, um Registro de Roteamento da Internet, certificação de recursos e RPKI, publicação de contato de abuso, administração de membros e processos de gerenciamento de recursos.

O material público de exaustão registra que a AFRINIC entrou na Fase 2 de Soft Landing em janeiro de 2020, deixando novas alocações ou atribuições IPv4 comuns restritas a tamanhos pequenos. Seu manual de política trata precisão de registro, justificativa de necessidade, uso regional e condições de transferência como características centrais do sistema.

Reportagens públicas também descreveram alegações de roubo de endereços, a disputa da Cloud Innovation sobre uso, arrendamento e serviço fora da região, um congelamento de recursos em 2021 e briga judicial, anos sem função normal do conselho, administração judicial a partir de 2023, tentativas eleitorais conturbadas em 2025, uma eleição do conselho em setembro de 2025 e contínuas questões de litígio e restauração em 2026.

Esses fatos são evidências de fundo, não um veredito sobre cada arrendamento. Eles importam porque cada um muda o custo da contratação privada.

O arrendatário quer saber se pode originar rotas, se o DNS reverso e o RPKI estarão sob controle oportuno, quem responde por abuso, quem absorve danos à reputação, o que acontece quando o contrato termina, o que acontece se o reconhecimento do registro mudar, como os clientes são protegidos durante uma disputa, se o subarrendamento é permitido, como os fatos de uso regional e geolocalização são tratados, e se o acordo privado torna a realidade operacional mais visível ou a esconde de todos que dependem do registro de endereço. O arrendamento não é uma fuga da governança.

É governança por contrato onde o livro-razão público é muito fino para descrever o uso.

O arrendamento começa onde a transferência reconhecida pelo registro não pode atender à demanda

O arrendamento é frequentemente descrito como um substituto de segunda classe para a propriedade. Isso perde a distinção mais importante nos mercados de IPv4: controle reconhecido pelo registro versus uso operacional. Uma transferência completa tenta alinhar o titular registrado, proprietário comercial, rede operacional e futuro portador de risco. Um arrendamento deliberadamente os separa. O titular permanece no registro; o arrendatário opera os endereços; os clientes dependem do arrendatário; sistemas de roteamento, sistemas de reputação e mesas de abuso observam um uso que pode não corresponder à leitura simples do registro.

Essa separação aparece porque a demanda não espera por mobilidade administrativa perfeita. A escassez do pool livre da AFRINIC limita o que uma rede em crescimento pode obter por meio de alocação ordinária. Suas regras de transferência são baseadas em necessidade e enquadradas regionalmente: o destinatário deve justificar a necessidade, tornar-se membro da AFRINIC, assinar o acordo de serviços de registro e aceitar as políticas atuais. Recursos legados transferidos não desfrutam mais do tratamento de legados. Entidades de origem enfrentam condições de resfriamento.

Essas regras podem servir a propósitos de conservação, equidade e combate à especulação, mas também tornam a transferência um evento institucional mais elaborado do que uma ordem de compra privada. Se um operador de data center precisa de endereços neste trimestre, e se uma transferência reconhecida levaria tempo incerto ou exporia as partes a revisão de política, um arrendamento se torna comercialmente atraente.

O arrendamento também aparece onde o titular valoriza a opcionalidade futura. Um titular pode não querer vender um bloco porque espera demanda interna posterior, quer reserva estratégica, teme perder poder de barganha ou não quer converter uma posição reconhecida em um arquivo de transferência que pode ser questionado. Um arrendamento transforma capacidade ociosa ou de reserva em rendimento, mantendo o nome do titular no registro. Para o arrendatário, a troca é diferente. Ele recebe uso imediato, mas não o mesmo controle durável de uma transferência. O contrato não é, portanto, uma fatura de aluguel com anexos técnicos.

É uma constituição privada para controle dividido.

A história recente da AFRINIC aumenta a demanda por tais constituições. Relatos públicos da disputa da Cloud Innovation descrevem um desacordo sobre se o uso real, o serviço ao cliente fora da região e o arrendamento comercial eram compatíveis com representações anteriores, expectativas políticas e obrigações contratuais. A disputa não era apenas sobre endereços. Era sobre se a realidade operacional alterada poderia se tornar um defeito no reconhecimento do registro. Essa questão é exatamente o que um arrendatário teme.

Se o registro posteriormente desafiar o titular, a rede do arrendatário pode sofrer mesmo que o arrendatário não tenha sido o requerente original, não tenha assinado a justificativa anterior e possa não ter representação direta na conta do registro.

O contrato deve, portanto, responder a uma pergunta que o livro-razão não responde por si só: o que o arrendatário realmente obtém? Ele não pode prometer sensatamente "endereços" no abstrato. Deve definir um conjunto de direitos e serviços: permissão de origem de rota, uso exclusivo ou compartilhado, prazo mínimo, obrigações de suporte, tratamento de DNS reverso, alterações de RPKI e IRR, roteamento de abuso, remediação de reputação, cooperação de geolocalização, obrigações de notificação ao cliente, continuidade durante disputas e assistência na saída. Sem esse conjunto, o arrendatário pagou por uma string numérica e uma esperança.

Um arrendamento é um pacote de controle, não uma tabela de aluguel

A forma comercial de um arrendamento IPv4 é enganosamente familiar. Uma parte paga aluguel periódico. Outra fornece acesso a um bloco definido. O cliente pode depositar uma caução, fornecer informações de caso de uso, aceitar regras de abuso e concordar em não subarrendar sem consentimento. Isso faz o acordo parecer com aluguel de equipamento ou escritório. Não é. Um bloco de endereços arrendado é um objeto de coordenação que depende de sistemas independentes aceitarem uma história sobre controle.

O primeiro controle é a exclusividade. Se o arrendador mantém o registro mas dá ao arrendatário o uso operacional, o arrendatário precisa de garantia de que nenhuma outra parte anunciará, venderá, arrendará, penhorará, reservará ou roteará o mesmo prefixo durante o prazo. O uso duplicado pode criar conflitos de rota, vazamentos, problemas de filtragem e interrupções para o cliente. Um arrendador com múltiplos corretores, revendedores ou clientes históricos pode criar inadvertidamente reivindicações sobrepostas. Um registro nomeando o arrendador não dirá ao arrendatário se existe outro acordo privado.

O segundo controle é a autoridade. O arrendatário precisa de evidência de que o arrendador pode conceder uso. Essa evidência pode incluir registros atuais, autoridade corporativa, acesso à conta, ausência de disputas conhecidas, controle histórico de rota, registros de delegação passada e autorização por escrito para o AS de origem do arrendatário. Isso se assemelha à diligência em uma transferência, mas a questão é mais operacional que arquivística: esta parte pode suportar o uso do arrendatário hoje e manter os controles vinculados ao registro necessários durante o prazo?

A evidência de autoridade é uma entrada para a continuidade, não o objeto central do artigo.

O terceiro controle é a cooperação. Um arrendador pode manter seu nome no WHOIS e ainda tornar o arrendamento inútil ao não publicar ROAs, atualizar DNS reverso, aprovar objetos IRR, responder a escalações de abuso, assinar cartas para upstreams, apoiar correções de geolocalização ou dar aviso quando o registro levantar uma questão. Muitas falhas em um arrendamento são falhas de cooperação após a primeira rota subir. O contrato deve transformar cooperação de cortesia em dever, com janelas de serviço, contatos autorizados, caminhos de emergência e consequências para atraso.

O quarto controle é a alocação de risco. Se o abuso vem do cliente do arrendatário, quem absorve o dano de filtragem e lista negra? Se um banco de dados de geolocalização atribui o bloco ao país errado, quem busca a correção? Se o registro pede ao titular para explicar o uso, quem prepara evidências e quem arca com o custo? Se uma ação judicial ou de registro interrompe o serviço, o aluguel pausa, o arrendador fornece espaço substituto, o arrendatário recebe tempo de transição, e o que acontece com os clientes downstream? Esses não são casos extremos exóticos.

São os riscos comuns criados pela separação entre reconhecimento do registro e uso operacional.

O aluguel importa, mas apenas depois que o pacote de controle estiver visível. Um arrendamento com autoridade de rota clara, longos períodos de aviso, RPKI utilizável, reputação limpa e fortes termos de continuidade tem economia diferente de um arrendamento que oferece apenas permissão de rota e uma caixa de correio. O preço não pode ser avaliado separadamente do pacote de controle oculto. Um arrendamento barato com promessas operacionais fracas pode ser o plano de endereçamento mais caro da sala.

Fatos de uso regional pertencem ao acordo

Cada RIR enfrenta o problema de corresponder região do registro à geografia operacional. A versão da AFRINIC é extraordinariamente consequente porque argumentos de uso regional passaram do texto político para litígio e prática de mercado. O histórico é claro o suficiente. A região de serviço da AFRINIC cobre a África e partes do Oceano Índico. Suas regras de exaustão e transferência são projetadas em torno da escassez regional e distribuição baseada em necessidade. Seu manual de política contém requisitos de registro e regras de gerenciamento de recursos que assumem que o registro pode perguntar onde e por que os endereços estão sendo usados.

Análises públicas da disputa da Cloud Innovation relatam que a AFRINIC questionou discrepâncias entre uso registrado e países reais de uso, consistência com a necessidade declarada e o requisito de que os serviços se originem dentro da região definida.

Para um arrendamento, isso cria um problema de redação. Suponha que o titular registrado esteja na região da AFRINIC, o arrendatário esteja incorporado em outro lugar, o AS de origem seja operado a partir de um data center europeu, os clientes sejam globais, o bloco de endereços suporte serviços voltados para a África por meio de uma plataforma de conteúdo, e bancos de dados de geolocalização mostrem vários países dependendo de roteamento e conjuntos de dados comerciais. Isso é uso regional compatível, uso offshore impermissível, serviço global ordinário ou um registro incompleto?

O arrendamento não pode decidir a questão política para a AFRINIC. Mas pode decidir quais fatos devem ser divulgados, quem representa o quê e o que acontece se o registro ou uma contraparte desafiar o acordo.

Um contrato fraco evita a questão com linguagem vaga: "o cliente deve cumprir a política de registro aplicável" ou "os endereços não devem ser mal utilizados". Isso pode satisfazer um formulário, mas não aloca risco. O arrendatário precisa saber se a origem fora da região é permitida, se o uso deve suportar conectividade africana, se a geografia do cliente é restrita, se o arrendador fez representações à AFRINIC que limitam o uso e se o arrendador fornecerá cópias ou resumos das restrições relevantes. O arrendador precisa saber se a implantação do arrendatário o exporá a revisão de recursos, danos à reputação ou risco de rescisão.

A melhor arquitetura trata os fatos de uso regional como dados contratuais. O arrendatário deve declarar onde os serviços são operados, quais ASNs originarão rotas, quais categorias de cliente usarão o espaço, se alguma parte é destinada a serviço voltado para a África, se reivindicações de geolocalização serão feitas e se a subdelegação é esperada. O arrendador deve declarar se o bloco está sujeito a correspondência política conhecida, status de disputa, representações passadas, restrições de transferência, condições de revisão de recursos ou compromissos de uso que possam afetar o arrendamento.

Essas divulgações não precisam tornar todos os segredos comerciais públicos. Entre as partes, elas devem ser específicas o suficiente para evitar surpresas posteriores.

Isso não é um argumento para contratos privados evadirem a política regional. É o oposto. Um contrato de arrendamento que nomeia a geografia operacional honestamente dá às partes, upstreams e possivelmente ao registro uma imagem mais precisa do que um que finge que o titular e o operador são os mesmos. Onde a política proíbe um uso, o contrato não deve encobrir a proibição. Onde a política é pouco clara, o contrato deve dizer quem arca com a incerteza. O pior resultado não é o arrendamento comercial em si. É um mercado de arrendamento que sobrevive escondendo os fatos que todos depois afirmam precisar.

A origem de rota é o primeiro direito de controle

O ato mais visível em um arrendamento é o anúncio de rota. Até que um prefixo seja originado, o arrendatário não tem serviço. Uma vez originado, o resto da internet começa a formar uma opinião sobre quem controla o bloco. Provedores de trânsito, peers, servidores de rota, coletores de rota, sistemas de monitoramento e clientes observam o AS de origem. Alguns pedem uma carta de autorização. Alguns verificam objetos de rota IRR. Alguns confiam no RPKI. Alguns aplicam filtros locais. A rota é onde a permissão privada se torna comportamento público.

Um contrato de arrendamento deve, portanto, definir a autoridade de origem de rota antes de qualquer outra coisa. Deve identificar o AS ou ASNs de origem autorizados, se multi-origem é permitida, se anúncios mais específicos são permitidos, quais comprimentos de prefixo podem ser anunciados, quais upstreams ou IXPs podem receber a rota e se o arrendatário pode mover o prefixo entre redes durante o prazo. Deve definir quem assina cartas de autorização, quem pode revogá-las, com que rapidez a revogação pode ocorrer em uma emergência real e qual aviso é necessário antes que o arrendador retire a autorização ordinária.

Um arrendamento que simplesmente diz que o arrendatário pode "usar" o bloco é perigosamente incompleto.

A autoridade de rota também é o primeiro lugar onde a continuidade do cliente encontra o controle do arrendador. Um arrendador pode querer direitos de suspensão imediata se o arrendatário violar regras de abuso, não pagar, subarrendar sem consentimento ou criar risco legal. O arrendatário precisa de períodos de cura e remédios proporcionais porque a retirada abrupta pode quebrar serviços ao cliente, fluxos de pagamento, VPNs, sistemas de email e listas de permissão de segurança. O contrato deve distinguir emergências de inadimplências ordinárias. Um sequestro, campanha de fraude ativa ou ordem judicial pode justificar ação rápida.

Uma disputa de cobrança ou atraso de papelada geralmente não deve. Sem essa distinção, o arrendador detém um interruptor privado sobre os clientes do arrendatário.

O ambiente institucional da AFRINIC torna a questão da rota mais que técnica. Se o registro desafiar o uso do titular, ou se uma disputa alterar o status da conta do titular, os upstreams podem hesitar em aceitar a autorização do arrendatário. O arrendatário pode não resolver isso mostrando o arrendamento sozinho; as redes ainda podem perguntar se o titular reconhecido pelo registro suporta a rota e se os objetos de segurança vinculados ao registro estão atualizados.

Um contrato deve antecipar isso, exigindo que o arrendador mantenha evidência contínua de autorização e notifique o arrendatário dentro de um período de aviso definido de qualquer evento de registro, tribunal ou conta que possa afetar a aceitação da rota.

A origem de rota também separa delegação legítima de transferência oculta. Um arrendamento limpo pode dizer que o titular permanece o titular registrado do recurso; o arrendatário pode originar rotas especificadas para serviços especificados durante um prazo definido; contatos de registro e objetos de segurança identificarão ou apoiarão essa delegação operacional onde viável; e nenhuma transferência semelhante a propriedade é reivindicada. Um arranjo sombra diz pouco, roteia através de intermediários e deixa estranhos adivinhando se o arrendatário é autorizado ou meramente explorando um registro desatualizado.

A diferença não é linguagem moral. É evidência.

DNS reverso, RPKI e IRR transformam permissão em acessibilidade

O espaço IPv4 arrendado falha silenciosamente quando controles adjacentes ficam atrás do roteamento. Uma rota BGP pode subir enquanto o DNS reverso ainda aponta para um uso anterior, o RPKI ainda autoriza a origem antiga do arrendador, objetos IRR estão ausentes ou desatualizados, e contatos de abuso ainda caem em uma caixa de correio que ninguém do lado do arrendatário lê. Engenheiros às vezes tratam essas como tarefas de housekeeping. Em um arrendamento, elas fazem parte do ativo.

O DNS reverso é o exemplo mais claro. Muitos serviços usam registros PTR para reputação de email, registro, diagnósticos, suporte ao cliente e conforto institucional. O manual de política da AFRINIC trata a delegação reversa como um serviço de registro vinculado a atribuições ou subalocações registradas e status de membro. Se o arrendador permanecer no controle do DNS reverso, o arrendatário deve saber como as atualizações serão solicitadas, qual política de nomenclatura se aplica, quanto tempo as alterações levam, se os clientes podem receber controle delegado para suas faixas e o que acontece na rescisão.

Se o DNS reverso não puder ser atualizado porque a conta do arrendador está em disputa ou não está atualizada, o cliente do arrendatário pode experimentar problemas de entregabilidade ou confiança que parecem falha de serviço.

O RPKI é ainda mais consequente porque pode transformar autoridade em filtragem automatizada. Se um ROA válido autoriza a origem errada, ou se nenhum ROA está presente onde o upstream espera um, o arrendatário pode enfrentar falhas parciais de acessibilidade. Se o arrendador pode revogar ou alterar ROAs sem aviso, a rede do arrendatário está exposta a uma ação administrativa privada com efeitos globais.

O contrato deve especificar quem solicita ou cria ROAs, qual AS de origem e valores maxLength são permitidos, como alterações de emergência são tratadas, se o arrendatário pode receber controle de certificação delegado se disponível e qual aviso é necessário antes da revogação. Também deve exigir testes antes da migração, não depois dos clientes reclamarem.

Os objetos IRR ficam entre o contrato e o hábito de roteamento. Muitas redes ainda filtram usando objetos de rota mesmo quando o RPKI está disponível. Um arrendamento deve identificar qual banco de dados IRR será usado, quem mantém os objetos de rota e route6, qual maintainer os controla, se o arrendador autenticará objetos criados pelo arrendatário e como objetos desatualizados serão removidos no final. Dados IRR desatualizados podem fazer uma rota parecer autorizada após o fim do arrendamento, ou fazer uma rota legítima parecer suspeita durante o arrendamento. Ambos os casos criam risco.

Esses serviços são onde o livro-razão do registro, o contrato privado e a internet operacional se intersectam. Os materiais de serviço da AFRINIC listam DNS reverso, IRR, RPKI, WHOIS e RDAP porque o registro do titular sozinho não é suficiente. Um contrato de arrendamento que ignora esses controles deixa o arrendatário dependente de boa vontade. Um contrato sério os trata como entregas com prazos, evidência, caminhos alternativos e consequências voltadas ao cliente.

O tratamento de abuso decide se o risco segue o cliente ou o prefixo

O abuso é o vocabulário moral recorrente do arrendamento IPv4. Críticos apontam spam, fraude, infraestrutura de botnet, phishing e hospedagem evasiva. Defensores respondem que o abuso pode ocorrer em qualquer rede e que contatos transparentes são melhores que uso oculto. Ambas as afirmações podem ser verdadeiras. A questão contratual é mais prática: quando tráfego ou conteúdo prejudicial vem de um bloco arrendado, quem recebe o aviso, quem investiga, quem age, quem reporta e quem arca com o custo de reputação?

O manual de política da AFRINIC reconhece um objeto de contato de abuso dedicado como uma forma de encaminhar reclamações ao contato de rede correto. Também observa o problema familiar de precisão de dados. Em um arrendamento, a precisão se torna mais difícil porque o titular reconhecido pelo registro pode não ser a rede que opera os clientes. Se as reclamações de abuso vão apenas para o arrendador, o arrendatário pode saber tarde demais. Se vão apenas para o arrendatário, o arrendador pode enfrentar consequências de registro ou upstream sem visibilidade.

Se vão para um corretor ou revendedor, ambas as partes principais podem estar isoladas da realidade operacional. O contrato deve exigir caminhos de escalação diretos, referências de ticket compartilhadas e tempos de resposta definidos.

As cláusulas de abuso também precisam de proporcionalidade. Um arrendador não pode tolerar um arrendatário que queima reputação, ignora reclamações e expõe o bloco à filtragem. Um arrendatário não pode operar se o arrendador puder rescindir todo o prefixo por um relato não verificado. O contrato deve classificar eventos: reclamações ordinárias, reclamações repetidas não resolvidas, abuso grave verificado, notificações de aplicação da lei ou tribunal, ameaças de suspensão de upstream, consultas de registro e emergências de reputação.

Cada classe deve ter um remédio: aviso, cura, isolamento do cliente, null-route temporário, saque de depósito, faixa de substituição, suspensão de uma sub-rede ou rescisão. O remédio deve corresponder ao dano operacional.

Os casos mais difíceis envolvem clientes downstream. Uma empresa de hospedagem pode arrendar um bloco e atribuir endereços a centenas de clientes. Um cliente envia spam ou hospeda conteúdo de phishing. O arrendador exige rescisão de todo o arrendamento. A empresa de hospedagem diz que pode isolar o cliente. Upstreams ameaçam filtros. O registro pergunta quem é responsável. Sem contrato, todos apontam para outro lugar.

Com um bom contrato, o arrendatário deve manter registros de identidade do cliente, regras de uso aceitável, arquivos de investigação e capacidade de contenção rápida; o arrendador deve evitar perturbação mais ampla que o necessário; e ambos os lados têm um pacote de evidências para escalação externa.

O tratamento de abuso também influencia se os acordos privados revelam ou escondem a realidade. Se o arrendamento fornece contatos operacionais precisos e registra responsabilidade downstream, as reclamações alcançam a parte que pode agir. Se o arrendamento esconde o arrendatário atrás do titular, o registro público parece limpo até falhar. O arrendamento então se torna associado à evasão, mesmo quando muitos arrendamentos são acordos de capacidade ordinários. A maneira de defender o arrendamento legítimo não é retórica. É contatabilidade.

A reputação precisa ser entregue, mantida e devolvida

A reputação IPv4 não está armazenada em um único banco de dados. Acumula-se em listas negras, sistemas de email, fornecedores de geolocalização, gateways de pagamento, históricos de provedores de hospedagem, mecanismos de fraude, registros de roteamento, memórias de clientes e julgamento informal de operadores de rede. Um arrendamento cria exposição conjunta a essa reputação. O arrendatário pode danificar o bloco através do comportamento do cliente. O arrendador pode danificar o serviço do arrendatário fornecendo um bloco com histórico não divulgado. O registro pode afetar ambos ao associar o bloco a disputa ou incerteza política.

Nenhum registro único conta toda a história.

Um arrendamento deve, portanto, tratar a reputação como uma condição de entrega e um pacto contínuo. Na entrega, o arrendador deve divulgar o status conhecido em listas negras, histórico recente de abuso, categorias anteriores de cliente, anomalias de geolocalização, problemas de histórico de rota, resíduos de DNS reverso e qualquer disputa de registro ou pública que possa afetar a integração. O arrendatário deve testar o bloco antes da produção e aceitá-lo ou rejeitá-lo dentro de um período definido. Se o arrendatário aceitar uma condição conhecida, não deve posteriormente tratar essa condição como violação.

Se o arrendador esconder uma condição material, apenas crédito de aluguel dificilmente compensará migrações de cliente fracassadas.

Durante o prazo, a reputação deve ser mantida. O arrendatário deve operar controles de uso aceitável, preservar registros de cliente, responder a reclamações, evitar rotatividade rápida que pareça hospedagem evasiva e cooperar com remediação. O arrendador deve apoiar a remoção de listas onde seu status de titular é necessário, manter contatos de registro e evitar arrendar espaço adjacente ou sobreposto que contamine a reputação. Ambas as partes devem manter registros de etapas de remediação. A reputação é frequentemente recuperada por evidência, não por afirmação.

O período de rescisão é especialmente arriscado. Um arrendatário que sai pode ter clientes ainda usando registros DNS, listas de permissão ou APIs vinculadas aos endereços. Um arrendador se preparando para arrendar o bloco novamente precisa de garantia de que os clientes antigos se foram, o abuso foi remediado e os resíduos de DNS reverso ou IRR foram removidos. Um novo arrendatário não quer herdar a reputação de email ou erros de geolocalização do arrendatário anterior.

O contrato deve prever um processo de devolução de reputação: varredura final, relatório de lista negra, encerramento de tickets de abuso, limpeza de objetos de rota, redefinição de DNS reverso, status de geolocalização e alterações de certificação. Este é o equivalente operacional de devolver as instalações em bom estado.

O histórico da AFRINIC reforça o ponto porque as histórias públicas da região incluem alegações de manipulação de registro e uso comercial disputado. Essa combinação pode fazer com que estranhos tratem o espaço arrendado administrado pela AFRINIC como mais arriscado, mesmo quando um bloco específico está limpo. Um contrato não pode reparar a reputação institucional por si só. Mas pode evitar que as partes adicionem opacidade privada à incerteza pública.

A rescisão é difícil porque os endereços se tornam memória do cliente

A maioria dos arrendamentos é redigida como se o fim do prazo devolvesse o mundo ao estado anterior. O arrendamento IPv4 raramente funciona assim. Os endereços se tornam incorporados nos sistemas do cliente. Aparecem em DNS, firewalls, listas de permissão de API, configurações de VPN, cabeçalhos de email, modelos de fraude, processadores de pagamento, ferramentas de monitoramento, certificados, políticas de segurança e documentação de fornecedor. Um cliente pode não saber que seu provedor arrendou o espaço. Só sabe que o endereço funciona. Quando o arrendamento termina, retirar uma rota pode se tornar uma interrupção comercial.

Os direitos de rescisão, portanto, exigem mais cuidado que cláusulas de pagamento. O arrendador quer proteção contra não pagamento, abuso, subarrendamento não autorizado, violação de política, perda de reconhecimento do registro e dano à reputação. O arrendatário quer aviso previsível, direitos de cura, assistência à migração e continuidade do cliente. Um contrato que dá ao arrendador rescisão imediata por "preocupação política" ampla ou "risco de reputação" pode ser comercialmente inutilizável. Um contrato que prende o arrendador por meses enquanto o abuso continua pode ser imprudente.

O problema de redação é distinguir tipos de inadimplência e combiná-los com períodos de transição.

O não pagamento ordinário geralmente pode ser tratado através de aviso, curtos períodos de cura, depósitos e suspensão escalonada. Abuso grave pode exigir contenção imediata de um cliente ou sub-rede, mas não necessariamente retirada de todo o bloco. O subarrendamento não autorizado pode justificar suspensão da porção não autorizada enquanto preserva o serviço inocente do cliente. O desafio do registro pode exigir resposta com evidência e plano de contingência, não rescisão automática. Ordens judiciais podem sobrepor o contrato, mas ainda devem desencadear deveres de cooperação e processos de notificação ao cliente.

Cada evento tem um perfil de continuidade diferente.

A camada do cliente é a razão pela qual a rescisão não pode ser um duelo privado. Se um arrendatário atende empresas, bancos, agências públicas, hospitais, plataformas de conteúdo ou redes de acesso, a retirada abrupta pode prejudicar partes que nunca negociaram o arrendamento. O contrato deve exigir que o arrendatário mantenha um inventário de clientes em nível apropriado de confidencialidade, identifique serviços críticos onde legal e viável, e prepare planos de migração.

O arrendador não precisa se tornar responsável por cada cliente downstream, mas não deve ser autorizado a ignorar danos previsíveis quando um remédio menos disruptivo está disponível.

A rescisão também afeta a evidência após o fato. Rotas desatualizadas, ROAs desatualizados, objetos IRR antigos, DNS reverso persistente e registros DNS do cliente podem fazer um bloco devolvido parecer sequestrado, sujo ou contestado. O arrendamento deve exigir uma lista de verificação de devolução e uma atestação de que o controle operacional terminou. Isso protege o arrendador, o próximo arrendatário e a rede mais ampla. Uma saída limpa é um dos sinais mais fortes de que o arrendamento é uma delegação ordenada em vez de uma transferência oculta.

Eventos de registro precisam de suas próprias cláusulas

O risco mais específico da AFRINIC é que o reconhecimento do registro pode não permanecer uma suposição de fundo tranquila. Um arrendador pode ser o titular reconhecido quando o arrendamento é assinado. Depois, o registro pode questionar o uso, suspender um serviço, rejeitar uma atualização, recusar uma transferência, alterar a interpretação da política, receber uma reclamação, tornar-se sujeito a uma ordem judicial ou enfrentar restrições operacionais próprias. O contrato do arrendatário com o titular não vincula o registro. Essa é a assimetria fundamental do arrendamento.

A história recente da AFRINIC dá a esse risco uma forma concreta. Reportagens públicas descrevem uma ação de recursos contra a Cloud Innovation em 2021, litígio que afetou as contas bancárias do registro, anos de disfunção do conselho e executiva, administração judicial, tentativas eleitorais anuladas e repetidas, uma eleição do conselho em setembro de 2025, declarações em 2026 sobre recuperação e orçamentos, e mais litígios sobre liquidação, publicações e representações relacionadas a arrendamento. Esses fatos não decidem nenhum arrendamento privado.

Eles mostram por que um arrendatário não pode assumir que os serviços de registro serão sempre administrativamente rotineiros.

O contrato deve, portanto, definir cláusulas de evento de registro. Um evento de registro pode incluir perda de boa situação, revisão de recursos, correspondência adversa, rejeição de uma atualização técnica solicitada, bandeira de disputa, ordem judicial, restrição de administração judicial, mudança na política que afete o arrendamento ou declaração pública que prejudique materialmente a aceitação da rota ou a confiança do cliente.

O arrendador deve ter o dever de notificar o arrendatário sem demora, fornecer informações não privilegiadas, cooperar em uma resposta e evitar fazer admissões unilaterais que prejudiquem a operação do arrendatário. O arrendatário deve ter o dever de fornecer fatos de implantação e informações de impacto ao cliente necessárias para a resposta.

O tratamento do aluguel deve ser secundário, mas claro. Se a ação do registro impedir o uso, o aluguel pode ser reduzido ou créditos podem ser aplicados. Um depósito ou aluguel pré-pago pode garantir desempenho ou obrigações de transição. Mas a questão central não é mecânica de pagamento. É quem arca com as consequências operacionais quando o reconhecimento público e o uso privado divergem. Um arrendatário que moveu clientes para o prefixo precisa de evidência, níveis de serviço e direitos de transição mais do que um ajuste contábil posterior.

As cláusulas de evento de registro também devem evitar fingir que toda preocupação do registro é ilegítima. Se a implantação do arrendatário viola uma restrição política clara e divulgada, o arrendatário deve arcar com esse risco. Se o arrendador não divulgou correspondência ou restrições anteriores, o arrendador deve arcar. Se o ambiente político muda imprevisivelmente, as partes podem compartilhar o risco através de direitos de rescisão, espaço substituto, períodos de transição ou ajuste de aluguel. O ponto é alocar a incerteza antes que o ticket chegue.

Subarrendamento é onde a delegação se torna opacidade

O subarrendamento é o ponto em que um acordo de capacidade eficiente pode se transformar em um mercado sombra. Um titular arrenda um bloco a uma rede. Essa rede arrenda partes a clientes de hospedagem, revendedores, operadores de VPN, inquilinos de nuvem ou provedores de serviço gerenciado. Alguns desses clientes atribuem endereços novamente. Após duas ou três camadas, a parte nomeada no registro pode ter pouca ideia de quem origina tráfego, quem recebe reclamações de abuso, quem controla o DNS reverso para uma fatia ou qual cliente será prejudicado pela rescisão. O livro público vê um titular; a internet experimenta uma cadeia.

Nem toda delegação downstream é abusiva. Muitos serviços de rede exigem isso. Um data center pode atribuir endereços a clientes de colocation. Um ISP pode fornecer endereços estáticos a empresas. Um provedor de hospedagem gerenciada pode alocar endereços a servidores de clientes. O problema não é a delegação em si. É a delegação descontrolada sem evidência, contatos ou obrigações de repasse. Uma política de registro que condena toda delegação pode levá-la à clandestinidade. Um contrato que permite toda delegação sem controles convida ao abuso e danos ao cliente.

Um bom contrato de arrendamento distingue atribuição ordinária de cliente de subarrendamento comercial. A atribuição ordinária de cliente pode ser permitida dentro do serviço do arrendatário, sujeita a regras de uso aceitável e registros de abuso. O subarrendamento comercial, onde o cliente pode revender, rotear independentemente, controlar DNS reverso ou apresentar-se como provedor dos endereços, deve exigir consentimento por escrito, verificações de identidade, termos de repasse e divulgação operacional.

O arrendador deve saber se o arrendatário é um operador de rede usando endereços para seus próprios serviços ou um intermediário construindo um segundo mercado de arrendamento.

As obrigações de repasse importam porque o arrendador não pode fazer cumprir o que o cliente downstream nunca concordou. Resposta a abuso, pactos de não sequestro, limites de roteamento, reivindicações de geolocalização, assistência à rescisão, retenção de registros de cliente, cooperação com consultas de registro e regras de não subarrendamento adicional devem seguir os endereços. Se param no primeiro arrendatário, a cadeia quebra exatamente onde a evidência é necessária. O arrendatário deve permanecer responsável por atos downstream, mas responsabilidade sem registros é teatral.

O subarrendamento também afeta reivindicações de uso regional. Um arrendatário pode ser regionalmente conforme em sua própria implantação, mas permitir que um revendedor downstream use o espaço em outro lugar. Ou pode reivindicar serviço voltado para a África enquanto a maior parte do uso downstream é global. Se o arrendamento não rastrear essa distinção, o titular pode fazer declarações imprecisas ao registro ou a contrapartes. Transparência não precisa significar divulgação pública de cada cliente. Significa que o contrato preserva verdade suficiente para responder à próxima pergunta séria.

A geolocalização transforma fatos concorrentes em risco contratual

A geolocalização é frequentemente tratada como um problema externo de banco de dados. No arrendamento, torna-se um problema contratual porque local de uso do endereço, localização do titular registrado, AS de origem, localização do cliente e propósito comercial podem apontar em direções diferentes. Um bloco administrado pela AFRINIC pode ser detido por um membro da região da África ou Oceano Índico, roteado de um data center europeu, usado por clientes em vários continentes e marcado por provedores de geolocalização comerciais em outro país. Nenhum desses sinais sozinho prova uso indevido ou legitimidade. Juntos, criam risco de inferência.

Um projeto de pesquisa de 2026, WHEREIS, é um fundo útil porque trata a geo-consistência de registro como um problema de medição, não um slogan. Os pesquisadores construíram uma maneira de comparar localização medida de prefixo com região do RIR e localização da organização registrada. Descobriram que a maioria dos prefixos era consistente no agregado, mas que a variação entre RIRs importa e a AFRINIC foi um estudo de caso. Também mostraram que inconsistências podem aparecer em bancos de dados de geolocalização comerciais e que questões estruturais, não meramente exaustão IPv4, moldam o problema.

Para o arrendamento, a lição não é que todo sinal fora da região prova violação. A lição é que a realidade operacional é mais difícil de inferir quando o registro, a rota e a história do cliente divergem.

Os contratos não devem terceirizar esse problema para fornecedores de geolocalização. Devem especificar quem é responsável pela correção de geolocalização, que reivindicações de país ou região podem ser feitas, que evidência o arrendatário pode enviar a bancos de dados e se o arrendador deve apoiar pedidos de correção. Se o serviço é vendido como conectividade africana, essa afirmação deve ser suportada por fatos operacionais reais. Se o serviço é hospedagem global usando espaço administrado pela AFRINIC, as partes não devem fingir o contrário entre si.

Geolocalização imprecisa pode quebrar licenciamento de conteúdo, controles de fraude, acesso bancário, localização fiscal, portais do setor público e análises de cliente. Essas perdas não devem ser deixadas para linguagem de indenização genérica.

As reivindicações de uso regional também exigem humildade. Uma categoria política pode não se mapear claramente na arquitetura de rede. Um serviço de entrega de conteúdo fora da África pode melhorar a experiência do usuário africano. Um serviço global de anti-abuso pode usar endereços em múltiplas regiões. Um cliente de nuvem pode ser incorporado em um país, servir usuários em outro e rotear através de um terceiro. Um registro pode focar onde os serviços se originam. Um cliente pode focar onde os usuários estão. Um banco de dados de geolocalização pode focar na latência.

O arrendamento não pode eliminar essas definições, mas pode evitar que as partes troquem de definições oportunisticamente.

É aqui que os acordos privados podem melhorar ou degradar a compreensão pública. Um arrendamento que registra geografia de implantação, categoria de cliente e responsabilidade de contato pode ajudar a explicar por que a localização medida difere da localização do titular registrado. Um arrendamento que esconde esses fatos faz a mesma diferença parecer evasão. Em uma região onde o uso fora da região foi litigado e politizado, a opacidade não é neutra. Torna-se evidência na história de outra pessoa.

O livro-razão público e o contrato privado devem se encontrar no controle

A escolha institucional mais importante no arrendamento IPv4 é se os contratos tornam a realidade operacional mais legível. Um arrendamento pode revelar a realidade documentando o titular, arrendatário, origem de rota, contatos técnicos, mesa de abuso, arranjos de DNS reverso, responsabilidades de RPKI, categorias de cliente, regras de subdelegação, fatos de uso regional e plano de rescisão. Pode enterrar a realidade nomeando apenas o titular, roteando através de intermediários, deixando contatos desatualizados, usando autorizações genéricas, escondendo subarrendamentos e tratando toda consulta como ato hostil.

Ambas as estruturas podem produzir tráfego. Apenas uma produz confiança.

A política de registro pode, involuntariamente, decidir qual estrutura prevalece. Se o registro fornece uma maneira segura de registrar delegação operacional sem tratar cada arrendamento como uma transferência proibida, partes responsáveis têm uma razão para ser francas. Se o registro trata a franqueza como um gatilho para revisão ampla do modelo de negócios, as partes divulgarão menos. O banco de dados então se torna menos preciso, e o registro pode citar a imprecisão como razão para mais controle. Esse ciclo não é único da AFRINIC, mas a crise da AFRINIC o torna visível.

O livro-razão público não precisa publicar todo termo comercial. Aluguel, margens, listas de clientes, depósitos, taxas de rescisão e estratégia de negócios podem permanecer privados. Mas certos fatos operacionais são fatos de infraestrutura. Quem pode originar o prefixo? Quem recebe relatórios de abuso? Quem pode alterar ROAs? Quem controla o DNS reverso? O titular registrado é também a rede operacional? Existe uma disputa conhecida? Existe um plano de impacto ao cliente se o reconhecimento mudar? Esses fatos afetam terceiros. Não são meros pontos de barganha privados.

Existem maneiras de respeitar a confidencialidade enquanto melhora a legibilidade. O arrendador pode fornecer uma declaração limitada de autorização operacional a upstreams e clientes. O arrendatário pode publicar contatos de abuso precisos. As partes podem manter registros de clientes disponíveis sob condições legais ou de registro definidas. Objetos técnicos podem identificar maintainers sem divulgar economia sensível. O status de disputa pode ser registrado sem declarar culpa. O arrendamento pode exigir respostas verdadeiras a operadoras, bancos, compradores públicos e consultas de registro.

O princípio de design é simples: esconda preços se necessário; não esconda o controle.

O acordo também deve preservar evidência versionada. Os arrendamentos IPv4 frequentemente duram tempo suficiente para que pessoal, política de roteamento, clientes, upstreams e prática de registro mudem. Uma carta de autorização emitida no início pode não explicar uma migração de AS posterior. Uma delegação de DNS reverso feita para uma classe de cliente pode não explicar um produto de hospedagem posterior. Uma correção de geolocalização enviada em um trimestre pode ser contradita por novo roteamento no próximo.

O arrendamento deve exigir um arquivo de evidência que evolua com a implantação: ASNs de origem atuais, contatos técnicos atuais, categorias de uso downstream atuais, migrações materiais de cliente, eventos significativos de abuso, correspondência de registro, alterações de ROA, alterações de IRR e avisos de rescisão. Isso não é burocracia por si só. É a memória que permite que as partes provem continuidade quando um upstream, tribunal, cliente ou registro pergunta por que a rota ainda merece confiança.

A legibilidade também é uma defesa contra o oportunismo entre as partes. Um arrendatário que mantém registros precisos não pode alegar facilmente depois que nunca soube de uma restrição de uso regional divulgada. Um arrendador que assina autoridade de rota específica não pode negar facilmente que a origem do arrendatário foi autorizada. Um cliente downstream que recebe termos de repasse não pode tratar facilmente o bloco como estoque de revenda se o serviço era apenas uma atribuição. O contrato, portanto, age menos como um muro contra estranhos e mais como uma base de fatos compartilhada.

Em um mercado onde a memória é fragmentada entre tickets, objetos WHOIS, coletores BGP, threads de email e faturas privadas, essa base de fatos tem valor econômico.

Essa distinção é crítica para a AFRINIC porque os argumentos públicos em torno do arrendamento se tornaram altamente carregados. Se o arrendamento é defendido através de alegações exageradas de que tribunais aprovaram todos os modelos comerciais, isso convida correção e desconfiança. Se o arrendamento é atacado como inerentemente ilegítimo apesar da demanda operacional real, isso leva o uso a formas menos visíveis. Uma melhor cultura contratual faria reivindicações modestas: este titular autoriza este operador para este uso, sob estes controles, com estes contatos, por este período, sujeito a estas restrições divulgadas.

Isso não é um manifesto político. É higiene de infraestrutura.

A tentação em um ambiente de registro conturbado é fazer contratos mais barulhentos. Um arrendador promete controle ininterrupto. Um arrendatário exige indenizações abrangentes. Um corretor garante a todos que o registro não importará. Os clientes recebem descrições de serviço polidas que omitem a diferença entre espaço transferido e arrendado. Nada disso reduz o risco. Apenas converte incerteza em futura violação.

Um arrendamento IPv4 viável relacionado à AFRINIC deve fazer o oposto. Deve reduzir a incerteza. Deve declarar exatamente o que o arrendador pode fornecer e o que não pode. Deve reconhecer que o registro permanece com o titular a menos que e até que uma transferência reconhecida ocorra. Deve definir os direitos operacionais do arrendatário sem fingir que esses direitos são propriedade. Deve alocar responsabilidades de rota, DNS reverso, RPKI, IRR, abuso, reputação, geolocalização, subarrendamento, uso regional e rescisão. Deve criar deveres de cooperação para eventos de registro.

Deve proteger os clientes através de aviso, cura e planejamento de migração quando possível. Deve reservar remédios de emergência para emergências reais.

Essa arquitetura beneficia tanto o arrendador quanto o arrendatário. Um arrendador com contratos claros pode mostrar que controla quem usa seu espaço, que o abuso é direcionado à mesa correta, que a delegação downstream é governada, que os fatos de uso regional são conhecidos e que os objetos técnicos correspondem à realidade operacional. Isso torna o arrendador menos vulnerável à acusação de que o arrendamento é indistinguível de abandono ou evasão. Também protege o valor do bloco reduzindo danos à reputação e saídas caóticas.

Beneficia o arrendatário porque converte uma dependência frágil em uma dependência gerenciada. O arrendatário ainda não possui a posição de registro. Ainda enfrenta risco se a AFRINIC, um tribunal, um upstream, um fornecedor de geolocalização ou um cliente contestar o acordo. Mas tem evidência, níveis de serviço, direitos de aviso e um plano. Para muitos operadores, isso pode ser suficiente para justificar o arrendamento durante a escassez de IPv4. Para outros, compra, endereços de provedor, transição para IPv6, CGNAT ou renumeração podem ser mais racionais. O trabalho do contrato não é forçar uma resposta. É tornar a troca visível.

Também beneficia o sistema de registro, se o sistema estiver disposto a aprender com ele. Um registro não pode satisfazer toda demanda operacional através de nova alocação. Pode não querer endossar toda transferência. Pode ter razões legítimas para se preocupar com vazamento regional, fraude, abuso e especulação. Mas suprimir o arrendamento responsável sem oferecer um caminho de delegação legível não elimina a demanda. Empurra a demanda para documentos privados, soluções de roteamento e registros incompletos. O resultado é menos visibilidade sobre a própria realidade operacional que o registro diz que deve entender.

O teste da AFRINIC é, portanto, economia institucional em miniatura. Escassez cria demanda. Política restringe transferência. Operadores buscam continuidade. Contratos privados preenchem a lacuna. A qualidade desses contratos decide se o arrendamento se torna uma forma disciplinada de delegação operacional ou um mercado de alocação sombra. O livro-razão do registro pode dizer quem é reconhecido. Não pode, por si só, decidir quem responde às 02:17 quando a interrupção do cliente começa. Essa resposta tem que ser escrita antes que o prefixo seja roteado.