Resumo

  • A transição de 2003–2005 transferiu objetos inetnum e aut-num, ASNs e espaço independente de provedor do banco de dados do RIPE para o da AFRINIC, encerrou os Contratos de Serviço Padrão com membros africanos e deixou a responsabilidade pela nova delegação de DNS reverso imediatamente a cargo da parte receptora.
  • O ICP-2 exige que um RIR mantenha procedimentos de continuidade, redundâncias e compartilhamento de registros, e prevê um processo de descredenciamento com entrega a um sucessor — mas nenhum instrumento localizado nesta pesquisa escreve um gatilho de custódia independente, portabilidade de registros de membros ou garantia contratual de continuidade de DNS reverso no próprio ato de transferência.
  • O teste real de continuidade não é institucional, e sim operacional: se WHOIS e RDAP da AFRINIC permanecem consultáveis e completos, se as delegações de DNS reverso dos recursos transferidos ainda resolvem e se os membros conseguem recuperar seus próprios registros. Nenhum desses pontos foi confirmado pelas fontes examinadas.

O que exatamente mudou de mãos

Entre outubro de 2003 e abril de 2005, operadores de rede na África obtinham recursos de numeração diretamente do APNIC, do ARIN ou do RIPE NCC. O RIPE NCC tratava de alocações e designações de IPv4 para países africanos ao norte do equador e, em abril de 2005, parou de alocar para a região africana (RIPE NCC). A AFRINIC foi constituída em Maurício em 2004, recebeu aprovação provisória do Conselho da ICANN em 30 de setembro de 2004 e foi reconhecida como o quinto Registro Regional da Internet em abril de 2005 sob os critérios do ICP-2; tornou-se o quinto membro do NRO em 27 de abril de 2005 (ICANN).

O que se seguiu foi menos um anúncio político e mais uma migração de banco de dados. O projeto AFRINIC-ERX transferiu objetos inetnum e aut-num — além de ASNs e espaço independente de provedor — do banco de dados do RIPE para o da AFRINIC, com todos os objetos referenciados transferidos ou copiados; a AFRINIC também herdou registros de registro do ARIN e do APNIC (RIPE NCC, NRO). O RIPE NCC encerrou os Contratos de Serviço Padrão com membros africanos e a AFRINIC celebrou novos contratos com eles; um acordo de confidencialidade cobrindo informações de LIRs foi assinado como parte da transição (RIPE NCC).

Um detalhe técnico importa mais do que a narrativa sugere. Onde recursos saíram do RIPE NCC para outro RIR, os objetos DOMAIN associados no banco de dados do RIPE foram apagados, e a responsabilidade por solicitar nova delegação de DNS reverso caiu imediatamente sobre a parte receptora (RIPE NCC, NRO). Em outras palavras: o ponteiro que permite a um bloco de endereços ser resolvido de volta para um nome não foi objeto de um período de sobreposição obrigatório. Ele foi simplesmente entregue junto com o recurso.

Quatro pontos de controle

A pergunta de quem controla prevenção, detecção, resposta e reparação pode ser respondida ponto por ponto, e nenhuma das respostas depende de confiança institucional.

Prevenção. O desenho da transferência definiu quais dados permaneceriam no RIPE NCC e quais migrariam. O que migrou — objetos de registro, ASNs, espaço PI e a relação contratual com o membro — passou a ter uma única cópia autoritativa, na AFRINIC. O que ficou para trás foi o objeto DOMAIN, que foi excluído, não espelhado.

Detecção. O instrumento que hoje mais se aproxima de uma supervisão multilateral sobre um RIR é o ICP-2. Ele exige que um RIR mantenha procedimentos de continuidade, redundâncias e compartilhamento de registros para que outro RIR possa executar seus serviços se necessário, e que mantenha registros auditáveis (ICANN, RIPE NCC). É um requisito sobre o comportamento do RIR, não um mecanismo de observação independente com direito de acesso.

Resposta. O ICP-2 prevê descredenciamento e um processo de handoff no qual o RIR descredenciado deve cooperar com a ICANN e os demais RIRs para transferir operações a um sucessor ou entidade interina designada (ICANN, RIPE NCC). Note a direção do dever: a cooperação é exigida do RIR que perde o reconhecimento. Se ele estiver sob controle de terceiros, esse dever recai sobre quem controla a entidade, não sobre quem detém os dados.

