IP/Fragmentierung: Unterschied zwischen den Versionen
K Textersetzung - „<div style="column-count:3">“ durch „<div style="column-count:2">“ |
|||
(29 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''IP | '''IP/Fragmentierung''' - Aufteilung eines [[IP-Datagramm]]s, wenn es größer als die [[Maximum Transmission Unit]] der Netzwerkschnittstelle ist | ||
== Beschreibung == | == Beschreibung == | ||
Fragmentierung von Paketen auf einem Übertragungsnetzwerk, wenn das Paket größer ist als die MTU-Size des Netzwerks oder einer Teilstrecke | |||
; Zielsetzung | ; Zielsetzung | ||
Ziel bei der Einführung der Fragmentierung im [[Internet Protocol|Internetprotokoll]] (IP) war es | Ziel bei der Einführung der Fragmentierung im [[Internet Protocol|Internetprotokoll]] (IP) war es | ||
* die zugrundeliegende Netzwerkstruktur für den Benutzer zu verbergen ([[OSI-Modell]]) | |||
* Implementierung des [[Netzwerkprotokoll]]s Hardware-unabhängig zu gestalten | |||
; Hintergrund | ; Hintergrund | ||
Im einfachsten Fall passt das gesamte IP-[[Datagramm]] in einen Datenblock | Im einfachsten Fall passt das gesamte IP-[[Datagramm]] in einen Datenblock | ||
* | |||
* Höchste Effizienz | |||
* Maximale Größe eines IP-Datagramms | |||
** 64 kB | |||
* Die maximal mögliche Paketgröße ([[MTU]]) ist abhängig von den verwendeten Infrastrukturkomponenten | |||
* Moderne Paket-[[Switch (Netzwerktechnik)|Switching]]-Techniken lassen unterschiedliche maximale Paketgrößen zu | |||
* | |||
; Relevanz | |||
{| class="wikitable options big" | {| class="wikitable options big" | ||
|- | |- | ||
Zeile 59: | Zeile 66: | ||
Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden | Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden | ||
== | <noinclude> | ||
; | |||
== Wo wird fragmentiert? == | |||
* | Wenn zwei System miteinander per TCP/IP kommunizieren, übertragen Sie Pakete mit Daten | ||
* | * Einige Pakete tragen nur wenige Inhalte, beispielsweise eine Terminal-Eingabe hat meist nur 1 Zeichen als Payload | ||
* | * Audio-Übertragungen kommen meist mit 160 Bytes Payload (= 20ms Ton bei 64kbit) aus | ||
* Ein Dateitransfer hingegen überträgt viele Daten und möchte die Bandbreite optimal ausnutzen | |||
Nun gibt es aber auf dem Übertragungsweg verschieden Teilstrecken mit unterschiedlicher Paketgröße | |||
* Das maximale Paket bei Ethernet beträgt normalerweise 1514 Bytes | |||
[[Image:Bild1.png|top]] | |||
Wenn man nun die 6 Bytes der Absender-MAC-Adresse, weitere 6 Bytes der Empfänger-MAC-Adresse und 2 Bytes für den Protokolltyp (0x0800 = IP) abzieht, bleiben noch 1500 Bytes Nutzdaten für das eigentliche Protokoll übrig | |||
* Das kann dann natürlich IP, TCP, UDP, ICMP aber auch NetBEUI, IPX o. ä. sein | |||
* Die MTU-Größe wird also von dem Übertragungsmedium der Netzwerkkarte definiert | |||
Sie können die aktuelle MTU Größe abfragen | |||
PS C:\> Get-NetAdapter | ft name,status,linkspeed,mtusize | |||
name Status LinkSpeed mtusize | |||
<nowiki>---- </nowiki> <nowiki>------ </nowiki> <nowiki>--------- -------</nowiki> | |||
Mobilfunk Disconnected 0 bps 1500 | |||
WLAN Disconnected 0 bps 1500 | |||
LAN Onboard Disconnected 0 bps 1500 | |||
Bluetooth-Netzwerkverbindung Disconnected 3 Mbps 1500 | |||
LAN USBDock Up 1 Gbps 1500 | |||
In der Regel sind es 1500 Bytes, aber das muss nicht sein | |||
* Der darauf aufbauende Protokollstapel muss seine großen Pakete entsprechend zum Versand aufteilen und auf der Gegenseite wieder zusammensetzen.Sie können abweichend auch eine kleinere MTU-Size auf ihrer Netzwerkkarte einstellen | |||
* Einige Treiber erlauben die Konfiguration per GUI in den Netzwerkeigenschaften | |||
Ansonsten geht es auch per NETSH | |||
netsh interface ipv4 set subinterface `Local USBDock` mtu=1472 store=persistent” | |||
netsh interface ipv4 show subinterface | |||
; Achtung | |||
: Sie sollten die MTU-Size nicht ohne sehr gute Kenntnisse der Funktion ändern | |||
:* Gut gemeinte Tipps die MTU-Size zu verringern, um mit DSL-Verbindungen schneller Ping-Zeiten zu erreichen, sind falsch | |||
:* Nur bei Problemen mit dem MTU-Discovery können Sie überlegen die MTU-Size manuell anzupassen | |||
Die Änderung der MTU-Size auf einer Netzwerkkarte beeinflusst sowohl die Sende- als auch Empfangsrichtung | |||
* Sie können damit absichtlich kleinere Pakete erreichen, beispielsweise wenn eine dynamische Anpassung nicht möglich ist | |||
* In dem folgenden Bild ist das die Einstellung am Punkt (1) | |||
[[Image:Bild2.png|top]] | |||
Ein Client kann aber nicht wissen, wie groß die Pakete auf dem Übertragungsweg sind | |||
* Gerade der erste Hop der Fritz!Box per DSL, DSLite, Kabel o. ä. sorgt schon dafür, dass an der Position (2) ein 1500 Bytes großes Paket nicht mehr mehr weiter geleitet werden kann | |||
* Der Router hat nun zwei Möglichkeiten damit umzugehen:* Verwerfen und Absender informierenMit einem "ICMP Fragmentation needed" kann der Router ein Paket an den Absender übermitteln, wie groß das Paket maximal sein darf | |||
* Der Sender schnürt dann kleinere Pakete, auch wenn dies bedeutet, dass auch auf den anderen Teilsteckern nicht mehr die maximale Paketgröße ausnutzt wird | |||
* Dieses "Paket zu groß" kann auch auf dem weiteren Verlauf weiter passieren und bei einem Wechsel des Routing auch während einer Verbindung passieren | |||
* Gehen Sie davon aus, dass alle Router im Internet nach dem Schema verfahren | |||
* Router packt selbst umHistorisch gibt es aber auch noch die Option, dass der Router das zu große Paket selbst in kleinere Pakete verpackt und die Gegenseite daraus wieder die originalen Pakete herstellt | |||
* Das belastet aber die Router zusätzlich und muss von beiden Seiten unterstützt werden | |||
* Zudem verschlechtert dies Durchsatz, wen beispielsweise * aus einem 1500er Paket dann ein 1400er + 100er Paket wird | |||
* Auf dem weiteren Weg könnte das Umpacken dann noch mal erforderlich werden | |||
* Die meisten ISPs unterstützen daher dieses Verfahren nicht mehr | |||
Es soll Router geben, die zu große Pakete verwerfen und keine Rückmeldung senden und es soll Firewall-Administratoren geben, die das Protokoll ICMP als Schutz gegen "Ping"-Anfragen blocken und dabei auch die anderen ICMP-Steuernachrichten verlieren. | |||
ICMP zu blocken ist eine schlechte Idee, denn diese Steuerungsnachrichten sind für das Internet und TCP/IP von elementarem Interesse | |||
* Angreifer brauchen keinen PING um ihr Netzwerk zu analysieren | |||
* Dazu reichen auch TCP-Sync-Scans, UPNP Abfragen, ARP-Requests im LAN u.a. "Security by Obscurity" war noch nie ein guter Ansatz | |||
Um solche Probleme zukünftig zu vermeiden, sollten sie zwei Fakten wissen:* IPv6 macht keine FragmentierungBei IPv6 müssen Sie daher "ICMP-Size Exceeded"-Meldungen verarbeiten | |||
* Ein Umpacken ist nicht mehr vorgesehen(Siehe auch [https://www.msxfaq.de/netzwerk/ipv6/index.htm IPv6 im Netzwerk] und "IPv6 fragmentation" [https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation] "IPv6 routers never fragment IPv6 packets" | |||
* [https://www.msxfaq.de/netzwerk/quic/index.htm QUIC - UDP mit TLS statt TCP]Bei der Übertragung von HTTP over UDP ist die MTU-Size auf 1300 Bytes festgelegt und wird beim ersten Paket gleich mit getestet | |||
== MTU anpassen == | |||
Dieser Abschnitt passt zwar besser auf die Seite [https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm Maximum Transmission Unit (MTU)] aber wenn Sie die folgenden Analysen im LAN nachtesten wollen, dann brauchen Sie diese Information | |||
* Mein Ziel ist es, dass ich von PC1 Pakete zu PC2 im gleichen LAN sende | |||
* Da beide im Ethernet sind damit die MTU = 1500 Bytes gleich ist, kann ich das Verhalten schlecht zeigen, denn alles >1500 Bytes lehnt der IP-Stack schon ab | |||
* Daher möchte ich auf der entfernten Seite die MTU-Size reduzieren | |||
* Einige Netzwerkkarten erlauben diese Konfiguration in den erweiterten Eigenschaften: | |||
[[Image:Bild3.png|top]] | |||
Ich würde diese hier aber nicht ändern sondern per NETSH auf der Netzwerkkarte des PC2 | |||
* Zuerst hole ich mir die Information zur Netzwerkkarte und setze sie dann temporär auf 1400 | |||
REM Anzeige der Netzwerkkarte mit ihren Einstellungen | |||
Netsh interface ipv4 show interfaces | |||
Idx Met MTU State Name | |||
--- <nowiki>---------- </nowiki> <nowiki>---------- </nowiki> <nowiki>------------ </nowiki> <nowiki>---------------------------</nowiki> | |||
1 75 4294967295 connected Loopback Pseudo-Interface 1 | |||
28 70 1500 disconnected WLAN | |||
21 25 1500 connected Ethernet | |||
REM Setzen der MTU Size | |||
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 | |||
Nun sollte ein zu großes Paket von PC1 zu PC2 nicht zugestellt oder fragmentiert werden | |||
Wenn Sie Pakete per Wireshark mitschneiden, dann kann es sein, dass die Netzwerkkarte selbst die Pakete fragmentiert und wieder zusammensetzt und Wireshark daher nicht die realen Pakete sieht | |||
Um den Mitschnitt zu optimieren, können sie im gleichen LAN einen CaptureFilter mit "Host <ip der gegenstelle>" eintragen | |||
== ICMP Fragmentation == | |||
Zuerst sende ich nun keinen "kleinen Ping" mit 1300 Bytes an die Gegenstelle | |||
* Hier ist noch keine Überraschung zu erwarten | |||
* Die Pakete werden mit 1300 Bytes "Payload" gesendet und sind auf dem Kabel 1342 Bytes groß: | |||
ping 192.168.102.183 -l 1300 | |||
[[Image:Bild4.png|top]] | |||
Die 42 Bytes gehen für den ICMP, IP und Ethernet Frame drauf und auch die Antwort ist einfach zu verstehen | |||
[[Image:Bild5.png|top]] | |||
Interessant wird es nun, wenn wir ein größeres Paket versenden | |||
* Bei meinem Sender ist die MTU=1500 eingestellt aber der Empfänger kann zumindest nicht mehr senden | |||
ping 192.168.102.183 -l 1450 | |||
Das ausgehende Paket 12 hat nun 1450 Bytes Nutzdaten und ist 1492 Bytes auf dem Kabel | |||
* Eigentlich würde ich nun erwarten, dass die Gegenseite das Paket gar nicht annimmt | |||
* Dem ist aber nicht so, denn ich habe in dem Test nur die ausgehende MTU-Größe reduziert | |||
* Daher kommt die Rückantwort reduziert an | |||
[[Image:Bild6.png|top]] | |||
In dem Fall sehen wir nun zwei Antwortpakete der Gegenseite | |||
* Der IP-Stack möchte die 1450 Bytes beantworten aber ist durch die MTU-Begrenzung limitiert | |||
* Also muss er die Pakete aufteilen | |||
* Das erste Paket selbst ist nur indirekt als ICMP-Paket erkennbar | |||
* Wireshark zeigt das fragmentierte IP-Paket als "Protocol=IPv4" | |||
[[Image:Bild7.png|top]] | |||
Es ist einfach in "Raw"-IP-Paket mit einer "Identification" und der Information, dass weitere Fragmente kommen | |||
* Der Empfänger wartet also nun auf das weitere Paket, welche die gleiche "Identification" beinhaltet: | |||
[[Image:Bild8.png|top]] | |||
Erst jetzt ist die komplette Antwort zurück gekommen | |||
Wireshark ist smart genug, die beiden Pakete 13/14 zusammenzusetzen und in Paket 14 komplett anzuzeigen | |||
* Die Fragmente sehen ist also nicht in der , wenn Sie beispielsweise * eine Filter "ICMP" aktivieren, da die Teil-Fragmente nicht als ICMP-Pakete angesehen werden | |||
Sie können aber im Paket 14 sehen, dass es aus mehreren Fragmenten übertragen wurde: | |||
[[Image:Bild9.png|top]] | |||
Sie haben nun gesehen, wie Fragmentation die Pakete aufteilt und wieder zusammensetzt und dies pro Richtung unterschiedlich sein kann | |||
== DoNotFragment und Router == | |||
Der Test mit einem PC im gleichen Subnetz ist natürlich nur bedingt sinnvoll | |||
* Ich möchte ja mal sehen, was ein Router auf dem Weg macht | |||
* Wenn ich nun ein Paket mit 1500 Bytes versende, dann verlässt dies meinen PC problemlos und der nächste Router kann es so aber nicht über eine DSL-Leitung senden | |||
* Ich kann aber nicht wissen, ob der Router nun selbst das Paket "fragmentiert" oder nicht | |||
* Aber ich kann ihn anweisen, keine Fragmentierung zu nutzen | |||
* Beim Ping ist das Flag "-f" dafür zuständig | |||
C:\> ping www.msxfaq.de -f -l 1500 | |||
Ping wird ausgeführt für www.msxfaq.de [178.77.117.98] mit 1500 Bytes Daten: | |||
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt | |||
Diese Paket kann ich allerdings nicht in Wireshark finden, denn es verlässt meinen PC gar nicht erst | |||
* Wenn ich eine 1500Byte Payload über ein Interface mit 1500 Bytes MTU-Size senden will, dann lehnt das der IP-Stack schon ab, denn die 1500 Bytes müssen ja noch in ICMP und IP eingepackt werden, denn die MTU-Size bezieht sich auf das Ethernet-Paket ohne die 14 Bytes für MAC-Adressen und Type | |||
* Die maximale Paketgröße ist daher 1500-14 = 1486 | |||
* Davon gehen noch mal 20 Byte für den IP-Header und 16 Bytes für ICMP-Header | |||
1512 Kabel | |||
-6 SenderMAC | |||
-6 EmpfängerMAC | |||
-2 Type | |||
<nowiki>=========</nowiki> | |||
<nowiki>= 1500 </nowiki> MTU für Daten | |||
- 20 für Version, DSCP, Flags, Protocol, Headerchecksumme, SourceIP, DestIP | |||
<nowiki>=========</nowiki> | |||
<nowiki>= 1480</nowiki> | |||
- 8 für ICMP Typ, Code, Checksumme, Identifier, Sequence | |||
<nowiki>========</nowiki> | |||
<nowiki>= 1872</nowiki> | |||
Erst wenn wir in dem Fall ein ICMP-Ping-Paket mit 1472 Bytes Payload oder kleiner senden, verlässt es meinen PC | |||
PS C:\> ping 178.77.117.98 -f -l 1472 | |||
Ping wird ausgeführt für 178.77.117.98 mit 1472 Bytes Daten: | |||
Antwort von 80.66.18.137: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt | |||
Durch das "-f" zeige ich aber an, dass ich keine Fragmentierung möchte | |||
* Im ausgehenden Paket sehen Sie dies in den Flags: | |||
[[Image:Bild10.png|top]] | |||
Das Paket kommt nun beim Router an und wenn er es aufgrund der Größe nicht weiterleiten kann aber Fragmentierung auch verboten ist, dann kann er nur mit einem "Fragmentation needed" antworten: | |||
Hinweis: Filtern Sie nicht auf die Zieladresse, denn das "ICMP Destination unreachable" kommt vom Router auf dem Weg | |||
[[Image:Bild11.png|top]] | |||
Ich muss mein Paket also um mindestens 8 Bytes kleiner machen damit es den nächsten Hop überspringt | |||
* Mit einem Ping und 1464 Bytes kam das Paket direkt beim Ziel an | |||
PS C:\> ping 178.77.117.98 -f -l 1464 | |||
Ping wird ausgeführt für 178.77.117.98 mit 1464 Bytes Daten: | |||
Antwort von 178.77.117.98: Bytes=1464 Zeit=15ms TTL=49 | |||
Antwort von 178.77.117.98: Bytes=1464 Zeit=15ms TTL=49 | |||
Antwort von 178.77.117.98: Bytes=1464 Zeit=15ms TTL=49 | |||
Es gibt auf der ganzen Strecke dann kein Teilstück mit einer kleineren MTU, sofern sich alle Router an das "Don't Fragment (DF)" halten | |||
Hinweis:Um DoS und Spoofing-Attacken zu erschweren, antworten Router nicht auf jedes Paket mit einer "ICMP Fragmentation needed" | |||
* Der Client merkt sich diese Information | |||
Das sehen Sie auch beim Ping eines übergroßen Pakets | |||
PS C:\> ping 178.77.117.98 -f -l 1470 -t | |||
Ping wird ausgeführt für 178.77.117.98 mit 1470 Bytes Daten: | |||
Antwort von 80.66.18.137: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt | |||
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt | |||
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt | |||
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt | |||
Nur die erste Antwort liefert die Details zum Router | |||
* Sie sollten das "Don't Fragment"-Bit nur setzen, wenn Sie es zwingend benötigen, da dies auch eine Fragmentierung auf ihrem Client unterbindet und ihre Software sich dann selbst drum kümmern muss, die richtige Paketgröße zu schnüren | |||
== Fragmentierung mit UDP == | |||
Neben ICMP gibt es mit UDP noch ein "verbindungsloses Protokoll", ehe wir uns dann noch TCP anschauen | |||
* Um zu zeigen, wie ein System auf fragmentierte Pakete umstellt, habe ich ein kleines PowerShell-Skript auf Basis von [https://www.msxfaq.de/powershell/psudp.htm PowerShell und UDP] geschrieben, welches immer größere UDP-Pakete sendet | |||
* Der Code eignet sich beispielsweise * um die Durchlässigkeit eines Routers, einer Firewall oder eines Loadbalancers zu verifizieren | |||
param ( | |||
[string]$remoteip = "www.msxfaq.de", # IP to send to | |||
[int]$remoteudpport=5060, <nowiki># port to send to</nowiki> | |||
[int]$sourceudpport = 0, <nowiki># SourcePort, maybe empty uses and available port</nowiki> | |||
[Parameter(ValueFromPipeline= $True)][int]$size = 100 | |||
) | |||
$udpClient = New-Object System.Net.Sockets.Udpclient($sourceudpport) | |||
$udpClient.DontFragment=$false | |||
Write-host "Sending Paket with $($size) bytes to $($remoteip):$($remoteudpport)" | |||
[string]$buffer = ("SendUDP Message by msxfaq").padright($size,"A") | |||
$byteBuffer <nowiki>= [System.Text.Encoding]::ASCII.GetBytes($Buffer)</nowiki> | |||
$sendbytes = $udpClient.Send($byteBuffer, $byteBuffer.length, $remoteip, $remoteudpport) | |||
if ($sendbytes -ne $byteBuffer.length) { | |||
write-host "Mismatch bytes" | |||
} | |||
$udpClient.close() | |||
Diese Skript sendet ohne Flusskontrolle, Drosselung o.ä | |||
* ganz schnell UDP-Pakete mit 1000-1500 Bytes an das angegebene Ziel | |||
* Es wartet nicht auf eine Antwort | |||
* Sie können damit also schon einen kleinen "Sturm" simulieren | |||
Wenn Sie hier beim Capture Filter ein "UDP.port=5060" eintragen, dann sehen Sie nur die UDP-Pakete und nicht die Fragmentierung | |||
[[Image:Bild12.png|top]] | |||
Beachten Sie dabei: | |||
Das fragmentierte Paket kommt zuerst und hat nur eine "Identification" mit den Informationen über SourceIP, DesIP und Protokoll=UDP aber keiner Information über UDP-Ports | |||
Das macht es für einen Loadbalancer unmöglich, diese Paket anhand eines "Protokoll" auf eine Regel zu mappen | |||
* Der Loadbalancer müsste die Pakete zwischenspeichern, bis er das letzte Paket bekommt | |||
* Erst das enthält die Information und kann anhand der "Identification" zusammengeführt werden | |||
[[Image:Bild13.png|top]] | |||
Hier sehen Sie den Src-Port und Dest-Port aber auch die errechnete Datenlänger (1472 Bytes), obwohl dieses Paket nur 35 Bytes auf dem Kabel groß war | |||
* Wireshark führt fragmentierte Pakete zur Analyse zusammen | |||
Theoretisch könnte ein Angreifer nun ein fragmentiertes Paket durch ein anderes Paket ersetzen | |||
* Daher ist eine zusätzliche Absicherung auf dem Datenlevel per TLS oder SRTP immer ratsam | |||
Für eine Firewall oder Loadbalancer sind das natürlich erschwerte Bedingungen | |||
Genau genommen müsste der Loadbalancer das Fragment puffern, bis das letzte Paket kommt und dann alle entweder defragmentiert weiterleiten oder wieder in der Reihenfolge | |||
* Wenn nun aber ein sehr großes Paket in viele Pakete fragmentiert wird und die auch noch unterschiedliche Wege nehmen und daher noch die Reihenfolge ändern, dann muss der Loadbalancer auch damit umgehen | |||
Das Problem hierbei ist, dass das Zielsystem solche Aufgaben natürlich übernehmen kann aber Router oder Loadbalancer dazwischen durch solche Fragmentieren nicht nur belastet sondern sogar gezielt gestört werden können | |||
* Als Angreifer könnte ich ja gezielt "Fragmente" senden und immer Pakete weglassen, so dass das System auf der anderen Seite überlastet wird | |||
Es macht daher schon Sinn, auf Fragmentierung komplett zu verzichten und IPv6 und QUIC machen das ja auch | |||
== UDP mit "DontFragment=$true" == | |||
Das gleiche Skripte habe ich auch noch einmal angewiesen, keine Fragmentierung zuzulassen | |||
* Das geht bei der UDP-Klasse ganz einfach durch folgende zusätzliche Zeile nach der Instanzierung des Objekts: | |||
$udpClient = new-Object system.Net.Sockets.Udpclient($sourceudpport) | |||
$udpClient.DontFragment=$false | |||
Wenn ich nun Pakete mit aufsteigender Paketgröße sende, dann bricht irgendwann die Übertragung zusammen und ich bekomme eine Meldung von dem Router, bei dem das Paket nicht mehr weiter gesendet wird | |||
* In dem Fall die 8.6.18.137 | |||
* Hier kommt der Fehler nun nicht erst bei dem Limit meiner Netzwerkkarte mit 1472Bytes (1514 Ethernet) sondern bei 1466 Bytes | |||
[[Image:Bild14.png|top]] | |||
Die Rückantwort ist ein ICMP und kein UDP-Paket | |||
* Beim Wireshark-Filter sollten Sie also beispielsweise "udp.port=5060 or ICMP" nutzen | |||
* Die Source-IP wird zu viele Daten liefern aber ein Filter auf die RemoteIP blende die ICMP-Antworten auch aus, die vom Router unterwegs kommen | |||
* Dass dies eine Statusmeldung für das ausgehende UDP-Paket ist, findet sich dann in der Payload | |||
[[Image:Bild15.png|top]] | |||
Dort geht auch, wir groß die MTU, hier 1492) maximal sein darf | |||
* Die ICMP Rückantwort wird vom IP-Stack auch an das UDP-Objekt zurück gegeben | |||
* Ohne entsprechende Fehlerbehandlung sehen Sie den Error direkt in der PowerShell: | |||
[[Image:Bild16.png|top]] | |||
Interessant ist hierbei, dass im Gegensatz zu dem ICMP-Ping hier der Router auf jedes Paket eine Meldung sendet und meine IP-Stack oder das UDP-Objekt die Größenüberschreitung nicht cached | |||
Das "do Not Fragment" ist ein IP-Flag und kann genauso mit ICMP und UDP genutzt werden | |||
* Es ist dann in der Verantwortung des Absenders korrekt darauf zu reagieren, beispielsweise: indem es entsprechend kleine Pakete sendet | |||
Beim PING geht das mit dem "-f"-Paramterl | |||
ping -f -l 1500 | |||
Interessant ist dazu eine Aussage einer schwedischen Quelle: | |||
3.2.3 IP fragmentation During the year 2000, McCreary et al. [1] observed an increase in the fraction IP packets carrying fragmented traffic from 0.03% to 0.15% | |||
* Indeed, one year later, Shannon et al. [6] reported fractions of fragmented traffic of up to 0.67% | |||
* Contrary to this trend, we found a much smaller fraction of 0.06% of fragmented traffic in the analyzed data. ...3.2.4 IP flags The analysis of the IP flags (fragment bits) revealed that 91.3% of all observed IP packets have the don’t fragment bit (DF) set, as proposed by Path MTU Discovery (RFC 1191). 8.65% use neither DF nor MF (more fragments) and 0.04% set solely the MF bit.Quelle: Analysis of Internet Backbone Traffic and Header Anomalies observed [http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf] | |||
Es werden also wohl sehr wenige Pakete tatsächlich fragmentiert und die meisten sogar ein "DF"-Flag gesetzt haben | |||
Analysis of Internet Backbone Traffic and Header Anomalies observed[http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf]* [https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm Maximum Transmission Unit (MTU) und Fragmentierung] | |||
* RFC 1191 Path MTU Discovery[https://datatracker.ietf.org/doc/html/rfc1191 https://datatracker.ietf.org/doc/html/rfc1191] | |||
* RFC 1981 Path MTU Discovery for IP version 6[https://datatracker.ietf.org/doc/html/rfc1981 https://datatracker.ietf.org/doc/html/rfc1981] | |||
* Path MTU Discovery[https://de.wikipedia.org/wiki/Path_MTU_Discovery https://de.wikipedia.org/wiki/Path_MTU_Discovery] | |||
* Path MTU discovery in practice[https://blog.cloudflare.com/path-mtu-discovery-in-practice/ https://blog.cloudflare.com/path-mtu-discovery-in-practice/] | |||
* Path MTU Discovery[https://www.elektronik-kompendium.de/sites/net/2012221.htm https://www.elektronik-kompendium.de/sites/net/2012221.htm] | |||
== Fragmentierung mit TCP == | |||
Heute versuchen System eine Fragmentierung von Paketen vom Anfang an zu vermeiden | |||
* Aufgrund der "TCP-Verbindung" ist das im Gegensatz zu UDP auch pro Session und der eindeutigen 1:1 Beziehung von Sender und Empfänger sinnvoll | |||
* Daher gibt es mit "Path MTU Discovery (PMTUD)" eine Spezifikation, mit der die beiden Endpunkte ermitteln, welche Paketgröße maximal möglich ist | |||
Technisch senden Sie wie auch UDP nun ihre TCP-Pakete mit dem "DH-Flag=1" und werten die ICMP-Meldung "Fragmentation needed" aus | |||
* Das Paket enthält ja die maximale MTU-Size und diese wird vom Sender für alle weiteren Pakete übernommen | |||
* Diese Rückmeldung kann auch mehrfach eintreffen, wenn verschiedene Router hintereinander immer kleinere MTU-Werte nutzen oder das Routing sich ändert | |||
* Insofern verhält sich TCP nicht anders als UDP, nur dass bei UDP die eigene Software sich um zur große Pakete kümmern muss, wenn man DF-Flag=1 nutzt | |||
Allerdings kann es sein, dass Sie mit Wireshark gar nicht die entsprechenden Pakete sehen, denn die Funktion wird immer mehr von "intelligenten Netzwerkkarten" übernommen um die Host-CPU zu entlasten | |||
* Wireshark sieht dann immer erfolgreiche Verbindungen mit bis zu 1514 Bytes | |||
[[Image:Bild17.png|top]] | |||
Daher kann es sein, dass die Mitschnitte bei der Analyse in die Irre führen und sie immer nur "fehlerfreie Übertragungen" sehen | |||
* Das gilt natürlich nur für TCP aber nicht für UDP.* Wireshark Wiki: Offloading[https://wiki.wireshark.org/CaptureSetup/Offloading https://wiki.wireshark.org/CaptureSetup/Offloading] | |||
* When is full packet capture NOT full packet capture?[https://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html https://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html] | |||
* Analyzing TCP Segmentation Offload (TSO) with Wireshark[https://www.networkdatapedia.com/post/2016/08/11/analyzing-tcp-segmentation-offload-tso-with-wireshark https://www.networkdatapedia.com/post/2016/08/11/analyzing-tcp-segmentation-offload-tso-with-wireshark] | |||
* Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008[https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/information-about-tcp-chimney-offload-rss-netdma-feature?WT.mc_id=M365-MVP-6771 https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/information-about-tcp-chimney-offload-rss-netdma-feature] | |||
* [https://www.msxfaq.de/netzwerk/grundlagen/tcpsynackres.htm TCP SYN ACK RES] | |||
* [https://www.msxfaq.de/netzwerk/grundlagen/tcp_retransmit_und_sack.htm TCP Retransmit und SACK]Netzwerkgrundlagen für Cloud und LAN | |||
* [https://www.msxfaq.de/tools/3rdparty/wireshark.htm Wireshark] | |||
* Wireshark Wiki: Offloading[https://wiki.wireshark.org/CaptureSetup/Offloading https://wiki.wireshark.org/CaptureSetup/Offloading] | |||
* Path MTU Discovery[https://de.wikipedia.org/wiki/Path_MTU_Discovery https://de.wikipedia.org/wiki/Path_MTU_Discovery] | |||
* Empfohlene TCP/IP-Einstellungen für WAN-Verbindungen mit einer MTU-Größe von weniger als 576 Byte[https://support.microsoft.com/de-de/topic/empfohlene-tcp-ip-einstellungen-für-wan-verbindungen-mit-einer-mtu-größe-von-weniger-als-576-byte-2312050e-2a1b-1e89-94a1-b2868afa436f?WT.mc_id=M365-MVP-6771 https://support.microsoft.com/de-de/topic/empfohlene-tcp-ip-einstellungen-f%C3%BCr-wan-verbindungen-mit-einer-mtu-gr%C3%B6%C3%9Fe-von-weniger-als-576-byte-2312050e-2a1b-1e89-94a1-b2868afa436f] | |||
* RFC 879 The TCP Maximum Segment Size and Related Topics[https://tools.ietf.org/html/rfc879 https://tools.ietf.org/html/rfc879] | |||
* RFC 1191 Path MTU Discovery[https://tools.ietf.org/html/rfc1191 https://tools.ietf.org/html/rfc1191] | |||
* RFC 1981 Path MTU Discovery for IP version 6[https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981] | |||
* RFC 2923 TCP Problems with Path MTU Discovery[https://tools.ietf.org/html/rfc2923 https://tools.ietf.org/html/rfc2923] | |||
* RFC 4821 Packetization Layer Path MTU Discovery[https://tools.ietf.org/html/rfc4821 https://tools.ietf.org/html/rfc4821] | |||
* Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec[https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html] | |||
== IPv6 und Fragmentierung == | |||
Bei IPv6 ist es nicht mehr erlaubt, dass ein System auf dem Übertragungsweg die Pakete fragmentiert | |||
* Das, was bei IPv4 noch als Verletzung des OSI-Modells geschimpft wurde, wenn ein IP-Router (OSI-Schicht 3) in den Übertragungsweg (OSI Schicht 2) eingreift, ist bei IPv6 nun empfohlen | |||
IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [[https://tools.ietf.org/html/rfc1981#ref-IPv6-SPEC IPv6-SPEC]] section "Fragment Header") | |||
* However, packetization layers are encouraged to avoid sending messages that will require fragmentationQuelle: RFC 1981 - Path MTU Discovery for IP version 6 - [https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981] | |||
The Fragment header is used by an IPv6 source to send packets larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery pathIPv6 requires that every link in the internet have an MTU of 576 octets or greater | |||
* On any link that cannot convey a 576-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.Links that have a configurable MTU (for example, PPP links) must be configured to have an MTU of at least 576 octets; it is recommended that a larger MTU be configured, to accommodate possible encapsulations (i.e., tunneling) without incurring fragmentation.Quelle: RFC 1883 Internet Protocol, Version 6 (IPv6) Specification" - [https://tools.ietf.org/html/rfc1883 https://tools.ietf.org/html/rfc1883] | |||
Mit IPv6 kommt bei "Test-Connection" eine MTUSize von 9999 Bytes zustande | |||
PS C:\> Test-Connection fritz.box -MTUSizeDetect -Verbose -IPv6 | |||
Source : FC-T480S | |||
Destination : fritz.box | |||
MTUSize : 9999 | |||
Status : Success | |||
Address : 2003:ea:a713:2c00:cece:1eff:fe34:3d04 | |||
RoundtripTime : 1 | |||
Options : | |||
Buffer : {97, 98, 99, 100_} | |||
Da scheint noch ein Bug vorzuliegen, denn auch hier ist die echte Paketgröße auf dem Kabel bei 1502 (eigentlich 1500) aber der IP-Stack scheint zu fragmentieren, ohne das Test-Connection davon etwas merkt | |||
* Wireshark zeigt schön die vielen Pakete vom Client zum Server und markiert das finale Paket | |||
[[Image:Bild18.png|top]] | |||
Irgendwie macht das dann aber auch Sinn, wenn ein Versuch das Phänomen mit PING nachzuvollziehen liefert einfach die folgende Ausgabe: | |||
C:> ping fritz.box -6 -f | |||
Die Option "-f" wird nur für IPv4 unterstützt | |||
Interessant finde ich dann aber schon, dass Test-Connection durch den IPv6-Stack ausgetrickst und keine Fehlermeldung liefert, dass IPv6-Adressen nicht geprüft werden können.* RFC 1981 - Path MTU Discovery for IP version 6[https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981] | |||
* RFC 1883 Internet Protocol, Version 6 (IPv6) Specification"[https://tools.ietf.org/html/rfc1883 https://tools.ietf.org/html/rfc1883] | |||
* Path MTU Discovery[https://de.wikipedia.org/wiki/Path_MTU_Discovery https://de.wikipedia.org/wiki/Path_MTU_Discovery] | |||
== SIP mit UDP == | |||
Die meisten UDP-Kommunikationen sind Audio/Video-Übertragungen, die von der effektiven Behandlung von Verlusten profitieren | |||
* Immer, wenn ein verlorenes Paket eh nicht mehr nachgesendet werden muss, da es schon obsolet ist, ist UDP gegenüber TCP von Vorteil | |||
* Auch IoT-Geräte können per UDP beispielsweise * Energie spare, wenn Sie einfach ein Paket ein oder mehrfach senden und nicht erst einen TCP/TLS-Handshake aufbauen etc | |||
* Auch DNS-Anfagen sind lange Zeit über UDP erfolgt, weil es eine einfache Kommunikation ist | |||
* Wobei hier auch TCP zum Einsatz kommt, beispielsweise * bei Zonentransfers, DNSSEC oder auch DNSoverHTTP u.a | |||
* Einsatzbereichen | |||
Aber im VoIP-Umfeld wurde lange Zeit auch die Signalisierung per SIP über UDP übertragen | |||
* Heute würde ich das nicht mehr machen, denn TCP hat viele Vorteile hinsichtlich der Behandlung von verlorenen Paketen, Stateful Inspection, Filterung auf Quell-IPs, TLS-Handshake, Paketen über 1472 Bytes etc | |||
* Dennoch gibt es auch heute noch Carrier, die UDP nutzen und dabei sogar im INVITE sehr große Pakete per UDP mit Fragmentierung senden | |||
* Hier ein Auszug: | |||
[[Image:Bild19.png|top]] | |||
Das ist ein INVITE von EWE an einen SBC über UDP, mit Fragmentierung, was im Dez 2022 sogar entsprechend dokumentiert war | |||
"Als Netzwerkprotokoll ist für die SIP Kommunikation UDP zu verwenden."SIP Trunk Spezifikation Technische Beschreibung des EWE SIP Trunkbusiness [https://business.ewe.de/dokumente/telekommunikation/04_Broschueren_und_Infomaterial/technische_beschreibung_des_ewe_sip_trunk.pdf https://business.ewe.de/dokumente/telekommunikation/04_Broschueren_und_Infomaterial/technische_beschreibung_des_ewe_sip_trunk.pdf] | |||
Das Problem dabei ist natürlich, dass nicht alle Firewalls oder Loadbalancer problemlos mit UDP-Fragmentierungen umgehen können | |||
* Siehe dazu auch [https://www.msxfaq.de/cloud/azure/azure_fragmentation.htm Azure Fragmentation] | |||
== Weitere Links == | |||
* [https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm Maximum Transmission Unit (MTU)] | |||
* [https://www.msxfaq.de/cloud/azure/azure_fragmentation.htm Azure Fragmentation] | |||
* [https://www.msxfaq.de/cloud/azure/azure_vpn_und_mtu.htm Azure VPN und MTU] | |||
* [https://www.msxfaq.de/netzwerk/ipv6/ds-lite.htm DS-Lite] | |||
* [https://www.msxfaq.de/powershell/psudp.htm PowerShell und UDP] | |||
* [https://www.msxfaq.de/netzwerk/ipv6/index.htm IPv6 im Netzwerk] | |||
* TCP/IP performance tuning for Azure VMs[https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning?WT.mc_id=M365-MVP-6771 https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning] | |||
* Always On VPN and IKEv2 Fragmentation[https://directaccess.richardhicks.com/2019/02/11/always-on-vpn-and-ikev2-fragmentation/ https://directaccess.richardhicks.com/2019/02/11/always-on-vpn-and-ikev2-fragmentation/] | |||
* UDP - Sender/Reciever[https://apps.microsoft.com/store/detail/udp-senderreciever/9NBLGGH52BT0?WT.mc_id=M365-MVP-6771&hl=de-de&gl=de https://apps.microsoft.com/store/detail/udp-senderreciever/9NBLGGH52BT0?hl=de-de&gl=de] | |||
* IP fragmentation[https://en.wikipedia.org/wiki/IP_fragmentation https://en.wikipedia.org/wiki/IP_fragmentation] | |||
* IPv6 fragmentation[https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation] | |||
* Behebung von IPv4-Fragmentierung, MTU-, MSS- und PMTUD-Problemen mit GRE und IPSec [https://www.cisco.com/c/de_de/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html https://www.cisco.com/c/de_de/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html] | |||
* Fragmentation, Truncation, and Timeouts: Are Large DNS Messages Falling to Bits?[https://labs.ripe.net/author/giovane_moura/fragmentation-truncation-and-timeouts-are-large-dns-messages-falling-to-bits/ https://labs.ripe.net/author/giovane_moura/fragmentation-truncation-and-timeouts-are-large-dns-messages-falling-to-bits/] | |||
* IP fragmentation and the DNS — Vulnerable DNS servers[https://blog.apnic.net/2022/09/29/ip-fragmentation-and-the-dns-vulnerable-dns-servers/ https://blog.apnic.net/2022/09/29/ip-fragmentation-and-the-dns-vulnerable-dns-servers/] | |||
* CHANGING THE MTU ON AN AUDIOCODES E-SBC DEVICE [https://www.b4z.co.uk/changing-the-mtu-on-an-audiocodes-e-sbc-device.html https://www.b4z.co.uk/changing-the-mtu-on-an-audiocodes-e-sbc-device.html] | |||
* SIP Trunk Spezifikation Technische Beschreibung des EWE SIP Trunk[https://business.ewe.de/dokumente/telekommunikation/04_Broschueren_und_Infomaterial/technische_beschreibung_des_ewe_sip_trunk.pdf https://business.ewe.de/dokumente/telekommunikation/04_Broschueren_und_Infomaterial/technische_beschreibung_des_ewe_sip_trunk.pdf]"Als Netzwerkprotokoll ist für die SIPKommunikation UDP zu verwenden." | |||
* Change MTU size on a NIC on Windows[https://automatica.com.au/2020/10/change-mtu-size-on-a-nic-on-windows/ https://automatica.com.au/2020/10/change-mtu-size-on-a-nic-on-windows/] | |||
* Changing the MTU size of Intel® Network Adapter[https://www.intel.com/content/www/us/en/support/articles/000038224/ethernet-products/gigabit-ethernet-adapters-up-to-2-5gbe.html https://www.intel.com/content/www/us/en/support/articles/000038224/ethernet-products/gigabit-ethernet-adapters-up-to-2-5gbe.html] | |||
* How 1500 bytes became the MTU of the internet[https://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500 https://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500] | |||
== Anhang == | == Anhang == | ||
=== Siehe auch === | === Siehe auch === | ||
<div style="column-count:2"> | |||
<categorytree hideroot=on mode="categories">IP/Fragmentierung</categorytree> | |||
</div> | |||
---- | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}/}} | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} | ||
=== Links === | === Links === | ||
# [[:Kategorie:IP/Fragmentierung]] | |||
# [[IP/Fragmentierung/IPv4]] | |||
# [[IP/Fragmentierung/IPv6]] | |||
# [[Fragmentierung]] | |||
# [[Path MTU Discovery]] | |||
# [[Maximum Transmission Unit]] | |||
# [[IPv6/Header/Extension]] | |||
==== Weblinks ==== | ==== Weblinks ==== | ||
# https://de.wikipedia.org/wiki/IP-Fragmentierung | # https://de.wikipedia.org/wiki/IP-Fragmentierung | ||
# [https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm Maximum Transmission Unit (MTU)] | |||
[[Kategorie:IP]] | [[Kategorie:IP/Fragmentierung]] | ||
---- | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}/}} | |||
</noinclude> | </noinclude> |
Aktuelle Version vom 28. Juni 2025, 11:14 Uhr
IP/Fragmentierung - Aufteilung eines IP-Datagramms, wenn es größer als die Maximum Transmission Unit der Netzwerkschnittstelle ist
Beschreibung
Fragmentierung von Paketen auf einem Übertragungsnetzwerk, wenn das Paket größer ist als die MTU-Size des Netzwerks oder einer Teilstrecke
- Zielsetzung
Ziel bei der Einführung der Fragmentierung im Internetprotokoll (IP) war es
- die zugrundeliegende Netzwerkstruktur für den Benutzer zu verbergen (OSI-Modell)
- Implementierung des Netzwerkprotokolls Hardware-unabhängig zu gestalten
- Hintergrund
Im einfachsten Fall passt das gesamte IP-Datagramm in einen Datenblock
- Höchste Effizienz
- Maximale Größe eines IP-Datagramms
- 64 kB
- Die maximal mögliche Paketgröße (MTU) ist abhängig von den verwendeten Infrastrukturkomponenten
- Moderne Paket-Switching-Techniken lassen unterschiedliche maximale Paketgrößen zu
- Relevanz
Bereich | Beschreibung |
---|---|
LAN | Router, WLAN |
Sicherheit | Angriffe |
Internet | 2007 machte der fragmentierte Datenverkehr 0,06 % aus, 91 % der IPv4-Pakete hatten das don’t fragment (DF) Bit gesetzt, zuvor wurden 1-2% gemessen |
Arbeitsweise
Sobald der IP-Stack (vgl. auch OSI-Modell oder TCP/IP-Referenzmodell) ein Datenpaket zum Versenden enthält, prüft dieser, ob die Paketgröße eine Aufteilung anhand der für die zu verwendende Netzwerkschnittstelle gegebene MTU notwendig macht
- Ist dies nötig, so teilt dieser das vorhandene Datenpaket in mehrere Datenpakete auf
- Dieser Vorgang wird als Fragmentierung bezeichnet
- Diese Fragmentierung kann sowohl beim ursprünglichen Sender stattfinden oder auch auf Routern, die zwischen Sender und Empfänger liegen
- Wird ein IP-Datagramm fragmentiert, so wird es erst beim Empfänger wieder zusammengesetzt (Ausnahme: ggf. zwischengeschaltete Firewalls, die speziell angewiesen wurden, ein sogenanntes reassembly durchzuführen, bevor die Daten weitergeleitet werden)
Sollte es nötig sein, kann auch ein bereits fragmentiertes Paket weiter fragmentiert werden (etwa bei einem Wechsel der Übertragungstechnik)
Jedes IP-Datagramm, das fragmentiert wurde, erhält einen neuen Header auf Basis des originalen Headers und spezieller aktualisierter Felder
- Der Fragment-Offset (13 bit im IP-Header) wird dabei in 8-Byte-Blöcken angegeben
- Wenn also das erste Datagramm 1000 Byte Nutzdaten enthält, dann ist der Fragment-Offset des zweiten Paketes 125 (= 1000 Byte/8 Byte)
- Somit kann nur das letzte Fragment eine Nutzdaten-Menge haben, die nicht ein Vielfaches von 8 Byte ist
- Weiterhin ist zu beachten, dass der Fragment-Offset bei 0 beginnt (der Eintrag im ersten Fragment) und deswegen der Offset des zweiten Paketes im genannten Beispiel 125 und nicht etwa 126 ist
Bei allen Fragmenten, außer dem letzten, wird das More-Fragments-Flag gesetzt
- Ins Längen-Feld des IP-Headers wird bei allen Fragmenten die Länge des jeweiligen Fragments eingetragen, und für jeden Header wird die IP-Header-Prüfsumme separat berechnet, während der Rest des Headers dem Originalheader vor der Fragmentierung entspricht
Der Empfänger hat nun die Aufgabe, das Original aus den in den Paketheadern vorhandenen Informationen wieder zusammenzusetzen, indem er alle Fragmente mit gleichem IP-Header (mit Ausnahme der für jedes Fragment separaten Information) nimmt und sie anhand ihres Offsets in die richtige Reihenfolge bringt
- Da jedes einzelne Fragment ein eigenständiges Paket darstellt, kann es auch vorkommen, dass diese Einzelteile nicht geordnet ankommen
- Es ist auch möglich, dass einzelne Fragmente verlorengehen oder defekt sind
- Es ist dann Sache des Empfängers, das Paket zu verwerfen und die Daten erneut anzufordern, wodurch eine höhere Netzwerklast entstehen kann
Per Definition kann die IP-Schicht keine Angaben darüber machen, ob ein Paket im Verlauf seiner Übertragung fragmentiert wird oder nicht
- Einzige Ausnahme: Der Sender kann das sogenannte Don’t-Fragment-Flag setzen, welches alle beteiligten Kommunikationssysteme (Router, Gateways und weitere) anweist, keine Fragmentierung vorzunehmen
- Für den Fall, dass eine Fragmentierung doch notwendig wäre, wird das Paket verworfen und dem Sender eine ICMP Fehlermeldung vom Typ 3 (destination unreachable) mit Code 4 (fragmentation required but don’t fragment bit set) gesendet, welche besagt, dass das Ziel für unfragmentierbare Pakete dieser Größe nicht erreichbar sei
Auswirkungen
Obwohl die Zielsetzung eine für höhere Schichten (z. B. TCP/UDP) transparente Implementierung ist, gibt es zwei Punkte, in denen dieses nicht ganz erreicht wird:
- Die Fragmentierung kann großen Einfluss auf den Datendurchsatz haben und beeinflusst diesen im Allgemeinen negativ
- Geht ein fragmentiertes Paket des originalen Paketes verloren, so muss das gesamte Original erneut übertragen werden. IP hat jedoch keine Sicherungs- bzw.ggf.Timeoutmechanismen und ist hierbei auf die Sicherungsfunktionen höherer Schichten wie die des TCP angewiesen
Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden
Wo wird fragmentiert?
Wenn zwei System miteinander per TCP/IP kommunizieren, übertragen Sie Pakete mit Daten
- Einige Pakete tragen nur wenige Inhalte, beispielsweise eine Terminal-Eingabe hat meist nur 1 Zeichen als Payload
- Audio-Übertragungen kommen meist mit 160 Bytes Payload (= 20ms Ton bei 64kbit) aus
- Ein Dateitransfer hingegen überträgt viele Daten und möchte die Bandbreite optimal ausnutzen
Nun gibt es aber auf dem Übertragungsweg verschieden Teilstrecken mit unterschiedlicher Paketgröße
- Das maximale Paket bei Ethernet beträgt normalerweise 1514 Bytes
Wenn man nun die 6 Bytes der Absender-MAC-Adresse, weitere 6 Bytes der Empfänger-MAC-Adresse und 2 Bytes für den Protokolltyp (0x0800 = IP) abzieht, bleiben noch 1500 Bytes Nutzdaten für das eigentliche Protokoll übrig
- Das kann dann natürlich IP, TCP, UDP, ICMP aber auch NetBEUI, IPX o. ä. sein
- Die MTU-Größe wird also von dem Übertragungsmedium der Netzwerkkarte definiert
Sie können die aktuelle MTU Größe abfragen
PS C:\> Get-NetAdapter | ft name,status,linkspeed,mtusize name Status LinkSpeed mtusize ---- ------ --------- ------- Mobilfunk Disconnected 0 bps 1500 WLAN Disconnected 0 bps 1500 LAN Onboard Disconnected 0 bps 1500 Bluetooth-Netzwerkverbindung Disconnected 3 Mbps 1500 LAN USBDock Up 1 Gbps 1500
In der Regel sind es 1500 Bytes, aber das muss nicht sein
- Der darauf aufbauende Protokollstapel muss seine großen Pakete entsprechend zum Versand aufteilen und auf der Gegenseite wieder zusammensetzen.Sie können abweichend auch eine kleinere MTU-Size auf ihrer Netzwerkkarte einstellen
- Einige Treiber erlauben die Konfiguration per GUI in den Netzwerkeigenschaften
Ansonsten geht es auch per NETSH
netsh interface ipv4 set subinterface `Local USBDock` mtu=1472 store=persistent” netsh interface ipv4 show subinterface
- Achtung
- Sie sollten die MTU-Size nicht ohne sehr gute Kenntnisse der Funktion ändern
- Gut gemeinte Tipps die MTU-Size zu verringern, um mit DSL-Verbindungen schneller Ping-Zeiten zu erreichen, sind falsch
- Nur bei Problemen mit dem MTU-Discovery können Sie überlegen die MTU-Size manuell anzupassen
Die Änderung der MTU-Size auf einer Netzwerkkarte beeinflusst sowohl die Sende- als auch Empfangsrichtung
- Sie können damit absichtlich kleinere Pakete erreichen, beispielsweise wenn eine dynamische Anpassung nicht möglich ist
- In dem folgenden Bild ist das die Einstellung am Punkt (1)
Ein Client kann aber nicht wissen, wie groß die Pakete auf dem Übertragungsweg sind
- Gerade der erste Hop der Fritz!Box per DSL, DSLite, Kabel o. ä. sorgt schon dafür, dass an der Position (2) ein 1500 Bytes großes Paket nicht mehr mehr weiter geleitet werden kann
- Der Router hat nun zwei Möglichkeiten damit umzugehen:* Verwerfen und Absender informierenMit einem "ICMP Fragmentation needed" kann der Router ein Paket an den Absender übermitteln, wie groß das Paket maximal sein darf
- Der Sender schnürt dann kleinere Pakete, auch wenn dies bedeutet, dass auch auf den anderen Teilsteckern nicht mehr die maximale Paketgröße ausnutzt wird
- Dieses "Paket zu groß" kann auch auf dem weiteren Verlauf weiter passieren und bei einem Wechsel des Routing auch während einer Verbindung passieren
- Gehen Sie davon aus, dass alle Router im Internet nach dem Schema verfahren
- Router packt selbst umHistorisch gibt es aber auch noch die Option, dass der Router das zu große Paket selbst in kleinere Pakete verpackt und die Gegenseite daraus wieder die originalen Pakete herstellt
- Das belastet aber die Router zusätzlich und muss von beiden Seiten unterstützt werden
- Zudem verschlechtert dies Durchsatz, wen beispielsweise * aus einem 1500er Paket dann ein 1400er + 100er Paket wird
- Auf dem weiteren Weg könnte das Umpacken dann noch mal erforderlich werden
- Die meisten ISPs unterstützen daher dieses Verfahren nicht mehr
Es soll Router geben, die zu große Pakete verwerfen und keine Rückmeldung senden und es soll Firewall-Administratoren geben, die das Protokoll ICMP als Schutz gegen "Ping"-Anfragen blocken und dabei auch die anderen ICMP-Steuernachrichten verlieren.
ICMP zu blocken ist eine schlechte Idee, denn diese Steuerungsnachrichten sind für das Internet und TCP/IP von elementarem Interesse
- Angreifer brauchen keinen PING um ihr Netzwerk zu analysieren
- Dazu reichen auch TCP-Sync-Scans, UPNP Abfragen, ARP-Requests im LAN u.a. "Security by Obscurity" war noch nie ein guter Ansatz
Um solche Probleme zukünftig zu vermeiden, sollten sie zwei Fakten wissen:* IPv6 macht keine FragmentierungBei IPv6 müssen Sie daher "ICMP-Size Exceeded"-Meldungen verarbeiten
- Ein Umpacken ist nicht mehr vorgesehen(Siehe auch IPv6 im Netzwerk und "IPv6 fragmentation" https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation "IPv6 routers never fragment IPv6 packets"
- QUIC - UDP mit TLS statt TCPBei der Übertragung von HTTP over UDP ist die MTU-Size auf 1300 Bytes festgelegt und wird beim ersten Paket gleich mit getestet
MTU anpassen
Dieser Abschnitt passt zwar besser auf die Seite Maximum Transmission Unit (MTU) aber wenn Sie die folgenden Analysen im LAN nachtesten wollen, dann brauchen Sie diese Information
- Mein Ziel ist es, dass ich von PC1 Pakete zu PC2 im gleichen LAN sende
- Da beide im Ethernet sind damit die MTU = 1500 Bytes gleich ist, kann ich das Verhalten schlecht zeigen, denn alles >1500 Bytes lehnt der IP-Stack schon ab
- Daher möchte ich auf der entfernten Seite die MTU-Size reduzieren
- Einige Netzwerkkarten erlauben diese Konfiguration in den erweiterten Eigenschaften:
Ich würde diese hier aber nicht ändern sondern per NETSH auf der Netzwerkkarte des PC2
- Zuerst hole ich mir die Information zur Netzwerkkarte und setze sie dann temporär auf 1400
REM Anzeige der Netzwerkkarte mit ihren Einstellungen Netsh interface ipv4 show interfaces Idx Met MTU State Name --- ---------- ---------- ------------ --------------------------- 1 75 4294967295 connected Loopback Pseudo-Interface 1 28 70 1500 disconnected WLAN 21 25 1500 connected Ethernet REM Setzen der MTU Size netsh interface ipv4 set subinterface "Ethernet" mtu=1400
Nun sollte ein zu großes Paket von PC1 zu PC2 nicht zugestellt oder fragmentiert werden
Wenn Sie Pakete per Wireshark mitschneiden, dann kann es sein, dass die Netzwerkkarte selbst die Pakete fragmentiert und wieder zusammensetzt und Wireshark daher nicht die realen Pakete sieht
Um den Mitschnitt zu optimieren, können sie im gleichen LAN einen CaptureFilter mit "Host <ip der gegenstelle>" eintragen
ICMP Fragmentation
Zuerst sende ich nun keinen "kleinen Ping" mit 1300 Bytes an die Gegenstelle
- Hier ist noch keine Überraschung zu erwarten
- Die Pakete werden mit 1300 Bytes "Payload" gesendet und sind auf dem Kabel 1342 Bytes groß:
ping 192.168.102.183 -l 1300
Die 42 Bytes gehen für den ICMP, IP und Ethernet Frame drauf und auch die Antwort ist einfach zu verstehen
Interessant wird es nun, wenn wir ein größeres Paket versenden
- Bei meinem Sender ist die MTU=1500 eingestellt aber der Empfänger kann zumindest nicht mehr senden
ping 192.168.102.183 -l 1450
Das ausgehende Paket 12 hat nun 1450 Bytes Nutzdaten und ist 1492 Bytes auf dem Kabel
- Eigentlich würde ich nun erwarten, dass die Gegenseite das Paket gar nicht annimmt
- Dem ist aber nicht so, denn ich habe in dem Test nur die ausgehende MTU-Größe reduziert
- Daher kommt die Rückantwort reduziert an
In dem Fall sehen wir nun zwei Antwortpakete der Gegenseite
- Der IP-Stack möchte die 1450 Bytes beantworten aber ist durch die MTU-Begrenzung limitiert
- Also muss er die Pakete aufteilen
- Das erste Paket selbst ist nur indirekt als ICMP-Paket erkennbar
- Wireshark zeigt das fragmentierte IP-Paket als "Protocol=IPv4"
Es ist einfach in "Raw"-IP-Paket mit einer "Identification" und der Information, dass weitere Fragmente kommen
- Der Empfänger wartet also nun auf das weitere Paket, welche die gleiche "Identification" beinhaltet:
Erst jetzt ist die komplette Antwort zurück gekommen
Wireshark ist smart genug, die beiden Pakete 13/14 zusammenzusetzen und in Paket 14 komplett anzuzeigen
- Die Fragmente sehen ist also nicht in der , wenn Sie beispielsweise * eine Filter "ICMP" aktivieren, da die Teil-Fragmente nicht als ICMP-Pakete angesehen werden
Sie können aber im Paket 14 sehen, dass es aus mehreren Fragmenten übertragen wurde:
Sie haben nun gesehen, wie Fragmentation die Pakete aufteilt und wieder zusammensetzt und dies pro Richtung unterschiedlich sein kann
DoNotFragment und Router
Der Test mit einem PC im gleichen Subnetz ist natürlich nur bedingt sinnvoll
- Ich möchte ja mal sehen, was ein Router auf dem Weg macht
- Wenn ich nun ein Paket mit 1500 Bytes versende, dann verlässt dies meinen PC problemlos und der nächste Router kann es so aber nicht über eine DSL-Leitung senden
- Ich kann aber nicht wissen, ob der Router nun selbst das Paket "fragmentiert" oder nicht
- Aber ich kann ihn anweisen, keine Fragmentierung zu nutzen
- Beim Ping ist das Flag "-f" dafür zuständig
C:\> ping www.msxfaq.de -f -l 1500
Ping wird ausgeführt für www.msxfaq.de [178.77.117.98] mit 1500 Bytes Daten: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt
Diese Paket kann ich allerdings nicht in Wireshark finden, denn es verlässt meinen PC gar nicht erst
- Wenn ich eine 1500Byte Payload über ein Interface mit 1500 Bytes MTU-Size senden will, dann lehnt das der IP-Stack schon ab, denn die 1500 Bytes müssen ja noch in ICMP und IP eingepackt werden, denn die MTU-Size bezieht sich auf das Ethernet-Paket ohne die 14 Bytes für MAC-Adressen und Type
- Die maximale Paketgröße ist daher 1500-14 = 1486
- Davon gehen noch mal 20 Byte für den IP-Header und 16 Bytes für ICMP-Header
1512 Kabel -6 SenderMAC -6 EmpfängerMAC -2 Type ========= = 1500 MTU für Daten - 20 für Version, DSCP, Flags, Protocol, Headerchecksumme, SourceIP, DestIP ========= = 1480 - 8 für ICMP Typ, Code, Checksumme, Identifier, Sequence ======== = 1872
Erst wenn wir in dem Fall ein ICMP-Ping-Paket mit 1472 Bytes Payload oder kleiner senden, verlässt es meinen PC
PS C:\> ping 178.77.117.98 -f -l 1472
Ping wird ausgeführt für 178.77.117.98 mit 1472 Bytes Daten: Antwort von 80.66.18.137: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt
Durch das "-f" zeige ich aber an, dass ich keine Fragmentierung möchte
- Im ausgehenden Paket sehen Sie dies in den Flags:
Das Paket kommt nun beim Router an und wenn er es aufgrund der Größe nicht weiterleiten kann aber Fragmentierung auch verboten ist, dann kann er nur mit einem "Fragmentation needed" antworten:
Hinweis: Filtern Sie nicht auf die Zieladresse, denn das "ICMP Destination unreachable" kommt vom Router auf dem Weg
Ich muss mein Paket also um mindestens 8 Bytes kleiner machen damit es den nächsten Hop überspringt
- Mit einem Ping und 1464 Bytes kam das Paket direkt beim Ziel an
PS C:\> ping 178.77.117.98 -f -l 1464 Ping wird ausgeführt für 178.77.117.98 mit 1464 Bytes Daten: Antwort von 178.77.117.98: Bytes=1464 Zeit=15ms TTL=49 Antwort von 178.77.117.98: Bytes=1464 Zeit=15ms TTL=49 Antwort von 178.77.117.98: Bytes=1464 Zeit=15ms TTL=49
Es gibt auf der ganzen Strecke dann kein Teilstück mit einer kleineren MTU, sofern sich alle Router an das "Don't Fragment (DF)" halten
Hinweis:Um DoS und Spoofing-Attacken zu erschweren, antworten Router nicht auf jedes Paket mit einer "ICMP Fragmentation needed"
- Der Client merkt sich diese Information
Das sehen Sie auch beim Ping eines übergroßen Pakets
PS C:\> ping 178.77.117.98 -f -l 1470 -t
Ping wird ausgeführt für 178.77.117.98 mit 1470 Bytes Daten: Antwort von 80.66.18.137: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt
Nur die erste Antwort liefert die Details zum Router
- Sie sollten das "Don't Fragment"-Bit nur setzen, wenn Sie es zwingend benötigen, da dies auch eine Fragmentierung auf ihrem Client unterbindet und ihre Software sich dann selbst drum kümmern muss, die richtige Paketgröße zu schnüren
Fragmentierung mit UDP
Neben ICMP gibt es mit UDP noch ein "verbindungsloses Protokoll", ehe wir uns dann noch TCP anschauen
- Um zu zeigen, wie ein System auf fragmentierte Pakete umstellt, habe ich ein kleines PowerShell-Skript auf Basis von PowerShell und UDP geschrieben, welches immer größere UDP-Pakete sendet
- Der Code eignet sich beispielsweise * um die Durchlässigkeit eines Routers, einer Firewall oder eines Loadbalancers zu verifizieren
param ( [string]$remoteip = "www.msxfaq.de", # IP to send to [int]$remoteudpport=5060, # port to send to [int]$sourceudpport = 0, # SourcePort, maybe empty uses and available port [Parameter(ValueFromPipeline= $True)][int]$size = 100 ) $udpClient = New-Object System.Net.Sockets.Udpclient($sourceudpport) $udpClient.DontFragment=$false Write-host "Sending Paket with $($size) bytes to $($remoteip):$($remoteudpport)" [string]$buffer = ("SendUDP Message by msxfaq").padright($size,"A") $byteBuffer = [System.Text.Encoding]::ASCII.GetBytes($Buffer) $sendbytes = $udpClient.Send($byteBuffer, $byteBuffer.length, $remoteip, $remoteudpport) if ($sendbytes -ne $byteBuffer.length) { write-host "Mismatch bytes" } $udpClient.close()
Diese Skript sendet ohne Flusskontrolle, Drosselung o.ä
- ganz schnell UDP-Pakete mit 1000-1500 Bytes an das angegebene Ziel
- Es wartet nicht auf eine Antwort
- Sie können damit also schon einen kleinen "Sturm" simulieren
Wenn Sie hier beim Capture Filter ein "UDP.port=5060" eintragen, dann sehen Sie nur die UDP-Pakete und nicht die Fragmentierung
Beachten Sie dabei:
Das fragmentierte Paket kommt zuerst und hat nur eine "Identification" mit den Informationen über SourceIP, DesIP und Protokoll=UDP aber keiner Information über UDP-Ports
Das macht es für einen Loadbalancer unmöglich, diese Paket anhand eines "Protokoll" auf eine Regel zu mappen
- Der Loadbalancer müsste die Pakete zwischenspeichern, bis er das letzte Paket bekommt
- Erst das enthält die Information und kann anhand der "Identification" zusammengeführt werden
Hier sehen Sie den Src-Port und Dest-Port aber auch die errechnete Datenlänger (1472 Bytes), obwohl dieses Paket nur 35 Bytes auf dem Kabel groß war
- Wireshark führt fragmentierte Pakete zur Analyse zusammen
Theoretisch könnte ein Angreifer nun ein fragmentiertes Paket durch ein anderes Paket ersetzen
- Daher ist eine zusätzliche Absicherung auf dem Datenlevel per TLS oder SRTP immer ratsam
Für eine Firewall oder Loadbalancer sind das natürlich erschwerte Bedingungen
Genau genommen müsste der Loadbalancer das Fragment puffern, bis das letzte Paket kommt und dann alle entweder defragmentiert weiterleiten oder wieder in der Reihenfolge
- Wenn nun aber ein sehr großes Paket in viele Pakete fragmentiert wird und die auch noch unterschiedliche Wege nehmen und daher noch die Reihenfolge ändern, dann muss der Loadbalancer auch damit umgehen
Das Problem hierbei ist, dass das Zielsystem solche Aufgaben natürlich übernehmen kann aber Router oder Loadbalancer dazwischen durch solche Fragmentieren nicht nur belastet sondern sogar gezielt gestört werden können
- Als Angreifer könnte ich ja gezielt "Fragmente" senden und immer Pakete weglassen, so dass das System auf der anderen Seite überlastet wird
Es macht daher schon Sinn, auf Fragmentierung komplett zu verzichten und IPv6 und QUIC machen das ja auch
UDP mit "DontFragment=$true"
Das gleiche Skripte habe ich auch noch einmal angewiesen, keine Fragmentierung zuzulassen
- Das geht bei der UDP-Klasse ganz einfach durch folgende zusätzliche Zeile nach der Instanzierung des Objekts:
$udpClient = new-Object system.Net.Sockets.Udpclient($sourceudpport) $udpClient.DontFragment=$false
Wenn ich nun Pakete mit aufsteigender Paketgröße sende, dann bricht irgendwann die Übertragung zusammen und ich bekomme eine Meldung von dem Router, bei dem das Paket nicht mehr weiter gesendet wird
- In dem Fall die 8.6.18.137
- Hier kommt der Fehler nun nicht erst bei dem Limit meiner Netzwerkkarte mit 1472Bytes (1514 Ethernet) sondern bei 1466 Bytes
Die Rückantwort ist ein ICMP und kein UDP-Paket
- Beim Wireshark-Filter sollten Sie also beispielsweise "udp.port=5060 or ICMP" nutzen
- Die Source-IP wird zu viele Daten liefern aber ein Filter auf die RemoteIP blende die ICMP-Antworten auch aus, die vom Router unterwegs kommen
- Dass dies eine Statusmeldung für das ausgehende UDP-Paket ist, findet sich dann in der Payload
Dort geht auch, wir groß die MTU, hier 1492) maximal sein darf
- Die ICMP Rückantwort wird vom IP-Stack auch an das UDP-Objekt zurück gegeben
- Ohne entsprechende Fehlerbehandlung sehen Sie den Error direkt in der PowerShell:
Interessant ist hierbei, dass im Gegensatz zu dem ICMP-Ping hier der Router auf jedes Paket eine Meldung sendet und meine IP-Stack oder das UDP-Objekt die Größenüberschreitung nicht cached
Das "do Not Fragment" ist ein IP-Flag und kann genauso mit ICMP und UDP genutzt werden
- Es ist dann in der Verantwortung des Absenders korrekt darauf zu reagieren, beispielsweise: indem es entsprechend kleine Pakete sendet
Beim PING geht das mit dem "-f"-Paramterl
ping -f -l 1500
Interessant ist dazu eine Aussage einer schwedischen Quelle:
3.2.3 IP fragmentation During the year 2000, McCreary et al. [1] observed an increase in the fraction IP packets carrying fragmented traffic from 0.03% to 0.15%
- Indeed, one year later, Shannon et al. [6] reported fractions of fragmented traffic of up to 0.67%
- Contrary to this trend, we found a much smaller fraction of 0.06% of fragmented traffic in the analyzed data. ...3.2.4 IP flags The analysis of the IP flags (fragment bits) revealed that 91.3% of all observed IP packets have the don’t fragment bit (DF) set, as proposed by Path MTU Discovery (RFC 1191). 8.65% use neither DF nor MF (more fragments) and 0.04% set solely the MF bit.Quelle: Analysis of Internet Backbone Traffic and Header Anomalies observed http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf
Es werden also wohl sehr wenige Pakete tatsächlich fragmentiert und die meisten sogar ein "DF"-Flag gesetzt haben
Analysis of Internet Backbone Traffic and Header Anomalies observedhttp://conferences.sigcomm.org/imc/2007/papers/imc91.pdf* Maximum Transmission Unit (MTU) und Fragmentierung
- RFC 1191 Path MTU Discoveryhttps://datatracker.ietf.org/doc/html/rfc1191
- RFC 1981 Path MTU Discovery for IP version 6https://datatracker.ietf.org/doc/html/rfc1981
- Path MTU Discoveryhttps://de.wikipedia.org/wiki/Path_MTU_Discovery
- Path MTU discovery in practicehttps://blog.cloudflare.com/path-mtu-discovery-in-practice/
- Path MTU Discoveryhttps://www.elektronik-kompendium.de/sites/net/2012221.htm
Fragmentierung mit TCP
Heute versuchen System eine Fragmentierung von Paketen vom Anfang an zu vermeiden
- Aufgrund der "TCP-Verbindung" ist das im Gegensatz zu UDP auch pro Session und der eindeutigen 1:1 Beziehung von Sender und Empfänger sinnvoll
- Daher gibt es mit "Path MTU Discovery (PMTUD)" eine Spezifikation, mit der die beiden Endpunkte ermitteln, welche Paketgröße maximal möglich ist
Technisch senden Sie wie auch UDP nun ihre TCP-Pakete mit dem "DH-Flag=1" und werten die ICMP-Meldung "Fragmentation needed" aus
- Das Paket enthält ja die maximale MTU-Size und diese wird vom Sender für alle weiteren Pakete übernommen
- Diese Rückmeldung kann auch mehrfach eintreffen, wenn verschiedene Router hintereinander immer kleinere MTU-Werte nutzen oder das Routing sich ändert
- Insofern verhält sich TCP nicht anders als UDP, nur dass bei UDP die eigene Software sich um zur große Pakete kümmern muss, wenn man DF-Flag=1 nutzt
Allerdings kann es sein, dass Sie mit Wireshark gar nicht die entsprechenden Pakete sehen, denn die Funktion wird immer mehr von "intelligenten Netzwerkkarten" übernommen um die Host-CPU zu entlasten
- Wireshark sieht dann immer erfolgreiche Verbindungen mit bis zu 1514 Bytes
Daher kann es sein, dass die Mitschnitte bei der Analyse in die Irre führen und sie immer nur "fehlerfreie Übertragungen" sehen
- Das gilt natürlich nur für TCP aber nicht für UDP.* Wireshark Wiki: Offloadinghttps://wiki.wireshark.org/CaptureSetup/Offloading
- When is full packet capture NOT full packet capture?https://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html
- Analyzing TCP Segmentation Offload (TSO) with Wiresharkhttps://www.networkdatapedia.com/post/2016/08/11/analyzing-tcp-segmentation-offload-tso-with-wireshark
- Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/information-about-tcp-chimney-offload-rss-netdma-feature
- TCP SYN ACK RES
- TCP Retransmit und SACKNetzwerkgrundlagen für Cloud und LAN
- Wireshark
- Wireshark Wiki: Offloadinghttps://wiki.wireshark.org/CaptureSetup/Offloading
- Path MTU Discoveryhttps://de.wikipedia.org/wiki/Path_MTU_Discovery
- Empfohlene TCP/IP-Einstellungen für WAN-Verbindungen mit einer MTU-Größe von weniger als 576 Bytehttps://support.microsoft.com/de-de/topic/empfohlene-tcp-ip-einstellungen-f%C3%BCr-wan-verbindungen-mit-einer-mtu-gr%C3%B6%C3%9Fe-von-weniger-als-576-byte-2312050e-2a1b-1e89-94a1-b2868afa436f
- RFC 879 The TCP Maximum Segment Size and Related Topicshttps://tools.ietf.org/html/rfc879
- RFC 1191 Path MTU Discoveryhttps://tools.ietf.org/html/rfc1191
- RFC 1981 Path MTU Discovery for IP version 6https://tools.ietf.org/html/rfc1981
- RFC 2923 TCP Problems with Path MTU Discoveryhttps://tools.ietf.org/html/rfc2923
- RFC 4821 Packetization Layer Path MTU Discoveryhttps://tools.ietf.org/html/rfc4821
- Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsechttps://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
IPv6 und Fragmentierung
Bei IPv6 ist es nicht mehr erlaubt, dass ein System auf dem Übertragungsweg die Pakete fragmentiert
- Das, was bei IPv4 noch als Verletzung des OSI-Modells geschimpft wurde, wenn ein IP-Router (OSI-Schicht 3) in den Übertragungsweg (OSI Schicht 2) eingreift, ist bei IPv6 nun empfohlen
IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header")
- However, packetization layers are encouraged to avoid sending messages that will require fragmentationQuelle: RFC 1981 - Path MTU Discovery for IP version 6 - https://tools.ietf.org/html/rfc1981
The Fragment header is used by an IPv6 source to send packets larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery pathIPv6 requires that every link in the internet have an MTU of 576 octets or greater
- On any link that cannot convey a 576-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.Links that have a configurable MTU (for example, PPP links) must be configured to have an MTU of at least 576 octets; it is recommended that a larger MTU be configured, to accommodate possible encapsulations (i.e., tunneling) without incurring fragmentation.Quelle: RFC 1883 Internet Protocol, Version 6 (IPv6) Specification" - https://tools.ietf.org/html/rfc1883
Mit IPv6 kommt bei "Test-Connection" eine MTUSize von 9999 Bytes zustande
PS C:\> Test-Connection fritz.box -MTUSizeDetect -Verbose -IPv6 Source : FC-T480S Destination : fritz.box MTUSize : 9999 Status : Success Address : 2003:ea:a713:2c00:cece:1eff:fe34:3d04 RoundtripTime : 1 Options : Buffer : {97, 98, 99, 100_}
Da scheint noch ein Bug vorzuliegen, denn auch hier ist die echte Paketgröße auf dem Kabel bei 1502 (eigentlich 1500) aber der IP-Stack scheint zu fragmentieren, ohne das Test-Connection davon etwas merkt
- Wireshark zeigt schön die vielen Pakete vom Client zum Server und markiert das finale Paket
Irgendwie macht das dann aber auch Sinn, wenn ein Versuch das Phänomen mit PING nachzuvollziehen liefert einfach die folgende Ausgabe:
C:> ping fritz.box -6 -f
Die Option "-f" wird nur für IPv4 unterstützt
Interessant finde ich dann aber schon, dass Test-Connection durch den IPv6-Stack ausgetrickst und keine Fehlermeldung liefert, dass IPv6-Adressen nicht geprüft werden können.* RFC 1981 - Path MTU Discovery for IP version 6https://tools.ietf.org/html/rfc1981
- RFC 1883 Internet Protocol, Version 6 (IPv6) Specification"https://tools.ietf.org/html/rfc1883
- Path MTU Discoveryhttps://de.wikipedia.org/wiki/Path_MTU_Discovery
SIP mit UDP
Die meisten UDP-Kommunikationen sind Audio/Video-Übertragungen, die von der effektiven Behandlung von Verlusten profitieren
- Immer, wenn ein verlorenes Paket eh nicht mehr nachgesendet werden muss, da es schon obsolet ist, ist UDP gegenüber TCP von Vorteil
- Auch IoT-Geräte können per UDP beispielsweise * Energie spare, wenn Sie einfach ein Paket ein oder mehrfach senden und nicht erst einen TCP/TLS-Handshake aufbauen etc
- Auch DNS-Anfagen sind lange Zeit über UDP erfolgt, weil es eine einfache Kommunikation ist
- Wobei hier auch TCP zum Einsatz kommt, beispielsweise * bei Zonentransfers, DNSSEC oder auch DNSoverHTTP u.a
- Einsatzbereichen
Aber im VoIP-Umfeld wurde lange Zeit auch die Signalisierung per SIP über UDP übertragen
- Heute würde ich das nicht mehr machen, denn TCP hat viele Vorteile hinsichtlich der Behandlung von verlorenen Paketen, Stateful Inspection, Filterung auf Quell-IPs, TLS-Handshake, Paketen über 1472 Bytes etc
- Dennoch gibt es auch heute noch Carrier, die UDP nutzen und dabei sogar im INVITE sehr große Pakete per UDP mit Fragmentierung senden
- Hier ein Auszug:
Das ist ein INVITE von EWE an einen SBC über UDP, mit Fragmentierung, was im Dez 2022 sogar entsprechend dokumentiert war
"Als Netzwerkprotokoll ist für die SIP Kommunikation UDP zu verwenden."SIP Trunk Spezifikation Technische Beschreibung des EWE SIP Trunkbusiness https://business.ewe.de/dokumente/telekommunikation/04_Broschueren_und_Infomaterial/technische_beschreibung_des_ewe_sip_trunk.pdf
Das Problem dabei ist natürlich, dass nicht alle Firewalls oder Loadbalancer problemlos mit UDP-Fragmentierungen umgehen können
- Siehe dazu auch Azure Fragmentation
Weitere Links
- Maximum Transmission Unit (MTU)
- Azure Fragmentation
- Azure VPN und MTU
- DS-Lite
- PowerShell und UDP
- IPv6 im Netzwerk
- TCP/IP performance tuning for Azure VMshttps://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning
- Always On VPN and IKEv2 Fragmentationhttps://directaccess.richardhicks.com/2019/02/11/always-on-vpn-and-ikev2-fragmentation/
- UDP - Sender/Recieverhttps://apps.microsoft.com/store/detail/udp-senderreciever/9NBLGGH52BT0?hl=de-de&gl=de
- IP fragmentationhttps://en.wikipedia.org/wiki/IP_fragmentation
- IPv6 fragmentationhttps://en.wikipedia.org/wiki/IPv6_packet#Fragmentation
- Behebung von IPv4-Fragmentierung, MTU-, MSS- und PMTUD-Problemen mit GRE und IPSec https://www.cisco.com/c/de_de/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
- Fragmentation, Truncation, and Timeouts: Are Large DNS Messages Falling to Bits?https://labs.ripe.net/author/giovane_moura/fragmentation-truncation-and-timeouts-are-large-dns-messages-falling-to-bits/
- IP fragmentation and the DNS — Vulnerable DNS servershttps://blog.apnic.net/2022/09/29/ip-fragmentation-and-the-dns-vulnerable-dns-servers/
- CHANGING THE MTU ON AN AUDIOCODES E-SBC DEVICE https://www.b4z.co.uk/changing-the-mtu-on-an-audiocodes-e-sbc-device.html
- SIP Trunk Spezifikation Technische Beschreibung des EWE SIP Trunkhttps://business.ewe.de/dokumente/telekommunikation/04_Broschueren_und_Infomaterial/technische_beschreibung_des_ewe_sip_trunk.pdf"Als Netzwerkprotokoll ist für die SIPKommunikation UDP zu verwenden."
- Change MTU size on a NIC on Windowshttps://automatica.com.au/2020/10/change-mtu-size-on-a-nic-on-windows/
- Changing the MTU size of Intel® Network Adapterhttps://www.intel.com/content/www/us/en/support/articles/000038224/ethernet-products/gigabit-ethernet-adapters-up-to-2-5gbe.html
- How 1500 bytes became the MTU of the internethttps://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500
Anhang
Siehe auch
Links
- Kategorie:IP/Fragmentierung
- IP/Fragmentierung/IPv4
- IP/Fragmentierung/IPv6
- Fragmentierung
- Path MTU Discovery
- Maximum Transmission Unit
- IPv6/Header/Extension
Weblinks