Fragilidade do IRR da AFRINIC em dados de rota obsoletos, espelhados e recursivos

Quando vários registros respondem pela mesma rota

O trabalho do servidor de rotas acontece antes do amanhecer porque o exchange quer que seus filtros estejam prontos antes do início do dia comercial. Ele busca em várias fontes do Internet Routing Registry, atualiza dados espelhados, expande AS-SETs de membros, constrói listas de prefixos e verificações de origem, e emite configurações que decidirão quais anúncios o exchange aceitará. A maioria das manhãs é tranquila. Esta manhã o trabalho para em um prefixo IPv4 administrado pela AFRINIC cuja história muda dependendo de qual fonte é consultada.

Uma fonte de IRR tem um objeto de rota para o prefixo com um AS de origem que pertence a um upstream anterior. Outra tem um objeto mais recente para uma rede de cliente que diz ter se mudado para um data center regional. Uma terceira fonte espelha uma entrada mais antiga que ainda parece plausível porque o nome do mantenedor se assemelha ao titular do recurso. Um AS-SET fornecido pelo cliente se expande de forma diferente dependendo da ordem das fontes. Em uma expansão, o prefixo é coberto através do cone de clientes de um revendedor. Em outra, ele desaparece porque um route-set referencia um AS-SET que existe em um repositório diferente.

Uma verificação pública de RPKI ajuda em parte da questão, mas não explica por que as visões do IRR discordam ou qual relação operacional é atual. O engenheiro do exchange pode rejeitar a rota, aceitá-la, fazer uma exceção manual, pedir cartas ou atrasar o ticket. Nenhuma dessas escolhas é gratuita.

Essa é a cena prática por trás da fragilidade do Internet Routing Registry. O problema não é apenas que um único objeto de rota pode estar errado, desatualizado ou difícil de corrigir. O problema mais amplo é que os dados de política de roteamento estão distribuídos em vários repositórios com diferentes históricos, regras de atualização, práticas de autenticação, cronogramas de mirror, hábitos de limpeza e reputações sociais. Uma operadora ou IXP raramente consome "o IRR" como um único banco de dados.

Ela consome um conjunto selecionado de fontes, em uma ordem selecionada, através de ferramentas que fazem suposições sobre duplicatas, recursão, associação a route-sets e preferência de fontes. Quando essas suposições colidem com registros conflitantes, o design do banco de dados se torna um evento econômico.

As partes afetadas são mais amplas do que os engenheiros de rede. Um provedor de trânsito precisa saber em qual fonte confiar antes de provisionar. Um provedor de nuvem precisa de confiança antes de anunciar o espaço do cliente. Um servidor de rotas de IXP precisa de filtros que protejam os participantes sem excluir redes locais legítimas. Um corretor deve explicar por que registros IRR obsoletos não reduzirão o preço ou atrasarão a transferência. Um comprador, credor ou segurador precisa saber se a aceitação operacional sobreviverá à devida diligência.

Um cliente comprando conectividade não se importa com a sintaxe RPSL, mas sentirá o custo se as rotas não forem aceitas rapidamente.

AFRINIC é o teste de estresse útil porque seu ambiente institucional torna o custo oculto visível. A região enfrentou uma longa crise de governança, litígios, questões de recepção, turbulência eleitoral e preocupação pública sobre a integridade dos registros históricos de endereços. A escassez de IPv4 tornou cada bloco roteável mais consequente economicamente. Nesse cenário, os dados de roteamento adjacentes ao registro não são um apêndice burocrático. Eles se tornam parte da infraestrutura de confiança do mercado. Se os dados são coerentes, terceiros podem dizer sim a um custo menor.

Se estão fragmentados, cada participante deve decidir quanto risco legal, operacional e de reputação absorver.

O quadro correto não é lealdade institucional. Não é que a AFRINIC, ou qualquer outro RIR, deva ser confiável porque alega um mandato comunitário. Nem é que IRRs privados devam ser confiáveis porque operadores os usam há anos. A questão é mais difícil: quando vários bancos de dados dão respostas plausíveis, mas contraditórias, sobre a política de roteamento em torno de um recurso numérico escasso, em qual resposta um upstream, exchange, plataforma de nuvem, corretor, comprador, credor ou cliente deve confiar, e quem paga quando a resposta está errada?

RPSL tornou a política de roteamento legível, não autovalidável

O sistema Internet Routing Registry cresceu a partir de uma necessidade operacional razoável. O BGP permite que as redes anunciem rotas, mas não fornece, por si só, uma explicação pública completa do que uma rede pretende originar, transitar ou aceitar. A política de roteamento é importante demais para ser deixada apenas em configurações privadas de roteadores e threads de e-mail. O RPSL, definido na RFC 2622, deu aos operadores uma linguagem estruturada para expressar essa política. Inclui objetos como route, route6, aut-num, as-set, route-set e mntner. Estes não são instrumentos legais.

São objetos de banco de dados projetados para que as relações de roteamento possam ser descritas em uma forma que o software possa consultar.

Essa distinção é muitas vezes a primeira vítima da automação. Um objeto de rota associa um prefixo a um sistema autônomo de origem. Um objeto route6, descrito na extensão multiprotocolo da RFC 4012, desempenha o papel comparável para IPv6. Um objeto mntner identifica o mantenedor que pode autenticar mudanças em outros objetos. AS-SETs e route-sets permitem que os operadores descrevam coleções de redes ou rotas, muitas vezes recursivamente. A partir dessas peças, uma rede pode gerar filtros para um cliente ou peer. A sintaxe é estreita, mas as consequências são amplas porque a saída se torna política de roteador.

A promessa inicial era coordenação. Se os operadores publicassem suas políticas de roteamento pretendidas em registros públicos ou semipúblicos, outros operadores poderiam tomar decisões mais seguras. Os filtros poderiam ser gerados em vez de construídos manualmente. As mudanças poderiam ser revisadas contra um modelo de política visível. Erros seriam mais fáceis de detectar. A coordenação em toda a Internet teria uma gramática comum.

A RFC 2725, escrita à medida que as preocupações de segurança em torno do IRR cresciam, capturou a mudança: à medida que os dados do IRR se tornavam mais úteis para operações, seus requisitos de integridade e segurança se tornavam mais fortes. Um banco de dados de coordenação mantido de forma frouxa é uma coisa. Um banco de dados que alimenta filtros é outra.

RPSL não tornou os dados autovalidáveis. Tornou os dados legíveis. Essa diferença importa em toda disputa fragmentada de IRR. Se um objeto de rota existe em um repositório, o objeto pode ser analisado. Pode ser espelhado. Pode ser correspondido a um anúncio. Pode ser puxado para uma lista de prefixos. Mas a existência do objeto não prova que o titular do recurso o autorizou, que o AS de origem ainda é atual, que o mantenedor ainda representa a parte relevante, que uma duplicata em outro lugar é falsa, ou que uma expansão de route-set entre fontes reflete relações comerciais atuais. O formato torna uma afirmação legível por máquina.

Não torna a afirmação verdadeira.

Essa limitação já foi menos importante porque os riscos eram menores e a cultura operacional era mais baseada em relacionamentos. O mercado moderno é menos tolerante. O IPv4 é escasso; a automação é mais profunda; a integração em nuvem, servidores de rota, serviços de segurança gerenciados, peering remoto e transferências de endereços dependem de evidências externas repetíveis. Um registro que antes ajudava os engenheiros a se coordenar agora influencia se capital, conectividade e relacionamentos com clientes podem se mover.

A lição institucional é simples, mas desconfortável. Um banco de dados de registro que afeta filtros não pode ser governado como se fosse apenas um quadro de avisos conveniente. No entanto, também não deve ser convertido em um amplo ponto de controle discricionário sobre a atividade do mercado. A legitimidade do banco de dados vem da estreiteza e confiabilidade de sua função de registro. Deve registrar, autenticar e expor declarações operacionais de maneiras que reduzam a incerteza. Não deve fingir que toda entrada de política de roteamento é um julgamento de propriedade, um plebiscito comunitário ou um instrumento de soberania institucional.

