Resumen

  • RFC 2004 cambia Protocol y destino en la cabecera original, cambia la fuente cuando procede y guarda los valores desplazados en un Minimal Forwarding Header de ocho o doce octetos.
  • S=0 elimina la fuente original porque el encapsulador ya era el emisor; la igualdad es una precondición del formato, no una autenticación.
  • El checksum del encabezado mínimo solo cubre ese encabezado. Decapsular con éxito demuestra reconstrucción sintáctica, no identidad, autorización, integridad de ruta ni entrega.

El encabezado original tomó prestado otro destino

La motivación de RFC 2004 era concreta: una encapsulación IP-in-IP convencional añade al menos veinte octetos y duplica campos. La alternativa no conserva una segunda cabecera completa. Deja el payload intacto, modifica la cabecera original y coloca después de ella una ficha de reenvío.

Protocol pasa a 55 y Destination Address pasa a ser la salida del túnel. Si el encapsulador no es el origen inicial, Source Address también se sustituye por una dirección del encapsulador. Total Length crece ocho o doce y el checksum IP se actualiza. Frente al sobre completo de RFC 2003, la forma corta ahorra doce octetos y la larga ocho. También conserva menos evidencia independiente del estado anterior.

Cuatro octetos aparecen solo cuando dejan de ser redundantes

El encabezado mínimo siempre guarda el Protocol original y el destino original. La fuente original aparece únicamente con S=1, produciendo doce octetos. Esa rama corresponde a un paquete reenviado: la fuente visible durante el túnel pertenece al punto de entrada, de modo que la fuente previa debe viajar aparte.

Con S=0, el encapsulador era el propio origen y no cambió Source Address. La ficha queda en ocho octetos porque la fuente necesaria para la salida sigue en la cabecera modificada. El bit permite analizar la longitud y aplicar la regla de restitución. No acredita el derecho sobre esa dirección, la identidad del nodo ni la autorización de la política. La ausencia es una decisión de codificación basada en igualdad, no una segunda prueba de igualdad.

Cada checksum protege un perímetro distinto

El checksum de dieciséis bits de la ficha se calcula solo sobre el Minimal Forwarding Header. No incluye la cabecera IP modificada ni el payload. Un resultado válido respalda la consistencia accidental de los campos guardados dentro de ese pequeño perímetro.

La cabecera IPv4 mantiene otro checksum. Se recalcula al entrar, cuando cambian direcciones, Protocol y longitud; y al salir, cuando se restauran valores, se elimina la ficha y se reduce Total Length. Ninguno es una firma. Dos perímetros que pasan sus sumas no producen por acumulación autenticación, confidencialidad o un recibo de aplicación.

Reconstruir no devuelve el reloj al pasado

La salida recupera los campos previstos, pero no reproduce cada byte observado antes del túnel. El checksum IP antiguo no fue guardado y se fabrica uno nuevo para el encabezado actual. Además, el TTL original permanece en la única cabecera y disminuye con el reenvío normal. Por eso los saltos del túnel pueden ser visibles a traceroute. No existe el reloj exterior independiente propio de RFC 2003.

La decapsulación prueba que la salida pudo interpretar 55, validar la estructura, retirar ocho o doce octetos y producir un paquete IPv4 coherente. No prueba que el emisor fuera auténtico, que la ruta estuviera autorizada, que no hubiera alteraciones previas, que el siguiente salto aceptara el paquete o que la aplicación lo recibiera.

La economía no admite fragmentos heredados

La entrada no puede usar encapsulación mínima si el datagrama original ya está fragmentado: la ficha carece de espacio para conservar la información de fragmentación anterior. Después de encapsular, la fragmentación IPv4 ordinaria sigue disponible si DF no lo impide, y RFC 1191 conserva su papel acotado.

RFC 2004 remite a RFC 2003 para bucles, ICMP y estado blando, y declara que no resuelve la seguridad. RFC 2002 aporta el uso Mobile IP, pero registrar un binding y reconstruir un datagrama son actos diferentes. RFC Editor y Datatracker prueban la identidad y el estado Proposed Standard del documento, no una implantación.

Las ideas de Lu Heng sobre Running-Code Primacy, Minimum Initial Specification y Reality Layers ofrecen una disciplina útil: un formato mínimo puede hacer verificable una transformación local; los resultados operativos siguen necesitando pruebas propias.

Fuentes