IPv4 und IPv6 - Informatik 4

Rheinisch-Westfälische Technische Hochschule Aachen
Lehrstuhl für Informatik IV
Prof. Dr. rer. nat. Otto Spaniol
IPv4 und IPv6
Proseminar: Internetprotokolle für die
Multimediakommunikation
Michael Schmitz
Matrikelnummer: 234902
Betreuung:
Mesut Günes
Lehrstuhl für Informatik IV, RWTH Aachen

2 INHALTSVERZEICHNIS
Inhaltsverzeichnis
1 Einleitung 6
2 Grundlagen 7
2.1 Eine kurze Geschichte des Internets . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Klärung wichtiger Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Das ISO-OSI-Referenz und das TCP/IP-Schichtenmodell . . . . . . . . . . . . . . . 10
2.3.1 Das ISO-OSI-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 TCP/IP-Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Das Internet Protokoll 16
3.1 Das Internet Protokoll Version 4 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Allgemeines über IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 IPv4-Protokollkopfformat . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3 Optionen unter IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.4 Aufbau einer IPv4-Adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.5 Spezielle IPv4-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.6 Teilnetze und Teilnetzwerkmasken . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.7 Klassenlose Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.8 Fragmentierung von IP-Datagrammen . . . . . . . . . . . . . . . . . . . . . 29
3.1.9 Probleme und Schwächen des IPv4 . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Das Internet Protokoll Version 6 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Allgemeines über IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 IPv6-Protokollkopfformat . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 IPv6-Erweiterungsprotokollköpfe . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.4 Aufbau einer IPv6-Adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.5 Fragmentierung von IPv6-Datagrammen & Path MTU Discovery . . . . . . 42

INHALTSVERZEICHNIS 3
3.3 Wesentliche Unterschiede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Umstellung von IPv4 auf IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Zusammenfassung 47

4 ABBILDUNGSVERZEICHNIS
Abbildungsverzeichnis
1 APRANET-Wachstum : (a) Dezember 1969, (b) July 1970, (c) März 1971, (d) April
1971, (e) September 1972. [TA02] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 ISO-OSI-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Vergleich ISO-OSI-Referenzmodell und TCP/IP-Modell . . . . . . . . . . . . . . . 13
4 TCP/IP-Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Das IPv4-Paketformat:IP-Datagramm [RFC791] . . . . . . . . . . . . . . . . . . . 17
6 IPv4-Protokollkopfformat [RFC791] . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 Type of Service - Aufbau nach [RFC791] . . . . . . . . . . . . . . . . . . . . . . . 19
8 IPv4-Adressklassen [RFC791]: Klasse A, B, C, D, E . . . . . . . . . . . . . . . . . 23
9 IP-Adresszuweisung: Jedes Interface hat eine eindeutige Adresse . . . . . . . . . . . 24
10 Fragmentierung von IPv4-Datagrammen [RFC791] . . . . . . . . . . . . . . . . . . 29
11 Mehrmalige Fragmentierung von IPv4-Datagrammen [RFC791] . . . . . . . . . . . 30
12 Wachstum des Internets [isc.org]: Anzahl der Hosts von 1991 bis 2002 . . . . . . . . 31
13 Allgemeine Form eines IPv6-Pakets [RFC2460] . . . . . . . . . . . . . . . . . . . . 33
14 IPv6 Protokollkopfformat [RFC2460] . . . . . . . . . . . . . . . . . . . . . . . . . 33
15 Traffic Class - Aufbau nach RFC 2474 [RFC2474] . . . . . . . . . . . . . . . . . . . 34
16 Hop-by-Hop Options Extension Header [RFC2460] . . . . . . . . . . . . . . . . . . 35
17 Routing Extension Header [RFC2460] . . . . . . . . . . . . . . . . . . . . . . . . . 36
18 Fragment Extension Header [RFC2460] . . . . . . . . . . . . . . . . . . . . . . . . 36
19 Authentication Header [RFC2402] . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
20 Encapsulating Security Payload Erweiterungsprotokollkopf [RFC2406] . . . . . . . 38
21 Destination Options Extension Header [RFC2460] . . . . . . . . . . . . . . . . . . 39
22 Fragmentierung von IPv6-Datagrammen [RFC1981] . . . . . . . . . . . . . . . . . 44
23 Dual-Stacks: Mischbetrieb von IPv6 und IPv4 [ct1601] . . . . . . . . . . . . . . . . 46
24 IPv6 over IPv4: zwei IPv6-Hosts tauschen Daten über einen per Multicast aufgebauten
Tunnel durch das IPv4-Netz aus [ct1601] . . . . . . . . . . . . . . . . . . . . . 46

TABELLENVERZEICHNIS 5
Tabellenverzeichnis
1 Eine IPv4-Adresse in Punkt-Dezimal-Notation, gepunkteter hexadezimaler und in
binärer Schreibweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 Länge des Netzwerk- und Hostanteils und Maximale Anzahl der Netzwerke und
Hosts in der jeweiligen IPv4-Adressklasse . . . . . . . . . . . . . . . . . . . . . . . 24
3 Die IPv4-Standardnetzwerkmasken der Klasse A, B und C. . . . . . . . . . . . . . . 25
4 Drei Blöcke des IP-Adressraums sind für private Netzwerke reserviert. . . . . . . . . 26
5 Klassenlose Adressierung (CIDR): Aufteilung der verbliebenen Klasse C in vier Zonen 28
6 Eine IPv6-Adresse in binärer Schreibweise, in Punkt-Dezimal- und in Doppelpunkt-
Hexadezimal-Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Aufteilung des IPv6-Adressraumes [RFC2373] . . . . . . . . . . . . . . . . . . . . 42

6 1 EINLEITUNG
1 Einleitung
Das Internet, eine Sammlung von Teilnetzen, die miteinander verbunden sind und die ”
Welt zu einem
Dorf“ machen. Es gibt keine wirkliche Netzstruktur – das Rückgrat des Internets sind mehrere
größere Backbones. Diese Backbones werden aus schnellen Routern und Leitungen mit sehr hoher
Bandbreite gebildet. Netzwerke von Universitäten, Behörden, Service-Providern und Unternehmen
werden zu größeren regionalen Netzwerken zusammengeschlossen und sind an die Backbones angeschlossen.
Und genau dort braucht man ein Protokoll, welches die verschiedensten Netze zu einem
zusammenschließt. Das Internet Protokoll ist der Leim, der alles zusammenhält.
Jeder der sich mit Computer beschäftigt kennt es, jeder der schon einmal eine Verbindung mit dem
Internet hergestellt hat kommt nicht an ihm vorbei. Doch wer hat sich wirklich mit dem Internet Protokoll
beschäftigt Jeder kennt seine äußere Erscheinungsform: Die Adresse, wie etwa 194.95.176.70
oder gar schon 1234:5678:9ABC:DEF0:0123:4567:89AB:CDEF
Jeder weiß auch sicherlich über die ”
Adressenknappheit“ Bescheid und das ein neues Protokoll, das
IPv6 oder IPng, das alte IPv4 ablösen soll.
In dieser Ausarbeitung soll ein Einblick in diese zwei grundlegenden Protokolle des Internets ermöglicht
werden.

7
2 Grundlagen
2.1 Eine kurze Geschichte des Internets
Der Krieg ist der Vater aller Dinge“ (Zit. Heraklit)
”
Der kalte Krieg“ erlangte Ende der 1960er Jahre seinen Höhepunkt. Das US-Verteidigungsministerium
(Department of Defense - DoD) forderte eine Netzwerktechnologie, die in einem hohen Maß
”
gegenüber Ausfällen sicher ist. Das Netz sollte dazu in der Lage sein, auch im Falle eines Atomkrieges
weiter zu operieren. Eine Datenübermittlung über Telefonleitungen war zu diesem Zweck nicht geeignet,
da diese gegenüber Ausfällen zu verletzlich waren und auch heute noch sind. Aus diesem Grund
beauftragte das US-Verteidigungsministerium die Advanced Research Projects Agency (ARPA) mit
der Entwicklung einer zuverlässigen Netztechnologie. 1957 als Reaktion auf den Start des Sputniks
durch die UdSSR gegründet und hatte die ARPA die Aufgabe Technologien zu entwickeln, die für das
Militär von Nutzen sind. Zwischenzeitlich wurde die ARPA in Defense Advanced Research Projects
Agency (DARPA) umbenannt, da ihre Interessen primär militärischen Zwecken dienten. Die ARPA
war keine Organisation, die Wissenschaftler und Forscher beschäftigte, sondern verteilte Aufträge an
Universitäten und Forschungsinstitute.
Um die geforderte Zuverlässigkeit des Netzes zu erreichen, fiel die Wahl darauf, das Netz als ein
paketvermitteltes Netz (packet-switched network) zu gestalten. Bei der Paketvermittlung werden zwei
Partner während der Kommunikation nur virtuell miteinander verbunden. Die zu übertragenden Daten
werden vom Absender in Stücke variabler oder fester Länge zerlegt und über die virtuelle Verbindung
übertragen; vom Empfänger werden diese Stücke nach dem Eintreffen wieder zusammengesetzt.
Schon im Dezember 1969 wurde von der University of California Los Angeles (UCLA), der University
of California Santa Barbara (UCSB), dem Stanford Research Institute (SRI) und der University
of Utah (UTAH) ein experimentelles Netz, das ARPANET, mit vier Knoten in Betrieb genommen.
Diese vier Universitäten wurden von der ARPA gewählt, da sie bereits eine große Anzahl von ARPA-
Verträgen hatten. Abbildung 1 zeigt das schnelle Wachstum des ARPA-Netzes. Es überspannte bald
ein großes Gebiet der Vereinigten Staaten von Amerika. In der nächsten Zeit entstanden viele paketvermittelnde
Netzwerke mit zum Teil unterschiedlichen Architekturen. Jedes dieser Netzwerke hatte
sein eigenes Protokoll. Mit der Zeit und dem Wachstum des ARPANET wurde klar, dass die bis dahin
gewählten Protokolle nicht mehr für den Betrieb eines größeren Netzes, das auch mehrere (heterogene)
Teilnetze miteinander verband, geeignet war. Aus diesem Grund wurden schließlich weitere
Forschungsarbeiten initiiert.Die beiden Wissenschaftler Vinton Cerf und Robert Kahn erfanden ein
netzübergreifendes Protokoll namens ”
TCP/IP“ (Transmission Control Protocol / Internet Protocol).
Das TCP/IP-Protokoll wurde von Cerf und Kahn anfangs als ein Protokoll betrachtet, doch es wurde
später in seine heutigen zwei Teile zerlegt, dem ”
TCP“- und dem ”
IP“-Protokoll. Das IP-Protokoll
wird in dieser Ausarbeitung behandelt. Im Mai 1974 hatten Cerf und Kahn ihre erste Arbeit über
TCP/IP veröffentlicht. Zudem wurde auch das bekannte TCP/IP-Modell entwickelt, welches im Kapitel
2.3.2 behandelt wird. TCP/IP wurde mit der Zielsetzung entwickelt, mehrere heterogene Netze

8 2 GRUNDLAGEN
Abbildung 1: APRANET-Wachstum : (a) Dezember 1969, (b) July 1970, (c) März 1971, (d) April
1971, (e) September 1972. [TA02]
zur Datenübertragung miteinander zu verbinden. Vor allem sollte es eine breite Unterstützung für
künftige Anwendungen ermöglichen. Um die Einbindung der TCP/IP-Protokolle in das ARPANET
zu forcieren beauftragte die DARPA die Firma Bolt, Beranek & Newman (BBN) und die University
of California at Berkeley zur Integration von TCP/IP in Berkeley UNIX. Dies bildete auch den
Grundstein des Erfolges von TCP/IP in der UNIX-Welt.
Im Jahr 1983 wurde das ARPANET schließlich von der Defense Communications Agency (DCA),
welche die Verwaltung des ARPANET von der ARPA übernahm, aufgeteilt. Der militärische Teil des
ARPANET, wurde in ein separates Teilnetz, das MILNET abgetrennt, das durch streng kontrollierte
Gateways vom Rest des ARPANET - dem Forschungsteil - separiert wurde.
Nachdem TCP/IP das einzige offizielle Protokoll des ARPANET wurde, nahm die Zahl der angeschlossenen
Netze und Hosts rapide zu. Viele bestehende Netze wurden an das APRANET angeschlossen.
Das ARPANET wurde von Entwicklungen, die es selber hervorgebracht hatte, überrannt. Es existiert
in seiner ursprünglichen Form heute nicht mehr, das MILNET ist aber noch in Betrieb.

2.2 Klärung wichtiger Begriffe 9
Die Sammlung von Netzen, die das ARPANET darstellte, wurde zunehmend als Netzverbund betrachtet.
Dieser Netzverbund wird heute allgemein als das Internet bezeichnet und basiert immer noch auf
dem IP-Protokoll. Doch seitdem das Internet nicht mehr nur etwas für Wissenschaftler und Freaks
ist, ist es Anfang der 1990er vor allem mit der Erfindung des WorldWideWeb geradezu explodiert.
Jedes Jahr verdoppelte sich die Zahl der angeschlossenen Hosts. Jetzt ist man an einen Punkt angekommen,
wo das ”
gute, alte“ Internet Protokoll Version 4 langsam ausgedient hat und ein neues in
seine Fußstapfen treten soll: IPv6.
2.2 Klärung wichtiger Begriffe
Im Folgenden wird eine Terminologie eingeführt, wie sie u.a. in [RFC2460] benutzt wird. Weiterhin
werden noch grundlegende Begriffe definiert, die in dieser Ausarbeitung benutzt werden und die
nicht immer eindeutig sind. Nicht alle Bücher und Dokumente, besonders die ” Älteren“ verwenden
zwangsläufig diese Terminologie und entsprechend sind unter Umständen beim Lesen dieser Literatur
”
mentale Abbildungen“ notwendig. Zudem werden in dieser Ausarbeitung soweit möglich und
sinnvoll die deutschen Begriffe verwendet.
Protokoll: Protokolle sind Regeln, die den Nachrichtenaustausch – oder allgemeiner das Verhalten
– zwischen (Kommunikations)Partnern regeln ( ”
Protocols are formal rules of behaviour“).
Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie sogar
gänzlich unmöglich. Ein Beispiel für ein Protokoll ”
aus dem täglichen Leben“ ist z.B. der
Funkverkehr: Die Kommunikationspartner bestätigen den Empfang einer Nachricht mit ”
Roger“
und leiten einen Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindung
schließlich mit ”
Over and Out“.
Knoten: Ein Gerät welches ein Internet Protokoll (IPv4 und/oder IPv6) implementiert, heißt Knoten
(Node).
Router: Ein Knoten, der IP-Datagramme weiterleitet, die nicht explizit an ihn selbst adressiert sind,
heißt Router. Er ”
versucht“ Pakete in Richtung des Ziels weiterzuleiten, wobei man sich in der
Regel innerhalb eines logischen Netzes befindet und die Weiterleitung aufgrund einer Auswertung
der Adresse realisiert ist.
Host: Jeder Knoten, der kein Router ist, heißt Host.
Link: Ein Kommunikationskanal, über den Knoten miteinander kommunizieren können (z.B. das
Ethernet, PPP links, X.25 usw.), heißt Link.
Neighbors: Alle Knoten, die an demselben Link angeschlossen sind, heißen Neighbors (Nachbarn).
Interface: Die Schnittstelle, über die ein Knoten an einen Link angeschlossen ist, heißt Interface.