É por isso que a fragmentação é tão cara. Se o mesmo vocabulário RPSL aparece em muitos repositórios, cada um com um modelo de autoridade diferente, o mercado recebe declarações que parecem comparáveis, mas repousam em fundamentos diferentes. O objeto de rota em uma fonte pode estar intimamente ligado a um registro de titular do RIR. O objeto de rota em outra pode ter sido criado por um operador de rede há anos sob uma prática de mantenedor menos restritiva. Um objeto espelhado pode ficar atrás da fonte ou preservar uma visão excluída. Um route-set pode referir-se a objetos que existem apenas se a ferramenta consultar os repositórios certos.

A gramática comum mascara a diferença institucional subjacente.

A fragmentação transforma uma ferramenta de coordenação em um pedágio de mercado

A fragmentação é às vezes descrita como um incômodo para ferramentas de filtragem. Isso é muito suave. Em um mercado de endereços escassos, dados fragmentados de IRR são um sistema de pedágio. Ele cobra de toda parte que deve investigar, explicar, reconciliar, substituir, documentar ou segurar em torno de registros contraditórios. O pedágio não é pago a um único coletor. É pago em trabalho, atraso, descontos de risco, integração falhada, peering bloqueado, exceções manuais, revisão legal e desconfiança entre contrapartes.

O primeiro custo é a busca. Um operador não pode simplesmente perguntar se um prefixo tem um objeto IRR. Deve perguntar quais fontes sua política reconhece, se essas fontes são autoritativas para a região do recurso, se as cópias espelhadas estão atualizadas, se as duplicatas devem ser colapsadas ou tratadas como conflito, e se um objeto em uma fonte privada ou não RIR deve ter permissão para substituir uma entrada ausente ou desatualizada em uma fonte vinculada ao RIR. Uma pequena rede vê apenas um ticket. Uma grande operadora vê um conjunto de regras.

Entre os dois, há um custo de transação que muitas vezes decide se a pequena rede obtém serviço rapidamente.

O segundo custo é a explicação. Quando um cliente diz: "o objeto de rota está lá", o upstream deve perguntar onde. Se o objeto está no RADB, mas não no IRR do RIR relevante, isso é suficiente? Se está em uma fonte da AFRINIC, mas uma duplicata em outra fonte aponta para uma origem diferente, qual objeto vence? Se o cliente tem um AS-SET que se expande por vários repositórios, o upstream aceita todas as fontes ou apenas aquelas em uma lista preferida? Se o provedor anterior do cliente criou objetos em seu próprio mantenedor, o cliente deve excluí-los antes que um novo provedor aceite a rota? Cada pergunta é razoável.

Juntas, elas fazem a conectividade parecer litígio com outro nome.

O terceiro custo é a competência assimétrica. Grandes operadores podem manter equipes de registro, construir políticas específicas de fonte, executar verificações regulares de objetos obsoletos, monitorar diferenças de filtro e saber a quem contatar. ISPs africanos menores, universidades, agências públicas e empresas podem não ter essa capacidade. Eles podem herdar registros antigos de contratados. Podem depender de upstreams para criar objetos. Podem não saber que uma duplicata em um IRR distante afetará um servidor de rotas em um mercado diferente. A fragmentação, portanto, favorece atores com escala suficiente para gerenciar ambiguidade.

Pune aqueles para quem a acessibilidade à Internet deveria ser infraestrutura comum.

O quarto custo é o poder de barganha. Se um comprador de espaço IPv4 descobre que o bloco tem entradas IRR conflitantes, pode exigir um desconto ou retenção de garantia. Se um credor vê que o serviço dependente de endereço de um tomador depende de exceções manuais em operadoras, pode tratar o ativo como garantia menos confiável. Se um provedor de nuvem exige limpeza antes da integração, o titular pode perder tempo de migração ou negociar de uma posição fraca. Registros fragmentados não precisam ser maliciosos para mudar o preço. Eles só precisam tornar o ativo mais difícil de confiar.

O quinto custo é a segurança. Duplicatas obsoletas podem preservar antigas reivindicações de origem. Fontes fracamente autenticadas podem dar legitimidade aparente a rotas que deveriam ser desafiadas. AS-SETs muito amplos podem puxar downstreams que não pertencem mais. Atraso de mirror pode fazer um registro corrigido parecer não resolvido. Se os operadores reagem ignorando completamente os dados de IRR, perdem uma camada defensiva útil. Se reagem confiando em todas as fontes indiscriminadamente, ampliam a superfície de ataque.

Se reagem confiando apenas em uma lista estreita de fontes, redes legítimas com registros incompletos podem ser excluídas. A fragmentação força a política de segurança a uma escolha entre danos imperfeitos.

O sexto custo é a confiança institucional. Em um ambiente de registro estável, os operadores toleram alguma bagunça porque sabem como a correção funciona. Sob estresse, cada ambiguidade é lida mais sombriamente: objeto obsoleto, controle de registro fraco, lacuna burocrática, bloqueio de titular ou bypass do registro regional? A história recente da AFRINIC torna essas questões mais difíceis de descartar. O problema de dados se torna um problema de governança porque terceiros não separam bancos de dados das instituições que os mantêm ou falham em mantê-los.

A fragmentação, portanto, muda o significado econômico de um registro IRR. Em um ambiente unificado e bem governado, o registro reduz o custo da confiança de roteamento. Em um ambiente fragmentado, o registro pode deslocar o custo para fora. O servidor de rotas, upstream, plataforma de nuvem, corretor e comprador se tornam árbitros não remunerados de conflito de banco de dados. Eles não estão bem posicionados para fazer esse trabalho, mas o sistema de roteamento não lhes dá escapatória. Pacotes precisam de uma decisão.

A seleção de fontes é uma decisão econômica disfarçada de engenharia

A RFC 7454, o documento de Operações e Segurança BGP, trata a seleção de fontes como uma preocupação prática para operadores. Discute filtragem de prefixos, filtros de cliente derivados de registros de roteamento, recursão de AS-SET, a necessidade de atualizar filtros e a dificuldade de escolher quais fontes de IRR usar. O texto é operacional, mas a implicação econômica é grande: uma regra de seleção de fonte é uma política de confiança. Decide quais reivindicações de banco de dados são baratas o suficiente para confiar e quais reivindicações requerem escalação manual ou rejeição.

Considere uma operadora que aceita objetos da AFRINIC, RIPE, APNIC, ARIN e RADB ao construir filtros. Essa política maximiza a inclusividade. Reduz tickets de suporte de clientes cujos dados vivem em fontes mais antigas ou não regionais. Também aumenta a exposição a duplicatas obsoletas, históricos de autorização mais fracos e surpresas de recursão entre fontes. Agora considere uma operadora que prefere apenas a fonte RIR relevante para cada prefixo e ignora IRRs privados onde existe um IRR RIR.

Essa política pode melhorar o alinhamento de autoridade, mas pode quebrar clientes legítimos cujos registros foram historicamente mantidos em outro lugar ou cujos objetos criados pelo provedor vivem fora da fonte regional. Uma terceira operadora pode usar uma ordem de preferência de fonte, aceitando o primeiro objeto correspondente. Essa regra é eficiente até que a fonte preferida esteja desatualizada e uma fonte menos preferida esteja atualizada.

Essas escolhas parecem técnicas porque são codificadas em scripts. São econômicas porque alocam o custo da incerteza. Uma política de fonte estrita faz com que os clientes limpem seus registros antes de receber serviço. Isso pode melhorar o banco de dados, mas desloca o trabalho para o cliente e pode excluir redes menores. Uma política frouxa faz com que as rotas sejam aceitas mais rapidamente, mas desloca o risco para a rede da operadora e seus peers. Uma política de exceção manual preserva flexibilidade, mas cria vantagem para insiders e gargalos de suporte. Não existe política de fonte neutra.

Existem apenas diferentes maneiras de alocar custo.

Para prefixos administrados pela AFRINIC, a seleção de fontes é excepcionalmente sensível porque os registros da região podem carregar múltiplas histórias ao mesmo tempo. Um prefixo pode ter um objeto de rota antigo em um IRR comercial porque um upstream o criou muito antes de o titular usar as próprias ferramentas IRR da AFRINIC. Pode ter um objeto vinculado à AFRINIC criado durante uma limpeza posterior. Pode ter referências de route-set que assumem ferramentas do estilo RIPE porque um provedor de trânsito europeu manteve a política do cliente. Pode ter entradas de IRR privadas usadas por um provedor de nuvem ou DDoS.

