Domain Name System (DNS)

Während menschliche Benutzer und die meisten Anwendungsprogramme zur Adressierung entfernter Rechner im Internet symbolische Namen benutzen, verwendet die Netzwerk-Software aus Gründen der Effizienz und der Eindeutigkeit ausschliesslich die 32 Bits bzw. 128 Bits lange binäre IP-Adresse.

In der Anfangszeit des Internet, zur Zeit des ARPANET, wurde die Zuordnung zwischen symbolischen Rechnernamen und ihren binären Adressen mittels einer zentral gelagerte Datei host.txt organisiert, die fortlaufend zu aktualisieren war. Jeweils Nachts forderten dann alle Rechner des ARPANET diese Datei an, um ihre eigenen Adresszuordnungslisten zu aktualisieren. Ein derartiges Vorgehen war allerdings nur solange praktikabel, als das betreffende Netzwerk nur einige hundert Rechner umfasste. Mit dem explosionsartigen Wachstum des Internets wurde schnell klar, dass eine zentrale Verwaltung einer Namens-Adresszuordnung im großen Maßstab nicht mehr sinnvoll war, schon einfach aus dem Grund, weil die zu verwaltenden Zuordnungstabellen schnell viel zu groß und das massenhafte Update zu viel Bandbreite kostete und zu aufwändig wurde (siehe Abbildung).

Nutzung eines Internetdienstes über einen Namensdienst

Darüber hinaus barg dieser flach organisierte Namensraum noch zusätzlich das Problem, dass doppelt vergebene symbolische Namen erkannt und bereinigt werden mussten, was einen erheblichen Administrationsaufwand verursachte.

Zur Lösung dieses Problems wurde von Paul Mockapetris (* 1948) das sogenannte Domain Name System (DNS) entwickelt, das 1983 in den RFCs 882 und 883 spezifiziert und als Internetstandard publiziert wurde. 1987 wurde diese Spezifikation durch die RFCs 1034 und 1035 abgelöst. DNS arbeitet als verteilte Datenbankanwendung und dient dazu, symbolischen Namen binäre IP-Adressen zuzuordnen. Um die verteilte Anwendung sinnvoll zu organisieren, wurde der zur Verfügung stehende Adressraum hierarchisch strukturiert und verschiedenen Abschnitten jeweils eigene DNS-Server zugeordnet, die für die Zuordnung (Mapping) im betreffenden
Adressraumabschnitt verantwortlich sind.

IPv6 Basis-Header