10 2 GRUNDLAGEN
IP-Adresse: Die IP-Adresse identifiziert ein Interface oder eine Menge von Interfaces.
Paket: Eine Bitfolge bestehend aus einem Protokollkopf (Header) und den Nutzdaten, heißt Paket.
IP-Datagramm: Ein Paketformat, das vom Internet Protokoll definiert ist, heißt IP-Datagramm. IP-
Datagramme sind also nichts anderes als in einem ”
TCP/IP-Netzwerk“ übertragene Pakete.
IP-Paket und IP-Datagramm sind äquivalent.
Link MTU: (link maximum transmission unit) Die maximale Paketgröße in Bytes (8 Bits) die auf
einem Link befördert werden kann, heißt Link MTU.
Path MTU: (path maximum transmission unit) Die minimale Link MTU aller Links zwischen einem
Quellknoten und einem Zielknoten, heißt Path MTU.
NAT: (Network Address Translation) NAT setzt IP-Adressen transparent in andere IP-Adressen um.
Hier wird der private Adressbereich im LAN auf eine öffentliche IP-Adresse (z.B. vom Provider
zugewiesen) umgesetzt und erlaubt so direkt auf Dienste außerhalb des LANs (z.B. des
Internets) zuzugreifen.
MAC-Adresse: (Media Access Control-Adresse) Die MAC-Adresse ist eine eindeutige und einmalig
vergebene Hardware-Adresse einer Komponente im Netz, die Datenpakete selbst generieren
kann (z.B. Netzwerkkarte).
MAC-Adressformat: 6 Byte in Hex-Code, getrennt durch Doppelpunkt. z.B. 00:80:63:01:A2:B3
DHCP: (Dynamic Host Configuration Protocol) Das DHCP dient dazu, Einstellungen in einem Netzwerk
zentral von einem Server aus zu vergeben, statt diese dezentral an den einzelnen Arbeitsplatzrechnern
zu konfigurieren. Ein mit DHCP konfigurierter Client verfügt selbst nicht über
statische Adressen, sondern konfiguriert sich voll und ganz selbstständig nach den Vorgaben
des DHCP-Servers.
DNS: Domain Name System. Das Internet verwendet zur Adressierung IP-Adressen, die maschinell
effizient verarbeitet werden können aber für Menschen nur schwer zu merken sind. Das Domain
Name System (DNS) ist der Unterbau, die nutzerfreundliche Namen in entsprechende Adressen
abbildet. So braucht man sich lediglich z.B. www.deutschland.de anstelle von 194.95.176.70 zu
merken.
2.3 Das ISO-OSI-Referenz und das TCP/IP-Schichtenmodell
2.3.1 Das ISO-OSI-Referenzmodell
1979 entwickelte die International Standards Organization (ISO) als Basis für eine internationale
Standardisierung der verschiedenen Protokolle ein Schichtenmodell. Es teilt die komplexe Aufgabe

2.3 Das ISO-OSI-Referenz und das TCP/IP-Schichtenmodell 11
der Kommunikation zwischen verschiedenen Rechnern in sieben Schichten auf. Dieses Modell wird
als OSI-Modell (Open Systems Interconnection) bezeichnet. Offiziell heißt dieses Modell ISO-OSI-
Referenzmodell. Abbildung 2 stellt dieses Modell dar.
Schicht
(Layer)
7
6
5
4
3
2
1
Anwendungssystem
Transportsystem
Host A
Anwendungsschicht
besteht aus den Anwendungen mit
denen man das Netzwerk nutzen kann
Darstellungsschicht
standardisiert das Format der Daten
auf dem Netzwerk
Sitzungsschicht
verwaltet die Verbindungen zwischen
den Anwendungen
Transportschicht
garantiert die fehlerfreie
Datenübertragung durch
Netzwerkschicht
verwaltet die Verbindungen zwischen
den Rechnern im Netzwerk für die
höheren Schichten
Sicherungsschicht
sorgt für die zuverlässige Übertragung
der Daten über die physikalischen
Verbindungen
Bitübertragungsschicht
definiert die physikalischen
Eigenschaften der Übertragungswege
(e)
(f)
(g)
( Transportsprotokoll)
Subnetz
Router A Router B
Bitübertragungsschicht
(j)
Netzwerkschicht
Protokolle
(Protocols)
(Anwendungsprotokoll)
( Darstellungsprotokoll)
( Sitzungsprotokoll)
(h)
(i)
Sicherungsschicht
Network
Layer
Data Link
Layer
Physical
Layer
Host B
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Application System
Transport System
phys. Medium
Medium
phys. Media
(e)
(f)
(g)
(h)
(i)
(j)
Host/Router-Netzwerkschichtprotokoll
Host/Router-Sicherungsschichtprotokoll
Host/Router-Bitübertragungsschichtprotokoll
Subnetzprotokoll
Subnetzprotokoll
Subnetzprotokoll
Abbildung 2: ISO-OSI-Referenzmodell
Jeder Schicht sind bestimmte, genau definierte Aufgaben zugeordnet. Die einzelnen Schichten werden
im Folgenden kurz beschrieben, wobei die Abbildung 2 fast schon selbsterklärend ist. Das Hauptaugenmerk
liegt aber auf der Netzwerkschicht (network layer), da dort das Internet Protokoll (IP)
einzuordnen ist.
Anwendungsschicht: (application layer) Die Anwendungsschicht enthält eine große Zahl häufig
benötigter Protokolle, die einzelne Programme zur Erbringung ihrer Dienste definiert haben.

12 2 GRUNDLAGEN
Darstellungsschicht: (presentation layer) Die Darstellungsschicht regelt die Darstellung der Übertragungsdaten
in einer von der darüber liegenden Ebene unabhängigen Form, indem sie die
Daten auf eine standardisierte und vereinbarte Weise kodiert.
Sitzungsschicht: (session layer) Die Sitzungsschicht ermöglicht den Verbindungsauf- und abbau.
Von der Sitzungsschicht wird der Austausch von Nachrichten auf der Transportverbindung geregelt.
Sitzungen können z.B. ermöglichen, ob der Transfer gleichzeitig in zwei oder nur eine
Richtung erfolgen kann. Kann der Transfer jeweils in nur eine Richtung stattfinden, regelt die
Sitzungsschicht, welcher der Kommunikationspartner jeweils an die Reihe kommt.
Transportschicht: (transport layer) Die Transportschicht übernimmt den Transport von Nachrichten
zwischen den Kommunikationspartnern. Die Transportschicht hat die grundlegende Aufgaben,
den Datenfluß zu steuern und die Unverfälschtheit der Daten sicherzustellen.
Netzwerkschicht: (network layer) Die Netzwerkschicht hat die Hauptaufgabe eine Verbindung zwischen
Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei die übergeordneten
Schichten von den Details der Datenübertragung über das Netzwerk befreien. Eine der wichtigsten
Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das Routing
von einem Quell- zu einem Zielhost. Die Routen können statisch sein, also sich nur selten
ändern oder hochdynamisch sein und für jedes Paket neu für eine optimale Netzauslastung neu
bestimmt werden. Die Streuung von Staus, die bei zu vielen Pakten in einem Teilnetz entstehen
können, ist auch Aufgabe der Vermittlungsschicht. Ein Problem ist es auch das ein Paket
unter Umständen mehrere Netze durchläuft welche die Paketgröße nicht annimmt. Dann muß
die Vermittlungsschicht dafür sorgen, dass das Paket fragmentiert und wieder defragmentiert
wird. Hingegen ist bei Broadcast-Netze das Routing-Problem einfach, und damit ist die ”
Vermittlungsschicht“
dort dünn oder gar nicht vorhanden.
Sicherungsschicht: (data link layer) Die Aufgabe der Sicherungsschicht ist die gesicherte Übertragung
von Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt und
sequentiell an den Empfänger gesendet. Vom Empfänger werden die empfangenen Daten durch
Bestätigungsrahmen quittiert.
Bitübertragungsschicht: (physical layer) Die Bitübertragungsschicht regelt die Übertragung 1 von
Bits über das Übertragungsmedium. Die Festlegungen auf der Bitübertragungsschicht betreffen
im wesentlichen die Eigenschaften des Übertragungsmedium.
2.3.2 TCP/IP-Schichtenmodell
Das TCP/IP-Schichtenmodell wird im Großvater aller Rechnernetze, dem APRANET und seinem
Nachfolger, dem Internet, eingesetzt [TA02] und wurde schon Mitte der 1970er 2 Jahre entwickelt.
1 Übertragungsgeschwindigkeit, Bit-Codierung, Anschluß, usw.
2 TCP/IP-Modell wurde vor dem ISO-OSI-Modell entwickelt.

2.3 Das ISO-OSI-Referenz und das TCP/IP-Schichtenmodell 13
Das Internet besteht ja bekanntlich aus vielen z.T. heterogenen Netzen. Es musste also eine neue Referenzarchitektur
gefunden werden, die die Fähigkeit hat, mehrere heterogene Netze nahtlos zusammenzuschließen.
Das bedeutet nichts anderes, als dass Daten eventuell zwischen unterschiedlichen
Rechnern mit unterschiedlichen Betriebssystemen, die sich in unterschiedlichen Netzwerktopologien
mit unterschiedlichen Protokollen befinden, ausgetauscht werden müssen. Das von Cerf und Kahn
entwickelte TCP/IP-Protokoll kann die ”
Verbindung“ zwischen heterogenen Netzwerke herstellen.
Ein neues Referenzmodell war entstanden, welches im Gegensatz zu dem ISO-OSI-Referenzmodell
eine Beschreibung der Protokolle ist.
Die Ähnlichkeiten zwischen den beiden Modellen zeigt Abbildung 3. Die verschiedenen Anforderungen
führten letztendlich zu der Wahl eines paketvermittelten Netzes auf der Grundlage einer verbindungslosen
Vernetzungsschicht. Die einzelnen Schichten werden im Folgenden kurz beschrieben.
Application Layer
Presentation Layer
Application Layer
Session Layer
Host-to-Host Transport Layer
Transport Layer
Internet Layer
Network Layer
Network Access Layer
Data Link Layer
TCP/IP-Modell
Physical Layer
ISO/OSI-Referenzmodell
Abbildung 3: Vergleich ISO-OSI-Referenzmodell und TCP/IP-Modell
Abbildung 4 zeigt das vierschichtige TCP/IP-Modell. Das Hauptaugenmerk liegt wieder auf der Internetschicht
(internet layer), da dort das Internet Protokoll definiert ist.
Anwendungsschicht: (application layer) Die Anwendungsschicht umfaßt alle höherschichtigen Protokolle
des TCP/IP-Modells. Zu den ersten Protokollen der Anwendungsschicht zählten FTP,
TELNET und SMTP. Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitere
Protokolle wie z.B. DNS und HTTP hinzu.
Transportschicht: (transport layer) Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation
zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser
Schicht zwei Ende-zu-Ende-Protokolle definiert: das Transmission Control Protocol (TCP) und
das User Datagram Protocol (UDP).

14 2 GRUNDLAGEN
Schicht
(Layer)
4
3
2
Host A
Anwendungsschicht
enthält Anwendungen und Prozesse,
die auf das Netzwerk zugreifen
Transportschicht
stellt End-to-End-Datendienste zur
Verfügung
Internetschicht
definiert den Aufbau von
Datagrammen und routet Daten
(c)
Router A
Internetschicht
Protokolle
(Protocols)
(a)
(b)
Subnetz
Router B
Internet
Layer
Host B
Application Layer
Host-to-Host
Transport Layer
Internet Layer
1
Netzwerkzugriffsschicht
enthält Routinen für den Zugriff auf
physikalische Netze
(d)
Netzwerkschicht
Network
Layer
Network Access
Layer
phys. Medium
Medium
phys. Media
(a)
(b)
(c)
(d)
Anwendungsschichtprotokoll (FTP, TELNET,...)
TCP (Transmission Transport Protocol)
UDP (User Datagram Protocol)
Internet Protocol
Netzwerkzugriffsschichtprotokoll
Abbildung 4: TCP/IP-Schichtenmodell
Internetschicht: (internet layer) Die Internetschicht definiert nur ein Protokoll, das Internet Protokoll
(IP - Internet Protocol) [RFC791, RFC2460], das alle am Netzwerk beteiligten Rechner
verstehen können. Wie schon erwähnt ist sie eine verbindungslose Vernetzungsschicht“,
”
welche wie die Sicherheitsnadel, die die gesamte Architekur zusammenhält“[TA02] ist. Die
”
Internetschicht hat die Aufgabe IP-Datagramme richtig und unabhängig vom jeweiligen Netz
zuzustellen.
In [TA02] wird eine Analogie zur Internetschicht beschrieben:
Eine Analogie dazu wäre die gelbe Post. Eine Person wirft eine Reihe von Auslandsbriefen in
”
einem Land in einen Briefkasten, und mit ein wenig Glück werden die meisten an die richtige
Adresse im Zielland zugestellt. Die Briefe bereisen wahrscheinlich eine oder mehrere internationale
Sammelstellen (Gateways) auf ihrem Weg, was für den Benutzer allerdings transparent
ist. Dass jedes Land (d.h. Netz) seine eigenen Briefmarken, bevorzugte Umschlagsformate und
Zustellungsregeln hat, ist dem Benutzer auch egal.“
Das Routing der Pakete spielt eine wichtige Rolle, ebenso das Vermeiden von Überlastungen.
Das Internet Control Message Protocol (ICMP) [RFC792, RFC2463] ist fester Bestandteil jeder
IP-Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das
Internet Protokoll.
Netzwerkzugriffsschicht: (network access layer) Unterhalb der Internetschicht befindet sich im

2.3 Das ISO-OSI-Referenz und das TCP/IP-Schichtenmodell 15
TCP/IP-Modell eine große Definitionslücke. Aber sie beinhaltet sehr hardwarenahe Dienste,
z.B. Netzwerkkartentreiber. Das Referenzmodell sagt auf dieser Ebene nicht viel darüber 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 muß. Dieses Protokoll ist im
TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das
TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen,
wie z.B. dem Ethernet (IEEE 802.3).

