Tcpip

Einfhrung in
TCP/IP
Heiko Holtkamp
(heikorvs.uni-bieleIeld.de)
AG Rechnernetze und Verteilte Systeme
Technische Fakultt, Universitt BieleIeld
18. Juni 1997
letzte nderung 14. Februar 2002
Einfhrung in TCP/IP Heilo Holtlamp
InhaItsverzeichnis
1 Vorwort............................................................................................................................................4
2 Grundlagen......................................................................................................................................5
2.1 Was ist ein Rechnernetz............................................................................................................5
2.2 Protokolle, Protokollhierarchien................................................................................................5
2.3 Eine kurze Geschichte des Internet............................................................................................6
2.4 Internet-Standards und Dokumentation.....................................................................................8
2.5 ReIerenzmodelle......................................................................................................................10
2.5.1 Das OSI-ReIerenzmodell.................................................................................................10
2.5.2 Das TCP/IP-ReIerenzmodell............................................................................................12
3 TCP/IP im Detail...........................................................................................................................14
3.1 Die TCP/IP-Protokoll-Architektur...........................................................................................14
3.2 Netzwerkschicht.......................................................................................................................16
3.3 Internet-Schicht........................................................................................................................16
3.3.1 Internet Protokoll (IP)......................................................................................................17
IP-Datengramm....................................................................................................................17
3.3.2 Adressierung auI der Internet-Schicht..............................................................................20
Protokollnummern................................................................................................................21
IP-Adressen..........................................................................................................................21
Private IP-Adressen..............................................................................................................25
Spezielle IP-Adressen...........................................................................................................25
Subnetting (Teilnetzwerke)..................................................................................................26
3.3.3 Fragmentierung................................................................................................................30
3.3.4 Internet Control Message Protocol (ICMP).....................................................................30
3.4 Transportschicht.......................................................................................................................32
3.4.1 Transmission Control Protocol (TCP).............................................................................32
Portnummern........................................................................................................................34
Der TCP-Header...................................................................................................................36
3.4.2 User Datagram Protocol (UDP).......................................................................................40
3.5 Applikationsschicht.................................................................................................................40
4 IP Version 6....................................................................................................................................42
4.1 Die ZukunIt..............................................................................................................................42
4.2 Classless InterDomain Routing (CIDR)..................................................................................43
4.3 Internet Protokoll Version 6 (IPv6).........................................................................................43
4.3.1 Die Merkmale von IPv6...................................................................................................44
4.3.2 Das IPv6 DatengrammIormat...........................................................................................45
4.3.3 Der IPv6-Basis-Header....................................................................................................45
4.3.4 IPv6-Erweiterungs-Header...............................................................................................47
Hop-by-Hop Options Header................................................................................................49
Routing Header.....................................................................................................................49
Seite 2
Fragment Header..................................................................................................................49
Destination Options Header.................................................................................................49
4.3.5 IPv6-Adressierung............................................................................................................49
5 Quellenverzeichnis.........................................................................................................................50
5.1 Anmerkungen zur Literatur......................................................................................................50
5.2 Literaturliste.............................................................................................................................52
5.3 Wichtige Organisationen.........................................................................................................55
Seite 3
1 Vorwort
,Despite its popularitv and widespread use, the details of TCP/IP protocols and the structure of
software that implements them remain a mvsterv to most computer professionals.
(Comer D.E., Stevens D.L.: Internetworling with TCP/IP, Vol. II)
Dieses Dokument ist die Ausarbeitung des Seminarvortrages Introduction to TCP/IP, den ich am
22. Mai und 5. Juni 1997 im Rahmen des Seminars UNIX Svstem Administration gehalten habe. Es
dient auch als Grundlage Ir eine EinIhrung in Netzwerkprotokolle in den Vorlesungen
Rechnernet:e, UNIX Svstemadministration und Internet: Werl:euge und Dienste, die von der AG
Rechnernetze und Verteilte Systeme an der Universitt BieleIeld gehalten werden.
Mittlerweile hat dieses Dokument einige Versionen hinter sich und wird weiterhin in
unregelmigen Abstnden berarbeitet. Es gibt immer wieder Punkte, die besser beschrieben
werden knnen, sich im LauIe der Zeit gendert haben oder ergnzt werden mssen. Insbesondere
sind der Grundlagenteil und der Abschnitt ber IPv6 immer noch nicht Iertig gestellt. Ich mchte
mich an dieser Stelle bei all denjenigen bedanken, die mir eine Rckmeldung und
nderungsvorschlge Ir diese Arbeit gegeben haben. Ich hoIIe, die Vorschlge in ihrem Sinne
auIgenommen zu haben.
ber Anregungen, Lob, Verbesserungsvorschlge und Kritik zu dieser Arbeit wrde ich mich
Ireuen. Das Dokument ist nicht als statisch gedacht, d. h. einmal geschrieben und damit vergessen,
sondern soll, wie gesagt, weiterhin ergnzt und verbessert werden.
Mit der letzten berarbeitung des Dokumentes habe ich mich entschieden, die Arbeit als PDF-
Dokument zu verIIentlichen. Da mir leider die Zeit Iehlt, die PDF-Version und die HTML-Version
nebeneinander auI einem aktuellen Stand zu halten, werden Berichtigungen, nderungen und
Neuerungen vorerst nur noch in der PDF-Version durchgeIhrt. Eventuell ergibt sich in ZukunIt ein
VerIahren, mit dem beide Versionen nebeneinander erzeugt werden knnen.
Diese Arbeit kann jeder Ir private Zwecle und fr die Lehre herunter laden und verwenden. Ich
mchte aber darum bitten, Ialls jemand diese Arbeit auI seinen eigenen Seiten verwenden mchte,
nicht einIach die Dateien zu kopieren, sondern einen Verweis auI die Seiten (bzw. auI die die Seite,
http://www.rvs.uni-bieleIeld.de/~heiko/tcpip) zu setzen. Wie schon gesagt, wird diese Arbeit
stndig berarbeitet und es ist rgerlich, wenn jemand eine veraltete Kopie im Netz zur VerIgung
stellt. Ebenso mchte ich darum bitten, dass die Namen der ursprnglichen Autoren der Arbeit
weiterhin genannt und nicht einIach aus dem Dokument gelscht werden (ist leider auch schon
vorgekommen).
BieleIeld, den 14. Februar 2002
Heilo Holtlamp
Seite 4
2 GrundIagen
2.1 Was ist ein Rechnernetz?
Diese Frage habe ich mir auch lngere Zeit gestellt. Die Literatur uert sich hierzu leider nicht so
ganz klar. Tanenbaum ,deIiniert ein Rechnernetz in |Tanenbaum1996| wie Iolgt:
,Das gan:e Buch hindurch wird der Begriff Rechnernet:e fr mehrere miteinander verbundene
autonome Computer verwendet. Zwei Computer gelten als miteinander verbunden, wenn sie
Informationen austauschen lnnen. Die Verbindung mu nicht aus einem Kupferlabel bestehen - es
lnnen auch Lichtwellenleiter, Milrowellen oder Kommunilationssatelliten benut:t werden. Die
Vorgabe, da die Computer autonom sein mssen schliet Svsteme, bei denen ein eindeutiges
Master/Slave-Verhltnis herrscht, von vornherein aus unserer Definition aus. Kann ein Computer
einen anderen beliebig ein- oder ausschalten oder steuern, besteht leine Unabhngigleit. Ein
Svstem mit einer Steuereinheit als Master und vielen Slaves ist lein Net:, ebensowenig wie ein
Grorechner mit entfernten Druclern und Terminals.
Nach dieser DeIinition ist ein Netz, das aus einer Anzahl von Java-Rechnern (oder sind es doch nur
Terminals) besteht kein Rechnernetz. Die Java-Rechner mssen ihr System erst aus dem Netz laden,
bevor mit ihnen ,autonom gearbeitet werden kann. Die Frage ist hier zustzlich: arbeiten Java-
Rechner wirklich autonom.
Deshalb mchte ich noch eine allgemeinere ,DeIinition eines Rechnernetzes aus |Comer1998|
geben:
,Das alte Modell, bei dem ein Grorechner den gesamten Rechenaufwand eines Unternehmens
bewltigte, wurde durch eines erset:t, bei dem eine groe An:ahl ein:elner miteinander
verbundener Rechner die Arbeit bernimmt. Ein solches Svstem nennt man Rechnernet:.
2.2 ProtokoIIe, ProtokoIIhierarchien
Protokolle sind Regeln, die den Nachrichtenaustausch - oder allgemeiner das Verhalten - zwischen
(Kommunikations)Partnern regeln (,Protocols are Iormal rules oI behaviour). Die Verletzung eines
vereinbarten Protokolls erschwert die Kommunikation oder macht sie sogar gnzlich unmglich.
Seite 5
Abbildung 1 Anordnung von Protolollen :u einem Protolollstapel.
Layer 4
Layer 3
Layer 2
Layer 1
Layer 4
Layer 3
Layer 2
Layer 1
Physical Medium
Layer 4 Protocol
Layer 3 Protocol
Layer 2 Protocol
Layer 1 Protocol
Layer 3/4 Interface
Layer 2/3 Interface
Layer 1/2 Interface
Ein Beispiel Ir ein Protokoll ,aus dem tglichen Leben ist z.B. der Funkverkehr: Die
Kommunikationspartner besttigen den EmpIang einer Nachricht mit Roger und leiten einen
Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindung schlielich mit Over and
out.
hnliche Protokolle werden auch beim Datenaustausch zwischen verschiedenen Computern
bentigt, auch wenn hier die Komplexitt der AnIorderungen etwas hher ist. AuIgrund dieser
hheren Komplexitt werden viele AuIgabe nicht von einem einzigen Protokoll abgewickelt. In der
Regel kommen eine ganze Reihe von Protokollen, mit verschiedenen TeilauIgaben, zum Einsatz.
Diese Protokolle sind dann in Form von Protokollschichten mit jeweils unterschiedlichen
Funktionen angeordnet.
2.3 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 Hhepunkt erlangte, wurde vom US-
Verteidigungsministerium (Department oI DeIence - DoD) eine Netzwerktechnologie geIordert, die
in einem hohen Ma gegenber AusIllen sicher ist. Das Netz sollte dazu in der Lage sein, auch im
Falle eines Atomkrieges weiter zu operieren. Eine Datenbermittlung ber TeleIonleitungen war zu
diesem Zweck nicht geeignet, da diese gegenber AusIllen zu verletzlich waren (sind). Aus diesem
Grund beauItragte das US-Verteidigungsministerium die Advanced Research Profects Agencv
(ARPA) mit der Entwicklung einer zuverlssigen Netztechnologie. Die ARPA wurde 1957 als
Reaktion auI den Start des Sputniks durch die UdSSR gegrndet. Die ARPA hatte die AuIgabe
Technologien zu entwickeln, die Ir das Militr von Nutzen sind. Zwischenzeitlich wurde die
ARPA in Defense Advanced Research Profects Agencv (DARPA) umbenannt, da ihre Interessen
primr militrischen Zwecken dienten. Die ARPA war keine Organisation, die WissenschaItler und
Forscher beschItigte, sondern verteilte AuItrge an Universitten und Forschungsinstitute.
Um die geIorderte Zuverlssigkeit des Netzes zu erreichen, Iiel die Wahl darauI, das Netz als ein
paletvermitteltes Net: (paclet-switched networl) zu gestalten. Bei der Paketvermittlung werden
zwei Partner whrend der Kommunikation nur virtuell miteinander verbunden. Die zu
bertragenden Daten werden vom Absender in Stcke variabler oder Iester Lnge zerlegt und ber
die virtuelle Verbindung bertragen; vom EmpInger werden diese Stcke nach dem EintreIIen
wieder zusammengesetzt. Im Gegensatz dazu werden bei der Leitungsvermittlung (circuit
switching) Ir die Dauer der Datenbertragung die Kommunikationspartner Iest miteinander
verbunden.
Ende 1969 wurde von der Universitv of California Los Angeles (UCLA), der Universitv of
California Santa Barbara (UCSB), dem Stanford Research Institute (SRI) und der Universitv of
Utah ein experimentelles Netz, das ARPANET, mit vier Knoten in Betrieb genommen. Diese vier
Universitten wurden von der (D)ARPA gewhlt, da sie bereits eine groe Anzahl von ARPA-
Vertrgen hatten. Das ARPA-Netz wuchs rasant (siehe Abbildung) und berspannte bald ein groes
Gebiet der Vereinigten Staaten.
Mit der Zeit und dem Wachstum des ARPANET wurde klar, dass die bis dahin gewhlten
Seite 6
Protokolle nicht mehr Ir den Betrieb eines greren Netzes, das auch mehrere (Teil)Netze
miteinander verband, geeignet war. Aus diesem Grund wurden schlielich weitere
Forschungsarbeiten initiiert, die 1974 zur Entwicklung der TCP/IP-Protololle bzw. des TCP/IP-
Modells Ihrten. TCP/IP wurde mit mit der Zielsetzung entwickelt, mehrere verschiedenartige
Netze zur Datenbertragung miteinander zu verbinden. Um die Einbindung der TCP/IP-Protokolle
in das ARPANET zu Iorcieren beauItragte die (D)ARPA die Firma Bolt, Beranel & Newman
(BBN) und die Universitv of California at Berlelev zur Integration von TCP/IP in Berkeley UNIX.
Dies bildete auch den Grundstein des ErIolges von TCP/IP in der UNIX-Welt.
Im Jahr 1983 wurde das ARPANET schlielich von der Defence Communications Agencv (DCA),
welche die Verwaltung des ARPANET von der (D)ARPA bernahm, auIgeteilt. Der militrische
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 oIIizielle 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 ursprnglichen Form existiert
heute nicht mehr, das MILNET ist aber noch in Betrieb.
Hinweis: Das Denic Ihrt Statistiken zum Wachstum des Internet in Deutschland. Die
Statistiken sind unter der Adresse http://www.denic.de/de/domains/statistiken/index.html
verIgbar
Die Sammlung von Netzen, die das ARPANET darstellte, wurde zunehmend als Net:verbund
Seite 7
Abbildung 2 Wachstum des ARPANET a)De:ember 1969 b)Juli 1970 c)Mr: 1971 d)
April 1971 e)September 1972. (Quelle: [Tanenbaum1996])
betrachtet. Dieser Netzverbund wird heute allgemein als das Internet bezeichnet. Der Leim, der das
Internet zusammenhlt, sind die TCP/IP-Protokolle.
Hinweis: Weitere InIormationen zur Geschichte des Internet sind unter Iolgenden Adressen
zu Iinden:
Internet Society - ISOC: History oI the Internet
(http://www.isoc.org/internet/history/)
Musch J.: Die Geschichte des Netzes: ein historischer Abriss
(http://www.psychologie.uni-bonn.de/sozial/staII/musch/history.htm)
Hauben M.: Behind the Net: The Untold History oI the ARPANET and Computer Science
(http://www.columbia.edu/~rh120/ch106.x07)
Hauben R.: The Birth and Development oI the ARPANET
(http://www.columbia.edu/~rh120/ch106.x08)
w3history: Die Geschichte des World Wide Web
(http://www.w3history.org/)
Media History Project
(http://www.mediahistory.com/)
2.4 Internet-Standards und Dokumentation
Eine wichtige Rolle bei der Entstehung und Entwicklung des Internet spielen die so genannten
RFCs - Request for Comments. RFCs sind Dokumente, in denen die Standards Ir TCP/IP bzw. das
Internet verIIentlicht werden. Einige RFCs beschreiben Dienste und Protokolle sowie deren
Implementierung, andere Iassen Regeln und Grundstze (policies) zusammen. Standards Ir TCP/IP
werden immer als RFCs verIIentlicht, aber nicht alle RFCs beschreiben Standards. Einige RFCs
sind auch durchaus amsant zu lesen (darauI weist schon zum Teil das Datum der
VerIIentlichung , 1. April, hin):
RFC527 ARPAWOCKY
RFC968 - 'Twas the Night BeIore Start-up
RFC1118 The Hitchhiker's Guide to the Internet
RFC1149 A Standard Ior the Transmission oI IP Datagrams on Avian Carriers
RFC1180 - A TCP/IP Tutorial
RFC2324 Hyper Text CoIIe Pot Control Protocol (HTCPCP/1.0)
RFC2795 The InIinite Monkey Protocol Suite (IMPS)
u.a.
Die Standards Ir TCP/IP werden im wesentlichen nicht durch ein Komitee entwickelt, sondern
durch Diskussion und Konsens beschlossen. Jeder hat die Mglichkeit ein Dokument als RFC zu
verIIentlichen und so zur Diskussion zu stellen. Ist ein Dokument verIIentlicht, wird ihm eine
RFC-Nummer zugewiesen. RFCs werden IortlauIend nummeriert; zur Zeit gibt es etwa 3000.
Neben der eindeutigen RFC-Nummer haben RFCs einen beschreibenden Titel.
Das erste RFC wurde am 7. April 1969 von Steve Crocker versendet (RFC 1, ,Host-
SoItware). Steve Crocker und andere arbeiteten zusammen an dem Problem des Host-zu-
Host-Dialogs in einem Netzwerk. Sie beschlossen, die Diskussionen, die sie Ihrten,
Seite 8
schriItlich zu protokollieren, um spter auI diese AuIzeichnungen zurckgreiIen zu knnen.
Crocker arbeitete an der ZusammenIassung der Diskussionen und bezeichnete das Dokument
an dem er arbeitete, um ihm den Anschein von ,Amtlichkeit zu nehmen, als ,Request Ior
Comment (Ersuchen um Stellungnahme). |HaInerLyon2000|
Die Dokumente werden von einer Arbeitsgruppe und/oder dem RFC-Editor geprIt. Dabei
durchluIt das Dokument verschiedene StuIen, die StuIen der Entwicklung, Testung und Akzeptanz.
Die StuIen bilden den so genannten Standards Process. Die StuIen werden Iormal als maturitv
levels (Reifestufen) bezeichnet. Zustzlich zu seiner StuIe bekommt ein RFC einen Status.
Ton Postel (6. August 1943 16. Oktober 1998) gehrt zu den Pionieren des Internet.
Zusammen mit mit anderen (wie Bob Taylor, Vinton CerI, Frank Heart, Larry Roberts,
Leonard Kleinrock, Bob Kahn, Wesley Clark, Douglas Engelhart, Barry Wessler, Dave
Walden, Severo Ornstein, Truett Thach, Roger Scantlebury, Charlie HerzIeld, Ben Barker,
Steve Crocker, Bill Naylor, Roland Bryan |HaInerLyon2000|) arbeitete er an den Grundlagen
des ARPANET und des Internet. Postel war 30 Jahre lang Direktor der Internet Assigned
Numbers Authority (IANA). Daneben war er knapp 30 Jahre lang ,der RFC-Editor. Etwa
2.500 RFCs gingen durch seine Hnde und er prgte wesentlich das System und den ErIolg
der RFCs mit. In RFC1122 Iormulierte Postel einen zentralen Satz Ir das Design von
Protokollen im Internet: ,Be liberal in what vou accept, and conservative in what vou send.
Ein RFC, das einmal verIIentlicht ist,wird nie verndert oder aktualisiert. Es kann nur durch ein
neues RFC ersetzt werden. Bei einer Ersetzung wird das alte RFC mit der Bezeichnung ,Obsoleted
bv RFC xxx gekennzeichnet, das neue RFC beinhaltet einen Hinweis ,Obsolets RFC xxx auI das
alte RFC. Korrekturen an einem RFC werden durch ,Updates RFC xxx und ,Updated bv RFC
xxx gekennzeichnet. Einige RFCs beschreiben Protokolle, die durch bessere ersetzt wurden, diese
RFCs werden durch die Bezeichnung ,historic gekennzeichnet. Ein entsprechender Standard
erhlt den Status ,not recommended. RFCs, die sich in einer experimentellen Phase der
Entwicklung beIinden werden mit der Bezeichnung ,experimental versehen. Protokolle, die von
anderen Organisationen oder von Firmen entwickelt wurden und von Interesse Ir das Internet sind
werden zum Teil auch in RFCs verIIentlicht mit den Bezeichnungen ,informational oder ,best
current practice.
Neben der RFC-Nummer knnen RFCs auch STD-Nummern (Standard), FYI-Nummern (For Your
Interest) oder BCP-Nummern (Best Current Practice) erhalten. STDs, FYIs und BCPs sind
untergeordnete Kategorien von RFCs, die Dokumente mit einem bestimmten oder besonderen Inhlt
kennzeichnen. Die RFCs, STDs, FYIs und BCPs sind wiederum in ihrer Kategorie eindeutig,
IortlauIen nummeriert; ein Dokument kann also mehrere Nummern haben.
Der Prozess, wie RFCs verIIentlicht werden, ist ebenIalls in einem RFC, dem Internet Official
Protocol Standard (OPS), dokumentiert. Neben einer Erluterung, wie RFCs verIIentlich und
verIasst werden, enthlt es auch Verweise auI die derzeit aktuellsten RFCs der Protokollstandards.
Das OPS-RFC wird regelmig, jeweils nach 100 neuen RFCs, aktualisiert; RFC2600, RFC2700,
RFC2800 usw. Der Internet-Standardisierungsprozess ist in RFC2026 beschrieben. Im RFC2555
(30 Years oI RFCs) wird der technische und soziale Aspekt der RFCs erlutert.
Seite 9
Maturity Level Bedeutung
Proposed Standard (PS) Diese StuIe dauert mindestens 6 Monate und
erIordert zwei unabhngige Implementierungen.
DraIt Standard (DS) Diese StuIe dauert mindestens 4 Monate mit
Demonstrationen und einem ErIahrungsbericht mit
mindestens zwei unabhngigen
Implementierungen.
Standard (S oder STD) Das RFC ist zum oIIiziellen Standard erhoben.
Internet-Standards erhalten neben der RFC-
Nummer eine so genannte STD-Nummer (z.B.
Internet Protocol, RFC791, STD-5).
Status Bedeutung
Required Muss bei allen TCP/IP-basierten Hosts und Gateways
implementiert werden.
Recommended Es wird empIohlen, da alle TCP/IP-basierten Hosts
und Gateways die SpeziIikationen des RFCs
implementieren. Diese RFCs werden blicherweise
auch immer implementiert.
Elective Die Implementierung ist optional. Der Anwendung
wurde zugestimmt, ist aber nicht erIorderlich.
Limited Use Nicht Ir die generelle Nutzung gedacht.
Not recommended Nicht zur Implementierung empIohlen.
Das ,System der RFCs leistet einen wesentlichen Beitrag zum ErIolg von TCP/IP und dem
Internet. RFCs werden von zahlreichen Quellen im Internet zur VerIgung gestellt. In der
ReIerenzliste Iindet sich eine Angabe zu Quellen, bei denen die RFCs bezogen werden knnen.
2.5 ReferenzmodeIIe
2.5.1 Das OSI-ReferenzmodeII
Das Open Svstems Interconnection (OSI)-Referen:modell ist ein Modell, dass auI einem Vorschlag
der International Standards Organisation (ISO) basiert. Der AuIbau des OSI-Modells ist in
Abbildung 3 dargestellt.
Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von Protokollcharakteristika und
-Iunktionen |Tanenbaum1996|. Das OSI-Modell (die oIIizielle Bezeichnung lautet ISO-OSI-
Referen:modell) besteht aus sieben Schichten. Die Schichtung beruht auI dem Prinzip, dass 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 deIiniert werden. Das Modell beschreibt lediglich, welche AuIgaben die Schichten
erledigen sollen. Die Iolgenden Prinzipien haben zu den sieben Schichten des OSI-Modells geIhrt
Seite 10
|Tanenbaum1996|:
1. Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad bentigt wird.
2. Jede Schicht sollte eine genau deIinierte Funktion erIllen.
3. Bei der Funktionswahl sollte die DeIinition international genormter Protokolle
bercksichtigt werden.
4. Die Grenzen zwischen den einzelnen Schichten sollten so gewhlt werden, dass der
InIormationsIluss ber die Schnittstellen mglichst gering ist.
5. Die Anzahl der Schichten sollte so gro sein, dass keine Notwendigkeit besteht,
verschiedene Funktionen auI eine Schicht zu packen, aber so klein, dass die gesamte
Architektur nicht unhandlich wird.
Den Schichten im OSI-Modell sind die Iolgenden AuIgaben zugeordnet:
Anwendungsschicht (application layer): Die Anwendungsschicht enthlt eine groe Zahl huIig
bentigter Protokolle, die einzelne Programme zur Erbringung ihrer Dienste deIiniert haben. AuI
der Anwendungsschicht Iinden sich z.B. die Protokolle Ir die Dienste Itp, telnet, mail etc.
Darstellungsschicht (presentation layer): Die Darstellungsschicht regelt die Darstellung der
bertragungsdaten in einer von der darber liegenden Ebene unabhngigen Form.
Computersysteme verwenden z.B. oIt verschiedene Codierungen Ir Zeichenketten (z.B. ASCII,
Unicode), Zahlen usw. Damit diese Daten zwischen den Systemen ausgetauscht werden knnen,
kodiert die Darstellungsschicht die Daten auI eine standardisierte und vereinbarte Weise.
Sitzungsschicht (session layer): Die Sitzungsschicht (oIt auch Verbindungsschicht oder
Kommunikationssteuerschicht genannt) ermglicht den VerbindungsauI- und abbau. Von der
Sitzungsschicht wird der Austausch von Nachrichten auI der Transportverbindung geregelt.
Sitzungen knnen z.B. ermglichen, ob der TransIer gleichzeitig in zwei oder nur eine Richtung
erIolgen kann. Kann der TransIer jeweils in nur eine Richtung stattIinden, 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
AuIgabe, den DatenIluss zu steuern und die UnverIlschtheit der Daten sicherzustellen. Beispiele
Ir Protokolle der Transportschicht sind TCP und UDP.
Netzwerkschicht (network layer): Die Netzwerkschicht (Vermittlungsschicht) hat die
Seite 11
Abbildung 3 Das OSI-Referen:modell.
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
HauptauIgabe eine Verbindung zwischen Knoten im Netzwerk herzustellen. Die Netzwerkschicht
soll dabei die bergeordneten Schichten von den Details der Datenbertragung ber das Netzwerk
beIreien. Eine der wichtigsten AuIgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten
bzw. das Routing vom Absender zum EmpInger. Das Internet Protokoll (IP) ist in der
Netzwerkschicht einzuordnen.
Sicherungsschicht (data link layer): Die AuIgabe der Sicherungsschicht (Verbindungsschicht) ist
die gesicherte bertragung von Daten. Vom Sender werden hierzu die Daten in Rahmen (Irames)
auIgeteilt und sequentiell an den EmpInger gesendet. Vom EmpInger werden die empIangenen
Daten durch Besttigungsrahmen quittiert. Protokollbeispiele Ir die Sicherungsschicht sind HDLC
(high-level data link control), SLIP (serial line IP) und PPP (point-to-point Protokoll).
Bitbertragungsschicht (physical layer): Die Bitbertragungsschicht regelt die bertragung von
Bits ber das bertragungsmedium. Dies betriIIt die bertragungsgeschwindigkeit, die Bit-
Codierung, den Anschluss (wieviele Pins hat der Netzanschluss.) etc. Die Festlegungen auI der
Bitbertragungsschicht betreIIen im wesentlichen die EigenschaIten des bertragungsmedium.
2.5.2 Das TCP/IP-ReferenzmodeII
Im vorhergehenden Abschnitt wurde das OSI-ReIerenzmodell vorgestellt. In diesem Abschnitt soll
nun das ReIerenzmodell Ir die TCP/IP-Architektur vorgestellt werden. Das TCP/IP-
Referen:modell - benannt nach den beiden primren Protokollen TCP und IP der Netzarchitektur
beruht auI den Vorschlgen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das
TCP/IP-Modell ist zeitlich vor dem OSI-ReIerenzmodell entstanden, deshalb sind auch die
ErIahrungen des TCP/IP-Modells mit in die OSI-Standardisierung eingeIlossen. Das TCP/IP-
ReIerenzmodell 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 deIiniert:
Unabhngigkeit von der verwendeten Netzwerk-Technologie.
Unabhngigkeit von der Architektur der Hostrechner.
Universelle Verbindungsmglichkeiten im gesamten Netzwerk.
Ende-zu-Ende-Quittungen.
Standardisierte Anwendungsprotokolle.
Seite 12
Abbildung 4 Vergleich des OSI-Referen:modells mit dem TCP/IP-Referen:modell.
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Application Layer
Transport Layer
Internet Layer
Network Layer
Applikationsschicht (application layer): Die Applikationsschicht (auch Verarbeitungsschicht
genannt) umIasst alle hherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen
der Verarbeitungsschicht zhlen TELNET (Ir virtuelle Terminals), FTP (DateitransIer) und SMTP
(zur bertragung von E-Mail). Im LauIe der Zeit kamen zu den etablierten Protokollen viele weitere
Protokolle wie z.B. DNS (Domain Name Service) und HTTP (Hypertext TransIer Protocol) hinzu.
Transportschicht (transport layer): Wie im OSI-Modell ermglicht die Transportschicht die
Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-ReIerenzmodell wurden auI dieser
Schicht zwei Ende-zu-Ende-Protokolle deIiniert: das Transmission Control Protocol (TCP) und das
User Datagram Protocol (UDP). TCP ist ein zuverlssiges verbindungsorientiertes Protokoll, durch
das ein Bytestrom IehlerIrei zu einem anderen Rechner im Internet bermittelt werden kann. UDP
ist ein unzuverlssiges verbindungsloses Protokoll, das vorwiegend Ir AbIragen und Anwendungen
in Client/Server-Umgebungen verwendet wird, in denen es in erster Linie nicht um eine exakte,
sondern schnelle Datenbermittlung geht (z.B. bertragung von Sprache und Bildsignalen).
Internetschicht (internet layer): Die Internetschicht im TCP/IP-Modell deIiniert nur ein Protokoll
namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner verstehen knnen. Die
Internetschicht hat die AuIgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete
eine wichtige Rolle. Das Internet Control Message Protocol (ICMP) ist Iester Bestandteil jeder IP-
Implementierung und dient zur bertragung von Diagnose- und FehlerinIormationen Ir das
Internet Protocol.
Netzwerkschicht (network layer): Unterhalb der Internetschicht beIindet sich im TCP/IP-Modell
eine groe DeIinitionslcke. Das ReIerenzmodell sagt auI dieser Ebene nicht viel darber aus, was
hier passieren soll. Festgelegt ist lediglich, dass zur bermittlung von IP-Paketen ein Host ber ein
bestimmtes Protokoll an ein Netz angeschlossen werden muss. Dieses Protokoll ist im TCP/IP-
Modell nicht weiter deIiniert 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.
Seite 13
3 TCP/IP im DetaiI
3.1 Die TCP/IP-ProtokoII-Architektur
Die TCP/IP-Architektur wird, wie im Abschnitt ReIerenzmodelle, Das TCP/IP-ReIerenzmodell ge-
sagt, im allgemeinen als vierschichtiges Modell beschrieben. OIt wird das TCP/IP-ReIerenzmodell
auch als InIschichtiges Modell dargestellt. Andrew S. Tanenbaum bezeichnet das in
|Tanenbaum1996| vorgestellte InIschichtige Modell als hvbrides Referen:modell. Er schreibt in
|Tanenbaum1996| dazu:
,(...) Viertens unterscheidet das TCP/IP-Modell nicht :wischen den Bitbertragungs- und
Sicherungsschichten (erwhnt sie nicht einmal). Diese Schichten sind vllig unterschiedlich. Die
Bitbertragungsschicht hat mit den bertragungsmerlmalen von Kupferdarht, Glasfaser und
drahtlosen Kommunilationsmedien :u tun. Die Sicherungsschicht ist darauf beschrnlt, den
Anfang und das Ende von Rahmen ab:ugren:en und sie mit der gewnschten Zuverlssigleit von
einem Ende :um anderen :u befrdern. Ein lorreltes Modell sollte beides als separate Schichten
beinhalten. Das TCP/IP-Modell tut das nicht.
Die Schichtung beruht auI dem Prinzip, dass eine Schicht die angebotenen Dienste der darunter lie-
Seite 14
Abbildung 5 Die TCP/IP-Protololl-Architeltur.
Telnet FTP SMTP
Name
Server
NFS
X.25
Transmission Control
Protocol (TCP)
User Datagram
Protocol (UDP)
Internet Protocol (IP)
Internet Control Message Protocol (ICMP)
Ethernet Token Ring
Application Layer
Transport Layer
Internet Layer
Network Layer
Abbildung 6 Vergleich: OSI-Referen:modell, TCP/IP-Referen:modell, Hvbrides
Referen:modell.
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Application Layer
Transport Layer
Internet Layer
Network Layer
Application Layer
Transport Layer
Internet Layer
Network Layer
Physical Layer
genden Schicht in Anspruch nehmen kann. Dabei braucht die Schicht, die die Dienstleistung in An-
spruch nimmt keinerlei Kenntnisse darber haben, wie die geIorderten Dienste erbracht werden
bzw. implementiert sind. AuI diese Art und Weise wird eine AuIgabenteilung der Schichten erreicht
(siehe dazu auch ReIerenzmodelle, Das TCP/IP-ReIerenzmodell). Daten, die von einem Appli-
kationsprogramm ber ein Netzwerk versendet werden, durchlauIen den TCP/IP-Protokollstapel
von der Applikationsschicht zur Netzwerkschicht. Von jeder Schicht werden dabei
KontrollinIormationen in Form eines ProtokollkopIes angeIgt. Diese KontrollinIormationen dienen
der korrekten Zustellung der Daten. Das ZuIgen von KontrollinIormationen wird als Einlapselung
(encapsulation) bezeichnet.
Innerhalb der Schichten des TCP/IP-Modells werden Daten mit verschiedenen Termini benannt, da
jede Schicht auch ihre eigenen Datenstrukturen hat |Hunt1995|. Applikationen, die das
Transmission Control Protocol benutzen, bezeichnen Daten als Strom (stream); Applikationen, die
das User Datagram Protocol verwenden, bezeichnen Daten als Nachricht (message). AuI der
Transportebene bezeichnen die Protokolle TCP und UDP ihre Daten als Segment (segment) bzw.
Palet (paclet). AuI der Internet Schicht werden Daten allgemein als Datengramm (datagram)
benannt. OIt werden die Daten hier aber auch als Paket bezeichnet. AuI der Netzwerkebene
bezeichnen die meisten Netzwerke ihre Daten als Palete oder Rahmen (frames).
Seite 15
Abbildung 7 Dateneinlapselung [Hunt1995]
Data
Data
Data
Data
Header Header
Header Header Header
Application Layer
Transport Layer
Internet Layer
Network Layer
send
receive
Header
Abbildung 8 Be:eichnung der Daten auf den verschiedenen Schichten des
TCP/IP-Modells [Hunt1995].
TCP UDP
stream
segment
datagram
frame
message
packet
datagram
frame
Application Layer
Transport Layer
Internet Layer
Network Layer
3.2 Netzwerkschicht
Die Netzwerkschicht ist die unterste Schicht des TCP/IP-Modells. Protokolle, die auI dieser Schicht
angesiedelt sind, legen Iest, wie ein Host an ein bestimmtes Netzwerk angeschlossen wird und wie
IP-Pakete ber dieses Netzwerk bertragen werden.
Im Gegensatz zu den Protokollen der hheren Schichten des TCP/IP-Modells, mssen die Protokol-
le der Netzwerkschicht sich auI die Details des verwendeten Netzwerks - wie z.B. Paketgren,
Netzwerkadressierung, Anschlusscharakteristika etc. - beziehen. Die Netzwerkschicht des TCP/IP-
Modells umIasst also die AuIgaben der Bitbertragungsschicht und der Sicherungsschicht im OSI-
Modell.
Die Protokolle der Netzwerkschicht sind allerdings nicht im TCP/IP-Modell deIiniert. Wie schon
gesagt, legt das Modell lediglich Iest, dass zur bermittlung von IP-Paketen ein Host ber ein be-
stimmtes Protokoll an ein Netzwerk angeschlossen werden muss. Die Protokolle sind im Modell
nicht weiter deIiniert. Es werden hier vielmehr bestehende Standards verwendet und in das Modell
auIgenommen. Insbesondere bedeutet dies auch, dass mit neuer Hardware-Technologie auch neue
Protokolle auI der Netzwerkschicht entwickelt werden mssen, so dass TCP/IP-Netzwerke diese
Hardware verwenden knnen. Dies ist jedoch kein Nachteil, sondern eher ein Vorteil. Durch die
weitgehende Unabhngigkeit vom bertragungsmedium knnen neue Netzwerktechnologien
schnell in das TCP/IP-Modell auIgenommen werden.
Hinweis: Eine EinIhrung in den Ethernet-Standard (von Michael Blume) ist unter der Iol-
genden URL zu Iinden: http://www.rvs.uni-bieleIeld.de/~mblume/seminar/ss97/ethernet
3.3 Internet-Schicht
Das Internet ist eine Sammlung von Teilnetzen, die miteinander verbunden sind. Es gibt keine echte
Struktur des Netzes, sondern mehrere grere Baclbones, die quasi das Rckgrat (wie der Name
Backbone ja schon sagt) des Internet bilden. Die Backbones werden aus Leitungen mit sehr hoher
Seite 16
Abbildung 9 ,Das Internet [Tanenbaum1996].
Bandbreite und schnellen Routern gebildet. An die Backbones sind wiederum grere regionale
Netze angeschlossen, die lokale Netze von Universitten, Behrden, Unternehmen und Service-
Providern verbinden.
3.3.1 Internet ProtokoII (IP)
Das Internet Protololl (Internet Protocol - IP) ist der Leim, der dies alles zusammenhlt. IP stellt
die Basisdienste Ir die bermittlung von Daten in TCP/IP-Netzen bereit und ist im RFC 791
speziIiziert. HauptauIgaben des Internet Protokolls sind die Adressierung von Hosts und das
Fragmentieren von Paketen. Diese Pakete werden von IP nach bestem Bemhen (,best eIIort) von
der Quelle zum Ziel beIrdert, unabhngig davon, ob sich die Hosts im gleichen Netz beIinden oder
andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet
Protokoll enthlt keine Funktionen Ir die Ende-zu-Ende-Sicherung oder Ir die Flusskontrolle.
Die Funktionen von IP umIassen:
Die DeIinition von Datengrammen, welche die Basiseinheiten Ir die bermittlung von
Daten im Internet bilden.
DeIinition 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 Datenbertragung wird keine Ende-zu-Ende-
Verbindung der Kommunikationspartner etabliert. Ferner ist IP ein un:uverlssiges Protokoll, da es
ber keine Mechanismen zur Fehlererkennung und -behebung verIgt. Unzuverlssig bedeutet aber
keinesIalls, dass man sich auI das IP Protokoll nicht verlassen kann. Unzuverlssig bedeutet in
diesem Zusammenhang lediglich, dass 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 Palet ist ein Datenblock zusammen mit den InIormationen, die
notwendig sind, um sie dem EmpInger zuzustellen (ein Paket ist also nichts anderes als ein Paket
im herkmmliche Sinn bei der Post - das Paket enthlt die Daten, auI dem Paket ist die Adresse des
EmpIngers notiert). Das Datengramm (datagram) ist das PaketIormat, das vom Internet Protokoll
deIiniert ist. Ein IP-Datengramm besteht aus einem Header und den zu bertragenden Daten. Der
Header hat einen Iesten 20 Byte groen Teil, geIolgt von einem optionalen Teil variabler Lnge.
Der Header umIasst alle InIormationen, die notwendig sind, um das Datengramm dem EmpInger
zuzustellen. Ein Datengramm kann theoretisch maximal 64 KByte gro sein, in der Praxis liegt die
Gre ungeIhr bei 1500 Byte (das hngt mit der maximalen Rahmengre des Ethernet-Protokolls
zusammen).
Die Felder des in der Abbildung dargestellten ProtokollkopIes haben die Iolgende Bedeutung:
Version:
Das Versions-Feld enthlt die Versionsnummer des IP-Protokolls. Durch die Einbindung der
Versionsnummer besteht die Mglichkeit ber eine lngere Zeit mit verschiedenen Versionen
des IP Protokolls zu arbeiten. Einige Hosts knnen mit der alten und andere mit der neuen
Seite 17
Version arbeiten. Die derzeitige Versionsnummer ist 4, aber die Version 6 des IP Protokolls
beIindet sich bereits in der Erprobung (siehe |Hartjes1997|, |Hinden|, |HosenIeld1996|,
|Kuschke1994|, |Tanenbaum1996|, |WiN|).
Length:
Das Feld Length (Internet Header Length - IHL) enthlt die Lnge des ProtokollkopIs, da
diese nicht konstant ist. Die Lnge wird in 32-Bit-Worten angegeben. Der kleinste zulssige
Wert ist 5 - das entspricht also 20 Byte; in diesem Fall sind im Header keine Optionen gesetzt.
Die Lnge des Headers kann sich durch AnIgen von Optionen aber bis auI 60 Byte erhhen
(der Maximalwert Ir das 4-Bit-Feld ist 15).
Type oI Servive:
ber das Feld Tvpe of Service kann IP angewiesen werden Nachrichten nach bestimmten
Kriterien zu behandeln. Als Dienste sind hier verschiedene Kombinationen aus
Zuverlssigkeit und Geschwindigkeit mglich. In der Praxis wird dieses Feld aber ignoriert,
hat also den Wert 0. Das Feld selbst hat den Iolgenden AuIbau:
Precedence (Bits 0-2) gibt die Prioritt von 0 (normal) bis 7 (Steuerungspaket) an. Die drei
Flags (D,T,R) ermglichen es dem Host anzugeben, worauI er bei der Datenbertragung am
meisten Wert legt: Verzgerung (Delay - D), Durchsatz (Throughput - T), Zuverlssigkeit
(Reliability - R). Die beiden anderen Bit-Felder sind reserviert.
Total Length:
Enthlt die gesamte Paletlnge, d.h. Header und Daten. Da es sich hierbei um ein 16-Bit-Feld
handelt ist die Maximallnge eines Datengramms auI 65.535 Byte begrenzt. In der
SpeziIikation von IP (RFC 791) ist Iestgelegt, dass jeder Host in der Lage sein muss, Pakete
bis zu einer Lnge von 576 Bytes zu verarbeiten. In der Regel knnen von den Host aber
Pakete grerer Lnge verarbeitet werden.
IdentiIication:
ber das Identifilationsfeld kann der Zielhost Ieststellen, zu welchem Datengramm ein neu
angekommenes Fragment gehrt. Alle Fragmente eines Datengramms enthalten die gleiche
IdentiIikationsnummer, die vom Absender vergeben wird.
Flags:
Das Flags-Feld ist drei Bit lang. Die Flags bestehen aus zwei Bits namens DF - Dont
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, dass das Datengramm nicht Iragmentiert
werden darI. Auch dann nicht, wenn das Paket dann evtl. nicht mehr weiter transportiert
werden kann und verworIen werden muss. Alle Hosts mssen, wie schon gesagt Fragmente
bzw. Datengramme mit einer Gre von 576 Bytes oder weniger verarbeiten knnen. Mit dem
MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpakete nachIolgen. Diese Bit ist bei
Seite 18
Abbildung 10 Aufbau des Tvpe of Service Feldes.
D precedence T R
0 1 2 3 4 5 6 7
allen Fragmenten auer dem letzten gesetzt.
Fragment OIIset:
Der Fragmentabstand bezeichnet, an welcher Stelle relativ zum Beginn des gesamten
Datengramms ein Fragment gehrt. Mit HilIe dieser Angabe kann der Zielhost das
Originalpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit gro
ist, knnen maximal 8192 Fragmente pro Datengramm erstellt werden. Alle Fragmente, auer
dem letzten, mssen ein VielIaches von 8 Byte sein. Dies ist die elementare Fragmenteinheit.
Time to Live:
Das Feld Time to Live ist ein Zhler, mit dem die Lebensdauer von IP-Paketen begrenzt wird.
Im RFC 791 ist Ir dieses Feld als Einheit Sekunden speziIiziert. Zulssig ist eine maximale
Lebensdauer von 255 Sekunden (8 Bit). Der Zhler muss von jedem Netzknoten, der
durchlauIen wird um mindestens 1 verringert werden. Bei einer lngeren
Zwischenspeicherung in einem Router muss der Inhalt sogar mehrmals verringert werden.
Enthlt das Feld den Wert 0, muss das Paket verworIen werden: damit wird verhindert, dass
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) inIormiert.
Protocol:
Enthlt die Nummer des Transportprotokolls, an das das Paket weitergeleitet werden muss.
Die Numerierung von Protokollen ist im gesamten Internet einheitlich. Bisher wurden die
Protokollnummern im RFC 1700 deIiniert. Diese AuIgabe ist nun von der Internet Assigned
Numbers Authoritv (IANA) |http://www.iana.org| bernommen worden. Bei UNIX-Systemen
sind die Protokollnummern in der Datei /etc/protocols abgelegt.
Header Checksum:
Dieses Feld enthlt die PrIsumme der Felder im IP-Header. Die Nutzdaten des IP-
Datengramms werden aus EIIizienzgrnden nicht mit geprIt. Diese PrIung Iindet beim
EmpInger innerhalb des Transportprotokolls statt. Die PrIsumme muss von jedem
Netzknoten, der durchlauIen wird, neu berechnet werden, da der IP-Header durch das Feld
Time-to-Live sich bei jeder Teilstrecke verndert. Aus diesem Grund ist auch eine sehr
eIIiziente Bildung der PrIsumme wichtig. Als PrIsumme wird das 1er-Komplement der
Summe aller 16-Bit-Halbwrter der :u berprfenden Daten verwendet. Zum Zweck dieses
Algorithmus wird angenommen, dass die PrIsumme zu Beginn der Berechnung Null ist.
Source Address, Destination Address:
In diese Felder werden die 32-Bit langen Internet-Adressen eingetragen. Die Internet-
Adressen werden im Abschnitt Adressierung auI der Internet-Schicht nher betrachtet.
Options und Padding:
Das Feld Options wurde im ProtokollkopI auIgenommen, um die Mglichkeit zu bieten das
IP-Protokoll um weitere InIormationen zu ergnzen, die im ursprnglichen Design nicht
bercksichtigt wurden. Das OptionsIeld hat eine variable Lnge. Jede Option beginnt mit
einem Code von einem Byte, ber den die Option identiIiziert wird. Manchen Optionen Iolgt
ein weiteres OptionsIeld von 1 Byte und dann ein oder mehrere Datenbytes Ir die Option.
Seite 19
Das Feld Options wird ber das Padding auI ein VielIaches von 4 Byte auIgeIllt. Derzeit
sind die Iolgenden Optionen bekannt:
End oI Option List
Kennzeichnet das Ende der Optionsliste.
No Option
Kann zum AuIIllen von Bits zwischen Optionen verwendet werden.
Security
Bezeichnet, wie geheim ein Datengramm ist. In der Praxis wird diese Option jedoch Iast
immer ignoriert.
Loose Source-Routing, Strict Source-Routing
Diese Option enthlt eine Liste von Internet-Adressen, die das Datagramm durchlauIen
soll. AuI 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, dass das Paket diese Route genau einhalten muss. Desweiteren wird die
genommene Route auIgezeichnet. Die zweite Variante schreibt vor, dass die
angegebenen Router nicht umgangen werden drIen. AuI dem Weg knnen aber auch
andere Router besucht werden.
Record Route
Die Knoten, die dieses Datengramm durchluIt, werden angewiesen ihre IP-Adresse an
das OptionsIeld anzuhngen. Damit lsst sich ermitteln, welche Route ein Datengramm
genommen hat. Wie anIangs schon gesagt, ist die Gre Ir das OptionsIeld auI 40 Byte
beschrnkt. Deshalb kommt es heute auch oItmals zu Problemen mit dieser Option, da
weit mehr Router durchlauIen werden, als dies zu Beginn des ARPANET der Fall war.
Time Stamp
Diese Option ist mit der Option Record Route vergleichbar. Zustzlich zur IP-Adresse
wird bei dieser Option die Uhrzeit des DurchlauIs durch den Knoten vermerkt. Auch
diese Option dient hauptschlich zur Fehlerbehandlung, wobei zustzlich z.B.
Verzgerungen auI den Netzstrecken erIasst werden knnen.
Weitere Details zu den Optionen sind in RFC 791 zu Iinden.
3.3.2 Adressierung auf der Internet-Schicht
Zur Adressierung eines Kommunikationspartners in Form eines Applikationsprogramms mssen
beim DurchlauIen der vier TCP/IP-Schichten auch vier verschiedene Adressen angegeben werden.
1. Eine Netzwerkadresse (z.B. eine Ethernet-Adresse, MAC-Adresse)
2. Eine Internet-Adresse
3. Eine Transportprotokoll-Adresse
4. Eine Portnummer
Seite 20
Zwei dieser Adressen Iinden sich als Felder im IP-Header: die Internet-Adresse und die
Transportprotololl-Adresse.
ProtokoIInummern
IP verwendet Protolollnummern, um empIangene Daten an das richtige Transportprotokoll
weiterzuleiten. Die Protokollnummer ist ein einzelnes Byte im IP-Header. Die Protokollnummern
sind im gesamten Internet einheitlich. Protokollnummern wurden im RFC 1700 deIiniert. Diese
AuIgabe ist nun von der Internet Assigned Numbers Authoritv (IANA) |http://www.iana.org| bzw.
der Internet Corporation for Assigned Names and Numbers (ICANN) |http://www.icann.org|
bernommen worden. Die Nummern werden in einer Datenbank unter
http://www.iana.org/numbers.htm verwaltet.
AuI UNIX-Systemen sind die Protokollnummern in der Datei /etc/protocols abgelegt. Diese
Datei ist eine einIache Tabelle, die einen Protokollnamen und die damit verbundene
Protokollnummer enthlt. NachIolgend ist der Inhalt der Datei /etc/protocols einer aktuellen
LINUX-Maschine abgebildet:
heiko@phoenix:~> more /etc/protocols
#
# protocols This file describes the various protocols that are
# available from the TCP/IP subsystem. It should be
# consulted instead of using the numbers in the ARPA
# include files, or, worse, just guessing them.
#
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group multicast protocol
ggp 3 GGP # gateway-gateway protocol
tcp 6 TCP # transmission control protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
idp 22 IDP # WhatsThis?
raw 255 RAW # RAW IP interface
# End.
EmpIngt 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 (mindestens) eine 32-Bit lange IP-Adresse. Eine IP-Adresse
ist eindeutig, kein Knoten im Internet hat die gleiche IP-Adresse wie ein anderer. Knoten, die an
mehrere Netze angeschlossen sind, haben in jedem Netz eine eigene IP-Adresse. Es gilt: Jede
Schnittstelle in fedem Host und Router muss im Internet eine global eindeutige IP-Adresse haben
|KuroseRoss2002|. Die Vergabe von IP-Adressen wird zentral organisiert, um AdresskonIlikte zu
vermeiden. Diese AuIgabe wurde eine lngere Zeit vom Networl Information Center (NIC)
|http://www.internic.net| wahrgenommen und ist nun an die Internet Assigned Numbers Authoritv
(IANA) bzw. an die Internet Corporation for Assigned Names and Numbers (ICANN) bergegangen.
Seite 21
Die ICANN hat Teile des Adressraums an ihre Vertreter in den verschiedenen regionalen Gebieten -
Asia Pacific Networl Information Center (APNIC), American Registrv for Internet Numbers
(ARIN), Reseaux IP Europeens (RIPE) vergeben, die die IP-Adressen dann an Unternehmen,
Behrden und Internet Service Provider (ISP) vergeben. Die Adressen werden nicht einzeln
zugeordnet, sondern nach Netzklassen vergeben. Beantragt man IP-Adressen Ir ein Netz, so erhlt
man nicht Ir jeden Rechner eine einzelne Adresse zugeteilt, sondern einen Bereich von Adressen,
der selbst zu verwalten ist. Nur Internet Service Provider, die sehr viel Adressraum bentigen,
wenden sich noch direkt an die jeweiligen Vertreter der IANA bzw. ICANN in ihren Gebieten. Alle
anderen Unternehmen wenden sich Ir die Zuordnung von IP-Adressen bzw. Adressbereichen an
ihren ISP. Die Grundlage Ir die Vergabe von IP-Adressen bilden die Richtlinien, die in RFC 2050
(Internet Registrv IP Allocation Guidelines) Iestgehalten sind.
Wie die Abbildung ,IP-AdressIormate zeigt, sind IP-Adressen in verschiedene Klassen, mit
unterschiedlich langer Netzwerk- und Hostadresse, eingeteilt. Die Net:werladresse deIiniert das
Netzwerk, in dem sich ein Host beIindet: alle Hosts eines Netzes haben die gleiche
Netzwerkadresse. Die Hostadresse identiIiziert einen bestimmten Rechner bzw. eine Schnittstelle
innerhalb eines Netzes.
Ist ein Host an mehrere Netze angeschlossen, so hat er Ir jedes Netz eine eigene IP-Adresse. "Eine
IP-Adresse identifi:iert leinen bestimmten Computer (Host), sondern eine Verbindung :wischen
einem Computer (Host) und einem Net:. Ein Computer (Host) mit mehreren Net:anschlssen (:.B.
ein Router) muss fr feden Anschluss eine IP-Adresse :ugewiesen werden." |Comer1998|.
IP-Adressen sind 32-Bit groe Zahlen, die normalerweise nicht als Binrzahl, sondern in
Seite 22
Abbildung 11 IP-Adressformate.
0 1 1
0
1 0
1 1 1 0
network address
(8 bit)
0 8 16 24 31
host address (24 bit)
network address (16 bit) host address (16 bit)
network address (24 bit) host address
(8 bit)
host group (multicast)
Class A
Class B
Class C
Class D
1 1 1 1
reserved for future use
Class E
Abbildung 12 IP-Adressen bestehen aus einer Net:werladresse und einer Hostadresse.
Netzwerkadresse 192.168.100
Hostadresse 10 Hostadresse 20
IP-Adresse
192.168.100.10
IP-Adresse
192.168.100.20
gepunkteter Dezimalnotation geschrieben werden. In diesem Format wird die 32-Bit groe Zahl in 4
Byte-Blcke auIgeteilt, die mit Punkten voneinander getrennt sind. Die Adresse
01111111 11111111 11111111 11111111 wird so als 127.255.255.255 geschrieben. Die niedrigste
IP-Adresse ist 0.0.0.0., die hchste 255.255.255.255.
Wie zuvor gesagt, sind IP-Adressen in Klassen unterteilt. Der Wert des ersten Bytes gibt die
Adressklasse an:
Adressklasse Erstes Byte Bytes fr die
Netzadresse
Bytes fr die
Hostadresse
Adressformat* Anzahl Hosts
Klasse A 1-126 1 3 N.H.H.H 2
24
(~16 Mio.)
Klasse B 128-191 2 2 N.N.H.H. 2
16
(~64.000)
Klasse C 192-223 3 1 N.N.N.H 254
Klasse D 224-239 Multicast-Adressen
Klasse E 240-254 Experimentelle Adressen bzw. Ir zuknItige Nutzung reserviert
*
N steht Ir einen Teil der Netzadresse, H Ir einen Teil der Hostadresse.
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 identiIizieren einen Host im Netz. Es gibt
demzuIolge also 126 Klasse A Netze, die bis zu 16 Millionen Host in einem Netz.
Klasse B:
Ein Wert von 128 bis 191 Ir das erste Byte (das erste Bit ist gleich 1, Bit 2 gleich 0)
identiIiziert eine Klasse B Adresse. Die ersten beiden Bytes identiIizieren das Netzwerk, die
letzen beiden Bytes einen Host. Das ergibt 16.382 Klasse B Netze mit bis zu 64.000 Hosts in
einem Netz.
Klasse C:
Seite 23
Abbildung 13 Jedes Net:werl hat eine verschiedene Net:werladresse und feder Host im
Net:werl hat eine andere Hostadresse.
IP-Adresse
129.72.100.11
Netzwerk 1
(129.72.100.0)
Router
IP-Adresse
129.72.100.12
IP-Adresse
129.72.100.13
IP-Adresse
165.80.20.31
IP-Adresse
165.80.20.32
IP-Adresse
165.80.20.33
IP-Adresse
165.80.20.1
IP-Adresse
129.72.100.1
Netzwerk 2
(165.80.20.0)
Klasse C Netze werden ber Werte von 192 bis 223 Ir das erste Byte (die ersten beiden Bits
sind gleich 1, Bit 3 gleich 0) identiIiziert. Es gibt 2 Millionen Klasse C Netze, d.h. die ersten
drei Bytes werden Ir die Netzwerkadresse verwendet. Ein Klasse C Netz kann bis zu 254
Host beinhalten.
Klasse D:
Klasse D Adressen, so genannte 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 erIolgt, wie bei
IP blich, nach bestem Bemhen, d.h. ohne Garantie, dass die Daten auch tatschlich alle
Mitglieder einer Gruppe erreichen.
Fr das Multicasting wird ein spezielles Protokoll namens Internet Group Management
Protocol (IGMP) verwendet. IGMP entspricht grob ICMP, mit dem Unterschied, dass es nur
zwei Arten von Paketen kennt: AnIragen und Antworten. AnIragen werden dazu verwendet,
zu ermitteln welche Hosts Mitglieder einer Gruppe sind. Antworten inIormieren darber, zu
welchen Gruppen ein Host gehrt. Jedes IGMP-Paket hat ein Iestes Format und wird zur
bertragung in IP-Pakete eingekapselt.
Version
In RFC1112 ist die aktuelle Version 1 des IGMP Protokolls speziIiziert. Version 0, die
in RFC998 beschrieben wird, ist obsolet.
Type
Wie zuvor gesagt, kennt IGMP zwei Nachrichtentypen: AnIragen und Antorten:
1 Host Membership Query (AnIrage)
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 AnIrage zur Gruppenzugehrigkeit wird das GruppenadressenIeld mit Nullen
geIllt. Ein Host, der eine AnIrage erhlt, ignoriert dieses Feld. Bei einer IGMP-
Seite 24
Abbildung 14 Der IGMP-Header.
Version Unused Type Checksum
Group Address
1 4 8 12 16 20 24 28 32
Bits
Antwort enthlt das GruppenadressenIeld die Adresse der Gruppe, zu der der sendende
Host gehrt.
Eine genaue Beschreibung des Internet Group Management Protocol ist in RFC1112 zu Iinden
(RFC1054 und RFC 998 beschreiben ltere Versionen von IGMP).
Der weitere Bereich der IP-Adressen von 240 bis 254 im ersten Byte ist Ir zuknItige Nutzungen
reserviert. In der Literatur wird dieser Bereich oIt auch als Klasse E bezeichnet (vgl. |Comer1998|).
Im Internet mssen die Adressen eindeutig sein. Aus diesem Grund werden die IP-Adressen, wie
bereits gesagt, von einer zentralen Organisation vergeben bzw. deren Vergabe koordiniert. Dabei ist
sichergestellt, dass die Adressen eindeutig und auch im Internet sichtbar sind.
Private IP-Adressen
Dies ist aber nicht immer notwendig. Netze, die keinen Kontakt zum globalen Internet haben
(,geschlossene Netzwerke), bentigen keine Adresse, die auch im Internet sichtbar ist. Es ist auch
nicht notwendig, dass sichergestellt ist, das diese Adressen in keinem anderen, privaten Netz
eingesetzt werden. Aus diesem Grund wurden Adressbereiche Iestgelegt, die nur Ir private Net:e
bestimmt sind. Diese Bereiche sind in RFC 1918 (Address Allocation for Private Internets)
Iestgelegt (RFC 1597, auI das sich oIt auch neuere Literatur bezieht, ist durch RFC 1918 ersetzt).
IP-Nummern aus dem privaten Adressenbereich drIen im globalen Internet nicht weitergeleitet
werden. Dadurch ist es mglich, diese Adressen in beliebig vielen, nicht-IIentlichen Netzen,
einzusetzen.
Die Iolgenden Adressbereiche sind Ir die Nutzung in privaten Netzen reserviert (nach RFC 1918):
Klasse A: 10.0.0.0
Fr ein privates Klasse A-Netz ist der Adressbereich von 10.0.0.0 bis 10.255.255.254
reserviert.
Klasse B: 172.16.0.0 bis 172.31.0.0
Fr 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.0
256 Klasse C-Netzte stehen zur privaten Nutzung zur VerIgung. 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 Adressbereich Ir sein eigenes privates Netz auswhlen. Die
Zuteilung dieser Adressen bedarI nicht die Koordination mit der IANA bzw. ICANN oder einer
anderen Organisation, die Ir die Zuordnung von IP-Adressen verantwortlich ist.
SpezieIIe IP-Adressen
Neben den IP-Adressen aus dem privaten Adressbereich gibt es weitere IP-Adressen, die eine
bestimmte Bedeutung haben.
Adressen mit der Netznummer 0 beziehen sich auI das aktuelle Netz. Mit einer solchen Adresse
Seite 25
knnen sich Hosts auI ihr eigenes Netz beziehen, ohne die Netzadresse zu kennen (allerdings muss
bekannt sein, um welche Netzklasse es sich handelt, damit die passende Anzahl Null-Bytes gesetzt
wird). Insbesondere hat die Adresse 0.0.0.0, bei der alle Bits 0 sind, die Bedeutung ,Dieser Host
(,This Host).
Der Wert 127 im ersten Byte steht Ir das Loopbacl Device eines Hosts. Pakete, die an eine Adresse
der Form 127.x.y.z gesendet werden, werden nicht auI einer Leitung bzw. Schnittstelle ausgegeben,
sondern lokal verarbeitet. Dieses Merkmal wird huIig zur Fehlerbehandlung benutzt. In der
Literatur wird huIig die Adresse 127.0.0.1 als Adresse Ir das Loopback-Device angegeben, es gilt
aber, das alle Adressen der Form 127.x.y.z das Loopback-Device adressieren sollten.
Neben einigen Netzadressen sind auch bestimmte Hostadressen Ir spezielle Zwecke reserviert. Bei
allen Netzwerkklassen sind die Werte 0 und 255 bei den Hostadressen reserviert.
Eine IP-Adresse, bei der alle Hostbits auI Null gesetzt sind, identiIiziert das Netz selbst. Die
Adresse 80.0.0.0 bezieht sich so z.B. auI das Klasse-A-Netz 80, die Adresse 128.66.0.0 bezieht sich
auI 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. Die Adresse, bei
der alle Bits gesetzt sind (255.255.255.255) wird als eingeschrnlte Broadcast-Adresse (loakler
Broadcast) bezeichnet, die nur im lokalen Netz verarbeitet und nicht ber Router weitergeleitet
wird.
Subnetting (TeiInetzwerke)
Mit der ursprnglichen Einteilung von IP-Adressen in Adressklassen wurde beabsichtigt, durch den
Netzwerkteil ein physikalisches Netzwerk eindeutig zu erkennen und die Weiterleitung von Paketen
zu diesem Netz zu vereinIachen. Dieser Ansatz birgt aber einen groen Nachteil in sich: der
verIgbare Adressraum ist verschwenderisch und ungnstig auIgeteilt. Bei der Vergabe einer
Netzwerkadresse pro physikalischen Netz wird der IP-Adressraum viel schneller als notwendig
auIgebraucht. Das Problem liegt im wesentlichen darin, dass sich die Adresse eines Klasse A, B
oder C Netzes auI ein physikalisches Netz bezieht und nicht auI eine Gruppe von LANs.
Als Beispiel, um dieses Problem zu verdeutlichen, stelle man sich ein groes Unternehmen oder
eine Universitt vor, die ihre internen Netze an das Internet anschlieen mchte. Ungeachtet der
Gre bzw. der Anzahl der vorhandenen Hosts, msste das Unternehmen Ir jedes Netzwerk
mindestens eine Netzwerkadresse der Klasse C nutzen. Besteht eines der Netze z.B. nur aus 10
Knoten wrden dabei 244 Adressen (256-2-10 244) vergeudet. Schlimmer noch, Ir ein Netz mit
mehr als 255 Hosts wrde eine Klasse-B-Adresse bentigt; sind an dieses Netzt z.B. nur 300 Hosts
angeschlossen wrden ber 16.000 Adressen verschwendet.
Um den theoretisch vorhandenen IP-Adressraum auIzubrauchen, mssten ber 4 Milliarden Hosts
an das Internet angeschlossen werden (verIgbarer IP-Adressraum ~ 2
32
), um aber z.B. den
Adressraum, der Ir Klasse-B-Netze reserviert ist, auIzubrauchen, gengen 16.000 physikalische
Netze (2
14
verIgbarer Adressraum Ir die Netzwerkadresse), die eine Klasse-B-Netzadresse
verwenden.
Als Lsung des Problems kann man ein Netz Ir die interne Verwendung in mehrere Teilnetze
auIteilen, wobei das Netz nach auen weiterhin als ein einzelnes Netz erscheint. Der Mechanismus,
der diese VerIeinerung in so genannte Teilnetze oder Subnetze (subnets, subnetworks) ermglicht,
Seite 26
wird als subnetting bezeichnet. Subnetze sind in RFC 950 (Internet Standard Subnetting
Procedure) deIiniert. Beim Subnetting wird ein Teil der Hostadresse dazu genutzt, um den
Netzwerkteil zu erweitern.
Anstatt beispielsweise eine einzelne Adresse der Klasse B mit 14 Bit (bzw. 16 Bit) Ir die
Netzwerknummer und 16 Bit Ir die Hostnummer zu haben, werden aus der Hostnummer Bits
entnommen, um damit eine Teilnet:-ID zu erstellen. Ein Unternehmen knnte so z.B. eine Klasse-
B-Adresse beantragen und diese Adresse weiter unterteilen. Von den Hostbits knnten 6 Bit genutzt
werden, um Teilnetze zu identiIizieren, zur Adressierung der Hosts blieben dann 10 Bit. Damit ist
es dem Unternehmen mglich, 64 Subnetzwerke mit bis zu 1.022 Host ber eine Klasse-B-Adresse
zu betreiben.
Um den Mechanismus Ir Subnetzwerke zu implementieren, mssen Hosts und Router um eine
Teilnet:masle (Subnet Masl), die die Grenze zwischen der Netwerk-ID, der Teilnetz-ID und der
Host-ID angibt, erweitert werden. Wie viele Bit Ir die Teilnetz-ID genutzt werden, bleibt dem
Administrator berlassen. Die Teilnetzmaske ist eine 32 Bit groe ,Adresse, die dazu benutzt
wird, die Netzwerk-ID von der Host-ID in einer bestimmten IP-Adresse zu unterscheiden. Alle Bits
der IP-Adresse, die zur Netzwerk-ID gehren, haben in der Teilnetzmaske den Wert 1; alle Bits, die
zur Host-ID gehren, haben den Wert 0. Teilnetzmasken werden, ebenso wie IP-Adressen,
blicherweise in der Punktdezimalnotation geschrieben. Fr die oben genannte AuIteilung wrde
die Subnetzmaske 255.255.252.0 (binr 11111111.11111111.11111100.00000000) lauten.
Alternativ werden Subnetzmasken auch oIt in der Form /xx angegeben, wobei xx die Anzahl der
Bits Ir den Netzwerkteil der Adresse angibt. Fr obiges Beispiel wrde die Notation also /22 lauten
(22 Bit werden Ir den Netzwerkteil der Adresse genutzt, die Teilnetzmaske ist 22 Bit lang).
Auerhalb des so auIgeteilten Netzes sind die Teilnetze nicht erkennbar, die AuIteilung in Subnetze
ist Ir den Rest des Internets transparent, die innere Strukturierung bleibt verborgen. Deshalb ist es
auch nicht notwenig, dass die AuIteilung eines Netzes in Subnetze mit der ICANN koordiniert wird
oder andere Router im Internet rekonIiguriert werden mssen.
Als Beispiel sei angenommen, dass das Klasse-C-Netzwerk 192.96.34.0 in zwei Subnetzwerke
auIgeteilt werden soll. Alles was daIr getan werden muss ist, statt der Standard-Subnetzmaske /24
(255.255.255.0) Ir ein Klasse-C-Netzwerk die Subnetzmaske /25 (255.255.255.128) zu whlen.
Diese Subnetzmaske teilt das Klasse-C-Netz in zwei Teilnetze mit jeweils 128 mglichen Host-
Adressen (tatschlich sind es auIgrund der speziellen IP-Adressen jeweils 126 Hostadressen). Das
erste Netz hat einen Adressraum von 192.96.34.0 bis 192.96.34.127, das zweite Netz einen
Adressraum von 192.96.34.128 bis 192.96.34.255.
Seite 27
Abbildung 15 Klasse-B-Net:, das ber eine Subnet:masle in 64 Teilnet:e unterteilt ist.
1 0
1 0
0 8 16 24 31
Netzwerkadresse Hostadresse
Hostadresse Netzwerkadresse Teilnetz-ID
Klasse-B-Adresse, die ber eine Teilnetz-ID strukturiert ist.
Klasse-B-Adresse
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0 0
Die nachIolgende Tabelle zeigt die gebruchlichsten Netzmasken Ir Klasse-B- und Klasse-C-Netze
mit ihrer Anzahl Teilnetze und der Anzahl Hosts in einem Teilnetz:
Subnetzmaske Netzwerk
Bits
Netze per
Subnetzmask
e
Host Bits Hosts per
Subnetz
Netzwerkklasse
255.255.0.0 /16 16 1 16 65.534 Klasse B Maske
(Standard)
255.255.128.0 /17 17 2 15 32.766 Klasse B Maske
255.255.192.0 /18 18 4 14 16.382 Klasse B Maske
255.255.224.0 /19 19 8 13 8.190 Klasse B Maske
255.255.240.0 /20 20 16 12 4.094 Klasse B Maske
255.255.248 /21 21 32 11 2.046 Klasse B Maske
255.255.252.0 /22 22 64 10 1.022 Klasse B Maske
255.255.254 /23 23 128 9 510 Klasse B Maske
255.255.255.0 /24 24 1 8 254 Klasse C Maske
(Standard)
255.255.255.128 /25 25 2 7 126 Klasse C Maske
255.255.255.192 /26 26 4 6 62 Klasse C Maske
255.255.255.224 /27 27 8 5 30 Klasse C Maske
255.255.255.240 /28 28 16 4 14 Klasse C Maske
255.255.255.248 /29 29 32 3 6 Klasse C Maske
255.255.255.252 /30 30 64 2 2 Klasse C Maske
Mit RFC 950 ist Iestgelegt, dass jeder Host in einem IP-Netzwerk eine Subnetzmaske haben muss,
entweder eine Standard-Subnet:masle (default-Subnet:masle) oder eine angepasste Subnet:masle
(custom-Subnet:masle). Wird ein Netz in mehrere Teilnetze auIgeteilt, muss jeder Host innerhalb
eines Netzes die gleiche Subnetzmaske haben, damit er mit den anderen Hosts im Netz
kommunizieren kann. Haben die Hosts unterschiedliche Subnetzmasken, ,denken sie, sie wren in
unterschiedlichen Netzen und mssen erst einen Router kontaktieren, um miteinander zu
kommunizieren.
Seite 28
Abbildung 16 Aufteilung eines Net:es in Subnet:e.
Router
Rest des
Internets
192.96.34.0
Pakete fr das Netz
192.96.34.0
Router
Rest des
Internets
192.96.34.0
Pakete fr das Netz
192.96.34.0
192.96.34.128
Teilnetz 1
Teilnetz 2
Alle Gerte in einem (IP-)Netzwerk mssen Routing-Entscheidungen (wie werden die Pakete
weitergeleitet) treIIen. Die Routing-Entscheidungen sind in den meisten Fllen sehr einIach:
Liegt der Zielhost im lokalen Netz, werden die Daten direkt an den Zielhost gelieIert.
Liegt der Zielhost in einem entIernten Netzwerk, werden die Daten an einen lokalen Router
weitergeleitet (oIt auch Gateway genannt), der ausIhrlichere Routing-Tabellen hat.
Jeder Router Ihrt intern eine Tabelle, aus der hervorgeht, wie IP-Pakete zu Hosts weitergeleitet
werden mssen. Kommt ein IP-Paket bei einem Router an, wird seine Zieladresse in der Routing-
Tabelle (Weiterleitungstabelle) nachgeschlagen. Die Routing-Tabelle setzt sich aus Eintrgen im
Format Netzwerk-ID, NchsterHop> zusammen. Ist das Paket an einen Host adressiert, der im
selben lokalen Netz liegt, wird das Paket direkt an das Ziel bertragen. Ist das Paket Ir einen Host
in einem entIernten Netz bestimmt und dieses entIernte Netz in der Tabelle bekannt ist, wird es an
den nchsten Router, der zu diesem Netz Ihrt, an der in der Tabelle auIgeIhrten Schnittstelle
weitergegeben. Ist das Netz an das das Paket adressiert ist nicht bekannt, wird das Paket an einen
Standard-Router (Standard-Gatewav) weitergeleitet, der ausIhrlichere Tabellen hat. Dieser
Algorithmus bedeutet, dass jeder Router nur andere entIernte Netzwerke und lokale Hosts kennen
muss, nicht aber Netzwerk/Host-Paare. Dadurch wird der UmIang der Routing-Tabellen stark
reduziert.
Fr die Untersttzung von Subnetting haben die Eintrge in den Routing-Tabellen das Format
Subnetz-ID, Subnetzmaske, NchsterHop>. Um den richtigen Eintrag in der Tabelle zu Iinden,
Ihrt der Router ein boolsches UND zwischen der Zieladresse des Pakets und der Subnetzmaske
jeden Eintrags in der Routing-Tabelle nacheinander durch. Stimmt das Ergebnis mit der Subnetz-ID
eines Eintrags berein, ist dies der zu verwendende Eintrag und das Paket wird an den dadruch
bezeichneten Router weitergeleitet.
Hinweis: Der Inhalt der Routing-Tabelle kann mit den BeIehlen netstat -nr oder
route print auI den meisten UNIX und Windows-Systemen angezeigt werden.
Um dies zu verdeutlichen, sei das oben genannte Beispiel des Klasse-C-Netzes auIgegriIIen. Ein
entIernter Host adressiert ein IP-Paket an die IP-Adresse 192.96.34.160. Der Zielhost liegt also in
dem Klasse-C-Netzwerk 192.96.34.0. Bei Erreichen des Routers, der die Pakete an Hosts im Netz
192.96.34.0 weiterleitet, das intern ber die Subnetzmaske 255.255.255.128 in zwei Teilnetze
auIgeteilt ist, Ihrt nun der Router ein boolsches UND der Zieladresse mit der Subnetzwerkmaske
des Netzwerkes durch.
11000000.01100000.00100010.10100000 192.96.34.160 Klasse-C-Adresse
11111111.11111111.11111111.10000000 255.255.255.128 Subnetzmaske Ir das
Teilnetz 192.96.34.0
11000000.01100000.00100010.10000000 192.96.34.128 Netzwerkadresse des
Teilnetzes
Die Berechnung ergibt, dass das Paket an den Host 192.96.34.160 in Teilnetz 2 (192.96.34.128)
weitergeleitet werden muss.
Der Mechanismus des Subnetting hilIt, die Zuweisung von IP-Adressen eIIizienter durchzuIhren.
Es muss nicht jedes mal eine ganze Adresse der Klasse B oder C auIgebraucht werden, wenn es
neues physikalisches Netzwerk an das Internet angeschlossen wird. Stattdessen, kann ein
bestehendes Netz strukturiert und besser ausgenutzt werden. Zustzlich ist Subnetting bei der
Seite 29
Aggregation von InIormationen ntzlich. Eine komplexe Sammlung physikalischer Netze kann nach
auen wie ein einzelnes Netzwerk dargestellt werden. Damit lsst sich der UmIang der
InIormationen, die in den Routern gespeichert werden mssen, um einen Host in einem dieser Netze
Pakete zu bermitteln, erheblich reduzieren.
3.3.3 Fragmentierung
Damit Datengramme ber jede Art von Netzwerk verschickt werden knnen, muss das Internet
Protokoll dazu in der Lage sein, die Gre der Datengramme dem jeweiligen Netz anzupassen.
Jedes Netzwerk besitzt eine so genannte maximale Paletgre (Maximum Transfer Unit - MTU),
die bezeichnet, dass nur Pakete bis zu dieser Gre ber das Netz verschickt werden knnen. So
drIen z.B. Pakete, die ber ein X.25-Netz verschickt werden sollen nicht grer als 128 Byte sein.
Ein Ethernet-Paket darI die Gre von 1500 Byte nicht berschreiten. Falls die MTU eines
bertragungsmediums kleiner ist als die Gre eines versendeten Pakets, so muss dieses Paket in
kleinere Pakete auIgeteilt werden.
Es gengt allerdings nicht, dass die Protokolle der Transportschicht nun von sich aus einIach
kleinere Pakete versenden. Ein Paket kann auI dem Weg vom Quell- zum Zielhost mehrere
unterschiedliche Netzwerke mit unterschiedlichen MTUs durchlauIen. Aus diesem Grund muss ein
Ilexibleres VerIahren angewendet werden, dass bereits auI der Internet-Schicht kleiner Pakete
erzeugen kann. Dieses VerIahren wird Fragmentierung genannt.
Unter Fragmentierung wird verstanden, dass das IP-Protokoll eines jeden Netzwerkknotens (sei es
ein Router, ein Host o..) in der Lage ist (sein sollte), empIangene Pakete gegebenenIalls zu
zerteilen, um sie weiter ber ein Teilnetz bis zum Zielhost zu bertragen. Jedes empIangende IP
muss dazu in der Lage sein, diese Fragmente wieder zum ursprnglichen Paket zusammenzusetzen.
Jedes Fragment eines zerteilten Pakets erhlt einen eigenen, vollstndigen IP-Header. ber das
IdentiIikationsIeld im Header knnen alle Fragmente eines Pakets wiedererkannt werden. Die
einzelnen Fragmente eines Pakets knnen durchaus unterschiedliche Wege auI dem Weg zum
Zielhost nehmen. Die Lage der Daten eines Fragments innerhalb der Gesamtnachricht wird mit
HilIe des Fragment OIIset-Feldes ermittelt.
3.3.4 Internet ControI Message ProtocoI (ICMP)
Das Internet Control Message Protocol (ICMP) ist Bestandteil jeder IP-Implementierung und hat
die AuIgabe Fehler- und DiagnoseinIormationen Ir IP zu transportieren. ICMP ist im RFC 792
speziIiziert. OIt wird ICMP auch Ir Testzwecke verwendet, etwa um zu ermitteln, ob ein Host
derzeit empIangsbereit ist.
Durch seine Vielseitigkeit bietet ICMP aber auch leider die Mglichkeit versteckte Nachrichten zu
bermitteln. Ein Stichwort ist hier das so genannte ,ICMP-Tunneling. Beim ICMP-Tunneling wird
das DatenIeld eines ICMP-Paketes genutzt, um InIormationen zwischen Rechnern auszutauschen.
Seite 30
Abbildung 17 Fragementierung eines IP-Palets.
IP Header
Fragment
Data
IP Header Fragment IP Header Fragment IP Header
ICMP-Tunneling ist aber keine Technik, die es eventuellen Datenspionen ermglicht, in einen
Rechner oder ein Netz einzubrechen. Dennoch stellt das Tunneling eine Bedrohung Ir das
Sicherheitskonzept eines Netzes dar. In |Schmidt1997a| ist ein ausIhrlicher Bericht ber das
ICMP-Tunneling zu Iinden.
ICMP hat sehr unterschiedliche InIormationen zu transportieren. Deshalb ist nur der GrundauIbau
des ICMP-Headers immer gleich, die Bedeutung der einzelnen Felder im ProtokollkopI wechselt
jedoch. Jeder ICMP-Nachrichtentyp wird in einem IP-Datengramm eingekapselt.
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 Iragmentiert werden kann, weil das DF-Bit gesetz ist,
die Source Route Option nicht erIolgreich ist.
Source Quench (Quelle lschen):
Wird ausgesendet, wenn ein Host zu viele Pakete verschickt, die aus Kapazittsmangel nicht
mehr verarbeitet werden knnen. Der sendende Host muss dann die Rate zum Aussenden von
Nachrichten verringern.
Parameter Problem:
Verstndigt den Absender eines Datengramms darber, dass das Paket auIgrund einer
IehlerhaIten Angabe im IP-Header verworIen werden musste.
Redirect:
Wird ausgesendet, wenn ein Router Ieststellt, dass ein Paket Ialsch weitergeleitet wurde. Der
sendende Host wird damit auIgeIordert, 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 daIr, dass Pakete in einem Zyklus
wandern, dass Netz berlastet ist oder die Lebensdauer Ir das Paket zu gering eingestellt
wurde.
Echo Reply, Echo Request:
Seite 31
Abbildung 18 Der ICMP-Header (allgemeiner Aufbau).
(content depends on type and code)
Type Code Checksum
1 4 8 12 16 20 24 28 32
Bits
Mit diesen Nachrichten kann Iestgestellt werden, ob ein bestimmtes Ziel erreichbar ist. Ein
Echo Request wird an einen Host gesendet und hat einen Echo Reply zur Folge (Ialls der Host
erreicht wird).
Timestamp Request, Timestamp Reply:
Diese beiden Nachrichten sind hnlich den zuvor beschriebenen Nachrichten, auer das die
AnkunItszeit der Nachricht und die Sendezeit der Antwort mit erIasst werden. Mit diesen
Nachrichtentypen kann die Netzleistung gemessen werden.
IP verwendet ICMP zum versenden von Fehler- und Diagnosemeldungen, whrend ICMP zur
bertragung seiner Nachrichten IP benutzt. Das bedeutet, wenn eine ICMP-Nachricht verschickt
werden muss, wird ein IP-Datengramm erzeugt und die ICMP-Meldung in den Datenbereich des IP-
Datengramms eingekapselt.
Das Datengramm wird dann wie blich versendet. Eine ICMP-Nachricht wird immer als Antwort
auI ein Datengramm verschickt. Entweder ist ein Datengramm auI ein Problem gestoen, oder das
Datengramm enthlt eine ICMP-AnIrage, auI die eine Antwort versendet versendet werden muss. In
beiden Fllen sendet ein Host oder Router eine ICMP-Nachricht an die Quelle des Datengramms
zurck.
3.4 Transportschicht
ber der Internet-Schicht beIindet sich die Transportschicht (Host-to-Host-Transport Laver). Die
beiden wichtigsten Protokolle der Transportschicht sind das Transmission Control Protocol (TCP)
und das User Datagram Protocol (UDP). Die AuIgabe von TCP besteht in der Bereitstellung eines
sicheren und zuverlssigen Ende-zu-Ende-Transports von Daten durch ein Netzwerk. UDP ist im
Gegensatz dazu ein verbindungsloses Transportprotokoll, das Anwendungen die Mglichkeit bietet,
eingekapselte rohe IP-Pakete zu bertragen.
3.4.1 Transmission ControI ProtocoI (TCP)
Das Transmission Control Protocol (TCP) ist ein :uverlssiges, verbindungsorientiertes, Bvtestrom
Protokoll. Die HauptauIgabe von TCP besteht in der Bereitstellung eines sicheren Transports von
Daten durch das Netzwerk. TCP ist im RFC 793 deIiniert. Diese DeIinitionen wurden im LauIe der
Zeit von Fehlern und Inkonsistenzen beIreit (RFC 1122) und um einige AnIorderungen ergnzt
(RFC 1323).
Im weiteren sollen nun die oben genannten EigenschaIten des Transmission Control Protocol -
zuverlssig (reliable), verbindungsorientiert (connection-oriented), Bytestrom (byte-stream) - nher
betrachtet werden.
Seite 32
Abbildung 19 ICMP-Nachrichten-Einlapselung.
ICMP Header
IP Header
Frame Header
ICMP Data
Datagram Data
Frame Data
Das Transmission Control Protocol stellt die Zuverlssigleit der Datenbertragung mit einem
Mechanismus, der als Positive Aclnowledgement with Re-Transmission (PAR) bezeichnet wird,
bereit. Dies bedeutet nichts anderes als das, dass das System, welches Daten sendet, die
bertragung der Daten solange wiederholt, bis vom EmpInger der Erhalt der Daten quittiert bzw.
positiv besttigt wird. Die Dateneinheiten, die zwischen den sendenden und empIangenden TCP-
Einheiten ausgetauscht werden, heien Segmente. Ein TCP-Segment besteht aus einem mindestens
20 Byte groen ProtokollkopI (siehe den Abschnitt Der TCP-Header) und den zu bertragenden
Daten. In jedem dieser Segmente ist eine PrIsumme enthalten, anhand derer der EmpInger prIen
kann, ob die Daten IehlerIrei sind. Im Falle einer IehlerIreien bertragung sendet der EmpInger
eine EmpIangsbesttigung an den Sender. AndernIalls wird das Datengramm verworIen und keine
EmpIangsbesttigung verschickt. Ist nach einer bestimmten Zeitperiode (timeout-period) beim
Sender keine EmpIangsbesttigung eingetroIIen, verschickt der Sender das betreIIende Segment
erneut. Nheres zur Zeitberwachung siehe |SantiIaller1998|.
TCP ist ein verbindungsorientiertes Protokoll. Verbindungen werden ber ein Dreiwege-Handshale
(three-wav handshale) auIgebaut. ber das Dreiwege-Handshake werden SteuerinIormationen
ausgetauscht, die die logische Ende-:u-Ende-Verbindung etablieren. Zum AuIbau einer Verbindung
sendet ein Host (Host 1) einem anderen Host (Host 2), mit dem er eine Verbindung auIbauen will,
ein Segment, in dem das SYN-Flag (siehe Der TCP-Header, Flags) gesetzt ist. Mit diesem Segment
teilt Host 1 Host 2 mit, das der AuIbau einer Verbindung gewnscht wird. Die Sequenznummer des
von Host 1 gesendeten Segments gibt Host 2 auerdem an, welche Sequenznummer Host 1 zur
Datenbertragung verwendet. Sequenznummern sind notwendig, um sicherzustellen, dass die Daten
vom Sender in der richtigen ReihenIolge beim EmpInger ankommen. Der empIangende Host 2
kann die Verbindung nun annehmen oder ablehnen. Nimmt er die Verbindung an, wird ein
Besttigungssegment gesendet. In diesem Segment sind das SYN-Bit und das ACK-Bit (siehe Der
TCP-Header, Flags) gesetzt. Im Feld Ir die Quittungsnummer besttigt Host 2 die Sequenznummer
von Host 1, dadurch, dass die um Eins erhhte Sequenznummer von Host 1 gesendet wird. Die
Sequenznummer des Besttigungssegments von Host 2 an Host 1 inIormiert Host 1 darber, mit
welcher Sequenznummer beginnend Host 2 die Daten empIngt. Schluendlich besttigt Host 1 den
EmpIang des Besttigungssegments von Host 2 mit einem Segment, in dem das ACK-Flag gesetzt
ist und die um Eins erhhte Sequenznummer von Host 2 im QuittungsnummernIeld eingetragen ist.
Mit diesem Segment knnen auch gleichzeitig die ersten Daten an Host 2 bertragen werden. Nach
dem Austausch dieser InIormationen hat Host 1 die Besttigung, dass Host 2 bereit ist Daten zu
empIangen. Die Datenbertragung kann nun stattIinden. Eine TCP-Verbindung besteht immer aus
genau zwei Endpunkten (Punkt-zu-Punkt-Verbindung).
Zum Beenden der Verbindung tauschen die beiden Host wiederum einen Dreiwege-Handshake aus,
bei dem das FIN-Bit (siehe Der TCP-Header, Flags) zum Beenden der Verbindung gesetzt ist.
Natrlich verluIt der VerbindungsauIbau nicht immer ohne Probleme. Eine Reihe interessanter
Betrachtungen ist zu Iinden in |Tanenbaum1996|.
Seite 33
TCP nimmt Datenstrme von Applikationen an und teilt diese in hchsten 64 KByte groe
Segmente auI (blich sind ungeIhr 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 ursprnglichen Bytestrmen zusammengesetzt. Die IP-Schicht gibt
allerdings keine Gewhr daIr, dass die Datengramme richtig zugestellt werden. Es ist deshalb, wie
oben bereits gesagt, die AuIgabe von TCP Ir eine erneute bertragung der Daten zu sorgen. Es ist
aber auch mglich, dass die IP-Datengramme zwar korrekt ankommen, aber in der Ialschen
ReihenIolge sind. In diesem Fall muss TCP daIr sorgen, dass die Daten wieder in die richtige
ReihenIolge gebracht werden. HierIr verwendet TCP eine Sequen:nummer und eine
Besttigungsnummer (siehe: TCP Sequence Number, Acknowledgement Number).
Portnummern
TCP ist auerdem daIr verantwortlich, die empIangenen Daten an die korrekte Applikation
weiterzuleiten. Zur Adressierung der Anwendungen werden auI der Transportebene deshalb
sogenannte Portnummern (Kanalnummern) verwendet. Portnummern sind 16 Bit gro; theoretisch
kann ein Host somit bis zu 65.535 verschiedene TCP-Verbindungen auIbauen. Auch UDP
verwendet Portnummern zur Adressierung. Portnummern sind nicht einzigartig zwischen den
Transportprotokollen - die Transportprotokolle haben jeweils eigene Adressrume. Das bedeutet
TCP und UDP knnen die gleichen Portnummern belegen. Das heit, dass die Portnummer 53 in
TCP nicht identisch mit der Portnummer 53 in UDP ist. Der Gltigkeitsbereich einer Portnummer
ist auI einen Host beschrnkt.
Eine IP-Adresse zusammen mit der Portnummer speziIiziert einen Kommunikationsendpunkt, einen
so genannten Soclet (ein Socket kann als 48-Bit Endpunkt betrachtet werden). Die Socketnummern
von Quelle und Ziel identiIizieren die Verbindung (socket1, socket2). Eine Verbindung ist durch die
Angabe dieses Paares eindeutig identiIiziert.
Mchte z.B. ein Host A (129.75.123.140) eine Verbindung zu einem entIernten Host B
(149.22.99.101) auInehmen, z.B. um den Inhalt einer Webseite anzuzeigen, so wird auI der TCP-
Schicht als Zielport die Portnummer 80 Ir das Hypertext TransIer Protocol (http) angegeben. Host
A, der den Dienst auI Port 80 von Host B in Anspruch nehmen mchte gibt als Quellport eine
dynamische Portnummer (s.u.) aus dem Bereich 49.152 - 65.535 an, damit die von ihm
gewnschten Daten von Host B an ihn zurckgelieIert werden knnen, z.B. 49.177. Damit ist die
Seite 34
Abbildung 20 Dreiwege-Handshale (am Beispiel Verbindungsaufbau).
Host A Host B
(FLAGS=SYN), (SEQ=x)
(FLAGS=SYN,ACK), (SEQ=y), (ACK=x+1)
(FLAGS=ACK), (SEQ=x+1), (ACK=y+1)
Verbindung auI der TCP-Schicht ber die Angabe von
Quell- und Zielport eindeutig identiIiziert. 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 Ir gut
belannte Ports (well-lnown ports) reserviert. Well-
known Ports werden Ir Standarddienste, wie z.B
telnet, Itp etc. genutzt. Ports zwischen 256 und 1023
wurden im allgemeinen Ir UNIX-speziIische Dienste (wie z.B. rlogin) benutzt. Ein Beispiel Ir
den Unterschied zwischen einem Internet-weiten Dienst und einem UNIX-speziIischen Dienst ist
der Unterschied zwischen Telnet und RLogin. Beide Dienste erlauben es, sich ber das Netz auI
einem entIernten Host einzuloggen. Telnet ist ein TCP/IP-Standard mit der Portnummer 23 und
kann von so gut wie auI allen Betriebssystemen implementiert werden. RLogin ist im Gegensatz
dazu ein UNIX-speziIischer Dienst, dessen Portnummer 53 ist.
Die Verwaltung der Portnummern ist nun von der Internet Assigned Numbers Authoritv (IANA)
|http://www.iana.org| bernommen worden. Portnummern sind dabei in drei Bereiche auIgeteilt
worden: well-lnown ports, registered ports und dvnamic ports.
0 - 1023 Well-known ports (von der IANA verwaltet). Der Bereich
der well-known ports ist bis 1023 erweitert worden, damit
sind auch die UNIX-speziIischen Dienste als
Standarddienste Iestgelegt.
1024 - 49151 Registered ports. Registrierte Ports dienen Ir Dienste, die
blicher Weise auI bestimmten Ports lauIen. Ein Beispiel
ist hier der Port 8080, der als "zweiter" bzw. alternativer
Port Ir das http dient.
49152 -
65535
Dynamic and/or private ports. Dieser Bereich ist Ir die
sogenannten dynamischen Ports Iestgelegt. Dynamische
Ports dienen zur Kommunikation zwischen den beiden
TCP-Schichten, die an einer Kommunikation beteiligt
sind. Ein dynamischer Port wird nicht von bestimmten
Standarddiensten belegt.
AuI UNIX-Systemen sind Portnummern in der Datei /etc/services deIiniert. Auszug aus der
Datei /etc/services eines Linux-Systems:
heiko@phoenix:~> more /etc/services
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-
# known port number for both TCP and UDP; hence, most entries here have
# two entries even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
#
Seite 35
Host A (129.75.123.140)
(49177, 80)*
Host B (149.22.99.101)
(80, 49177)
(49177, 80)
(80, 49177)
*(Source, Destination)
# from: @(#)services 5.8 (Berkeley) 5/9/91
# $Id: services,v 1.9 1993/11/08 19:49:15 cgd Exp $
#
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp 21/tcp
# 22 - unassigned
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
Der TCP-Header
Die sendende und die empIangende TCP-Einheit tauschen Daten in Form von Segmenten aus. Ein
Segment ist nichts anderes als die zu bertragenden Daten, versehen mit ,SteuerinIormationen.
Jedes Segment beginnt mit einem 20-Byte-Header, auI den Header-Optionen Iolgen knnen. Den
Optionen Iolgen schlielich die zu bertragenden Daten. Die Segmentgre wird durch zwei
Faktoren begrenzt: erstens muss jedes Segment, einschlielich des TCP-Headers, in das
NutzdatenIeld des IP-Protokolls passen (65.535 Byte); zweitens hat jedes Netz eine maximale
Transfereinheit (MTU - Maximum Transfer Unit), in die das Segment passen muss. In der Regel ist
die MTU einige tausend Byte gro und gibt die obere Grenze der Segmentgre vor (z.B. Ethernet
1.500 Bytes). LuIt ein Segment durch eine Anzahl von Netzen und triIIt dabei auI ein Netz mit
einer kleineren MTU, so muss das Segment vom Router in kleinere Segmente auIgeteilt
(fragmentiert) werden. Unabhngig von der Gre der MTU knnen dem TCP-Header und den
Seite 36
Optionen maximal 65.535-20-20 65.495 Datenbyte Iolgen (die ersten 20 Byte beziehen sich auI
den IP-Header, die zweiten auI den TCP-Header; die Lnge der Optionen wird mit zu den
Datenbytes gezhlt). TCP-Segmente ohne Daten sind zulssig und dienen der bermittlung von
Besttigungen und Steuernachrichten.
Die Felder des TCP-Headers haben die Iolgende Bedeutung:
Source-/Destination-Port:
Die Felder Source Port (Quellport) und Destination Port (Zielport) adressieren die Endpunkte
der Verbindung. Die Gre Ir die beiden Felder betrgt 16 Bit (siehe auch den Abschnitt
Portnummern).
Sequence Number, Acknowledgement Number:
Die Sequen:nummer und die Besttigungsnummer 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 Besttigungsnummer Ir
EmpIangsquittungen. Jeder der beiden TCP-Verbindungspartner generiert beim
VerbindungsauIbau eine Sequenznummer, die sich whrend des Zeitraums der Verbindung
nicht wiederholen darI. Dies ist allerdings durch den groen Zahlenraum von 2
32
wohl
ausreichend gesichert (RFC1323 stellt allerdings dar, dass die Gre der Sequenznummer bei
schnellen Netztechnologien zu einem Problem werden kann, so liegt die DurchlauIzeit bei 10-
Mbit/s-Ethernet durch alle Folgenummern noch bei 57 Minuten, whrend die DurchlauIzeit
bei 1-Gbit/s-Ethernet bereits nur noch 34 Sekunden betrgt). Diese Nummern werden beim
VerbindungsauIbau ausgetauscht und gegenseitig quittiert. Bei der Datenbertragung wird die
Sequenznummer vom Absender jeweils um die Anzahl der bereits gesendeten Bytes erhht.
Mit der Quittungsnummer gibt der EmpInger an, bis zu welchem Byte er die Daten bereits
korrekt empIangen hat. Die Nummer gibt allerdings nicht an, welches Byte zuletzt korrekt
empIangen wurde, sondern welches Byte als nchstes zu erwarten ist.
OIIset:
Das Feld Offset (oder auch Header Length) gibt die Lnge des TCP-Headers in 32-Bit Worten
an. Dies entspricht dem AnIang der Daten im TCP-Segment. Das Feld ist notwendig, da der
Seite 37
Abbildung 21 Der TCP-Header.
Source Port Destination Port
Sequence Number
Acknowledgement Number
Window
Checksum
Options Padding
Data begins here...
1 4 8 12 16 20 24 28 32
Bits
H
e
a
d
e
r
Urgent Pointer
Offset Reserved Flags
Header durch das OptionsIeld eine variable Lnge hat.
Flags:
Mit den sechs 1-Bit-Flags im Flags-Feld werden bestimmte Aktionen im TCP-Protokoll
aktiviert:
URG
Wird das Flag URG auI 1 gesetzt, so bedeutet dies, dass der Urgent Pointer
(Dringend:eiger) verwendet wird.
ACK
Das ACK-Bit wird gesetzt, um anzugeben, dass die Besttigungsnummer im Feld
Aclnowledgement Number gltig ist. Ist das Bit auI 0 gesetzt, enthlt das TCP-Segment
keine Besttigung, das Feld Acknowledgement Number wird ignoriert.
PSH
Ist das PSH-Bit gesetzt, so werden die Daten in dem entsprechenden Segment soIort bei
AnkunIt der adressierten Anwendung bereitgestellt ohne sie zu puIIern.
RST
Das RST-Bit dient dazu eine Verbindung zurckzusetzen, Ialls ein Fehler bei
bertragung auIgetreten ist. Dies kann sowohl der Fall sein, wenn ein ungltiges
Segment bertragen wurde, ein Host abgestrzt ist oder der Versuch eines
VerbindungsauIbaus abgewiesen werden soll.
SYN
Das SYN-Flag (Svnchroni:e Sequen:e Numbers) wird verwendet, um Verbindungen
auIzubauen. Zusammen mit der Acknowledgement Number und dem ACK-Bit wird die
Verbindung im Form eines Dreiwege-Handshale auIgebaut (siehe oben).
FIN
Das FIN-Bit dient zum Beenden einer Verbindung. Ist das Bit gesetzt, gibt dies an, dass
der Sender keine weiteren Daten zu bertragen hat. Das Segment mit gesetztem FIN-Bit
muss quittiert werden.
Window:
Das Feld Fenstergre enthlt die Anzahl Bytes, die der EmpInger ab dem bereits
besttigten Byte empIangen kann. Mit der Angabe der Fenstergre erIolgt in TCP die
Flusteuerung. Das TCP-Protokoll arbeitet nach dem Prinzip eines Schiebefensters mit
variabler Gre (Sliding Window). Jede Seite einer Verbindung darI die Anzahl Bytes senden,
die im Feld Ir die Fenstergre angegeben ist, ohne auI eine Quittung von der
EmpIngerseite zu warten. Whren des Sendens knnen gleichzeitug Quittungen Ir die von
der anderen Seite empIangenen Daten eintreIIen (diese Quittungen knnen wiederum neue
Fenstergren einstellen). Eine Fenstergre von 0 besagt, dass die Bytes bis einschlielich
der Acknowledgement Number minus Eins empIangen wurden, der EmpInger momentan
aber keine weiteren Daten empIangen kann. Die Erlaubnis zum weiteren Senden von Daten
erIolgt durch das versenden eines Segments mit gleicher Besttigungsnummer und einer
Fenstergre ungleich Null.
Seite 38
Checksum:
Die Prfsumme prIt den ProtokollkopI, die Daten und den Pseudo-Header (siehe Abbildung
20).
Der Algorithmus Ir die Bildung der PrIsumme ist einIach: alle 16-Bit Wrter werden im
1er-Komplement addiert und die Summe ermittelt. Bei der Berechnung ist das Feld Checksum
auI Null gesetzt und das DatenIeld wird bei ungerader Lnge um ein Nullbyte auIgeIllt.
Fhrt der EmpInger des Segments die Berechnung auI das gesamte Segment aus - inklusive
des Feldes Ir die PrIsumme - sollte das Ergebnis 0 sein |Tanenbaum1996|. Der Pseudo-
Header enthlt die 32-bit groen IP-Adressen der Quell- und Zielmaschine sowie die
Protokollnummer (Ir TCP 6) und die Lnge des TCP-Segments. Die Einbeziehung der Felder
des Pseudo-Headers in die PrIsummenberechnung hilIt, durch IP Ialsch zugeteilte Pakete zu
erkennen. Die Verwendung von IP-Adressen auI der Transportebene stellt allerdings eine
Verletzung der Protokollhierarchie dar.
Urgent Pointer:
Der Urgent-Zeiger ergibt zusammen mit der Sequenznummer einen Zeiger auI ein Datenbyte.
Dies entspricht einem Byteversatz zu einer Stelle, an der dringende Daten vorgeIunden
werden. TCP signalisiert damit, dass sich an einer bestimmten Stelle im Datenstrom wichtige
Daten beIinden, die soIort gelesen werden sollten. Das Feld wird nur gelesen, wenn auch das
Urgent-Flag (siehe oben) gesetzt ist.
Options:
Das Options-Feld soll eine Mglichkeit bieten Funktionen bereitzustellen, die im normalen
TCP-ProtokollkopI nicht vorgesehen sind. In TCP sind drei Optionen deIiniert: End of Option
List, No-Operation und Maximum Segment Si:e. Die wichtigste dieser drei Optionen ist die
Maximale Segmentgre. Mit dieser Option kann ein Host die maximale Anzahl Nutzdaten
bermitteln, die er annehmen will bzw. annehmen kann. Whrend eines VerbindungsauIbaus
kann jede Seite ihr Maximum an Nutzdaten bermitteln, die kleinere der beiden Zahlen wird
als maximale Nutzdatengre Ir die bertragung bernommen. Wird diese Option von
einem Host nicht untersttzt wird als Standard die Vorgabe von 536 Byte verwendet.
Padding:
Das Feld Padding wird verwendet, um sicherzustellen, dass der Header an einer 32-Bit
Grenze endet und die Daten an einer 32-Bit Grenze beginnen. Das FllIeld wird mit Nullen
geIllt.
Seite 39
Abbildung 22 Der Pseudo-Header in der Prfsumme.
Source Address
Destination Address
00000000
1 4 8 12 16 20 24 28 32
Bits
Protocol = 6 TCP segment length
3.4.2 User Datagram ProtocoI (UDP)
Das User Datagram Protocol (UDP) ist im RFC 768 deIiniert. UDP ist ein unzuverlssiges,
verbindungsloses Protokoll. Wie zuvor schon gesagt, bedeutet unzuverlssig in diesem
Zusammenhang nicht, dass die Daten evtl. IehlerhaIt beim Zielrechner ankommen, sondern, dass
das Protokoll keinerlei Mechanismen zur VerIgung stellt, die sichern, dass die Daten auch
tatschlich beim Zielrechner ankommen. Sind die Daten aber beim Zielrechner angekommen, so
sind sie auch korrekt. UDP bietet gegenber 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 auI der Grundlage einer AnIrage und einer Antwort lauIen),
verwenden UDP als Transportprotokoll, da unter Umstnden der AuIwand zur Herstellung einer
Verbindung und einer zuverlssigen Datenbermittlung grer ist als die wiederholte bertragung
der Daten.
Ein UDP-Segment besteht aus einem Header von 8 Byte, geIolgt von den Daten.
Die Sender- und EmpInger-Portnummern erIllen den gleichen Zweck wie beim Transmission
Control Protocol. Sie identiIizieren die Endpunkte der Quell- und Zielmaschine. Das Feld Ir die
Lnge enthlt die Lnge des gesamten Datengramms, inklusive der Lnge des ProtokollkopIes. Die
PrIsumme enthlt die Internet-PrIsumme der UDP-Daten, des ProtokollkopIs und des Pseudo-
Headers. Das PrIsummenIeld ist optional. Enthlt das Feld eine 0, wurde vom Absender keine
PrIsumme eingetragen und somit Iindet beim EmpInger keine berprIung statt.
Das User Datagram Protocol lieIert ber die Leistungen des Internet Protokolls hinaus nur
Portnummern Ir die Adressierung der Kommunikationsendpunkte und eine optionale PrIsumme.
Das Protokoll beinhaltet keine Transportquittungen oder andere Mechanismen Ir die Bereitstellung
einer zuverlssigen Ende-zu-Ende-Verbindung. Hierdurch wird UDP allerdings sehr eIIizient und
eignet sich somit besonders Ir Anwendungen, bei denen es in erster Linie auI die Geschwindigkeit
der Datenbertragung ankommt (z.B. verteilte Dateisysteme wie NFS).
3.5 AppIikationsschicht
Die oberste Schicht des TCP/IP-Modells ist die Applikationsschicht. Diese Schicht bietet eine Reihe
standardisierter Anwendungsprotokolle, auI die eine Vielzahl von Anwendungsprogrammen
auIsetzen. An dieser Stelle seien nur einige Protokolle, die auI der Anwendungsschicht angeboten
werden, genannt:
TELNET:
TELNET ist das Protokoll Ir virtuelle Terminals. Es dient dazu, ZugriII auI einen am Netz
angeschlossenen Rechner in Form einer Terminalsitzung (auch remote login genannt) zu
Seite 40
Abbildung 23 Der UDP-Header.
Source Port
Length
Data begins here...
1 4 8 12 16 20 24 28 32
Bits
Checksum
Destination Port
H
e
a
d
e
r
lieIern. Der TELNET-Dienst benutzt den TCP-Port 23. TELNET ist im RFC 854 speziIiziert.
FTP:
Mit dem File Transfer Protocol - FTP lassen sich Dateien externer Rechner bertragen,
lschen, ndern oder umbenennen. FTP ist im RFC 959 deIiniert. 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 Ir die elektronische Post im
Internet. Das bertragungsprotokoll Ir elektronische Post ist im RFC 821 und das
NachrichtenIormat im RFC 822 speziIiziert.
DNS:
Der Domain Name Service - DNS dient dazu ASCII-Zeichenketten in Internet-Adressen und
umgekehrt zu wandeln. DNS ist ein hierarchisches Benennungssystem, das auI Domnen
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 knnen) in IP-Adressen umzuwandeln. DNS ist in den RFCs 1034
und 1035 deIiniert.
NFS:
Mit dem Networl File Svstem - NFS lassen sich mehrere Rechner auI transparente Weise
miteinander verbinden. Der NFS-Dienst stellt eine virtuelle Verbindung von LauIwerken und
Festplatten her, so da sich entIernte Dateisysteme als Erweiterung des eigenen lokalen
Dateisystems darstellen.
Seite 41
4 IP Version 6
Es wird wohl noch etwas lnger dauern, bis dieser Abschnitt der Arbeit endlich Iertig ist, da ich im
Moment ziemlich viele andere Dinge zu tun habe. Fr alle, die aber jetzt schon mehr wissen wollen
gebe ich an dieser Stelle einen kurzen Hinweis auI Literatur (weitere Quellen sind in der
Literaturliste zu Iinden):
Hinden R.: IP Next Generation (IPng). http://playground.sun.com/pub/ipng/html/ipng-
main.html.
Huitema, C.: IPv6 - die neue Generation, Architektur und Implementierung. Addison-
Wesley, Mnchen, 2000.
4.1 Die Zukunft
Das rasche (exponentielle) Wachstum des Internet zwingt dazu, das Internet Protokoll in der
Version 4 (IPv4) zu ndern oder durch ein NachIolgeprotokoll zu ersetzen .
Bis zu Beginn 90er Jahre wurde das Internet grtenteils nur von Universitten,
Regierungsbehrden (dies aber auch Iast nur in den USA und hier vor allem vom
Verteidigungsministerium) und einigen Firmen aus der Industrie genutzt. Seit der EinIhrung des
World Wide Web (WWW) ist das Internet aber auch zunehmend Ir Privatpersonen, kleinere Firmen
etc. interessant. Das Internet wandelt sich von einem "Spielplatz Ir Akademiker" zu einem
weltweiten InIormations- und Unterhaltungssystem. Mit der stndig steigenden Anzahl von
Benutzern des Internet werden sich auch die AnIorderungen an das Netz ndern bzw. haben sich
bereits gendert. Genannt sei hier nur als Beispiel das angestrebte Zusammenwachsen der
Computer-, Unterhaltungs- und Telekommunikationsbranchen. Den AnIorderungen, die z.B. Video-
on-demand stellt, ist das Internet bzw. das Internet Protokoll in der Version 4 nicht gewachsen.
Vinton CerI (der ,Vater des Internet) bezeichnet in einem Interview mit der ZeitschriIt c't
|Krempl1998| das Internet "(...) als die wichtigste Infrastrultur fr alle Arten von
Kommunilation.". AuI die Frage, wie man sich die neuen Kommunikationsdienste des Internet
vorstellen knne, antwortete CerI:
"Am spannendsten finde ich es, die gan:en Haushaltsgerte ans Net: an:uschlieen. Ich
denle dabei nicht nur daran, dass der Khlschranl sich in Zulunft mit der Hei:ung
austauscht, ob es in der Kche :u warm ist. Stromgesellschaften lnnten beispielsweise
Gerte wie Geschirrsplmaschinen lontrollieren und ihnen Strom genau dann :ur
Verfgung stellen, wenn gerade leine Spit:ennachfrage herrscht. Derartige
Anwendungen hngen allerdings davon ab, dass sie :u einem erschwinglichen Preis
angeboten werden. Das ist nicht unbedingt ferne Zulunftsmusil, die Programmierer
mten eigentlich nur damit anfangen, endlich Software fr intelligente
Net:werlanwendungen :u schreiben. Und natrlich mu die Sicherheit derartiger
Svsteme garantiert sein. Schlielich mchte ich nicht, dass die Nachbarlinder mein
Haus programmieren!"
AuI die Internet Protokolle kommen in der nchsten Zeit also vllig neue AnIorderungen zu. Wie
versucht wird, diese AnIorderungen zu erIllen, wird in den nchsten Abschnitten beschrieben.
Seite 42
4.2 CIassIess InterDomain Routing (CIDR)
Der Verknappung der Internet-Adressen durch die stndig steigende Benutzerzahl wird zunchst
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 groe
Anzahl von Adressen verschwendet. Hierbei stellt sich vor allem die Klasse B als Problem dar.
Viele Firmen nehmen ein Netz der Klasse B Ir sich in Anspruch, da ein Klasse A Netz mit bis zu
16 Mio. Hosts selbst Ir eine sehr groe Firma berdimensioniert scheint. Tatschlich ist aber oIt
auch ein Klasse B Netz zu gro. Fr viele Firmen wrde ein Netz der Klasse C ausreichen. Dies
wurde aber nicht verlangt, da viele Unternehmen die BeIrchtung hatten, dass ein Klasse C Netz mit
seinen bis zu 254 mglichen Hosts nicht ausreichen wrde.
Ein greres HostIeld Ir Netze der Klasse C (z.B. 10 Bit, das entspricht 1022 Host pro Netz) htte
das Problem der knapper werdenden IP-Adressen vermutlich gemildert. Ein anderes Problem wre
dadurch allerdings entstanden: die Eintrge der Routing-Tabellen wren explodiert.
Ein anderes Konzept ist das Classless InterDomain Routing (RFC 1519): die verbleibenden Netze
der Klasse C werden in Blcken variabler Gre zugewiesen. Werden beispielsweise 2000
Adressen bentigt, so knnen einIach acht auIeinander Iolgende Netze der Klasse C vergeben
werden; das entspricht einem Block von 2048 Adressen. Zustzlich 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 Adressraums erhlt, auIgeteilt:
194.0.0.0 - 195.255.255.255 Europa
198.0.0.0 - 199.255.255.255 Nordamerika
200.0.0.0 - 201.255.255.255 Mittel- und Sdamerika
202.0.0.0 - 203.255.255.255 Asien und paziIischer Raum
204.0.0.0 - 223.255.255.255 Reserviert Ir zuknItige Nutzung
Jede der Zonen erhlt dadurch in etwa 32 Millionen Adressen zugewiesen. Vorteil bei diesem
Vorgehen ist, dass die 32 Millionen Adressen einer Region im Prinzip zu einem Eintrag in den
Routing-Tabellen komprimiert worden sind. Der Vorteil der dadurch entsteht ist, dass z.B. jeder
Router, der eine Adresse auerhalb seiner Region zugesandt bekommt...
4.3 Internet ProtokoII Version 6 (IPv6)
Der vorrangige Grund Ir eine nderung des IP-Protokolls ist auI den begrenzten Adreraum
zurckzuIhren. CIDR schaIIt hier zwar wieder etwas LuIt, dennoch ist klar absehbar, dass auch
diese Manahmen nicht ausreichen, um die Verknappung der Adressen Ir eine lngere Zeit in den
GriII zu bekommen.
Weitere Grnde Ir eine nderung des IP-Protokolls sind die oben schon erwhnten neuen
AnIorderungen an das Internet. Diesen AnIorderungen ist IP in der Version 4 nicht gewachsen. Die
IETF (Internet Engineering Tasl Force) begann deshalb 1990 mit der Arbeit an einer neuen
Version von IP. Die wesentlichen Ziele des Projekts sind |Tanenbaum1996|:
Untersttzung von Milliarden von Hosts, auch bei ineIIizienter Nutzung des Adressraums
Seite 43
Reduzierung des UmIangs der Routing-Tabellen
VereinIachung des Protokolls, damit Router Pakete schneller abwickeln knnen
Hhere Sicherheit (AuthentiIikation und Datenschutz) als das heutige IP
Mehr Gewicht auI Dienstarten, insbesondere Ir Echtzeitanwendungen
Untersttzung von Multicasting durch die Mglichkeit, den UmIang zu deIinieren
Mglichkeit Ir Hosts, ohne Adressnderung auI Reise zu gehen
Mglichkeit Ir das Protokoll, sich zuknItig weiterzuentwickeln
Untersttzung der alten und neuen Protokolle in Koexistenz Ir Jahre
Im Dezember 1993 Iorderte die IETF mit RFC 1550 |IP: Next Generation (IPnG) White Paper
Solicitation, Dec. 1993| die Internet-Gemeinde dazu auI, Vorschlge Ir ein neues Internet
Protokoll zu machen. AuI die AnIrage wurde eine Vielzahl von Vorschlgen eingereicht. Diese
reichten von nur geringIgigen nderungen am bestehenden IPv4 bis zur vollstndigen Ablsung
durch ein neues Protokoll. Die drei besten Vorschlge wurden im IEEE Networl Maga:ine
verIIentlicht (|Deering1993|, |Francis1993|, |KatzFord1993|). Aus diesen Vorschlgen wurde von
der IETF das Simple Internet Protocol Plus (SIPP) als Grundlage Ir die neue IP-Version
ausgewhlt. SIPP ist eine Kombination aus den Vorschlgen von Deering |Deering1993| und
Francis |Francis1993|.
Als die Entwickler mit den Arbeiten an der neuen Version des Internet Protokolls begannen, wurde
natrlich auch ein Name Ir das Projekt bzw. das neue Protokoll bentigt. Wohl angeregt durch eine
gleichnamige Fernsehsendung, wurde als Arbeitsname IP - Next Generation (IPnG) gewhlt.
Schlielich bekam das neue IP eine oIIizielle Versionsnummer zugewiesen: IP Version 6 oder kurz
IPv6. Die Protokollnummer 5 (IPv5) wurde bereits Ir ein experimentelles Protokoll verwendet.
Die Iolgende Beschreibung von IPv6 orientiert sich an RFC 2460 |Internet Protocol, Version 6
(IPv6) SpeciIication, Dec. 1998|. Dieses Dokument gibt den neuesten Stand der SpeziIikation des
Internet Protokolls in der Version 6 wieder. RFC 2460 enthlt einige wesentliche nderungen der
SpeziIikation gegenber RFC 1883 |Internet Protocol, Version 6 (IPv6) SpeciIication, Dec. 1995|.
4.3.1 Die MerkmaIe von IPv6
Viele der als erIolgreich 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 geringIgigen
ModiIikationen. Die ModiIikationen betreIIen im wesentlichen die erweiterte Adressgre (bisher
32 Bit auI nun 128 Bit).
Die wesentlichen Merkmale von IPv6 sind:
Adressgre: Als wichtigstes Merkmal hat IPv6 gegenber IPv4 grere Adressen. Statt
bisher 32 Bit stehen nun 128 Bit Ir die Adressen bereit. Theoretisch lassen sich damit
2
128
3.4*10
38
Adressen vergeben.
Header-Format: Der IPv6 (Basis)Header wurde vollstndig gendert. Der Header enthlt
nur 7 statt bisher 13 Felder. Diese nderung ermglicht 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, geIolgt von den Nutzdaten.
Erweiterte Untersttzung von Optionen und Erweiterungen: Die Erweiterung der
Seite 44
Optionen ist notwendig geworden, da einige, bei IPv4 notwendige Felder nun optional sind.
Darber hinaus unterscheidet sich auch die Art, wie die Optionen dargestellt werden. Fr
Router wird es damit einIacher, Optionen, die nicht Ir sie bestimmt sind, zu berspringen.
Dies ermglicht ebenIalls eine schnellere Verarbeitung von Paketen.
Dienstarten: IPv6 legt mehr Gewicht auI die Untersttzung von Dienstarten. Damit kommt
IPv6 den Forderungen nach einer verbesserten Untersttzung der bertragung von Video-
und Audiodaten entgegen. IPv6 bietet hierzu eine Option zur Echtzeitbertragung.
Sicherheit: IPv6 beinhaltet nun im Protokoll selbst Mechanismen zur sicheren
Datenbertragung. Wichtige neue Merkmale von IPv6 sind hier AuthentiIikation
(authentication), Datenintegritt (data integrity) und Datenverlsslichkeit (data
conIidentiality).
Erweiterbarkeit: IPv6 ist ein erweiterbares Protokoll. Bei der SpeziIikation des Protokolls
wurde nicht versucht alle potentiell mglichen EinsatzIelder Ir das Protokoll in die
SpeziIikation zu integrieren. Vielmehr bietet IPv6 die Mglichkeit ber IPv6-Erweiterungs-
Header das Protokoll zu erweitern. Damit ist das Protokoll oIIen Ir zuknItige
Verbesserungen.
4.3.2 Das IPv6 Datengrammformat
Ein IPv6-Datengramm besteht aus dem Basis-Header, geIolgt von den optionalen IPv6-
Erweiterungs-Headern und den Nutzdaten.
4.3.3 Der IPv6-Basis-Header
Der IPv6-Basis-Header ist doppelt so gro wie der IPv4-Header. Der IPv6-Basis-Header enthlt
weniger Felder als der IPv4-Header, daIr ist aber die Adressgre Ir die Quell- und Zieladresse
von bisher 32-Bit auI nunmehr 128-Bit erweitert worden.
Version
Mit dem Feld Version knnen Router berprIen, um welche Version des Protokolls es sich
handelt. Fr ein IPv6-Datengramm ist dieses Feld immer 6 und Ir ein IPv4-Datengramm
dementsprechend immer 4. Mit diesem Feld ist es mglich Ir eine lange Zeit die
unterschiedlichen Protokollversionen IPv4 und IPv6 nebeneinander zu verwenden. ber die
PrIung des Feldes Version knnen die Daten an das jeweils richtige
,Verarbeitungsprogramm weitergeleitet werden.
Priority:
Das Feld Prioritv (oder Traffic Class) ...
Flow Label
Das Feld Flow Label...
Seite 45
Abbildung 24 Allgemeine Form eines IPv6-Datengramms.
Base
Header
Extension
Header 1
Extension
Header n
... Data
optional
Payload Length
Das Feld Pavload Length (Nut:datenlnge) gibt an, wie viele Bytes dem IPv6-Basis-Header
Iolgen, der IPv6-Basis-Header ist ausgeschlossen. Die Erweiterungs-Header werden bei der
Berechnung der Nutzdatenlnge mit einbezogen. Das entsprechende Feld wird in der
Protokollversion 4 mit Total Length bezeichnet. Allerdings bezieht IPv4 den 20 Byte groen
Header auch mit in die Berechnung ein, wodurch die Bezeichnung ,total length gerechtIertigt
ist.
Next Header
Das Feld Next Header gibt an, welcher Erweiterungs-Header dem IPv6-Basis-Header Iolgt.
Jeder Iolgende Erweiterungs-Header beinhaltet ebenIalls ein Feld Next Header, das auI den
nachIolgenden Header verweist. Ist dies der letzte zu IPv6 zugehrige Header, so gibt das Feld
an, welches Transportprotokoll (z.B. TCP oder UDP) Iolgt. Eine genauere Beschreibung des
Konzepts mehrerer Header Iolgt im Abschnitt IPv6-Erweiterungs-Header
Hop Limit
Mit dem Feld Hop Limit wird Iestgelegt, wie lange ein Paket berleben darI. Der Wert des
Feldes wird nach jeder Teilstrecke gesenkt. Ein Datengramm wird dann verworIen, wenn das
Feld Hop Limit auI Null herunter gezhlt 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 darI. Allerdings wird dieses Feld von den meisten Routern nicht so
interpretiert. In IPv6 wurde das Feld deshalb umbenannt, um die tatschliche Nutzung
wiederzugeben.
Source Address, Destination Address
Die beiden Felder Quell- und Zieladresse dienen zur IdentiIizierung des Senders und
EmpIngers eines IP-Datengramms. IPv6 verwendet zur Adressierung 4 mal so groe
Adressen wie IPv4: 128 Bit statt 32 Bit. Eine genaue Beschreibung der IPv6-Adressen Iolgt
Seite 46
Abbildung 25 IPv6-Basis-Header.
Version Flow Label Priority
Payload Length Hop Limit Next Header
Source Address
1 4 8 12 16 20 24 28 32
Bits
H
e
a
d
e
r
Destination Address
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 Ieste Lnge von 40 Byte hat. Bei IPv4 ist dieses Feld notwendig, da der
Header auIgrund der Optionen eine variable Lnge hat.
Das Feld Protocol wird nicht mehr bentigt, da das Feld Next Header angibt, was nach dem
letzten IP-Header Iolgt (z.B. TCP oder UDP).
Alle Felder die bisher zur Fragmentierung eines IP-Datengramms bentigt wurden
(Identification, Flags, Fragment Offset), sind im IPv6-Basis-Header nicht mehr vorhanden,
da die Fragmentierung in IPv6 gegenber IPv4 anders gehandhabt wird. Alle IPv6
kompatiblen Hosts und Router mssen Pakete mit einer Gre von 1280 Byte (RFC 1883
legte diese Gre noch auI 576 Byte Iest) untersttzen. Durch diese Regel wird eine
Fragmentierung im Prinzip nicht notwendig. EmpIngt ein Router ein zu groes Paket, so
Ihrt er keine Fragmentierung mehr durch, sondern sendet eine Nachricht an den Absender
des Pakets zurck. In dieser Nachricht wird der sendende Host angewiesen, alle weiteren
Pakete zu diesem Ziel auIzuteilen. Das bedeutet, dass von den Hosts ,erwartet wird, dass
sie von vornherein eine Datengrammgre whlen, die keine Fragmentierung voraussetzt.
Dadurch wird eine grere EIIizienz bei der bertragung erreicht, als wenn Pakete von
Routern auI dem Weg Iragmentiert werden mssen. Die Steuerung der Fragmentierung
erIolgt bei IPv6 ber den Fragment Header.
Das Feld Checlsum ist nicht mehr vorhanden, da die Berechnung der PrIsumme sich
nachteilig auI die Leistung der Datenbertragung ausgewirkt hat. Das entIernen der
PrIsumme aus dem Internet Protokoll hat zu heItigen Diskussionen geIhrt
|Tanenbaum1996|. Die eine Seite kritisierte heItig das entIernen der PrIsumme, whrend
die andere Seite argumentierte, dass PrIsummen etwas sind, das auch von Anwendungen
bernommen werden kann, soIern sich die Anwendung tatschlich um Datenintegritt
kmmert. Ein weiteres Gegenargument war, dass eine PrIsumme auI der Transportschicht
bereits vorhanden ist, weshalb innerhalb der Vermittlungsschicht keine weitere PrIsumme
notwendig sei. Letztendlich Iiel die Entscheidung, dass IPv6 keine PrIsumme enthlt.
4.3.4 IPv6-Erweiterungs-Header
IPv6 nutzt das Konzept der Erweiterungs-Header, um a) eine eIIiziente Datenbertragung und b)
eine Erweiterung des Protokolls zu ermglichen. Der erste Punkt ist leicht ersichtlich: Der Basis-
Header enthlt nur Felder, die unbedingt Ir die bermittlung eines Datengramms notwendig sind,
erIordert die bertragung weitere Optionen, so knnen 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 Iragmentiert werden mssen, enthlt der IPv4-Header Felder, Ir die
Fragmentierung. IPv6 gliedert die Felder Ir die Fragmentierung in einen separaten Header aus, der
wirklich nur dann verwendet werden mu, wenn das Datengramm tatschlich Iragmentiert werden
mu. Ein weiterer wesentlicher Vorteil des Konzepts der Erweiterungs-Header ist, dass das
Protokoll um neue Funktionen erweitert werden kann. Es gengt, Ir das Feld Next Header einen
neuen Typ und ein neues Header-Format zu deIinieren. IPv4 erIordert hierzu eine vollstndige
nderung des Headers.
Seite 47
Derzeit sind 6 Erweiterungs-Header deIiniert. Alle Erweiterungs-Header sind optional. Werden
mehrere Erweiterungs-Header verwendet, so ist es erIorderlich, sie in einer Iesten ReihenIolge
anzugeben.
Header Beschreibung
IPv6-Basis-Header Zwingend erIorderlicher IPv6-Basis-Header
Optionen Ir Teilstrecken
(Hop-by-Hop Options Header)
Verschiedene InIormationen Ir Router
Optionen Ir Ziele
(Destination Options Header)
Zustzliche InIormationen Ir das Ziel
Routing
(Routing Header)
DeIinition einer vollstndigen oder teilweisen
Route
Fragmentierung
(Fragment Header)
Verwaltung von DatengrammIragmenten
AuthentiIikation
(Authentication Header)
EchtheitsberprIung des Senders
Verschlsselte Sicherheitsdaten
(Encapsulating Security Payload Header)
InIormationen ber den verschlsselten Inhalt
Optionen Ir Ziele
(Destination Options Header)
Zustzliche InIormationen Ir das Ziel (Ir
Optionen, die nur vom endgltigen Ziel des
Pakets verarbeitet werden mssen)
Header der hheren Schichten
(Upper Layer Header)
Header der hheren Protokollschichten (TCP,
UDP etc.)
Die ersten 5 Header sind in RFC 2460 (bzw. RFC 1883). Der AuthentiIikations-Header sowie der
Header Ir Sicherheitsdaten werden in RFC 2402 (RFC 1826) und RFC 2406 (RFC 1827)
beschrieben.
Seite 48
Abbildung 26 IPv6-Datengramme. (a) IPv6-Basis-Header und Nut:daten (b) IPv6-Basis-
Header mit einem Zusat:-Header fr Routing-Informationen und Nut:daten (c) IPv6-Basis-
Header mit einem Zusat:-Header fr Routing-Informationen, einem Zusat:-Header fr
Fragmentierung und Nut:daten.
TCP Header + Data
TCP Header + Data
IPv6 Header
(next header=TCP)
IPv6 Header
(next header=routing)
Routing Header
(next header=TCP)
(a)
(b)
Fragment with
TCP Header + Data
IPv6 Header
(next header=routing)
Routing Header
(next header=fragment)
(c)
Fragment Header
(next header = TCP)
Hop-by-Hop Options Header
Routing Header
Fragment Header
Destination Options Header
4.3.5 IPv6-Adressierung
Seite 49
5 QueIIenverzeichnis
5.1 Anmerkungen zur Literatur
Es gibt eine groe Zahl an Literatur, die sich mit TCP/IP und Computernetzwerken im allgemeinen
beIasst. Ich mchte an dieser Stelle einige Werke hervorheben, die mir bei der Erstellung des Semi-
narvortrags und dieses Textes besonders hilIreich waren.
Comer D.E.: Internetworling with TCP/IP, Volumes I-III
Die drei Bnde von Comer ber TCP/IP sind wohl die Werke ber TCP/IP schlechthin - wird
von einigen auch als ,TCP/IP-Bibel bezeichnet.
Stevens R. W.: TCP/IP Illustrated, Volumes I-III
Stevens hat mit seinem dreibndigen Werk ber TCP/IP wohl die zweite Bibel zum Thema
TCP/IP verIasst (oder nennen wir es das Neue Testament). Mir persnlich geIallen die drei
Bnde von Stevens noch besser als die Bcher von Comer. Stevens hat Ir die Darstellung der
TCP/IP-Protokolle einen anderen Weg, als die bloe theoretische Vorstellung der einzelnen
Protokolle gewhlt, die Protokolle werden anhand eines Analyse-Tools untersucht und ihre
Funktionsweise so anschaulich vermittelt.
Tanenbaum A.S.: Computernet:werle
Wer allgemein etwas ber Computernetzwerke erIahren mchte, der sollte in dieses Buch
schauen. Das Buch deckt so ziemlich alles ab, was mit Computernetzen zu tun hat und ist da-
bei sehr gut geschrieben. Im WWW werden vom Autor und dem Verlag Leseproben und alle
Abbildungen des Buches zur VerIgung gestellt (siehe die Angaben in der Literaturliste).
Kurose J.F., Ross K.W.: Computernet:e
Normalerweise werden Computernetze in der Literatur immer von unten nach oben, d.h. von
der Netzwerkschicht hinauI zur Applikationsschicht beschrieben. Kurose und Ross whlen
den umgekehrten Weg und beschreiben Computernetze in einem Top-Down-Ansatz von der
Applikationsschicht hinunter zur Netzwerkschicht. Das Buch enthlt zahlreiche Interviews
mit Fachleuten und gibt damit einen interessanten Einblick in die Praxis. Das Buch steht in
der englischsprachigen Ausgabe auch komplett im WWW zur VerIgung.
Comer D.E.: Computernet:werle und Internets
Noch ein gutes Buch von Douglas Comer. Das Buch gibt eine sehr gute und umIassende Dar-
stellung aller wichtigen Themen im Bereich Netzwerke und Internets. Es geht dabei nicht
stark in die TieIe, sondern gibt eher einen ersten Einstieg in das Thema. Zu dem Buch gibt es
auch eine WWW-Seite, auI der weitere InIormationen zum Buch (insbesondere alle Abbil-
dungen und zahlreiche Animationen) vorhanden sind. Dem Buch ist eine Kopie der WWW-
Seiten als CD-ROM beigelegt.
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 Ir den Einsatz von IPv6 getroIIen werden mssen.
Neben allen wichtigen Erluterungen zum neuen Internet Protokoll wird Iast nebenher auch
ein geschichtlicher berblick ber die Entwicklung von IPv6 gegeben.
Hol:mann G.J.: Design and Validation of Computer Protocols
Seite 50
Dieses Buch ist eine sehr gute EinIhrung in (Computer)Protokolle, den EntwurI von Proto-
kollen und VeriIikation von Protokollen. Und das beste ist, dass das Buch vollstndig als
Postscript- oder PDF-Datei im Internet verIgbar ist!
Hunt C.: TCP/IP Networl Administration
Ein Buch, das die Grundlagen von TCP/IP bespricht und vor allem Ir die Administration von
TCP/IP Netzwerken in einer UNIX Umgebung gedacht ist. Neben einer Version, die sich spe-
ziell mit der Administration von TCP/IP-Netzwerken in UNIX-Umgebungen beIasst ist auch
eine Version Ir TCP/IP unter Windows verIgbar.
Hafner K., Lvon M.: ARPA KADABRA - Die Geschichte des Internet
Das Buch erzhlt die Geschichte des Internet und der Gruppe von WissenschaItlern, die ma-
geblich an der Entwicklung des Internet bzw. seines VorluIern beteiligt waren. Sehr kurzwei-
lig geschrieben und mehr eine Art Erzhlung als ein Sachbuch, aber dennoch eine hervorra-
gende sachliche Darstellung der Internet-Geschichte.
RFCs - Request for Comments
Ein RFC ist ein Papier, das sich in irgendeiner Form mit VerIahren, die im Internet verwendet
werden, beschItigt. Dabei kann es sich um einen Verbesserungsvorschlag oder eine Anmer-
kung Ir ein bestehendes VerIahren handeln oder einem Vorschlag zu einem neuen VerIahren.
Ein Vorschlag zu einem neuen VerIahren kann nach einiger Zeit (und PrIung) dann zu einem
Standard erklrt werden. Jedem vorgeschlagenen Standard wird eine Nummer zugeordnet. Die
Iolgende Liste gibt eine Reihe von RFCs wieder, die sich mit Themen des Vortrags bzw.
dieser Arbeit beIassen:
RFC768 - UDP
RFC783 - TFTP
RFC791 - IP
RFC792 - ICMP
RFC793 - TCP
RFC814 - Name, adresses, ports and routes
RFC821/2 - Mail
RFC825 - SpeciIication Ior RFC's
RFC826 - ARP
RFC854 - TELNET
RFC894 - A Standard Ior the Transmission oI IP Datagrams over Ethernet
RFC903 - RARP
RFC950 - Internet Standard Subnetting Procedure (Subnets)
RFC959 - FTP
RFC1009 - Requirements Ior Internet Gateways
RFC1011 - OIIicial Internet Protocols
RFC1013 - X Window System Protocol, Version 11 (Alpha Update)
Seite 51
RFC1032/3/4/5 - Domains (Domain Administration & Domain Names)
RFC1042 - Transmission oI IP Datagrams over IEEE 802 Networks
RFC1058 - Routing InIormation Protocol
RFC1112 - Host Extensions Ior IP Multicasting
RFC1117 - Internet numbers
RFC1118 - Hitchhikers guide to the Internet
RFC1180 - A TCP/IP Tutorial
RFC1208 - Networking glossary oI terms
RFC1310 - The Internet Standards Process
RFC1323 - TCP Extensions Ior High PerIormance
RFC1521 - MIME
RFC1550 - IPng White Paper Solicitation
RFC1597 - Address Allocation Ior Private Internets
RFC1700 - Assigned Numbers (Well-known Ports etc.)
RFC1752 - Recommedation Ior the IP Next Generation Protocol
RFC1825 - Security Architecture Ior 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 Ior Private Internets
RFC1972 - Transmission oI IPv6 Packets over Ethernet Networks
RFC2019 - Transmission oI IPv6 Packets over FDDI Networks
RFC2200 - Internet OIIicial Protocol Standards
5.2 LiteraturIiste
Im Gegensatz dazu, wie es bei wissenschaItlichen VerIIentlichungen blich ist, nenne ich in der
Literaturliste auch Quellen, die nicht unmittelbar im Text zitiert sind. Viele der hier angegebenen
Quellen habe ich zum Thema gelesen und indirekt Wissen aus ihnen in den Text einIlieen lassen.
Ich Iand es immer hilIreich einen berblick ber die Literatur zu einem Gebiet zu bekommen und
mchte deshalb eine Literaturliste mit einer Vielzahl hilIreicher Quellen angeben.
|Black1999| Black U.: Internet-Technologien der ZukunIt. Addison-Wesley,
Mnchen, 1999.
Seite 52
|ComerStevens1995| Comer D.E., Stevens D.L.: Internetworking with TCP/IP, Vol. I -
Priciples, Protocols and Internals. Prentice Hall, Englewood CliIIs, New
Jersey, 1995, 3rd ed.
|ComerStevens1994| Comer D.E., Stevens D.L.: Internetworking with TCP/IP, Vol. II -
Design, Implementation and Internals. Prentice Hall, Englewood CliIIs,
New Jersey, 1994, 2nd ed.
|ComerStevens1996| Comer D.E., Stevens D.L.: Internetworking with TCP/IP, Vol. III -
Client-Server Programming and Applications Ior the BSD Socket
Version. Prentice Hall, Englewood CliIIs, New Jersey, 1996, 2nd ed.
|Comer1998| Comer D.E.: Computernetzwerke und Internets. Prentice Hall,
Mnchen, 1998. http://www.netbook.cs.purdue.edu.
|Davidson1988| Davidson J.: Introduction to TCP/IP. Springer, New York, 1988
|DE-NIC| DE-NIC: Deutsches Network InIormation Center. http://www.nic.de/
|Deering1993| Deering S.E.: SIP - Simple Internet Protocol. IEEE Network Magazine,
Band 7, S. 16-28, Mai/Juni 1993.
|Francis1993| Francis P.: A Near-Termn Architecture Ior Deploying Pip. IEEE
Network Magazine, Band 7, S. 30-37, Mai/Juni 1993.
|Hasenstein1997| Hasenstein M.: IP Network Address Translation. Diplomarbeit an der
Technischen Universitt Chemnitz, 1997. Online verIgbar unter:
http://www.suse.de/~mha/HyperNews/get/linux-ip-net.html.
|HaInerLyon2000| HaIner K., Lyon M.: ARPA Kadabra - oder die Geschichte des Internet.
DPunkt-Verlag, Heidelberg, 2000, 2. AuIlage.
|Hartjes1997| Hartjes K., LIIler H., WessendorI G.: Fortsetzung Iolgt: Aktuelles zur
IPv6-EinIhrung. ix 4/97, S. 97II.
|Hedrick1987| Hedrick C.L.: Introduction to the Internet Protocols . Computer Science
Facilities Group, Rutgers The State University oI New Jersey, 1987.
|Hinden| Hinden R.: IP Next Generation (IPng).
http://playground.sun.com/pub/ipng/html/ipng-main.html.
|Holzmann1991| Holzmann G.J.: Design and Validation oI Computer Protocols. Prentice
Hall, Englewood CliIIs, New Jersey, 1991.
Im Internet unter: http://cm.bell-
labs.com/cm/cs/what/spin/Doc/Book91.html.
|HosenIeldBrauer1995| HosenIeld F., Brauer K.: Kommunikation ohne Grenzen: TCP/IP -
InIormationsbermittlung im Internet. c't 12/95, S. 330II.
|HosenIeld1996| HosenIeld F.: Next Generation - IPv6: ein neues
Kommunikationszeitalter.. c't 11/96, S. 380II.
|Huitema2000| Huitema, C.: IPv6 - die neue Generation, Architektur und
Implementierung. Addison Wesley, Mnchen, 2000.
Seite 53
|Hunt1995| Hunt C.: TCP/IP Network Administration. O'Reilly & Assoc.,
Sebastopol, CA, 1995
|KatzFord1993| 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.
|Khntopp1993a| Khntopp K.: Weltweit vernetzt - Struktur und Dienste des Internet. c't
2/93, S. 82II.
|Khntopp1993b| Khntopp K.: Einheitliche Sicht - Netzwerkprotokolle im Internet. c't
3/93, S. 232II.
|Krempl1998| Krempl S.: Das Internet bleibt spannend! Im Gesprch mit 'Internet-
Vater' Vinton G. CerI. c't 3/98. S. 44II.
|Kuri1996| Kuri J.: Wenn der Postmann zweimal klingelt - Namen und Adressen im
TCP/IP-Netzwerk und im Internet. c't 12/96, S. 334II.
|Kuri1997a| Kuri J.: Bhmische DrIer - Vom Kabel zum Netzwerk. c't 1/97, S.
245II.
|Kuri1997b| Kuri J.: Da geht's lang! - Routing, oder: wie die Daten im Internet ihren
Weg Iinden. c't 6/97, S. 380II.
|KuroseRoss2002| Kurose J.F., Ross K.W.: Computernetze, Ein Top-Down-Ansatz mit
Schwerpunkt Internet, Addison-Wesley, 2002.
Unter http://www.awl.com/kurose-ross steht das gesamte Buch online
zur VerIgung, ebenso weitere ergnzende Materialien.
|Kuschke1994| Kuschke M.: VervierIacht - IPv6: neue SpeziIikationen zur Lsung des
Adredilemmas. ix 10/94, S. 132II.
|MicrosoIt1998| MicrosoIt: Windows NT Server - Introduction to TCP/IP. White Paper,
MicrosoIt Corporation, Redmond, 1998. Online verIgbar unter:
http://www.microsoIt.com/NTServer/nts/techdetails/compares/TCPIntro
wp.asp.
|MicrsoIt2001| MicrosoIt: Introduction to IP Version 6. White Paper, MicrosoIt
Corporation, Redmond, 2001. Online verIgbar unter:
http://www.microsoIt.com/technet/network/ipvers6.aps.
|OberschelpVossen1995| Oberschelp W., Vossen G.: RechnerauIbau und Rechnerstrukturen.
Oldenbourg, Mnchen, 1995, 6. AuIlg.
|RFC| RFCs - Requests For Comments: Liste aller RFC http://www.RFC-
editor.org oder: http://internic.net/ds/RFC-index.txt oder:
Itp://Itp.nic.de/RFC/pub/doc/RFC
Es gibt aber noch viele andere Adressen, unter denen die RFCs zu
bekommen sind, auch als Zustellung per E-Mail.
|SantiIaller1998| SantiIaller M.: TCP/IP und ONC/NFS - Internetworking mit UNIX.
Addison Wesley, Bonn, Reding Massachucetts, 1998, 4. AuIlage.
Seite 54
|Schmidt1997a| Schmidt J.: Firewall getunnelt - Geheimer Datenaustausch ber ICMP-
Pakete. c't 11/97, S. 332II.
|Schmidt1997b| Schmidt J.: Falsche Fhrten - Mibrauchsmglichkeiten von ARP und
ICMP. c't 12/97, S. 246II.
|Sietmann2000| Sietmann R.: Mobilmachung - Internetprotokoll Version 6. iX 4/2000,
S. 100II.
|Stainov2000| Stainov, R.: IPnG - Das Internet-Protokoll der nchsten Generation.
Thomson Publishing, Bonn, 1997.
|Stallings1987| Stallings W.: Handbook oI Computer Communications Standards, Vol.
I: The Open Systems Interconnection (OSI) Model and OSI-Related
Standards. MacMillan Pub. Company, Indianapolis, 1987
|Stallings1988a| Stallings W.: Handbook oI Computer Communications Standards, Vol.
II: Local Network Standards. MacMillan Pub. Company, New York,
London, 1988
|Stallings1988b| Stallings W.: Handbook oI Computer Communications Standards, Vol.
III: Department oI DeIense (DoD) Protocol Standards. MacMillan Pub.
Company, New York, London, 1988
|Stevens1999a| Stevens R. W.: TCP/IP Illustrated, Vol. 1: The Protocols. Addison
Wesley, 1999, 14th ed.
|StevensWright1999b| Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 2: The
Implementation. Addison Wesley, 1999, 7th ed.
|StevensWright1999c| Stevens R. W., Wright G. R.: TCP/IP Illustrated, Vol. 3: TCP Ior
transactions, HTTP, NNTP, and the UNIX Domain protocols. Addison
Wesley, 1998, 4th ed.
|Tanenbaum1996| Tanenbaum A.S.: Computernetzwerke. Prentice Hall, Mnchen, 1997,
3. AuIlage.)
Zu dem Buch werden im WWW auch zustzliche InIormationen vom
Verlag unter
http://www.prenhall.com/divisions/ptr/tanenbaum/book.html und vom
Autor unter http://www.cs.vu.nl/~ast zur VerIgung gestellt.
|Weihrich1997| Weihrich T.: FiloIax Irs Internet - Der Domain Name Service von
TCP/IP. c't 10/97, S. 346II.
|WiN| WiN/DFN: IP Version 6 im WiN - Ein DFN Projekt.
http://www.join.uni-muenster.de.
5.3 Wichtige Organisationen
Internet Architecture Board - IAB (http://www.iab.org)
Das Internet Architecture Board (IAB) ist eine technische Beratungsgruppe der Internet Society,
die sich der organisatorisch-technischen Entwicklung des Internets widmet. Vom IAB werden die
gltigen Standards und Protokolle des Internets in so genannten RFCs verIIentlicht. Die beiden
Seite 55
wichtigsten Gremien des IAB sind die Internet Engineering Task Force (IETF) und die Internet
Research Task Force (IRTF).
Internet Society - ISOC (http://www.isoc.org)
Die Internet Society (ISOC) ist eine 1992 gegrndete NGO (Non Government Organization) Ir
die PIlege und Weiterentwicklung der InternetinIrastruktur und der Art, wie das Internet genutzt
wird. Neben sozialen, politischen und technischen Fragen beIasst sich die ISOC auch mit PR-
Arbeiten. Die ISOC beherbergt die Ir die Standards im Internet zustndigen Gremien Internet
Engineering Task Force (IETF) und Internet Architecture Board (IAB). Die ISOC ernennt die
Mitarbeiter des IAB, die vom Nominierungsausschuss der IETF vorgeschlagen werden.
Internet Engineering Task Force - IETF (http://www.ietf.org)
Die Internet Engineering Task Force (IETF) ist neben der Internet Research Task Force (IRTF)
eine von zwei Arbeitsgruppen des Internet Architecture Board (IAB). Sie ist eine oIIene,
internationale Vereinigung von Netzwerktechnikern, Herstellern und Anwendern, die Ir
Vorschlge zur Standardisierung des Internets zustndig ist und wurde 1986 gegrndet. Die IETF
gliedert sich in verschiedene Bereiche (Anwendungen (Applications), Internet-Dienste, IP Next
Generation (IPnG), Netzwerkmanagement, Betriebliche AnIorderungen (Operational
Requirements),. Routing, Sicherheit (Security), Transportdienste und Benutzerdienste (Transport
and User Services)). Jeder Bereich hat ein oder zwei Direktoren, die zusammen mit dem IETF-
Vorsitzendem bilden die Internet Engineering Steering Group (IESG). Die IESG ist verantwortlich
Ir das technische Management der IETF Aktivitten und Ir die Internet-Standards. Eine
detaillierte bersicht zur IETF ist in RFC 3160 The TAO of IETF zu Iinden.
Internet Research Task Force - IRTF (http://www.irtf.org)
Die Internet Research Task Force (IRTF) ist neben der Internet Engineering Task Force (IETF)
die zweite Arbeitsgruppe des Internet Architecture Board (IAB). Sie wurde 1998 gegrndet um die
Forschung und Entwicklung im Bereich der Netzwerke und deren Techniken zu Irdern. Sie besteht
aus Forschern im Bereich der Netzwerktechnik mit dem Schwerpunkt Internet. Die Internet
Research Steering Group (IRSG) leitet und koordiniert die Forschungsarbeiten der IRTF. Dabei
kommt es mitunter zu berschneidungen mit den Arbeiten der IETF. Auch bei den Mitgliedern der
Gruppen gibt es berschneidungen. hnlich wie die IETF ist die IRTF in Arbeits- bzw.
Forschungsgruppen organisiert, die sich mit unterschiedlichen Themen beIassen. Weitere
InIormationen sind in RFC 2014 Research Group Guidelines and Procedures zu Iinden.
Internet Assignes Numbers Authority - IANA (http://www.iana.org)
Die Internet Assigned Numbers Authority ( IANA) ist eine Organisation, die die Vergabe von IP-
Adressen, Top Level Domains und IP-Protokollnummern regelt. Die IANA delegiert die lokale
Registration von IP- Adressen an Regionale Internet-Registries (RIRs). Jede RIR ist Ir einen
bestimmten Teil der Welt verantwortlich, im einzelnen:
ARIN - American Registry Ior Internet Numbers (http://www.arin.net)
Seite 56
RIPE - Reseaux IP Europeens (http://www.ripe.net)
APNIC - Asia PaciIic Network InIormation Center (http://www.apnic.net)
LACNIC - Latin American and Caribbean Internet Address Registry (http://www.lacnic.net)
AIriNIC AIrican Internet Numbers Registry (http://www.aIrinic.net)
Die IANA verteilt IPv4-Adressen in groen Blcken (typischerweise /8 in CIDR-Notation), und die
RIRs Iolgen dann ihren eigenen Regelungen Ir die Zuweisung von Adressen an Endkunden (in
diesem Sinne Provider oder Organisationen, die ihre IP-Adressen selbst verwalten), wobei dann
meist /19er oder /20er Blcke zugeteilt werden. Die IANA ist auch Ir die Delegation und
Zuweisung von IPv6-Adressen zustndig Die IANA ist organisatorisch eine Unterabteilung der
Internet Corporation Ior Assigned Names and Numbers (ICANN) bzw. ist in der ICANN
auIgegangen.
Internet Corporation for Assigned Names and Numbers - ICANN (http://www.icann.org)
Die Internet Corporation for Assigned Names and Numbers (ICANN) verwaltet Namen und
Adressen im Internet und koordiniert somit technische Aspekte des Internet. Sie wird oIt auch, nicht
ohne Wertung, als eine Art ,Weltregierung des Internets bezeichnet. Die ICANN wurde im
Oktober 1998 von einem Zusammenschluss verschiedener Interessenverbnde (WirtschaIt, Technik,
WissenschaIt und Nutzer) gegrndet. Die ICANN hat die Verantwortung Ir eine Reihe technischer
Vorgaben, die zuvor von der IANA und verschiedenen anderen Gruppen getragen wurden. Das
Direktorium der ICANN besteht aus verschiedenen Mitgliedern aus aller Welt. Die ICANN
koordiniert:
Internet-Domain-Namen (Domain Name System, speziell die Root-Server),
IP-Adressen,
Protokoll-Parameter und Port-Adressen der Internet- Protokoll-Familie.
World Wide Web Consortium - W3C (http://www.w3c.org)
Das World Wide Web Consortium (W3C) wurde 1994 gegrndet und ist das Gremium, das
speziell die Weiterentwicklung technischer Standards des World Wide Web (WWW) koordiniert.
Grnder und Vorsitzender des W3C ist Tim Berners-Lee, der auch als ,ErIinder des World Wide
Web gilt. Beispiele Ir vom W3C mageblich entwickelte und verabschiedete Standards sind:
Hypertext Markup Language (HTML)
Extensible Markup Language (XML)
Extensible Hypertext Markup Language (XHTML)
Synchronized Multimedia Integration Language (SMIL)
Scalable Vector Graphics (SVG)
Mathematical Markup Language (MathML)
Portable Network Graphics (PNG)
Das W3C und seine Mitglieder beschItigen sich auch mit der Weiterentwicklung von Standards
Seite 57
oder mit der Entwicklung neuer Standards. Bei der Entwicklung neuer Standards hat sich das W3C
verpIlichtet, nur noch Technologien zu verwenden, die Irei von Patentgebhren sind.
Institute of Electrical and Electronics Engineers - IEEE (http://www.ieee.org)
Das Institute of Electrical and Electronics Engineers (IEEE - ,ei tripel ih) ist ein weltweiter
BeruIsverband von Ingenieuren aus den Bereichen Elektrotechnik und InIormatik. Das IEEE ist
Veranstalter von Fachtagungen und bildet Gremien Ir die Standardisierung von Technologien,
Hardware und SoItware. Das IEEE entstand am 1. Januar 1963 aus dem Zusammenschluss der
beiden amerikanischen Ingenieursverbnde American Institute oI Electrical Engineers (AIEE) und
Institute oI Radio Engineers (IRE). Wichtige IEEE-Standards sind u.a.
IEEE 488 (Bussystem Ir Peripheriegerte)
IEEE 754 (Fliekomma-Arithmetik-SpeziIikationen)
IEEE 802 (LAN/MAN)
IEEE 1284 (Parallele Schnittstelle)
IEEE 1003 (POSIX)
IEEE 1394 (FireWire)
IEEE 802.11 (Wireless LAN)
International Telecommunication Union - ITU (http://www.itu.org)
Der Status von TeleIongesellschaIten ist den verschiedenen Lndern der Welt uerst
unterschiedlich. HuIig haben Landesregierungen ein Monopol auI nahezu alle
Kommunikationsmedien (wie z.B. Post, Telegrammdienst, TeleIon, Radio und Fernsehen). In
einigen Fllen ist die Behrde, die Ir die Regelung der Telekommunikation zustndig ist, ein
staatliches Unternehmen, in anderen Fllen ist es direkt eine Regierungsorganisation. Es zeichnet
sich weltweit jedoch ein Trend ab, diese Monopolstellungen auIzuheben und den
Telekommunikationsbereich Ir private Unternehmen zu IInen. Angesichts der Vielzahl
verschiedener Betreiber und Anbieter liegt es nahe, Ir eine globale Kompatibilitt zu sorgen, damit
Menschen und technische Gerte in allen Lndern der Erde untereinander genutzt werden knnen.
Die International Telecommunication Union (ITU, frz: Union Internationale des
Tlcommunications, UIT) mit Sitz in GenI ist die Organisation, die sich oIIiziell und weltweit
mit technischen und rechtlichen Aspekten der Telekommunikation beschItigt. Die ITU geht zurck
auI den 1865 gegrndeten Internationalen Telegraphenverein. Heute ist sie eine Teilorganisation der
Vereinten Nationen (UNO). Die Ziele der ITU sind Abstimmung und Frderung der internationalen
Zusammenarbeit im Nachrichtenwesen. In ihrem Rahmen arbeiten Landesregierungen,
Unternehmen des privaten Sektors, sowie weitere regionale und nationale Organisationen
zusammen. Grundlage der ITU ist der Internationale Fernmeldevertrag, der AuIgaben, Rechte und
PIlichten der ITU-Organe Iestlegt. Wichtig ist Iestzuhalten, dass die EmpIehlungen der ITU nur als
EmpIehlungen zu betrachten sind, die von den einzelnen Landesregierungen angenommen oder
ignoriert werden knnen.
Seite 58
International Organization for Standardization - ISO (http://www.iso.org)
Die International Organization for Standardization (ISO, auch als International Standards
Organization bezeichnet), erarbeitet internationale Normen (engl. Standards) in so gut wie allen
Bereichen (Ausnahme ist z.B. der Bereich Elektrik und Elektronik, Ir den die International
Electrotechnical Commission) zustndig ist), wie z.B. technischen Standards (Normung von
Schrauben und Muttern, Leitungsbeschichtungen, DatenIormate), klassiIikatorischen Standards (die
berhmten Lndercodes Ir Domains .de, .nl, .jp etc.) und VerIahrensstandards (ISO9000
Qualittsmanagement). Die ISO wurde 1946 gegrndet und ist eine Ireiwillige, nicht per
Staatsvertrag geregelte Organisation. Mitglieder der ISO sind die nationalen Normungsinstitute der
jeweiligen Mitgliedslnder (z.B. ANSI (USA), BSI (Grobritannien), AFNOR (Frankreich)). Das
deutsche Institut Ir Normung e.V. ist seit 1951 Mitglied der ISO. In Bezug auI
Telekommunikationsstandards arbeitet die ISO eng mit der ITU zusammen.
Deutsches Institut fr Normung e.V. - DIN (http://www.din.de)
Das Deutsches Institut fr Normung e.V. (DIN) mit Sitz in Berlin ist die nationale
Normungsorganisation in Deutschland. Der Verein entwickelt in Zusammenarbeit mit Handel,
Industrie, WissenschaIt, Verbrauchern und Behrden technische Standards (Normen) zur
Rationalisierung und Qualittssicherung. Das DIN vertritt die deutschen Interessen in den
internationalen Normungsgremien (wie ISO und IEC). Durch die Festlegung der Normen soll
sichergestellt werden, dass die Inhalte und VerIahrenstechniken den allgemein anerkannten Regeln
der Technik entsprechen. Dem DIN angegliedert ist der Beuth-Verlag, der den Vertrieb der vom
DIN herausgegebenen Normen, Normen anderer Normungsstellen und auslndischer Normen
bernimmt. Gegrndet wurde das DIN 1917 als Normenausschuss der deutschen Industrie (NADI).
Die erste Norm (DIN 1 KegelstiIte) erschien im Jahr 1918. Seit 1920 ist das DIN ein eingetragener
Verein. 1926 wurde das DIN von Normenausschuss der deutschen Industrie in Deutscher
Normenausschuss (DNA) umbenannt. 1975 erIolgte schlielich die Umbenennung auI den heutigen
Namen im Rahmen eines Vertrages zwischen der Bundesregierung und dem Verein, der die
Zusammenarbeit zwischen beiden Iestlegt.
Seite 59

Tcpip

Hochgeladen von

Copyright:

Verfügbare Formate

Tcpip

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tcpip

Hochgeladen von

Copyright:

Verfügbare Formate

Einfhrung in

Das könnte Ihnen auch gefallen