Resumo
- A borda de entrada consultaria endereços de domínios autônomos, envolveria o datagrama num segundo cabeçalho IP e a borda de saída removeria essa camada, sem alterar os endereços originais.
- “Nenhuma mudança nos hosts” transferia custo: novos registros no DNS, endereços e rotas de domínio, encapsulamento nas bordas e vinte bytes adicionais em cada datagrama de trânsito.
- O texto é Informativo, não prova aceitação pelo IPng, implementação ou uso. Ele pressupunha unicidade global dos endereços IPv4 internos e não discutia segurança.
Um destino para chegar ao destino
O host emitia um pacote comum. No primeiro limite interdomínio, o roteador examinaria origem e destino internos, obteria no DNS outro par de endereços e criaria o cabeçalho externo. Durante o trânsito, a rede encaminharia esse novo destino. No último limite, o invólucro desapareceria e o destino antigo voltaria a comandar o percurso.
O plano fazia questão de não traduzir os endereços do pacote. Isso evitava editar checksums e procurar endereços escondidos em protocolos de aplicação. Mas conservar bytes não eliminava controle. A associação de domínio, a escolha da saída e a capacidade de retirar a camada eram estados novos.
Publicado em junho de 1996, o documento registra uma ideia enviada ao grupo ROAD em janeiro de 1992, originalmente por e-mail. Depois ela respondeu à solicitação de trabalhos do IPng. A própria RFC impede a celebração retrospectiva: publicação não significava aceitação das ideias pela área IPng.
O registro prova que a opção foi formulada. Não prova que a Internet a executou.
Ganhar tempo era o requisito
O debate ocorria sob relógios diferentes. Números de classe B escasseavam; tabelas de rotas já pressionavam memória, processamento e trabalho humano; o limite total do IPv4 era mais distante. Esperar uma arquitetura perfeita poderia deixar o problema próximo vencer primeiro.
ROAD dividiu a resposta em fases que deveriam começar juntas. No horizonte curto, alterar hosts não era aceitável. ENCAPS assumiu essa condição e se chamou de solução de médio prazo: manter a Internet funcionando enquanto alternativas duradouras eram escolhidas e implantadas.
O inventário de vantagens prometia hosts intactos, maioria dos roteadores intacta, nenhum protocolo novo, endereços existentes, ausência de tradução e tabelas menores. Eram metas, não medições. As fontes não trazem inventário de instalações, captura, teste de interoperabilidade ou redução observada.
A geografia externa viria do DNS
A entrada buscaria endereços AD correspondentes ao pacote e os colocaria na camada exterior. O texto sugeriu reservar pequenas parcelas de redes de classe A e B para representar domínios. Vários espaços poderiam formar “commonwealths”: cada agrupamento conheceria seus membros em detalhe e resumiria os demais.
Roteadores de borda injetariam endereços AD no roteamento interno dos domínios de trânsito. Equipamentos comuns poderiam tratá-los como destinos IP normais. BGP, IS-IS ou OSPF foram citados como possíveis mecanismos entre bordas.
A compatibilidade vinha da forma conhecida, não de conhecimento compartilhado. O roteador intermediário executaria o endereço externo sem compreender sua função especial.
Isso exigia que DNS e roteamento concordassem. Um mapeamento correto para uma saída inalcançável não entregava nada. Uma rota válida para um mapeamento antigo também falhava. E a chegada do invólucro à saída não comprovava a entrega interna.
Não traduzir ainda exigia memória
A NAT contemporânea alterava endereços e checksums, mantinha tabelas e precisava reconhecer endereços transportados pela aplicação; criptografia podia tornar a modificação impossível. ENCAPS evitava essa classe de intervenção ao manter o datagrama intacto.
Porém, entrada, mapeamento, identificador de domínio, rota externa e saída correta continuavam necessários. Um pacote perfeitamente preservado pode ser preservado no lugar errado.
Havia ainda uma hipótese central: endereços IPv4 internos permaneceriam globalmente únicos por bastante tempo. O texto cogitou formar unicidade com o par AD+IP. Se hosts continuassem sem mudança, seria necessário traduzir na borda; se a tradução fosse recusada, os hosts teriam de consultar e encapsular.
A proposta adiava a escolha; não a removia. Unicidade global, host intacto e fronteira sem tradução não poderiam ser garantidos indefinidamente ao mesmo tempo.
O preço não cabia em vinte bytes
A parcela visível era um cabeçalho IP de vinte bytes e processamento adicional nas duas bordas. A parcela operacional incluía novo registro por nome, distribuição de identificadores, roteamento da abstração, diagnóstico de duas camadas e responsabilidade sobre falhas assimétricas.
O documento não fechou política de cache, resposta negativa, autenticação do mapeamento, atualização unilateral, MTU, fragmentação, atribuição de ICMP ou retirada do sistema. Segurança não foi discutida. Essas lacunas não condenam automaticamente o conceito; apenas impedem que um diagrama seja tratado como prova operacional.
Mais tarde, IP dentro de IP ganhou regras mais completas e IPv6 emergiu do IPng. São comparações legítimas, não uma genealogia demonstrada.
CIDR cobrou de outros lugares
CIDR atacou o crescimento por alocação topológica e agregação de prefixos. Seus custos recaíam sobre política de endereçamento, protocolos, vínculo com provedores e possível renumeração. Não acrescentava uma camada AD a cada pacote.
ENCAPS construía outra hierarquia fora do datagrama existente. Ambos queriam comprar tempo, mas escolhiam pagadores diferentes. Dizer “agregação” sem nomear quem mantém tabela, quem muda pacote e quem pode sair esconde a decisão real.
Cada camada requer seu recibo
Pela primazia do código em execução, a RFC comprova texto. Um registro DNS comprovaria configuração. Uma borda preparada comprovaria capacidade local. Uma captura externa comprovaria encapsulamento num ponto. Saída correta, remoção, entrega interna e resultado da aplicação exigiriam outros recibos.
A especificação inicial mínima favorece experimentos limitados às bordas que decidem participar. Essa localização só permanece verdadeira se recusa, caminho comum e retirada continuarem possíveis. Um mapeamento provisório que passa a definir quem é válido já mudou de função.
Nas camadas da realidade, número proposto, registro publicado, cache, cabeçalho emitido, encaminhamento executado e serviço recebido não são sinônimos. RFC 1955 vale por tornar essa separação examinável sem nos permitir inventar sucesso.
Fontes e limites
A identidade está no registro da RFC 1955 e o mecanismo na RFC 1955. O problema ROAD vem da RFC 1380, e o processo IPng da RFC 1550. A alternativa CIDR é delimitada pela RFC 1519, e a tradução pela RFC 1631. Sem afirmar descendência, comparam-se a primeira especificação IPv6 e IP dentro de IP. A leitura segue Running-Code Primacy, Minimum Initial Specification e Reality Layers.
As fontes comprovam a proposta escrita e comparações limitadas. Não comprovam aceitação pelo IPng, padrão, implementação, implantação, adoção, desempenho, interoperabilidade, segurança, operador, tráfego real, produto atual ou linhagem causal.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
