Resumen

  • RFC 1191 hizo que el origen IPv4 marcara Don't Fragment y que el router limitante devolviera por ICMP el next-hop MTU. El camino observaba; el extremo conservaba la estimación y decidía cómo reducirla.
  • RFC 2923 documentó el PMTUD black hole: si el aviso era filtrado o se perdía, una conexión TCP podía abrirse y después detenerse cuando empezaban los segmentos grandes. MSS no medía por sí solo el camino.
  • En el caso de Cloudflare de 2015, TCP e ICMP usaban hashes ECMP distintos. El control llegó a la red del operador, pero no al backend que mantenía el estado pertinente.
  • PLPMTUD y DPLPMTUD trasladaron más control al extremo mediante sondas y confirmación de entrega. Evitar la dependencia de ICMP exigió tráfico, estado y distinguir una barrera de tamaño de otras pérdidas.

Dos distribuciones para un mismo problema

Cloudflare había ampliado el uso interno de Equal-Cost Multi-Path routing. Para TCP, el equipo calculaba un hash con las direcciones y los puertos de origen y destino. Así, los paquetes de una conexión permanecían en el mismo servidor.

El mensaje ICMP no ofrecía la misma información al distribuidor. Según el relato del operador, el hash para ICMP se apoyaba en las direcciones de origen y destino. Packet Too Big podía acabar en otro servidor aunque el flujo TCP continuara en el suyo. Cloudflare afirmó que eso fue exactamente lo ocurrido.

El postmortem menciona solo a un par de usuarios conectados mediante túneles IPv6. No permite estimar la frecuencia global ni atribuir daños a un tercero. Sí permite ver una forma concreta de fallo: la organización recibió la evidencia, pero su arquitectura rompió la asociación con el estado de conexión.

Como medida temporal, Cloudflare redujo a 1280 el MTU de IPv6 y habilitó para IPv4 el sondeo descrito en RFC 4821. Después creó un daemon que capturaba fragmentation needed en IPv4 y Packet Too Big en IPv6, y los difundía por Ethernet a todos los backends.

El repositorio establecía por defecto un paquete por segundo desde una fuente y diez por segundo en una interfaz. Compartir la evidencia resolvía un problema de pertenencia, pero abría otra superficie de validación, capacidad y abuso. Era una reparación para esa arquitectura, no una norma para todos.

La alternativa conservadora tampoco conocía el camino

RFC 1191, publicado en 1990, define Path MTU como el menor MTU de los saltos entre origen y destino. Es una propiedad estimada de un recorrido. Si cambia la ruta o aparece un túnel, puede cambiar el mínimo aunque se mantengan las direcciones.

Antes, un host podía usar el menor valor entre 576 octetos y el MTU del primer salto. Era prudente frente a lo desconocido, pero enviaba paquetes innecesariamente pequeños por trayectos capaces de transportar más. Tampoco evitaba que un router posterior fragmentara si su enlace era más estrecho.

La fragmentación IPv4 trasladaba el ajuste al interior de la red. El destino tenía que recomponer las piezas y la pérdida de una podía invalidar el datagrama completo. La experiencia recogida después en RFC 8900 añadió otras fragilidades: middleboxes con estado, filtros, rutas desiguales y encapsulaciones.

La decisión histórica no fue entre una técnica perfecta y otra absurda. Había que repartir el coste entre paquetes pequeños, fragmentación en routers, mensajes explícitos del camino y recuperaciones posteriores. RFC 1191 prefirió la información explícita para aprovechar mejor el recorrido sin fragmentar rutinariamente.

Un router podía declarar el problema, no elegir la cura

En el PMTUD clásico de IPv4, el origen activa Don't Fragment. Si un router no puede reenviar el datagrama por su siguiente enlace, lo descarta y envía ICMP Destination Unreachable con el código fragmentation needed.

RFC 1191 exige incluir el next-hop MTU. El host debe disminuir su estimación y puede enviar menos bytes o dejar de marcar DF. El router tiene autoridad sobre su interfaz y la capacidad de informar; no adquiere autoridad sobre la política del transporte.

Ahí se formó la dependencia. El router poseía una observación directa. El extremo poseía el algoritmo que podía cambiar el paquete. El mensaje ICMP era la conexión institucional entre dos poderes que no podían sustituirse.

La subida de tamaño quedaba sometida a otra regla. Un ICMP no podía aumentar el PMTU estimado; el host debía probar más tarde. RFC 1191 recomendó esperar al menos cinco minutos después de una reducción, preferiblemente diez, antes de ensayar un valor mayor.

Esos tiempos pertenecen a la guía histórica y no describen todas las implementaciones actuales. Expresan una frontera probatoria: las rutas varían y un mensaje puede ser falso o antiguo; ningún número debe convertirse en permiso permanente.

IPv6 dejó la fragmentación en el origen

La base actual de IPv6 exige que cada enlace transporte 1280 octetos o fragmente y recomponga por debajo de IP. Los routers IPv6 no fragmentan paquetes en tránsito. Solo el origen puede añadir un Fragment header.

RFC 8200 recomienda firmemente PMTUD para usar tamaños superiores a 1280. Una implementación mínima puede limitarse a 1280. Esa salida reduce la dependencia de descubrimiento y sacrifica eficiencia en caminos más amplios; no demuestra que todos los caminos tengan ese MTU.

RFC 8201 dispone que un router incapaz de reenviar envíe ICMPv6 Packet Too Big. El receptor del aviso debe comprobar que el paquete citado corresponde a tráfico propio. Puede reducir su estimación, pero no por debajo del mínimo IPv6 de 1280.

