El ping funciona, el navegador carga una página pequeña y la transferencia de archivos se cuelga, todo por IPv6 a través del mismo túnel. Ese patrón suele significar que el emisor nunca aprendió el tamaño real de la ruta, no que el túnel sea lento. IPv6 espera que los enrutadores informen del problema con un mensaje Packet Too Big, y la encapsulación añade sobrecarga antes de que un paquete llegue siquiera a la red exterior. Si ese mensaje se filtra, el emisor sigue repitiendo un tamaño que no puede pasar.

Solicitudes pequeñas, bloqueos grandes

Un túnel envuelve cada paquete en otra cabecera, así que el tamaño utilizable dentro es menor que el tamaño fuera. Un paquete dimensionado para el enlace físico antes de la encapsulación se vuelve demasiado grande después. Los enrutadores IPv4 pueden fragmentar en la ruta, mientras que los enrutadores IPv6 no lo hacen en nombre del emisor, así que el emisor tiene que ajustarse él mismo. Y ese ajuste depende por completo de recibir la retroalimentación.

Un solo mensaje perdido basta para producir el síntoma clásico: los apretones de manos y las respuestas pequeñas funcionan, y un listado de directorio o una subida se atasca siempre en el mismo punto. Los usuarios lo describen como que la VPN va lenta, y los registros no muestran nada malo en la autenticación. Ambas observaciones son exactas y ninguna localiza la avería.

Packet Too Big es retroalimentación, no tráfico

Un mensaje ICMPv6 Packet Too Big lleva el tamaño que el siguiente salto puede aceptar, y el emisor lo usa para bajar su estimación. Filtrarlo equivale a quitar una señal de tráfico y luego culpar a los conductores. Una regla que descarta todo el ICMPv6 parece estricta mientras rompe el descubrimiento de ruta en cada enlace que lo necesita. El mensaje es información de control sobre la ruta, no carga útil de la aplicación.

El filtrado selectivo sigue siendo razonable. Las solicitudes de eco y el descubrimiento de vecinos desempeñan papeles distintos de los mensajes de error, y una política puede tratarlos de forma diferente. Siga las directrices de filtrado documentadas de la plataforma en lugar de aceptar o descartar todo el protocolo, porque RFC 8201 define cómo esa retroalimentación impulsa el descubrimiento.

Pruebe ambas familias de direcciones por separado

Pruebe IPv6 por separado, porque una transferencia IPv4 correcta no demuestra nada sobre la ruta IPv6. Luego capture mensajes de control mientras la transferencia grande se atasca. Los dos registros juntos o bien muestran que la retroalimentación sale, o bien prueban que nunca llegó.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

La sonda envía un paquete con el bit de no fragmentar activado e informa del tamaño en el que falla, que es el número que el túnel tiene que absorber. La consulta de ruta nombra la interfaz que llevaría el destino, así que sabe qué MTU de enlace se aplica. La captura filtra ICMPv6 tipo 2, el mensaje Packet Too Big, y muestra si llega a este host. Si el mensaje aparece en la captura y la transferencia sigue atascada, el emisor lo ignora, lo que traslada la investigación a la pila en lugar de a la red.

Ajuste el tamaño del túnel solo después de las pruebas

Bajar el MTU del túnel puede ocultar un mensaje filtrado y hacer desaparecer el síntoma, a costa de más sobrecarga en cada paquete. Es un rodeo y no un diagnóstico, y debería seguir a la captura en lugar de sustituirla. Un valor bajo arbitrario tampoco rompe nada visible, y por eso sobrevive años en las configuraciones. Cámbielo a propósito, anote el valor e indique qué medición lo justificó.

Cuando controle la puerta de enlace, revise la regla que descarta el mensaje en lugar de desactivar el cortafuegos. Una regla corregida es más estrecha que una excepción de política y mucho más fácil de defender después. El mismo razonamiento vale para los tiempos de espera: no todo bloqueo es un problema de tamaño, y la captura es lo que separa los dos casos.

Artículos relacionados