O que as subalocações da AFRINIC deixam abaixo do registro público

O ticket de abuso parecia comum até que todos tentassem nomear a parte responsável. Um ISP regional havia recebido reclamações sobre tráfego de preenchimento de credenciais de um pequeno /27 usado por um de seus clientes comerciais. O titular registrado do bloco IPv4 pai estava visível no registro da AFRINIC. O AS de origem estava visível no BGP. Um revendedor estava em algum lugar na cadeia comercial. Um provedor de firewall gerenciado lidava com o dispositivo de borda.

O cliente cujos servidores estavam gerando o tráfego queria privacidade, em parte porque as máquinas podem ter sido comprometidas e em parte porque não queria que seus acordos de hospedagem fossem expostos a concorrentes. O upstream queria responsabilidade. O banco que registrou a reclamação queria uma pessoa que pudesse parar o ataque. O livro contábil do registro nomeava o titular, não o pequeno usuário operacional.

Essa lacuna é o assunto da visibilidade de subalocação. A palavra "subalocação" tem um significado formal na política da AFRINIC: um LIR pode distribuir espaço para ISPs downstream para distribuição subsequente, sujeito a regras de tamanho, documentação e registro. O problema econômico é mais amplo do que o rótulo formal. O escasso IPv4 agora é usado através de titulares, LIRs, ISPs downstream, revendedores, provedores de hospedagem, fornecedores de serviços gerenciados, plataformas em nuvem, corretores, acordos de locação, clientes empresariais e, às vezes, usuários delegados adicionais. Parte desse uso é legítimo e comum.

Parte é sensível à privacidade. Parte é comercialmente confidencial. Parte é onde realmente surgem abusos, fraudes, triagem de sanções, solicitações de aplicação da lei, erros de geolocalização, erros de roteamento e danos à reputação.

O registro público muitas vezes vê apenas a primeira camada. A internet opera através de muitas mais camadas. Um prefixo pode ser registrado para uma parte, originado por outra, delegado em DNS reverso a uma terceira, listado em um objeto IRR mantido pelo contato de um corretor, coberto por um ROA criado pelo titular formal e usado por clientes cujos nomes nunca aparecem no RDAP ou WHOIS. Nada disso é automaticamente suspeito. A divisão do trabalho é normal nas operações de rede. O problema começa quando cada pessoa de fora deve arcar com o custo de descobrir o operador responsável depois que algo já deu errado.

A AFRINIC é um caso de teste útil porque a camada downstream já está incorporada nas regras operacionais com as quais as redes devem conviver, enquanto sua história institucional recente mostra por que a visibilidade abaixo do titular é importante. O African Network Information Centre (AFRINIC) atende a África e parte do Oceano Índico como o registro regional de internet. Ele se baseia nos serviços que transformam o uso de recursos em evidências públicas: WHOIS, RDAP, DNS reverso, um Registro de Roteamento da Internet e RPKI.

As regras operacionais relevantes exigem que alocações, atribuições e subalocações sejam registradas no banco de dados da AFRINIC, e que os dados de registro, como nomes, blocos, contatos e status, permaneçam corretos. Elas também vinculam a delegação reversa a atribuições ou subalocações registradas. Essas regras não são ornamentais. Elas são os pontos estreitos onde a realidade operacional downstream deve se tornar legível.

A pressão sobre esses pontos aumentou. A AFRINIC entrou na Fase 2 do Soft Landing IPv4 em 13 de janeiro de 2020, com os tamanhos normais de novas alocações e atribuições IPv4 restritos a blocos pequenos, incluindo um mínimo de /24 e máximo de /22.

Reportagens públicas descreveram alegações de manipulação de registros de endereços envolvendo espaço IPv4 africano inativo, a disputa de alto valor entre a AFRINIC e a Cloud Innovation sobre uso e comercialização de recursos, um congelamento judicial dos fundos da AFRINIC em 2021, administração judicial a partir de 2023, descontinuidade do conselho e eleições, uma tentativa de eleição anulada em 2025, posterior restauração do conselho e questões contínuas de recuperação em 2026. Esses eventos não devem ser transformados em uma história genérica de moralidade de governança.

Para a visibilidade de subalocação, sua importância é mais restrita: quando o próprio registro está sob estresse, os mercados dependem ainda mais de evidências claras de quem está usando endereços escassos, quem pode ser contatado e qual incerteza é real em vez de boato.

A pergunta certa não é se cada cliente deve ser nomeado publicamente. Isso seria perigoso e economicamente tolo. A pergunta certa é quanto detalhe downstream deve ser visível, para quem, em que nível de certeza e com que efeito sobre o custo do roteamento, resposta a abusos, transferências, locação, compras públicas e responsabilidade do registro. Um livro contábil público não é uma lista de clientes privada. Mas se expõe apenas o titular formal enquanto o usuário prático está a três contratos de distância, deixa o mercado precificar a opacidade.

O cliente invisível é agora o fato caro

Na era da abundância, um cliente downstream oculto era muitas vezes um incômodo, não um problema de precificação. Se o abuso viesse de uma sub-rede de cliente, o provedor poderia rastreá-lo dentro de seus próprios sistemas. Se um contato estivesse desatualizado, outra alocação poderia estar disponível. Se um pequeno intervalo estivesse mal configurado, a renumeração era dolorosa, mas não um evento de capital. A escassez de IPv4 mudou essa aritmética.

Um pequeno bloco pode suportar receita de hospedagem, infraestrutura de pagamento, portais governamentais, clientes SaaS, acesso VPN, sistemas antifraude, reputação de e-mail e continuidade de rede. O cliente por trás do endereço não é mais apenas um detalhe operacional. É uma fonte de risco, valor e responsabilidade.

A opacidade tem um caminho econômico mensurável. Aumenta o custo de busca, porque um reclamante, upstream, comprador, banco, segurador ou investigador deve gastar tempo determinando se o titular listado, AS de origem, revendedor, provedor de serviços gerenciados ou cliente final pode resolver o problema. Aumenta o custo do erro, porque, se o /27 responsável não puder ser identificado rapidamente, as contrapartes bloqueiam um /24, /22 ou toda a reputação do titular.

Aumenta o custo de contratação, porque clientes e contrapartes exigem garantias, indenizações, garantias, contatos de emergência, créditos de serviço e diligência extra quando o registro público não lhes diz o suficiente. Aumenta o custo de capital, porque um credor ou comprador desconta a receita vinculada a endereços cuja responsabilidade operacional não pode ser reconstruída independentemente.

O cliente invisível também muda os incentivos dentro da cadeia. Um titular que pode cobrar receita enquanto deixa o usuário downstream não registrado pode subinvestir em resposta a abusos e verificação de clientes. Um revendedor que pode passar a responsabilidade para cima pode vender para clientes mais arriscados. Um provedor gerenciado que não aparece no registro pode evitar danos à reputação quando sua configuração falha. Um cliente que não pode ser nomeado publicamente por razões legítimas de privacidade ainda pode precisar fornecer responsabilidade autenticada ao titular, ao registro ou a um solicitante legal sob condições definidas.

Se ninguém sabe qual camada tem qual dever, todos têm um incentivo para manter a parte lucrativa visível e a parte arriscada privada.

