Tcp/ip

Grundlagen

Was ist ein Rechnernetz?

Diese Frage habe ich mir auch längere Zeit gestellt. Die Literatur äußert sich hierzu leider auch nicht so ganz klar. Tanenbaum "definiert" ein Rechnernetz in [Ta96] wie folgt:

"Das ganze Buch hindurch wird der Begriff Rechnernetze für mehrere miteinander verbundene autonome Computer verwendet. Zwei Computer gelten als miteinander verbunden, wenn sie Informationen austauschen können. Die Verbindung muß nicht aus einem Kupferkabel bestehen - es können auch Lichtwellenleiter, Mikrowellen oder Kommunikationssatelliten benutzt werden. Die Vorgabe, daß die Computer autonom sein müssen schließt Systeme, bei denen ein eindeutiges Master/Slave-Verhältnis herrscht, von vornherein aus unserer Definition aus. Kann ein Computer einen anderen beliebig ein- oder ausschalten oder steuern, besteht keine Unabhängigkeit. Ein System mit einer Steuereinheit als Master und vielen Slaves ist kein Netz, ebensowenig wie ein Großrechner mit entfernten Druckern und Terminals."

Nach dieser Definition ist ein Netz, das aus einer Anzahl von Java-Rechnern (oder sind es doch nur Terminals) besteht kein Rechnernetz. Die Java- Rechner müssen ihr System erst aus dem Netz laden, bevor mit ihnen "autonom" gearbeitet werden kann. Die Frage ist hier zusätzlich: arbeiten Java-Rechner wirklich autonom? Deshalb möchte ich noch eine allgemeinere "Definition" eines Rechnernetzes aus [Co98] geben:

"Das alte Modell, bei dem ein Großrechner den gesamten Rechenaufwand eines Unternehmens bewältigte, wurde durch eines ersetzt, bei dem eine große Anzahl einzelner miteinander verbundener Rechner die Arbeit übernimmt. Ein solches System nennt man Rechnernetz."

Protokolle, Protokollhierarchien

Protokolle sind Regeln, die den Nachrichtenaustausch - oder allgemeiner das Verhalten - zwischen (Kommunikations)Partnern regeln ("Protocols are formal rules of behaviour"). Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie sogar gänzlich unmöglich. Ein Beispiel für ein Protokoll "aus dem täglichen Leben" ist z.B. der Funkverkehr: Die Kommunikationspartner bestätigen den Empfang einer Nachricht mit Roger und leiten einen Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindung schließlich mit Over and out. Ähnliche Protokolle werden auch beim Datenaustausch zwischen verschiedenen Computern benötigt - auch wenn hier die Komplexität der Anforderungen etwas höher ist. Aufgrund dieser höheren Komplexität werden viele Aufgabe nicht von einem einzigen Protokoll abgewickelt. In der Regel kommen eine ganze Reihe von Protokollen, mit verschiedenen Teilaufgaben, zum Einsatz. Diese Protokolle sind dann in Form von Protokollschichten mit jeweils unterschiedlichen Funktionen angeordnet.

Anordnung von Protokollen zu einem Protokollstapel.

Eine kurze Geschichte des Internet

From small things, big things sometimes come (Tittel E., Robbins M.) Gegen Ende der sechziger Jahre, als der "kalte Krieg" seinen Höhepunkt erlangte, wurde vom US-Verteidigungsministerium (Department of Defence - DoD) eine Netzwerktechnologie gefordert, die in einem hohen Maß gegenüber Ausfällen sicher ist. Das Netz sollte dazu in der Lage sein, auch im Falle eines Atomkrieges weiter zu operieren. Eine Datenübermittlung über Telefonleitungen war zu diesem Zweck nicht geeignet, da diese gegenüber Ausfällen zu verletzlich waren (sind). Aus diesem Grund beauftragte das US-Verteidigungsministerium die Advanced Research Projects Agency (ARPA) mit der Entwicklung einer zuverlässigen Netztechnologie. Die ARPA wurde 1957 als Reaktion auf den Start des Sputniks durch die UdSSR gegründet. Die ARPA hatte die Aufgabe Technologien zu entwickeln, die für das Militär von Nutzen sind. Zwischenzeitlich wurde die ARPA in Defense Advanced Research Projects Agency (DARPA) umbenannt, da ihre Interessen primär militärischen Zwecken dienten. Die ARPA war keine Organisation, die Wissenschaftler und Forscher beschäftigte, sondern verteilte Aufträge an Universitäten und Forschungsinstitute.

Um die geforderte Zuverlässigkeit des Netzes zu erreichen, fiel die Wahl darauf, das Netz als ein paketvermitteltes Netz (packet-switched network) zu gestalten. Bei der Paketvermittlung werden zwei Partner während der Kommunikation nur virtuell miteinander verbunden. Die zu übertragenden Daten werden vom Absender in Stücke variabler oder fester Länge zerlegt und über die virtuelle Verbindung übertragen; vom Empfänger werden diese Stücke nach dem Eintreffen wieder zusammengesetzt. Im Gegensatz dazu werden bei der Leitungsvermittlung (circuit switching) für die Dauer der Datenübertragung die Kommunikationspartner fest miteinander verbunden. Ende 1969 wurde von der University of California Los Angeles (UCLA), der University of California Santa Barbara (UCSB), dem Stanford Research Institute (SRI) und der University of Utah ein experimentelles Netz, das ARPANET, mit vier Knoten in Betrieb genommen. Diese vier Universitäten wurden von der (D)ARPA gewählt, da sie bereits eine große Anzahl von ARPA-Verträgen hatten. Das ARPA-Netz wuchs rasant (siehe Abbildung) und überspannte bald ein großes Gebiet der Vereinigten Staaten

