IPv4 und IPv6 Proseminar: Internetprotokolle fur die ... · Protokoll: Protokolle sind Regeln, die den Nachrichtenaustausch – oder allgemeiner das Verhal- ten – zwischen (Kommunikations)Partnern

Rheinisch-Westfalische Technische Hochschule AachenLehrstuhl fur Informatik IV

Prof. Dr. rer. nat. Otto Spaniol

IPv4 und IPv6

Proseminar: Internetprotokolle fur dieMultimediakommunikation

Michael Schmitz

Matrikelnummer: 234902

Betreuung: Mesut GunesLehrstuhl fur Informatik IV, RWTH Aachen

2 INHALTSVERZEICHNIS

Inhaltsverzeichnis

1 Einleitung 6

2 Grundlagen 7

2.1 Eine kurze Geschichte des Internets. . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Klarung 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 Allgemeinesuber 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 Schwachen des IPv4. . . . . . . . . . . . . . . . . . . . . . 31

3.2 Das Internet Protokoll Version 6 - IPv6. . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Allgemeinesuber IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.2 IPv6-Protokollkopfformat. . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.3 IPv6-Erweiterungsprotokollkopfe . . . . . . . . . . . . . . . . . . . . . . . 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) Marz 1971, (d) April1971, (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 Datenuber einen per Multicast aufgebau-ten Tunnel durch das IPv4-Netz aus [ct1601] . . . . . . . . . . . . . . . . . . . . . 46

TABELLENVERZEICHNIS 5

Tabellenverzeichnis

1 Eine IPv4-Adresse in Punkt-Dezimal-Notation, gepunkteter hexadezimaler und inbinarer Schreibweise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Lange des Netzwerk- und Hostanteils und Maximale Anzahl der Netzwerke undHosts in der jeweiligen IPv4-Adressklasse. . . . . . . . . . . . . . . . . . . . . . . 24

3 Die IPv4-Standardnetzwerkmasken der Klasse A, B und C.. . . . . . . . . . . . . . 25

4 Drei Blocke des IP-Adressraums sind fur private Netzwerke reserviert.. . . . . . . . 26

5 Klassenlose Adressierung (CIDR): Aufteilung der verbliebenen Klasse C in vier Zonen28

6 Eine IPv6-Adresse in binarer 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 ei-

nem Dorf“ machen. Es gibt keine wirkliche Netzstruktur – das Ruckgrat des Internets sind mehreregroßere Backbones. Diese Backbones werden aus schnellen Routern und Leitungen mit sehr hoherBandbreite gebildet. Netzwerke von Universitaten, Behorden, Service-Providern und Unternehmenwerden zu großeren regionalen Netzwerken zusammengeschlossen und sind an die Backbones ange-schlossen. Und genau dort braucht man ein Protokoll, welches die verschiedensten Netze zu einemzusammenschließt. DasInternet Protokoll ist der Leim, der alles zusammenhalt.

Jeder der sich mit Computer beschaftigt kennt es, jeder der schon einmal eine Verbindung mit demInternet hergestellt hat kommt nicht an ihm vorbei. Doch wer hat sich wirklich mit dem Internet Pro-tokoll beschaftigt? Jeder kennt seineaußere Erscheinungsform: Die Adresse, wie etwa 194.95.176.70oder gar schon 1234:5678:9ABC:DEF0:0123:4567:89AB:CDEFJeder weiß auch sicherlichuber die

”Adressenknappheit“ Bescheid und das ein neues Protokoll, das

IPv6 oder IPng, das alte IPv4 ablosen soll.

In dieser Ausarbeitung soll ein Einblick in diese zwei grundlegenden Protokolle des Internets ermoglichtwerden.

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 Hohepunkt. Das US-Verteidigungsminis-

terium (Department of Defense - DoD) forderte eine Netzwerktechnologie, die in einem hohen Maßgegenuber Ausfallen sicher ist. Das Netz sollte dazu in der Lage sein, auch im Falle eines Atomkriegesweiter zu operieren. Eine Datenubermittlunguber Telefonleitungen war zu diesem Zweck nicht geeig-net, da diese gegenuber Ausfallen zu verletzlich waren und auch heute noch sind. Aus diesem Grundbeauftragte das US-Verteidigungsministerium dieAdvanced Research Projects Agency(ARPA) mitder Entwicklung einer zuverlassigen Netztechnologie. 1957 als Reaktion auf den Start des Sputniksdurch die UdSSR gegrundet und hatte die ARPA die Aufgabe Technologien zu entwickeln, die fur dasMilit ar von Nutzen sind. Zwischenzeitlich wurde die ARPA in Defense Advanced Research ProjectsAgency (DARPA) umbenannt, da ihre Interessen primar militarischen Zwecken dienten. Die ARPAwar keine Organisation, die Wissenschaftler und Forscher beschaftigte, sondern verteilte Auftrage anUniversitaten und Forschungsinstitute.

Um die geforderte Zuverlassigkeit des Netzes zu erreichen, fiel die Wahl darauf, das Netz als einpaketvermitteltes Netz(packet-switched network) zu gestalten. Bei der Paketvermittlung werden zweiPartner wahrend der Kommunikation nur virtuell miteinander verbunden. Die zuubertragenden Datenwerden vom Absender in Stucke variabler oder fester Lange zerlegt unduber die virtuelle Verbindungubertragen; vom Empfanger werden diese Stucke nach dem Eintreffen wieder zusammengesetzt.

Schon im Dezember 1969 wurde von der University of California Los Angeles (UCLA), der Univer-sity of California Santa Barbara (UCSB), dem Stanford Research Institute (SRI) und der Universityof Utah (UTAH) ein experimentelles Netz, das ARPANET, mit vier Knoten in Betrieb genommen.Diese vier Universitaten wurden von der ARPA gewahlt, da sie bereits eine große Anzahl von ARPA-Vertragen hatten. Abbildung1 zeigt das schnelle Wachstum des ARPA-Netzes. Esuberspannte baldein großes Gebiet der Vereinigten Staaten von Amerika. In der nachsten Zeit entstanden viele paket-vermittelnde Netzwerke mit zum Teil unterschiedlichen Architekturen. Jedes dieser Netzwerke hattesein eigenes Protokoll. Mit der Zeit und dem Wachstum des ARPANET wurde klar, dass die bis dahingewahlten Protokolle nicht mehr fur den Betrieb eines großeren Netzes, das auch mehrere (hetero-gene) Teilnetze miteinander verband, geeignet war. Aus diesem Grund wurden schließlich weitereForschungsarbeiten initiiert.Die beiden Wissenschaftler Vinton Cerf und Robert Kahn erfanden einnetzubergreifendes 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 wurdespater 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 ArbeituberTCP/IP veroffentlicht. Zudem wurde auch das bekannte TCP/IP-Modell entwickelt, welches im Ka-pitel 2.3.2behandelt 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) Marz 1971, (d) April1971, (e) September 1972. [TA02]

zur Datenubertragung miteinander zu verbinden. Vor allem sollte es eine breite Unterstutzung furkunftige Anwendungen ermoglichen. Um die Einbindung der TCP/IP-Protokolle in das ARPANETzu forcieren beauftragte die DARPA die Firma Bolt, Beranek & Newman (BBN) und die Universi-ty of California at Berkeley zur Integration von TCP/IP in Berkeley UNIX. Dies bildete auch denGrundstein 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 ARPAubernahm, aufgeteilt. Der militarische Teil desARPANET, wurde in ein separates Teilnetz, das MILNET abgetrennt, das durch streng kontrollierteGateways vom Rest des ARPANET - dem Forschungsteil - separiert wurde.

Nachdem TCP/IP das einzige offizielle Protokoll des ARPANET wurde, nahm die Zahl der ange-schlossenen Netze und Hosts rapide zu. Viele bestehende Netze wurden an das APRANET ange-schlossen.

Das ARPANET wurde von Entwicklungen, die es selber hervorgebracht hatte,uberrannt. Es existiertin seiner ursprunglichen Form heute nicht mehr, das MILNET ist aber noch in Betrieb.

2.2 Klarung wichtiger Begriffe 9

Die Sammlung von Netzen, die das ARPANET darstellte, wurde zunehmend als Netzverbund betrach-tet. Dieser Netzverbund wird heute allgemein als das Internet bezeichnet und basiert immer noch aufdem IP-Protokoll. Doch seitdem das Internet nicht mehr nur etwas fur Wissenschaftler und Freaksist, 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 ange-kommen, wo das

”gute, alte“ Internet Protokoll Version 4 langsam ausgedient hat und ein neues in

seine Fußstapfen treten soll: IPv6.

2.2 Klarung wichtiger Begriffe

Im Folgenden wird eine Terminologie eingefuhrt, wie sie u.a. in [RFC2460] benutzt wird. Weiter-hin werden noch grundlegende Begriffe definiert, die in dieser Ausarbeitung benutzt werden und dienicht immer eindeutig sind. Nicht alle Bucher und Dokumente, besonders die

”Alteren“ verwenden

zwangslaufig diese Terminologie und entsprechend sind unter Umstanden beim Lesen dieser Litera-tur

”mentale Abbildungen“ notwendig. Zudem werden in dieser Ausarbeitung soweit moglich und

sinnvoll die deutschen Begriffe verwendet.

Protokoll: Protokolle sind Regeln, die den Nachrichtenaustausch – oder allgemeiner das Verhal-ten – zwischen (Kommunikations)Partnern regeln (

”Protocols are formal rules of behaviour“).

Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie so-gar ganzlich unmoglich. Ein Beispiel fur ein Protokoll

”aus dem taglichen Leben“ ist z.B. der

Funkverkehr: Die Kommunikationspartner bestatigen den Empfang einer Nachricht mit”Ro-

ger“ und leiten einen Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindungschließlich mit

”Over and Out“.

Knoten: Ein Gerat 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 Auswer-tung der Adresse realisiert ist.

Host: Jeder Knoten, der kein Router ist, heißt Host.

Link: Ein Kommunikationskanal,uber den Knoten miteinander kommunizieren konnen (z.B. dasEthernet, PPP links, X.25 usw.), heißt Link.

Neighbors: Alle Knoten, die an demselben Link angeschlossen sind, heißen Neighbors (Nachbarn).

Interface: Die Schnittstelle,uber 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“ubertragene Pakete.

IP-Paket und IP-Datagramm sindaquivalent.

Link MTU: (link maximum transmission unit) Die maximale Paketgroße in Bytes (8 Bits) die aufeinem Link befordert werden kann, heißt Link MTU.

Path MTU: (path maximum transmission unit) Die minimale Link MTU aller Links zwischen einemQuellknoten 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 eineoffentliche IP-Adresse (z.B. vom Pro-vider zugewiesen) umgesetzt und erlaubt so direkt auf Dienste außerhalb des LANs (z.B. desInternets) zuzugreifen.

