AFRINIC e a economia da governança dos objetos de rota IRR

O mantenedor do servidor de rota já viu esse tipo de ticket. Um pequeno provedor de acesso deseja que um novo prefixo seja aceito em um exchange africano. O e-mail é educado e urgente. O cliente afirma que o prefixo pertence a uma fundação universitária que recentemente mudou sua hospedagem para um data center local. A carta de autorização é assinada por um diretor financeiro cujo nome não aparece no contato do registro. Um objeto de rota existe, mas seu AS de origem aponta para um antigo provedor de trânsito.

O AS-SET fornecido pelo cliente se estende a duas redes downstream e a um revendedor cujo mantenedor é controlado por uma empresa de serviços gerenciados em outro país. O contato do registro responde de um e-mail pessoal. O cliente afirma que a mudança é rotina, pois os pacotes já passam por um link de backup. A ferramenta do servidor de rota indica outra coisa: aceitar o anúncio no exchange poderia ajudar uma rota não autorizada a se propagar; rejeitá-lo e uma rede africana legítima poderia perder um caminho mais barato para a acessibilidade local.

A mesma cena se repete, com pequenas variações, nos departamentos de trânsito, filas de integração em nuvem, equipes de roteadores gerenciados e revisões de aprovisionamento empresarial. Ninguém nessas salas deveria confundir um objeto de rota com uma escritura de propriedade. Ninguém deveria tratá-lo como uma autorização de origem de rota criptográfica (ROA). No entanto, o registro ainda pode decidir se um prefixo entra em um filtro, se uma migração ocorre esta semana ou no próximo mês, e se um cliente é tratado como comum ou excepcional. Um operador precisa saber se um comprador de trânsito pode anunciar um bloco.

Um IXP precisa saber o que seus servidores de rota devem permitir. Um revendedor precisa convencer um provedor upstream de que sua delegação de cliente é real. Uma rede pública precisa de continuidade durante uma troca de subcontratado. Um data center precisa mover um cliente sem se tornar o elo fraco de um desvio. Em cada caso, uma antiga entrada textual em um registro de roteamento da Internet pode se tornar um bilhete prático para a economia de roteamento.

É aí que reside a importância das regras relativas aos objetos de rota da AFRINIC. As entradas de rota e rota6 RPSL são declarações operacionais prefixo-origem: elas associam um prefixo IP a um sistema autônomo de uma forma que os engenheiros de rede e softwares de filtragem podem consumir. Elas não constituem um título legal, nem uma ordem judicial, nem um certificado de membro, nem uma asserção RPKI assinada. Sua autoridade é mais flexível e mais institucional.

Mas como operadores, IXPs, provedores gerenciados, plataformas em nuvem e clientes frequentemente usam dados IRR para construir filtros de prefixo e origem, esses registros podem determinar se é fácil tornar um prefixo acessível. Em uma região onde a escassez de IPv4 tornou a aceitação operacional valiosa, uma comodidade de registro pode se tornar um guardião das sombras se seu propósito e regras de correção não forem estritamente definidos.

A história institucional recente da AFRINIC dá ao problema uma força incomum. O registro enfrentou estresse jurídico e de governança de longa data, relatos públicos sobre preocupações de desvio de IPv4, períodos de supervisão judicial, sequestro, uma eleição de 2025 anulada após alegações de irregularidades relatadas e uma subsequente restauração do conselho. Nenhum desses fatos prova que uma declaração de roteamento específica está errada.

Uma eleição difícil não mostra que um AS de origem carece de autoridade; uma batalha legal não mostra que um mantenedor está comprometido; um escândalo de endereços relatado não justifica tratar cada detentor histórico como suspeito. Mas o estresse institucional altera o custo da ambiguidade. Quando os canais de correção são lentos, contestados ou mal documentados, os registros operacionais ganham mais peso no mercado. A resposta não é transformar cada modificação de roteamento em um processo de propriedade. Trata-se de tornar a autoridade estreita, verificável, baseada em notificação e barata de corrigir.

O pequeno arquivo que se torna um cartão de embarque

O objeto de rota começou como uma forma de descrever a política de roteamento, não como um instrumento de mercado. No RPSL, a classe route especifica uma rota inter-AS originada de um sistema autônomo. Sua chave é o prefixo e o AS de origem. A classe route6 para IPv6 desempenha o papel equivalente, usando os atributos route6 e origin como chave. A forma é intencionalmente enxuta. Ela responde a uma pergunta operacional: se uma rede afirma que o AS X é a origem do prefixo P, existe uma entrada de registro afirmando isso?

Essa resposta é importante porque o BGP é permissivo. Um roteador que recebe um anúncio não sabe intrinsecamente se o AS anunciante está autorizado a ser a origem do prefixo. Os operadores adicionam, portanto, políticas. Eles podem rejeitar espaço não alocado, rotas muito específicas, rotas incompatíveis com dados RPKI ou rotas ausentes de uma lista de permissão derivada do IRR. Cada verificação responde a uma pergunta diferente. O registro IRR responde a uma pergunta restrita: alguém com a autoridade relevante publicou a declaração prefixo-origem que minha ferramenta espera?

Em um contexto fluido, esse arquivo permanece invisível. Um cliente pede para anunciar um prefixo. O provedor upstream vê uma entrada IRR limpa, um registro de detentor de registro, um contato correspondente à solicitação, possivelmente um ROA e um AS-SET que se expande como esperado. O ticket de provisionamento é fechado. O cliente obtém trânsito, o provedor contabiliza receita, o servidor de rota evita um erro óbvio e ninguém precisa de uma teoria de design institucional.

O atrito começa quando os registros divergem. Um prefixo pode ser registrado por uma organização, ter origem em outra, ser mantido por uma terceira, delegado a um cliente e apresentado a um servidor de rota por uma quarta. Isso não é necessariamente suspeito. As redes modernas são em camadas. Os detentores terceirizam o roteamento. Universidades contratam provedores de serviços. Agências públicas compram conectividade por meio de contratos-quadro. Data centers anunciam espaço de cliente. Revendedores agregam clientes atrás de seus próprios ASNs. Provedores de segurança gerenciados direcionam o tráfego durante ataques.

Um prefixo pode passar por várias mãos legítimas antes de chegar à pessoa que pede a um provedor upstream para aceitá-lo.

As operações em camadas criam uma carga de documentação. O detentor do registro pode controlar os direitos legais ou contratuais. O AS de origem pode controlar o anúncio BGP real. O mantenedor pode controlar a edição IRR. O cliente pode controlar a relação comercial. O transportador terceirizado pode controlar a aceitação. Se a entrada estiver desatualizada, ou se o mantenedor não representar mais o detentor, a ferramenta de filtragem pode converter papelada antiga em acessibilidade atual. Se o transportador rejeitar a solicitação, ele pode bloquear tráfego legítimo. Se ele aceitar, pode normalizar uma cadeia de autoridade fraca.

O pequeno arquivo se torna um cartão de embarque porque terceiros podem processá-lo mais facilmente do que podem processar a realidade institucional subjacente.

