Das Internet der nächsten Generation (IPng) oder auch IPv6 wird vordergründig vor allem eines können: unendlich viele "Hausnummern" vergeben. Das derzeitig noch vorrangig eingesetzte Internetprotokoll in Version 4 (IPv4) wurde 1983 in der Praxis eingeführt [1] – zu einer Zeit, in der etwa 1000 Rechner an "das Netz" angeschlossen waren (die Standards waren auch da schon einige Jahre alt). Mittlerweile beanspruchen jedoch immer mehr Endanwender, Telefone und sogar einige Waschmaschinen und Kühlschränke ihren Draht zum World Wide Web, was den Adressenhaushalt des heutigen Internets zunehmend sprengt.
Bei IPv5, das nie umfassend spezifiziert wurde, sträubten sich die Hersteller noch: Als einstiger Nachfolger von IPv4 konzipiert, sollte die neue Version vor allem die Übertragung von Audio- und Videodaten besser unterstützen. Das Update des Internetprotokolls war jedoch seiner Zeit vermutlich voraus: Die Hard- und Softwareindustrie zeigte sich nach Abwägung von Kosten und Nutzen wenig interessiert, ihre Produkte zusätzlich für IPv5 fit zu machen – Adressen für den Webspace gab es damals auch noch reichlich.
Die Situation hat sich mittlerweile geändert. Das Internet greift beharrlich in alle Lebensbereiche ein, komplett vernetzte Haushalte sind keine weltfremde, ferne Vision mehr. Netzwerkfähige Handhelds, Smartphones und Home-Appliances sind bereits Realität, man sieht über das Internet fern und führt mithilfe von Voice over IP (VoIP) Telefonate. Die Nachfrage nach IP-Adressen wird zudem durch Schwellenländer wie China und Indien angeheizt, die im Rahmen ihres Wachstums einen gewaltigen Hunger nach den digitalen Hausnummern entwickeln. IPv4 arbeitet jedoch mit einem 32-Bit-Adressraum und ermöglicht so nur knapp 4,3 Milliarden Internetadressen – abzüglich reservierter und spezieller Adressbereiche (RFC 3330) und Adressen, etwa für Netzbezeichnung, Multicast oder "private" IPs (RFC 1918).
Die Knappheit an Internet-Adressen hat mittlerweile auch die IT-Industrie vor Augen, sodass IPv6 wesentlich mehr Unterstützung erfährt als sein angedachter Vorgänger – wenngleich mit erheblicher Verzögerung: Denn IPv6 wurde als RFC 1883 bereits im Dezember 1995 als Proposed Standard vorgestellt und drei Jahre später als RFC 2460 zum Draft Standard [2]. Mittlerweile unterstützen bereits fast alle verbreiteten Betriebssysteme und eine beträchtliche Zahl von Routern alternativ auch IPv6. Zudem hat der Verband der deutschen Internetwirtschaft (![[externer Link]](../../../../images/link.gif)
www.eco.de) schon vor einem Jahr festgestellt, dass die deutsche Wirtschaft "massiv in die nächste Generation der Datenstandards investiert": Im September 2004 übersprang der Anteil der Internet Service Provider (ISP), die eine IPv6-fähige Anbindung am zentralen deutschen Internetknoten De-Cix besaßen, erstmals die Marke von 25 % – derzeit beträgt dieser Anteil gut 23 % ( www.de-cix.de/info/connected.html).
Die an der Entwicklung von IPv6 beteiligten Organisationen Internet Engineering Task Force (IETF) und North American IPv6 Task Force (Nav6TF) haben sich darauf geeinigt, IP-Adressen im v6-Format von derzeit 32 auf 128 Bits aufzustocken. Der neue Standard ermöglicht damit eine enorme Zahl von IP-Nummern: Laut einer Rechnung des IPv6-Forums ist es theoretisch möglich, 655 570 793 348 866 943 898 599 Adressen pro Quadratmeter Erde zu vergeben. Der gesamte Adress-Pool umfasst rund 3,4 mal 1038 (wiederum abzgl. Spezialadressen); mathematisch gesehen wäre das genug, um jedem Insekt dieser Erde einen Internetanschluss zu verpassen.
Diese "Größe" schlägt sich naturgemäß auch in der Darstellung der Adressen nieder. Von den "handlichen" IPv4-Adressen mit vier Dezimalzahlen (z. B. 192.168.0.42) muss man sich auf weniger leicht vorzulesende Hexadezimal-Folgen umstellen: Eine IPv6-Adresse benötigt in vollständig ausgeschriebener Textform acht Gruppen zu vier Hex-Ziffern, die durch Doppelpunkte getrennt werden – zum Beispiel 2001:0db8:0000:1337:0000:0000:0000:0017. Um das Ganze etwas abzukürzen, darf man führende Nullen innerhalb einer Gruppe weglassen (2001:db8:0:1337:0:0:0:17) und maximal eine Folge von beliebig vielen Null-Gruppen durch die Abkürzung "::" ersetzen, was für unser Beispiel die Kurzschreibweise 2001:db8:0:1337::17 ergibt.
Wie schon bei IPv4 können Adressbereiche durch einen Präfix bezeichnet werden, an den durch Schrägstrich getrennt die (dezimale) Zahl der relevanten Bits angehängt wird. Bei 2001:db8::/32 handelt es sich etwa um den Präfix desjenigen Adressbereichs, der mittlerweile offiziell für Dokumentations- und Beispielzwecke vereinbart wurde (RFC 3849). Als "Sonderbereiche" sind FC00::/7 (Unique Local Unicast, s. u.), FE80::/10 (Link Local Unicast) und FF00::/8 (Multicast) definiert (s. RFC 3513). Zudem bezeichnen die beiden Einzel-Adressen ::0 (meist nur ::) die "unspezifizierte Adresse" und ::1 die so genannte Loopback-Adresse (in IPv4 127.0.0.1).
Der gesamte restliche Adressraum ist für "Global Unicast"-Adressen vorgesehen, die weltweit routing-fähig sind und eindeutig IPv6-Netzknoten bezeichnen (genauer: deren Schnittstellen/Netzwerk-Adapter). Zurzeit ist allerdings von der Internet Engineering Task Force (IETF) "nur" ein Achtel des gesamten IPv6-Adressraums zur Vergabe durch die Internet Assigned Numbers Authority (IANA, www.iana.net) freigegeben: Momentan entstammen alle offiziell vergebenen IPv6-Adressen somit dem Segment 2000::/3 (also 2000:... bis 3FFF:...).
Die Vergabe von Adressraum erfolgt dabei streng hierarchisch: Innerhalb dieses freigegebenen Bereichs verteilt die IANA "kleinere" Adresssegmente an die fünf Regional Internet Registries (RIR), die diese wiederum – üblicherweise über weitere Zwischenstufen – in kleinere Segmente für Internet-Service-Provider (ISPs) "zerstückeln", die daraus letztlich ihren Kunden einen Adressbereich zuweisen.
Von den 128 Bit einer IPv6-Adresse ist die (hintere) Hälfte fix als Interface ID vorgesehen, die ersten 64 Bit teilen sich der Global Routing Prefix und die Subnet ID (vgl. Abb. 1): Einen n-Bit-langen Global Routing Prefix vergibt dabei ein ISP (der angesprochenen Hierarchie folgend) an einen Kunden, dem die verbleibenden 64 − n Bits der Subnet ID zur freien Verfügung stehen, um seine internen Netze zu segmentieren. Der Regelfall ist dabei die Vergabe eines 48-Bit Global Routing Prefix, sodass dem Kunden (vom Heimanwender bis zum großen Unternehmen) 16 Bit oder anders ausgedrückt 65 536 eigene Teilnetze zur Untergliederung verbleiben, die jeweils (!) 264 einzelne Interface IDs umfassen. Größere Subnetz-Anteile sind nur für "sehr große Netzteilnehmer" vorgesehen, kleinere nur für Szenarien angeraten, wo sicher erscheint, dass lediglich ein einzelnes Subnetz (z. B. für ein Handy, das andere Geräte über Bluetooth anbindet) oder ein einzelnes Endgerät (z. B. ein Notebook im Hotelzimmer) erforderlich sind (RFC 3177).
![[Illustration]](05-5-012-1.jpg)
Abbildung 1: Netz- und Interface-Anteil einer IPv6-Adresse betragen jeweils 64 Bit. Die Aufteilung des Subnet Prefix ist zwar prinzipiell beliebig, laut Empfehlung zur Adressaufteilung werden Internet Service Provider aber fast generell 48-Bit Global-Routing-Präfixe vergeben (n=48).
Die im obigen Beispiel genannte IPv6-Adresse 2001:db8:0:1337::17 könnte sich demnach – läge sie nicht im "Demo-Netz" – wie folgt ergeben haben: Der umgebende Bereich 2001:c00::/23 wurde von der IANA dem Registrar für den Asia-pazifischen Raum (APNIC) zugewiesen (dieser Block umfasst rund 33,5 Mio. 48-Bit-Präfix-Netze), der hieraus in unserer Fiktion einem großen ISP 2001:d80::/26 zur Verfügung stellt (also 2001:0d80:... bis 2001:0dbf:... – genug Raum für knapp 4,2 Mio. Kunden). Das Unternehmen, dem unsere Beispiel-IP gehört, hat von diesem ISP den Adressbereich (Global Routing Prefix) 2001:db8:0::/48 erhalten. Erst was nun folgt ist "Privatsache": Die genannte Beispieladresse liegt im Subnetz 1337 dieses Unternehmens und hat dort die Interface-Adresse ...:0:0:0:17.
Wichtig ist diese strenge Hierarchie der Adressbereiche für das Routing im stetig wachsenden Internet der nächsten Generation: Die klare Struktur verringert die Anzahl der Einträge in den Routing Tables enorm, da jeweils nur die Untergliederung der "eigenen Ebene" in die Router programmiert werden muss. Im Übrigen unterstützt das neue Internetprotokoll die existierenden Routing-Protokolle wie OSPFv3, IS-ISv6, RIPng und MBGP4+.
In Sachen Adressierung wird mit IPv6 zukünftig neben den bisher bekannten Adresstypen Multicast und Unicast, die neue Kategorie Anycast eingeführt: Dieser Typ zielt wie Multicast auf eine Gruppe von Empfängern – anders als bei einem Multicast erhält aber nicht jedes Gruppenmitglied das Datenpaket, sondern nur ein einziger Knoten (beispielsweise bei einer DNS-Anfrage der am nächsten gelegene). Auch hierdurch können Netzwerkkapazitäten geschont werden.
Nicht zuletzt ist das Adressformat der neuen Generation (vgl. Kasten/Abb. 2) im Vergleich zum Format der IPv4-Header auch einfacher strukturiert, da einige Felder des IPv4-Headers in Erweiterungs-Header ausgelagert wurden. Dies erleichtert Netzwerkhardware das Lesen von Adressen und beschleunigt wiederum den Datenverkehr.
----------Anfang Textkasten----------
Die Header in IPv6 sind zwar länger, aber einfacher strukturiert. Im Ganzen ist der IPv6-Header durch optionale Bestandteile (Header Extensions) zwar länger als bei IPv4, der Grundbaustein wurde jedoch um die Felder Header Length, Identification, Flags, Fragment Offset, Header Checksum und Padding verkürzt. Zudem sind alle Felder im neuen Header-Format auf 64 Bit abgestimmt.
Die Felder des Basis-Headers bedeuten im Einzelnen: Version (4 Bit) markiert die Internet-Protocol-Version und enthält bei IPv6 naturgemäß den statischen Wert 6. Die Standardkennzeichnung im Header ermöglicht den parallelen Betrieb der verschiedenen IP-Versionen, die für einen fließenden Übergang ausgelegt sind. Class (8 Bit) gibt die Prioriät der zu übermittelnden Daten an: Je nach Netzauslastung und Belegung des Class-Feldes können Router Pakete auf unterschiedlichen Wegen zum Empfänger schicken, verwerfen oder wenn nötig auch den Wert dieses Feldes ändern. Das Flow-Label (20 Bit) markiert Datenpakete, für die eine besondere Behandlung benötigt wird, zum Beispiel bei Daten für Echtzeitanwendungen (Quality-of-Service-Funktionen). Alle Pakete mit diesem Label müssen dieselben Hop-by-Hop- und Routing-Header erhalten. Die Payload Length (16 Bit) notiert die Länge des Datenpakets. Next (8 Bit) bezeichnet den Typ des ersten Erweiterungs-Header nach dem IPv6-Basis-Header. Das Hop-Limit (8 Bit) bestimmt, nach wie vielen Durchgängen das Paket von einem Router verworfen werden soll, um Schleifen zu vermeiden. Source und Destination Address (je 128 Bit) geben die Absender- beziehungsweise Empfängeradresse an.
![[Illustration]](05-5-012-2.jpg)
Abbildung 2: IPv6 Header-Format
----------Ende Textkasten----------
Um es noch einmal zu betonen: Die Aufteilung der 128-Bit-Adressen in 64 Bit Netzwerk- und 64 Bit Host-Anteil ist fest vorgegeben. Die von IPv4 bekannten Netzmasken, die hierfür eine flexible – oft aber eher verwirrende – Zuordnung ermöglicht haben, entfallen ersatzlos. Eine weitere wesentliche Änderung ist zudem, dass jedes Interface beliebig viele IP-Nummern tragen kann.
Die Zuweisung von IPv6-Adressen kann dabei wie gehabt statisch manuell oder per IPv6-Version des Dynamic Host Configuration Protocol erfolgen (DHCPv6, RFC 3315). Eine neue, zusätzliche Möglichkeit stellt die automatische Konfiguration dar: Bei der so genannten Stateless Address Autoconfiguration (RFC 2462) leitet beispielsweise eine Ethernet-Karte ihre IPv6 Interface ID auf festgelegte Weise eindeutig aus ihrer MAC-Adresse (Media Access Control) ab und verhandelt mit auffindbaren Routern oder benachbarten Systemen letztlich eine eindeutige IP-Nummer. Da MAC-Adressen (weitgehend) global eindeutig sind, entsteht hieraus durch Ergänzen um einen Global Routing Prefix eine global eindeutige IPv6-Adresse, ohne dass es dafür eines administrativen Eingriffs bedarf.
Neben diesem Vorteil birgt das Verfahren allerdings auch (Datenschutz-)Risiken: Denn eine derart erstellte, weltweit eindeutige Interface ID bleibt weltweit eindeutig, selbst beim Wechsel des Subnetzes oder beispielsweise beim Einsatz in einem fremden Netz, das ebenfalls diese Art der Auto-Konfiguration unterstützt. Somit können weitreichende Bewegungs- und Nutzungsprofile entstehen. Abhilfe versprechen die Privacy Extensions for Stateless Address Autoconfiguration (RFC 3041), die über den Einsatz einer Hash-Funktion aus der MAC-Adresse regelmäßig neue pseudo-zufällige Interface IDs ableiten und hierzu gleich mehrere – ebenfalls nur temporär gültige – IPv6-Adressen erstellen. Beim Wechsel in ein anderes Subnetz wird im Zuge der Adressaushandlung dann eine neue Interface ID generiert, mit der das System von nun an in diesem Netz auftritt. Aufgrund der Möglichkeit mehrerer IP-Nummern pro Interface bleibt das Gerät aber dennoch für eine gewisse Zeit unter den "alten" IPs erreichbar. Im Übrigen werden die Adressen auch zeitgesteuert verworfen. Als Standardeinstellung gelten sieben Adressen, wobei jeweils nach einem Tag eine neue hinzukommt und die älteste wegfällt.
Eine "unverschleierte" Automatik-IP aufgrund der MAC-Adresse liefert zudem in aller Regel Auskunft über die Art der eingesetzten Hardware, da die ersten 24 Bit der MAC-Adresse eine vom IEEE verwaltete Herstellerkennung darstellen (Organisational Unique Identifier, OUI). Im Extremfall lassen sich hieraus möglicherweise sogar Hinweise auf bestimmte Schwachstellen der Hardware ableiten.
Durch den fast unbegrenzten Adressraum bei IPv6 wird Network Address Translation (NAT) überflüssig – und ist zunächst auch nicht als Option vorgesehen. Die vormals für IPv4 definierten "Private Internets" entfallen. Auch wenn mit "Unique Local Unicast"-Adressen hier ein Ersatz für den Aufbau von IPv6-Netzen ohne offiziell zugeteilten Adressraum in der Planung ist [3], so besteht auch dort das Ziel, mit möglichst hoher Wahrscheinlichkeit eindeutige Adressen zu generieren. Die Paradigmen von IPv6 lauten "globale IP-Adressen" und "Ende-zu-Ende-Sicherheit".
Einerseits entfallen hierdurch natürlich der zusätzliche Aufwand und auch spezifische Probleme für bestimmte Protokolle im Zusammenhang mit NAT. Zum anderen zeigt sich aber auch hier das Datenschutzrisiko weltweiter Beobachtbarkeit einzelner Systeme: Wo sich bei IPv4 womöglich Tausende PCs unter derselben IP-Nummer im Netz bewegt haben, werden diese plötzlich unterscheidbar. Wie viel Nutzen das einem Beobachter beziehungsweise Angreifer bringt, lässt sich schwer abschätzen. Die Verknüpfung verschiedener Quellen kann jedoch immer heikel sein: Wenn etwa durch einen typischen Mail-Header-Eintrag die IP-Adresse des PCs eines Geschäftsführers bekannt wird und man diese anschließend in verschiedenen Log-Files im Internet wiederfindet, mag das durchaus unerwünschte Erkenntnisse für Dritte liefern.
NAT an sich ist zwar kein Sicherheitsmechanismus und kann sicherlich auch heute nur in Verbindung mit einer Firewall sinnvoll sein. Dennoch könnte im NAT-Umfeld ein Angreifer bei einer Fehlkonfiguration der Firewall nicht ohne weiteres einen beliebigen internen Client von außen ansprechen – mit einer global erreichbaren und möglicherweise auch bekannten IPv6-Nummer ginge das. Als Gegenmaßnahme sind wechselnde IP-Adressen oder der Einsatz nicht-transparenter Proxys denkbar.
Verschwinden oder deutlich zurückgehen dürfte hingegen mit der explosionsartigen Vergrößerung des Adressraums das Phänomen umfassender Netzwerk-Scans: Wer den 64-Bit großen Interface-ID-Bereich auch nur eines Subnetzes vollständig durchsuchen wollte, muss bei 1 Sekunde pro IP-Nummer über 500 Milliarden Jahre auf das Ergebnis warten. Selbst in einem Netz, wo die MAC-Adressumsetzung den variablen Anteil auf 48 Bit reduziert und man die Suche auf die vier größten Hersteller von Netzwerkhardware einschränkt (somit 2 Bit Varianz statt 24 Bit Herstellerkennung), dauert der "vollständige" Scan noch rund zwei Jahre. Ein – in aller Regel ja vergleichsweise "dünn besiedeltes" – IPv6-Teilnetz ist also kaum aktiv durch Scans zu ergründen.
----------Anfang Textkasten----------
Das Internet der nächsten Generation wird auch der stark zunehmenden Nutzung mobiler Geräte besser gerecht werden als IPv4. Wichtig für eine unbegrenzte technische Mobilität ist es, an jedem Standort dieser Erde unter seiner "Heimatadresse" erreichbar zu sein. Um dies zu gewährleisten, arbeitet IPv6 ähnlich wie der heutige GSM-Mobilfunk: Ein im "Heimatnetz" mit einer bestimmten IPv6-Adresse bezeichneter Rechner erhält in fremden Netzen – beispielsweise via statusloser Autokonfiguration – eine Gastadresse, eine so genannte Care-of-Adresse.
So wie in der Handy-Welt ein Anruf unter der heimatlichen Rufnummer per Roaming weitergeleitet wird, übernimmt im IPv6-Netz der Heimat-Router die Weitervermittlung: Hierzu sendet das mobile System zuvor ein Paket mit einem so genannten Binding Update, in dem er seine temporäre Care-of-Adresse mitteilt. Der Heimat-Router leitet dann eingehende Pakete an die Care-of-Adresse weiter und übermittelt dabei in einem speziellen Optionsfeld die Originaladresse des Absenders. Die mobile Station hat dadurch die Möglichkeit, eine mögliche Antwort direkt zu schicken, ohne wiederholten Umweg über den Router.
----------Ende Textkasten----------
Bei der Entwicklung von IPv6 wurden Sicherheitsfunktionen auch auf IP-Ebene vorgesehen: IPSec [4], das mittlerweile auch auf IPv4 "zurückportiert" wurde, legt hier die Basis für Ende-zu-Ende-Authentifizierung und -Verschlüsselung auf Paket-Ebene. Die IPSec-Mechanismen sind in IPv4 und IPv6 dieselben und sollen hier daher nur kurz angerissen werden (Details siehe [5]).
Generell ist es weiterhin notwendig im Vorfeld kryptographische Schlüssel auszutauschen. Dies kann entweder manuell geschehen oder aber vom Internet Key Exchange (IKE) Protocol übernommen werden (RFC 2409). Beim manuellen Austausch der Schlüssel werden bei beiden Kommunikationspartnern die Schlüssel fest eingetragen. IKE nutzt hingegen entweder ein vorab ausgetauschtes Geheimnis (Pre Shared Keying, PSK) oder X.509-Zertifikate und erstellt auf dieser Grundlage via Diffie-Hellmann-Verfahren zunächst einen Session Key und anschließend eine so genannte Security Association (SA), welche die Grundlage für die IPSec-Verbindung darstellt.
Der Authentication Header (AH) ist, wie der Name bereits nahelegt, ein zusätzlicher Header für ein Datenpaket (Details siehe RFC 2402). Darin enthalten ist eine Checksumme, die über das gesamte (originale) Paket gebildet wird, ohne diejenigen Felder zu berücksichtigen, die üblicherweise auf dem Transportweg geändert werden (z. B. das Hop-Limit, das auf jedem Router um eins verringert wird). Diese Methode allein verhindert nicht das Mitlesen von Paketen, sondern nur ihre Manipulation auf dem Transportweg. Das Verfahren wäre zudem bei einem Endpunkt, der über NAT angebunden ist, unmöglich, da hierbei der Header (der in die Checksumme eingeht) verändert wird.
Bei einer IPSec-Verschlüsselung (Encapsulating Security Payload, ESP) im Transport-Modus werden die Nutzdaten eines IP-Pakets mit dem ausgehandelten Verfahren und Schlüssel chiffriert; optional kann eine Integritäts-Checksumme angehängt werden. Darüber hinaus unterstützt ESP noch den Tunnel Mode, der nicht nur die Daten, sondern das gesamte Paket verschlüsselt. Eine Kopie des originalen Headers wird für die Adressierung an die Spitze des so entstandenen Paketes angehängt (Details siehe RFC 2406).
Mit IPv6 ist eine IPSec-Implementierung obligatorisch, allerdings sind bis heute noch keine neuen Infrastruktur-Mechanismen abschließend definiert worden, die für eine deutliche Erleichterung der Schlüsselverteilung sorgen würden.
IPv6 wird zum einen das Problem mangelnder IP-Adressen beheben, versucht aber auch Lösungsansätze für andere Schwachpunkte des bisherigen Netz-Standards zu liefern – unter anderem für die Sicherheit. Obwohl die grundlegenden IPv6-Standards schon viele Jahre auf dem Buckel haben, ist auch in der "RFC-Szene" noch immer reichlich Bewegung, um Details zu korrigieren oder zu definieren – die IPv6 Working Group [6] hat derzeit 17 Internet Drafts in Bearbeitung. Zudem wird das Ende-zu-Ende-Paradigma von IPv6 an einigen Stellen zum Umdenken und Neubewerten von Datenschutz- und Sicherheits-Policies führen müssen, beispielsweise beim Einsatz von Gateway-Security.
Derzeit unterstützen vor allem amerikanische und asiatische Institutionen und Firmen die Entwicklung von IPv6, die EU zieht aber jetzt nach: Kürzlich hat sie Maßnahmen für den Übergang zum neuen Internet-Protokoll verabschiedet. Im Rahmen ihres Forschungsprogramms Information Society Technologies (IST) finanziert die EU zudem Forschungstätigkeiten rund um IPv6. Daran beteiligt sind sowohl Hochschulen und Forschungseinrichtungen, als auch kleine und mittlere Unternehmen sowie staatliche Stellen aus ganz Europa. Gesteuert werden die Aktivitäten von der European IPv6 Task Force ( www.eu.ipv6tf.org/in/i-index.php) und den entsprechenden nationalen Organisationen.
Als Anstoß wird zudem die vom US-Verteidigungsministerium erlassene Vorschrift für US-Behörden gewertet, bis zum Jahr 2008 nur noch IPv6-fähige Anwendungssoftware einzusetzen. Diese Entwicklung dürfte auch Auswirkungen auf Europa und Deutschland haben, da die NATO-Partner kaum vermeiden können, sich den Vorgaben der USA anzugleichen.
Insgesamt erwarten Insider einen langjährigen parallelen Betrieb der beiden Internetstandards und die sukzessive Ablösung von IPv4 im Laufe der nächsten 10 Jahre. Einen Stichtag zur Umstellung auf IPv6 wird es ohnehin nie geben: Der Standard ist von Anfang an so angelegt worden, das man ihn mit und über IPv4 parallel betreiben kann, um so IPv6 nach und nach in das vorhandene Internet einzuführen.
Dass IPv6 aber mittlerweile keine Randerscheinung von und für "Freaks" ist, sonder auch von den großen Providern ernst genommen wird, kann man deutlich daran erkennen, dass beispielsweise die Deutsche Telekom AG kürzlich vom RIPE das Präfix 2003:0000::/19 zugewiesen bekommen hat. Gemäß der RIPE-Vergaberichtlinien hätte sie diesen Adressbereich nicht erhalten, wenn nicht mindestens ein schlüssiges Grobkonzept vorgelegen hätte
Wer schon heute selbst einmal IPv6 ausprobieren möchte, findet eine ausführliche Darstellung mit Anleitung zum Einrichten von IPv6-Knoten und -Diensten beispielsweise im iX-Tutorial vom Frühjahr 2005 [7].
Frank Kölmel ist Sales Director Central und Eastern Europe bei Secure Computing. André Stolze ist wissenschaftlicher Mitarbeiter im Zentrum für Informationsverarbeitung der Westfälischen Wilhelms-Universität Münster.
www.isoc.org/internet/history/brief.shtml www.rfc-editor.org/rfc/rfc2460.txt www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-09.txt www.rfc-editor.org/rfc/rfc2401.txt www.ietf.org/html.charters/ipv6-charter.html
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2005#5, Seite 12
| 