MAC-Adresse: (Media Access Control-Adresse) Die MAC-Adresse ist eine eindeutige und einma-lig vergebene Hardware-Adresse einer Komponente im Netz, die Datenpakete selbst generierenkann (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 Netz-werk zentral von einem Server aus zu vergeben, statt diese dezentral an den einzelnen Arbeits-platzrechnern zu konfigurieren. Ein mit DHCP konfigurierter Client verfugt selbst nichtuberstatische Adressen, sondern konfiguriert sich voll und ganz selbststandig nach den Vorgabendes DHCP-Servers.

DNS: Domain Name System. Das Internet verwendet zur Adressierung IP-Adressen, die maschinelleffizient verarbeitet werden konnen aber fur Menschen nur schwer zu merken sind. Das DomainName System (DNS) ist der Unterbau, die nutzerfreundliche Namen in entsprechende Adressenabbildet. So braucht man sich lediglich z.B. www.deutschland.de anstelle von 194.95.176.70 zumerken.

2.3 Das ISO-OSI-Referenz und das TCP/IP-Schichtenmodell

2.3.1 Das ISO-OSI-Referenzmodell

1979 entwickelte dieInternational Standards Organization(ISO) als Basis fur eine internationaleStandardisierung 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 wirdals OSI-Modell (Open Systems Interconnection) bezeichnet. Offiziell heißt dieses Modell ISO-OSI-Referenzmodell. Abbildung2 stellt dieses Modell dar.

Transportschicht

Netzwerkschicht

Sicherungsschicht

Bitübertragungsschicht

garantiert die fehlerfreieDatenübertragung durch

verwaltet die Verbindungen zwischenden Rechnern im Netzwerk für diehöheren Schichten

sorgt für die zuverlässige Übertragungder Daten über die physikalischenVerbindungen

definiert die physikalischenEigenschaften der Übertragungswege

Tra

nsp

ort

syst

em

Anwendungsschicht

Darstellungsschicht

Sitzungsschicht

besteht aus den Anwendungen mitdenen man das Netzwerk nutzen kann

standardisiert das Format der Datenauf dem Netzwerk

verwaltet die Verbindungen zwischenden Anwendungen

An

wen

du

ngss

yste

m

Host A

Tra

nsp

ort

Sys

tem

Transport Layer

Data Link Layer

Physical Layer

Network Layer

Appli

cati

on

Sys

tem

Application Layer

Presentation Layer

Session Layer

Host B

phys. Medium phys. Media

Sicherungs-schicht

Bitübertra-gungsschicht

Netzwerk-schicht

Data LinkLayer

PhysicalLayer

NetworkLayer

Router A Router BSubnetz

Medium

Protokolle(Protocols)

Schicht(Layer)

7

6

5

4

3

2

1

(Anwendungsprotokoll)

( )Darstellungsprotokoll

( )Sitzungsprotokoll

( )Transportsprotokoll

(g)

(f)

(e)

(e) Host/Router-Netzwerkschicht rotokoll(f)(g)

pHost/Router-SicherungsschichtprotokollHost/Router-Bitübertragungsschichtprotokoll

(h) Subnetzprotokoll(i) Subnetzprotokoll(j) Subnetzprotokoll

(j)

(i)

(h)

Abbildung 2: ISO-OSI-Referenzmodell

Jeder Schicht sind bestimmte, genau definierte Aufgaben zugeordnet. Die einzelnen Schichten werdenim Folgenden kurz beschrieben, wobei die Abbildung2 fast schon selbsterklarend ist. Das Haupt-augenmerk liegt aber auf der Netzwerkschicht (network layer), da dort das Internet Protokoll (IP)einzuordnen ist.

Anwendungsschicht: (application layer) Die Anwendungsschicht enthalt eine große Zahl haufigbenotigter Protokolle, die einzelne Programme zur Erbringung ihrer Dienste definiert haben.

12 2 GRUNDLAGEN

Darstellungsschicht: (presentation layer) Die Darstellungsschicht regelt die Darstellung derUber-tragungsdaten in einer von der daruber liegenden Ebene unabhangigen Form, indem sie dieDaten auf eine standardisierte und vereinbarte Weise kodiert.

Sitzungsschicht: (session layer) Die Sitzungsschicht ermoglicht den Verbindungsauf- und abbau.Von der Sitzungsschicht wird der Austausch von Nachrichten auf der Transportverbindung ge-regelt. Sitzungen konnen z.B. ermoglichen, ob der Transfer gleichzeitig in zwei oder nur eineRichtung erfolgen kann. Kann der Transfer jeweils in nur eine Richtung stattfinden, regelt dieSitzungsschicht, welcher der Kommunikationspartner jeweils an die Reihe kommt.

Transportschicht: (transport layer) Die Transportschichtubernimmt den Transport von Nachrichtenzwischen den Kommunikationspartnern. Die Transportschicht hat die grundlegende Aufgaben,den Datenfluß zu steuern und die Unverfalschtheit der Daten sicherzustellen.

Netzwerkschicht: (network layer) Die Netzwerkschicht hat die Hauptaufgabe eine Verbindung zwi-schen Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei dieubergeordnetenSchichten von den Details der Datenubertragunguber das Netzwerk befreien. Eine der wich-tigsten Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das Routingvon einem Quell- zu einem Zielhost. Die Routen konnen statisch sein, also sich nur seltenandern oder hochdynamisch sein und fur jedes Paket neu fur eine optimale Netzauslastung neubestimmt werden. Die Streuung von Staus, die bei zu vielen Pakten in einem Teilnetz entste-hen konnen, ist auch Aufgabe der Vermittlungsschicht. Ein Problem ist es auch das ein Paketunter Umstanden mehrere Netze durchlauft welche die Paketgroße nicht annimmt. Dann mußdie Vermittlungsschicht dafur sorgen, dass das Paket fragmentiert und wieder defragmentiertwird. Hingegen ist bei Broadcast-Netze das Routing-Problem einfach, und damit ist die

”Ver-

mittlungsschicht“ dort dunn oder gar nicht vorhanden.

Sicherungsschicht: (data link layer) Die Aufgabe der Sicherungsschicht ist die gesicherteUber-tragung von Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt undsequentiell an den Empfanger gesendet. Vom Empfanger werden die empfangenen Daten durchBestatigungsrahmen quittiert.

Bit ubertragungsschicht: (physical layer) Die Bitubertragungsschicht regelt dieUbertragung1 vonBits uber dasUbertragungsmedium. Die Festlegungen auf der Bitubertragungsschicht betreffenim wesentlichen die Eigenschaften desUbertragungsmedium.

2.3.2 TCP/IP-Schichtenmodell

Das TCP/IP-Schichtenmodell wird im Großvater aller Rechnernetze, dem APRANET und seinemNachfolger, dem Internet, eingesetzt [TA02] und wurde schon Mitte der 1970er2 Jahre entwickelt.

1Ubertragungsgeschwindigkeit, Bit-Codierung, Anschluß, usw.2TCP/IP-Modell wurde vor dem ISO-OSI-Modell entwickelt.


Das Internet besteht ja bekanntlich aus vielen z.T. heterogenen Netzen. Es musste also eine neue Re-ferenzarchitektur gefunden werden, die die Fahigkeit hat, mehrere heterogene Netze nahtlos zusam-menzuschließen. Das bedeutet nichts anderes, als dass Daten eventuell zwischen unterschiedlichenRechnern mit unterschiedlichen Betriebssystemen, die sich in unterschiedlichen Netzwerktopologienmit unterschiedlichen Protokollen befinden, ausgetauscht werden mussen. Das von Cerf und Kahnentwickelte TCP/IP-Protokoll kann die

”Verbindung“ zwischen heterogenen Netzwerke herstellen.

Ein neues Referenzmodell war entstanden, welches im Gegensatz zu dem ISO-OSI-Referenzmodelleine Beschreibung der Protokolle ist.Die Ahnlichkeiten zwischen den beiden Modellen zeigt Abbildung3. Die verschiedenen Anforde-

rungen fuhrten letztendlich zu der Wahl eines paketvermittelten Netzes auf der Grundlage einer ver-bindungslosen Vernetzungsschicht. Die einzelnen Schichten werden im Folgenden kurz beschrieben.

Application Layer

Host-to-Host Transport Layer

Internet Layer

Network Access Layer

Transport Layer

Data Link Layer

Physical Layer

Network Layer

Application Layer

Presentation Layer

Session Layer

ISO/OSI-Referenzmodell

TCP/IP-Modell

Abbildung 3: Vergleich ISO-OSI-Referenzmodell und TCP/IP-Modell

Abbildung4 zeigt das vierschichtige TCP/IP-Modell. Das Hauptaugenmerk liegt wieder auf der In-ternetschicht (internet layer), da dort das Internet Protokoll definiert ist.

Anwendungsschicht: (application layer) Die Anwendungsschicht umfaßt alle hoherschichtigen Pro-tokolle des TCP/IP-Modells. Zu den ersten Protokollen der Anwendungsschicht zahlten FTP,TELNET und SMTP. Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitereProtokolle wie z.B. DNS und HTTP hinzu.

Transportschicht: (transport layer) Wie im OSI-Modell ermoglicht die Transportschicht die Kom-munikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieserSchicht zwei Ende-zu-Ende-Protokolle definiert: das Transmission Control Protocol (TCP) unddas User Datagram Protocol (UDP).

14 2 GRUNDLAGEN

Transportschicht

Internetschicht

Netzwerkzugriffsschicht

stellt End-to-End-Datendienste zurVerfügung

definiert den Aufbau vonDatagrammen und routet Daten

enthält Routinen für den Zugriff aufphysikalische Netze

Anwendungsschichtenthält Anwendungen und Prozesse,die auf das Netzwerk zugreifen

Host A

Host-to-HostTransport Layer

Network AccessLayer

Internet Layer

Application Layer

Host B

Netzwerk-schicht

Internet-schicht

NetworkLayer

InternetLayer

Router A Router B

Subnetz

phys. Medium phys. MediaMedium

Protokolle(Protocols)

Schicht(Layer)

4

3

2

1

(a) Anwendungsschicht rotokoll (FTP, TELNET,...)(b) TCP (Transmission Transport P

UDP (User Datagram Protocol)(c) Internet Protocol

protocol)

(d) Netzwerkzugriffsschichtprotokoll

(a)

(b)

(c)

(d)

Abbildung 4: TCP/IP-Schichtenmodell

Internetschicht: (internet layer) Die Internetschicht definiert nur ein Protokoll, das Internet Pro-tokoll (IP - Internet Protocol) [RFC791, RFC2460], das alle am Netzwerk beteiligten Rech-ner verstehen konnen. Wie schon erwahnt ist sie eine verbindungslose

”Vernetzungsschicht“,

welche wie”die Sicherheitsnadel, die die gesamte Architekur zusammenhalt“[TA02] ist. Die

Internetschicht hat die Aufgabe IP-Datagramme richtig und unabhangig vom jeweiligen Netzzuzustellen.In [TA02] wird eine Analogie zur Internetschicht beschrieben:

”Eine Analogie dazu ware die gelbe Post. Eine Person wirft eine Reihe von Auslandsbriefen in

einem Land in einen Briefkasten, und mit ein wenig Gluck werden die meisten an die richtigeAdresse im Zielland zugestellt. Die Briefe bereisen wahrscheinlich eine oder mehrere interna-tionale Sammelstellen (Gateways) auf ihrem Weg, was fur den Benutzer allerdings transparentist. Dass jedes Land (d.h. Netz) seine eigenen Briefmarken, bevorzugte Umschlagsformate undZustellungsregeln hat, ist dem Benutzer auch egal.“

Das Routing der Pakete spielt eine wichtige Rolle, ebenso das Vermeiden vonUberlastungen.Das Internet Control Message Protocol (ICMP) [RFC792, RFC2463] ist fester Bestandteil jederIP-Implementierung und dient zurUbertragung von Diagnose- und Fehlerinformationen fur dasInternet Protokoll.

Netzwerkzugriffsschicht: (network access layer) Unterhalb der Internetschicht befindet sich im


TCP/IP-Modell eine große Definitionslucke. Aber sie beinhaltet sehr hardwarenahe Dienste,z.B. Netzwerkkartentreiber. Das Referenzmodell sagt auf dieser Ebene nicht viel daruber aus,was hier passieren soll. Festgelegt ist lediglich, dass zurUbermittlung von IP-Paketen ein Hostuber ein bestimmtes Protokoll an ein Netz angeschlossen werden muß. Dieses Protokoll ist imTCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. DasTCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokol-len, 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, derdas Internet zusammenhalt. Fakt ist, dass das aktuelle Internet Protokoll (IPv4) seit Jahrzehnten er-folgreich im Einsatz ist. Dem Internet Protokoll ist es zu verdanken, dass das Internet so erfolgreichwurde. Denn selbst einschneidendeAnderungen von Hardwaretechnologien und der Internet-Boomin den 1990ern und vor allem die Fahigkeit heterogene Netzwerke zusammenzuschließen hat das In-ternet Protokoll souveran gemeistert. Die Heterogenitat ist es auch, was das Internet heute ausmacht.Das Internet Protokoll wurde von Anfang an mit Blick auf Netzverbund ausgelegt. Es definiert eineinheitliches Paketformat und einen Pakettransfermechanismus um Datenuber heterogene Netzwerkezu ubertragen. Dabei benutzt es sogenannte IP-Adressen, welche unabhangig vom jeweiligen Netz-werk sind, unduber denen es Anwendungen und Protokolle hoheren Schichten des TCP/IP-Modellsmoglich ist, selbstuber heterogene Netzwerke miteinander zu kommunizieren. In diesem Kapitelwird 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 Versionnummer5 schon an ein experimentelles Protokoll vergeben war. Das IPv5 war an ein Protokoll fur Echtzeit-Strome, das ST-2 (Internet Stream Protocol Version 2) hieß und von RSVP (ReSerVation Protocolzur Bandbreitenanforderung bei Routern) abgelost wurde, vergeben. ST-2 sollte einst Audio- und Vi-deosignale per Multicastubertragen konnen und die Bandbreiten-Reservierungsvorteile von ATM inIP-Netze bringen, gelang aber nie zur Serienreife.

3.1 Das Internet Protokoll Version 4 - IPv4

3.1.1 Allgemeinesuber IPv4

DasInternet 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 imLauf der Zeit den Erfordernissen angepasst.

Das Internet Protokoll empfangt von der Transportschicht im sendenden Host einSegment, verkap-selt jenes in ein bestimmtes Paketformat, demIP-Datagramm, und sendet es an den ersten Routerauf den Pfad zum Zielhost. Die Menge an Nutzdaten in einem IP-Datagramm ist nicht zwingend vor-geschrieben. Jedoch kann ein IP-Datagramm maximal 64 Kbyte groß sein. Der prinzipielle Aufbaueines IP-Datagramm respektive des IP-Paketes wird in Abbildung5 gezeigt.Das Internet Protokoll ist einverbindungsloses Protokoll, d.h. zur Datenubertragung wird keine

Ende-zu-Ende Verbindung der Kommunikationspartner etabliert. Eine Ende-zu-Ende Verbindung be-deutet, dass es eine Verbindung direkt von einer Anwendung eines Quellhosts zu einer Anwendungeines Zielhosts gibt; w.z.B. bei TCP. Das heißt im Umkehrschluss, dass jeder Router, der das IP-Datagramm empfangt, den Protokollkopf auslesen muss, bevor er es weitersenden kann. Das Internet

3.1 Das Internet Protokoll Version 4 - IPv4 17

IPv4 Protokollkopfggf. mit Optionen Daten

20 - 60 Bytes

Abbildung 5: Das IPv4-Paketformat:IP-Datagramm[RFC791]

Protokoll implementiert zwei Basisfunktionen:AdressierungundFragmentierung. Die Adressierunggeschieht mit Hilfe derIP-Adresse. Das Kapitel3.1.4behandelt ausfuhrlich die IPv4-Adresse. DieIP-Adresse wird im IP-Protokollkopf gefuhrt und dient derUbertragung eines IP-Datagrammes voneinem Quellhost zu einem Zielhost. Die Auswahl des Pfades fur dieUbermittlung heißtrouting. DasIP-Datagramm kann fragmentiert werden, wenn es fur die Ubermittlung notig ist. Die Fragmentie-rung wird in Kapitel3.1.8behandelt. Die Aufgabe des Internet Protokolls ist also die Bereitstellungeiner Moglichkeit IP-Datagramme von einem Quellhost zu einem Zielhost zu befordern. Dabei istes unerheblich, ob sich der Quellhost und der Zielhost im gleichen Netz befinden oder ob andere(heterogene) Netze dazwischenliegen. Routerubernehmen die Aufgabe der Auswahl des Pfades furdie Ubermittlung. Jeder Router leitet das IP-Datagramm weiter, indem er die ausgelesene Zieladressemit einer Routing-Tabelle indiziert und das IP-Datagramm in Richtung des Zielhosts weiterleitet.Da diese Routing-Tabellen jederzeit modifiziert werden konnen, kann es vorkommen, dass die IP-Datagramme, die von einem Quellhost zu einem Zielhost gesendet werden, unterschiedliche Routendurch das Netzwerk nehmen und moglicherweise außer der Reihenfolge ankommen [KK02]. IP bie-tet zurUbertragung nur den sogenannten

”Best-Effort“-Dienstan, d.h. das Internet Protokoll garan-

tiert nicht, dass die IP-Datagramme in einer bestimmten Zeit, in der richtigen Reihenfolge oder garuberhaupt am Zielhost ankommen. Es verfugt auchuber keine Mechanismen zur Fehlererkennungund -behebung, außer einer Protokollkopf-Prufsumme und dem

”Internet Control Message Protocol“

(ICMP) [RFC792], welches fest mit dem Internet Protokoll verbunden ist. Aufgrund diesen Mangelsnennt man das Internet Protokoll auch ein

”unzuverlassiges“ Protokoll.

3.1.2 IPv4-Protokollkopfformat

Abbildung6 zeigt das Protokollkopfformat eines IPv4-Datengramms [RFC791].

Version: 4 BitsDas FeldVersionenthalt die Versionsnummer des IP-Protokolls. Der Wert ist 4. Der eigentlicheSinn dieses Feldes ist, dass derUbergang zwischen den Versionen Monate oder Jahre dauernkann, wobei einige Maschinen mit der alten Version, andere mit der neuen Version laufen.


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

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

Abbildung 6: IPv4-Protokollkopfformat [RFC791]

Internet Header Length: 4 BitsDas FeldInternet Header Length - IHLenthalt die Lange des gesamten IP-Protokollkopfes in32-Bit Wortern, da diese nicht konstant ist. Der fixe Teil des Protokollkopfes ist 20 Bytes3. Indiesem Fall sind im Protokollkopf keine Optionen gesetzt. Die maximale Lange des Protokoll-kopfes inklusive Optionen ist 60 Bytes4, also kann man 40 Bytes an Optionen setzen.

Type of Service: 8 BitsDie Interpretation desType of Service(TOS) Felds hat sich im Lauf der Zeit verandert. Nach

der aktuellen Interpretation enthalt das TOS-Byte einen Differentiated Services Code Point(DSCP) sowie Bits zur expliziten Benachrichtigunguber Stausituationen (explicit congestionnotification, ECN). Die Spezifikation der aktuellsten

”Version“ wird im FeldTraffic Classim

IPv6 [RFC2460] benutzt.Der Aufbau des Type of Service-Feldes nach [RFC791] :Das FeldType of Servicebestimmt die Art des Dienstes und ist in Abbildung7 aufgefuhrt. Hiersind verschiedene Kombinationen aus Zuverlassigkeit, Verzogerung und Durchsatz moglich. Inder Praxis wurde dieses Feld aber ignoriert.

Precedence:(Priorit at) (Bits 0 - 2) Mit Precedence wird dem IP-Datagramm eine Prioritat von0 (normal) bis 7 (Netzsteuerungspaket) zugewiesen.

Delay: (Verzogerung)(Bit 3)

0 Normal Delay (Normale Verzogerung)1 Low Delay (Niedrige Verzogerung)

3Der kleinste zulassige Wert dieses Feldes ist also 54Der maximale Wert dieses Feldes ist somit 15


Precedence D T R Res

D - DelayT - ThroughputR - Relibility

0 1 2 3 4 5 6 7

Abbildung 7: Type of Service - Aufbau nach [RFC791]

Throughput: (Durchsatz)(Bit 4)

0 Normal Throughput (Normaler Durchsatz)1 High Throughput (Hoher Durchsatz)

Relibility: (Zuverlassigkeit)(Bit 5)

0 Normal Relibility (Normale Zuverlassigkeit)1 High Relibility (Hohe Zuverlassigkeit)

Res: Bits 6 - 7 mussen Null sein und sind fur die Zukunft reserviert.

Der Aufbau des Type of Service-Feldes nach [RFC2474]:Die aktuelle Spezifikation ging in die IPv6-Spezifikation ein und ist im Kapitel3.2.2auf Seite33beschrieben.

Total Length: 16 BitsDas FeldTotal Lengthenthalt die gesamte Lange eines IP-Datagramms, d.h. inklusive Pro-

tokollkopf und Nutzdaten. Die Maximallange eines IP-Datagramms ist auf 65.535 Bytes be-grenzt. Jeder Host muss in der Lage sein, IP-Datagramme bis zu einer Lange von 576 Byteszu verarbeiten [RFC791]. In der Regel konnen vom Host aber IP-Datagramme großerer Langeverarbeitet werden.

Identification: 16 BitsDas FeldIdentificationenthalt einen Identifizierungswert, welcher vom Sender gesetzt wird,

um zu helfen die Fragmente eines IP-Datagrammes wieder zusammenzusetzen. Alle Fragmenteeines IP-Datagrammes enthalten somit die gleiche Identifikationsnummer.

Flags: 3 BitsDas erste Bit des FeldesFlagsist ungenutzt und muss Null sein. Die beiden andern BitsDF undMF 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 0haben, d.h.

”May Fragment“Kann fragmentiert werdenoder den Wert 1, d.h.

”Don’t Fragment“

Darf nicht fragmentiert werden. Mit dem MF-Bit wird angezeigt, ob einem IP-Datagramm


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 FragmentLetztes Fragmentoder 1,d.h. More FragmentsMehr Fragmentehaben.Die Fragmentierung wird in Kapitel3.1.8ausfuhrlich beschrieben.

Fragment Offset: 13 BitsDas FeldFragment Offsetzeigt an, an welcher Stelle relativ zum Beginn des gesamten IP-

Datagramms ein Fragment gehort. Es konnen maximal 8192 Fragmente pro IP-Datagramm er-stellt werden, da die Feldgroße nur 13 Bits lang ist. Alle Fragmente, außer dem letzten, mussenein Vielfaches von 8 Byte (64 Bits) sein. (Kap.3.1.8)

Time to Live: 8 BitsDas FeldTime to Live - TTLzeigt die maximale Lebensdauer des IP-Datagramms an. Es ist eineArt Zahler, der bei jeder Verarbeitung des Protokollkopfes um mindestens 1 verringert wird. DieEinheit 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 ineinem Netz umherwandert. Der Absender wird in einem solchen Fall durch eine Warnmeldungin Form einer ICMP-Nachricht [RFC792] informiert. Bei einer langeren Zwischenspeicherungsoll der Wert sogar mehrmals verringert werden.

Protocol: 8 BitsDas FeldProtocolenthalt die Nummer des Transportprotokolls, an welches das IP-Datagrammweitergeleitet werden muss. Die Numerierung von Protokollen ist im gesamten Internet einheit-lich und in [RFC1700] definiert.

Header Checksum 16 BitsDas FeldHeader Checksumenthalt die Prufsumme der Felder im Protokollkopf. Die Nutzda-ten des IP-Datagramm werden aus Effizienzgrunden nicht mit gepruft. Die Prufsumme mussbei jeder Verarbeitung des Protokollkopfes neu berechnet werden, da sich der Protokollkopfdurch das FeldTime to Liveverandert. Aus diesem Grund ist auch eine sehr effiziente Bil-dung der Prufsumme wichtig. Als Prufsumme wird das1er-Komplement der Summe aller 16-Bit-Halbworter der zuuberprufenden Datenverwendet. Zum Zweck dieses Algorithmus wirdangenommen, dass die Prufsumme zu Beginn der Berechnung Null ist.

Source Address: 32 BitsIn dem FeldSource Addresswird die 32 Bit lange Quelladresse eingetragen, von der das IP-

Datagramm gesendet wird. Die 32 Bit-Adresse wird ausfuhrlich im Kapitel3.1.4auf Seite22behandelt.

Destination Address: 32 BitsIn dem FeldDestination Addresswird die 32 Bit lange Zieladresse eingetragen, an die das IP-Datagramm gesendet wird. Die 32 bit-Adresse wird ausfuhrlich im Kapitel3.1.4auf Seite22behandelt.


Options: variable Anzahl von Bits.Das FeldOptionswurde im Protokollkopf aufgenommen, um die Moglichkeit zu bieten das IP-Protokoll um weitere Informationen zu erganzen, die im ursprunglichen Design nicht beruck-sichtigt wurden. Die maximale Große dieses Feldes ist 40 Bytes.

3.1.3 Optionen unter IPv4

Praktisch sind die meisten Optionen von geringer Bedeutung, da der verfugbare Platz von 40 Bytefur die meisten Optionen in der Regel zu klein ist. Jede Option beginnt mit einem Code von einemByte, uber den die Option identifiziert wird. Manchen Optionen folgt ein weiteres Optionsfeld von 1Byte und dann ein oder mehrere Datenbytes fur die Option. Das Feld Options wirduber dasPaddingauf ein Vielfaches von 4 Byte aufgefullt. Im Folgenden werden kurz neun der bekanntesten Optionenangeschnitten, die genauen Spezifikationen sind in großtenteils in [RFC791] beschrieben:

1. NOP (No Option): Keine Operation. Eine 1 Byte Option, die typischerweise zum Fullen einge-setzt wird, um eine spatere Option auf eine 4 Byte Begrenzung zu setzen.

2. EOL (End of Option List): Ende der Liste. Eine 1 Byte Option, die die Optionsverarbeitungbeendet.

3. LSRR (Loose Source and Record Route): Lose Quell- und Record-Route. Diese Option enthalteine Liste von Internet-Adressen, die das IP-Datagramm durchlaufen soll. Auf diese Weisekann dem IP-Datagramm vorgeschrieben werden eine bestimmte Route durch das Internet zunehmen. Die angegebenen Router durfen nicht umgangen werden. Auf dem Weg konnen aberauch andere Router besucht werden.

4. SSRR (Strict Source and Record Route): Strikte Quell- und Record-Route. Diese Option enthalteine Liste von Internet-Adressen, die das IP-Datagramm durchlaufen soll. Auf diese Weise kanndem IP-Datagramm vorgeschrieben werden eine bestimmte Route durch das Internet zu neh-men. Das IP-Datagramm muss diese Route genau einhalten. Des Weiteren wird die genommeneRoute aufgezeichnet.

5. Record-Route: Routenaufzeichnung. Die Knoten, die dieses IP-Datagramm durchlauft, werdenangewiesen ihre IP-Adresse an das Optionsfeld anzuhangen. Damit laßt sich ermitteln, welcheRoute ein IP-Datagrammenommen hat. Wie anfangs schon gesagt, ist die Große fur das Opti-onsfeld auf 40 Byte beschrankt. Deshalb kommt es heute auch oftmals zu Problemen mit dieserOption, da weit mehr Router durchlaufen werden, als dies zu Beginn des ARPANET der Fallwar.


6. Time Stamp: Zeitstempel. Diese Option ist mit der Option”Record Route“ vergleichbar. Zusatz-

lich zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten ver-merkt. Auch diese Option dient hauptsachlich zur Fehlerbehandlung, wobei zusatzlich z.B.Verzogerungen auf den Netzstrecken erfasst werden konnen.

7. Security: Sicherheit. Diese Option zeigt, wie geheim ein IP-Datagramm ist. In der Praxis wirddiese Option jedoch von fast allen Routern ignoriert.

8. Stream Identifier: Diese Option tragt die Stream-Identifizierung, ist aber schon sehr veraltet.

9. Router-Alert: Router-Alarm. Diese Option ist nicht in [RFC791] sondern in [RFC2113] be-schrieben. IP-Datagramme, die diese Option eingebunden haben, sollen von allen Routern un-tersucht werden, die dieses IP-Datagramm weiterleiten.

3.1.4 Aufbau einer IPv4-Adresse

Die IPv4-Adresse hat eine Lange von 32-Bit5. Eine 32-Bit-Adressierung lasst232 = 4.294.967.296mogliche Adressen zu. Sie wird normalerweise nicht als Binarzahl oder Hexadezimalzahl, sondern ingepunktenen Dezimalzahlen geschrieben. In dieser Punkt-Dezimal-Notation (Dotted Decimal Notati-on) werden alle 8 Bit dezimal geschrieben, und mit Punkten getrennt. Das IPv4-Adressenformat siehtdann folgendermaßen aus:∗.∗.∗.∗ wobei∗ eine dezimale Zahl zwischen 0 und 255 ist.Tabelle1 zeigt ein Beispiel fur verschiedene Schreibweisen ein und derselben Adresse. Aus dieser

Schreibweise Adresse

binare Schreibweise 11000010 01011111 10110000 01000110gepunktete hexadezimaleC2.5F.B0.46

Punkt-Dezimal 194.95.176.70

Tabelle 1: Eine IPv4-Adresse in Punkt-Dezimal-Notation, gepunkteter hexadezimaler und in binarerSchreibweise

Tabelle ist ersichtlich, dass die Punkt-Dezimal-Notation eine 32-Bit-Binarzahl in ein fur den Men-schen verstandlicheres Format abbildet. Der Computer benutzt normalerweise die duale Darstellung.Das ursprungliche Schema, das alsklassenbezogene Adressierung(Classful Addressing) bezeichnetwird, teilt den IP-Adressraum in drei primare Klassen (Klasse A, B und C) ein. Insgesamt gibt es aberfunf Netzwerkklassen: Klasse A, B, C, D und E. Die klassenbezogenen IP-Adressen sind selbstidenti-fizierend, da sich die Netzwerkklasse aus der IP-Adresse selbst berechnen lasst. Die Unterscheidungder einzelnen Netzwerkklassen findet in den ersten vier Bit der Adresse statt. Eine IP-Adresse der

54 Byte


Klasse A, B und C wird in einNetzwerk-und in einHostanteilgegliedert. In welchem Bit dieseGliederung stattfindet, legt die jeweilige Klasse fest.

Der Netzwerkanteilidentifiziert das physische Netzwerk, in dem sich ein Host befindet: alle Hostseines Netzes haben die gleicheNetzwerkadresse. DerHostanteilidentifiziert einen bestimmten Hostinnerhalb eines Netzes.

Abbildung8 zeigt die funf Adressklassen jeweils mit dem Hostbereich in Punkt-Dezimal-Notation.Die Netzwerkanteile der jeweiligen Adressklassen sind mitNetzund die Hostanteile mitHost ge-kennzeichnet.

Netz Host0

10

110

1110

1111

HostNetz

Netz Host

Multicast-Adresse

Für künftige Nutzung reserviert

A

B

C

D

E

Klasse Host-Adressbereich

1.0.0.0 bis127.255.255.255

128.0.0.0 bis191.255.255.255

192.0.0.0 bis223.255.255.255

224.0.0.0 bis239.255.255.255

240.0.0.0 bis255.255.255.255

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∗.∗.∗.0bis∗. ∗ . ∗ .255.Eine Universitat mit 80.000 Hosts wurde ein Netz der Klasse A, der Form∗.0.0.0 bis∗.255.255.255,fur sich beanspruchen.

Klasse D-Adressen sind sogenannte Multicast-Adressen. Sie werden dazu verwendet ein IP-Datagramman mehrere Hostadressen gleichzeitig zu versenden. Sendet ein Prozeß eine Nachricht an eine Adresseder Klasse D, wird die Nachricht an alle Mitglieder der adressierten Gruppe versendet. Dies geschiehtmit einem eigenen Protokoll, demInternet Group Management Protocol(IGMP) und ist ausfuhrlichin [RFC2236] beschrieben.

In der Literatur wird der weitere Bereich der IP-AdressenKlasse Ebezeichnet [CO02]. Dieser Bereichist fur zukunftige Nutzungen reserviert und z.Z. ungenutzt.

Die Anzahl der Netze bzw. Hosts der jeweiligen Klasse in Tabelle2 sind rein”theoretische“ Wer-

te, welche rein rechnerisch ermittelt wurden. Der Grund liegt darin, dass einige Adressen spezielleBedeutungen haben (Kapitel3.1.5) und nicht zur Verfugung stehen. Aus der Tabelle folgt, dass dieAdressklasse A eine sehr geringe Anzahl von Netzwerken mit einer sehr großen Anzahl von Hosts proNetzwerk, die Adressklasse B eine

”mittlere“ Anzahl von Netzwerken mit einer

”mittleren“ Anzahl


Lange des Maximale Anzahl derKlasse Netzwerkanteils Hostanteils Netzwerke Host pro Netzwerk

A 8 Bit 24 Bit 128 16.777.216B 16 Bit 16 Bit 16.384 65.536C 24 bit 8 Bit 2.097.152 256

Tabelle 2: Lange des Netzwerk- und Hostanteils und Maximale Anzahl der Netzwerke und Hosts inder jeweiligen IPv4-Adressklasse

von Hosts pro Netzwerk und die Adressklasse C eine sehr große Anzahl von Netzwerken mit einersehr geringen Anzahl von Hosts pro Netzwerk besitzt.

Die IP-Adresse identifiziert keinen bestimmten Knoten, sondern nur ein Interface. Einem Knoten mitmehreren Interfaces (z.B. ein Router) muss fur jedes Interface eine IP-Adresse zugewiesen werden.Jedes Interface besitzt eine eindeutige IP-Adresse, d.h. dass keine verschiedenen Interfaces die iden-tischen IP-Adressen besitzen. Dies veranschaulicht Abbildung9.

Token-Ring223.240.129.0/24

Ethernet 132.221.0.0/16

Router

Router

132.221.25.1

223.240.129.10 223.240.129.11

132.221.12.3

132.221.99.5

223.240.129.22

223.240.129.22

79.0.0.17

WAN 79.0.0.0/8

Abbildung 9: IP-Adresszuweisung: Jedes Interface hat eine eindeutige Adresse

3.1.5 Spezielle IPv4-Adressen

Es sind spezielle Adressen reserviert, d.h. sie durfen nicht als IP-Adresse an Interface vergeben wer-den. Im Folgenden werden diese speziellen Adressen bzw. Adressformate aufgelistet und erklart.


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.0Die 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ßeBedeutung bei der Teilnetz- und der klassenlosen Adressierung, auf die in Kapitel3.1.6respektiveKapitel3.1.7eingegangen wird.

Fur jede der Netzwerkklassen (Klasse A, B und C) wurde jeweils eineStandardnetzwerkmaskefest-gelegt, bei der alle Bitstellen des Netzwerkanteils auf 1 und alle Bitstellen des Hostanteils auf 0gesetzt sind. Tabelle3 zeigt fur die Klassen A, B und C die jeweilige Standardnetzwerkmaske mitder

”neuen“ Prafix-Notation oder auch CIDR-Notation, auf die in Kapitel3.1.7 noch eingegangen

wird. Netzwerkadressenbeziehen sich auf das Netzwerk selbst, und nicht auf die angeschlossenen

Klasse 1. Byte 2. Byte 3. Byte 4. Byte Prafix-NotationA 255 0 0 0 /8B 255 255 0 0 /16C 255 255 255 0 /24

Tabelle 3: Die IPv4-Standardnetzwerkmasken der Klasse A, B und C.

Hosts. Man erhalt die Netzwerkadresse bei gegebenen IP-Adresse, indem man die IP-Adresse bitwei-se mit dem boolschen UND verknupft. Die Netzwerkadresse setzt sich also aus der Netzwerknummerund 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 Netzwerknummer130.216 die Netzwerkadresse130.216.0.0 und die Netzwerkmaske255.255.0.0. Die Netzwerkadres-sen 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 denverschiedenen Gebieten (Asia Pacific Network Information Center (APNIC), American Registry forInternet Numbers (ARIN), Reseau IP Europeens (RIPE))ubernommen. Die Adressen werden nichteinzeln zugeordnet, sondern nach den Adressklassen vergeben.

Fur den Fall, dass man an alle Hosts eines physischen Netzwerks, ein IP-Datagramm senden will,existiert die sogenanntegerichtete Broadcast-Adresse(Directed Broadcast Address) fur jedes phy-sische Netzwerk. Der Netzwerkanteil besteht wiederum aus der Netzwerkadresse und im Hostanteilsind nur 1-Bit gesetzt. Die Broadcast-Adresse wird ermittelt, indem man die Netzwerkadresse mit derbitweise invertierten Netzwerkmaske bitweise mit dem boolschen ODER verknupft.

Zudem existiert aber nochbegrenzte Broadcast-Adresse(Limited Broadcast), die sich nur auf einlokales Netz beziehen. Diese Art von Adressen werden meist beim Systemstart verwendet, da dortdie Netzwerkkennung noch nicht bekannt ist, oder um einen Broadcast im lokalen Netzwerk durch-zufuhren. Netzwerk- und Hostanteil bestehen nur aus 1-Bits, somit ist255.255.255.255 die begrenzteBroadcast-Adresse.


Fur Testzwecke wurde eineSchleifenadresse(Loopback Address) definiert. Sie wird z.B. von Pro-grammieren von Netzwerkanwendungen zur Fehlerdiagnose und Fehlerkorrektur verwendet. Wahrendder Ausfuhrung eines Schleifentest verlasst kein IP-Datagramm den Knoten, sondern nur zwischenzwei Anwendungen werden die IP-Datagramme befordert. Fur die Schleifenadresse ist der Netz-werkanteil127.0.0.0 bis 127.255.255.255 reserviert. Der Hostanteil kann beliebig gewahlt werden,die Konvention sieht die Verwendung der Hostnummer 1 vor, so dass 127.0.0.1 dieubliche Schleifen-adresse ist.

Zudem hat die Internet Assigned Numbers Authority (IANA) drei Blocke des IP Adressraums furprivate Netzwerkereserviert [RFC1918]. Diese bedurfen keiner Koordination der IANA und konnenfrei gewahlt werden. Tabelle4 listet die drei Blocke auf.

Klasse Adressbereich Prafix-NotationA 10.0.0.0 - 10.255.255.255 10/8B 172.16.0.0 - 172.31.255.255 172.16/12C 192.168.0.0 - 192.168.255.255 192.168/16

Tabelle 4: Drei Blocke des IP-Adressraums sind fur private Netzwerke reserviert.

3.1.6 Teilnetze und Teilnetzwerkmasken

Die Teilnetz-Adressierung (Subnet Addressing)teilt ein”großes“ Netzwerk in eine entsprechende An-

zahl”kleinerer“ Teilnetzwerke (Subnets). Die Grunde fur eine Teilnetzbildung (Subnetting) konnen

verschiedener Natur sein:

• Beschrankungen der physikalischen Medien6

• Uberlastungen aufgrund zu hohen Traffic-Aufkommens

• große geographische Abstande

• 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

610BASE-T-Ethernet: max. 1.024 Hosts pro Netzwerk


• einfachere Verwaltung

Teilnetzbildung bedeutet nichts anderes, als dass dem Netzwerkanteil einzelne Bitstellen des Hostan-teils hinzugeschlagen werden und somit der Netzwerkanteil vergroßert wird. Also wird eigentlichnur die Standardnetzmaske geandert und somit der

”Filter“ verandert, der entscheidet, welche Rech-

ner sich im gleichen logischen Netzwerk befinden. Anzahl der Teilnetze wirduber die Anzahl derBitstellen gesteuert, die dem Netzwerkanteil hinzugeschlagen wird. Die Ermittlung der gerichtetenBroadcast Adresse geschieht weiterhin wie in Kap.3.1.5auf Seite25beschrieben.

Als die Teilnetzbildung eingefuhrt wurde, entfernte man sich gleichzeitig von der klassenbezogenenAdressierung. Jetzt musste immer die Netzwerkmaske mit angegeben werden. Und zwar geschieht dasnach wie vor wie oben beschrieben. In neuerer Literatur wird meist nicht immer die Netzwerkmaskein der Punkt-Dezimal-Notation angegeben, sondern es wird nur noch die Anzahl der Bitstellen, diedem Netzwerkanteil entspricht, angegeben. Diese Darstellung nennt man Prafix-Notation oder CIDR-Notation und wird im Folgenden Kapitel auf Seite28beschrieben.

3.1.7 Klassenlose Adressen

Die Anforderung, dass der Netzwerkanteil einer IP-Adresse genau ein, zwei oder drei Byte umfassenmuss, hat sich hinsichtlich der zunehmender Große des Internets als problematisch erwiesen. DemIPv4 gehen langsam die Adressen aus. Zwar gibt es Millionen von Adressen, aber viele bleiben ein-fach ungenutzt, weil fur jedes Netzwerk eine der drei Großen gewahlt werden musste. Die großtenProbleme losten dabei die Klassen B und C aus. Mit der Klasse C kann man nur maximal 254 Hostadressieren. Viele Firmen beantragten deshalb statt einer Klasse C eine Klasse B mit denen sie ma-ximal 65.536 Hosts eine Adresse zuweisen konnen, da sie die Befurchtung hatten, ein Klasse C Netzwurde nicht ausreichen. Tatsachlich ist aber oft auch ein Klasse B Netz zu groß. Fur viele Firmenwurde ein Netz der Klasse C ausreichen.Als Beispiel nehmen wir eine Firma

”Muller 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 benotigt man

ein Klasse B Netz und das Klasse B Netz ist einfach zu groß. Zudem wurde in den Anfangen desInternets allzu sorglos mit der Adressenvergabe umgegangen. Eine Losung um die starre Klassenauf-teilung der Adressen flexibel an die Gegebenheiten anzupassen, war lokal gesehen die im vorherigenKapitel beschriebene Teilnetzbildung, aber 1993 tauchte mit demClassless InterDomain Routing(CIDR) [RFC1519] eine globale Moglichkeit auf.

Dazu sollen die restlichen7 Klasse C Netze in Blocken mit variabler Lange vergeben werden. Sobraucht man kein Klasse B Netz mehr, um 300 Adressen zu adressieren, sondern einfach 2 aufeinan-

7es sind immernochuber 1,5 Millionen


derfolgende Klasse C Netze. Zusatzlich wurde die Welt in vier Zonen, von denen jede einen Teil8 desverbliebenen Klasse C-Adressraums erhalt, aufgeteilt [RFC1519]. Tabelle5 zeigt die vier verschiede-nen 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 Europa198.0.0.0 - 199.255.255.255 Nordamerika200.0.0.0 - 201.255.255.255 Mittel- und Sudamerika202.0.0.0 - 203.255.255.255 Asien und pazifischer Raum204.0.0.0 - 223.255.255.255 Reserviert fur zukunftige Nutzung

Tabelle 5: Klassenlose Adressierung (CIDR): Aufteilung der verbliebenen Klasse C in vier Zonen

einer Adresse zwischen194.∗.∗.∗ und195.∗.∗.∗, einfach zu seinem europaischen Standard-Gatewaysenden kann. So sind praktisch die jeweils 32 Millionen Adresse zu einem Routing-Tabelleneintragkomprimiert. Um nun die aufeinanderfolgenden Netze als ein Netz zu beschreiben, ist wiederum dieNetzwerkmaske wichtig. Sie wird mit den Netzen vergeben. Bei jeder Vergabe von aufeinanderfolge-nen Klasse C Netzen wird in der jeweiligen Zone (z.B. Europa) alle Routingtabellen um die Eintrageerganzt, somit wurde man auch der

”Explosion der Routingeintrage“ herr.

Um nun nicht immer die Netzwerkmaske in der Punkt-Dezimal-Notation schreiben zu mussen, wurdediePrafix- oder CIDR-Notationeingefuhrt [RFC1878]. Das Format der Prafix-Notation ist∗.∗.∗.∗/x,wobeix die Anzahl der Bits des Netzwerkanteils ist. In [RFC1878] werden alle 32 moglichen Prafixeaufgelistet.Da mit CIDR die klassische klassenbezogenen Adressenaufteilung aufgehoben wurde, braucht mannicht mehr in Klassen zu denken, sondern benutzt einfach die Prafix-Notation, um die Grenze zwi-schen Netzwerk- und Hostanteil festzulegen. Zum Beispiel schreibt man die Standardnetzmaske derKlasse B in der Prafix-Notation nur noch mit /16. Es werden also die Bits des Netzwerkanteils mit 16Bits angegeben. Somit kann die IP-Adresse128.10.0.1 mit Netzmaske255.255.0.0 als128.10.0.1/16geschrieben werden. Zudem braucht man nichts mehruber Klassen zu wissen, da man sofort sieht,dass die Adresse10.104.0.19/8 8 Bit fur den Netzwerkanteil und 24 Bit fur den Hostanteil besitzt.Aber in den Hosttabellen wird immer noch die Punkt-Dezimal-Notation fur die Netzmaske verwen-det. Anhand der Tabelle in [RFC1878], in der alle 32 moglichen Prafixe aufgelistet werden, kann mandie Netzmaske feststellen.

Um nun herauszufinden in welches Netz ein IP-Datagramm geroutet werden muss, wird auf dieZieladresse und einer Netzmaske aus der Routing-Tabellen das boolesche UND angewendet. So-bald das Ergebnis die identische Netzmaske ergibt, wird das IP-Datagramm an den jeweiligen Routergeschickt. Das ist jetzt sehr kurz erklart, wird aber in [RFC1519] ausfuhrlich beschrieben.

Mit CIDR wird der Firma”Muller GmbH“ aus dem obigen Beispiel statt eine Klasse B Netzadresse

8etwa 32 Millionen Adressen


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 dieNetzmaske255.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 LinkMTU uber dessen Link sein IP-Datagramm gesendet wird. In [RFC791] ist definiert, dass jeder Rou-ter mindestens ein IP-Datagramm von 68 Byte weitersenden konnen muss. Dieser Wert (68 Byte) istdiekleinste Link MTUdie das IP-Protokoll unterstutzt. Hingegen muss jeder Zielhost in der Lage sein,ein IP-Datagramm der Große 576 Bytes, empfangen zu konnen. Nun kann es jedoch moglicherweisevorkommen, dass das IP-Datagramm von einem Router auf der Streckeuber ein Netzwerk mit gerin-gerer Link MTU9 verschickt wird. Dazu muss nun der Router an dem Interface die IP-Datagramme

”umverpacken“, sprich aus einem IP-Datagramm mehrere machen. Dies nennt man dannFragmen-

tierung. Jeder Router muss der Lage ist, empfangene IP-Datagramme gegebenenfalls zu zerteilen,um sie weiteruber ein Teilnetz bis zum Zielhost zuubertragen. Fragmentierte IP-Datagramme hei-ßenFragmente. In Abbildung10 ist die Fragmentierung anhand eines Beispiels gezeigt. Jedes Frag-

Netz mit 4000 Byte MTU Netz mit 1500 Byte MTU

Ro

ute

r

Original PaketGesamtlänge: 4000 ByteNutzdaten: 2980 ByteIdentifikation: 1783Fragment Offset: 0DF = 0 MF = 0

1. FragmentGes.länge: 1500 ByteNutzdaten: 1480 ByteIdent.: 1783Frag. Offset: 0DF = 0 MF = 1

2. FragmentGes.länge: 1500 ByteNutzdaten: 1480 ByteIdent.: 1783Frag. Offse:DF = 0 MF = 1

1480

3. FragmentGes.länge: 1040 ByteNutzdaten: 1020 ByteIdent.: 1783Frag. Offset: 2960DF = 0 MF = 0

Abbildung 10: Fragmentierung von IPv4-Datagrammen [RFC791]

ment erhalt einen eigenen, vollstandigen IP-Protokollkopf. Damit jedes Fragment beim Empfangereindeutig dem richtigen IP-Datagramm zugeordnet werden kann, hat es schon beim Quellhost eineeindeutige Kennung erhalten. Zudem kann der Quellhostuber das

”DF“-Flag eine Fragmentierung

untersagen. Allerdings wird dann, wenn das IP-Datagramm zum Weitertransport fragmentiert werdenmusste 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 Zusammenetzen-beginnen kann. Der Fragment Offset gibt fur jedes Fragment an, ab welcher Stelle des originalenIP-Datagrammes die Nutzdaten einzufugen sind.Jeder Host muss in der Lage sein, diese Fragmente wieder zum ursprunglichen IP-Datagramm zu-

9aber mindestens 68 Byte


sammenzusetzen. Das Zusammensetzen von fragmentierten IP-Datagramme (Fragmente) heißtDe-fragmentierung. Die Defragmentierung geschieht nur beim Zielhost. Muss ein Fragment nochmalsfragmentiert werden um weitergesendet zu werden, geschieht dies, ohne die Fragmente in das ur-sprungliche IP-Datagramm zu defragmentieren, um es dann wieder zu fragmentieren. Das InternetProtokoll unterscheidet also nicht zwischen Fragmente und IP-Datagramme.

In Abbildung11 sendetHost Aein IP-Datagramm (I) der Lange 4000 Byte anHost B. Zuerst mussdieses IP-Datagramm vomRouter Afragmentiert werden, da die Link MTU kleiner ist. Es entste-hen drei IP-Datagramme,Fragmente, die anRouter Bgesendet werden. Router B kann aufgrund derder Link MUT von 1280 die zwei großeren Fragmente nicht weitersenden und muss diese nochmalsfragmentieren, bevor er sie weitersenden kann. Nun kann er alle Fragmente anRouter Csenden.Rou-ter C kann alle Fragmente sofort anHost Bzustellen. Host B defragmentiert nun alle empfangenenFragmente zu dem ursprunglichen IP-Datagramm (II). Die Fragmentierung von IP-Datagrammen ist

Host A Host BMTU 4000 MTU 1500 MTU 1280 MTU 1500

Router A Router B Router C(I) (II)

Abbildung 11: Mehrmalige Fragmentierung von IPv4-Datagrammen [RFC791]

problematisch und zudem noch rechenintensiv fur die Router, die fragmentieren mussen. Eine Losungist diePath MTU Discovery(PMTUD). Diese Methode wird in [RFC1191] beschrieben, ist aber keinStandard fur IPv4, sondern wird lediglich empfohlen. Der Zweck dieser PMTUD ist einzig und alleindem Quellhost die Fragmentierung der IP-Datagramme zuuberlassen, so dass auf dem gesamten Pfadvom Quell- zum Zielhost nicht mehr fragmentiert werden muss. Hierzu mussen aber alle Router aufdem Pfad PMTUD unterstutzen. Der Quellhost erlernt die Path MTU, indem er ein IP-Datagrammmit gesetzter

”DF“-Flag an den Zielhost sendet. Ein Router, der dieses IP-Datagramm fragmentieren

musste, schickt eine ICMP-Fehlermeldung mit der Link MTU an den Quellhost zuruck. Der Quell-host 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 tretenviele Probleme auf. Die Path MTU kann sich dynamisch verandern, d.h. der Host sollte die einmal

”gelernte“ Path MTU periodischuberprufen und dann ggf. auchandern. Zudem schicken nicht alle


IPv4-Router die lokale maximale Link MTU. Einige Host blocken zudem auch ICMP-Meldungenab, 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] be-schrieben. In Kapitel3.2.5wird auf die Path MTU Discovery fur IPv6 eingegangen.