É por isso que o assunto pertence à economia institucional, não a um anexo administrativo do BGP. O custo de um registro pouco claro não é suportado apenas pelo registro. É suportado pelo provedor de acesso que perde um cliente, pelo exchange que precisa abrir uma exceção, pelo data center que não consegue concluir uma migração, pela rede pública que paga por uma revisão manual e pelo provedor upstream cuja equipe de segurança precisa decidir se confia em um documento que não pode verificar totalmente. Boas regras reduzem os custos de transação.

Regras fracas os transferem para o mercado, onde aparecem como atrasos, prêmios de risco, favores bilaterais e decisões de filtragem inconsistentes.

A declaração estreita do RPSL e suas vastas consequências

O RPSL foi projetado para que a política de roteamento pudesse ser expressa de forma estruturada. A RFC 2622 descreve a classe route como uma forma de especificar uma rota inter-AS originada de um AS, com o prefixo de rota e o AS de origem formando a chave da classe. A RFC 4012 estendeu posteriormente o RPSL para famílias de endereços adicionais e descreveu route6 como a contraparte IPv6. Esses documentos são âncoras técnicas, não manifestos comerciais. Sua importância para a AFRINIC é que eles definem a estreiteza da entrada. Um objeto route ou route6 não é uma declaração geral sobre quem possui um recurso.

É uma declaração prefixo-origem dentro de um sistema de política de roteamento.

Essa estreiteza é frequentemente perdida na prática. Um engenheiro de rede sob pressão pede "o objeto IRR" como prova de que um cliente pode anunciar um prefixo. O cliente produz a entrada. A entrada é tratada como prova de legitimidade porque a ferramenta de filtragem a consome. Se ninguém se opuser, a decisão operacional pode se tornar um fato de mercado. A rota é aceita, o tráfego flui, os contratos são executados e revisores posteriores podem supor que a própria aceitação provou a autoridade. O registro não mudou de natureza jurídica. Sua função social mudou.

A lacuna entre a natureza jurídica e a função operacional é onde a regulamentação importa. Se o registro for entendido de forma muito ampla, ele se torna um substituto de título. Quem pode criá-lo ou preservá-lo obtém alavancagem sobre a acessibilidade. Se for entendido de forma muito restrita, os operadores podem ignorá-lo e recorrer a cartas privadas, exceções ad hoc e confiança baseada em relacionamentos. Nenhum extremo é saudável. A entrada deve ser tratada como uma declaração operacional estruturada com limites conhecidos e requisitos de autoridade conhecidos.

A comparação com route6 ajuda porque mostra que o problema não é apenas um resquício da escassez de IPv4. As redes IPv6 também precisam de declarações prefixo-origem. IXPs e provedores upstream também constroem filtros para IPv6. Mas a escassez de IPv4 aumenta os riscos porque um único prefixo IPv4 aceito pode ter valor de mercado, um histórico de cliente e dificuldade de substituição. Uma entrada route6 desatualizada pode criar risco operacional; um objeto de rota IPv4 desatualizado também pode afetar a liquidez e o poder de barganha de um ativo escasso. O problema tem a mesma forma e intensidade diferente.

Esses registros também diferem dos ROAs. Um ROA faz parte do sistema RPKI e é validado por certificados de recurso criptográficos. Uma entrada IRR depende das regras do banco de dados, autenticação do mantenedor, seleção de fonte e confiança do operador. Comparar os dois só é útil se a comparação permanecer disciplinada. Os ROAs podem mostrar que um detentor de recurso publicou uma autorização de origem verificável criptograficamente no sistema de certificados. Os objetos de rota podem mostrar que uma declaração prefixo-origem existe em um registro de roteamento de acordo com as regras de atualização desse registro.

Muitos operadores usam ambos. Nenhum elimina a necessidade de entender quem tinha autoridade para publicar o sinal relevante.

A consequência prática é que a sintaxe sozinha não pode resolver as questões importantes. Quem pode criar a entrada quando o detentor do recurso e o AS de origem diferem? Quem pode excluí-la quando um relacionamento com o cliente termina? O que acontece quando duas fontes contêm origens diferentes para o mesmo prefixo? O que fazer se um mantenedor for controlado por um provedor terceirizado que não representa mais o detentor? O que fazer se o detentor for uma universidade cujo contato de registro se aposentou há anos? O que fazer se um síndico, liquidante, administrador supervisionado por tribunal ou agência pública reivindicar autoridade?

O RPSL fornece a forma. As regras institucionais determinam se a forma permanece confiável em mercados reais.

Mantenedores, credenciais e valor da autoridade de edição

O objeto mntner é o centro discreto do sistema. A RFC 2622 descreve os mantenedores como entidades autorizadas a adicionar, remover e modificar conjuntos de objetos. Isso parece administrativo. Em um ambiente dependente de filtros, a autoridade de edição tem valor econômico. A parte que pode criar, preservar ou remover uma entrada prefixo-origem pode influenciar o aparecimento de um prefixo nos filtros. A parte que pode controlar um AS-SET pode influenciar os ASNs de clientes incluídos em listas de permissão geradas recursivamente. A parte que pode atualizar campos de contato pode afetar quem recebe notificações.

A parte que pode autenticar alterações pode dar a aparência de ordem a uma declaração operacional mesmo quando a relação comercial subjacente é contestada.

A autenticação é necessária, mas insuficiente. Uma senha, chave, certificado, sessão de portal ou etapa de dois fatores pode mostrar que o usuário controla as credenciais do mantenedor. Isso não mostra por si só que o usuário ainda representa o detentor do recurso, o AS de origem, o cliente ou a parte com a delegação atual. Uma conta de e-mail corporativo pode permanecer válida após o término de um contrato. Um antigo provedor de serviços gerenciados pode reter as credenciais. Um revendedor pode ter acesso de edição para o prefixo de um cliente, mas nenhuma autoridade para autorizar uma nova origem.

Um funcionário pode controlar um mantenedor sem ter autoridade corporativa. Controles de login fortes reduzem a falsificação de identidade; eles não resolvem a questão do mandato.

Para a AFRINIC, a distinção é valiosa porque o estresse institucional e o valor de mercado dos endereços tornam a autoridade desatualizada mais cara. Se o acesso ao mantenedor for frouxo, as entradas podem ser criadas com muita facilidade. Se o acesso ao mantenedor for tratado como conclusivo, credenciais antigas podem se tornar armas econômicas. Se o acesso for muito difícil de recuperar, detentores legítimos com maus registros históricos podem ser excluídos dos próprios arquivos que os provedores upstream esperam que eles mantenham. O registro precisa, portanto, de um modelo de autoridade que separe autenticação de direito.

O erro mais simples é confundir autoridade do mantenedor com a do detentor. Um mantenedor pode estar anexado aos registros do detentor, mas a pessoa que o controla pode ser um subcontratado, um ex-administrador de rede ou um provedor terceirizado. O erro inverso é ignorar a autoridade do mantenedor e exigir prova completa do detentor do registro para cada pequena modificação. Isso tornaria as operações de rotina muito lentas, especialmente para pequenas redes que dependem de serviços gerenciados. A abordagem útil é em camadas. As atualizações de rotina por um mantenedor estável e validado devem ser rápidas.

