Resumo

  • O RFC 1241 preservava o “Clear Datagram” dentro de um cabeçalho IP externo e de um cabeçalho próprio de oito octetos, transportando-o por um Encapsulation Space separado.
  • O Flow ID de 32 bits valia apenas no encapsulador ou desencapsulador local; uma entidade superior não especificada tinha de manter tabelas e traduções entre os saltos.
  • Um ICMP originado no túnel citava o cabeçalho externo e os oito octetos de encapsulamento, mas nenhum conteúdo do datagrama claro; o erro podia perder sua causa original.

A transparência transferia controle para a borda do túnel

Publicado em julho de 1991 por Robert Woodburn e David L. Mills, o RFC 1241 definiu um protocolo experimental. Ele chamou o pacote IP ainda sem embalagem de Clear Datagram, no User Space. Encapsuladores e desencapsuladores operavam em outro domínio de endereços e rotas, o Encapsulation Space.

O mecanismo podia contornar falhas de roteamento, gateways quebrados ou domínios indesejados. Também permitia experimentar com redes virtuais sem exigir que a origem conhecesse a topologia intermediária. A entrada acrescentava o invólucro; a saída o retirava e preservava a origem do pacote interno.

Esconder o caminho da origem não eliminava a decisão de caminho. O encapsulador precisava escolher qual Clear Header iria para qual rota, e o desencapsulador precisava saber o próximo passo. O documento chamou essa rota de Flow, também “tunnel”. Um Flow podia atravessar vários pares de aparelhos sem registrar quais gateways do User Space eram percorridos.

Seu identificador não era universal. Cada Flow ID de 32 bits era exclusivo somente dentro de uma entidade. A mesma rota podia receber outro número no salto seguinte. Para devolver um erro, cada tabela tinha de conservar o endereço do encapsulador anterior e o número que ele reconhecia. O retorno causal dependia de traduções locais sucessivas.

O RFC 1241 não definiu como as tabelas seriam criadas, atualizadas ou reconciliadas. Uma entidade de camada superior cuidaria delas; arquivos ASCII poderiam bastar num teste. Um acerto de Flow ID, portanto, comprova apenas a existência de uma entrada local. Não comprova que ela esteja atual, que o próximo nó concorde ou que a tradução de volta continue válida.

O conteúdo interno ficou igual, mas o pacote ficou maior

O cabeçalho de encapsulamento somava um novo IP e oito octetos com versão, tipo, motivo, checksum e Flow ID. O Clear Datagram seguia intacto. Ainda assim, o objeto encaminhado pela rede ganhava tamanho e novos endereços.

Origem e destino externos passavam a ser encapsulador e desencapsulador. Precedência e qualidade de serviço podiam ser copiadas, enquanto timestamp, record route e source route não eram. O TTL interno não era copiado, mas precisava ser reduzido antes do encapsulamento. Um desencapsulador que pulasse o encaminhamento IP normal por meio do Flow ID assumia essa obrigação antes de encapsular novamente.

O acréscimo consumia a margem do MTU. Um datagrama que cabia na interface da origem podia exceder a próxima interface depois da embalagem. Era possível fragmentar o pacote externo, embora o texto reconhecesse a ineficiência. Se a fragmentação fosse proibida, o MTU efetivo do espaço de encapsulamento diminuía e a origem interna precisava receber uma indicação útil.

A fragmentação anterior também afetava a seleção. A tabela podia discriminar por portas TCP ou por conexão. Só o primeiro fragmento IP, porém, preservava o cabeçalho TCP. Uma regra por porta poderia reconhecer a primeira parte e não as demais. O RFC não registra uma queda específica; ele delimita o que uma regra baseada no pacote completo consegue saber depois que o pacote foi dividido.

O RFC 1191 já havia descrito Path MTU Discovery com o bit DF e ICMP “fragmentation needed”. Dentro do túnel, o remetente visível era o encapsulador. O retorno ao encapsulador era correto para o pacote externo; convertê-lo em evidência para a origem do pacote interno era uma tarefa adicional.

A janela do ICMP fechava antes do datagrama claro

Pelo RFC 792, a mensagem ICMP incluía o cabeçalho IP ofensivo e ao menos os primeiros 64 bits de dados. No RFC 1241, esses 64 bits eram exatamente os oito octetos do protocolo de encapsulamento. Nenhum byte do Clear Datagram entrava na citação.

O encapsulador recuperava o destino externo e o Flow ID, mas não a origem IP interna nem as portas TCP do pacote. Como vários Clear Headers podiam mapear para o mesmo Flow, o identificador não era uma função reversível. O erro confirmava uma condição no caminho externo sem identificar de modo único a troca interna.

Um Flow ID desconhecido podia ser avisado ao encapsulador anterior e ao gestor da tabela. Outros ICMP podiam seguir para trás no Flow, com o ID traduzido em cada salto. Esse transporte não recriava os bytes internos. Se houvesse erro ao enviar um erro, nenhum novo aviso seria gerado.

O compromisso proposto usava o próximo pacote. Um ICMP marcaria o Flow, e o próximo Clear Datagram correspondente faria o encapsulador gerar um novo aviso para sua origem. O pacote seguinte comunicava estado aprendido no anterior. Não era recibo individual, e o próprio documento considerava a técnica provavelmente segura apenas para algumas classes.

A literatura posterior manteve a fronteira explícita

Textos posteriores não provam adoção ampla do RFC 1241. O RFC 1853, porém, distinguiu o IP-in-IP sem cabeçalho intermediário especial do protocolo 98 de RFC 1241 e declarou ter derivado dele parte da organização e do texto. Essa é uma influência documentada, não uma linhagem completa de implantação.

O RFC 2003 voltou ao limite dos oito octetos: eles não bastavam para incluir o cabeçalho IP interno. Sua solução manteve estado temporário de MTU, TTL e alcance do túnel. Esse contexto permitia gerar respostas melhores para pacotes subsequentes, mas não transformava cada erro externo em prova um a um do pacote interno.

O RFC 4459 chamou o tamanho em túneis de problema comum e não trivial. Fragmentar fora, sinalizar MTU menor, reservar folga ou fragmentar dentro distribuem custo, estado e evidência de maneiras diferentes.

O que RFC 1241 comprova é o formato proposto, a localidade do Flow ID, a tradução de retorno e a ausência do datagrama interno na citação comum. Ele não comprova implementação, entrega ou recebimento do erro por uma origem real. Para isso, seria necessário correlacionar captura de entrada, versão da tabela, embalagem externa, observação de saída e bytes exatos do ICMP. A palavra “transparente” não substitui essa cadeia.

Fontes