IPv6/Header/Extension: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 35: | Zeile 35: | ||
== Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen == | == Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen == | ||
; Extension Headers können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen | |||
* Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen | * Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen | ||
* Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der folgenden Tabelle | * Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der folgenden Tabelle |
Version vom 9. Januar 2024, 13:39 Uhr
topic - Kurzbeschreibung
Beschreibung
- IPv6-Erweiterungsheader
Einige der gestrichenen Felder sind manchmal doch noch notwendig
- für diese Fälle sind derzeit 6 Erweiterungsheader definiert
- die benutzt werden um zusätzliche Informationen zu kodieren
- Alle Erweiterungsheader sind optional
- Werden mehrere benutzt müssen sie direkt nach dem Hauptheader erscheinen
Optionen für Teilstrecken
- Dieser Header wird für Informationen benutzt die alle Router auf der Strecke prüfen müssen
- Bisher ist eine Option definiert, die Unterstützung von Jumbogrammen, also Paketen die größer als 64 kByte sind
- Routing
- Mit diesem Header kann eine Route vollständig oder teilweise spezifiziert werden
- Fragmentierung Dieser Header enthält Optionen für die Fragmentierung von Paketen
- Nanu, hatten wir nicht eben gesagt IPv6 fragmentiert nicht? Im Prinzip ja
- Der Quellhost darf Pakete immer noch fragmentieren
- Nur die Router auf der Strecke sind nicht mehr dazu berechtigt
- Authentifikation
- Der Authentifizierungsheader bietet einen Mechanismus, durch den der Empfänger sicher sein kann, das der in der Adresse angegebene Sender auch tatsächlich der ist, der er behauptet zu sein
- Verschlüsselte Sicherheitsdaten
- Dieser Header enthält Informationen über das verwendete Verschlüsselungsverfahren
Optionen für Ziele
- Dieser Header ist für Optionen vorgesehen, die nur vom Zielhost interpretiert werden müssen
- Er wird derzeit nicht benutzt
Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen
- Extension Headers können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen
- Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen
- Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der folgenden Tabelle
- Wie im Next Header Feld verwiesen sind einige Extension Headers und ein Platzhalter definiert
Name | Typ | Größe | Beschreibung | RFCs |
---|---|---|---|---|
Hop-By-Hop Options | 0 | variabel | Optionenvon allen IPv6-Geräten zu beachtenwird z.B. für Jumbograms benutzt | RFC 2460RFC 2675 |
Routing | 43 | variabel | Hier kann der Weg des Paketes durch das Netzwerk beeinflusst werdenwird u.a. für Mobile IPv6 verwendet | RFC 2460RFC 6275RFC 5095 |
Fragment | 44 | 64 Bit | Parameter zur Fragmentierung | RFC 2460 |
Authentication Header (AH) | 51 | variabel | Daten zur Vertraulichkeit (IPsec) | RFC 4302 |
Encapsulating Security Payload (ESP) | 50 | variabel | Daten zur Verschlüsselung (IPsec) | RFC 4303 |
Destination Options | 60 | variabel | Optionennur vom Zielrechner zu beachten | RFC 2460 |
Mobility | 135 | variabel | Daten für Mobile IPv6 | RFC 6275 |
No Next Header | 59 | leer | Platzhalterzeigt Ende eines Header-Stapels an | RFC 2460 |
Verwendung von Extension Headers
Reihenfolge der Extension Header
- IPv6 Header
- Hop-by-Hop Options Header (für Optionen, welche von Routern auf dem Pfad zum endgültigen Empfänger verarbeitet werden müssen)
- Routing Header
- Fragment Header
- Authentication Header
- Encapsulating Security Payload Header
- Destination Options Header (für Optionen, welche vom endgültigen Empfänger des Paketes verarbeitet werden müssen)
- Upper-Layer Header
Extension Headers
- Next-Header
- Alle Extension Headers enthalten ein Next-Header-Feld, in dem
- der nächste Extension Header oder
- das Upper Layer Protocol genannt wird
- Größen immer Vielfache von 64 Bit
- Speicherzugriffe im Router beschleunigen
- die meisten Felder der Kopfdatenbereiche sind auf 64-Bit-Grenzen ausgerichtet
- Keine Prüfsummen
- Es werden keine Prüfsummen über die IP-Kopfdaten berechnet
- im Gegensatz zu IPv4
- Fehlerkorrektur auf Schichten 2 und 4
Format des Hop-by-Hop Options Headers
Format des Routing Headers