Obwohl der Basis-Header eines IPv6-Datagramms nur gut die doppelte Länge eines IPv4-Datagrammheaders aufweist, ist es doch möglich, Sender und Empfängeradresse in ihrer gegenüber IPv4 vierfachen Länge von jeweils 128 Bits darin unterzubringen. Dieses Paradoxon erklärt sich aus der Tatsache, dass andere Informationen aus dem IPv4-Header weggelassen und in die optionalen Erweiterungs-Header verlagert wurden, die jeweils nur bei Bedarf genutzt werden. Der IPv6-Header weist gegenüber dem älteren IPv4-Datagrammheader sogar wesentliche Vereinfachungen auf (siehe Abbildung). Neben den beiden jeweils 16 Bytes (128 Bits) langen Adressen von Sender und Empfänger – der folgenreichsten Veränderung gegenüber IPv4 – beinhaltet der IPv6–Basis-Header lediglich sechs Felder:

  • Version
    Ebenso wie der IPv4-Datagrammheader startet der Basis-Header mit einer 4 Bits langen Versionsangabe zum verwendeten IP-Protokoll. Bei IPv6 steht hier stets der Wert 6.
  • Traffic Class
    Das 8 Bits lange TClass-Feld (Traffic Class) entscheidet über die Priorisierung des vorliegenden Datagramms relativ zu anderen Datagrammen und erlaubt es den Routern im Internet, das Datagramm einer bestimmten Datenverkehrsklasse zuzuordnen, wie z.B. Daten, Audio oder Video. Die Zugehörigkeit zu einer Datenverkehrsklasse entscheidet über das Verhalten der Router bzgl. Priorisierung, Warteschlangenverwaltung und überlastbedingtem Verwerfen von Datagrammen. Die Verwendung des TClass-Feldes wird in RFC 2474 (Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers) spezifiziert.
  • Flow Label
    Das 20 Bits lange FL-Feld (Flow Label, Übertragungsart) bietet Platz für eine zufällig gewählte Identifikationsnummer (im Bereich #00001 bis #FFFFF) für eine virtuelle Ende-zu-Ende-Verbindung, mit der bestimmte Datagramme für eine gesonderte Übertragung im globalen Internet gekennzeichnet werden können. Datagramme mit identischem Flow Label müssen auch dieselbe Quell- und Zieladresse beinhalten. Daher sind Router anhand des Flow Labels in der Lage, die betreffenden Datagramme direkt weiterzuleiten, ohne den Rest des Headers auswerten zu müssen. Darüber hinaus können Router anhand des Flow Labels besondere Transportentscheidungen zur Behandlung der betreffenden Datagramme treffen.

Eigenschaften und Merkmale von IPv6

Viele der Merkmale, die den Erfolg von IPv4 ausmachten, bleiben in der neuen Version erhalten. Nach wie vor handelt es sich bei IPv6 um einen verbindungslosen Datagrammdienst. Jedes IPv6-Datagramm enthält die Adressen von Sender und Empfänger. Der Time-to-Live Mechanismus, der die Anzahl der möglichen Hops eines IP-Datagramms festlegt, wurde ebenso wie die Möglichkeit der Angabe zusätzlicher Header-Optionen beibehalten. Obwohl die Basiskonzepte des erfolgreichen IPv4-Standards erhalten blieben, gibt es z.T. erhebliche Veränderungen in den jeweiligen Details:

  • Adressgröße und Adressraummanagement
    Die bisherige Adressgröße wird von 32 Bits auf 128 Bits erweitert. Die Adresse wird in Analogie zur Dezimal-Punkt-Darstellung bei IPv4-Adressen angegeben vermittels von maximal 8 vierstelligen Hexadezimalzahlen, die durch Doppelpunkte voneinander getrennt sind (z.B. 231B:1A:FF:02:0:3DEF:11). Darüber hinaus wurde besondere Rücksicht auf eine möglichst flexible Aufteilung des Adressraums und Nutzung der Adressbits gelegt.
  • Multiple Header
    Die verlängerte Adresse führt bei IPv6 zu einer erheblichen Verlängerung der Header. Um diesen unvermeidbaren Overhead so gering wie möglich zu halten, wurde das Konzept der optionalen Header eingeführt, die nur im Bedarfsfall Anwendung finden. Im Gegensatz zu IPv4 kann ein IPv6-Datagramm mehrere Header besitzen. Nach einem ersten obligatorischen Basis-Header können optional mehrere Erweiterungs-Header folgen, bevor sich daran die eigentlichen Nutzdaten anschließen.
  • Autokonfiguration
    Die Konfiguration eines IPv4 Netzwerkes ist meist sehr arbeitsaufwändig und komplex. Auch wenn Adresskonfigurationswerkzeuge und -protokolle, wie z.B. DHCP diese Arbeit erleichtern, lösen sie das Problem einer einfachen TCP/IP Administration nur teilweise. Daher wurde beim Design von IPv6 besonderer Wert darauf gelegt, die aktuell aufwändige Netzwerkkonfiguration so weit wie möglich zu vereinfachen und zu automatisieren.
  • Sicherheit
    Zu der Zeit als das Design von IPv4 festgelegt wurde, spielten Sicherheitsaspekte im Internet noch keine große Rolle, da niemand mit einer derartigen Verbreitung und Popularität des Mediums Internet gerechnet hatte und nur eine relativ überschaubare Anzahl von Einzelnetzwerken zu verbinden waren. Diese Situation hat sich drastisch verändert. Während Verschlüsselung und Authentifikation bei IPv4 lediglich optional über zusätzliche Protokolle (IPsec, siehe Abschnitt 7.5) realisiert werden, bietet IPv6 selbst die Unterstützung ausgereifter Sicherheitstechnologien.
  • Mobilität
    Mobilität spielte zu der Zeit, als das Design von IPv4 festgelegt wurde, im Internet keine Rolle. Erst das Aufkommen mobiler Endgeräte und der Versuch, diese ebenfalls mit dem weltweiten Internet zu verbinden, führten zur Entwicklung spezieller mobiler Internet Protokolle (MobileIP, siehe Abschnitt 7.7). IPv6 baut auf diesen Entwicklungen auf und bietet nativ bereits eine Unterstützung für mobile Netzwerke.
  • Erweiterbarkeit
    Während die Möglichkeiten von IPv4 voll ausdefiniert wurden, sieht IPv6 von vornherein die Möglichkeit der Erweiterung des Protokoll-Standards vor, wodurch zusätzlichen Anforderungen aus zukünftigen Entwicklungen Rechnung getragen werden kann. Es wird so eine hohe Flexibilität und Anpassungsfähigkeit gegenüber zukünftigen Verbesserungen erreicht.

IPv6 – Änderungsbedarf von IPv4

1983, bei der experimentellen Einführung des immer noch aktuellen Protokollstandards IPv4 für die Datenkommunikation im Internet wurde diesem nur eine kurze Lebensdauer prophezeit. Aller aktuellen Probleme zum Trotz erwies sich diese IP- Version jedoch als sehr langlebig und äußerst erfolgreich. So hat das globale Internet sein immenses Wachstum IPv4 zu verdanken. Das eigene IPv4-Datagrammformat und die Mechanismen von IPv4 zur Verbindung unterschiedlicher Netzwerktypen lassen das globale Internet als einheitliches, homogenes Netzwerk erscheinen und verbergen die zur Kommunikation notwendigen Details der Netzhardware und der Hardware-nahen Kommunikations-Software. Dank des ausgeklügelten Designs überlebte das IPv4-Protokoll eine Reihe von Hardware-Generationen, was sicher in seinem hohen Grad an Skalierbarkeit und seiner Flexibilität begründet liegt.

Weshalb soll also ein Protokoll ersetzt werden, das sich als derart robust erwiesen hat? Hauptgrund dafür ist die Aufteilung des eng begrenzten IP-Adressraums. Als IP Mitte der 70er Jahre entwickelt wurde, sah niemand das explosionsartige Wachstum der Datennetze des Internet voraus und so hielt man 32 Bits lange IP-Adressen für völlig ausreichend, immerhin erlaubt das den Anschluss von Millionen von unterschiedlichen Netzwerken. Das Wachstum des globalen Internets verlief jedoch exponentiell, die Anzahl der mit ihm verbundenen Computer verdoppelte sich stets in weniger als einem Jahr. Zwar scheint der Markt an Personal Computern bald gesättigt, doch zeichnet sich bereits die nächste Welle ab: Mobiltelefone, Sensoren, RFID-Geräte und zukünftig auch heute noch nicht geläufige ” Endgeräte“, wie z.B. Chipkarten, Haushaltselektronik oder Kfz-Nummernschilder aus dem ” Internet der Dinge“, alle werden mit Prozessoren ausgestattet sein, die über das globale Internet miteinander kommunizieren wollen. Die dazu notwendige eindeutige Adresse ist die Voraussetzung für eine globale (Inter-)Konnektivität. Daher liegt das erste und wohl wichtigste Ziel einer Erneuerung von IP in einer Erweiterung des bei IPv4 begrenzten Adressraums.

IPv4 ist ein verbindungsloser und unzuverlässiger Dienst, der zwar nach besten Vermögen arbeitet (Best Effort), jedoch keinerlei Dienstgütegarantien (Quality of Service) gewähren kann. Heutige Internet-Anwendungen arbeiten aber zunehmend mit multimedialen Dateninhalten, die eine annähernd echtzeitfähige Weiterleitung verlangen. Der zweite, gewichtige Grund für eine Renovierung von IPv4 lag daher in dessen Unvermögen, Dienstgütegarantien zu gewährleisten.

Die gängige Vergabepraxis von IPv4-Adressen an den Endanwender über einen Internet Service Provider (ISP) erfolgt über eine dynamische Adresszuweisung. Der Endanwender verbindet sein Internet-fähiges Endgerät über ein geeignetes Zugangsnetzwerk mit dem ISP, der diesem eine IPv4-Adresse aus dem ihm zur Verfügung stehenden Adresskoningent für eine bestimmte Zeitspanne zuweist. Nach Ablauf der Gültigkeit (meist spätestens nach 24 Stunden) muss wieder eine neue IPv4-Adresse zugewiesen werden. Bei diesem Vorgang werden bestehende Kommunikationsverbindungen unterbrochen. Das gilt auch im Bereich der mobilen Endgeräte, wenn bei der Übergabe einer Verbindung während des Funkzellenwechsels (Handover) eine neue IPv4-Adresse vergeben werden muss. Moderne Anwendungen erfordern aber oft eine sogenannte ” Always-On“-Konnektivität, d.h. die Verbindung zwischen dem Endgerät und dem Netzwerk muss permanent sein und darf nicht unterbrochen werden. Auch diese Anforderung kann nur nicht mit IPv4 erfüllt werden.

Bereits 1990 startete deshalb die IETF ein Projekt zur Entwicklung eines Nachfolgers für das IPv4-Protokoll. Vorläufiger Name des Projekts war zunächst IP – The Next Generation (IPnG). Nach Abschluss der Definitionsphase wurde dann nach einem endgültigen Namen gesucht, schließlich nannten sich auch viele andere Projekte ” Next Generation“. So wurde beschlossen, eine neue Versionsnummer für dieses IP-Protokoll zu wählen. Dabei kam die Versionsnummer 5 nicht in Frage, da diese bereits für das experimentelle Stream Protocol Version 2 (ST2) vergeben worden war. Das inzwischen aufgegebene ST2 war nicht als IPv4-Nachfolger geplant, sondern als gleichzeitig benutzbares, für das Streaming optimiertes Kommunikationsprotokoll. So wurde für die Nachfolgeversion von IPv4 die Versionsnummer 6 gewählt und IPv6 zum Nachfolger von IPv4.

Fragmentierung

Jeder Netzwerktyp beschränkt die Maximallänge eines einzelnen, zu übertragenden Datenpakets auf einen bestimmten Wert. Verantwortlich dafür sind Beschränkungen von Seiten der Hardware, des verwendeten Betriebssystems, von Protokoll- und Standardkonventionen oder Beschränkungen, die durch konkurrierende Ziele hervorgerufen werden. Zu diesen zählen z.B. die Verringerung vonÜbertragungsfehlern in einem einzelnen Datenpaket (je länger, desto mehr Fehler sind möglich) oder eine möglichst kurze Belegungszeit des Übertragungsmediums durch ein einzelnes Datenpaket.

Die Maximallänge der transportierten Nutzlast reicht von 48 Bytes bei ATM- Datenpaketen bis hin zu 65.515 Bytes für IP-Datenpakete (IPv4), wobei auf höheren Protokollschichten auch noch größere Paketlängen möglich sind. Werden verschiedenartige Netzwerke miteinander verbunden, so können die Datenpakete des einen Netzwerks zu groß sein für das nachfolgende Netzwerk. Zwar könnte man dieses Problem einfach dadurch lösen, dass man eine Weiterleitung der betreffenden Datenpakete in ein Nachbarnetzwerk nur dann gestattet, wenn dieses die Ursprungsdatenpakete jeweils vollständig in einem Stück transportieren kann. Allerdings könnten dann bestimmte Destinationen nicht von jedem Netzwerk aus erreicht werden. Es ist also ein alternatives Verfahren nötig, das den Transport zwischen beliebigen Netzwerkkombinationen gestattet, unabhängig von den jeweils geltenden Beschränkungen bzgl. der maximal erlaubten Datenpaketlänge.

Die Grundidee zu einem solchen Verfahren besteht darin, Datenpakete eines Netzwerks mit großer Paketlänge zur Übertragung über ein Netzwerk mit geringerer Paketlänge in einzelne Teilstücke (Fragmente) aufzubrechen und beim Verlassen dieses Netzwerks oder zu einem späteren Zeitpunkt wieder in das ursprüngliche Datenpaket zusammenzusetzen. Dabei erweist sich das Zusammensetzen der fragmentierten Datenpakete stets als die schwierigere der beiden Operationen.

Adressklassen

Bei der festgelegten Adresslänge von 32 Bits war zu entscheiden, welcher Anteil für die Netzwerk-IDs und welcher für die Host-IDs vergeben werden soll. Da zu den an das Internet angeschlossenen Netzwerken oft ganz unterschiedlich viele Rechner gehören, tatsächlich gibt es nur wenige sehr große Netzwerke, aber eine Vielzahl kleinerer, entschied man sich für einen Kompromiss: Der IP-Adressraum wurde in fünf verschiedene Adressklassen unterteilt, wobei in drei Klassen Adresspräfix und Adresssuffix über einen unterschiedlichen Anteil an den zur Verfügung stehenden 32 Bits langen IP-Adressen verfügen. Aus den ersten Bits einer IP-Adresse ergibt sich die jeweils vorliegende Adressklasse und damit die Aufteilung der Adresse in Adresspräfix und Adresssuffix. Die Abbildung zeigt die zulässigen IP-Adressklassen. Sie basieren auf der für TCP/IP- Protokolle gültigen Konvention, dass die Bits jeweils von links nach rechts gelesen werden, wobei das erste linke Bit als 0. Bit bezeichnet wird.

  • IP-Adressen der Klasse A waren nur für sehr große Netzwerke vorgesehen, an die mehr als 2 16 Rechner angeschlossen werden sollen. Zu den Inhabern von Klasse-A Netzwerken zählen große Firmen wie IBM oder die amerikanische Regierung. Dabei sind in einer IP-Adresse der Klasse A 7 Bits für die Netzwerk-ID vorgesehen und 24 Bits für die Host-ID, so dass theoretisch bis zu 16.888.214 Rechner an ein einziges Klasse-A-Netzwerk angeschlossen werden können.
  • IP-Adressen der Klasse B dagegen waren für mittelgroße Netzwerke vorgesehen. Diese kommen in weitaus größerer Anzahl vor, weshalb für deren Netzwerk-ID auch 14 Bits nutzbar sind. Für Host-IDs bleiben dann 16 Bits übrig. Ein Klasse-B-Netzwerk erlaubt den Anschluss von bis zu 65.534 einzelnen Rechnern.
  • IP-Adressen der Klasse C besitzen die größte Verbreitung. Die 21 Bits für die Netz-ID einer IP-Adresse der Klasse C, die eine maximale Anzahl von 2.097.152 eindeutig adressierbaren Netzwerken erlaubt, schränkt allerdings den zur Verfügung stehenden Raum für Host-IDs auf 8 Bits ein. Da jeweils zwei der möglichen Host-IDs reserviert sind (Local Host und Broadcast), können maximal 254 Rechner an ein Klasse-C-Netzwerk angeschlossen werden.

Datagramm

Das Internet Protocol (IP) bietet dem Anwender bzw. einem Anwendungsprogramm einen verbindungslosen Dienst (Datagrammdienst), der die Zustellung von IP- Datenpaketen (Datagrammen) über Netzwerkgrenzen hinweg zu einem entfernten Empfänger besorgt. Der von IP angebotene Dienst sieht jedoch keine Dienstgarantien für den Nutzer vor. Ob und wann ein einmal versendetes Datenpaket tatsächlich den designierten Empfänger erreicht, wird nicht garantiert – auch wenn man davon ausgeht, dass die Zustellung in der Regel zuverlässig und so schnell wie möglich erfolgt (Best Effort). Doch können Fehler oder Überlast in den einzelnen Netzwerken dazu führen, dass ein Paket verfälscht wird, für eine unzumutbar lange Zeitspanne unterwegs ist, dupliziert wird oder sogar verloren geht. IP wird deshalb als unzuverlässiger Dienst bezeichnet. Allerdings – und das ist der große Verdienst des IP-Protokolls – verbirgt IP die jeweils unterschiedliche Netzwerk- Hardware und alle Details der darauf eingesetzten Netzwerk-Software vor den Augen des Internet-Nutzers, dem dadurch ein einheitliches und homogenes Netzwerk vorgetäuscht wird.

Wie erreicht nun ein IP-Datenpaket sein vorbestimmtes Ziel? Der Sender trägt im Datenheader des IP-Datenpakets die IP-Adresse des Empfängers ein und schickt das IP-Datenpaket auf die Reise in das lokale Netzwerk. Das IP-Datenpaket wird dazu in ein Netzwerk-Datenpaket (Schicht 2) verpackt ( ” gekapselt“) und entsprechend den Anforderungen des lokalen Netzwerks an den nächstliegenden Router (Vorgabe-Router) gesendet. Dieser entpackt das IP-Datenpaket, wertet die angegebene IP-Zieladresse aus und sendet das IP-Datenpaket neu gekapselt über das nächste Netzwerk zum Folgerouter entlang des Pfades zum vorbestimmten Ziel. Dieser Vorgang wiederholt sich so lange, bis das IP-Datenpaket einen Router erreicht, der es in einem der an ihn angeschlossenen Netzwerke direkt zum Endziel befördern kann. Da das IP-Datenpaket über verschiedenartige Netzwerke mit den unterschiedlichen Kenngrößen und Parametern befördert werden muss, wurde für das IP-Datenformat ein Format gewählt, das vollkommen unabhängig von diesen Kenngrößen der jeweils zugrunde liegenden Hardware ist.

Das bis heute aktuelle und am weitesten verbreitete IP-Protokoll ist IP Version 4 (IPv4). Obwohl die Unzulänglichkeiten dieses mittlerweile in die Jahre gekommenen Protokolls schon seit langem bekannt sind, wird es seine Bedeutung sicher noch für einige weitere Jahre behalten. Der designierte Nachfolger IPv6 steht bereits seit langem in den Startlöchern, allerdings kommt eine weltweite Umstellung auf das neue Internet Protokoll nur langsam in Gang. Das IPv4-Datagramm folgt in seinem Aufbau wie viele andere Protokoll-Datenformate dem bereits bekannten Schema eines gesonderten IP-Datenheaders, in dem Steuer- und Kontrollinformationen untergebracht sind, die zur korrekten Weiterleitung des Datagramms benötigt werden, und der IP-Nutzdaten mit den eigentlich zu übertragenden Daten. Die Größe eines IPv4-Datagramms kann vom Nutzer bzw. einer Anwendung selbst festgelegt werden, d.h. die zu befördernde Datenmenge ist nicht festgeschrieben. Lediglich darf ein IPv4-Datagramm die maximale Länge von 64 kByte nicht überschreiten. Je länger das zu transportierende Datagramm, desto besser ist das Verhältnis zwischen transportierter Nutzinformation und Overhead, der durch die im Header enthaltene Steuer- und Kontrollinformation verursacht wird. Der IP-Datenheader besteht aus einem 20 Bytes langen, fixen Teil und einem optionalen Teil variabler Länge; die Länge der transportierten IP-Nutzdaten ist innerhalb der vorgegebenen Längenbegrenzung variabel. Die Übertragung des Datagramms erfolgt in der sogenannten Big Endian Order, d.h. von links nach rechts, wobei die Übertragung mit dem High-Order-Bit des ersten Feldes startet.

Adressierung

Wie bereits dargestellt, besteht das Ziel jedes Internetworking darin, dem Nutzer die Illusion zu geben, ein großes, einheitliches Netzwerk vor sich zu haben, und die eigentlichen physischen Details der darunter liegenden Netzwerke zu verbergen. Das globale Internet ist dabei wie jedes andere Internet nichts anderes als ein reines Software-Produkt, das im wesentlichen aus der Protokollsoftware und insbesondere dem IP-Protokoll, z.Z. meist in der Version 4, IPv4 besteht. Dieses schreibt dem Nutzer unabhängig von der verwendeten Hardware alle notwendigen Kommunikationsparameter wie Datenpaketgröße und -format zwingend vor, und stellt ein universelles Adressierungsschema bereit, mit dem es möglich ist, jeden einzelnen mit dem Internet verbundenen Rechner direkt anzusprechen.

Dank dieses IP-Adressierungsschema erscheint das globale Internet dem Nutzer tatsächlich als ein einziges homogenes und universelles Netzwerk und es bleiben die Details der vielen Einzelnetze, aus denen das Internet besteht, vollständig vor seinen Augen verborgen. Zwar bleiben den meisten Nutzern auch die eigentlichen IP-Adressen verborgen – an ihrer Stelle können leichter zu merkende, hierarchisch aufgebaute, logische Namen verwendet werden –, doch bevor auf die Eigenheiten dieser Namensvergabe und die Regeln zur Umsetzung von Namen in IP-Adressen eingegangen wird , soll zuerst das eigentliche IP-Adressierungsschema von IPv4 vorgestellt werden.

IP-Adresshierarchie und -klassen
Um einen an das Internet angeschlossenen Rechner eindeutig zu adressieren, erhält er in Anlehnung an die in Netzwerken verwendete Hardware-Adressierung eine 32- Bit lange Internet-Adresse (IP-Adresse). Jede IP-Adresse besteht aus 4 Bytes (4 Oktetten), die meist als Folge von 4 vorzeichenlosen, ganzzahligen, durch Dezimalpunkte getrennte Dezimalzahlen angegeben wird. Beispiel:

IP-Adresse: 155.136.32.17

Diese Schreibweise wird als Punkt-Dezimal-Notation (Dotted Decimal Notation) bezeichnet. Da jede Dezimalzahl ein einzelnes Adressbyte repräsentiert, können Werte aus dem Bereich von 0 bis 255 angenommen werden. Der gesamte, theoretisch verfügbare Adressbereich solcher 32 Bit IP-Adressen umfasst in Dezimaldarstellung also den Bereich

0.0.0.0 bis 255.255.255.255

Logisch gliedert sich eine IP-Adresse in zwei Teile, einen Adresspräfix und einen Adresssuffix. Die mit dieser Struktur erreichte Hierarchie soll das Routing durch das Internet vereinfachen. Der Adresspräfix identifiziert das physikalische Netzwerk, an das der betreffende Rechner angeschlossen ist, und wird auch als Netzwerk-ID (Network Identification, NetId) bezeichnet. Das Adresssuffix dagegen identifiziert einen konkreten Rechner in dem durch die Netzwerk-ID bestimmten Netzwerk. Daher wird das Adresssuffix auch als Host-ID (Host Identifier) bezeichnet. Während Host-IDs in einem bestimmten, durch eine eindeutige Netzwerk-ID beschriebenen Netzwerk stets eindeutig vergeben werden, können in unterschiedlichen Netzwerken durchaus identische Host-IDs benutzt werden. Dieses Schema der Adresshierarchie unterstützt eine globale Verwaltung der Netzwerk-IDs, während die Verwaltung der Host-IDs lokal durch den jeweiligen Netzwerk-Administrator erfolgen kann.

Ein Problem, das sich aus dieser Aufteilung der IP-Adressen in Netzwerk-IDs und Host-IDs ergab, war, dass zum Einen sowohl genügend viel Raum vorgesehen werden musste, um alle physisch existierenden Netzwerke eindeutig adressieren zu können, zum Anderen aber auch für jedes Netzwerk genügend viele Adressen zur Verfügung stehen müssen, auch wenn eine große Zahl von Rechnern daran angeschlossen ist.

Dijkstra-Algorithmus

Die Bestimmung des kürzesten Weges (Shortest Path) vom Sender zum Empfänger innerhalb eines Netzwerks ist für eine Vielzahl von Routingverfahren von entscheidender Bedeutung. Eine einfache Technik, die in diesem Zusammenhang häufig zum Einsatz kommt, ist der sogenannte Dijkstra-Algorithmus, benannt nach seinem Erfinder Edsger W. Dijkstra (1930–2002).

Edsger W. Dijkstra

Der Dijkstra-Algorithmus arbeitet auf einem Graphen, dessen Knoten die Router des Netzwerks und dessen Kanten die Verbindungen zwischen den einzelnen Routern darstellen. Das Verfahren ermittelt die Länge der kürzesten Wege von einem Sender zu allen Routern im Netz und stellt während der Berechnung eine Routingtabelle für den Sender zusammen.

Welcher Weg dabei den kürzesten Weg in einem Netzwerk darstellt, hängt von der gewählten Metrik ab, z.B. der Anzahl der notwendigen Hops vom Sender zum Empfänger. Allerdings ist diese Vorgehensweise in der Praxis nicht immer zielführend, da die Verbindungen zwischen den einzelnen Netzwerkkomponenten unterschiedliche Bandbreiten besitzen und sich über unterschiedliche Entfernungen erstrecken können. Daher macht es Sinn, die Verbindungen entsprechend ihrer Bandbreite und ihrer räumlichen Ausdehnung zu gewichten, und in die Gewichtung auch Größen, wie z.B. die Schaltgeschwindigkeit des Routers oder Wartezeiten innerhalb des Routers, mit einzubeziehen. Daneben kann die Benutzung von Übertragungsleitungen auch mit Kosten verbunden sein, die ebenfalls in die Gewichtung der Netzwerkkanten mit einfließen kann. Der Dijkstra-Algorithmus ist in der Lage, stets den kürzesten Weg entsprechend der gewählten Metrik zu bestimmen.

Die Internetschicht

Das Internet Protokoll bildet das verbindende Element für die unterschiedlichsten Netzwerktechnologien und erschafft damit aus einem bunten Fleckenteppich unterschiedlicher Architekturen ein einheitliches, homogenes und globales Netzwerk. Doch damit alleine ist es noch lange nicht getan. IP stellt lediglich einen unzuverlässigen und unsicheren Dienst zur Verfügung: Einmal abgesendete Datenpakete bewegen sich unabhängig voneinander im Netz zum Empfänger, aber es wird keine Garantie für deren sichere und zuverlässige Zustellung übernommen. Zuverlässige Kommunikation ist aber eine Grundvoraussetzung für einen effizienten und sicheren Datenverkehr im Netzwerk.

Eine Anwendung muss sich darauf verlassen können, dass einmal gesendete Daten auch tatsächlich den designierten Empfänger erreichen bzw. muss zeitnah und zuverlässig feststellen können, ob die gesendeten Daten auch tatsächlich ihr Ziel erreicht haben oder nicht. Die Etablierung und Gewährleistung einer sicheren und zuverlässigen Kommunikationsverbindung zählt zu den Aufgaben der nächsthöheren Protokollschicht im TCP/IP-Referenzmodell, der Transportschicht. Dort arbeiten das komplexe und zuverlässige Transport Control Protocol (TCP) und das auf Geschwindigkeit hin optimierte User Datagram Protocol (UDP), die dem Benutzer komfortable Werkzeuge zum Verbindungsmanagement bieten. Die Protokolle der Transportschicht legen eine weitere Abstraktionsschicht über das Internet und realisieren eine direkte Ende-zu-Ende-Verbindung, ohne dass dabei auf die Details des Datentransports, wie z.B. das Routing des Datenverkehrs, Rücksicht genommen werden muss.