IPv6-Header-Format: Struktur, Felder und Extension Headers

Warum IPv6 den Header änderte#

Der IPv4-Header wuchs über Jahrzehnte organisch. Optionen wurden hinzugefügt, Felder wurden umgewidmet, und am Ende hatte man einen Header mit variabler Länge mit 14 verschiedenen Feldern (einige optional) und einer komplexen Struktur, die Router bei jedem Hop sorgfältig parsen mussten.

IPv6 verfolgte einen anderen Ansatz: feste Länge, vereinfacht und optimiert für schnelles Forwarding. Der Basis-Header ist immer genau 40 Bytes groß, mit 8 klar definierten Feldern. Keine Optionen mit variabler Länge, keine Header-Prüfsumme, keine Fragmentierungsfelder im Haupt-Header.

Das Ergebnis ist ein Header, den Router schneller verarbeiten können, der einfacher in Hardware zu implementieren ist und der Erweiterung ohne Bruch der Rückwärtskompatibilität unterstützt. Das Verständnis des IPv6-Headers bedeutet zu verstehen, warum er so aufgebaut ist und welche Kompromisse die Designer gemacht haben.

Der 40-Byte-Basis-Header#

Jedes IPv6-Paket beginnt mit genau 40 Bytes in diesem Format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Feste Größe. Keine Optionen im Basis-Header. Jeder Router weiß genau, wo sich jedes Feld befindet, ohne zu parsen.

Die acht Felder#

Betrachten wir jedes Feld in der Reihenfolge, in der Router sie typischerweise verarbeiten.

1. Version (4 Bits)#

Immer 6 für IPv6-Pakete. Immer 4 für IPv4-Pakete. So unterscheiden Geräte IPv6 von IPv4 auf der Leitung.

Praktische Auswirkung: Dual-Stack-Systeme schauen zuerst auf diese 4 Bits, um zu bestimmen, wie der Rest des Pakets zu parsen ist.

Version = 6 (binär: 0110)

Einfach, unveränderlich und kritisch für die Protokollidentifikation.

2. Traffic Class (8 Bits)#

Früher in frühen IPv6-Spezifikationen „Priority" genannt, markiert dieses Feld Pakete für Quality of Service (QoS)-Behandlung. Es dient demselben Zweck wie IPv4s Type of Service (ToS) oder Differentiated Services Code Point (DSCP).

Struktur:

• Bits 0-5: DSCP (Differentiated Services Code Point)
• Bits 6-7: ECN (Explicit Congestion Notification)

Häufige DSCP-Werte:

ECN ermöglicht Routern, Überlastung zu signalisieren, ohne Pakete zu verwerfen. Es wird von modernen TCP-Implementierungen für bessere Staukontrolle verwendet.

Beispiel:

Traffic Class = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (Nicht ECN-fähig)

Router, die QoS unterstützen, untersuchen dieses Feld, um Pakete zu priorisieren. VoIP erhält höhere Priorität als Datei-Downloads. Echtzeit-Video erhält bessere Behandlung als E-Mail.

3. Flow Label (20 Bits)#

Eine der interessantesten, aber ungenutzten Funktionen von IPv6. Das Flow Label identifiziert Pakete, die zum selben Flow gehören und identische Routing-Behandlung erhalten sollen.

Zweck:

• Ermöglicht Routern, verwandte Pakete zu identifizieren, ohne Upper-Layer-Header zu untersuchen
• Unterstützt Fast-Path-Forwarding für bekannte Flows
• Bietet einen Handle für Per-Flow-QoS

Spezifikation (RFC 6437):

• Wert 0: Paket ist nicht Teil eines Flows
• Wert 1-0xFFFFF: Flow-Kennung (zufällig von der Quelle gewählt)
• Muss für alle Pakete in einem Flow konsistent sein
• Sollte pseudo-zufällig sein, um Router-Hashing zu ermöglichen

Was einen Flow ausmacht:

• Quelle + Ziel + Flow Label identifiziert ihn eindeutig
• Alle Pakete in einer TCP-Verbindung könnten dasselbe Flow Label verwenden
• Oder jeder Videostream könnte ein eindeutiges Label erhalten

