Das Internet Protokoll Version 4 & Version 6

Seminararbeit , 1999 , 34 Seiten

Informatik - Technische Informatik

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen von Kommunikationsprotokollen
2.1 Kommunikationsprotokolle
2.2 Das OSI Referenzmodell
2.3 Die Vermittlungsschicht
2.4 Der TCP/IP Protokollstapel

3 IP Version 4
3.1 IP Adressierung
3.2 Netzklassen
3.3 Subnetze
3.4 Spezielle Absenderadressen,Loopback- und Broadcast Adressen .
3.5 Das IP Datagramm
3.6 Fragmentierung von IP Datagrammen
3.7 IP Routing
3.7.1 Routing Tabellen

4 Implementierung von IP Version 4 in BSD Unix

5 Output Processing
5.1 Initialisierung und Erstellung des Headers:
5.2 Route Selection
5.3 Source address selection und Fragmentation

6 Input Processing

7 Forwarding

8 Options and Option Processing
8.1 Allgemeines
8.2 Beschreibung der ipdnsertoptions Funktion
8.3 Die Funktion Ip_dooptions
8.4 Die Optionen
8.4.1 Record route option
8.4.2 Source and Record Route Option
8.4.3 Timestamp Option
8.5 Einschränkungen von Optionsverwendung und Option Processing

9 Fragmentation and Reassembly
9.1 Allgemeines
9.2 Zur Fragmentierung
9.2.1 Die Ip-optcopy Funktion
9.3 Reassembly
9.3.1 Die Ip-reass Funktion
9.3.2 Reassembly Timeout
9.3.3 Datagram Identifiers

10 IP Routing L· Routing Tabellen

11 IP Version 6
11.1 Adreßraum
11.2 Der Headeraufbau
11.3 Dienstgüte

12 Zusammenfassung

1 Einleitung

Protokollstapel sind die Software, die in Computernetzwerken die komplette Ab­handlung der Kommunikation zwischen verschiedenen Rechnern übernehmen. Der meist benutzte Protokollstapel ist dabei wegen seiner Exklusivität im Ein­satz im weltweiten Internet der Protokollstapel TCP/IP. Dieser Protokollstapel wird seit den Anfängen des Internets in den 60er Jahren eingesetzt und hat seitdem schon mehrere Revisionen durchgemacht. Das Internet Protokoll (IP) nimmt eine zentralen Position in diesem ca. 20 Einzelprotokolle umfassenden Protokollstapel ein. Ziel der vorliegenden Seminararbeit ist die Beschreibung der Funktionsweise des Internet Protokolls, der Einordnung von IP in die ge­samte Datenkommunikation, und der Vorstellung des aktuell genutzten Internet Protokoll Version 4 und die Erweiterung dieses Protokolls in Version 6.

Um den Rahmen für das Verständnis des Protokolls zu setzen wird im folgenden Kapitel auf die Grundlagen von Kommunikationsprotokollen [4], die Funktionen der Protokollgruppe, zu der das Internet Protokoll gehört, und der Aufbau des TCP/IP Protokollstapels gegeben [1]. Die darauffolgende Vorstellung der Ver­sion 4 des Internet Protokolls gliedert sich in die funktionale Beschreibung des Protokolls und einer Betrachtung von Implementierungsdetails von IP Version 4 am Beispiel von BSD Unix [2]. Die Veränderungen in IP Version 6 im Vergleich zum Vorgänger werden dann in darauf folgenden Kapitel erläutert. Abschließend folgt eine Zusammenfassung der wichtigsten Erkenntnisse dieser Arbeit.

2 Grundlagen von Kommunikationsprotokollen

IP ist eines von vielen existierenden Kommunikationsprotokollen, die Ihre An­wendung in Computernetzwerken finden. Dabei hat jedes Protokoll eine spezielle Funktion, die es von den anderen abgrenzt. Das folgende Kapitel dient daher der Einordnung des IP Protokolls in die Klasse der Kommunikationsprotokolle. Dabei werden die Aufgaben von Kommunikationsprotokollen, deren genereller Aufbau, und der spezielle Aufbau der TCP/IP Protokolle erläutert.

2.1 Kommunikationsprotokolle

Kommunikationsprotokolle dienen dem Austausch von Daten innerhalb von Computernetzwerken. Sie legen die Regeln und Bestimmungen fest, nach denen die Kommunikation zwischen den Stationen abläuft. Dabei sind die Aufgaben der Netzwerkprotokolle recht komplex: Sie reichen der physikalischen Übertra­gung einzelner Bits auf dem gewählten Übertragungsmedium über Fehlererken­nung und -behandlung bis hin zur Ermittlung des besten Kommunikationsweges von Sender zu Empfänger.

Aufgrund dieser Komplexität werden diese Aufgaben nicht von einem einzi­gen Protokoll erledigt, sondern auf verschiedene Protokolle begrenzter Kom­plexität verteilt. Dabei werden Netzwerke in sogenannte Schichten unterteilt, denen jeweils abgeschlossene Aufgabenbereiche zugewiesen werden. Diese Auf­gabenbereiche werden dann durch spezialisierte Protokolle abgedeckt. Gruppen von Protokollen, die zusammen die Aufgaben der Netzwerkkommunikation meh­rerer Schichten abdecken, nennt man Protokollstapel.

2.2 Das OSI Referenzmodell

Verschiedene Hersteller entwickelten zur Lösung ihrer Konmiunikationsproblenie verschiedene Protokollstapel, die aber nicht universell einsetzbar, aber vor allen Dingen nicht untereinander kompatibel waren. Um diesen Inkompatibilitäten ein Ende zu machen wurde von der International Standards Organization (ISO) ein Modell entwickelt, das die Kommunikation offener Systeme beschreibt. Dieses Modell trägt den Namen OSI-(Open Systems Interconnection) Roforonzmodell, und beschreibt die Aufgaben der verschiedenen Kommunikationsschichten. Abb. 1 zeigt die sieben Schichten des OSI-Roforonzmodolls.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Das OSI-Roforonzmodoll

Auch wenn TCP/IP weit vor der Entstehung des OSI-Roforonzmodolls ent­wickelt worden ist, und sich die Protokolle nicht sauber auf die einzelnen Schich­ten dieses Modells übertragen lassen, dient die Beschreibung des Modells dazu, die Gesamtheit der Aufgaben eines Protokollstapels zu erläutern, und eine Auf­teilung der Aufgaben auf verschiedene Schichten zu zeigen. Außerdem deckt sich gerade IP recht gut mit einer einzigen Sicht des OSI-Roforonzmodolls, der Vcr- mittlungsschicht [3].

Das OSI-Roforonzmodoll besteht aus sieben Schichten. Jede Schicht löst die ihm zugeordneten Aufgaben mit einem eigenen Protokoll. Jede Schicht kann dabei mit den Nachbarschichten oberhalb und unterhalb kommunizieren. Die Bitübertragungsschicht beschäftigt sich mit der Übertragung der Rohdaten über einen Kommunikationskanal. Hier wird die Versendung der Bits auf dem physi­kalischen Übcrtragungsmcdium - z.B. einem Kupferkabel, einem Lichtwellenlei- ter, oder einer Funkstrecke - definiert. Für jeden Typ von Übertragungsmedium ist ein spezielles Protokoll notwendig.

Die Aufgabe der Sicherungsschicht ist es, die Rohdaten der Bitübertragungs­schicht an die nächst- höhere Schicht weiterzugeben. Dabei wird eine erste Feh­lererkennung und -behandlung vorgenommen. Weiterhin obliegt dieser Schicht die Steuerung und Kontrolle des Datenflusses, und die Vermeidung einer Über­lastung der Verbindung.

IP ist ein Protokoll, dessen Aufgaben sich im Wesentlichen mit denen der Ver­mittlungssicht des O Sí-Referenzmodells decken. Sie hat die Aufgabe des Be­triebs einer Netz Verbindung zwischen Sender und Empfänger, ggf. über mehrere Zwischenknoten. Wesentliches Merkmal ist dabei die Bestimmung des „optima­len“ Weges zwischen Sender und Empfänger, da in Netzwerken oft eine Vielzahl von Wegen unterschiedlicher Qualität zur Verfügung stehen. Dabei können ver­schiedene Kriterien wie Datendurchsatz, Verzögerung, Kosten, Sicherheit, und Länge eine Aussage über die Qualität eines Weges geben. Weitere Aufgaben sind zusätzliche Fehlererkennung und -behandlung, die Vermeidung von Überlastung durch eine Flußkontrolle, und die Bereitstellung von Abrechnungsfunktionen. Die Transportschicht sorgt für eine sichere Ende-zu-Ende Verbindung zwischen zwei Hosts. Sie kümmert sich um den Verbindungsaufbau, die Übertragung der Daten von der Sitzungsschicht, die Fehlererkennung und -behandlung, und den anschließenden Verbindungsabbau.

Die Sitzungsschicht organisiert und synchronisiert die Verbindung zweier Kom­munikationspartner. Eine Sitzung ist einen Kommunikationsverbindung, ähnlich der Verbindung der Transportschicht, jedoch mit gehobenen Funktionen für die höheren Schichten. Eine der Funktionen ist die Dialogsteuerung, die festlegt, welcher der beiden Partner mit der Informationsübertragung an der Reihe ist. Außerdem bietet die Sitzungssicht das Setzen von Checkpoints innerhalb eines zu übertragenden Datenstroms an. Dadurch kann beim Auftreten eines Fehlers im Datenstrom die Übertragung am letzten vom Empfänger bestätigten Check­point aufgenommen werden, so daß nicht der ganze Datenstrom neu gesendet werden muß.

Die Darstellungsschicht enthält Dienste für Funktionen, die für viele Programme der darüber liegenden Anwendungsschicht nützlich sind, und daher besser ein­mal für alle zugänglich anstatt in jeder Anwendung separat angeboten werden sollten. Ein Beispiel solcher Dienste ist die Kodierung der Daten auf netzweit standardisierte Weise. Dies beinhaltet z.B. die Konvertierung der Daten des Senders dort vorliegenden Format, im Fall von Zeichenketten z.B. ASCII (Ame­rican Standard Code for Information Interchange), in ein netzweites Format, und zurück in das auf dem Zielrechner verwendete Datenformat, z.B. EBCDIC (Extended Binary Coded Decimal Interchange Code), ein von IBM eingeführ­tes Zeichenformat. Weitere Beispiele von Diensten der Darstellungsschicht sind Kompression, Verschlüsselung, und Authentifizierung von Daten [4].

Die Anwendungsschicht stellt nun Protokolle für eine Vielzahl gängiger Aufga­ben bereit, die der Anwender an ein Netzwerk steift. Dazu gehören Dateitransfer, Email, globales Filemanagement, virtuelle Netzwerkterminals, und Verzeichnis­abfragen. Auch verteilte Anwendungen, die über ein Netzwerkprotokoll mitein­ander kommunizieren, werden zu dieser Schicht gezählt.

