IPv4 fragmenta en tránsito; IPv6 envía en su lugar un mensaje de paquete demasiado grande

Los fallos de IPv6 se achacan al protocolo mucho más a menudo que al tamaño del paquete que los causó. Las dos familias tratan de forma realmente distinta un paquete de tamaño excesivo, y un túnel es lo que hace que esa diferencia importe. Los enrutadores IPv4 pueden fragmentar un paquete cuando las reglas lo permiten, mientras que los enrutadores IPv6 no deben fragmentar en tránsito en absoluto. IPv6 se lo dice en su lugar al emisor, y se espera que el emisor reaccione. Todo lo que sale mal después depende de si ese mensaje llega.

Qué hace cada familia

La tabla es el mecanismo en cuatro líneas, y una fila explica la mayor parte de la confusión.

IPv6 no tiene fragmentación en tránsito ni un indicador DF que limpiar, así que no hay nada a lo que recurrir cuando un paquete es demasiado grande. Hay que decírselo al emisor, y el emisor tiene que creérselo.

El túnel estrecha la ruta en silencio

Una VPN añade cabeceras externas, y en el caso cifrado también datos de integridad, antes de que el paquete salga del host. El paquete interno puede caber en la MTU de la interfaz que ve, mientras que el paquete externo supera el límite del siguiente enlace, y por eso esto aparece primero en un túnel. Baje deliberadamente la MTU de la interfaz del túnel, o fije el MSS de TCP en la ruta, y anote qué número eligió y por qué.

La sobrecarga de ESP depende del modo y de los algoritmos, así que la MTU correcta del túnel es un cálculo y no una convención. Elija lo que elija, debe dejar sitio para un paquete IPv6 interno completo de 1280 bytes, porque cada enlace IPv6 está obligado a transportar eso. Un túnel que no puede transportar 1280 bytes de IPv6 no es un problema de ajuste; es una ruta rota para esa familia. Esa restricción es la que desaparece cuando se copia un valor de MTU de un despliegue solo IPv4.

Por qué el síntoma es un cuelgue

El fallo no es un error limpio, y por eso se diagnostica mal. Un handshake TCP se completa, llegan respuestas pequeñas y la conexión se atasca en cuanto empieza una respuesta grande o una subida masiva, porque esos son los primeros paquetes lo bastante grandes para ser descartados. SSH se conecta y luego se cuelga en la primera salida grande, y la cabecera de una página carga mientras el cuerpo nunca termina.

Si se filtran los mensajes de ICMPv6 de paquete demasiado grande, el emisor nunca se entera y sigue reintentando el mismo tamaño. Eso es un agujero negro y no una ruta lenta, y su firma es un límite de tamaño repetible y no una pérdida aleatoria. Permitir el tráfico de control pertinente forma parte de un despliegue IPv6 que funciona, no es una cortesía.

No desactive los mensajes de los que depende su propia ruta y luego describa el resultado como un fallo de IPv6. El mismo argumento vale para los mensajes Fragmentation Needed de IPv4, que son igual de impopulares entre los autores de cortafuegos e igual de necesarios.

Mida el límite y luego arregle la capa

Compruebe en lugar de adivinar: use el indicador don't-fragment en IPv4 y tamaños de carga fijos en IPv6, y anote dónde se detienen las respuestas. ping -M do -s 1472 y ping -6 -s 1400 bastan para establecer la forma del problema, y tracepath informa de la MTU de ruta descubierta por el camino.

Luego arregle la capa que posee el número: la MTU de la interfaz del túnel, el clamp de MSS para TCP, o la ruta misma. RFC 8200 es la referencia para la regla de IPv6, y se lee más rápido que el incidente que evita.

Pruebe la familia que la aplicación usa de verdad, porque un nombre de doble pila puede responder en una familia y no en la otra, y una aplicación puede cambiar tras un cambio de red. Anote la dirección que probó, porque un resultado contra el registro A no dice nada sobre el registro AAAA.

Trate el límite de tamaño como una prueba

Un límite de tamaño repetible es uno de los pocos fallos de red que se reproducen exactamente, con el mismo número de bytes, desde la misma fuente, cada vez. Eso lo convierte en un regalo y no en un misterio, y también significa que un arreglo se puede verificar en lugar de esperar.

Escriba en el ticket la MTU descubierta, la MTU del túnel que configuró y la prueba que demostró la diferencia. La siguiente persona se encontrará la misma aritmética en otro enlace.