IP

Kommentieren Drucken
Teil 34 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Das Internet Protocol (IP) ermöglicht den Transport von Datenpaketen vom Sender über mehrere Netze hinweg bis zum Empfänger. Die Datenpakete bei IP heißen Datagramme. Bei IP gibt es keine Quittierungsmechanismen. IP garantiert deshalb weder eine Datagramm-Reihenfolge noch eine gesicherte Ablieferung der Datagramme beim Empfänger. IP besitzt allerdings die Möglichkeit der Fragmentierung, um große Datagramme auch über Netze transportieren zu können, deren maximal erlaubte Datagramm-Länge kleiner ist.

Sender und Empfänger in TCP/IP Netzen können eineindeutig mit 32-Bit- Adressen gekennzeichnet werden. Eine zentrale Stelle vergibt auf Wunsch kostenlos einen Adressbereich an eine Installation, um somit sicherzustellen, dass Endsysteme immer eindeutig identifizierbar sind. Wer nur ein privates Netz unterhält und keine Kommunikation mit anderen Netzen ermöglicht, kann die Adressierung frei entsprechend seinen eigenen Wünschen gestalten.

Da Netze und Installationen unterschiedlich groß sein können, sieht IP eine Einteilung der Adressen in drei verschiedene Klassen vor:

  • Klasse A: (Groáe Netze) 0-126 nnn.hhh.hhh.hhh
  • Klasse B: (Mittlere Netze 128.1-191.254 nnn.nnn.hhh.hhh
  • Klasse C: (Kleine Netze) 192.1.1-223.254.254 nnn.nnn.nnn.hhh

„n“ bezeichnet dabei das Netzwerk und „h“ den Host innerhalb des Netzwerkes. Einige Adressen sind für besondere Funktionen wie Test-Und-Diagnosemöglichkeiten reserviert.

Ansprechen kann man einen Zielrechner nicht nur über diese Adresse, sondern auch über einen vorher vergebenen Namen. Die Umsetzung des Namens auf die eigentliche Zieladresse wird durch das Name Server Protocol geregelt.

Zur Übergabe der Daten an die nächsthöhere Schicht stehen die beiden Kommandos SEND und RECV zur Verfügung. Mit übergeben werden Parameter wie Adresse, Protokolltyp, Service-Typ etc.). Die Header Information des IP-Datagramms ist im Minimum 20 Zeichen lang.

Obwohl die Diskussion eines Standardprotokolls sonst eher langweilig ist, wollen wir bei IP einigen Dingen genauer nachgehen, zum einen, weil interessante Lösungen enthalten sind, zum anderen, weil das Protokoll für die Benutzung des Internet so immens wichtig ist.

Die ersten Bytes werden vom IP-Header gebildet. Zunächst muss die Versionsnummer angegeben werden, damit sich die empfangende Station darauf einstellen kann. Meistens wird heute die Version 4 benutzt. Man kann mit unterschiedlichen Versionsangaben z. B. verhindern, dass sich verschiedene Protokolle, die im Netz alle IP benutzen, gegenseitig stören.

Danach gibt ein Feld die Länge des Headers an (Internet Header Length IHL) und den Typ des mit diesem Frame geleisteten Dienstes. Die Länge des Headers ist nicht fest, sondern wegen des Optionen Feldes variabel und muss deshalb angegeben werden.

Das „Type of Service“-Feld kann eine Reihe von Qualitäten für den Dienst des IP-Datagramms festlegen. Man kann für Durchsatz, Verzögerung und Zuverlässigkeit jeweils einen Normal- und einen verbesserten Wert annehmen und eine vorrangige Behandlung von Datagrammen verlangen. Die beteiligten Router sind dann entweder dazu in der Lage oder nicht.

Das zweite und dritte Byte dienen der Darstellung der Gesamtlänge des Frames. Ein Frame-Datenfeld kann maximal 65 535 Bytes lang werden. Manche Netze, Protokolle oder Zwischenschalteinrichtungen können diese Länge gar nicht verarbeiten. IP definiert eine Mindestlänge von 576 Bytes. Es kann also durchaus die Notwendigkeit bestehen, IP-Pakete zu fragmentieren und am Ende des Weges wieder zusammenzubauen.

Jedes dabei entstehende Fragment hat natürlich wieder ein ganzes IP-Frame-Format mit eigenem Header. Kurzum: Man erzeugt auf diese Weise nur Overhead.

