Resumen

  • RFC 7112 exige que el fragmento IPv6 con Fragment Offset igual a cero incluya la cadena completa de encabezados hasta el primero de capa superior. Así, un filtro sin estado puede ver el selector de protocolo y, cuando corresponde, los puertos antes de decidir.
  • El control solo valida esa frontera. No autentica al emisor, no examina toda la carga, no garantiza la llegada de los demás fragmentos ni reemplaza el registro de MTU, reglas, errores ICMPv6, reensamblado y resultado del servicio.

Una pregunta sin el campo decisivo

Los encabezados de extensión son parte de la flexibilidad de IPv6. Entre el encabezado base y TCP pueden aparecer opciones, rutas, autenticación o fragmentación. Para el receptor, la secuencia se lee siguiendo cada valor Next Header. Para un equipo que aplica una regla por paquete, esa lectura es también una carrera contra el final del fragmento.

Si el corte ocurre antes de TCP, el filtro ve que el paquete continúa, pero no ve el puerto de destino. Puede enviar la pieza y descubrir demasiado tarde que la política habría ordenado descartarla. Puede descartarla y negar un flujo que habría sido válido. En ambos casos, la regla existe en la configuración, pero la observación disponible no permite ejecutarla fielmente.

RFC 7112 sitúa la corrección en el origen. El host que fragmenta un datagrama debe colocar en el primer fragmento la cadena IPv6 completa. En vez de exigir a todos los routers que mantengan estado y reensamblen, hace que la primera pieza lleve la presentación protocolaria necesaria.

Es una obligación pequeña con una consecuencia importante. El dispositivo ya no necesita adivinar qué tipo de encabezado quedó escondido en la segunda pieza. Puede seguir la cadena visible y llegar hasta el primer protocolo superior.

La carga no tiene que caber

«Cadena completa» no significa «paquete completo». La precisión es central para no atribuir al mecanismo más de lo que hace.

La cadena empieza en el encabezado IPv6 inicial. Incluye los encabezados de extensión referidos sucesivamente. Termina en el primer encabezado de capa superior o, si no existe, en No Next Header. TCP, UDP e ICMPv6 son ejemplos habituales. Un segundo encabezado IPv6 en un túnel cuenta como límite superior para esta definición; ESP también.

Los datos que siguen al encabezado TCP no pertenecen a la cadena. El primer fragmento debe mostrar TCP, pero no toda la conversación. Por eso la regla es compatible con cargas grandes y fragmentación real. El límite recae en el tamaño de los encabezados hasta la frontera superior, que debe caber dentro del MTU del camino.

La diferencia protege la lectura operativa. Un puerto visible permite ejecutar una ACL basada en puertos. No demuestra que el contenido posterior sea inocuo. Tampoco demuestra que el origen sea quien dice ser. La sintaxis suficiente para una decisión no es identidad ni autorización.

El desplazamiento cero abre un expediente

RFC 7112 llama primer fragmento a la pieza cuyo desplazamiento vale cero. El campo puede leerse sin consultar una autoridad ni terminar el reensamblado. Pero es solo la primera columna de un expediente.

La siguiente columna es el bit M. Indica si se esperan más fragmentos. Después vienen el identificador, la secuencia de Next Header, el punto exacto en el que acaba la pieza y el primer encabezado superior observado. Con esos datos se puede probar si la presentación está completa.

La construcción en origen es otro registro. Debe saberse qué versión de la pila generó el paquete, qué MTU creía vigente y qué encapsulaciones aplicó. Un cambio en un túnel puede reducir el MTU efectivo sin modificar la aplicación. Una cadena que antes cabía puede dejar de hacerlo.

RFC 7112 vincula la longitud de la cadena al MTU de la ruta. Si el host no realiza descubrimiento del MTU, debe limitarla a 1.280 bytes. Una infracción puede ser un intento evasivo, pero también un error de implementación o una creencia desactualizada sobre el camino. La clasificación llega después de la observación, no antes.

Origen, tránsito y destino no son la misma autoridad

El texto distribuye las responsabilidades de manera desigual y deliberada.

El origen tiene una obligación de construcción: cuando fragmenta, debe incluir la cadena. El host receptor debería descartar una primera pieza incompleta y debería enviar un error ICMPv6 conforme a las reglas generales. Para compatibilidad, una implementación puede ofrecer una opción que permita aceptarla.

Un router o cortafuegos intermedio puede descartar y puede enviar el error. Si dispone de esa función, debería permitir configurarla. Esto no es una orden universal de que todo equipo de tránsito aplique la misma política. Es una condición común que cada punto puede reconocer, con elecciones acotadas y auditables.

Por eso «la red bloqueó el fragmento» es una frase insuficiente. ¿Cuál equipo? ¿En qué interfaz? ¿Con qué versión de software y compilación de reglas? ¿Estaba habilitado el modo de compatibilidad? ¿El destino lo recibió? Sin estas respuestas, la atribución institucional ocupa el lugar de la prueba técnica.

Un error con nombre propio

Cuando un nodo descarta por esta causa y genera una señal, RFC 7112 especifica ICMPv6 Parameter Problem, tipo 4, código 3. El puntero se fija en cero. La descripción registrada señala que el primer fragmento IPv6 contiene una cadena incompleta.

