Resumo

  • Um mesmo responsável pode conectar até duas sondas de software sob o mesmo IP e quatro no mesmo prefixo visto no BGP; entre todas as contas, o teto é 32 por prefixo IPv4 e 64 por prefixo IPv6.
  • A política do RIPE Atlas explica custo, ganho informacional limitado, exceções e revisão futura dos tetos. O que não aparece é o elo reproduzível entre um estado BGP datado e o grupo contado numa decisão específica.
  • Um comprovante privado deve registrar horário, visão de roteamento, prefixo resolvido, contagens, faixa acionada, condição de liberação e análise da exceção, deixando ao público apenas resultados agregados e seguros.

Os quatro tetos não medem a mesma coisa

Uma rede de medição distribuída cresce por diversidade, não por simples multiplicação de processos. Cada sonda conectada consome recursos centrais. Várias sondas de software na mesma rede e no mesmo local podem acrescentar pouco ao diagnóstico. Ao mesmo tempo, seus responsáveis recebem créditos enquanto elas permanecem ativas. Há, portanto, um incentivo legítimo à participação e um risco igualmente real de recompensar densidade sem informação nova.

O anúncio de 29 de abril de 2026 traduziu esse problema em quatro números. Uma conta pode conectar duas sondas a partir do mesmo endereço IP. Pode conectar quatro a partir do mesmo prefixo IP, “conforme visto no BGP”. Independentemente da conta, um prefixo IPv4 comporta no máximo 32 sondas e um prefixo IPv6, 64. Acima disso, a nova sonda não se conecta até que outra saia.

Dois, quatro, 32 e 64 não são apenas graus de severidade. O primeiro une responsável e endereço. O segundo une responsável e prefixo de roteamento. Os dois últimos contam todas as contas dentro do prefixo e separam famílias de endereços. Um aviso genérico de farming não informa qual conjunto foi formado nem qual teste falhou.

RIPE NCC também registrou que os tetos podem mudar. Reconheceu que sondas do mesmo usuário podem parecer concentradas numa rede embora estejam geograficamente espalhadas, e abriu um caminho por e-mail para explicar o caso e pedir flexibilização. Naquele instante, a estimativa era de 71 sondas pertencentes a 13 responsáveis. É um retrato do planejamento em abril, não a situação atual nem uma prova de que as 71 foram efetivamente retidas.

O trecho decisivo é “conforme visto no BGP”. Ele evita tratar uma alocação administrativa, um ASN inteiro ou uma descrição preenchida pelo usuário como a rede operacional. A regra olha para o roteamento observável. Só que uma rota não é uma placa fixada na sonda. Pode surgir um anúncio mais específico; uma rota pode ser agregada ou retirada; a origem pode mudar; diferentes observadores podem enxergar estados distintos. O equipamento fica parado e, mesmo assim, o grupo que o limite enxerga pode mudar.

Isso é uma inferência sobre o funcionamento de redes, não o relato de uma falha do RIPE Atlas. As fontes não demonstram uma sonda retida ou liberada apenas porque seu prefixo BGP mudou. Também não informam qual fonte de rotas, conjunto de coletores, critério de visibilidade, instante ou regra de escolha é usado na aplicação do limite.

O teste dos grandes acessos

Na discussão pública, Robert Scheck perguntou se AS3209 e AS3320 seriam afetados. Ele citou uma investigação na qual sondas dentro do mesmo prefixo visível no BGP apresentaram comportamentos diferentes.

O exemplo não transforma toda repetição em diversidade útil. Ele separa duas noções: pertencer ao mesmo anúncio global não significa, por definição, observar o mesmo caminho interno. Grandes redes de acesso podem esconder agregadores, políticas locais e domínios de falha diferentes atrás de um prefixo comum.

