IPv6 MTU y Path MTU Discovery: Evitar Problemas de Fragmentación

La fragmentación de paquetes es uno de esos problemas que no notas hasta que rompe todo.

TL;DR - Resumen rápido

Puntos clave:

Los routers IPv6 no pueden fragmentar: Los hosts fuente deben manejar toda fragmentación vía Path MTU Discovery
Nunca bloquees ICMPv6 Tipo 2: Los mensajes Packet Too Big son esenciales para que PMTUD funcione
MTU mínimo es 1280 bytes: Todos los enlaces IPv6 deben soportar esto, úsalo como fallback
Los túneles reducen MTU: Cuenta la sobrecarga de encapsulación (6in4: 20 bytes, VPN: 40-80 bytes)
Usa MSS clamping: Fuerza TCP a usar segmentos más pequeños cuando PMTUD falla

Ir a: Agujeros Negros PMTUD | Diagnosticar Problemas MTU | Configuración Firewall

Por Qué el MTU Importa Más en IPv6 #

IPv6 eliminó completamente la fragmentación basada en enrutador. En IPv4, si un enrutador recibe un paquete demasiado grande para el siguiente salto, puede fragmentarlo. Los enrutadores IPv6 no pueden hacer eso: descartan el paquete y envían un mensaje ICMPv6 «Packet Too Big» de vuelta al origen.

El host de origen es responsable de toda fragmentación. Esta decisión de diseño mejora el rendimiento del enrutador y simplifica el protocolo, pero traslada la carga a los extremos y hace que Path MTU Discovery (PMTUD) sea crítico.

Si PMTUD falla, tus conexiones se cuelgan misteriosamente. Los handshakes TCP se completan, pero la transferencia de datos se detiene. Las solicitudes HTTP expiran. Las sesiones SSH se congelan después de la autenticación. Estos son síntomas clásicos de agujero negro de MTU.

MTU Mínimo de IPv6 #

Todos los enlaces IPv6 deben soportar al menos 1280 bytes. Este es el MTU mínimo y no es negociable. Si tu enlace no puede manejar paquetes de 1280 bytes, no es compatible con IPv6.

La mayoría de las redes usan 1500 bytes (MTU estándar de Ethernet), lo que proporciona espacio para la cabecera IPv6 de 40 bytes más 1460 bytes de carga útil. Eso es equivalente al MSS TCP típico de 1460 de IPv4.

Los túneles y protocolos de encapsulación reducen el MTU disponible. Si estás ejecutando IPv6-en-IPv4 (6in4), 6to4 o ISATAP, pierdes bytes por la cabecera externa. VPNs, IPsec, GRE y VXLAN consumen espacio de MTU.

Valores MTU comunes que encontrarás:

1500: Ethernet estándar
1480: PPPoE (pierde 8 bytes por sobrecarga PPP)
1460: Túnel 6in4 (pierde 20 bytes por cabecera IPv4)
1420: 6in4 sobre PPPoE
1280: MTU mínimo IPv6, valor de respaldo
9000: Tramas jumbo (redes de centro de datos)

Cómo Funciona Path MTU Discovery #

PMTUD determina el tamaño de paquete más grande que puede atravesar la ruta entre origen y destino sin fragmentación.

El proceso es directo:

El host envía paquetes con el MTU actual
Si un enrutador a lo largo de la ruta tiene un MTU más pequeño, descarta el paquete
El enrutador envía un mensaje ICMPv6 Tipo 2 «Packet Too Big» de vuelta al origen
El mensaje incluye el MTU del siguiente salto
El host reduce su MTU de ruta y reenvía
El proceso se repite hasta que los paquetes atraviesan toda la ruta

El mensaje «Packet Too Big» (ICMPv6 Tipo 2, Código 0) contiene el valor MTU en la carga útil del mensaje. Esto le dice al origen exactamente qué tan grandes pueden ser los paquetes, no solo que son demasiado grandes.

El host mantiene una caché de MTU de ruta con entradas que típicamente expiran después de 10 minutos (recomendación RFC 8201). Si las rutas de red cambian, las entradas de caché obsoletas podrían causar problemas hasta que expiren.

Agujeros Negros de PMTUD #

