Resumo

  • RFC 2004 altera Protocol e destino no cabeçalho original, altera a origem quando necessário e guarda os valores deslocados em um Minimal Forwarding Header de oito ou doze octetos.
  • S=0 omite a origem original porque o encapsulador já era a origem. A condição reduz quatro octetos, mas não autentica endereço nem operador.
  • O checksum mínimo cobre apenas o cabeçalho mínimo. Reconstrução válida comprova uma etapa de processamento, não autorização, integridade do caminho ou entrega final.

A economia mudou o objeto preservado

RFC 2004 evita os campos duplicados de um segundo cabeçalho IPv4. A carga permanece intacta, mas o cabeçalho original vira o cabeçalho visível no túnel. Protocol passa a 55; Destination Address passa a indicar a saída; Source Address passa a indicar o encapsulador quando este não é a origem. Total Length cresce oito ou doze, e o checksum IP acompanha os novos valores.

Um cabeçalho IPv4 sem opções tem vinte octetos. Logo, a forma curta economiza doze e a longa economiza oito em relação ao envelope completo de RFC 2003. Só que RFC 2003 mantém a antiga cabeçalho inteiro dentro do novo. RFC 2004 mantém uma seleção de valores e uma regra para remontá-los.

O bit S decide se existe uma segunda cópia da origem

O cabeçalho mínimo sempre leva o Protocol original e o destino original. Quando S=1, também leva a origem original e mede doze octetos. Isso ocorre quando o ponto de entrada substituiu a origem pelo seu próprio endereço.

Quando o encapsulador é o próprio emissor, Source Address não precisa mudar. S=0 produz oito octetos e deixa a origem apenas no cabeçalho IP modificado. A omissão significa “o valor necessário já está aqui”. Não significa “este valor foi autenticado”. O bit não assina a relação, não autoriza o túnel e não prova que a política de origem foi cumprida. Sem registro de entrada, faltará uma cópia independente para testar a premissa.

Checksums não somam autoridade

O checksum de dezesseis bits do Minimal Forwarding Header cobre exclusivamente seus oito ou doze octetos. O cabeçalho IP e a carga ficam fora. Um resultado correto é evidência localizada sobre os campos salvos.

Há ainda o checksum do cabeçalho IPv4. Ele muda na entrada e muda de novo na saída, depois que Protocol, destino e talvez origem são restaurados, o pequeno cabeçalho é retirado e Total Length diminui. São dois perímetros de integridade acidental, não duas assinaturas. Mesmo ambos corretos não comprovam identidade, autorização ou conteúdo entregue.

Restaurar não apaga o percurso

O antigo checksum IP não foi arquivado; a saída calcula um valor novo para o cabeçalho atual. O TTL também não volta ao número anterior. Ele permanece na única cabeçalho enquanto o pacote atravessa o túnel e sofre decremento no encaminhamento comum. Assim, os saltos internos continuam visíveis a traceroute, ao contrário do relógio externo separado de RFC 2003.

Decapsular com sucesso prova que a saída reconheceu Protocol 55, escolheu o comprimento certo, devolveu campos e produziu um datagrama IPv4 utilizável. Não prova origem autêntica, política de entrada, caminho íntegro, aceitação posterior nem entrega à aplicação.

O formato pequeno recusa uma história de fragmentação já existente

Um datagrama já fragmentado antes da entrada não pode usar encapsulamento mínimo, pois não há espaço para preservar os dados de fragmentação anteriores. Isso não elimina a fragmentação IPv4 posterior quando DF está limpo; RFC 1191 continua delimitando o comportamento de MTU.

RFC 2004 delega laços, ICMP e soft state ao RFC 2003 e não cria segurança própria. RFC 2002 mostra o contexto Mobile IP, mas registro e transporte continuam distintos. RFC Editor e Datatracker confirmam o Proposed Standard, não uma implantação.

Em Running-Code Primacy, Minimum Initial Specification e Reality Layers, Lu Heng separa regra comum, adoção e resultado executável. RFC 2004 pode definir uma reconstrução verificável; só evidência operacional pode mostrar que ela ocorreu e aonde o pacote chegou.

Fontes