A linguagem política da AFRINIC aponta para a distinção correta. Subalocações e atribuições devem ser registradas porque unicidade, solução de problemas e continuidade exigem mais do que o nome do titular. Ao mesmo tempo, o manual não exige um dossiê público sobre cada usuário downstream. O meio-termo útil é a visibilidade de responsabilidade: informações públicas e autenticadas suficientes para identificar a camada operacional responsável, sem expor toda a identidade do cliente para toda a internet.

O custo de errar isso é maior para redes menores. Grandes plataformas podem construir canais de confiança privados com grandes bancos, provedores de trânsito, fornecedores de segurança e autoridades públicas. Pequenos ISPs e empresas de hospedagem regionais não podem. Eles dependem de registros públicos e semipúblicos para serem acreditados por estranhos. Se a evidência pública é fraca, eles pagam através de atrasos, filtragem mais rigorosa, clientes perdidos e poder de barganha mais fraco. A opacidade da subalocação torna-se, portanto, um imposto regressivo sobre as redes menos capazes de absorvê-lo.

A camada downstream já faz parte da economia de alocação

O manual de políticas da AFRINIC não descreve a distribuição de endereços como uma transação de uma etapa entre registro e usuário final. Ele define uma hierarquia. Um LIR recebe alocações de um registro regional e atribui espaço de endereço principalmente a usuários finais. Uma subalocação é a distribuição por um LIR a um ISP para distribuição subsequente. Uma atribuição é um bloco dado por um LIR a um ISP ou usuário final para uso específico dentro da infraestrutura que essa parte opera.

O espaço agregável pelo provedor pode ser atribuído ou subalocado para redes downstream como espaço não portátil, enquanto as atribuições independentes do provedor não são para subalocação adicional. Este já é um sistema em camadas.

O manual então atribui responsabilidades a essa estratificação. Ele diz que toda alocação, atribuição PI, atribuição PA, subalocação e outra atribuição de recurso deve ser registrada no banco de dados da AFRINIC, e que recursos não registrados serão considerados inválidos. Exige que os dados de registro estejam corretos em todos os momentos. Define a subalocação formal mínima de IPv4 em /24. Exige que os LIRs façam subalocações dentro de suas janelas de subalocação ou busquem aprovação da AFRINIC acima dessas janelas.

Torna os LIRs responsáveis por garantir que o espaço alocado a eles e subsequentemente subalocado seja usado de acordo com as políticas e diretrizes da comunidade. Aconselha início lento para ISPs downstream. Trata o espaço do ISP downstream como não portátil dentro do bloco agregável do LIR.

Essas regras revelam a lógica institucional. A AFRINIC não precisa conhecer todos os pacotes dos usuários, mas não pode permanecer indiferente à estrutura downstream. Se um ISP downstream recebe um /24, o banco de dados do registro não deve permanecer cego. Se o espaço de endereço público de um usuário final não é meramente infraestrutura ponto a ponto, o manual diz que deve ser registrado com contatos do usuário final, com uma acomodação de privacidade para indivíduos. Se o DNS reverso for solicitado para um /24, o manual diz que pelo menos uma atribuição ou subalocação deve ser registrada para esse /24 específico.

Os próprios serviços de registro assumem fatos downstream registrados.

A dificuldade moderna é que a realidade comercial cria camadas que nem sempre correspondem às categorias antigas. Uma empresa de hospedagem pode atribuir /29s, /28s ou /27s dentro de um /24 registrado. Um provedor de firewall pode operar dispositivos de segurança para muitos clientes dentro do agregado de um provedor. Um revendedor pode vender servidores privados virtuais sem receber uma subalocação formal de /24. Um corretor pode ajudar a organizar o uso sem aparecer como operador técnico. Uma plataforma de locação pode coordenar o acesso do cliente enquanto o titular registrado permanece inalterado.

Um provedor de serviços gerenciados pode controlar a remediação de abusos, mas não a origem da rota. A camada downstream é mais granular do que a unidade de política.

Esse descompasso não deve levar a duas respostas ruins. A primeira é fingir que o registro público pode ignorar tudo abaixo do titular registrado. Isso torna a solução de problemas, resposta a abusos, diligência e aplicação da lei muito caras. A segunda é exigir que cada pequeno intervalo de cliente e cada nome de cliente sejam públicos. Isso cria danos à privacidade e segurança e pode levar operadores legítimos a acordos privados que revelam menos, não mais.

Uma resposta melhor começa com a visibilidade funcional. O registro deve distinguir espaço operado pelo titular de atribuição de cliente, subalocação de ISP downstream, espaço gerenciado por revendedor, operação de serviço gerenciado, operação apoiada por locação, uso de usuário final com privacidade protegida e status disputado ou desatualizado. Não precisa publicar sempre o nome legal do cliente. Deve publicar o suficiente para mostrar qual camada é responsável pela resposta operacional e quanto peso se atribui a essa declaração. O titular permanece responsável pelo relacionamento com o registro.

O operador downstream torna-se localizável para questões operacionais. O cliente pode permanecer protegido quando a lei, a segurança ou a confidencialidade comercial o justificarem.

Essa lógica de registro já suporta um mapa de responsabilidade. O registro existe para garantir unicidade e fornecer informações para solução de problemas. Em um mercado de escassez de IPv4, a solução de problemas agora inclui acessibilidade de abusos, explicação da origem da rota, consistência do DNS reverso, evidência de subdelegação, diligência de transferência, compras do setor público e a capacidade de estranhos distinguirem um cliente oculto de um registro abandonado.

Um livro contábil público não é uma lista de clientes privada

A fronteira institucional é simples de afirmar e difícil de implementar. Um livro contábil de registro público não deve se tornar uma lista de clientes. Deve se tornar um mapa de responsabilidade. A distinção importa. Uma lista de clientes divulga quem compra serviços de quem. Um mapa de responsabilidade divulga qual função é responsável por um segmento de recurso, qual canal de contato está ativo, que evidências suportam a função e quanta confiança os estranhos devem atribuir a ele.

Para usuários públicos, o registro mínimo útil não é a identidade completa do cliente. É a função e a acessibilidade. Um registro público pode mostrar que um /24 é operado pelo titular, atribuído a uma organização, subalocado a um ISP downstream, usado através de um serviço gerenciado, delegado a um usuário final com privacidade protegida, arrendado ou delegado comercialmente sob responsabilidade do titular, ou sujeito a confirmação disputada ou desatualizada. Pode publicar contatos de função: contato do titular, contato técnico, contato de abuso, contato de roteamento e contato de DNS reverso.

Pode expor timestamps: primeiro registro, última validação, última atualização material e expiração da validação. Pode mostrar se a função downstream foi autodeclarada pelo titular, validada pela AFRINIC, inferida de evidências de roteamento, confirmada por delegação de DNS reverso ou redigida por privacidade.

Para contrapartes autenticadas, mais detalhes podem ser apropriados. Um provedor de trânsito avaliando uma rota, um comprador realizando diligência de transferência, um registro lidando com uma revisão ou um órgão público com uma solicitação legal pode precisar da identidade legal do operador downstream, uma carta de autorização, evidências de contrato, contatos de emergência, geografia operacional, categoria do cliente, janelas de tempo de escalação e prova de que o titular pode compelir a cooperação. Esses detalhes não precisam ser legíveis por todos.

