IPv4/Header: Unterschied zwischen den Versionen
Zeile 76: | Zeile 76: | ||
|} | |} | ||
== Header-Felder == | |||
=== Version === | |||
* Version des IP-Protokolls | |||
* Hier Version 4 | |||
=== Länge === | |||
* Dieses Feld gibt die Länge des IP-Protokoll-Kopfes in 32-Bit-Worten an | |||
* Die minimale Länge beträgt 5 Worte, was auch der Normalfall ist | |||
* Vergrößerung durch Angabe von Optionen | |||
=== Servicetypen === | |||
[[File:ipServicetypes.png|200px]] | |||
Mit den Precedence-Bit (0-2) kann eine Priorität von 0 - 7 angegeben werden | |||
* 1000 Minimize-delay | |||
* 0100 Maximize throughput | |||
* 0010 Maximize reliability | |||
* 0001 Minimize monetary costs | |||
* 0000 Normal service | |||
* Bit 7 ohne Bedeutung (reserviert) | |||
Servicetypen werden nicht von allen Routern unterstützt | |||
Eine spezielle Bedeutung kommt in modernen Implementierungen dem früheren Feld ''Type of Service'' (ToS) im zweiten Oktett des IPv4-Headers zu. | |||
* Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. | |||
* In modernen Implementierungen wird dieses Feld im Zusammenhang mit der ''[[network congestion avoidance]]'' (Vermeidung von Überlastungen) verwendet. | |||
* Das ToS-Feld wurde durch das DS-Feld (''[[DiffServ|differentiated services]]'') ersetzt, dessen erste sechs Bits als ''differentiated services code point'' (DSCP) und dessen letzte beiden Bits als ''[[Explicit Congestion Notification|explicit congestion notification]]'' (ECN) benutzt werden. | |||
=== Paketlänge === | |||
* Die Länge des Paketes in Byte inklusive Protokoll-Kopf | |||
: 16 Bit – Feld (Maximale Paketgröße = 65.535 Byte) | |||
=== Identifikation === | |||
* Eine eindeutige Identifikation (Zähler) | |||
* Diese Kennungen sollten sich nur nach längeren Zeitabständen wiederholen, um nicht mit verspäteten PDU in Konflikt zu kommen. | |||
=== Paketübertragung im Internet === | |||
=== TTL === | |||
; Time To Live | |||
: Anzahl der Router, die ein IP-Datagramm passieren darf | |||
; Problem | |||
* Beim Routen durch vermaschte Netze, können Datagramme/ Fragmente ziellos und unendlich lange kreisen | |||
* Die verbrauchten Ressourcen können ein Netzwerk bis zum Stillstand belasten | |||
; Lösung | |||
* Jeder Knoten (Router) verringert diesen Wert um mindestens 1 | |||
* Hält ein Router ein Paket länger als eine Sekunde, verringert er die TTL um 1 je weitere Sekunde | |||
* Bei Erreichen des Wertes „0“, wird Paket verworfen | |||
=== Sender- und Empfänger-Adressen === | |||
; 32-Bit IP-Adresse (IPv4) | |||
; Unabhängig von der zugrunde liegenden Netztechnologie | |||
* Das Internet-Protokoll definiert also eine rein logische Netztopologie | |||
; Die Vergabe der IP-Adressen | |||
* wird international von der IANA (Internet Assigned Numbers Association) geregelt | |||
* die IANA verteilt die Organisation auf mehrere Unterorganisationen | |||
* Die in Europa zuständige Organisation ist das RIPE (Réseaux IP Européens) | |||
=== DF, MF und Fragmentabstand === | |||
; DF (Don‘t Fragment) | |||
* 0 = May Fragment | |||
* 1 = Don‘t Fragment | |||
; MF (More Fragment) | |||
* 0 = Last Fragment | |||
* 1 = More Fragment | |||
; Fragmentabstand | |||
* Länge relativ zum Beginn des ursprünglichen Datagram | |||
=== Protokoll === | |||
; Nummer des Transportprotokolls | |||
* Legt fest, welches Protokoll für die Weiterverarbeitung auf 03 zuständig ist (demultiplexing) | |||
* gemäß RFC 1700 (Assigned Numbers) | |||
* /etc/protocol | |||
* %SYSTEMROOT%\system32\drivers\etc\protocol | |||
; Ausgewählte IP-Protokollnummern | |||
=== Weitere Felder === | |||
; Prüfsumme | |||
* wird über den gesamten IP Header berechnet | |||
; Berechnung beim Sender | |||
* setze das checksum Feld auf 0 | |||
* XOR über alle 16-bit Worte im Header | |||
* das Ergebnis wird bitweise invertiert und stellt dann den Wert für das checksum Feld dar. | |||
; Check beim Emfänger | |||
* XOR über alle 16-bit Worte im Header (inkl. checksum) | |||
* OK, wenn im Ergebnis alle bits auf 1 stehen | |||
=== Nutzdaten === | |||
* Segmente und Datagramme höherer Protokolle | |||
* Meist TCP oder UDP | |||
=== Optionen === | |||
Erweiterbarkeit des Headers | |||
* Variable Länge (max. 40 Byte) | |||
==== Source Routing ==== | |||
* Liste von Routern, die ein Datagram durchlaufen soll | |||
* Der genommene Weg wird aufgezeichnet (max. 9 Hops) | |||
; loose | |||
Die Angegebenen IP Adressen müssen nicht benachbart sein | |||
; strict | |||
Die Angegebenen IP Adressen müssen benachbart sein | |||
* sonst wird das Paket verworfen und eine ICMP source route failed Nachricht an den Sender geschickt | |||
* Source Routing ist nahezu überall abgeschaltet, da es ein Sicherheitsrisiko darstellt (IP Spoofing) | |||
==== Record Route ==== | |||
Router hängen ihre IP-Adresse an das Optionsfeld an | |||
==== Zeitstempel ==== | |||
IP-Adresse und Zeitpunkt des Durchlaufes werden aufgezeichnet | |||
=== Füllzeichen === | |||
Auffüllen des Wortes auf 32-Bit | |||
== Dokumentation == | == Dokumentation == |
Version vom 10. Dezember 2022, 01:41 Uhr
topic kurze Beschreibung
Beschreibung
Header-Format
Der IPv4-Header ist normalerweise 20 Bytes lang.
- Bei Übertragung auf Basis von Ethernet folgt er dem Ethernet-Typfeld, das für IPv4-Pakete auf 080016 festgelegt ist.
- Auf anderen Übertragungsmedien und Protokollen kann der Header auch der erste Eintrag sein.
IPv4 bietet verschiedene, größtenteils ungenutzte Optionen, die den Header bis auf 60 Bytes (in 4-Byte-Schritten) verlängern können.
- Ohne Optionen ist der IPv4-Header 20 Bytes lang
- Wortlänge 32 Bit (4 Byte)
- Daten im Feld Optionen können den Header auf maximal 60 Bytes (in 32-Bit-Worten) verlängern (selten)
- Im Typfeld des Ethernet-Frames wird für IPv4 080016 eingetragen
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Version | IHL | DSCP | ECN | Gesamtlänge | H e a d e r | |||||||||||||||||||||||||||
Identifikation | Flags | Fragment Offset | ||||||||||||||||||||||||||||||
TTL | Protokoll | Header-Prüfsumme | ||||||||||||||||||||||||||||||
Quell-IP-Adresse | ||||||||||||||||||||||||||||||||
Ziel-IP-Adresse | ||||||||||||||||||||||||||||||||
Optionen | Padding | |||||||||||||||||||||||||||||||
Payload |
Header-Felder
Version
- Version des IP-Protokolls
- Hier Version 4
Länge
- Dieses Feld gibt die Länge des IP-Protokoll-Kopfes in 32-Bit-Worten an
- Die minimale Länge beträgt 5 Worte, was auch der Normalfall ist
- Vergrößerung durch Angabe von Optionen
Servicetypen
Mit den Precedence-Bit (0-2) kann eine Priorität von 0 - 7 angegeben werden
- 1000 Minimize-delay
- 0100 Maximize throughput
- 0010 Maximize reliability
- 0001 Minimize monetary costs
- 0000 Normal service
- Bit 7 ohne Bedeutung (reserviert)
Servicetypen werden nicht von allen Routern unterstützt
Eine spezielle Bedeutung kommt in modernen Implementierungen dem früheren Feld Type of Service (ToS) im zweiten Oktett des IPv4-Headers zu.
- Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter.
- In modernen Implementierungen wird dieses Feld im Zusammenhang mit der network congestion avoidance (Vermeidung von Überlastungen) verwendet.
- Das ToS-Feld wurde durch das DS-Feld (differentiated services) ersetzt, dessen erste sechs Bits als differentiated services code point (DSCP) und dessen letzte beiden Bits als explicit congestion notification (ECN) benutzt werden.
Paketlänge
- Die Länge des Paketes in Byte inklusive Protokoll-Kopf
- 16 Bit – Feld (Maximale Paketgröße = 65.535 Byte)
Identifikation
- Eine eindeutige Identifikation (Zähler)
- Diese Kennungen sollten sich nur nach längeren Zeitabständen wiederholen, um nicht mit verspäteten PDU in Konflikt zu kommen.
Paketübertragung im Internet
TTL
- Time To Live
- Anzahl der Router, die ein IP-Datagramm passieren darf
- Problem
- Beim Routen durch vermaschte Netze, können Datagramme/ Fragmente ziellos und unendlich lange kreisen
- Die verbrauchten Ressourcen können ein Netzwerk bis zum Stillstand belasten
- Lösung
- Jeder Knoten (Router) verringert diesen Wert um mindestens 1
- Hält ein Router ein Paket länger als eine Sekunde, verringert er die TTL um 1 je weitere Sekunde
- Bei Erreichen des Wertes „0“, wird Paket verworfen
Sender- und Empfänger-Adressen
- 32-Bit IP-Adresse (IPv4)
- Unabhängig von der zugrunde liegenden Netztechnologie
- Das Internet-Protokoll definiert also eine rein logische Netztopologie
- Die Vergabe der IP-Adressen
- wird international von der IANA (Internet Assigned Numbers Association) geregelt
- die IANA verteilt die Organisation auf mehrere Unterorganisationen
- Die in Europa zuständige Organisation ist das RIPE (Réseaux IP Européens)
DF, MF und Fragmentabstand
- DF (Don‘t Fragment)
- 0 = May Fragment
- 1 = Don‘t Fragment
- MF (More Fragment)
- 0 = Last Fragment
- 1 = More Fragment
- Fragmentabstand
- Länge relativ zum Beginn des ursprünglichen Datagram
Protokoll
- Nummer des Transportprotokolls
- Legt fest, welches Protokoll für die Weiterverarbeitung auf 03 zuständig ist (demultiplexing)
- gemäß RFC 1700 (Assigned Numbers)
- /etc/protocol
- %SYSTEMROOT%\system32\drivers\etc\protocol
- Ausgewählte IP-Protokollnummern
Weitere Felder
- Prüfsumme
- wird über den gesamten IP Header berechnet
- Berechnung beim Sender
- setze das checksum Feld auf 0
- XOR über alle 16-bit Worte im Header
- das Ergebnis wird bitweise invertiert und stellt dann den Wert für das checksum Feld dar.
- Check beim Emfänger
- XOR über alle 16-bit Worte im Header (inkl. checksum)
- OK, wenn im Ergebnis alle bits auf 1 stehen
Nutzdaten
- Segmente und Datagramme höherer Protokolle
- Meist TCP oder UDP
Optionen
Erweiterbarkeit des Headers
- Variable Länge (max. 40 Byte)
Source Routing
- Liste von Routern, die ein Datagram durchlaufen soll
- Der genommene Weg wird aufgezeichnet (max. 9 Hops)
- loose
Die Angegebenen IP Adressen müssen nicht benachbart sein
- strict
Die Angegebenen IP Adressen müssen benachbart sein
- sonst wird das Paket verworfen und eine ICMP source route failed Nachricht an den Sender geschickt
- Source Routing ist nahezu überall abgeschaltet, da es ein Sicherheitsrisiko darstellt (IP Spoofing)
Record Route
Router hängen ihre IP-Adresse an das Optionsfeld an
Zeitstempel
IP-Adresse und Zeitpunkt des Durchlaufes werden aufgezeichnet
Füllzeichen
Auffüllen des Wortes auf 32-Bit
Dokumentation
RFC
Man-Pages
Info-Pages
Siehe auch
Links
Projekt-Homepage
Weblinks
Einzelnachweise
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5