As alterações que alteram o significado comercial da entrada, como um novo AS de origem, uma remoção contestada ou uma modificação após recuperação de conta, devem acionar controles mais rigorosos.

As regras de mantenedores também são uma forma de atribuir responsabilidade sem pretender eliminá-la. Um registro pode estar errado porque o detentor cometeu um erro, porque o cliente forneceu informações incorretas, porque o AS de origem mudou, porque um subcontratado não fez a limpeza, porque o processo do registro permitiu uma atualização não autorizada ou porque outro IRR copiou uma entrada antiga. A AFRINIC não pode absorver todos os erros operacionais da economia de roteamento. Mas pode exigir atribuição suficiente para tornar os erros corrigíveis.

Um log de alterações deve mostrar qual mantenedor agiu, sob qual conta autenticada, com qual base declarada e com qual notificação aos contatos relevantes. Essas evidências reduzem o custo de disputas posteriores.

O ônus de más práticas de mantenedor recai de forma desigual. Grandes transportadoras podem alocar pessoal para limpar registros em várias fontes. ISPs menores podem ter um único engenheiro que também cuida de quedas de energia, compras, escalonamento de clientes e segurança. Uma universidade pode não saber qual ex-subcontratado detém um mantenedor antigo. Uma rede governamental pode precisar de uma cadeia de cartas oficiais antes que um engenheiro possa sequer solicitar uma correção. Se as modificações dependem de conhecimento informal, essas organizações pagam mais.

Se o registro fornecer um processo de autoridade claro e restrito, elas podem competir com menos dependência de relacionamentos pessoais.

Cinco formas de autoridade que os operadores frequentemente comprimem em uma

A disputa que chega a um provedor upstream raramente chega em uma forma jurídica limpa. Chega como uma solicitação de cliente. O cliente pode dizer "nós possuímos este prefixo" quando quer dizer "nosso provedor de serviços nos disse que podemos anunciá-lo". Pode dizer "a AFRINIC tem o registro" quando quer dizer "há uma entrada em algum lugar com nosso AS". Pode dizer "o detentor nos autorizou" quando tem uma carta de uma pessoa que já foi o gerente de rede do detentor. O operador deve traduzir uma linguagem imprecisa em risco. Um bom processo ajuda separando as formas de autoridade que as operações frequentemente comprimem.

A primeira forma é a autoridade do detentor do registro. Esta é a organização reconhecida no registro do registro como detentora ou cessionária do recurso de numeração. É o ponto de partida para muitas decisões, mas não significa que o AS do detentor deva sempre originar o prefixo. Os detentores delegam o roteamento o tempo todo. Uma empresa pode usar o AS de uma transportadora. Uma agência pública pode terceirizar a infraestrutura. Uma universidade pode deixar uma rede de pesquisa transportar o tráfego. A autoridade do detentor é fundamental, mas não se executa automaticamente no BGP.

A segunda forma é a autoridade do AS de origem. O AS que origina o prefixo deve estar disposto e operacionalmente capaz de anunciá-lo. O AS de origem pode ser um provedor de trânsito, um cliente, um data center, uma rede de conteúdo, um provedor de mitigação DDoS gerenciado ou o próprio detentor. Sua autoridade pode derivar de um contrato, de uma relação com o cliente ou de uma delegação operacional. Uma entrada prefixo-origem só faz sentido se a relação subjacente existir e se a parte que a publicou tinha qualidade para fazer essa declaração.

A terceira forma é a autoridade do mantenedor. Esta é a capacidade de editar o registro IRR. É mais restrita do que a autoridade do detentor e do AS de origem, mas pode ser mais imediatamente poderosa porque os filtros dependem dos dados publicados. Um mantenedor pode pertencer ao detentor, à rede de origem, ao registro, a um subcontratado ou a um arranjo histórico. Seu controle não deve ser confundido com o direito pleno de decidir o futuro do recurso.

A quarta forma é a delegação do cliente. Um cliente pode ter uma carta, um contrato, uma aprovação de ticket ou uma ordem de serviço que o autoriza a rotear um prefixo por meio de um provedor específico. A delegação pode ser ampla ou restrita, temporária ou indefinida, revogável ou vinculada a um serviço pago. O provedor upstream ou o IXP precisa saber se ela cobre a origem, o comprimento do prefixo e o período solicitados. Uma carta autorizando "serviços de conectividade" pode não autorizar a criação de um objeto de rota para um AS diferente três anos depois.

A quinta forma é a aceitação por terceiros. Nenhum registro pode forçar cada transportadora ou IXP a aceitar uma rota. Os operadores decidem seus próprios filtros. Eles podem usar dados relacionados à AFRINIC, outros IRRs, RPKI, exceções manuais e um histórico de confiança privado. Sua aceitação também não é um título. É uma decisão operacional. Mas aceitação suficiente cria dependência, e rejeição suficiente pode destruir a usabilidade prática. É por isso que as formas de autoridade anteriores devem ser legíveis para terceiros.

Quando essas formas estão alinhadas, o sistema é monótono. Quando não estão, a questão não é "quem possui o número da Internet?" no abstrato. É "qual declaração operacional pode ser publicada, por quem, com qual notificação, para qual finalidade de roteamento, e como pode ser corrigida se a cadeia de autoridade estiver errada?" Esse enquadramento mantém o papel do registro restrito, ao mesmo tempo em que leva em conta o fato econômico de que os filtros transformam registros em condições de acesso.

Como os dados IRR se tornam filtros em operadores e exchanges

A RFC 7454 descreve a lógica operacional de forma simples. A filtragem de prefixos é uma parte essencial das operações BGP. As informações IRR podem ser usadas para construir, para um determinado AS vizinho, uma lista de prefixos originados ou transitados que podem ser aceitos. Um peer fornece um AS e, opcionalmente, um AS-SET; as ferramentas expandem o AS-SET recursivamente para obter os números AS; o operador então pesquisa os prefixos associados e constrói listas de prefixos e origens permitidas.

A RFC também adverte que os registros nem sempre são precisos, que os objetos variam ao longo do tempo, que a seleção de fonte é difícil e que os filtros devem ser atualizados regularmente. Ela recomenda a publicação e manutenção adequadas dos recursos no IRR do RIR quando disponível.

Essa é a ponte entre a disciplina do banco de dados e o custo de mercado. Uma entrada relacionada à AFRINIC pode ser consumida pela construção noturna de filtros de um provedor de trânsito. A configuração do roteador do provedor pode não conhecer a história por trás. Ela sabe apenas se um par prefixo-origem aparece em uma fonte que o provedor escolheu confiar. Se a entrada estiver faltando, desatualizada ou contestada, o cliente pode ser rejeitado automaticamente. Se estiver presente, mas não autorizada, a rota pode passar automaticamente. A decisão humana foi deslocada para upstream na curadoria dos dados.

A automação é economicamente necessária. Uma grande transportadora não pode examinar manualmente cada mudança de rota. Um servidor de rota IXP não pode operar com segurança com base em promessas informais. Um provedor gerenciado não pode tratar cada novo cliente como um processo jurídico personalizado. Os filtros derivados do IRR tornam o mercado mais barato, transformando a revisão repetida em software. Mas a automação também amplifica os erros de registro. Uma única entrada errada pode ser incorporada em muitos filtros. Uma única remoção pode retirar a aceitação de muitos peers.

