ARIN e a economia da fragilidade do banco de dados IRR

Resumo

• A fragilidade do banco de dados IRR na região do ARIN é um problema de fragmentação de fontes: o mesmo prefixo, ASN de origem, AS-SET ou relação de roteamento pode ser representado de forma diferente entre o ARIN, fontes espelhadas, repositórios do tipo RADb e bancos de dados de roteamento privados.
• A questão prática de mercado não é apenas se um único registro de rota é válido, mas qual fonte um provedor de trânsito, plataforma de nuvem, servidor de rotas IXP ou construtor de filtros escolhe acreditar primeiro.
• O limite autoritativo do ARIN importa porque os dados da fonte ARIN vinculados a recursos gerenciados pelo ARIN carregam um peso probatório diferente de dados não autoritativos ou de terceiros que ainda podem ser consumidos por filtros privados.
• O espelhamento e as cópias obsoletas criam "vidas após a morte" ocultas: um registro corrigido em um lugar pode continuar a afetar a filtragem em outro se outra fonte, espelho ou caminho AS-SET ainda apontar para a história antiga.
• A expansão de AS-SET agrava o problema, pois conjuntos recursivos podem puxar membros e prefixos de várias fontes, permitindo que a ordem da fonte se comporte como uma política econômica não reconhecida.
• Transferências de IPv4, integração em nuvem e participação em IXPs agora exigem diligência sobre a fonte IRR, especialmente para pequenos ISPs e operadoras do Caribe que não podem absorver exceções manuais facilmente.
• O RPKI melhora o ambiente de evidências, mas não elimina a fragilidade do IRR porque os filtros privados ainda usam dados IRR para políticas de roteamento, cones de clientes, associação a AS-SET e admissão operacional.

A fragilidade está nas fontes plurais, não em uma entrada incorreta

O primeiro erro é procurar um único registro quebrado. Em uma sala de transferência, um ticket de provisionamento de IXP, uma análise de traga-seu-próprio-IP para nuvem ou um caso de integração de trânsito, o problema muitas vezes surge como um desacordo entre fontes. Um banco de dados diz que o prefixo pertence ao novo ASN de origem do titular. Outro ainda reflete um antigo provedor de trânsito. Uma terceira fonte tem um registro de rota inserido anos antes por um engenheiro de rede que já saiu.

Um espelho apresenta dados que parecem atualizados porque a consulta funcionou hoje, mesmo que o registro subjacente tenha sido herdado de um arranjo operacional mais antigo. Um AS-SET expande-se por uma cadeia que inclui um membro inesperado, e o construtor de filtros trata o resultado como política de roteamento comum.

Isso é fragilidade do banco de dados IRR. Não é a mesma questão de quem pode publicar ou remover um registro específico de prefixo-origem. Essa questão mais restrita importa, mas está dentro de uma arquitetura de mercado maior. O problema maior é que o ambiente do Internet Routing Registry é plural. Ele é composto por fontes operadas por RIRs, repositórios comerciais e privados, espelhos, preferências de fonte locais, conjuntos recursivos, registros copiados, entradas abandonadas e ferramentas que traduzem essa evidência desigual em filtros privados.

O efeito econômico aparece quando uma rede precisa decidir em qual versão da história de roteamento acreditar.

O ARIN é um caso de teste útil porque sua região combina um mercado de transferência de IPv4 altamente desenvolvido com uma dependência operacional densa. Operadoras norte-americanas, plataformas de nuvem, redes de conteúdo, bancos, universidades, provedores de hospedagem, empresas de serviços gerenciados, agências públicas e operadoras do Caribe usam endereços cujo valor depende de serem aceitos por outros. O IPv4 escasso não é apenas registrado. Ele é roteado, filtrado, levado para plataformas de nuvem, financiado, alugado, triado reputacionalmente e incorporado em planos de continuidade do cliente.

Nesse ambiente, o custo da evidência IRR fragmentada não é acadêmico. É atraso, desconto, trabalho de exceção manual e, às vezes, alcançabilidade parcial.

A questão também é institucional. Um registro é mais legítimo quando preserva um livro-razão confiável de recursos numéricos escassos e facilita a prova operacional. Torna-se perigoso quando tenta transformar esse livro-razão em controle discricionário sobre todo uso comercial de endereços. A fragmentação do IRR testa esse limite pela outra direção. Se o ARIN fizer muito pouco para esclarecer a semântica autoritativa das fontes para recursos em sua região, repositórios privados e espelhos antigos preenchem o vácuo. Se tentar comandar todas as escolhas de filtragem, excede-se.

A resposta duradoura está entre esses erros: autoridade de fonte clara, semântica de publicação limpa, evidência responsável e limites explícitos sobre o que o registro do registro prova e não prova.

Este é um ensaio sobre seleção de fontes. O mesmo registro de rota pode ter significado operacional diferente dependendo se vem do ARIN, de uma fonte não autoritativa adjacente ao ARIN, do RADb, do IRR privado de um antigo provedor, de um espelho de outro repositório ou de um AS-SET expandido recursivamente. O mesmo prefixo pode parecer limpo para um upstream e suspeito para outro porque a ordem das fontes deles difere. A mesma transferência pode estar operacionalmente completa no livro-razão do ARIN e ainda incompleta no mundo dos filtros porque o comprador não encontrou todas as fontes que um aceitador privado consome.

O limite autoritativo do ARIN e a sombra dos dados não autoritativos

A distinção mais importante no ambiente IRR da região ARIN é a fronteira entre dados autoritativos e dados que apenas parecem úteis. Para recursos gerenciados pelo ARIN, um registro de roteamento da fonte ARIN vinculado ao titular reconhecido e gerenciado através do framework de controle de recursos do ARIN tem um caráter probatório diferente de um registro que está em um repositório de terceiros. Isso não significa que repositórios privados sejam inúteis. Significa que não devem ser confundidos com a declaração do próprio registro sobre um recurso sob sua responsabilidade de coordenação.

O limite do tipo ARIN-NONAUTH é útil precisamente porque nomeia a ambiguidade. Uma fonte não autoritativa pode conter dados operacionalmente relevantes. Pode descrever um arranjo real de cliente, uma migração histórica ou uma rota que já funcionou. Mas não é a mesma coisa que uma declaração autoritativa da fonte ARIN ancorada no livro-razão de recursos do ARIN. Se os filtros privados tratam essas categorias como iguais, eles convertem conveniência em autoridade oculta. Se os operadores ignoram completamente os dados não autoritativos, podem perder a evidência de que um upstream ou servidor de rotas está realmente usando.