Cada fonte pode ser plausível da perspectiva da parte que a criou. Plausibilidade não é o mesmo que autoridade atual.

A preferência conflitante de fontes também afeta a concorrência entre provedores. Se a política de um upstream dominante aceita um conjunto mais amplo de fontes, pode integrar clientes mais rapidamente do que um provedor menor com filtros mais estritos. Se uma plataforma de nuvem exige um tipo de limpeza e um provedor de trânsito exige outro, o cliente pode escolher o caminho de menor atrito administrativo em vez do melhor serviço técnico. Se um servidor de rotas de IXP usa regras de fonte conservadoras, membros com registros bagunçados podem evitar peering multilateral e permanecer dependentes de trânsito.

A política de banco de dados então molda a estrutura do mercado indiretamente.

A seleção de fontes também pode se tornar uma forma oculta de escolha jurisdicional. Um objeto de rota para um prefixo administrado pela AFRINIC em um repositório não AFRINIC pode ser mais fácil de criar ou preservar do que um vinculado aos registros de titular da AFRINIC. Um operador que aceita esse objeto não está formalmente transferindo autoridade da AFRINIC, mas está decidindo que uma fonte não AFRINIC pode apoiar a confiança operacional. Em casos normais, isso pode ser inofensivo. Em casos contestados, importa.

O mercado pode rotear de acordo com o banco de dados mais fácil de usar, não o banco de dados que melhor reflete o registro de recursos.

A solução não é exigir uma lista universal de fontes. Operadores têm diferentes tolerâncias a risco, bases de clientes e ambientes legais. A solução é transparência e expectativas mais restritas. Operadoras e operadores de servidores de rotas devem publicar como usam fontes, como lidam com duplicatas, com que frequência atualizam mirrors, como tratam conflitos entre dados RIR e não RIR, e quais evidências são necessárias para exceções. Registros devem publicar metadados suficientes para permitir que operadores distingam autoridade de fonte, em vez de adivinhar.

Clientes devem poder aprender com antecedência se sua postura IRR passará pelos filtros de uma determinada rede. Uma regra de seleção de fonte oculta é uma regra de mercado oculta.

No caso da AFRINIC, a prioridade institucional deve ser tornar a fonte vinculada à AFRINIC previsível o suficiente para que os operadores tenham menos razão para pesquisar entre bancos de dados pela resposta que preferem. Isso não significa tornar a AFRINIC um governante de mercado. Significa fortalecer a função de registro para que a fonte regional se torne um ponto de referência de baixo custo. Proteja o registro, não o porteiro: o valor do registro reside em tornar a confiança mais barata, não em transformar a preferência de fonte em poder discricionário.

Atraso de mirror e duplicatas obsoletas criam falsa continuidade

Os dados do IRR muitas vezes viajam através de mirrors. O espelhamento é útil porque os operadores precisam de acesso local, rápido e resiliente às informações do registro. Também cria uma nova classe de fragilidade. Um mirror pode ficar atrasado em relação à fonte autoritativa. Pode preservar uma visão após uma correção. Pode falhar silenciosamente. Pode atualizar uma fonte enquanto outra permanece desatualizada. Pode dar à automação a impressão de que um registro ainda existe ou ainda tem uma certa origem quando o repositório subjacente já avançou.

O atraso de mirror é fácil de subestimar porque a maioria dos atrasos é inofensiva. Se uma atualização de filtro está algumas horas atrás de uma atualização rotineira de route-set, nada dramático acontece. O problema não é o atraso médio. É o atraso durante mudanças contestadas ou economicamente significativas. Um titular exclui um objeto obsoleto após deixar um provedor anterior. O route-set do provedor antigo ainda referencia o objeto através de um mirror. Um servidor de rotas de IXP atualiza a partir de uma cópia atrasada e continua a aceitar uma rota que o titular acredita ter sido retirada.

Ou um cliente cria um novo objeto para uma migração, mas o mirror escolhido pelo provedor de trânsito não acompanhou, então o ticket emperra. A diferença entre uma visão atual e uma desatualizada se torna uma interrupção de negócios.

Duplicatas obsoletas são mais duráveis que o atraso de mirror. Um objeto duplicado pode permanecer em outra fonte muito depois de a relação comercial original ter terminado. O upstream anterior pode tê-lo criado para um cliente e nunca o limpou. O cliente pode não saber que ele existe. O mantenedor pode ser inalcançável. A fonte pode ter fracos incentivos para removê-lo porque o objeto não está vinculado ao registro de recursos dessa fonte. Anos depois, filtros automatizados ainda veem uma reivindicação plausível de prefixo-origem.

Se o titular atual quiser mudar de provedor, pode ter que explicar por que o objeto antigo não deve governar a aceitação. Se um agente malicioso quiser cobertura, o objeto antigo pode fornecer ambiguidade suficiente para atrasar a rejeição.

A falsa continuidade é o perigo econômico. Um objeto obsoleto faz um relacionamento passado parecer presente. Um objeto espelhado faz uma visão corrigida parecer não resolvida. Um AS-SET recursivo que inclui um downstream antigo faz um ex-cliente parecer parte do cone atual. O banco de dados não precisa dizer "isso é autoritativo". Ele só precisa ser consumido por ferramentas suficientes para criar confiança. Em um mercado onde a velocidade importa, a continuidade aparente é valiosa. Permite que uma parte diga: "os dados sempre foram assim", mesmo quando a sobrevivência dos dados é uma falha de manutenção.

O contexto da AFRINIC aumenta o preço da falsa continuidade. Preocupações com a integridade do registro histórico significam que dados dormentes ou obsoletos não são apenas bagunça. Podem se tornar uma sombra probatória em torno do escasso espaço IPv4. Um comprador revisando um bloco da região da AFRINIC pode perguntar se objetos IRR antigos sobrevivem em fontes não regionais. Um provedor de nuvem pode perguntar se uma origem anterior ainda aparece em qualquer lugar que ele consome. Um corretor pode precisar limpar referências antigas de route-set antes de fechar.

Um upstream pode se recusar a aceitar uma nova origem até que a antiga seja removida. Cada passo é racional, mas juntos transformam a limpeza fragmentada de banco de dados em uma pré-condição de mercado.

Duplicatas obsoletas também criam incentivos perversos. Uma parte que se beneficia da ambiguidade pode ter pouca razão para remover dados antigos. Um provedor anterior pode não priorizar a limpeza de um cliente perdido. Um revendedor pode preferir AS-SETs amplos porque tornam a integração mais fácil. Uma fonte fraca pode preferir volume e conveniência em vez de verificações rigorosas de autoridade. Uma fonte estrita pode remover registros, mas não tem poder sobre cópias em outros lugares.

O resultado é uma externalidade negativa: o custo dos dados obsoletos é suportado pelo titular atual, pelo novo provedor e pelas redes que devem filtrar com segurança, não necessariamente pela parte que deixou o registro obsoleto para trás.

A resposta prática deve ser disciplina de ciclo de vida. Registros usados para filtros de roteamento precisam de carimbos de data/hora, proveniência da fonte, visibilidade de exclusão, status de espelhamento e indicadores de conflito que as ferramentas possam entender. Operadores precisam de relatórios de objetos obsoletos que mostrem quando um par prefixo-origem aparece em múltiplas fontes com diferentes origens ou mantenedores. Registros e grandes operadores de IRR devem facilitar a limpeza para titulares que possam mostrar autoridade atual, enquanto preservam histórico de auditoria suficiente para evitar reescrita furtiva.

O software do servidor de rotas deve expor conflitos em vez de escondê-los atrás de regras de primeira correspondência. Nada disso requer transformar o IRR em um tribunal de propriedade. Requer admitir que dados obsoletos não são neutros quando filtros os consomem.

Há também um ponto cultural. Engenheiros muitas vezes toleram registros desorganizados porque a Internet sempre funcionou com uma mistura de dados formais e soluções informais. Essa tolerância era útil em uma rede em crescimento. É menos útil quando blocos escassos de IPv4, integração em nuvem e diligência financeira dependem de registros que estranhos não podem interpretar facilmente. Nesse ambiente, uma duplicata obsoleta não é apenas um objeto antigo. É uma reivindicação sobre o custo de confiança de outra pessoa.