Podem ser mantidos pelo titular, depositados no registro de forma limitada, compartilhados sob confidencialidade ou divulgados por ordem judicial ou demanda legal.

Para tribunais e aplicação da lei, o limite deve ser maior, mas a informação mais profunda. Onde uma solicitação legal busca a identidade por trás de uma atribuição com privacidade protegida, o sistema não deve exigir que os investigadores adivinhem através de cinco intermediários. O titular deve ser capaz de rastrear a cadeia. O registro deve saber se o titular afirma tal rastreabilidade. O registro público deve mostrar que um usuário downstream com privacidade protegida existe e que a escalação legal tem um caminho definido, não que o cliente é invisível para todos.

Rótulos de evidência são essenciais, mas devem ser usados com moderação e clareza. O mesmo fato visível tem valor diferente dependendo de como foi obtido. Um ISP downstream atestado pelo titular não é o mesmo que um validado pelo registro. Uma origem observada por roteamento não é o mesmo que um usuário operacional registrado. Uma delegação de DNS reverso não é prova de responsabilidade por abuso. Um usuário com privacidade redigida não é o mesmo que um usuário desconhecido. Um registro atualizado no mês passado não é o mesmo que um tocado pela última vez em 2014.

Um registro que expõe essas diferenças reduz o custo de interpretação sem fingir saber mais do que sabe.

A mesma estrutura protege o registro do excesso. Ao publicar função, contatabilidade, status de evidência e incerteza, a AFRINIC pode melhorar a confiança pública sem afirmar um direito de inspecionar cada cliente para conformidade política. Pode dizer: este é o titular reconhecido; este bloco é operado downstream; o canal operacional responsável está aqui; a identidade legal é omitida da visão pública, mas rastreável sob condições definidas; a data da última validação é atual ou desatualizada. Tal livro contábil é mais fino que um banco de dados de clientes e mais grosso que um registro de titular simples.

Esse é o meio-termo economicamente útil.

A escassez de IPv4 transforma a opacidade em um desconto de mercado

A opacidade da subalocação não é apenas um problema de segurança. É um desconto de mercado. Quando um recurso escasso não pode ser rastreado do titular até a responsabilidade operacional real, cada contraparte precifica a lacuna. O comprador de um bloco quer saber se usuários downstream não divulgados resistirão à migração. O locatário quer saber se o locador pode suportar alterações de rota, DNS reverso e abuso através de cada revendedor intermediário. O banco quer saber se a receita apoiada por endereços depende de clientes cujos contratos não podem ser verificados.

O comprador público quer saber se um serviço crítico está em endereços cuja cadeia de autoridade é ambígua. O upstream quer saber se pode aceitar a rota sem se tornar a primeira parte acessível para cada reclamação.

Os fatos de escassez da AFRINIC tornam o desconto concreto. Seu aviso de exaustão dizia que a Fase 2 começou quando não mais que um /11 de espaço não reservado permanecia no último /8. Na Fase 2, o intervalo normal de alocação ou atribuição é pequeno, com um mínimo de /24 e máximo de /22. Tais limites não eliminam a demanda; eles movem a demanda para reutilização, transferências, locação, oferta de hospedagem, reatribuição de clientes e delegação operacional. Quanto mais a demanda se move através de titulares existentes, mais importante se torna saber o que está acontecendo abaixo desses titulares.

A opacidade também torna os registros antigos mais perigosos. O KrebsOnSecurity relatou em 2019 sobre alegações de que valioso espaço IPv4 africano associado a organizações inativas ou extintas foi desviado ou vendido através de empresas ligadas a uma ex-figura sênior da AFRINIC; o pesquisador Ron Guilmette estimou o espaço afetado em mais de US$ 50 milhões em valor de mercado. O significado para a visibilidade de subalocação não é apenas a suposta corrupção. É que registros inativos e trilhas de autoridade fracas se tornam valiosos quando o IPv4 tem um preço.

Um registro que não revela claramente quem pode falar pelo uso downstream convida tanto à fraude quanto ao desconto defensivo.

A disputa da Cloud Innovation mostra a borda oposta do mesmo problema. Análises públicas descreveram um conflito sobre milhões de endereços IPv4, locação comercial, uso real comparado com uso registrado ou esperado e a capacidade reivindicada da AFRINIC de revisar ou encerrar o reconhecimento de recursos. A Cloud Innovation contestou a teoria da AFRINIC e o litígio escalou. Para a visibilidade de subalocação, a lição não é que cada locação é ruim ou que cada consulta de registro é legítima.

A lição é que quando o uso downstream real é opaco, o registro pode ser tentado a pedir informações amplas do cliente, enquanto o titular pode resistir alegando privacidade comercial. Ambos os lados podem estar parcialmente certos e ainda assim produzir um equilíbrio ruim.

Em um bom equilíbrio, os titulares revelam responsabilidade estruturada sem entregar listas brutas de clientes. Em um equilíbrio ruim, eles revelam pouco, o registro exige demais, o litígio começa e o mercado desconta todo o portfólio. O IPv4 escasso torna esse desconto grande o suficiente para mudar o comportamento. Um titular com baixa visibilidade downstream enfrenta menor confiança do comprador, maior custo legal, pior reputação após abuso e menor aceitação no setor público. Um registro com baixa visibilidade enfrenta pressão para usar revisões amplas porque evidências mais restritas não estão disponíveis.

A ausência de visibilidade cria assim o argumento para a discrição.

O alvo econômico deve ser tornar o uso responsável mais barato que o uso oculto. Um titular que mantém registros de função downstream validados, contatos ativos, clientes com privacidade protegida rastreáveis e rótulos de incerteza claros deve enfrentar menor atrito em transações e incidentes. Um titular que não pode explicar quem está usando seu espaço deve pagar através de descontos, aprovações mais lentas e escrutínio mais rigoroso. Isso não é punição. É precificar a qualidade da informação.

A pilha de evidências é plural, e cada superfície tem limites

Nenhuma fonte de dados única pode responder à pergunta de responsabilidade downstream. RDAP e WHOIS fornecem dados do titular registrado e contatos. BGP mostra qual sistema autônomo origina uma rota. Objetos IRR expressam política de roteamento e convenções de autorização de rota. RPKI e ROAs podem validar autoridade de origem. DNS reverso pode revelar padrões de nomenclatura, delegações de clientes e histórico operacional. Bancos de dados de geolocalização, traceroute, latência, certificados TLS, históricos de abuso, zonas DNS, reputação de e-mail, banners de hospedagem, registros corporativos e contratos de clientes podem adicionar pistas.

Nenhum é conclusivo por si só.

Essa pilha plural de evidências é útil e perigosa. É útil porque a responsabilidade downstream muitas vezes aparece apenas quando os sinais são combinados. Um /24 registrado a um titular, originado por um ASN de hospedagem, coberto por um ROA para esse ASN, nomeado com um padrão de DNS reverso de revendedor, listado em um objeto IRR mantido por terceiros e carregando histórico de abuso vinculado a clientes VPS provavelmente não é operado pelo titular no sentido simples. Mas é perigoso porque a inferência pode ultrapassar a prova. Um rótulo de DNS reverso pode estar desatualizado. Um objeto IRR pode ser não autorizado.

