IPv4 fragmenta en tránsito; IPv6 envía no seu lugar unha mensaxe de paquete demasiado grande
Só os enrutadores IPv4 poden fragmentar un paquete demasiado grande. IPv6 espera que o emisor reaccione á mensaxe de paquete demasiado grande, que un túnel ou unha regra ICMP filtrada poden romper.
As fallas de IPv6 atribúense ao protocolo moito máis a miúdo que ao tamaño do paquete que as causou. As dúas familias tratan de xeito realmente distinto un paquete de tamaño excesivo, e un túnel é o que fai que esa diferenza importe. Os enrutadores IPv4 poden fragmentar un paquete cando as regras o permiten, mentres que os enrutadores IPv6 non deben fragmentar en tránsito en absoluto. IPv6 dío no seu lugar ao emisor, e espérase que o emisor reaccione. Todo o que sae mal despois depende de se esa mensaxe chega.
Que fai cada familia
A táboa é o mecanismo en catro liñas, e unha fila explica a maior parte da confusión.
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6 non ten fragmentación en tránsito nin un indicador DF que limpar, así que non hai nada ao que recorrer cando un paquete é demasiado grande. Cómpre decirlle ao emisor, e o emisor ten que crelo.
O túnel estreita a ruta en silencio
Unha VPN engade cabeceiras externas, e no caso cifrado tamén datos de integridade, antes de que o paquete saia do host. O paquete interno pode caber na MTU da interface que ve, mentres que o paquete externo supera o límite da seguinte ligazón, e por iso isto aparece primeiro nun túnel. Baixe deliberadamente a MTU da interface do túnel, ou fixe o MSS de TCP na ruta, e anote que número escolleu e por que.
A sobrecarga de ESP depende do modo e dos algoritmos, así que a MTU correcta do túnel é un cálculo e non unha convención. Escolla o que escolla, debe deixar sitio para un paquete IPv6 interno completo de 1280 bytes, porque cada ligazón IPv6 está obrigada a transportar iso. Un túnel que non pode transportar 1280 bytes de IPv6 non é un problema de axuste; é unha ruta rota para esa familia. Esa restrición é a que desaparece cando se copia un valor de MTU dun despregamento só IPv4.
Por que o síntoma é un colgado
O fallo non é un erro limpo, e por iso se diagnostica mal. Un handshake TCP complétase, chegan respostas pequenas e a conexión atáscase en canto comeza unha resposta grande ou unha subida masiva, porque eses son os primeiros paquetes o bastante grandes para ser descartados. SSH conéctase e despois colga na primeira saída grande, e a cabeceira dunha páxina carga mentres o corpo nunca remata.
Se se filtran as mensaxes de ICMPv6 de paquete demasiado grande, o emisor nunca se entera e segue intentando o mesmo tamaño. Iso é un burato negro e non unha ruta lenta, e a súa sinatura é un límite de tamaño repetible e non unha perda aleatoria. Permitir o tráfico de control pertinente forma parte dun despregamento IPv6 que funciona, non é unha cortesía.
Non desactive as mensaxes das que depende a súa propia ruta e despois describa o resultado como unha falla de IPv6. O mesmo argumento vale para as mensaxes Fragmentation Needed de IPv4, que son igual de impopulares entre os autores de devasas e igual de necesarias.
Mida o límite e despois arranxe a capa
Comprobe en lugar de adiviñar: use o indicador don't-fragment en IPv4 e tamaños de carga fixos en IPv6, e anote onde se deteñen as respostas. ping -M do -s 1472 e ping -6 -s 1400 abondan para establecer a forma do problema, e tracepath informa da MTU de ruta descuberta polo camiño.
Despois arranxe a capa que posúe o número: a MTU da interface do túnel, o clamp de MSS para TCP, ou a propia ruta. RFC 8200 é a referencia para a regra de IPv6, e lese máis rápido que o incidente que evita.
Probe a familia que a aplicación usa de verdade, porque un nome de dobre pila pode responder nunha familia e non na outra, e unha aplicación pode cambiar tras un cambio de rede. Anote o enderezo que probou, porque un resultado contra o rexistro A non di nada sobre o rexistro AAAA.
Trate o límite de tamaño como unha proba
Un límite de tamaño repetible é un dos poucos fallos de rede que se reproducen exactamente, co mesmo número de bytes, desde a mesma fonte, cada vez. Iso convérteo nun regalo e non nun misterio, e tamén significa que un arranxo se pode verificar en lugar de esperar.
Escriba no tícket a MTU descuberta, a MTU do túnel que configurou e a proba que demostrou a diferenza. A seguinte persoa atopará a mesma aritmética noutra ligazón.