Resumen
- RFC 2003 antepone un encabezado IPv4 a un datagrama IPv4 íntegro: el par exterior identifica los extremos del túnel y el interior conserva los extremos originales.
- El TTL interior se consume al reenviar hacia el túnel; el TTL exterior se elige por separado y la mera desencapsulación no gasta el interior.
- DF y el MTU deciden dónde se fragmenta, quién reensambla y quién puede interpretar un error ICMP; protocolo 4 sólo identifica el tipo de carga.
El segundo reloj aparece en la entrada
RFC 2003 envuelve el datagrama original sin reemplazarlo. La dirección exterior de origen pertenece al encapsulador y la exterior de destino al desencapsulador. Dentro permanecen las direcciones del emisor y receptor originales. Hasta la salida se enruta por la dirección exterior; después vuelve a mandar la interior.
Si la entrada está reenviando, debe disminuir el TTL interior antes de encapsular. Si llega a cero, descarta el paquete y normalmente genera Time Exceeded. Nunca debe envolver un datagrama cuyo TTL ya sea cero. Cuando la propia entrada originó el datagrama, encapsular por sí solo no constituye ese salto de reenvío.
El TTL exterior se escoge para alcanzar la salida. Quitar el sobre no reduce el TTL interior, aunque el siguiente reenvío sí. Por eso ninguna resta hecha sólo sobre una captura exterior reconstruye de forma fiable la vida restante del paquete interior.
Dos pares de direcciones no forman una identidad larga
El valor 4 del campo Protocol dice que tras el encabezado exterior viene IPv4. RFC 1853 contrasta este mecanismo sin cabecera intermedia con otros túneles más adornados. Es una declaración de formato, no una firma. La fuente exterior puede ser legítima como entrada autorizada y, aun así, el origen interior necesita su propia validación.
Esta distinción importa para los filtros. El documento advierte que el envoltorio aparta de su posición habitual las direcciones originales, el protocolo de transporte y los puertos. Una política de frontera que sólo mire el exterior puede aprobar una relación entre túneles que nunca aprobó entre usuarios finales.
DF decide dónde nace la presión
El sobre tiene su propio Identification, Flags y Fragment Offset. Si el datagrama interior trae DF activado, el exterior también debe llevarlo. Si el interior permite fragmentación, la entrada puede activar DF exterior para aprender el MTU del túnel. La obligación sólo corre en una dirección: no se puede debilitar la prohibición del emisor, pero el operador puede endurecer su propio tramo.
Cuando el exterior se fragmenta, la salida debe reensamblarlo antes de retirar el encabezado. Allí terminan los búferes y temporizadores exteriores. Si, en cambio, el datagrama interior se fragmenta antes de ser envuelto, cada fragmento puede cruzar por separado y el destino final realiza el reensamblaje interior.
RFC 1191 define la señal IPv4: un router que no puede pasar un paquete DF envía Destination Unreachable, código 4, e informa el MTU del siguiente salto. En el túnel, ese ICMP regresa a la fuente exterior, la entrada. RFC 2003 exige que la entrada mantenga estado blando del MTU, longitud o TTL del camino y accesibilidad de la salida.
El valor útil que puede comunicar al emisor original descuenta el encabezado añadido. Pero si el interior permitía fragmentar y fue la entrada quien activó DF afuera, el estándar reconoce que quizá no haya nada sensato que decir al emisor por ese fallo concreto. Guardar una copia durante una sonda, fragmentar y reenviar, o excluir cierto tráfico de esa política son decisiones operativas, no evidencias inscritas en protocolo 4.
ICMP atraviesa una frontera semántica
Protocol Unreachable se traduce a red u host inalcanzable porque el origen interior no eligió el protocolo 4. Port Unreachable no se reenvía: el sobre no tenía puerto. Datagram Too Big sí debe cruzar la frontera. Un Time Exceeded en el trayecto exterior se comunica como Host Unreachable. Parameter Problem sólo puede atribuirse al origen cuando señala un campo copiado del interior.
RFC 792 pedía históricamente citar el encabezado culpable y apenas ocho octetos de carga. En IP-dentro-de-IP, esa cita puede acabar antes del encabezado interior. La entrada aprende entonces algo sobre el camino, pero no necesariamente qué datagrama original lo sufrió. Los errores posteriores que produce con su estado blando no mantienen una correspondencia uno a uno con cada ICMP interno.
La lectura vigente incluye dos correcciones
El texto de 1996 copiaba el TOS interior. RFC 3168 actualizó el tratamiento de los bits ECN: un túnel de funcionalidad plena preserva la señal de congestión entre entrada y salida; uno limitado desactiva ECN en el exterior. Perder la marca de congestión al quitar el sobre borraría información destinada a los extremos.
RFC 6864 actualizó la regla del Identification exterior. La unicidad depende de si la fragmentación es posible o efectiva; correlacionar todos los paquetes atómicos por ese campo le atribuye una garantía que ya no tiene. El registro del IETF muestra el estado Proposed Standard y ambas actualizaciones, pero no certifica una implementación concreta.
Una escala de prueba, no un salto de fe
RFC 791 define las piezas básicas de IPv4 y RFC 4459 documenta que MTU y fragmentación siguieron causando dificultades en túneles. La prueba debe avanzar por capas: especificación para la regla, configuración para la intención, captura de entrada para vincular el interior con el exterior, reensamblaje para reconstruir el sobre, captura de salida para el reenvío y confirmación de aplicación para un resultado posterior.
La primacía del código en ejecución separa publicación de conducta. La especificación inicial mínima deja espacio a decisiones futuras sin fingir unanimidad. Las capas de realidad impiden que una etiqueta, una configuración, una observación y un resultado se traten como sinónimos. Protocolo 4 permite abrir el sobre correcto; no entrega un acuse de recibo.
Fuentes
- RFC 2003 — IP Encapsulation within IP
- Ficha de RFC 2003 en RFC Editor
- Ficha de RFC 2003 en IETF Datatracker
- RFC 791 — Internet Protocol
- RFC 792 — Internet Control Message Protocol
- RFC 1191 — Path MTU Discovery
- RFC 1853 — IP in IP Tunneling
- RFC 3168 — Explicit Congestion Notification
- RFC 6864 — Updated Specification of the IPv4 ID Field
- RFC 4459 — MTU and Fragmentation Issues with In-the-Network Tunneling
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification
- Lu Heng — On Reality Layers
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

