IPv4/IPv6 fragmented packet delivery

Hallo @almightyloaf,

vielen Dank für deine Anfrage.

Bemerkst du denn Einschränkungen bei der Nutzung oder geht es jetzt nur um eine allgemeine Erklärung? Treten z.B. Paketverluste auf?

Gut, dass du schon etwas getestet hast, dass die Firewall nicht schuld ist, hilft ja schon einmal weiter.

Die Ursachen können hier wie immer vielfältig sein. Vielleicht findet sich hier ja noch jemand, der sich damit auskennt, @pufferueberlauf0 z.B.?

Viele Grüße

Giulia

Normalerweise sollte es eben nicht dazu kommen (*1), da viele Dienste sich bewusst für kleinere MTUs entscheiden (*2), unter anderem um eben solche Fragmentierungsprobleme zu vermeiden. Dazu ist dieses nur bei UDP stark problematisch, TCP kann fehlende Pakete ja wieder anfragen.

Allerdings wäre es trotzdem anstrebenswert dass Path MTU Discovery und die erfolgreiche “Zustellung” fragmentierter Pakete, korrekt funktioniert (*3).

Was ich bisher prüfen konnte, ist dass ICMPv6 Type 2 Code 0 (also Packet Too Big) nicht blockiert werden, so dass das Interface eben “bescheid weisst” dass es an der MTU ran muss damit das Paket durchgeht und nicht verworfen wird. Das gilt bei IPv6 besonders, da IPv6 Pakete nur vom senden Interface fragmentiert werden darf, nicht von zwischenliegenden Netzelementen.

Bei IPv4 wäre das pendant ICMPv4 Type 3 Code 4, da erhält das sendende Interface ebenfalls die zu verwendende MTU. Hierfür ist es natürlich nötig, dass diese ICMP Pakete durchgehen.

Deshalb habe ich auch testweise in meine Firewall ICMPv4 und ICMPv6 komplett auf gemacht sowie auf meine Testgeräte die Firewall deaktiviert, um das als Faktor auszuschliessen.

Das “Problem” dabei ist, dass auch mit dem üblichen Regelset den ich anwende, die Testergebnisse exakt gleich sind wie mit “Tore weit auf für ICMP” Regeln.

Absolut. Ich möchte nicht direkt den Finger “auf Euch” zeigen, sondern erstmal ausschliessen, dass ich irgendwo etwas in der Kette übersehen habe oder nicht wusste.

Theoretisch sollten aber fragmentierten Pakete durchgeleitet werden, insbesondere wenn ICMP korrekt durchgeht, was aber bei meinem Anschluss laut den Tests nicht der Fall ist.

Daher wäre es spannend zu wissen, sieht es z.B. bei pufferueberlauf0 auch so aus, oder ist es regional, oder sind nur FTTH Kunden über Telekom Netz betroffen, …

Im Mobilfunknetz geht es bei mir meistens (IPv4 scheint unauffällig, IPv6 funktioniert sagen wir mal fast immer), bei einem bekannten von mir meinte er beide Tests scheitern sowohl an “ICMP path MTU packet delivery” als auch an “IP fragmented packet delivery” und zwar bei IPv4 und IPv6.

Ähnliches gab es letztes Jahr bei Vodafone (*4), die haben es laut deren Community Beitrag wohl irgendwann auch zu eine Lösung gebracht.

*1) Paketverlust habe ich durchaus, aber liegt höchstwahrscheinlich an etwas anderes, habe auch einen separaten Thema dafür aufgemacht

*2) Siehe https://blog.cloudflare.com/increasing-ipv6-mtu/

*3) Naja, ich möchte nicht gleich unterstellen dass grundsätzliche Pakete nicht zugestellt werden, aber dass fragmentierten Pakete nicht durchgehen (also vor allem welche die vom sendenden Interface fragmentierten werden aufgrund PMTUD, die nicht irgendwie zwischendrin durch ein Netzelement fragmentiert und wieder von einem anderen Netzelement zusammengeführt werden (gilt nur bei IPv4)) könnte eventuell sein

*4) Siehe https://forum.vodafone.de/t5/St%C3%B6rungen-im-Mobilfunk-Netz/Probleme-mit-mobilfunk-datennetz-IPv6-und-IPv4-fragments-MTU/td-p/3100381

Ich habe mit http://icmpcheckv6.popcount.org generelle Erreichbarkeitsprobleme (oft laedt die Seite gar nicht), ich bin nicht 100% sicher was da los, aber habe vor den dort vorgeschlagenen manuellen Test mit curl und tcpdump fuer IPv6 auszuprobieren...

Ja, wobei es eher so aussieht als würde der Browser sich “zwingen” HTTPS zu verwenden, obwohl die Seite über HTTPS gar nicht erreichbar ist… vielleicht ist HSTS fälschlicherweise konfiguriert, keine Ahnung. Lasse ich den “S” weg, lädt die Seite, meistens :D

Sieht aber auch aus, als würde inzwischen der IPv6 Test erfolgreich sein, der IPv4 Test scheitert weiterhin, zumindest bei mir.

ich habe es mal gemacht, allerdings kann ich den Ergebnis aus tcpdump nicht wirklich bewerten, da mir hierfür die Kenntnistiefe in das Internet Protocol fehlt (Sollte man aber zu meiner Verteidigung von einem Kunde auch nicht erwarten, wiederum darf man es aber erwarten, wenn man den ISP beweisen möchte dass etwas in seine Infrastruktur eventuell nicht stimmt).