Das O Sí-Referenzmodell zeigt also, daß bei der Netzwerkkommunikation ver­schiedene Aufgaben beim Senden und Empfangen von Nachrichten anfallen. Die verschiedenen Aufgaben können dann gruppiert in verschiedene Schichten angeordnet werden. Dabei zeigt das Referenzmodell eine mögliche Gruppierung der Aufgaben an, die von Netzwerkprotokollen übernommen werden.

2.3 Die Vermittlungsschicht

Von besonderem Interesse für diese Seminararbeit ist die Vermittlungsschicht, da sich das IP Protokoll dort ansiedeln läßt. Die Vermittlungsschicht bekommt Daten von der Transportschicht geliefert. Diese Daten müssen geeignet adres­siert werden, und dann zum Empfänger auf den Weg gebracht werden. Dabei muß die Vermittlungsschicht eine möglichst optimale Route ermitteln, mögli­cherweise auch über mehrere heterogene Netzwerke hinweg. Die Qualität einer Route kann durch verschiedene Parameter bestimmt sein, z.B. Datendurchsatz, Verzögerung, Kosten, Sicherheit und Länge.

Beim Transport der Daten kommen folgende Vermittlungstechniken in Frage: Leitungsvermittlung, Nachrichtenvermittlung und Packetvermittlung. Bei der Leitungsvermittlung wird ein fester Weg zwischen den Kommunikationspart­nern festgelegt, den die Daten nehmen. Bei der Nachrichten Vermittlung werden die Daten in Packete zerteilt, die dann jeweils ihren eigenen Weg entlang des Netzes gehen. Die Packetvermittlung arbeitet wie die Nachrichtenvermittlung mit dem Zusatz, daß die Packete alle die gleiche Größe haben.

Bei Vermittlungsprotokollen unterscheidet man zwischen verbindungsorientier­ten und verbindungslosen Diensten. Ein verbindungsorientierter Dienst erzwingt zuerst den Verbindungsaufbau, d.h. legt die Route aller Datenpackete zu Be­ginn der Verbindung fest, während bei einem verbindungslosem Dienst für jedes Datenpacket der Weg neu bestimmt wird. IP gehört zu den verbindungslosen Diensten.

Die Vermittlungsschicht kann entweder als sicherer oder unsicherer Dienst auf­gebaut werden: Ein sicherer Dienst garantiert das Ankommen der von der Trans­portschicht gelieferten Daten, während bei einem unsicheren Dienst Daten ver­loren gehen können, und es Sache einer der höheren Sichten ist, fehlende Daten zu erkennen und eventuell neu zu senden. IP ist als unsicherer Dienst imple­mentiert, die Protokolle auf der Transportschicht sorgen hier für die nötige Feh­lerbehandlung.

Die wesentliche Aufgabe der Vermittlungsschicht ist die Leitwegbestimmung, das Routing der Pakete durch das Netzwerk. In einem dichten Netzwerk ist die­se Aufgabe nicht trivial, da zum einen eine Route erst einmal gefunden werden muß, zum anderen diese möglichst optimal gewählt werden muß. Eine weitere Aufgabe der Vermittlungssicht ist die Überlaststeuerung: Der Routingalgorith­mus achtet bei der Wahl der Route auf eine ausgeglichene Belastung der Knoten, um Engpässe zu vermeiden.

2.4 Der TCP/IP Protokollstapel

Im Folgenden wird die generelle Betrachtung von Netzwerkprotokollen auf das konkrete Beispiel TCP/IP angewandt. Da der TCP/IP Protokollstapel seine Anfänge weit vor der Festlegung des OSI-Referenzmodells hat kann man kei­ne 1:1 Korrespondenz finden, sondern kann eher als eine abgespeckte Version des Referenzmodell angesehen werden. Abb. 2 zeigt die Aufteilung des TCP/IP Protokollstapels in Schichten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Der TCP/IP Protokollstapd

Der Protokollstapd besteht aus einer Vielzahl von Einzelprotokollen, die sich auf vier Schichten aufteilen lassen: Sicherungs-. Vermitthmgs-. Transport-, und Anwendungsschicht. Dabei übernehmen die verschiedenen Protokolle in jeder Schicht jeweils unterschiedliche Aufgaben innerhalb dieser Schicht.

Die typische Kommunikation zwischen zwei verteilten Instanzen einer Applikati­on aus der Anwendungsschicht geht dann wie folgt vonstatten: Die Startinstanz der Applikation. z.B. das FTP Programm, das auf Rechner 1 läuft, schickt sei­ne applikationsspezifischen Daten. z.B. ein Anfrage für den aktuellen Verzeich­nisbaum des anderen Rechners, an die Endinstanz der Applikation, das FTP Programm auf Rechner 2. Dabei gehen diese Daten den Weg von oben nach unten durch den Protokollstapel von Rechner 1 aus der Netzwerkkarte über das physikalische Medium, z.B. Ethernet, zur Netzwerkkarte von Rechner 2, von wo aus es nun den Protokollstapel von unten nach oben durchwandert, Bis das die Daten wieder bei der Endinstanz der Anwendung ankommt. Zwischen Start- und Zielrechner durchwandern die Daten noch die Protokollstapel der Knoten, an denen Routingentscheidungen getroffen werden. Die Daten gehen dabei aber nur bis zur IP Schicht des Routers, auf der dann entschieden wird, wohin die Datenpackete weitergeleitet werden.

Für die Kommunikation zwischen den verschiedenen Instanzen der Protokol­le werden Header- und eventuell Footerdaten an die Rohdaten von der nächst höheren Schicht angehängt. Diese zusätzlichen Daten enthalten die Informatio­nen, die die Protokolle brauchen, um ihre Arbeit verrichten zu können. Bei IP sind das z.B. Daten über die IP Version, den Absender, den Empfänger, und die Länge des Pakets.

3 IP Version 4

Nach dieser Einführung in den Thematik von Kommunikationsprotokollen beschäftigt sich dieses Kapitel mit der aktuell eingesetzten Version der Internet Protokolls, IP Version 4. Dabei wird zuerst die generelle Funktionsweise des Protokolls und sein Zusammenspiel mit anderen Protokollen erklärt, um dann anhand des Pro­grammcodes des TCP/IP Stacks von BSD Unix auf Implementierungsdetails dieses Protokolls einzugehen [2].

Das Internet Protokoll ist ein unsicherer, verbindungsloser Packetzustellservice, dessen Hauptaufgabe das Senden der Daten von Absender zum Empfänger ist.

Um diese Aufgabe zu erfüllen muß IP über ein Adressierungssystem verfügen, daß Absender und Empfänger eindeutig im Netzwerk kennzeichnet. Dieses Sy­stem weist jedem Teilnehmer im Netzwerk eine sogenannte IP Adresse zu.

Alle Datenpackete, die IP von der Transportschicht bekommt, werden mit zu­sammen mit einem IP Header, der u.a. die Absender- und Empfängeradres­se enthält, zu einem IP Datagramm zusammengeschnürt, und über die Siche­rungsschicht auf den Weg geschickt. Die wichtigste Aufgabe von IP, das Rou­ting, kommt nun zum Tragen. IP muß den Weg zum Empfänger bestimmen, und das IP Datagramm, möglicherweise über mehrere Zwischenstationen, zum Empfänger bringen. Ist das Datagramm beim Empfänger angekommen, löst das Protokoll den IP Header wiederum von den Rohdaten, und reicht diese an die Transportschicht weiter. An dieser Stelle ist die Aufgabe von IP beendet.

3.1 IP Adressierung

Um Daten innerhalb eines Netzwerkes hin- und herzuschicken bedarf es eines einheitlichen Adressierungsverfahrene, um Absender und Empfänger ähnlich ei­ner Postanschrift eindeutig zu kennzeichnen. Die Funktion der Postanschrift übernimmt beim Internet Protokoll die IP Adresse, eine 32 Bit lange Zahl. Jede Netzwerkkarte innerhalb eines TCP/IP Netzes hat eine eindeutige IP Adresse zugewiesen.

IP Adressen sind nicht einfach fortlaufend durchnumeriert wie Hausnummern, sondern folgen einer hierarchischen Struktur. Sie werden normalerweise als vier durch Punkte getrennte Dezimalzahlen dargestellt, wobei jede Zahl einen Wert von 0 bis 255 annehmen kann und daher 8 Bit der 32 Bit langen IP Adresse darstellt. Ein Beispiel einer IP Adresse ist 140.252.13.33.

3.2 Netzklassen

Dio Strukturierung von IP Adresse spiegelt die Topologie des Internets wieder: Das Internet selbst bestellt aus vielen untereinander verbundenen Netzwerken, die jeweils eine unterschiedliche Anzahl von Hosts enthalten. Die Hosts eines Netzwerkes können wiederum in kleinere Gruppen, sogenannten Subnets, zu­sammengefaßt werden. Diese Aufteilung kann wiederum mit der einer Postan­schrift verglichen werden: Das Land besteht aus vielen Orten, die jeweils eine unterschiedliche Anzahl von Postanschriften hat. Die Postanschriften eines Or­tes lassen sich wiederum nach Zustellbezirken der Post zusammenfassen.

Diese Struktur des Internets wird im IP Adrcßraum aufgegriffen. Jede IP Adres­se besteht aus einer Netzwerk ID und einer Host ID. Die Subnetz ID ist wie­derum Teil der Host ID. worauf aber später noch eingegangen wird. Die Anteile von Netzwerk ID und Host ID sind variabel, so daß man verschieden große Netz­werke aufbauen kann. Abb. 3 zeigt die verschiedenen Netzklassen.

Der IP Adrcßraum wird je nach Länge der Host ID in Netzklassen A. B. C.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: IP Netzklassen

D. und E unterteilt. Innerhalb der Klassen gibt es eine Anzahl von Netzwerken, die wiederum eine Anzahl von Hosts enthalten können. Eine Sonderstellung ha­ben dabei die Klasse D und Klasse E Adressen: Klasse D Adressen werden für sogenannte Multicasts verwendet, bei denen IP Datagramme zu mehren Hosts gleichzeitig gesendet werden. Klasse E Adresse sind für zukünftige Erweiterung gedacht. Diese beiden Netzklassen werden bei der Beschreibung hier zunächst einmal außer Acht gelassen.

Die Netzklasse entscheidet, wieviel der gesamten 32 Bit Adresse für die Host Adresse innerhalb eines Netzwerks benutzt wird. d.h. wieviele Hosts maximal zu diesem Netzwerk gehören können. Anhand der Länge der Host ID und der Klassen ID errechnet sich dann die Länge der Netzwerk ID. die die Anzahl der Netzwerke innerhalb dieser Klasse bestimmt.

