Resumo

  • Na RFC 1475, o identificador de rota adiante tinha 64 bits, mas seu significado pertencia ao roteador que o havia emitido para o vizinho imediato.
  • Zero ou um valor inválido levava à busca comum por destino; agregação, mudança de rota, fluxo e conversão também podiam interromper ou substituir o atalho.
  • A trajetória de Experimental para CATNIP e depois Historic registra a vida documental da proposta, não comprova sua implantação nem o percurso de um pacote real.

Quando rejeitar o atalho era o comportamento correto

Um pacote chega com um valor de 64 bits que parece apontar diretamente para uma entrada de encaminhamento. O roteador verifica a faixa, o alinhamento e a compatibilidade com o destino. Algo não confere. Em vez de declarar falha, ele ignora o valor e faz a consulta normal na tabela.

Esse retorno ao caminho comum está no centro da RFC 1475, publicada em junho de 1993. O documento descrevia TP/IX, também chamado Internet Protocol version 7, uma proposta de endereços maiores e de mecanismos de rota e fluxo mais rápidos. Cada datagrama teria um forward route identifier de 64 bits.

O nome parece forte: identificador de rota. O procedimento era deliberadamente mais modesto. Um roteador podia associar à sua própria rota um número interno — um índice de tabela ou até um endereço de memória — e informá-lo ao vizinho que enviaria tráfego de volta. O vizinho transportava esse número como objeto opaco. Não ganhava acesso à tabela interna nem uma descrição do caminho completo.

Se a validação falhasse, o destino e o estado local continuavam disponíveis. A otimização podia desaparecer sem que a conectividade desaparecesse com ela. É justamente essa independência que impede tratar o campo como prova da rota.

Três roteadores reescreviam a mesma posição

O exemplo do RFC coloca os hosts X e Y nas pontas e os roteadores A, B e C no meio. C anuncia a B uma rota para Y e fornece um identificador que só C entende. B guarda o valor, cria uma rota via C e anuncia a A outro identificador, pertencente ao espaço interno de B.

X envia o primeiro datagrama com zero. A consulta o endereço de destino, escolhe B, escreve o identificador de B e encaminha. B interpreta sua própria chave, encontra a saída para C, substitui o campo pelo identificador de C e envia. C usa a chave que havia criado, limpa o campo e entrega a Y. O destino reconhece seu endereço e não precisa do identificador.

O recipiente de 64 bits permaneceu; a autoridade sobre o conteúdo mudou. Entre A e B, o valor descrevia algo em B. Entre B e C, descrevia algo em C. Para Y, podia não descrever nada necessário. Um mesmo número poderia apontar para objetos diferentes em dois equipamentos, e números diferentes poderiam levar ao mesmo enlace físico.

Uma captura isolada conserva os bits, mas perde o dicionário. Para explicar o encaminhamento, seria preciso preservar quem emitiu a chave, qual geração da tabela estava ativa, qual destino foi comparado, se houve validação ou busca alternativa, qual saída foi usada e que novo valor foi gravado.

Zero pedia uma decisão; não anunciava ausência de rota

O zero de X era normal. Significava que o pacote não trazia um identificador utilizável para o roteador atual. A então executava a descoberta convencional e semeava a próxima passagem local. Em certas conversões de protocolo, o campo também voltava a zero.

Valores inválidos recebiam tratamento parecido. Como o campo podia conter uma referência tão crua quanto um endereço de memória, a RFC recomendava validação e uma provável checagem de que a rota apontada cobria o destino do datagrama. Falhou a checagem, volta-se à tabela. Não há razão para transformar o fallback em prova de indisponibilidade.

Também não há razão para transformar o acerto em recibo de entrega. Um valor aceito prova, no máximo, que um objeto local foi reconhecido naquele instante. A seleção de interface, o recebimento pelo próximo salto e a chegada ao destino exigem observações próprias.

A RFC declarou que questões de segurança não eram discutidas. Validade estrutural não equivale a autenticação, autorização ou integridade. Uma chave de desempenho não se torna credencial só porque passou por uma verificação de faixa.

Agregação encerrava o conhecimento emprestado