Wie gesagt, gibt es nur die Send- und Deliver-(Receive-) Primitive. Das Send-Primitiv benutzt die Parameter: Quell-Adresse, Ziel-Adresse, Protokoll, Services-Typ Indicator, „Nicht fragmentieren!“-Indicator, Lebenszeit, Datenlänge, Optionen und Daten. Das Deliver-Primitiv kann auf die Indikatoren und die Lebenszeit verzichten.

Die Quell-Adresse gibt die Internet-Adresse des Senders an, während die Ziel-Adresse die Internet-Adresse des Empfängers beschreibt.

Das Feld „Flags“ dient zur Aufnahme der Kontrollflags für „Don’t Fragment“ und „More Fragment“, welches zur Eingliederung von Fragmenten bei der Reassemblierung benutzt wird.

Das Fragment Offset gibt die Lage der Fragmentdaten relativ zum Anfang des Datenblocks im ursprünglichen unzerlegten Frame als Vielfaches von 8 Bytes an. Maximal sind pro Datagramm 8192 Fragmente möglich. Durch den Fragment Offest kann der Empfänger auch dann ein Datagramm wieder zusammenbauen, wenn die einzelnen Fragmente auf dem Weg vom Sender zum Empfänger etwas durcheinandergeraten sind. Wegen der Identifikation ist es darüber hinaus auch gar nicht schlimm, wenn Fragmente mehrerer Datagramme durcheinander purzeln. Dies geschieht z. B. dann, wenn im Rahmen einer bestehenden Verbindung plötzlich ein dynamisches Re-Routing stattfindet, z. B. weil sich Optimalitätskriterien geändert haben oder weil schlicht eine defekte oder überlastete Leitung umgangen werden soll.

Bei großen Netzen ergab sich schnell das Problem endlos kreisender Uralt-Pakete. Sie können aus den unterschiedlichsten Gründen entstehen, z. B. dann, wenn das Adressierungsschema geändert wurde oder ein Empfänger die Pakete nicht „abgenommen“ sondern zurückgeschickt hat. Wir stellen uns vor, dass eine Teilstrecke zusammenbricht, weil eine Leitung in der Mitte ausfällt. Das dynamische Re-Routing baut einen Ersatzweg auf. Leider muss dieser Weg schon weit vor der eigentlichen Störstelle „abzweigen“. Deshalb nimmt ein Protokoll der höheren Schichten (ab 4) an, dass eine Menge von Daten verlorengegangen ist, und veranlasst den Sender, in seiner Übertragung nochmals zurückzusetzen und früher bereits übertragene Daten, die aber durch das Re-Routing „verschollen“ sind, erneut zu übertragen. Es ist dann denkbar, dass die Router, die zwischen neuem Abzweig und Störstelle liegen, noch die alten Datenpakete gespeichert haben, weil sie sie ja durch die gestörte Leitung nicht mehr losgeworden sind. Wird dann die gestörte Leitung früher als erwartet wieder arbeitsfähig, schicken die Router die Pakete einfach weiter. So kommen dann völlig veraltete Pakete als Doubletten bei den Empfängern an.

Wie auch immer, ein Paket darf in einem modernen Datennetz nicht allzu lange leben. Ist es zu alt, liegt die Annahme nahe, dass sich niemand mehr für dieses Paket interessiert. Das Feld für die maximale Lebenszeit enthält die dem Paket noch verbleibende Restlebenszeit im Netz. Als Einheit werden dafür höchstens 255 Sekunden gegeben. Es gibt aber in den meisten Datennetzen keine einheitliche Uhr für derartige Fragen, besonders bei einem weltumspannenden Netz wie Internet ist dies ein fast unlösbares Designproblem – außerdem benötigen wir auch keine solche Uhr. Wir nehmen einfach an, dass ein Paket in jedem Router eine Sekunde bearbeitet wird und darüber hinaus auf den Leitungen ohne Zeitverlust übertragen werden kann. Ein Paket kann also höchstens 255 Routerdurchläufe überleben. Dann hat es die Nase voll. Diese Zahl war zu Beginn des IP-Designs völlig unproblematisch, stellt aber heute ggf. bei verzweigten großen Netzen einen Engpass dar. Andererseits möchte man in vielen Anwendungen die Lebenszeit, z. B. aus organisatorischen oder Datenschutzgründen, enger beschränken. Dies ist ohne weiteres möglich.

Das Protokoll-Feld definiert das gewünschte höhere Protokoll beim Empfänger, z. B.

  • 1 = ICMP Internet Control Message Protocol,
  • 2 = IGMP Internet Group Management Protocol,
  • 6 = TCP Transmission Control Protocol
  • 8 = EGP Exterior Gateway Protocol
  • 17 = UDP User Datagram Protocol
  • 22 = Xerox Netzwerk Protokoll
  • 29 = ISO Transport-Protokoll Klasse 4
  • 30 = NETBLT Bulk Data Transfer Protocol
  • 83 = Banyan VINES PC-Netz Software
  • 88 = Cisco IGRP