Autenticação sem autorização não estabelece confiança

As discussões de segurança do IRR muitas vezes começam com autenticação. O usuário controlava a credencial do mantenedor? A senha, chave PGP, conta do portal ou outro método era válido? A atualização foi submetida através do canal adequado? Essas questões importam. Um banco de dados que não pode autenticar atualizações não é confiável o suficiente para geração de filtros. Mas autenticação não é autorização. A RFC 2725 chamou a atenção para essa separação há mais de duas décadas, e a distinção permanece central para a economia fragmentada do IRR.

Autenticação prova controle de uma credencial. Autorização pergunta se o titular da credencial tinha o direito de fazer esta declaração de política de roteamento específica para este recurso específico neste momento específico. Um ex-contratado ainda pode controlar um mantenedor. Um provedor de trânsito pode ter sido autorizado a criar um objeto de rota para um cliente durante o serviço, mas não a preservá-lo após o término. Um revendedor pode ter autoridade para incluir um downstream em um AS-SET para um produto, mas não para autorizar um novo AS de origem.

Uma caixa de correio corporativa pode existir após o funcionário que a usava ter saído. Uma conta de registro pode ser tecnicamente válida enquanto a autoridade corporativa subjacente é contestada. Controles de login fortes reduzem a personificação; eles não respondem ao mandato.

A fragmentação multiplica o problema porque cada fonte pode traçar a linha entre autenticação e autorização de maneira diferente. Um repositório pode vincular a criação de objetos de rota estritamente a um titular de recurso ou a um modelo de autorização hierárquico. Outro pode permitir a criação com base no controle do mantenedor e na confirmação do AS de origem. Um terceiro pode preservar objetos antigos sob práticas legadas. Um quarto pode permitir que mantenedores provedores criem objetos de cliente para conveniência operacional.

Quando os filtros consomem todos eles como dados RPSL comparáveis, o mercado perde de vista os diferentes pressupostos de autoridade por trás dos registros.

Para prefixos da região da AFRINIC, a distinção não é teórica. Estresse de governança, litígios e preocupações com a integridade do registro tornam as questões de mandato mais propensas a surgir. Quem pode agir por uma empresa em regime de recepção, liquidação ou disputa de conselho? Quem pode atualizar registros durante um período supervisionado pelo tribunal? O que acontece quando uma alocação histórica está vinculada a uma instituição pública cujas operações de rede atuais foram terceirizadas? Como um registro ou operador deve tratar um mantenedor controlado por um provedor de serviços que não tem mais o cliente?

Essas são questões de autorização. Uma senha de mantenedor válida não pode respondê-las sozinha.

A economia dessa distinção é severa porque os mercados gostam de credenciais. Credenciais são rápidas. Encaixam-se em software. Permitem que tickets sejam fechados. Autorização é mais lenta. Envolve contratos, cartas, autoridade corporativa, registros de registro, contexto histórico e, às vezes, lei. Um mercado sob pressão será tentado a aceitar a autenticação como substituto da autorização porque o atraso é caro. Essa tentação cria uma superfície de ataque para quem pode preservar ou obter credenciais sem autoridade atual. Também cria uma barreira para titulares legítimos que carecem de credenciais antigas, mas podem provar direito atual.

O erro inverso também é caro. Se toda atualização de IRR exigir reprovação completa da autoridade do recurso, mudanças rotineiras de roteamento se tornam muito caras. Pequenos operadores evitarão atualizar registros. Provedores manterão AS-SETs amplos para reduzir atrito. Clientes dependerão de cartas privadas e exceções manuais. Os filtros se tornarão menos precisos porque o custo da publicação precisa é muito alto. O objetivo não é documentação máxima.

É autorização proporcional: mais evidências para mudanças que alteram risco ou significado econômico, menos atrito para manutenção rotineira estável, correção rápida onde a autoridade obsoleta é evidente, e aviso claro onde as partes podem ser afetadas.

Na prática, isso significa que as fontes de IRR devem expor o contexto de autoridade, não apenas o conteúdo do objeto. Um objeto de rota criado sob autenticação direta do titular do recurso deve ser distinguível de um criado por um mantenedor provedor. Um registro vinculado à confirmação do AS de origem deve ser distinguível de um objeto histórico legado. Um objeto disputado ou recentemente corrigido deve carregar status visível o suficiente para que os operadores o tratem com cuidado. Evidências privadas não precisam ser publicadas.

Mas o banco de dados não deve forçar todos os usuários downstream a inferir autoridade a partir da sintaxe do objeto e dos nomes dos mantenedores.

É aqui que o princípio da continuidade estreita é importante. Os registros devem atuar como utilitários de continuidade, não como governantes discricionários de cada uso de mercado. Devem manter o registro confiável o suficiente para que terceiros possam interpretar declarações operacionais. Devem resistir à lavagem de mandato, onde uma ampla invocação de comunidade ou administração transforma coordenação técnica em controle institucional sobre resultados comerciais. Mas também devem resistir à falha oposta, onde a fraca higiene de autenticação permite que credenciais antigas e fontes fragmentadas governem a acessibilidade presente.

Um utilitário estreito ainda precisa de procedimento forte. Apenas usa o procedimento para proteger a confiança, não para acumular poder discricionário.

A recursão de AS-SET faz pequenos erros viajarem longe

AS-SETs são uma das partes mais úteis e perigosas do ecossistema IRR. Eles permitem que uma rede publique um conjunto de ASNs que devem ser tratados como parte de seu cone de clientes ou política de roteamento. Um provedor de trânsito pode pedir a um cliente um AS-SET, expandi-lo recursivamente, encontrar os ASNs dentro, e então construir filtros para prefixos associados a esses ASNs. Sem essa maquinaria, a manutenção de filtros de cliente seria muito mais manual. Com ela, um único servidor de rotas ou operadora pode processar muitas relações de roteamento automaticamente.

O perigo é a recursão. Um AS-SET pode incluir outros AS-SETs. Esses AS-SETs podem viver em fontes diferentes. Podem incluir ASNs de clientes obsoletos, revendedores downstream, route-sets ou objetos mantidos sob diferentes padrões de autoridade. A expansão pode depender da fonte. Uma ferramenta que busca todas as fontes pode produzir um conjunto maior do que uma ferramenta que se restringe a fontes preferidas. Uma ferramenta que para na primeira correspondência pode tratar um banco de dados como decisivo. Uma ferramenta que falha fechado pode rejeitar clientes legítimos.

Uma ferramenta que falha aberto pode aceitar rotas através de uma cadeia que ninguém auditou recentemente. A cautela da RFC 7454 sobre recursão de AS-SET e filtros derivados de IRR não é uma nota de rodapé acadêmica. É o ponto operacional em que a fragmentação do banco de dados se torna configuração de roteador.

Em um caso da região da AFRINIC, o problema de recursão pode ser disfarçado pela camada comercial comum. Um pequeno ISP compra trânsito de uma operadora regional. O AS-SET da operadora inclui um revendedor. O revendedor inclui ASNs de clientes. Alguns desses clientes têm prefixos da AFRINIC, alguns de outras regiões, alguns alugados ou delegados, alguns transferidos para provedores de nuvem ou DDoS. Os objetos foram criados ao longo de muitos anos por diferentes mantenedores. Quando um servidor de rotas de IXP expande o AS-SET de nível superior, pode importar toda uma história de relações comerciais, não apenas a política atual do membro.

Se a expansão for muito ampla, clientes obsoletos podem permanecer roteáveis. Se for muito estreita, downstreams legítimos podem desaparecer.

O efeito econômico é a escala. Um único objeto de rota obsoleto afeta uma reivindicação prefixo-origem. Um membro de AS-SET obsoleto pode afetar muitos prefixos. Um route-set amplo pode afetar todos os prefixos associados a vários ASNs. Um objeto recursivo em uma fonte confiável pode importar dados menos confiáveis de outra fonte. O raio do erro cresce com cada camada de indireção. Isso torna a higiene do AS-SET uma questão de mercado. O custo de um conjunto impreciso é suportado não apenas pelo mantenedor, mas por todo upstream, servidor de rotas, cliente e peer que depende de sua expansão.

