Resumo

  • cidr0_cidrs representa como 196.1.0.0/24 o intervalo registrado entre 196.1.0.0 e 196.1.0.255.
  • A resposta não informa anúncio BGP, AS de origem, AS_PATH, visibilidade entre pares nem tráfego efetivo.
  • O prefixo pode ligar dados de registro e de roteamento, desde que cada fato preserve sua própria fonte, data e limitação probatória.

O mesmo prefixo pode sustentar fatos diferentes

O ponto de partida é um objeto de registro. Em 28 de agosto de 2026, o serviço RDAP público da AFRINIC respondeu à consulta de 196.1.0.0/24 com um objeto da classe ip network. O identificador superior cobre 196.1.0.0 - 196.1.0.255, o tipo é ASSIGNED PI e a lista cidr0_cidrs traz uma entrada com prefixo IPv4 196.1.0.0 e comprimento 24.

O contexto determina o significado dos campos. Os endereços inicial e final delimitam a faixa registrada. O parentHandle aponta para o objeto de rede pai na hierarquia de registros. O valor active é o estado do objeto dentro do RDAP. Nenhum desses dados é uma observação em tempo real do plano de controle da Internet.

A documentação da AFRINIC delimita a finalidade da consulta. Ao receber um endereço ou prefixo, o serviço devolve a rede registrada mais específica que o contém por inteiro. A pergunta respondida é: qual objeto cadastral engloba este recurso? Não é: qual rota um roteador prefere agora, ou por qual caminho os pacotes vão passar?

A confusão surge porque CIDR também é a linguagem cotidiana do BGP. Um coletor de rotas pode mostrar 196.1.0.0/24 como destino de um anúncio. Na resposta RDAP observada, a mesma sequência é apenas a expressão da faixa cadastrada. A coincidência textual cria uma boa chave de comparação, não uma prova de que as duas fontes observaram o mesmo fenômeno.

Uma rota BGP combina destinos descritos como informação de alcançabilidade com atributos de caminho trocados entre sistemas autônomos. Para afirmar que a rota existe, é preciso dizer qual ponto de observação recebeu qual prefixo, em que momento, com que origem e atributos. O objeto RDAP não contém essa observação.

Por isso o prefixo deve funcionar como chave, não como conclusão. Ele pode associar o registro a uma medição BGP independente. Até que a segunda fonte exista, campos como “rota observada”, “AS de origem” e “alcançabilidade” devem permanecer vazios.

O problema que cidr0_cidrs realmente resolve

O modelo básico de rede IP do RDAP usa um endereço inicial e um endereço final. Essa forma representa com precisão intervalos que não cabem em um único bloco CIDR. Quando as bordas não coincidem com uma fronteira de prefixo, são necessárias várias expressões CIDR para cobrir a faixa sem acrescentar endereços que não pertencem ao registro.

A extensão cidr0 fornece essa conversão como uma lista. Cada item contém um prefixo IPv4 ou IPv6 e seu comprimento. A lista completa expressa em CIDR os limites do objeto que a contém. Ela não enumera rotas coletadas de sessões BGP.

No caso observado, as bordas se alinham exatamente. Os 256 endereços de 196.1.0.0 a 196.1.0.255 formam um único /24, então a lista tem apenas um item. O resultado é útil para inventários, controles de acesso e comparação entre bases, mas essa utilidade não amplia o alcance da evidência.

A resposta também declara conformidade com cidr0 em rdapConformance. Isso permite que um cliente relacione o campo à especificação registrada e interprete a estrutura sem adivinhação. A conformidade explica como ler a lista; não acrescenta origem, visibilidade de rota, relação de trânsito ou controle operacional.

A transformação segura é estreita. É possível derivar de cidr0_cidrs uma lista de “prefixos da faixa registrada”. Não é possível derivar automaticamente uma lista de “prefixos anunciados agora”. Para isso é necessária uma fonte de roteamento.

O que falta para falar de BGP

A captura da AFRINIC não diz se 196.1.0.0/24 aparecia em uma tabela BGP no momento da consulta. Não identifica AS de origem, AS_PATH, número de pares que viram a rota, data de anúncio ou retirada. Também não mostra se um agregado maior cobria a faixa ou se havia anúncios mais específicos dentro dela.

Essas ausências são centrais, não acessórios que podem ser preenchidos por intuição. A RFC 4271 define o BGP como protocolo entre sistemas autônomos para troca de informação de alcançabilidade. Sem observar destinos e atributos em uma atualização, a faixa registrada não substitui a evidência de rota.

Mesmo um anúncio confirmado responderia apenas a parte das perguntas operacionais. Ele poderia mostrar que um observador recebeu determinada rota com certos atributos em certo horário. Não provaria sozinho a entrega ponta a ponta, o volume de tráfego, a qualidade do serviço, um contrato de trânsito, acesso a roteadores ou controle societário.

O tempo também deve ficar explícito. O registro pode permanecer estável enquanto as rotas mudam; os metadados cadastrais podem ser atualizados sem alteração do anúncio. Unir capturas feitas em momentos diferentes, sem registrar as datas, transforma simultaneidade aparente em uma narrativa causal que as fontes não sustentam.

Afirmações negativas exigem ainda mais cautela. A ausência de uma rota em um coletor não demonstra ausência global. A visibilidade depende do ponto de observação, da janela de tempo e do método de coleta. A formulação correta nomeia a fonte e limita o resultado ao período observado.

Preservar a procedência no nível do campo

Uma cadeia de dados confiável pode ser dividida em três camadas. A primeira guarda o fato RDAP como foi capturado: URL, horário, identificador, limites, marcadores de conformidade e lista CIDR. A segunda registra somente a interpretação autorizada pela especificação: a lista representa a faixa cadastrada em notação CIDR.

A terceira camada recebe evidências independentes de roteamento, tráfego ou organização, cada uma com sua fonte e horário. Uma camada de conciliação pode apontar correspondência, divergência ou ausência de medição. Ela não deve inventar o lado que falta.

Essa separação impede que uma conveniência técnica se torne afirmação editorial sem base. Um campo registeredPrefixes pode ser preenchido a partir de cidr0_cidrs. Um campo observedRoutes não pode. O AS de origem deve ficar nulo até que uma fonte BGP o informe, e a alcançabilidade precisa de evidência adequada à entrega de pacotes.

Manter as camadas distintas também torna divergências analisáveis. Uma faixa pode ser coberta apenas por um agregado, conter um anúncio mais específico ou apresentar caminhos diferentes em coletores distintos. A origem pode mudar depois da captura RDAP. Nenhum desses casos apaga o fato de registro; eles descrevem outra propriedade ou outro momento.

A escrita para o público segue a mesma regra. “A AFRINIC representa esta faixa como 196.1.0.0/24” é sustentado pela captura. “O prefixo está anunciado” requer medição BGP citada. “A entidade associada controla a rede” exige documentação adicional de autoridade e operação.

Limite da observação e fontes

Este texto usa somente os campos superiores selecionados que o RDAP público da AFRINIC devolveu em 2026-08-28T06:35:54Z. O pacote factual não inclui consulta BGP; portanto, não faz afirmação sobre anúncio atual, origem, caminho, alcançabilidade ou tráfego do prefixo.

O significado do campo vem da orientação da AFRINIC, do registro de extensões RDAP da IANA, da especificação cidr0 do NRO e dos padrões da IETF para respostas RDAP e BGP. Essas fontes definem tanto a utilidade da lista quanto a fronteira que ela não atravessa.