Praktische Verwendung:

Viele Implementierungen setzen Flow Label auf 0, weil:

• Hardware zum Hashen/Forwarden basierend auf Flow Label nicht universell ist
• Anwendungsunterstützung begrenzt ist
• Es optional ist und Null gut funktioniert

Aber richtig verwendet, ermöglicht Flow Label:

• Lastverteilung über ECMP (Equal Cost Multi-Path)-Routen
• Per-Flow-Traffic-Engineering
• Hardware-Fast-Path-Forwarding

Beispiel zum Setzen von Flow Label (Linux):

# Automatische Flow Labels aktivieren
sysctl -w net.ipv6.auto_flowlabels=1
 
# Flow Labels werden basierend auf 5-Tupel-Hash gesetzt

Linux generiert automatisch Flow Labels für TCP-Verbindungen, wenn aktiviert, unter Verwendung eines Hashs von Quell-/Zieladresse und Ports.

4. Payload Length (16 Bits)#

Länge der Paket-Payload in Bytes, ohne den 40-Byte-Basis-Header.

Bereich: 0 bis 65.535 Bytes

Wichtige Details:

• Umfasst Extension Headers (falls vorhanden) plus Upper-Layer-Daten
• Umfasst NICHT den 40-Byte-IPv6-Basis-Header
• Maximalwert 65.535 bedeutet maximale Paketgröße von 65.575 Bytes (65.535 + 40)

Sonderfall: Jumbograms

Für Pakete größer als 65.535 Bytes wird Payload Length auf 0 gesetzt und ein Hop-by-Hop-Extension-Header mit der Jumbogram-Option trägt die tatsächliche Länge (bis zu 4.294.967.295 Bytes).

Jumbograms sind selten. Sie werden auf spezialisierten Hochleistungsnetzwerken mit Jumbo-Frame-Unterstützung verwendet, typischerweise über 10-Gbps+-Links.

Beispiel:

Payload Length = 1440 Bytes
  40-Byte-IPv6-Header (nicht gezählt)
  1440-Byte-Payload (TCP-Header + Daten)
  Gesamtpaket = 1480 Bytes

5. Next Header (8 Bits)#

Identifiziert den Typ des Headers, der unmittelbar auf den IPv6-Header folgt. So werden Extension Headers und Upper-Layer-Protokolle spezifiziert.

Häufige Werte:

Wie Verkettung funktioniert:

Jeder Extension Header enthält sein eigenes Next Header-Feld und bildet eine Kette:

IPv6 Header (Next Header = 0)
  -> Hop-by-Hop Options (Next Header = 43)
    -> Routing Header (Next Header = 6)
      -> TCP Header
        -> Daten

Der empfangende Host verarbeitet Header in Reihenfolge, bis er das Transportprotokoll (TCP/UDP) oder Daten erreicht.

Beispiel ohne Extension Headers:

Next Header = 6 (TCP)
  IPv6-Header direkt gefolgt von TCP-Header

Beispiel mit Extension Headers:

Next Header = 44 (Fragment)
  IPv6-Header gefolgt von Fragment-Header (Next Header = 6)
    Fragment-Header gefolgt von TCP-Header

6. Hop Limit (8 Bits)#

Die Anzahl verbleibender Router-Hops, bevor das Paket verworfen wird. Jeder Router dekrementiert dies um 1. Wenn es 0 erreicht, verwirft der Router das Paket und sendet eine ICMPv6 Time Exceeded-Nachricht.

Bereich: 0-255

Dies ist IPv6s Äquivalent zu IPv4s TTL (Time To Live)-Feld, aber der Name ist genauer — es zählt Hops, nicht Zeit.

Häufige Anfangswerte:

Warum unterschiedliche Werte für Fingerprinting wichtig sind:

Sie können das Quell-OS erraten, indem Sie das Hop Limit in empfangenen Paketen betrachten:

Empfangenes Hop Limit: 56
  56 + 8 Hops = 64 (wahrscheinlich Linux/BSD)
 
