Grundlagen Computernetze

Prof. Jürgen Plate

TCP/IP

Die Protokolle der TCP/IP-Familie wurden in den 70-er Jahren für den Datenaustausch in heterogenen Rechnernetzen (d. h. Rechner verschiedener Hersteller mit unterschiedlichen Betriebssystemen) entwickelt. TCP steht für 'Transmission Control Protocol' (Schicht 4) und IP für 'Internet Protocol' (Schicht 3). Die Protokollspezifikationen sind in sogenannten RFC-Dokumenten (RFC - Request for Comment) festgeschrieben und veröffentlicht. Aufgrund ihrer Durchsetzung stellen sie Quasi-Standards dar.

Die Schichten 5 - 7 des OSI-Standards werden hier in einer Anwendungsschicht zusammengefaßt, da die Anwendungsprogramme alle direkt mit der Transportschicht kommunizieren.

In Schicht 4 befindet sich außer TCP, welches gesicherten Datentransport (verbindungsorientiert, mit Flußkontrolle (d. h. Empfangsbestätigung, etc.) durch Windowing ermöglicht, auch UDP (User Datagram Protocol), in welchem verbindungsloser und ungesicherter Transport festgelegt ist. Beide Protokolle erlauben durch die Einführung von sogenannten Ports den Zugriff mehrerer Anwendungsprogramme gleichzeitig auf ein- und dieselbe Maschine.

In Schicht 3 ist das verbindungslose Internet-Protokoll (IP) angesiedelt. Datenpakete werden auf den Weg geschickt, ohne daß auf eine Empfangsbestätigung gewartet werden muß. IP-Pakete dürfen unter bestimmten Bedingungen (TTL=0, siehe unten) sogar vernichtet werden. In Schicht 3 werden damit auch die IP-Adressen festgelegt. Hier findet auch das Routing, das heißt die Wegsteuerung eines Paketes von einem Netz ins andere statt. Ebenfalls in diese Ebene integriert sind die ARP-Protokolle (ARP - Address Resolution Protocol), die zur Auflösung (= Umwandlung) einer logischen IP-Adresse in eine physikalische (z. B. Ethernet-) Adresse dienen und dazu sogenannte Broadcasts (Datenpakete, durch die alle angeschloßenen Stationen angesprochen werden) verwenden. ICMP, ein Protokoll, welches den Austausch von Kontroll- und Fehlerpaketen im Netz ermöglicht, ist ebenfalls in dieser Schicht realisiert.

Die Schichten 1 und 2 sind gegenüber Schicht 3 protokolltransparent. Sie können durch standardisierte Protokolle (z. B. Ethernet (CSMA/CD), FDDI, SLIP (Serial Line IP), PPP (Point-to-Point Protocol)) oder andere Übertragungsverfahren realisiert werden.

Zur TCP/IP-Familie gehören mehrere Dienstprogramme der höheren OSI-Schichten (5 - 7), z. B.:

 

Die TCP/IP-Protokolle

Der große Vorteil der TCP/IP-Protokollfamilie ist die einfache Realisierung von Netzwerkverbunden. Einzelne Lokale Netze werden über Router oder Gateways verbunden. Einzelne Hosts können daher über mehrere Teilnetze hinweg miteinander kommunizieren.
IP als Protokoll der Ebene 3 ist die unterste Ebene, die darunter liegenden Netzebenen können sehr unterschiedlich sein:

 
Internet-Protokolle
OSI-Schicht Internet Protokoll Suite DOD Schicht
7 Anwendung File Transfer Electronic
Mail		 Terminal Emulation Usenet News Domain Name Service World Wide Web Art der
Kommuni-
kation
6 Darstellung File Transfer Protocol (FTP)
RFC 959		 Simple Mail Transfer Protocol (SMTP)
RFC 821		 Telnet Protocol (Telnet)
RFC 854		 Usenet News Transfer Protocol (NNTP)
RFC 977		 Domain Name Service (DNS)
RFC 1034		 World Wide Web (WWW)
RFC		 Applikation
5 Sitzung
4 Transport Transmission Control Protocol (TCP)
RFC 793		 User Datagram Protocol (UDP)
RFC 768		 Host to Host Kommunikation
3 Netzwerk Address Resolution Protocol (ARP)
RFC 826		 Internet Protocol (IP)
RFC 791		 Internet Control Messsage Protocol
RFC 792		 Internet
2 Sicherung Ethernet Token Ring DQDB FDDI ATM lokales Netzwerk
1 Physikalische Übertragung Twisted Pair Lichtwellenleiter Coaxkabel Funk Laser Netzzugriff

Es ist offensichtlich, daß die Gateways neben dem Routing weitere nichttriviale Funktionen haben, wenn sie zwischen den unterschiedlichsten Teilnetzen vermitteln (z. B. unterschiedliche Protokolle auf Ebene 2, unterschiedliche Datenpaketgröße, usw.).

Aus diesem Grund existieren in einem Internet drei unabhängige Namens- bzw. Adressierungsebenen:

Die Ethernet-Adresse wurde bereits behandelt, auf die anderen beiden Ebenen wird in den folgenden Abschnitten eingegangen. Die Umsetzung der höchsten Ebene (Domain-Namen) in IP-Adressen erfolgt durch das oben erwähnte DNS, worauf die Dienstprogramm der Schichten 5-7 zurückgreifen.

 

ARP

Die Umsetzung einer IP-Adresse in eine Hardware-Adresse erfolgt durch Tabellen und auf Hardware-Ebene (z. B. Ethernet) automatisch über ARP (Adress Resolution Protocol). Dazu ein Beispiel:

Die Station A will Daten an eine Station B mit der Internetadresse I(B) senden, deren physikalische Adresse P(B) sie noch nicht kennt. Sie sendet einem ARP-Request an alle Stationen im Netz, der die eigene physikalische Adresse und die IP-Adresse von B enthält.

Alle Stationen erhalten und überprüfen den ARP-Request und die angesprochene Station B antwortet, indem sie einen ARP-Reply mit ihrer eigenen physikalischen Adresse an die Station A sendet. Letztere speichert die Zuordnung in einer Tabelle (Address Resolution Cache).

Auch für die Umkehrfunktion gibt es eine standardisierte Vorgehensweise, den RARP (Reverse ARP). Hier sendet die Station A unter Angabe ihrer physikalischen Adresse P(A) einen RARP-Request. Wenn im Netz nur eine Station als RARP-Server eingerichtet ist (eine Station, die alle Zuordnungen von P(x) <--> I(x) "kennt"), antwortet diese mit einem RARP-Reply an die anfragende Station, der I(A) enthält. Diese Funktion ist z. B. für sogenannte "Diskless Workstations" wichtig, die ihre gesamte Software von einem Server laden.

 

IP - Internet Protocol

Auf der Netzwerkschicht aufbauend liegt die Internet-Schicht, die die erste Abstraktionsschicht vom Transportmechanismus darstellt. Auf dieser Schicht 3 stellt das Internet-Protokoll (IP) den grundlegenden Netzdienst zur Verfügung, den Versand von Datenpaketen, sogenannten Datagrammen, über verschiedene Netze hinweg. Die Netzwerkschicht hat keine Information darüber, von welcher Art die Daten sind, die sie befördert. Nehmen wir als Beispiel das Ethernet: Von der Ethernet-Karte werden die vom Netz kommenden Daten an die Treibersoftware für die Karte weitergereicht. Diese interpretiert einen Teil dieser Daten als IP-Header und den Rest als Datenteil eines IP-Paketes. Auf diese Weise ist der IP-Header innerhalb eines Ethernet-Paketes eingekapselt. Aber auch das IP-Paket selbst enthält wieder ein Datenpaket für eine höhere Protokollebene (TCP), dessen Header auf der IP-Ebene als Bestandteil der Daten erscheint. Man kann sich das so vorstellen, wie die russischen Puppen, die ineinandergeschachtelt sind. Die kleinste Puppe ganz innen repräsentiert die Nutzdaten, alle außen herum geschachtelten Puppen sind 'Protokoll-Verpackung'.

IP ist ein verbindungsloses Protokoll. Es ist also nicht notwendig, eine IP-Verbindung zu einem Rechner zu 'öffnen', bevor man Daten zu diesem Rechner senden kann, sondern es genügt, das IP-Paket einfach abzusenden und darauf zu vertrauen, daß es schon ankommen wird. Bei einem verbindungsorientierten Protokoll wird beim Öffnen einer Verbindung getestet, ob der Zielrechner überhaupt erreichbar ist. Ein verbindungsloses Protokoll macht das nicht und kann demnach auch nicht garantieren, daß ein Datenpaket überhaupt beim Empfänger ankommt. IP garantiert auch nicht, daß von einem einmal abgeschickten Datenpaket nur eine Kopie beim Empfänger ankommt oder daß in einer bestimmten Reihenfolge abgeschickte Datenpakete auch wieder in dieser Reihenfolge empfangen werden.
Normalerweise laufen die IP-Pakete über mehrere Zwischenstationen, bis sie am Zielrechner ankommen. Bricht irgendwann während der Übertragung ein Übertragungsweg zusammen, so wird ein neuer Weg zum Ziel gesucht und benutzt. Da der neue Weg zeitlich länger oder kürzer sein kann als der alte, kann man keine allgemeingültigen Aussagen darüber machen, in welcher Reihenfolge IP-Pakete beim Empfänger eintreffen. Es kann auch sein, daß bei dieser Umschalterei IP-Pakete verlorengehen oder sich verdoppeln. Das Beheben der so entstehenden Probleme überläßt das IP-Protokoll anderen, höherliegenden Schichten.

Das Internet-Protokoll ist somit ein verbindungsloser Dienst mit einem 'Unreliable Datagram Service', d. h. es wird auf der IP-Ebene weder die Richtigkeit der der Daten noch die Einhaltung von Sequenz, Vollständigkeit und Eindeutigkeit der Datagramme überprüft. Ein zuverlässiger verbindungsorientierter Dienst wird in der darüberliegenden TCP-Ebene realisiert.

Ein IP-Datagramm besteht aus einem Header und einem nachfolgenden Datenblock, der seinerseits dann z. B. in einem Ethernet-Frame "verpackt" wird. Die maximale Datenlänge wird auf die maximale Rahmenlänge des physikalischen Netzes abgestimmt. Da nicht ausgeschlossen werden kann, daß ein Datagramm auf seinem Weg ein Teilnetz passieren muß, dessen Rahmenlänge niedriger ist, müssen zum Weitertransport mehrere (Teil-)Datagramme erzeugt werden. Dazu wird der Header im Wesentlichen repliziert und die Daten in kleiner Blöcke unterteilt. Jedes Teil-Datagramm hat also wieder einen Header. Diesen Vorgang nennt man Fragmentierung. Es handelt sich um eine rein netztechnische Maßnahme, von der Quell- und Zielknoten nicht wissen müssen. Es gibt natürlich auch eine umgekehrte Funktion, "Reassembly", die kleine Datagramme wieder zu einem größeren packt. Geht auf dem Übertragungsweg nur ein Fragment verloren, muß das gesamte Datagramm wiederholt werden. Es gilt die Empfehlung, daß Datagramme bis zu einer Länge von 576 Bytes unfragmentiert übertragen werden sollten.

 

Format des IP-Headers

 

Version
Kennzeichnet die IP-Protokollversion
IHL (Internet Header Length)
Die Angabe der Länge des IP-Headers erfolgt in 32-Bit-Worten (normalerweise 5). Da die Optionen nicht unbedingt auf Wortlänge enden, wird der Header gegebenenfalls aufgefüllt.
Type of Service
Alle Bits haben nur "empfehlenden" Charakter. 'Precedence' bietet die Möglichkeit, Steuerinformationen vorrangig zu befördern.
Total Length
Gesamtlänge des Datagramms in Bytes (max. 64 KByte).
Identification
Dieses und die beiden folgenden Felder steuern die Reassembly. Eindeutige Kennung eines Datagramms. Anhand dieses Feldes und der 'Source Address' ist die Zusammengehörigkeit von Fragmenten zu detektieren.
Flags
Die beiden niederwertigen Bits haben folgende Bedeutung:
Fragment Offset
Die Daten-Bytes eines Datagramms werden numeriert und auf die Fragmente verteilt. Das erst Fragment hat Offset 0, für alle weiteren erhöht sich der Wert um die Länge des Datenfeldes eines Fragments. Anhand dieses Wertes kann der Empfänger feststellen, ob Fragmente fehlen. Beispiel siehe unten.
Time-to-live (TTL)
Jedes Datagramm hat eine vorgegebene maximale Lebensdauer, die hier angegeben wird. Auch bei Routing-Fehlern (z. B. Schleifen) wird das Datagramm irgendwann aus dem Netz entfernt. Da Zeitmessung im Netz problematisch ist, und keine Startzeit im Header vermerkt ist, decrementiert jeder Gateway dieses Feld --> de-facto ein 'Hop Count'.
Protocol
Da sich unterschiedliche Protokolle auf IP stützen, muß das übergeordnete Protokoll (ULP, Upper Layer Protocol) angegeben werden. Wichtige ULPs sind
Header Checksum
16-Bit-Längsparität über den IP-Header (nicht die Daten)
Source Address
Internet-Adresse der Quellstation
Destinantion Address
Internet-Adresse der Zielstation
Options
Optionales Feld für weitere Informationen (deshalb gibt es auch die Header-Länge). Viele Codes sind für zukünftige Erweiterungen vorgesehen. Die Optionen dienen vor allem der Netzsteuerung, der Fehlersuche und für Messungen. Die wichtigsten sind:
Padding
Füllbits

Die Hauptaufgabe von IP ist es also, die Unterschiede zwischen den verschiedenen, darunterliegenden Netzwerkschichten zu verbergen und eine einheitliche Sicht auf die verschiedensten Netztechniken zu präsentieren. So gibt es IP nicht nur in Netzen, sondern auch als SLIP (Serial Line IP) oder PPP (Point to Point Protocol) für Modem- oder ISDN-Verbindungen. Zur Vereinheitlichung gehören auch die Einführung eines einheitlichen Adressierungsschemas und eines Fragmentierungsmechanismus, der es ermöglicht, große Datenpakete durch Netze mit kleiner maximaler Paketgröße zu senden: Normalerweise existiert bei allen Netzwerken eine maximale Größe für ein Datenpaket. Im IP-Jargon nennt man diese Grenze die 'Maximum Transmisson Unit' (MTU). Natürlich ist diese Obergrenze je nach verwendeter Hardware bzw. Übertragungstechnik unterschiedlich. Die Internet-Schicht teilt IP-Pakete, die größer als die MTU des verwendeten Netzwerks sind, in kleinere Stücke, sogenannte Fragmente, auf. Der Zielrechner setzt diese Fragmente dann wieder zu vollständigen IP-Paketen zusammen, bevor er sie an die darüberliegenden Schichten weitergibt. Der Fragement Offset gibt an, an welcher Stelle in Bezug auf den IP-Datagramm-Anfang das Paket in das Datagramm einzuordnen ist. Aufgrund des Offset werden die Pakete in die richtige Reihenfolge gebracht. Dazu ein Beispiel:

Es soll ein TCP-Paket mit einer Länge von 250 Byte über IP versandt werden. Es wird angenommen, daß ein IP-Header eine Länge von 20 Byte hat und eine maximale Länge von 128 Byte pro Paket nicht überschritten werden darf Der Identifikator des Datagramms beträgt 43 und der Fragmentabstand wird in 8-Byte-Schritten gezählt. Das Datenfragment muß also durch 8 dividierbar sein.

Da alle Fragmente demselben Datagramm angehören, wird der Identifikator für alle Fragmente beibehalten. Im ersten Fragment ist das Fragment Offset natürlich noch Null, das MF-Bit jedoch auf 1 gesetzt, um zu zeigen, daß noch Fragmente folgen. Im IP-Header des zweiten Fragments beträgt das Fragment Offset 13 (104/8 = 13) und zeigt die Position des Fragments im Datagramm an. Das MF-Bit ist noch immer 1, da noch ein Datenpaket folgt. Der Header des dritten Fragments enthält dann ein MF-Bit mit dem Wert 0, denn es handelt sich um das letzte Datenpaket zur Datagramm 43. Das Fragment Offset ist auf 26 gesetzt, da vorher schon 208 Daten-Bytes (8 * 26 = 208) übertragen wurden.
Sobald das erste Fragment (gleich welches) im Empfänger ankommt, wird ein Timer gesetzt. Sind innerhalb der dort gesetzten Zeit nicht alle Pakete zu einem Datagramm eingetroffen, wird angenommen, daß Fragmente verlorengingen. Der Empfänger verwirft dann alle Datenpakete mit diesem Identifikator.

Was geschieht aber, wenn der Kommunikationspartner nicht erreichbar ist? Wie schon erwähnt, durchläuft ein Datagramm mehrere Stationen. Diese Stationen sind in der Regel Router oder Rechner, die gleichzeitig als Router arbeiten. Ohne Gegenmaßnahme würde das Datenpaket für alle Zeiten durch das Netze der Netze irren. Dazu gibt es im IP-Header neben anderer Verwaltungsinfo auch ein Feld mit dem Namen TTL (Time To Live). Der Wert von TTL kann zwischen 0 und 255 liegen. Jeder Router, der das Datagramm transportiert, vermindert den Wert dieses Feldes um 1. Ist der Wert von TTL bei Null angelangt, wird das Datagramm vernichtet.

Die Adressen, die im Internet verwendet werden, bestehen aus einer 32 Bit langen Zahl. Damit sich die Zahl leichter darstellen läßt, unterteilt man sie in 4 Bytes (zu je 8 Bit). Diese Bytes werden dezimal notiert und durch Punkte getrennt (a.b.c.d). Zum Beispiel: 

    141.84.101.2
    129.187.10.25
Bei dieser Adresse werden zwei Teile unterscheiden, die Netzwerkadresse und die Rechneradresse, wobei unterschiedlich viele Bytes für beide Adressen verwendet werden:
Die Bereiche für die Netzwerkadresse ergeben sich durch die Zuordnung der ersten Bits der ersten Zahl (a), die eine Erkennung der Netz-Klassen möglich machen.

 

Netzklassen

 
  Klasse A - Netz Klasse B - Netz Klasse C - Netz
Netz-ID 8 Bit = 1 Byte 16 Bit = 2 Byte 24 Bit = 3 Byte
Host-ID 24 Bit = 3 Byte 16 Bit = 2 Byte 8 Bit = 1 Byte
Netzmaske 255.0.0.0 255.255.0.0 255.255.255.0
Adressklassen-ID
(= Feste Bits im 1. Byte, 1. Quad)		 0 10 110
Wertebereich (theoretisch) 0.0.0.0 bis 127.255.255.255 128.0.0.0 bis 191.255.255.255 192.0.0.0 bis 223.255.255.255
Anzahl der Netze 128 (= 27) 16384 (= 26*256
= 64*256)		 2097152 (= 25*256*256
= 32*256*256)
Anzahl der Rechner
im Netz		 16777216 (= 2563) 65536 (= 2562) 256 (= 2561)

 

Besondere Adreßklassen

 
  Klasse D Klasse E
Adressklassen-ID 4 Bit = "1110" 5 Bit = "11110"
keine Netz-ID, sondern: 28 Bit-Identifikator 27 Bit-Identifikator
Wertebereich 224.0.0.0 bis 239.255.255.255 240.0.0.0 bis 247.255.255.255
Anwendungen für Multicast-Gruppen reservierte Adressen für Zukünftiges

Grundsätzlich gilt:

In einem Netz der Klasse C können z. B. 254 verschiedene Rechner gekoppelt werden (Rechneradresse 1 bis 254). Die Hostadresse 0 wird für die Identifikation des Netzes benötigt und die Adresse 255 für Broadcast-(Rundruf-)Meldungen.

Die Netzwerkadresse 127.0.0.1 bezeichnet jeweils den lokalen Rechner (loopback address). Sie dient der Konsistenz der Netzwerksoftware (jeder Rechner ist über seine Adresse ansprechbar) und dem Test.

Damit man nun lokale Netze ohne Internetanbindung mit TCP/IP betreiben kann, ohne IP-Nummern beantragen zu müssen und um auch einzelne Rechnerverbindungen testen zu können, gibt es einen ausgesuchten Nummernkreis, der von keinen Router nach außen gegeben wird. Diese "privaten" Adressen sind im RFC 1597 festgelegt. Es gibt ein Class-A-Netz, 16 Class-B-Netze und 255 Class-C-Netze:

Zusätzlich hat die IANA auch das folgende Class-B-Netz für private Netze reserviert, das schon von Apple- und Microsoft-Clients verwendet wird, sofern kein DHCP-Server zur Verfügung steht. Das Verfahren heißt APIPA (Automatic Private IP Addressing):

Der für IP reservierte Adressraum reicht nicht mehr aus, um alle Endgeräte anzusteuern. Mögliche Abhilfen:

 

Network Address Translation (NAT) und IP-Masquerading

Die begrenzte Verfügbarkeit von IP-Adressen hat dazu geführt, daß man sich Gedanken über verschiedene Möglichkeiten machen mußte, wie man mit den existierenden Adressen ein größeres Umfeld abdecken kann. Eine Möglichkeit, um private Netze (und dazu gehört letztendlich auch ein privater Anschluß mit mehr als einem PC) unter Verwendung möglichst weniger Adressen an das Internet anzukoppeln stellen NAT, PAT und IP Masquerading. Alle Verfahren bilden private Adressen gemäß RFC 1918 oder einen proprietären (nicht registrierten) Adreßraum eines Netzes auf öffentliche registrierte IP-Adressen ab.

 

Subnetze

Nachdem nun klar ist, was ein Netz der Klasse A oder B ist, soll auf die Bildung von Subnetzen hingewiesen werden. Diese dienen dazu, ein bestehendes Netz in weitere, kleinere Netze zu unterteilen. Die Subnetzmaske dient dem Rechner dazu, die Zuordnung von Netzwerk-Teil und Host-Teil vorzunehmen. Sie hat denselben Aufbau wie eine IP-Adresse (32 Bit bzw. 4 Byte). Per Definition sind alle Bit des "Netzwerk-Teils" auf 1 zu setzen, alle Bit des "Host-Teils" auf 0. Für die o.a. Adreßklassen hat die Subnetzmaske demnach folgendes Aussehen:

 
Adreß-Klasse Subnetzmaske (binär) Subnetzmaske (dezimal)
Class A 11111111.00000000.00000000.00000000 255.0.0.0
Class B 11111111.11111111.00000000.00000000 255.255.0.0
Class C 11111111.11111111.11111111.00000000 255.255.255.0

Diese Subnetzmaske (auch "Default Subnetzmaske" genannt) kann manuell überschrieben werden.

Eine Subnet-Maske für ein Netz der Klasse C lautet daher 255.255.255.0. Das bedeutet, daß die ersten drei Bytes die Netzadresse angeben und das vierte Byte die Rechner adressiert. Eine Subnetz-Maske mit dem Wert 255.255.0.0 würde folglich ein Netz der Klasse B angeben und für ein C-Netz steht die Maske 255.255.255.0.

Aufteilung in Subnetze

 
Netzwerk-
anteil in Bit		 Hostanteil
in Bit		 Subnetz-
anzahl *)		 Hostanzahl **) Subnetzmaske
8 24 1 16777216 255.0.0.0       Klasse A
9 23 2 128*65536 255.128.0.0
10 22 4 64*65536 255.192.0.0
11 21 8 32*65536 255.224.0.0
12 20 16 16*65536 255.240.0.0
13 19 32 8*65536 255.248.0.0
14 18 64 4*65536 255.252.0.0
15 17 128 2*65536 255.254.0.0
16 16 1 65536 255.255.0.0       Klasse B
17 15 2 128*256 255.255.128.0
18 14 4 64*256 255.255.192.0
19 13 8 32*256 255.255.224.0
20 12 16 16*256 255.255.240.0
21 11 32 8*256 255.255.248.0
22 10 64 4*256 255.255.252.0
23 9 128 2*256 255.255.254.0
24 8 1 256 255.255.255.0       Klasse C
25 7 2 128 255.255.255.128
26 6 4 64 255.255.255.192
27 5 8 32 255.255.255.224
28 4 16 16 255.255.255.240
29 3 32 8 255.255.255.248
30 2 64 4 255.255.255.252

 