A recursão também cria opacidade. Um cliente pode não saber por que o filtro de um upstream inclui ou exclui uma rota. A resposta pode estar enterrada em uma regra de seleção de fonte vários níveis abaixo. O ticket de suporte pode dizer "incompatibilidade IRR" quando o problema real é que o AS do cliente está faltando em um conjunto downstream, ou que um AS-SET duplicado em outra fonte está sendo preferido, ou que uma entrada antiga de revendedor ainda está expandindo. As partes discutem sobre o prefixo visível enquanto a causa está em uma cadeia oculta de objetos RPSL.

Para provedores de nuvem e grandes redes de conteúdo, o problema do AS-SET se cruza com a escala de integração. Eles precisam verificar muitos clientes e evitar se tornar pontos de origem para espaço questionável. O manuseio estrito de AS-SET reduz o risco de abuso, mas aumenta o atrito do cliente. O manuseio frouxo melhora a velocidade de integração, mas pode importar política obsoleta ou excessivamente ampla. Para corretores e compradores, a proliferação de AS-SET é ruído de due diligence. Um bloco pode parecer limpo nos registros do titular, mas aparecer em route-sets associados a provedores antigos, revendedores ou clientes.

Antes que o dinheiro se mova, alguém deve determinar se essas referências são operacionalmente significativas, obsoletas ou prejudiciais.

A política certa não é abandonar os AS-SETs. Eles permanecem práticos e amplamente utilizados. A política é tratar a expansão recursiva como uma cadeia de confiança com elos fracos visíveis. As ferramentas devem relatar caminhos de fonte, nomes de conjuntos duplicados, referências entre fontes, idade da expansão, crescimento incomum e conflitos com dados conhecidos de titular ou origem. Operadores devem evitar aceitar recursão arbitrária em todas as fontes sem considerar a autoridade. Registros devem ajudar titulares a descobrir onde seus prefixos e ASNs aparecem em conjuntos que eles não controlam.

Grandes IXPs e operadoras devem publicar como lidam com recursão entre fontes. Quanto mais um mercado depende de automação, mais a automação deve explicar suas suposições.

Para a AFRINIC, a recursão de AS-SET tem uma dimensão de desenvolvimento regional. O peering local e o trânsito regional se tornam mais baratos quando os filtros podem ser construídos de forma previsível. Se pequenas redes não conseguem fazer seus AS-SETs funcionarem em exchanges e upstreams, podem permanecer dependentes de alguns provedores que já entendem os rituais. Se conjuntos obsoletos ou muito amplos criam preocupações de segurança, os operadores de servidores de rota podem apertar regras de maneiras que excluem essas mesmas pequenas redes. A boa governança de AS-SET não é, portanto, apenas uma conveniência de segurança.

É parte da redução do custo de participação na economia de roteamento.

AFRINIC transforma ambiguidade de banco de dados em risco institucional

Todos os RIRs enfrentam dados fragmentados de IRR. A AFRINIC não é única por ter objetos de rota, registros obsoletos ou operadores que discordam sobre política de fontes. É distinta porque a ambiguidade do banco de dados se sobrepõe ao estresse institucional que já tornou as contrapartes sensíveis à continuidade. Uma crise de governança muda a forma como os defeitos técnicos comuns são precificados. Em uma instituição calma, uma duplicata obsoleta de IRR pode ser tratada como limpeza. Em uma instituição estressada, a mesma duplicata pode ser interpretada como evidência de que o registro não pode policiar suas bordas.

A história recente da AFRINIC inclui litígios, governança disputada, incerteza relacionada à recepção, turbulência eleitoral, uma eleição de 2025 anulada após relatos de irregularidades, e esforços posteriores para restaurar a função do conselho. Também inclui preocupação pública sobre a integridade do registro histórico de IPv4 e apropriação indevida de endereços. Esses fatos não devem ser usados para condenar todos os registros ou todos os operadores da região. Eles não provam que um determinado objeto IRR é falso. Mas eles mudam o custo da prova.

Um terceiro olhando para um prefixo administrado pela AFRINIC pode fazer mais perguntas porque a instituição em torno do registro esteve visivelmente sob tensão.

É aí que os dados fragmentados de IRR se tornam risco institucional. Se um prefixo tem uma origem em uma fonte vinculada à AFRINIC, outra em um IRR comercial, e uma referência obsoleta em um AS-SET mantido por um provedor anterior, o conflito técnico é também um sinal de governança. Diz que o mercado não pode ver facilmente qual instituição, qual fonte e qual cadeia de autoridade deve resolver a reivindicação operacional. Em uma região onde os endereços são escassos e o registro esteve sob pressão, essa incerteza atrai prêmios de risco.

O perigo não são apenas os maus atores. Redes legítimas sofrem o mesmo desconto. Uma universidade pública com registros antigos pode ser tratada como suspeita quando muda de provedor. Um pequeno ISP pode perder uma oportunidade de trânsito porque seu AS-SET se expande inconsistentemente. Uma agência governamental pode enfrentar semanas de revisão porque contatos históricos não respondem mais. Um data center pode ter dificuldade em trazer espaço de cliente para um exchange local porque outra fonte ainda aponta para uma operadora internacional. Essas não são necessariamente falhas da equipe da AFRINIC ou de qualquer operador de IRR.

São falhas de um sistema de confiança fragmentado para tornar a legitimidade ordinária barata.

O estresse institucional também encoraja a expansão do mandato. Um registro sob crítica pode ser tentado a provar vigilância afirmando controle mais amplo sobre dados de roteamento, uso de endereços ou comportamento de mercado. A linguagem de soberania comunitária pode fazer essa expansão parecer natural: porque o registro serve uma região, deve decidir mais questões em nome da região. Mas a coordenação técnica não se torna legítima meramente invocando a comunidade. Se o registro se torna um governante discricionário de mercado, eleva os riscos de captura, litígio e conflito político.

Se se retira para a manutenção passiva de registros enquanto dados fragmentados governam a acessibilidade, falha com o mercado de outra forma. O caminho estreito é uma confiabilidade mais forte do registro sem um portão mais amplo.

Esse caminho requer reconhecer as camadas separadas. O registro de recursos numéricos da AFRINIC é o registro durável. Os dados de IRR são publicação de política de roteamento adjacente a esse registro. RPKI e ROAs fornecem evidência criptográfica de origem de rota através de um mecanismo diferente. Anúncios BGP mostram roteamento observado, não autoridade. Contratos e ordens judiciais podem decidir direitos entre partes, mas precisam de tradução em sinais operacionais. Confundir essas camadas produz excesso ou negligência. Mantê-las separadas permite que cada uma faça seu trabalho.

Por exemplo, se um prefixo disputado da região da AFRINIC tem entradas IRR conflitantes, o registro não deve ter que decidir toda disputa comercial antes que qualquer registro operacional possa mudar. Mas deve fornecer procedimentos claros para autoridade de fonte, avisos, rótulos de status, relatórios de conflito e correção. Se um titular mostra que um objeto obsoleto em uma fonte controlada pela AFRINIC não reflete mais sua delegação, o caminho de correção deve ser rápido e auditável.

Se uma duplicata persiste em outro lugar, os operadores devem ter metadados de fonte suficientes para saber que a fonte AFRINIC tem uma postura de autoridade diferente. Se uma ordem judicial afeta quem pode agir pelo titular, o registro deve mapear essa ordem para o registro cuidadosamente, em vez de transformar filtros de rota em instrumentos legais ad hoc.

O objetivo institucional é a continuidade. As redes não devem ter que esperar por calma perfeita na governança antes que seus dados de roteamento se tornem utilizáveis. Nem a turbulência de governança deve ser permitida transformar registros IRR ambíguos em alavancas privadas. Um registro que é estreito, processual e transparente reduz o valor da captura institucional. Quanto menos discrição estiver ligada à ambiguidade do banco de dados, menor será o prêmio em controlar a instituição.

A escassez de IPv4 transforma ambiguidade em prêmio