O ponto não é abolir uma categoria. O ponto é evitar a confusão de categorias.

Em um ambiente de baixo valor, a confusão de categorias poderia ser tolerável. Uma pequena inconsistência seria resolvida com um ticket, um telefonema ou uma exceção manual. No mercado atual, a inconsistência pode afetar o preço de transferência, o cronograma de liquidação, a migração para nuvem, a admissão em IXP e a continuidade do cliente. Um comprador de espaço IPv4 pode receber o status de transferência reconhecida pelo ARIN e ainda descobrir que uma entrada do tipo RADb, uma fonte de provedor antigo ou um registro não autoritativo é a primeira coisa que uma ferramenta de filtro vê. O comprador não perdeu o recurso.

Ele herdou um ônus de prova.

O limite autoritativo também importa para os vendedores. Um vendedor que tem registros limpos no ARIN, mas deixa dados de rota antigos de terceiros no lugar, não entregou uma história operacional limpa. O vendedor pode dizer, com precisão, que o ARIN reconhece a transferência. O comprador pode responder, também com precisão, que os filtros privados não consultam apenas o ARIN. A disputa não é sobre propriedade metafísica. É sobre qual evidência pode ser lida pelas redes cuja aceitação torna o bloco útil.

O papel do ARIN deve ser disciplinado. Ele não deve alegar ser o tribunal global de toda fonte IRR. Não pode e não deve ordenar que cada rede privada prefira dados do ARIN em cada filtro. Mas pode tornar o limite da fonte ARIN mais difícil de interpretar mal. Pode publicar semânticas de fonte que separam dados autoritativos de recursos gerenciados pelo ARIN de material não autoritativo ou de terceiros. Pode deixar claro que uma transferência de reconhecimento de registro não é uma garantia de que toda fonte IRR externa foi limpa.

Pode ajudar os titulares a identificar a diferença entre o estado mantido pelo ARIN e os dados que sobrevivem fora do controle do ARIN.

Esse limite também protege o ARIN de exceder-se. O registro não deve se tornar um regulador geral de rotas só porque os filtros privados são bagunçados. Sua função central é mais restrita: unicidade, reconhecimento atual de recursos, contatos responsáveis, continuidade de serviço e evidências adjacentes ao roteamento que as redes possam avaliar. Se a fonte é autoritativa, diga o porquê. Se a fonte não é autoritativa, diga claramente. Se um registro foi espelhado, preserve a origem da alegação. Os mercados podem tolerar incerteza quando a incerteza é rotulada. Tornam-se frágeis quando os rótulos desaparecem.

O espelhamento faz dados antigos parecerem vivos

O espelhamento é útil porque torna os dados disponíveis. É perigoso porque pode fazer dados antigos parecerem vivos. Um operador consultando um servidor IRR pode não perceber se a resposta veio da fonte original, de uma cópia espelhada, de um espelho obsoleto de uma fonte anteriormente válida ou de um repositório que mantém dados históricos por mais tempo do que a relação operacional sobrevive. A consulta tem sucesso, a resposta é estruturada e o prefixo aparece em um formato que as ferramentas podem consumir. Isso é suficiente para muitos filtros prosseguirem.

Esta é a tranquila vida após a morte dos dados de roteamento. Um registro pode ser corrigido em um lugar, mas ainda visível por outro caminho. Um provedor antigo pode atualizar sua própria fonte, enquanto um cronograma de atualização de espelho fica para trás. Um repositório comercial pode reter uma rota registrada por proxy por conveniência. Um IRR privado pode ser espelhado por um par que não percebeu que a fonte mudou. Um AS-SET pode apontar para uma fonte cujos membros incluem dados mais antigos.

Um servidor de rotas pode reconstruir diariamente, mas a partir de uma lista de entrada que dá a um espelho obsoleto mais peso do que uma fonte autoritativa corrigida.

O problema econômico é que a parte que tenta rotear paga pela história. Um comprador de transferência não pode simplesmente dizer: "O ARIN agora me reconhece". Ele precisa perguntar quais fontes de dados cada contraparte importante consome. Uma equipe de nuvem pode perguntar por que a origem antiga ainda aparece. Um provedor de trânsito pode rejeitar até que o conflito seja resolvido. Um servidor de rotas de troca pode não explicar qual fonte causou a negação. Um credor ou consultor pode marcar o bloco como operacionalmente bagunçado. Os dados antigos se tornam um pequeno imposto sobre o titular atual.

O espelhamento também obscurece a responsabilidade. Se um registro obsoleto é consultado a partir de um espelho, quem deve corrigi-lo? O titular pode não controlar a fonte original. A fonte original pode dizer que os dados já foram alterados. O operador do espelho pode tratar o problema como um problema de atualização, e não um problema de autoridade. A rede que consumiu o espelho pode não divulgar sua lista de fontes. O resultado é um exercício de prova de quatro pontas em torno de um registro que pode ter começado como uma conveniência de roteamento comum.

É por isso que a proveniência da fonte importa tanto quanto o conteúdo. Uma resposta IRR útil não deve apenas relatar dados de prefixo, origem e mantenedor. Deve preservar informações de fonte suficientes para que o leitor saiba de onde veio a alegação e se os dados são autoritativos para o recurso em questão. Se um espelho está envolvido, o leitor deve entender que é um espelho. Se uma fonte é não autoritativa, o leitor não deve ser autorizado a inferir autoridade a partir da formatação. Se um registro é antigo, as informações de última modificação e frescor devem ser fáceis de encontrar e fáceis para as ferramentas reterem.

Para o ARIN, a lição não é que o espelhamento é ruim. O ecossistema de políticas de roteamento da Internet depende da replicação, alcançabilidade e conveniência de consulta. A lição é que a evidência replicada precisa de identidade clara. Uma função de livro-razão que é confiável na fonte ainda pode perder força se os espelhos borrarem a autoridade. O registro pode publicar dados atuais, mas o mercado consome cópias. Se as cópias não carregam semântica de fonte, o mercado vê um mundo plano: uma resposta entre muitas, todas moldadas como RPSL, todas aparentemente capazes de influenciar filtros.