Anmerkungen:

Besitzt breispielsweise ein Unternehmen ein Netz der Klasse C, möchte man dieses vielleicht in zwei Segmente unterteilen, die voneinander getrennt sind. Der Broadcastverkehr des ersten Segments kann so das andere nicht beeinträchtigen. In diesem Fall kommt die Subnetz-Maske zum Einsatz, welche die Rechneradressen in zwei Bereiche gliedert. Sollen die Rechner in vier gleich große Subnetze mit je 64 Knoten eingeteilt werden, lautet die Subnetz-Maske 255.255.255.192. Es gilt die folgende Formel für das Maskier-Byte:

Bytewert = 256 - (Anzahl der Knoten im Segment)

Als das Subnetting erstmals standardisiert wurde, war es verboten die Subnetze zu nutzen, in denen alle Subnetzbits den Wert 0 oder 1 hatten (siehe Anmerkungen oben). Damit ergeben sich im Beispiel nur zwei Subnetze mit je 62 Hosts. Inzwischen beherrschen fast alle Systeme korrektes Subnetting ("classless" routing).

 

Beispiel: Aufteilung in 4 Subnetze

Ein Netz der Klasse C soll in vier gleich große Subnetze geteilt werden. Die Netzadresse beträgt 192.168.98.0. Der Administrator wählt daher zur Unterteilung die Subnetz-Maske 255.255.255.192. Die vier Rechner mit den IP-Adressen 192.168.98.3, 192.168.98.73. 192.168.98.156 und 192.168.98.197 befinden sich daher in vier Subnetzen zwischen denen geroutet werden muß. Broadcasts in Subnetz 1 werden somit nicht in die anderen Subnetze übertragen. Es ist nun zum Beispiel für das Unternehmen möglich, die Rechner des Vertriebs in Subnetz 1, die des Einkaufs in Subnetz 2, jene der Entwicklung in Subnetz 3 und ein Netz aus Demorechnern in Subnetz 4 zu organisieren. Damit ist gesichert, daß Störungen in einzelnen Subnetzen auch lokal auf diese beschränkt bleiben. Sie schlagen nicht auf die Datenstruktur des ganzen Unternehmens durch.