3.1.9 Probleme und Schwachen des IPv4

Wie schon zu Beginn erwahnt, wurde die Spezifikation von IPv4 im Lauf der Zeit den Erfordernis-sen angepasst. Als großes Problem stellt sich die zu kleine Adressenlange von 32-Bit heraus und diedaraus resultierende Adressenknappheit. Dem wurde versucht mit NAT und mit CIDR entgegenzu-wirken. Nur das kann auf die Dauer nicht gelingen. Das Internet wachst jedes Jahr um MillionenHosts wie Abbildung12zeigt. Mit der heutigen Wachstumsrate sind die verfugbaren Netzwerkanteile

Abbildung 12: Wachstum des Internets [isc.org]: Anzahl der Hosts von 1991 bis 2002

bald erschopft und ein weiteres Wachstum nicht moglich. Das zweite Problem ist dieAnderung diesich durch neue Internetanwendungen ergab. Audio- und Videowiedergabe in Echtzeit gehoren zumBeispiel dazu. Damit solche Daten

”ruckelfrei“ im Internetubertragen werden konnen, mussen der

haufige Wechsel von Routen vermieden werden. Router werden von IPv4 damit beschaftigt, Check-summen zu prufen und zu errechnen und IP-Datagramme zu fragmentieren. Beides ist heutzutage