O espelhamento transforma a publicação em uma cadeia de suprimentos. Uma cadeia de suprimentos defeituosa não é consertada apenas consertando a fábrica se os distribuidores continuam enviando estoque antigo. Em termos de IRR, a fonte autoritativa pode ser a fábrica, mas o servidor de rotas, o provedor de trânsito e o balcão de nuvem geralmente recebem os bens através de intermediários. A fragilidade vive nessa distância.

RADb e IRRs privados fazem parte do mercado, não estão fora dele

O RADb e outras fontes IRR não-RIR ou privadas são frequentemente tratadas como um incômodo nas discussões de políticas, mas elas fazem parte do mercado real. Elas existem porque os operadores precisavam de algum lugar para publicar políticas de roteamento, dados de rota de clientes e informações de AS-SET quando os bancos de dados dos RIRs estavam incompletos, difíceis de usar, lentos para se adaptar ou não eram autoritativos para o recurso sendo descrito. Elas também existem porque redes privadas tomam decisões de roteamento privadas.

Uma grande operadora, provedor de serviços gerenciados ou data center pode manter registros para clientes porque isso reduz o atrito de provisionamento.

O resultado é uma economia probatória mista. Alguns registros de terceiros estão obsoletos. Alguns são descuidados. Alguns são registros de proxy que deveriam ter sido aposentados. Alguns são a única evidência legível por máquina que um pequeno cliente pode fornecer a um upstream. Alguns descrevem relações legítimas de cliente-provedor que o próprio ARIN não deveria tentar julgar. Alguns são conveniências comerciais. Alguns se tornam passivos operacionais anos depois. Tratar todos os dados de terceiros como lixo é errado. Tratar todos como equivalentes a dados de registro autoritativo também é errado.

Fontes do tipo RADb têm uma importância particular na região do ARIN porque a região tem muitos titulares legados, clientes de nuvem, arranjos de endereços alugados, clientes de data center, redes gerenciadas e compradores de transferência cujas relações de roteamento não se encaixam em uma história simples de titular-origem. Uma empresa pode possuir um bloco, mas rotear através de um provedor. Uma universidade pode usar um intervalo legado através de uma rede de consórcio. Um cliente de nuvem pode precisar de um ASN de plataforma durante uma migração. Um provedor caribenho pode depender de um upstream que mantém registros em seu nome.

Dados de IRR privados podem refletir essas relações melhor do que uma linha de titular simples. Mas essa utilidade operacional não responde à questão da autoridade.

A questão da autoridade é: o que a fonte prova? Um registro de terceiros pode provar que alguém publicou uma alegação de roteamento naquele repositório. Pode ser evidência de que um upstream esperava uma rota. Pode ser uma entrada útil para um filtro. Pode apoiar uma relação de serviço. Não prova, por si só, o controle de recursos atual reconhecido pelo ARIN. Quando os filtros privados não mantêm essa distinção, uma fonte privada pode ganhar poder prático sobre um recurso escasso sem assumir responsabilidade em nível de registro.

É aqui que a economia institucional ajuda. Um repositório privado reduz os custos de transação para participantes que entendem seus limites. Aumenta os custos sistêmicos quando estranhos confiam nele sem entender esses limites. O mesmo registro do tipo RADb pode ser útil entre um provedor e seu cliente, mas prejudicial se um futuro comprador, plataforma de nuvem ou servidor de rotas o confundir com autoridade atual do titular. O valor do registro depende do contexto. A fragilidade aparece quando o contexto é removido pelo espelhamento e pela geração automatizada de filtros.

A resposta construtiva não é exigir um mundo puro com apenas dados de RIR. A política de roteamento é diversa demais para isso. A resposta é tornar explícita a qualidade da fonte e alinhar a preferência de fonte com a cadeia de autoridade do recurso. Para espaço de endereços gerenciado pelo ARIN, dados atuais da fonte ARIN normalmente devem ter peso especial como um sinal adjacente ao livro-razão. Dados de terceiros devem ser tratados como evidência de relacionamento, não como prova final de autoridade de recurso.

Onde dados de terceiros conflitam com dados autoritativos do ARIN, o conflito deve desencadear uma explicação em vez da aceitação cega de qualquer fonte que apareça primeiro em uma ferramenta local.

Essa distinção melhoraria o mercado. Os vendedores saberiam quais registros externos devem ser divulgados. Os compradores saberiam o que estão herdando. Os upstreams poderiam usar fontes privadas sem fingir que são provas equivalentes a títulos. Os IXPs poderiam construir políticas de fonte que sejam claras o suficiente para que os membros corrijam erros. O ARIN poderia preservar a disciplina do mandato esclarecendo sua própria fonte em vez de reivindicar comando sobre todas as outras.

A recursão de AS-SET é onde a fragilidade se agrava

Os AS-SETs são onde a fragilidade do IRR deixa de ser uma lista de registros isolados e se torna uma rede de suposições herdadas. Um registro de rota diz que se espera que um prefixo se origine de um ASN. Um AS-SET diz quais ASNs, ou quais outros AS-SETs, pertencem ao cone de roteamento ou grupo de políticas de um cliente. Os construtores de filtros geralmente começam com um nome de AS-SET, expandem-no recursivamente, coletam prefixos relacionados e geram listas de prefixos ou políticas de rota. Se a cadeia AS-SET cruza fontes, dados obsoletos podem se multiplicar silenciosamente.

A recursão importa porque a primeira pergunta pode ser inocente: "Qual é o seu AS-SET?" Um cliente fornece um nome. A ferramenta do provedor o procura em uma lista de fontes. Se o mesmo nome existe em mais de uma fonte, a ordem da fonte pode decidir qual conjunto é usado. Se um conjunto inclui outro conjunto, a ferramenta segue a cadeia. Se um conjunto membro aponta para uma fonte antiga, o filtro pode puxar ASNs antigos. Se os registros de rota para esses ASNs são extraídos de várias fontes, a lista final de prefixos pode incluir rotas que ninguém revisou recentemente.

No momento em que o filtro é implantado, a entrada parece autoritativa porque se tornou configuração.

Isso não é uma fraqueza teórica. É um dispositivo de escalabilidade cotidiano. As grandes redes não podem aprovar manualmente cada prefixo downstream. Os IXPs não podem construir manualmente o cone de clientes de cada membro. As operações de nuvem e trânsito não podem depender de e-mails personalizados para cada rota. A expansão de AS-SET transforma declarações de roteamento dispersas em política legível por máquina. Isso é valioso. O perigo é que a recursão esconde o caminho pelo qual uma fonte antiga ou fraca entrou na decisão final.