A escassez de IPv4 é a força que converte a fragilidade do IRR de um incômodo de engenharia em um problema econômico. Quando os endereços eram abundantes, um bloco bagunçado às vezes podia ser substituído, renumerado ou ignorado. A exaustão mudou isso. Um bloco IPv4 roteável agora carrega dependências de clientes, histórico de reputação, listas de permissão de firewall, suposições de geolocalização, expectativas de DNS reverso, mapeamentos de nuvem e valor de ativo. A capacidade de ter esse bloco aceito por upstreams, IXPs e plataformas de nuvem é parte do valor do bloco.

Um bloco de endereços não é valioso meramente porque aparece em um registro. É valioso porque as contrapartes acreditam que pode ser usado. A usabilidade depende de uma pilha de evidências: registros de titular do registro, autoridade contratual, histórico de roteamento, objetos IRR, AS-SETs, status RPKI, reputação de abuso, DNS reverso, aprovações de integração em nuvem e filtros de operadora. Dados fragmentados de IRR estão no meio dessa pilha. Estão perto o suficiente das operações para afetar a acessibilidade e perto o suficiente do registro para influenciar percepções de legitimidade. Quando conflitam, o bloco se torna menos líquido.

Um comprador vê isso como risco de limpeza. Se adquirir o bloco, os objetos de rota antigos permanecerão? Uma origem anterior ainda aparecerá nos filtros? O vendedor conseguirá excluir duplicatas obsoletas de fontes que não controla? Os provedores de nuvem aceitarão a nova origem rapidamente? Um credor financiando o negócio verá a postura de roteamento como estável? Cada resposta incerta pode mudar o preço, os termos de garantia ou o cronograma de fechamento. O mercado não precisa acreditar que os registros IRR são títulos de propriedade. Só precisa acreditar que registros IRR ruins podem atrasar o valor.

Um corretor vê como risco de execução. Corretores vendem confiança tanto quanto vendem introduções. Um bloco com dados de registro limpos, mas histórico IRR bagunçado, requer mais explicação. Se o corretor não puder mostrar que o prefixo será aceito pelos principais provedores de trânsito e plataformas, o comprador pode descontá-lo. Se o corretor confiar em um objeto obsoleto para mostrar roteabilidade, o comprador pode depois descobrir que a aceitação operacional foi baseada em evidências frágeis. Dados fragmentados de IRR transformam a corretagem em uma forma de due diligence de roteamento.

Um credor vê como incerteza colateral. Empresas dependentes de endereços podem não penhorar blocos IPv4 diretamente de forma simples, mas os credores ainda se preocupam se os ativos de rede que suportam o fluxo de caixa são estáveis. Se a capacidade de uma empresa de atender clientes depende de prefixos que exigem exceções manuais de rota, o ativo é mais fraco. Se registros IRR conflitantes podem permitir que um provedor antigo ou reclamante crie confusão, o risco é maior. Se o ambiente de registro está estressado, o credor pode pedir mais controles. Dados de roteamento ambíguos se tornam um custo de financiamento.

Um cliente vê como confiabilidade do serviço. Empresas, agências públicas e usuários de nuvem não querem aprender a diferença entre RADB, AFRINIC, recursão de AS-SET e RPKI. Eles querem que a rede de seu provedor funcione. Quando uma migração falha porque um servidor de rotas rejeita um prefixo, o cliente experimenta atraso e desconfiança. O provedor pode culpar o registro, o antigo provedor, o novo upstream ou uma fonte de banco de dados. O cliente ouve apenas que o ativo de endereço foi mais difícil de usar do que o prometido.

A escassez intensifica a questão distributiva. Redes mais ricas podem comprar expertise. Redes menores podem pagar através de atraso. Operadores africanos tentando construir interconexão local podem enfrentar ceticismo de plataformas globais acostumadas a documentação mais rigorosa. Redes do setor público com alocações antigas podem ter dificuldade em se modernizar porque registros antigos não correspondem às estruturas atuais de contratação. Universidades e redes de pesquisa podem herdar registros de uma era mais informal. O prêmio de mercado por dados IRR limpos não é, portanto, apenas uma recompensa pela boa higiene.

É também uma penalidade pela complexidade histórica.

A conclusão política deve ser modesta. A AFRINIC não deve se tornar o árbitro de cada preço de transferência, aluguel, penhor ou decisão de integração em nuvem. Isso transformaria um registro em um supervisor de mercado. Mas deve entender que os dados de roteamento adjacentes ao registro afetam essas decisões. Se a fonte regional é previsível, se registros obsoletos podem ser encontrados e corrigidos, se a autoridade da fonte é visível e se os operadores podem confiar em procedimentos claros, o prêmio de escassez ligado à ambiguidade cai. A boa governança do IRR torna os mercados de IPv4 menos feudais.

A má governança do IRR permite que aqueles com conhecimento privado extraiam valor da incerteza de todos os outros.

RPKI ajuda, mas não dissolve a dependência do IRR

RPKI e Autorizações de Origem de Rota são frequentemente apresentados como a alternativa mais limpa ao IRR. Eles são mais limpos para uma questão específica. Uma ROA permite que um titular de recurso, dentro do sistema de certificado de recurso, declare qual AS pode originar um prefixo até um comprimento máximo definido. Redes que realizam validação de origem de rota podem classificar anúncios como válidos, inválidos ou não encontrados. Isso é uma melhoria poderosa em relação a registros de texto não autenticados ou fracamente autenticados. Reduz uma classe de incerteza em torno da autoridade de origem.

Mas o RPKI não dissolve o problema do IRR. Os operadores ainda usam dados de IRR para filtros de cliente, expansão de AS-SET, política de route-set, expectativas de prefixo máximo e documentação de política de roteamento. Uma ROA pode dizer que um AS está autorizado a originar um prefixo. Não descreve o cone completo de clientes por trás de um AS de trânsito. Não limpa AS-SETs obsoletos. Não remove objetos de rota duplicados de IRRs privados. Não explica por que um repositório diz que um upstream anterior ainda origina o bloco. Não diz a um corretor se referências IRR antigas atrasarão a integração do comprador na operadora.

Não decide se um objeto criado pelo provedor deve ser excluído após o término do contrato.

RPKI é, portanto, um comparador e alternativa parcial, não o centro do problema de fragmentação de fontes. Pode fornecer evidências mais fortes para reivindicações de prefixo-origem. Pode ajudar operadores a rejeitar anúncios inconsistentes com ROAs. Pode reduzir a dependência de dados fracos de IRR para um subconjunto de decisões. No entanto, a economia de roteamento permanece plural. Algumas redes aplicam ROV estritamente. Algumas monitoram. Algumas usam filtros IRR mais pesadamente que RPKI. Algumas exigem ambos. Algumas aceitam RPKI para origem, mas ainda exigem AS-SETs para filtragem de cone de cliente.

O mercado não é governado por um único interruptor de validação.

No caso da AFRINIC, o valor do RPKI pode ser especialmente alto porque o estresse institucional torna a evidência de origem verificável por máquina atraente. Uma ROA pode tranquilizar um upstream de que um titular publicou uma autorização de origem atual. Pode ajudar um provedor de nuvem a distinguir uma nova origem legítima de um objeto IRR obsoleto. Pode dar a um comprador um item de diligência mais limpo. Mas não responde a todas as questões de fragmentação de fontes. Um prefixo pode ter uma ROA válida e ainda aparecer em AS-SETs antigos.

Um servidor de rotas pode usar filtros derivados de IRR que rejeitam a rota antes mesmo de o RPKI importar. Um upstream pode exigir registro IRR para provisionamento mesmo que o RPKI seja válido. As culturas operacionais mudam lentamente.

Há também uma economia política de substituição. Se um registro ou comunidade de padrões disser "use RPKI e ignore IRR", pode subestimar dependências operacionais existentes. Se os operadores disserem "IRR funciona bem o suficiente", podem preservar cadeias de autoridade fracas. O caminho realista é o layering. O RPKI deve reduzir o fardo colocado sobre o IRR para validação de origem. O IRR deve permanecer útil para política de roteamento e expressão de cone de cliente. Onde os dois conflitam, os operadores devem ter políticas claras sobre qual sinal governa qual decisão. Uma ROA válida não deve automaticamente limpar todo AS-SET obsoleto.

