Con IPv4, la "sujeción" TCP MSS (un dispositivo de red que edita el valor MSS en un encabezado TCP) puede ayudar cuando el descubrimiento de la unidad de transmisión máxima de ruta no funciona. (por ejemplo, cuando ICMP se está bloqueando en algún lugar de la ruta). Dado que no hay fragmentación en IPv6, todavía tenemos el 'paquete demasiado grande' de ICMPv6 para señalar el punto final de origen.
¿Hay alguna guía sobre cómo sujetar TCP MSS sobre IPv6 específicamente?
Bueno, técnicamente puede ocurrir fragmentación en IPv6; Este es el artículo de Wikipedia en él.
Esta página de Juniper es un poco antigua, pero muestra que puede sujetar un MSS para TCP sobre IPv6 en Junos de la misma forma que lo haría en IPv4 con el mismo comando tcp mss. Lo mismo se muestra en este artículo para Cisco IOS 15, utilizando el adjust-msscomando tradicional ip tcp .
Por lo tanto, puede configurar el bloqueo de MSS si PMTUD no funciona, ya que debería estar en una parte de su red; de lo contrario, debe asegurarse de que está ayudando a ejecutar PTMUD en su red para que el bloqueo de MSS no sea necesario ( Entiendo que esto no siempre está bajo tu control).
Actualizar
Aquí hay un enlace a un artículo más reciente de Junos para Junos 10x en lugar de 9, no puedo encontrar uno para 11 y no estoy frente a 11 en este momento, pero espero que sea lo mismo.
Definitivamente, hay casos, que generalmente involucran túneles IPv6-in-IPv4 en algún punto a lo largo del camino, donde incluso si PMTUD funciona correctamente, la negociación de MSS falla. En este caso, una sesión TCP puede comenzar correctamente (ya que los paquetes SYN / ACK son pequeños) pero no llegan paquetes de datos (ya que esos paquetes son demasiado grandes para el túnel). En este caso, la sujeción de MSS en el otro extremo ayudaría, pero no está bajo el control de la "víctima" que espera los paquetes. La solución a prueba de fallas es que ambos extremos establezcan la MTU IPv6 en 1280, que debe pasar por cualquier túnel.
fuente