A resposta do RIPE NCC, preservada nas respostas oficiais, foi específica e limitada. Os números foram escolhidos para não alterar a quantidade habitual de sondas naquelas redes. A situação seria acompanhada e o algoritmo poderia dar mais folga a prefixos grandes. Isso confirma um parâmetro de ajuste, não concede automaticamente uma cota diferenciada a qualquer ASN amplo.

Havia ainda uma pergunta operacional: o responsável enxergaria um motivo claro ou apenas “desconectada”? RIPE NCC prometeu uma etiqueta específica e contato prévio com as 13 contas estimadas. As notas de 15 de julho dizem agora que a visão geral avisa quando a sonda está em espera por uma violação de farming.

Dar nome à espera resolve uma confusão importante. O responsável pode separar uma decisão de admissão de problemas de firewall, acesso ou controlador. Mas uma etiqueta não é um comprovante. Ela não diz se o gatilho foi dois, quatro, 32 ou 64, qual prefixo foi resolvido, quantas sondas foram contadas ou quando haverá nova avaliação.

Descrever o prefixo não reproduz a decisão

A FAQ de gerenciamento repete hoje os quatro limites, a referência ao BGP e a exceção para dispersão geográfica. A FAQ sobre sondas e responsáveis traz os incentivos: sondas ativas geram créditos, enquanto o objetivo declarado é uma rede topologicamente diversa e sem cultivo artificial de créditos.

A referência pública da API documenta prefix_v4 e prefix_v6. Esses campos descrevem um estado da sonda, mas a documentação revista não apresenta um objeto público que una prefixo, instante de rota, contagem, limite e revisão de uma retenção. Nem seria adequado publicar todo detalhe. IPs exatos, vínculos entre contas e informações que ajudem a contornar controles precisam de proteção.

Há dois públicos e duas camadas. RIPE NCC e o responsável afetado precisam de um registro privado que permita refazer a decisão. Pesquisadores e a comunidade precisam de estatísticas agregadas que mostrem o comportamento da política sem identificar instalações. Transparência útil não exige que essas camadas tenham o mesmo conteúdo.

A documentação de BGP State do RIPEstat serve apenas de exemplo para a linguagem de proveniência. Uma observação de rota pode registrar recurso, horário, coletores selecionados, identificadores de fonte e tempo da consulta. Nada prova que o mecanismo do Atlas use RIPEstat, RIS, todos os coletores RIS ou aquele cálculo. O ponto é mais simples: “visto no BGP” pode ser ligado a coordenadas verificáveis.

Um comprovante sem abrir o mecanismo ao abuso

O registro privado começa com horário da decisão, família de endereços e uma representação protegida do IP de origem. Guarda o prefixo resolvido, o instante do estado BGP e a fronteira de dados usada. Se existiam rotas concorrentes ou várias coberturas, anota a regra de escolha.

Depois identifica o teste: terceira sonda da conta sob um IP, quinta da conta no prefixo, trigésima terceira no grupo IPv4 ou sexagésima quinta no grupo IPv6. A contagem imediatamente anterior e o teto vigente devem aparecer juntos. Conexões quase simultâneas exigem ainda uma regra estável de ordenação.

Por fim vem a saída. “Até que outras sondas saiam” expressa a política, mas o responsável precisa saber quando o grupo será recontado, se uma alteração BGP provoca revisão, se há fila e qual evento devolveu a conexão. Uma exceção deve guardar solicitação, classe do motivo, decisão, revisor e validade sem expor a justificativa sensível.

O relatório público pode agregar retenções e liberações por família e faixa; tempo até a liberação; pedidos de exceção e resultados; impactos de revisões de teto; e reavaliações associadas a mudanças de fronteira BGP. Volumes pequenos podem ser agrupados ou atrasados.

Essa é uma recomendação editorial de Theo March. Ela não pressupõe que o RIPE NCC não tenha logs internos e não chama de abusivo todo responsável atingido. O rótulo do produto descreve a regra aplicada; sozinho, não prova intenção.

Fontes