Uma única regra de seleção de fonte pode privilegiar uma versão de uma disputa em detrimento de outra sem que as partes envolvidas percebam até que o tráfego falhe.

Os IXPs expõem o problema de forma aguda. Um servidor de rota de exchange não é apenas uma relação bilateral; é uma comodidade compartilhada para muitos membros. Se o servidor aceitar dados ruins, o risco se propaga. Se rejeitar de forma muito agressiva, pequenos membros perdem uma das principais vantagens de ingressar em um exchange: acessibilidade multilateral simples. Muitos IXPs africanos existem para reduzir a dependência de trânsito internacional caro e manter o tráfego local local.

Uma ambiguidade que poderia ser um incômodo em um grande mercado europeu pode ser um custo material em um ecossistema menor onde o peering local ainda está se aprofundando.

Os provedores de trânsito enfrentam um incentivo diferente. Eles querem vender serviço, evitar desvios e reduzir a carga de suporte. Um registro limpo permite que vendas e provisionamento ocorram. Um registro desordenado cria atrasos internos. Se a receita do cliente for baixa, o provedor pode recusar em vez de investigar. Essa recusa é racional para o provedor, mas cara para o mercado. Resulta em um viés a favor de clientes cujos dados já estão em ordem, cujos engenheiros conhecem o ritual ou cuja marca é grande o suficiente para justificar escalonamento manual.

A economia da filtragem depende, portanto, da qualidade dos dados upstream. A AFRINIC não controla a política de roteamento de cada operador, mas pode afetar o custo de usar registros relacionados à AFRINIC. Se a criação e a correção forem claras, os operadores podem confiar na fonte com menos exceções. Se a autoridade for opaca, os operadores desconfiam ou a usam com risco oculto. Ambos os resultados são caros. A desconfiança empurra as redes para evidências fragmentadas e exceções bilaterais. A confiança excessiva permite que entradas desatualizadas ou não autorizadas moldem a acessibilidade.

A recursão AS-SET e o poder discreto das listas delegadas

Os objetos de rota declaram pares prefixo-origem, mas os AS-SETs geralmente decidem como esses pares entram nos filtros em grande escala. Um cliente de trânsito pode dizer a um provedor upstream para construir filtros a partir de AS-CUSTOMER. Esse conjunto pode conter o AS do cliente, os ASNs de clientes downstream e outros AS-SETs. A recursão pode continuar por revendedores e redes gerenciadas. O resultado é uma grande lista de ASNs cujos prefixos associados são aceitos do caminho do cliente. O processo é eficiente quando os conjuntos são bem organizados. É arriscado quando se tornam desatualizados ou muito amplos.

A prática de AS-SET pertence à mesma discussão porque os dois instrumentos interagem. Se um conjunto inclui um ASN downstream e esse ASN tem objetos de rota para vários prefixos, o filtro de um provedor upstream pode aceitar esses prefixos do caminho do cliente. Se a relação downstream terminou, mas o conjunto não foi atualizado, o filtro pode continuar a permitir a aceitação. Se um revendedor adiciona um cliente sem evidência suficiente, o provedor upstream pode aceitar esse cliente indiretamente.

Se um conjunto de rotas inclui prefixos por referência a mantenedores, o controle do mantenedor pode moldar os prefixos que aparecem nas listas derivadas.

O risco não é apenas o desvio malicioso. Conjuntos muito amplos criam exposição acidental. Uma empresa de serviços gerenciados pode incluir todos os ASNs de clientes em um único conjunto por conveniência. Um data center pode esquecer de remover um locatário que saiu. Um pequeno ISP pode copiar uma estrutura recomendada por um provedor upstream sem entender a recursão. Uma universidade pode depender de uma rede de pesquisa que mantém arquivos para muitos campi. A saída do filtro parece técnica, mas reflete escolhas sobre delegação, custódia e limpeza.

Para a região da AFRINIC, as listas recursivas podem impor um custo de desenvolvimento. Muitos operadores dependem de provedores gerenciados porque não têm pessoal para manter cada arquivo de registro. Isso é razoável. Mas a dependência se torna um bloqueio se o provedor controlar o AS-SET e os objetos de rota que tornam os prefixos do cliente aceitáveis. Um pequeno ISP saindo de um acordo de trânsito gerenciado pode descobrir que o antigo provedor controla os registros necessários para o novo provedor. A disputa pode não ser sobre a propriedade legal do prefixo.

Pode ser sobre a capacidade prática de atualizar os dados que os filtros consomem.

Boas regras devem, portanto, tratar as listas delegadas como instrumentos operacionais revogáveis. A parte que controla um AS-SET deve ser identificável. A base para adicionar ASNs de clientes deve ser documentada. Deve haver um caminho simples para que um detentor de recurso ou o AS de origem atual conteste uma inclusão desatualizada. Deve haver aviso prévio antes da remoção quando a remoção pode interromper o serviço em andamento, a menos que uma razão de segurança urgente justifique uma ação mais rápida. O registro deve distinguir a rotatividade ordinária de clientes do uso não autorizado suspeito.

Essa distinção impede que a limpeza se torne uma arma.

A seleção de fonte complica a questão. Os operadores podem consultar vários IRRs e preferir algumas fontes a outras. Uma entrada limpa relacionada à AFRINIC pode ser substituída na prática por um registro desatualizado em outro lugar se a ferramenta do operador priorizar essa outra fonte. Inversamente, uma entrada desatualizada relacionada à AFRINIC pode ter mais credibilidade do que um arquivo de terceiros mais recente porque parece mais próxima do registro de recurso. Este artigo não é sobre a fragmentação global do IRR; o foco está na autoridade e correção relacionadas à AFRINIC.

No entanto, os próprios dados da AFRINIC devem ser bons o suficiente para que os operadores tenham uma razão para preferi-los. Dados de má qualidade com aparência autoritária são piores do que dados abertamente informais porque são mais propensos a serem automatizados nos filtros.

A recursão AS-SET é um multiplicador. Ela multiplica a confiança quando os registros estão limpos. Multiplica os erros quando a delegação está desatualizada. Amplia o acesso ao mercado para pequenas redes quando bem gerenciada. Aprofunda a dependência de intermediários quando a correção é difícil. A AFRINIC não pode tratar arquivos prefixo-origem como entradas isoladas se as mesmas decisões de aceitação são construídas por meio de conjuntos recursivos.

Registros obsoletos e contraditórios, impostos ocultos

O custo de uma má declaração de roteamento raramente aparece como um item de despesa. Aparece como uma semana de provisionamento atrasado, um cliente perdido, um domingo de engenheiro passado limpando dados de registro, um membro de exchange excluído de um servidor de rota, uma migração empresarial adiada, um ticket de suporte traduzido por três organizações, uma exceção manual que ninguém lembra depois ou um preço mais alto cotado por uma transportadora esperando problemas. Esses custos são reais mesmo quando o tráfego acaba fluindo.

