IPv4 frammenta in transito; IPv6 invia invece un messaggio di pacchetto troppo grande

I guasti di IPv6 vengono attribuiti al protocollo molto più spesso che alla dimensione del pacchetto che li ha causati. Le due famiglie trattano davvero in modo diverso un pacchetto troppo grande, ed è il tunnel che rende questa differenza importante. I router IPv4 possono frammentare un pacchetto quando le regole lo consentono, mentre i router IPv6 non devono frammentare in transito affatto. IPv6 lo dice invece al mittente, e ci si aspetta che il mittente reagisca. Tutto ciò che va storto dopo dipende dall'arrivo di quel messaggio.

Cosa fa ciascuna famiglia

La tabella è il meccanismo in quattro righe, e una riga spiega la maggior parte della confusione.

IPv6 non ha frammentazione in transito né un flag DF da azzerare, quindi non c'è nulla su cui ripiegare quando un pacchetto è troppo grande. Bisogna dirlo al mittente, e il mittente deve crederci.

Il tunnel restringe il percorso in silenzio

Una VPN aggiunge intestazioni esterne, e nel caso cifrato anche dati di integrità, prima che il pacchetto lasci l'host. Il pacchetto interno può stare nell'MTU dell'interfaccia che vede, mentre il pacchetto esterno supera il limite del collegamento successivo, ed è per questo che il problema emerge prima in un tunnel. Abbassate deliberatamente l'MTU dell'interfaccia del tunnel, o fissate l'MSS TCP sul percorso, e annotate quale numero avete scelto e perché.

L'overhead ESP dipende dalla modalità e dagli algoritmi, quindi l'MTU corretto del tunnel è un calcolo e non una convenzione. Qualunque cosa scegliate, deve lasciare spazio a un pacchetto IPv6 interno completo di 1280 byte, perché ogni collegamento IPv6 deve trasportarne altrettanto. Un tunnel che non riesce a trasportare 1280 byte di IPv6 non è un problema di regolazione; è un percorso rotto per quella famiglia. È proprio questo vincolo a sparire quando un valore di MTU viene copiato da una distribuzione solo IPv4.

Perché il sintomo è un blocco

Il guasto non è un errore pulito, ed è per questo che viene diagnosticato male. Un handshake TCP si completa, arrivano risposte piccole, e la connessione si blocca appena inizia una risposta grande o un caricamento massiccio, perché quelli sono i primi pacchetti abbastanza grandi da essere scartati. SSH si connette e poi si blocca sul primo output grande, e l'intestazione di una pagina si carica mentre il corpo non finisce mai.

Se i messaggi ICMPv6 di pacchetto troppo grande vengono filtrati, il mittente non lo scopre mai e continua a riprovare la stessa dimensione. È un buco nero e non un percorso lento, e la sua firma è un confine di dimensione ripetibile e non una perdita casuale. Consentire il traffico di controllo pertinente fa parte di una distribuzione IPv6 funzionante, non è una cortesia.

Non disattivate i messaggi da cui dipende il vostro stesso percorso e poi descrivete il risultato come un guasto di IPv6. Lo stesso argomento vale per i messaggi Fragmentation Needed di IPv4, ugualmente impopolari presso gli autori di firewall e ugualmente necessari.

Misurate il confine, poi correggete il livello

Verificate invece di indovinare: usate il flag don't-fragment su IPv4 e dimensioni fisse del carico su IPv6, e registrate dove si fermano le risposte. ping -M do -s 1472 e ping -6 -s 1400 bastano a stabilire la forma del problema, e tracepath riporta l'MTU del percorso scoperta lungo la strada.

Poi correggete il livello che possiede il numero: l'MTU dell'interfaccia del tunnel, il clamp dell'MSS per TCP, o il percorso stesso. RFC 8200 è il riferimento per la regola IPv6, e si legge più in fretta dell'incidente che evita.

Provate la famiglia che l'applicazione usa davvero, perché un nome dual-stack può rispondere su una famiglia e non sull'altra, e un'applicazione può cambiare dopo un cambio di rete. Annotate l'indirizzo che avete provato, perché un risultato contro il record A non dice nulla sul record AAAA.

Trattate il confine di dimensione come una prova

Un confine di dimensione ripetibile è uno dei pochi guasti di rete che si riproducono esattamente, allo stesso numero di byte, dalla stessa fonte, ogni volta. Questo lo rende un regalo e non un mistero, e significa anche che una correzione si può verificare invece di sperarla.

Scrivete nel ticket l'MTU scoperta, l'MTU del tunnel configurata e il test che ha dimostrato la differenza. La persona successiva incontrerà la stessa aritmetica su un altro collegamento.