nur als kleine Auswahl.

Die IP-Header Checksum beinhaltet eine Prüfsumme nur für den IP-Header. In jedem Router verändert sich der Header aber, alleine durch die Angabe der Restlebensdauer. Deshalb muss die Checksum jedes Mal neu berechnet werden.

Es gibt des Weiteren eine Reihe von Optionen. So kann man z. B. verlangen, dass Teilnehmer einer Sicherheitsklasse angehören, deren Kennung eingetragen werden muss. Frames können eine Sicherheits-Indikation besitzen, die angibt, zu welcher Sicherheitsstufe sie gehören, z. B. Top Secret. Das IP ist allerdings nicht in der Lage, irgendwelche Sicherheitsfunktionen selbständig durchzuführen. Vielmehr muss dies in den höheren Schichten geschehen. Die Frames bekommen praktisch lediglich eine Bauchbinde. Mit einem Transmission Control Code kann man zusammenhängende Benutzergruppen definieren und auf IP-Ebene zu mindestens bei kooperativen Benutzern und Benutzergruppen durchsetzen. Man kann eine Dokumentation des Weges von der Quelle zum Ziel vornehmen, indem man die Kenndaten der betreffenden Router im entsprechenden Optionenfeld sammelt. Dies ist eine nützliche Funktion bei gelegentlichen Verbindungen oder im Rahmen der Optimierung einer Routing-Strategie. Der sendende Rechner kann eine Adressliste generieren, in der der gewünschte Weg von der Quelle bis zum Ziel durch das Internet beschrieben ist. Er übermittelt diese Daten in einem entsprechenden Feld an den ersten Router. Das Protokoll des Routers sucht sich die nächste Adresse heraus und schickt das Paket entsprechend weiter. Dabei muss der angegebene Router nicht unmittelbar ein direkt mit dem aktuellen Router verbundenes Gerät sein, sondern kann auch am Ende einer Adresskette stehen. Diese Technik nennt man Loose Source Routing. Es ist genauso, als wenn man einem Taxifahrer am Flugplatz sagt: „zum Hilton, aber bei McDonalds vorbei“. Es gibt bei IP auch ein striktes Source Routing, dann muss man den gesamten Weg, so wie er ist, ohne Auslassungen angeben. Umgekehrt kann man auch die durchlaufenen Wege unterschiedlich aufzeichnen, z. B. an markanten Punkten oder den gesamten Weg. Im Rahmen der Optionen kann man auch einen „Stream“ vereinbaren. Normalerweise erhalten die höheren Schichten jedes IP-Datagramm als singuläres Ereignis. Dies entspricht aber in vielen Fällen nicht der Realität, z. B. bei der Übertragung sehr großer Dateien. Dann kann man eine Reihe von Datagrammen auch als zusammengehörig kennzeichnen. Dies ist völlig unabhängig von der Kennzeichnung im Rahmen der Fragmentierung, aber natürlich sinngemäß das gleiche. Allerdings können die meisten höheren Protokolle eine derartige Kennzeichnung selbst vornehmen und benötigen diese Funktion auf der IP-Ebene nicht. Mit dem Internet Timestamp kann der Zeitpunkt festgehalten werden, an dem ein Router ein Datagramm verarbeitet oder weitergibt. Mit Hilfe dieses Timestamps lassen sich z. B. Unregelmäßigkeiten in der Übertragungsdauer feststellen, indem man die Differenz von Timestamps und Paketalter bestimmt. Ein Füllfeld schließlich stellt sicher, dass der IP-Header immer im 32-Bit-Format endet.

Alles, was bis hierher dargestellt wurde, gilt für IP bis Version 4, IPv4. Wegen des enormen Interesses am Internet stellte sich jedoch heraus, dass etwa Mitte 2011 der Adressraum ausgeschöpft sein würde. Daher wurde mit IPv6 eine Erweiterung geschaffen, die nicht nur mit einem wesentlich größeren Adressraum umgehen kann, sondern darüber hinaus auch noch einige weitere Funktionen bietet, die Sicherheit und Komfort der Kommunikation mit TCP/IP steigert. Da es bei ComConsult-Study.tv darüber einige sehr schöne Videos gibt, wollen wir das hier nicht weiter betrachten.

« Teil 33: TCPTeil 35: DC-History (3): Rise of the Internet »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.