A desatualização é o imposto mais comum. Um prefixo que antes era originado pelo AS A agora é originado pelo AS B, mas o registro antigo persiste. Algumas ferramentas podem aceitar ambos. Alguns operadores podem ver um conflito e rejeitar a solicitação. Alguns podem solicitar uma remoção que o cliente atual não pode efetuar porque o mantenedor pertence ao antigo provedor. A situação pode ser inofensiva em intenção, mas cara em tempo. A desatualização é particularmente cara em mercados onde o pessoal é limitado porque a pessoa que conhecia o arranjo inicial pode ter saído anos antes.

As duplicatas criam outro custo. Se o mesmo prefixo aparecer com origens diferentes, os operadores devem decidir se a situação reflete um roteamento multi-origem legítimo, uma migração em fases, engenharia de tráfego, um erro ou uso não autorizado. Arranjos multi-origem existem, e regras de remoção muito rígidas podem quebrá-los. Mas duplicatas sem contexto forçam terceiros a adivinhar. Um registro que as permite deve tornar a razão e a autoridade visíveis o suficiente para que os operadores possam interpretar o resultado.

Os conflitos entre fontes criam um custo mais sutil. Uma entrada relacionada à AFRINIC pode mostrar uma origem; um IRR comercial pode mostrar outra; um conjunto de rotas pode incluir um prefixo por referência; um ROA RPKI pode apontar para uma terceira origem ou estar ausente. A ferramenta da transportadora pode ser configurada para confiar em uma fonte para certos clientes e em outra fonte para outros. O cliente não vivencia isso como um pluralismo elegante. Ele vivencia um atraso arbitrário. Dizem-lhe para corrigir "o IRR" sem saber qual arquivo importa.

As entradas não autorizadas são o caso mais grave porque externalizam o risco. Uma parte que pode publicar uma declaração prefixo-origem plausível pode convencer algumas redes a aceitar uma rota antes que o detentor perceba. Mesmo que nenhum tráfego seja roubado, o registro pode poluir os filtros, criar trabalho de limpeza posterior e reduzir a confiança na fonte do registro. Em um ambiente IPv4 escasso, também pode apoiar modelos de negócios que dependem de controle aparente. Um comprador, locatário, cliente ou provedor de hospedagem pode confiar na entrada como parte de um dossiê de due diligence.

Quando o registro é corrigido, a cadeia de dependência se quebra.

O imposto oculto atinge particularmente as redes africanas que buscam reduzir os custos de conectividade. O peering local e o trânsito regional reduzem a dependência de longos caminhos internacionais. Mas o peering exige confiança. Se os registros de um pequeno operador estão desordenados, um servidor de rota pode rejeitá-lo ou seus peers podem evitar sessões bilaterais. Se os prefixos dos clientes de um data center são difíceis de validar, o data center pode usar um provedor upstream mais caro disposto a lidar com exceções.

Se as redes do setor público não conseguem limpar arquivos antigos, elas podem permanecer vinculadas a provedores estabelecidos por mais tempo do que a política de aquisição previa.

O argumento não é que cada entrada desatualizada é um escândalo. Os registros e operadores mantêm dados imperfeitos em todos os lugares. O argumento é que o custo da imperfeição aumenta quando os registros se tornam portas de entrada para conectividade rara e valiosa. Nesse ambiente, a regulamentação da AFRINIC é uma ferramenta de redução de custos. Ela reduz o custo ordinário de dizer sim a rotas africanas legítimas.

Os usuários que pagam quando a ambiguidade persiste

Os pequenos ISPs pagam primeiro porque carecem de poder de barganha. Uma grande transportadora pode persuadir um provedor upstream a criar uma exceção temporária. Um pequeno ISP é mais propenso a ouvir que volte quando seus objetos estiverem limpos. Isso pode parecer justo, mas pode reforçar a posição dominante. O pequeno ISP pode ser a rede que leva serviço a uma cidade secundária, uma área rural ou uma comunidade empresarial especializada. Se seus registros de prefixo são herdados de um revendedor, ex-subcontratado ou delegação de cliente, ele pode enfrentar semanas de atraso antes que um provedor aceite seu anúncio.

Um problema de rede se torna um problema de capital: a receita é atrasada enquanto os custos fixos continuam.

Os revendedores pagam de forma diferente. Seu negócio depende de montar conectividade, endereços, hospedagem e suporte em um pacote que os clientes possam comprar sem se tornar especialistas em roteamento. Um revendedor com má disciplina de registro se torna um risco para todos os upstreams. Um revendedor sujeito a regras de correção arbitrárias se torna comercialmente frágil. O objetivo político não deve ser estigmatizar a revenda. Deve ser tornar a delegação visível.

Se o revendedor está autorizado a rotear o prefixo de um cliente por meio de um AS nomeado para uma finalidade definida, a entrada deve dizer o suficiente para que os operadores entendam esse fato. Se a delegação terminar, a limpeza deve ser previsível.

Os data centers pagam pelo atrito da migração. Um cliente entrando em um data center pode trazer seu próprio espaço de endereçamento e esperar que a instalação o anuncie. Se a entrada existente ainda nomeia um antigo AS de trânsito, o data center não pode simplesmente pedir aos roteadores que obedeçam. Ele precisa de alinhamento de registro, autoridade do cliente, talvez um novo objeto de rota, talvez um AS-SET atualizado, talvez um ROA e, às vezes, a remoção de dados desatualizados. A proposta de valor do data center é velocidade e confiabilidade. Dados IRR ambíguos transformam a integração em uma investigação.

Os detentores históricos corporativos pagam porque sua história é frequentemente administrativamente desordenada. Uma empresa pode ter recebido espaço sob arranjos antigos, fundido várias vezes, terceirizado operações de rede e mantido endereços que ainda suportam acesso remoto, sistemas industriais ou serviços ao cliente. A pessoa que pode assinar um contrato pode não conhecer o mantenedor. A pessoa que conhece o mantenedor pode não estar autorizada a assinar. Se as regras de correção são muito rígidas, detentores legítimos podem ser incapazes de modernizar os registros.

Se as regras são muito frouxas, o espaço histórico se torna um alvo para reivindicações oportunistas. Evidências proporcionais são a única resposta viável.

As universidades pagam porque as redes acadêmicas frequentemente misturam autonomia e dependência. Uma universidade pode ter espaço histórico, uma relação com uma rede nacional de pesquisa, departamentos de TI do campus, provedores de hospedagem externos, laboratórios financiados por bolsas e contatos antigos. Um objeto de rota pode ter sido criado por um antigo provedor para um projeto de pesquisa já encerrado. Quando a universidade deseja mover o tráfego para um novo provedor, podem dizer-lhe para corrigir um registro do qual ninguém se lembra.

O interesse público não é servido forçando essas instituições a escolher entre um laxismo inseguro e uma papelada impossível. É servido por caminhos documentados para a autoridade que podem lidar com a continuidade institucional.

As redes do setor público pagam porque suas cadeias de autoridade são formais e lentas. Ministérios, municípios, sistemas de saúde e agências podem depender de subcontratados enquanto mantêm responsabilidade pública. Uma modificação de roteamento pode exigir uma carta, um processo de aquisição ou um agente nomeado. Se um subcontratado controla o mantenedor, a agência pode ter uma dependência prática de um intermediário privado. Se o registro insistir em uma única forma de prova, a agência pode falhar apesar do controle legítimo. Se aceitar qualquer carta, convida ao abuso.