Allgemein ergibt sich für ein C-Netz folgende Aufstellung:

 

Subnetze eines C-Netzes

In Klammern die reduzierte Anzahl der Subnetze (Anzahl - 2). Die rot unterlegten Möglichkeiten sind dann in der Praxis nicht einsetzbar.

 
Subnetzbits Hostbits mögliche Subnetze Hostadressen Subnetzmaske
1 7 2 (0) 126 (0) 255.255.255.128
2 6 4 (2) 62 255.255.255.192
3 5 8 (6) 30 255.255.255.224
4 4 16 (14) 14 255.255.255.240
5 3 32 (30) 6 255.255.255.248
6 2 64 (62) 2 255.255.255.252
7 1 128 0 255.255.255.254

 

Beispiel: Aufteilung in 8 (6) Subnetze

Von den acht variabel verwendbaren Bits nutzt er also die drei höchstwertigen Bits für das Subnetz und die fünf letzten Bits für die Hostadresse. Die erste Adresse jedes Subnetz ist die Adresse in der alle Hostbits den Wert 0 haben.

 
  Subnetzbits Hostbits dezimal
Dezimale Wertigkeit des Bit 128 64 32 16 8 4 2 1  
erstes Subnetz 0 0 0 0 0 0 0 0 0
zweites Subnetz 0 0 1 0 0 0 0 0 32
drittes Subnetz 0 1 0 0 0 0 0 0 64
viertes Subnetz 0 1 1 0 0 0 0 0 96
fünftes Subnetz 1 0 0 0 0 0 0 0 128
sechstes Subnetz 1 0 1 0 0 0 0 0 160
siebtes Subnetz 1 1 0 0 0 0 0 0 192
achtes Subnetz 1 1 1 0 0 0 0 0 224