Wachstum des ARPANET a)Dezember 1969 b)July 1970 c)März 1971 d)April 1971 e)September 1972.(Quelle: A.S. Tanenbaum: Computernetworks ) Mit der Zeit und dem Wachstum des ARPANET wurde klar, daß die bis dahin gewählten Protokolle nicht mehr für den Betrieb eines größeren Netzes, das auch mehrere (Teil)Netze miteinander verband, geeignet war. Aus diesem Grund wurden schließlich weitere Forschungsarbeiten initiiert, die 1974 zur Entwicklung der TCP/IP-Protokolle bzw. des TCP/IP-Modells führten. TCP/IP wurde mit mit der Zielsetzung entwickelt, mehrere verschiedenartige Netze zur Datenübertragung miteinander zu verbinden. Um die Einbindung der TCP/IP-Protokolle in das ARPANET zu forcieren beauftragte die (D)ARPA die Firma Bolt, Beranek & Newman (BBN) und die University of California at Berkeley zur Integration von TCP/IP in Berkeley UNIX. Dies bildete auch den Grundstein des Erfolges von TCP/IP in der UNIX-Welt. Im Jahr 1983 wurde das ARPANET schließlich von der Defence Communications Agency (DCA), welche die Verwaltung des ARPANET von der (D)ARPA übernahm, aufgeteilt. Der militärische Teil des ARPANET, wurde in ein separates Teilnetz, das MILNET, abgetrennt, das durch streng kontrollierte Gateways vom Rest des ARPANET - dem Forschungsteil - separiert wurde. Nachdem TCP/IP das einzige offizielle Protokoll des ARPANET wurde, nahm die Zahl der angeschlossenen Netze und Hosts rapide zu. Das ARPANET wurde von Entwicklungen, die es selber hervorgebracht hatte, überrannt. Das ARPANET in seiner ursprünglichen Form existiert heute nicht mehr, das MILNET ist aber noch in Betrieb. (Zum Wachstum des Internet in Deutschland siehe: http://www.nic.de/Netcount/netStatHosts.html) Die Sammlung von Netzen, die das ARPANET darstellte, wurde zunehmend als Netzverbund betrachtet. Dieser Netzverbund wird heute allgemein als das Internet bezeichnet. Der Leim, der das Internet zusammenhält, sind die TCP/IP-Protokolle.

RFCs

Eine wichtige Rolle bei der Entstehung und Entwicklung des Internet spielen die sogenannten RFCs - Request for Comments. RFCs sind Dokumente, in denen die Standards für TCP/IP bzw. das Internet veröffentlicht werden. Einige RFCs beschreiben Dienste und Protokolle sowie deren Implementierung, andere fassen Regeln und Grundsätze (policies) zusammen. Standards für TCP/IP werden immer als RFCs veröffentlicht, aber nicht alle RFCs beschreiben Standards (siehe z.B. RFC1180 - A TCP/IP Tutorial, RFC527 - ARPAWOCKY, RFC968 - 'Twas the Night Before Start-up etc.) Die Standards für TCP/IP werden im wesentlichen nicht durch ein Komitee entwickelt, sondern durch Diskussion und Konsens beschlossen. Jeder hat die Möglichkeit ein Dokument als RFC zu veröffentlichen und so zur Diskussion zu stellen. Ist ein Dokument veröffentlicht, wird ihm eine RFC- Nummer zugewiesen. Die Dokumente werden von einer Arbeitsgruppe und/oder dem RFC-Editor geprüft. Dabei durchläuft das Dokument verschiedene Stufen, die Stufen der Entwicklung, Testung und Akzeptanz. Die Stufen bilden den sogenannten Standards Process. Die Stufen werden formal als maturity levels (Reifestufen) bezeichnet.

Maturity Level
Proposed Standard (PS)	Diese Stufe dauert mindestens 6 Monate und erfordert zwei unabhängige Implementierungen.
Draft Standard (DS)	Diese Stufe dauert mindestens 4 Monate mit Demonstrationen und einem Erfahrungsbericht mit midestens zwei unabhängigen Implementierungen.
Standard (S oder STD)	Das RFC ist zum offiziellen Standard erhoben. Internet-Standards erhalten neben der RFC- Nummer eine sogenannte STD-Nummer (z.B. Internet Protocol, RFC791, STD-5).

Zusätzlich zu seiner Stufe bekommt ein RFC einen Status

Status
Required	Muß bei allen TCP/IP-basierten Hosts und Gateways implementiert werden.
Recommended	Es wird empfohlen, daß alle TCP/IP-basierten Hosts und Gateways die Spezifikationen des RFCs implementieren. Diese RFCs werden üblicherweise auch immer implementiert.
Elective	Die Implementierung ist optional. Der Anwendung wurde zugestimmt, ist aber nicht erforderlich.
Limited Use	Nicht für die generelle Nutzung gedacht.
Not recommended	Nicht zur Implementierung empfohlen.

Ein RFC, das einmal veröffentlicht ist, wird nie verändert oder aktualisiert. Es kann nur durch ein neues RFC ersetzt werden. Bei einer Ersetzung wird das alte RFC mit der Bezeichnung "Obsoleted by RFC xxx" gekennzeichnet, das neue RFC beinhaltet einen Hinweis "Obsolets RFC xxx" auf das alte RFC. Korrekturen an einem RFC werden durch "Updates RFC xxx" und "Updated by RFC xxx" gekennzeichnet. Einige RFCs beschreiben Protokolle, die durch bessere ersetzt wurden, diese RFCs werden durch die Bezeichnung "historic" gekennzeichnet. Ein entsprechender Standard erhält den Status "not recommended". RFCs, die sich in einer experimentellen Phase der Entwicklung befinden werden mit der Bezeichnung "experimental" versehen. Protokolle, die von anderen Organisationen oder von Firmen entwickelt wurden und von Interesse für das Internet sind werden zum Teil auch in RFCs veröffentlicht mit den Bezeichnungen "informational" oder "best current practice". Das 'System' der RFCs leistet einen wesentlichen Beitrag zum Erfolg von TCP/IP und dem Internet. In der Referenzliste findet sich eine Angaben zu Quellen, bei denen die RFCs bezogen werden können. Anm.: Wer weitere Quellen zur Geschichte des Internet sucht, wird hier fündig:

Internet Society - ISOC: History of the Internet

Musch J.: Die Geschichte des Netzes: ein historischer Abriß

Hauben M.: Behind the Net: The Untold History of the ARPANET and Computer Science

Hauben R.: The Birth and Development of the ARPANET

w3history: Die Geschichte des World Wide Web

Logische Struktur von Netzen

In diesem Abschnitt wird ganz knapp die logische Struktur von Netzen behandelt, also die Art und Weise, wie die einzelnen Stationen miteinander verbunden werden. Bei der Verkabelung von LANs muß man aber zwischen logischer Stuktur und Verkabelungsstruktur unterscheiden, z. B. kann ein Netz mit logischer Busstruktur bei der Verkabelung mit 'Twisted Pair'-Kabeln wie ein Sternnetz aussehen.

Sternstruktur

Alle Teilnehmer werden an einen zentralen Knoten angeschlossen (früher z. B. häufig Anschluß von Sichtgeräten an einen Zentralrechner). Eine direkte Kommunikation der Teilnehmer untereinander ist nicht möglich, jegliche Kommunikation läuft über den zentralen Knoten (Punkt-zu-Punkt-Verbindung, Leitungsvermittlung). Die Steuerung der Kommunikation vom Knoten aus ist sehr einfach: Polling (regelmäßige Abfrage aller Stationen) oder Steuerung über Interrupt. Bei Ausfall der Zentrale sind sämtliche Kommunikationswege unterbrochen.

Ringstruktur

Es gibt keine Zentrale, alle Stationen sind gleichberechtigt. Jeder Teilnehmer verfügt über einen eigenen Netzanschluß (Knoten) und ist über diesen mit seinem linken und rechten Partner verbunden. Die Übertragung der Info erfolgt in einer Richtung von Knoten zu Knoten. Bei Ausfall eines Knotens sind sämtliche Kommunikationswege unterbrochen.

Busstruktur

Es gibt keine Zentrale und keine Knoten. Die Verbindung aller Teilnehmer erfolgt über einen gemeinsamen Übertragungsweg. Zu einem Zeitpunkt kann immer nur eine Nachricht über den Bus transportiert werden. Bei Ausfall einer Station bleibt die Kommunikation der anderen Stationen erhalten. Bei den Bussystemen kann man noch unterscheiden in Basisband-Bussysteme und Breitband-Bussysteme. Bei Basisband-Bussystemen werden die elektrischen Pegel direkt übertragen; bei den für uns interessanten digitalen Informationen also 0- und 1-Pegel. Bei Breitband-Bussystemen werden über das Kabel mehrere unabhängige Kanäle geleitet (modulierte Übertragung). Busnetze müssen auf beiden Seiten mit der Leitungsimpedanz abgeschlossen werden, damit keine Echos auftreten, die zu Empfangsfehlern führen.

vermaschte Struktur

Jeder Teilnehmer ist mit mehreren anderen verbunden. Es gibt keine Zentrale und es existieren mehrere, unabhängige Übertragungswege zwischen zwei Stationen. Manchmal gibt es keine direkte Verbindung zwischen zwei Stationen. Dann führt der Weg über eine oder mehrere andere Stationen.

Je nach Bedarf können die o. g. Topologien auch miteinander kombiniert werden, z. B. Bus mit angeschlossenen Sternen oder Bus mit angeschlossenen Bussen, was zu einer Baumstruktur führt. Insbesondere bei Weitverkehrsnetzen (WAN) treten vermaschte Strukturen auf. Teilweise ergeben sich dabei redundante Leitungswege, die auch bei Unterbrechung eines Wegs den Datentransport sicherstellen.

Referenzmodelle

Das OSI-Referenzmodell

Das Open Systems Interconnection (OSI)-Referenzmodell ist ein Modell, daß auf einem Vorschlag der International Standards Organisation (ISO) basiert. Der Aufbau des OSI-Modells ist in der folgenden Abbildung dargestellt.

OSI-Referenzmodell

Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von Protokollcharakteristika und -funktionen (Ta96). Das OSI-Modell (die offizielle Bezeichnung lautet ISO-OSI-Referenzmodell) besteht aus sieben Schichten. Die Schichtung beruht auf dem Prinzip, daß eine Schicht der jeweils über ihr angeordneten Schicht bestimmte Dienstleistungen anbietet. Das OSI-Modell ist keine Netzarchitektur, da die Protokolle und Dienste der einzelnen Schichten vom Modell nicht definiert werden. Das Modell beschreibt lediglich, welche Aufgaben die Schichten erledigen sollen. Die folgenden Prinzipien haben zur Siebenschichtigkeit des OSI-Modells geführt (Ta96): Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird. Jede Schicht sollte eine genau definiert Funktion erfüllen. Bei der Funktionswahl sollte die Definition international genormter Protokolle berücksichtigt werden. Die Grenzen zwischen den einzelnen Schichten sollten so gewählt werden, daß der Informationsfluß über die Schnittstellen möglichst gering ist. Die Anzahl der Schichten sollte so groß sein, daß keine Notwendigkeit besteht, verschiedene Funktionen auf eine Schicht zu packen, aber so klein, daß die gesamte Architektur nicht unhandlich wird.

Aufgaben der Schichten OSI

Den Schichten im OSI-Modell sind die folgenden Aufgaben zugeordnet:

Anwendungsschicht (application layer)

Die Anwendungsschicht enthält eine große Zahl häufig benötigter Protokolle, die einzelne Programme zur Erbringung ihrer Dienste definiert haben. Auf der Anwendungsschicht finden sich z.B. die Protokolle für die Dienste ftp, telnet, mail etc.

Darstellungsschicht (presentation layer)

Die Darstellungsschicht regelt die Darstellung der Übertragungsdaten in einer von der darüber liegenden Ebene unabhängigen Form. Computersysteme verwenden z.B. oft verschiedene Codierungen für Zeichenketten (z.B. ASCII, Unicode), Zahlen usw. Damit diese Daten zwischen den Systemen ausgetauscht werden können, kodiert die Darstellungsschicht die Daten auf eine standardisierte und vereinbarte Weise.

Sitzungsschicht (session layer)

Die Sitzungsschicht (oft auch Verbindungsschicht oder Kommunikationssteuerschicht genannt) ermöglicht den Verbindungsauf- und abbau. Von der Sitzungsschicht wird der Austausch von Nachrichten auf der Transportverbindung geregelt. Sitzungen können z.B. ermöglichen, ob der Transfer gleichzeitig in zwei oder nur eine Richtung erfolgen kann. Kann der Transfer jeweils in nur eine Richtung stattfinden, regelt die Sitzungsschicht, welcher der Kommunikationspartner jeweils an die Reihe kommt.

Transportschicht (transport layer)

Die Transportschicht übernimmt den Transport von Nachrichten zwischen den Kommunikationspartnern. Die Transportschicht hat die grundlegende Aufgaben, den Datenfluß zu steuern und die Unverfälschtheit der Daten sicherzustellen. Beispiele für Transportprotokolle sind TCP und UDP.

Netzwerkschicht (network layer)

Die Netzwerkschicht (Vermittlungsschicht) hat die Hauptaufgabe eine Verbindung zwischen Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei die übergeordneten Schichten von den Details der Datenübertragung über das Netzwerk befreien. Eine der wichtigsten Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das Routing vom Absender zum Empfänger. Das Internet Protokoll (IP) ist in der Netzwerkschicht einzuordnen.

Sicherungsschicht (data link layer)

Die Aufgabe der Sicherungsschicht (Verbindungsschicht) ist die gesicherte Übertragung von Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt und sequentiell an den Empfänger gesendet. Vom Empfänger werden die empfangenen Daten durch Bestätigungsrahmen quittiert. Protokollbeispiele für die Sicherungsschicht sind HDLC (high-level data link control), SLIP (serial line IP) und PPP (point-to-point Protokoll).

Bitübertragungsschicht (physical layer)

Die Bitübertragungsschicht regelt die Übertragung von Bits über das Übertragungsmedium. Dies betrifft die Übertragungsgeschwindigkeit, die Bit-Codierung, den Anschluß (wieviele Pins hat der Netzanschluß?) etc. Die Festlegungen auf der Bitübertragungsschicht betreffen im wesentlichen die Eigenschaften des Übertragungsmedium.

Das TCP/IP-Referenzmodell

Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In diesem Abschnitt soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt werden. Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen TCP und IP der Netzarchitektur beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI- Standardisierung eingeflossen. Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus nur vier Schichten: Application Layer, Transport Layer, Internet Layer, Network Layer. Als Ziele der Architektur wurden bei der Entwicklung definiert:

• Unabhängigkeit von der verwendeten Netzwerk-Technologie

• Unabhängigkeit von der Architektur der Hostrechner

• Universelle Verbindungsmöglichkeiten im gesamten Netzwerk

• Ende-zu-Ende-Quittungen

• Standardisierte Anwendungsprotokolle.

Vergleich des OSI-Referenzmodells mit dem TCP/IP-

Referenzmodell

Aufgaben der Schichten TCP/IP

Applikationsschicht (application layer)

Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfaßt alle höherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen TELNET (für virtuelle Terminals), FTP (Dateitransfer) und SMTP (zur Übertragung von E- Mail). Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitere Protokolle wie z.B. DNS (Domain Name Service) und HTTP (Hypertext Transfer Protocol) hinzu.

Transportschicht (transport layer)

Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-Protokolle definiert: das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll, durch das ein Bytestrom fehlerfrei einen anderen Rechner im Internet übermittelt werden kann. UDP ist ein unzuverlässiges verbindungsloses Protokoll, das vorwiegend für Abfragen und Anwendungen in Client/Server-Umgebungen verwendet wird, in denen es in erster Linie nicht um eine sehr genaue, sondern schnelle Datenübermittlung geht (z.B. Übertragung von Sprache und Bildsignalen).

Internetschicht (internet layer)

Die Internetschicht im TCP/IP-Modell definiert nur ein Protokoll namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige Rolle. Das Internet Control Message Protocol (ICMP) ist fester Bestandteil jeder IP-Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das Internet Protocol.

Netzwerkschicht (network layer)

Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke. Das Referenzmodell sagt auf dieser Ebene nicht viel darüber aus, was hier passieren soll. Festgelegt ist lediglich, daß zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netz angeschlossen werden muß. Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B. Ethernet (IEEE 802.3), Serial Line IP (SLIP), etc.

Die TCP/IP-Protokoll-Architektur

Die TCP/IP-Architektur wird, wie im Abschnitt Referenzmodelle - Das TCP/IP- Referenzmodell gesagt, im allgemeinen als vierschichtiges Modell beschrieben. Oft wird das TCP/IP-Referenzmodell auch als fünfschichtiges Modell dargestellt. Andrew S. Tanenbaum bezeichnet das fünfschichtige Modell als hybrides Referenzmodell. Er schreibt dazu: "(...) Viertens unterscheidet das TCP/IP-Modell nicht zwischen den Bitübertragungs- und Sicherungsschichten (erwähnt sie nicht einmal). Diese Schichten sind völlig unterschiedlich. Die Bitübertragungsschicht hat mit den Übertragungsmerkmalen von Kupferdarht, Glasfaser und drahtlosen Kommunikationsmedien zu tun. Die Sicherungsschicht ist darauf beschränkt, den Anfang und das Ende von Rahmen abzugrenzen und sie mit der gewünschten Zuverlässigkeit von einem Ende zum anderen zu befördern. Ein korrektes Modell sollte beides als separate Schichten beinhalten. Das TCP/IP-Modell tut das nicht."

OSI-Referenzmodell TCP/IP-Referenzmodell Hybrides Referenzmodell

Einkapselung

Die Schichtung beruht auf dem Prinzip, daß eine Schicht die angebotenen Dienste der darunter liegenden Schicht in Anspruch nehmen kann. Dabei braucht die Schicht, die die Dienstleistung in Anspruch nimmt keinerlei Kenntnisse darüber haben, wie die geforderten Dienste erbracht werden. Auf diese Art und Weise wird eine Aufgabenteilung der Schichten erreicht . Daten, die von einem Applikationsprogramm über ein Netzwerk versendet werden, durchlaufen den TCP/IP-Protokollstapel von der Applikationsschicht zur Netzwerkschicht. Von jeder Schicht werden dabei Kontrollinformationen in Form eines Protokollkopfes angefügt. Diese Kontrollinformationen dienen der korrekten Zustellung der Daten. Das Zufügen von Kontrollinformationen wird als Einkapselung (encapsulation) bezeichnet.

Innerhalb der Schichten des TCP/IP-Modells werden Daten mit verschiedenen Termini benannt, da jede Schicht auch ihre eigenen Datenstrukturen hat. Applikationen, die das Transmission Control Protocol benutzen, bezeichnen Daten als Strom (stream); Applikationen, die das User Datagram Protocol verwenden, bezeichnen Daten als Nachricht (message). Auf der Transportebene bezeichnen die Protokolle TCP und UDP ihre Daten als Segment (segment) bzw. Paket (packet). Auf der Internet Schicht werden Daten allgemein als Datengramm (datagram) benannt. Oft werden die Daten hier aber auch als Paket bezeichnet. Auf der Netzwerkebene bezeichnen die meisten Netzwerke ihre Daten als Pakete oder Rahmen (frames).

Netzwerkschicht

Die Netzwerkschicht ist die unterste Schicht des TCP/IP-Modells. Protokolle, die auf dieser Schicht angesiedelt sind, legen fest, wie ein Host an ein bestimmtes Netzwerk angeschlossen wird und wie IP-Pakete über dieses Netzwerk übertragen werden. Im Gegensatz zu den Protokollen der höheren Schichten des TCP/IP- Modells, müssen die Protokolle der Netzwerkschicht sich auf die Details des verwendeten Netzwerks - wie z.B. Paketgrößen, Netzwerkadressierung, Anschlußcharakteristiken etc. - beziehen. Die Netzwerkschicht des TCP/IP-Modells umfaßt also die Aufgaben der Bitübertragungsschicht, Sicherungsschicht und Vermittlungsschicht im OSI- Modell. Die Protokolle der Netzwerkschicht sind allerdings nicht im TCP/IP-Modell definiert. Wie schon gesagt, legt das Modell lediglich fest, daß zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netzwerk angeschlossen werden muß. Die Protokolle sind im Modell nicht weiter definiert. Es werden hier vielmehr bestehende Standards verwendet und in das Modell aufgenommen. Insbesondere bedeutet dies auch, daß mit neuer Hardware-Technologie auch neue Protokolle auf der Netzwerkschicht entwickelt werden müssen, so daß TCP/IP-Netzwerke diese Hardware verwenden können. Dies ist jedoch kein Nachteil, sondern eher ein Vorteil. Durch die weitgehende Unabhängigkeit vom Übertragungsmedium können neue Netzwerktechnologien schnell in das TCP/IP-Modell aufgenommen werden. Als Beispiel soll hier Ethernet dienen.

Ethernet

• Ethernet

Internet-Schicht

Das Internet ist eine Sammlung von Teilnetzen, die miteinander verbunden sind. Es gibt keine echte Struktur des Netzes, sondern mehrere größere Backbones, die quasi das Rückgrat (wie der Name Backbone ja schon sagt) des Internet bilden. Die Backbones werden aus Leitungen mit sehr hoher Bandbreite und schnellen Routern gebildet. An die Backbones sind wiederum größere regionale Netze angeschlossen, die LANs von Universitäten, Behörden, Unternehmen und Service-Providern verbinden.

Internet Protokoll

Das Internet Protokoll (Internet Protocol - IP) ist der Leim, der dies alles zusammenhält. IP stellt die Basisdienste für die Übermittlung von Daten in TCP/IP-Netzen bereit und ist im RFC 791 spezifiziert. Hauptaufgaben des Internet Protokolls sind die Adressierung von Hosts und das Fragmentieren von Paketen. Diese Pakete werden von IP nach bestem Bemühen ("best effort") von der Quelle zum Ziel befördert, unabhängig davon, ob sich die Hosts im gleichen Netz befinden oder andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet Protokoll enthält keine Funktionen für die Ende-zu-Ende-Sicherung oder für die Flußkontrolle.

Die Funktionen von IP umfassen:

Die Definition von Datengrammen zur Übermittlung von Daten im Internet bilden. Definition des Adressierungsschemas. Übermittlung der Daten von der Transportebene zur Netzwerkschicht. Routing von Datengrammen durch das Netz. Fragmentierung und Zusammensetzen von Datengrammen. IP ist ein verbindungsloses Protokoll, d.h. zur Datenübertragung wird keine Ende-zu-Ende-Verbindung der Kommunikationspartner etabliert. Ferner ist IP ein unzuverlässiges Protokoll, da es über keine Mechanismen zur Fehlererkennung und -behebung verfügt. Unzuverlässig bedeutet aber keinesfalls, daß man sich auf das IP Protokoll nicht verlassen kann. Unzuverlässig bedeutet in diesem Zusammenhang lediglich, daß IP die Zustellung der Daten nicht garantieren kann. Sind die Daten aber beim Zielhost angelangt, sind diese Daten auch korrekt.

IP-Datengramm

Die TCP/IP-Protokolle wurden entwickelt, um Daten über ein paketvermittelndes Netz (wie dem ARPANET) zu übertragen. Ein Paket ist ein Datenblock zusammen mit den Informationen, die notwendig sind, um sie dem Empfänger zuzustellen (ein Paket ist also nichts anderes als ein Paket im herkömmliche Sinn bei der Post - das Paket enthält die Daten, auf dem Paket ist die Adresse des Empfängers notiert). Das Datengramm (datagram) ist das Paketformat, das vom Internet Protokoll definiert ist. Ein IP-Datengramm besteht aus einem Header und den zu übertragenden Daten. Der Header hat einen festen 20 Byte großen Teil, gefolgt von einem optionalen Teil variabler Länge. Der Header umfaßt alle Informationen, die notwendig sind, um das Datengramm dem Empfänger zuzustellen. Ein Datengramm kann theoretisch maximal 64 KByte groß sein, in der Praxis liegt die Größe ungefähr bei 1500 Byte (das hängt mit der maximalen Rahmengröße des Ethernet-Protokolls zusammen).

Der IP-Header

IP______________________________________________________________.
|version|  ihl  |      tos      |            totlen             |
|___4___|___5___|____0x00=0_____|___________0x0028=40___________|
|              id               |r|D|M|       offsetfrag        |
|__________0x0C7D=3197__________|0|0|0|________0x0000=0_________|
|      ttl      |   protocol    |           checksum            |
|____0x00=0_____|____0x06=6_____|____________0x489C_____________|
|                            source                             |
|_________________________192.168.242.1_________________________|
|                          destination                          |
|________________________192.168.242.100________________________|
TCP_____________________________________________________________.
|          source port          |       destination port        |
|__________0x04D2=1234__________|___________0x0016=22___________|
|                            seqnum                             |
|_____________________0x6BD4594F=1809078607_____________________|
|                            acknum                             |
|_________________________0x00000000=0__________________________|
| doff  |r|r|r|r|C|E|U|A|P|R|S|F|            window             |
|___5___|0|0|0|0|0|0|0|0|0|0|0|0|___________0x0000=0____________|
|           checksum            |            urgptr             |
|_________0x8021=32801__________|___________0x0000=0____________|

Die Felder des in der Abbildung dargestellten Protokollkopfes haben die folgende Bedeutung:

Version

Das Versions-Feld enthält die Versionsnummer des IP-Protokolls. Durch die Einbindung der Versionsnummer besteht die Möglichkeit über eine längere Zeit mit verschiedenen Versionen des IP Protokolls zu arbeiten. Einige Hosts können mit der alten und andere mit der neuen Version arbeiten. Die derzeitige Versionsnummer ist 4, aber die Version 6 des IP Protokolls befindet sich bereits in der Erprobung

Update: Mittlerweile (2019) ist die Erprobungsphase von IPv6 abgeschlossen und das Protokoll befindet neben IPv4 im Einsatz. Wobei der Großteil der im Internet eingesetzten Geräte parallel beide Protokolle (IPv4 und IPv6) nutzen. Der Plan ist IPv4 auslaufen zu lassen, um in den kommenden Jahren nur noch IPv6 zum Einsatz zu bringen.

Length

Das Feld Length (Internet Header Length - IHL) enthält die Länge des Protokollkopfs, da diese nicht konstant ist. Die Länge wird in 32-Bit- Worten angegeben. Der kleinste zulässige Wert ist 5 - das entspricht also 20 Byte; in diesem Fall sind im Header keine Optionen gesetzt. Die Länge des Headers kann sich durch Anfügen von Optionen aber bis auf 60 Byte erhöhen (der Maximalwert für das 4-Bit-Feld ist 15).

Type of Service

Über das Feld Type of Service kann IP angewiesen werden Nachrichten nach bestimmten Kriterien zu behandeln. Als Dienste sind hier verschiedene Kombinationen aus Zuverlässigkeit und Geschwindigkeit möglich. In der Praxis wird dieses Feld aber ignoriert, hat also den Wert 0. Das Feld selbst hat den folgenden Aufbau:

Precedence

(Bits 0-2) gibt die Priorität von 0 (normal) bis 7 (Steuerungspaket) an. Die drei Flags (D,T,R) ermöglichen es dem Host anzugeben, worauf er bei der Datenübertragung am meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigkeit (Reliability - R). Die beiden anderen Bit-Felder sind reserviert.

Total Length

Enthält die gesamte Paketlänge, d.h. Header und Daten. Da es sich hierbei um ein 16-Bit-Feld handelt ist die Maximallänge eines Datengramms auf 65.535 Byte begrenzt. In der Spezifikation von IP (RFC 791) ist festgelegt, daß jeder Host in der Lage sein muß, Pakete bis zu einer Länge von 576 Bytes zu verarbeiten. In der Regel können von den Host aber Pakete größerer Länge verarbeitet werden.

Identification

Über das Identifikationsfeld kann der Zielhost feststellen, zu welchem Datengramm ein neu angekommenes Fragment gehört. Alle Fragmente eines Datengramms enthalten die gleiche Identifikationsnummer, die vom Absender vergeben wird.

Flags

Das Flags-Feld ist drei Bit lang. Die Flags bestehen aus zwei Bits namens DF - Don't Fragment und MF - More Fragments. Das erste Bit des Flags-Feldes ist ungenutzt bzw. reserviert. Die beiden Bits DF und MF steuern die Behandlung eines Pakets im Falle einer Fragmentierung. Mit dem DF-Bit wird signalisiert, daß das Datengramm nicht fragmentiert werden darf. Auch dann nicht, wenn das Paket dann evtl. nicht mehr weiter transportiert werden kann und verworfen werden muß. Alle Hosts müssen, wie schon gesagt Fragemente bzw. Datengramme mit einer Größe von 576 Bytes oder weniger verarbeiten können. Mit dem MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpakete nachfolgen. Diese Bit ist bei allen Fragmenten außer dem letzten gesetzt.

Fragment Offset

Der Fragmentabstand bezeichnet, an welcher Stelle relativ zum Beginn des gesamten Datengramms ein Fragment gehört. Mit Hilfe dieser Angabe kann der Zielhost das Originalpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit groß ist, können maximal 8192 Fragmente pro Datengramm erstellt werden. Alle Fragmente, außer dem letzten, müssen ein Vielfaches von 8 Byte sein. Dies ist die elementare Fragmenteinheit.

Time to Live

Das Feld Time to Live ist ein Zähler, mit dem die Lebensdauer von IP- Paketen begrenzt wird. Im RFC 791 ist für dieses Feld als Einheit Sekunden spezifiziert. Zulässig ist eine maximale Lebensdauer von 255 Sekunden (8 Bit). Der Zähler muß von jedem Netzknoten, der durchlaufen wird um mindestens 1 verringert werden. Bei einer längeren Zwischenspeicherung in einem Router muß der Inhalt sogar mehrmals verringert werden. Enthält das Feld den Wert 0, muß das Paket verworfen werden: damit wird verhindert, daß ein Paket endlos in einem Netz umherwandert. Der Absender wird in einem solchen Fall durch eine Warnmeldung in Form einer ICMP-Nachricht (siehe weiter unten) informiert.

Protocol

Enthält die Nummer des Transportprotokolls, an das das Paket weitergeleitet werden muß. Die Numerierung von Protokollen ist im gesamten Internet einheitlich.. Bei UNIX-Systemen sind die Protokollnummern in der Datei /etc/protocols abgelegt.

Header Checksum

Dieses Feld enthält die Prüfsumme der Felder im IP-Header. Die Nutzdaten des IP-Datengramms werden aus Effiziengründen nicht mit geprüft. Diese Prüfung findet beim Empfänger innerhalb des Transportprotokolls statt. Die Prüfsumme muß von jedem Netzknoten, der durchlaufen wird, neu berechnet werden, da der IP-Header durch das Feld Time-to-Live sich bei jeder Teilstrecke verändert. Aus diesem Grund ist auch eine sehr effiziente Bildung der Prüfsumme wichtig. Als Prüfsumme wird das 1er-Komplement der Summe aller 16-Bit- Halbwörter der zu überprüfenden Daten verwendet. Zum Zweck dieses Algorithmus wird angenommen, daß die Prüfsumme zu Beginn der Berechnung Null ist.

Source Address, Destination Address

In diese Felder werden die 32-Bit langen Internet-Adressen zur eingetragen. Die Internet-Adressen werden im nächsten Abschnitt näher betrachtet.

Options und Padding

Das Feld Options wurde im Protokollkopf aufgenommen, um die Möglichkeit zu bieten das IP-Protokoll um weitere Informationen zu ergänzen, die im ursprünglichen Design nicht berücksichtigt wurden. Das Optionsfeld hat eine variable Länge. Jede Option beginnt mit einem Code von einem Byte, über den die Option identifiziert wird. Manchen Optionen folgt ein weiteres Optionsfeld von 1 Byte und dann ein oder mehrere Datenbytes für die Option. Das Feld Options wird über das Padding auf ein Vielfaches von 4 Byte aufgefüllt. Derzeit sind die folgenden Optionen bekannt:

End of Options List

Kennzeichnet das Ende der Optionsliste.

No Option

Kann zum Auffüllen von Bits zwischen Optionen verwendet werden.

Security

Bezeichnet, wie geheim ein Datengramm ist. In der Praxis wird diese Option jedoch fast immer ignoriert.

Loose Source-Routing, Strict Source-Routing

Diese Option enthält eine Liste von Internet-Adressen, die das Datagramm durchlaufen soll. Auf diese Weise kann dem Datenpaket vorgeschrieben werden eine bestimmte Route durch das Internet zu nehmen. Beim Source-Routing wird zwischen Strict Source and Record Route und Loose Source and Record Route unterschieden. Im ersten Fall wird verlangt, daß das Paket diese Route genau einhalten muß. Desweiteren wird die genommene Route aufgezeichnet. Die zweite Variante schreibt vor, daß die angegebenen Router nicht umgangen werden dürfen. Auf dem Weg können aber auch andere Router besucht werden.

Record Route

Die Knoten, die dieses Datengramm durchläuft, werden angewiesen ihre IP-Adresse an das Optionsfeld anzuhängen. Damit läßt sich ermitteln, welche Route ein Datengramm genommen hat. Wie anfangs schon gesagt, ist die Größe für das Optionsfeld auf 40 Byte beschränkt. Deshalb kommt es heute auch oftmals zu Problemen mit dieser Option, da weit mehr Router durchlaufen werden, als dies zu Beginn des ARPANET der Fall war.

Time Stamp

Diese Option ist mit der Option Record Route vergleichbar. Zusätzlich zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten vermerkt.

Adressierung auf der Internet-Schicht

Zur Adressierung eines Kommunikationspartners in Form eines Applikationsprogramms müssen beim Durchlaufen der vier TCP/IP- Schichten auch vier verschiedene Adressen angegeben werden.

1. Eine Netzwerkadresse (z.B. eine Ethernet-Adresse)
2. Eine Internet-Adresse
3. Eine Transportprotokoll-Adresse
4. Eine Portnummer

Zwei dieser Adressen finden sich als Felder im IP-Header: die Internet- Adresse und die Transportprotokoll-Adresse. Protokollnummern IP verwendet Protokollnummern, um empfangene Daten an das richtige Transportprotokoll weiterzuleiten. Die Protokollnummer ist ein einzelnes Byte im IP-Header. Die Protokollnummern sind im gesamten Internet einheitlich. Bisher wurden die Protokollnummern im RFC 1700 definiert. Diese Aufgabe ist nun von der Internet Assigned Numbers Authority (IANA) [1] übernommen worden. Auf UNIX-Systemen sind die Protokollnummern in der Datei /etc/protocols abgelegt. Diese Datei ist eine einfache Tabelle, die einen Protokollnamen und die damit verbundene Protokollnummer enthält. Nachfolgend ist der Inhalt der Datei /etc/protocols einer aktuellen LINUX-Maschine abgebildet:

Empfängt IP ein Datengramm, in dessen Header als Protokollnummer 6 eingetragen ist, so werden diese Daten an das Transmission Control Protocol weitergeleitet; ist die Nummer 17, werden die Daten an das User Datagram Protocol weitergeleitet etc.

IP-Adressen

Jeder Host und Router im Internet hat eine 32-Bit lange IP-Adresse. Eine IP- Adresse ist eindeutig: kein Knoten im Internet hat die gleiche IP-Adresse wie ein anderer. Maschinen, die an mehrere Netze angeschlossen sind, haben in jedem Netz eine eigene IP-Adresse. Die Netzwerkadressen wurden bisher vom Network Information Center (NIC) [2] vergeben, um Adresskonflikte zu vermeiden. Seit einiger Zeit hat diese Aufgabe die Internet Assigned Numbers Authority (IANA) [3] bzw. ihre Vertreter in den verschiedenen Gebieten - Asia Pacific Network Information Center (APNIC), American Registry for Internet Numbers (ARIN), Réseaux IP Européens (RIPE) - übernommen. Die Adressen werden nicht einzeln zugeordnet, sondern

nach Netzklassen vergeben. Beantragt man IP-Adressen für ein Netz, so erhält man nicht für jeden Rechner eine Adresse zugeteilt, sondern einen Bereich von Adressen, der selbst zu verwalten ist.

IP-Adreßformate. Wie die obere Abbildung zeigt, sind IP-Adressen in verschiedene Klassen, mit unterschiedlich langer Netzwerk- und Hostadresse, eingeteilt. Die Netzwerkadresse definiert das Netzwerk, in dem sich ein Host befindet: alle Hosts eines Netzes haben die gleiche Netzwerkadresse. Die Hostadresse identifiziert einen bestimmten Rechner innerhalb eines Netzes. Ist ein Host an mehrere Netze angeschlossen, so hat er für jedes Netz eine eigene IP-Adresse. "Eine IP-Adresse identifiziert keinen bestimmten Computer [Host], sondern eine Verbindung zwischen einem Computer [Host] und einem Netz. Einem Computer [Host] mit mehreren Netzanschlüssen (z.B. ein Router) muß für jeden Anschluß eine IP-Adresse zugewiesen werden." ([Co98]) IP-Adressen sind 32-Bit große Zahlen, die normalerweise nicht als Binärzahl, sondern in gepunkteten Dezimalzahlen geschrieben werden. In diesem Format wird die 32-Bit große Zahl in 4 Byte getrennt, die mit Punkten voneinander getrennt sind. Die Adresse 01111111111111111111111111111111 wird so z.B. als 127.255.255.255 geschrieben. Die niedrigste IP-Adresse ist 0.0.0.0., die höchste 255.255.255.255. Wie zuvor gesagt, sind IP-Adressen in Klassen unterteilt. Der Wert des ersten Bytes gibt die Adressklasse an:

Klasse A

Das erste Byte hat einen Wert kleiner als 128, d.h. das erste Bit der Adresse ist 0. Das erste Byte ist Netzwerknummer, die letzten drei Bytes identifizieren einen Host im Netz. Es gibt demzufolge also 126 Klasse A Netze, die bis zu 16 Millionen Host in einem Netz.

Klasse B

Ein Wert von 128 bis 191 für das erste Byte (das erste Bit ist gleich 1, Bit 2 gleich 0) identifiziert eine Klasse B Adresse. Die ersten beiden Bytes identifizieren das Netzwerk, die letzen beiden Bytes einen Host. Das ergibt 16382 Klasse B Netze mit bis zu 64000 Hosts in einem Netz.

Klasse C

Klasse C Netze werden über Werte von 192 bis 223 für das erste Byte (die ersten beiden Bits sind gleich 1, Bit 3 gleich 0) identifiziert. Es gibt 2 Millionen Klasse C Netze, d.h. die ersten drei Bytes werden für die Netzwerkadresse verwendet. Ein Klasse C Netz kann bis zu 254 Host beinhalten.

Klasse D

Klasse D Adressen, sogenannte Multicast-Adressen, werden dazu verwendet ein Datengramm an mehrere Hostadressen gleichzeitig zu versenden. Das erste Byte einer Multicast-Adresse hat den Wertebereich von 224 bis 239, d.h. die ersten drei Bit sind gesetzt und Bit 4 ist gleich 0. Sendet ein Prozeß eine Nachricht an eine Adresse der Klasse D, wird die Nachricht an alle Mitglieder der adressierten Gruppe versendet. Die Übermittlung der Nachricht erfolgt, wie bei IP üblich, nach bestem Bemühen, d.h. ohne Garantie, daß die Daten auch tatsächlich alle Mitglieder einer Gruppe erreichen. Für das Multicasting wird ein spezielles Protokoll namens Internet Group Management Protocol (IGMP) verwendet. IGMP entspricht grob ICMP, mit dem Unterschied, daß es nur zwei Arten von Paketen kennt: Anfragen und Antworten. Anfragen werden dazu verwendet, zu ermitteln welche Hosts Mitglieder einer Gruppe sind. Antworten informieren darüber, zu welchen Gruppen ein Host gehört. Jedes IGMP-Paket hat ein festes Format und wird zur Übertragung in IP-Pakete eingekapselt.

EXKURS: Subnetting

EXKURS: Supernetting

Der IGMP-Header

Version

In RFC1112 ist die aktuelle Version 1 des IGMP Protokolls spezifiziert. Version 0, die in RFC998 beschrieben wird, ist obsolet

Type

Wie zuvor gesagt, kennt IGMP zwei Nachrichtentypen: Anfragen und Antorten:

1 = Host Membership Query (Anfrage) 2 = Host Membership Report (Antwort)

Unused

Dieses Feld wird derzeit nicht benutzt.

Checksum

Der Algorithmus zur Berechnung der Checksumme entspricht dem des IP-Protokolls.

Group Address

Bei einer Anfrage zur Gruppenzugehörigkeit wird das Gruppenadressenfeld mit Nullen gefüllt. Ein Host, der eine Anfrage erhält, ignoriert dieses Feld. Bei einer IGMP-Antwort enthält das Gruppenadressenfeld die Adresse der Gruppe, zu der der sendende Host gehört. Eine genaue Beschreibung des Internet Group Management Protocol ist in RFC1112 zu finden (RFC1054 und RFC 998 beschreiben ältere Versionen von IGMP).

Klasse E

Der weitere Bereich der IP-Adressen von 240 bis 254 im ersten Byte ist für zukünftige Nutzungen reserviert. In der Literatur wird dieser Bereich oft auch als Klasse E bezeichnet (vgl. [Co98)].

Private Adressbereiche

Im Internet müssen die Netzkennungen eindeutig sein. Aus diesem Grund werden die (Netz)Adressen, wie weiter oben schon gesagt, von einer zentralen Organisation vergeben. Dabei ist sichergestellt, daß die Adressen eindeutig sind und auch im Internet sichtbar sind. Dies ist aber nicht immer notwendig. Netze, die keinen Kontakt zum globalen Internet haben, benötigen keine Adresse, die auch im Internet sichtbar ist. Es ist auch nicht notwendig, daß sichergestellt ist, das diese Adressen in keinem anderen, privaten Netz eingesetzt werden. Aus diesem Grund wurden Adreßbereiche festgelegt, die nur für private Netze bestimmt sind. Diese Bereiche sind in RFC 1918 (Address Allocation for Private Internets) festgelegt (RFC 1597, auf das sich oft auch neuere Literatur bezieht, ist durch RFC 1918 ersetzt). Diese IP- Nummern dürfen im Internet nicht weitergeleitet werden. Dadurch ist es möglich, diese Adressen in beliebig vielen, nicht-öffentlichen Netzen, einzusetzen. Die folgenden Adressbereiche sind für die Nutzung in privaten Netzen reserviert:

Klasse A: 10.0.0.0

Für ein privates Klasse A-Netz ist der Adressbereich von 10.0.0.0 bis 10.255.255.255 reserviert.

Klasse B: 172.16.0.0 bis 172.31.255.255

Für die private Nutzung sind 16 Klasse B-Netze reserviert. Jedes dieser Netze kann aus bis zu 65.000 Hosts bestehen (also z.B. ein Netz mit den Adressen von 172.17.0.1 bis 172.17.255.254).

Klasse C: 192.168.0.0 bis 192.168.255.255

256 Klasse C-Netzte stehen zur privaten Nutzung zur Verfügung. Jedes dieser Netze kann jeweils 254 Hosts enthalten (z.B. ein Netz mit den Adressen 192.168.0.1 bis 192.168.0.254). Jeder kann aus diesen Bereichen den Adreßbereich für sein eigenes privates Netz auswählen. Die Zuteilung dieser Adressen bedarf nicht die Koordination mit der IANA oder einer anderen Organisation, die für die Zuordnung von IP-Adressen verantwortlich ist.

Weitere Sonderfälle

Netznummer 0

Adressen mit der Netznummer 0 beziehen sich auf das aktuelle Netz. Mit einer solchen Adresse können sich Hosts auf ihr eigenes Netz beziehen, ohne die Netzadresse zu kennen (allerdings muß bekannt sein, um welche Netzklasse es sich handelt, damit die passende Anzahl Null-Bytes gesetzt wird).

127

steht für das Loopback Device eines Hosts. Pakete, die an eine Adresse der Form 127.x.y.z gesendet werden, werden lokal verarbeitet. Neben einigen Netzadressen sind auch bestimmte Hostadressen für spezielle Zwecke reserviert. Bei allen Netzwerkklassen sind die Werte 0 und 255 bei den Hostadressen reserviert. Eine IP-Adresse, bei der alle Hostbits auf Null gesetzt sind, identifiziert das Netz selbst. Die Adresse 80.0.0.0 bezieht sich so z.B. auf das Klasse A Netz 80, die Adresse 128.66.0.0 bezieht sich auf das Klasse B Netz 128.66. Eine IP- Adresse, bei der alle Host-Bytes den Wert 255 haben, ist eine Broadcast-Adresse. Eine Broadcast-Adresse wird benutzt, um alle Hosts in einem Netzwerk zu adressieren.

Fragmentierung

Damit Datengramme über jede Art von Netzwerk verschickt werden können, muß das Internet Protokoll dazu in der Lage sein, die Größe der Datengramme dem jeweiligen Netz anzupassen. Jedes Netzwerk besitzt eine sogenannte maximale Paketgröße (Maximum Transfer Unit - MTU), die bezeichnet, daß nur Pakete bis zu dieser Größe über das Netz verschickt werden können. So dürfen z.B. Pakete, die über ein X.25-Netz verschickt werden sollen nicht größer als 128 Byte sein. Ein Ethernet- Paket darf die Größe von 1500 Byte nicht überschreiten. Falls die MTU eines Übertragungsmediums kleiner ist als die Größe eines versendeten Pakets, so muß dieses Paket in kleinere Pakete aufgeteilt werden. Es genügt allerdings nicht, daß die Protokolle der Transportschicht nun von sich aus einfach kleinere Pakete versenden. Ein Paket kann auf dem Weg vom Quell- zum Zielhost mehrere unterschiedliche Netzwerke mit unterschiedlichen MTUs durchlaufen. Aus diesem Grund muß ein flexibleres Verfahren angewendet werden, daß bereits auf der Internet- Schicht kleiner Pakete erzeugen kann. Dieses Verfahren wird Fragmentierung genannt. Unter Fragmentierung wird verstanden, daß das IP-Protokoll eines jeden Netzwerkknotens (sei es ein Router, ein Host o.ä.) in der Lage ist (sein sollte), empfangene Pakete gegebenenfalls zu zerteilen, um sie weiter über ein Teilnetz bis zum Zielhost zu übertragen.

Jedes empfangende IP muß dazu in der Lage sein, diese Fragmente wieder zum ursprünglichen Paket zusammenzusetzen. Jedes Fragment eines zerteilten Pakets erhält einen eigenen, vollständigen IP-Header. Über das Identifikationsfeld im Header können alle Fragmente eines Pakets wiedererkannt werden. Die einzelnen Fragmente eines Pakets können durchaus unterschiedliche Wege auf dem Weg zum Zielhost nehmen. Die Lage der Daten eines Fragments innerhalb der Gesamtnachricht wird mit Hilfe des Fragment Offset- Feldes ermittelt.

Internet Control Message Protocol

Das Internet Control Message Protocol (ICMP) ist Bestandteil jeder IP- Implementierung und hat die Aufgabe Fehler- und Diagnoseinformationen für IP zu transportieren. ICMP ist im RFC 792 spezifiziert. Oft wird ICMP auch für Testzwecke verwendet, etwa um zu ermitteln, ob ein Host derzeit empfangsbereit ist. ICMP hat sehr unterschiedliche Informationen zu transportieren. Deshalb ist nur der Grundaufbau des ICMP-Headers immer gleich, die Bedeutung der einzelnen Felder im Protokollkopf wechselt jedoch. Jeder ICMP- Nachrichtentyp wird in einem IP-Datengramm eingekapselt. Der ICMP-Header (allgemeiner Aufbau).

Die derzeit wichtigsten ICMP-Nachrichtentypen sind:

Destination Unreachable (Ziel nicht erreichbar)

Diese Nachricht wird verwendet, wenn: ein Netzwerk, Host, Protokoll oder Port nicht erreichbar ist, ein Paket nicht fragmentiert werden kann, weil das DF-Bit gesetz ist, die Source Route Option nicht erfolgreich ist.

Source Quench (Quelle löschen)

Wird ausgesendet, wenn ein Host zu viele Pakete verschickt, die aus Kapazitätsmangel nicht mehr verarbeitet werden können. Der sendende Host muß dann die Rate zum Aussenden von Nachrichten verringern.

Parameter Problem

Verständigt den Absender eines Datengramms darüber, daß das Paket aufgrund einer fehlerhaften Angabe im IP-Header verworfen werden mußte.

Redirect

Wird ausgesendet, wenn ein Router feststellt, daß ein Paket falsch weitergeleitet wurde. Der sendende Host wird damit aufgefordert, die angegebene Route zu ändern.

Time Exceeded (Zeit verstrichen)

Diese Nachricht wird an den Absender eines Datengramms gesendet, dessen Lebensdauer den Wert 0 erreicht hat. Diese Nachricht ist ein Zeichen dafür, daß Pakete in einem Zyklus wandern, daß Netz überlastet ist oder die Lebensdauer für das Paket zu gering eingestellt wurde

Echo Reply, Echo Request

Mit diesen Nachrichten kann festgestellt werden, ob ein bestimmtes Ziel erreichbar ist. Ein Echo Request wird an einen Host gesendet und hat einen Echo Reply zur Folge (falls der Host erreicht wird).

Timestamp Request, Timestamp Reply

Diese beiden Nachrichten sind ähnlich den zuvor beschriebenen Nachrichten, außer das die Ankunftszeit der Nachricht und die Sendezeit der Antwort mit erfaßt werden. Mit diesen Nachrichtentypen kann die Netzleistung gemessen werden.

Einsatz von icmp

IP verwendet ICMP zum versenden von Fehler- und Diagnosemeldungen, während ICMP zur Übertragung seiner Nachrichten IP benutzt. Das bedeutet, wenn eine ICMP-Nachricht verschickt werden muß, wird ein IP- Datengramm erzeugt und die ICMP-Meldung in den Datenbereich des IP- Datengramms eingekapselt (siehe Abbildung).

ICMP-Nachrichten-Einkapselung. Das Datengramm wird dann wie üblich versendet. Eine ICMP-Nachricht wird immer als Antwort auf ein Datengramm verschickt. Entweder ist ein Datengramm auf ein Problem gestoßen, oder das Datengramm enthält eine ICMP-Anfrage, auf die eine Antwort versendet versendet werden muß. In beiden Fällen sendet ein Host oder Router eine ICMP-Nachricht an die Quelle des Datengramms zurück.

EXKURS: ICMP TYPES AND CODES

Transportschicht

Über der Internet-Schicht befindet sich die Transportschicht (Host-to-Host- Transport Layer). Die beiden wichtigsten Protokolle der Transportschicht sind das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). Die Aufgabe von TCP besteht in der Bereitstellung eines sicheren und zuverlässigen Ende-zu-Ende-Transports von Daten durch ein Netzwerk. UDP ist im Gegensatz dazu ein verbindungsloses Transportprotokoll, das Anwendungen die Möglichkeit bietet, eingekapselte rohe IP-Pakete zu übertragen.

Transmission Control Protocol (TCP)

Das Transmission Control Protocol (TCP) ist ein zuverlässiges, verbindungsorientiertes, Bytestrom Protokoll. Die Hauptaufgabe von TCP besteht in der Bereitstellung eines sicheren Transports von Daten durch das Netzwerk. TCP ist im RFC 793 definiert. Diese Definitionen wurden im Laufe der Zeit von Fehlern und Inkonsistenzen befreit (RFC 1122) und um einige Anforderungen ergänzt (RFC 1323). Im weiteren sollen nun die oben genannten Eigenschaften des Transmission Control Protocol zuverlässig (reliable), verbindungsorientiert (connection-oriented), Bytestrom (byte-stream) - näher betrachtet werden. Das Transmission Control Protocol stellt die Zuverlässigkeit der Datenübertragung mit einem Mechanismus, der als Positive Acknowledgement with Re-Transmission (PAR) bezeichnet wird, bereit. Dies bedeutet nichts anderes als das, daß das System, welches Daten sendet, die Übertragung der Daten solange wiederholt, bis vom Empfänger der Erhalt der Daten quittiert bzw. positiv bestätigt wird. Die Dateneinheiten, die zwischen den sendenden und empfangenden TCP- Einheiten ausgetauscht werden, heißen Segmente. Ein TCP-Segment besteht aus einem mindestens 20 Byte großen Protokollkopf (s.u. Der TCP- Header) und den zu übertragenden Daten. In jedem dieser Segmente ist eine Prüfsumme enthalten, anhand derer der Empfänger prüfen kann, ob die Daten fehlerfrei sind. Im Falle einer fehlerfreien Übertragung sendet der Empfänger eine Empfangsbestätigung an den Sender. Andernfalls wird das Datengramm verworfen und keine Empfangsbestätigung verschickt. Ist nach einer bestimmten Zeitperiode (timeout-period) beim Sender keine Empfangsbestätigung eingetroffen, verschickt der Sender das betreffende Segment erneut. Näheres zur Zeitüberwachung siehe [Sa94]. TCP ist ein verbindungsorientiertes Protokoll. Verbindungen werden über ein Dreiwege-Handshake (three-way handshake) aufgebaut. Über das Dreiwege-Handshake werden Steuerinformationen ausgetauscht, die die logische Ende-zu-Ende-Verbindung etablieren. Zum Aufbau einer Verbindung sendet ein Host (Host 1) einem anderen Host (Host 2), mit dem er eine Verbindung aufbauen will, ein Segment, in dem das SYN-Flag (s.u. Der TCP-Header - Flags) gesetzt ist. Mit diesem Segment teilt Host 1 Host 2 mit, das der Aufbau einer Verbindung gewünscht wird. Die Sequenznummer des von Host 1 gesendeten Segments gibt Host 2 außerdem an, welche Sequenznummer Host 1 zur Datenübertragung verwendet. Sequenznummern sind notwendig, um sicherzustellen, daß die Daten vom Sender in der richtigen Reihenfolge beim Empfänger ankommen. Der empfangende Host 2 kann die Verbindung nun annehmen oder ablehnen. Nimmt er die Verbindung an, wird ein Bestätigungssegment gesendet. In diesem Segment sind das SYN-Bit und das ACK-Bit (s.u. Der TCP-Header - Flags) gesetzt. Im Feld für die

Quittungsnummer bestätigt Host 2 die Sequenznummer von Host 1, dadurch, daß die um Eins erhöhte Sequenznummer von Host 1 gesendet wird. Die Sequenznummer des Bestätigungssegments von Host 2 an Host 1 informiert Host 1 darüber, mit welcher Sequenznummer beginnend Host 2 die Daten empfängt. Schlußendlich bestätigt Host 1 den Empfang des Bestätigungssegments von Host 2 mit einem Segment, in dem das ACK- Flag gesetzt ist und die um Eins erhöhte Sequenznummer von Host 2 im Quittungsnummernfeld eingetragen ist. Mit diesem Segment können auch gleichzeitig die ersten Daten an Host 2 übertragen werden. Nach dem Austausch dieser Informationen hat Host 1 die Bestätigung, daß Host 2 bereit ist Daten zu empfangen. Die Datenübertragung kann nun stattfinden. Eine TCP-Verbindung besteht immer aus genau zwei Endpunkten (Punkt-zu-Punkt-Verbindung). Dreiwege-Handshake (hier Verbindungsaufbau). Zum Beenden der Verbindung tauschen die beiden Host wiederum einen Dreiwege-Handshake aus, bei dem das FIN-Bit (s.u. Der TCP-Header - Flags) zum Beenden der Verbindung gesetzt ist. Natürlich verläuft der Verbindungsaufbau nicht immer ohne Probleme. Eine Reihe interessanter Betrachtungen ist zu finden in [Ta96].

TCP nimmt Datenströme von Applikationen an und teilt diese in höchsten 64 KByte große Segmente auf (üblich sind ungefähr 1.500 Byte). Jedes dieser Segmente wird als IP-Datengramm verschickt. Kommen IP- Datengramme mit TCP-Daten bei einer Maschine an, werden diese an TCP weitergeleitet und wieder zu den ursprünglichen Byteströmen zusammengesetzt. Die IP-Schicht gibt allerdings keine Gewähr dafür, daß die Datengramme richtig zugestellt werden. Es ist deshalb, wie oben bereits gesagt, die Aufgabe von TCP für eine erneute Übertragung der Daten zu sorgen. Es ist aber auch möglich, daß die IP-Datengramme zwar korrekt ankommen, aber in der falschen Reihenfolge sind. In diesem Fall muß TCP dafür sorgen, daß die Daten wieder in die richtige Reihenfolge gebracht werden. Hierfür verwendet TCP eine Sequenznummer und eine Bestätigungsnummer (siehe: Der TCP-Header - Sequence Number, Acknowledgement Number).

Portnummern

TCP ist außerdem dafür verantwortlich, die empfangenen Daten an die korrekte Applikation weiterzuleiten. Zur Adressierung der Anwendungen werden auf der Transportebene deshalb sogenannte Portnummern (Kanalnummern) verwendet. Portnummern sind 16 Bit groß; theoretisch kann ein Host somit bis zu 65.535 verschiedene TCP-Verbindungen aufbauen. Auch UDP verwendet Portnummern zur Adressierung. Portnummern sind nicht einzigartig zwischen den Transportprotokollen - die Transportprotokolle haben jeweils eigene Adreßräume. Das bedeutet TCP und UDP können die gleichen Portnummern belegen. Das heißt, daß die Portnummer 53 in TCP nicht identisch mit der Portnummer 53 in UDP ist. Der Gültigkeitsbereich einer Portnummer ist auf einen Host beschränkt.

---

Das passt noch nicht ganz...

Eine IP-Adresse zusammen mit der Portnummer spezifiziert einen Kommunikationsendpunkt, einen sogenannten Socket. Die Socketnummern von Quelle und Ziel identifizieren die Verbindung (socket1, socket2). Eine Verbindung ist durch die Angabe dieses Paares eindeutig identifiziert. Möchte z.B. ein Host A eine Verbindung zu einem entfernten Host B aufnehmen, z.B. um den Inhalt einer Webseite anzuzeigen, so wird auf der TCP-Schicht als Zielport die Portnummer 80 für das Hypertext Transfer Protocol (http) angegeben. Host A, der den Dienst auf Port 80 von Host B in Anspruch nehmen möchte gibt als Quellport eine dynamische Portnummer (s.u.) aus dem Bereich 49.152 - 65.535 an, damit die von ihm gewünschten Daten von Host B an ihn zurückgeliefert werden können. Damit ist die Verbindung auf der TCP- Schicht über die Angabe von Quell- und Zielport eindeutig identifiziert. Zusammen mit den IP-Adressen bilden die Portnummern die beiden Sockets, die die Kommunikation zwischen Host A und Host B eindeutig kennzeichnen.

Bis 1992 waren Portnummern unter 256 für gut bekannte Ports (well- known ports) reserviert. Well-known Ports werden für Standarddienste, wie z.B telnet, ftp etc. genutzt. Ports zwischen 256 und 1023 wurden im allgemeinen für UNIX-spezifische Dienste (wie z.B. rlogin) benutzt. Ein Beispiel für den Unterschied zwischen einem Internet-weiten Dienst und einem UNIX-spezifischen Dienst ist der Unterschied zwischen Telnet und RLogin. Beide Dienste erlauben es, sich über das Netz auf einem entfernten Host einzuloggen. Telnet ist ein TCP/IP-Standard mit der Portnummer 23 und kann von so gut wie auf allen Betriebssystemen implementiert werden. RLogin ist im Gegensatz dazu ein UNIX- spezifischer Dienst, dessen Portnummer 53 ist.

Verwaltung

Die Verwaltung der Portnummern ist nun auch von der Internet Assigned Numbers Authority (IANA) [4] übernommen worden. Portnummern sind dabei in drei Bereiche aufgeteilt worden: well-known ports, registered ports und dynamic ports.

Der TCP-Header

Die folgende Abbildung zeigt den Aufbau des TCP-Protokollkopfs.

Der TCP-Header.

Die sendende und die empfangende TCP-Einheit tauschen Daten in Form von Segmenten aus. Ein Segment ist nichts anderes als die zu übertragenden Daten, versehen mit "Steuerinformationen". Jedes Segment beginnt mit einem 20-Byte-Header, auf den Header-Optionen folgen können. Den Optionen folgen schließlich die zu übertragenden Daten. Die Segmentgröße wird durch zwei Faktoren begrenzt: erstens muß jedes Segment, einschließlich des TCP-Headers, in das Nutzdatenfeld des IP-Protokolls passen (65.535 Byte); zweitens hat jedes Netz eine maximale Transfereinheit (MTU - Maximum Transfer Unit), in die das Segment passen muß. In der Regel ist die MTU einige tausend Byte groß und gibt die obere Grenze der Segmentgröße vor (z.B. Ethernet 1.500 Bytes). Läuft ein Segment durch eine Anzahl von Netzen und trifft dabei auf ein Netz mit einer kleineren MTU, so muß das Segment vom Router in kleinere Segmente aufgeteilt (fragmentiert) werden. Unabhängig von der Größe der MTU können dem TCP-Header und den Optionen maximal 65.535-20-20 = 65.495 Datenbyte folgen (die ersten 20 Byte beziehen sich auf den IP-Header, die zweiten auf den TCP-Header; die Länge der Optionen wird mit zu den Datenbytes gezählt). TCP-Segmente ohne Daten sind zulässig un dienen der Übermittlung von Bestätigungen und Steuernachrichten.

Felder des TCP-Headers

Source-/Destination-Port:

Die Felder Source Port (Quellport) und Destination Port (Zielport) adressieren die Endpunkte der Verbindung. Die Größe für die beiden Felder beträgt 16 Bit.

Sequence Number, Acknowledgement Number:

Die Sequenznummer und die Bestätigungsnummer sind jeweils 32-Bit- Zahlen. Die Nummern geben die Stellung der Daten des Segments innerhalb des in der Verbindung ausgetauschten Datenstroms an. Die Sequenznummer gilt in Senderichtung, die Bestätigungsnummer für Empfangsquittungen. Jeder der beiden TCP-Verbindungspartner generiert beim Verbindungsaufbau eine Sequenznummer, die sich während des Zeitraums der Verbindung nicht wiederholen darf. Dies ist allerdings durch den großen Zahlenraum von 2^32 wohl ausreichend gesichert. Diese Nummern werden beim Verbindungsaufbau ausgetauscht und gegenseitig quittiert. Bei der Datenübertragung wird die Sequenznummer vom Absender jeweils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer gibt der Empfänger an, bis zu welchem Byte er die Daten bereits korrekt empfangen hat. Die Nummer gibt allerdings nicht an, welches Byte zuletzt korrekt empfangen wurde, sondern welches Byte als nächstes zu erwarten ist.

Offset:

Das Feld Offset (oder auch Header Length) gibt die Länge des TCP- Headers in 32-Bit Worten an. Dies entspricht dem Anfang der Daten im TCP-Segment. Das Feld ist notwendig, da der Header durch das Optionsfeld eine variable Länge hat.

Flags

Mit den sechs 1-Bit-Flags im Flags-Feld werden bestimmte Aktionen im TCP-Protokoll aktiviert:

URG

Wird das Flag URG auf 1 gesetzt, so bedeutet dies, daß der Urgent Pointer (Dringendzeiger) verwendet wird.

ACK

Das ACK-Bit wird gesetzt, um anzugeben, daß die Bestätigungsnummer im Feld Acknowledgement Number gültig ist. Ist das Bit auf 0 gesetzt, enthält das TCP-Segment keine Bestätigung, das Feld Acknowledgement Number wird ignoriert.

PSH

Ist das PSH-Bit gesetzt, so werden die Daten in dem entsprechenden Segment sofort bei Ankunft der adressierten Anwendung bereitgestellt ohne sie zu puffern.

RST

Das RST-Bit dient dazu eine Verbindung zurückzusetzen, falls ein Fehler bei Übertragung aufgetreten ist. Dies kann sowohl der Fall sein, wenn ein ungültiges Segment übertragen wurde, ein Host abgestürzt ist oder der Versuch eines Verbindungsaufbaus abgewiesen werden soll.

SYN

Das SYN-Flag (Synchronize Sequenze Numbers) wird verwendet, um Verbindungen aufzubauen. Zusammen mit der Acknowledgement Number und dem ACK-Bit wird die Verbindung im Form eines Dreiwege-Handshake aufgebaut (siehe oben).

FIN

Das FIN-Bit dient zum Beenden einer Verbindung. Ist das Bit gesetzt, gibt dies an, daß der Sender keine weiteren Daten zu Übertragen hat. Das Segment mit gesetztem FIN-Bit muß quittiert werden.

Window

Das Feld Fenstergröße enthält die Anzahl Bytes, die der Empfänger ab dem bereits bestätigten Byte empfangen kann. Mit der Angabe der Fenstergröße erfolgt in TCP die Flußsteuerung. Das TCP-Protokoll arbeitet nach dem Prinzip eines Schiebefensters mit variabler Größe (Sliding Window). Jede Seite einer Verbindung darf die Anzahl Bytes senden, die im Feld für die Fenstergröße angegeben ist, ohne auf eine Quittung von der Empfängerseite zu warten. Währen des Sendens können gleichzeitug Quittungen für die von der anderen Seite empfangenen Daten eintreffen (diese Quittungen können wiederum neue Fenstergrößen einstellen).

Eine Fenstergröße von 0 besagt, daß die Bytes bis einschließlich der Acknowledgement Number minus Eins empfangen wurden, der

Empfänger momentan aber keine weiteren Daten empfangen kann. Die Erlaubnis zum weiteren Senden von Daten erfolgt durch das versenden eines Segments mit gleicher Bestätigungsnummer und einer Fenstergröße ungleich Null.

Checksum

Die Prüfsumme prüft den Protokollkopf, die Daten und den Pseudo- Header (siehe Abbildung). Der Pseudo-Header in der Prüfsumme. Der Algorithmus für die Bildung der Prüfsumme ist einfach: alle 16-Bit Wörter werden im 1er-Komplement addiert und die Summe ermittelt. Bei der Berechnung ist das Feld Checksum auf Null gesetzt und das Datenfeld wird bei ungerader Länge um ein Nullbyte aufgefüllt. Führt der Empfänger des Segments die Berechnung auf das gesamte Segment aus - inklusive des Feldes für die Prüfsumme - sollte das Ergebnis 0 sein [Ta96]. Der Pseudo-Header enthält die 32-bit großen IP-Adressen der Quell- und Zielmaschine sowie die Protokollnummer (für TCP 6) und die Länge des TCP-Segments. Die Einbeziehung der Felder des Pseudo-Headers in die Prüfsummenberechnung hilft, durch IP falsch zugeteilte Pakete zu erkennen. Die Verwendung von IP- Adressen auf der Transportebene stellt allerdings eine Verletzung der Protokollhierarchie dar.

Urgent Pointer

Der Urgent-Zeiger ergibt zusammen mit der Sequenznummer einen Zeiger auf ein Datenbyte. Dies entspricht einem Byteversatz zu einer Stelle, an der dringende Daten vorgefunden werden. TCP signalisiert damit, daß sich an einer bestimmten Stelle im Datenstrom wichtige Daten befinden, die sofort gelesen werden sollten. Das Feld wird nur gelesen, wenn auch das Urgent-Flag (s.o.) gesetzt ist.

Options

Das Options-Feld soll eine Möglichkeit bieten Funktionen bereitzustellen, die im normalen TCP-Protokollkopf nicht vorgesehen sind. In TCP sind drei Optionen definiert: End of Option List, No- Operation und Maximum Segment Size. Die wichtigste dieser drei Optionen ist die Maximale Segmentgröße. Mit dieser Option kann ein Host die maximale Anzahl Nutzdaten übermitteln, die er annehmen will bzw. annehmen kann. Während eines Verbindungsaufbaus kann jede Seite ihr Maximum an Nutzdaten übermitteln, die kleinere der beiden Zahlen wird als maximale Nutzdatengröße für die Übertragung übernommen. Wird diese Option von einem Host nicht unterstützt wird als default die Vorgabe von 536 Byte verwendet.

Padding

Das Feld Padding wird verwendet, um sicherzustellen, daß der Header an einer 32-Bit Grenze endet und die Daten an einer 32-Bit Grenze beginnen. Das Füllfeld wird mit Nullen gefüllt.

User Datagram Protocol (UDP)

Das User Datagram Protocol (UDP) ist im RFC 768 definiert. UDP ist ein unzuverlässiges, verbindungsloses Protokoll. Wie zuvor schon gesagt, bedeutet unzuverlässig in diesem Zusammenhang nicht, daß die Daten evtl. fehlerhaft beim Zielrechner ankommen, sondern, daß das Protokoll keinerlei Mechanismen zur Verfügung stellt, die sichern, daß die Daten auch tatsächlich beim Zielrechner ankommen. Sind die Daten aber beim Zielrechner angekommen, so sind sie auch korrekt. UDP bietet gegenüber TCP den Vorteil eines geringen Protokoll-Overheads. Viele Anwendungen, bei denen nur eine geringen Anzahl von Daten übertragen wird (z.B. Client/Server-Anwendungen, die auf der Grundlage einer Anfrage und einer Antwort laufen), verwenden UDP als Transportprotokoll, da unter Umständen der Aufwand zur Herstellung einer Verbindung und einer zuverlässigen Datenübermittlung größer ist als die wiederholte Übertragung der Daten.

Ein UDP-Segment besteht aus einem Header von 8 Byte, gefolgt von den Daten. Der Header ist in der folgenden Abbildung dargestellt: Der UDP-Header.

Die Sender- und Empfänger-Portnummern erfüllen den gleichen Zweck wie beim Transmission Control Protocol. Sie identifizieren die Endpunkte der Quell- und Zielmaschine. Das Feld für die Länge enthält die Länge des gesamten Datengramms, inklusive der Länge des Protokollkopfes. Die Prüfsumme enthält die Internet-Prüfsumme der UDP-Daten, des Protokollkopfs und des Pseudo-Headers. Das Prüfsummenfeld ist optional. Enthält das Feld eine 0, wurde vom Absender keine Prüfsumme eingetragen und somit findet beim Empfänger keine Überprüfung statt. Das User Datagram Protocol liefert über die Leistungen des Internet Protokolls hinaus nur Portnummern für die Adressierung der Kommunikationsendpunkte und eine optionale Prüfsumme. Das Protokoll beinhaltet keine Transportquittungen oder andere Mechanismen für die Bereitstellung einer zuverlässigen Ende-zu-Ende-Verbindung. Hierdurch wird UDP allerdings sehr effizient und eignet sich somit besonders für Anwendungen, bei denen es in erster Linie auf die Geschwindigkeit der Datenübertragung ankommt (z.B. verteilte Dateisysteme wie NFS).

Applikationsschicht

Die oberste Schicht des TCP/IP-Modells ist die Applikationsschicht. Diese Schicht bietet eine Reihe standardisierter Anwendungsprotokolle, auf die eine Vielzahl von Anwendungsprogrammen aufsetzen. An dieser Stelle seien nur einige Protokolle, die auf der Anwendungsschicht angeboten werden, genannt:

TELNET

TELNET ist das Protokoll für virtuelle Terminals. Es dient dazu, Zugriff auf einen am Netz angeschlossenen Rechner in Form einer Terminalsitzung (auch remote login genannt) zu liefern. Der TELNET-Dienst benutzt den TCP-Port 23. TELNET ist im RFC 854 spezifiziert.

FTP

Mit dem File Transfer Protocol - FTP lassen sich Dateien externer Rechner übertragen, löschen, ändern oder umbenennen. FTP ist im RFC 959 definiert. Von FTP werden die Ports 20 und 21 benutzt. Port 21 wird als Kommandokanal verwendet und Port 20 dient als Datenkanal.

SMTP

Das Simple Mail Transfer Protocol - SMTP ist das Protokoll für die elektronische Post im Internet. Das Übertragungsprotokoll für elektronische Post ist im RFC 821 und das Nachrichtenformat im RFC 822 spezifiziert.

DNS

Der Domain Name Service - DNS dient dazu ASCII-Zeichenketten in Internet-Adressen und umgekehrt zu wandeln. DNS ist ein hierarchisches Benennungssystem, das auf Domänen basiert und ein verteiltes Datenbanksystem zur Implementierung des Benennungsschemas. Es wird im wesentlichen dazu benutzt Hostnamen und E-Mailadressen (mit denen Menschen nun einmal besser umgehen können) in IP-Adressen umzuwandeln. DNS ist in den RFCs 1034 und 1035 definiert.

NFS

Mit dem Network File System - NFS lassen sich mehrere Rechner auf transparente Weise miteinander verbinden. Der NFS-Dienst stellt eine virtuelle Verbindung von Laufwerken und Festplatten her, so daß sich entfernte Dateisysteme als Erweiterung des eigenen lokalen Dateisystems darstellen.

Die Zukunft

Das rasche (exponentielle Wachstum) des Internet zwingt dazu, das Internet Protokoll in der Version 4 (IPv4) durch ein Nachfolgeprotokoll zu ersetzen. Bis vor einiger Zeit wurde das Internet größtenteils nur von Universitäten, Regierungsbehörden (dies aber auch fast nur in den USA und hier vor allem vom Verteidigungsministerium) und einigen Firmen aus der Industrie genutzt. Seit der Einführung des World Wide Web (WWW) ist das Internet aber auch zunehmend für Privatpersonen, kleinere Firmen etc. interessant. Das Internet wandelt sich von einem "Spielplatz für Akademiker" zu einem weltweiten Informations- und Unterhaltungssystem. Mit der ständig steigenden Anzahl von Benutzern des Internet werden sich auch die Anforderungen an das Netz ändern bzw. haben sich bereits geändert. Genannt sei hier nur als Beispiel das angestrebte Zusammenwachsen der Computer-, Unterhaltungs- und Telekommunikationsbranchen. Den Anforderungen, die z.B. Video-on-demand stellt, ist das Internet bzw. das Internet Protokoll in der Version 4 nicht gewachsen. Vinton Cerf (der 'Vater' des Internet) bezeichnet in einem Interview mit der Zeitschrift c't [Kr98] 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. Wie versucht wird, diese Anforderungen zu erfüllen, wird in den nächsten Abschnitten beschrieben.

Classless InterDomain Routing - CIDR

Der Verknappung der Internet-Adressen durch die ständig steigende Benutzerzahl wird zunächst versucht, mit dem Classless InterDomain Routing (CIDR) entgegen zu wirken. Durch die Vergabe von Internet-Adressen in Klassen (Netze der 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. Tatsächlich ist aber oft auch ein Klasse B Netz zu groß. Für viele Firmen würde ein Netz der Klasse C ausreichen. Dies wurde aber nicht verlangt, da viele Unternehmen die Befürchtung hatten, daß ein Klasse C Netz mit seinen bis zu 254 möglichen Hosts nicht ausreichen würde. Ein größeres Hostfeld für Netze der Klasse C (z.B. 10 Bit, das entspricht 1022 Host 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 wären explodiert. Ein anderes Konzept ist das Classless InterDomain 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; das entspricht einem Block von 2048 Adressen. Zusätzlich werden die verbliebenen Klasse C Adressen restriktiver und strukturierter vergeben (RFC 1519). Die Welt ist dabei in vier Zonen, von denen jede einen Teil des verbliebenen Klasse C Adreßraums erhält, aufgeteilt:

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

Internet Protokoll Version 6 - IPv6 (IP Next Generation)

Der vorrangige Grund für eine Änderung des IP-Protokolls ist auf den begrenzten Adreßraum zurückzuführen. CIDR schafft hier zwar wieder etwas Luft, dennoch ist klar absehbar, daß auch diese Maßnahmen nicht ausreichen, 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 oben schon erwähnten neuen Anforderungen an das Internet. Diesen Anforderungen ist IP in der Version 4 nicht gewachsen. Die IETF (Internet Engineering Task Force) begann deshalb 1990 mit der Arbeit an einer neuen Version von IP. Die wesentlichen Ziele des Projekts sind [Ta96]:

• Unterstützung von Milliarden von Hosts, auch bei ineffizienter Nutzung des Adreßraums

• Reduzierung des Umfangs der Routing-Tabellen

• Vereinfachung des Protokolls, damit Router Pakete schneller abwickeln können

• Höhere Sicherheit (Authentifikation und Datenschutz) als das heutige IP

• Mehr Gewicht auf Dienstarten, insbesondere für Echtzeitanwendungen

• Unterstützung von Multicasting durch die Möglichkeit, den Umfang zu definieren

• Möglichkeit für Hosts, ohne Adreßänderung auf Reise zu gehen

• Möglichkeit für das Protokoll, sich zukünftig weiterzuentwickeln

• Unterstützung der alten und neuen Protokolle in Koexistenz für Jahre

Im Dezember 1993 forderte die IETF mit RFC 1550 [IP: Next Generation (IPnG) White Paper Solicitation, Dec. 1993] 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. Die drei besten Vorschläge wurden im IEEE Network Magazine veröffentlicht ([De93], [Fr93], [KF93]). Aus diesen Vorschlägen wurde von der IETF das Simple Internet Protocol Plus (SIPP) als Grundlage für die neue IP-Version ausgewählt. SIPP ist eine Kombination aus den Vorschlägen von Deering [De93] und Francis [Fr93]. Als die Entwickler mit den Arbeiten an der neuen Version des Internet Protokolls begannen, wurde natürlich auch ein Name für das Projekt bzw. das neue Protokoll benötigt. Wohl angeregt durch eine gleichnamige Fernsehsendung, 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 folgende Beschreibung von IPv6 orientiert sich an RFC 2460 [Internet Protocol, Version 6 (IPv6) Specification, Dec. 1998]. Dieses Dokument gibt den neuesten Stand der Spezifikation des Internet Protokolls in der Version 6 wieder. RFC 2460 enthält einige wesentliche Änderungen der Spezifikation gegenüber RFC 1883 [Internet Protocol, Version 6 (IPv6) Specification, Dec. 1995].

Die Merkmale von IPv6

Viele der als erfolgreich betrachteten Merkmale von IPv4 bleiben in IPv6 voll erhalten. Trotzdem ist IPv6 im allgemeinen nicht mit IPv4 kompatibel, wohl aber zu den weiteren Internet-Protokollen, insbesondere den Protokollen der Transportschicht (TCP, UDP); eventuell nach geringfügigen Modifikationen. Die Modifikationen betreffen im wesentlichen die erweiterte Adreßgröße (bisher 32 Bit auf nun 128 Bit).

Die wesentlichen Merkmale von IPv6 sind:

• Adressgröße:

Als wichtigstes Merkmal hat IPv6 gegenüber IPv4 größere Adressen. Statt bisher 32 Bit stehen nun 128 Bit für die Adressen bereit. Theoretisch lassen sich damit 2128 = 3.4*1038 Adressen vergeben.

• Header-Format:

Der IPv6 (Basis)Header wurde vollständig geändert. Der Header enthält nur 7 statt bisher 13 Felder. Diese Änderung ermöglicht Routern, Pakete schneller zu verarbeiten. Im Gegensatz zu IPv4 gibt es bei IPv6 nicht mehr nur einen Header, sondern mehrere Header. Ein Datengramm besteht aus einem Basis-Header, sowie einem oder mehreren Zusatz-Headern, gefolgt von den Nutzdaten.

• Erweiterte Unterstützung von Optionen und Erweiterungen:

Die Erweiterung der Optionen ist notwendig geworden, da einige, bei IPv4 notwendige Felder nun optional sind. Darüber hinaus unterscheidet sich auch die Art, wie die Optionen dargestellt werden. Für Router wird es damit einfacher, Optionen, die nicht für sie bestimmt sind, zu überspringen. Dies ermöglicht ebenfalls eine schnellere Verarbeitung von Paketen.

• Dienstarten:

IPv6 legt mehr Gewicht auf die Unterstützung von Dienstarten. Damit kommt IPv6 den Forderungen nach einer verbesserten Unterstützung der Übertragung von Video- und Audiodaten entgegen. Pv6 bietet hierzu eine Option zur Echtzeitübertragung.

• Sicherheit:

IPv6 beinhaltet nun im Protokoll selbst Mechanismen zur sicheren Datenübertragung. Wichtige neue Merkmale von IPv6 sind hier Authentifikation (authentication), Datenintegrität (data integrity) und Datenverlässlichkeit (data confidentiality).

• Erweiterbarkeit:

IPv6 ist ein erweiterbares Protokoll. Bei der Spezifikation des Protokolls wurde nicht versucht alle potentiell möglichen Einsatzfelder für das Protokoll in die Spezifikation zu integrieren. Vielmehr bietet IPv6 die Möglichkeit über Erweiterungs-Header (s.u.) das Protokoll zu erweitern. Damit ist das Protokoll offen für zukünftige Verbesserungen.

Das IPv6 Datengrammformat

Ein IPv6-Datengramm besteht aus dem Basis-Header (s.u. Der IPv6-Basis- Header), gefolgt von den optionalen Zusatz-Headern (s.u. Erweiterungs- Header) und den Nutzdaten.

Allgemeine Form eines IPv6-Datengramms.

Der IPv6-Basis-Header

Der IPv6-Basis-Header ist doppelt so groß wie der IPv4-Header. Der IPv6-Basis- Header enthält weniger Felder als der IPv4-Header, dafür ist aber die Adreßgröße für die Quell- und Zieladresse von bisher 32-Bit auf nunmehr 128- Bit erweitert worden.

IPv6 Basis-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:

Das Feld Priority (oder Traffic Class) ...

Flow Label

Das Feld Flow Label...

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 mit 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. Ist dies der letzte zu IPv6 zugehörige Header, so gibt das Feld an, welches Transportprotokoll (z.B. TCP oder UDP) folgt. Eine genauere Beschreibung des Konzepts mehrerer Header folgt im Abschnitt Erweiterungs-Header

Hop Limit

Mit dem Feld Hop Limit wird festgelegt, wie lange ein Paket überleben darf. Der Wert des Feldes wird nach jeder Teilstrecke gesenkt. Ein Datengramm wird dann verworfen, wenn das Feld Hop Limit auf Null herunter gezählt ist, bevor das Datengramm sein Ziel erreicht hat. IPv4 verwendet hierzu das Feld Time to Live, welches die Zeit in Sekunden angibt, die ein Paket überleben darf. Allerdings wird dieses Feld von den meisten Routern nicht so interpretiert. In IPv6 wurde das Feld deshalb umbenannt, um die tatsächliche Nutzung wiederzugeben.

Source Address, Destination Address

Die beiden Felder Quell- und Zieladresse dienen zur Identifizierung des Senders und Empfängers eines IP-Datengramms. IPv6 verwendet zur Adressierung 4 mal so große Adressen wie IPv4: 128 Bit statt 32 Bit. Eine genaue Beschreibung der IPv6-Adressen folgt im Abschnitt IPv6- Adressierung.

Ein Vergleich des IPv4-Headers mit dem IPv6-Basis-Header veranschaulicht, welche Felder bei IPv6 weggelassen wurden:

• Das Feld Length (Internet Header Length - IHL) ist nicht mehr vorhanden, da der IPv6-Basis-Header eine feste Länge von 40 Byte hat. Bei IPv4 ist dieses Feld notwendig, da der Header aufgrund der Optionen eine variable Länge hat.

• Das Feld Protocol wird nicht mehr benötigt, da das Feld Next Header angibt, was nach dem letzten IP-Header folgt (z.B. TCP oder UDP).

• 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 (RFC 1883 legte diese Größe noch auf 576 Byte fest) unterstützen. Durch diese Regel wird eine Fragmentierung im Prinzip nicht notwendig. 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 dieser Nachricht wird der sendende Host angewiesen, alle weiteren Pakete zu diesem Ziel aufzuteilen. Das bedeutet, daß von den Hosts "erwartet" wird, daß sie von vornherein eine Datengrammgröße wählen, die keine Fragmentierung voraussetzt. Dadurch wird eine größere Effizienz bei der Übertragung erreicht, als wenn Pakete von Routern auf dem Weg fragmentiert werden müssen. Die Steuerung der Fragmentierung erfolgt bei IPv6 über den Fragment Header.

• Das Feld Checksum ist nicht mehr vorhanden, da die Berechnung der Prüfsumme sich nachteilig auf die Leistung der Datenübertragung ausgewirkt hat. Das entfernen der Prüfsumme aus dem Internet Protokoll hat zu heftigen Diskussionen geführt [Ta96]. Die eine Seite kritisierte heftig das entfernen der Prüfsumme, während die andere Seite argumentierte, daß Prüfsummen etwas sind, das auch von Anwendungen übernommen werden kann, sofern sich die Anwendung tatsächlich um Datenintegrität kümmert. Ein weiteres Gegenargument war, daß eine Prüfsumme auf der Transportschicht bereits vorhanden ist, weshalb innerhalb der Vermittlungsschicht keine weitere Prüfsumme notwendig sei. Letztendlich fiel die Entscheidung, daß IPv6 keine Prüfsumme enthält.

Erweiterungs Header

IPv6 nutzt das Konzept der Erweiterungs-Header, um a) eine effiziente Datenübertragung und b) eine Erweiterung des Protokolls zu ermöglichen. Der erste Punkt ist leicht ersichtlich: Der Basis-Header enthält nur Felder, die unbedingt für die Übermittlung eines Datengramms notwendig sind, erfordert die Übertragung weitere Optionen, so können diese über einen Erweiterungs- Header angegeben werden. IPv6 sieht vor, das einige Merkmale des Protokolls nur gezielt benutzt werden. Ein gutes Beispiel ist hier die Fragmentierung von Datengrammen. Obwohl viele IPv4-Datengramme nicht fragmentiert werden müssen, enthält der IPv4-Header Felder, für die Fragmentierung. IPv6 gliedert die Felder für die Fragmentierung in einen separaten Header aus, der wirklich nur dann verwendet werden muß, wenn das Datengramm tatsächlich fragmentiert werden muß. Ein weiterer wesentlicher Vorteil des Konzepts der Erweiterungs-Header ist, daß das Protokoll um neue Funktionen erweitert werden kann. Es genügt, für das Feld Next Header einen neuen Typ und ein neues Header-Format zu definieren. IPv4 erfordert hierzu eine vollständige Änderung des Headers. Derzeit sind 6 Erweiterungs-Header definiert. Alle Erweiterungs-Header sind optional. Werden mehrere Erweiterungs-Header verwendet, so ist es erforderlich, sie in einer festen Reihenfolge anzugeben.

Die ersten 5 Header sind in RFC 2460 (bzw. RFC 1883). Der Authentifikations- Header sowie der Header für Sicherheitsdaten werden in RFC 2402 (RFC 1826) und RFC 2406 (RFC 1827) beschrieben.

Anycast

Adressierungsart die über eine Adresse einzelne Rechner aus einer Gruppe ansprechen kann. Es antwortet derjenige, der über die kürzeste Route erreichbar ist.

• Geschwindigkeit

Mehrere Rechner können über die selbe Adresse angesprochen werden, wobei nur der Rechner antwortet der über die kürzeste Route angesprochen wird.

• Ausfallsicherheit

Sollte der Rechner mit der kürzesten Route ausfallen wird ohne Umwege der zweit nächste Rechner angesprochen.

• Transparenz

Aus Sicht eines Clients besteht zwischen Unicast und Anycast kein Unterschied. Der Client sendet ein IP-Paket an eine „normale“ IP-Adresse und erhält von dieser eine Antwort. Welcher Server angesprochen wird, bestimmt allein das Routing.

• Instabilitäten

Bei instabilem Routing können aufeinanderfolgende IP-Pakete zu unterschiedlichen Servern geleitet werden. Daher wird Anycast vorzugsweise bei verbindungslosen Protokollen wie UDP eingesetzt. In stabilen Umgebungen kann Anycast aber auch bei TCP verwendet werden.

• Aufwand

Da alle beteiligten Server stets identische Daten bereitstellen müssen, ist die interne Synchronisation aufwendig. Außerdem wird im Störfall die Fehlersuche erschwert, da oft nicht ohne weitere Analyse ersichtlich ist, welcher Server verantwortlich ist.

Referenzen

Anmerkungen zur Literatur

Es gibt eine ganze Reihe an Literatur, die sich mit TCP/IP befaßt. Ich möchte an dieser Stelle einige Werke hervorheben, die mir bei der Erstellung des Seminarvortrags und der Ausarbeitung als besonders hilfreich aufgefallen sind.

Comer D.E.: Internetworking with TCP/IP, Volumes I-III

Die drei Bände von Comer über TCP/IP sind wohl die Werke über TCP/IP schlechthin (wird von einigen auch die 'TCP/IP-Bibel' genannt).

Stevens R. W.: TCP/IP Illustrated, Volumes I-III

Die drei Bände von Stevens stellen wohl die zweite Bibel über TCP/IP dar. Mir persönlich gefallen die drei Bände von Stevens noch besser als die Bücher von Comer. Stevens hat für die Darstellung der TCP/IP-Protokolle einen etwas anderen Weg als die bloße Vorstellung der einzelnen Protokolle gewählt; die Protokolle werden auch anhand eines Analyse-Tools untersucht.

Comer D.E.: Computernetzwerke und Internets

Noch ein gutes Buch von Douglas Comer. Das Buch gibt eine sehr gute und umfassende Darstellung aller wichtigen Themen im Bereich Netzwerke und Internets. Es geht dabei nicht so in die Tiefe wie das dreibändige Werk "Internetworking with TCP/IP" oder "Computernetzwerke" von Tanenbaum. Gerade deshalb eignet es sich aber besonders gut für den Einstieg. Zu dem Buch gibt es auch eine WWW-Seite, auf der weitere Informationen zum Buch (insbesondere alle Abbildungen und zahlreiche Animationen) vorhanden sind. Dem Buch ist eine Kopie der WWW-Seiten als CD-ROM begelegt.

Huitema C.: IPv6 die neue Generation

Eine hervorragende Übersicht über das neue IP. Es wird verdeutlicht, wie sich IPv6 von IPv4 unterscheidet und welche Vorbereitungen für den Einsatz von IPv6 getroffen werden müssen. Neben allen wichtigen Erläuterugen zum neuen Internet Protokoll wird fast nebenher auch ein geschichtlicher Überblick über die Entwicklung von IPv6 gegeben.

Holzmann G.J.: Design and Validation of Computer Protocols

Dieses Buch ist eine sehr gute Einführung in (Computer)Protokolle, den Entwurf von Protokollen und Verifikation von Protokollen. Und das beste ist, daß das Buch vollständig als Postscript- oder PDF-Datei im Internet verfügbar ist!

Hunt C.: TCP/IP Network Administration

Ein Buch, das die Grundlagen von TCP/IP bespricht und vor allem für die Administration von TCP/IP Netzwerken in einer UNIX Umgebung gedacht ist. Eine sehr gute Informationsquelle.

Tanenbaum A.S.: Computer Networks

Wer allgemein etwas über Computernetzwerke erfahren möchte, der sollte in dieses Buch schauen. Das Buch deckt so ziemlich alles ab, was mit Computernetzen zu tun hat und ist dabei sehr gut geschrieben. Im WWW werden vom Autor und dem Verlag Leseproben und alle Abbildungen des Buches zur Verfügung gestellt. Die vom Verlag zur Verfügung gestellten Informationen finden sich unter http://www.prenhall.com/divisions/ptr/tanenbaum/book.html; die Informationen des Autors stehen unter http://www.cs.vu.nl/~ast.

Hedrick C.L.: Introduction to the Internet Protocols

Hedrick's on-line Beschreibung von TCP/IP ist eine gute Quelle für alle, die sich schnell einen Überblick darüber verschaffen wollen, was TCP/IP ist und wie TCP/IP funktioniert.

Santifaller M.: TCP/IP and ONC/NFS - Internetworking in a UNIX Environment

Eine umfassende Beschreibung von TCP/IP, die sich auch mit NFS/ONC (Network File System, Open Network Computing) befaßt.

RFCs - Request for Comments

Ein RFC ist ein Papier, das sich in irgendeiner Form mit Verfahren, die im Internet verwendet werden, beschäftigt. Dabei kann es sich um einen Verbesserungsvorschlag oder eine Anmerkung für ein bestehendes Verfahren handeln oder einem Vorschlag zu einem neuen Verfahren. Ein Vorschlag zu einem neuen Verfahren kann nach einiger Zeit (und Prüfung) dann zu einem Standard erklärt werden. Jedem vorgeschlagenen Standard wird eine Nummer zugeordnet. Eine genauere Beschreibung von RFCs findet sich im Abschnitt Eine kurze Gesichte des Internet in dieser Arbeit. Die folgende Liste gibt eine Reihe von RFCs wieder, die sich mit Themen des Vortrags bzw. dieser Arbeit befassen:

• rfc768 - UDP

• rfc783 - TFTP

• rfc791 - IP

• rfc792 - ICMP

• rfc793 - TCP

• rfc814 - Name, adresses, ports and routes

• rfc821/2 - Mail

• rfc825 - Specification for RFC's

• rfc826 - ARP

• rfc854 - TELNET

• rfc894 - A Standard for the Transmission of IP Datagrams over Ethernet

• rfc903 - RARP

• rfc950 - Internet Standard Subnetting Procedure (Subnets)

• rfc959 - FTP

• rfc1009 - Requirements for Internet Gateways

• rfc1011 - Official Internet Protocols

• rfc1013 - X Window System Protocol, Version 11 (Alpha Update)

• rfc1032/3/4/5 - Domains (Domain Administration & Domain Names)

• rfc1042 - Transmission of IP Datagrams over IEEE 802 Networks

• rfc1058 - Routing Information Protocol

• rfc1112 - Host Extensions for IP Multicasting

• rfc1117 - Internet numbers

• rfc1118 - Hitchhikers guide to the Internet

• rfc1180 - A TCP/IP Tutorial

• rfc1208 - Networking glossary of terms

• rfc1310 - The Internet Standards Process

• rfc1323 - TCP Extensions for High Performance

• rfc1521 - MIME

• rfc1550 - IPng White Paper Solicitation

• rfc1597 - Address Allocation for Private Internets

• rfc1700 - Assigned Numbers (Well-known Ports etc.)

• rfc1752 - Recommedation for the IP Next Generation Protocol

• rfc1825 - Security Architecture for the Internet Protocol

• rfc1826 - IP Authentication Header

• rfc1883 - Internet Protocol, Version 6 (IPv6)

• rfc1884 - IP Version 6 Addressing Architecture

• rfc1885 - Internet Control Message Protocol (ICMPv6)

• rfc1886 - DNS Extensions to support IP version 6

• rfc1918 - Address Allocation for Private Internets

• rfc1972 - Transmission of IPv6 Packets over Ethernet Networks

• rfc2019 - Transmission of IPv6 Packets over FDDI Networks

• rfc2200 - Internet Official Protocol Standards

Literaturliste

[Bl99 Black U.: Internet-Technologien der Zukunft. Addison-Wesley-] Longman, München, 1999.

Co95 Comer D.E., Stevens D.L.: Internetworking with TCP/IP, Vol. I -] Priciples, Protocols and Internals. Prentice Hall, Englewood Cliffs, New Jersey, 1995, 3rd ed.