16 3 DAS INTERNET PROTOKOLL
3 Das Internet Protokoll
In der Einleitung wurde die Behauptung aufgestellt, dass das Internet Protokoll der Leim ist, der
das Internet zusammenhält. Fakt ist, dass das aktuelle Internet Protokoll (IPv4) seit Jahrzehnten erfolgreich
im Einsatz ist. Dem Internet Protokoll ist es zu verdanken, dass das Internet so erfolgreich
wurde. Denn selbst einschneidende Änderungen von Hardwaretechnologien und der Internet-Boom
in den 1990ern und vor allem die Fähigkeit heterogene Netzwerke zusammenzuschließen hat das Internet
Protokoll souverän gemeistert. Die Heterogenität ist es auch, was das Internet heute ausmacht.
Das Internet Protokoll wurde von Anfang an mit Blick auf Netzverbund ausgelegt. Es definiert ein
einheitliches Paketformat und einen Pakettransfermechanismus um Daten über heterogene Netzwerke
zu übertragen. Dabei benutzt es sogenannte IP-Adressen, welche unabhängig vom jeweiligen Netzwerk
sind, und über denen es Anwendungen und Protokolle höheren Schichten des TCP/IP-Modells
möglich ist, selbst über heterogene Netzwerke miteinander zu kommunizieren. In diesem Kapitel
wird das Internet Protokoll Version 4 (IPv4) und sein Nachfolger das Internet Protokoll Version 6
(IPv6) dargestellt und beschrieben. Das IPv4 wird nicht durch IPv5 ersetzt, weil die Versionnummer
5 schon an ein experimentelles Protokoll vergeben war. Das IPv5 war an ein Protokoll für Echtzeit-
Ströme, das ST-2 (Internet Stream Protocol Version 2) hieß und von RSVP (ReSerVation Protocol
zur Bandbreitenanforderung bei Routern) abgelöst wurde, vergeben. ST-2 sollte einst Audio- und Videosignale
per Multicast übertragen können und die Bandbreiten-Reservierungsvorteile von ATM in
IP-Netze bringen, gelang aber nie zur Serienreife.
3.1 Das Internet Protokoll Version 4 - IPv4
3.1.1 Allgemeines über IPv4
Das Internet Protokoll Version 4 (IPv4) wurde in den 1970er spezifiziert und im Jahr 1981 in [RFC791]
standardisiert und ist die Basis des heutigen Internets. Die Spezifikation wurde in vielen Punkten im
Lauf der Zeit den Erfordernissen angepasst.
Das Internet Protokoll empfängt von der Transportschicht im sendenden Host ein Segment, verkapselt
jenes in ein bestimmtes Paketformat, dem IP-Datagramm, und sendet es an den ersten Router
auf den Pfad zum Zielhost. Die Menge an Nutzdaten in einem IP-Datagramm ist nicht zwingend vorgeschrieben.
Jedoch kann ein IP-Datagramm maximal 64 Kbyte groß sein. Der prinzipielle Aufbau
eines IP-Datagramm respektive des IP-Paketes wird in Abbildung 5 gezeigt.
Das Internet Protokoll ist ein verbindungsloses Protokoll, d.h. zur Datenübertragung wird keine
Ende-zu-Ende Verbindung der Kommunikationspartner etabliert. Eine Ende-zu-Ende Verbindung bedeutet,
dass es eine Verbindung direkt von einer Anwendung eines Quellhosts zu einer Anwendung
eines Zielhosts gibt; w.z.B. bei TCP. Das heißt im Umkehrschluss, dass jeder Router, der das IP-
Datagramm empfängt, den Protokollkopf auslesen muss, bevor er es weitersenden kann. Das Internet

3.1 Das Internet Protokoll Version 4 - IPv4 17
IPv4 Protokollkopf
ggf. mit Optionen
20 - 60 Bytes
Daten
Abbildung 5: Das IPv4-Paketformat:IP-Datagramm [RFC791]
Protokoll implementiert zwei Basisfunktionen: Adressierung und Fragmentierung. Die Adressierung
geschieht mit Hilfe der IP-Adresse. Das Kapitel 3.1.4 behandelt ausführlich die IPv4-Adresse. Die
IP-Adresse wird im IP-Protokollkopf geführt und dient der Übertragung eines IP-Datagrammes von
einem Quellhost zu einem Zielhost. Die Auswahl des Pfades für die Übermittlung heißt routing. Das
IP-Datagramm kann fragmentiert werden, wenn es für die Übermittlung nötig ist. Die Fragmentierung
wird in Kapitel 3.1.8 behandelt. Die Aufgabe des Internet Protokolls ist also die Bereitstellung
einer Möglichkeit IP-Datagramme von einem Quellhost zu einem Zielhost zu befördern. Dabei ist
es unerheblich, ob sich der Quellhost und der Zielhost im gleichen Netz befinden oder ob andere
(heterogene) Netze dazwischenliegen. Router übernehmen die Aufgabe der Auswahl des Pfades für
die Übermittlung. Jeder Router leitet das IP-Datagramm weiter, indem er die ausgelesene Zieladresse
mit einer Routing-Tabelle indiziert und das IP-Datagramm in Richtung des Zielhosts weiterleitet.
Da diese Routing-Tabellen jederzeit modifiziert werden können, kann es vorkommen, dass die IP-
Datagramme, die von einem Quellhost zu einem Zielhost gesendet werden, unterschiedliche Routen
durch das Netzwerk nehmen und möglicherweise außer der Reihenfolge ankommen [KK02]. IP bietet
zur Übertragung nur den sogenannten ”
Best-Effort“-Dienst an, d.h. das Internet Protokoll garantiert
nicht, dass die IP-Datagramme in einer bestimmten Zeit, in der richtigen Reihenfolge oder gar
überhaupt am Zielhost ankommen. Es verfügt auch über keine Mechanismen zur Fehlererkennung
und -behebung, außer einer Protokollkopf-Prüfsumme und dem ”
Internet Control Message Protocol“
(ICMP) [RFC792], welches fest mit dem Internet Protokoll verbunden ist. Aufgrund diesen Mangels
nennt man das Internet Protokoll auch ein ”
unzuverlässiges“ Protokoll.
3.1.2 IPv4-Protokollkopfformat
Abbildung 6 zeigt das Protokollkopfformat eines IPv4-Datengramms [RFC791].
Version: 4 Bits
Das Feld Version enthält die Versionsnummer des IP-Protokolls. Der Wert ist 4. Der eigentliche
Sinn dieses Feldes ist, dass der Übergang zwischen den Versionen Monate oder Jahre dauern
kann, wobei einige Maschinen mit der alten Version, andere mit der neuen Version laufen.

18 3 DAS INTERNET PROTOKOLL
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Version IHL Type of Service Total Length
Identification Flags Fragment Offset
Time To Live Protocol Header Checksum
Source Address
Destination Address
Options
Padding
IHL - Internet Header Length
Abbildung 6: IPv4-Protokollkopfformat [RFC791]
Internet Header Length: 4 Bits
Das Feld Internet Header Length - IHL enthält die Länge des gesamten IP-Protokollkopfes in
32-Bit Wörtern, da diese nicht konstant ist. Der fixe Teil des Protokollkopfes ist 20 Bytes 3 . In
diesem Fall sind im Protokollkopf keine Optionen gesetzt. Die maximale Länge des Protokollkopfes
inklusive Optionen ist 60 Bytes 4 , also kann man 40 Bytes an Optionen setzen.
Type of Service: 8 Bits
Die Interpretation des Type of Service (TOS) Felds hat sich im Lauf der Zeit verändert. Nach
der aktuellen Interpretation enthält das TOS-Byte einen Differentiated Services Code Point
(DSCP) sowie Bits zur expliziten Benachrichtigung über Stausituationen (explicit congestion
notification, ECN). Die Spezifikation der aktuellsten ”
Version“ wird im Feld Traffic Class im
IPv6 [RFC2460] benutzt.
Der Aufbau des Type of Service-Feldes nach [RFC791] :
Das Feld Type of Service bestimmt die Art des Dienstes und ist in Abbildung 7 aufgeführt. Hier
sind verschiedene Kombinationen aus Zuverlässigkeit, Verzögerung und Durchsatz möglich. In
der Praxis wurde dieses Feld aber ignoriert.
Precedence: (Priorität) (Bits 0 - 2) Mit Precedence wird dem IP-Datagramm eine Priorität von
0 (normal) bis 7 (Netzsteuerungspaket) zugewiesen.
Delay: (Verzögerung) (Bit 3)
0 Normal Delay (Normale Verzögerung)
1 Low Delay (Niedrige Verzögerung)
3 Der kleinste zulässige Wert dieses Feldes ist also 5
4 Der maximale Wert dieses Feldes ist somit 15

3.1 Das Internet Protokoll Version 4 - IPv4 19
0 1 2 3 4 5 6 7
Precedence D T R Res
D - Delay
T - Throughput
R - Relibility
Abbildung 7: Type of Service - Aufbau nach [RFC791]
Throughput: (Durchsatz) (Bit 4)
0 Normal Throughput (Normaler Durchsatz)
1 High Throughput (Hoher Durchsatz)
Relibility: (Zuverlässigkeit) (Bit 5)
0 Normal Relibility (Normale Zuverlässigkeit)
1 High Relibility (Hohe Zuverlässigkeit)
Res: Bits 6 - 7 müssen Null sein und sind für die Zukunft reserviert.
Der Aufbau des Type of Service-Feldes nach [RFC2474]:
Die aktuelle Spezifikation ging in die IPv6-Spezifikation ein und ist im Kapitel 3.2.2 auf Seite
33 beschrieben.
Total Length: 16 Bits
Das Feld Total Length enthält die gesamte Länge eines IP-Datagramms, d.h. inklusive Protokollkopf
und Nutzdaten. Die Maximallänge eines IP-Datagramms ist auf 65.535 Bytes begrenzt.
Jeder Host muss in der Lage sein, IP-Datagramme bis zu einer Länge von 576 Bytes
zu verarbeiten [RFC791]. In der Regel können vom Host aber IP-Datagramme größerer Länge
verarbeitet werden.
Identification: 16 Bits
Das Feld Identification enthält einen Identifizierungswert, welcher vom Sender gesetzt wird,
um zu helfen die Fragmente eines IP-Datagrammes wieder zusammenzusetzen. Alle Fragmente
eines IP-Datagrammes enthalten somit die gleiche Identifikationsnummer.
Flags: 3 Bits
Das erste Bit des Feldes Flags ist ungenutzt und muss Null sein. Die beiden andern Bits DF und
MF steuern die Behandlung eines IP-Datagramms im Falle einer Fragmentierung. Mit dem DF-
Bit wird angezeigt, daß das IP-Datagramm nicht fragmentiert werden darf. DF kann den Wert 0
haben, d.h. ”
May Fragment“ Kann fragmentiert werden oder den Wert 1, d.h. ”
Don’t Fragment“
Darf nicht fragmentiert werden. Mit dem MF-Bit wird angezeigt, ob einem IP-Datagramm

20 3 DAS INTERNET PROTOKOLL
weitere Teil-IP-Datagramme nachfolgen. Dieses Bit ist nur bei dem letzten Fragment gesetzt.
Die Fragmentierung wird MF kann den Wert 0, d.h. Last Fragment Letztes Fragment oder 1,
d.h. More Fragments Mehr Fragmente haben.
Die Fragmentierung wird in Kapitel 3.1.8 ausführlich beschrieben.
Fragment Offset: 13 Bits
Das Feld Fragment Offset zeigt an, an welcher Stelle relativ zum Beginn des gesamten IP-
Datagramms ein Fragment gehört. Es können maximal 8192 Fragmente pro IP-Datagramm erstellt
werden, da die Feldgröße nur 13 Bits lang ist. Alle Fragmente, außer dem letzten, müssen
ein Vielfaches von 8 Byte (64 Bits) sein. (Kap. 3.1.8)
Time to Live: 8 Bits
Das Feld Time to Live - TTL zeigt die maximale Lebensdauer des IP-Datagramms an. Es ist eine
Art Zähler, der bei jeder Verarbeitung des Protokollkopfes um mindestens 1 verringert wird. Die
Einheit dieses Feldes ist die Sekunde. Der maximale Wert ist 255 (8 Bit). Sobald der Wert 0 ist,
wird das IP-Datagramm verworfen, damit wird verhindert, dass ein IP-Datagramm endlos in
einem Netz umherwandert. Der Absender wird in einem solchen Fall durch eine Warnmeldung
in Form einer ICMP-Nachricht [RFC792] informiert. Bei einer längeren Zwischenspeicherung
soll der Wert sogar mehrmals verringert werden.
Protocol: 8 Bits
Das Feld Protocol enthält die Nummer des Transportprotokolls, an welches das IP-Datagramm
weitergeleitet werden muss. Die Numerierung von Protokollen ist im gesamten Internet einheitlich
und in [RFC1700] definiert.
Header Checksum 16 Bits
Das Feld Header Checksum enthält die Prüfsumme der Felder im Protokollkopf. Die Nutzdaten
des IP-Datagramm werden aus Effizienzgründen nicht mit geprüft. Die Prüfsumme muss
bei jeder Verarbeitung des Protokollkopfes neu berechnet werden, da sich der Protokollkopf
durch das Feld Time to Live verändert. Aus diesem Grund ist auch eine sehr effiziente Bildung
der Prüfsumme wichtig. Als Prüfsumme wird das 1er-Komplement der Summe aller 16-
Bit-Halbwörter der zu überprüfenden Daten verwendet. Zum Zweck dieses Algorithmus wird
angenommen, dass die Prüfsumme zu Beginn der Berechnung Null ist.
Source Address: 32 Bits
In dem Feld Source Address wird die 32 Bit lange Quelladresse eingetragen, von der das IP-
Datagramm gesendet wird. Die 32 Bit-Adresse wird ausführlich im Kapitel 3.1.4 auf Seite 22
behandelt.
Destination Address: 32 Bits
In dem Feld Destination Address wird die 32 Bit lange Zieladresse eingetragen, an die das IP-
Datagramm gesendet wird. Die 32 bit-Adresse wird ausführlich im Kapitel 3.1.4 auf Seite 22
behandelt.