Um objeto IRR obsoleto não deve automaticamente derrotar uma forte evidência de origem atual. Cada sinal tem um trabalho.

Essa abordagem em camadas também evita transformar o RPKI em um instrumento de propriedade excessivamente amplo. Uma ROA não é uma escritura, assim como um objeto de rota não é uma escritura. É uma autorização criptográfica de roteamento com significado operacional definido. A tentação em um mercado escasso é deixar o artefato mais forte se tornar a resposta geral para todas as disputas. Isso seria um erro. O RPKI pode reduzir a ambiguidade de origem de rota, mas contratos, registros de registro, autoridade corporativa, ordens judiciais, delegações de clientes e limpeza de IRR ainda importam.

O fato de uma camada ser mais forte não elimina a necessidade de coerência entre as camadas.

Para automação de servidores de rota e trânsito, a melhoria prática é uma política consciente de conflitos. Um sistema deve ser capaz de dizer: a ROA valida esta origem, a fonte IRR vinculada à AFRINIC a suporta, um IRR não regional tem uma duplicata obsoleta, e um AS-SET em outra fonte ainda referencia o provedor anterior. Esse é um sinal de mercado melhor do que uma aceitação ou rejeição binária. Permite que o operador aceite a rota enquanto abre um ticket de limpeza, ou rejeite apenas se o conflito atingir um limite de risco definido. O objetivo não é mais dados por si só. O objetivo é um julgamento mais barato e mais consistente.

A ascensão do RPKI deve, portanto, tornar a governança do IRR mais disciplinada, não irrelevante. À medida que evidências de origem mais fortes se tornam disponíveis, os dados restantes de IRR devem ser usados para o que fazem de melhor e limpos onde causam confusão. O desafio da AFRINIC é apoiar essa transição sem usá-la para expandir o poder discricionário. Uma segurança de roteamento mais forte deve proteger a confiabilidade do registro. Não deve dar ao operador do registro um mandato maior para governar relações de mercado por implicação.

A questão da confiança é diferente para cada contraparte

A frase "em qual banco de dados se pode confiar?" parece singular. Na prática, a confiança depende da contraparte e da decisão. Um upstream, um IXP, um provedor de nuvem, um corretor, um comprador, um credor e um cliente fazem perguntas diferentes aos dados do IRR. A fragmentação é cara porque o mesmo conflito deve ser traduzido em cada contexto de decisão.

Um upstream pergunta se pode aceitar com segurança o anúncio de um cliente. Ele se preocupa em evitar sequestros, evitar vazamentos de rota, satisfazer a política interna, limitar a carga de suporte e provisionar receita. Pode aceitar uma mistura de evidências IRR e RPKI se a relação com o cliente for forte. Pode ser mais estrito para clientes novos ou pequenos. Para o upstream, a confiança no banco de dados é um filtro de risco do cliente. Se as fontes conflitam, a resposta conservadora pode ser atrasar o serviço até que o cliente limpe os registros. O custo recai sobre o cliente.

Um servidor de rotas de IXP faz uma pergunta mais comunitária. Deve proteger muitos participantes ao mesmo tempo. Uma rota ruim pode se propagar através do peering multilateral. Uma rota rejeitada pode reduzir o valor do exchange para um membro legítimo. O servidor de rotas é muitas vezes mais orientado por regras porque não pode negociar privadamente cada caso sem minar a previsibilidade. Para o IXP, a confiança no banco de dados é uma política de risco compartilhado. A fragmentação de fontes pode reduzir o valor do peering local ou aumentar o risco aceito por todos os membros.

Um provedor de nuvem pergunta se pode anunciar o espaço do cliente em escala sem se tornar um canal de lavagem para prefixos questionáveis. Precisa de integração padronizada. Pode preferir evidências fortes de registro e RPKI, mas ainda encontra registros IRR durante a due diligence e filtragem operacional. Para a nuvem, a confiança no banco de dados é parte do risco da plataforma. Um prefixo bagunçado da região da AFRINIC pode não ser rejeitado por preconceito; pode ser atrasado porque a plataforma não pode resolver contradições de forma barata em escala. O efeito econômico sobre o titular é o mesmo.

Um corretor pergunta se o bloco de endereços pode ser vendido, alugado ou introduzido sem surpresas. Ele se preocupa com confiança, preço e cronograma de fechamento. Dados fragmentados de IRR são um defeito a ser divulgado, limpo ou descontado. Para o corretor, a confiança no banco de dados é a comercialização. Duplicatas obsoletas e origens conflitantes reduzem a promessa de que o comprador pode usar o bloco rapidamente. O corretor pode não controlar nenhum banco de dados, mas deve vender em torno dos defeitos dos bancos de dados.

Um comprador pergunta se receberá um ativo que funcione operacionalmente após o fechamento. A transferência de registro sozinha não é suficiente se objetos de rota antigos, referências de AS-SET ou conflitos de fonte bloquearem a implantação. O comprador pode exigir remediação antes do pagamento ou reter fundos até que as operadoras aceitem a nova origem. Para o comprador, a confiança no banco de dados é a usabilidade pós-fechamento. A ambiguidade se torna um termo de preço.

Um credor pergunta se a receita dependente de endereço é resiliente. Pode não entender cada objeto RPSL, mas seu consultor técnico traduzirá o conflito de banco de dados em risco operacional. Se os prefixos de um tomador dependem de exceções manuais de operadora ou disputas de registro não resolvidas, o credor vê fragilidade. Para o credor, a confiança no banco de dados é o suporte ao fluxo de caixa. Afeta o crédito mesmo quando o empréstimo não é garantido diretamente por endereços.

Um cliente faz a pergunta mais simples: o serviço funcionará? Pode não saber qual banco de dados um servidor de rotas usou. Ele só vê que uma migração emperra, um prefixo é rejeitado ou um provedor não pode explicar por que a aceitação difere entre redes. Para o cliente, a confiança no banco de dados é a credibilidade do serviço. Quando os provedores se escondem atrás de "problemas de IRR" sem explicação clara, os clientes aprendem que a canalização invisível do mercado não é confiável.

Essas diferenças importam para a AFRINIC porque uma resposta centrada no registro sozinha não satisfará todas as necessidades de confiança. O registro pode tornar sua fonte mais limpa, fornecer caminhos de correção, publicar metadados de conflito e melhorar a continuidade sob estresse. Cada contraparte ainda escolherá como usar os dados. O objetivo não é confiança uniforme, mas fatos coerentes: o que a fonte prova, o que não prova, como os conflitos são rotulados, como os dados obsoletos são corrigidos e como terceiros podem fazer política sem adivinhar. A confiança não é comandada. É tornada mais barata.

Um padrão restrito para confiança na região da AFRINIC

Um padrão prático para confiança no IRR da região da AFRINIC deve começar com humildade sobre o que qualquer artefato prova. Um objeto de rota prova que uma declaração prefixo-origem existe em uma fonte sob as regras dessa fonte. Um objeto route6 faz o mesmo para IPv6. Um mntner prova quem pode autenticar certas mudanças no banco de dados, não quem detém todo mandato subjacente. Um AS-SET descreve relações de roteamento pretendidas, mas pode importar dados obsoletos ou entre fontes. Uma ROA fornece evidência criptográfica de origem mais forte, mas não um mapa completo de cones de cliente, autoridade comercial ou limpeza de banco de dados.

O BGP observado mostra o que está acontecendo, não necessariamente o que está autorizado.

Dessa humildade segue uma hierarquia. Para recursos administrados pela AFRINIC, a fonte de registro e política de roteamento vinculada à AFRINIC deve ter alto peso probatório quando estiver atualizada, processualmente limpa e transparente. Entradas IRR não AFRINIC devem permanecer utilizáveis, mas os operadores não devem fingir que todo objeto RPSL repousa na mesma base de autoridade. RPKI deve fortalecer a garantia de origem. A expansão de AS-SET deve ser tratada como uma cadeia cujas fontes, idades e referências entre fontes importam. Exceções manuais devem ser temporárias e registradas.

Duplicatas obsoletas devem ser visíveis e corrigíveis.