Damit sind die acht zur Verfügung stehenden Subnetze bekannt:

192.168.0.0/27
192.168.0.32/27
192.168.0.64/27
192.168.0.96/27
192.168.0.128/27
192.168.0.160/27
192.168.0.192/27
192.168.0.224/27

Anmerkung:

Diese Subnetze können jetzt einzelnen Netzen zugeordnet werden. Die folgende Tabelle zeigt die Netz- und Broadcastadressen von jedem einzelnen Subnetz und die Rechneradressen.

 
Subnetz IP-Adressen (letztes Oktett)
  Netz Hosts Broadcast
erstes Subnetz 0 1-30 31
zweites Subnetz 32 33-62 63
drittes Subnetz 64 65-94 95
viertes Subnetz 96 97-126 127
fünftes Subnetz 128 129-158 159
sechstes Subnetz 160 161-190 191
siebtes Subnetz 192 193-222 223
achtes Subnetz 224 225-254 255

 

ICMP - Internet Control Message Protocol

ICMP erlaubt den Austauch von Fehlermeldungen und Kontrollnachrichten auf IP-Ebene. ICMP benutzt das IP wie ein ULP, ist aber integraler Bestandteil der IP-Implementierung. Es macht IP nicht zu einem 'Reliable Service', ist aber die einzige Möglichkeit Hosts und Gateways über den Zustand des Netzes zu informieren (z. B. wenn ein Host temporär nicht erreichbar ist --> Timeout).

Die ICMP-Nachricht ist im Datenteil des IP-Datagramms untergebracht, sie enthält ggf. den IP-Header und die ersten 64 Bytes des die Nachricht auslösenden Datagramms (z. B. bei Timeout).

Die fünf Felder der ICMP-Message haben folgende Bedeutung:

Type
Identifiziert die ICMP-Nachricht
Code
Detailinformation zum Nachrichten-Typ
Checksum
Prüfsumme der ICMP-Nachricht (Datenteil des IP-Datagramms)
Identifier und Sequence-Nummer
dienen der Zuordnung eintreffender Antworten zu den jeweiligen Anfragen, da eine Station mehrere Anfragen aussenden kann oder auf eine Anfrage mehrere Antworten eintreffen können.

Wenden wir uns nun den einzelnen Nachrichtentypen zu:

Echo request/reply
Überprüfen der Erreichbarkeit eines Zielknotens. Es können Testdaten mitgeschickt werden, die dann unverändert zurückgeschickt werden (--> Ping-Kommando unter UNIX).
Destination unreachable
Im Codefeld wird die Ursache näher beschrieben: 0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable 4 Fragmentation needed 5 Source route failed
Source quench
Wenn mehr Datagramme kommen als eine Station verarbeiten kann, sendet sie diese Nachricht an die sendende Station.
Redirect
wird vom ersten Gateway an Hosts im gleichen Teilnetz gesendet, wenn es eine bessere Route-Verbindung über einen anderen Gateway gibt. In der Nachricht wird die IP-Adresse des anderen Gateways angegeben.
Time exceeded
Für diese Nachricht an den Quellknoten gibt es zwei Ursachen:
Parameter problem on a Datagramm
Probleme bei der Interpretation des IP-Headers. Es wird ein Verweis auf die Fehlerstelle und der fragliche IP-Header zurückgeschickt.
Timestamp request/reply
Erlaubt Zeitmessungen und -synchronisation im Netz. Drei Zeiten werden gesendet (in ms seit Mitternacht, Universal Time):
Information request/reply
Mit dieser Nachricht kann ein Host die Netid seines Netzes erfragen, indem er seine Netid auf Null setzt.
Address mask request/reply
Bei Subnetting (siehe unten) kann ein Host die Subnet-Mask erfragen.

 

UDP - User Datagram Protocol

