3.7    Internetprotokoll

Das Internetprotokoll (IP) stellt für Sie nur die grundlegenden Transportmechanismen bereit, die für die Sendung von Datagrammen über Netzwerkgrenzen hinweg benötigt werden. Das Internetprotokoll arbeitet verbindungslos. Es wird, anders als bei verbindungsorientierten Verfahren, keine Verbindung im technischen Sinne aufgebaut, gesichert und abgebaut. Vielmehr sendet Ihr Rechner die Datagramme auf gut Glück in das Netz, in der Hoffnung, diese mögen ihr Ziel erreichen. Damit haben Sie auch schon eine besondere Stärke des Internetprotokolls kennengelernt. Sie und Ihr Rechner müssen sich nicht um Verbindungswege und dergleichen kümmern. Und Sie werden auch kein »Besetztzeichen« erhalten. Wenn viele Rechner gleichzeitig Daten für ein Ziel senden, geht es einfach langsamer (oder, wenn es einfach zu viel wird, gar nicht mehr).

Es ist durchaus normal, dass die Datagramme nicht in der Reihenfolge ihrer Aussendung am Ziel eintreffen bzw. nicht oder unvollständig ankommen. Das IP-Protokoll verfügt für solche Situationen über keinerlei Mechanismen. Diese sind vielmehr eine OSI-Schicht darüber angesiedelt (im TCP-Protokoll, siehe Kapitel 6, »Datentransport mit TCP und UDP«).

Ihre IP-Pakete reisen mittels der Ethernet-Frames durch das Netz. Die IP-Header stehen vor den TCP- bzw. UDP-Headern, die die Nutzdaten selbst aufnehmen. Details über die Ethernet-Frames finden Sie in Abschnitt 3.2, »Ethernet-Pakete (Ethernet-Frames)«.

Anhand des folgenden Gedankenmodells sehen Sie die Zusammenhänge klarer: Eine Fabrik versendet einen Traktor. Für den Versand wird er in eine Kiste (TCP- oder UDP-»Verpackung«) verpackt. Diese Umverpackung ist aber keine geeignete Transporthülle, also wird die Kiste in einen Container gestellt. Der Container enthält ein Dokument mit der Absender- und Zielangabe (IP-Header). Der Container wird auf einen Eisenbahnwaggon verladen. Der Waggon hat unabhängig von den Angaben auf dem Container die Angabe eines Abgang- und Zielbahnhofs (Ethernet-Frame, Quell- und Ziel-MAC-Adresse). Der Waggon gelangt zum Zielbahnhof, einem Güterverkehrszentrum (Router). Der Container wird vom Waggon abgeladen und anhand des Frachtdokuments auf das nächste Verkehrsmittel geladen, das die Zielrichtung ansteuert. Auf diesem Weg wird der Container sicher noch öfter zwischen den verschiedenen Verkehrsträgern (Ethernet-Frames) umgeladen, bis er schließlich beim Empfänger landet. Dort wird er wieder vom Waggon genommen (Herauslösung aus dem Ethernet-Frame). Der Container wird geöffnet und die Kiste herausgeholt (Herausnahme aus der Transportverpackung, IP-Header). Die Kiste (TCP- oder UDP-Paket) wird geöffnet und schließlich der Traktor (Nutzlast) von ihr befreit.

Dieses Beispiel ist sehr ausführlich, Sie erkennen darin aber den kompletten Grundzug des Datentransports über Netzwerke. Oft wird auf den notwendigen Zusammenhang von Ethernet-Frame und IP-Paket nicht eingegangen (Abbildung 3.6). Wenn Sie nun betrachten, was sich damit alles an »Overhead« zusammenballt, verstehen Sie, was es mit dem Begriff Netzlast auf sich hat. Selbst für ein paar Byte brauchen Sie diesen ganzen Aufwand.

Abbildung 3.6     IP-Paket als Nutzlast des Ethernet-Frames

3.7.1    Der IPv4-Header

Im Header (Abbildung 3.7) finden Sie die Informationen für den Transport von Datagrammen. Je Zeile beträgt die Datenmenge 32 Bit. Die Bedeutung der einzelnen Felder des Headers finden Sie in Tabelle 3.22. Weitere Informationen finden Sie in den RFCs 3168 (Updates 4301, 6040, 8311) und 3260.

Abbildung 3.7     IPv4-Header

