IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Protokolle - Das IP-Protokoll (IPv4)



Das IP-Protokoll (IPv4)

Das Internet Protocol transportiert Daten von Computer A nach Computer B - es ist eindeutig eines der wichtigsten Protokolle im heutigen Internet. Hier ein detailierter Einblick...


Autor: Martin Puaschitz (onestone)
Datum: 23-01-2002, 19:31:04
Referenzen: Hall, Eric. A - Internet Core Protocols; O'Reily 2000
Schwierigkeit: Fortgeschrittene
Ansichten: 11048x
Rating: 5.5 (8x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



1.1. Geschichtlicher Hintergrund

Das Internet Protokoll ist im Dokument RFC 791 erstmalig veröffentlich worden und wurde als STD 5 (IP ist ein Internet Standard Protokoll) überarbeitet und erneut veröffentlicht. Jegliche Unklarheiten aus RFC 791 wurden mit RFC 1122 (Host Network Requirements) beseitigt. Aus diesem Grund müssen allerdings alle IP-Implementationen sowohl die Bestimmungen von RFC 791 als auch von 1122 beinhalten.

1.2. Wozu also IP?

Das Internet Protokoll ist für nichts anderes verantwortlich, als Daten vom lokalen System entgegenzunehmen und sie über die physikalischen Verbindungen (also den Layer 1 im OSI-Schichtenmodell) in Richtung des Zieles zu leiten. Im großen Gegensatz zu TCP hat IP keine wie immer gearteten Möglichkeiten zu überprüfen ob die Datenpakete, die es gesendet hat, auch wirklich ihr Ziel erreichen. Werden Datenpakete verloren, (durch defekte Kabel oder Geräte) ist es nicht die Aufgabe von IP sich darum zu kümmern. Allerdings ist IP befähigt, die zu sendenden Daten in kleinere Teile zu zerteilen, damit sie auch über verschiedene physikalischen Leitungen gesendet werden können. Dies ist deshalb notwendig, da verschiedene Netzwerkarten und Kabel andere Dateneinheiten für das Senden und Empfangen verwenden.

1.3. IP Datagramme / IP Pakete

Es ist sehr wichtig zwischen IP-Datagrammen und IP-Paketen zu unterscheiden. IP-Datagramme beinhalten die zu sendenden Daten sowie den Header, welcher z.B. Informationen über den Zielort enthält. Wenn also IP von einer Applikation auf dem lokalen Gerät Daten empfängt, die es zu versenden hat, erzeugt IP zuerst einmal die entsprechenden IP-Datagramme. IP-Datagramme werden allerdings nicht als solche über die physikalischen Verbindungen versendet. Hierzu werden Sie in IP-Pakete gepackt, da das Datagramm eventuell fragmentiert werden muss (aufgrund der Netzwerktopologie). Das folgende Beispiel in Grafik 3.1 verdeutlich dies. Ferret möchte vier Kilobyte Daten an Fungi senden. Ferret erstellt nun ein Datagramm, kann dieses aber nicht als solches an Fungi schicken, da für Ethernetverbindungen kleinere Datenpakete benötigt werden. Aus diesem Grund wird das vier Kilobyte große Datagramm in vier kleine IP-Pakete zerteilt und an Fungi gesendet. Sobald die Daten bei Fungi angekommen sind, werden sie wieder zu einem IP-Datagramm zusammengestellt und an die entsprechende Applikation weitergeleitet.


Grafik 3.1

Diese Methode ist besonders wichtig, da IP auf vielen verschiedenen Netzwerktopologien zum Einsatz kommen muss. Nur somit ist gewährleistet, dass verschiedenste Netzwerksysteme gemeinsam arbeiten können. IP erkennt selbständig wie groß die jeweiligen IP-Pakete für den jeweiligen Netzwerktyp sein müssen.

1.4. Lokal- versus Fernauslieferung

Solange zwei Computer an dem gleichen physischen Kabelsegment angeschlossen sind, kann der Sender den Empfänger direkt kontaktieren und ihm die Daten übermitteln. Sobald sich der Empfänger allerdings nicht mehr im selben Segment befindet, (was in großen Netzwerken wie dem Internet gang und gebe ist) muss sich das IP-Paket erst seinen Weg dorthin bahnen. Das Beispiel in Grafik 3.2 soll dies verdeutlichen. Im Header eines jedem IP-Pakets wird die Sender- und Empfänger Adresse gespeichert. Sobald Ferret bemerkt, dass sich Bacteria nicht mehr in seinem lokalen Segment befindet, muss er einen anderen Rechner suchen, der eine physikalische Verbindung zu Bacteria hat. Er findet nun Sasquatsch, welchem er dann auch gleich das entsprechende IP-Paket übermittelt. Nun liegt es im Aufgabenbereich von Sasquatsch, das IP-Paket an Bacteria zu senden. Dies wird im Allgemeinen als Routing bezeichnet. Unser Beispiel war bis jetzt sehr einfach. Im Internet wird ein Paket deutlich öfters weitergeleitet. In der folgenden Grafik 3.3 wird das gleiche Prinzip angewendet wie bisher, nur wird das IP-Paket nun durch fünf verschiedene Netzwerksegmente geschickt.


Grafik 3.2


Graikf 3.2

1.5. Wie findet IP den Weg zu seinem Ziel?

Jede Netzwerkkarte muss eine eigene IP-Adresse erhalten. Bei normalen Computern wird dies in den meisten Fällen auch nur bei einer bleiben. Doch bei großen Servern oder Routern kommen oft mehrere Netzwerkkarten in ein Gerät. Somit hat jede Netzwerkkarte eine einzigartige IP-Adresse. Sobald IP gestartet wird, (was bei den meisten Systemen automatisch geschieht) wird ein sogenannter Routing-table gestartet. Dieser enthält jegliche Daten über Anbindungen an verschiedene Netzwerke über die einzelnen Netzwerkkarten. Hier kann auch festgelegt werden, wohin Daten weitergeleitet werden. In Grafik 3.4 wiederum ein Beispiel.


Grafik 3.4

Unser Senderechner hat eine Netzwerkverbindung und heißt in diesem Fall Putzfrau (ein System aus dem Netz 10.0.1.0). Er ist an den Router Hausmeister (10.0.1.1 und 10.0.100.1) angeschlossen, welcher eine Verbindung in das lokale Netzwerk und eine ins Internet hat. Solange Putzfrau IP-Pakete im lokalen Segment verschickt, kann Hausmeister diese Daten über die Ethernet-Netzwerkkarte schicken. Sobald Putzfrau allerdings Daten außerhalb des Ethernets schicken möchte, muss Hausmeister diese Daten korrekt weiterleiten, und zwar über die andere Netzwerkverbindung. Hier sehen Sie den Routing-table von Hausmeister:

Ziel Netzwerk Interface
127.0.0.0 127.0.0.1 (loopback)
10.0.1.0 10.0.1.1 (Lokaes Ethernet interface)
213.229.11.74 10.0.100.1 (Externes interface)

Natürlich ist auch dieser Routing-table eher einfach. Sobald mehrere Netzwerke auf einem Knotenpunkt zusammenlaufen, wird auch der Routing-table dementsprechend komplex. Dennoch ist das Prinzip das gleiche, bis hin zu den High-End-Super-Routern, die ganze Kontinente in Ihrem Routingbereich haben.

1.6. Unabhängigkeit von Datagrammen

Oft werden Internetverbindungen zwischen zwei Computern mit Telefongesprächen verglichen. Doch das stimmt nur bedingt. Bei einem Telefonat wird eine two-way Verbindung aufgebaut, solange wie das Gespräch dauert. Wenn allerdings ein Datagramm in IP-Pakete zerteilt und gesendet wird, existiert kein einheitlicher Weg, um die Pakete an den Zielrechner zu schicken. Wenn wir z.B. drei Pakete vom Server zu Client schicken wollen, kann es sein, dass ein Paket über eine Satellitenleitung, ein weiteres über normale Kupferdrähte und das letzte über Funkwellenverbindungen geschickt wird. Es ist also egal, welchen Weg sich die IP-Pakete bahnen, sobald sie beim Client ankommen, werden sie zusammengesetzt und es entsteht wieder ein Datagramm.

1.7. Transiente und Semi-Permanente Fehler

Die Unterscheidung dieser zwei Fehlergruppen ist bei IP eine ganz besondere. Transiente Probleme entstehen, wenn ein Gerät ein IP-Paket erhält, und bemerkt, dass etwas damit nicht in Ordnung ist. Das kann zum Beispiel eine falsche Checksumme sein oder ein anderer temporärer Fehler. Sobald dies der Rechner bemerkt, wird das Paket gelöscht ohne eine Nachricht an den ursprünglichen Sender zu übermitteln. Diese Art des Fehlers wird nicht durch einen Fehler des Senders hervorgerufen. Ein Semi-permanentes Problem tritt auf, sobald ein Rechner nicht weiß, was er mit einem IP-Paket tun soll. Das kann zum Beispiel eine fehlende Netzwerkverbindung in Richtung des Zieles dieses speziellen Paketes sein. Dann wird eine ICMP Nachricht verwendet um den Sender zu benachrichtigen, dass dieser Weg nicht zielführend ist. Im Gegensatz zu Transienten Fehlern werden Semi-permanente Fehler durchaus auch vom Sender hervorgerufen. In jedem Fall ist es aber wichtig, diesen zu benachrichten, damit er eine andere Route für die Lieferung des IP-Paketes verwenden kann.

Transiente Fehler werden häufig durch falsch berechnete Checksummen oder durch abgelaufene Time To Live Felder hervorgebracht. Die Checksumme ist jener Teil im IP-Header, welche alle Daten addiert, um zu prüfen, ob das Paket korrupt ist oder nicht – hier können leicht auch Rechenfehler geschehen (die Ausnahme bestätigt die Regel). Der TTL Timer (Time to Live) ist eine Option im IP-Header, welcher festlegt wie viele Rechner bis zum Ziel durchlaufen werden dürfen. Jeder Router oder Rechner subtrahiert hier die Zahl eins, bevor er es weiterleitet. Sobald die Checksumme falsch ist, wird das Paket ohne Warnung gelöscht.

1.8. Fragmentierung und Wiederzusammenstellung

Wie bereits erwähnt, hat jede Netzwerktopologie andere Charakteristiken bezüglich der Datenübertragung. Hier ist für IP vor allem die maximale Transmissionsrate wichtig (MTU = Maximum Transmission Unit). Diese ist in den verschiedenen Netzen jeweils unterschiedlich. Aus diesem Grund werden IP-Segmente in IP-Pakete zerteilt, um sich an die physikalischen Eigenschaften des Netzwerkes anzupassen. Ein Beispiel: Ethernet hat als MTU 1500 Byte in einem einzelnen Paket, ein 16-Megabit Token Ring allerdings kann 17 914 Byte in einem Paket übertragen. Um die Kompatibilität zwischen diesen Netzwerken zu gewährleisten, ist die Fragmentierung von IP besonders wichtig.

Eine wichtige Anmerkung ist die maximale und minimale Größe der MTU. RFC 791 definiert die höchste Schwelle der MTU mit 65 535 und die niedrigste mit 68 Byte. Kein Netzwerk sollte größere oder kleinere Werte als diese verwenden. Hier habe ich eine Tabelle (3.2) mit den gängigsten Netzwerktopologien, die derzeit existieren zusammengestellt. Anhand dieser lässt sich sehr leicht erkennen, welche Unterschiede zwischen den einzelnen Standards existieren.

Topologie MTU (in Bytes) Standardisiert durch
Hyperchannel 65 535 RFC 1374
16 MB/s Token Ring 17 917 IBM
802.4 Token Bus 8 166 RFC 1042
4 MB/s Token Ring 4 464 RFC 1042
FDDI 4 352 RFC 1390
DIX Ethernet 1 500 RFC 894
Point-to-Point (PPP) 1 500 RFC 1548
802.3 Ethernet 1 495 RFC 1042
Serial-Line IP (SLIP) 1 006 RFC 1055
X.25 576 RFC 1356
ARCnet 508 RFC 1051

Tabelle 3.2

Um dieses Beispiel ein wenig leichter darzustellen folgt nun Grafik 3.5.


Grafik 3.5

Hier sehen wir 192.168.40.20, der an einem 4-Megabit Token Ring Netzwerk angebunden ist. Wie wir aus der Tabelle entnehmen können, ist die MTU bei solch einer Topologie 4 464 Byte. Dieser Rechner möchte an 192.168.10.10 Daten verschicken, welcher allerdings nur über Ethernet erreichbar ist. Da das gesamte zu sendende Datagramm in ein IP-Paket hineinpasst, wird auch nur ein großes Paket versendet. Sobald dieses Datagramm auf den Router zwischen dem Token Ring und dem Ethernetnetzwerk trifft, muss der Router das große Paket in vier kleinere Teile zerteilen, da die MTU von Ethernet nur 1 500 Byte groß ist (der mathematische Aspekt wird gleich behandelt). Wenn das originale Paket, 4 464 Byte, fragmentiert wird, werden den Headern der vier neuen 1500-Byte Pakete die gleichen Informationen gegeben, wie sie auch im originalen Header zu finden sind. Die einzige Option, die verändert wird, ist der Fragmentation Identifier. Dieser ist mehr oder weniger eine 16-Bit große Seriennummer, welche von 192.168.40.3 (dem Router) erstellt wird. Diese Nummer dient dazu, damit der Empfänger die fragmentierten Daten von anderen Paketen auseinanderhalten kann. Über das Feld Fragmentation Offset kann der Empfänger feststellen, welcher Reihenfolge die einzelnen Pakete angehören. Dies ist notwendig, um am Ende wieder ein vollständiges IP-Datagramm herzustellen.

Ein weiteres Feld im Header sind die Fragment Flags. Diese Option besteht aus drei Zahlen: Die erste ist für zukünftige Anwendungen reserviert; über die zweite kann dem einzelnen Paket zugewiesen werden, ob es erneut fragmentiert werden darf (0= Erlaubt, 1 = nicht erlaubt). Die dritte Zahl gibt an, ob das derzeitige Paket das letzte in der Reihe der fragmentierten ist (=0) oder ob noch weitere folgen werden (=1).

Ich habe nochmals alle Regeln zusammengefasst, welche für das Fragmentieren von Daten wichtig sind.

- Bei Fragmentation wird nur der reine Datenteil unterteilt.

- Die Header sind nicht in diese Fragmentierung eingebunden. Wenn das originale Datagramm 4 464 Byte lang ist und 20 Byte für den Header verwendet werden, bleiben nur noch 4 444 Byte an Daten übrig, die fragmentiert werden.

- Jedes Fragment wird mit einer eigenen Sender und Empfänger-Adresse ausgestattet. IP muss diesen Zuwachs an Daten (ein Header hat ja 20 Byte an Daten) in die Berechnung bezüglich der maximalen Größe der Pakete einbeziehen.

- Fragmentierte Daten müssen immer ein Vielfaches der Zahl acht sein. Wenn ein Datagramm 256 Byte an Daten beinhaltet, aber nur 250 Byte in ein Paket verpackt werden können, wird ein Paket mit 248 Byte (248 ist die größte, durch acht teilbare Zahl, die unter 256 liegt), und eines mit 8 Byte (256 – 248 = 8) an Daten erstellt.

- Das Fragmentation Offset Feld wird für die korrekte Zuordnung der Reihenfolge der einzelnen Pakete verwendet. Diese Zahl gibt an, welche Daten in einem Paket enthalten sind, indem sie immer die letzte Byte-Zahl angibt.

Die folgenden Abbildungen sollen die gerade genannten Regeln ein wenig verdeutlichen. Die Tabelle 3.3 zeigt den Header des Originalen 4 464 Bytes Paketes:

Fragment Fragment Identifier Reserved Flag May Fragment Flag More Fragment Flags Fragment Offset Paket Lenght
1 321 0 0 0 0 4 464

Tabelle 3.3

Die Grafik 3.6 zeigt, wie das originale Datagramm in vier kleinere Pakete zerlegt wird.


Grafik 3.6

Als Vergleich zum Header des originalen Datagramms, finden Sie in Tabelle 3.4 die Header der einzelnen Pakete.

Fragment Fragment Identifier Reserved Flag May Fragment Flag More Fragment Flags Fragment Offset Paket Lenght
1 321 0 0 1 0 1500
2 321 0 0 1 185 1500
3 321 0 0 1 370 1500
4 321 0 0 0 555 24

Tabelle 3.4

- Fragment Identifier: Es ist leicht zu erkennen, dass alle Fragmente zusammengehören, da der Fragment Identifier bei allen 321 ist.

- Reserved Flag: Ist derzeit deaktiviert und darf nur 0 enthalten.

- May Fragment Flag: Alle Fragmente dürfen auch noch ein weiteres Mal fragmentiert werden, sofern dies notwendig ist, um an das entsprechende Ziel zu gelangen.

- More Fragment Flags: Den ersten drei Fragmenten folgt jeweils ein weiteres, aus diesem Grund, wird dieses Feld auf eins gesetzt. Das letzte Paket setzt dieses Feld auf null, damit dem IP-System klar ist, dass dies das letzte Paket war.

- Fragment Offset: Hier wird angegeben bis zu welchem Teil dieses Paket den Inhalt des originalen Fragmentes beinhaltet.

- Paket Length: Hier ist leicht zu erkennen, dass die ersten drei Pakete gleich groß sind, und nur das letzte deutlich kleiner ist. Dies ist deshalb, da Ethernet (womit der Empfänger angebunden ist) eine MTU von 1500 Bytes verwendet. Da das -dritte Paket nicht 1524 Byte beinhalten darf, muss ein viertes - wenn auch sehr kleines - Paket erstellt werden um die restlichen 24 Byte zu transferieren.

1.9. Routingprioritäten

IP bietet auch die Möglichkeit gewisse Prioritäten zuzuordnen. Damit ist es zum Beispiel möglich, anwenderkritische Daten (Kundendaten, Rechnungen, etc.) schneller an den Empfänger zu bringen als Datentransfers. Diese Unterscheidung liegt bei IP in dem sogenannten TOS Byte. Dies ist ein 8-Bit Feld innerhalb des Headers und beinhaltet ein drei-Bit Feld für prioritization und ein vier-Bit Feld für Quality of Service (die letzte Stelle ist derzeit noch ungenutzt). Es gibt sieben Stufen, welche in den ersten drei Bit festgelegt werden können (sieben hat höchste Priorität). Hierdurch kann eine Unterscheidung der Daten vorgenommen werden. Diese Unterscheidungen können Sie in Tabelle 3.5 leicht erkennen.

Priorität Definition
0 Routine (normal)
1 Prority
2 Immediate
3 Flash
4 Flash Override
5 Critical
6 Internetwork Control
7 Network Control

Tabelle 3.5

Die zweite Möglichkeit, Pakte vor anderen zu bevorzugen, ist das Quality of Service. In der folgenden sind die wichtigsten Werte zu finden. Eine vollständige Liste gibt es unter http://www.isi.edu/).

Wert Dienst Beschreibung
0 Normal Wenn jegliche Optionsfelder bezüglich der Priorität null enthalten, gilt das Paket als normal.
1 Minimize Delay Die Aufgabe dieser Option besteht darin, die Antwortzeiten möglichst gering zu halten. Dies ist z.B. bei einer Terminalemulation wichtig.
2 Maximize Troughput Hier gilt es die IP-Pakete über möglichst schnelle Leitungen zu routen. Eine Anwendung könnte hier z.B. FTP sein, wo der Anwender möglichst schnell Daten herunterladen möchte.
4 Maximize Reliability Durch diese Option ist es möglich, dass IP eine möglichst ausfallsichere Leitung sucht. Dies ist besonders bei Anwendungen wie NSF wichtig.
8 Minimize Cost In der heutigen Zeit ist dies wohl eine ganz besonders wichtige Option. Hier sucht IP immer die günstigste Verbindung zu dem gewünschten Rechner. Eine Paradeanwendung ist hier NNTP.
15 Maxime Security Diese Option ist in RFC 1455 als experimental dargelegt. Hier soll IP immer die sicherste Verbindung wählen, die zur Verfügung steht. Da dies allerdings erst im Experimental-Stadium ist, wird diese Option noch nicht weitläufig unterstützt.


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04506
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06241
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1140
Comments: 0