As redes públicas precisam de categorias de evidência que reconheçam leis, nomeações, instrumentos de aquisição e obrigações de continuidade sem expor detalhes internos confidenciais ao registro público.

Esses grupos não são exemplos decorativos. Eles são o mercado. As regras de objetos de rota da AFRINIC reduzem seus custos operacionais ou os aumentam. Os debates sobre recursos escassos frequentemente se concentram em grandes detentores de endereços e disputas de alto valor, mas o valor econômico cotidiano de uma boa prática IRR é menor e mais amplamente distribuído: menos tickets, peering mais rápido, migrações mais limpas, menor dependência de operadores estabelecidos e menos necessidade de intervenção pessoal.

O estresse institucional e o preço da correção

O sistema de objetos de rota da AFRINIC não pode ser analisado como se a instituição tivesse passado por uma década tranquila. Relatos públicos desde 2019 descreveram sérias preocupações sobre desvio de IPv4 e abuso dos registros do registro. Disputas legais separadas colocaram o registro sob pressão intensa, incluindo envolvimento de tribunais, episódios de congelamento de ativos, descontinuidade do conselho e sequestro. Em 2025, um processo eleitoral do conselho foi anulado após preocupações com irregularidades relatadas, incluindo alegações sobre votos e procurações; uma eleição subsequente restaurou um conselho.

Relatos públicos posteriores descreveram esforços contínuos para reconstruir a gestão e o planejamento ordinários enquanto a pressão dos litígios permanecia.

Esses fatos devem ser usados com cautela. Eles não provam que um objeto de rota específico é inválido. Não significam que a equipe da AFRINIC não pode operar os serviços técnicos. Não justificam que atores externos tratem os registros relacionados à AFRINIC como culpados até prova em contrário. A lição é mais restrita: os caminhos de correção importam mais quando a confiança institucional foi testada. Se uma declaração de roteamento está errada, quem pode corrigi-la? Se duas partes discordam, quem recebe notificação? Se um mantenedor está comprometido ou desatualizado, como a autoridade é restaurada?

Se um período de liderança nomeada por tribunal ou restaurada pelo conselho altera quem pode agir para o registro, como os registros técnicos são isolados das turbulências institucionais?

O preço da correção tem três componentes. O primeiro é o tempo. Um prefixo que não pode ser aceito hoje pode perder um cliente hoje. O segundo é a incerteza. Se as partes não podem prever as evidências que o registro aceitará, elas coletam muitos documentos, contratam intermediários ou abandonam a mudança. O terceiro é a legitimidade. Se a parte perdedora não pode ver por que uma entrada foi criada, removida ou preservada, ela pode deslocar a disputa para acusação pública ou litígio. Regras de correção transparentes reduzem esses três custos.

O estresse também altera os incentivos. Quando um registro é criticado, pode evitar correções decisivas por medo de ser acusado de tomar partido. O atraso parece seguro internamente, mas externaliza os custos para os operadores. A tentação inversa é supercorrigir, usando a necessidade de reparar registros antigos como justificativa para um amplo controle discricionário. Isso pode parecer força, mas pode transformar modificações de roteamento de rotina em eventos políticos. A AFRINIC não precisa nem de paralisia nem de controle teatral. Ela precisa de procedimentos restritos suficientemente monótonos para sobreviver às críticas.

A história de apropriação ilícita de endereços é relevante porque mostra que falhas de integridade dos registros podem ter grandes consequências. A resposta correta não é uma presunção permanente de má-fé. É melhor controle de acesso, logs mais sólidos, separação de funções, verificações de autoridade documentadas, escalonamento para alterações de alto risco e rótulos públicos claros para o status dos registros. Um registro que experimentou abusos de registro deve se tornar mais preciso, não mais vago.

O episódio eleitoral de 2025 é relevante por uma razão semelhante. As alegações em torno do voto institucional não determinam a autoridade de roteamento. Mas lembram às entidades do mercado que os processos de governança podem ser contestados. Se a legitimidade está sendo reconstruída, os sistemas de correção técnica devem exigir menos confiança pessoal. Um detentor não deve precisar saber qual facção, qual oficial ou qual insider chamar. Um IXP não deve precisar adivinhar se uma solicitação de remoção reflete uma correção legítima ou um ponto de pressão institucional.

O próprio registro deve mostrar a categoria de processo, o status de notificação e a base da ação.

Isso importa porque as disputas de roteamento podem se tornar procuradores para conflitos mais amplos. Uma luta sobre uso de recursos, locação, controle de clientes, sucessão empresarial ou conformidade com políticas pode se manifestar como uma solicitação para criar ou remover uma entrada. O registro deve resistir às tentativas de ambas as partes de transformar um arquivo prefixo-origem em uma decisão final sobre tudo. Sua pergunta deve permanecer operacional: as evidências justificam a publicação, manutenção, anotação ou remoção desta declaração para fins de roteamento?

A remoção é governança, não faxina

A criação atrai mais atenção porque uma nova entrada pode permitir a acessibilidade. A remoção merece igual atenção porque a remoção pode desativar a aceitação. Um registro desatualizado não deve viver para sempre simplesmente porque a remoção é arriscada. Mas a remoção sem aviso pode quebrar um serviço real. O problema é distinguir a limpeza da perturbação.

Existem vários cenários de remoção. O mais fácil é a limpeza não contestada: o detentor ou o mantenedor autorizado atual remove uma entrada que todos concordam estar desatualizada. O segundo é a rotatividade de provedor: um antigo AS de origem persiste após a saída de um cliente. O terceiro é a delegação contestada: um cliente diz que ainda tem autoridade; o detentor diz que não. O quarto é a criação não autorizada suspeita: o arquivo parece ter sido criado sem qualidade. O quinto é a correção institucional: o registro descobre que os dados históricos ou o vínculo do mantenedor estão errados. Cada cenário requer um padrão diferente.

A rotatividade de provedor geralmente deve ser baseada em aviso prévio e limitada no tempo. Se um registro nomeia o antigo provedor como origem, a remoção pode ser necessária. Mas a remoção imediata pode prejudicar o tráfego se a migração for em fases ou se o antigo provedor ainda estiver fornecendo serviço de backup. O processo do registro ou do mantenedor deve permitir um período de correção definido, com notificações ao detentor, ao AS de origem, aos mantenedores relevantes e aos contatos publicados. Se nenhuma parte se opuser com evidências, a remoção prossegue.

Se uma parte se opuser, a entrada pode exigir uma anotação ou status temporário enquanto a questão restrita de roteamento é examinada.

A criação não autorizada suspeita pode justificar ação mais rápida, mas o padrão deve ser explícito. O registro deve perguntar se a entrada foi criada por um mantenedor com autoridade reconhecida, se o detentor ou o operador delegado foi notificado, se o AS de origem confirma a relação, se existe um ROA correspondente ou contrário, se a rota está ativa e se a remoção imediata criaria danos colaterais desproporcionais. Uma ação de emergência pode ser necessária, mas deve ser registrada, revisada e limitada no tempo.