Para um comprador de transferência, isso pode ser caro. O comprador pode limpar os registros de rota do bloco adquirido e ainda descobrir que um AS-SET antigo controlado por um antigo provedor puxa o prefixo de volta para um caminho de política obsoleto. Um pequeno ISP pode atualizar seu próprio conjunto, mas deixar um membro cliente em uma fonte privada que se expande de forma diferente em diferentes upstreams. Um data center pode pedir a um cliente para usar um AS-SET mantido pelo provedor porque isso se adapta às ferramentas do provedor, enquanto outro par insiste em um conjunto qualificado por fonte em outro lugar.

Um servidor de rotas pode rejeitar porque o AS-SET declarado pelo membro não inclui a combinação exata de origem-fonte que o servidor espera.

A recursão de AS-SET também cria problemas de nomenclatura. Nomes que não são qualificados por fonte podem colidir. Um conjunto em um repositório pode não ser o conjunto que uma ferramenta escolhe. Um cliente pode assumir que o provedor está expandindo um conjunto atual, enquanto a lista de fontes do provedor encontra um conjunto mais antigo primeiro. Um grande operador pode conseguir corrigir isso por meio de coordenação direta. Um pequeno operador pode receber apenas uma rejeição que diz que seu AS-SET está errado. A diferença não é apenas conhecimento técnico. É poder de barganha.

Uma boa higiene de IRR, portanto, requer visibilidade da cadeia. Um construtor de filtros deve ser capaz de informar a um cliente não apenas que um prefixo foi rejeitado, mas qual caminho AS-SET e fonte produziram a rejeição. Um titular deve ser capaz de auditar quais conjuntos nomeiam seu ASN ou prefixos. Um arquivo de diligência de transferência deve incluir não apenas registros de rota para o bloco, mas referências de AS-SET que podem fazer com que a antiga história de roteamento persista. Um servidor de rotas deve incentivar o uso de AS-SET qualificado por fonte onde a ambiguidade é provável. Essas práticas não eliminam a recursão.

Elas tornam a recursão inspecionável.

O RPKI não resolve esse problema específico porque o RPKI não modela cones de clientes. Um ROA pode dizer que um AS pode originar um prefixo. Não diz quais ASNs pertencem ao AS-SET de um cliente, se um provedor deve aceitar uma rota downstream ou se um servidor de rotas deve incluir os clientes de um membro nos filtros gerados. Os dados IRR continuam sendo a linguagem das relações de política de roteamento. É por isso que a fragilidade do AS-SET permanece economicamente importante mesmo em um mercado mais consciente do RPKI.

A ordem das fontes é uma política econômica oculta

A ordem das fontes soa como uma preferência de engenharia. Na prática, pode se comportar como política econômica. Um construtor de filtros pode consultar o ARIN primeiro, depois o RADb, depois o RIPE, depois um repositório privado. Outro pode colocar o RADb primeiro porque seus clientes historicamente o usaram. Outro pode preferir o RPKI para validação de origem, mas ainda usar várias fontes IRR para geração de listas de prefixos. Um servidor de rotas IXP pode publicar uma lista de fontes padrão. Uma operadora pode manter sua lista privada.

O resultado é que duas redes podem avaliar a mesma alegação de rota de forma diferente sem que nenhuma delas seja irracional.

Quando a ordem das fontes difere, os resultados comerciais diferem. Um prefixo aceito por um upstream pode ser rejeitado por outro. Uma solicitação de integração em nuvem pode passar depois que um revisor humano der prioridade à evidência atual do ARIN, enquanto um filtro de trânsito rejeita porque um registro de terceiros mais antigo aparece primeiro. Um comprador pode acreditar que a limpeza está completa porque seu consultor consultou uma ordem de fontes, enquanto o provedor preferido do comprador usa outra.

Um pequeno ISP pode perder uma semana descobrindo que "incompatibilidade de IRR" realmente significa "nossa ferramenta preferiu uma fonte não autoritativa que você não sabia que consumíamos".

Essa política oculta tem efeitos distributivos. Grandes redes podem pedir exceções, persuadir pares e manter contatos diretos com equipes de filtros. Redes menores frequentemente não podem. Um grande cliente de nuvem pode receber uma explicação cuidadosa; uma pequena empresa de hospedagem pode receber uma resposta padrão. Uma operadora nacional pode executar sua própria política de fontes; um provedor de acesso caribenho pode estar vinculado às escolhas de dois fornecedores de trânsito disponíveis. A ordem das fontes, portanto, aloca custos fixos. Ela decide quem deve limpar qual banco de dados antes que a receita possa continuar.

A natureza oculta da ordem das fontes também distorce os preços. Um comprador de transferência pode exigir um desconto se o bloco parecer bagunçado sob listas de fontes comuns. Um vendedor pode resistir, dizendo que o estado autoritativo do ARIN está limpo. Ambos podem estar certos. A diferença de valor vem da probabilidade de que contrapartes importantes prefiram dados obsoletos ou não autoritativos antes de verem o estado limpo. Essa probabilidade é difícil de precificar se a ordem das fontes é opaca. Torna-se um prêmio de risco.

A melhor disciplina é a transparência, não a uniformidade. Seria irrealista exigir que todas as redes usem as mesmas fontes IRR na mesma ordem. As redes têm diferentes históricos, clientes, posturas de segurança e apetites de risco. Mas as redes que rejeitam rotas por causa de dados IRR devem divulgar o suficiente para que o titular possa corrigir o problema. Se a rejeição veio de um conflito de fonte específico, diga qual fonte. Se o problema veio de um caminho AS-SET, mostre o caminho. Se a rede prefere dados da fonte ARIN para recursos ARIN, diga isso. Se prefere uma fonte comercial ampla por razões operacionais, torne o risco visível.

A ordem das fontes é onde o código em execução revela a realidade institucional. As reuniões podem descrever um banco de dados como autoritativo, mas a lista de fontes do construtor de filtros decide se essa autoridade é lida primeiro, depois ou nunca. Um mercado de endereços construído em torno do IPv4 escasso não pode ignorar esse fato. Se a ordem das fontes está oculta, os participantes do mercado estão negociando ativos cujas regras de aceitação eles não podem ver completamente. Se a ordem das fontes é visível, o mesmo mercado pode precificar a limpeza, atribuir responsabilidade e reduzir surpresas.