[CS9 Comer D.E., Stevens D.L.: Internetworking with TCP/IP, Vol. II -4] Design, Implementation and Internals. Prentice Hall, Englewood Cliffs, New Jersey, 1994, 2nd ed.

[CS9 Comer D.E., Stevens D.L.: Internetworking with TCP/IP, Vol. III - 6] Client-Server Programming and Applications for the BSD Socket Version. Prentice Hall, Englewood Cliffs, New Jersey, 1996, 2nd ed.

[Co98 Comer D.E.: Computernetzwerke und Internets. Prentice Hall,] München, 1998. http://www.netbook.cs.purdue.edu.

[Da8 Davidson J.: Introduction to TCP/IP. Springer, New York, 19888]

[DE- DE-NIC: Deutsches Network Information Center. http://www.nic.de/NIC]

[De9 Deering S.E.: SIP - Simple Internet Protocol. IEEE Network Magazine,3] Band 7, S. 16-28, Mai/Juni 1993.

[Fr93] Francis P.: A Near-Termn Architecture for Deploying Pip. IEEE NetworkMagazine, Band 7, S. 30-37, Mai/Juni 1993.

[Ha9 Hasenstein M.: IP Network Address Translation. Diplomarbeit an der7] Technischen Universität Chemnitz, 1997. Online verfügbar unter:http://www.suse.de/~mha/HyperNews/get/linux-ip-net.html.

[HL20 Hafner K., Lyon M.: ARPA Kadabra - oder die Geschichte des Internet.00] DPunkt-Verlag, Heidelberg, 2000, 2. Auflage.

[HLW Hartjes K., Löffler H., Wessendorf G.: Fortsetzung folgt: Aktuelles zur97] IPv6-Einführung. ix 4/97, S. 97ff.

[He8 Hedrick C.L.: Introduction to the Internet Protocols . Computer7] Science Facilities Group, Rutgers The State University of New Jersey,1987.

[Hind Hinden R.: IP Next Generation (IPng).en] http://playground.sun.com/pub/ipng/html/ipng-main.html.

[Ho9 Holzmann G.J.: Design and Validation of Computer Protocols. Prentice1] Hall, Englewood Cliffs, New Jersey, 1991.Im Internet unter: http://cm.belllabs.com/cm/cs/what/spin/Doc/Book91.html.

[HB9 Hosenfeld F., Brauer K.: Kommunikation ohne Grenzen: TCP/IP -5] Informationsübermittlung im Internet. c't 12/95, S. 330ff.

[Ho9 Hosenfeld F.: Next Generation - IPv6: ein neues6] Kommunikationszeitalter?. c't 11/96, S. 380ff.

[Hui2 Huitema, C.: IPv6 - die neue Generation, Architektur und000] Implementierung. Addison Wesley, München, 2000.

[Hu9 Hunt C.: TCP/IP Network Administration. O'Reilly & Assoc.,5] Sebastopol, CA, 1995

[KF93 Katz D., Ford P.S.: TUBA - Replacing IP with CLNP. IEEE Network] Magazine, Band 7, S. 38-47, Mai/Juni 1993.

[Kirch Kirch O.: LINUX Network Administrators Guide.] http://metalab.unc.edu/mdw/LDP/nag/nag.html.

[Kö93 Köhntopp K.: Weltweit vernetzt - Struktur und Dienste des Internet.a] c't 2/93, S. 82ff.

[Kö93 Köhntopp K.: Einheitliche Sicht - Netzwerkprotokolle im Internet. c'tb] 3/93, S. 232ff.

[Kr98 Krempl S.: Das Internet bleibt spannend! Im Gespräch mit 'Internet-] Vater' Vinton G. Cerf. c't 3/98. S. 44ff.

[Ku96 Kuri J.: Wenn der Postmann zweimal klingelt - Namen und Adressen] im TCP/IP-Netzwerk und im Internet. c't 12/96, S. 334ff.

[Ku97 Kuri J.: Böhmische Dörfer - Vom Kabel zum Netzwerk. c't 1/97, S.a] 245ff.

[Ku97 Kuri J.: Da geht's lang! - Routing, oder: wie die Daten im Internetb] ihren Weg finden. c't 6/97, S. 380ff.

[Kus9 Kuschke M.: Vervierfacht - IPv6: neue Spezifikationen zur Lösung des4] Adreßdilemmas. ix 10/94, S. 132ff.

[MS9 Microsoft: Windows NT Server - Introduction to TCP/IP. White Paper,8] Microsoft Corporation, Redmond, 1998. Online verfügbar unter:http://www.microsoft.com/NTServer/nts/techdetails/compares/TCPIntrowp.asp.

[MS2 Microsoft: Introduction to IP Version 6. White Paper, Microsoft001] Corporation, Redmond, 2001. Online verfügbar unter:http://www.microsoft.com/technet/network/ipvers6.aps.

[OV9 Oberschelp W., Vossen G.: Rechneraufbau und Rechnerstrukturen.5] Oldenbourg, München, 1995, 6. Auflg.

[RFC] RFC'S - Requests For Comments: Liste aller RFC's (nach Nummernsortiert) http://www.rfc-editor.org oder: http://internic.net/ds/rfc-index.txt oder: ftp://ftp.nic.de/rfc/pub/doc/rfc Es gibt aber noch viele andere Adressen, unter denen die RFC's zu bekommen sind - auch als email.

[Sa98 Santifaller M.: TCP/IP und ONC/NFS - Internetworking mit UNIX.] Addison Wesley, Bonn, Reding Massachucetts, 1998, 4. Auflage.

[Sch9 Schmidt J.: Firewall getunnelt - Geheimer Datenaustausch über ICMP-7a] Pakete. c't 11/97, S. 332ff.

[Sch9 Schmidt J.: Falsche Fährten - Mißbrauchsmöglichkeiten von ARP und 7b] ICMP. c't 12/97, S. 246ff.

[Si20 Sietmann R.: Mobilmachung - Internetprotokoll Version 6. iX 4/2000,00] S. 100ff.

[St20 Stainov, R.: IPnG - Das Internet-Protokoll der nächsten Generation.00] Thomson Publishing, Bonn, 1997.

[St87 Stallings W.: Handbook of Computer Communications Standards, Vol.] I: The Open Systems Interconnection (OSI) Model and OSI-Related Standards. MacMillan Pub. Company, Indianapolis, 1987

[St88 Stallings W.: Handbook of Computer Communications Standards, Vol.a] II: Local Network Standards. MacMillan Pub. Company, New York,London, 1988

[St88 Stallings W.: Handbook of Computer Communications Standards, Vol.b] III: Department of Defense (DoD) Protocol Standards. MacMillan Pub. Company, New York, London, 1988

[St99 Stevens R. W.: TCP/IP Illustrated, Vol. 1: The Protocols. Addisona] Wesley, 1999, 14th ed.

[St99 Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 2: Theb] Implementation. Addison Wesley, 1999, 7th ed.

[St99 Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 3: TCP forc] transactions, HTTP, NNTP, and the UNIX Domain protocols. Addison Wesley, 1998, 4th ed.

[Ku97 Kuri J.: Da geht's lang! - Routing, oder: wie die Daten im Internetb] ihren Weg finden. c't 6/97, S. 380ff.

[Kus9 Kuschke M.: Vervierfacht - IPv6: neue Spezifikationen zur Lösung des4] Adreßdilemmas. ix 10/94, S. 132ff.

[MS9 Microsoft: Windows NT Server - Introduction to TCP/IP. White Paper,8] Microsoft Corporation, Redmond, 1998. Online verfügbar unter: http://www.microsoft.com/NTServer/nts/techdetails/compares/TCPIntrowp.asp.

[MS2 Microsoft: Introduction to IP Version 6. White Paper, Microsoft001] Corporation, Redmond, 2001. Online verfügbar unter: http://www.microsoft.com/technet/network/ipvers6.aps.

[OV9 Oberschelp W., Vossen G.: Rechneraufbau und Rechnerstrukturen.5] Oldenbourg, München, 1995, 6. Auflg.

[RFC] RFC'S - Requests For Comments: Liste aller RFC's (nach Nummernsortiert) http://www.rfc-editor.org oder: http://internic.net/ds/rfc-index.txt oder: ftp://ftp.nic.de/rfc/pub/doc/rfc Es gibt aber noch viele andere Adressen, unter denen die RFC's zu bekommen sind - auch als email.

[Sa98 Santifaller M.: TCP/IP und ONC/NFS - Internetworking mit UNIX.] Addison Wesley, Bonn, Reding Massachucetts, 1998, 4. Auflage.

[Sch9 Schmidt J.: Firewall getunnelt - Geheimer Datenaustausch über ICMP-7a] Pakete. c't 11/97, S. 332ff.

[Sch9 Schmidt J.: Falsche Fährten - Mißbrauchsmöglichkeiten von ARP und7b] ICMP. c't 12/97, S. 246ff.

[Si20 Sietmann R.: Mobilmachung - Internetprotokoll Version 6. iX 4/2000,00] S. 100ff.

[St20 Stainov, R.: IPnG - Das Internet-Protokoll der nächsten Generation.00] Thomson Publishing, Bonn, 1997.

[St87 Stallings W.: Handbook of Computer Communications Standards, Vol.] I: The Open Systems Interconnection (OSI) Model and OSI-Related Standards. MacMillan Pub. Company, Indianapolis, 1987

[St88 Stallings W.: Handbook of Computer Communications Standards, Vol.a] II: Local Network Standards. MacMillan Pub. Company, New York,London, 1988

[St88 Stallings W.: Handbook of Computer Communications Standards, Vol.b] III: Department of Defense (DoD) Protocol Standards. MacMillan Pub. Company, New York, London, 1988

[St99 Stevens R. W.: TCP/IP Illustrated, Vol. 1: The Protocols. Addisona] Wesley, 1999, 14th ed.

[St99 Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 2: Theb] Implementation. Addison Wesley, 1999, 7th ed.

[St99 Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 3: TCP forc] transactions, HTTP, NNTP, and the UNIX Domain protocols. Addison Wesley, 1998, 4th ed.

[Ku97 Kuri J.: Da geht's lang! - Routing, oder: wie die Daten im Internetb] ihren Weg finden. c't 6/97, S. 380ff.

[Kus9 Kuschke M.: Vervierfacht - IPv6: neue Spezifikationen zur Lösung des4] Adreßdilemmas. ix 10/94, S. 132ff.

[MS9 Microsoft: Windows NT Server - Introduction to TCP/IP. White Paper,8] Microsoft Corporation, Redmond, 1998. Online verfügbar unter:http://www.microsoft.com/NTServer/nts/techdetails/compares/TCPIntrowp.asp.

[MS2 Microsoft: Introduction to IP Version 6. White Paper, Microsoft001] Corporation, Redmond, 2001. Online verfügbar unter:http://www.microsoft.com/technet/network/ipvers6.aps.

[OV9 Oberschelp W., Vossen G.: Rechneraufbau und Rechnerstrukturen.5] Oldenbourg, München, 1995, 6. Auflg.

[RFC] RFC'S - Requests For Comments: Liste aller RFC's (nach Nummern sortiert) http://www.rfc-editor.org oder: http://internic.net/ds/rfc- index.txt oder: ftp://ftp.nic.de/rfc/pub/doc/rfc Es gibt aber noch viele andere Adressen, unter denen die RFC's zubekommen sind - auch als email.

[Sa98 Santifaller M.: TCP/IP und ONC/NFS - Internetworking mit UNIX.] Addison Wesley, Bonn, Reding Massachucetts, 1998, 4. Auflage.

[Sch9 Schmidt J.: Firewall getunnelt - Geheimer Datenaustausch über ICMP-7a] Pakete. c't 11/97, S. 332ff.

[Sch9 Schmidt J.: Falsche Fährten - Mißbrauchsmöglichkeiten von ARP und7b] ICMP. c't 12/97, S. 246ff.

[Si20 Sietmann R.: Mobilmachung - Internetprotokoll Version 6. iX 4/2000,00] S. 100ff.

[St20 Stainov, R.: IPnG - Das Internet-Protokoll der nächsten Generation.00] Thomson Publishing, Bonn, 1997.

[St87 Stallings W.: Handbook of Computer Communications Standards, Vol.] I: The Open Systems Interconnection (OSI) Model and OSI-Related Standards. MacMillan Pub. Company, Indianapolis, 1987

[St88 Stallings W.: Handbook of Computer Communications Standards, Vol.a] II: Local Network Standards. MacMillan Pub. Company, New York, London, 1988

[St88 Stallings W.: Handbook of Computer Communications Standards, Vol.b] III: Department of Defense (DoD) Protocol Standards. MacMillan Pub. Company, New York, London, 1988

[St99 Stevens R. W.: TCP/IP Illustrated, Vol. 1: The Protocols. Addisona] Wesley, 1999, 14th ed.

[St99 Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 2: Theb] Implementation. Addison Wesley, 1999, 7th ed.

[St99 Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 3: TCP forc] transactions, HTTP, NNTP, and the UNIX Domain protocols. Addison Wesley, 1998, 4th ed.

Organisation	Abkürzung	URL
Internet Assigned Numbers Authority	IANA	www.iana.org/
Internet Corporation for Assigned Names and Numbers	ICANN	www.icann.org/
Asia Pacific Network Information Center	APNIC	www.apnic.net/
American Registry for Internet Numbers	ARIN	www.arin.net/
Réseaux IP Européens	RIPE	www.ripe.net/
Network Information Center	NIC	www.internic.net/
Internet Architecture Board	IAB	www.iab.org/
Internet Engineering Task Force	IETF	www.ietf.org/
Internet Research Task Force	IRTF	www.irtf.org/
Internet Societal Task Force	ISTF	www.istf.org/
Internet Society	ISOC	www.isoc.org/

MANPAGES

IFCONFIG

NAME

ifconfig ­ Konfiguration einer Netzwerkskarte

SYNOPSIS

ifconfig [Schnittstelle] ifconfig Schnittstelle [AF­Typ] Optionen | Adresse ...

BESCHREIBUNG

Ifconfig wird benutzt um kernel­residente Netzwerksschnittstellen zu konfigurieren. Es wird zur Systemstartzeit verwendet, um die Schnittstellen nach Notwendigkeit zu initialisieren. Danach wird es üblicherweise nur zur Fehlersuche oder zur Verfeinerung der Systemkonfiguration verwendet. Wenn keine Argumente angegeben werden, dann zeigt ifconfig den Zustand der Augenblicklich aktiven Netzwerksschnittstellen. Wird ein einzelne Schnittstellenargument angegeben, so zeigt es nur den Zustand der angegebenen Netzwerksschnittstelle an. Wird ein einzelne ­a Option angegeben, zeigt es den Zustand aller Schnittstellen an, selbst wenn diese inaktiviert sind. Ansonsten konfiguriert ifconfig eine Schnittstelle.

Adressfamilien

Wird das erste Argument hinter dem Schnittstellennamen als der Name einer unterstützten Adressfamilie erkannt, so wird diese Adressfamilie dazu benutzt um alle Protokolladressen zu dekodieren und darzustellen. Zur Zeit werden u.a. folgende Adressfamilien unterstützt. inet (TCP/IP, standard), inet6 (IPv6), ax25 (AMPR Packet Radio), ddp (Appletalk Phase 2), ipx (Novell IPX) and netrom (AMPR Packet radio).

OPTIONEN

Schnittstelle Der Name einer Netzwerksschnittstelle. Dies ist üblicherweise ein Treiber gefolgt von einer laufenden Nummer, z.B. eth0 für die erste Ethernetschnittstelle

up

Diese Flagge aktiviert die Schnittstelle. Sie wird implizit gesetzt, wenn eine Adresse einer Schnittstelle zugewiesen wird.

down

Durch diese Flagge wird der Treiber für die Schnittstelle deaktiviert.

[­]arp

Schaltet das ARP­Protokoll auf dieser Schnittstelle ein oder aus.

[­]promisc

Ein-/Ausschalten des promiscuous Modus der Schnittstelle. Ist er eingeschaltet, so werden alle Pakete vom Netzwerk empfangen unabhängig davon, ob sie an die Schnittstelle adressiert sind.

[­]allmulti

Ein­/Ausschalten des all­multicast Modus. Ist er eingeschaltet, so werden alle Multicastpakete vom Netzwerk empfangen unabhängig davon, ob sie an die Schnittstelle adressiert sind oder nicht.

metric N

Dieses Argument setzt den Metrik­Wert für die Schnittstelle auf N.

mtu N

Dieses Argument setzt die Maximum Transfer Unit (MTU) der Schnittstelle. Dies ist das grösste Paket, das gesendet werden kann.

dstaddr addr

Setzt die IP­Adresse der Gegenseite für Punkt­zu­Punkt­Verbindungen wie z.B. PPP. Dieses Schlüsselwort ist überholt; stattdessen sollte das pointopoint Schlüsselwort verwendet werden.

netmask Adr

Setzt die IP Netzwerksmaske für diese Schnittstelle. Die Voreinstellung ist abhängig von der IP­Adresse der Schnittstelle, die Maske für ein Klasse A, B oder C Netzwerk, kann aber auf jeden beliebigen Wert gesetzt werden.

add Adr/Prefixlen

Fügt der Schnittstelle eine IPv6­Adresse zu.

del addr/prefixlen Entfernt eine IPv6­Adresse von der Schnittstelle.

tunnel aa.bb.cc.dd

Erzeugt ein neues SIT (IPv6­in­IPv4) Gerät, das Pakete zum angegebenen Ziel tunnelt.

irq addr

Setzt die Interruptleitung, die von diesem Gerät benutzt wird. Nicht alle Geräte können ihre Interruptkonfiguration dynamisch ändern.

io_addr Adr

Setzt die I/O­Basisadresse für dieses Gerät.

mem_start Adr

Setzt die Startadresse für shared memory der von diesem Gerät benutzt wird. Dies wird nur von wenigen Geräten benötigt.

media Typ

Setzt den physikalischen Anschluss oder den Mediumstyp, der vom Gerät verwendet wird. Nicht alle Geräte können diese Einstellung ändern, und bei denjenigen, bei denen dies möglich ist, variieren die unterstützten Werte. Typische Werte f:ur Typ sind 10base2 (thin Ethernet), 10baseT (twisted­pair 10Mbps Ethernet), AUI (Externer Transceiver) und so weiter. Der spezielle Mediumstyp auto kann benutzt werden, damit der Treiber automatischen den Typ des Mediums erkennt. Wiederum unterstützen dies nicht alle Treiber.

[­]broadcast [Adr]

Wird das Adressargument gegeben, so wird die Protokolladresse für Broadcast für diese Schnittstelle gesetzt. Ansonsten wird die IFF_BROADCAST Flagge für diese Schnittstelle gesetzt bzw. gelöscht.

[­]pointopoint [Adr]

Dieses Schlüsselwort aktiviert den Punkt­zu­Punkt Modus einer Schnittstelle. Das bedeutet, dass eine Verbindung zwischen zwei Maschinen direkt ist, ohne dass weitere Maschinen mithören. Wird auch ein Adressargument gegeben, so wird die Protokolladrsse auf der Gegenseite der Verbindung gesetzt, genau wie beim jetzt überholten dstaddr Schlüsselwort. Ansonsten wird die IFF_POINTOPOINT Flagge für die Schnittstelle gesetzt bzw. gelöscht.

hw Klasse Adresse

Setzt die Hardwareadresse dieser Schnittstelle, wenn der Gerätetreiber diese Operation unterstützt. Das Schlüsselwort muss vom Namen der Hardwareklasse und der ASCII­ Darstellung der Hardwareadresse gefolgt werden. Zur Zeit werden unter anderem folgende Hardwareklassen unterstützt: ether (Ethernet), ax25 (AMPR AX.25), ARCnet and netrom (AMPR NET/ROM).

multicast

Setzt die Multicastflagge der Schnittstelle. Dies sollte im Normalfall nicht benötigt werden, da die Treiber die Flagge selbst setzen.

Adresse

Die IP­Adresse, die der Schnittstelle zugewiesen wird.

txqueuelen L:ange

Setzt die Länge der Sendewarteschlange des Geräts. Es kann nützlich sein, diesen Wert auf einen kleinen Wert für langsame Geräte mit hoher Paketlaufzeit (Modems, ISDN) zu setzen um zu verhindern, dass schnelle Grossübertragungen interaktiven Verkehr wie Telnet zu sehr stören.

BEMERKUNGEN

Seit Kernel Version 2.2 gibt es keine expliziten Statistiken für Schnittstellenaliase mehr. Die Statistiken für die Originaladresse werden mit allen Aliasen auf das gleiche Gerät geteilt. Um Statistiken per Adresse zu erhalten sollte explizite EInträge für die Adresse mit dem ipchains(8) Kommando gemacht werden.

DATEIEN

/proc/net/socket

/proc/net/dev

/proc/net/if_inet6

TCPDUMP

NMAP

nmap ist ein Portscanner, der einen Zielrechner auf offene Ports, also potentielle Sicherheitslücken, durchsuchen kann. Ihm entgegenzuwirken ist die Aufgabe von snort, einem Daemon, der ein Netzwerk auf verdächtige Pakete durchscannt und diese mitprotokolliert. Die Welt der Netzwerksicherheit ist zweigeteilt: entweder gute oder böse Absichten, entweder White Hat oder Black Hat, und dazwischen meist ein tiefer Abgrund. Dabei sind sie sich ähnlicher als die meisten von ihnen zugeben würden und auf jeden Fall benutzen sie die gleichen Werkzeuge. Denn sicherlich wird jeder sicherheitsbewusste Netzwerkadministrator auch einmal einen Portscanner benutzen wollen und jeder Hacker wird sich der grundsätzlichen Unsicherheit jedes TCP/IP-Netzwerks bewusst sein, so dass bei vielen von ihnen auch ein Network Intrusion Detection System das LAN überwacht.

nmap - die dunkle Seite

nmap - der "Network Mapper" - wurde von dem Hacker "Fyodor" primär für das Scannen großer Netzwerke entworfen, funktioniert aber natürlich auch für einzelne Hosts. Durch die große Anzahl möglicher Scans und Optionen existieren fast immer mehrere Möglichkeiten, ein- und dasselbe "Ziel" zu erreichen: Manchmal benötigt man einen "schnellen" Scan, manchmal will man nur minimale Spuren auf dem Zielsystem hinterlassen. In wieder anderen Fällen ist es eventuell erforderlich, eine Firewall zu umgehen; oder man möchte nach verschiedenen Protokollen (UDP, TCP, ICMP, etc.) scannen.

Verbergen der eigenen IP-Adresse

Desweiteren kann man noch eine sogenannte "decoy"-Option (-D) aktivieren - sie verhindert, dass die Gegenseite erkennt, welcher Host den Scan nun tatsächlich initiiert hat. Durch die Angabe der Option -Ddecoy1. host.com,ME,decoy2.host.com "fälscht" nmap Pakete mit den Absendeadressen von decoy1.host.com und decoy2.host.com.

Sind sowohl decoy1.host.com als auch decoy2.host.com "up", schicken diese ihrerseits, wie erwartet, RST-Pakete, sodass für die Zielmaschine decoy1.host.com, decoy2.host.com und der lokale Host ununterscheidbar sind. Sind die decoy-Hosts "down", so wird das Ziel unseres Scans mit SYN-Paketen überflutet.

Im Standardmodus benutzt nmap einen ICMP-Ping und einen TCP-ACK-Ping mit Quellport Port 80 (Port 80 wird oft wegen HTTP-Requests durch Firewalls durchgelassen), um zu bestimmen, ob Maschinen "up" sind. Danach wird der Portscan durchgeführt. Als letztes wird versucht, das Betriebssystem des ge- scannten Hosts zu bestimmen.

Ganz offensichtlich kann man für ein Intrusion Detection System (IDS) sehr leicht eine Regel schreiben, die einen nmap-Scan sicher erkennen kann. Daher kann man zum Beispiel mit -P0 den ICMP-Ping deaktivieren; explizites Aktivieren des TCP-Pings geschieht durch -PT.

Beispiele

% nohup nmap -r -iR -I -sT -p53 > named.scan.out &

% tail -f named.scan.out

Hiermit gehen wir auf die Suche nach Maschinen, auf denen der named als root läuft. Die Option -r scannt die Ports der Zielmaschine in einer zufälligen Reihenfolge, -iR wählt zufällige IP's als Ziel der Scans aus, -I aktiviert den reverse ident scan, der nur mit einem TCP-connect()-Scan (-sT) funktioniert. -p53 definiert schließlich Port 53 als Scanziel.

Im zweiten Beispiel wollen wir target.host scannen, dabei aber einer allzu leichten Entdeckung entgehen. Wir benutzen daher einige Decoy Hosts:

% nohup nmap -r -P0 -sS -Ddecoy1,decoy2,decoy3,decoy4,decoy5 target.host

Dabei sollten die Hosts decoy1 bis decoy5 existieren und erreichbar beziehungsweise "up" sein. Die Option -P0 deaktivert das ping-en von target.host vor dem Scan - wir gehen davon aus, dass er "up" ist. -sS aktiviert den SYN-Scan und -Ddecoy1,decoy2,decoy3,decoy4,decoy5 nutzt die Hosts decoy1 bis decoy5 um ein wenig Verwirrung zu stiften.

Route

OPTIONEN

-v

schaltet ausführliche Ausgaben an.

-A

Adressfamilie Benutzt die angegebene Adresse, z.B. inet oder inet6.

-n

zeigt numerische Adressen an, d.h. es wird nicht mehr versucht IP- Adressen in symbolische Hostnamen umzuwandeln. Dies kann z.B. nützlich sein, wenn der Nameserver nicht mehr erreichbar ist, z.B. weil keine Route existiert.

-e

Schaltet das Ausgabeformat von netstat(8) für die Anzeige der Routentabelle an. -ee gibt eine sehr lange Zeile mit allen Routenparametern aus der Routentabelle aus.

-net

Das Ziel ist ein Netzwerk.

-host

das Ziel ist ein Rechner

-F

zeigt die FIB Routentabelle des Kerns an. Das Ausgabeformat kann mit den Optionen -e und -ee geändert werden.

-C

zeigt den Routencache des Kernels an.

del

löscht eine Route.

add

fügt eine Route zu.

Ziel

Das Zielnetzwerk oder -System. Die Angabe sowohl von IP-Adressen in Form von dezimalen durch Punkt getrennten Quadrupeln, als auch Rechner- und Netznamen ist zulässig.

netmask Nm

ändert die Netzwerksmaske der Route, die zugefügt werden soll.

gw Router

Alle IP-Pakete für das Zielnetzwerk / -System werden zum angegebenen Router weitergeleitet.

ANMERKUNG: Das angegebene Ziel muss zuerst erreichbar sein. Üblicherweise bedeutet dies, dass zuerst eine statische Route zum Router eingetragen werden muss. Wird die Adresse einer lokalen Schnittstelle angegeben, so wird sie benutzt um zu entscheiden zu welcher Schnittstelle die Pakete weitergeleitet werden. Dieses Merkmal dient der Kompatibilität mit BSD.

metric M

Setzt das Metric-Feld der Routentabelle, das von Routendämonen verwendet wird, auf M.

mss M

Setzt den MSS-Wert (Maximum Segment Size) für TCP-Verbindungen über diese Route auf M bytes. Diese Einstellung kann verwendet werden um eine kleinere MTU zu erzwingen, wenn Path MTU Discovery nicht funktioniert (normalerweise weil ein Firewall dazwischen ist der ICMP Fragmentation Needed blockt). Die Standardeinstellung ist die MTU des Netzwerkinterfaces minus Headers oder eine kleinere, falls bekannt.

window W

Setzt das TCP-Fenster für Verbindungen über diese Route auf W bytes. Dies wird üblicherweise nur auf AX.25-Netzwerken und mit Treibern, die Probleme mit aufeinanderfolgenden Paketen haben, benutzt.

irtt A

Setzt die anfängliche Paketumlaufzeit (IRTT, Initial Round Trip Time) für TCP-Verbindungen auf A Millisekunden. Erlaubte Werte sind im Bereich von 1-12000 Milisekunden. Dies wird üblicherweise nur auf AX.25 Netzwerken benutzt. Wenn ausgelassen, dann wird der Standardwert aus RFC1122 von 300ms benutzt.

reject

Installiert eine Blockaderoute, die im Abbruch der Suche nach einer Route resultiert. Dies wird zum Beispiel benutzt um Netzwerke auszumaskieren, bevor die Standardroute verwendet wird. Dieses Merkmal ist NICHT zur Verwendung als Firewall gedacht.

mod, dyn, reinstate

Installiert eine dynamische oder modifizierte Route. Beide Flaggen werden im allgemeinen nur von Routendämonen verwendet und dienen im route(8) Kommando nur zu diagnostischen Zwecken.

dev Schnittstelle

Erzwingt, dass die Route mit der angegebenen Schnittstelle assoziiert wird. Ansonsten würde der Kern selbstständig versuchen, die Schnittstelle durch Überprüfung bereits existierender Routen, Schnittstellenspezifikationen und der Stelle, zu der die Route zugefügt wird, festzustellen. In den meisten normalen Netzwerken wird dies nicht benötigt. Wird als letzte Option dev Schnittstelle angegeben, so kann das Schlüsselwort dev ausgelassen werden, da es Standardwert ist. Ansonsten ist die Reihenfolge der Optionen (metric, netmask, gw und dev), die die Route verändern, egal.

BEISPIELE

route add -net 127.0.0.0

erzeugt die normale Loopbackroute mit der Netzmaske 255.0.0.0 (Netzwerk Klasse A, ermittelt aus der Zieladresse) und assoziert sie mit der Schnittstelle lo unter der Annahme, dass dieses Gerät vorher mit ifconfig(8) konfiguriert wurde.

route add -net 192.56.76.0 netmask 255.255.255.0 dev eth0

Legt eine Route zum Netzwerk 192.56.76.x über eth0 an. Die Angabe der Klasse C Netzmaske ist in diesem Fall nicht nötig. Das Wort dev darf in diesem Fall ausgelassen werden.

route add default gw mango-gw

legt eine Standardroute, d.h. eine Route die verwendet wird, wenn keine andere Route passt, an. Alle Pakete über diese Route werden über mango- gw weitergeleitet. Die Schnittstelle, die tatsächlich für diese Route verwendet wird, hängt davon ab, wie mango-gw erreicht werden kann. Zuvor muss mango-gw bereits über eine andere Route erreicht werden können.

route add ipx4 sl0

Legt eine Route zum Rechner ipx4 über die SLIP-Schnittstelle an. Dabei wird angenommen dass ipx4 der SLIP-Rechner auf der Gegenseite ist.

route add -net 192.57.66.0 netmask 255.255.255.0 gw ipx4

Dieses Kommando sorgt dafür, dass das Netz 192.57.66.x über die obige Route über die SLIP-Schnittstelle weitergeleitet wird.

route add 224.0.0.0 netmask 240.0.0.0 dev eth0

Dieses etwas obscure Beispiel wird hier dokumentiert, um zu zeigen, wie Multicastrouten angelegt werden. Durch diese Route werden alle Pakete der Klasse D (Multicast) über eth0 weitergeleitet. Diese ist die korrekte Konfiguration für einen Kernel mit Multicast-Unterstützung.

route add 10.0.0.0 netmask 255.0.0.0 reject

Dies installiert eine zurückweisende Route für das private Netzwerk 10.x.x.x.

AUSGABE

Die Ausgabe der Kernelroutentabelle besteht aus folgenden Spalten

Ziel

    Das Zielnetzwerk oder -System.

Router

    Die Adresse des weiterleitenden Routers oder "*", wenn keine gesetzt ist.

Genmask

    Die Netzmaske für das Zielnetz; '255.255.255.255' für ein einzeles
    Zielsystem und '0.0.0.0' für die Standardroute (. default).

Flaggen

    Mögliche Flaggen sind
    U Route ist aktiviert ( up)

H Ziel ist ein einzelner Rechner

G Benutzt einen Router als gateway

R modifiziert eine Route bei dynamischem Routen

D Route ist dynamisch von einem daemon oder redirect-Paket erzeugt worden.

M modified von einem Routendämon oder redirekt-Paket.

! (zurückweisendeRoute)

Metric

    Der Abstand zum Ziel, d.h. üblicherweise die Anzahl der Zwischenrouter.
    Dieser Wert wird von aktuellen Kernen nicht verwendet, kann aber u.U.
    von Routendämonen benötigt werden.

Ref

    Anzahl der Referenzen auf diese Route. Wird vom Linux Kernel nicht
    benutzt.

Benutzer

    Zahl der Suchvorgänge nach dieser Route. Abhängig von -F oder -C werden
    entweder fehlgeschlagene Suchen im Cache (-F) oder Cache-Treffer (-C)
    angezeigt.

Schnittstelle

    Schnittstelle auf die Pakete für diese Route geleitet werden.

MSS

    Maximale Segmentgrösse für TCP-Verbindungen über diese Route.

Fenster

    Voreinstellung für die Fenstergrösse von Verbindungen über diese Route.

irtt

    Anfängliche Paketumlaufszeit (IRTT, Initial Round Trip Time). Der Kernel
    benutzt diesen Wert um die bestmöglichen Parameter für das TCP-Protokoll
    abzuschätzen ohne möglicherweise auf eventuell langsame Antworten
    warten zu müssen.

HH (cached only)

    Die Anzahl der ARP-Einträge und gecachten Routen, die den Hardware-
    headercache der gecachten Route referenzieren. Die ist -1 wenn keine
    Hardwareadresse nicht für den Eintrag der gecachten Route benötigt wird,
    z.B. für lo.

Arp (nur gecachet)

    Nur wenn die Hardwareadresse für die gecachte Route aktuell ist.

DATEIEN

/proc/net/ipv6_route

/proc/net/route

/proc/net/rt_cache

SIEHE AUCH

ifconfig(8), netstat(8), arp(8), rarp(8)

GESCHICHTE

Route für Linux wurde ursprünglich von Fred N. van Kempen geschrieben (waltje@uwalt.nl.mugnet.org) und dann von Johannes Stille und Linus Torvalds für pl15 verändert. Alan Cox hat die mss und window Optionen für Linux 1.1.22 hinzugefügt. Bernd Eckenfels hat schliesslich die Unterstützung für irtt beigesteuert und den Code mit dem von Netstat vereinigt.

traceroute

NETSTAT

(no option)

Ohne Optionen zeigt netstat den Zustand von offenen Sockets an. Wird keine Adressfamilie angegeben, dann werden die offenen Sockets aller konfigurierten Adressfamilien gedruckt. Die Option -e gibt zusätzliche Informationen aus (User ID). Mit der Option -v gibt netstat zusätzlich Fehlermeldungen über vom Kernel nicht unterstützte Adressfamilien aus. Die Option -p gibt zusätzlich die PID und den Namen des Programms, das den Socket geöffnet hat, aus. -a druckt alle Sockets einschliesslich der auf Verbinungen wartenden Serversockets aus. Die Adressfamilie inet zeigt RAW, UDP und TCP Sockets an.

-r, --route

Die -r, --route Option gibt die Routentabellen des Kernels im gleichen Format wie route -e aus. netstat -er benutzt das Ausgabeformat von route. Für mehr Details siehe route(8).

-i, --interface Schnittstelle

Wird die -i, --interfaces Option verwendet, so wird eine Tabelle aller (oder der angegebenen Schnittstellen) ausgedruckt. Die Ausgabe ist im Format von ifconfig -e und wird in ifconfig(8) beschrieben. netstat -ei druckt eine Tabelle oder einen Eintrag für ein einzelnes Interface wie bei ifconfig. Die -a Option schliesst Schnittstellen, die gar nicht konfiguriert sind in die Ausgabe ein, (d.h. Alle, die U=UP Flagge nicht gesetzt haben).

-M, --masquerade Eine Liste aller maskierten Sitzungen wird dargestellt. Maskieren wird dazu verwendet um Maschinen mit inoffiziellen Netzwerkssitzungen vor der Aussenwelt zu verstecken. Dies wird in ipfw(4), ipfwadm(8) und ipfw(8) beschrieben.

-N, --netlink

Aktuelle Kernel unterstützen die Kommunikation zwischen Kernel und Anwendungen durch eine Option namens Netlink. Netlink ermöglicht es Informationen über die Erzeugung und das Löschen von Schnittstellen oder Routen von /dev/route (36,0) zu erhalten.

OPTIONEN

-v, --verbose

macht detailiertere Ausgaben. Insbesondere wird ausgegeben, welche Adressfamilien nicht im Kern konfiguriert sind.

-n, --numeric

gibt numerische Adressen aus, statt zu versuchen, den symbolischen Rechner, Port oder Benutzernamen auszugeben.

-p, --programs

Zeigt den Prozessnamen und die PID des Eigentümers des Sockets, der ausgegeben wird. Nur der Eigentümer eines Prozess oder Root haben alle die dazu nötigen Privilegien.

-A, --af Familie

benutzt einen alternativen Weg, um Adressfamilien zu setzen. Familie ist eine durch Kommatas abgetrennte Liste von Schlüsselworten für Adressfamilien wie inet, unix, ipx, ax25, netrom und ddp. Dies hat den gleichen Effekt wie die Langoptionen --inet, --unix, --ipx, --ax25, --netrom und --ddp.

-c, --continous

Mit dieser Option wiederholt netstat im Sekundenabstand die Ausgabe, bis es abgebrochen wird.

AUSGABE

Aktive Internet-Verbindungen (TCP, UDP, RAW)

Proto

Das von Socket verwendete Protokoll (TCP, UDP, RAW).

Recv-Q

Die Anzahl von Bytes, die noch nicht von der Anwendung vom Socket abgeholt wurden.

Send-Q

Die Anzahl von Bytes, die von der Gegenseite noch nicht bestätigt wurde.

Lokale Adresse

Die lokale Adresse (lokaler Rechnername) und Portnummer des Sockets. Ausser bei Verwendung der -n Option wird die Socketadresse nach dem kanonischen Rechnernamen und die Portnummer in den zugehörigen Dienstenamen aufgelistet.

Gegenadresse

Die Adresse und Portnummer der Gegenseite des Sockets. Wie bei lokalen Adressen schaltet der -n Schalter die Umwandlung von Rechneradresse und Portnummer ab.

State

Der Zustand des Sockets. Da RAW-Sockets und UDP-Sockets üblicherweise keinen Zustand haben, kann diese Spalte leer bleiben. Normalerweise ist sie einer von mehreren Werten:

VERBUNDEN

    Der Socket hat eine etablierte Verbindung.

SYN_SENT

    Es wird versucht auf dem Socket eine Verbindung aufzubauen.

SYN_RECV

    Eine Verbindungsanfrage wurde von der Gegenseite empfangen.

FIN_WAIT1

   Der Socket wurde geschlossen und die Verbindung wird beendet.

FIN_WAIT2

   Die Verbindung ist geschlssen und der Socket wartet darauf, dass sie von
   der Gegenseite ebenfalls geschlossen wird.

TIME_WAIT

   Der Socket ist nach dem Schliessen im Wartezustand um Pakete zu
   handhaben, die sich eventuell noch im Netzwerk befinden.

CLOSE

   Der Socket wird nicht benutzt.

CLOSE_WAIT

   Die Gegenseite hat die Verbindung beendet und das Schliessen des
   Sockets wird erwartet.

LAST_ACK

   Die Gegenseite hat die Verbindung beendet und der Socket ist
   geschlossen; die Bestätigung wird abgewartet.

LISTEN

   Der Socket wartet auf eingehende Verbindungen. Diese Sockets werden
   nur angezeit, wenn die -a,--listening Option gegeben wird.

CLOSING

   Beide Sockets sind geschlossen es wurden aber noch nicht alle Daten
   geschickt.

UNKNOWN

   Der Zustand des Sockets ist unbekannt.

Benutzer

Der Name oder die Benutzer-ID des Eigentümers des Sockets.

PID/Program name

Durch einen Schrägstrich abgetrenntes Paar von Prozess-ID und Programmname des Programms, das diesen Socket besitzt. Die Option -p schaltet die Anzeige dieser Spalte ein. Es werden root Privilegien benötigt um die nötigen Daten zu erhalten. Für IPX Sockets sind diese Daten nicht verfügbar.

Aktive Sockets in der UNIX Dom:ane

Proto

Das Protokoll (in der Regel unix), das vom Socket verwendet wird.

RefCnt

Der Referenzzähler, d.h. die Zahl der Prozesse, die diesen Socket benutzen.

Flaggen

Die Flaggen, die angezeigt werden sind SO_ACCEPTON (angezeigt als ACC), SO_WAITDATA (W) oder SO_NOSPACE (N). SO_ACCECPTON wird auf unverbundenen Sockets verwendet, wenn die zugehörigen Sockets auf Verbindungsanfragen warten. Die anderen Flaggen sind normalerweise nicht von Interesse.

Typ

Es gibt verschiedene Arten von Socketzugriff:

SOCK_DGRAM

    Der Socket wird im verbindungslosen Datagram-Modus verwendet.

SOCK_STREAM

    Dies ist ein verbindungsorientierter Stream-Socket.

SOCK_RAW

    Der Socket wird als RAW-Socket verwendet.

SOCK_RDM

    Dieser Socket bedient zuverlässig zugestellte Nachrichten.

SOCK_SEQPACKET

    Dies ist ein Socket, der die Zustellung in der richtigen Reihenfolge
    garantiert.

SOCK_PACKET

    Socket mit direktem (RAW) Zugriff auf die Schnittstelle.

UNKNOWN

    Wer weiss, was uns die Zukunft bringt soll es hier hinschreiben :-)

Zustand

Dieses Feld enthält eines der folgenden Schlüsselworte:

FREI

    Der Socket ist unbenutzt

H:Ort

    Der Socket lauscht nach Verbindungsanfragen. Diese Sockets werden nur
    angezeigt, wenn die -a,--listening Option gesetzt ist.

VERBINDUNGSAUFBAU

    Auf dem Socket wird gerade eine Verbindung aufgebaut.

VERBUNDEN

    Auf dem Socket ist Verbindung aufgebaut.

VERBINDUNGSABBAU

    Die Verbindung des Sockets wird gerade abgebaut.

(empty)

    Der Socket hat keine Verbundung zu einem anderen Socket.

UNKNOWN

    Ein Socket sollte niemals in diesem Zustand sein.

PID/Programmname

Prozess-ID und Programmname des Programs, das diesen Socket hält. Details siehe oben unter Aktive Internetverbindungen.

Pfad

Zeigt den Pfadnamen an, über den der entsprechende Prozess in den Socket eingebunden ist.

Aktive IPX-Sockets

(Dieser Abschnitt sollte von jemandem geschrieben werden, der davon Ahnung hat.)

Aktive NET/ROM-Verdingungen

(Dieser Abschnitt sollte von jemandem geschrieben werden, der davon Ahnung hat.)

Aktive AX.25-Verbindungen

(Dieser Abschnitt sollte von jemandem geschrieben werden, der davon Ahnung hat.)

BEMERKUNGEN

Seit der Kernel Version 2.2 zeigt netstat -i keine Schnittstellenstatistiken von Schnittstellenaliasen mehr an. Um Statistiken per Schnittstelle zur erhalten, müssen jetzt mit dem ipchains(8) Befehl explizite Regeln zugefügt werden.

DATEIEN

/etc/services -- Die Zuordungstabelle für Netzwerksdienste

/proc/net/dev -- Informationen über Netzwerksschnittstellen

/proc/net/raw -- Informationen über RAW-Sockets

/proc/net/tcp -- Informationen über TCP-Sockets

/proc/net/udp -- Informationen über UDP-Sockets

/proc/net/igmp -- IGMP-bezogene Informationen

/proc/net/unix -- Informationen über UNIX-Sockets

/proc/net/ipx -- Informationen über IPX-Sockets

/proc/net/ax25 -- Informationen über AX25-Sockets

/proc/net/appeltalk -- Informationen über Appletalk-/DDP-Sockets

/proc/net/nr -- Informationen über NET/ROM-Sockets

/proc/net/route -- Informationen zu Kernelrouten

/proc/net/ax25_route -- Kernelinformationen zum AX25-Routen

/proc/net/ipx_route -- Kernelinformationen zum IPX-Routen

/proc/net/nr_nodes -- Kernelliste der NET/ROM-Knoten

/proc/net/nr_neigh -- Kernelliste der NET/ROM-Nachbarn

/proc/net/ip_masquerade -- Liste der maskierten Verbindungen.

SIEHE AUCH

route(8), ifconfig(8), ipfw(4), ipfw(8), ipfwadm(8) ipchains(8)

PROBLEME

Ändert sich der Zustand des Sockets während er gerade angezeigt wird, so kann unsinnige Information ausgegeben werden. Dies ist jedoch unwahrscheinlich. Die netstat -i die beschrieben wird sollte nach einigem Säubern der BETA- Version des Codes des Net-Tools Packets funktionieren.

ARP

NAME

arp - Manipulation des ARP-Caches

SYNOPSIS

arp [-vn] [-H Typ] [-i Schnittstelle] -a [Rechnername]

arp [-v] [-i if] -d Rechnername [pub]

arp [-v] [-H Typ] [-i Schnittstelle] -s Rechnername hw_adr [temp]

arp [-v] [-H Typ] [-i Interface] -s Rechnername hw_adr [netmask nm] pub

arp [-v] [-H Typ] [-i Schnittstelle] -Ds Rechnername ifa [netmask nm] pub

arp [-vnD] [-H Typ] [-i Schnittstelle] -f [Dateiname]

BESCHREIBUNG

Arp kann den ARP-Cache des Kernels auf verschiedene Arten manipulieren. Die hauptsächliche Verwendung ist es Adresszuordnungseinträge zu löschen und von Hand neue zu erzeugen. Zum Zweck der Fehlersuche ist möglich mit dem arp Programm den Inhalt des ARP-Caches vollständig auszugeben.

OPTIONEN

-v, --verbose

     Ausführlichere Ausgaben.

-n, --numeric

     macht numerische Adressausgaben statt zu versuchen, den symbolischen
     Rechner-, Port- oder Benutzernamen zu ermitteln.

-H type, --hw-type type

     Beim Setzen oder Auslesen des ARP-Caches schränkt diese Option ein, auf
     welcher Klasse von Einträgen arp operieren soll. Der Standardwert dieses
     Arguments ist ether (d.h. Hardwarecode 0x01 für IEEE 802.3 10Mbps
     Ethernet). Andere mögliche Werte sind Netzwerkstechnologien so wie z.B.
     ARCnet (arcnet) , PROnet (pronet) , AX.25 (ax25) and NET/ROM
     (netrom).

-a [Rechnername], --display [Rechnername]

     Zeigt die Einträge der angegebenen Rechner an. Wird kein hostname-
     Argument verwendet, so werden alle Einträge aufgelistet.

-d Rechnername, --delete Rechnername

     Alle Einträge für den angegebenen Host entfernen. Dies kann z.B. benutzt
     werden, wenn ein System angehalten wird.

-D, --use-device

     Die Hardwareadresse der Netzwerksschnittstelle ifa verwenden.

-i If, --device Schnittstelle

     Eine Netzwerksschnittstelle auswählen. Es werden nur Einträge für die
     angegebene Schnittstelle ausgedruckt. Beim Setzen von von permanenten
     oder temporären Einträgen wird diese Schnittstelle mit dem Eintrag
     assoziiert. Wird diese Option nicht verwendet, so versucht der Kernel auf
     Basis der Routentabelle eine Schnittstelle auszuwählen. Für pub Einträge
     ist die angegebene Schnittstelle diejenige, auf der ARP-Anfragen
     beantwortet werden.
     ANMERKUNG: Diese Schnittstelle muss eine andere sein als die, auf die
     die IP-Datagramme weitergeleitet werden.

-s Rechnername hw_addr, --set Rechnername

     Erzeugt manuel einen ARP Adresseintrag für den Rechner Rechnername
     in dem die Hardwareadresse auf hw_addr gesetzt ist. Das genaue Format
     der Hardwareadresse ist abhängig von der Hardwareklasse aber für die
     meisten Klassen kann man davon ausgehen, dass die übliche Darstellung
     verwendet wird. Für die Ethernetklasse sind dies sechs hexadezimale, von
     Doppelpunkten getrennte Bytes. Beim Zufügen von Proxy-ARP-Enträgen
     (das sind die mit der gesetzten publizieren Flagge) kann die Netmaske
     für ARP-Einträge für ganze Subnetze angegeben werde. Von dieser Praxis
     wird abgeraten. Sie wird von älteren Kerneln unterstützt, da sie
     gelegentlich nützlich ist. Wird die temp Flagge nicht angegeben, so
     werden die erzeugten Einträge nicht dauerhaft in den ARP-Cache
     eingetragen.
     ANMERKUNG: Ab der Kernelversion 2.2.0 ist es nicht mehr möglich ARP-
     Einträge für ganze Teilnetze zu erzeugen. Stattdessen wird automatisches
     Proxy ARP durchgeführt, d.h. wenn eine Route existiert und Forwarding
     eingeschaltet ist wird automatisch ein temporärer Proxyarpeintrag erzeugt.
     Siehe auch arp(7) für mehr Details.

-f Dateiname, --file Dateiname

     Ähnlich der -s Option, ausser, dass diesmal die Adressinformation aus der
     Datei Dateiname verwendet wird. Dies kann verwendet werden, wenn
     ARP-Einträge für viele Rechner erzeugt werden müssen. Der Name dieser
     Datei ist oft /etc/ethers, aber dies ist nicht offizieil standardisiert. Wenn
     kein Dateinamen angeben ist wird /etc/ethers benutzt.
     
     Das Format der Datei ist einfach; es enthält nur ASCII-Textzeilen, die aus
     einem Rechnernamen und einer Hardwareadresse, getrennt von einem
     Zwischenraum, bestehen. Zusätzlich können die Flaggen pub, temp and
     netmask angegeben werden.

Überall, wo Rechnername erwartet wird, kann auch eine IP-Adresse in Form eines durch Punkte getrennten Dezimalquadrupels angegeben werden. Aus Kompatiblitätsgründen können Rechnername und die Hardwareadresse auch vertauscht werden. Jeder vollständige Eintrag wird im ARP-Cache mit der C Flagge markiert. Permanente Einträge werden mit M und zu publizierende Einträge mit der P Flagge.

DATEIEN

/proc/net/arp,

/etc/networks

/etc/hosts

/etc/ethers

SIEHE AUCH

ethers(5), rarp(8), route(8), ifconfig(8), netstat(8)

telnet

NAME

telnet – Benutzer-Schnittstelle zum TELNET Protokoll

SYNOPSIS

telnet [-S tos] [-e Fluchtzeichen] [-l Benutzer] [-n tracefile] [host [port]

BESCHREIBUNG

Das Programm telnet wird als Benutzerschnittstelle für die interaktive Kommunikation mit einem anderen Netzwerkrechners mittels Verwendung des telnet-Protokolls verwendet.Es strtet im Befehlsmodus, wo die Eigabeaufforderung 'telnet>' angezeigt wird. Wenn telnet mit 'host-argument' aufgerufen wird, wird der Befehl 'open' mit diesen Argumenten ausgeführt.

OPTIONEN

-a

    Durchführung einer automatischen Login-Prozedur auf dem entferneten
    System.

-d

    schaltet Debugging auf Socket-Ebene ein.

-e [Fluchtzeichen]

    Bestimmt Fluchtzeichen, mit dem die Telnet-Sitzung unterbrochen werden
    kann. Wird die Option -e ohne Angabe eines Fluchtzeichens verwendet,
    wird das vordefinierte Fluchtzeichen gelöscht.

-l Benutzer

    Der angegebene Benutzer wird, wenn die Verbindung zu einem entfernten
    System aufgebaut wird, als User für die Login-Prozedur übergeben (System
    muss die Option 'Environ' unterstützen).

-n tracefile

    Öffnet das angegebene Tracefile und schreibt Informationen zu einer
    TN3270-verbindung mit, wenn diese Variante unterstützt wird.

-r

    Emuliert rlogin. Das voreingestellt Escape-Zeichen ist eine Tilde. Ein
    Escape-Zeichen gefolgt von eienm Punkt führt zu eienm Abbruch der
    Verbindung. Ein ] (das voreingestellte Escape-Zeichen von telnet) erzeugt
    eine telnet-Eingabeaufforderung. Die Codes werden nur am Anfang einer Zeile verstanden.

-8

    Schaltet 8-Bit-Betrieb ein.

-E

    Schaltet die Escape-zeichen Funktionalität ab.

-L

    Legt einen 8-Bit-datenpfad für dei Ausgabe fest.

-S tos

    Setzt die Type-of-Service-Option (TOS) im IP-Protokoll für die telnet-
    verbindung auf den Wert tos

Befehle

Strg – Z

    Hält telnet an

close

    schliesst eien laufende Sitzung

display Argument

    Zeigt Einstellungen für alle oder für die als Argument angegebenen set
    und toggle Werte an

environ [Argumente[ ]]

    Manipuliert Variablen, die über die Telnet Environ-Option geschickt werden
    können

logout

    Unterstützt derv entfernte Host den logout-Befehl, wird die telnet-Sitzung
    beendet.

open [-l User] Host [Port]

    Öffnet eine Verbindung zum angegebenen Host. Wenn kein spezieller Port
    angegeben ist, wird der Kontakt über den Standardport von Telnet (23/TCP)
    hergestellt.

quit

    schliesst alle offenen telnet-Sitzungen und beendet das Programm

status

    zeigt aktuellen Status an. Der Netzwerkrechner, zu dem eine Verbindung
    besteht, und der aktuelle Modus werden ausgegeben

send Argumente

    Sendet Zeichensequenzen zum entfernten Rechner.

toggle Argumente

   Schaltet verschiedene Flags zur Steuerung der Telnet-Reaktion auf
   Ergebnisse.

ping

NAME

ping - sendet ICMP ECHO_REQUEST-Pakete an Netzwerk-Hosts

SYNOPSIS

ping [-dfnqrvR] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize]

BESCHREIBUNG

Ping benutzt das bei ICMP-Protokollen obligatorische ECHO_REQUEST Datagram um eine ICMP ECHO_RESPONSE von einem Host oder Gateway zu erhalten. ECHO_REQUEST Datagramme (pings) bestehen aus IP und ICMP-Header gefolgt von einem 'struct timeval' und einer belibigen Anzahl von 'pad bytes', die zum Auffüllen des Paketes dienen. Die Optionen lauten:

-c Anzahl

Stoppe nach (und Erhalt) Anzahl ECHO_RESPONSE Paketen.

-f

Flood ping. Sendet Pakete so schnell wie sie zurückkommen oder 100 Stück pro Sekunde, je nachdem was mehr ist. Für jedes gesendete ECHO_REQUEST wird ein '.' ausgegeben, für jedes erhaltene ECHO_REPLY ein 'backspace'. Dies ermöglicht eine schnelle Anzeige der Anzahl der 'gedroppten' Pakete. Die Option steht nur dem Super- User zur Verfügung. Sie kann grosse Auswirkungen auf die Geschwindigkeit eines Netzwerkes haben und soltte mit Vorsicht verwendet werden.

-i Wartezeit

Warte 'Wartezeit' Sekunden zwischen dem Senden einzelner Pakete. Standard ist eine Wartezeit von einer Sekunde zwischen jedem Paket. Die Option ist nicht kompatibel mit der -f -Option

-l preload

Wird diese Option verwendet sendet ping die gewählte Anzahl von Paketen so schnell wie möglich, bevor es zu seiner normalen Verhaltensweise zurückkehrt. Die Option steht nur dem Super-User zur Verfügung.

-n

Nur numerische Ausgabe. Es wird kein Versuch unternommen symbolische Hostnamen für Host-Adressen aufzulösen.

-p pattern

man kann bis zu 16 'pad bytes' angeben um das zu sendende Paket aufzufüllen. Dies kann bei der Diagnose von datenabhängigen Problemen in einem Netzwerk nützlich sein. Mit '-p ff' zum Beispiel wird das gesendete Paket komplett gefüllt.

-q

Es wird nichts angezeigt ausser der Zusammenfassung beim Start und beim Beenden.

-R

Aufzeichnungsroute. Erfasst die RECORD_ROUTE Option im ECHO_REQUEST Packet und zeigt den route buffer bei erhaltenen Paketen. Der IP-Header ist gross genug für neun solcher Routen. Viele Hosts ignorieren oder verwerfen diese Option.

-r

Umgehe sie normale Routing-Tabelle und versende direkt an den Host im eingebundenen Netzwerk. Ist der Host nicht in einem direkt eingebundenen Netzwerk wird eine Fehlermeldung zurückgegeben. Die Option kann verwendet werden um einen lokalen Host über ein Interface anzupingen, durch das keine Route läuft.

-s Paketgrösse

Legt die Anzahl der zu sendenden Datenbytes fest. Standard ist 56 (ergibt sich, wenn 64 ICMP data-bytes mit den 8 bytes der ICMP-Header Daten kombiniert werden)

-v

geschwätzige Ausgabe. Auch andere ICMP-Pakete als ECHO_RESPONSE die empfangen wurden, werden gelistet.

SIEHE AUCH

netstat, ifconfig, route

Ethereal/wireshark

Ethereal ist ein freier Netzwerkprotokollanalysator. Er erlaubt es sowohl Daten im laufenden Netzwerkbetrieb zu analysieren, als auch gesammelte Daten aus einem Capture-File zu lesen. Mit diesem Tool lassen sich Details über jedes einzelne TCP/IP-Paket anzeigen. Zusätzlich verfügt Ethereal über leistungsfähige Analyse- und Summary-Funktionen sowie eine eigene Sprache zum Filtern von Netzwerkpaketen. Um Ethereal wirklich effizient anzuwenden, benötigen Sie allerdings Know-how über die zu analysierenden Protokolle. Für den gelegentlichen Check, ob etwa ein Tool "nach Hause telefoniert", reicht Basiswissen. Das einzige Manko an Ethereal ist die etwas umständliche Definition der Filter. Die Installation unter Debian erfolgt als 'root' mit dem Befehl 'apt-get install ethereal'. Gestartet wird durch Eingabe von 'ethereal' an der Konsole. Will man 'ethereal' auch als 'normaler' User starten, sollte man mit 'visudo' die Datei '/etc/sudoers' etwa folgendermassen editieren:

Hinter 'User_Alias' folgt der Eintrag des priviligierten Benutzers, hinter 'Cmd_Alias' die entsprechende Anwendung. Am Ende werden die Einträge miteinander verknüpft.Durch die Einstellungen im obigen Beispiel ist auch die Eingabe eines Passwortes nicht nötig.

Nach dem Start sieht man folgendes Fenster:

Durch klicken auf 'Capture' und 'Start' gelngt man in folgendes Menu, das eine Anzahl verschiedener Optionen anbietet.

Unter Interface wählt man das entsprechende Interface aus (hier 'eth0'). Falls die Capture-Session nicht manuell beendet werden soll, kann man dies unter Count (Anzahl der aufgezeichneten Pakete), File size (Größe der temporären Stream-Datei) und Duration (Dauer der Capture-„Session) einstellen. Wenn man die Pakete im promiscuous mode aufzeichnet, bringt man die Karte dazu auch Pakete zu empfangen bzw. „durchzulassen“ die gar nicht an sie bestimmt sind. Durch Angabe eines Filters lässt sich die erfasste Datenmenge zur besseren Übersicht einschränken. Eine IP-Adresse wird mit dem Schlüsselwort 'host' ergänzt um eine Richtungsangabe ('dst' für das Ziel der Pakete, 'src' für die Quelle) angegeben. Man kann auch mehrere Filterkriterien mit 'and' bzw. 'or' verknüpfen und durch eine Klammer gruppieren. Im Feld 'Capture file' gibt man die Datei an, in der 'ethereal' den Datenverkehr ablegt. . Mit „Update list of packets in real time“ kann man sich die Pakete in Echtzeit anzeigen lassen, wobei hier die Filterfunktionen etc. dementsprechend langsamer ablaufen, da ständig neue Pakete hinzukommen (außerdem kann es hier zu Drops führen, da der Rechner unter Umständen stark belastet wird). Die Optionen „Enable MAC name resolution“, „Enable network name resolution“, „Enable transport name resolution“ sollte man deaktivieren, da das Programm sonst versucht die entsprechenden „Namen“ aufzulösen, was natürlich nicht (immer) möglich ist und zu einer extremen Verlangsamung der Auswertung führen kann (da es für jede Anfrage einen timeout-Wert gibt, der erst erreicht werden muss). Nachdem man auf „OK“ geklickt hat beginnt die Aufzeichnung, dabei sieht man wieder eine Art „Statistik“:

Man beendet die Aufzeichnung durch einen Klick auf 'Stop'. Damit wird die aufgezeichnete Datei geladen. Durch anklicken einer Zeile kann man sich nun Details über entsprechende Pakete anzeigen lassen.

Im oberen Fenster sieht man die Zeit, den Quell- und den Zielrechner, das Protokoll und Informationen. Im mittleren Fenster schlüsselt Ethereal die Struktur des ausgewählten Paketes nach Protokollschichten auf. Man kann sich durch Klicken auf das + Zeichen Informationen über die Protokolltypen im Deteil anzeigen lassen. Der untere Teil zeigt das oben ausgewählte Paket als Hex- und ASCII-Dump. Eine interessante Funktion ist 'Follow TCP Stream', mit dem der Ablauf eines Protokolls nachvollziehbar ist. Man markiert dazu das gewünschte Paket. Mit einem Klick auf die rechte Maustste öffnet sich ein Menu, in dem der erste Eintrag 'Follow TCP Stream' ist. Mit dem Anklicken öffnet sich ein Fenster, das den Inhalt des TCP-Streams (in der unteren Menuleiste können die Verbindungspartner ausgewählt werden) anzeigt.