vollig unnotig und kostet bei dem heutigen Traffic summa summarum doch viel Rechenzeit. Ein wei-teres Problem sind die Optionen in IPv4. Sie sind nicht flexibel genug und konnen auch nicht wirklicherweitert werden, was den Nutzungsgrad von IPv4 schon sehr einengt. Auch der relativ große Proto-kollkopf mit den vielen, oft ungenutzten Feldern10, stellt ein Problem dar. Auch Sicherheit spielte beiIPv4 lange keine große Rolle, aber mit der Entwicklung von IPsec, welches eigentlich fur das neueProtokoll erdacht war, kam vorerst Linderung. Durch DHCP wurde auch der Administratoraufwanderheblich vermindert.Viele Schwachen, die IPv4 hat, wurden im Laufe der Zeit vermindert und im alten Design wurde

soweit dies moglich war, Verbesserungen gemacht. Das Verfahren, Path MTU Discovery, wurde furIPv6 entwickelt und existiert jetzt schon in leicht abgewandelter Form in IPv4. Aber damit entstandein neues Problem. Denn um die IP-Datagramme direkt in der richtigen Große schicken zu konnenbekommt der Quellhost eine ICMP-Fehlermeldung. Doch wenn die nicht, z.B. durch falsches kon-figurieren, ankommt, so dass die Path MTU Discovery fehlschlagt, benutzt IPv4 die kleinste MTU,68 Byte, um die IP-Datagramme zuzustellen. Das viel hohere Paketaufkommen belastet unnotig denRouter.

