Resumen

  • Una confirmación positiva demuestra que la sonda identificada llegó al extremo remoto, con ese tamaño y por el camino observado.
  • RFC 8201 trata la MTU de ruta como un estado que cambia; RFC 8899 exige volver a confirmar y mantener estado por camino cuando hay multipath o multihoming.
  • Una constancia operativa debe unir extremos, flujo o camino, sobrecarga, sonda, respuesta, tiempo y entrega representativa de datos.

Un resultado correcto con un alcance equivocado

Supongamos que un servicio envía una sonda rellenada hasta 1450 bytes. El receptor confirma esa sonda y el emisor eleva su PLPMTU. Poco después, un datagrama de aplicación del mismo tamaño se asigna a otro miembro ECMP. Allí hay más sobrecarga de túnel o un enlace con menor MTU efectiva, y el paquete deja de llegar.

La primera medición sigue siendo cierta. Describe la entrega de un paquete concreto en el camino que tomó entonces. No describe automáticamente todos los miembros paralelos ni una ruta posterior. Guardarla como un simple estado «MTU OK» elimina el identificador de sonda, las claves del flujo, la generación de ruta, la sobrecarga y la edad de la confirmación.

La PMTUD de IPv6 mantiene una estimación

RFC 8201 define la PMTU como la menor MTU de enlace de un camino entre origen y destino. El origen puede comenzar con la MTU del primer salto y reducir su estimación cuando valida un ICMPv6 Packet Too Big. Pueden hacer falta varios ciclos porque otra restricción más pequeña puede encontrarse más adelante.

La topología cambia, y con ella puede cambiar la PMTU. Las reducciones se detectan mediante PTB; para descubrir aumentos el origen debe probar tamaños mayores de forma periódica. Tras una reducción, RFC 8201 recomienda no intentar un aumento con más frecuencia que una vez cada cinco minutos. Un valor almacenado tiene caducidad y política de renovación. No es un atributo eterno del destino.

Un PTB validado es evidencia de una restricción encontrada por el tráfico al que corresponde. No explica por sí solo qué ruta cambió, qué encapsulación añadió bytes o si todos los caminos paralelos comparten el mismo límite.

Qué confirma DPLPMTUD

RFC 8899 lleva el descubrimiento a la capa que forma los datagramas. La respuesta debe confirmar que la sonda específica llegó a la capa remota. Tras esa confirmación, el tamaño probado puede convertirse en la PLPMTU vigente.

La afirmación es precisa. Una sola pérdida no demuestra un problema de MTU, porque también existen congestión, corrupción y reordenamiento. Y una sola confirmación no convierte Search Complete en garantía permanente. Si la capa no dispone de otra prueba de entrega, el temporizador de confirmación sirve para volver a comprobar el tamaño actual.

El algoritmo debe resistir cambios de camino, información inconsistente, retrasos, duplicados y tráfico repartido por más de una ruta. Cuando existe multipath o multihoming, RFC 8899 pide una máquina de estados para cada camino. Esa obligación impide tratar la medición como un semáforo único por destino.

El presupuesto de cabeceras también cambia

La PLPMTU y la carga útil disponible no son lo mismo. Cabeceras IP y de transporte, cifrado, extensiones y túneles consumen espacio. Una nueva encapsulación puede reducir el tamaño máximo de mensaje aunque la MTU física no cambie.

Por eso el registro debe indicar la capa de medición y el presupuesto de cabeceras. Las pérdidas repetidas de un tamaño pueden justificar una reducción segura, pero no bastan para atribuir el incidente a la MTU: también deben considerarse filtros, congestión, estado del receptor y pérdida ordinaria.

Fuentes