O objetivo não é tornar cada filtro privado obediente ao ARIN. O objetivo é tornar a filtragem privada inteligível o suficiente para que a autoridade atual do recurso não seja derrotada por acidente, inércia ou uma preferência não examinada por dados antigos.

Tratamento de conflitos: silêncio, preferência e ônus

Os conflitos não são exceções raras. São subprodutos normais de um mundo de registro de roteamento plural. O mesmo prefixo pode aparecer em várias fontes. Uma origem antiga pode coexistir com uma nova origem. Um AS-SET pode incluir um membro que não pertence mais. Um repositório privado pode descrever uma relação de cliente que o ARIN não pode ver. Um espelho pode estar atrasado. Um servidor de rotas pode ler uma resposta enquanto uma plataforma de nuvem lê outra. O tratamento de conflitos determina se essa pluralidade permanece gerenciável ou se torna uma penalidade de mercado.

Existem três maneiras básicas de lidar com conflitos: silêncio, preferência e transferência de ônus. Silêncio significa que a rede rejeitante dá pouca explicação. O titular aprende apenas que sua rota não passou. Preferência significa que a rede tem uma hierarquia de fontes ou regra de decisão, seja pública ou privada. Transferência de ônus significa que o titular atual deve provar por que a fonte obsoleta ou conflitante deve ser ignorada. A maioria dos sistemas reais combina os três. A questão econômica é quem paga quando eles colidem.

O silêncio é o mais caro para pequenos atores. Uma grande rede pode diagnosticar executando suas próprias ferramentas e ligando para pares. Um pequeno ISP pode não saber se o problema é um registro RADb obsoleto, um resíduo do tipo ARIN-NONAUTH, um atraso de espelho, uma colisão de AS-SET, um qualificador de fonte ausente ou uma incompatibilidade de RPKI. Quanto mais longo o diagnóstico, mais o operador paga em tempo perdido. Em um mercado caribenho com opções de trânsito limitadas, o atraso pode significar custo de atacado mais alto, pior desempenho para o cliente ou prazos de serviço perdidos.

A preferência pode ser eficiente se for clara. Um servidor de rotas que diz que prefere dados autoritativos de RIR para recursos na região relevante, e então usa fontes de terceiros selecionadas para dados de relacionamento, dá aos membros um caminho previsível. Um provedor de trânsito que diz que consulta fontes especificadas em ordem especificada permite que os clientes testem antes da ativação. Um provedor de nuvem que explica como reconcilia dados do ARIN, ROAs e registros IRR reduz o risco de integração. A preferência torna-se problemática quando está oculta, mas é tratada como verdade objetiva.

A transferência de ônus é inevitável, mas deve ser disciplinada. Se um titular atual quer que outros ignorem um registro antigo de terceiros, deve fornecer evidências. Se uma origem delegada quer manter uma rota aceita, deve mostrar autoridade atual. Se um provedor mantém um AS-SET de proxy, deve mantê-lo atualizado. Mas o ônus não deve ser infinito. Uma vez que a autoridade atual da fonte ARIN, a postura atual do ROA quando relevante e a evidência operacional atual estejam alinhadas, dados não autoritativos obsoletos não devem ser autorizados a manter o mercado refém indefinidamente.

O padrão de tratamento de conflitos deve perguntar o que cada fonte é competente para provar. Os dados da fonte ARIN são mais fortes sobre a autoridade de recursos ARIN. Dados do tipo RADb ou privados podem ser mais fortes sobre uma relação de roteamento cliente-provedor. Um espelho é tão forte quanto sua fonte e frescor. Um AS-SET é evidência de intenção política, não de propriedade. Um ROA é autorização de origem de rota, não um mapa de cone de clientes. Se cada sinal é mantido dentro de sua competência, os conflitos podem ser resolvidos sem fingir que um artefato responde a todas as perguntas.

O ganho econômico do tratamento disciplinado de conflitos é a liquidez. Um bloco com detritos antigos de IRR não é inútil; é um bloco com risco de limpeza. Um bloco com dados autoritativos claros e resíduos externos isolados é mais fácil de precificar. Uma rede com razões de rejeição transparentes é mais fácil de trabalhar. Um registro que rotula a autoridade da fonte reduz disputas sem se tornar um órgão de execução. Os conflitos não desaparecerão. Mas a ambiguidade não deve ser autorizada a decidir o resultado por padrão.

Diligência de transferência em um mundo IRR fragmentado

As transferências de IPv4 expõem a fragilidade do IRR porque uma transferência muda a história do titular mais rápido do que o ambiente de registro de roteamento pode mudar. O ARIN pode reconhecer o destinatário. As partes podem fechar. Os advogados podem atualizar documentos. O comprador pode preparar um novo plano de origem. No entanto, o mundo dos filtros ainda pode conter registros mais antigos, cópias espelhadas, AS-SETs de proxy, entradas não autoritativas e dados mantidos pelo provedor que apontam para o passado operacional do vendedor. O ativo se moveu. A cadeia de suprimentos de evidências não se moveu totalmente com ele.

Um arquivo sério de diligência de transferência deve, portanto, incluir um inventário de fontes IRR. Deve listar registros da fonte ARIN, registros não autoritativos adjacentes ao ARIN onde visíveis, registros do tipo RADb, registros mantidos por provedores, referências de IRR privadas conhecidas pelas partes, cópias espelhadas, referências AS-SET e resultados comuns de construtores de filtros. Deve distinguir registros que o vendedor pode alterar, registros que o comprador pode alterar após o fechamento, registros controlados por provedores e registros que podem exigir cooperação de terceiros.

Também deve identificar quais contrapartes importantes dependem de quais fontes.

Isso não é ornamento legal. É economia de entrega. Um comprador que precisa do bloco para migração para nuvem, transição de clientes, mitigação de DDoS, compras públicas, expansão de hospedagem ou serviço de banda larga regional não pode tratar a limpeza de IRR como uma tarefa casual pós-fechamento. Se o upstream preferido do comprador não aceitar a rota até que uma fonte obsoleta seja corrigida, o comprador não está recebendo capacidade produtiva imediata. Está recebendo um projeto de remediação. O preço deve refletir isso.

