
Glossar |
|
| BGP: | Border Gateway Protocol: Protokoll mit dem Router in IPv4 Netzen Pfade zu Netzwerkzielen austauschen. |
| CLIR: | Classless Internet Routing (IPv4): Bessere Aufteilung des Adressraumes, da Adressbereiche ohne die veraltete Klasseneinteilung vergeben werden. |
| DHCP: | Dynamic Host Configuration Protocol: Client/Server-Protokoll, welches Clients auf Anfrage IP-Adressen zuteilt. Neben einer IP-Adresse erhält ein Client zusätzliche Informationen, etwa die Adresse des Gateways (Routers) und die Adresse eines zuständigen Name-Servers (DNS). |
| DNS: | Domain Name System: Dezentraler Dienst, der Rechner-Namen (z. B. www.ordix.de) und IP-Adressen (z. B. 212.218.179.19) einander zuordnet. |
| IETF: | Internet Engineering Task Force: Institution, die Standards im Internet entwickelt und katalogisiert. |
| IPX: | Internet Packet Exchange: Protokoll, welches bei Novell Netware Verwendung findet. |
| MAC: | Media Access Control: Zugangsverfahren zum eigentlichen Medium (Kabel) eines Netzes, das auf der Netzwerkkarte implementiert ist. Dieses Verfahren verfügt über eine sogenannte MAC-Adresse (oder Hardware-Adresse), durch die eine Station eindeutig im Netz identifiziert ist. |
| NAT: | Network Address Translation (IPv4): Nutzung von privaten IP-Adressen hinter einem Gateway. |
| NSAP: | Network Service Access Point: Adresse, die in ATM-Netzen genutzt wird. Zu ATM, siehe [2] |
| OSPF: | Open Shortest Path First: Protokoll mit dem Router in IPv4 Netzen Pfade zu Netzwerkzielen austauschen. |
| QoS: | Quality of Service: Im IPv6 Protokoll eine zusätzliche Kennzeichnung von Datenpaketen, um unterschiedliche Anforderungen zu Erkennen (schnelle Antwortzeiten, kontinuierlicher Datenstrom, oder hohe Bandbreite). |
| RFC: | Request for Comments (Bitte um Kommentar): Schriftstücke, mittels derer die Internet Engineering Task Force (IETF) Spezifikationen, Vorschläge und Informationen veröffentlicht. |
Weiterführende Links
Verwandte Technologie-ThemenSeit 1992 gab es verschiedene Arbeitsgruppen im IETF, die drei bis vier verschiedene Ansätze zur Weiterentwicklung des bisherigen IP-Protokolls verfolgten. Insbesondere musste die Adressknappheit von IPv4 durch eine Neu- oder Weiterentwicklung des Protokolls behoben werden.
1994 wurde IPv6 im RFC 1752 erstmals dokumentiert und als "purposed standard" von IETF anerkannt. Seitdem wird es kontinuierlich vorangetrieben.
Ende der 90er Jahre war eine gewisse Panik bezüglich des knappen Adressraums zu spüren. IPv6 kam in aller Munde. In verschiedenen Fachzeitschriften fanden sich entsprechende Artikel.
IPv6 ist keine Weiterentwicklung von IPv4, sondern eine komplette Neuentwicklung. Neben der Netzwerkanbindung im Betriebssystem mussten alle Netzwerkdienste (z. B. DHCP, DNS), die darauf aufsetzenden Anwendungen und zu guter Letzt auch die Administratoren damit zurechtkommen. Zu dieser Zeit waren weder die Definitionen der Standards noch die Umsetzung dieser Standards schon so weit, um IPv4 abzulösen.
Mit anderen Lösungsansätzen wie CLIR und NAT konnte die Not der Adressknappheit zumindest im europäischen Raum gelindert werden, was dazu führte, dass es um IPv6 wieder ruhiger wurde.
Stand heute sind immer noch nicht alle Einzelheiten standardisiert. Trotzdem findet man in den meisten nennenswerten Betriebssystemen aktuelle Implementierungen. Die Roadmap der IPv6 Working Group des IETF schließt nach heutigem Stand Januar 2005 ab [1].
Das Adressfeld von IPv6 ist 128 Bit (16 Byte) lang und damit 4-mal so groß wie das IPv4-Adressfeld (siehe Abbildung 1). Pro Quadratmillimeter Erdoberfläche wären somit ca. 667x1015 (667 Peta) Adressen möglich.
|
||||||||||||||||||||||||||||||||||
| Abb. 1: Größe einer IPv6 Adresse im Vergleich zu IPv4. |
Die Adressen werden hexadezimal dargestellt, wobei Gruppen von 2 Bytes (bzw. 4 Oktets) durch Doppelpunkte getrennt werden. Führende Nullen können in jeder Gruppe weggelassen werden. Um die Schreibweise weiter zu vereinfachen, können an einer beliebigen Stelle in der Adressangabe Gruppen, die komplett 0 sind, weggelassen werden (siehe Abbildung 2). Folgen zwei Gruppen aufeinander, die komplett 0 sind und somit weggelassen werden können, so fällt auch der trennende Doppelpunkt weg.
fec0:0000:0000:9256:0a00:20ff:fe12:0028 fec0:0:0:9256:a00:20ff:fe12:28 fec0::9256:a00:20ff:fe12:28 |
| Abb. 2: Beispiel einer IPv6-Adresse. |
Ungefähr 15 % des IPv6 Adressraumes sind heute für konkrete Zwecke definiert. Organisationen, die einen neuen Adressbereich nutzen möchten, erhalten ihre konkrete Netzwerkadresse aus diesen 15 %. Die verbleibenden 85 % dienen zukünftigen Fragestellungen oder der Erweiterung des bestehenden Adressraumes. Die zuvor genannten 15 % umfassen auch Bereiche zur Abbildung von IPX- oder NSAP-Adressen.
Es sind Unicast- und Multicast-Adressbereiche definiert. Über Unicast-Adressen erreicht man genau ein Zielsystem beziehungsweise ein Interface des Zielsystems. Diese sind mit den bisherigen IPv4 Host-Adressen vergleichbar.
Mit Multicast-Adressen wird eine Gruppe von Zielsystemen erreicht. Bekannt sind solche Adressen in IPv4 z. B. für Newsserver. Die Aufgaben der Broadcast-Adressen, mit denen z. B. ein ganzes Netzwerk adressiert werden konnte, haben die feiner konfigurierbaren Multicast-Adressen mit übernommen. Broadcast-Adressen gibt es bei IPv6 nicht mehr.
Der Adressraum, der einer Organisation zur Verfügung gestellt wird, ist immer gleich aufgebaut. Die ersten 48 Bit definieren das Netz der Organisation und sind fest vom Provider vorgegeben. Die folgenden 16 Bit ermöglichen es der Organisation, circa 65 Tausend Subnetze einzurichten.
Die hinteren 64 Bit sind als Interface-ID vorgesehen, womit in jedem Subnetz 18x1018 (18 Exa) Interface-Adressen verwendbar sind. Eine komplette IPv4-Adresse könnte somit als Teil einer Interface-ID eingebettet sein (siehe Abbildung 3).
|
||||||||||||||||||||||||
| Abb. 3: Aufbau einer IPv6 Adresse. | ||||||||||||||||||||||||
Dieser fest definierte Aufbau verursacht hohen Verschnitt an IP-Adressen, der aber in Anbetracht der Größe des Adressraumes zu verkraften ist. Durch den immer gleichen Aufbau der Adressen wird Routing effizienter, da das Auswerten von Netzmasken entfällt.
Während IPv4 prinzipiell von statischen IP-Adressen ausgegangen ist, dynamische Zuordnung nur durch Zusatzprotokolle erreicht wurde und doppelte IP-Adressen in der Verantwortung des Administrators lagen, sind diese Fragestellungen von IPv6 direkt adressiert. Dies bringt einige neue Verfahren mit sich, die im Folgenden kurz vorgestellt werden:
Obwohl die automatischen Verfahren zur Konfiguration von IPv6-Adressen eindeutige Adressen hervorrufen und auch statisch (von Hand) konfigurierte Adressen eindeutig sein sollten, hat IPv6 das Duplicate Address Detection-Verfahren (DAD) definiert. Dieses Verfahren prüft über Mulitcast-Adressen vor der Konfiguration einer IP-Adresse, ob schon ein anderes System diese Adresse verwendet.
Die Interface-ID wird bei dynamischer Konfiguration aus der MAC-Adresse abgeleitet. Im ersten Byte wird eine 2 addiert und zwischen Byte 3 und 4 wird FFFE eingefügt (siehe Abbildung 4).
MAC-Adresse 00:04:e2:09:da:ad Interface-ID 0204:e2ff:fe09:daad |
| Abb. 4: Wandlung von MAC-Adresse zu Interface-ID. |
Unter IPv4 wurde ARP verwendet, um zu einer bekannten, im gleichen Teilnetz befindlichen IP-Adresse die zugehörige MAC-Adresse zu ermitteln. Bei IPv6 wird stattdessen Neighbor Detection verwendet. Dieses Protokoll arbeitet wiederum mit Hilfe von Multicasts, ähnlich dem DAD. Hinweis: Neighbor Detection finden Sie natürlich auch unter der brit. Schreibweise "Neighbour Detection" :-)
Generell ist es denkbar, auch IPv6 Adressen statisch, das heißt von Hand, zu konfigurieren. Dies funktioniert ähnlich wie bei IPv4 Adressen. In der Praxis zeigt sich aber, dass das DAD-Verfahren bei statisch konfigurierten Adressen häufig nicht aktiviert ist, obwohl es laut RFCs auch dort arbeiten sollte. Es ist somit ratsam, statische Adressen sparsam beziehungsweise nur zusätzlich zu den automatisch generierten Adressen zu verwenden.
Auch für jedes einzelne Interface wird vergleichsweise großzügig mit IPv6 Adressen verfahren. Alle gefundenen und einmal konfigurierten Adressen bleiben dem Interface erhalten.
Zuerst ermittelt jedes Interface eine eigene Link Local Adresse. Diese ist nur innerhalb des Broadcast-Mediums nutzbar und wird nicht geroutet.
Mit dem Router Discovery Protokoll wird mittels Multicast-Adressen nach Routern gefragt, welche ihre eigene Adresse und die verwendeten Adresspräfixe propagieren. Aus dieser Information können Nodes zusammen mit der eigenen MAC-Adresse eine eindeutige IPv6-Adresse konfigurieren. Auch die so ermittelte Adresse wird mit dem DAD vorher auf Eindeutigkeit geprüft.
Weiterhin kann ein IPv6-fähiger DHCP-Server (DHCPv6 genannt) für die Adresskonfiguration nach dem in IPv4 bekannten Modell eingesetzt werden. Ein Vorteil von DHCPv6 ist, dass über DHCP zusätzliche Informationen, wie z. B. die Adresse des Nameservers, propagiert werden können.
Da die Stateless Konfiguration zum integralen Bestandteil von IPv6 gehört, sollte darauf nicht verzichtet werden. DHCPv6 ist somit als Ergänzung zu sehen.
Das neue Adressformat ist zwar die auffälligste Änderung im IPv6-Header. Tatsächlich ist aber der gesamte Aufbau des Headers neu. Der IPv4-Header betrug inklusive Adressen und diversen Optionen 24 Byte. Bei IPv6 werden für Ziel- und Quell-Adresse 32 Byte benötigt. Vor den beiden Adressfeldern befinden sich noch 64 Bit (4 Byte) in denen die IP-Version, die Länge des Datenpaketes und einige andere Informationen kodiert werden. Die Länge des IPv6-Headers ist mit 36 Byte somit nicht wesentlich größer als bei IPv4. Der IPv6 Overhead hält sich demzufolge in Grenzen.
Hinter dem IPv6-Header können sogenannte Erweiterungs-Header angehängt werden. Diese Header unterliegen keiner gemeinsamen Form. Es wird somit eine hohe Flexibilität bezüglich der Transporteigenschaften von IPv6 erreicht.
Router können meist ohne die Informationen in den Erweiterungs-Headern arbeiten. Sie beschränken sich somit auf die Auswertung des relevanten IPv6-Headers. Dies wirkt sich wiederum positiv auf die Performance aus.
Zwei Erweiterungsheader bedürfen der besonderen Aufmerksamkeit. Mit dem Authentication Header (AH) wird die Herkunft und die Integrität des Paketes sichergestellt.
Hinzu kommt der Encapsulation Security Payload (ESP). Dieser bietet Verschlüsselung und stellt wiederum die Integrität der Daten sicher. Beide Header zusammen sind Bestandteil des "Internet Protocol Security" (IPsec). Das IPsec findet meist zum Aufbau Virtueller Privater Netze Verwendung und hat durch Zusatzsoftware auch unter IPv4 Einzug gehalten.
DNS ist schon bei IPv4 einer der grundlegenden Dienste. Ohne ihn würde fast keine namensbasierte IP-Kommunikation reibungslos funktionieren. Nicht nur aufgrund der Länge der IP-Adressen ist auch unter IPv6 dieser Dienst einer der wichtigsten Basisdienste.
Unterschiedliche Zielrichtungen bei der Entwicklung der neuen DNS-Einträge haben unterschiedliche Formate hervorgerufen. Von der Implementierung der Clientsoftware hängt es ab, welches Format angefragt (und somit auf dem Server benötigt) wird.
Um eine größtmögliche Funktionsfähigkeit sicherzustellen, sollten alle Formate eingetragen werden.
Abbildung 5 zeigt die notwendigen Eintragungen für einen Rechner.
FORWARD Einträge in Zone "ordix.de": jupiter.ordix.de. AAAA fec0::1 jupiter.ordix.de. A6 0 fec0::1 REVERSE Eintrag in Zone "0.c.e.f.ip6.arpa" (nibble –Format): ; 1 0 9:8 7 6 5:4 3 2 1:0 9 8 7:6 5 4 3:2 1 0 9:8 7 6 5 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR jupiter.ordix.de. REVERSE Eintrag in Zone "0.c.e.f.ip6.int" (nibble –Format): 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR jupiter.ordix.de. REVERSE Eintrag in Zone "\[xfec0/16].ip6.arpa" (Bitstring –Format): ; 5678901234567890123456789012 \[x0000000000000000000000000001/112] PTR jupiter.ordix.de. |
| Abb. 5: Beispiel der notwendigen DNS-Einträge eines Rechners(vergrößern!). |
Nach dem OSI 7-Schichten Modell liegt die Vermutung nahe, dass Dienste in den höheren Schichten unabhängig vom darunterliegenden Protokoll funktionieren. Doch viele Serverdienste machen z. B. eine Ident-Abfrage an die Client-IP-Adresse oder tragen die Client-IP-Adresse in die Logdateien ein.
In beiden Fällen müssen IPv6 Adressen extra vorgesehen werden. Z. B. prüft Sendmail die Reverse-DNS-Einträge und muss somit von den neuen Adressen und den neuen Records Kenntnis haben.
scp nutzt den ":" als Trennzeichen zwischen Rechner und Verzeichnis. IPv6-Adressen müssen bei scp somit in eckigen Klammern angegeben werden, was wiederum vor der Interpretation durch die Shell geschützt werden muss.
Solaris 9 ist prinzipiell IPv6-fähig, doch der mitgelieferte DNS-Server in der Version Bind 8.3.3 kann keine IPv6-Anfragen beantworten.
Befehle zur Administration oder Diagnose von IPv6 unterscheiden sich von den für IPv4 gewohnten. Unangenehm ist für den Administrator, dass diese Unterschiede auf jeder Plattform anders geartet sind, wie Abbildung 6 beispielhaft zeigt. Die Beispiele zeigen, dass faktisch jeder einzelne Dienst und jede einzelne Anwendung auf IPv6-Fähigkeit geprüft werden muss.
Abb. 6: Unterschiedliche Kommandos für IPv4 und IPv6 auf den gebräuchlichsten Systemen. |
Sonstige EigenschaftenDas Routing unter IPv6 ist dem Routing von IPv4 ähnlich. Durch das Router Discovery Protokoll, welches integraler Bestandteil des IPv6-Stack ist, ist es möglich, ohne Zusatzaufwand (z. B. ohne OSPF oder BGP) Netzwerktopologien mit redundanten Netzwerkpfaden aufzubauen. Durch die Angabe von QoS-Eigenschaften können Pakete priorisiert werden. Kontinuierlicher Datenstrom neben kurzen Antwortzeiten wird dadurch ermöglicht. Pakete, die über den gleichen IP-Header verfügen, können zu sogenannten "Flows" zusammengefasst werden. Router werten die Optionen eines Flows nur einmal aus und behandeln nachfolgende IP-Pakete desselben Flows entsprechend. Weiterhin verspricht IPv6 Roomingfähigkeiten. Dies ermöglicht Systemen durch unterschiedliche (Funk-)Netze (mit unterschiedlichen Netzwerk-Adressen) zu wandern, ohne die bestehende Datenkommunikation zu unterbrechen. Die eigene IPv6-Adresse wird durch die unterschiedlichen Providernetze getunnelt. AusblickEs hat sich gezeigt, dass Ipv6 eine komplette Neuentwicklung mit neuer Technik und neuen Konzepten ist. IPv6 bietet die Voraussetzung für zukünftige Anwendungen und löst drängende Probleme. Andererseits sind bisher nicht alle Fragestellungen zufriedenstellend beantwortet. Ein Umstieg auf IPv6 kann und sollte noch etwas hinausgezögert werden. Um diesen aber zukünftig zu erleichtern, sollte bei Neuanschaffungen die IPv6-Fähigkeit gewährleistet sein. Markus Schreier (info@ordix.de). |