3.2 Das Internet Protokoll Version 6 - IPv6

3.2.1 Allgemeinesuber IPv6

Das Internet Protokoll Version 6 (IPv6 oder IPng11) wurde aus einer Not heraus geboren. Das Com-putermagazin c’t beschreibt in [ct1601] das Problem 2001 folgendermaßen:

”Die Spatzen brullen es

von den Dachern: Der Adressraum im Internet wird knapp. Zwar hat die Network Address Trans-lation (NAT) bei Providern fur den Wahlzugang ins Internet vorerst Linderung gebracht, doch kanndies nur eine vorubergehende Losung sein. Eine durchgreifende Abhilfe existiert in Form des InternetProtocol 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 diesdurch die Verlagerung von Funktionen in sogenannte Erweiterungsprotokollkopfe, die zwischen demIPv6 Protokollkopf und der eigentlichen Nutzlast, den Daten, enthalten sein konnen. Die Abbildung13 zeigt den Aufbau eines solchen IPv6-Pakets. Unbekannte Erweiterungsprotokollkopfe konnennicht von einer Implementation ignoriert werden sondern fuhren zum Verwerfen des Pakets. Zusatz-liche Parameter, die von Implementationen ignoriert werden konnen, werden als Optionen bezeichnetund in speziellen Erweiterungsprotokollkopfen fur Optionenubertragen.