UDP ist ein einfaches Schicht-4-Protokoll, das einen nicht zuverlässigen, verbindungslosen Transportdienst ohne Flußkontrolle zur Verfügung stellt. UDP ermöglicht zwischen zwei Stationen mehrere unabhängige Kommunikationsbeziehungen (Multiplex-Verbindung): Die Identifikation der beiden Prozesse einer Kommuninkationsbeziehung geschieht (wie auch bei TCP, siehe unten) durch Port-Nummern (kurz "Ports"), die allgemein bekannten Anwendungen fest zugeordnet sind. Es lassen sich aber auch Ports dynamisch vergeben oder bei einer Anwendung durch verschiedene Ports deren Verhalten steuern. Die Transporteinheiten werden 'UDP-Datagramme' oder 'User Datagramme' genannt. Sie haben folgenden Aufbau:

 

Source Port
Identifiziert den sendenden Prozeß (falls nicht benötigt, wird der Wert auf Null gesetzt).
Destination Port
Identifiziert den Prozeß des Zielknotens.
Length
Länge des UDP-Datagramms in Bytes (mindestens 8 = Headerlänge)
UDP-Checksum
Optionale Angabe (falls nicht verwendet auf Null gesetzt) einer Prüfsumme. Zu deren Ermittlung wird dem UDP-Datagramm ein Pseudoheader von 12 Byte vorangestellt (aber nicht mit übertragen), der u. a. IP-Source-Address, IP-Destination-Address und Protokoll-Nummer (UDP = 17) enthält.

 

TCP - Transmission Control Protocol

Welches übergeordnete Protokoll der Transportschicht das Datenpaket erhält, steht im 'Protokoll'-Feld eines jeden IP-Paketes. Jedes Protokoll der Transportschicht bekommt eine eindeutige Identifikationsnummer zugewiesen, anhand der die IP-Schicht entscheiden kann, wie weiter mit dem Paket zu verfahren ist. Eines der wichtigsten Protokolle der Transportschicht ist TCP.

Die Aufgabe von TCP ist es, die oben geschilderten Defizite von IP zu verbergen. Für den TCP-Benutzer soll es nicht mehr sichtbar sein, daß die darunterliegenden Protokollschichten Datenpakete versenden, sondern es soll der Benutzer mit einem Byte-Strom wie bei einer normalen Datei (oder einem Terminal) arbeiten können. TCP garantiert vor allen Dingen den korrekten Transport der Daten - jedes Paket kommt nur einmal, fehlerfrei und in der richtigen Reihenfolge an. Zusätzlich können bei TCP mehrere Programme die Verbindung zwischen zwei Rechnern quasi-gleichzeitig nutzen. TCP teilt die Verbindung in viele virtuelle Kanäle ("Ports") auf, die zeitmultiplex mit Daten versorgt werden. Nur so ist es möglich, daß beispielsweise mehrere Benutzer eines Rechners zur selben Zeit das Netz in Anspruch nehmen können oder daß man mit einer einzigen Wählverbindung zum Provider gleichzeitig E-Mail empfangen und Dateien per FTP übertragen kann.

Dieses Protokoll implementiert also einen verbindungsorientierten, sicheren Transportdienst als Schicht-4-Protokoll. Die Sicherheit wird durch positive Rückmeldungen (acknowledgements) und Wiederholung fehlerhafter Blöcke erreicht. Fast alle Standardanwendungen vieler Betriebssysteme nutzen TCP und das darunterliegende IP als Transportprotokoll, weshalb man die gesamte Protokollfamilie allgemein unter 'TCP/IP' zusammenfaßt. TCP läßt sich in lokalen und weltweiten Netzen einsetzen, da IP und die darunterliegenden Schichten mit den unterschiedlichsten Netzwerk- und Übertragungssystemen arbeiten können (Ethernet, Funk, serielle Leitungen, ...). Zur Realisierung der Flußkontrolle wird ein Fenstermechanismus (sliding windows) verwendet (variable Fenstergröße). TCP-Verbindungen sind vollduplex. Wie bei allen verbindungsorientierten Diensten muß zunächst eine virtuelle Verbindung aufgebaut und bei Beendigung der Kommunikation wieder abgebaut werden. "Verbindungsaufbau" bedeutet hier eine Vereinbarung beider Stationen über die Modalitäten der Übertragung (z. B. Fenstergröße, Akzeptieren eines bestimmten Dienstes, usw.). Ausgangs- und Endpunkte einer virtuellen Verbindung werden wie bei UDP durch Ports identifiziert. Allgemein verfügbare Dienste werden über 'well known' Ports (--> feste zugeordnete Portnummer) erreichbar. Andere Portnummern werden beim Verbindungsaufbau vereinbart.

Damit die ständige Bestätigung jedes Datensegments den Transport nicht über Gebühr hemmt, werden zwei Tricks verwendet. Zum einen kann die Empfangsbetätigung einem Segment in Gegenrichtung mitgegeben werden - das spart ein separates Quittungssegment. Zweitens muß nicht jedes Byte sofort bestätigt werden, sondern es gibt ein sogenanntes 'Fenster'. Die Fenstergröße gibt an, wieviele Bytes gesendet werden dürfen, bis die Übertragung quittiert werden muß. Erfolgt keine Quittung, werden die Daten nochmals gesendet. Die empfangene Quittung enthält die Nummer des Bytess, das als nächstes vom Empfänger erwartet wird - womit auch alle vorhergehenden Bytes quittiert sind. Die Fenstergröße kann dynamisch mit der Quittung des Empfängers geändert werden. Werden die Ressourcen knapp, wird die Fenstergröße verringert. Beim Extremfall Null wird die Übertragung unterbrochen, bis der Empfänger erneut quittiert. Neben einem verläßlichen Datentransport ist so auch die Flußkontrolle gewährleistet.

Das Prinzip des Fenstermechanismus ist eigentlich ganz einfach. Wenn man das Bild betrachtet, ergibt sich folgende Sachverhalt:

Das TCP-Paket wird oft auch als 'Segment' bezeichnet. Jedem TCP-Block ist ein Header vorangestellt, der aber wesentlich umfangreicher als die bisherigen ist:

 

Source Port
Identifiziert den sendenden Prozeß.
Destination Port
Identifiziert den Prozeß des Zielknotens.
Sequence Number
TCP betrachtet die zu übertragenden Daten als numerierten Bytestrom, wobei die Nummer des ersten Bytes beim Verbindungsaufbau festgelegt wird. Dieser Bytestrom wird bei der Übertragung in Blöcke (TCP-Segmente) aufgeteilt. Die 'Sequence Number' ist die Nummer des ersten Datenbytes im jeweiligen Segment (--> richtige Reihenfolge über verschiedene Verbindungen eintreffender Segmente wiederherstellbar).
Acknowledgement Number
Hiermit werden Daten von der Empfängerstation bestätigt, wobei gleichzeitig Daten in Gegenrichtung gesendet werden. Die Bestätigung wird also den Daten "aufgesattelt" (Piggyback). Die Nummer bezieht sich auf eine Sequence-Nummer der empfangenen Daten; alle Daten bis zu dieser Nummer (ausschließlich) sind damit bestätigt --> Nummer des nächsten erwarteten Bytes. Die Gültigkeit der Nummer wird durch das ACK-Feld (--> Code) bestätigt.
Data Offset
Da der Segment-Header ähnlich dem IP-Header Optionen enthalten kann, wird hier die Länge des Headers in 32-Bit-Worten angegeben.
Res.
Reserviert für spätere Nutzung
Code
Angabe der Funktion des Segments:
Window
Spezifiziert die Fenstergröße, die der Empfänger bereit ist anzunehmen - kann dynamisch geändert werden.
Checksum
16-Bit Längsparität über Header und Daten.
Urgent Pointer
Markierung eines Teils des Datenteils als dringend. Dieser wird unabhängig von der Reihenfolge im Datenstrom sofort an das Anwenderprogramm weitergegeben (URG-Code muß gesetzt sein). Der Wert des Urgent-Pointers markiert das letzte abzuliefernde Byte; es hat die Nummer <Sequence Number> + <Urgent Pointer>.
Options
Dieses Feld dient dem Informationsaustausch zwischen beiden Stationen auf der TCP-Ebene, z. B. die Segmentgröße (die Ihrerseits von der Größe des IP-Datagramms abhängen sollte, um den Durchsatz im Netz optimal zu gestalten).

 