3.1 Das Internet Protokoll Version 4 - IPv4 21
Options: variable Anzahl von Bits.
Das Feld Options wurde im Protokollkopf aufgenommen, um die Möglichkeit zu bieten das IP-
Protokoll um weitere Informationen zu ergänzen, die im ursprünglichen Design nicht berücksichtigt
wurden. Die maximale Größe dieses Feldes ist 40 Bytes.
3.1.3 Optionen unter IPv4
Praktisch sind die meisten Optionen von geringer Bedeutung, da der verfügbare Platz von 40 Byte
für die meisten Optionen in der Regel zu klein ist. Jede Option beginnt mit einem Code von einem
Byte, über den die Option identifiziert wird. Manchen Optionen folgt ein weiteres Optionsfeld von 1
Byte und dann ein oder mehrere Datenbytes für die Option. Das Feld Options wird über das Padding
auf ein Vielfaches von 4 Byte aufgefüllt. Im Folgenden werden kurz neun der bekanntesten Optionen
angeschnitten, die genauen Spezifikationen sind in größtenteils in [RFC791] beschrieben:
1. NOP (No Option): Keine Operation. Eine 1 Byte Option, die typischerweise zum Füllen eingesetzt
wird, um eine spätere Option auf eine 4 Byte Begrenzung zu setzen.
2. EOL (End of Option List): Ende der Liste. Eine 1 Byte Option, die die Optionsverarbeitung
beendet.
3. LSRR (Loose Source and Record Route): Lose Quell- und Record-Route. Diese Option enthält
eine Liste von Internet-Adressen, die das IP-Datagramm durchlaufen soll. Auf diese Weise
kann dem IP-Datagramm vorgeschrieben werden eine bestimmte Route durch das Internet zu
nehmen. Die angegebenen Router dürfen nicht umgangen werden. Auf dem Weg können aber
auch andere Router besucht werden.
4. SSRR (Strict Source and Record Route): Strikte Quell- und Record-Route. Diese Option enthält
eine Liste von Internet-Adressen, die das IP-Datagramm durchlaufen soll. Auf diese Weise kann
dem IP-Datagramm vorgeschrieben werden eine bestimmte Route durch das Internet zu nehmen.
Das IP-Datagramm muss diese Route genau einhalten. Des Weiteren wird die genommene
Route aufgezeichnet.
5. Record-Route: Routenaufzeichnung. Die Knoten, die dieses IP-Datagramm durchläuft, werden
angewiesen ihre IP-Adresse an das Optionsfeld anzuhängen. Damit läßt sich ermitteln, welche
Route ein IP-Datagrammenommen hat. Wie anfangs schon gesagt, ist die Größe für das Optionsfeld
auf 40 Byte beschränkt. Deshalb kommt es heute auch oftmals zu Problemen mit dieser
Option, da weit mehr Router durchlaufen werden, als dies zu Beginn des ARPANET der Fall
war.

22 3 DAS INTERNET PROTOKOLL
6. Time Stamp: Zeitstempel. Diese Option ist mit der Option ”
Record Route“ vergleichbar. Zusätzlich
zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten vermerkt.
Auch diese Option dient hauptsächlich zur Fehlerbehandlung, wobei zusätzlich z.B.
Verzögerungen auf den Netzstrecken erfasst werden können.
7. Security: Sicherheit. Diese Option zeigt, wie geheim ein IP-Datagramm ist. In der Praxis wird
diese Option jedoch von fast allen Routern ignoriert.
8. Stream Identifier: Diese Option trägt die Stream-Identifizierung, ist aber schon sehr veraltet.
9. Router-Alert: Router-Alarm. Diese Option ist nicht in [RFC791] sondern in [RFC2113] beschrieben.
IP-Datagramme, die diese Option eingebunden haben, sollen von allen Routern untersucht
werden, die dieses IP-Datagramm weiterleiten.
3.1.4 Aufbau einer IPv4-Adresse
Die IPv4-Adresse hat eine Länge von 32-Bit 5 . Eine 32-Bit-Adressierung lässt 2 32 = 4.294.967.296
mögliche Adressen zu. Sie wird normalerweise nicht als Binärzahl oder Hexadezimalzahl, sondern in
gepunktenen Dezimalzahlen geschrieben. In dieser Punkt-Dezimal-Notation (Dotted Decimal Notation)
werden alle 8 Bit dezimal geschrieben, und mit Punkten getrennt. Das IPv4-Adressenformat sieht
dann folgendermaßen aus: ∗.∗.∗.∗ wobei ∗ eine dezimale Zahl zwischen 0 und 255 ist.
Tabelle 1 zeigt ein Beispiel für verschiedene Schreibweisen ein und derselben Adresse. Aus dieser
Schreibweise Adresse
binäre Schreibweise 11000010 01011111 10110000 01000110
gepunktete hexadezimale C2.5F.B0.46
Punkt-Dezimal 194.95.176.70
Tabelle 1: Eine IPv4-Adresse in Punkt-Dezimal-Notation, gepunkteter hexadezimaler und in binärer
Schreibweise
Tabelle ist ersichtlich, dass die Punkt-Dezimal-Notation eine 32-Bit-Binärzahl in ein für den Menschen
verständlicheres Format abbildet. Der Computer benutzt normalerweise die duale Darstellung.
Das ursprüngliche Schema, das als klassenbezogene Adressierung (Classful Addressing) bezeichnet
wird, teilt den IP-Adressraum in drei primäre Klassen (Klasse A, B und C) ein. Insgesamt gibt es aber
fünf Netzwerkklassen: Klasse A, B, C, D und E. Die klassenbezogenen IP-Adressen sind selbstidentifizierend,
da sich die Netzwerkklasse aus der IP-Adresse selbst berechnen lässt. Die Unterscheidung
der einzelnen Netzwerkklassen findet in den ersten vier Bit der Adresse statt. Eine IP-Adresse der
5 4 Byte

3.1 Das Internet Protokoll Version 4 - IPv4 23
Klasse A, B und C wird in ein Netzwerk- und in ein Hostanteil gegliedert. In welchem Bit diese
Gliederung stattfindet, legt die jeweilige Klasse fest.
Der Netzwerkanteil identifiziert das physische Netzwerk, in dem sich ein Host befindet: alle Hosts
eines Netzes haben die gleiche Netzwerkadresse. Der Hostanteil identifiziert einen bestimmten Host
innerhalb eines Netzes.
Abbildung 8 zeigt die fünf Adressklassen jeweils mit dem Hostbereich in Punkt-Dezimal-Notation.
Die Netzwerkanteile der jeweiligen Adressklassen sind mit Netz und die Hostanteile mit Host gekennzeichnet.
Klasse
A 0
Netz
Host
Host-Adressbereich
1.0.0.0 bis
127.255.255.255
128.0.0.0 bis
191.255.255.255
192.0.0.0 bis
223.255.255.255
224.0.0.0 bis
239.255.255.255
240.0.0.0 bis
255.255.255.255
B 10
Netz
Host
C 110
Netz
Host
D 1110
Multicast-Adresse
E 1111
Für künftige Nutzung reserviert
Abbildung 8: IPv4-Adressklassen [RFC791]: Klasse A, B, C, D, E
Einer Firma, die z.B. 200 Hosts adressieren will, wird ein Klasse C Netz zugeteilt. In der Form ∗.∗.∗.0
bis ∗. ∗ . ∗ .255.
Eine Universität mit 80.000 Hosts würde ein Netz der Klasse A, der Form ∗.0.0.0 bis ∗.255.255.255,
für sich beanspruchen.
Klasse D-Adressen sind sogenannte Multicast-Adressen. Sie werden dazu verwendet ein IP-Datagramm
an mehrere Hostadressen gleichzeitig zu versenden. Sendet ein Prozeß eine Nachricht an eine Adresse
der Klasse D, wird die Nachricht an alle Mitglieder der adressierten Gruppe versendet. Dies geschieht
mit einem eigenen Protokoll, dem Internet Group Management Protocol (IGMP) und ist ausführlich
in [RFC2236] beschrieben.
In der Literatur wird der weitere Bereich der IP-Adressen Klasse E bezeichnet [CO02]. Dieser Bereich
ist für zukünftige Nutzungen reserviert und z.Z. ungenutzt.
Die Anzahl der Netze bzw. Hosts der jeweiligen Klasse in Tabelle 2 sind rein ”
theoretische“ Werte,
welche rein rechnerisch ermittelt wurden. Der Grund liegt darin, dass einige Adressen spezielle
Bedeutungen haben (Kapitel 3.1.5) und nicht zur Verfügung stehen. Aus der Tabelle folgt, dass die
Adressklasse A eine sehr geringe Anzahl von Netzwerken mit einer sehr großen Anzahl von Hosts pro
Netzwerk, die Adressklasse B eine ”
mittlere“ Anzahl von Netzwerken mit einer ”
mittleren“ Anzahl

24 3 DAS INTERNET PROTOKOLL
Länge des
Maximale Anzahl der
Klasse Netzwerkanteils Hostanteils Netzwerke Host pro Netzwerk
A 8 Bit 24 Bit 128 16.777.216
B 16 Bit 16 Bit 16.384 65.536
C 24 bit 8 Bit 2.097.152 256
Tabelle 2: Länge des Netzwerk- und Hostanteils und Maximale Anzahl der Netzwerke und Hosts in
der jeweiligen IPv4-Adressklasse
von Hosts pro Netzwerk und die Adressklasse C eine sehr große Anzahl von Netzwerken mit einer
sehr geringen Anzahl von Hosts pro Netzwerk besitzt.
Die IP-Adresse identifiziert keinen bestimmten Knoten, sondern nur ein Interface. Einem Knoten mit
mehreren Interfaces (z.B. ein Router) muss für jedes Interface eine IP-Adresse zugewiesen werden.
Jedes Interface besitzt eine eindeutige IP-Adresse, d.h. dass keine verschiedenen Interfaces die identischen
IP-Adressen besitzen. Dies veranschaulicht Abbildung 9.
Ethernet 132.221.0.0/16
132.221.99.5
223.240.129.10
223.240.129.11
132.221.12.3
132.221.25.1
Router
223.240.129.22
Token-Ring
223.240.129.0/24
223.240.129.22
WAN 79.0.0.0/8
79.0.0.17
Router
Abbildung 9: IP-Adresszuweisung: Jedes Interface hat eine eindeutige Adresse
3.1.5 Spezielle IPv4-Adressen
Es sind spezielle Adressen reserviert, d.h. sie dürfen nicht als IP-Adresse an Interface vergeben werden.
Im Folgenden werden diese speziellen Adressen bzw. Adressformate aufgelistet und erklärt.

3.1 Das Internet Protokoll Version 4 - IPv4 25
Die Adresse ”
This Computer“ wird vom Knoten beim ”
Booten“ benutzt, da dort die IP-Adresse noch
nicht bekannt ist. Sie besteht nur aus Nullen: 0.0.0.0
Die Netzwerkmaske (Netmask) stellt einen Filter dar, der entscheidet, ob sich ein Router in einen
entfernten Netzwerk oder im gleichen logischen Netzwerk befindet. Netzwerkmasken haben große
Bedeutung bei der Teilnetz- und der klassenlosen Adressierung, auf die in Kapitel 3.1.6 respektive
Kapitel 3.1.7 eingegangen wird.
Für jede der Netzwerkklassen (Klasse A, B und C) wurde jeweils eine Standardnetzwerkmaske festgelegt,
bei der alle Bitstellen des Netzwerkanteils auf 1 und alle Bitstellen des Hostanteils auf 0
gesetzt sind. Tabelle 3 zeigt für die Klassen A, B und C die jeweilige Standardnetzwerkmaske mit
der ”
neuen“ Präfix-Notation oder auch CIDR-Notation, auf die in Kapitel 3.1.7 noch eingegangen
wird. Netzwerkadressen beziehen sich auf das Netzwerk selbst, und nicht auf die angeschlossenen
Klasse 1. Byte 2. Byte 3. Byte 4. Byte Präfix-Notation
A 255 0 0 0 /8
B 255 255 0 0 /16
C 255 255 255 0 /24
Tabelle 3: Die IPv4-Standardnetzwerkmasken der Klasse A, B und C.
Hosts. Man erhält die Netzwerkadresse bei gegebenen IP-Adresse, indem man die IP-Adresse bitweise
mit dem boolschen UND verknüpft. Die Netzwerkadresse setzt sich also aus der Netzwerknummer
und als Hostanteil nur Nullen zusammen. Nur Hosts, die eine identische Netzwerkadresse besitzen,
befinden sich im gleichen logischen Netz. Somit hat z.B. das Netzwerk mit der Netzwerknummer
130.216 die Netzwerkadresse 130.216.0.0 und die Netzwerkmaske 255.255.0.0. Die Netzwerkadressen
wurden vom Network Information Center (NIC) vergeben, um Adresskonflikte zu vermeiden.
Diese Aufgabe hat nun die Internet Assigned Numbers Authority (IANA) bzw. ihre Vertreter in den
verschiedenen Gebieten (Asia Pacific Network Information Center (APNIC), American Registry for
Internet Numbers (ARIN), Reseau IP Europeens (RIPE)) übernommen. Die Adressen werden nicht
einzeln zugeordnet, sondern nach den Adressklassen vergeben.
Für den Fall, dass man an alle Hosts eines physischen Netzwerks, ein IP-Datagramm senden will,
existiert die sogenannte gerichtete Broadcast-Adresse (Directed Broadcast Address) für jedes physische
Netzwerk. Der Netzwerkanteil besteht wiederum aus der Netzwerkadresse und im Hostanteil
sind nur 1-Bit gesetzt. Die Broadcast-Adresse wird ermittelt, indem man die Netzwerkadresse mit der
bitweise invertierten Netzwerkmaske bitweise mit dem boolschen ODER verknüpft.
Zudem existiert aber noch begrenzte Broadcast-Adresse (Limited Broadcast), die sich nur auf ein
lokales Netz beziehen. Diese Art von Adressen werden meist beim Systemstart verwendet, da dort
die Netzwerkkennung noch nicht bekannt ist, oder um einen Broadcast im lokalen Netzwerk durchzuführen.
Netzwerk- und Hostanteil bestehen nur aus 1-Bits, somit ist 255.255.255.255 die begrenzte
Broadcast-Adresse.