Um banco de dados de geolocalização pode estar errado. Um ROA pode provar autoridade de origem de rota, não identidade do cliente. Um AS de origem pode ser um operador de trânsito ou serviço gerenciado, não o usuário final.

Os serviços públicos da AFRINIC estão espalhados por grande parte dessa pilha. O registro fornece WHOIS, RDAP, DNS reverso, IRR e serviços relacionados ao RPKI. Seu manual de políticas conecta a delegação reversa a atribuições ou subalocações registradas. Sua política de contato de abuso cria um lugar para informações de abuso, embora reconheça que o objeto, como outros objetos, enfrenta o problema de precisão dos dados. A franqueza importa. Um campo pode criar um canal sem provar que o canal está correto. Um ROA pode autorizar uma origem sem provar o cliente downstream.

Uma atribuição pode identificar um intervalo de usuário final sem provar todos os detalhes operacionais posteriores.

O registro público deve, portanto, expor o tipo de evidência. Uma função downstream pode ser registrada, atestada pelo titular, validada pelo registro, observada por roteamento, consistente com DNS reverso, depositada em contrato, rastreável por escalação legal, desatualizada, disputada ou redigida por privacidade. Esses rótulos podem soar burocráticos se usados em excesso. Usados corretamente, são economicamente valiosos. Eles impedem que um sinal fraco seja tratado como um sinal forte e que a ausência de identidade pública seja tratada como ausência de responsabilidade.

Rótulos de evidência também reduzem o incentivo para mitologia privada. Em mercados opacos, corretores e contrapartes preenchem lacunas com alegações: bloco limpo, apoiado por tribunal, primeira parte, compatível com a África, sem abuso, totalmente autorizado, seguro para uso público. Algumas alegações podem ser verdadeiras. Outras podem ser marketing. Um registro que expõe evidências estruturadas dá a compradores e operadores uma maneira de testar alegações sem transformar a AFRINIC em um árbitro comercial. O registro pode dizer o que validou e o que não validou. O mercado pode precificar o resto.

Isso é especialmente importante sob estresse institucional. Durante administração judicial, disputas eleitorais ou litígios, rumores tornam-se substitutos de registros. Se o banco de dados público não pode distinguir operação downstream comum de delegação contestada, ou proteção de privacidade de uso desconhecido, as contrapartes inferirão a partir de manchetes. Um rótulo de evidência fino pode evitar uma reação exagerada cara. O registro não precisa garantir todos os fatos downstream. Precisa divulgar o status dos fatos que carrega.

A pilha de evidências deve ser lida como um mapa de probabilidade. Quanto mais forte a combinação de subalocação registrada, contato validado, origem de rota correspondente, ROA atual, DNS reverso coerente e confirmação recente, menor o imposto de ambiguidade. Quanto mais fraca a combinação, mais cautela é justificada. É assim que os mercados já se comportam informalmente. A AFRINIC pode melhorar o mercado tornando o mapa de probabilidade informal mais explícito.

A acessibilidade de abuso é uma consequência, não toda a história

As reclamações de abuso são muitas vezes onde a opacidade da subalocação se torna visível. Um banco vê ataques. Um fornecedor de segurança vê retornos de malware. Um operador de e-mail vê spam. Um reclamante de direitos autorais vê hospedagem. Um órgão público vê varredura contra um serviço governamental. O reclamante consulta o registro e envia e-mail para o contato listado. Se o titular listado não é o operador real, o ticket começa a se mover lateralmente: titular para revendedor, revendedor para provedor de hospedagem, provedor de hospedagem para fornecedor de firewall gerenciado, fornecedor para cliente.

Cada salto adiciona atraso e erro.

É tentador fazer do contato de abuso todo o assunto. Isso seria muito restrito. A acessibilidade de abuso é um produto da visibilidade downstream, não a economia completa. A mesma visibilidade afeta a aceitação de roteamento, diligência de transação, continuidade do cliente, compras públicas, triagem de sanções, resposta da aplicação da lei, geolocalização, DNS reverso, manutenção de RPKI e gerenciamento de reputação. Um ticket de abuso é simplesmente o momento em que a estrutura oculta se torna cara o suficiente para ser notada.

A política de contato de abuso da AFRINIC é uma evidência útil desse papel limitado. Ela especifica um objeto dedicado como o lugar preferido para publicar informações de contato de abuso públicas, referenciado em objetos inetnum, inet6num e aut-num. Visa ajudar relatórios de abuso a alcançar o contato de rede correto. Também reconhece uma desvantagem: o objeto enfrenta o mesmo problema de precisão de dados que outros objetos e não melhora por si só a precisão do banco de dados. Esse é exatamente o ponto.

Uma caixa de correio não resolve a opacidade downstream se a caixa de correio pertence à camada errada ou se o titular não pode compelir o operador downstream a agir.

Uma estrutura melhor vincula a acessibilidade de abuso à visibilidade de função. Se um bloco é operado pelo titular, o abuso do titular deve ser o canal público principal. Se é subalocado a um ISP downstream, o canal de abuso validado do ISP downstream deve ser visível, com escalação do titular preservada. Se é atribuído a um cliente empresarial cuja identidade é protegida por privacidade, o registro público deve publicar uma mesa operacional responsável ou proxy mais um caminho de escalação legal. Se é gerenciado por um provedor de firewall ou hospedagem, o registro público deve mostrar qual camada operacional recebe o abuso primeiro.

Se a responsabilidade é disputada ou desatualizada, o registro deve dizer isso.

Isso evita duas falhas comuns. A primeira é o problema da mesa errada, onde as reclamações alcançam o titular legal, mas não o operador capaz de remediar. A segunda é o problema do cliente não responsável, onde o titular alega privacidade ou distância de revendedor e nenhuma parte alcançável age. Em ambos os casos, o custo é transferido para terceiros. Bancos bloqueiam demais. Upstreams ameaçam suspensão. Serviços de reputação marcam espaço vizinho. A aplicação da lei escala por canais mais lentos. Usuários inocentes compartilham a penalidade.

A visibilidade de abuso também protege os titulares. Um titular que pode mostrar responsabilidade downstream validada pode restringir sua própria exposição. Pode dizer a um reclamante: este intervalo é operado por esta função downstream; aqui está o canal de abuso; o titular permanece disponível para escalação se a mesa downstream falhar. Isso é melhor do que receber todos os tickets, perder alguns e ser tratado como negligente. Também é melhor do que publicar identidades brutas de clientes de uma forma que crie riscos de privacidade ou segurança.

A economia, portanto, não é sobre fazer cada titular administrar um grande departamento de abuso. É sobre tornar o caminho para a responsabilidade curto o suficiente para que os custos fixos de incidentes não recaiam sobre estranhos aleatórios. A visibilidade de subalocação é a infraestrutura mais ampla que faz a política de contato de abuso funcionar.

A redação responsável é o acordo de privacidade

