Resumo

  • O RFC 2185 tratou o alcance IPv4 e IPv6 como cálculos separados, embora o túnel aparecesse como um enlace comum.
  • Vazar uma rota para IPv6 era escolher o roteador que encapsularia o pacote antes de transferir a responsabilidade ao IPv4.
  • Uma rota visível, um endpoint alternativo, uma decapsulação ou uma entrega unilateral eram provas limitadas, não garantias de autorização, simetria ou serviço ponta a ponta.

A rota precisava encontrar o ponto de mudança

Publicado em setembro de 1997, o RFC 2185 descreveu uma transição longa em que infraestruturas IPv4 e IPv6 coexistiriam. O texto chamou de vazamento de rotas o anúncio de alcançabilidade entre regiões de roteamento. Rotas IPv4 eram aprendidas por protocolos IPv4 e rotas IPv6 por protocolos IPv6; uma implementação integrada não eliminaria a dualidade do cálculo.

O registro do RFC Editor e o IETF Datatracker classificam o documento como Informacional, não como padrão da Internet. Ele propôs um desenho derivado do trabalho ngtrans, mas não demonstrou adoção, desempenho em produção ou conclusão da migração.

Um túnel estático configurado manualmente parecia ao IPv6 um enlace ponto a ponto. As pontas formavam adjacência e trocavam rotas, enquanto o pacote externo seguia o caminho escolhido independentemente pelo IPv4. A adjacência provava um acordo entre duas pontas; não provava capacidade, filtragem, condições dos roteadores intermediários nem o trajeto de retorno.

O RFC 1933 detalhou mecânicas de transição, incluindo MTU, fragmentação e retorno de erros ICMP. O RFC 2003 especificou IP dentro de IP e exigiu conhecimento prévio de que a saída pudesse decapsular. Esses documentos explicavam o invólucro. O RFC 2185 perguntou qual rota levaria o pacote até o lugar certo para criá-lo.

O anúncio também nomeava quem encapsulava

No túnel automático entre hosts, endereços IPv6 compatíveis com IPv4 permitiam extrair as duas pontas externas e encapsular na origem. No modelo de roteador padrão configurado, o host enviava o pacote externo ao endereço IPv4 de um roteador dual ligado ao backbone IPv6; ali o cabeçalho era removido e o encaminhamento IPv6 recomeçava. O endereço configurado escolhia a fronteira de responsabilidade.

O caso roteador-para-host tornava a autoridade explícita. O roteador dual precisava injetar na região IPv6 o alcance correspondente aos destinos compatíveis com IPv4. O IPv6 conduzia o pacote ao roteador que havia anunciado a promessa. Só então o IPv4 assumia o segmento final encapsulado.

Havia uma escolha de escala. Um stub IPv4 pequeno podia ser representado por um prefixo agregado. Na borda de um backbone maior, era possível alimentar toda a tabela IPv4 no roteamento IPv6, aproximadamente duplicando o estado, ou selecionar manualmente destinos supostamente capazes de IPv6. A primeira opção gastava estado; a segunda gastava julgamento operacional e podia envelhecer silenciosamente.

O fallback também tinha significado restrito. O RFC descreveu rotas de host para os endpoints preferenciais e um prefixo de cobertura para que outro roteador recebesse o tráfego caso a rota específica desaparecesse. Isso mostrava que algum anunciante do prefixo amplo recebera o pacote externo. Não mostrava equivalência de política, túnel, filtros, MTU, capacidade ou continuação IPv6.

As duas direções podiam usar formas diferentes de túnel. Um teste de ida bem-sucedido não modelava o retorno. A seção de segurança registrou apenas que o tunelamento poderia violar firewalls da infraestrutura subjacente e não discutiu outros problemas. Entrega por roteamento não significava autenticação.

O que cada observação realmente prova

Uma entrada de rota mostra uma escolha do plano de controle. Um prefixo vazado mostra que uma região anunciou uma alegação a outra. Uma adjacência virtual mostra intercâmbio de controle. A decapsulação mostra que um pacote externo alcançou uma saída funcional. Uma resposta de aplicação oferece evidência adicional, mas somente para o sentido e o instante observados.

Nenhum desses sinais, isoladamente, comprova autorização do anúncio, ausência de loops, retorno simétrico, capacidade sustentada, entrega integral ou migração concluída.

Essa fronteira separa o tema de histórias próximas. O RFC 1955 propôs ENCAPS, deslocando outra abstração para cabeçalhos de domínio autônomo, DNS e roteadores de borda. O RFC 4213 documentou depois mecanismos básicos de transição e preservou a distinção entre um salto IPv6 aparente e o TTL e caminho IPv4 externos. A contribuição específica do RFC 2185 foi mostrar quem precisava fazer os dois planos se encontrarem.

A primazia do código em execução de Lu Heng fornece uma lente atribuída: documento e configuração não são execução. Sua especificação inicial mínima recomenda invariantes comuns estreitos e decisões futuras localizadas. Seu argumento sobre o imposto permanente da pilha dupla dá uma leitura econômica às superfícies paralelas; não é prova de implantação do RFC. O ensaio sobre camadas da realidade reforça que anúncio, caminho executado e serviço entregue pertencem a camadas probatórias distintas.

O memorando não provou o sucesso da transição. Seu valor duradouro foi localizar a troca de responsabilidade: o IPv6 prometia o encapsulador correto; o IPv4 prometia a saída externa; somente um resultado ponta a ponta poderia demonstrar que as duas promessas foram cumpridas.