26 3 DAS INTERNET PROTOKOLL
Für Testzwecke wurde eine Schleifenadresse (Loopback Address) definiert. Sie wird z.B. von Programmieren
von Netzwerkanwendungen zur Fehlerdiagnose und Fehlerkorrektur verwendet. Während
der Ausführung eines Schleifentest verlässt kein IP-Datagramm den Knoten, sondern nur zwischen
zwei Anwendungen werden die IP-Datagramme befördert. Für die Schleifenadresse ist der Netzwerkanteil
127.0.0.0 bis 127.255.255.255 reserviert. Der Hostanteil kann beliebig gewählt werden,
die Konvention sieht die Verwendung der Hostnummer 1 vor, so dass 127.0.0.1 die übliche Schleifenadresse
ist.
Zudem hat die Internet Assigned Numbers Authority (IANA) drei Blöcke des IP Adressraums für
private Netzwerke reserviert [RFC1918]. Diese bedürfen keiner Koordination der IANA und können
frei gewählt werden. Tabelle 4 listet die drei Blöcke auf.
Klasse Adressbereich Präfix-Notation
A 10.0.0.0 - 10.255.255.255 10/8
B 172.16.0.0 - 172.31.255.255 172.16/12
C 192.168.0.0 - 192.168.255.255 192.168/16
Tabelle 4: Drei Blöcke des IP-Adressraums sind für private Netzwerke reserviert.
3.1.6 Teilnetze und Teilnetzwerkmasken
Die Teilnetz-Adressierung (Subnet Addressing) teilt ein ”
großes“ Netzwerk in eine entsprechende Anzahl
”
kleinerer“ Teilnetzwerke (Subnets). Die Gründe für eine Teilnetzbildung (Subnetting) können
verschiedener Natur sein:
• Beschränkungen der physikalischen Medien 6
• Überlastungen aufgrund zu hohen Traffic-Aufkommens
• große geographische Abstände
• Trennung von Netzwerken nach Abteilungen bzw. Bereichen
• Trennung von Netzwerken nach Standorten, Zweigstellen
• Trennung nach unterschiedlichen Technologien
• Bildung von logischen Arbeitsgruppen
• Abkopplung von Bereichen mit sicherheitsrelevanten Daten
6 10BASE-T-Ethernet: max. 1.024 Hosts pro Netzwerk

3.1 Das Internet Protokoll Version 4 - IPv4 27
• einfachere Verwaltung
Teilnetzbildung bedeutet nichts anderes, als dass dem Netzwerkanteil einzelne Bitstellen des Hostanteils
hinzugeschlagen werden und somit der Netzwerkanteil vergrößert wird. Also wird eigentlich
nur die Standardnetzmaske geändert und somit der ”
Filter“ verändert, der entscheidet, welche Rechner
sich im gleichen logischen Netzwerk befinden. Anzahl der Teilnetze wird über die Anzahl der
Bitstellen gesteuert, die dem Netzwerkanteil hinzugeschlagen wird. Die Ermittlung der gerichteten
Broadcast Adresse geschieht weiterhin wie in Kap. 3.1.5 auf Seite 25 beschrieben.
Als die Teilnetzbildung eingeführt wurde, entfernte man sich gleichzeitig von der klassenbezogenen
Adressierung. Jetzt musste immer die Netzwerkmaske mit angegeben werden. Und zwar geschieht das
nach wie vor wie oben beschrieben. In neuerer Literatur wird meist nicht immer die Netzwerkmaske
in der Punkt-Dezimal-Notation angegeben, sondern es wird nur noch die Anzahl der Bitstellen, die
dem Netzwerkanteil entspricht, angegeben. Diese Darstellung nennt man Präfix-Notation oder CIDR-
Notation und wird im Folgenden Kapitel auf Seite 28 beschrieben.
3.1.7 Klassenlose Adressen
Die Anforderung, dass der Netzwerkanteil einer IP-Adresse genau ein, zwei oder drei Byte umfassen
muss, hat sich hinsichtlich der zunehmender Größe des Internets als problematisch erwiesen. Dem
IPv4 gehen langsam die Adressen aus. Zwar gibt es Millionen von Adressen, aber viele bleiben einfach
ungenutzt, weil für jedes Netzwerk eine der drei Größen gewählt werden musste. Die größten
Probleme lösten dabei die Klassen B und C aus. Mit der Klasse C kann man nur maximal 254 Host
adressieren. Viele Firmen beantragten deshalb statt einer Klasse C eine Klasse B mit denen sie maximal
65.536 Hosts eine Adresse zuweisen können, da sie die Befürchtung hatten, ein Klasse C Netz
würde nicht ausreichen. Tatsächlich ist aber oft auch ein Klasse B Netz zu groß. Für viele Firmen
würde ein Netz der Klasse C ausreichen.
Als Beispiel nehmen wir eine Firma ”
Müller GmbH“ die 2.000 Hosts adressieren will. Im Rahmen
der klassenbezogenen Adressierung wurde dieser Firma eine Klasse B Netzwerkadresse zugewiesen,
der Form ∗. ∗ .0.0 bis ∗. ∗ .255.255. Damit liegen aber mehr als 63.000 unbenutzte Adressen brach.
Wie man leicht erkennen kann ist die Klasse C ist einfach zu klein, denn ab 255 Host benötigt man
ein Klasse B Netz und das Klasse B Netz ist einfach zu groß. Zudem wurde in den Anfängen des
Internets allzu sorglos mit der Adressenvergabe umgegangen. Eine Lösung um die starre Klassenaufteilung
der Adressen flexibel an die Gegebenheiten anzupassen, war lokal gesehen die im vorherigen
Kapitel beschriebene Teilnetzbildung, aber 1993 tauchte mit dem Classless InterDomain Routing
(CIDR) [RFC1519] eine globale Möglichkeit auf.
Dazu sollen die restlichen 7 Klasse C Netze in Blöcken mit variabler Länge vergeben werden. So
braucht man kein Klasse B Netz mehr, um 300 Adressen zu adressieren, sondern einfach 2 aufeinan-
7 es sind immernoch über 1,5 Millionen

28 3 DAS INTERNET PROTOKOLL
derfolgende Klasse C Netze. Zusätzlich wurde die Welt in vier Zonen, von denen jede einen Teil 8 des
verbliebenen Klasse C-Adressraums erhält, aufgeteilt [RFC1519]. Tabelle 5 zeigt die vier verschiedenen
Zonen. Anhand dieser Tabelle ”
weiß“ z.B. ein Router außerhalb Europas, dass er ein Paket mit
Adressbereich Zonen
194.0.0.0 - 195.255.255.255 Europa
198.0.0.0 - 199.255.255.255 Nordamerika
200.0.0.0 - 201.255.255.255 Mittel- und Südamerika
202.0.0.0 - 203.255.255.255 Asien und pazifischer Raum
204.0.0.0 - 223.255.255.255 Reserviert für zukünftige Nutzung
Tabelle 5: Klassenlose Adressierung (CIDR): Aufteilung der verbliebenen Klasse C in vier Zonen
einer Adresse zwischen 194.∗.∗.∗ und 195.∗.∗.∗, einfach zu seinem europäischen Standard-Gateway
senden kann. So sind praktisch die jeweils 32 Millionen Adresse zu einem Routing-Tabelleneintrag
komprimiert. Um nun die aufeinanderfolgenden Netze als ein Netz zu beschreiben, ist wiederum die
Netzwerkmaske wichtig. Sie wird mit den Netzen vergeben. Bei jeder Vergabe von aufeinanderfolgenen
Klasse C Netzen wird in der jeweiligen Zone (z.B. Europa) alle Routingtabellen um die Einträge
ergänzt, somit wurde man auch der ”
Explosion der Routingeinträge“ herr.
Um nun nicht immer die Netzwerkmaske in der Punkt-Dezimal-Notation schreiben zu müssen, wurde
die Präfix- oder CIDR-Notation eingeführt [RFC1878]. Das Format der Präfix-Notation ist ∗.∗.∗.∗/x,
wobei x die Anzahl der Bits des Netzwerkanteils ist. In [RFC1878] werden alle 32 möglichen Präfixe
aufgelistet.
Da mit CIDR die klassische klassenbezogenen Adressenaufteilung aufgehoben wurde, braucht man
nicht mehr in Klassen zu denken, sondern benutzt einfach die Präfix-Notation, um die Grenze zwischen
Netzwerk- und Hostanteil festzulegen. Zum Beispiel schreibt man die Standardnetzmaske der
Klasse B in der Präfix-Notation nur noch mit /16. Es werden also die Bits des Netzwerkanteils mit 16
Bits angegeben. Somit kann die IP-Adresse 128.10.0.1 mit Netzmaske 255.255.0.0 als 128.10.0.1/16
geschrieben werden. Zudem braucht man nichts mehr über Klassen zu wissen, da man sofort sieht,
dass die Adresse 10.104.0.19/8 8 Bit für den Netzwerkanteil und 24 Bit für den Hostanteil besitzt.
Aber in den Hosttabellen wird immer noch die Punkt-Dezimal-Notation für die Netzmaske verwendet.
Anhand der Tabelle in [RFC1878], in der alle 32 möglichen Präfixe aufgelistet werden, kann man
die Netzmaske feststellen.
Um nun herauszufinden in welches Netz ein IP-Datagramm geroutet werden muss, wird auf die
Zieladresse und einer Netzmaske aus der Routing-Tabellen das boolesche UND angewendet. Sobald
das Ergebnis die identische Netzmaske ergibt, wird das IP-Datagramm an den jeweiligen Router
geschickt. Das ist jetzt sehr kurz erklärt, wird aber in [RFC1519] ausführlich beschrieben.
Mit CIDR wird der Firma ”
Müller GmbH“ aus dem obigen Beispiel statt eine Klasse B Netzadresse
8 etwa 32 Millionen Adressen

3.1 Das Internet Protokoll Version 4 - IPv4 29
ein Block mit 2.048 Hostadressen, also acht aufeinanderfolgende Klasse C Netze, der Form ∗. ∗
. ∗ .∗/21, zugewiesen. Diese Adresse hat also einen 21-Bit langen Netzwerkanteil, daraus folgt die
Netzmaske 255.255.248.0.
3.1.8 Fragmentierung von IP-Datagrammen
Jeder Link spezifiziert eine Link MTU. Das IP-Protokoll sendet seine IP-Datagramme mit der Link
MTU über dessen Link sein IP-Datagramm gesendet wird. In [RFC791] ist definiert, dass jeder Router
mindestens ein IP-Datagramm von 68 Byte weitersenden können muss. Dieser Wert (68 Byte) ist
die kleinste Link MTU die das IP-Protokoll unterstützt. Hingegen muss jeder Zielhost in der Lage sein,
ein IP-Datagramm der Größe 576 Bytes, empfangen zu können. Nun kann es jedoch möglicherweise
vorkommen, dass das IP-Datagramm von einem Router auf der Strecke über ein Netzwerk mit geringerer
Link MTU 9 verschickt wird. Dazu muss nun der Router an dem Interface die IP-Datagramme
umverpacken“, sprich aus einem IP-Datagramm mehrere machen. Dies nennt man dann Fragmentierung.
Jeder Router muss der Lage ist, empfangene IP-Datagramme gegebenenfalls zu zerteilen,
”
um sie weiter über ein Teilnetz bis zum Zielhost zu übertragen. Fragmentierte IP-Datagramme heißen
Fragmente. In Abbildung 10 ist die Fragmentierung anhand eines Beispiels gezeigt. Jedes Frag-
Netz mit 4000 Byte MTU
Netz mit 1500 Byte MTU
Original Paket
Gesamtlänge: 4000 Byte
Nutzdaten: 2980 Byte
Identifikation: 1783
Fragment Offset: 0
DF=0 MF=0
Router
1. Fragment
2. Fragment 3. Fragment
Ges.länge: 1500 Byte Ges.länge: 1500 Byte Ges.länge: 1040 Byte
Nutzdaten: 1480 Byte Nutzdaten: 1480 Byte Nutzdaten: 1020 Byte
Ident.: 1783 Ident.: 1783 Ident.: 1783
Frag. Offset: 0 Frag. Offse: 1480 Frag. Offset: 2960
DF=0 MF=1 DF=0 MF=1 DF=0 MF=0
Abbildung 10: Fragmentierung von IPv4-Datagrammen [RFC791]
ment erhält einen eigenen, vollständigen IP-Protokollkopf. Damit jedes Fragment beim Empfänger
eindeutig dem richtigen IP-Datagramm zugeordnet werden kann, hat es schon beim Quellhost eine
eindeutige Kennung erhalten. Zudem kann der Quellhost über das ”
DF“-Flag eine Fragmentierung
untersagen. Allerdings wird dann, wenn das IP-Datagramm zum Weitertransport fragmentiert werden
müsste einfach verworfen und eine Fehlermeldung via ICMP an den Host geschickt.
Mit dem ”
MF“-Flag kennzeichnet der Knoten nun alle Fragmente - mit Ausnahme des letzten. Der
Zielhost weiß dann, dass keine weiteren Fragmente mehr kommen und er mit dem Zusammenetzenbeginnen
kann. Der Fragment Offset gibt für jedes Fragment an, ab welcher Stelle des originalen
IP-Datagrammes die Nutzdaten einzufügen sind.
Jeder Host muss in der Lage sein, diese Fragmente wieder zum ursprünglichen IP-Datagramm zu-
9 aber mindestens 68 Byte

30 3 DAS INTERNET PROTOKOLL
sammenzusetzen. Das Zusammensetzen von fragmentierten IP-Datagramme (Fragmente) heißt Defragmentierung.
Die Defragmentierung geschieht nur beim Zielhost. Muss ein Fragment nochmals
fragmentiert werden um weitergesendet zu werden, geschieht dies, ohne die Fragmente in das ursprüngliche
IP-Datagramm zu defragmentieren, um es dann wieder zu fragmentieren. Das Internet
Protokoll unterscheidet also nicht zwischen Fragmente und IP-Datagramme.
In Abbildung 11 sendet Host A ein IP-Datagramm (I) der Länge 4000 Byte an Host B. Zuerst muss
dieses IP-Datagramm vom Router A fragmentiert werden, da die Link MTU kleiner ist. Es entstehen
drei IP-Datagramme, Fragmente, die an Router B gesendet werden. Router B kann aufgrund der
der Link MUT von 1280 die zwei größeren Fragmente nicht weitersenden und muss diese nochmals
fragmentieren, bevor er sie weitersenden kann. Nun kann er alle Fragmente an Router C senden. Router
C kann alle Fragmente sofort an Host B zustellen. Host B defragmentiert nun alle empfangenen
Fragmente zu dem ursprünglichen IP-Datagramm (II). Die Fragmentierung von IP-Datagrammen ist
Host A
(I)
MTU 4000 MTU 1500 MTU 1280 MTU 1500
Router A Router B Router C
Host B
(II)
Abbildung 11: Mehrmalige Fragmentierung von IPv4-Datagrammen [RFC791]
problematisch und zudem noch rechenintensiv für die Router, die fragmentieren müssen. Eine Lösung
ist die Path MTU Discovery (PMTUD). Diese Methode wird in [RFC1191] beschrieben, ist aber kein
Standard für IPv4, sondern wird lediglich empfohlen. Der Zweck dieser PMTUD ist einzig und allein
dem Quellhost die Fragmentierung der IP-Datagramme zu überlassen, so dass auf dem gesamten Pfad
vom Quell- zum Zielhost nicht mehr fragmentiert werden muss. Hierzu müssen aber alle Router auf
dem Pfad PMTUD unterstützen. Der Quellhost erlernt die Path MTU, indem er ein IP-Datagramm
mit gesetzter DF“-Flag an den Zielhost sendet. Ein Router, der dieses IP-Datagramm fragmentieren
”
müsste, schickt eine ICMP-Fehlermeldung mit der Link MTU an den Quellhost zurück. Der Quellhost
passt sich nach dieser Link MTU an und schickt wieder ein IP-Datagramm mit gesetzter DF“- ”
Flag. Dies wird solange gemacht, bis ein IP-Datagramm am Zielhost angekommen ist. Dabei treten
viele Probleme auf. Die Path MTU kann sich dynamisch verändern, d.h. der Host sollte die einmal
gelernte“ Path MTU periodisch überprüfen und dann ggf. auch ändern. Zudem schicken nicht alle
”