Ablauf einer TCP-Session

Im Gegensatz zu IP ist TCP verbindungsorientiert. Das muß so sein, denn TCP-Verbindungen sollen ja für den Benutzer prinzipiell wie Dateien zu handhaben sein. Das bedeutet, eine TCP-Verbindung wird wie eine Datei geöffnet und geschlossen, und man kann ihre Position innerhalb des Datenstroms bestimmen, genau wie man bei einer Datei die Position der Lese- oder Schreibposition angeben kann. TCP sendet die Daten auch in größeren Einheiten, um den Verwaltungsaufwand durch Header- und Kontrollinformationen klein zu halten. Im Gegensatz zu den IP-Paketen bezeichnet man die Einheiten der Transportschicht als "Segmente". Jedes gesendete TCP-Segment hat eine eindeutige Folgenummer, welche die Position seines ersten Bytes im Byte-Strom der Verbindung angibt. Anhand dieser Nummer kann die Reihenfolge der Segmente korrigiert und doppelt angekommene Segmente können aussortiert werden. Da die Länge des Segments aus dem IP-Header bekannt ist, können auch Lücken im Datenstrom entdeckt werden, und der Empfänger kann verlorengegangene Segmente neu anfordern.

Beim Öffnen einer TCP-Verbindung tauschen beide Kommunikationspartner Kontrollinformationen aus, die sicherstellen, daß der jeweilige Partner existiert und Daten annehmen kann. Dazu schickt die Station A ein Segment mit der Aufforderung, die Folgenummern zu synchronisieren.
Das einleitende Paket mit gesetztem SYN-Bit ("Synchronise-" oder "Open"-Request) gibt die Anfangs-"Sequence Number" des Client bekannt. Diese Anfangs-"Sequence Number wird zufällig bestimmt. Bei allen nachfolgenden Paketen ist das ACK-Bit ("Acknowledge", "Quittung") gesetzt. Der Server antwortet mit ACK, SYN und der Client bestätigt mit ACK. Das sieht dann so aus:

Die Station B weiß jetzt, daß der Sender eine Verbindung öffnen möchte und an welcher Position im Datenstrom der Sender anfangen wird zu zählen. Sie bestätigt den Empfang der Nachricht und legt ihrerseits eine Folgenummer für Übertragungen in Gegenrichtung fest.

Station A bestätigt nun den Empfang der Folgenummer von B und beginnt dann mit der Übertragung von Daten.

Diese Art des Austausches von Kontrollinformationen, bei der jede Seite die Aktionen der Gegenseite bestätigen muß, ehe sie wirksam werden können, heißt "Dreiwege-Handshake". Auch beim Abbau einer Verbindung wird auf diese Weise sichergestellt, daß beide Seiten alle Daten korrekt und vollständig empfangen haben. Im zeitlichen Zusammenhang stellt sich eine TCP/IP-Verbindung folgendermaßen dar:

Das folgende Beispiel zeigt die Arbeitsweise des TCP/IP - Protokolls. Es wird eine Nachricht von einem Rechner im grünen Netz zu einem Rechner im orangen Netz gesendet.

 
Die Nachricht wird in mehrere Pakete aufgeteilt und auf der besten Route auf die Reise geschickt. Das verbindungslose IP-Protokoll sorgt zusammen mit den Routern für den Weg.
Da eine Strecke überlastet ist, werden die Pakete 3, 4 und 5 auf einer anderen Strecke weiter transportiert. Dieser Transport erfolgt zufälligerweise schneller als jener der Pakete 1 und 2.
Die Pakete wandern ihrem Bestimmungsnetz entgegen. Das erste Paket ist bereits angekommen. Paket 3 kommt vor Paket 2 am Ziel an.
Die Pakete 1, 2 und 3 sind - in falscher Reihenfolge - am Zielrechner angekommen. Auf der Strecke, auf der Pakete 4 und 5 transportiert werden, tritt eine Störung auf.
Paket 4 ist bei der Störung verloren gegangen. Paket 5 wird auf einer anderen Route zum Zielnetz geschickt (wären die Routen statisch am Router eingetragen, ginge auch Paket 5 verloren).
Alle überlebenden Pakete sind am Zielrechner angekommen. Das TCP-Protokoll setzt die Pakete wieder in der richtigen Reihenfolge zusammen und fordert das fehlende Paket 4 nochmals beim Sender an. Für den Empfänger ergibt sich ein kontinuierlicher Datenstrom.

 

TCP-Zustandsübergangsdiagramm

Den gesamte Lebenszyklus einer TCP-Verbindung beschreibt die folgende Grafik in einer relativ groben Darstellung.

Erklärung der Zustände:

 

Die Hauptmerkmale von TCP

Normalerweise stützen sich Programme auf Anwendungseben auf mehrere der Protokolle (ICMP, UDP, TCP).

 

Ports für jeden Dienst

Server-Prozesse lauschen bei UDP und TCP auf bestimmten Portnummern. Per Übereinkunft werden dazu Ports niedriger Nummern verwendet. Für die Standarddienste sind diese Portnummern in den RFCs festgeschrieben. Ein Port im "listen"-Modus ist gewissermaßen eine halboffene Verbindung. Nur Quell-IP und Quellport sind bekannt. Der Serverprozeß kann vom Betriebssystem dupliziert werden, so daß weitere Anfragen auf diesem Port behandelt werden können.

 

Die "well known" Portnummern (0 bis 1023), die weltweit eindeutig adressiert werden müssen, werden durch die IANA (Internet Assigned Numbers Authority) vergeben. Einige Beispiele für TCP-Ports (UDP verwendet eine andere Zuordnung):

 
Portnummer Protokoll
20 FTP (Daten)
21 FTP (Befehle)
22 Secure Shell
23 Telnet
25 SMTP
53 DNS-Server
70 Gopher
79 Finger
80 HTTP (Proxy-Server)
110 POP3
119 NNTP
143 IMAP
194 IRC
210 WAIS
256 - 1023 UNIX-spezifische Services
540 UUCP
1024 - 49151 Registered Ports
49152 - 65535 Dynamic / Private Ports

Eine vollständige Portliste erhält man bei http://www.isi.edu/in-notes/iana/assignments/port-numbers.

IP-Adresse und Portnummer definieren einen Kommunikationsendpunkt, der in der TCP/IP-Welt "Socket" genannt wird. Die Grenze zwischen der Anwendungsschicht und der Transportschicht ist in den meisten Implementierungen zugleich die Grenze zwischen dem Betriebssystem und den Anwendungsprogrammen. Im OSI-Modell ist diese Grenze in etwa die Grenze zwischen den Schichten 4 und 5. Daher ordnet man IP meist ungefähr in die Ebene 3 und TCP ungefähr in Ebene 4 des OSI-Modells ein. Da TCP/IP jedoch älter und einfacher als das OSI-Modell ist, kann diese Einordnung nicht genau passen.

 

IP Next Generation

Das rasche (exponentielle Wachstum) des Internet zwingt dazu, das Internet Protokoll in der Version 4 (IPv4) durch ein Nachfolgeprotokoll (IPv6 Internet Protocol Version 6) zu ersetzen.

Vinton Cerf (der 'Vater' des Internet) bezeichnet in einem Interview mit der Zeitschrift c't das Internet "(...) als die wichtigste Infrastruktur für alle Arten von Kommunikation.". Auf die Frage, wie man sich die neuen Kommunikationsdienste des Internet vorstellen könne, antwortete Cerf:

 

"Am spannendsten finde ich es, die ganzen Haushaltsgeräte ans Netz anzuschließen. Ich denke dabei nicht nur daran, daß der Kühlschrank sich in Zukunft mit der Heizung austauscht, ob es in der Küche zu warm ist. Stromgesellschaften könnten beispielsweise Geräte wie Geschirrspülmaschinen kontrollieren und ihnen Strom genau dann zur Verfügung stellen, wenn gerade keine Spitzennachfrage herrscht. Derartige Anwendungen hängen allerdings davon ab, daß sie zu einem erschwinglichen Preis angeboten werden. Das ist nicht unbedingt ferne Zukunftsmusik; die Programmierer müßten eigentlich nur damit anfangen, endlich Software für intelligente Netzwerkanwendungen zu schreiben. Und natürlich muß die Sicherheit derartiger Systeme garantiert sein. Schließlich möchte ich nicht, daß die Nachbarkinder mein Haus programmieren!"