A delegação contestada é mais difícil porque a modificação pode se tornar uma alavanca em uma disputa comercial. Um detentor pode querer cortar um revendedor. Um revendedor pode dizer que seus clientes dependem dele. Um provedor pode reivindicar faturas não pagas. Um cliente pode invocar um contrato. O registro não deve se tornar um cobrador de dívidas ou um árbitro comercial.

Deve perguntar apenas o necessário para a declaração de roteamento: quem pode autorizar esta origem para este prefixo agora, quais evidências sustentam essa reivindicação, qual notificação foi dada e qual período de transição protege usuários inocentes se o registro atual for retirado?

Os padrões de remoção também devem tratar duplicatas. Se duas entradas existem para o mesmo prefixo com origens diferentes, a resposta nem sempre é remover uma. Roteamento multi-origem, anycast, migração em fases e mitigação DDoS podem ser legítimos. A questão é se as razões estão documentadas e se os detentores e origens têm autoridade. Uma duplicata sem explicação deve acionar uma revisão; uma duplicata com autoridade clara e atual pode ser aceitável.

Tratar a remoção como um ato de política tem outra vantagem: reduz o incentivo para criar desorganização defensiva. Se os operadores temem que as entradas possam ser removidas de forma imprevisível, eles podem criar duplicatas em várias fontes, preservar membros antigos de AS-SET ou resistir à limpeza. Se a remoção for previsível, eles têm menos razões para manter reivindicações redundantes. Procedimentos limpos produzem dados mais limpos.

Regras de evidência para uma comodidade na qual os mercados confiam

O modelo de evidência correto para objetos de rota deve ser restrito em seu propósito e amplo nas evidências aceitas. Restrito no propósito significa que o registro pergunta apenas se um objeto route ou route6 deve existir como uma declaração operacional prefixo-origem.

Amplo nas evidências significa que diferentes atores podem mostrar autoridade de diferentes maneiras: registros do detentor do registro, documentos de autoridade corporativa, instrumentos do setor público, cartas de clientes, confirmações de provedores, histórico de roteamento, registros de tickets, logs de mantenedor, ROAs, BGP observado, entradas anteriores e documentos judiciais ou de insolvência, quando aplicável.

As evidências devem ser rotuladas de acordo com sua divulgação. Alguns fatos podem ser públicos: a existência da entrada, o AS de origem, o mantenedor, os carimbos de data/hora, o status e talvez uma categoria de motivo, como autorizado-pelo-detentor, delegado-pelo-cliente, confirmado-pelo-provedor, migração, multi-origem ou em-revisão. Alguns itens devem permanecer não públicos: contratos, documentos de identidade, tickets internos, relatórios de segurança, cartas governamentais, documentos de recuperação de conta e detalhes confidenciais de clientes. A transparência pública não exige despejar arquivos privados em um registro.

Exige estrutura suficiente visível para que os operadores entendam o status.

O registro também deve distinguir a força da evidência da adjudicação final. Uma confirmação do detentor atual mais uma confirmação do AS de origem pode ser forte o suficiente para criar uma entrada. Isso não prova que todas as relações comerciais por trás da rota são incontestáveis. Uma ordem judicial pode determinar quem pode agir para uma empresa, mas o registro ainda deve mapear essa ordem para uma modificação de roteamento. O BGP observado pode mostrar que uma rota está ativa, mas não prova que a rota é autorizada.

Um ROA pode apoiar a reivindicação de origem, mas o RPKI permanece aqui como um comparador e um sinal de apoio, não o centro da decisão.

A notificação faz parte da evidência. Antes de criar uma entrada que altera a origem aceita para um prefixo, o processo deve notificar os contatos do detentor, os mantenedores existentes, o AS de origem proposto e qualquer origem atual visível nos objetos existentes quando possível. Antes de remover, deve notificar as mesmas partes interessadas, a menos que condições de emergência justifiquem ação imediata. A notificação transforma a surpresa em processo. Dá às partes legítimas uma chance de corrigir os registros e dá ao registro um registro de quem não respondeu.

Os períodos de correção devem ser calibrados de acordo com o risco. Uma limpeza de rotina de um registro desatualizado pode permitir vários dias úteis ou uma janela operacional definida. Um desvio suspeito pode exigir suspensão temporária imediata seguida de revisão rápida. Um caso de continuidade do setor público ou universitário pode exigir mais tempo porque as cadeias de autoridade são mais lentas. O período de correção não deve se tornar uma forma de manter entradas ruins vivas indefinidamente; a urgência também não deve se tornar uma forma de contornar a revisão em disputas comerciais ordinárias.

Os logs de auditoria devem ser invioláveis e utilizáveis. O mercado não precisa ver os documentos privados, mas o registro deve manter quem solicitou a alteração, qual mantenedor a autenticou, quais contatos foram notificados, qual categoria de evidência foi aceita, quem aprovou o escalonamento, o que mudou e quando. Se a AFRINIC enfrentar críticas ou demandas judiciais posteriormente, o log deve mostrar o processo sem reconstruir a memória a partir de caixas de entrada. Para um registro se recuperando de estresse institucional, esse tipo de registro não é um luxo burocrático. É uma infraestrutura de legitimidade.

O modelo deve evitar requisitos uniformes. Um pequeno ISP pode não ter atas oficiais do conselho para uma atualização de rotina. Um ministério pode exigir cartas oficiais. Uma universidade pode provar continuidade por meio de alocações antigas, registros de rede e declarações de dirigentes institucionais. Um data center pode ter uma carta do cliente e um histórico de tickets. Um revendedor pode ter autorização do cliente e confirmação upstream. O registro deve exigir evidências proporcionais ao risco da ação e ao dano causado pelo atraso.

Continuidade, correção de emergência e revisão sob pressão

O trabalho em objetos de rota deve continuar mesmo quando a instituição não está calma. A experiência da AFRINIC mostra por quê. Os serviços técnicos não podem esperar que cada disputa de governança seja resolvida. Os operadores precisam dos dados do registro, entradas IRR, DNS reverso, atualizações de contatos e serviços de suporte ao roteamento para continuar funcionando durante um litígio, sequestro, transição do conselho ou mudança de liderança. O plano de continuidade deve, portanto, identificar as operações em objetos de rota como uma função técnica protegida, não como moeda de troca em um conflito institucional.

A continuidade começa com a separação de papéis. As pessoas que administram as alterações IRR devem ter autoridade clara de acordo com procedimentos documentados. As alterações de alto risco devem ser revisadas por mais de um papel. As alterações de emergência devem ser registradas e revisadas posteriormente. A liderança institucional deve definir a política, mas as correções individuais não devem depender da aprovação pessoal dos diretores, a menos que um caso realmente levante exceções políticas ou legais. Quanto mais rotineiro o processo, menos a autoridade de modificação se torna um prêmio em um conflito de governança.

