Resumo

  • O RFC 3330 reuniu blocos IPv4 dispersos e mostrou que números parecidos podem seguir regras muito diferentes de host, origem, destino, encaminhamento e vazamento.
  • A tabela de 2002 era um retrato histórico, não um oráculo de segurança permanente. RFCs posteriores e o registro atual da IANA transformaram a classificação em atributos versionados, nos quais prefixos mais específicos também importam.

O mesmo endereço não autoriza o mesmo comportamento

Um endereço IPv4 comum pode indicar um host alcançável por rotas públicas. Já 127/8 deve voltar para dentro do próprio equipamento; 10/8, 172.16/12 e 192.168/16 destinam-se a redes privadas; 169.254/16 permite comunicação no mesmo enlace quando falta a configuração usual. Prefixos de documentação servem para exemplos, enquanto 198.18/15 foi reservado a testes de desempenho. Multicast e broadcast limitado têm regras próprias.

Essas diferenças não estão nos 32 bits. Elas vêm de uma decisão de protocolo, de uma alocação ou de uma política de roteamento. Um roteador que trata todo valor como destino público comum pode deixar uma interface de loopback escapar para a rede. Um filtro que bloqueia qualquer coisa chamada “especial” pode impedir um uso previsto. O nome da classe não diz qual ação deve ser aplicada.

Antes do RFC 3330, as descrições desses blocos estavam espalhadas por RFCs e registros de parâmetros. O documento reuniu as referências em um catálogo da IANA, mas deixou explícito que não tratava do espaço IPv4 distribuído a operadores e usuários pelos RIRs. Portanto, não substituiu a alocação comum: tornou mais visível um pequeno conjunto de exceções e designações especializadas.

“Especial” não é uma propriedade só

O texto de 2002 descrevia expectativas em prosa. Com o tempo, ficou claro que um único sinalizador “especial” não bastava para implementar filtros ou investigar incidentes. Um endereço pode ser válido como origem e inválido como destino; um roteador pode encaminhá-lo entre interfaces externas sem que ele deva ser globalmente alcançável; um protocolo pode exigir tratamento específico mesmo quando outras propriedades são falsas.

O RFC 5735 substituiu o catálogo histórico. Depois, o RFC 6890 criou registros mantidos para endereços IPv4 e IPv6 de propósito especial. As entradas distinguem validade como origem, validade como destino, possibilidade de encaminhamento, alcance global e reserva pelo protocolo. Cada campo responde a uma pergunta diferente; juntar tudo em um rótulo apaga justamente a informação de que os filtros de borda dependem.

O RFC 8190 esclareceu o sentido de “globalmente alcançável”. É uma propriedade operacional esperada dentro de um modelo administrativo, não uma garantia empírica de que nenhuma rota será anunciada nem pacote vazará. Se um observador público encontra um prefixo marcado como não global, pode ter ocorrido vazamento, falha de filtro, falsificação ou artefato de medição. A observação isolada não altera a entrada do registro.

O prefixo mais específico também conta. Uma entrada ampla pode conter uma designação menor com atributos diferentes. Uma regra que para no primeiro prefixo abrangente pode aceitar uma origem indevida ou descartar tráfego legítimo. Uma decisão justificável registra a entrada exata que venceu a correspondência, os atributos consultados e a versão do registro.

A tabela tinha data porque a rede mudava

O RFC 3330 incluiu blocos cujo uso especial estava terminando ou que depois poderiam voltar à alocação comum. Isso não era um erro: era uma fotografia da rede naquele momento. O risco aparece quando a fotografia de 2002 fica congelada para sempre em software, relatórios de segurança ou regras de conformidade.

Os documentos seguintes continuaram a atualização. O RFC 5737 reservou três prefixos distintos para documentação, em vez de depender apenas do TEST-NET citado em 2002. O RFC 3927 detalhou o comportamento do IPv4 link-local. O RFC 6890 substituiu listas estáticas por registros revisáveis. Hoje, o registro de endereços IPv4 de propósito especial da IANA é a referência operacional desses atributos; o RFC 3330 permanece como evidência histórica da formação do catálogo.

A data funciona nos dois sentidos. Não se deve aplicar retroativamente um atributo criado anos depois para julgar um operador de 2002. Tampouco um RFC antigo basta para classificar um pacote observado hoje. Um relatório sólido informa o horário da observação, a versão ou captura do registro, o prefixo exato, o sentido do pacote, a interface e os atributos que fundamentaram a decisão.

O documento também separou necessidades técnicas de uma designação especial da política geral de endereços. Se um RFC precisava de um bloco IPv4 para o processo de padrões, deveria descrever requisitos técnicos como tamanho ou comprimento do prefixo. A IANA consultaria os RIRs e faria a designação perto da publicação. O RFC 3330 descreveu uma prática; não concedeu reserva permanente a todo experimento nem criou uma nova regra geral de alocação.

Uma entrada não filtra pacote algum

O registro expressa intenção e oferece dados a hosts, roteadores, firewalls, bibliotecas e ferramentas de auditoria. Ele não atualiza equipamentos automaticamente nem aplica uma política nas fronteiras. A distância entre a propriedade registrada e o comportamento observado é uma questão operacional própria.

Um pacote com origem privada visto numa interface externa pode indicar falsificação, configuração errada ou um caminho encapsulado. Um programa pode empregar loopback como convenção local. Um exemplo copiado pode deixar um prefixo de documentação na produção; um teste de benchmark pode contaminar as métricas normais. Em nenhum desses casos o endereço, por si só, revela onde o pacote foi criado ou qual ação a rede tomou.

É preciso preservar o sentido do pacote, as interfaces de entrada e saída, o encapsulamento, o estado de tradução, a entrada do registro que corresponde ao prefixo mais longo e o resultado efetivo do filtro. Uma captura comprova que certos bits foram observados em certo ponto; não comprova sozinha o local de origem. Da mesma forma, “sem alcance global” não quer dizer “nunca visível em um coletor público”.

O RFC 3330 marcou uma mudança de perspectiva: o espaço IPv4 não era apenas uma sequência de números distribuídos, mas também um espaço compartilhado com exceções operacionais documentadas. A lição duradoura não é decorar alguns prefixos famosos. É separar valor numérico, tipo de designação, regra executada e observação. Se esses quatro recibos forem confundidos, o catálogo vira uma falsa prova de origem ou alcance.

Fontes