Dieses System ist eigentlich sehr intuitiv, nur die variable Länge der Klassen ID ist etwas schwierig. Soll von einer gegebenen IP Adresse die Klasse, die Netz­werk ID. und die Host ID bestimmt werden, muß die Adresse zuerst in die binäre Schreibweise umgewandelt werden. Dann trennt die erste „0“dic Klassen ID vom Rest der IP Adresse. Anhand der Klassen ID kann nun bestimmt werden, wie- vid Bits dio Netzwerk ID und wieviel Bits die Host ID ausmachen[5].

IP Adressen werden von einer zentralen Instanz im Internet vergeben. Dabei werden nicht einzelne Adressen vergeben, sondern immer ganze Klassen. Ein Netzwerkadministrator, der mit seinem LAN am Internet teilnelimen möchte, muß sich daher überlegen, wieviel IP Adressen er maximal braucht, und anhand dieser Zahl eine Class A. Class В. oder Class C Adresse beantragen. Er bekommt dann entsprechend nur die Netzwerk ID zugewiesen. Die Auswahl der Host ID für die Rechner bleibt ihm überlassen.

3.3 Subnetze

Klasse A Adressen haben die größte Anzahl an möglichen Hosts, wegen der 24 Bit Host ID über 16 Millionen Hosts. Da so große Netze schwer zu verwalten ist. kann man die Hosts in einem Netzwerk noch mal gruppieren. Die Gruppierung geschieht über die sogenannte Subnet Mask, eine zusätzlich zu der IP Adresse gegebene 32 Bit lange Zahl. Diese Subnet Mask teilt die eigentliche Host ID der Adresse noch mal in Subnetz ID und Host ID. Die Subnet Mask besteht aus einer Reihe von Einsen gefolgt von einer Reihe von Nullen, wobei die Einsen den Teil der IP Adresse „maskieren“, der nicht zur Host ID gehört. Der Rest der eigentlichen Host ID wird dann zur Subnetz ID. So kann man z.B. eine Klasse В Adreßraum, der eigentlich 65535 Host ID enthält, in 255 Subnetze mit je 255 Hosts auf-teilen. Dabei muß die Aufteilung keineswegs wie hier an Bytegrenzen geschehen. Ein Beispiel für eine Subnet Mask zeigt Abb. 4.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Ein Beispiel für eine Subnet Mask

3.4 Spezielle Absenderadressen,Loopback- und Broadcast Adressen

Einige IP Adressen haben spezielle Bedeutung und können nicht an Hosts verge­ben werden. Dabei kann zwischen drei Klassen von Spezialadressen unterschie­den werden:

- Spezielle Absenderadressen - Adressen mit einer Netzwerk ID von 0 und einer Host ID entweder von 0 oder einer gültigen Host ID werden als Absenderadresse benutzt, wenn ein Host z.В. beim Booten seine Netzwerk ID bzw. Host ID noch nicht kennt.
- Loopback Adressen - Eine Netzwerk ID von 127 und eine gültige Host ID zeigen immer auf den eigenen Rechner, und kann für Testzwecke benutzt werden. Wird ein Datenpacket mit der Empfänger Netzwerk ID von 127 adressiert, so muß auf der Sicherungsschicht dieses Datagramm zurück ins lokale IP Protokoll leiten, ohne daß das Datagramm im Netzwerk er­scheint. Daher gibt es kein Klasse A Netzwerk mit Netzwerk ID 127. Oft wird per Default die Adresse 127.0.0.1 als Loopback Adresse konfiguriert.
- Broadcast Adressen - Broadcast Adressen ermöglichen das Versenden von Datagrammen an Gruppen von Hosts. Dabei wird zwischen vier Klassen von Broadcast Adressen unterschieden. Durch diese reservierten IP Adres­sen reduziert sich die Anzahl der Hosts pro Netz-werk bzw. Sub-netz. so daß z.B. bei Klasse C Netzwerken nicht die maximal möglichen 256 Hosts pro Netz adressiert werden können, sondern einer weniger, da die Host ID von 255 für den Broadcast in diesem Netz reserviert ist.

3.5 Das IP Datagramm

IP bekommt von der Transportschicht Datenpackete. bettet diese in einem so­genannten IP Datagramm ein. und gibt dieses an die Sicherungsschicht weiter. Ein IP Datagramm besteht dabei aus einem IP Header, der die Informationen enthält, die das IP Protokoll braucht, um die Vermittlung der TCP Pakete zu erledigen, und den Rohdaten der Transportschicht. Abb. 5 zeigt den Aufbau eines IP Datagramms.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Aufbau eines IP Datagramms

Die Übertragung der Bytes geschieht in der sogenannten big-endian byte order, die niederwertigen Bits zuerst, und dann die höherwertigen. Dies ist die Konvention für die Übertragung aller Integerwerte in einem TCP/IP Netzwerk. Rechner, die intern die little-endian byte order verwenden, müssen Werte vor dem Versenden entsprechend umwandeln.

Das Versionsfeld (VERS) des IP Headers zeigt aktuell die Version 4 an. Das im nächsten Kapitel beschriebene Protokoll IP Version 6 zeigt entsprechend Versi­on 6 an.

Die Header-Länge (LEN) legt die Länge des Headers gemessen in 32-Bit Wörtern fest. Wegen der 4-Bit Länge des Feldes ist der Header also auf eine maximale Länge von 60 Bytes begrenzt. Dabei besteht der Header aus einem festen Teil von 20 Bytes Länge, und einem variablen Teil, den Optionen, die bis zu 40 Bytes in Anspruch nehmen können.

Das Type-Of-Service Feld (TOS) besteht aus drei ungenutzten Bits, vier Dienstart Bits, gefolgt wiederum von einem ungenutzten Bit. Die vier Dienstart Bits erlau­ben dem Absender des Datenpackets, gewisse Anforderungen bezüglich Verzöge­rung, Geschwindigkeit, Zuverlässigkeit und Kosten an die Übertragung zu stel­len, wobei je ein Bit einer eine der vier Eigenschaften darstellt. Nur eins der vier Bits darf dabei gesetzt sein.

Das folgende 16-Bit Feld gibt die Länge des Datagramme in Bytes an. Die maxi­male Größe eines Datagramme ist somit auf 65535 Bytes beschränkt. Zusammen mit der Header-Länge ergibt sich der Anfang des Datenteils und dessen Länge. Das Identifikator-Feld dient zur Identifikation eines Datagramme von einem be­stimmten Absender. Normalerweise inkrementiert der Absender diesen Wert für jedes neue Datagramm um eins. Dieses Feld, genauso wie das Flag-Feld und das Fragment-Offset Feld, dienen dem Zusammensetzen fragmentierter Datagram­me, und werden im nächsten Abschnitt genauer betrachtet.

Das Time-To-Live Feld (TTL) ist ein Zähler für die maximale Anzahl von Hops, die ein Datagramm machen kann. Ein Hop ist dabei als da Passieren eines Netz­werkknotens definiert. Das Feld wird auf einen bestimmten Wert initialisiert, z.B. 32 oder 64, und jedes Mal, wenn das Datagramm einen Router passiert, wird der Wert um eins dekrementiert. Ist der Wert null, so wird das Datagramm zerstört und der Absender bekommt eine Fehlermeldung. Somit wird die Lebens­dauer des Datagramme begrenzt.

Das Feld Protokolltyp bestimmt das Protokoll, von dem die Rohdaten an IP geliefert worden sind. Zur Auswahl stehen hier TCP, UDP, ICMP, und IGMP. Die Prüfsumme des Nachrichtenkopfes dient zur Fehlererkennung. Liegt ein Prüfsummenfehler vor, so wird das Datagramm zerstört, ohne daß eine Fehler­meldung an den Absender generiert wird, da keine Angaben über die Richtigkeit der Absenderadresse gemacht werden können. Die höheren Schichten müssen in dem Fall selbst erkennen, daß das Datagramm fehlt, und den Fehler behandeln. Die Felder Quelladresse und Zieladresse enthaften die IP Adressen von Absen­der und Empfänger des Datagramme.

Das Feld Optionen ist ein Feld variabler Länge, und enthält optionale Informa­tionen für spezielle IP Datagramme. Sind Optionen gesetzt, so zeigt das erste Byte im Optionsfeld den Optionstyp an. Anhand dieses Typ kann dann das IP Protokoll entscheiden, was mit dem weiteren Inhalt des Optionsfeldes zu ma­chen ist. Beispiele für Optionen sind das Aufzeichnen der Datagramm-Route, Das lose oder strikte Vorgeben der zu benutzenden Route, oder die Zeitstempe­lung des IP Datagramme. Das Feld sollte auch späteren Versionen des Internet Protokolls dazu dienen, weitere Informationen im IP Header unterzubringen. Damit ist der IP Header abgeschlossen, und es folgt der Datenteil, den IP von er Transportschicht bekommen hat. Die Gesamtlänge eines Datagramme ist theo­retisch auf 65535 Bytes begrenzt, aber ein Host ist nicht verpflichtet, Datagram­me anzunehmen, die größer als 576 Bytes sind. TCP unterteilt seiner Userdaten selbst, und viele der Applikationen, die UDP benutzen, beschränken sich selbst auf 512 Bytes Userdaten, um unter diesem Limit zu bleiben. Trotzdem können diese Datagramme die maximale Größe der Datenpackete der Sicherungsschicht überschreiten, so daß eine Fragmentierung, die Unterteilung eines Datagramme in kleinere Einheiten, notwendig wird.

3.6 Fragmentierung von IP Datagrammen

Die auf der Bitübertragungsschicht versendeten Datenpackete nennt man Fra­mes. Diese Frames haben je nach physikalischem Medium eine unterschiedli­che Maximalgröße. Fragmentierung von Datagrammen ist dann nötig, wenn die Größe des Datagramme die maximale Größe der Frames des darunterliegenden Netzes überschreitet. Verschiedene Netztypen haben dabei verschiedene maxi­male Framegrößen: Ethernet z.B. hat eine Obergrenze von 1500 Bytes pro Fra­me, X.25 nur 576 Bytes pro Frame, andere Netztypen sogar noch weniger. Erhält IP ein Datagramm zum versenden oder zum weiterleiten, stellt das Pro­tokoll zuerst einmal über eine sogenannte Routing Tabelle fest, welches Netz­werkinterface benutzt werden muß. Die Sicherungsschicht dieses Interfaces gibt nun die Maximum Transmission Unit (MTU) bekannt, die maximale Größe der Datenframes. Liegt die Größe des Datagramme über der MTU des Interfaces muß fragmentiert werden, und das Datagramm auf mehrere Pakete aufgeteilt werden.

