RFC 791 §3.1 · RFC 1071

📦Der IPv4-Header

Vor jedem IPv4-Paket stehen mindestens 20 Byte Verwaltungsdaten. Ändere Felder und sieh, wie sich Bytes und Prüfsumme sofort mitändern. Klick auf ein Feld erklärt es.

Total Length = 20 + 64 = 84 Byte. Bei ping mit 56 Byte Daten: 20 + 8 (ICMP) + 56 = 84.

Bit 08162431
Header Checksum · 16 Bit — Einerkomplement-Prüfsumme nur über den Header; jeder Router muss sie nach der TTL-Änderung neu berechnen.
Die 20 Byte auf der Leitung (hex)

🧮 Header-Prüfsumme Schritt für Schritt

Der Header wird in zehn 16-Bit-Worte zerlegt; das Prüfsummenfeld zählt dabei als 0000. Addiert wird im Einerkomplement: Ein Übertrag über 16 Bit hinaus wird unten wieder dazugezählt („end-around carry“). Zum Schluss werden alle Bits invertiert (RFC 1071).

Schritt 1/12
4500
Wort 1
0054
Wort 2
4C2A
Wort 3
4000
Wort 4
4001
Wort 5
0000
Prüfs.=0
C000
Wort 7
020A
Wort 8
C633
Wort 9
6414
Wort 10
Summe bisher 0x0000 + Wort 1 0x4500 ───────────────────── Ergebnis 0x4500

Kein Übertrag – die Summe passt noch in 16 Bit.

🧱Fragmentierung

Ist ein Paket größer als die MTU der nächsten Strecke, zerlegt IPv4 es in Fragmente – oder verwirft es, wenn DF gesetzt ist.
#1
20
1.480 B
Offset 0 (= 0 B) · MF=1
#2
20
1.480 B
Offset 185 (= 1.480 B) · MF=1
#3
20
1.020 B
Offset 370 (= 2.960 B) · MF=0

Alle Fragmente tragen dieselbe Identification. Nutzdaten pro Fragment: ⌊(1500 − 20) / 8⌋ × 8 = 1480 Byte. Zusammengesetzt wird erst beim Empfänger.

Path-MTU-Discovery (RFC 1191)
Moderne Systeme setzen bei TCP das DF-Bit. Ist ein Paket zu groß, meldet der Router ICMP Typ 3 Code 4 mit der passenden MTU, und der Sender verkleinert seine Pakete. Werden diese ICMP-Meldungen gefiltert, hängen Verbindungen („PMTU-Blackhole“).
Rechenbeispiel
3.980 Byte Nutzdaten über MTU 1500: 1.480 + 1.480 + 1.020 Byte. Offsets: 0, 185, 370 (× 8 = 0, 1.480, 2.960). Nur das letzte Fragment hat MF = 0.
📚 Quellen