Para transferências de alta dependência, as condições de liquidação podem precisar incluir marcos de IRR. O vendedor pode concordar em divulgar registros de rota e AS-SET conhecidos. As partes podem concordar quais registros permanecem temporariamente durante a migração. Os provedores podem ser notificados. O comprador pode criar registros de substituição da fonte ARIN quando a autoridade permitir. Repositórios externos podem ser contatados. Um cronograma de caução pode distinguir o reconhecimento do registro da aceitação operacional para as contrapartes mais importantes. Nem toda transferência precisa de tal detalhe.

Mas quanto mais o caso de negócios depende da alcançabilidade rápida, mais o arquivo de fonte IRR importa.

A contribuição do ARIN é ser explícito sobre o que pode e não pode entregar. Pode registrar a transferência, manter o livro-razão de recursos autoritativo, apoiar dados de roteamento da fonte ARIN e ajudar os titulares a entender o estado do lado ARIN. Não pode garantir que o RADb, um IRR privado, uma fonte de provedor antigo, um servidor de rotas IXP ou uma plataforma de nuvem tenha atualizado sua própria visão. Essa limitação deve fazer parte do entendimento padrão do mercado, não uma surpresa descoberta após o fechamento.

A diligência de transferência é onde o princípio do registro como livro-razão se torna prático. O livro-razão deve ser limpo, restrito e confiável. Ao seu redor, existe um mercado de aceitação mais amplo que deve ser inspecionado. Um comprador de IPv4 escasso não está apenas comprando um intervalo de números. Está comprando um caminho para ser acreditado por muitos sistemas independentes. Dados IRR fragmentados são um dos lugares onde esse caminho pode quebrar.

Operadores pequenos, nuvens e IXPs sentem o custo primeiro

A fragilidade do IRR não é distribuída uniformemente. Grandes redes podem frequentemente contorná-la. Elas mantêm equipes de engenharia, contatos privados, ferramentas de política de rota, caminhos de escalada e suporte jurídico. Podem executar suas próprias comparações de fontes. Podem negociar exceções. Podem persuadir um provedor de nuvem, parceiro de trânsito ou par a olhar novamente. Um pequeno ISP, uma empresa de hospedagem regional, um departamento universitário, um provedor de serviços gerenciados ou um operador do Caribe pode ter a mesma reivindicação legítima de recurso, mas menos maneiras de tornar essa reivindicação legível.

Para pequenos operadores, o custo é fixo. Aprender regras de fontes IRR, manter AS-SETs, auditar espelhos, limpar registros antigos do tipo RADb, coordenar ROAs e responder a rejeições opacas de filtros leva tempo, independentemente do tamanho do bloco. Um /24 usado por um pequeno provedor de acesso pode exigir quase o mesmo trabalho de prova que um portfólio maior mantido por uma plataforma sofisticada. Esse custo fixo é regressivo. Penaliza operadores cuja receita por exercício de prova é baixa.

As redes caribenhas ilustram o ponto nitidamente. A região de serviço do ARIN inclui operadores de ilhas e pequenos mercados cuja conectividade pode depender de um conjunto limitado de cabos submarinos, escolhas de upstream, opções de troca e regiões de nuvem fora de seu mercado doméstico. Se um conflito de IRR atrasar um servidor de rotas ou a ativação de trânsito, o operador pode não ter cinco substitutos. Pode pagar mais, aceitar caminhos piores ou decepcionar clientes que não se importam que o problema tenha vindo de uma fonte obsoleta. Evidências frágeis tornam-se um custo de conectividade local.

As plataformas de nuvem criam outra forma de pressão. Programas de traga-seu-próprio-IP geralmente exigem prova de que o cliente controla o prefixo e pode autorizar a origem da plataforma. O RPKI pode ser parte dessa prova. Os dados IRR também podem ser examinados, especialmente quando a plataforma quer entender origens antigas ou a política de rota atual. Se uma fonte obsoleta de terceiros diz uma coisa e a evidência atual do ARIN diz outra, a plataforma pode pausar. A pausa é racional da perspectiva da plataforma. É cara para o cliente.

IXPs e servidores de rotas colocam a lógica em código. Um servidor de rotas deve proteger os membros de rotas ruins e configurações incorretas. Pode usar dados IRR e RPKI juntos. Pode gerar filtros a partir dos AS-SETs dos membros. Se os dados IRR do membro estão ausentes, conflitantes ou ocultos atrás da ordem de fonte errada, a rota pode não ser propagada. Para uma grande rede de conteúdo, isso é um caminho entre muitos. Para um operador regional, a aceitação do servidor de rotas pode afetar o desempenho e o custo de trânsito materialmente.

O custo social não é mero inconveniente. Se apenas grandes plataformas podem pagar por evidências limpas, o mercado de endereços se torna menos competitivo. Pequenos titulares podem vender com desconto porque não podem provar a limpeza de forma eficiente. Pequenos compradores podem evitar blocos com históricos complicados. Redes regionais podem permanecer dependentes de upstreams que mantêm a maquinaria de IRR para elas. O mercado então recompensa a capacidade administrativa tanto quanto a necessidade operacional.

O ARIN pode reduzir esse fardo de custo fixo sem se tornar um programa de subsídio ou uma polícia de rotas. Pode fornecer orientação mais clara sobre limites de fonte, visibilidade mais fácil para os titulares dos dados de roteamento da fonte ARIN, listas de verificação práticas de transferência, exemplos de qualificação de fonte AS-SET e explicações de como as evidências RPKI e IRR interagem. As redes privadas podem ajudar fornecendo razões de rejeição acionáveis. IXPs podem publicar políticas de fonte. As nuvens podem explicar quais evidências exigem e por quê.

O objetivo compartilhado é legitimidade de baixo atrito: um pequeno operador legítimo não deve precisar de uma campanha institucional personalizada para provar uma rota de rotina.

Por que o RPKI ajuda, mas não aposenta o IRR

O RPKI é a resposta mais forte para parte do problema. Um ROA permite que um titular de recurso autorize um ASN de origem em um sistema baseado em certificados. A validação de origem de rota permite que as redes classifiquem os anúncios contra essa autorização. Comparado a um registro IRR de terceiros solto, um ROA válido vinculado ao titular atual do recurso é um sinal muito mais limpo para autorização de origem. A implantação mais ampla do RPKI reduz o espaço para que algumas alegações falsas ou obsoletas de origem de rota sejam acreditadas.