3.1 Das Internet Protokoll Version 4 - IPv4 31
IPv4-Router die lokale maximale Link MTU. Einige Host blocken zudem auch ICMP-Meldungen
ab, d.h. der Host sendet dann die IP-Datagramme mit der kleinsten Link MTU, eben den 86 Bytes
[RFC2923].
Im neuen IP-Protokoll, IPv6, wird die Path MTU Discovery implementiert und in [RFC1981] beschrieben.
In Kapitel 3.2.5 wird auf die Path MTU Discovery für IPv6 eingegangen.
3.1.9 Probleme und Schwächen des IPv4
Wie schon zu Beginn erwähnt, wurde die Spezifikation von IPv4 im Lauf der Zeit den Erfordernissen
angepasst. Als großes Problem stellt sich die zu kleine Adressenlänge von 32-Bit heraus und die
daraus resultierende Adressenknappheit. Dem wurde versucht mit NAT und mit CIDR entgegenzuwirken.
Nur das kann auf die Dauer nicht gelingen. Das Internet wächst jedes Jahr um Millionen
Hosts wie Abbildung 12 zeigt. Mit der heutigen Wachstumsrate sind die verfügbaren Netzwerkanteile
Abbildung 12: Wachstum des Internets [isc.org]: Anzahl der Hosts von 1991 bis 2002
bald erschöpft und ein weiteres Wachstum nicht möglich. Das zweite Problem ist die Änderung die
sich durch neue Internetanwendungen ergab. Audio- und Videowiedergabe in Echtzeit gehören zum
Beispiel dazu. Damit solche Daten ”
ruckelfrei“ im Internet übertragen werden können, müssen der
häufige Wechsel von Routen vermieden werden. Router werden von IPv4 damit beschäftigt, Checksummen
zu prüfen und zu errechnen und IP-Datagramme zu fragmentieren. Beides ist heutzutage

32 3 DAS INTERNET PROTOKOLL
völlig unnötig und kostet bei dem heutigen Traffic summa summarum doch viel Rechenzeit. Ein weiteres
Problem sind die Optionen in IPv4. Sie sind nicht flexibel genug und können auch nicht wirklich
erweitert werden, was den Nutzungsgrad von IPv4 schon sehr einengt. Auch der relativ große Protokollkopf
mit den vielen, oft ungenutzten Feldern 10 , stellt ein Problem dar. Auch Sicherheit spielte bei
IPv4 lange keine große Rolle, aber mit der Entwicklung von IPsec, welches eigentlich für das neue
Protokoll erdacht war, kam vorerst Linderung. Durch DHCP wurde auch der Administratoraufwand
erheblich vermindert.
Viele Schwächen, die IPv4 hat, wurden im Laufe der Zeit vermindert und im alten Design wurde
soweit dies möglich war, Verbesserungen gemacht. Das Verfahren, Path MTU Discovery, wurde für
IPv6 entwickelt und existiert jetzt schon in leicht abgewandelter Form in IPv4. Aber damit entstand
ein neues Problem. Denn um die IP-Datagramme direkt in der richtigen Größe schicken zu können
bekommt der Quellhost eine ICMP-Fehlermeldung. Doch wenn die nicht, z.B. durch falsches konfigurieren,
ankommt, so dass die Path MTU Discovery fehlschlägt, benutzt IPv4 die kleinste MTU,
68 Byte, um die IP-Datagramme zuzustellen. Das viel höhere Paketaufkommen belastet unnötig den
Router.
3.2 Das Internet Protokoll Version 6 - IPv6
3.2.1 Allgemeines über IPv6
Das Internet Protokoll Version 6 (IPv6 oder IPng 11 ) wurde aus einer Not heraus geboren. Das Computermagazin
c’t beschreibt in [ct1601] das Problem 2001 folgendermaßen: ”
Die Spatzen brüllen es
von den Dächern: Der Adressraum im Internet wird knapp. Zwar hat die Network Address Translation
(NAT) bei Providern für den Wählzugang ins Internet vorerst Linderung gebracht, doch kann
dies nur eine vorübergehende Lösung sein. Eine durchgreifende Abhilfe existiert in Form des Internet
Protocol Version 6 (IPv6) zwar schon seit 1995, allein in der Praxis zeigt es sich herzlich selten.“
Das IPv6 Paketformat ist gemessen am IPv4 Paketformat wesentlich einfacher. Erreicht wird dies
durch die Verlagerung von Funktionen in sogenannte Erweiterungsprotokollköpfe, die zwischen dem
IPv6 Protokollkopf und der eigentlichen Nutzlast, den Daten, enthalten sein können. Die Abbildung
13 zeigt den Aufbau eines solchen IPv6-Pakets. Unbekannte Erweiterungsprotokollköpfe können
nicht von einer Implementation ignoriert werden sondern führen zum Verwerfen des Pakets. Zusätzliche
Parameter, die von Implementationen ignoriert werden können, werden als Optionen bezeichnet
und in speziellen Erweiterungsprotokollköpfen für Optionen übertragen.

3.2 Das Internet Protokoll Version 6 - IPv6 33
optional
IPv6 Basis 1-ter
Protokollkopf Erweiterungs- ...
Protokollkopf
(40 Byte)
n-ter
Erweiterungs-
Protokollkopf
Daten
Abbildung 13: Allgemeine Form eines IPv6-Pakets [RFC2460]
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Version Traffic Class Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
Abbildung 14: IPv6 Protokollkopfformat [RFC2460]
3.2.2 IPv6-Protokollkopfformat
Version: 4 Bits
Das Feld Version enthält die Versionsnummer des IP-Protokolls. Der Wert ist 6.
Traffic Class: 8 Bits
Das Feld Traffic Class wird zum Unterscheiden der verschiedenen Übermittlungsanforderungen
von Paketen benutzt. Zum Bsp. benötigt man für die Übertragung von digitaler Sprache
mehr Schnelligkeit und weniger Genauigkeit, im Gegensatz zur Übertragung von Dateien, wo
10 Fragmentierung muss nicht immer sein
11 Internet Protocol The Next Generation

34 3 DAS INTERNET PROTOKOLL
die Genauigkeit wichtiger ist als die Geschwindigkeit. Die Abbildung 15 zeigt den Aufbau des
Feldes.
0 1 2 3 4 5 6 7
DSCP
CU
DSCP - differentiated services codepoint
CU - currently unused
Abbildung 15: Traffic Class - Aufbau nach RFC 2474 [RFC2474]
Flow Label: 20 Bits
Das Feld Flow Label ist noch in der Experimentierphase, soll aber benutzt werden, um es einer
Quelle und einem Ziel zu ermöglichen, eine Pseudoverbindung mit bestimmten Merkmalen
und Anforderungen aufzubauen. Das Feld kann dann benutzt werden, um ein IP-Datagramm
mit einem bestimmten Netzwerkpfad zu assoziieren. Router sollen dann das Feld benutzen, um
die IP-Datagramm auf diesen vorab ”
geplanten“ Pfad zu befördern.
Payload Length: 16 Bits
Das Feld Payload Length gibt an, wie viele Bytes dem 40 Byte langen Protokollkopf folgen.
Next Header: 8 Bits
Das Feld Next Header gibt an, welcher der Erweiterungsprotokollköpfe (Kap. 3.2.3) diesem
folgt oder falls er der letzte IP-Protokollkopf ist, welches Transportprotokoll folgt.
Hop Limit: 8 Bits
Das Feld Hop Limit entspricht dem ”
Time to Live“-Feld in IPv4 nur mit dem Unterschied, dass
die Einheit nicht mehr Sekunden ist, und dass das Feld nach jeder Teilstrecke um den Wert 1
verringert wird. Sobald der Wert des Feldes 0 ist, wird das Paket verworfen.
Source Address: 128 Bits
In diesem Feld wird die 128 Bit-Quelladresse eingetragen. Die 128 Bit Adresse wird ausführlich
im Kapitel 3.2.4 auf Seite 39 behandelt.
Destination Address: 128 Bits
In diesem Feld wird die 128 Bit-Zieladresse eingetragen. Die 128 Bit Adresse wird ausführlich
im Kapitel 3.2.4 auf Seite 39 behandelt.

3.2 Das Internet Protokoll Version 6 - IPv6 35
3.2.3 IPv6-Erweiterungsprotokollköpfe
Es sind die folgenden sechs Erweiterungsprotokollköpfe (Extension Headers) definiert [RFC2460,
RFC2402, RFC2406]:
Optionen für Teilstrecken“ Erweiterungsprotokollkopf
”
Abbildung. 16 zeigt den Hop-by-Hop Options Extension Header (HO). Er enthält eine Liste von Optionen,
die von jedem Knoten auf dem Weg untersucht werden müssen [RFC2460].
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next Header
Hdr Ext Len
Options
Abbildung 16: Hop-by-Hop Options Extension Header [RFC2460]
Next Header: Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem HO enthaltenen
Nachricht.
Hdr Ext Len: Das Feld Header Extension Length spezifiziert die Länge des HO gemessen in der
Anzahl von 64 Bit Worten minus 1.
Options: Das Feld Options enthält die einzelnen Optionen.
Routing Erweiterungsprotokollkopf
Der Routing Extension Header (RH) wird in Abbildung 17 gezeigt. Er erlaubt es, den Weg eines
Datagramms im voraus zu planen [RFC2460].
Next Header: Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem RH enthaltenen
Nachricht.
Hdr Ext Len: Das Feld Header Extension Length spezifiziert die Länge des RH gemessen in der
Anzahl von 64 Bit minus 1.

36 3 DAS INTERNET PROTOKOLL
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next Header Hdr Ext Len Routing Type Segments Left
Type-Specific Data
Abbildung 17: Routing Extension Header [RFC2460]
Routing Type: Das Feld Routing Type identifiziert eine bestimmte Variante des RH und die Bedeutung
des Felds Type-Specific Data.
Segments Left: Das Feld Segments Left identifiziert die Anzahl der verbleibender Routing-Segmente.
Fragmentierungs Erweiterungsprotokollkopf
IPv6 setzt voraus, daß jeder Link eine MTU von mindestens 1280 Byte besitzt. Entsprechend müssen
Links, die eine kleinere Link MTU besitzen, Fragmentierung und Reassemblierung unterhalb von
IPv6 realisieren. Einfache Implementationen, die kein Path MTU Discovery (Kap. 3.2.5) unterstützen,
müssen sich auf IP-Datagramme mit einer maximalen Länge von 1280 Byte beschränken. Mit Hilfe
des Fragment Extension Header (FH), der in Abbildung 18 gezeigt wird, können IP-Datagramme
die größer als die Path MTU sind, fragmentiert und versendet werden. Fragmentierung erfolgt ausschließlich
beim Quellhost eines IP-Datagramms und niemals innerhalb eines Routers [RFC2460].
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
M
Next Header Reserved Fragment Offset Res
Identification
Abbildung 18: Fragment Extension Header [RFC2460]
Next Header: Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem FH enthaltenen
Nachricht.
Fragment Offset: Das Feld Fragment Offset definiert die relative Position eines Fragments (gemessen
in 64 Bit Worten) des original IP-Datagramms.

3.2 Das Internet Protokoll Version 6 - IPv6 37
M: Die Flag M ist gesetzt, wenn weitere Fragmente folgen. Die Bits Res sind nicht benutzt.
Identification: Das Feld Identification enthält für alle Fragmente eines IP-Datagramms denselben
Wert.
Authentifikation Erweiterungsprotokollkopf
Der Authentication Header (AH), in Abbildung 19 gezeigt, realisiert für IP-Datagramme die grundlegenden
Sicherheitsdienste Authentifikation und Datenintegrität [RFC2402].
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next Header Payload Len Reserved
Security Parameters Index (SPI)
Authentication Data (variable)
Abbildung 19: Authentication Header [RFC2402]
Next Header: Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem AH enthaltenen
Nachricht.
Payload Len: Das Feld Payload Length spezifiziert die Länge des AH gemessen in der Anzahl von
32 Bit Worten minus 2.
Security Parameters Index: Das Feld Security Parameters Index enthält einen Wert, der zusammen
mit der Zieladresse eindeutig eine Security Association (SA) identifiziert.
Sequence Number: Das Feld Sequence Number enthält eine streng monoton wachsende Sequenznummer.
Das erste Paket, das nach der Einrichtung einer SA gesendet wird, hat den Sequenznummernwert
1. Erreicht die Sequenznummer den Wert 232, so muss in der Regel eine neue
SA eingerichtet werden.
Authentication: Das Feld Authentication Data enthält eine Integritätsprüfsumme (integrity check
value, ICV). Die Länge dieses Felds hängt von der verwendeten Authentifizierungsfunktion ab.

38 3 DAS INTERNET PROTOKOLL
Verschlüsselte Sicherheitsdaten“ Erweiterungsprotokollkopf
”
Abbildung 20 zeigt den Encapsulating Security Payload Erweiterungsprotokollkopf (ESP). Er realisiert
Sicherheitsdienste wie Vertraulichkeit, Authentifikation, Datenintegrität, Schutz vor Wiederholungen
und eingeschränkte Sicherung gegen Verkehrsflußanalysen [RFC2406]. Eine Fragmentierung
kann nur nach einer Verschlüsselung erfolgen, d.h. ESP wird nie auf ein Fragment angewendet.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Security Parameters Index (SPI)
Sequence Number
Payload Data (varibale)
Padding (0-255 bytes)
Pad Length
Next Header
Authentication Data (variable)
Abbildung 20: Encapsulating Security Payload Erweiterungsprotokollkopf [RFC2406]
Security Parameters Index: Das Feld Security Parameters Index enthält einen Wert, der zusammen
mit der Zieladresse eindeutig eine Security Association (SA) identifiziert.
Sequence Number: Das Feld Sequence Number enthält eine streng monoton wachsende Sequenznummer.
Das erste Paket, das nach der Einrichtung einer SA gesendet wird, hat den Sequenznummernwert
1. Erreicht die Sequenznummer den Wert 232, so muss in der Regel eine neue
SA eingerichtet werden.
Payload Data: Die verschlüsselte Nutzlast (inklusive etwaiger Initialisierungsvektoren) ist im Feld
Payload Data untergebracht.
Padding: Das Feld Padding kann benutzt werden, um durch Füllbytes eine Ausrichtung der verschlüsselten
Daten zu erreichen oder um eine passende Eingabelänge für ein gegebenes Verschlüsselungsverfahren
bereitzustellen. Durch das Anfügen von Füllbytes kann auch die ursprüngliche
Länge der Nutzlast verschleiert werden.
Pad Length: Das Feld Pad Length enthält die Anzahl der Füllbytes.
Next Header: Das Feld Next Header identifiziert den Typ der in der Nutzlast enthaltenen Nachricht.