Empfangenes Hop Limit: 117
  117 + 11 Hops = 128 (wahrscheinlich Windows)

Traceroute verwendet Hop Limit:

Traceroute funktioniert durch Senden von Paketen mit inkrementierenden Hop Limit-Werten:

• Hop Limit 1: Erster Router antwortet mit Time Exceeded
• Hop Limit 2: Zweiter Router antwortet mit Time Exceeded
• Hop Limit 3: Dritter Router antwortet mit Time Exceeded
• ...bis Ziel erreicht

Sicherheitsüberlegung:

Einige Angriffe verwenden niedrige Hop Limits, um Pakete vor Erreichen von IDS/IPS-Systemen ablaufen zu lassen. Firewalls erzwingen manchmal minimale Hop Limit-Werte für eingehenden Verkehr.

Beispiel:

Hop Limit = 64
  Router 1 empfängt, dekrementiert auf 63, leitet weiter
  Router 2 empfängt, dekrementiert auf 62, leitet weiter
  ...
  Router 64 empfängt, dekrementiert auf 0, verwirft und sendet ICMPv6 Typ 3

7. Source Address (128 Bits)#

Die IPv6-Adresse des Paket-Absenders. Immer 128 Bits, keine Ausnahmen.

Format: Standard-IPv6-Adressnotation

2001:db8:1234:5678:9abc:def0:1234:5678

Besondere Überlegungen:

Die nicht spezifizierte Adresse (::) ist nur in bestimmten Fällen gültig:

• Duplicate Address Detection (DAD)
• DHCP-Anfragen vor Adresszuweisung
• Bestimmte ICMPv6-Nachrichten

Link-Local-Adressen (fe80::/10) sind gültige Quelladressen, aber nur auf dem lokalen Link. Router leiten Pakete mit Link-Local-Quellen nicht weiter.

Multicast-Adressen sind niemals gültige Quelladressen. Ein Paket mit einer Multicast-Quelle sollte sofort verworfen werden.

Praktisches Problem: Quelladressenauswahl

Wenn ein Host mehrere IPv6-Adressen hat (üblich mit SLAAC, DHCPv6 und Privacy Extensions), muss er wählen, welche als Quelle verwendet wird. RFC 6724 definiert den Auswahlalgorithmus und bevorzugt:

1. Gleicher Adressbereich wie Ziel
2. Adressen mit längerem übereinstimmenden Präfix
3. Nicht veraltete Adressen
4. Adressen mit höherer Präferenz

8. Destination Address (128 Bits)#

Die IPv6-Adresse des beabsichtigten Empfängers des Pakets. Wie Source Address, immer 128 Bits.

Format: Standard-IPv6-Adressnotation

2001:4860:4860::8888

Routing-Entscheidung:

Router untersuchen dieses Feld, um zu bestimmen, wohin das Paket weitergeleitet werden soll. Anders als bei IPv4, wo NAT Adressen umschreiben könnte, bleiben IPv6-Zieladressen typischerweise End-to-End unverändert.

Spezielle Adressen:

Loopback (::1) darf niemals in einem Paket auf der Leitung erscheinen. Pakete an ::1 werden intern behandelt.

Multicast-Adressen (ff00::/8) zeigen an, dass das Paket an mehrere Empfänger zugestellt werden soll:

• ff02::1 - Alle Knoten auf lokalem Link
• ff02::2 - Alle Router auf lokalem Link
• ff02::1:ff00:0/104 - Solicited-Node-Multicast (für Neighbor Discovery)

Routing-Header-Modifikation:

Wenn ein Routing-Extension-Header vorhanden ist, könnten Zwischenknoten die Zieladresse unterschiedlich verarbeiten, aber dies ist in modernen Netzwerken aufgrund von Sicherheitsbedenken unüblich.

IPv6 vs IPv4 Header-Vergleich#

Das Verständnis dessen, was sich geändert hat, hilft, die Design-Entscheidungen zu würdigen.

Was entfernt wurde und warum#

Header-Prüfsumme: IPv4-Router berechnen die Prüfsumme bei jedem Hop neu, weil TTL sich ändert. Dies fügt Verarbeitungsoverhead hinzu. IPv6 eliminiert sie, weil:

• Link-Layer (Ethernet) hat seine eigene Prüfsumme
• Transport-Layer (TCP/UDP) hat seine eigene Prüfsumme
• Router müssen Paketintegrität nicht verifizieren — Endpunkte tun es

Header Length-Feld: IPv4 benötigt dies, weil Optionen den Header variabel lang machen. IPv6s fester 40-Byte-Header macht dieses Feld unnötig.

Fragmentierungsfelder: IPv4 erlaubt jedem Router, Pakete zu fragmentieren. IPv6 erfordert, dass die Quelle die Fragmentierung mittels Path MTU Discovery durchführt. Dies verlagert Komplexität auf die Endpunkte und verbessert die Router-Leistung.

Optionen: IPv4-Optionen werden selten verwendet, zwingen Router aber, Header mit variabler Länge zu parsen. IPv6 verschiebt Optionen in Extension Headers und hält den Basis-Header einfach.

Extension Headers erklärt#

Extension Headers sind IPv6s Art, Funktionalität hinzuzufügen, ohne den Basis-Header zu verkomplizieren. Sie erscheinen zwischen dem IPv6-Header und der Transport-Layer (TCP/UDP) und bilden eine Kette.

Wie Extension Headers funktionieren#

Jeder Extension Header enthält ein Next Header-Feld, das auf den nächsten Header in der Kette zeigt:

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

Hosts verarbeiten Extension Headers in Reihenfolge. Router verarbeiten typischerweise nur Hop-by-Hop Options; andere Headers werden nur vom Ziel untersucht.

Standard Extension Headers#

RFC 8200 definiert die empfohlene Reihenfolge, wenn mehrere Extension Headers vorhanden sind:

1. Hop-by-Hop Options (0)
2. Destination Options (für Zwischenziele, wenn Routing-Header vorhanden ist)
3. Routing (43)
4. Fragment (44)
5. Authentication Header (51)
6. Encapsulating Security Payload (50)
7. Destination Options (60) (für Endziel)
8. Upper Layer (TCP=6, UDP=17, ICMPv6=58)

Hop-by-Hop Options Header (Typ 0)#

Trägt Optionen, die von jedem Router entlang des Pfades untersucht werden müssen.

Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Häufige Optionen:

Pad1 und PadN: Padding für Ausrichtung

Router Alert (Typ 5): Sagt Routern, dass sie das Paket genauer untersuchen sollen. Verwendet von Protokollen wie MLD (Multicast Listener Discovery).

Jumbogram (Typ 194): Für Pakete größer als 65.535 Bytes.

Muss der erste sein: Falls vorhanden, müssen Hop-by-Hop Options unmittelbar auf den IPv6-Header folgen. RFC 8200 erfordert diese strikte Reihenfolge.

Sicherheitsbedenken: Viele Router verwerfen Pakete mit Hop-by-Hop-Headern, die sie nicht erkennen, oder drosseln sie stark. In der Praxis ist dieser Extension Header außerhalb spezifischer Protokolle (MLD, Jumbograms) unüblich.

Routing Header (Typ 43)#

Spezifiziert Zwischenknoten, die das Paket besuchen soll, bevor es sein Endziel erreicht.

Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     Type-specific data                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Routing-Typen:

Typ 0 (Veraltet): Ursprüngliches Loose Source Routing. Durch RFC 5095 wegen Sicherheitsproblemen (Verstärkungsangriffe) veraltet.

Typ 2: Verwendet von Mobile IPv6 für Routing zu mobilen Knoten. Begrenzter Anwendungsfall.

Typ 3: Segment Routing Header (SRH) für SRv6. Moderner Anwendungsfall für Traffic Engineering und Service Chaining in Carrier-Netzwerken.

Sicherheit: Typ-0-Routing-Header ermöglichten Angreifern, Pakete durch beliebige Knoten zu routen und Verstärkungsangriffe zu erstellen. Die meisten Netzwerke verwerfen Typ 0. Typ 3 (SRv6) ist sorgfältiger entworfen, wirft aber immer noch Sicherheitsbedenken im öffentlichen Internet auf.