Die folgenden Felder werden bei der Fragmentierung herangezogen:

- Das Kennungsfeld enthält einen eindeutigen Wert zur Identifikation des IP Datagramme. Dieser Wert wird für die Fragmente übernommen.
- Das 3-Bit Flags-Feld enthält ein Bit, das anzeigt, daß noch mehr Fragmen­te folgen. Dieses Bit ist bei allen Fragmenten außer dem letzten gesetzt. Ein Bit zeigt an, daß das Paket nicht fragmentiert werden darf. Ist die­ses Bit gesetzt, so darf das IP Protokoll dieses Paket nicht fragmentieren. Wäre dies für den Transport notwendig, so wird das Paket verworfen, und eine ICMP Fehlermeldung wird an den Absender zurückgeschickt. Das dritte Bit dieses Feldes wird nicht genutzt.
- Der Fragment-Offset enthält den Offset dieses Fragments vom Anfang des Originaldatagramms.
- Wird ein Datagramm fragmentiert wird das Feld Gesamtlänge entspre­chend angepaßt.

Ein fragmentiertes IP Datagramm wird erst beim Empfänger wieder zusam­mengesetzt. Da ein IP Fragment verschiedene Netze mit verschiedenen MTU passieren kann, bedeutet dies, daß ein IP Fragment wiederum fragmentiert wer­den kann. Die Fragmentierungsinformation, die im IP Header gehalten wird, reicht aber aus, alle Pakete beim Empfänger wieder korrekt zusammenzusetzen. Da jedes IP Paket separat geroutet wird ist es möglich, daß Fragmente in der falschen Reihenfolge ankommen. Dies muß beim Zusammensetzen berücksichtigt werden.

Abb. 6 zeigt ein Beispiel von Fragmentierung eines UDP Datenpackets von 1473 Bytes. Zusammen mit dem UDP Header von 8 Bytes und dem 20 Byte

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Fragmentierung von Datagramme!!

großen IP Header ist die Länge des Datagramme 1501 Bytes, was über der 1500- Byte-MTU von Ethernet liegt. In solch einem Fall wird das Datagramm in zwei Pakete aufgeteilt, ein Paket mit 1472 Bytes UDP Daten, und ein Paket mit einem Byte UDP Daten.

Die Fragmentierung und das Zusammensetzen geschieht komplett auf IP Ebene und ist für höhere Schichten wie TCP und UDP völlig transparent. Trotz dieser Transparenz hat die Fragmentierung einen Nachteil: Wird ein Fragment nicht korrekt übermittelt, so muß das ganze Datagramm neu gesendet werden, da IP selbst kein Fehlerbehandlung dieser Art vornimmt. Kann das Datagramm bei Empfänger nicht korrekt zusammengesetzt werden, so wird dieses einfach ver­worfen. Das darüberliegende Protokoll muß dies erkennen und wenn notwendig, die Daten zur Übertragung wieder an das Internet Protokoll übergeben. Aus diesem Grund wird oft versucht. Fragmentierung zu vermeiden.

3.7 IP Routing

Mit Routing bezeichnet man die Wegbestimmung der Pakete der Vemiittlungs- schicht durch das Netzwerk. Das Paket bewegt sich im Netzwerk vom Sen­deknoten zum Empfangsknoten. möglicherweise über mehrere Zwischenknoten hinweg. Ziel des Routing ist es. das Paket über einen möglichst günstigen Weg zum Empfänger zu bringen.

In einem Netzwerk unterscheidet man grundsätzlich zwischen zwei Typen von Knoten: Hosts und Router. Hosts sind Maschinen, die nur über ein Interface mit dem Netzwerk verbunden sind. Router sind Maschinen, die mit zwei oder mehr Interfaces verschiedene Subnetze miteinander verbinden, und IP Pakete von einem Subnetz in ein anderes routen können.

Das Routing in einem TCP/IP Netzes wird vom IP Protokoll übernommen. So­wohl Hosts als auch Router verfahren dabei nach denselben Routing Prinzipien. Das Routing für Hosts gestaltet sich relativ einfach: Ist der Empfänger im sel­ben Subnetz des Hosts oder direkt mit dem Host verbunden, so wird das Paket direkt an den Empfänger gesendet. In allen anderen Fällen wird das Paket an einen Default Router gesendet, der dann dafür zuständig ist. das Paket wei­ter zum Empfänger zu übermitteln. Router dagegen haben mehr Informationen über die lokale Netzwerkstruktur und müssen anhand dieser Information das Paket entweder zum entsprechenden Host im entsprechenden Subnetz leiten, oder an den nächsten, für das Subnetz zuständigen Router.

3.7.1 Routing Tabellen

Die Routing Entscheidungen werden für Hosts und Router anhand von Routing Tabellen in den Knoten erledigt. Die Tabellen enthalten jeweils Einträge, wel­cher Knoten Pakete für welche Host- bzw. Netzwerkadresse erhalten soll. Ein einfaches Beispiel einer Routing Tabelle zeigt Abb. 7.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Eine einfache Routing Tabelle

Es gibt Einträge für einzelne Hosts, für das eigene Loopback Interface, für den Default Router, und für ganze Subnetze. Anhand der gesetzten Flags können die verschiedenen Eintragstypen unterschieden werden.

4 Implementierung von IP Version 4 in BSD Unix

In diesem Kapitel, wird genauer beschrieben, wie Pakete erzeugt werden, wie sie über Netze an den Zielrechner geleitet werden und wie sie bei jedem System verarbeitet werden. An Abb. 8 können wir erkennen, daß ein Paket vom Sen­dersystem zu verschiedenen Systemen in anderen Netzwerken verschickt werden kann (oder auch im lokalen Netz). Soll das Paket z.B. von dem Sender an den Empfänger mit IP Adresse 140.258.13.2 verschickt werden, muß es sogar über mehrere Netze verschickt werden.

Um das Paket über diese Netze an den richtigen Empfänger zu schicken, werden die Pakete von Systemen bearbeitet, die Router heißen. Diese sind im wesentlichen dafür zuständig die Pakete an das Ziel weiterzuleiten ( = Forwar­ding). Bei Abb. 9 können wir sehen, mit welchen Aufgaben sich der Sender, der Router und der Emfänger eines Paketes befaßt.

Beim Sender werden Daten von dem Transportprotokoll ans Internet Proto­koll übergeben, aus diesen Daten wird ein Datagramm erstellt und verschickt. Ist das Datagramm zu groß ( kann die Schnittstelle nicht so große Pakete ver­schicken). muß das Datagramm in kleine Fragmente geteilt werden. Hierzu wird in späteren Kapiteln noch genaueres geschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Netz

Beim Router liegt das Paket auf einem Puffer, bis die Input Processing Funk­tion (Funktion, die sich mit Paketen beschäftigt, die an das System geschickt werden) auf sie zugreift und nacheinander die Pakete aus dem Puffer verarbei­tet. Als nächstes werden bei der Weiterleitung von Paketen Optionen verarbeitet und dann an die Forwarding Funktion weitergegeben. Dabei ist die Input Pro­cessing Funktion die gleiche, die bei dem Empfängersystem benutzt wird, bei ihr muß also zwischen den Paketen unterschieden werden, die weitergeleitet werden sollen oder am Zielsystem angelangt sind. Bei der Forwarding Funktion wird im wesentlichen die Route bis zum Zielsystem ermittelt. Hierzu wird eine An­frage an die Routing Tabelle, die in jedem System vorhanden ist, gemacht. Die Forwarding Funktion gibt das Paket an die Output Funktion weiter, die auch in diesem Fall überprüft, ob das Paket fragmentiert werden muß oder gleich verschickt werden kann.

Beim Emfänger greift auch die Input Processing Funktion auf den Puffer zu. Ist im Puffer ein Fragment gespeichert, muß dieses von der Ressembly Fun- tion zum passendem Datagramm zugeordnet werden. Ist ein Datagramm aus Fragmenten erstellt worden oder von dem Puffer genommen worden, kann es an das Transportprotokoll weitergegeben werden. Wie in Abb. 9 zu sehen ist, wird dem Transportprotokoll, nach der Bearbeitung eines Paketes, nicht der IP Hea­der übergeben. Dieser wird nur von der Vermittlungsschicht bei jedem System bearbeitet.

Es kann auch sein, daß ein Paket an mehrer Empfänger verschickt wird. Der Unterschied bei diesen Paketen zu den vorher beschriebenen ist nur die Zieladresse, sie werden bis auf Ausnahmen gleich behandelt.

Nach diesem Überblick werden anschließend noch genauer die angesproche­nen Funktionen (Forwarding Funktion, Input Processing Funktion und die Out­put Funktion) und die Routing Tabelle behandelt.

5 Output Processing

Aufgaben mit denen sich Output Processing befaßt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Funktionen

- Empfang von Paketen von der Forwarding Funktion den Transportproto­kollen.
- Initialisierung und Erstellung des Headers.
- Auswahl des Weges beim Verschicken eines Packetes.
- Wahl der Senderadresse.
- Fragmentierung.

Die Output Processing Funktion erhält die Pakete, die es verschicken soll, von zwei Quellen: der Forwarding Funktion und den Protokollschichten UDP und TCP des Systems. Die Output Processing Funktion kann in drei Teilen beschrieben werden:

Initialisierung und Erstellung des Headers. Auswahl des Weges beim Ver­schicken eines Packetes und Wahl der Senderadresse und Fragmentierung.

5.1 Initialisierung und Erstellung des Headers:

Dieser Schritt wird bei weitergeleiteten Paketen nicht durchgeführt, da der Hea­der schon vorhanden ist. und Änderungen in ihm von der Forwarding Funktion durchgeführt werden. Wird die Funkion beim Sender aufgerufen, übergibt das Transportprotokoll die Daten aus dem das Paket zusammengestellt werden soll. Wie in Abb. 9 zu sehen ist. wird der Vermittlungschicht Daten einer Anwendung mit einem vorgestellten TCP oder UDP Header übergeben. An diese Daten fügt die Output Processing Funktion mit den weiteren übergeben Parametern (Länge des Paketes. Identifizierung des Paketes. TTL . Protokoll. TOS. Zieladresse des Paketes, mögliche Optionen, gespeicherte Route und anderen Merkmalen (Flags)) einen eigenen Header ein. Werden Optionen angegeben, so werden sie von ip-insertoptions, einer weiteren Funktion die fürs Einfügen der Optionen in ein Paket zuständig ist, ins Datagramm eingefügt und die neue Länge des Hea­ders aktualisiert. Mit den übergebenen Parametern muß das Identifizierungsfeld, das TTL, das Protokoll, der Typ of Service (TOS), die Zieladresse und Optionen in die vorgegebenen Felder im Header eingetragen werden. Weiter stellt die Out­put Processing Funktion die richtige IP Version ein und Felder, die Paketlänge oder Headerlänge angeben, werden wegen neuen Daten im Header neu gesetzt.