A alternativa tentadora é a centralização: tornar uma fonte decisiva e exigir que todos os atores de mercado difiram. Isso responderia à fragmentação transformando um registro em um porteiro. A AFRINIC deve evitar esse caminho. Seu valor não está em aprovar cada transferência, aluguel, integração em nuvem ou mudança de provedor. Seu valor está em proteger um registro de continuidade estreito para que outros possam tomar suas próprias decisões de roteamento e comerciais de forma barata. A linguagem de mandato não deve lavar um papel de coordenação técnica em controle discricionário de mercado.

Estreiteza não significa fraqueza. Uma fonte confiável ainda pode ter autenticação forte, verificações de autorização proporcionais, caminhos de correção claros, rótulos de conflito, métricas públicas e procedimentos de continuidade. Atualizações rotineiras por mantenedores estáveis devem ser fáceis. Mudanças que alteram o AS de origem, removem um provedor anterior, adicionam cones de clientes amplos, afetam blocos escassos de IPv4 ou surgem durante disputas corporativas ou de governança devem exigir mais evidências e aviso. O teste é a proporcionalidade: pouca evidência convida ao abuso; muita evidência congela operações ordinárias.

O aviso deve fazer parte dessa proporcionalidade. Se uma mudança deslocaria uma origem existente ou removeria um objeto usado por filtros, os contatos afetados devem ser notificados quando viável: titular do recurso, mantenedor existente, origem proposta, origem atual e contatos operacionais relevantes. O aviso não deve se tornar um veto. É uma maneira de superfície erros antes que se tornem interrupções. Onde a urgência requer ação emergencial, a ação deve ser temporária, registrada e revisada.

Métricas tornariam o padrão crível. A AFRINIC e os principais operadores devem ser capazes de medir com que frequência os prefixos administrados pela AFRINIC têm objetos de rota ou route6 conflitantes entre fontes, com que frequência as expansões de AS-SET diferem por ordem de fonte, a idade das duplicatas obsoletas, a atualidade dos mirrors, quanto tempo levam as correções e quantos clientes exigem exceções manuais. Esses números não precisam expor arquivos privados de clientes. Eles diriam ao mercado se a fragmentação é uma anedota, um imposto crônico ou uma condição em melhoria.

A mesma disciplina deve ser aplicada às ferramentas. Sistemas de filtro devem expor caminhos de fonte: qual fonte, objeto, cadeia de AS-SET e regra de recursão produziu aceitação ou rejeição. Os titulares devem poder descobrir onde seus prefixos e ASNs aparecem nas principais fontes de IRR e route-sets. Servidores de rotas devem relatar categorias de rejeição que sejam inteligíveis para os membros. Registros históricos devem ser preservados para auditoria, mas a orientação do estado atual deve ser clara o suficiente para os operadores usarem. O objetivo não é um banco de dados perfeito.

É um ambiente de banco de dados no qual a incerteza é rotulada, limitada e barata de reduzir.

Esse padrão tornaria a vida mais fácil para o engenheiro do servidor de rotas enfrentando o trabalho de filtro ao amanhecer. Se várias fontes dessem respostas contraditórias, a ferramenta mostraria atualidade, postura de autoridade, caminho de fonte e idade do conflito. Uma ROA válida seria pesada para garantia de origem, mas não usada para ignorar AS-SETs obsoletos. A fonte vinculada à AFRINIC seria confiável porque seus procedimentos eram visíveis, não porque a instituição exigia deferência. Fontes externas seriam consideradas com suas limitações. O cliente receberia um caminho de limpeza claro em vez de uma rejeição misteriosa.

Julgamento ainda seria necessário, mas seria mais barato.

O custo de não corrigir a fragmentação

Se a fragmentação do IRR permanecer não gerenciada, o mercado ainda encontrará maneiras de rotear. A Internet é boa em rotear em torno da fraqueza institucional. Essa resiliência não deve ser confundida com saúde. O caminho de solução alternativa é previsível: grandes operadores constroem sistemas de confiança privados, plataformas impõem integração mais rigorosa, pequenas redes dependem de incumbentes, corretores precificam risco de limpeza, servidores de rotas apertam políticas, e clientes aprendem que serviços dependentes de endereços em algumas regiões requerem mais explicação.

Pacotes ainda podem fluir, mas a participação se torna mais cara e menos igualitária.

Para a AFRINIC, esse resultado seria prejudicial porque a região precisa de custos de coordenação mais baixos, não mais altos. Interconexão local, localização em nuvem, serviços digitais do setor público, redes universitárias, entrega de conteúdo regional e concorrência de pequenos provedores dependem todos de aceitação de roteamento previsível. Se cada migração ou integração pode ser atrasada por fontes de banco de dados contraditórias, a região paga um imposto silencioso.

O imposto aparece como projetos atrasados, maior dependência de trânsito, posições de barganha mais fracas, valores de ativos mais baixos e maior dependência de intermediários fora da região.

A segurança não melhoraria necessariamente. Políticas excessivamente estritas podem reduzir algumas rotas ruins, mas também empurram operadores legítimos para exceções manuais. Políticas excessivamente frouxas mantêm a autoridade obsoleta viva. Soluções privadas tornam o sistema menos transparente. O melhor resultado de segurança vem de evidências coerentes: dados atuais vinculados ao titular, AS-SETs limpos, RPKI onde apropriado, conflito de fonte visível e correção rápida. Fragmentação sem gerenciamento não produz nem abertura nem segurança. Produz opacidade seletiva.

O custo institucional seria igualmente sério. Um registro se recuperando de turbulência de governança precisa mostrar que suas funções básicas de utilidade são confiáveis. A coerência do IRR é uma dessas funções porque está próxima das operações diárias. Se a AFRINIC puder tornar os dados de política de roteamento mais limpos, mais transparentes e mais fáceis de corrigir, fortalecerá a confiança no registro sem pedir ao mercado confiança cega. Se não puder, as contrapartes criarão seus próprios sistemas de confiança.

Uma vez que esses sistemas se endureçam, a função pública do registro regional se torna menos central e os porteiros privados se tornam mais poderosos.

O custo de mercado aumentará à medida que a escassez de IPv4 persistir. A escassez eleva o valor de cada ambiguidade que pode afetar o uso: um objeto de rota obsoleto, uma entrada faltante de AS-SET, um atraso de mirror, uma preferência de fonte ou uma disputa de governança. Dados fragmentados de IRR transformam pequenos defeitos técnicos em opções econômicas detidas por quem pode explorá-los ou resolvê-los.

A resposta não é uma nova e dramática reivindicação de soberania sobre o roteamento. É uma redução disciplinada da ambiguidade. A AFRINIC deve ser um utilitário de continuidade estreito para os recursos que administra, com suporte de política de roteamento que seja confiável o suficiente para terceiros usarem e limitado o suficiente para não se tornar comando de mercado. Operadores devem publicar como consomem fontes e lidam com conflitos. Grandes fontes de IRR devem melhorar a descoberta de objetos obsoletos e o contexto de autoridade. IXPs e operadoras devem tornar as decisões de servidores de rotas e filtros de cliente explicáveis.

Compradores, corretores e credores devem tratar a postura de IRR como diligência, não folclore.

O trabalho do servidor de rotas ao amanhecer não deve ter que decidir o futuro institucional da numeração da Internet africana. Deve ter que decidir se uma rota é segura para aceitar sob uma política clara. Isso já é bastante difícil. Dados fragmentados de IRR tornam mais difícil ao apresentar vários passados plausíveis como se fossem presentes iguais. Em um mercado construído sobre números escassos e interconexão voluntária, essa confusão tem um preço.

A oportunidade da AFRINIC é reduzir esse preço. Não se tornando um porteiro sobre todo uso comercial de IPv4. Não pedindo aos operadores que ignorem fontes não regionais. Não fingindo que o RPKI elimina bancos de dados de política de roteamento. A oportunidade é mais estreita e mais valiosa: tornar o registro vinculado à AFRINIC e a fonte de política de roteamento confiáveis, expor conflitos, preservar a história, acelerar a correção, separar autenticação de autorização e ajudar os operadores a ver em qual fundamento institucional repousa cada reivindicação de banco de dados.

Se isso acontecer, os dados de IRR retornam ao seu papel econômico adequado. Tornam-se uma maneira de tornar a confiança mais barata, em vez de uma razão para cada rede comprar seu próprio mapa privado de dúvida.