3.2 Das Internet Protokoll Version 6 - IPv6 39
Authentication Data: Das Feld Authentication Data enthält eine Integritätsprüfsumme (integrity
check value, ICV). Die Länge dieses Felds hängt von der verwendeten Authentifizierungsfunktion
ab.
Optionen für Ziele“ Erweiterungsprotokollkopf
”
Der Destination Options Extension Header (DO) enthält eine Liste von Optionen, die nur von den
Zielknoten untersucht werden müssen [RFC2460]. Er wird in Abbildung 21 gezeigt.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next Header
Hdr Ext Len
Options
Abbildung 21: Destination Options Extension Header [RFC2460]
• Die Felder Next Header, Hdr Ext Len und Options sind analog zum HO Erweiterungsprotokollkopf
definiert.
3.2.4 Aufbau einer IPv6-Adresse
Die IPv6-Adresse hat eine Länge von 128 Bit 12 . Mit einer 128-Bit-Adressierung kann man nun 2 128 =
340.282.366.920.938.463.463.374.607.431.768.211.456 mögliche Adressen vergeben. Wie man sieht,
ist das eine unvorstellbar große Zahl und man kann nun jedem Quadratmeter Erdoberfläche ca. 7×10 23
Adressen zuweisen. Die Entscheidung eine IP-Adresse mit 128 Bit für das neue IP-Protokoll zu benutzten,
lag nicht darin, jeden Quadratmeter mit Quadrillionen von Adressen zu ”
bepflastern“, sondern
eine Aufteilung des Internets nach topographischen und hierarchischen Gesichtspunkten zu erreichen.
Eine 128-Bit-Adresse wird nicht als Binärzahl, im Gegensatz zur IPv4-Adresse aber auch
nicht als Punkt-Dezimal-Notation geschrieben, sondern in doppelgepunkteten Hexadezimalzahlen. In
dieser Doppelpunkt-Hexadezimal-Notation (Colon Hexadecimal Notation) werden jeweils 16 Bit zu
einer Gruppe zusammengefügt und die insgesamt 8 Gruppen mit einem Doppelpunkt ”
:“ getrennt.
Somit sieht das IPv6-Adressenformat folgendermaßen aus: ∗ : ∗ : ∗ : ∗ : ∗ : ∗ : ∗ : ∗ wobei ∗ eine
hexadezimale Zahl zwischen 0 und F F F F ist.
12 16 Byte

40 3 DAS INTERNET PROTOKOLL
Tabelle 6 zeigt eine 128-Bit-IPv6-Adresse in jeweils dualer Schreibweise, Punkt-Dezimal-Notation
und die Doppelpunkt-Hexadezimal-Notation. An dieser Tabelle ist für jeden ersichtlich, dass eigent-
Schreibweise Adresse
Binär 0010000111011010 1010111111111110
0000000000000000 1011101011111111
0010111100111011 0000000011111111
0000001010101011 0101101010011100
Punkt-Dezimal (8 Bit) 33.218.175.254.0.0.186.255.47.59.0.255.2.171.90.156
Punkt-Dezimal (16 Bit) 7180.37124.0.39599.9956.244.627.19272
Doppelpunkt-Hexadezimal 21DA:AF F E:0000:BAF F :2F 3B:00F F :02BC:5A9C
Tabelle 6: Eine IPv6-Adresse in binärer Schreibweise, in Punkt-Dezimal- und in Doppelpunkt-
Hexadezimal-Notation
lich alle Schreibweisen sehr umständlich sind, im Gegensatz zur IPv4-Adresse, doch hat man sich
für die Doppelpunkt-Hexadezimal-Notation entschieden. Dadurch kommt auch dem DNS eine höhere
Bedeutung zu. Da viele IPv6-Adressen erwartungsgemäß zahlreiche Nullen enthalten, entschied
man sich für eine sogenannte Nullenkompression (Zero Compression). Somit können eine Folge von
Nullen einmalig durch zwei Doppelpunkte ”
::“ ersetzt und führende Nullen der Hexadezimalzahlen
weggelassen werden. Somit kann die Adresse F F 02:0000:0000:0000:0000:0000:0000:0002 zu
F F 02::2 komprimiert werden.
Weiterhin wird der Adresspräfix (Address Prefixe) durch die CIDR-Notation [RFC1519] dargestellt.
Das Format der Präfix-Notation ist ∗:∗:∗:∗:∗:∗:∗:∗/x, wobei x die Anzahl der Bits von links an angibt,
welche zum Präfix gehören.
Die Knotenadresse 12AB::CD30:123:4567:89AB:CDEF und ihre Teilnetznummer
12AB:0:0:CD30::/60 kann mit 12AB::CD30:123:4567:89AB:CDEF /60 abgekürzt werden.
Es sind drei verschiedene Arten von IPv6-Adressen definiert [RFC2373]: Unicast-, Anycast- und
Mulitcast-Adressen. Im Folgenden werden die drei Adresstypen beschrieben.
Unicast
Eine Unicast-Adresse identifiziert ein einzelnes Interface. Ein an diese Art von Adressen gesendetes
IP-Datagramm wird auf den kürzesten Pfad an den Zielhost gesendet. Eine Unicast-Adresse
hat prinzipiell einen Teilnetzpräfix und eine Interface-ID und ist mit IPv4-Adressen unter CIDR vergleichbar.
Alle Unicast-Adressen, außer jene die mit dem binären Wert 000 beginnen, haben 64 Bit
lange Interface IDs, welche aus dem Modified EUI-64-Format 13 konstruiert werden. Es sind Globale
Unicast-Adressen (Global Unicast Addresses), IPv6-Adressen mit eingebetteten IPv4-Adressen
und lokale Unicast-Adressen (Local Unicast Addresses) definiert [RFC2373]. Die lokalen Unicast-
13 Es leitet die Interface ID direkt aus der MAC-Adresse ab.

3.2 Das Internet Protokoll Version 6 - IPv6 41
Adressen teilen sich in Verbindungsspezifische lokale Adressen (Link-local Unicast) und Standortspezifische
lokale Adressen (Site-Local Unicast) auf. Die verbindungsspezifischen lokalen Adressen
haben nur lokale Bedeutung auf einem Link. Sie werden automatisch per Neighbor Discovery oder
wenn kein Router existiert vergeben. IP-Datagramme von dieser oder an diese Adresse werden von
keinem Router weitergesendet und gelten z.B. nur innerhalb eines Unternehmens. Sie besteht aus einem
10 Bit langen Präfix, weitere 54 Bit langen, die Null sind und der 64 Bit langen Interface ID.
Die standortspezifischen lokalen Adressen werden zu Adressierung innerhalb eines Standortes verwendet,
ohne eine direkte Verbindung an das Internet. IP-Datagramme von dieser oder zu dieser
Adresse werden auch nicht von einem Router weitergesendet. Sie besteht aus einem 10 Bit langen
Präfix, einer 54 Bit langen Subnet ID und der 64 Bit langen Interface ID.
Es gibt zwei verschiedene IPv6-Adressen mit eingebeteten IPv4-Adressen: IPv4-compatible IPv6
Adresse und IPv4-mapped IPv6 Adresse. Bei beiden sind die ersten 80 Bits Null und die letzten 32 Bits
sind die alte IPv4-Adresse, die in Punkt-Dezimal-Notation geschrieben werden kann. Nur in den mittleren
16 Bits unterscheiden sie sich.
Die mittleren 16 Bits der IPv4-compatible IPv6 Adresse sind Null. Somit hat die Adresse folgende
Form ::∗.∗.∗.∗. Bei der IPv4-compatible IPv6 Adresse kann man einem IPv6-Knoten eine IPv4-
kompatible Adresse zuweisen. Diese IPv6 Adresse kann über ein IPv4-Netz übertragen werden. Beim
Übergang von IPv6-Netz in IPv4-Netz und umgekehrt werden nur die ersten 96 Nullen entfernt bzw.
hinzugefügt. Zu beachten ist, dass diese IPv4-Adresse eindeutig sein muss. Die IPv4-mapped IPv6
Adresse setzt die mittleren 16 Bits auf 1, damit hat sie die folgende Form ::F F F F :∗.∗.∗.∗. Dieser
Adressentyp wird benutzt um die Adressen von IPv4 Knoten als IPv6 Adressen darzustellen.
Anycast
Eine Anycast-Adresse identifiziert eine Menge von Interfaces, welche typischerweise zu verschiedenen
Knoten gehören. Ein an diese Adresse gesendetes IP-Datagramm wird auf dem kürzesten Pfad
befördert und dem nächsten Interface mit dieser Adresse zugestellt. Anycast-Adressen basieren auf
den üblichen Unicast-Adressen.
Multicast
Eine Multicast-Adresse identifiziert eine Menge von Interfaces, welche typischerweise zu verschiedenen
Knoten gehören. Ein an diese Adresse gesendetes IP-Datagramm wird an alle Interfaces,
die zu dieser Adresse gehören, gesendet. Die Zugehörigkeit zu dieser ”
Gruppe“ kann sich jederzeit
ändern. Die Multicast-Adresse übernehmen u.a. die Aufgabe der IPv4-Broadcast-Adressen. Vier Bit
der Adresse sind für das Umgangsfeld (Scope) reserviert. Durch 16 verschiedene Werte kann man ein
Multicast auf eine Verbindung, einen Standort, eine Unternehmen und weltweit begrenzen.
Der IPv6-Adressraum teilt sich auf, wie in der Tabelle 7 aufgeführt.
Hinzukommmen noch einige spezielle Adressen, die nicht verwendet werden dürfen:
Die Adresse 0:0:0:0:0:0:0:0 heißt die unspezifizierte Adresse (Unspecified Address). Sie soll beim
Booten“ benutzt werden, noch bevor der Host eine eigene Adresse erhält.
”
Die Unicast-Adresse 0:0:0:0:0:0:0:1 14 ist die Schleifenadresse (Loopback Address). Unter IPv4 hatte

42 3 DAS INTERNET PROTOKOLL
Präfix (binär) Verwendung Adress Raum
0000 0000 Reserviert, u.a. für IPv4-Adressen 1/256
0000 0001 Nicht zugewiesen 1/256
0000 001 OSI-NSAP-Adresse 1/128
0000 010 Novel-NetWare-IPX-Adressen 1/128
0000 011 Nicht zugewiesen 1/128
0000 1 Nicht zugewiesen 1/32
0001 Nicht zugewiesen 1/16
001 Nicht zugewiesen 1/8
010 Adressen für ISP (Internet Service Provider) 1/8
011 Nicht zugewiesen 1/8
100 Adressen für geographische Bereiche 1/8
101 Nicht zugewiesen 1/8
110 Nicht zugewiesen 1/8
1110 Nicht zugewiesen 1/16
1111 0 Nicht zugewiesen 1/32
1111 10 Nicht zugewiesen 1/64
1111 110 Nicht zugewiesen 1/128
1111 1110 0 Nicht zugewiesen 1/512
1111 1110 10 Link-local unicast 1/1024
1111 1110 11 Site-Local unicast 1/1024
1111 1111 Multicast-Adressen 1/256
Tabelle 7: Aufteilung des IPv6-Adressraumes [RFC2373]
sie die folgende Form: 127.0.0.0.1.
Anycast-Adressen der Form Teilnetzpräfix:0· · · 0 sind vordefiniert und heißen Subnet-Router Anycast
Adresses. IP-Datagramme mit dieser Art von Adressen als Ziel, werden zu irgendeinem Router 15 in
dem Teilnetz gesendet.
Die Multicast-Adressen von FF00:: bis FF0F:: sind reserviert [RFC2373].
3.2.5 Fragmentierung von IPv6-Datagrammen & Path MTU Discovery
In Kapitel 3.1.8 wurde die Fragmentierung von IPv4-Datagrammen beschrieben. Im Gegensatz zu
IPv4 16 führt ein IPv6-Router keine Fragmentierung mehr durch. Empfängt ein Router ein zu großes
IP-Datagramm, sendet er eine ICMP-Nachricht an den Quellhost des IP-Datagramm [RFC1981], wel-
14 kurz: ::1
15 den nächsten
16 Ohne ”
Path MTU Discovery“