5.2 Route Selection

Auch bei dieser Aufgabe wird unterschieden, ob ein Paket weitergeleitet wird oder am momentanen System erstellt wird. Bei weitergeleiteten Paketen wurde diese Aufgabe (Route Selection) schon von der Forwarding Funktion durch­geführt und ein Flag zeigt an, daß es sich um ein weitergeleitetes Paket handelt. Wird ein Datagramm gerade erstellt, beschäftigt sich die Output Processing Funktion, nachdem der Header fertiggestellt ist, mit der Wahl des Weges bis zum Endziel. Eine gespeicherte Route wird der Output Processing Funktion übergeben, stimmt die Zieladresse dieser Route mit dem angegebenen Zielsy­stem nicht überein, ist die Route nicht für dieses Paket geeignet, es wird ei­ne passende Adresse für das Paket aus der Routing Tabelle gesucht. Da dies natürlich Zeit kostet, wird versucht eine schon vorher für ein anderes Paket be­nutzte Route, auf das aktuelle anzuwenden, es ist nämlich meistens der Fall, daß aufeinanderfolgende Pakete zum gleichen Ziel verschickt werden. Routing kann verhindert werden, wenn das IP_ROUTETOIF Flag gesetzt wird (von der Transportschicht gesetzt). In diesem Fall sucht die Output Processing Funktion eine Schnittstelle, die direkt zum Zielnetz angeschlossen ist.

5.3 Source address selection und Fragmentation

Im letzten Teil von der Output Processing Funktion wird auf Richtigkeit der Senderadresse (source address) geprüft und dann wird das Paket an die Schnitt­stelle weitergegeben. Ein System kann mehrere Schnittstellen habe, die für das Paket benutzte wird festgehalten. Pakete die weitergeleitet werden, haben im­mer eine Senderadresse. Wenn das Paket größer als die MTU (maximale Über­tragungsgröße) der Schnittstelle ist, muß das Paket fragmentiert werden und in mehreren kleineren Teilen verschickt werden. Da dies auch eine recht aufwendige Funktion ist, wird sie später extra behandelt. Ist das Paket klein genug und die Senderadresse festgelegt, kann das Paket verschickt werden, nachdem Daten ins Netzformat verwandelt wurden, die Prüfsumme berechnet und das Paket an die Schnittstelle weitergegeben wurde.

6 Input Processing

Jedes ankommende Paket wird von der Netzschnittsstelle in die Warteschlange abgelegt, auf die die Input Processing Funktion zugreift. Diese Funktion ist für die folgenden Aufgaben zuständig :

- Kontrolle ankommender Packete : IP Version, IP Prüfsumme (checksum) und Paketgröße
- Optionen Verarbeitung und Weiterleitung ?
- Reassembly

Input Processing wird nicht nur von einer Funktion durchgeführt. Input Processing wird von mehreren Funktionen durchgeführt (wie reassembly und Optionsverarbeitung), die bei bedarf aufgerufen werden.Wie an dieser Stelle zu erkennen ist, werden auch hier (nicht nur bei der Output Processing) Optio­nen verarbeitet. Es sollte an dieser Stelle gesagt werden, daß Option Processing in mehreren Funktionen durchgeführt wird, einige von ihnen werden in Out­put Processing andere in Input Processing benutzt. Zu den Einzelheiten dieser Funktionen wird in weiteren Abschnitten noch mehr geschrieben.

Die Hauptverarbeitungsprozedur von Input Processing fängt damit an Pa­kete aus der Warteschlange auszulesen. Nacheinander werden Pakete aus ihr verarbeitet und aus ihr gelöscht, bis keines mehr enthalten ist. Als erstes wird bei ankommenden Paketen der Inhalt überprüft, beschädigte Pakete werden verworfen. Die Überprüfung erfolgt in mehreren Schritten:

1. Als erstes wird überprüft, ob dem System eine Adresse zugeteilt wurde. Wird das System gerade hochgefahren, kann es sein, daß schon Pakete auf der Warteschlange liegen aber noch keine Adresse gegeben ist, mit der überprüft werden kann, ob das Paket an das System gerichtet ist, oder weitergeleitet werden soll. Kann dieses nicht kontrolliert werden, wird das Paket verworfen.
2. Weiter wird kontrolliert, ob das System auch mit der IP Version des an­kommenden Pakets vertraut ist. Handelt es sich um eine neuere Version, werden im Header Felder Vorkommen, die nicht von diesem System er­kannt/verarbeitet werden können.
3. Überprüfung der erhaltenen Datenmenge eines Pakets. Nimmt das Pa­ket mehr Speicher ein, als im Header angegeben wird, müssen Daten aus dem Paket entfernt werden. Dies kommt dann vor, wenn ein Paket von ei­nem System verschickt wurde, daß Pakete einer bestimmten Mindestgröße nicht verschickt. Diese Systeme fügen unbrauchbare Daten in das Paket ein, so daß das Paket die minimale Größe erreicht. Nimmt das Paket we­niger Speicher ein, als im Header angegeben wird, wurden Daten verloren, in diesem Fall wird das Paket verworfen.
4. Weiter wird überprüft, ob das Paket das Zielsystem erreicht hat oder wei­tergeleitet werden muß. Hierfür wird bei Input Processing die ip_dooptions Funktion ausgeführt, die sich mit der Verarbeitung von Optionen beschäftigt. Da die Verarbeitung der Option eine komplizierte Funktion ist, wird sie in einem weiteren Abschnitt behandelt.

Ist das Paket noch nicht am Endziel angekommen, es wird weitergeleitet wenn dies möglich ist. Hierfür ist die Forwarding Funktion zuständig (die auch im Input Processing Code enthalten ist, aber wegen seiner Komplextät extra be­handelt wird). Ist das Paket am Endziel und kein Reassembly erforderlich, dann wird das Paket an das Transportprotokoll weitergeleitet. Ansonsten wird es an das nächste System weitergeleitet. Die Beschreibung von IP Forwarding, Option Processing und IP Reassembly haben wir in weiteren Abschnitten beschrieben.

7 Forwarding

Die Forwarding Funktion wird ausgeführt, wenn ein in ein System ankommendes Paket nicht das Endziel erreicht hat. Die Funktion befaßt sich mit folgenden Punkten:

- Kontrolle, ob Weiterleitung möglich ist.
- Aktualisierung des IP Headers.
- Auswahl des Weges zur Weiterleitung eines Paketes.
- Übergabe der Pakete an die Output Processing Funktion.

Die Aufgabe von der Forwarding Funktion kann in zwei Teile aufgeteilt wer­den.

1. Als Erstes muß sichergestellt werden, daß das System es erlaubt Pakete weiterzuleiten. Ist dies der Fall, aktualisiert den Headers und wählt einen geeigneten Weg für die Weiterleitung.
2. Im zweiten Teil wird das Paket an die Output Processing Funktion wei­tergegeben, damit es verschickt werden kann.

Bei der ersten Aufgabe arbeitet die Funktion folgendermaßen: Die Zieladres­se wird erkannt und Pakete mit Link-level broadcast-, Loopback-, Network 0 and class E- und Class D Adressen werden verworfen.

Beim Aktualisieren des Headers geht es darum das TTL Feld (time-to-live) zu aktualisieren. Bei jedem Router wird das Feld um mindestens eine Einheit oder der Zeit dekrementiert, die das Paket aufgehalten wird.

Als nächstes wird ein Weg für das Paket gesucht. Der IP Forwarding Algo­rithmus versucht den zuletzt benutzten Weg auf das Paket anzuwenden. Stimmt die Zieladresse des gespeicherten Weges mit der Zieladresse des Headers übe­rein, braucht nicht in der Routing Tabelle nachgesehen werden. Sonst muß eine weitere Funktion aufgerufen werden, die sich damit beschäftigt, den passenden Eintrag zu dem Paket in der Routing Tabelle zu finden. Wie diese aufgebaut sind, wird im Kapitell IP Routing & Routing Tabellen noch beschrieben.

Bei der zweiten Aufgabe übergibt die Forwarding Funktion der Output Pro­cessing Funktion das Paket und die Routeradresse, zu der es versendet werden soll. Ausserdem gibt die Forwarding Funktion an, daß es sich um ein Paket han­delt, das weitergeleitet wird. Dies soll darauf hinweisen, daß das Paket bis auf Fragmentierung nicht weiter verarbeitet werden muß.

8 Options and Option Processing

8.1 Allgemeines

In diesem Abschnitt werden wir über die Optionsmöglichkeiten schreiben und wie diese bearbeitet werden. Optionen sind dazu da, Aplikationen verschiedene Dienste zu bieten. Werden diese Dienste nicht benötigt, braucht auch kein Opti­onsfeld angegeben zu werden. Von der Seite des Senders wird bestimmt, ob Op­tionen in ein Paket eingefügt werden. Ist dies der Fall, muß die ip jnsertoptions Funktion, Teil der von Output Processing, Platz für die Optionen schaffen. Bei der Input Processing Funktion wird Option Processing durchgeführt, nachdem das Paketformat kontrolliert wurde und bevor geprüft wurde, ob das Endziel eines Pakets erreicht ist, d.h. die Optionen werden von jedem Router und vom Zielrechner verarbeitet. Die Optionen haben keine festgelegte Reihenfoge in den maximal 40 Bytes, die für Optionen in einem Paket vorgesehen sind (siehe Abb. 11). Sie werden gerade in der Reihenfoge behandelt, in der sie im Feld auftre­ten. Wie in Abb. 10 zu sehen ist, gibt es zwei Arten von Optionen bezüglich des Aufbaus. Die single-byte und die multibyte Optionen. Im wesentlichen existie­ren die record route, timestamp, security, stream identifier und die source and record route Option , die anschließend noch behandelt werden. Optionen, die nur eingeschränkt benutzt werden, sind security (vom US Militär) und stream ID. Sie werden aus diesem Grund hier nicht behandelt.

Handelt es sich bei der Optionsverarbeitung um ein Datagramm, das beim Sender erzeigt wird und bei dem Optionen eingefügt werden sollen, wird die ip Jnsertopions Funktion aufgerufen.

8.2 Beschreibung der ipJnsertoptions Funktion

Diese Funktion wird von der Output Processing Funktion aufgerufen und ist dafür zuständig Optionen in ein Datagramm einzufügen oder Platz für diese zu schaffen. Dieser Platz wird später bei den Routern benötigt um z.B. Zeit- stemmpel zu setzen. Wird die Output Processing Funktion von der Forwarding Funktion aufgerufen, dann sind die Optionen schon in dem Datagramm ent­haften, und es wird keine weitere Option übergeben. Wenn ein Paket sich aber beim Sender befindet, dann ruft eines der Transportprotokolle die Funktion die Output Processing Funktion auf.

