Resumen

  • IPv4 permitió que un gateway fragmentara el datagrama que no cabía en el siguiente enlace y dejó el reensamblaje al destino. Ocultaba la diversidad de las redes, pero una sola pieza perdida comprometía el conjunto.
  • El PMTUD clásico hizo que la fuente marcara DF y redujera el tamaño tras recibir un ICMP de fragmentación necesaria. Cuando ese aviso no volvía, los paquetes pequeños funcionaban y los grandes caían en un agujero negro.
  • PLPMTUD trasladó la prueba a la capa que forma los paquetes: comienza con un tamaño útil, envía sondas mayores y confirma su entrega. La red ofrece evidencia limitada; el emisor conserva el control revisable.

El datagrama que no cabe en la próxima red

Las redes reunidas por Internet no compartían un único tamaño máximo. RFC 791, de septiembre de 1981, definió direccionamiento y fragmentación como las dos funciones básicas de IP. Un gateway podía dividir un datagrama cuando una red posterior sólo admitía paquetes menores.

Identification, Fragment Offset y More Fragments daban al destino la información necesaria para reconstruirlo. La diferencia física desaparecía para las capas superiores, pero no su coste: el cuello de botella producía más paquetes, el receptor mantenía estado y la pérdida de un fragmento impedía completar el datagrama original.

El bit Don't Fragment ofrecía otra asignación de responsabilidad. Un paquete DF que no cupiera tenía que descartarse. La fuente podía evitar la fragmentación intermedia, pero sólo se adaptaría si recibía una explicación útil. Sin ella, el descarte era indistinguible de muchas otras pérdidas.

El Path MTU es el mínimo MTU de los enlaces de una ruta concreta. No pertenece para siempre al destino. Una nueva ruta, los encabezados de un túnel o una rama distinta de multipath cambian el espacio disponible.

Una opción que todos debían editar

En julio de 1988, RFC 1063 propuso que el propio recorrido anotara el mínimo. Probe MTU salía con el límite del primer enlace. Cada gateway lo comparaba con sus interfaces y reducía el valor; Reply MTU lo devolvía a la fuente.

El texto veía bien el problema: elegir poco desperdicia capacidad y multiplica cabeceras; elegir mucho causa fragmentación; enviar sondas adicionales consume red y envejece con los cambios de ruta. También separó TCP MSS del MTU del camino. MSS expresa cuánto dato TCP acepta el par; PMTU, cuánto paquete IP transporta el recorrido.

La precisión exigía cooperación general. El propio RFC reconocía que algunos gateways no conocían todavía ambas interfaces cuando trataban opciones IP y que soportarlas podía requerir cambios importantes. Cada nodo poseía una parte del conocimiento, pero el mecanismo dependía de actualizar todos.

Que responda sólo el enlace que rechaza

RFC 1191, publicado en noviembre de 1990, redujo la tarea. La fuente comienza con el MTU del primer salto y envía con DF. Sólo el router que no puede reenviar intacto descarta y devuelve ICMP Destination Unreachable, código de fragmentación necesaria con DF. La fuente baja su estimación.

El RFC asignó a un campo ICMP antes vacío el MTU del siguiente salto que causó el rechazo. El router ya no modifica cada paquete: informa cuando fracasa un tamaño. Mantener DF permite descubrir otra vez una ruta que se estreche.

Los routers antiguos devolvían cero. Para ellos, la fuente buscaba hacia abajo entre “mesetas” de MTU frecuentes. Era preferible subestimar unos puntos porcentuales a pasarse por un solo octeto. La tabla era una ayuda de implementación, no un catálogo permanente de enlaces.

El estado también debía envejecer porque la ruta podía ensancharse. Los intentos de aumentar se espaciaban para no convertir el aprendizaje en pérdida repetida. Un error podía reducir la estimación, pero jamás elevarla por su contenido: el aumento necesitaba entrega real.

Alcanzable para el saludo, invisible para los datos

El diseño clásico necesitaba que el ICMP llegara a la fuente. RFC 2923, en 2000, catalogó el agujero negro resultante cuando un router no generaba el aviso o un firewall bloqueaba ICMP. El emisor repetía el mismo paquete DF demasiado grande sin saber que debía disminuirlo.