La especificidad ayuda. Un equipo de desarrollo puede reproducir la condición. Un SOC puede observar un aumento tras actualizar una pila. Un operador puede comparar los mensajes con contadores de descarte y capturas tomadas a ambos lados de un equipo.

El código no debe convertirse en oráculo. Un sistema intermedio puede optar por no emitirlo. Las limitaciones de ICMPv6 pueden impedirlo. El retorno puede filtrarse, y una dirección falsificada puede enviar la señal a otro destino. Un código observado prueba que alguien generó un diagnóstico sobre un paquete citado; no identifica automáticamente al equipo ni prueba que todas las demás piezas eran válidas.

El recibo útil conserva hora, interfaz, paquete citado, punto de captura, regla y contador. El número 3 sin ese contexto es solo una notificación aislada.

Pasar la entrada no termina el viaje

RFC 8200 incorporó la regla al texto base de IPv6. En su modelo, los encabezados que deben acompañar cada fragmento aparecen antes del encabezado Fragment. En la primera pieza se colocan además las extensiones posteriores y el encabezado superior. Las piezas siguientes llevan sus desplazamientos y datos. El destino reúne el conjunto.

Son máquinas distintas. El control de RFC 7112 pregunta si la primera pieza expone la frontera necesaria. El reensamblador pregunta si llegaron suficientes piezas, si sus longitudes son correctas, si se superponen, si caben en el tamaño permitido y si lo hicieron antes del plazo.

Una primera pieza conforme puede quedarse sola hasta que venza el temporizador. Dos piezas pueden solaparse y obligar a abandonar todo el datagrama. Un duplicado exacto puede descartarse sin destruir las demás. La última pieza puede perderse. Ninguno de esos resultados retroactivamente vuelve incompleta la cadena inicial.

También es posible que un filtro descarte la primera pieza y reenvíe posteriores. El destino no puede reconstruir sin offset cero, de modo que la política puede haberse aplicado aunque los contadores muestren fragmentos enviados. «Se reenviaron fragmentos» no equivale a «se admitió el datagrama».

Para investigar, hacen falta tres estados separados: validación inicial, reensamblado y servicio. Una sola bandera de tráfico fragmentado borra el orden causal.

El fragmento atómico no espera a nadie

RFC 6946, cuyo autor es Fernando Gont, corrige otra mezcla de estados. Un fragmento atómico incluye encabezado Fragment, pero tiene desplazamiento cero y bit M cero. Es un datagrama completo; no hay segunda pieza.

Algunas pilas lo trataban como si debiera compartir una cola de reensamblado con piezas que tuvieran la misma fuente, destino e identificador. Eso permitía que tráfico ajeno interfiriera con un paquete que en realidad estaba completo. RFC 6946 ordena procesarlo de forma independiente, y RFC 8200 conserva esa separación.

El parecido visual no hace equivalentes los casos. Un primer fragmento incompleto puede tener offset cero y M uno. Un atómico tiene cero y cero. Un solapamiento requiere varias piezas. Cada uno cambia un estado distinto.

Los sistemas de observabilidad deberían guardar los campos que permiten reconstruir esas clases. Si transforman todos los casos en la etiqueta «IPv6 fragmentado», el dato original sobrevive en el cable y muere en el repositorio.

Lo que demuestra la incorporación a RFC 8200

RFC 7112 actualizó RFC 2460 en 2014. Tres años después, RFC 8200 sustituyó la especificación anterior e incluyó la obligación: las extensiones y el encabezado superior posteriores a Fragment deben estar en la primera pieza. También incorpora el descarte recomendado y el código 3 cuando faltan.

RFC 9099 traduce esa arquitectura en guía de seguridad operativa. Recomienda que los equipos de filtrado y los destinos descarten primeras piezas sin la cadena completa, incluido el encabezado de transporte, porque de otro modo puede eludirse un filtro sin estado.

La secuencia de documentos muestra que la condición pasó de actualización a base protocolaria y luego a práctica recomendada. No demuestra la conducta de un modelo de equipo en producción. Puede haber interruptores heredados, límites del parser en hardware o diferencias en la emisión de ICMPv6.

La adopción real se prueba con paquetes diseñados, capturas, contadores y resultados. El texto fija el vector de prueba. El dispositivo produce la evidencia.

La contribución documentada de Fernando Gont

Fernando Gont no firmó RFC 7112 solo. Vishwas Manral y Ron Bonica son coautores, y el documento pasó por revisión y consenso del IETF. Hablar de su aporte no autoriza a convertir una obra colectiva en patente biográfica.

Su historial sí permite identificar una línea de trabajo. RFC 6946 separa el fragmento atómico de una cola que no le corresponde. RFC 7112 obliga a que la primera pieza muestre el encabezado necesario para decidir. El perfil actual del IETF enumera 40 RFC y presenta una trayectoria en seguridad de protocolos.

En ambos mecanismos, el valor está en hacer explícitas fronteras que una implementación podía confundir. La norma define un estado verificable; el operador escoge el tratamiento; el código revela si la implementación lo cumple. Ninguno hereda autoridad sobre los demás.

El primer fragmento no tiene que revelar toda la carga. Tiene que decir lo suficiente para que el próximo sistema sepa qué decisión está tomando y qué decisión todavía queda pendiente.

Fuentes