Resumen

  • El fragmento final y el fragmento cero son condiciones diferentes. El primero permite calcular la longitud; el segundo aporta el comienzo y el encabezado original.
  • Un receptor puede mantener bytes, huecos y un temporizador aunque nunca reciba offset cero. Al expirar, RFC 1122 exige eliminar el datagrama parcial.
  • El ICMP Time Exceeded Code 1 es obligatorio sólo cuando llegó fragmento cero. Por eso la ausencia del mensaje no demuestra que el reensamblaje no haya caducado.

Dos bordes que podían llegar por separado

RFC 791 no numeraba los fragmentos por orden de llegada. Fragment Offset indicaba la posición de sus datos. El que tenía offset cero aportaba el borde inicial. El que llevaba MF en cero aportaba el borde final. Entre ambos podían quedar huecos de cualquier tamaño compatible con la fragmentación.

La identidad del contexto procedía de la dirección de origen, la de destino, el protocolo y Identification. Con esa combinación, una pieza intermedia bastaba para que el receptor reservara recursos y colocara bytes. Si llegaba el fragmento final, podía calcular la longitud total. Sólo la presencia continua de todos los bloques desde cero permitía entregar el datagrama.

Esta arquitectura contiene una lección de evidencia. Saber dónde termina un objeto no significa poseer el objeto. Un log puede mostrar el último offset y varios segmentos recibidos, pero la ausencia del inicio mantiene inválido el conjunto entero.

La espera tenía un precio explícito

El ejemplo de RFC 791 asignaba a cada contexto un buffer de datos, otro de encabezado, un mapa de bloques, una longitud total y un temporizador. La espera comenzaba con un mínimo recomendado de quince segundos. Cada fragmento podía ampliarla si su TTL restante era mayor que el valor actual.

La propia RFC relacionaba tasa, tiempo y capacidad de buffer. Una demora más tolerante consume más memoria; una demora más estricta destruye antes y puede convertir una entrega lenta en pérdida. El timeout era una decisión de recursos incluso antes de que se reconociera el problema de usar TTL como reloj.

Ese reloj no era estable. Los routers descontaban TTL al menos una vez por salto, aunque no hubiera transcurrido un segundo. La cifra restante mezclaba distancia de encaminamiento con tiempo. Un receptor no podía deducir de ella una política consistente para su memoria.

Una lista de huecos podía empezar por el medio

RFC 815 simplificó el seguimiento: registrar lo que faltaba, no cada cosa presente. Un fragmento recortaba un hueco, lo dividía o lo cerraba. La lista vacía indicaba éxito. No había necesidad de que la primera llegada contuviera el comienzo.

El encabezado introducía una excepción. Algunas opciones IPv4 aparecen en todos los fragmentos; otras quedan sólo en el primero. Sin fragmento cero no siempre se conoce el tamaño ni el contenido exacto del encabezado original. El buffer puede organizarse para soportar esa incertidumbre, pero no puede inventar la información.

RFC 1122 recomendó el algoritmo y añadió que el encabezado del primer fragmento debía conservarse para un posible ICMP de timeout. El comienzo se volvió una pieza de la ruta de error, no sólo de la ruta de éxito.

Por qué no servía citar una pieza posterior

RFC 792 definió Time Exceeded Type 11, Code 1 para reassembly time exceeded. El mensaje devuelve el encabezado IP original y los primeros 64 bits de datos, destinados a ayudar al origen a asociar el fallo con su proceso.

Un fragmento posterior sí lleva dirección de origen. También contiene protocolo e Identification. La limitación no nace de una imposibilidad de direccionar la respuesta, sino de la calidad de la cita. La RFC restringe los errores ICMP a fragmento cero y permite omitir Time Exceeded si ese fragmento no está disponible.

Responder con una pieza posterior cambiaría silenciosamente el significado del formato. Los bytes citados ya no serían los primeros del datagrama original. El receptor sabría que su reensamblaje fracasó, pero no poseería el testimonio que el protocolo prometía adjuntar.

La regla fija devolvió la decisión al receptor

RFC 1122 estableció un timeout obligatorio y recomendó que fuera fijo, entre 60 y 120 segundos, no derivado del TTL. Esos números son orientación histórica, no un censo de configuraciones modernas.

Al vencer, el datagrama parcial debe descartarse. Si se recibió fragmento cero, debe enviarse ICMP Time Exceeded al origen. La redacción separa una obligación local sin condición de una obligación remota condicionada. La memoria se libera siempre; la explicación sólo se construye desde el inicio original.

La espera demasiado larga también afecta la identidad. RFC 6864 relaciona el horizonte de reensamblaje con el tiempo durante el cual un Identification no debe confundirse con otra generación para la misma combinación. Mantener viejos fragmentos prolonga tanto la ocupación física como la ambigüedad posible.

El nodo que reensambla es el destino