A objeção mais forte à visibilidade downstream é a privacidade. Ela merece ser levada a sério. Um registro público que nomeia todos os clientes downstream poderia expor organizações vulneráveis, operações de segurança, infraestrutura de denunciantes, grupos políticos, contratados do setor público, instituições financeiras, provedores de saúde e empresas comuns. Também poderia transformar o registro em uma ferramenta de reconhecimento. Atacantes poderiam mapear clientes, inferir relacionamentos de compra, identificar fornecedores de segurança gerenciada, mirar janelas de migração ou pressionar provedores de serviços.

Concorrentes comerciais poderiam aprender quem hospeda quem. Uma política de visibilidade que ignora esses danos se derrotaria.

Mas a privacidade não justifica a opacidade completa. A internet já impõe externalidades a estranhos. Pacotes de um intervalo podem atacar um banco, escanear um hospital, hospedar páginas de phishing, poluir a reputação de e-mail, desencadear revisão de sanções ou afetar um serviço público. Se a parte responsável está escondida atrás de linguagem de privacidade e nenhum canal rastreável existe, a privacidade torna-se uma forma de exportar custo. O problema de design é preservar a confidencialidade enquanto preserva a responsabilidade.

A resposta prática é a divulgação em camadas. Os registros públicos devem carregar função, contatabilidade, status, data de validação e força da evidência. Não devem necessariamente publicar todos os nomes legais de clientes. Contrapartes autenticadas podem receber mais detalhes sob contrato ou necessidade operacional. O registro pode manter ou verificar evidências limitadas sem divulgá-las publicamente. A aplicação da lei e tribunais podem obter informações de identidade mais profundas através de demanda legal. Canais de emergência podem existir para danos iminentes sem tornar a divulgação de emergência rotineira.

Indivíduos podem receber redação mais forte do que ISPs downstream corporativos. Agências públicas podem usar contatos de segurança designados em vez de expor todos os contratados.

A redação deve ser rotulada, não silenciosa. "Identidade do cliente omitida por privacidade; titular mantém contato rastreável; proxy de abuso validado" é economicamente diferente de "nenhuma informação downstream". Diz a estranhos que existe uma estrutura responsável mesmo que o nome não seja público. Também cria responsabilidade para o titular: se o titular alega rastreabilidade protegida por privacidade, deve ser capaz de rastrear. Falha em rastrear sob condições definidas deve ter consequências, porque senão a privacidade torna-se um status falso.

O rótulo também deve separar a privacidade do sigilo comercial. A infraestrutura sensível de um banco, um grupo de direitos humanos e a lista de clientes de um revendedor podem merecer proteção, mas por razões diferentes e contra níveis de divulgação diferentes. Um ISP downstream recebendo uma subalocação formal de /24 não está na mesma posição que um cliente individual recebendo uma pequena atribuição. O interesse público em identificar uma rede operacional é maior do que o interesse público em nomear cada usuário final.

O manual de políticas da AFRINIC já contém uma acomodação limitada de privacidade quando um usuário final é um indivíduo: o espaço pode ser registrado com as informações de contato do provedor enquanto referencia o usuário final no objeto do banco de dados. Essa lógica pode ser estendida com cuidado.

O teste institucional é se o sistema pode responder a uma pergunta estreita: se surgir dano, disputa ou demanda legal, quem pode agir? Não precisa responder a toda curiosidade. Não precisa publicar todos os clientes. Não deve deixar a privacidade apagar a responsabilidade. Em um mercado de IPv4 escasso, o design de privacidade que funciona não é o sigilo. É a redação responsável.

Roteamento, IRR e RPKI provam autoridade, não uso

A evidência de roteamento é poderosa porque é observável. Se um prefixo é originado por um AS específico, a internet operacional pode vê-lo. Se existe um objeto de rota IRR, as redes podem inferir uma política de roteamento declarada. Se um ROA autoriza um AS de origem, as partes confiantes podem validar a autoridade de origem da rota. Esses sinais são importantes para a visibilidade downstream, mas não devem ser confundidos com um relato completo do uso.

O BGP de origem identifica a rede que anuncia a rota, não necessariamente o cliente que usa os endereços. Um provedor de hospedagem pode originar espaço para muitos clientes. Um provedor de serviços gerenciados pode anunciar um prefixo em nome de uma empresa. Um locador pode autorizar o AS de um locatário enquanto o locatário atende milhares de pequenos usuários. Um provedor de trânsito pode aparecer na evidência devido ao manuseio da rota, não à responsabilidade do cliente. O AS de origem é uma pista sobre o controle operacional, não uma identidade legal para cada usuário downstream.

Objetos IRR têm limites semelhantes. Eles podem ajudar upstreams e pares a construir filtros. Podem mostrar que alguém criou um objeto de rota ou conjunto de rotas consistente com uma origem reivindicada. Mas os dados IRR podem estar desatualizados, duplicados, criados em bancos de dados diferentes com padrões de autenticação diferentes ou mantidos por uma parte que não é mais operacionalmente responsável. Um objeto IRR mantido pelo contato técnico de um corretor pode ajudar a explicar como a rota foi aceita, mas não prova quem lida com abuso ou contratos de clientes.

RPKI e ROAs são mais fortes para autoridade de origem, mas mais restritos para responsabilidade. Um ROA válido pode dizer que um AS especificado está autorizado a originar um prefixo. Não pode dizer por que o AS está usando o espaço, quem é o cliente downstream, se o uso é regional, se um revendedor está envolvido, se os relatórios de abuso chegam à mesa certa ou se existe uma atribuição de cliente abaixo do prefixo coberto. RPKI é uma ferramenta de segurança de origem de rota, não um sistema de identidade de cliente.

Essa distinção é importante para a AFRINIC porque os serviços RPKI e IRR estão próximos ao reconhecimento do registro. Um titular pode ser capaz de criar um ROA para o AS de um locatário. Isso faz a rota parecer legítima em um sentido de segurança. Não torna a cadeia downstream visível. Por outro lado, a ausência de um ROA pode refletir atraso operacional ou baixa adoção, em vez de uso não autorizado. Se o registro público trata o RPKI como a única prova, perderá o problema real de responsabilidade.

O uso correto da evidência de roteamento é a triangulação. Um registro de função downstream pode dizer que o titular registrado autorizou o AS X a originar o prefixo Y; que existe ou não um ROA; que existe um objeto IRR e está atualizado ou desatualizado; que o contato de abuso para a função operacional é acessível; e que a identidade do cliente é pública, apenas autenticada ou redigida por privacidade. Isso combina autoridade de roteamento com visibilidade de responsabilidade. Não sobrecarrega um artefato criptográfico ou de política de roteamento com fatos que não pode provar.

A recuperação institucional da AFRINIC se beneficiaria dessa precisão. O registro não precisa se tornar um juiz onisciente do uso downstream. Precisa parar de permitir que uma superfície de evidência se passe por outra. O roteamento diz acessibilidade. RPKI diz autoridade de origem. IRR diz declaração de política. RDAP e WHOIS dizem reconhecimento registrado e contatos. DNS reverso diz delegação de nomenclatura. A visibilidade downstream diz quem é responsável abaixo do titular e quão certo alguém pode estar.

DNS reverso é uma pista, não uma prova