Mas o RPKI não aposenta o IRR porque responde a uma pergunta diferente. O RPKI diz se um AS está autorizado a originar um prefixo, dentro dos limites de comprimento de prefixo especificados. Não descreve um AS-SET, um cone de clientes, uma política de peering, uma relação de trânsito, uma associação a servidor de rotas, uma delegação de serviço gerenciado ou uma fonte de filtro preferida pelo provedor. Os dados IRR continuam sendo a linguagem de trabalho para muitas dessas relações de política. As redes que constroem filtros de clientes ainda precisam de uma maneira de saber quais ASNs e prefixos pertencem atrás de um cliente.

O RPKI sozinho não conta essa história.

Também há uma lacuna de implantação. Algumas redes aplicam a validação de origem de rota estritamente. Outras a usam como um aviso. Algumas rotas são cobertas por ROAs. Outras permanecem NotFound. Alguns erros são temporários e operacionais, em vez de maliciosos. Algumas redes combinam RPKI com filtros IRR, aceitando uma rota apenas se tanto a autorização de origem quanto a política IRR parecerem plausíveis. Nesse mundo misto, um conflito de IRR ainda pode atrasar uma rota mesmo quando o RPKI está correto, e um ROA ausente ainda pode deixar o IRR como a principal evidência legível por máquina.

O RPKI também pode aguçar o tempo de transferência. Uma transferência pode exigir mudanças de ROA, mudanças de origem e limpeza de IRR em uma sequência coordenada. Se o ROA é atualizado, mas dados IRR antigos permanecem, alguns filtros ainda podem questionar a rota. Se os dados IRR são atualizados, mas o ROA está errado, a validação de origem de rota pode classificar o anúncio como inválido. Se os estados antigo e novo se sobrepõem durante a migração, ambos os sistemas devem ser entendidos.

O valor do RPKI é alto precisamente porque adiciona um sinal melhor; a necessidade de disciplina de IRR permanece porque a aceitação privada ainda lê vários sinais.

Os sistemas também falham de maneira diferente. O RPKI depende da continuidade do certificado e do repositório, do frescor da publicação, do comportamento do validador e das escolhas corretas de maxLength. O IRR depende da qualidade da fonte, mantenedores, espelhamento, recursão de AS-SET e preferência de fonte local. Um operador maduro observa ambos. Um arquivo de transferência maduro explica ambos. Um processo maduro de integração em nuvem reconcilia ambos. Tratar qualquer um deles como um substituto total para o outro cria pontos cegos.

Para o ARIN, o RPKI é uma oportunidade de melhorar a hierarquia de evidências. Onde a autoridade atual de recursos do ARIN, a postura atual do ROA e os dados IRR atuais da fonte ARIN estão alinhados, os filtros privados devem ter uma forte razão para confiar na história de origem da rota. Onde conflitam, o conflito deve ser visível e explicável. Onde dados de terceiros conflitam com ambos, os dados de terceiros devem ser tratados como uma alegação que requer contexto, não como um voto igual. O RPKI fortalece a evidência autoritativa. Não apaga a necessidade de rotular evidências não autoritativas.

O mercado deve, portanto, parar de perguntar se o RPKI ou o IRR vence. A pergunta relevante é como os dois sinais são ordenados em um arquivo de aceitação prático. Um bloco limpo da região ARIN deve ter reconhecimento de registro atual, contatos precisos, ROAs apropriados, registros de rota atuais da fonte ARIN onde necessário, status conhecido de limpeza de IRR externo, AS-SETs qualificados por fonte e uma explicação clara de qualquer resíduo remanescente de terceiros. O RPKI é central nesse arquivo. Não é o arquivo inteiro.

O que o ARIN pode fazer sem se tornar um regulador de rotas

O caminho construtivo para o ARIN é estreito, mas significativo. Não deve dizer a cada rede o que rotear. Não deve supervisionar os termos comerciais de aluguéis de IPv4, migrações para nuvem ou relações de trânsito. Não deve converter preferência de fonte em uma lei de roteamento regional obrigatória. Sua legitimidade é mais forte quando atua como um livro-razão confiável e uma instituição de coerência de evidências. A fragilidade do IRR precisa exatamente desse tipo de disciplina.

Primeiro, o ARIN pode tornar a semântica da fonte mais clara. Os operadores devem ser capazes de distinguir dados autoritativos da fonte ARIN para recursos gerenciados pelo ARIN de dados não autoritativos, espelhados ou de terceiros. A distinção deve ser visível para humanos e fácil para as ferramentas preservarem. Se um registro não é autoritativo para o recurso, o rótulo deve sobreviver à consulta, ao espelho e à exportação em contextos de construção de filtros, sempre que viável. Um rótulo limpo é uma forma barata de infraestrutura de mercado.

Segundo, o ARIN pode melhorar a visibilidade do titular. Os titulares devem ser capazes de entender os registros de roteamento do lado ARIN associados aos seus recursos e as implicações básicas das categorias de fonte. Isso não exige que o ARIN descubra cada entrada de RADb ou IRR privado. Exige que o ARIN torne seu próprio estado legível o suficiente para que um titular possa separar as evidências governadas pelo ARIN das tarefas de limpeza externa. Um pequeno operador não deve precisar de um especialista apenas para saber o que o ARIN está dizendo sobre seu prefixo.

Terceiro, o ARIN pode publicar orientação de IRR voltada para transferências. Os participantes de transferências precisam saber que o reconhecimento do registro e a limpeza de IRR estão relacionados, mas não são idênticos. Uma lista de verificação prática deve perguntar: quais registros da fonte ARIN existem, quais registros externos são conhecidos, quais AS-SETs referenciam os ASNs relevantes, quais espelhos ou listas de fontes contrapartes importantes usam, quais ROAs devem mudar, quais origens antigas permanecem temporariamente válidas e quais registros exigem cooperação de terceiros.

Orientações desse tipo apoiam os mercados sem ditar termos de transação.

Quarto, o ARIN pode resistir à tentação de usar a fragilidade do IRR como expansão de mandato. Fontes fragmentadas são um problema real, mas nem todo problema real pertence ao registro como soberano. As redes privadas têm o direito de gerenciar riscos. Os clientes são responsáveis por suas relações de roteamento. Repositórios de terceiros podem ser úteis. Tribunais e contratos decidem muitas disputas comerciais. O trabalho do ARIN é manter o registro central confiável, não se tornar o juiz final de toda aceitação de rota.