RFC 1812 evita atribuir esta carga a todo router. Cuando un router reensambla un paquete destinado a sí mismo, actúa como host y aplica los requisitos de host. El tránsito ordinario no convierte automáticamente cada salto en propietario del buffer.

Además, un error ICMP no debe generarse por un fragmento que no sea el primero. La investigación debe ubicar el contexto en el nodo que realmente era destino, no en cualquier equipo que vio pasar una pieza.

El mensaje visible selecciona sus propios casos

Si llega Code 1, el origen sabe algo acotado: el destino conservó un conjunto incompleto hasta el timeout, tenía fragmento cero y su error sobrevivió al camino de vuelta. No sabe qué pieza se perdió ni dónde.

Si no llega, las explicaciones se multiplican. Puede faltar fragmento cero; el destino puede limitar ICMP; el retorno puede ser filtrado o perdido; la implementación puede divergir. La métrica visible selecciona preferentemente fallos en los que sobrevivió el comienzo. Precisamente los casos sin comienzo pueden desaparecer de la estadística.

Conocer los dos bordes tampoco atribuye la pérdida

Incluso cuando llegan fragmento cero y fragmento final, el receptor sólo conoce el intervalo completo que pretendía reconstruir. Los huecos interiores muestran qué bytes no observó, no quién los eliminó. Un enlace pudo perderlos, un filtro pudo rechazarlos, el emisor pudo no producirlos o una captura pudo quedar incompleta. El mapa de offsets delimita el hecho local; no adjudica responsabilidad.

Code 1 conserva esa modestia. Cita el comienzo para que el origen identifique la invocación, pero no incluye una sentencia sobre el camino. Tampoco prueba que la longitud o el patrón de fragmentación vayan a repetirse. Una ruta nueva, un túnel distinto o una decisión diferente en el origen puede cambiar el conjunto siguiente.

Por eso no debe usarse el mensaje como sustituto automático de Path MTU Discovery. RFC 1122 imaginó que en el futuro podría ayudar a algún procedimiento de descubrimiento, pero el Code 1 por sí solo no anuncia un MTU, no señala un enlace estrecho y no garantiza que el problema naciera del tamaño. Es evidencia de expiración de un conjunto concreto.

La ausencia de ambos bordes tiene otro efecto. Sin final, el receptor puede ignorar la longitud total. Sin cero, carece del comienzo citado. Un sistema de observabilidad que sólo registre incomplete=true pierde cuál de esas incertidumbres estaba abierta. La diferencia modifica tanto el diagnóstico como la posibilidad de responder.

El modelo correcto no busca convertir cada silencio en causa. Conserva las condiciones observables y deja explícito lo desconocido. Esa disciplina parece menos satisfactoria que una etiqueta única, pero evita que la interfaz de monitorización afirme más que el protocolo.

El plazo cambiaba también la muestra estadística

Alargar el timer no sólo modifica cuántos bytes permanecen ocupados. Algunos conjuntos que antes expiraban alcanzan a completarse y salen del universo de errores. Otros siguen incompletos durante más tiempo. El número de Code 1 puede bajar mientras crece la memoria máxima, sin que haya contradicción.

Acortarlo produce el movimiento inverso. El receptor libera antes, pero aumenta el conjunto de datagramas demorados que no llegarán a la aplicación. Si fragmento cero estaba presente, también puede crecer la cantidad elegible para error. Comparar sólo ICMP received antes y después confunde cambio de política local con cambio del camino.

Los denominadores adecuados son contextos creados, contextos con cero, contextos con final, completados, expirados y desalojados antes del timeout. Cada ratio responde una pregunta distinta. La proporción de expirados sin cero mide una fuente normativa de silencio; la proporción de mensajes emitidos entre los elegibles mide otra etapa.

La ventana afecta además al Identification. Mantener más tiempo piezas antiguas prolonga el periodo en que reutilizar la misma combinación puede resultar ambiguo. Este coste no siempre aparece en el gráfico de memoria, pero pertenece a la misma decisión.

Por eso un cambio operativo necesita ensayo reversible. Debe definirse qué mejora se espera —menos expiración legítima o menos presión— y qué deterioro obliga a volver. Una cifra recomendada en una RFC no sustituye medición local, y una cifra local no reescribe el contrato de evidencia.

La ventana de observación debe superar el timeout probado. De otro modo, un contexto que aún espera aparece como si ya no existiera y el análisis favorece artificialmente los plazos cortos. También deben mantenerse comparables tamaños de datagrama, tipos de tráfico y cambios de túnel. Sólo entonces puede distinguirse una mejora de memoria de un simple desplazamiento temporal del fallo. La comparación debe registrar cuándo terminó realmente cada contexto, sin atajos.

Fuentes y límites

Las fuentes describen reglas y razones de diseño. No miden valores actuales, tráfico fragmentado, entrega de ICMP, filtrado ni cumplimiento de productos concretos.