Fragment Header (Typ 44)#

Verwendet, wenn die Quelle ein Paket fragmentiert, das für die Pfad-MTU zu groß ist.

Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Felder:

• Next Header: Protokoll der fragmentierten Daten (TCP, UDP, etc.)
• Fragment Offset: Offset dieses Fragments im ursprünglichen Paket (in 8-Byte-Einheiten)
• M-Flag: More Fragments (1 = mehr kommen, 0 = letztes Fragment)
• Identification: Eindeutige ID für Reassemblierung (gleich für alle Fragmente eines Pakets)

Wie Fragmentierung funktioniert:

1. Quelle versucht, großes Paket zu senden
2. Empfängt ICMPv6 Packet Too Big-Nachricht
3. Fragmentiert Paket in kleinere Stücke
4. Fügt jedem Stück Fragment-Header hinzu
5. Ziel reassembliert basierend auf Identification-Feld

Beispiel:

Ursprüngliches 2000-Byte-Paket, MTU 1280:

Fragment 1:
  IPv6 Header (40 Bytes)
  Fragment Header (8 Bytes) [M=1, Offset=0, ID=12345]
  Daten (1232 Bytes)
  Gesamt: 1280 Bytes
 
Fragment 2:
  IPv6 Header (40 Bytes)
  Fragment Header (8 Bytes) [M=0, Offset=154, ID=12345]
  Daten (768 Bytes)
  Gesamt: 816 Bytes

Minimale MTU: IPv6 erfordert, dass alle Links mindestens 1280 Bytes unterstützen. Quellen können 1280-Byte-Pakete ohne Fragmentierung auf jedem konformen IPv6-Netzwerk senden.

Sicherheitsbedenken: Fragmentierung ermöglicht Angriffe:

• Überlappende Fragmente (Payload vor IDS verschleiern)
• Fragment Floods (Reassemblierungs-Ressourcen erschöpfen)
• Winzige Fragmente (Verarbeitungszeit verschwenden)

Viele Firewalls verwerfen fragmentierte Pakete oder reassemblieren sie vor der Inspektion.

Destination Options Header (Typ 60)#

Trägt Optionen nur für den Zielknoten. Zwischenrouter verarbeiten ihn nicht.

Format: Gleich wie Hop-by-Hop Options, aber nur am Ziel untersucht.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Anwendungsfälle:

• Padding für Ausrichtung
• Anwendungsspezifische Optionen
• Zukünftige Erweiterungen ohne Änderung des Basis-Headers

Kann zweimal in der Header-Kette erscheinen:

1. Vor Routing-Header (von Zwischenzielen verarbeitet)
2. Nach ESP/AH-Headern (vom Endziel verarbeitet)

Authentication Header (Typ 51) und ESP (Typ 50)#

IPsec-Header, die Authentifizierung und Verschlüsselung bieten.

AH (51): Bietet Authentifizierung und Integrität, aber keine Vertraulichkeit. Selten verwendet, weil ESP dasselbe plus Verschlüsselung kann.

ESP (50): Bietet Vertraulichkeit, Authentifizierung und Integrität. Standard für VPNs und verschlüsselte Kommunikation.

IPsec ist ein großes Thema jenseits der Header-Struktur. Kernpunkt: Diese Header sind Teil des IPv6-Designs von Anfang an, anders als IPv4, wo IPsec später hinzugefügt wurde.

Verarbeitung von Extension Headers#

Hosts müssen:

• Alle Extension Headers in Reihenfolge verarbeiten
• Alle Standard-Extension-Headers unterstützen
• Unbekannte Header gemäß Next Header-Wert behandeln

Router typischerweise:

• Untersuchen nur Hop-by-Hop Options
• Leiten andere Extension Headers ohne Verarbeitung weiter
• Können Pakete mit bestimmten Headern aus Sicherheitsgründen drosseln oder verwerfen

Firewall-Überlegungen:

Extension Headers erschweren Firewalls, weil:

• Transport-Header (TCP/UDP) tief im Paket sein könnte
• Gesamte Kette parsen muss, um Ports für Filterung zu finden
• Angreifer Payloads mit komplexen Header-Ketten verschleiern können

Best Practices:

• Extension-Header-Kettenlänge begrenzen
• Pakete mit veralteten Headern verwerfen (Typ-0-Routing)
• Fragmente vor Inspektion reassemblieren
• Pakete mit Hop-by-Hop-Optionen drosseln

Warum keine Prüfsumme?#

IPv4 enthält eine Header-Prüfsumme, die Router bei jedem Hop neu berechnen müssen (weil TTL sich ändert). IPv6 lässt diese bewusst weg.

Begründung:

1. Link-Layer hat bereits Prüfsummen: Ethernet hat CRC32. Wi-Fi hat Prüfsummen. Moderne Link-Layer sind zuverlässig.

2. Transport-Layer-Prüfsummen: TCP und UDP enthalten Prüfsummen, die Daten und Header abdecken. End-to-End-Verifizierung geschieht sowieso.

3. Router-Leistung: Prüfsummen bei jedem Hop neu zu berechnen verschwendet CPU-Zyklen. Hochgeschwindigkeitsrouter leiten Milliarden Pakete pro Sekunde weiter — Prüfsummenberechnung zu eliminieren hilft.

4. Fehler sind selten: Moderne Netzwerke haben niedrige Bit-Fehlerraten. Prüfsummen fangen weniger Fehler als in den 1980ern, als IPv4 entworfen wurde.

Was ist mit Korruption?

Wenn ein Bit in einem IPv6-Header umkippt:

• Falsche Zieladresse: Paket geht an falschen Ort oder wird verworfen, TCP überträgt neu
• Falsches Hop Limit: Paket könnte früh oder spät sterben, marginaler Einfluss
• Falscher Next Header: Ziel kann es nicht parsen, TCP erkennt fehlende Daten und überträgt neu

Das End-to-End-Prinzip besagt, dass Endpunkte Fehler erkennen und behandeln sollten. Zwischenrouter leiten Pakete einfach schnell weiter.

Praktische Auswirkungen#

Für Netzwerk-Ingenieure#

Firewall-Konfiguration:

• Muss Extension-Header-Ketten parsen, um Transport-Header zu finden
• Sollte Kettentiefe begrenzen, um Missbrauch zu verhindern
• Veraltete Header verwerfen (Typ-0-Routing)

Leistungsoptimierung:

• Keine Header-Prüfsumme bedeutet schnelleres Forwarding in Hardware
• Feste Header-Größe ermöglicht besseres Pipelining in Routern
• Extension Headers könnten Slow-Path-Verarbeitung auslösen

Fehlerbehebung:

• tcpdump zeigt alle Header: tcpdump -i eth0 -vv ip6
• Wireshark parst Extension Headers klar
• Nach unerwarteten Extension Headers suchen, die Verwerfungen verursachen

Für Entwickler#

Socket-Programmierung:

• IPv6-Sockets können Extension Headers über Ancillary Data empfangen
• Anwendungen müssen selten manuell Extension Headers konstruieren
• OS behandelt Fragmentierung automatisch

Paket-Konstruktion:

• Traffic Class für QoS-sensitive Anwendungen setzen (VoIP, Video)
• Automatische Flow Label-Generierung für besseren ECMP-Lastausgleich aktivieren
• Nicht annehmen, dass Sie fragmentieren können — PMTUD richtig verwenden

Sicherheit:

• Quelladressen validieren (Multicast-Quellen ablehnen, etc.)
• Fragmentierte Pakete vorsichtig behandeln oder ablehnen
• Bewusst sein, dass Middleboxes Extension Headers verwerfen könnten

Für Systemadministratoren#

MTU-Konfiguration:

• Sicherstellen, dass MTU mindestens 1280 Bytes auf allen Links ist
• Größere MTUs verbessern Leistung (1500 Standard, 9000 für Jumbo Frames)
• ICMPv6 Packet Too Big durch Firewalls erlauben

QoS-Einrichtung:

