IPv4 fragmentiert unterwegs; IPv6 sendet stattdessen die Meldung über ein zu großes Paket
Nur IPv4-Router dürfen ein übergroßes Paket fragmentieren. IPv6 erwartet, dass der Absender auf die Meldung über ein zu großes Paket reagiert, was ein Tunnel oder eine gefilterte ICMP-Regel zerstören kann.
IPv6-Fehler werden viel häufiger dem Protokoll angelastet als der Paketgröße, die sie verursacht hat. Die beiden Familien gehen mit einem übergroßen Paket tatsächlich unterschiedlich um, und ein Tunnel ist das, was den Unterschied wichtig macht. IPv4-Router dürfen ein Paket fragmentieren, wenn die Regeln es erlauben, während IPv6-Router unterwegs überhaupt nicht fragmentieren dürfen. IPv6 sagt es stattdessen dem Absender, und vom Absender wird erwartet, dass er reagiert. Alles, was danach schiefgeht, folgt daraus, ob diese Meldung ankommt.
Was die beiden Familien tun
Die Tabelle ist der Mechanismus in vier Zeilen, und eine Zeile erklärt den größten Teil der Verwirrung.
| 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 kennt keine Fragmentierung unterwegs und kein DF-Flag zum Löschen, es gibt also nichts, worauf man zurückfallen kann, wenn ein Paket zu groß ist. Der Absender muss informiert werden, und der Absender muss es glauben.
Der Tunnel verkleinert den Pfad still
Ein VPN fügt äußere Header hinzu, im verschlüsselten Fall auch Integritätsdaten, bevor das Paket den Host verlässt. Das innere Paket kann in die MTU der Schnittstelle passen, die es sieht, während das äußere Paket das Limit der nächsten Strecke überschreitet, und deshalb taucht das zuerst in einem Tunnel auf. Senken Sie die MTU der Tunnel-Schnittstelle bewusst ab oder klemmen Sie die TCP-MSS auf dem Pfad, und notieren Sie, welche Zahl Sie gewählt haben und warum.
Der ESP-Overhead hängt von Modus und Algorithmen ab, also ist die richtige Tunnel-MTU eine Rechnung und keine Konvention. Was Sie auch wählen, es muss Platz für ein volles inneres IPv6-Paket von 1280 Byte lassen, denn jede IPv6-Strecke muss so viel tragen. Ein Tunnel, der 1280 Byte IPv6 nicht tragen kann, ist kein Tuning-Problem; er ist ein kaputter Pfad für diese Familie. Genau diese Einschränkung verschwindet, wenn ein MTU-Wert aus einem reinen IPv4-Betrieb kopiert wird.
Warum sich das Symptom als Hänger zeigt
Der Fehler ist kein sauberer Fehler, und deshalb wird er falsch diagnostiziert. Ein TCP-Handshake läuft durch, kleine Antworten kommen an, und die Verbindung stockt, sobald eine große Antwort oder ein großer Upload beginnt, weil das die ersten Pakete sind, die groß genug sind, um verworfen zu werden. SSH verbindet sich und hängt dann bei der ersten großen Ausgabe, und der Kopf einer Seite lädt, während der Rumpf nie fertig wird.
Werden die ICMPv6-Meldungen Paket zu groß gefiltert, erfährt der Absender nie davon und wiederholt ständig dieselbe Größe. Das ist ein schwarzes Loch und kein langsamer Pfad, und seine Signatur ist eine wiederholbare Größengrenze und kein zufälliger Verlust. Den relevanten Steuerverkehr zuzulassen gehört zu einem funktionierenden IPv6-Betrieb und ist keine Höflichkeit.
Deaktivieren Sie nicht die Meldungen, von denen Ihr eigener Pfad abhängt, und beschreiben Sie das Ergebnis dann als IPv6-Fehler. Dasselbe Argument gilt für die Fragmentation-Needed-Meldungen von IPv4, die bei Firewall-Autoren ebenso unbeliebt und ebenso nötig sind.
Messen Sie die Grenze und reparieren Sie dann die Schicht
Prüfen statt raten: Nutzen Sie das Don't-Fragment-Flag bei IPv4 und feste Nutzlastgrößen bei IPv6 und halten Sie fest, wo Antworten aufhören. ping -M do -s 1472 und ping -6 -s 1400 reichen aus, um die Form des Problems zu bestimmen, und tracepath meldet unterwegs die ermittelte Pfad-MTU.
Reparieren Sie dann die Schicht, der die Zahl gehört: die MTU der Tunnel-Schnittstelle, das MSS-Clamping für TCP oder der Pfad selbst. RFC 8200 ist die Referenz für die IPv6-Regel, und sie ist kürzer zu lesen als der Vorfall, den sie verhindert.
Testen Sie die Familie, die die Anwendung tatsächlich nutzt, denn ein Dual-Stack-Name kann auf der einen Familie antworten und auf der anderen nicht, und eine Anwendung kann nach einer Netzwerkänderung wechseln. Notieren Sie die Adresse, die Sie getestet haben, denn ein Ergebnis gegen den A-Record sagt nichts über den AAAA-Record.
Behandeln Sie die Größengrenze als Beweis
Eine wiederholbare Größengrenze ist einer der wenigen Netzwerkfehler, die sich exakt reproduzieren, bei derselben Bytezahl, von derselben Quelle, jedes Mal. Das macht sie zu einem Geschenk statt zu einem Rätsel, und es bedeutet auch, dass sich eine Korrektur überprüfen statt erhoffen lässt.
Schreiben Sie die ermittelte MTU, die konfigurierte Tunnel-MTU und den Test, der den Unterschied bewiesen hat, ins Ticket. Die nächste Person trifft dieselbe Arithmetik auf einer anderen Strecke.