IPv6 BasisProtokollkopf ...

1-terErweiterungs-Protokollkopf

n-terErweiterungs-Protokollkopf

optional

Daten

(40 Byte)

Abbildung 13: Allgemeine Form eines IPv6-Pakets [RFC2460]

Version Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

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

Abbildung 14: IPv6 Protokollkopfformat [RFC2460]

3.2.2 IPv6-Protokollkopfformat

Version: 4 BitsDas FeldVersionenthalt die Versionsnummer des IP-Protokolls. Der Wert ist 6.

Traffic Class: 8 BitsDas FeldTraffic Classwird zum Unterscheiden der verschiedenenUbermittlungsanforderun-

gen von Paketen benutzt. Zum Bsp. benotigt man fur die Ubertragung von digitaler Sprachemehr Schnelligkeit und weniger Genauigkeit, im Gegensatz zurUbertragung von Dateien, wo

10Fragmentierung muss nicht immer sein11Internet Protocol The Next Generation


die Genauigkeit wichtiger ist als die Geschwindigkeit. Die Abbildung15zeigt den Aufbau desFeldes.

DSCP CU

DSCP - differentiated services codepointCU - currently unused

0 1 2 3 4 5 6 7

Abbildung 15: Traffic Class - Aufbau nach RFC 2474 [RFC2474]

Flow Label: 20 BitsDas FeldFlow Labelist noch in der Experimentierphase, soll aber benutzt werden, um es einerQuelle und einem Ziel zu ermoglichen, eine Pseudoverbindung mit bestimmten Merkmalenund Anforderungen aufzubauen. Das Feld kann dann benutzt werden, um ein IP-Datagrammmit einem bestimmten Netzwerkpfad zu assoziieren. Router sollen dann das Feld benutzen, umdie IP-Datagramm auf diesen vorab

”geplanten“ Pfad zu befordern.

Payload Length: 16 BitsDas FeldPayload Lengthgibt an, wie viele Bytes dem 40 Byte langen Protokollkopf folgen.

Next Header: 8 BitsDas FeldNext Headergibt an, welcher der Erweiterungsprotokollkopfe (Kap.3.2.3) diesem

folgt oder falls er der letzte IP-Protokollkopf ist, welches Transportprotokoll folgt.

Hop Limit: 8 BitsDas FeldHop Limitentspricht 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 1verringert wird. Sobald der Wert des Feldes 0 ist, wird das Paket verworfen.

Source Address: 128 BitsIn diesem Feld wird die 128 Bit-Quelladresse eingetragen. Die 128 Bit Adresse wird ausfuhr-

lich im Kapitel 3.2.4auf Seite39behandelt.

Destination Address: 128 BitsIn diesem Feld wird die 128 Bit-Zieladresse eingetragen. Die 128 Bit Adresse wird ausfuhrlichim Kapitel 3.2.4auf Seite39behandelt.


3.2.3 IPv6-Erweiterungsprotokollkopfe

Es sind die folgenden sechsErweiterungsprotokollkopfe (Extension Headers) definiert [RFC2460,RFC2402, RFC2406]:

”Optionen fur Teilstrecken“ Erweiterungsprotokollkopf

Abbildung.16 zeigt denHop-by-Hop Options Extension Header(HO). Er enthalt eine Liste von Op-tionen, die von jedem Knoten auf dem Weg untersucht werden mussen [RFC2460].

Next Header Hdr Ext Len

Options

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

Abbildung 16: Hop-by-Hop Options Extension Header [RFC2460]

Next Header: Das FeldNext Headeridentifiziert den Typ der in der Nutzlast hinter dem HO enthal-tenen Nachricht.

Hdr Ext Len: Das FeldHeader Extension Lengthspezifiziert die Lange des HO gemessen in derAnzahl von 64 Bit Worten minus 1.

Options: Das FeldOptionsenthalt die einzelnen Optionen.

Routing Erweiterungsprotokollkopf

Der Routing Extension Header(RH) wird in Abbildung17 gezeigt. Er erlaubt es, den Weg einesDatagramms im voraus zu planen [RFC2460].

Next Header: Das FeldNext Headeridentifiziert den Typ der in der Nutzlast hinter dem RH enthal-tenen Nachricht.

Hdr Ext Len: Das FeldHeader Extension Lengthspezifiziert die Lange des RH gemessen in derAnzahl von 64 Bit minus 1.


Next Header Hdr Ext Len Routing Type Segments Left

Type-Specific Data

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

Abbildung 17: Routing Extension Header [RFC2460]

Routing Type: Das FeldRouting Typeidentifiziert eine bestimmte Variante des RH und die Bedeu-tung des Felds Type-Specific Data.

Segments Left: Das FeldSegments Leftidentifiziert die Anzahl der verbleibender Routing-Segmente.

Fragmentierungs Erweiterungsprotokollkopf

IPv6 setzt voraus, daß jeder Link eine MTU von mindestens 1280 Byte besitzt. Entsprechend mussenLinks, die eine kleinere Link MTU besitzen, Fragmentierung und Reassemblierung unterhalb vonIPv6 realisieren. Einfache Implementationen, die keinPath MTU Discovery(Kap.3.2.5) unterstutzen,mussen sich auf IP-Datagramme mit einer maximalen Lange von 1280 Byte beschranken. Mit Hil-fe desFragment Extension Header(FH), der in Abbildung18 gezeigt wird, konnen IP-Datagrammedie großer als die Path MTU sind, fragmentiert und versendet werden. Fragmentierung erfolgt aus-schließlich beim Quellhost eines IP-Datagramms und niemals innerhalb eines Routers [RFC2460].

Next Header Reserved Fragment Offset Res

Identification

M

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

Abbildung 18: Fragment Extension Header [RFC2460]

Next Header: Das FeldNext Headeridentifiziert den Typ der in der Nutzlast hinter dem FH enthal-tenen Nachricht.

Fragment Offset: Das FeldFragment Offsetdefiniert die relative Position eines Fragments (gemes-sen in 64 Bit Worten) des original IP-Datagramms.


M: Die FlagM ist gesetzt, wenn weitere Fragmente folgen. Die Bits Res sind nicht benutzt.

Identification: Das FeldIdentificationenthalt fur alle Fragmente eines IP-Datagramms denselbenWert.

Authentifikation Erweiterungsprotokollkopf

DerAuthentication Header(AH), in Abbildung19gezeigt, realisiert fur IP-Datagramme die grundle-genden Sicherheitsdienste Authentifikation und Datenintegritat [RFC2402].

Next Header Payload Len Reserved

Authentication Data (variable)

Security Parameters Index (SPI)

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

Abbildung 19: Authentication Header [RFC2402]

Next Header: Das FeldNext Headeridentifiziert den Typ der in der Nutzlast hinter dem AH enthal-tenen Nachricht.

Payload Len: Das FeldPayload Lengthspezifiziert die Lange des AH gemessen in der Anzahl von32 Bit Worten minus 2.

Security Parameters Index: Das FeldSecurity Parameters Indexenthalt einen Wert, der zusammenmit der Zieladresse eindeutig eine Security Association (SA) identifiziert.

Sequence Number:Das FeldSequence Numberenthalt eine streng monoton wachsende Sequenz-nummer. Das erste Paket, das nach der Einrichtung einer SA gesendet wird, hat den Sequenz-nummernwert 1. Erreicht die Sequenznummer den Wert 232, so muss in der Regel eine neueSA eingerichtet werden.

Authentication: Das FeldAuthentication Dataenthalt eine Integritatsprufsumme (integrity checkvalue, ICV). Die Lange dieses Felds hangt von der verwendeten Authentifizierungsfunktion ab.


”Verschlusselte Sicherheitsdaten“ Erweiterungsprotokollkopf

Abbildung20 zeigt denEncapsulating Security PayloadErweiterungsprotokollkopf (ESP). Er reali-siert Sicherheitsdienste wie Vertraulichkeit, Authentifikation, Datenintegritat, Schutz vor Wiederho-lungen und eingeschrankte Sicherung gegen Verkehrsflußanalysen [RFC2406]. Eine Fragmentierungkann nur nach einer Verschlusselung erfolgen, d.h. ESP wird nie auf ein Fragment angewendet.

Security Parameters Index (SPI)

Padding (0-255 bytes)

Pad Length Next Header

Sequence Number

Payload Data (varibale)

Authentication Data (variable)

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

Abbildung 20: Encapsulating Security Payload Erweiterungsprotokollkopf [RFC2406]

Security Parameters Index: Das FeldSecurity Parameters Indexenthalt einen Wert, der zusammenmit der Zieladresse eindeutig eine Security Association (SA) identifiziert.

Sequence Number:Das FeldSequence Numberenthalt eine streng monoton wachsende Sequenz-nummer. Das erste Paket, das nach der Einrichtung einer SA gesendet wird, hat den Sequenz-nummernwert 1. Erreicht die Sequenznummer den Wert 232, so muss in der Regel eine neueSA eingerichtet werden.

Payload Data: Die verschlusselte Nutzlast (inklusive etwaiger Initialisierungsvektoren) ist im FeldPayload Datauntergebracht.

Padding: Das FeldPaddingkann benutzt werden, um durch Fullbytes eine Ausrichtung der ver-schlusselten Daten zu erreichen oder um eine passende Eingabelange fur ein gegebenes Ver-schlusselungsverfahren bereitzustellen. Durch das Anfugen von Fullbytes kann auch die ur-sprungliche Lange der Nutzlast verschleiert werden.

