IP Fragmentation

Diese Seite beschreibt die Fragmentierung von Paketen auf einem Übertragungsnetzwerk, wenn das Paket größer ist als die MTU-Size des Netzwerks oder einer Teilstrecke. Diese Seite geht aber weiter in die Tiefe als die einfache Beschreibung auf Maximum Transmission Unit (MTU). Auslöser war eine Thematik, die ich auf Azure Fragmentation beschrieben habe.

Wo wird fragmentiert?

Wenn zwei System miteinander per TCP/IP kommunizieren, übertragen Sie Pakete mit Daten. Einige Pakete tragen nur wenige Inhalte, z.B. 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 sehr einfach 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, z.B. 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 informieren
    Mit 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 um
    Historisch 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 z.B. 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:

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 z.B. 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 z.B. 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 z.B. "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, z.B.: 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 observed
http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf

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.

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 fragmentation
Quelle: 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 path

IPv6 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.

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 z.B. 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, z.B. 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