Zu folgendem Ergebnis komme ich (ich habe vor ein paar Minuten getestet):

Führe ich folgenden Befehl aus:

curl -v -s http://icmpcheck.popcount.org/frag -o /dev/null

kommt in tcpdump exakt nichts.

sudo tcpdump -ni any '(ip[6] & (1<<5)) != 0 or (ip[7] != 0) or (ip[6] & ((1<<5)-1) != 0) or ip6[6] == 44'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Führe ich hingegen folgenden Befehl aus:

curl -v -s http://icmpcheckv6.popcount.org/frag -o /dev/null

kommt auch etwas an:

sudo tcpdump -ni any '(ip[6] & (1<<5)) != 0 or (ip[7] != 0) or (ip[6] & ((1<<5)-1) != 0) or ip6[6] == 44'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:58:12.762672 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (0|1232) 80 > 34780: Flags [.], seq 2451380875:2451382075, ack 68953096, win 502, options [nop,nop,TS val 1847455487 ecr 1248995470], length 1200: HTTP
18:58:12.762682 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (1232|228)
18:58:12.782845 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (0|1232) 80 > 34780: Flags [.], seq 1428:2628, ack 1, win 502, options [nop,nop,TS val 1847455487 ecr 1248995470], length 1200: HTTP
18:58:12.782850 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (1232|228)
18:58:12.803319 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (0|1232) 80 > 34780: Flags [P.], seq 2856:4056, ack 1, win 502, options [nop,nop,TS val 1847455487 ecr 1248995470], length 1200: HTTP
18:58:12.803326 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (1232|40)
18:58:12.823802 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (0|1232) 80 > 34780: Flags [.], seq 4096:5296, ack 1, win 502, options [nop,nop,TS val 1847455487 ecr 1248995470], length 1200: HTTP
18:58:12.823807 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (1232|228)
18:58:12.844138 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (0|1232) 80 > 34780: Flags [.], seq 5524:6724, ack 1, win 502, options [nop,nop,TS val 1847455487 ecr 1248995470], length 1200: HTTP
18:58:12.844142 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (1232|228)
18:58:12.864621 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (0|1232) 80 > 34780: Flags [P.], seq 6952:8152, ack 1, win 502, options [nop,nop,TS val 1847455487 ecr 1248995470], length 1200: HTTP
18:58:12.864628 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a02:IPv6:8120:847e:a919:9904: frag (1232|198)
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Meinem IPv6 Präfix habe ich ein wenig versteckt, aber das wurde von mir editiert. In tcpdump kommt eine valide IPv6 Adresse raus als Ziel, nämlich die von meinem Testgerät.

Bestätigt also, würde ich stumpf und laienhaft erstmal sagen, die Testergebnissen der Webseite. Bei IPv6 fragmentierte Pakete gehen (wie gesagt inzwischen) durch, bei IPv4 kommen (weiterhin) keine fragmentierte Pakete an.

Hey @almightyloaf,

wenn @pufferueberlauf0 diese Tests bei Gelegenheit durchführen möchte, kann man diese Ergebnisse vielleicht vergleichen. Ich kenne mich da leider nicht aus und bin mir unsicher, was man da jetzt für ein weiterführendes Fazit ziehen kann. 

Liebe Grüße, Lea

Nicht schlimm :)

Gegentests sind absolut wichtig, alleine schon um zu prüfen ob das Problem regional ist (was auch eher wahrscheinlich ist) oder dasn gesamte Festnetz betrifft. Über Mobilfunk (5G) tritt der Fehler nicht auf.

Was allerdings ebenfalls nötig wäre ist, sofern meinerseits das Problem korrekt “gemessen” wurde, dass sich die Netztechnik sich ansieht, weshalb ich keine vom sendenden Interface fragmentierten IPv4 Packete erhalte. Hierfür gebe ich gerne dann z.B. über Privatnachrichten mehr Infos zum Anschluss, so dass die Technik auch z.B. bis zum letzten/ersten (je nach Sichtweise) von/zu mir sichtbaren IPv4 Router messen kann.

Ich will letztendlich nicht unnötig die Netzwerkingenieure hierfür beschäftigen, aber die anzeichen zeigen bisher, meiner Ansicht nach, dass ein Problem auf Netzseite besteht.

Am lustigsten wird es, wenn das Problem von einem Netzelement auf Infrastrukturbetreiberseite verursacht wird, aber ich kann das leider nicht gegenprüfen.

Mmmh, momentan funktioniert 

http://icmpcheck.popcount.org

Und http://icmpcheck6.popcount.org sieht auch gut aus:

Danke für’s prüfen.

Somit ist das auch kein genereller Fehler. Dadurch sinkt leider aber auch die Menge an betroffenen Kunden, was die Argumentation für eine vertiefte Prüfung seitens o2 natürlich schmälert

Bei mir ist bisher der Fehler unverändert, ganz egal welche IPv4 Router verwendet werden und welche IPv4 mein Router erhält. IPv6 geht, IPv4 nicht. Ich fürchte wieder ein recht lokales Problem erwischt zu haben mit wenig Impact :/