Als nächstes wird die Funktion beschrieben, die bei ankommenden Paketen durchgeführt wird und genaueres zu den verschiedenen Optionen geschrieben.

8.3 Die Funktion Ip_dooptions

Bei IPv4 ist kein fester Platz für die verschiedenen Optionen festgelegt, sie wer­den der Reihe nach verarbeitet. Falls nicht bekannte Optionen auftreten, werden diese nicht beachtet. Soll ein Paket weitergeleitet werden, wird das Paket an die Forwarding Funktion weitergegeben. Gibt es bei der Erkennung einer Option einen Fehler, wird eine ein Fehler gemeldet und die Headerlänge berichtigt. Als nächstes werden die von uns behandelten Optionen beschrieben.

8.4 Die Optionen

8.4.1 Record route option

Diese Option legt fest, daß die Adressen der Router, über die das Paket weiter­geleitet wird im Header gespeichert werden. Um die Adressen abspeichern zu können, setzt der Sender die Größe des Optionsfeldes fest.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Record Route

Wenn dieser Platz dann aber doch zu klein ist, wird das Paket wie gewöhn­lich weitergeleitet, ohne die Adressen der passierten Router zu speichern. Beim Zielsystem wird die Adresse der Schnittstelle, die das Paket empfängt, sonst die Adresse der Ausgangsschnittstelle gespeichert.

8.4.2 Source and Record Route Option

Normalerweise wird der Weg eines Paketes zum nächstem Router bei jedem Router festgelegt. Die Source and Record Option ermöglicht es dem Sender ei­nes Datagrammes den Weg bis zum Ziel festzulegen und so den Routern keine Entscheidung zu ermöglichen. Dies ist auch aus Zeitgründen positiv. Die Opti­on strict route erlaubt es jeden Router bis zum Ziel festzulegen. Die loose route Option, legt nur einige Router festlegt.

Auch bei dieser Option wird beim Zielsystem die Adresse der Schnittstel­le, die das Paket empfängt, gespeichert, sonst wird die Adresse der Ausgangs­schnittstelle gespeichert. RFC 1122 legt fest, daß der zurückgelegte Weg ei­nes Pakets, der im Header gespeichert wird, und der Transportschicht zugäng­lich gemacht wird. Wenn ICMP (Internet Control Message Protocol) und das Transportprotokoll einem Hostrechner eine Nachricht zu einem erhaltenen Pa­ket zurückschicken muß, dann benutzt es den Weg, indem er ihn in umgekehrter Reihenfolge dem neuen Paket gibt.

8.4.3 Timestamp Option

Bei der Timestamp Option handelt es sich um eine Option, die bewirkt, daß ein Zeitstempel in das Paket geschrieben wird. Auch hier gibt es mehrere Möglich­keiten. Es kann angegeben werden, daß nur die Zeit, daß die Zeit und die Adresse an den passierten Routern oder daß die Zeit an bestimmten Routern gespeichert wird. Da nur 40 bytes für IP Optionen in einem Paket vorhanden sind, ist es möglich entweder 9 Timestamps zu speichern oder vier Paare von Adressen und Timestamps. Bei jedem Router wird in das Optionfeld die aktuelle Zeit und die Adresse des Routers eingetragen. Dazu muß das System die genaue UTC Zeit seit Mitternacht in Millisekunden speichern, diese muß mindestens 15 mal in der Sekunde aktualisiert werden.

8.5 Einschränkungen von Optionsverwendung und Option Processing

Optionen sind meistens in IP Datagrammen enthalten, die von Verwaltungs­und Diagnoseprogrammen erzeugt werden, z.B. Werkzeuge wie ping und telnet. Es ist schwierig Anwendungen zu schreiben, die IP Otionen benutzen, denn die Programmschnittstellen sind nur schlecht beschrieben und nicht standarisiert. Die meisten käuflichen Anwendungen, wie Telnet und FTP, geben dem Benutzer keine Möglichkeit die Optionen, wie Source Route, festzulegen. Eine weiterere Einschränkung ist, daß der Nutzen von Record Route, Timestamp und Sour­ce Route Optionen bei Verbindungen über viele Router wegen der begrentzen Optionsfeldergröße von 40 bytes eingeschrängt ist. Oft reichen diese nicht aus um bis ans Ziel alle Daten zu speichern. Wenn mehrere Typen von Optionen in einem Paket angegeben werden, ist der Platz für diese dann meistens nicht ausreichend. Bei IPv6 wird dies berücksichtitg, und eine flexiblere Handhabung der Optionen und Header eingeführt.

9 Fragmentation and Reassembly

9.1 Allgemeines

Eine wichtige Aspekt vom Internet Protokoll ist, daß es die Fähigkeit hat, Da­tagramme die zu groß für die Übertragung sind, zu fragmentieren und am Ziel wieder zusammenzusetzen. Wie schon in vorherigen Abschnitten gesagt wur­de, ist die Fragmentation Teil von Output Processing, in ihr wird geprüft, ob das Paket klein genug ist oder die Fragmentation Funktion aufgrufen werden muß. Die Reassembly Routine wird bei Input Processing durchgeführt. Die Da­tagramme die zu groß sind, werden in zwei oder mehrere Pakete aufgeteilt und so wird ermöglicht, daß das System die Möglichkeit hat das Datagramm zu verschicken. Es kann auch sein, daß Fragmente im Verlaufe des Weges zum Ziel weiter von anderen Routern fragmentiert werden. Es kann also sein, daß ein Da­tagramm beim Ziel in bis zu mehreren Teilen ankommt und diese Pakete dann wieder zum ursprünglichen Datagramm zusammengesetzt werden müssen. Da ein Datagramm über den Weg bis ins Ziel mehrmals fragmentiert werden kann und diese Pakete über verschiedene Wege zum Ziel geschickt werden können, ist es nur für das Zielsystem möglich das Datagramm wieder zusammenzusetzen. Es könnte Vorkommen, daß aufeinaderfolgende Pakete in einem Router wieder zu einem größeren Paket zusammengesetzt werden könnten, dies geschieht aber nicht, nur das Destination System kümmert sich um das Reassembly. Dies ist die effektivste Art ein Datagramm über das Internet zu verschicken. Würden auch Router Pakete zusammenstellen, könnte es Vorkommen, daß ein Paket mehr- mals fragmentiert wird und dann wieder zusammengesetzt werden müßte. Drei Felder im Header sind für die Implementierung von Fragmentation und Reas­sembly nötig: Ein Feld das aus drei Flags bestellt, das Identification Feld(ip-id) und das 13 bit große Offset Feld

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Optionen

Wie bei anderen Feldern im Header, ist auch bei den flag Feldern eins für spätere Nutzen reserviert, und ist auf 0 gesetzt. Das zweite ist das don’t fragment (DF) flag. Wie der Name schon sagt, verhindert dies, daß ein System das Paket fragmentiert. Das dritte flag ist das more fragments (MF) flag. Diese flag wird auf eins gesetzt, wenn angezeigt werden soll, daß das Paket ein Fragment ist.

Das Offset Feld ist für die Reassembly Routine nötig, es gibt die Position des Fragmentes in dem Datagramm an. Die Pakete die zu einem Datagramm gehören kommen nämlich nicht immer in der Reihenfolge an. in der das Data- gramm wieder zu seiner ursprünglichen Form zusammengesetzt wird. Die Pakete brauchen unterschiedlich lange Zeit das Netz zu passieren, es kann Vorkommen, daß das Fragment das zuerst abgeschickt wurde, als letztes am Ziel eintrifft. Dies macht eine genaue Identifizierung jedes Paketes nötig. Die Position eines Fragmentes wird in 8-byte Einheiten gezählt, dies hängt damit zusammen, daß die Datagramme in höchstens 8-byte kleine Fragmente zerstückelt werden. Aus­nahme ist das letzte Fragment, dies kann auch kleiner sein. Bei diesem Paket wird auch als einziges das MF flag nicht gesetzt.

Daß Fragmente von verschiedenen Datagrammen nicht zu einem Datagramm zusammengesetzt werden, verhindert das identification Feld im Header (siehe Abschnitt 3.1.5).

9.2 Zur Fragmentierung

Wir kommen jetzt wieder zur Output Processing Funktion, in der die Funktion, die für das Fragmentieren zuständig ist, enthalten ist. In der Output Proces­sing Funktion wird geprüft, ob ein Datagramm klein genug ist, um auch ohne Fragmentierung verschickt zu werden. Ist dies nicht der Fall, muß ein Data- gramm oder ein Paket (wenn das Datagramm schon in einem anderem System fragmentiert wurde) erst von der Fragmontiorungsfunktion verarbeitet werden. Der Algorithmus dieser Funktion ist nicht kompliziert, seine Implementierung ist es aber nicht, da mit doppelt verketteten Listen komplizierter Strukturen (structs) gearbeitet werden muß. Wird Fragmentierung durch das DF flag im Paket verhindert, wird das Paket nicht verschickt und eine Fehlermeldung wird der Transportschicht übergeben.

Die Fragmentieren erfolgt im wesentlichen in drei Etapen:

1. Berechnung der Fragment große.
2. Erstellung der Fragmentliste.
3. Erstellung des Fragmentes aus dem ursprünglichen Paket und Senden des Fragments.

Berechnung der Fragmentgröße:

Die Berechnung der Datenmenge (len) der Fragmente eines Paketes, ist MTU (maximal transmition unit) minus der Länge des Headers, dieses aufgerundet auf eine 8-byte Grenze, wobei auf die 3 low-order bits geachtet werden muß. Wenn MTU so klein ist, daß die Fragmente weniger als 8 bytes aufnehmen, dann wird keine Fragmentierung durchgeführt. Wird die Fragmentierung durch­geführt, dann enthält jedes Fragment natürlich den IP header, einige der Op­tionen des ursprünglichen Pakets und “len” Bytes an Daten. Die Fragmente werden beim System in einer Kette verwaltet, einer Pufferkette. Die Kette wird mit dem zweiten Fragment des Paketes initialisiert und auf folgende Weise ver­vollständigt:

Die Schritte sind also für jedes Fragment:

1. Zuteilung eines Pufferbereiches.
2. Kopieren des IP Headers und der Optionen in das Fragment. Bei den Optionen kann es Unterschiede von Fragment zu Fragment geben, die Aufgabe diese zuzuteilen, bekommt eine weitere Funktion, die ip.optcopy Funktion, die später noch genauer beschrieben wird.
3. Setzen des offset Feldes und des MF Bits. Wenn das MF Bit schon im ursprünglichen Paket gesetzt war (wenn es sich um ein Fragment han­delt), dann werden alle MF’s gesetzt, ist das zu fragmentierende Paket ein Datagramm, dann wird das letzte MF bit nicht gesetzt.
4. Setzen der Größe des Fragmentes. Es muß berücksichtigt werden, daß Op­tionen wegfallen können und das nicht jedes Fragment die gleiche Daten­menge enthällt (letztes Fragment).
5. Kopieren der Daten von dem ursprünglichen Paket in das Fragment. Die Funktion m_copy teilt weiteren Pufferbereich zu, falls nötig.
6. Anpassen der korrekte Größe des Headers von dem erzeugtem Fragment, Umwandeln einiger Felder ins Netzformat, berechnen der Prüfsumme (checks­um) und verketten des Fragmentes in die Kette der Puffer, hierfür wird eine weitere Funktion benutzt.

Das erstes Fragment der Liste wird anschliessend aus dem vordersten Daten des ursprünglichen Paketes geformt. In diesem Fragment werden alle Optionen beibehalten, denn bei dem Zielsystem werden nur die Optionen von dem ersten Fragment für das reassembling benutzt.

Einige Optionen wie Source Routing werden in jedes Fragment kopiert, ob­wohl sie dann beim Reassembly nicht verwendet werden. Die Optionen die nicht bei Reassembly benutzt werden sind aber nicht nutzlos, sie werden bei den Rou­tern verwendet. Zu diesem Zeitpunkt, steht die Output Processing Funktion eine komplette Liste mit den Fragmenten zur Verfügung, die der Reihe nach verschickt werden können. Wenn es vorkommt, daß ein Fehler beim Verschicken eines Fragmentes entsteht, werden die restlichen Fragmente nicht verschickt.

9.2.1 Die Ip_optcopy Funktion

Wie schon erwähnt, ist ip_optcopy dafür zuständig die Optionen von einem Da- tagramm oder von einem anderem System ankommende Pakete, in die Frag­mentierten Pakete zu kopieren, die weitergeleitet werden sollen. Es werden ip_optcopy ein Zeiger auf den Header des ankommenden Paketes und ein Zeiger auf den Header des Fragmentes, in das die Optionen kopiert werden sollen, über­geben. Es wird dann bei den Optionen des ankommenden Paketes überprüft, ob diese in die Fragmente kopiert werden sollen. Die Optionen werden einzeln in das Fragment kopiert und anschliessend wird geprüft, ob das Optionenfeld ein Vielfaches von 4 bytes ist. Ist dies nicht der Fall, so muß das Feld auf diese Länge angepaßt werden.

9.3 Reassembly

Die Reassembly Funktion ip_reass. ist eine Funktion aus Input Processing die dafür zuständig ist. Fragmente am Zielrechner zu einem Datagramm zusammen­zustellen. Der Reassembly Algorithmus wird aufgerufen, wenn dieser ein Paket erhält, daß ein Fragment ist. Bevor die Reassembly Funktion aufgerufen wird, muß für jedes ankommende Paket noch überprüft werden, ob es ein Fragment ist.

Um zu überprüfen, ob das Paket ein Fragment ist. wird der Inhalt des ip_off Feldes (siehe Datagrammaufbau in Abschnitt 3.1.5) benutzt. Wenn das MF bit und das offset nicht Null sind, dann handelt es sich um ein Fragment. Wenn beide Felder Null sind, dann handelt es sich um ein Datagramm. dieses kann dann an das Transportprotokoll weitergegeben werden.

Ist das ankommende Paket ein Fragment, so wird es in einen Puffer gespei­chert. Um die Datagramme zusammenzusetzen. wird eine aufwendige Struktur benutzt, die in Abb. 12 zu sehen ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Reassembly

Eine doppelt verkettete Liste, ipq. speichert die unvollständigen Datagram­me. Die Datenstruktur ist kompliziert, dies hat aber Vorteile bei ihrer Bearbei- tung, wie zum Beispiel das Löschen eines Datagrammes aus der Liste ipq, wenn das wiederherstellte Datagramm an die Transportschicht weitergereicht wird. Wird Input Processing ein weiteres Fragment übergeben, kann dieses anhand der eindeutigen Identifizierung (dem Vierertupel : ip_id, ip^src, ip_dst und ip_p) in das passende Datagramm in der ipq Liste eingeordnet werden, ipq wird linear durchgegangen, bis das passende Datagramm gefunden ist.

9.3.1 Die Ip_reass Funktion

Die meiste Arbeit beim Reassembly wird von der Funktion ip_reass geleistet. Sie gibt einen Zeiger auf ein Datagramm zurück, wenn das letzte verarbeitete Fragment ein Datagramm fertigstellen konnte. Wenn das verarbeitete Fragment nicht ein Datagramm vervollständigen konnte, wird dieses an der richtigen Stelle gespeichert (Zeiger werden so gesetzt, daß Fragment die richtige Stelle im Da­tagramm einnimmt). Ip_reass sammelt Fragmente eines gleichen Datagramme in eine ringförmig doppelt verkettete Liste, die Zeiger ipLnext und ipLprev ver­binden die Elemente, wie in Abb. 12 zu sehen ist. Die gleiche Abbildung zeigt den Zusammenhang der Fragment header list (ipq) und der Fragmente (ipas- frag). Aus der Abbildung ist viel Information über den Aufbau der Listen zu entnehmen.

1. Alle Strukturen sind in mbufs enthalten
2. Die ipq Listen sind aus ipq Strukturen zusammengesetzt, die mit next und prev Zeigern verbunden sind. In diesen Strukturen sind die vier Einträge gespeichert, die ein Datagramm eindeutig identifizieren.
3. Jede ipq Struktur wird wie eine ipasfrag Struktur behandelt, wenn die ver­kettete Liste aus Fragmenten bearbeitet wird. Die Fragmente sind durch ipLnext und ipLprev verbunden.
4. Jeder ipasfragüberliegt eine ip Struktur eines ankommenden Datagramme.

Abb. 12 beschreibt die direkte Verbindung zwischen den Strukturen die re­assembled werden. Die Abbildung ist ein Beispiel für drei Datagramme die zu­sammengestellt werden und zeigt den Zusammenhang zwischen der ipq Liste und der ipasfrag Strukturen. Der Header jeder reassembly Liste enthält: die id, Protokoll, Sender- und Zieladresse des ursprünglichen Datagramme.

9.3.2 Reassembly Timeout

In RFC 1122 wurde festgelegt, daß die Zeit fürs wiederherstellen eines Data­grammes von begrenzter Dauer ist. Hierfür wird das ipq.ttl Feld des Headers benutzt, daß für die TTL Angabe beim Weiterleiten eines Pakets nötig war. Ist das Paket aber schon am Ziel angekommen wird diese Angabe nicht mehr gebraucht, und das Feld bekommt eine neue Zeitangabe. Beim Ankommen des ersten Fragments eines Datagrammes wird die reassembly Zeit, 30 Sekunden, runtergezählt. Ist innerhalb dieser 30 Sekunden nicht der Rest der Fragmen­te dieses Datagrammes eingetroffen, wird die komplette Liste von Fragmenten verworfen.

9.3.3 Datagram Identifiers

Diese ermöglichen es ein Fragment in die richtige Position im Datagramm ein­zunehmen. Es kann Vorkommen, daß die gleichen Daten eines Datagrammes in mehr als einem Fragment ans Ziel kommen. Die Identifizierer eines Paketes ermöglichen es die passenden Daten der verschiedenen Fragmente zu identifizie­ren und so das Datagramm wieder zu erstellen.

Weitere Aufgaben, mit denen sich die Funktion ip_reass beschäftigen muß, ist den Header zu erstellen und die Paketlänge zu berechnen.

10 IP Routing L· Routing Tabellen

Routing ist eine weitere wichtige Aufgabe die von dem Internet Protokoll über­nommen wird. Routing beschäftigt sich mit der Bereitstellung der Routing Ta­bellen, die von dem Sender eines Datagrammes wie von den Routern benutzt wird um ein Paket an sein Ziel zu führen. Sie werden von der Forwarding und von der Output Processing Funktion benutzt, damit diese die Pakete richtig adressieren können. Routing Tabellen werden auf verschiedene Arten initiali­siert und bearbeitet. In einigen Fällen wird schon beim Hochfahren eines Rech­ners die fertige Routing Tabelle bereitgestellt, in ihr werden nur Änderungen vorgenommen, wenn Einträge in ihr nicht richtig sind. Dies kann der Fall sein, wenn ein System, das in der Routing Tabelle eingetragen ist ausfällt. ICMP Nachrichten werden an einen Sender eines Paketes verschickt, wenn das Paket zu einem anderen System geschickt werden sollte. Dies bedeutet aber nicht, daß das Sendersystem aufgefordert wird das Paket wieder zu verschicken. Es wird anhand dieser Meldung bewirkt, daß der Sender seine Routing Tabelle korrigiert. Manuell können auch mit dem Befehl “route” weitere Enträge vor­genommen werden. Ein Beispiel hierfür ist: route default 137.226.141.104 . Mit diesem Eintrag in die lokale Routing Tabelle wird es dem System möglich ge­macht, ein Paket das nicht zu den schon eingetragenen Zielrechnern verschickt werden soll, auch so eine möglichen Weg hat. Der Rechner 137.226.141.104 muß dann sehen, ob das Ziel erreicht werden kann oder das Paket verworfen wird. Es ist auch möglich, daß in Systemen die Tabellen fortlaufend aktualisiert werden. Hierfür sind spezielle Programme zuständig, die im Hintergrund laufen, auch Daemons genannt. In dem letzten Fall kann es sein, daß eine Tabelle nur mit einem Eintrag gestartet wird und mit der Zeit erweitert und aktualisiert wird. Wegen diesen verschiedenen Arten die Tabellen zu bearbeiten, wird zwischen Statischen und Dynamischen Routing Tabellen unterschieden. Dynamische Ta­bellen werden auch dadurch aktualisiert, daß Router in Verbindung stehen und Information über den momentanen Zustand des Netzes austauschen. Die Nach­richten die sich die Router verschicken werden Redirects genannt.

Routing Tabellen können bis zu hundert Mal in der Sekunde abgefragt wer­den, die Tabellen werden aber in der Regel ungefähr alle 30 Sekunden aktuali­siert. Aus diesem Grund kann es Vorkommen, daß ein Paket über den falschen Weg verschickt wird. Abb. 13 zeigt, daß man mit dem Befehl “netstat” die Ta­belle eines Systems ausgeben lassen kann.

In dieser Tabelle sind Zieladressen zu vier Systemen angegeben (erste Spalte)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Routing Tablo