Auf die Internet Protokolle kommen in der nächsten Zeit also völlig neue Anforderungen zu.

 

Classless InterDomain Routing - CIDR

Der Verknappung der Internet-Adressen durch die ständig steigende Benutzerzahl wird zunächst versucht, mit dem Classless Inter-Domain Routing (CIDR) entgegen zu wirken. Durch die Vergabe von Internet-Adressen in Klassen (A,B,C,...) wird eine große Anzahl von Adressen verschwendet. Hierbei stellt sich vor allem die Klasse B als Problem dar. Viele Firmen nehmen ein Netz der Klasse B für sich in Anspruch, da ein Klasse A Netz mit bis zu 16 Mio. Hosts selbst für eine sehr große Firma überdimensioniert scheint, ein Netz der Klasse C mit 254 Hosts aber zu klein.

Ein größerer Host-Bereich für Netze der Klasse C (z. B. 10 Bit, 1022 Hosts pro Netz) hätte das Problem der knapper werdenden IP-Adressen vermutlich gemildert. Ein anderes Problem wäre dadurch allerdings entstanden: die Einträge der Routing-Tabellen hätten sich um ein Vielfaches vermehrt.

Ein anderes Konzept ist das Classless Inter-Domain Routing (RFC 1519): die verbleibenden Netze der Klasse C werden in Blöcken variabler Größe zugewiesen. Werden beispielsweise 2000 Adressen benötigt, so können einfach acht aufeinanderfolgende Netze der Klasse C vergeben werden. Zusätzlich werden die verbliebenen Klasse-C-Adressen restriktiver und strukturierter vergeben (RFC 1519). Die Welt ist dabei in vier Zonen aufgeteilt, von denen jede einen Teil des verbliebenen Klasse C Adreßraums erhält:

194.0.0.0 - 195.255.255.255 Europa
198.0.0.0 - 199.255.255.255 Nordamerika
200.0.0.0 - 201.255.255.255 Mittel- und Südamerika
202.0.0.0 - 203.255.255.255 Asien und pazifischer Raum
204.0.0.0 - 223.255.255.255 Reserviert für zukünftige Nutzung

Jede der Zonen erhält dadurch in etwa 32 Millionen Adressen zugewiesen. Vorteil bei diesem Vorgehen ist, daß die Adressen einer Region im Prinzip zu einem Eintrag in den Routing-Tabellen komprimiert worden sind und jeder Router, der eine Adresse außerhalb seiner Region zugesandt bekommt diese getrost ignorieren darf.

 

Internet Protokoll Version 6 - IPv6 (IP Next Generation, IPnG)

Der vorrangige Grund für eine Änderung des IP-Protokolls ist auf den begrenzten Adreßraum und das Anwachsen der ROuting-Tabellen zurückzuführen. CIDR schafft hier zwar wieder etwas Luft, dennoch ist klar absehbar, daß auch diese Maßnahme nicht ausreicht, um die Verknappung der Adressen für eine längere Zeit in den Griff zu bekommen. Weitere Gründe für eine Änderung des IP-Protokolls sind die neuen Anforderungen an das Internet, denen IPv4 nicht gewachsen ist. Streaming-Verfahren wie Real-Audio oder Video-on-Demand erfordern das Festlegen eines Mindestdurchsatzes, der nicht unterschritten werden darf. Bei IPv4 kann so ein "Quality of Service" jedoch nicht definiert - und damit auch nicht sichergestellt - werden. Die IETF (Internet Engineering Task Force) begann deshalb 1990 mit der Arbeit an einer neuen Version von IP. Die wesentlichen Ziele des Projekts sind: Im Dezember 1993 forderte die IETF mit RFC 1550 die Internet-Gemeinde dazu auf, Vorschläge für ein neues Internet Protokoll zu machen. Auf die Anfrage wurde eine Vielzahl von Vorschlägen eingereicht. Diese reichten von nur geringfügigen Änderungen am bestehenden IPv4 bis zur vollständigen Ablösung durch ein neues Protokoll. Aus diesen Vorschlägen wurde von der IETF das Simple Internet Protocol Plus (SIPP) als Grundlage für die neue IP-Version ausgewählt.

Als die Entwickler mit den Arbeiten an der neuen Version des Internet Protokolls begannen, wurde ein Name für das Projekt bzw. das neue Protokoll benötigt. Angeregt durch die Fernsehserie "Star Trek - Next Generation", wurde als Arbeitsname IP - Next Generation (IPnG) gewählt. Schließlich bekam das neue IP eine offizielle Versionsnummer zugewiesen: IP Version 6 oder kurz IPv6. Die Protokollnummer 5 (IPv5) wurde bereits für ein experimentelles Protokoll verwendet.

 

Die Merkmale von IPv6

Viele der Merkmale von IPv4 bleiben in IPv6 erhalten. Trotzdem ist IPv6 im allgemeinen nicht mit IPv4 kompatibel, wohl aber zu den darüberliegenden Internet-Protokollen, insbesondere den Protokollen der Transportschicht (TCP, UDP). Die wesentlichen Merkmale von IPv6 sind:

 

Aufbau des IPv6-Basis-Headers

Im IPv6 wird im Vergleich zum IPv4 auf eine Checksumme verzichtet, um den Routern die aufwendige Überprüfung - und damit Rechenzeit - zu ersparen. Ein Übertragungsfehler muss deshalb in den höheren Schichten erkannt werden. Der Paketkopf ist durch die Verschlankung nur doppelt so groß, wie ein IPv4-Header.

 

Version:
Mit dem Feld Version können Router überprüfen, um welche Version des Protokolls es sich handelt. Für ein IPv6-Datengramm ist dieses Feld immer 6 und für ein IPv4-Datengramm dementsprechend immer 4. Mit diesem Feld ist es möglich für eine lange Zeit die unterschiedlichen Protokollversionen IPv4 und IPv6 nebeneinander zu verwenden. Über die Prüfung des Feldes Version können die Daten an das jeweils richtige "Verarbeitungsprogramm" weitergeleitet werden.
Priority:
Durch das Feld Priority (oder Traffic Class) kann angegeben werden, ob ein Paket bevorzugt behandelt werden muß. Dies ist für die Anpassung des Protokolls an die neuen Real Time Anwendungen nötig geworden. Damit können zum Beispiel Videodaten den E-Maildaten vorgezogen werden. Bei einem Router unter Last besteht damit die Möglichkeit der Flusskontrolle. Pakete mit kleinerer Priorität werden verworfen und müssen wiederholt werden.Mit den vier Bit lassen sich 16 Prioritäten angeben, wovon 1 bis 7 für "Non Real Time"- und 8 bis 15 für "Real Time"-Anwendungen reserviert sind. Die Zahl Null gibt an, dass die Priorität des Verkehrs nicht charakterisiert ist.
Flow Label
Mit Hilfe des Feldes Flow Label können Eigenschaften des Datenflusses zwischen Sender und Empfänger definiert werden. Das Flow Label selbst ist nur eine Zufallszahl. Die Eigenschaften müssen durch spezielle Protokolle oder durch den Hop-by-Hop-Header in den Routern eingestellt werden. Eine Anwendung ist zum Beispiel, daß die Pakete eines Flusses immer den gleichen Weg im Netz nehmen. Durch Speichern der Informationen für das jeweilige Flow-Label, muß der Router bestimmte Berechnungen nur für das erste Paket ausführen, und kann danach für alle Folgepakete die Resultate verwenden. Erst die Einführung des Flow Labels ermöglicht die Einführung von Quality-of-Service-Parametern im IP-Verkehr.
Payload Length
Das Feld Payload Length (Nutzdatenlänge) gibt an, wie viele Bytes dem IPv6-Basis-Header folgen, der IPv6-Basis-Header ist ausgeschlossen. Die Erweiterungs-Header werden bei der Berechnung der Nutzdatenlänge mit einbezogen. Das entsprechende Feld wird in der Protokollversion 4 mit Total Length bezeichnet. Allerdings bezieht IPv4 den 20 Byte großen Header auch in die Berechnung ein, wodurch die Bezeichnung "total length" gerechtfertigt ist.
Next Header
Das Feld Next Header gibt an, welcher Erweiterungs-Header dem IPv6-Basis-Header folgt. Jeder folgende Erweiterungs-Header beinhaltet ebenfalls ein Feld Next Header, das auf den nachfolgenden Header verweist. Beim letzten IPv6-Header, gibt das Feld an, welches Transportprotokoll (z.B. TCP oder UDP) folgt.
Hop Limit
Im Feld Hop Limit wird festgelegt, wie lange ein Paket überleben darf. Der Wert des Feldes wird von jedem Router vermindert. Ein Datengramm wird verworfen, wenn das Feld den Wert Null hat. IPv4 verwendete hierzu das Feld Time to Live. Die Bezeichnung bringt mehr Klarheit, da schon in IPv4 die Anzahl Hops gezählt und nicht die Zeit gemessen wurde.
Source Address, Destination Address
Die beiden Felder für Quell- und Zieladresse dienen zur Identifizierung des Senders und Empfängers eines IP-Datengramms. Bei IPv6 sind die Adressen vier mal so groß wie IPv4: 128 Bit statt 32 Bit.