O DNS reverso é muitas vezes tratado como um serviço técnico secundário, mas na visibilidade downstream ele carrega um peso prático desproporcional. Um registro PTR pode revelar uma marca de hospedagem, um padrão de revendedor, um rótulo de cliente, uma dica de país, uma identidade de serviço de e-mail ou um uso antigo que deveria ter sido removido há anos. Sistemas de e-mail, ferramentas de segurança, equipes de suporte ao cliente e investigadores consultam regularmente o DNS reverso porque oferece uma pista legível por humanos quando o registro é muito abstrato.

O manual de políticas da AFRINIC dá ao DNS reverso um vínculo formal com o registro downstream. Diz que a AFRINIC aceita solicitações de delegação reversa de LIRs ativos e que nenhuma delegação reversa de espaço de endereço IP administrado ou alocado é permitida a menos que uma atribuição ou subalocação da alocação específica esteja registrada adequadamente no banco de dados da AFRINIC. Para uma delegação reversa de /24, pelo menos uma atribuição ou subalocação deve estar registrada para esse /24 específico. Essa regra é um reconhecimento silencioso de que o DNS reverso não deve flutuar livre de fatos downstream registrados.

A pista ainda pode enganar. O DNS reverso é muitas vezes desatualizado depois que um cliente sai. As convenções de nomenclatura podem usar rótulos genéricos que escondem o operador real. Um titular pode delegar DNS reverso a um revendedor cujo cliente controla o serviço. Um provedor de segurança pode usar nomes neutros para evitar expor clientes. Um operador de e-mail pode definir nomes para entregabilidade em vez de identidade. Um usuário malicioso pode criar nomes enganosos. O DNS reverso, portanto, não pode ser tratado como prova de identidade downstream.

Ainda assim, o DNS reverso desatualizado ou opaco tem consequências econômicas. Sistemas de reputação de e-mail podem desconfiar de um intervalo. Clientes podem perguntar por que os nomes apontam para um provedor anterior. Equipes de segurança podem enviar reclamações para a organização errada. Fornecedores de geolocalização e inteligência de hospedagem podem absorver rótulos antigos em sistemas de risco. Um cliente do setor público pode falhar em uma revisão de compras ou segurança porque a nomenclatura do endereço não corresponde ao serviço declarado. Um comprador pode exigir concessões de preço se o controle do DNS reverso parecer incerto.

Um locatário pode descobrir que o locador não pode atualizar nomes rapidamente porque a trilha de atribuição registrada está incompleta.

A resposta não é forçar nomes significativos em todos os registros PTR. A nomenclatura operacional tem compensações de segurança e privacidade. A resposta é tratar o DNS reverso como uma superfície de evidência. Um mapa de responsabilidade público pode dizer se o DNS reverso é controlado pelo titular, delegado downstream, gerenciado pelo cliente, desatualizado, neutro em privacidade ou inconsistente com a função registrada. Isso é mais útil do que tentar inferir tudo dos próprios nomes.

O DNS reverso também ilustra por que a visibilidade de subalocação não pode ser resolvida apenas no RDAP ou WHOIS. O banco de dados do registro pode mostrar um titular e uma subalocação. A árvore reversa pode mostrar uma história operacional diferente. A rota pode mostrar uma terceira. O contato de abuso pode mostrar uma quarta. Um regime sério de visibilidade reconcilia essas superfícies. Sinaliza inconsistências sem assumir que toda inconsistência é má conduta. Pergunta se a inconsistência é importante para a acessibilidade, a reputação, a escalação legal ou a confiança do mercado.

Para a AFRINIC, uma melhoria estreita seria valiosa: quando uma delegação reversa está vinculada a uma atribuição ou subalocação registrada, o registro público deve tornar a ligação legível. Se um /24 tem DNS reverso delegado porque existe uma atribuição de ISP downstream, os estranhos devem poder ver que a delegação reversa não é aleatória. Se o DNS reverso permanece sob o titular enquanto o uso operacional é downstream, o registro deve dizer quem lida com alterações de nomenclatura e escalação de abuso. Isso não expõe clientes. Expõe responsabilidade por um serviço que já os afeta.

Alegações de uso regional exigem humildade

A região da AFRINIC dá à visibilidade de subalocação uma carga política especial. O registro atende a África e parte do Oceano Índico. Seus materiais de exaustão e manual de políticas enquadram os recursos em torno da região de serviço da AFRINIC. Sua política de Soft Landing inclui linguagem de uso regional para recursos durante o período de exaustão. Análises públicas da disputa da Cloud Innovation descreveram preocupações da AFRINIC sobre discrepâncias entre descrições de uso registradas e países reais de uso, e sobre serviços originados dentro da região.

A Cloud Innovation e críticos alinhados contestaram essa interpretação e argumentaram que a operação global de rede não pode ser reduzida a uma regra geográfica simples.

Para a visibilidade downstream, o ponto chave é que o uso regional nem sempre é diretamente visível. A geografia do roteamento não é a geografia do cliente. Um prefixo originado de um AS na Europa pode atender usuários africanos através de uma plataforma de conteúdo ou segurança. Um servidor em Joanesburgo pode suportar clientes em todo o mundo. Um titular registrado nas Seicheles pode locar endereços para uma rede com clientes na China, Nigéria e África do Sul. Um banco de dados de geolocalização pode colocar um bloco em um país devido a dados de registro, outro devido ao roteamento e um terceiro devido a relatos de usuários.

O DNS reverso pode usar códigos de país para conveniência operacional. A latência pode indicar onde o tráfego entra na rede, não onde o serviço econômico é entregue.

Isso não significa que a evidência de uso regional seja inútil. Significa que deve ser expressa como confiança, não certeza. Um registro de responsabilidade pode distinguir região de serviço declarada, origem de rota observada, consenso de geolocalização, categoria do cliente, dependência africana, operação fora da região e status desconhecido. Pode dizer se um titular autodeclarou que o uso suporta a conectividade com a região da AFRINIC, se o registro validou uma alegação específica de uso regional, se a evidência é apenas observada por roteamento ou se a questão está disputada.

Isso é mais honesto do que fingir que um único campo de país resolve a questão.

A humildade também é economicamente eficiente. Se o registro trata a inferência fraca como prova, os titulares resistirão à divulgação e litigarão. Se os titulares tratam a geografia como incognoscível, o registro e as partes interessadas públicas assumirão evasão. Um registro baseado em confiança dá a ambos os lados um vocabulário menos explosivo. Permite que a AFRINIC veja padrões sem exigir listas brutas de clientes para cada bloco. Permite que os titulares divulguem relevância regional sem expor todos os clientes. Permite que os mercados precifiquem a incerteza em vez de inventar um binário de compatível e não compatível.

A inferência de uso regional também é importante para alegações de desenvolvimento. Alguns argumentam que o IPv4 emitido na África deve suportar a conectividade africana. Outros argumentam que os mercados globais e a demanda transregional serão mais importantes do que guardar o resíduo do estoque regional. O livro contábil público não deve decidir esse debate através de campos obscuros. Deve fornecer evidências: onde está a responsabilidade downstream, qual uso é declarado, o que é observado, o que é validado e o que permanece incerto. Boas evidências podem informar a política. Inferências ruins tornam-se controle de capital por adivinhação.