zu donen in dor zweiten Spalto angegeben wird, welcher Router benutzt werden muß. Die erste Zieladresse ist ein Rechner im gleichen Netz (Routeradresse und Zieladresse unterscheiden sich nur in der letzten Stelle im Vierertupel. der die Adresse angibt). Das Flag G zeigt an. daß der Rechner 140.252.13.35 ein Router ist (G = Gateway). Die weiteren Flags zeigen an. daß der Router läuft (U = route is Up) und dass die Route zu einem Host führt (H = route is to a Host). Weiter erkennt man in der zweiten Zeile, daß die Tabelle auch einen loopback Eintrag hat. Dies wird durch den Adresstyp deutlich. Flags die in diesem Beispiel nicht Vorkommen sind: M. D . λ! soll angeben, daß der Eintrag von einem Redirect verändert wurde. D gibt an. daß der Eintrag von einem Redirect eingetragen wurde.

Die Tabelleneinträge müssen nicht in einer festgelegten Reihenfolge gespei­chert sein, aber wenn auf sie zugegriffen wird, geschieht dies in einer festgelegten Reihenfolge Routing Tabellen können verschieden komplex aufgebaut sein, dies hängt damit zusammen, zu welchen Netz das jeweilige System Zugang hat.

Die einfachsten Tabellen sind die der Systeme, die zu keinem Netz ange­schlossen sind. Die TCP/IP Protokolle können auf dem System installiert sein, aber nur um mit sich selbst zu kommunizieren. In diesem Fall enthält die Tabelle nur einen Eintrag für die loopback Schnittstelle.

An zweiter Stelle stehen die Tabellen in Systemen, die an einem LAN ange­schlossen sind, das System steht also nur in Verbindung mit den Rechnern in dem LAN. Die Tabelle enthält zwei Einträge: für die loopback Schnittstelle und für das LAN.

An dritter Stelle stehen die Tabellen, die bei Rechner benutzt werden, die Verbindugen zu einem weiteren Netzwerk haben. Der Eintrag der dazu kommt, ist eine default Adresse zu dem Router der die Verbindung zum Netzwerk ermöglicht.

An letzter Stelle stehen die Tabellen von Systemen, die Host- und Netzspe­zifische Routereinträge haben. Dies ist bei unserer Beispieltabelle der Fall.

Um das Thema der Routing Tabellen noch abzuschliessen. kann noch gesagt werden, daß das dynamische Routing ein Gebiet ist an dem noch viel gearbeitet wird. Die Wahl des Routing Protokolls und des Daemons ist eine komplexe Aufgabe. Auch diese Algorithmen werden noch fortlaufend verbessert.

11 IP Version 6

Es gibt einige Engpässe und Probleme, die die Entwicklung einer neuen Version des Internet Protokolls notwendig gemacht haben. Seit Anfang der 90er Jahre wurde deswegen an IP Version 6 (IPv6), dem Nachfolger von IPv4 im Internet, gearbeitet [5]. Es wird erwartet, daß es sich in den nächsten zehn Jahren im Internet durchsetzen wird. Die wesentlichen Unterschiede zur Vorgängerversion liegen im erweiterten Adreßraum. der Vereinfachung des Headerformats. und der Unterscheidung von Dienstgüte.

11.1 Adreßraum

Ein wesentliches Problem von IPv4 ist Größe des Adreßraumes. Bedingt durch die enorme Ausbreitung des Internets wird erwartet, daß in den nächsten fünf bis zehn Jahren der Zeitpunkt erreicht sein wird, daß es keine freien IPv4 Adressen mehr gibt. Dies macht den Einsatz eines neuen Protokolls mit einem größeren Adreßraum unumgänglich.

IPv6 erweitert den Adreßraum von zuvor 32 Bits auf 128 Bits, was wesentlich mehr Adressen zur Verfügung stellt. Darüber hinaus bietet IPv6 weitere Struk­turierungsmöglichkeiten. die über das Klassenkonzept von IPv4 hinaus gehen. Eine typische IPv6 besteht aus den Hierarchieebenen Register. Anbieter. Sub­scriber. Subnetz und Interface. Abb. ??? zeigt eine solche typische IPv6 Adresse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Eine anwenderspezifische Unicast Adresse

Der Register ist eine Institution, die die Adressen einer Region auf der Er­de verwaltet. Regionen sind unter anderem Europa. Asien, und Pazifik. Die Anbieter-ID definiert große Anbieter von Netzwerkdiensten, die ein Kontingent an Adressen zugeteilt bekommen. Die Aufteilung der Adressen ist bisher flexibel definiert worden, so daß jede Region dort seine eigene Aufteilung z.B. anhand eines zu IPv4 analogen Klassenkonzepts vornehmen kann. Der Anbieter wieder­um verteilt sein Adreßkontingent auf verschiedene Subscriber.

Die Subnetz- und Interface-ID umfassen zusammen 64 Bit. wobei der Subscri­ber die Aufteilung nicht wie bei IPv4 frei wählen kann. Die Interface ID ist die link-lokale Adresse der Interfacekarte, und hat eine vorgegebene Länge. Bei Ethernet ist dies die MAC Adresse mit einer Länge von 48 Bit. Somit stehen 16 Bit für die Subnetz ID zur Verfügung.

11.2 Der Headeraufbau

Ein weiteres Problem von IPv4 ist das stetig steigende Datenvolumen. das von Routern weitergeleitet werden muß. Der komplizierte Headeraufbau von IPv4 fordort daboi oiriori großen Zeitovorhoad. der in IPv6 durch einen vereinfach­ten Aufbau vermieden wird. Durch die beschleunigte Verarbeitung kann somit ein höherer Datendurchsatz erzielt werden. Abb. 15 zeigt den Aufbau des IPv6 Headers.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Aufbau des IPv6 Headers

Der IP Header hat nunmehr immer eine feste Länge von 40 Bytes. Optionale Daten folgen dem IP Header in sogenannten Optionsheadern. Hier wird zwischen Hop-То-Hop Optionsheadern. die in jedem Knoten gelesen werden müssen, und End-То-End Optionsheadern. die nur am Anfang und am Ende bearbeitet wer­den müssen, unterschieden. Dieser Aufbau hilft bei der schnellen Bearbeitung der Pakete, da ein Router nicht mehr alle Optionen Lesen und bearbeiten muß. sondern sich nur noch urn die Hop-To-Hop Header kümmern.

Ein Beispiel für beschleunigte Bearbeitung ist die Fragmentierung. Die Frag­mentierungsdaten sind nicht mehr im IP Header enthalten, sondern in einem End-То-End Fragmentierungsheader. so daß diese Information von Routern gar nicht beachtet werden muß. sondern nur beim Endpunkt von Relevanz ist. Der Absender fragmentiert, der Empfänger defragmentiert, für alle Zwischenknoten ist die Fragmentierungsinformation unwichtig.

11.3 Dienstgüte

In IPv4 ist es im Dienstart Feld möglich, die Dienstgüte des Datenpackets zu unterscheiden. Hier wird je nach Applikation (FTP. Telnet, etc.) in vier Bits abgelegt., welche Anforderungen bezüglich Verzögerung. Geschwindigkeit. Zu­verlässigkeit und Kosten an die Übertragung gestellt werden, wobei nur jeweils eines der vier Bits belegt sein darf. Verschiedene Anwendungen haben verschie­dene Anforderungen ans Routing: Bei FTP ist ein hoher Datendurchsatz wichtig, bei Telnet ist eine niedrige Verzögerung wichtig, usw.

Leider hat sich die Auswertung dieses Feldes in Routern nie durchgesetzt, so daß der Wert zwar oft von IP gesetzt wird, aber nicht beachtet wird. In IPv6 erhält dieses 4-Bit Feld nun den Namen Priorität und soll nun zu einer ernsthaften Un­terscheidung der Dienstgüte beitragen. Waren vorher nur 4 Werte möglich (nur eines der 4 Bits durfte gesetzt sein), sind nun alle 16 Kombinationen möglich. wobei 8 Werte für Realzeit-Anforderungen und 8 Werte für die restlichen Ap­plikationen zur Verfügung stehen.

Pakete mit höherer Priorität müssen nun von Routern bevorzugt behandelt wer­den. Dieses System kann aber nur funktionieren, wenn die Priorität eines Paketes irgendwie geregelt ist, so daß nicht alle Applikationen ihre Pakete plötzlich mit höchster Priorität senden. Dies soll durch ein prioritätsabhängiges Kostenmo­dell geregelt werden: Pakete von Realzeitapplikation mit hoher Priorität werden künftig teurer sein als solche mit niedriger Priorität. Die genauen Spezifikatio­nen des Abrechnungsmodells werden z.Zt. noch erarbeitet, um einen sinnvollen Einsatz dieses Prioritätsfeldes zu gewährleisten und Realzeitapplikationen zu ermöglichen.

12 Zusammenfassung

IPv4 hat sich im allgemeinen als ein gutes und zuverlässiges Protokoll bewährt. Dennoch sind im Laufe der Zeit die Bedürfnisse an das Protokoll und den ge­samten Internet verkehr so stark gestiegen, daß kleine Reparaturen an diesem Protokoll nicht mehr ausreichen, um den Verkehr im Internet des 21ten Jahr­hunderts zu regeln. Auch wenn die Migration auf IPv6 noch von vielen Syste­madministratoren gescheut wird, hat man beim Design von IPv6 durch Koexi­stenzmöglichkeiten einen langsamen Umschwung auf das neue Protokoll möglich gemacht.

Literatur

[1] Stevens, W. Richard (1994): TCP/IP Illustrated, Volume 1. The Protocols. Massatchusetts: Addison- Wesley
[2] Wright, Gary R.; Stevens, W. Richard (1994): TCP/IP Illustrated, Volume 2. The Implementation. Massatchusetts: Addison- Wesley
[3] Tanenbaum, Andrew S. (1990): Computer-Netzwerke. München: Wolfram’s Fachverlag
[4] Spaniol, Otto; Quernheim, Ulrich; Erti, Markus (1994): Datenkom­munikation I L· II. Skript zur Vorlesung. Aachen
[5] Ehlert, Andre (1998): Aufbau und Funktion des IP Version 6. http://www.edtv.ruhr-uni-bochum.de/dv/lehre/seminar/ipv6-i/

• Hochschule: Rheinisch-Westfälische Technische Hochschule Aachen
• Veranstaltung: Seminar Internettechnologie
• Autor: Marc Fasel (Autor:in)
• Erscheinungsjahr: 1999
• Seiten: 34
• Katalognummer: V96188
• ISBN (eBook): 9783638088657
• Sprache: Deutsch
• Schlagworte: Internet, Protokoll, Version, RWTH, Aachen, Seminar, Internettechnologie