Um identificador de entrada agregada podia ser útil até o roteador onde as rotas componentes se separavam. Ali, o equipamento precisava consultar o destino específico, escolher uma das ramificações e escrever a chave oferecida pelo próximo roteador. O campo não antecipava essa decisão.

Mudanças de rota criavam a mesma necessidade no tempo. A RFC dizia que, se a topologia mudasse com datagramas em trânsito, algum roteador teria de decidir como recolocar cada um nos trilhos. O identificador não congelava a rede. Ele chegava a uma máquina cujo estado podia ter mudado desde a emissão.

Por isso, continuidade numérica não é continuidade de caminho. Um valor pode permanecer por um trecho e terminar num ponto de desagregação; outro pode ser substituído por causa de convergência enquanto o pacote continua chegando. A interpretação correta pertence a cada decisão local, não a uma narrativa montada depois apenas com números.

O fluxo compartilhava a mesma limitação

TP/IX permitia que um identificador de fluxo ocupasse o lugar do identificador de rota. O roteador podia manter um objeto privado de fluxo apontando para a rota usada em sua criação; datagramas podiam entrar e sair desse fluxo.

O método para distinguir IDs de rota e de fluxo continuava privado. O emissor via apenas um valor opaco, implicitamente destinado ao próximo salto. Um campo não nulo não demonstrava reserva de recursos, capacidade, qualidade de serviço nem resultado. Para isso seriam necessários o tipo do objeto no emissor, sua geração, a rota associada, o horário e a observação de saída.

O mecanismo preservava uma escolha importante: interoperar sem padronizar a estrutura interna de cada roteador. Mas essa liberdade também impedia um coletor externo de promover o valor a significado universal.

RAP oferecia uma afirmação limitada no tempo

A RFC 1476 descrevia RAP, o protocolo companheiro de distribuição de rotas. Um comando Add Route deveria representar uma rota realmente carregada na base de encaminhamento do anunciante no momento da oferta. O par usaria o identificador recebido nos datagramas enviados de volta.

Era evidência operacional melhor que uma intenção abstrata, porém tinha data implícita. Carregada naquele momento não significa carregada para sempre. O comando Purge Route instruía a apagar a rota e revogá-la junto aos pares que a haviam recebido. O texto preferia enviar o purge antes da remoção local, mas reconhecia que não podia exigir essa ordem.

Entre a remoção, o envio, a propagação e os pacotes em voo havia uma janela. Um identificador podia ser autêntico como memória de uma oferta e obsoleto para a decisão atual. O registro da RFC 1476 confirma o documento, não reconstrói os relógios de uma operação.

Conversão zerava o que não podia conservar

TP/IX queria permitir que sistemas IPv4 e IPv7 fossem atualizados em qualquer ordem. Isso criou pontos de conversão. A opção “Don't Convert” regulava o comportamento de roteadores no fio, enquanto um host ainda podia fazer processamento interno. Fragmentos que tomassem caminhos distintos e chegassem a conversores diferentes poderiam ser perdidos. Ter um endereço IPv7 híbrido também não comprovava uma implementação nativa.

Na conversão IPv4 para IPv7, o identificador de rota adiante era definido como zero. O conversor não copiava uma referência privada sem significado para fabricar continuidade. Ele devolvia a autoridade ao próximo domínio, que faria uma decisão nova. Endereço, versão, ação do conversor, fragmentos e entrega continuavam fatos separados.

O fim documental responde a outra pergunta

O registro do RFC Editor hoje marca a RFC 1475 como Historic. A RFC 1752 registrou que TP/IX evoluiu para CATNIP, considerou CATNIP incompleto demais para a seleção e recomendou o SIPP de 128 bits como base de IPng. Mais tarde, a RFC 6814 tornou a RFC 1475 formalmente obsoleta ao tratar de opções IPv4 depreciadas. A RFC 791 continuou como referência do IPv4.

Essa sequência permite dizer o que foi proposto, como foi comparado e qual destino normativo recebeu. Não permite concluir que nenhum componente foi testado, nem que uma rede específica o executou. A publicação de uma especificação tampouco é evidência de implantação.

Documento, recomendação, código em execução, estado de equipamento, pacote observado e resultado de entrega pertencem a camadas diferentes. A história fica mais precisa quando não usa uma delas como substituta automática das demais.

Fontes