A correção de emergência continua necessária. Se uma entrada não autorizada estiver sendo usada para apoiar um desvio ativo ou roteamento incorreto grave, esperar por um período de correção normal pode ser irresponsável. Mas o poder de emergência precisa de limites. Deve ser limitado a danos de roteamento, criação não autorizada, acesso comprometido do mantenedor, negação clara do detentor, conflito com evidências atuais mais fortes ou risco imediato a terceiros. Deve produzir um status temporário, notificação às partes interessadas, um curto período de revisão e um caminho para restaurar a entrada se a conclusão de emergência estiver errada.

A revisão deve ser suficientemente independente para contar e suficientemente restrita para ser rápida. A primeira revisão pode ser um escalonamento interno por pessoal não envolvido na alteração inicial. Uma segunda revisão pode envolver um painel técnico ou de resolução de disputas para casos difíceis. A revisão não deve decidir todas as questões de propriedade, contrato ou política. Deve decidir se a ação sobre o objeto de rota correspondeu ao padrão publicado.

Se as partes precisam de um tribunal ou árbitro para direitos mais amplos, o processo de roteamento pode preservar ou anotar o status operacional enquanto esses direitos são testados em outro lugar.

A linguagem de apelação deve ser prudente. Se cada modificação se tornar passível de apelação como se fosse uma revogação de recurso, o sistema congelará. Se nenhuma modificação puder ser revisada, a autoridade de modificação se torna muito poderosa. O meio-termo é a revisão operacional: uma notificação foi dada, a categoria de evidência era apropriada, a ação de emergência foi justificada, o período de correção foi razoável, a decisão foi registrada e novas evidências exigem correção? Isso é suficiente para disciplinar o processo sem convertê-lo em um tribunal de propriedade.

A continuidade também exige comunicação externa. A AFRINIC deve publicar métricas agregadas: quantas criações de objetos de rota, remoções, correções contestadas, ações de emergência e revisões ocorreram; o tempo médio de conclusão; quantas foram resolvidas por notificação; quantas envolveram mantenedores desatualizados; quantas envolveram problemas de autoridade do setor público, universitário ou histórico. Relatórios agregados reduzem o boato sem expor arquivos privados. Eles também permitem que os operadores avaliem a confiabilidade da fonte.

Um registro que reporta seu desempenho de correção é mais fácil de confiar do que um registro que pede confiança em silêncio.

Durante o estresse institucional, esses mecanismos fazem mais do que manter os roteadores limpos. Eles reduzem a recompensa econômica da captura da instituição. Se a autoridade de modificação é estreita, registrada, revisável e protegida pela continuidade, então ganhar influência sobre o registro é menos útil como forma de afetar o acesso ao mercado. Essa é uma vantagem de governança de uma regra técnica. Procedimentos estreitos podem reduzir os riscos políticos.

Um mercado mais acessível para a acessibilidade

O melhor sistema de objetos de rota não é aquele com a linguagem de aplicação mais dramática. É aquele que torna o roteamento legítimo ordinário barato. Um pequeno ISP deve ser capaz de fazer um prefixo válido ser aceito sem conhecer os hábitos privados de cada provedor de trânsito. Um data center deve ser capaz de migrar um cliente sem implorar por exceções. Uma universidade deve ser capaz de reparar uma entrada desatualizada sem provar toda a sua história institucional em público. Uma agência pública deve ser capaz de delegar o roteamento sem abandonar o controle prático a um subcontratado.

Uma transportadora deve ser capaz de construir filtros sem se perguntar se a fonte que usa é uma loteria.

Para a AFRINIC, o design deve começar pelo propósito. Os objetos route e route6 existem para suportar a publicação de política de roteamento e filtragem. Eles não devem ser tratados como título legal, substituto de RPKI, prova de virtude comercial, ferramenta de sanção para disputas não relacionadas ou uma licença ampla de operação. Seu poder vem de sua utilidade. Seu perigo vem do mesmo lugar. Porque são úteis, os mercados confiam neles. Porque os mercados confiam neles, regras fracas podem transformá-los em portas ocultas.

O design deve então definir a autoridade. A confirmação do detentor do registro, a confirmação do AS de origem, a autenticação do mantenedor, a delegação do cliente e a aceitação por terceiros são distintas. O processo deve dizer quais combinações são suficientes para criação, modificação, remoção e correção de emergência. Não deve fingir que um único identificador responde a todas as perguntas. Não deve permitir que um mantenedor desatualizado vença um detentor atual. Não deve permitir que um detentor interrompa uma rota delegada atual sem aviso prévio quando usuários inocentes dependem dela.

Não deve permitir que um AS de origem preserve um registro após o término da autoridade.

Vêm então as evidências. Os rótulos públicos devem informar aos operadores se uma entrada é ordinária, delegada, multi-origem, sob aviso, em revisão ou corrigida por emergência. As evidências não públicas devem ser preservadas sem expor detalhes confidenciais. Os logs de auditoria devem tornar possível a reconstrução posterior. Os períodos de correção devem dar às verdadeiras partes tempo para responder. A remoção deve ser tão disciplinada quanto a criação. A ação de emergência deve ser possível, mas limitada.

Vem finalmente a continuidade. O sistema deve continuar operando através de turbulências legais e institucionais. A restauração do conselho da AFRINIC importa, mas a governança restaurada será julgada no mercado por pequenos fatos operacionais: se os tickets fecham de forma previsível, se entradas desatualizadas podem ser corrigidas, se entradas contestadas são rotuladas em vez de ocultas, se alterações de emergência são revisadas, se os operadores podem ver o desempenho agregado e se o registro resiste ao uso de registros de roteamento como procuradores de lutas institucionais mais amplas.

Isso não é um apelo ao laxismo. Uma má prática de objetos de rota pode apoiar desvios, aceitação desatualizada, dependência de provedores antigos e uma economia cinzenta de autoridade aparente. Também não é um apelo ao maximalismo do registro. Um controle muito amplo pode excluir redes legítimas da acessibilidade, aumentar o custo de mudar de provedor e converter um banco de dados técnico em uma porta de mercado discricionária. A disciplina é mais restrita: tornar a boa declaração operacional fácil de publicar, tornar a má fácil de contestar e tornar cada modificação consequente suficientemente visível para ser digna de confiança.

O mantenedor do servidor de rota do início da história não precisa de uma teoria de propriedade. Ela precisa de uma razão confiável para aceitar ou rejeitar o prefixo. O cliente não precisa de um sermão sobre design institucional. Ele precisa de um caminho para provar autoridade sem perder a semana. O detentor não precisa que seu recurso escasso seja feito refém de credenciais antigas. O AS de origem não precisa que cada mudança de roteamento seja litigiosa. O exchange não precisa absorver a ambiguidade do registro em seu próprio risco. Uma boa prática de objetos de rota da AFRINIC serve a todos eles, reduzindo o custo da acessibilidade.

A economia é simples. Um objeto de rota é uma declaração operacional modesta. Em um mercado orientado por filtros, declarações modestas podem se tornar bilhetes de entrada. Se a AFRINIC mantiver seu propósito restrito, autoridade verificável, evidências rotuladas, caminhos de correção rápidos e revisão confiável, os objetos de rota reduzirão o custo da interconexão africana. Se ela os deixar se tornar obsoletos, opacos ou discricionários, eles aumentarão o preço de cada rede que precisa se explicar antes que os pacotes possam circular.