Pad Length: Das FeldPad Lengthenthalt die Anzahl der Fullbytes.

Next Header: Das FeldNext Headeridentifiziert den Typ der in der Nutzlast enthaltenen Nachricht.


Authentication Data: Das FeldAuthentication Dataenthalt eine Integritatsprufsumme (integritycheck value, ICV). Die Lange dieses Felds hangt von der verwendeten Authentifizierungsfunk-tion ab.

”Optionen fur Ziele“ Erweiterungsprotokollkopf

Der Destination Options Extension Header(DO) enthalt eine Liste von Optionen, die nur von denZielknoten untersucht werden mussen [RFC2460]. Er wird in Abbildung21gezeigt.

Next Header Hdr Ext Len

Options

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

Abbildung 21: Destination Options Extension Header [RFC2460]

• Die FelderNext Header, Hdr Ext LenundOptionssind analog zum HO Erweiterungsprotokoll-kopf definiert.

3.2.4 Aufbau einer IPv6-Adresse

Die IPv6-Adresse hat eine Lange von 128 Bit12. Mit einer 128-Bit-Adressierung kann man nun2128 =340.282.366.920.938.463.463.374.607.431.768.211.456 mogliche Adressen vergeben. Wie man sieht,ist das eine unvorstellbar große Zahl und man kann nun jedem Quadratmeter Erdoberflache ca.7×1023

Adressen zuweisen. Die Entscheidung eine IP-Adresse mit 128 Bit fur das neue IP-Protokoll zu be-nutzten, lag nicht darin, jeden Quadratmeter mit Quadrillionen von Adressen zu

”bepflastern“, son-

dern eine Aufteilung des Internets nach topographischen und hierarchischen Gesichtspunkten zu er-reichen. Eine 128-Bit-Adresse wird nicht als Binarzahl, im Gegensatz zur IPv4-Adresse aber auchnicht als Punkt-Dezimal-Notation geschrieben, sondern in doppelgepunkteten Hexadezimalzahlen. Indieser Doppelpunkt-Hexadezimal-Notation (Colon Hexadecimal Notation) werden jeweils 16 Bit zueiner Gruppe zusammengefugt und die insgesamt 8 Gruppen mit einem Doppelpunkt

”:“ getrennt.

Somit sieht das IPv6-Adressenformat folgendermaßen aus:∗ : ∗ : ∗ : ∗ : ∗ : ∗ : ∗ : ∗ wobei∗ einehexadezimale Zahl zwischen0 undFFFF ist.

1216 Byte


Tabelle6 zeigt eine 128-Bit-IPv6-Adresse in jeweils dualer Schreibweise, Punkt-Dezimal-Notationund die Doppelpunkt-Hexadezimal-Notation. An dieser Tabelle ist fur jeden ersichtlich, dass eigent-

Schreibweise Adresse

Binar 0010000111011010 10101111111111100000000000000000 10111010111111110010111100111011 00000000111111110000001010101011 0101101010011100

Punkt-Dezimal (8 Bit) 33.218.175.254.0.0.186.255.47.59.0.255.2.171.90.156Punkt-Dezimal (16 Bit) 7180.37124.0.39599.9956.244.627.19272

Doppelpunkt-Hexadezimal21DA:AFFE:0000:BAFF :2F3B:00FF :02BC:5A9C

Tabelle 6: Eine IPv6-Adresse in binarer Schreibweise, in Punkt-Dezimal- und in Doppelpunkt-Hexadezimal-Notation

lich alle Schreibweisen sehr umstandlich sind, im Gegensatz zur IPv4-Adresse, doch hat man sichfur die Doppelpunkt-Hexadezimal-Notation entschieden. Dadurch kommt auch dem DNS eine hohe-re Bedeutung zu. Da viele IPv6-Adressen erwartungsgemaß zahlreiche Nullen enthalten, entschiedman sich fur eine sogenannteNullenkompression(Zero Compression). Somit konnen eine Folge vonNullen einmalig durch zwei Doppelpunkte

”::“ ersetzt und fuhrende Nullen der Hexadezimalzah-

len weggelassen werden. Somit kann die AdresseFF02:0000:0000:0000:0000:0000:0000:0002 zuFF02::2 komprimiert werden.

Weiterhin wird derAdressprafix (Address Prefixe) durch die CIDR-Notation [RFC1519] dargestellt.Das Format der Prafix-Notation ist∗:∗:∗:∗:∗:∗:∗:∗/x, wobeix die Anzahl der Bits von links an angibt,welche zum Prafix gehoren.Die Knotenadresse12AB::CD30:123:4567:89AB:CDEF und ihre Teilnetznummer12AB:0:0:CD30::/60 kann mit12AB::CD30:123:4567:89AB:CDEF /60 abgekurzt werden.

Es sind drei verschiedene Arten von IPv6-Adressen definiert [RFC2373]: Unicast-, Anycast- undMulitcast-Adressen. Im Folgenden werden die drei Adresstypen beschrieben.

UnicastEine Unicast-Adresseidentifiziert ein einzelnes Interface. Ein an diese Art von Adressen gesen-

detes IP-Datagramm wird auf den kurzesten Pfad an den Zielhost gesendet. Eine Unicast-Adressehat prinzipiell einenTeilnetzprafix und eineInterface-IDund ist mit IPv4-Adressen unter CIDR ver-gleichbar. Alle Unicast-Adressen, außer jene die mit dem binaren Wert 000 beginnen, haben 64 Bitlange Interface IDs, welche aus demModified EUI-64-Format13 konstruiert werden. Es sindGlo-bale Unicast-Adressen(Global Unicast Addresses), IPv6-Adressen mit eingebetteten IPv4-Adressenund lokale Unicast-Adressen (Local Unicast Addresses) definiert [RFC2373]. Die lokalen Unicast-

13Es leitet die Interface ID direkt aus der MAC-Adresse ab.


Adressen teilen sich inVerbindungsspezifische lokale Adressen(Link-local Unicast) undStandorts-pezifische lokale Adressen(Site-Local Unicast) auf. Die verbindungsspezifischen lokalen Adressenhaben nur lokale Bedeutung auf einem Link. Sie werden automatisch perNeighbor Discoveryoderwenn kein Router existiert vergeben. IP-Datagramme von dieser oder an diese Adresse werden vonkeinem Router weitergesendet und gelten z.B. nur innerhalb eines Unternehmens. Sie besteht aus ei-nem 10 Bit langen Prafix, weitere 54 Bit langen, die Null sind und der 64 Bit langen Interface ID.Die standortspezifischen lokalen Adressen werden zu Adressierung innerhalb eines Standortes ver-wendet, ohne eine direkte Verbindung an das Internet. IP-Datagramme von dieser oder zu dieserAdresse werden auch nicht von einem Router weitergesendet. Sie besteht aus einem 10 Bit langenPrafix, einer 54 Bit langen Subnet ID und der 64 Bit langen Interface ID.Es gibt zwei verschiedeneIPv6-Adressen mit eingebeteten IPv4-Adressen: IPv4-compatible IPv6AdresseundIPv4-mapped IPv6 Adresse. Bei beiden sind die ersten 80 Bits Null und die letzten 32 Bitssind die alte IPv4-Adresse, die in Punkt-Dezimal-Notation geschrieben werden kann. Nur in den mitt-leren 16 Bits unterscheiden sie sich.Die mittleren 16 Bits derIPv4-compatible IPv6 Adressesind Null. Somit hat die Adresse folgen-de Form ::∗.∗.∗.∗. Bei der IPv4-compatible IPv6 Adresse kann man einem IPv6-Knoten eine IPv4-kompatible Adresse zuweisen. Diese IPv6 Adresse kannuber ein IPv4-Netzubertragen werden. BeimUbergang von IPv6-Netz in IPv4-Netz und umgekehrt werden nur die ersten 96 Nullen entfernt bzw.hinzugefugt. Zu beachten ist, dass diese IPv4-Adresse eindeutig sein muss. Die IPv4-mapped IPv6Adresse setzt die mittleren 16 Bits auf 1, damit hat sie die folgende Form ::FFFF :∗.∗.∗.∗. DieserAdressentyp wird benutzt um die Adressen von IPv4 Knoten als IPv6 Adressen darzustellen.

AnycastEineAnycast-Adresseidentifiziert eine Menge von Interfaces, welche typischerweise zu verschiede-nen Knoten gehoren. Ein an diese Adresse gesendetes IP-Datagramm wird auf dem kurzesten Pfadbefordert und dem nachsten Interface mit dieser Adresse zugestellt. Anycast-Adressen basieren aufdenublichen Unicast-Adressen.

MulticastEineMulticast-Adresseidentifiziert eine Menge von Interfaces, welche typischerweise zu verschie-

denen Knoten gehoren. Ein an diese Adresse gesendetes IP-Datagramm wird an alle Interfaces,die zu dieser Adresse gehoren, gesendet. Die Zugehorigkeit zu dieser

”Gruppe“ kann sich jederzeit

andern. Die Multicast-Adresseubernehmen u.a. die Aufgabe der IPv4-Broadcast-Adressen. Vier Bitder Adresse sind fur dasUmgangsfeld(Scope) reserviert. Durch 16 verschiedene Werte kann man einMulticast auf eine Verbindung, einen Standort, eine Unternehmen und weltweit begrenzen.

Der IPv6-Adressraum teilt sich auf, wie in der Tabelle7 aufgefuhrt.

Hinzukommmen noch einige spezielle Adressen, die nicht verwendet werden durfen:Die Adresse 0:0:0:0:0:0:0:0 heißt dieunspezifizierte Adresse(Unspecified Address). Sie soll beim

”Booten“ benutzt werden, noch bevor der Host eine eigene Adresse erhalt.Die Unicast-Adresse 0:0:0:0:0:0:0:114 ist dieSchleifenadresse(Loopback Address). Unter IPv4 hatte


Prafix (binar) Verwendung Adress Raum0000 0000 Reserviert, u.a. fur IPv4-Adressen 1/2560000 0001 Nicht zugewiesen 1/2560000 001 OSI-NSAP-Adresse 1/1280000 010 Novel-NetWare-IPX-Adressen 1/1280000 011 Nicht zugewiesen 1/1280000 1 Nicht zugewiesen 1/320001 Nicht zugewiesen 1/16001 Nicht zugewiesen 1/8010 Adressen fur ISP (Internet Service Provider) 1/8011 Nicht zugewiesen 1/8100 Adressen fur geographische Bereiche 1/8101 Nicht zugewiesen 1/8110 Nicht zugewiesen 1/81110 Nicht zugewiesen 1/161111 0 Nicht zugewiesen 1/321111 10 Nicht zugewiesen 1/641111 110 Nicht zugewiesen 1/1281111 1110 0 Nicht zugewiesen 1/5121111 1110 10 Link-local unicast 1/10241111 1110 11 Site-Local unicast 1/10241111 1111 Multicast-Adressen 1/256

Tabelle 7: Aufteilung des IPv6-Adressraumes [RFC2373]

sie die folgende Form: 127.0.0.0.1.Anycast-Adressen der FormTeilnetzprafix:0· · ·0 sind vordefiniert und heißenSubnet-Router AnycastAdresses. IP-Datagramme mit dieser Art von Adressen als Ziel, werden zu irgendeinem Router15 indem Teilnetz gesendet.Die Multicast-Adressen von FF00:: bis FF0F:: sind reserviert [RFC2373].

3.2.5 Fragmentierung von IPv6-Datagrammen & Path MTU Discovery

In Kapitel3.1.8 wurde die Fragmentierung von IPv4-Datagrammen beschrieben. Im Gegensatz zuIPv416 fuhrt ein IPv6-Router keine Fragmentierung mehr durch. Empfangt ein Router ein zu großesIP-Datagramm, sendet er eine ICMP-Nachricht an den Quellhost des IP-Datagramm [RFC1981], wel-

14kurz: ::115den nachsten16Ohne

”Path MTU Discovery“

3.3 Wesentliche Unterschiede 43

chen diesen anweist, alle weiteren IP-Datagramme zu diesem Ziel aufzuteilen. Das bedeutet, dass vonden Quellhosts

”erwartet“ wird, dass sie von vornherein eine Datengrammgroße wahlen, die keine