O teste é se o ARIN reduz o custo da prova sem aumentar os pontos de estrangulamento discricionários. Um titular deve achar mais fácil provar a autoridade atual do recurso. Um comprador deve achar mais fácil identificar resíduos externos de IRR. Um servidor de rotas deve achar mais fácil preferir evidências limpas. Um pequeno ISP deve achar mais fácil corrigir rejeições. Uma plataforma de nuvem deve achar mais fácil entender a história de origem da rota. Nenhum desses resultados exige que o ARIN comande o roteamento. Eles exigem que o ARIN mantenha o livro-razão e suas evidências adjacentes adequadas para um mercado no qual o IPv4 é capital.

Fontes e método

Este artigo trata as mecânicas de registro público e segurança de roteamento como exibições factuais, não como enquadramento institucional. O quadro analítico é a economia institucional em torno de recursos numéricos escassos: a distinção entre um livro-razão e um porteiro, o perigo do risco em nível de registro uma vez que o IPv4 se torna capital, a disciplina de que as redes em execução, e não a retórica, decidem a realidade operacional, e a necessidade de proteger a continuidade dos recursos numéricos sem transformar um registro em um executor geral.

O limite operacional importa porque o mesmo bloco de endereços pode se mover por vários canais de evidência ao mesmo tempo. Os contatos do registro e os ROAs podem apoiar a história atual do titular. Objetos de rota, AS-SETs, cópias espelhadas e registros mantidos por provedores ainda podem descrever arranjos operacionais mais antigos. Os filtros de nuvem, trânsito e troca podem então preferir diferentes listas de fontes. Este artigo se preocupa com essa fragmentação: como múltiplas fontes IRR, espelhos, recursão de AS-SET e ordem de fonte fazem com que a mesma alegação de roteamento signifique coisas diferentes para filtros diferentes.

As mecânicas de registro oficial são úteis aqui apenas para identificar o que os sistemas fazem: dados de registro de roteamento da fonte ARIN, RPKI, ROAs, registros públicos de recursos, rótulos de fonte e serviços relacionados ao roteamento. Elas não fornecem a conclusão. A conclusão vem do cenário de mercado: escassez de IPv4, prática de transferência norte-americana, integração de nuvem e data center, filtragem de IXP, restrições de capacidade de pequenos operadores e o fato de que as redes privadas transformam dados de roteamento públicos e semi-públicos em decisões privadas de aceitação.

O artigo evita deliberadamente um simples drama moral. As fontes do tipo RADb e IRR privadas não são tratadas como vilãs. Os dados da fonte ARIN não são tratados como mágica. O RPKI não é tratado como um substituto universal. Cada fonte de evidência é julgada pelo que é competente para provar e pelo custo imposto quando seus limites são mal compreendidos. Esse é o método necessário para um mercado cujos ativos são intangíveis, escassos e operacionalmente incorporados.

Conclusão: a fragilidade é um custo para ser acreditado

A fragilidade do banco de dados IRR é fácil de subestimar porque parece um problema técnico de dados. É realmente um problema de custo de confiança. Um bloco escasso de IPv4 se torna útil apenas quando sistemas independentes suficientes acreditam na história atual de roteamento. Esses sistemas não leem todos a mesma evidência. Alguns leem o ARIN. Alguns leem o RADb. Alguns leem espelhos. Alguns expandem AS-SETs recursivamente. Alguns combinam IRR e RPKI. Alguns usam listas de fontes antigas. Alguns escondem sua ordem de fonte atrás de uma fila de suporte. O titular experimenta essa pluralidade como fricção.

Para o ARIN, a postura institucional correta não é nem passividade nem excesso. A passividade permite que dados não autoritativos obsoletos e hábitos de fonte privados aloquem poder prático sobre os recursos da região ARIN. O excesso transformaria o registro em um regulador de rotas e repetiria o velho erro de converter escrituração em controle discricionário. A melhor postura é a disciplina do livro-razão: tornar o estado autoritativo claro, preservar a identidade da fonte, apoiar evidências atuais adjacentes ao roteamento, rotular limites e ajudar os operadores a entender o que permanece fora do ARIN.

Para o mercado, a lição prática é que a diligência da fonte IRR agora faz parte da diligência de ativos IPv4. Um arquivo de transferência que ignora fontes de roteamento externas está incompleto. Uma migração para nuvem que ignora caminhos antigos de AS-SET está exposta. Uma política de IXP que não dá aos membros razões de rejeição acionáveis aumenta os custos fixos. Um comprador que assume que o reconhecimento do ARIN limpa automaticamente registros do tipo RADb está comprando surpresa. Um vendedor que deixa dados obsoletos de terceiros para trás está entregando um ativo menos líquido do que o preço pode sugerir.

O RPKI melhora este mundo, mas não o abole. O futuro não é um sistema de prova único que faz todas as outras fontes desaparecerem. O futuro é uma hierarquia de evidências na qual cada fonte carrega o peso apropriado à sua autoridade. Os dados da fonte ARIN devem ser autoritativos para recursos gerenciados pelo ARIN. O RPKI deve carregar forte valor de autorização de origem. Fontes do tipo RADb e privadas devem descrever relações com limites claros. Espelhos devem preservar a proveniência. AS-SETs devem ser qualificados por fonte onde a ambiguidade importa.

Os construtores de filtros devem explicar suas escolhas quando essas escolhas bloqueiam rotas legítimas.

A economia é modesta, mas consequente. Semânticas de fonte limpas reduzem os custos de transação. Conflitos visíveis tornam o risco precificável. Melhor higiene de AS-SET reduz barreiras acidentais de mercado. Razões claras de rejeição ajudam as pequenas redes a competir. A diligência de transferência que inclui fontes IRR protege compradores e vendedores. O ARIN não precisa se tornar mais poderoso para produzir esses ganhos. Ele precisa tornar suas evidências existentes mais legíveis e mais difíceis de confundir com evidências mais fracas.

É por isso que a fragilidade do IRR pertence à discussão sobre a escassez de IPv4. A escassez dá preço aos endereços, mas a aceitação lhes dá valor produtivo. Em um mundo IRR fragmentado, a aceitação depende não apenas de estar certo, mas de estar certo na fonte que um filtro privado acredita primeiro. A economia da fragilidade do banco de dados IRR do ARIN é a economia dessa primeira crença.