Das Feld Length (Internet Header Length - IHL) von IPv4 ist nicht mehr vorhanden, da der IPv6-Basis-Header eine feste Länge von 40 Byte hat. Das Feld Protocol wird durch das Feld Next Header ersetzt. Alle Felder die bisher zur Fragmentierung eines IP-Datengramms benötigt wurden (Identification, Flags, Fragment Offset), sind im IPv6-Basis-Header nicht mehr vorhanden, da die Fragmentierung in IPv6 gegenüber IPv4 anders gehandhabt wird. Alle IPv6-kompatiblen Hosts und Router müssen Pakete mit einer Größe von 1280 Byte unterstützen. Empfängt ein Router ein zu großes Paket, so führt er keine Fragmentierung mehr durch, sondern sendet eine Nachricht an den Absender des Pakets zurück, in der er den sendenden Host anweist, alle weiteren Pakete zu diesem Ziel aufzuteilen. Es wird also vom Hosts erwartet, daß er von vornherein eine passende Paketgröße wählt. Die Steuerung der Fragmentierung erfolgt bei IPv6 über den Fragment Header. Das Feld Checksum ist nicht mehr vorhanden.

 

Erweiterungs-Header im IPv6

Bei IPv6 muß nicht mehr der ganze optionale Teil des Headers von allen Routern verarbeitet werden, womit wiederum Rechenzeit eingespart werden kann. Diese optionalen Header werden miteinander verkettet. Jeder optionale Header beinhaltet die Identifikation des folgenden Header. Es besteht auch die Möglichkeit selber Optionen zu definieren.

Derzeit sind sechs Erweiterungs-Header definiert. Alle Erweiterungs-Header sind optional. Werden mehrere Erweiterungs-Header verwendet, so ist es erforderlich, sie in einer festen Reihenfolge anzugeben.

Header Beschreibung
IPv6-Basis-Header Zwingend erforderlicher IPv6-Basis-Header
Optionen für Teilstrecken
(Hop-by-Hop Options Header)		 Dies ist der einzige optionale Header, der von jedem Router bearbeitet werden muß. Bis jetzt ist nur die "Jumbo Payload Option" definiert, in der die Länge eines Paketes angegeben werden kann, das länger als 64 KByte ist.
Optionen für Ziele
(Destination Options Header)		 Zusätzliche Informationen für das Ziel
Routing
(Routing Header)		 Definition einer vollständigen oder teilweisen Route. Er wird für das Source-Routing in IPv6 verwendet.
Fragmentierung
(Fragment Header)		 In IPv6 wird, wie oben beschrieben, die Fragmentierung nur noch End to End gemacht. Die Fragmentierinformationen werden in diesem optionalen Header abgelegt.
Authentifikation
(Authentication Header)		 Er dient der digitalen Signatur von Paketen, um die Quelle eindeutig feststellen zu können.
Verschlüsselte Sicherheitsdaten
(Encapsulating Security Payload Header)		 Informationen über den verschlüsselten Inhalt.
Optionen für Ziele
(Destination Options Header)		 Zusätzliche Informationen für das Ziel (für Optionen, die nur vom endgültigen Ziel des Paketes verarbeitet werden müssen).
Header der höheren Schichten
(Upper Layer Header)		 Header der höheren Protokollschichten (TCP, UDP, ...)

 

IPv6-Adressen

Die IPv6-Adressen sind zwar von 32 Bit auf 128 Bit angewachsen, trotzdem sind die grundsätzlichen Konzepte gleich geblieben. Die Adresse wird normalerweise Sedezimal (Hexadezimal, Basis 16) notiert und hat die allgemeine Form 
  xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
Sie ist damit recht länglich. Um die Schreibweise zu vereinfachen, wurden einige Regeln eingeführt:

In IPv4 wurden die Adressen anfänglich in die bekannten Klassen eingeteilt. Ein weiteres Problem bei den IPv4 Adressen ist, daß die Router keine Hierarchie in den Adressen erkennen können. Auch IPv6 ist in der allgemeinen Form unstrukturiert, es kann aber durch definierte Präfixe strukturiert werden. Die allgemein strukturiert Adresse sieht danach wie folgt aus:

Die Strukturierung erlaubt die Einteilung der Adresse in Adresstypen. Jeder Präfix identifiziert somit einen Adresstyp. Die bereits definierten Adresstypen und die zugehörigen Präfixe sind:

Adresstyp Präfix (binär)
Reserviert für IPv4 und Loopback 0000 0000
NSAP-Adressen 0000 001
IPX-Adressen 0000 010
Anbieterbasierte Unicast-Adresse 010
Reserviert für geografische Unicast-Adresse 100
Zusammenfassbare globale Adressen 001
Standortlokale Adresse 1111 1110 11
Multicast-Adresse 1111 1111

Wie man in der Tabelle erkennen kann, werden die Adressen grob in die Typen Unicast, Multicast und Anycast eingeteilt, deren Eigenschaften nachfolgend kurz erklärt werden sollen.

Sicherheit

Der Bedarf an digitalen Unterschriften oder elektronischen Zahlungsmöglichkeiten steigt ständig. Deshalb stand bei der Spezifikation von IPv6 die Sicherheit von Anfang an im Mittelpunkt. Für die Sicherheitsfunktionen von IPv6 ist eine spezielle Arbeitsgruppe "IPSec" zuständig.
In IPv6 wurden Sicherheitsmechanismen für die Authentisierung und Verschlüsselung auf IP Ebene spezifiziert. Die Verschlüsselungsfunktionen definieren Verfahren, die das Mitlesen durch Unbefugte verhindern. Es gibt zwei unterschiedliche Ansätze. Bei der ersten Variante werden alle Nutzdaten (Payload) verschlüsselt. Der Header bleibt normal lesbar. Bei der anderen Variante ist es möglich, den Header ebenfalls zu verschlüsseln. Das codierte Paket wird in ein anderes IPv6-Packet verpackt und zu einem fixen Ziel befördert ("IP-Tunnel"). Am Ziel wird das Paket wieder entschlüsselt und über das sichere interne Netz übertragen.

Authentisierungsmechanismen liefern den Beweis auf Unverfälschtheit der Nachricht und identifiziert den Absender (Digitale Unterschrift). Hier werden verschiedene kryptographische Verfahren eingesetzt. Die Verfahren für die Verschlüsselung und die Authentisierung können auch getrennt angewandt werden. Verwaltung und Verteilung der Schlüssel wird nicht von IPv6 gelöst. Das Standardverfahren für den IPv6-Authentisierungsmechanismus ist MD5 mit 128 Bit langen Schlüsseln. IPv6 schreibt keinen Verschlüsselungsmechanismus vor, jedes System im Internet muß jedoch den DES mit CBD (Cipher Block Chaining) unterstützen.

mit freundlicher Unterstützung von Herrn Prof. Jürgen Plate