El sistema se rompe cuando los mensajes ICMPv6 Tipo 2 son bloqueados. Esto crea «agujeros negros de PMTUD» donde los paquetes desaparecen silenciosamente.

Causas comunes:

Firewalls excesivamente celosos: Los administradores a veces bloquean todo el tráfico ICMP, tratándolo como un riesgo de seguridad. Esto está mal. ICMPv6 es integral a la operación de IPv6, no un protocolo de diagnóstico opcional como ping.

Problemas de inspección con estado: Algunos firewalls no asocian correctamente los mensajes de error ICMPv6 con conexiones existentes, descartándolos como tráfico no solicitado.

Limitación de velocidad: Los dispositivos de seguridad pueden limitar ICMPv6, descartando mensajes PMTUD legítimos durante períodos ocupados.

Gateways NAT64: La traducción entre IPv6 e IPv4 puede perder información de PMTUD si el gateway no traduce correctamente los mensajes ICMP.

Síntomas de agujeros negros de PMTUD:

La conexión TCP se establece (SYN, SYN-ACK, ACK completo)
Los paquetes pequeños funcionan (consultas DNS, banner de inicio de SSH)
Los paquetes grandes fallan (transferencias de archivos, HTTP POST con cuerpo, sesión SSH interactiva después de autenticación)
Sin mensajes de error, solo tiempos de espera agotados
El problema parece intermitente (depende del tamaño del paquete)

Diagnosticar Problemas de MTU #

Comienza con ping. Envía paquetes de tamaños específicos para probar el MTU de ruta:

# Probar con 1280 bytes (MTU mínimo)
ping6 -M do -s 1232 2001:db8::1
 
# Probar con 1500 bytes (Ethernet estándar)
ping6 -M do -s 1452 2001:db8::1
 
# Probar con carga útil de 1280 bytes
ping6 -c 5 -s 1280 2001:db8::1

La bandera -M do prohíbe la fragmentación (no fragmentar). El argumento -s especifica el tamaño de carga útil: añade 8 bytes para la cabecera ICMPv6 y 40 para la cabecera IPv6 para obtener el tamaño total del paquete.

Si 1452 bytes falla pero 1232 tiene éxito, tu MTU de ruta está entre 1280 y 1500. Búsqueda binaria para encontrar el valor exacto:

# Probar 1400
ping6 -M do -s 1352 2001:db8::1
 
# Probar 1450
ping6 -M do -s 1402 2001:db8::1

Usa traceroute para identificar dónde cambia el MTU:

traceroute6 -n 2001:db8::1

Luego prueba el MTU a cada salto individualmente. El salto donde comienzan a fallar los paquetes grandes es tu punto de problema.

TCP MSS Clamping #

MSS (Maximum Segment Size) es la opción TCP que le dice al otro extremo cuántos datos puede enviar en cada segmento. MSS = MTU - cabecera IP - cabecera TCP.

Para IPv6: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

Con MTU estándar de 1500 bytes: MSS = 1440

El clamping de MSS fuerza a las conexiones TCP a usar un valor MSS más bajo, trabajando alrededor de problemas de MTU sin depender de PMTUD. Esto es común en enrutadores que terminan túneles o conexiones PPPoE.

Configurar clamping de MSS en Linux:

# Clamp MSS a 1280 para IPv6
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

El valor 1220 contabiliza 1280 MTU menos 60 bytes para cabeceras.

Para PPPoE con MTU 1492:

ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1432

El clamping de MSS solo afecta a TCP. UDP, SCTP y otros protocolos todavía dependen de PMTUD o fragmentación a nivel de aplicación.

Configuración de Firewall #

Tu firewall debe permitir mensajes ICMPv6 Tipo 2 para que PMTUD funcione. Esto no es negociable para redes IPv6 de producción.

Tipos ICMPv6 mínimos requeridos para operación IPv6:

Tipo 1: Destination Unreachable
Tipo 2: Packet Too Big (PMTUD)
Tipo 3: Time Exceeded
Tipo 4: Parameter Problem
Tipo 133-137: Neighbor Discovery Protocol

Regla iptables para PMTUD:

# Permitir ICMPv6 Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

Mejor enfoque: permitir todo ICMPv6 necesario:

# Permitir ICMPv6 establecido
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Permitir tipos ICMPv6 necesarios
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT    # Destination Unreachable
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT    # Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT    # Time Exceeded
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT    # Parameter Problem
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT  # Echo Request
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT  # Echo Reply
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT  # Router Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT  # Router Advertisement
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT  # Neighbor Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT  # Neighbor Advertisement

La limitación de velocidad es aceptable pero establece límites generosos:

# Permitir ICMPv6 con límite de velocidad
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

Nunca bloquees completamente ICMPv6. No es un riesgo de seguridad: es un requisito de protocolo.

Consideraciones de MTU de Túnel #

Los túneles reducen el MTU efectivo por la sobrecarga de las cabeceras de encapsulación.

Tipos de túnel comunes y sobrecarga:

Tipo de Túnel	Sobrecarga	MTU Efectivo (desde 1500)
6in4	20 bytes	1480
6to4	20 bytes	1480
6rd	20 bytes	1480
ISATAP	20 bytes	1480
GRE	24 bytes	1476
IPsec	50-70 bytes	1430-1450
WireGuard	60 bytes	1420
OpenVPN	40-80 bytes	1420-1460

Configurar MTU de túnel explícitamente para evitar problemas:

# Túnel 6in4
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 up

Para WireGuard:

[Interface]
MTU = 1420

Algunos protocolos de túnel soportan descubrimiento de MTU, pero la configuración explícita es más confiable.

Tramas Jumbo y Centros de Datos #

Las redes de centros de datos a menudo usan MTU de 9000 bytes (tramas jumbo) para mejorar el rendimiento de transferencias masivas.

Habilitar tramas jumbo en interfaces:

ip link set eth0 mtu 9000

Asegúrate de que todos los switches y enrutadores en la ruta soporten tramas jumbo. Un dispositivo con MTU de 1500 bytes se convertirá en cuello de botella.

PMTUD todavía aplica. Si un paquete sale de tu red de tramas jumbo hacia Internet, debe reducirse a 1500 o menos.

Pruebas y Verificación #

Verificar la configuración de MTU de tu host:

ip -6 link show

Busca el valor MTU en cada interfaz.

Verificar la caché actual de MTU de ruta:

ip -6 route get 2001:db8::1

La salida muestra el MTU en caché para ese destino.

Probar conectividad extremo a extremo con tamaños de paquete variados:

for size in 1232 1352 1402 1452; do
  echo "Testing $size bytes:"
  ping6 -M do -s $size -c 3 2001:db8::1
done

Escenarios Comunes y Soluciones #

Problema: Las páginas web cargan lentamente, las imágenes fallan Causa: Agujero negro de PMTUD debido a firewall bloqueando ICMPv6 Tipo 2 Solución: Configurar firewall para permitir ICMPv6 Tipo 2

Problema: SSH se conecta pero se congela después del inicio de sesión Causa: MTU demasiado grande, PMTUD no funcionando Solución: Reducir MTU en interfaz del cliente o habilitar clamping de MSS en enrutador

Problema: VPN funciona para transferencias pequeñas, falla para archivos grandes Causa: MTU de túnel no configurado correctamente Solución: Reducir MTU de túnel para contabilizar sobrecarga de encapsulación

Problema: IPv6 funciona en red local, falla a través de Internet Causa: Enrutador upstream tiene MTU más pequeño, no lo anuncia correctamente Solución: Contactar ISP o reducir MTU local a 1280 (mínimo)

Problema: Algunos destinos funcionan, otros fallan Causa: Problemas de MTU específicos de ruta Solución: Probar con ping para identificar MTU funcional, configurar interfaz en consecuencia

Mejores Prácticas #

Siempre permitir ICMPv6 Tipo 2 en firewalls
Configurar MTU de túnel explícitamente en lugar de depender de autodetección
Probar con MTU mínimo (1280) para asegurar conectividad básica
Usar clamping de MSS en puntos finales de túnel y conexiones PPPoE
Monitorear fallos de PMTUD con capturas de paquetes durante resolución de problemas
Documentar el MTU de tu red en cada capa (físico, túnel, aplicación)
Establecer valores MTU conservadores cuando haya dudas (1280 siempre funciona)