El aviso tampoco puede elevarla. Después de una reducción, el extremo puede sondear hacia arriba con intervalos de al menos cinco minutos, preferiblemente diez. El router presenta un límite local; el extremo valida, conserva y decide.

RFC 4890 coloca Packet Too Big entre los mensajes ICMPv6 que un firewall no debe descartar porque su ausencia puede impedir o dañar seriamente una comunicación. Es una recomendación operativa precisa. No acredita el cumplimiento universal ni obliga a tratar todo ICMP de la misma manera.

El black hole no borró el límite, borró su explicación

RFC 2923 describió en 2000 un problema ya antiguo. Un router, un error de kernel, una configuración o un firewall podía impedir el retorno del ICMP. El origen seguía enviando un tamaño que el camino no podía transportar.

TCP hacía engañosa la experiencia. El handshake podía completarse porque sus paquetes eran pequeños. Los primeros datos circulaban. Cuando aparecía un segmento grande, desaparecía; las retransmisiones repetían el mismo tamaño y la conexión parecía congelada.

El ejemplo FTP del RFC separa un canal de control pequeño que funciona de una transferencia masiva que falla. Es un patrón para investigar, no una prueba automática. Congestión, corrupción u otras políticas asimétricas pueden producir pérdidas semejantes.

Por eso un diagnóstico necesita tamaños, familia IP, DF o Fragment, retransmisiones y el contenido citado en cualquier ICMP. El hecho de que una descarga falle después de abrir la conexión no basta para declarar un MTU black hole.

MSS no sustituye esa información. Indica el máximo payload TCP que el receptor está dispuesto a aceptar. No conoce todas las encapsulaciones del trayecto de ida y el trayecto de vuelta puede ser distinto.

RFC 2923 prefería corregir el black hole de ICMP. También admitía una detección local que redujera el tamaño tras varios timeouts. Esa recuperación tardaba segundos y podía ocultar un defecto que seguiría afectando a otros flujos.

Una política local podía vetar la adaptación

Un operador tiene autoridad legítima para filtrar su propia red. Las fuentes no prueban malicia, ilegalidad ni una motivación privada de un firewall concreto. La crítica verificable se refiere al alcance de ese poder.

Descartar Packet Too Big no vuelve transmisible el paquete original. Solo elimina la observación que necesitaba el extremo. El filtro ejerce un veto práctico sobre la corrección sin poseer la medida del enlace ni la responsabilidad completa del transporte.

Los túneles añaden cabeceras después de que el extremo elige tamaño. ECMP y anycast pueden separar la instancia que recibe datos de la que ve el error. Un MTU aislado de la hora, dirección, flujo y encapsulación no es una propiedad duradera de un prefijo.

Un titular de direcciones debe conservar esa distinción. Un RIR asigna recursos numéricos; no certifica el MTU extremo a extremo de todas las rutas hacia el titular. Un cambio operativo puede romper grandes paquetes sin alterar el ASN, el prefijo o la IP del servicio.

PLPMTUD convirtió el silencio en un experimento

RFC 4821 definió en 2007 Packetization Layer PMTUD. En lugar de esperar necesariamente un ICMP, la capa que forma los paquetes envía sondas de tamaño creciente y aprende de su entrega o pérdida.

La autonomía no elimina la ambigüedad. Una sonda grande perdida de forma aislada puede indicar que se cruzó el límite. Si se pierden otros paquetes cercanos, la congestión u otra causa impide concluir. Hacen falta estado de búsqueda, temporizadores y nuevas comprobaciones.

La carta del grupo PMTUD de la IETF describió las debilidades del método anterior como un obstáculo crónico para enlaces y túneles nuevos. Propuso empezar con paquetes pequeños y sondear hacia arriba sin depender de ICMP. Es un registro del encargo institucional, no una prueba de consenso o despliegue mundial.

RFC 8899 aplicó el principio a las capas de packetización de datagramas. DPLPMTUD ensaya tamaños, aumenta el valor confirmado tras una prueba de entrega y lo reduce ante un black hole. Puede usar un PTB validado, pero no depender solo de él ni usarlo para aumentar.

UDP no incorpora acknowledgements. La aplicación o su capa de packetización debe confirmar las sondas. El control vuelve al extremo, junto con el coste de generar tráfico, mantener estado e interpretar la pérdida.

La salida moderna conserva varias puertas

La especificación TCP actual recomienda firmemente PMTUD y recomienda PLPMTUD. Mantiene tamaños pequeños por defecto cuando falta MSS, a la vez que advierte del perjuicio de rendimiento. El sondeo complementa el mensaje del router; no lo hace inútil.

La documentación Linux actual muestra las opciones. tcp_mtu_probing=0 desactiva el sondeo TCP. El modo 1 lo activa al detectar un ICMP black hole. El modo 2 lo mantiene activo desde un base MSS configurado. El intervalo documentado tiene un valor predeterminado de diez minutos.

Estos datos pertenecen al producto, no miden la configuración del mundo. Prueban que dos hosts conformes pueden ejercer estrategias distintas. Firewalls, túneles, kernels y aplicaciones forman una base instalada que no cambia de manera coordinada.

RFC 8900, por eso, no abolió la fragmentación. Catalogó su fragilidad y recomendó reducir la dependencia en capas superiores. La solución heredada combina señal explícita, validación, sondeo de salida y un tamaño conservador cuando lo demás falla.