IPv6/Header/Extension: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „== 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üf…“ |
Keine Bearbeitungszusammenfassung |
||
Zeile 127: | Zeile 127: | ||
=== Format des Routing Headers === | === Format des Routing Headers === | ||
[[File:img-025-013.png|700px]] | [[File:img-025-013.png|700px]] | ||
[[Kategorie:IPv6/Header]] |
Version vom 24. Dezember 2023, 15:48 Uhr
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