IPv6
IPv6, das Internet Protocol Version 6, ist der Nachfolger des gegenwärtig im Internet noch fast ausschließlich verwendeten Internet Protocol v4.
Anwendung | FTP | SMTP | HTTP | DNS | ... |
Transport | TCP | UDP | |||
Netzwerk | IPv6 | ||||
Netzzugang | Ethernet | Token Bus |
Token Ring |
FDDI | ... |
Warum ein neues Internet-Protokoll?
Das alte IPv4 bietet einen Adressraum von etwas über 4 Milliarden IP-Adressen, mit denen Computer (oder andere Geräte) angesprochen werden können. In den Anfangstagen des Internet, als es nur wenige Rechner gab, die eine IP-Adresse brauchten, galt dies als mehr als ausreichend. Kaum jemand konnte sich vorstellen, dass überhaupt jemals so viele Rechner zu einem einzigen Netzwerk zusammengeschlossen würden, dass es im vorgegebenen Adressraum eng werden könnte.
Viele der theoretisch 4 Milliarden IP-Adressen sind in der Praxis nicht nutzbar, da sie Sonderaufgaben dienen (zum Beispiel Multicast) oder zu großen Subnetzen gehören: Den ersten großen Teilnehmern am Internet wurden riesige Adressbereiche (sog. Class-A-Netze) mit je 16,8 Millionen Adressen zugeteilt, die diese Organisationen bis heute behalten haben, ohne sie jemals voll ausnutzen zu können. Die Amerikaner (und teilweise die Europäer) teilten die relativ wenigen großen Adressbereiche unter sich auf, während die Internet-Späteinsteiger wie Südamerika, aber vor allem Asien, zunächst außen vor blieben.
Als Resultat herrscht besonders im zukünftigen IT-Wachstumsmarkt Asien heute eine latente Adressenknappheit, der man mit Notbehelfen wie NAT (Network Address Translation) oder dynamischer Vergabe von Adressen begegnen muss.
Auf Grund des Wachstums und der Wichtigkeit des Internet konnte dies kein Dauerzustand bleiben. Zusätzlich ist abzusehen, dass in den nächsten Jahren durch neue technische Innovationen (beispielsweise Mobiltelefone mit Internet-Anschluss, bald wohl auch Fernseher, Mikrowellen, Kühlschränke und Autos) der Bedarf an Adressen auch im Rest der Welt ansteigen wird.
Hauptsächlich wegen der Adressknappheit, aber auch, um einige der Probleme zu lösen, die sich im Zuge der großräumigen Verwendung von IPv4 gezeigt hatten, begann man 1995 mit den Arbeiten am neuen IPv6 (die ersten RFCs waren 1983ff.). Folgende Liste soll einen kurzen Überblick über die wesentlichen neuen Features von IPv6 geben, einige Punkte werden weiter unten näher erklärt:
- Vergrößerung des Adressraums von 232 bei IPv4 auf 2128 bei IPv6
- Autokonfiguration (ähnlich DHCP), Mobile IP und automatisches Renumbering
- Services wie IPSec, QoS und Multicast serienmäßig
- Vereinfachung und Verbesserung der Header (wichtig für Router)
Adressaufbau von IPv6
Eine IPv6-Adresse ist 128 Bit lang (IPv4: 32 Bit). Damit gibt es etwa 3,4 x 1038 IPv6-Adressen - für jeden Quadratmeter Erdoberfläche könnten 6,5 x 1023 Adressen bereitgestellt werden.
IPv6-Adressen werden nicht mehr dezimal (zum Beispiel 80.130.234.185), sondern hexadezimal mit Doppelpunkten geschrieben: 243f:6a88:85a3:08d3:1319:8a2e:0370:7344. Wenn eine 16-Bit-Gruppe den Wert 0000 hat, kann sie durch einen Doppelpunkt ersetzt werden. Wenn dann mehr als zwei Doppelpunkte aufeinander folgen würden, können diese auf zwei Doppelpunkte reduziert werden, solange es in der resultierenden Adresse nur einmal zwei aufeinander folgende Doppelpunkte gibt. 0588:2353::1428:57ab ist also das selbe wie 0588:2353:0000:0000:0000:0000:1428:57ab, aber 3906::25de::cade wäre nicht erlaubt, da zweimal zwei Doppelpunkte in der Zeichenkette vorkommen - ein Computer wüsste nicht, wo mit wie vielen Nullen aufzufüllen wäre.
Die ersten 64 Bit der IPv6-Adresse dienen standardmäßig der Netzadressierung, die letzten 64 Bit können zur Host-Adressierung verwendet werden - hiermit wird elegant das Konzept der Netzmasken von IPv4 implementiert. Bei Bedarf können auch andere Netzmasken eingesetzt werden.
Die korrekte Form einer IPv6-Adresse in einer URL ist http://[243f:6a88:85a3:08d3:1319:8a2e:0370:7344]/ .
Arten von IPv6-Adressen
Es gibt verschiedene IPv6-Adressen mit Sonderaufgaben und unterschiedlichen Eigenschaften. Diese werden durch die ersten Bits der Adresse (das "Präfix") signalisiert:
- Das Präfix 00 steht für IPv4 und IPv4-über-IPv6-Kompatibilitätsadressen. Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren und so die neue mit der alten Welt verbinden. Zwei weitere Adressen tragen ebenfalls dieses Präfix; ::0 ist die undefinierte Adresse, ähnlich der 0.0.0.0 in IPv4, und ::1 ist die Adresse des Loopback Devices "localhost".
- Die Präfixe 2 oder 3 stehen für Globale Unicast-Adressen, also eine routbare und weltweit einzigartige Adresse.
- fe80 bis febf sind so genannte Link-local-Adressen, die nicht geroutet werden dürfen und daher nur im gleichen Subnetz erreichbar sind. Interessant werden sie bei der Autokonfiguration.
- Adressen mit Präfixen fec0 bis feff sind die Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x). Sie dürfen nur innerhalb der gleichen Organisation geroutet werden. Man nennt sie daher Site-local (diese Adressen sind inzwischen "deprecated" und werden aus zukünftigen Standards möglicherweise verschwinden).
- Das Präfix ff steht für Multicast-Adressen. Dem Präfix folgt eine Angabe über den Gültigkeitsbereich des Pakets:
- ffx1: Node-lokal, diese Pakete verlassen den Knoten nie.
- ffx2: Link-lokal, werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Subnetz nicht verlassen.
- ffx5: Site-lokal, dürfen zwar geroutet werden, jedoch nicht von Border-Routern.
- ffx8: Organisations-lokal, die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch "in der Firma" (hierzu müssen seitens des Routing-Protokolls entsprechende Vorkehrungen getroffen werden).
- ffxe: Globaler Multicast, der nach überall hin geroutet werden darf.
Autokonfiguration
Ein IPv6-fähiges Interface kann aus seiner Layer 2-MAC-Adresse eine sog. Link-lokale Adresse errechnen, mit der es sich auf die Suche nach den Routern in seinem Netzwerksegment machen kann. Der Router kann dem Gerät dann eine "Unicast"-Adresse aus seinem Adressbereich zuweisen, mit der das Gerät aufs Internet zugreifen kann. Der ganze Vorgang läuft ohne Benutzerintervention vollautomatisch ab und ist eine Verbesserung des IPv4-DHCP (er kommt ohne Server aus). Ein IPv6-fähiges Gerät ist so "out-of-the-box" startklar, was besonders für unerfahrene Endnutzer oder stressgeplagte Administratoren ein großer Vorteil ist.
Renumbering
Sobald man bei IPv4 erstmal genug Rechner zu einem Subnetz zusammengeschlossen hat, bekommt man Probleme, wenn sich an den Adressparametern dieses Netzes etwas ändert (zum Beispiel ein Providerwechsel). Jeder Rechner muss dann nämlich per Hand umkonfiguriert werden - wenn das Netz groß genug ist, kann sich dies als praktisch undurchführbar darstellen. In diesem Fall hat man bei IPv4 häufig den Adressraum fragmentiert, d.h. ein Teil der IP-Adressen eines Subnetzes wurde anders geroutet als der Rest. Für die Router brachte dies eine vergrößerte Routing-Tabelle, da sie sich die Ausnahmen merken und beachten müssen, und damit Performance-Verlust. Bei IPv6 gibt es diese Probleme nicht, da man ja den Autokonfigurationsmechanismus hat. Der neue Adressbereich muss nur einmal neu am Router eingestellt werden, und schon haben alle Clients ihre neuen Adressen.
Mobile IP
Bei Mobile IP geht es darum, mit der gleichen IP-Adresse überall erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz. Normalerweise müssten dazu Routing-Tabellen geändert werden (noch dazu für jede mobile IP-Adresse einzeln!). IPv6 regelt dies unter Zuhilfenahme eines Agenten-Rechners am Hauptstandort des Mobilgeräts und ICMPv6-Redirects. Eingehende Verbindungen werden durch den Agenten an den momentanen Standort des Mobilgeräts umgeleitet.
Effizienzsteigerungen und neues Header-Format
Im Gegensatz zu IPv4 hat der IP-Header bei v6 eine feste Länge. Außerdem gibt es keine Paketfragmentierung mehr und es werden keine Checksummen über das IP-Paket berechnet, man nutzt nur noch die Fehlerkorrektur in den Layern 2 und 4. Die meisten Felder im Header sind auf 64-Bit-Grenzen ausgerichtet, so dass der Speicherzugriff im Router nicht unnötig ausgebremst wird. Die Flags liegen jetzt in Zwischenheadern zwischen dem IP-Header und dem Layer-4-Header (TCP/UDP). Dadurch können sich Hochleistungsrouter auf ihre eigentlichen Kernaufgaben konzentrieren und müssen nicht mehr die Fehler anderer Schichten ausbügeln.
Der frühere Broadcast wird nun konsequent über Multicast implementiert: ARP wurde beispielsweise durch das neue Verfahren "Neighbor Solicitation" ersetzt: Jeder Host muss sich bei einer aus seiner IP gebildeten Multicastgruppe anmelden, an die der anfragende Host seine Neighbor-Solicitation-Anfrage schickt und so die MAC-Adresse des anderen Hosts herausfinden kann. Als Nebeneffekt werden diese Anfragen nicht mehr im ganzen LAN verteilt, sondern gehen in geswitchten Umgebungen idealerweise nur noch über den direkten Weg zum eigentlichen Ziel.
Probleme
Gerade zu Anfang litt IPv6 unter einigen Kinderkrankheiten, die dem neuen Protokoll den Ruf einer "Totgeburt" einbrachten. Die Standards wurden häufig geändert, was einigen Unmut erzeugte, da man die gerade fertig gewordenen Implementationen schon wieder wegwerfen konnte. Der größte Einschnitt bestand in der Einführung der IEEE-Norm EUI-64 für die Link-local-Adressen. Vorher übernahm man die MAC-Adresse des Adapters einfach in die IPv6-Adresse, nun wurde die MAC-Adresse gemäß EUI-64 in veränderter Form in die IPv6-Adresse übernommen. Das änderte jedoch nichts an dem Problem, dass aus der gleichen MAC-Adresse auch immer die gleiche IPv6-Adresse resultiert. Dynamische IP-Vergabe wie bei IPv4 sollte es ja bei IPv6 nicht mehr geben. Datenschützer waren besorgt, dass auf diese Weise der Datenverkehr einer IP auf Routern mitgeschnitten werden könnte und beispielsweise für Marketing-Maßnahmen oder staatliche Interventionen aller Art verwendet werden könnte. Die IETF definierte deshalb nachträglich die Privacy Extensions gemäß RFC 3041: Die MAC-Adresse wird dabei zunächst mit einer pseudo-zufälligen Zahl verwürfelt, und aus dem Ergebnis dann die Link-lokale Adresse des Gerätes ermittelt.
In der Praxis ergab sich mit den Link-local-Adressen das Problem, dass es nicht mehr reicht, die IP-Adresse im Destination-Feld einzutragen, sondern auch eine Scope-ID angegeben werden muss, da die Link-local-Adressen relativ zum Link sind und alleine noch keinen Endpunkt definieren.
Deshalb sind die Link-local-Adressen nur beschränkt zur Kommunikation tauglich (abhängig davon, ob die IPv6-Unterstützung der verwendeten Anwendung das Konzept der Scope-ID kennt).
IPv6 und DNS
Auf Grund der Länge der IP-Nummern, die man sich nur in den seltensten Fällen merken können wird, ist IPv6 in besonderem Maße von einer funktionierenden Nameserver-Infrastruktur abhängig. Gerade dieser wichtige Bereich ist jedoch bis heute eine Baustelle. Es ergaben sich im wesentlichen folgende Probleme:
- IPv6-Autokonfiguration sucht normalerweise nicht nach Nameservern
- Privacy Extensions und DNS sind wegen der sich häufig ändernden Adressen schlecht unter einen Hut zu bekommen
- Chaos bei den DNS-Record-Typen für IPv6
Bei der Autokonfiguration erhält ein IPv6-Gerät vollautomatisch eine Adresse und ein Gateway, über das es ins Internet kommunizieren kann. Leider fehlt jedoch die Möglichkeit, auch automatisch einen DNS-Server zu suchen, was die Autokonfiguration fast wieder wertlos macht. Dies ist einer der Gründe, warum DHCPv6 entwickelt wurde, das eigentlich durch IPv6 überflüssig gemacht werden sollte. Wer ohne DHCP einen Nameserver finden will, muss auf Bastellösungen zurückgreifen, die meist ganz ähnlich wie die Router-Suche funktionieren. Statt einer Anfrage an die Multicast-Gruppe alle Router wird dabei eine Anfrage an alle Nameserver abgesetzt. Falls es mehrere DNS-Server im lokalen Netz gibt, sucht sich der Client dann den Server seiner Wahl aus den eintreffenden Antworten heraus.
Die Verwendung von Privacy Extensions ist insofern eine Herausforderung an das DNS, als sich IP-Adressen dabei häufig und unvermittelt ändern. Wenn ein Client auf Erreichbarkeit unter einem DNS-Namen angewiesen ist, benötigt er ein zuverlässiges und sicheres Verfahren, um dem DNS-Server eine Adressänderung mitteilen zu können. Auf diesem Gebiet ist bis heute noch viel Bewegung zu verzeichnen und es hat sich noch kein verwendbarer Standard herauskristallisiert.
Lange Zeit bestand auch auf der grundlegendsten Ebene des DNS, den Records auf den Nameservern, Verwirrung. 1995 wurden in RFC 1886 zunächst der Record-Typ AAAA für die Forward-Auflösung von DNS-Namen in IPv6-Adressen definiert, der funktional äquivalent zum A-Record für IPv4 ist. Im Jahr 2000 wurde AAAA in RFC 2874 durch den Record-Typ A6 abgelöst, der vor allem das Renumbering vereinfachen sollte, indem die IP-Adresse stückweise auf das DNS gemappt wurde, jedoch nie frei von technischen Problemen war. Im Jahr 2003 wurde das Verfahren A6 daher in RFC 3596 wieder nach "experimentell" zurückgestuft, und AAAA wurde der neue, alte Standard. Noch mehr Schwierigkeiten bereitet die Reverse-Auflösung von IPv6-Adressen, da es durch das Hin- und her bei den Standards PTR-Records in zwei verschiedenen Formaten gibt, die noch dazu in drei verschiedenen Zonen liegen.
Die Praxis: Das IPv6-Deployment
IPv6 setzt sich im praktischen Einsatz nur langsam durch. Mit der Betriebssystemunterstützung sieht es im Moment folgendermaßen aus:
- Windows XP: Auf expliziten Wunsch (ipv6 install) kann man bei Windows XP einen experimentellen IPv6-Stack installieren. Ab ServicePack 1 hat dieser Stack "Production Quality", und wird als Protokoll in den Netzwerkeigenschaften hinzugefügt.
- Windows 2000: Microsoft bietet einen experimentellen Stack als Patch an.
- Windows Server 2003: Enthält einen "Production Quality" Stack und unterstützt IPv6-DNS (AAAA) Einträge und IPv6-Routing.
- Windows 9x/ME: Lediglich eine kommerziell verfügbare Unterstützung der Firma Trumpet (Winsock).
- xBSD: Die derzeit noch beste und vollständigste Unterstützung für IPv6 - vor allem ein Verdienst des japanischen KAME-Projektes.
- Linux: Der Kernel 2.4 bietet eine als "experimental" markierte Unterstützung für IPv6, der jedoch noch wichtige Features wie IPSec und Privacy Extensions (RFC 3041) fehlen. Der neue Kernel 2.6.x bietet eine umfassende IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate.
- Mac OS X: Enthält seit Version 10.2 Unterstützung für IPv6 auf der Basis von KAME. Erst seit Version 10.3 lässt sich IPv6 auch über das GUI konfigurieren.
- Cisco: Cisco ist der Marktführer bei Internetroutern. Beim Deployment von IPv6 gehörte Cisco aber eher zu den Schlusslichtern. Es gibt zwar mittlerweile IPv6-fähige IOS-Versionen, diese werden aber nicht standardmässig installiert, da sie noch als experimentell eingestuft werden.
Viele Anwendungen (vor allem aus dem Bereich der Freien Software) sind inzwischen ebenfalls IPv6-fähig. Im heimatlichen LAN kann man so schon relativ problemfrei IPv6 benutzen. Jenseits des eigenen Border-Routers sieht es derzeit noch düster aus: Es gibt keine Provider, die native IPv6-Anbindung verkaufen, so dass man im Moment auf bisweilen unbefriedigende Bastel-Lösungen mit Tunneling zurückgreifen muss. Es existieren eine Reihe von Tunnelprotokollen für jeweils unterschiedliche Anwendungsbereiche, darunter die Protokolle 6in4, 6over4, 6to4, Teredo und das NAT-taugliche AYIYA.
Zumindest in Europa und Amerika besteht einfach auch keine Notwendigkeit zur Migration zu IPv6, da noch genügend freie IPv4-Adressen vorhanden sind (in Europa über 50%). In Asien geht der Trend inzwischen dahin, bei Neubauten (zum Beispiel dem NTT-Backbone) IPv6 auch zu benutzen. Von seiten der Endbenutzer wird IPv6 auch deshalb nicht gefordert, weil außer dem größeren Adressbereich die wesentlichen neuen Features von IPv6 inzwischen mehr oder weniger erfolgreich nach IPv4 rückportiert wurden (beispielsweise IPSec, QoS, Multicast. Das Renumbering und die Autokonfiguration kann man durch DHCP angenähert erreichen) - es gibt keine "Killer-Applikation", die nur mit IPv6 funktionieren würde.
In Deutschland federführend bei den Versuchen zu IPv6 ist das JOIN-Projekt der Uni Münster. Im Moment ist seitens des JOIN und des DFN ein erstes IPv6-Backbone in Deutschland im Aufbau. Die Planungen für das "6Win" sehen einen ringförmigen Backbone durch Deutschland mit Querverbindung zwischen Essen und Berlin vor. Parallel dazu baut die Deutsche Telekom einen eigenen IPv6-Backbone zwischen den Standorten Darmstadt, Münster und Berlin auf und bietet ihren Geschäftskunden im Rahmen eines Showcase-Projektes Anschluss daran an. Dieses Netz soll in Münster und Berlin mit dem 6Win verbunden werden. Ebenfalls in Münster liegt der deutsche zentrale Zugang zum experimentellen IPv6-Netzwerk 6Bone.
Weiterführende Informationen
Was ist mit IPv5?
Wenn es IPv4 und IPv6 gibt, was ist dann mit IPv5? gehört mit zu den häufigsten Fragen, die sich IPv6-Neueinsteiger stellen. Ein Protokoll mit dem Namen IPv5 gibt es nicht, allerdings hat die IANA die IP-Versionsnummer 5 für das Internet Stream Protocol Version 2 (ST2, definiert in RFC 1819) reserviert, das gegenüber IPv4 verbesserte Echtzeitfähigkeiten haben sollte, dessen Entwicklung dann aber zu Gunsten von IPv6 und RSVP eingestellt wurde.
Siehe auch
Weblinks
- http://www.iana.org/assignments/ipv6-address-space - der derzeit allozierte IPv6-Adressbereich im Überblick
- http://www.ipv6-net.org/ - Allgemeine Informationen zum Thema IPv6
- http://www.bieringer.de/linux/IPv6/ - Peter Bieringers Homepage mit einer HOWTO für IPv6 unter Linux
- http://6bone.net/ - Homepage des experimentellen IPv6-Netzwerks 6Bone
- http://www.join.uni-muenster.de/ - Homepage des JOIN-Projektes der Uni Münster
- http://www.ripe.net/ripencc/mem-services/general/allocs6.html - Liste der europäischen Provider, die IPv6 verfügbar oder in Planung haben
- http://www.sixxs.net/ - Bietet mit einigen anderen Providern IPv6-Tunnel an
- http://www.tunnelbroker.net/ - Bietet IPv6 Tunnel an (sogar einen /64 Präfix)