Feld	Länge (Bits)	Inhalt
Version	4	IP-Protokollversion (IPv4)
IHL	4	Internet Header Length, Länge des IP-Headers
TOS	8	Type of Service, Angabe zu Priorität und Eigenschaften des Pakets. Dieses Feld wird heute auch für die Angabe des QoS (Quality of Service) verwendet (RFC 3168, 4301, 6040, 8311), wobei nur die ersten 6 Bits benutzt werden: 0 für Best Effort, 40 für Expedited Flow (VoIP-Datenstrom) und 46 für Expedited Forwarding (VoIP-Datenstrom).
Länge	16	Total Length, maximal 64 kByte
Identifikation	16	laufende Nummerierung der Pakete, dient zum Bilden der richtigen Reihenfolge beim Empfänger
Flags	3	Bit 0:  0 (fest) Bit 1:  0:  Fragmentierung erlaubt              1:  Fragmentierung verboten Bit 2:  0:  letztes Fragment, 1: weitere Fragmente folgen Diese Anweisung betrifft Router. Ist die Fragmentierung nicht erlaubt und das Paket größer als die Maximum Transport Unit (MTU), verfällt das Paket. Im IPv4 beträgt die Standardgröße für die Nutzlast 1500 Byte.
Fragment- Offset	13	Positionsangabe für Fragmente
TTL	8	Time to live: Lebensdauer eines Pakets in Sekunden. Der Standardwert beträgt 64. Bei jedem Router, den das Paket durchläuft, vermindert sich der Wert um (mindestens) 1. Router verwerfen ein Paket mit der TTL 0. Dieser Mechanismus verhindert »unzustellbaren Datenmüll« und Nachrichten, die endlos im Internet kreisen.
Protokoll	8	Angabe des Upper Layer Protocols, des eine OSI-Schicht höher liegenden Protokolls Die Werte sind gemäß RFC 3232 in einer Datenbank hinterlegt. Beispiele: 6 = TCP, 17 = UDP, 1 = ICMP
Header- Prüfsumme	16	Prüfsumme (gilt ausschließlich für den Header, nicht für die folgende Nutzlast)
Sender-IP- Adresse	32	IP-Adresse des Absenders
Ziel-IP-Adresse	32	IP-Adresse des Empfängers
Optionen	2	Angaben zu Routing- und Diagnosezwecken
Padding	*	eventuell notwendige Füllbits zum Erreichen der vorgeschriebenen Bitzahl

Tabelle 3.22     Inhalt des IPv4-Headers

3.7.2    Der IPv6-Header

Der IPv6-Header (Abbildung 3.8) unterscheidet sich deutlich vom älteren IPv4-Format. So hat er eine feste Größe von 320 Bit. Weitere Informationen finden in dem erweiterten Kopfdatenbereich ihren Platz, der sich zwischen dem Header und dem Nutzdatenbereich befindet.

Tabelle 3.23 erläutert Ihnen die einzelnen Felder des IPv6-Headers. Einzelheiten zur IPv6-Adresse sind in den RFCs 8200, 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045 und 7112 niedergeschrieben.

Abbildung 3.8     IPv6-Header

Feld	Länge (Bits)	Inhalt
Version	4	IP-Protokollversion (6)
Traffic Class	8	Quality of Service (QoS), Kennzeichnung der Priorität
Flow Label	20	Markieren von Paketen gleicher Verwendung und Behandlung (QoS). Zufallswerte, möglicher Bereich von 00001 bis FFFFF. Pakete ohne Eintrag durch Absender führen alle Bits mit 0. Pakete desselben Flows müssen stets die gleiche Absender- und Empfängeradresse tragen, sonst wird das Flow-Label nicht ausgewertet. Weitere Informationen finden Sie in RFC 6437.
Payload Length	16	Länge der Daten nach dem IPv6-Header (maximal 64 KB; Ausnahme: Jumbogramm nach RFC 2675)
Next Header	8	Angabe des Folgeprotokolls (6 für TCP, 17 für UDP). Die Datenbank finden Sie unter www.iana.org/assignments/protocol-numbers/protocol-numbers.xml.
Hop-Limit	8	Anzahl der maximalen Router-Sprünge (Hops). Wird der Wert überschritten, wird das Paket verworfen, und der Absender erhält eine ICPMv6-Nachricht. Bei jedem Hop vermindert sich der Wert um 1.
Absenderadresse	128	Angabe zwingend
Zieladresse	128	kann auch nur die Adresse des nächsten Hops enthalten

Tabelle 3.23     IPv6-Header