Resumen

  • El bit más alto del tipo de opción IPv4 indicaba si la opción se copiaba sólo al primer fragmento o a todos los fragmentos derivados.
  • Fragmentar no era clonar una cabecera: podía cambiar el conjunto de opciones, IHL, longitud total, desplazamiento, MF y suma de comprobación sin romper la identidad del datagrama.
  • Copy 1 trasladaba una obligación de custodia, no una garantía de autenticidad o entrega. Las copias mutables podían divergir por ruta y el fragmento cero conservaba la versión decisiva para el reensamblado.

La diferencia entre heredar y duplicar

Una explicación superficial de la fragmentación dice que un paquete demasiado grande se divide y que cada pieza recibe una cabecera. Esa frase no responde qué cabecera. Si cada pieza recibiera una fotocopia íntegra, toda opción aparecería en todas partes. Si sólo la primera conservara las opciones, los demás fragmentos podrían perder instrucciones necesarias para atravesar la red por separado.

RFC 791 resolvió la decisión dentro del octeto de tipo de cada opción. El primer bit es Copied, los dos siguientes forman Class y los cinco restantes Number. Cero significa copiar la opción únicamente en el primer fragmento; uno significa copiarla en todos.

El primer fragmento se define por Fragment Offset igual a cero, no por el momento de llegada. Ése conserva todas las opciones del datagrama original. Los fragmentos posteriores conservan sólo las que declaran Copy 1. Por eso un mismo grupo de reensamblado puede contener cabeceras de longitudes distintas de manera deliberada.

La opción Loose Source and Record Route tiene tipo 131 y Copy 1. Record Route tiene tipo 7 y Copy 0. Al reunirlas en una cabecera original, el ejemplo deja visible el reparto: la instrucción de ruta acompaña a las piezas que serán encaminadas de forma independiente; el registro ordinario queda vinculado a la pieza que contiene el comienzo de los datos.

Antes del bit hubo una necesidad operacional

RFC 760, de enero de 1980, ya describía opciones copiadas a cada fragmento y otras presentes sólo en el primero. También exigía copiar selectivamente la cabecera Internet al formar un nuevo fragmento. RFC 791 no inventó de la nada el problema: lo volvió legible y aplicable a partir del propio tipo.

La regla común era mínima, pero la transformación exigía precisión. Para el primer fragmento se partía de la cabecera original. Para el siguiente se construía una cabecera que excluía las opciones no copiadas. Al reducir la zona de opciones, cambiaba Internet Header Length. También cambiaban Total Length, Fragment Offset y el indicador More Fragments. Finalmente se recalculaba Header Checksum.

El fragmentador producía objetos derivados. No tenía permiso para alterar cualquier semántica, pero tampoco podía limitarse a cortar la carga y repetir bytes. Su autoridad estaba descrita campo por campo.

Esto explica por qué una detección basada en “cabeceras no idénticas” resulta equivocada. La diferencia puede ser la prueba de que el fragmentador obedeció. La investigación debe preguntar si cada diferencia es la derivada exigida, no si toda pieza se parece a la primera.

Uno y cero no eran medallas de importancia

Strict Source and Record Route, tipo 137, y Stream Identifier, tipo 136, tienen Copy 1. Timestamp, tipo 68, y Record Route, tipo 7, tienen Copy 0. La antigua Basic Security Option, tipo 130, también tenía Copy 1. Esa distribución no ordena las opciones desde valiosas hasta prescindibles.

Copy 0 no autoriza a borrar la opción del datagrama entero. La selección completa continúa en el fragmento de desplazamiento cero. Copy 1 tampoco convierte la opción en una credencial. No aporta cifrado, autenticación, prioridad, fiabilidad ni confirmación de entrega. Sólo decide qué cabeceras derivadas deben incluirla.

El registro de parámetros IPv4 de IANA mantiene columnas separadas para Copy, Class, Number, Value, Name y Reference. El registro prueba la asignación y el documento normativo. No demuestra cuántos paquetes actuales usan una opción, qué producto la acepta ni si un router la ejecutó correctamente.

Una opción registrada puede no haberse enviado. Una opción enviada puede haber sido filtrada. Una que llegó puede no haber sido procesada. Y una procesada puede haber cambiado legítimamente. La evidencia debe mantener esas capas separadas.

Las copias podían escribir historias distintas

Cuando un fragmentador crea varias copias de una opción, todas parten de un estado relacionado. Pero RFC 815 advierte que los fragmentos pueden seguir caminos distintos. En una opción que registra ruta, cada camino puede añadir una secuencia diferente.

Por tanto, “copiada en todos” no significa “idéntica al llegar”. El bit distribuye la opción necesaria para el tratamiento de cada fragmento. No congela los campos que los routers están autorizados a actualizar después.

RFC 815 indica que, durante el reensamblado descrito, se usa la ruta de retorno registrada en el primer fragmento y se ignoran otras versiones. La decisión no combina las rutas ni escoge la más frecuente. Conserva una procedencia especificada: el fragmento cero.