• Router konfigurieren, um Traffic Class-Markierungen zu respektieren
• Anwendungsverkehr auf geeignete DSCP-Werte mappen
• Überwachen, dass QoS-Richtlinien korrekt funktionieren

IPsec/VPN:

• AH und ESP sind Extension Headers — Firewalls müssen sie erlauben
• IPsec fügt Overhead hinzu — dies in MTU-Berechnungen berücksichtigen
• Transport-Modus vs Tunnel-Modus-Auswirkung auf Header berücksichtigen

Header mit Tools untersuchen#

tcpdump#

IPv6-Header erfassen und anzeigen:

# Basis-IPv6-Paketerfassung
sudo tcpdump -i eth0 -n ip6
 
# Verbose-Ausgabe, die alle Header-Felder zeigt
sudo tcpdump -i eth0 -vv ip6
 
# Nur Pakete mit Extension Headers zeigen
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# Fragmentierte Pakete erfassen
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

Beispiel-Ausgabe:

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
Analyse:
- Quelle: 2001:db8::10, Port 54321
- Ziel: 2001:db8::20, Port 80
- Extension Header: Destination Options (DSTOPT)
- Transport: TCP SYN

Wireshark#

Wireshark bietet detaillierte Header-Analyse:

Filter:

# Aller IPv6-Verkehr
ipv6
 
# Pakete mit spezifischen Extension Headers
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# Fragmentierte Pakete
ipv6.fragment
 
# Spezifische Traffic Class
ipv6.tclass == 46  # Expedited Forwarding

Header-Inspektion:

1. „Internet Protocol Version 6" in Paketdetails erweitern
2. Alle 8 Felder klar beschriftet sehen
3. Extension Headers erscheinen als separate Schichten
4. Rechtsklick auf Felder für Filterung

Scapy (Python)#

IPv6-Pakete programmatisch erstellen und analysieren:

from scapy.all import *
 
# IPv6-Paket erstellen
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# Paketstruktur zeigen
pkt.show()
 
# Ausgabe:
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# Extension Header hinzufügen
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

Häufige Fehlkonfigurationen#

Extension Headers vollständig blockieren#

Problem: Firewall verwirft alle Pakete mit Extension Headers.

Auswirkung:

• Fragmentierung funktioniert nicht (Typ 44 blockiert)
• IPsec-VPNs schlagen fehl (Typen 50/51 blockiert)
• Einiger legitimer Verkehr wird verworfen

Lösung: Notwendige Header erlauben (Fragment, AH, ESP), veraltete blockieren (Typ-0-Routing).

# iptables: Fragmente erlauben, Typ-0-Routing verwerfen
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Traffic Class ignorieren#

Problem: Router ohne QoS konfiguriert, alle Pakete erhalten Best-Effort-Behandlung.

Auswirkung:

• VoIP-Qualität leidet
• Video-Streams puffern
• Zeitkritischer Verkehr konkurriert mit Massenübertragungen

Lösung: QoS-Richtlinien basierend auf Traffic Class/DSCP konfigurieren.

! Cisco IOS-Beispiel
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

MTU-Fehlanpassungen#

Problem: Links mit MTU < 1280 oder Firewalls, die ICMPv6 Packet Too Big blockieren.

Auswirkung:

• Verbindungen hängen
• Große Übertragungen schlagen fehl
• PMTUD funktioniert nicht

Lösung: Minimale 1280-MTU überall sicherstellen, ICMPv6 Typ 2 erlauben.

# MTU setzen
ip link set dev eth0 mtu 1500
 
# Verifizieren
ip -6 link show eth0
 
# Packet Too Big erlauben
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Verwandte Artikel#

• IPv6-Grundlagen - Verstehen Sie grundlegende IPv6-Adressierung und Konzepte, bevor Sie in Header eintauchen.
• ICMPv6 erklärt - Erfahren Sie mehr über ICMPv6, das Next Header-Wert 58 verwendet und kritisch für IPv6 ist.
• IPv6-Firewall-Konfiguration - Konfigurieren Sie Firewalls zur korrekten Handhabung von IPv6-Headern und Extension Headers.

Häufig gestellte Fragen#