Resumen

  • RFC 1241 envolvía el «Clear Datagram» sin modificar con una cabecera IP exterior y una cabecera de protocolo de ocho octetos para transportarlo por otro espacio de encaminamiento.
  • Cada Flow ID de 32 bits era local a un encapsulador o desencapsulador, y una entidad superior no especificada debía mantener las tablas y las equivalencias entre saltos.
  • El ICMP generado dentro del túnel citaba la cabecera exterior y los ocho octetos de encapsulación, pero no el datagrama claro; el retorno podía perder la prueba del paquete original.

La ruta invisible necesitaba administradores visibles

El RFC 1241 de Robert Woodburn y David L. Mills apareció en julio de 1991 como protocolo experimental. Su arquitectura dividía la operación en dos espacios. El paquete IP anterior a la envoltura era el Clear Datagram, dentro del User Space. Los encapsuladores y desencapsuladores vivían en un Encapsulation Space con sus propias direcciones y rutas.

La propuesta permitía sortear un fallo de encaminamiento, una pasarela rota o un dominio problemático. También servía para experimentar con topologías virtuales sin enseñar el trayecto a la fuente. El encapsulador añadía la envoltura; el desencapsulador la retiraba y conservaba la dirección de origen del paquete interior.

La invisibilidad trasladaba las decisiones. Alguien tenía que seleccionar qué Clear Header entraba en qué trayecto y quién recibiría el paquete después. RFC 1241 llamó Flow —también túnel— al camino de extremo a extremo dentro del espacio de encapsulación. Un Flow podía recorrer varios pares de encapsulador y desencapsulador sin describir las pasarelas atravesadas en el User Space.

Su identificador era deliberadamente local. Los 32 bits no formaban un nombre global: una misma ruta podía tener un número distinto en cada nodo. Para que un error retrocediera, la tabla debía guardar la dirección del encapsulador anterior y el Flow ID que ese vecino reconocía. La causalidad de vuelta dependía de una cadena de traducciones.

El protocolo no decía cómo crear o renovar esas tablas. La responsabilidad pertenecía a una capa superior, y un experimento podía usar simples archivos ASCII. Por eso, que un identificador sea conocido en un nodo no demuestra que la tabla esté vigente, que el siguiente salto comparta la intención o que sobreviva la equivalencia necesaria para regresar.

El datagrama siguió intacto y, aun así, cambió

La envoltura incluía una nueva cabecera IP y ocho octetos con versión, tipo, código de causa, suma y Flow ID. Detrás quedaba el Clear Datagram original. La preservación de sus bytes no preservaba su tamaño en la red ni el significado de todos sus campos en el exterior.

Las direcciones exteriores eran las del encapsulador y el desencapsulador. Se copiaban prioridad y calidad de servicio; no se copiaban timestamp, record route ni source route. El TTL interior no se trasladaba al exterior, aunque debía reducirse antes de encapsular. Si un nodo usaba el Flow ID para evitar el reenvío IP normal, asumía también la obligación de tratar el TTL antes de la siguiente envoltura.

El MTU hacía visible la capa añadida. Un paquete que cabía en la interfaz de la fuente podía dejar de caber tras sumar cabeceras. RFC 1241 permitía fragmentar el exterior, pero advertía de la ineficiencia. Si el encapsulador prohibía esa fragmentación, el MTU efectivo del trayecto era menor y había que construir una respuesta útil para la fuente interior.

Los fragmentos introducían otro desacuerdo. La función de mapeo podía mirar puertos TCP o identificar una conexión. Si el paquete ya se había fragmentado, solo el primer fragmento conservaba la cabecera TCP; los demás ofrecían únicamente información IP. Una regla por puertos podía mandar el primero a un Flow y no reconocer el resto. Eso es una limitación del selector, no evidencia de que se produjera una interrupción concreta.

El RFC 1191 había descrito Path MTU Discovery mediante DF y el ICMP de «fragmentation needed». El túnel interponía un nuevo origen. Para el encaminador exterior, el remitente era el encapsulador, de modo que el mensaje regresaba correctamente allí. Convertirlo en información para la fuente original era otro problema.

Ocho octetos cerraron la ventana antes del paquete interior

El RFC 792 exigía que un error ICMP incluyera la cabecera IP causante y al menos 64 bits de datos posteriores. En RFC 1241, esos 64 bits correspondían exactamente a la cabecera de encapsulación. La copia no alcanzaba el primer byte del Clear Datagram.

El encapsulador conocía el destino exterior y el Flow ID, pero no recibía la cabecera IP interior ni los puertos que distinguían aquel paquete. Tampoco podía invertir el identificador: varios Clear Headers podían converger en el mismo Flow. El error describía el estado del trayecto exterior sin identificar de forma única la conversación interior.

El diseño tenía un error para Flow ID desconocido y otro formato para reenviar ICMP. El primero avisaba al encapsulador anterior y al gestor de tablas. El segundo avanzaba hacia atrás por el Flow, traduciendo el número local en cada salto. Nada de ello reponía los octetos interiores ausentes. Si el propio envío de un error fallaba, no nacía otro error.

Una solución provisional usaba el futuro. El ICMP recibido podía marcar el Flow; cuando llegara el siguiente paquete coincidente, el encapsulador originaría un nuevo error hacia su fuente. Así, una observación posterior expresaba un estado aprendido antes. No era recibo individual del paquete que falló, y el texto solo consideraba probablemente segura la idea para algunos tipos de mensaje.

Los textos posteriores refinaron la respuesta, no el pasado

Los documentos posteriores no prueban que RFC 1241 tuviera despliegue amplio. El RFC 1853 sí deja una relación documental precisa: diferenció IP-in-IP, sin una cabecera especial entre las dos IP, del protocolo 98 de RFC 1241 y reconoció que parte de su organización y texto procedía de él.

El RFC 2003 volvió a señalar que ocho octetos no bastaban para incluir la cabecera IP interior. Su tratamiento estándar pidió estado blando sobre MTU, TTL y alcanzabilidad del túnel. Con ese contexto, el encapsulador podía construir mejores mensajes para paquetes posteriores; aun así, un error exterior no se convertía automáticamente en prueba uno a uno de un paquete interior.

El RFC 4459 calificó después el tamaño de paquetes en túneles de problema común y no trivial. Fragmentar fuera, indicar un MTU menor, reservar capacidad o fragmentar dentro son decisiones diferentes sobre quién paga, quién conserva estado y qué resultado puede demostrarse.

RFC 1241 permite probar el formato propuesto, el alcance local de los Flow ID y la pérdida del Clear Datagram en la cita ICMP ordinaria. No permite afirmar qué producto lo ejecutó, si un paquete interior llegó o si su fuente recibió un error equivalente. Esa conclusión exige unir captura de entrada, versión de tabla, envoltura, observación de salida y bytes exactos del ICMP. Llamar «transparente» a la capa no rellena los huecos.

Fuentes