Esa elección enseña algo más amplio sobre los datos derivados. La multiplicación de copias crea posibles versiones, pero no crea por sí sola una regla para reconciliarlas. La autoridad debe seguir documentada. Un colector que guarde sólo una opción normalizada puede borrar tanto la divergencia como la razón por la que una versión fue escogida.

El fragmento cero podía ser el último en llegar

RFC 815 señala que el receptor quizá no conozca el tamaño final de la cabecera hasta recibir el primer fragmento. Un fragmento posterior puede omitir opciones Copy 0 y mostrar un IHL menor. Si llega antes, ofrece una vista válida de sí mismo, no una descripción completa del original.

Confundir orden temporal con posición lógica crea un error sutil. La primera observación parece una base cómoda para reservar memoria o inspeccionar la capa superior. Pero su cabecera puede ser deliberadamente incompleta respecto del datagrama reensamblado.

RFC 6274 lleva el problema a una comprobación de seguridad. Para verificar que el resultado tiene espacio suficiente para la cabecera de transporte declarada, se necesita el IHL del fragmento cero. Si aún no está disponible, puede hacerse una prueba preliminar, pero la prueba completa debe repetirse cuando llegue.

El estado provisional no es un defecto que deba ocultarse. Es una representación honesta de la información disponible. El error aparece cuando una implementación convierte una conclusión reversible en una decisión definitiva antes de recibir la pieza con autoridad.

EOL y NOP impedían tratar las opciones como recortes arbitrarios

End of Option List y No Operation ayudan a terminar y alinear la zona de opciones. Si el fragmentador elimina opciones no copiadas, puede necesitar ajustar el cierre y el relleno para mantener la cabecera alineada a 32 bits.

Esto obliga a analizar la estructura. No basta con buscar octetos cuyo bit superior sea cero y borrarlos. Las opciones tienen límites y longitudes; cortar dentro de una opción, olvidar el final o dejar un IHL antiguo produciría una cabecera incoherente aunque la intención de Copy fuera correcta.

El mismo principio se aplica a opciones desconocidas. Una implementación quizá no entienda su política completa, pero debe conservar la gramática que le permite recorrerlas, copiar según el tipo o rechazar de modo explícito. Desconocer no equivale a adquirir libertad para reinterpretar.

La capa común funciona porque sus pocas invariantes son deterministas. Una especificación delgada no es una especificación vaga.

La fragilidad moderna no es una estadística universal

RFC 8900 vuelve a expresar la regla: todas las opciones IPv4 aparecen en el primer fragmento y sólo las de Copy 1 aparecen en los posteriores. Después analiza por qué la fragmentación es frágil ante pérdidas, middleboxes, filtros sin cabecera de transporte y límites de reensamblado.

Ese diagnóstico delimita mecanismos de fallo. No establece que todos los fragmentos se pierdan, que todos los equipos se comporten igual o que una opción concreta siga desplegada. Una recomendación arquitectónica no debe convertirse en un censo inventado.

IPv6 colocó la fragmentación sólo en el origen y organizó de otra manera lo que acompaña a cada fragmento. RFC 8200 sirve como contraste: la frontera cambió. No demuestra que el bit Copy de IPv4 careciera de función. Respondía a un mundo en el que también un router intermedio podía fragmentar y debía derivar semántica sin conocer la aplicación.

El que cortaba no se convertía en dueño del datagrama

En IPv4, el fragmentador puede ser el host de origen o un router, según MTU, camino y Don’t Fragment. El router del ejemplo inicial muestra con claridad una transformación intermedia, pero no agota los casos.

En ambos, el permiso es limitado: dividir la carga, preservar la identidad de reensamblado, calcular posiciones, seleccionar opciones por Copy, cerrar la cabecera y recalcular su suma. No incluye declarar irrelevantes las opciones Copy 0 ni garantizar la verdad de las Copy 1.

La división de autoridad reduce el ámbito común. Cada participante puede comprobar localmente el tipo y producir un resultado compatible. La adopción de la regla se vuelve real en código que fragmenta y reensambla, no por una declaración separada del comportamiento.

La captura debe conservar diferencias legítimas

Un análisis útil relaciona origen, destino, protocolo, Identification, Offset, MF, IHL, tipos de opción, bits Copy y orden de llegada. Busca infracciones concretas: una opción Copy 0 en un fragmento no cero, la ausencia de Copy 1, una longitud rota, mal alineamiento o una prueba provisional no repetida.

Si falta el fragmento cero, el informe debe decir que falta. No puede afirmar que el datagrama original carecía de Record Route o Timestamp. Si copias mutables difieren, debe examinar si la opción autorizaba el cambio antes de llamar contradicción al resultado.

La evidencia de calidad no obliga a todas las piezas a parecer iguales. Demuestra cómo cada una desciende de la original y qué regla resolvió la divergencia.

Fuentes y límite de evidencia

El análisis usa RFC 760, RFC 791, RFC 815, RFC 1122, RFC 1812, RFC 6274, RFC 8900, RFC 8200 y el registro IANA. Establecen diseños y consecuencias acotadas, no prevalencia actual, conformidad de productos, frecuencia de ataques ni resultados de todos los caminos.