O padrão deve ser frio e prático. Publicar função e região declaradas no nível certo de detalhe. Rotular sinais observados. Preservar a privacidade quando justificado. Escalar apenas quando as evidências entrarem em conflito material com a política ou a confiança pública. Em uma região onde o registro já enfrentou litígios sobre uso e controle, essa humildade não é fraqueza. É gestão de risco.

Intermediários precisam de rótulos de responsabilidade

A cadeia downstream moderna raramente é uma linha reta. Um titular pode trabalhar com um corretor. O corretor pode apresentar um revendedor. O revendedor pode empacotar endereços em produtos VPS, e-mail, VPN ou firewall gerenciado. Um provedor de hospedagem pode operar o AS de origem. Um cliente pode controlar o servidor. Um fornecedor de abuso terceirizado pode triar reclamações. Um provedor de DNS gerenciado pode controlar as zonas reversas. O registro público pode mostrar apenas o titular e talvez o AS de origem. Quando surgem problemas, cada camada pode dizer que outra camada tem os fatos operacionais.

Corretores e revendedores não são inerentemente ruins. Eles reduzem custos de busca, combinam capacidade não utilizada com demanda, fornecem integração técnica, montam documentação e ajudam redes menores a obter endereços que de outra forma não poderiam encontrar. Provedores de serviços gerenciados também resolvem problemas reais. Muitos clientes não querem administrar roteamento, DNS reverso, mesas de abuso ou RPKI. A terceirização pode melhorar a qualidade. O problema de visibilidade não é a intermediação. É a intermediação não rotulada.

Um rótulo de responsabilidade é uma divulgação estreita de função. Não diz que o corretor possui o bloco ou que o revendedor é o cliente final. Pode dizer que um intermediário comercial está envolvido, mas não é o contato operacional. Pode dizer que um revendedor é responsável pela verificação do cliente. Pode dizer que um operador de serviço gerenciado recebe o abuso primeiro. Pode dizer que o titular permanece responsável por alterações no registro. Pode dizer que um ISP downstream controla as atribuições de clientes. Pode dizer que a identidade do cliente é redigida por privacidade, mas rastreável através do operador.

Os rótulos dizem a estranhos para onde não enviar a solicitação errada.

Tais rótulos reduziriam falhas comuns. Um upstream avaliando uma rota saberia se o AS de origem está atuando como locatário, operador gerenciado ou rede titular. Um reclamante saberia se a caixa de correio pública de abuso alcança o operador mais próximo do cliente. Um comprador saberia se revendedores não divulgados podem ter reivindicações de continuidade de cliente. Um comprador público saberia se o fornecimento de endereço de um contratado depende de uma cadeia intermediada. O registro saberia se um titular que alega privacidade mapeou pelo menos sua cadeia de responsabilidade.

Rótulos de responsabilidade também ajudam a distinguir locação de visibilidade de subalocação sem tornar a locação o quadro principal. A locação é um canal através do qual a opacidade aparece. A questão relevante aqui não são os remédios privados da locação ou o preço comercial. É se a locação ou outra delegação comercial muda quem está usando o espaço e quem pode ser contatado. Uma locação com rótulos claros de responsabilidade pode ser menos arriscada do que uma atribuição de hospedagem comum sem rastreabilidade. Uma venda com clientes downstream ocultos pode ser mais problemática do que uma delegação transparente com prazo limitado.

A mesma lógica se aplica à privacidade do cliente. Um rótulo pode dizer "usuário final com privacidade protegida, rastreável pelo titular" sem nomear o usuário final. Pode dizer "contato de aplicação da lei disponível através de escalação do titular" sem publicar canais sensíveis. Pode dizer "lista de clientes controlada pelo revendedor" para que as contrapartes saibam que o titular pode não ter registros imediatos. Esta não é uma lista de clientes. É um mapa de quem tem qual dever operacional.

Intermediários tornam-se economicamente mais seguros quando seus papéis são legíveis. Se resistirem a toda divulgação de função, os mercados assumirão o pior. Se o registro exigir divulgação total do cliente, intermediários legítimos resistirão. Rótulos oferecem uma alternativa de menor custo: responsabilidade visível, identidade protegida e incerteza precificada.

A dependência do setor público transforma a opacidade em risco de capacidade estatal

A opacidade da subalocação torna-se mais grave quando sistemas do setor público dependem da cadeia de endereços. Um ministério pode hospedar serviços ao cidadão com um provedor local que usa endereços de um titular regional. Um hospital público pode comprar segurança gerenciada de um fornecedor cujos nós de firewall estão dentro de um bloco locado ou subalocado. Uma unidade policial de cibercrime pode precisar de informações de assinante ou cliente após um incidente. Uma rede de educação nacional pode depender de provedores downstream para campi. Um tribunal pode precisar preservar evidências enquanto um serviço permanece online.

Em cada caso, o órgão público pode não saber que sua continuidade depende de uma cadeia de endereços com várias camadas de profundidade.

Para clientes comerciais comuns, a opacidade é um problema de alocação de risco. Para clientes do setor público, pode se tornar um problema de capacidade estatal. Um portal de impostos que perde a entregabilidade de e-mail porque o DNS reverso está desatualizado, uma plataforma de compras que é bloqueada porque endereços vizinhos são abusivos ou um fornecedor de serviços de emergência que não pode provar autoridade de rota não está apenas enfrentando um inconveniente de TI. O custo é suportado por cidadãos e instituições públicas que não escolheram a estrutura de endereços oculta.

As necessidades de aplicação da lei também são específicas. Investigadores muitas vezes começam com um endereço IP, timestamp e porta. Se o registro público nomeia apenas o titular, o investigador deve percorrer a cadeia: titular, revendedor, provedor gerenciado, cliente, usuário final. NAT, CGNAT, locação VPS e hospedagem de curto prazo tornam o tempo crítico. Se o titular não mantém rastreabilidade ou se o revendedor não está registrado, as solicitações legais podem chegar tarde demais ou à parte errada. A divulgação pública excessiva não é a resposta, mas um caminho de escalação estruturado é.

O histórico de crise da AFRINIC aumenta as apostas porque as autoridades públicas já podem estar olhando para o registro como instituição. Reportagens em torno da administração judicial mauriciana descreveram um mandato para preservar operações e restaurar a governança, enquanto coberturas posteriores descreveram pressão judicial contínua, mecanismos eleitorais falhos, questões de restauração do conselho, processos e disputas sobre o tratamento de recursos de numeração.

Em tal ambiente, os usuários do setor público precisam de evidências de que a continuidade dos endereços não depende de acordos privados não registrados que entram em colapso sob litígio ou mudança de governança.

Um padrão de compras do setor público poderia ser simples. Provedores que usam IPv4 administrado pela AFRINIC para serviços públicos devem ser capazes de mostrar o titular registrado, a rede operacional, a autoridade de origem da rota, o controle do DNS reverso, os contatos de abuso e segurança, os rótulos de responsabilidade downstream, os arranjos de privacidade, a escalação de solicitações legais e qualquer disputa que afete o espaço. A versão pública não precisa revelar todos os clientes. O arquivo voltado ao comprador deve ser completo o suficiente para suportar continuidade e responsabilidade.