3.3 Wesentliche Unterschiede 43
chen diesen anweist, alle weiteren IP-Datagramme zu diesem Ziel aufzuteilen. Das bedeutet, dass von
den Quellhosts ”
erwartet“ wird, dass sie von vornherein eine Datengrammgröße wählen, die keine
Fragmentierung voraussetzt. Das ”
erwartet“ wird durch das Verfahren der Path MTU Discovery (PM-
TUD) erreicht, welche in IPv4 lediglich empfohlen war. Mit Hilfe der PMTUD weiß der Quellhost
nun, mit welcher IP-Datagramm-Größe er senden muss, damit seine IP-Datagramm auf dem gesamten
Pfad, zwischen ihm und dem Zielhost nicht mehr fragmentiert werden muss. In Abbildung 22 wird
ein Beispiel zur Path MTU Discovery gegeben. Um die Path MTU eines Pfades zu bestimmen sendet
Host A ein genügend langes IP-Datagramm (I) an Host B. Der Router A kann aufgrund der geringeren
Link MTU von 1500 dieses IP-Datagramm nicht unfragmentiert weitersenden. Deshalb sendet
er eine ICMP-Meldung an Host A (Abb. 22(1)). Dieser wählt aufgrund der Link MTU, die in der
ICMP-Meldung gesendet wurde, diese Größe für sein IP-Datagramm. Router A kann nun dieses IP-
Datagramm Router B weitersenden. Aber auch Router B kann aufgrund der geringeren Link MTU von
1280 das IP-Datagramm nicht weitersenden. Auch er sendet eine ICMP mit der Link MTU an Host A
zurück (Abb. 22(2)). Host A sendet nun wiederrum ein IP-Datagramm mit der Länge der neuen Link
MTU von 1280 an Router A. Das IP-Datagramm erreicht nun über Router A, Router B und Router C
den Host B (Abb. 22(3)). Nun ”
kennt“ Host A die Path MTU zum Host B. In Abbildung 22(4) sendet
Host A das IP-Datagramm (I) direkt in der Länge, so dass kein Router die IP-Datagramme fragmentieren
müsste. Der Host B wiederum defragmentiert diese IP-Datagramme zu einem IP-Datagramm
(II).
3.3 Wesentliche Unterschiede
Der größte sichtbare Unterschied ist die Länge der Adressen. Waren es bei IPv4 noch 32 Bit lange
Adressen, die in Punkt-Dezimal-Notation notiert wurden, sind es bei IPv6 128 Bit lange Adressen, die
in einer Doppelpunkt-Hexadezimal-Notation dargestellt werden. Die Adressen unter IPv4 und IPv6
unterscheiden sich nicht nur in der Länge und der Schreibweise, sondern auch in der Adressenaufteilung.
Die IPv4-Adressen wurden zuerst in Klassen aufgeteilt, dann aufgrund der Adressenknappheit
und der Unflexibilität der Adressklassen als klassenlose Adressen benutzt. IPv6-Adressen sind
nicht in Klassen aufgeteilt, sondern in Adresstypen und nach dem Präfix. Somit erreichen die IPv6-
Adressen Flexibilität und eine Aufteilung des Internets nach topographischen und hierarchischen Gesichtspunkten.
Ein IPv6-Datagramm aus einem Basisprotokollkopf fester Länge, einem oder mehreren
Erweiterungsprotokollköpfen und den Nutzdaten. Ein IPv4-Datagramm besteht hingegen nur
aus einem Protokollkopf variabler Länge und den Nutzdaten. Somit braucht der IPv6-Protokollkopf
auch kein Total Length-Feld mehr. Durch die feste Länge des IPv6-Basis-Protokollkopfes können
sich die Optionen nicht mehr innerhalb des Protokollkopfes befinden. Während unter IPv4 noch jede
Funktion ein oder mehrere Felder im Protokollkopf umfasste, existiert unter IPv6 für jede Funktion
einen eigenen Erweiterungsprotokollkopf. Dadurch hat IPv6 auch ein neues Feld bekommen, das
Next Header. Dadurch wird Feld Protocol in IPv4 nicht mehr benötigt, da das Feld Next Header auch
angibt, welches Transportprotokoll nach dem letzten IP-Header folgt. Die Fragmentierung wird in

44 3 DAS INTERNET PROTOKOLL
(1)
Host A
MTU 4000 MTU 1500 MTU 1280 MTU 1500
ICMP
Router A Router B Router C
Host B
(2)
Host A
MTU 4000 MTU 1500 MTU 1280 MTU 1500
Router A Router B Router C
ICMP
Host B
(3)
Host A
MTU 4000 MTU 1500 MTU 1280 MTU 1500
Router A Router B Router C
Host B
(4)
Host A
(I)
MTU 4000 MTU 1500 MTU 1280 MTU 1500
Router A Router B Router C
Host B
(II)
Abbildung 22: Fragmentierung von IPv6-Datagrammen [RFC1981]
IPv6 gegenüber IPv4 ein wenig anders gehandhabt. Alle Felder im IPv4-Protokollkopf, die bisher zur
Fragmentierung eines IP-Datagramms benötigt wurden (Identification, Flags, Fragment Offset), sind
im IPv6-Basis-Protokollkopf nicht mehr vorhanden. Das liegt vorallem an der Tatsache, dass es unter
IPv6 einen Erweiterungsheader Fragmentierung gibt. Zudem geschieht die Fragmentierung bei IPv4
standardmäßig bei Host und Router gleichermaßen. Wogegen bei IPv6 durch Path MTU Discovery

3.4 Umstellung von IPv4 auf IPv6 45
die Fragmentierung nur noch beim Host stattfindet. Da sich die Berechnung der Prüfsumme bei IPv4
nachteilig auf die Leistung der Datenübertragung ausgewirkt hat, wurde das Feld Checksum ist nicht
mehr in IPv6 implementiert. Eine Prüfsumme existiert bereits auf der Transportschicht, weshalb innerhalb
der Vermittlungsschicht keine weitere Prüfsumme notwendig sei.
Die Sicherheit ist ein große Thema, welches auch vor dem Internet Protokoll nicht Halt macht. IPsec
(Internet Protokoll Security) heißt dort die Lösung. Unter IPv4 ist die Unterstützung von IPsec optional,
in IPv6 aber Pflicht.
IPv4 sendet über die Broadcast Adressen an alle Knoten eines Teilnetzes ein IP-Datagramm. Unter
IPv6 gibt es keine Broadcast Adressen sondern nur noch Multicast.
Auch musste man unter IPv4 jedem Knoten manuell oder durch Konfiguration von DHCP eine IP-
Adresse zuweisen. Das geschieht unter IPv6 nun vollautomatisch anhand der MAC-Adresse und
Neighbor Solocitation.
Die minimale Link MTU des Internet Protokolls wurde von 86 Bytes bei IPv4 auf 1280 Bytes bei IPv6
angehoben. Somit kann selbst bei Fehlern während der Path MTU Discovery der IPv6-Quellhost IP-
Datagramme mit 1280 Bytes senden, anstatt sich auf 86 Bytes beschränken zu müssen.
Die maximale IP-Datengrammgröße wurde allerdings wie bei IPv4 bei 64 Kbyte belassen, allerdings
existiert ein Erweiterungsheader bei IPv6 mit dem Jumbogramme gesendet werden können.
3.4 Umstellung von IPv4 auf IPv6
Eine Umstellung von IPv4 auf IPv6 ist sehr problematisch. Zwar ist IPv6 abwärtskompatibel, aber installierte
IPv4-System, wie Router, können keine IPv6-Datagramme handhaben. Es ist enorm schwierig,
Protokolle der Vermittlungsschicht zu ändern. In [KK02] wird folgendes festgestellt:
Die Einführung neuer Protokolle auf der Vermittlungsschicht kommt ungefähr dem Austausch des
”
Fundaments eines Hauses gleich – das Ganze lässt sich kaum bewältigen, ohne das ganze Haus abzureißen
oder zumindestens alle Bewohner vorrübergehend zu evakuieren.“
Es gibt drei mögliche Szenarien wie eine Umstellung vonstatten gehen kann. In [RFC2893] werden
IPv6 Übergangsmethoden ausführlich beschrieben. Eine erste aber eher unwahrscheinliche Umstellungsart
wäre die des Stichtages. An einem Tag sollen alle IPv4-Knoten runtergefahren werden und
dann als IPv6-Knoten wieder gebootet werden.
Eine zweite, weichere Umstellungsart ist die des Dual-Stack“. Dual-Stacks erlauben den Mischbetrieb
von IPv6 und IPv4, d.h. jeder Knoten sollte IPv4- und IPv6-Datagramme senden und empfan-
”
gen können. Abbildung 23 zeigt schematisch zwei Dual-Stacks. Eine dritte Umstellungsart tunnelt
die gesendeten Daten zwischen zwei IPv6-Host durch eine IPv4-Infrastruktur. Dies erfordert auf der
IPv4-Ebene eine Multicast-Fähigkeit. Aktuell ist so ein IPv6-Tunnelnetz schon im Einsatz. Es heißt
6Bone, in Anlehnung an den Multicast-Backbone MBONE von IPv4. In diesem Tunnelnetz sind sogenannte
IPv6-Inseln durch statische Tunnel miteinander verbunden. Abbildung 24 zeigt schematisch
einen aufgebauten Tunnel. Inzwischen ist es auch möglich dynamische Tunnel automatisch öffnen zu

46 3 DAS INTERNET PROTOKOLL
Abbildung 23: Dual-Stacks: Mischbetrieb von IPv6 und IPv4 [ct1601]
Abbildung 24: IPv6 over IPv4: zwei IPv6-Hosts tauschen Daten über einen per Multicast aufgebauten
Tunnel durch das IPv4-Netz aus [ct1601]
lassen.
Eines ist aber gewiess; die Umstellung geschieht in Hosts, ebenso wie in Routern und auch einige
Programme müssen soweit dies überhaupt möglich ist umprogrammiert werden. Die Umstellung
in LANs kann schon heute geschehen. Bei Hubs und Switches, welche im LAN zum Einsatz kommen
sind heutzutage keine Änderungen für IPv6 vorzunehmen. Fast alle gängigen Betriebssysteme
wie Linux, Windows XP & Co., Solaris und selbst MAC OS X unterstützen IPv6. Somit sind einer
Umstellung im LAN von IPv4 auf IPv6 keine Steine in den Weg gelegt. Router-Firmen wie CISCO
unterstützen auch schon IPv6, zumindestens in Beta-Versionen. Es wird erst die Zeit zeigen, ob sich
IPv6 auf breiter Ebene durchsetzen wird. Asien und auch Europa sind die Vorreiter. Die USA holt
langsam auf. Manche Adminstratoren, Firmen u.a. sehen nicht die Notwendigkeit einer zeitaufwenigen
und arbeitsintensiven Umstellung, da viele Vorteile von IPv6 auf IPv4 zurückportiert wurden.

47
4 Zusammenfassung
Das Internet Protokoll ist das Fundament des Internets. Zu den Stärken des Internet Protokolls zählt
die Übertragung von Daten auch über heterogene Netze hinweg. Dazu benutzt es ein IP-Datagramm
als Basiseinheit für den Transfer in einem TCP/IP-Internet. Um Daten von einem Quellhost zu einem
Zielhost senden zu können, bedient sich das Internet Protokoll seiner IP-Adressen, die ein Interface
im Internet eindeutig identifiziert. Um nun auch über heterogenen Netze mit unterschiedlichen MTUs
Daten zum Zielhost senden zu können, beherrscht das Internet Protokoll die Fragmentierung von
IP-Datagrammen. Die Adressierung und die Fragmentierung sind die Basisfunktionen welche das Internet
Protokoll implementiert.
Das Internet Protokoll Version 4 leistet schon seit über 20 Jahren gute Dienste, aber die Adressen
werden knapp. Seit über 10 Jahren wird deshalb immer wieder an neuen Methoden gearbeitet, um
dieses und andere Mankos auszugleichen. Doch seit 1995 gibt es neues Internet Protokoll, welches
das Alte ablösen soll. Das Internet Protokoll Version 6 bietet statt der alten 32-Bit-Adressierung eine
128-Bit-Adressierung. IPv6 weist noch viele Merkmale von IPv4 auf, aber beide Protokolle unterscheiden
sich in Details.
Bei allen Problemen des IPv4, darf man eines nicht außer Acht lassen: Das Internet Protokoll Version
4 wurde entwickelt, bevor es überhaupt PCs oder Workstations, das Ethernet oder andere LAN-
Technologien gab. Es existierte schon, da hatte man an Millionen von Nutzern, Chat und Videostreaming
noch nicht mal gedacht, da waren 100.000 Hosts noch Utopie. Zudem wurden viele Vorteile
von IPv6 mit mehr oder weniger Erfolg auf IPv4 zurückportiert, das ist gut für IPv4 aber schlecht
für die Durchsetzung von IPv6. Ob und wann sich IPv6 durchsetzen wird, werden die nächsten Jahre
zeigen.

48 LITERATUR
Literatur
[KK02]
Kurose J.F., Keith W.R.: Computernetze - Ein Top-Down-Ansatz mit Schwerpunkt Internet.
Addison-Wesley, 2002
[TA02] Tanenbaum A.S.: Computer Networks. Pretice Hall, 4. Edition, 2002
[CO02] Comer D.E.: Computernetzwerke und Internets. Prentice Hall, 3. Auflage, 2002
[RFC791] Postel J.: RFC 791 - Internet Protocol. September 1981
[RFC792] Postel J.: RFC 792 - Internet Control Message Protocol. September 1981
[RFC950] Mogul J., Postel J.: RFC 950 - Internet Standard Subnetting Procedure. August 1985
[RFC1191] Mogul J. and Deering S.: RFC 1191 - Path MTU Discovery. November 1990
[RFC1519]
[RFC1878]
Fuller V., Li T., Yu J., Varadhan K.: RFC 1519 - Classless Inter-DomainRouting (CI-
DR): an Address Assignment and Aggregation Strategy. September 1993
Pummill T., Manning B.: RFC 1878 - Variable Length Subnet Table For IPv4. December
1995
[RFC1191] Mogul J.C., Deering S.E.: RFC 1191 - Path MTU discovery. November 1990
[RFC1918]
Rekhter Y., Moskowitz B., Karrenberg D. , de Groot G.: RFC 1918 - Address Allocation
for Private Internets. February 1996
[RFC1700] Reynolds J., Postel J.: RFC 1700 - Assigned Numbers. October 1994
[RFC2113] Katz D.: RFC 2113 - IP Router Alert Option. February 1997
[RFC2236]
Fenner W.: RFC 2236 - Internet Group Management Protocol, Version 2. November
1997
[RFC2460] Hinden R., Deering S.: RFC 2460 - Internet Protocol Version 6. December 1998
[RFC2463]
Conta A., Deering S.: RFC 2463 - Internet Control Message Protocol for the Internet
Protocol Version 6. December 1998
[RFC2402] Kent S.,Atkinson R.: RFC 2402 - IP Authentication Header. November 1998
[RFC2406]
[RFC2474]
Kent S.,Atkinson R.: RFC 2406 - IP Encapsulating Security Payload (ESP). November
1998
Nichols K., Blake S., Baker F., Black D.: RFC 2474 - Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers. December 1998

LITERATUR 49
[RFC2373] Hinden R., Deering S.: RFC 2373 - IP Version 6 Addressing Architecture. July 1998
[RFC1981] McCann J., Deering S., Mogul J.: RFC 1981 - Path MTU Discovery for IP version 6.
August 1996
[RFC2893]
Gilligan R., Nordmark E.: RFC 2893 - Transition Mechanisms for IPv6 Hosts and Routers.
August 2000
[HU97] Hunt C.: TCP/IP Network Administration. O’Reilly, December 1997
[ct1601] Felix von Leitner: Das nächste Netz. c’t 16/2001
[RFC2461]
Narten T., Nordmark E., Simpson W.: RFC 2461 - Neighbor Discovery for IP Version
6 (IPv6). December 1998
[RFC2923] Lahey K.: RFC 2923 - TCP Problems with Path MTU Discovery . September 2000
[isc.org]
[ipv6.org]
http://www.isc.org/
http://www.ipv6.org/