Ip

Aus xinux.net
Zur Navigation springen Zur Suche springen

Wireshark Mitschnitt

Ip-header2.png

Übersicht

Ip-header1.png

Erläuterung für IPv4

Im Folgenden werden die Felder für IPv4 beschrieben.

Version

4 Bit breit. Die IP-Version. Hierbei sind IPv4 und IPv6 zurzeit möglich.

IHL (IP Header Length)

4 Bit breit. Die gesamte Länge des IP-Kopfdatenbereiches wird in Vielfachen von 32 Bit angegeben. Steht hier also eine 5, so ist der Kopfdatenbereich 5 mal 32 Bit gleich 160 Bit oder 20 Byte lang, was auch die Minimallänge für den IP-Kopfdatenbereich ist (das Options-Feld ist optional) und dadurch anzeigt, wo die Nutzdaten beginnen.

n1 bis nx sind Optionen

Gesamtlänge des Headers = (5 · 32) + (Länge(n1) + … + Länge(nx) + Padding auf 32 Bit)

TOS (Type of Service)

8 Bit breit. Das Feld kann für die Priorisierung von IP-Datenpaketen gesetzt und ausgewertet werden (Quality of Service).

Früher (RFC 791) wurden die Bits wie folgt interpretiert:

Bits 0-2:  Precedence.
Bit    3:  0 = Normal Delay,      1 = Low Delay.
Bit    4:  0 = Normal Throughput, 1 = High Throughput.
Bit    5:  0 = Normal Reliability, 1 = High Reliability.
Bits 6-7:  Reserved for Future Use.

Seit Dezember 1998 (RFC 2474) gilt folgende Aufteilung:

Bits 0-5:   DSCP (Differentiated Services Code Point)
Bits 6-7:   CU (Currently unused)

Seit September 2001 (RFC 3168) gilt folgende Aufteilung:

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

Total Length

16 Bit breit. Gibt die Länge des gesamten Pakets (inkl. Kopfdaten) in Byte an. Daraus ergibt sich eine maximale Paketlänge von 65535 Byte (64 KiB). Alle Hosts müssen Datagramme mit einer Länge von mindestens 576 Byte verarbeiten können.

Identification

16 Bit breit. Dieses und die beiden folgenden Felder Flags und Fragment Offset steuern die Reassembly (Zusammensetzen von zuvor fragmentierten IP-Datenpaketen). Eindeutige Kennung eines Datagramms. Anhand dieses Feldes und der 'Source Address' kann der Empfänger die Zusammengehörigkeit von Fragmenten detektieren und sie mit Hilfe des Fragment Offset wieder reassemblieren.

Flags

3 Bit breit. Die Bits haben folgende Bedeutung:

Bit 0
reserviert, muss 0 sein
Bit 1 – DF (Don't Fragment)
Wenn auf 1, zeigt es an, dass das Paket nicht in Fragmente zerlegt (fragmentiert) werden darf
Bit 2 – MF (More Fragments)
Wenn auf 1, zeigt es an, dass weitere Fragmente folgen. Wenn auf 0, ist dieses Paket das letzte (bzw. einzige) Fragment.

Fragment Offset

13 Bit breit. Eine Nummer, die bei fragmentierten Paketen besagt, ab welcher Position innerhalb des Paketes das Daten anfangen. Die Nummerierung hat die "Einheit" 8 Byte Größe. Ein Paket kann daher falls notwendig mehrmals hintereinander in immer kleinere Fragmente zerteilt werden. Das erste Fragment, oder ein nicht fragmentiertes Paket, enthält als Offset den Wert Null. Alle fragmentierte Pakete müssen das More-Fragment-bit gesetzt haben mit Ausnahme des letzten. Ip-header3.png

Fragmenttest7.png


Time to Live (Lebenszeit)

8 Bit breit. Ein Wert, der die Lebensdauer des Pakets angibt. Hat dieses Feld den Wert null, so wird das Paket verworfen. Jede Station (Router) auf dem Weg des Pakets verringert diesen Wert um eins. Dies soll verhindern, dass Pakete ewig weitergeleitet werden (beispielsweise wenn das Paket fälschlicherweise im Kreis geleitet wird und somit das Netz überlasten würde).

Der Standard von 1981 sieht vor, dass jede Station den TTL-Wert um die Anzahl Sekunden verringert, wie lange das Paket an der Station verweilt, mindestens jedoch um eins. Heute wird es de facto als Hop-Count implementiert.

Ttl1.png

Ttl4.png

Protocol

8 Bit breit. Dieses Feld bezeichnet das Protokoll (IP)|Folgeprotokoll, zu dem die im betreffenden IPv4-Paket transportierten Nutzdaten gehören. Enthält das IP-Paket zum Beispiel ein TCP-Paket, steht hier der Wert 6, für ein UDP-Paket 17. Diese Werte werden seit RFC 3232 von der Internet Assigned Numbers Authority|IANA in einer Online-Datenbank für Protokoll-Nummern definiert.

Auswahl

Protokoll Nummer
icmp 1
udp 6
tcp 17
esp 50

Header Checksum

16 Bit breit. Eine Prüfsumme sichert ausschließlich den Kopfdatenbereich. IP selbst hat keine Mechanismen zur Prüfung der Nutzlast auf Korrektheit, dies wird im TCP/IP-Referenzmodell durch die Transportschicht sichergestellt. Dieser Wert wird bei jeder Station neu verifiziert und – weil sich die TTL pro Hop verändert – neu berechnet. Dabei werden alle 16-Bit-Halbwörter des Kopfdatenbereichs nach den Regeln des Einerkomplements addiert (Übertrag auf das LSB addieren) und von der Summe das Einerkomplement gebildet. Das Ergebnis sollte 1111 1111 1111 1111 (Hex: 0xFFFF) sein, denn sonst ist ein Fehler im Header. Vorteil dabei ist, dass sich die Prüfsumme pro Hop nur um eins erhöht. Die Berechnung kann daher schnell in der Hardware ausgeführt werden. Bei einem zuverlässigeren Prüfverfahren wie Zyklische Redundanzprüfung|CRC müsste dagegen die Prüfsumme bei jedem Hop neu berechnet werden. Trotzdem kostet das Prüfen der Prüfsumme verhältnismäßig viel Zeit. Moderne Router überprüfen die Prüfsumme aus Gründen der Verarbeitungsgeschwindigkeit nicht und inkrementieren sie nur. Diese Umstände haben dazu geführt, dass dieses Feld bei IPv6 nicht mehr existiert.

Source Address

32 Bit breit. Enthält die IP-Adresse|Quelladresse des IP-Pakets in network byte order (Byte Order, erstes Byte ist das most significant Byte).

Destination Address

Enthält die IP-Adresse|Zieladresse im gleichen Format wie die Quelladresse.

Options und Padding

Zusatzinformationen für das konkrete Paket. Die Optionen sind nur im Header optional, sie müssen aber von allen IP-Modulen unterstützt werden. Das Format der Optionen ist im RFC 791 beschrieben. Die maximale Anzahl der mit Optionen belegbaren Byte im konkreten Paket ergibt sich aus (IHL*4)-20. Da mit den 4 Bits in IHL ein Wertebereich von 0 bis 15 kodiert wird, können somit bis zu 40 Byte durch Optionen belegt werden. Die einzelnen Optionen selbst können unterschiedliche Länge haben, es gibt sowohl Optionen fester Länge als auch Optionen mit variabler Länge. Da die Gesamtlänge des IP-Headers durch das Feld IHL nur in Vielfachen von 4 Byte festgelegt wird, werden unbenutzte Byte mit Nullen aufgefüllt (Padding).