La conexión parecía medio sana. El saludo TCP era pequeño y se completaba. Ping y tráfico interactivo podían pasar. El primer tramo grande de una transferencia desaparecía, se retransmitía con igual tamaño y acababa agotando el tiempo. Existía conectividad, pero no para la unidad elegida.

Una reducción automática puede recuperar el servicio y ocultar la causa, imponiendo menor rendimiento durante años. Además, no todo agujero negro nace en un firewall: túneles, rutas asimétricas, limitación de ICMP o errores de MTU en capa 2 también rompen la cadena de evidencia.

RFC 8201, la especificación actual de PMTUD para IPv6, describe la misma combinación de saludo exitoso y datos detenidos si Packet Too Big no llega. Los routers IPv6 no fragmentan en tránsito; el origen elige el tamaño y, cuando procede, fragmenta.

Convertir la entrega en experimento

RFC 4821, de 2007, no esperó sólo la explicación de una pérdida. Packetization Layer PMTUD empieza con un tamaño que funciona y prueba paquetes progresivamente mayores. Una confirmación eleva el límite inferior; el fallo concluyente de una sonda aislada reduce el superior.

La capa de paquetización decide cómo dividir los datos —TCP en el caso habitual— y sabe qué sonda fue reconocida. Puede conservar el tráfico normal en un valor seguro mientras experimenta. Pero no recibe permiso para ignorar la congestión: un timeout o pérdidas adicionales vuelven ambiguo el resultado y exigen el control de congestión ordinario.

Una sonda perdida no demuestra por sí sola una barrera de MTU. Una entregada tampoco garantiza todos los futuros caminos ni todas las ramas de igual coste. Por eso el método usa rangos, repeticiones, temporizadores y estado que debe revalidarse.

PLPMTUD puede aprovechar ICMP, pero no depende de él. La información del router sigue siendo valiosa; deja de ser el único canal capaz de permitir o bloquear el progreso. A cambio, el extremo asume confirmaciones, búsqueda, contabilidad de cabeceras y coordinación con el estado de congestión.

El problema reaparece en los datagramas

IPv6 conserva la necesidad de descubrir. Un nodo puede limitarse al mínimo IPv6 y perder eficiencia en rutas más amplias, o buscar un tamaño mayor con mecanismos resistentes a la ausencia de PTB.

RFC 8899, de 2020, definió DPLPMTUD para transportes y aplicaciones de datagramas, incluidos protocolos sobre UDP, SCTP y QUIC. Cuando el transporte no confirma recepción, la aplicación debe proporcionar una señal que identifique la llegada de la sonda.

Los datos corrientes se mantienen dentro del tamaño efectivo; una sonda especial puede superarlo. Detectar un agujero negro reduce el valor; confirmar sondas permite subirlo. Un PTB validado puede acelerar la búsqueda, pero es opcional y debe corresponder a tráfico realmente enviado.

La dirección histórica no fue una expulsión del núcleo. La fragmentación ocultó la heterogeneidad con costes amplificados. La opción de 1988 recogía información precisa y pedía cambios en todos. ICMP hablaba sólo al fallar, pero confiaba en el regreso del mensaje. La prueba del extremo combinó entrega y pérdida para limitar esa dependencia.

El tamaño como decisión caducable

Recordar 1500 o 1280 es más fácil que recordar la estructura de control. El operador de un enlace fija el límite. El router lo aplica y puede anunciarlo. Un firewall puede borrar el anuncio. El host guarda una estimación. El transporte o la aplicación construye el siguiente paquete. Nadie posee toda la ruta.

La regla común debe ser pequeña: exponer la restricción cuando sea posible; permitir que el emisor confronte el mensaje con entrega y congestión; caducar y revisar la conclusión. El paquete no adquirió voluntad. La arquitectura colocó la decisión donde podían verse tanto la prueba como sus consecuencias.

Fuentes y límites

RFC 791 documenta fragmentación y DF; RFC 1063, las opciones actualizadas por gateways; RFC 1191, PMTUD clásico, MTU del siguiente salto, mesetas y envejecimiento. RFC 2923 describe el agujero negro TCP. RFC 4821 aporta la búsqueda de la capa de paquetización; RFC 8201, IPv6; RFC 8899, los datagramas.

Estos documentos prueban especificaciones y fallos reconocidos. No ofrecen una fecha universal de adopción, un censo de despliegues, una frecuencia global actual ni la configuración de cada red.