Tu IPv6 "funciona" pero tu app sigue fallando: el culpable de siempre
Haces ping6 al servidor y responde perfecto. Confirmas que tienes dirección IPv6, que el firewall deja pasar el tráfico, que el DNS resuelve el registro AAAA. Todo funciona. Y sin embargo, la aplicación se cuelga, el archivo grande nunca termina de subir, la videollamada se congela a los pocos segundos. El culpable en estos casos casi nunca es IPv6 en sí: es el paquete que nunca llegó a avisarte que había un problema.
El sospechoso: Path MTU Discovery bloqueado
A diferencia de IPv4, en IPv6 los routers intermedios no fragmentan paquetes en tránsito. Esa responsabilidad es del emisor, que descubre el tamaño correcto de paquete mediante Path MTU Discovery (PMTUD), un mecanismo que depende de que los mensajes ICMPv6 "Packet Too Big" (tipo 2) le lleguen de vuelta cuando un paquete es más grande de lo que un enlace puede transportar.
Si un firewall en el camino —muchas veces uno que se configuró hace años para IPv4 y simplemente se extendió a IPv6 sin revisar sus reglas de ICMPv6— descarta esos mensajes, el emisor nunca se entera de que sus paquetes son demasiado grandes. Los paquetes pequeños, como un ping, pasan sin problema. Los grandes (una imagen, una respuesta de base de datos, un stream de video) simplemente desaparecen, sin error, sin ningún mensaje que apunte a la causa real.
Por qué el diagnóstico básico no lo detecta
ping6 funciona porque el paquete de ping es pequeño. Un handshake TCP básico también suele completarse, porque SYN y SYN-ACK también son paquetes pequeños. La conexión se ve completamente sana hasta el momento exacto en que empiezan a fluir datos reales.
Qué revisar
- Confirma que ICMPv6 tipo 2 (Packet Too Big) está explícitamente permitido en sentido entrante en cada firewall o ACL del camino. No asumas que quedó cubierto por una regla genérica de "permitir ICMPv6".
- Revisa que las reglas de firewall para IPv6 no sean una copia de las de IPv4 que nunca se actualizó con la nueva familia de direcciones: es un origen común de bloqueos silenciosos.
- Verifica que existan registros AAAA en todos los servicios relevantes, no solo en el dominio principal.
- Ten en cuenta el comportamiento de Happy Eyeballs en clientes dual-stack: si la ruta IPv6 falla, muchos clientes caen a IPv4 sin mostrar error, lo que hace que el problema real quede oculto en vez de manifestarse.
"Cada :: que te ahorras escribiendo es una neurona que no recuperas."
¿Ya sabes en qué plazo va tu entidad frente al MinTIC? Léelo acá →. Y si el problema ya te tiene bloqueado en producción, escríbenos.