Fragmentierung voraussetzt. Das”erwartet“ wird durch das Verfahren derPath MTU Discovery(PM-

TUD) erreicht, welche in IPv4 lediglich empfohlen war. Mit Hilfe der PMTUD weiß der Quellhostnun, mit welcher IP-Datagramm-Große er senden muss, damit seine IP-Datagramm auf dem gesam-ten Pfad, zwischen ihm und dem Zielhost nicht mehr fragmentiert werden muss. In Abbildung22wirdein Beispiel zur Path MTU Discovery gegeben. Um die Path MTU eines Pfades zu bestimmen sendetHost Aein genugend langes IP-Datagramm (I) anHost B. Der Router Akann aufgrund der gerin-geren Link MTU von 1500 dieses IP-Datagramm nicht unfragmentiert weitersenden. Deshalb sendeter eine ICMP-Meldung an Host A (Abb.22(1)). Dieser wahlt aufgrund der Link MTU, die in derICMP-Meldung gesendet wurde, diese Große fur sein IP-Datagramm. Router A kann nun dieses IP-DatagrammRouter Bweitersenden. Aber auch Router B kann aufgrund der geringeren Link MTU von1280 das IP-Datagramm nicht weitersenden. Auch er sendet eine ICMP mit der Link MTU an Host Azuruck (Abb.22(2)). Host A sendet nun wiederrum ein IP-Datagramm mit der Lange der neuen LinkMTU von 1280 an Router A. Das IP-Datagramm erreicht nunuber Router A, Router B und Router Cden Host B (Abb.22(3)). Nun

”kennt“ Host A die Path MTU zum Host B. In Abbildung22(4) sendet

Host A das IP-Datagramm (I) direkt in der Lange, so dass kein Router die IP-Datagramme fragmen-tieren musste. Der Host B wiederum defragmentiert diese IP-Datagramme zu einem IP-Datagramm(II).

3.3 Wesentliche Unterschiede

Der großte sichtbare Unterschied ist die Lange der Adressen. Waren es bei IPv4 noch 32 Bit langeAdressen, die in Punkt-Dezimal-Notation notiert wurden, sind es bei IPv6 128 Bit lange Adressen, diein einer Doppelpunkt-Hexadezimal-Notation dargestellt werden. Die Adressen unter IPv4 und IPv6unterscheiden sich nicht nur in der Lange und der Schreibweise, sondern auch in der Adressenauf-teilung. Die IPv4-Adressen wurden zuerst in Klassen aufgeteilt, dann aufgrund der Adressenknapp-heit und der Unflexibilitat der Adressklassen als klassenlose Adressen benutzt. IPv6-Adressen sindnicht in Klassen aufgeteilt, sondern in Adresstypen und nach dem Prafix. Somit erreichen die IPv6-Adressen Flexibilitat und eine Aufteilung des Internets nach topographischen und hierarchischen Ge-sichtspunkten. Ein IPv6-Datagramm aus einem Basisprotokollkopf fester Lange, einem oder meh-reren Erweiterungsprotokollkopfen und den Nutzdaten. Ein IPv4-Datagramm besteht hingegen nuraus einem Protokollkopf variabler Lange und den Nutzdaten. Somit braucht der IPv6-Protokollkopfauch keinTotal Length-Feld mehr. Durch die feste Lange des IPv6-Basis-Protokollkopfes konnensich die Optionen nicht mehr innerhalb des Protokollkopfes befinden. Wahrend unter IPv4 noch jedeFunktion ein oder mehrere Felder im Protokollkopf umfasste, existiert unter IPv6 fur jede Funkti-on einen eigenen Erweiterungsprotokollkopf. Dadurch hat IPv6 auch ein neues Feld bekommen, dasNext Header. Dadurch wird FeldProtocolin IPv4 nicht mehr benotigt, da das FeldNext Headerauchangibt, welches Transportprotokoll nach dem letzten IP-Header folgt. Die Fragmentierung wird in



Router A Router B Router C





ICMP

(4)

(3)

(2)


Router A Router B Router CICMP

(1)

(I) (II)

Abbildung 22: Fragmentierung von IPv6-Datagrammen [RFC1981]

IPv6 gegenuber IPv4 ein wenig anders gehandhabt. Alle Felder im IPv4-Protokollkopf, die bisher zurFragmentierung eines IP-Datagramms benotigt wurden (Identification, Flags, Fragment Offset), sindim IPv6-Basis-Protokollkopf nicht mehr vorhanden. Das liegt vorallem an der Tatsache, dass es unterIPv6 einen ErweiterungsheaderFragmentierunggibt. Zudem geschieht die Fragmentierung bei IPv4standardmaß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 Prufsumme bei IPv4nachteilig auf die Leistung der Datenubertragung ausgewirkt hat, wurde das FeldChecksumist nichtmehr in IPv6 implementiert. Eine Prufsumme existiert bereits auf der Transportschicht, weshalb in-nerhalb der Vermittlungsschicht keine weitere Prufsumme 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 Losung. Unter IPv4 ist die Unterstutzung von IPsec optio-nal, in IPv6 aber Pflicht.IPv4 sendetuber 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 undNeighbor Solocitation.Die minimale Link MTU des Internet Protokolls wurde von 86 Bytes bei IPv4 auf 1280 Bytes bei IPv6angehoben. Somit kann selbst bei Fehlern wahrend der Path MTU Discovery der IPv6-Quellhost IP-Datagramme mit 1280 Bytes senden, anstatt sich auf 86 Bytes beschranken zu mussen.Die maximale IP-Datengrammgroße wurde allerdings wie bei IPv4 bei 64 Kbyte belassen, allerdingsexistiert ein Erweiterungsheader bei IPv6 mit demJumbogrammegesendet werden konnen.

3.4 Umstellung von IPv4 auf IPv6

Eine Umstellung von IPv4 auf IPv6 ist sehr problematisch. Zwar ist IPv6 abwartskompatibel, aber in-stallierte IPv4-System, wie Router, konnen keine IPv6-Datagramme handhaben. Es ist enorm schwie-rig, Protokolle der Vermittlungsschicht zuandern. In [KK02] wird folgendes festgestellt:

”Die Einfuhrung neuer Protokolle auf der Vermittlungsschicht kommt ungefahr dem Austausch des

Fundaments eines Hauses gleich – das Ganze lasst sich kaum bewaltigen, ohne das ganze Haus abzu-reißen oder zumindestens alle Bewohner vorrubergehend zu evakuieren.“Es gibt drei mogliche Szenarien wie eine Umstellung vonstatten gehen kann. In [RFC2893] werdenIPv6 Ubergangsmethoden ausfuhrlich beschrieben. Eine erste aber eher unwahrscheinliche Umstel-lungsart ware die des Stichtages. An einem Tag sollen alle IPv4-Knoten runtergefahren werden unddann als IPv6-Knoten wieder gebootet werden.Eine zweite, weichere Umstellungsart ist die des

”Dual-Stack“. Dual-Stacks erlauben den Mischbe-

trieb von IPv6 und IPv4, d.h. jeder Knoten sollte IPv4- und IPv6-Datagramme senden und empfan-gen konnen. Abbildung23 zeigt schematisch zwei Dual-Stacks. Eine dritte Umstellungsart tunneltdie gesendeten Daten zwischen zwei IPv6-Host durch eine IPv4-Infrastruktur. Dies erfordert auf derIPv4-Ebene eine Multicast-Fahigkeit. Aktuell ist so ein IPv6-Tunnelnetz schon im Einsatz. Es heißt6Bone, in Anlehnung an den Multicast-Backbone MBONE von IPv4. In diesem Tunnelnetz sind so-genannte IPv6-Inseln durch statische Tunnel miteinander verbunden. Abbildung24zeigt schematischeinen aufgebauten Tunnel. Inzwischen ist es auch moglich dynamische Tunnel automatischoffnen zu


Abbildung 23: Dual-Stacks: Mischbetrieb von IPv6 und IPv4 [ct1601]

Abbildung 24: IPv6 over IPv4: zwei IPv6-Hosts tauschen Datenuber einen per Multicast aufgebautenTunnel durch das IPv4-Netz aus [ct1601]

lassen.

Eines ist aber gewiess; die Umstellung geschieht in Hosts, ebenso wie in Routern und auch eini-ge Programme mussen soweit diesuberhaupt moglich ist umprogrammiert werden. Die Umstellungin LANs kann schon heute geschehen. Bei Hubs und Switches, welche im LAN zum Einsatz kom-men sind heutzutage keineAnderungen fur IPv6 vorzunehmen. Fast alle gangigen Betriebssystemewie Linux, Windows XP & Co., Solaris und selbst MAC OS X unterstutzen IPv6. Somit sind einerUmstellung im LAN von IPv4 auf IPv6 keine Steine in den Weg gelegt. Router-Firmen wie CISCOunterstutzen auch schon IPv6, zumindestens in Beta-Versionen. Es wird erst die Zeit zeigen, ob sichIPv6 auf breiter Ebene durchsetzen wird. Asien und auch Europa sind die Vorreiter. Die USA holtlangsam auf. Manche Adminstratoren, Firmen u.a. sehen nicht die Notwendigkeit einer zeitaufweni-gen und arbeitsintensiven Umstellung, da viele Vorteile von IPv6 auf IPv4 zuruckportiert wurden.

47

4 Zusammenfassung

Das Internet Protokoll ist das Fundament des Internets. Zu den Starken des Internet Protokolls zahltdie Ubertragung von Daten auchuber heterogene Netze hinweg. Dazu benutzt es ein IP-Datagrammals Basiseinheit fur den Transfer in einem TCP/IP-Internet. Um Daten von einem Quellhost zu einemZielhost senden zu konnen, bedient sich das Internet Protokoll seiner IP-Adressen, die ein Interfaceim Internet eindeutig identifiziert. Um nun auchuber heterogenen Netze mit unterschiedlichen MTUsDaten zum Zielhost senden zu konnen, beherrscht das Internet Protokoll die Fragmentierung vonIP-Datagrammen. Die Adressierung und die Fragmentierung sind die Basisfunktionen welche das In-ternet Protokoll implementiert.Das Internet Protokoll Version 4 leistet schon seituber 20 Jahren gute Dienste, aber die Adressenwerden knapp. Seituber 10 Jahren wird deshalb immer wieder an neuen Methoden gearbeitet, umdieses und andere Mankos auszugleichen. Doch seit 1995 gibt es neues Internet Protokoll, welchesdas Alte ablosen soll. Das Internet Protokoll Version 6 bietet statt der alten 32-Bit-Adressierung eine128-Bit-Adressierung. IPv6 weist noch viele Merkmale von IPv4 auf, aber beide Protokolle unter-scheiden sich in Details.Bei allen Problemen des IPv4, darf man eines nicht außer Acht lassen: Das Internet Protokoll Versi-on 4 wurde entwickelt, bevor esuberhaupt PCs oder Workstations, das Ethernet oder andere LAN-Technologien gab. Es existierte schon, da hatte man an Millionen von Nutzern, Chat und Videostre-aming noch nicht mal gedacht, da waren 100.000 Hosts noch Utopie. Zudem wurden viele Vorteilevon IPv6 mit mehr oder weniger Erfolg auf IPv4 zuruckportiert, das ist gut fur IPv4 aber schlechtfur die Durchsetzung von IPv6. Ob und wann sich IPv6 durchsetzen wird, werden die nachsten Jahrezeigen.

48 LITERATUR

Literatur

[KK02] Kurose J.F., Keith W.R.: Computernetze - Ein Top-Down-Ansatz mit Schwerpunkt In-ternet. 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] Fuller V., Li T., Yu J., Varadhan K.: RFC 1519 - Classless Inter-DomainRouting (CI-DR): an Address Assignment and Aggregation Strategy. September 1993

[RFC1878] Pummill T., Manning B.: RFC 1878 - Variable Length Subnet Table For IPv4. Decem-ber 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 Allocationfor 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. November1997

[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 InternetProtocol Version 6. December 1998

[RFC2402] Kent S.,Atkinson R.: RFC 2402 - IP Authentication Header. November 1998

[RFC2406] Kent S.,Atkinson R.: RFC 2406 - IP Encapsulating Security Payload (ESP). November1998

[RFC2474] Nichols K., Blake S., Baker F., Black D.: RFC 2474 - Definition of the DifferentiatedServices 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 Rou-ters. August 2000

[HU97] Hunt C.: TCP/IP Network Administration. O’Reilly, December 1997

[ct1601] Felix von Leitner: Das nachste Netz. c’t 16/2001

[RFC2461] Narten T., Nordmark E., Simpson W.: RFC 2461 - Neighbor Discovery for IP Version6 (IPv6). December 1998

[RFC2923] Lahey K.: RFC 2923 - TCP Problems with Path MTU Discovery . September 2000

[isc.org] http://www.isc.org/

[ipv6.org] http://www.ipv6.org/

Documents

IPv4 und IPv6 Proseminar: Internetprotokolle fur die ... · Protokoll: Protokolle sind Regeln, die den Nachrichtenaustausch – oder allgemeiner das Verhal- ten – zwischen (Kommunikations)Partnern