Reparação. O ICP-2 registra que propostas de reconhecimento ou descredenciamento se originam do Conselho Executivo do NRO após voto de maioria, com a ICANN mantendo autoridade final; a IANA, administrada pela ICANN, detém responsabilidade última pelo espaço IPv4, IPv6 e de ASN alocado e não alocado e delega blocos aos RIRs (ICANN). Há ainda, pela seção 9 do Memorando de Entendimento do NRO, um Painel Consultivo de Apelações para queixas de que um RIR, o NRO ou uma suborganização não seguiu processos documentados de desenvolvimento de políticas globais. Esse painel julga processo de política, não custódia de dados de registro nem failover (ICANN).

O que o ICP-2 promete e o que ele não cria

A leitura da documentação disponível sustenta uma conclusão restrita e verificável: nenhum instrumento público localizado nesta pesquisa inscreve, no próprio ato de transferência de 2004–2005, uma custódia acionável de forma independente, uma garantia de continuidade de DNS reverso ou um direito de portabilidade dos registros de membros (ICANN, RIPE NCC, NRO). As obrigações de continuidade aparecem como exigências gerais do ICP-2 sobre o RIR receptor — e é precisamente esse RIR, hoje sob controle de um administrador judicial, que passou a ser objeto dessas exigências, não o seu executor.

Isso não é o mesmo que afirmar que não exista remédio. É afirmar que o remédio depende de uma decisão coletiva de reconhecimento ou descredenciamento, tomada em outro foro, sob outro calendário, e que pressupõe cooperação da parte cujo controle está em disputa.

Vinte anos depois: auditoria, litígio e tutela

A AFRINIC e a Cloud Innovation Ltd litigam desde cerca de meados de 2019. Em 19 de julho de 2022, a Suprema Corte de Maurício decidiu a favor da Cloud Innovation, afastando a objeção preliminar da AFRINIC. A AFRINIC foi colocada sob administração judicial; em 15 de outubro de 2024, a Corte de Apelação Cível ouviu recurso sobre a ordem de administração. Em 10 de fevereiro de 2025, a Divisão de Falências encerrou a nomeação do administrador oficial inicial e nomeou o Sr. Gowtamsingh Dabee, estendendo o prazo para a eleição do conselho até 25 de abril de 2025 (ICANN, AFRINIC).

Em 6 de junho de 2025, a ICANN escreveu ao administrador judicial exigindo transparência e equidade na eleição do conselho da AFRINIC; em 19 de junho de 2025, apresentou pedido à Suprema Corte de Maurício; obteve ordem para que o administrador emitisse comunicado aos membros sobre um registro errôneo; e, em 25 de junho de 2025, escreveu novamente alertando para uma possível revisão de conformidade por conduta fraudulenta alegada. A eleição foi suspensa em 23 de junho de 2025 e realizada afinal de 10 a 12 de setembro de 2025 (ICANN, AFRINIC).

Em 25 de julho de 2025, o Presidente de Maurício declarou a AFRINIC "declared company" sob a seção 230 da Lei de Sociedades, após petição de liquidação apresentada pela Cloud Innovation Ltd; a declaração suspende processos judiciais existentes envolvendo a AFRINIC e aciona investigação encomendada pelo governo sobre seus negócios (ICANN, AFRINIC).

Antes disso, uma auditoria encomendada em julho de 2019 e tornada pública por volta de janeiro de 2021 encontrou 2.371.584 endereços IPv4 do pool livre da AFRINIC apropriados indevidamente. Cerca de 1.060.864 foram recuperados e colocados em quarentena por 12 meses; 1.310.720 vinculados a duas organizações permaneciam pendentes de recuperação. Outros 1.799.168 endereços IPv4 legados estavam comprometidos: 394.496 consolidados, alterações não substanciadas em 467.968 revertidas e 936.704 em disputa. As medidas corretivas incluíram camadas adicionais de verificação (ICANN, AFRINIC).

O teste operacional que ninguém publicou

Se a continuidade depende da instituição e não do registro, o modo de verificar isso não é jurídico. É medir quatro coisas: se o WHOIS e o RDAP da AFRINIC permanecem consultáveis e completos; se as delegações de DNS reverso dos recursos transferidos ainda resolvem; se os membros conseguem obter seus próprios registros; e se o RIPE NCC reteve algum papel de fallback. Nenhuma dessas condições foi confirmada pelas fontes examinadas nesta pesquisa (NRO, RIPE NCC, RIPE NCC).

O contraste é instrutivo. Uma transferência desenhada para a falha institucional teria custódia dos dados, delegações pré-configuradas para failover e registros de membros portáveis. Uma transferência desenhada para a solvência do receptor tem apenas um novo titular — e, quando o titular entra em crise, a falha institucional se converte automaticamente em evento de continuidade do registro. Foi esse o desenho adotado, e é esse o risco que segue aberto. Registro relacionado: entity:ripe-ncc-to-afrinic-transition.