A dependência do setor público, portanto, muda o equilíbrio da privacidade. O público não precisa de todos os nomes de clientes. Precisa de garantia de que serviços críticos têm responsabilidade de endereço rastreável. Um registro que ajuda a criar essa garantia não está se tornando um órgão de vigilância. Está reduzindo o risco de compras públicas em um mercado onde a escassez de endereços e a instabilidade institucional tornaram a camada de endereços visível.

A recuperação será julgada abaixo da linha do titular

A AFRINIC não precisa de um regime de transparência máxima. Precisa de um pacto de visibilidade que declare para que serve a visibilidade downstream: unicidade, solução de problemas, acessibilidade de abuso, diligência de autoridade de rota, consistência do DNS reverso, escalação legal, confiança em transações e continuidade para clientes que dependem do escasso IPv4. Também deve declarar para que a visibilidade não serve: publicar listas brutas de clientes, julgar todos os arranjos comerciais, expor usuários sensíveis ou usar campos de registro como alavanca em disputas não relacionadas.

O pacto poderia começar com alguns tipos de registro. Subalocações formais no mínimo político ou acima dele devem ser publicamente visíveis com identidade do ISP downstream, contatos, status, data de validação e escalação do titular. Atribuições de usuário final que exigem responsabilidade operacional pública devem identificar o usuário final ou um proxy com privacidade protegida com rótulos de função claros.

Intervalos menores de clientes abaixo dos limites públicos de subalocação não precisam ser nomeados publicamente, mas os titulares devem manter rastreabilidade e publicar rótulos de responsabilidade onde abuso, roteamento, DNS reverso ou solicitações legais tornam a função material.

Cada registro deve carregar status de evidência: validado pelo registro, atestado pelo titular, confirmado pela contraparte, observado por roteamento, redigido por privacidade mas rastreável, desatualizado, disputado ou restrito por tribunal. Esses rótulos impediriam que um campo público fingisse ser mais certo do que é. Também permitiriam que os mercados recompensassem melhores evidências. Um bloco com responsabilidade downstream atual deve ser mais barato para rotear, transferir, locar, financiar e comprar do que um bloco com dados apenas do titular desatualizados.

O pacto deve incluir ciclos de validação. Contatos e rótulos de função devem expirar a menos que sejam atualizados. Mudanças materiais, como novo ISP downstream, novo AS de origem, aquisição de serviço gerenciado, mudança de delegação de DNS reverso ou grande migração de clientes, devem desencadear obrigações de atualização. A falha em atualizar deve primeiro produzir incerteza visível e procedimentos de cura, não prejuízo imediato ao recurso. Remédios severos devem ser reservados para declarações falsas, uso de alto risco não rastreável, fraude, ordens judiciais ou recusa repetida em manter responsabilidade mínima.

Deve também haver uma camada de evidência privada. Os titulares devem manter registros de atribuições de clientes, autorizações, contratos de revendedores, escalação de abuso, permissões de roteamento e justificativas de privacidade. A AFRINIC não deve precisar de todos os documentos por padrão. Deve ser capaz de solicitar evidências proporcionais quando uma subalocação formal, dependência do setor público, transferência, disputa, grande padrão de abuso ou conflito de DNS reverso/RPKI torna a função downstream material.

A solicitação deve ser específica, com prazo determinado e mais restrita que uma auditoria de todos os clientes, a menos que a evidência justifique mais.

O pacto deve recompensar a correção. Se um titular atualiza voluntariamente a responsabilidade downstream desatualizada, a resposta padrão deve ser a correção do registro, não uma aplicação ampla. Caso contrário, titulares racionais se esconderão. Fraude e falsidade intencional exigem tratamento diferente, mas a correção comum deve ser incentivada. Um registro se recuperando de um histórico de corrupção de registros deve ser firme contra a falsidade e seguro para a verdade.

A recuperação pública da AFRINIC é frequentemente discutida através de conselhos, orçamentos, administração judicial, ordens judiciais, intervenção da ICANN e legitimidade institucional. Esses assuntos são reais. Mas para muitos operadores, o teste prático ficará abaixo da linha do titular. Um cliente, upstream, comprador, órgão público, mesa de aplicação da lei ou repórter de abuso pode entender quem é responsável por um uso específico do escasso IPv4 quando esse uso não é pelo titular registrado? Se não, a recuperação da governança permanece muito abstrata.

O registro pode ser legalmente preservado e ainda deixar a responsabilidade downstream opaca. Pode eleger um conselho e ainda expor apenas registros de nível de titular. Pode operar RDAP, WHOIS, DNS reverso, IRR e RPKI e ainda falhar em conectar essas superfícies em um mapa de responsabilidade. Pode anunciar políticas e ainda fazer os mercados adivinharem se um prefixo roteado é operado pelo titular, por revendedor, locado, subalocado, atribuído, protegido por privacidade ou disputado. Em um mercado de escassez, esse palpite é caro.

A história recente da AFRINIC lhe dá tanto razão quanto obrigação de fazer melhor. As reportagens sobre roubo de endereços mostram o perigo de uma autoridade de registro fraca. A disputa da Cloud Innovation mostra o perigo da delegação comercial opaca e da ampla discrição do registro colidindo. A administração judicial mostra a necessidade de continuidade quando a governança corporativa falha. A descontinuidade eleitoral mostra que a autoridade dos membros e a legitimidade institucional podem elas mesmas se tornar fatos de mercado.

O litígio contínuo mostra que alegações públicas sobre locação, comercialização e reconhecimento judicial podem mover a confiança. A visibilidade de subalocação não resolverá tudo isso. Estreitará uma importante incerteza que de outra forma alimenta o resto.

A postura institucional correta é modesta. A AFRINIC não deve afirmar conhecer todos os clientes. Não deve se tornar o regulador econômico de todos os serviços downstream. Não deve exigir listas de clientes como substituto de uma política clara. Não deve usar a visibilidade para punir arranjos comerciais impopulares sem garantias adequadas. Mas deve insistir que os titulares registrados podem explicar e evidenciar a responsabilidade downstream no nível em que terceiros confiam no registro de endereços. Essa é a diferença entre um livro contábil e uma névoa privada.

O retorno é prático: relatórios de abuso mais restritos, filtragem menos grosseira, alterações mais limpas de DNS reverso e RPKI, diligência menos dependente de corretores, compras públicas mais fortes e clientes protegidos com rastreabilidade responsável. Os mercados precificariam a responsabilidade verificada em vez de rumores.

O pacto também disciplinaria os titulares. Um titular que aluga, atribui, subaloca ou delega capacidade escassa de IPv4 não deve poder dizer apenas: o livro contábil público me nomeia, portanto, todos os outros devem confiar em mim. O titular é a âncora, não toda a história. Se lucra com o uso downstream, protege clientes ou usa intermediários, deve saber quem pode agir. Se não pode, o mercado está certo em descontar o bloco.

A AFRINIC é um caso de teste porque o registro da África viveu a colisão completa de escassez, integridade de registro, delegação comercial, litígio e recuperação institucional. A lição não é que todo usuário downstream deve ser público. É que a responsabilidade não pode permanecer privada quando os custos de sua ausência são públicos. Um livro contábil de registro útil não expõe a lista de clientes. Expõe o suficiente da cadeia de responsabilidade para que estranhos ajam sem se juntar à luta.