bdL KG | Adlershofer Str. 6 | D-12557 Berlin info [at] b-dL.com +49 30 740 767 16

IP Version 6

Einführung

IPv6Ursprünglich, in der IP Version 4, war einmal Platz für über 4 Milliarden IP-Adressen. Das ist viel, wenn man die Anzahl der Menschen bedenkt, die damals, in den 70er-Jahren des vorigen Jahrhunderts, die Erde bevölkerten. Man hätte zumindest in den Industriestaaten jedem Einwohner seine ganz persönliche IP-Adresse zuweisen können und immer noch Reserven für staatliche und universitäre Einrichtungen gehabt.

Adresszuweisung und Identifizierung

IP-Adressen werden aber nicht nach der Anzahl der Köpfe, die die Erde bevölkern und z. B. Computerzugang haben, benötigt, sondern nach der Anzahl der Maschinen, die eine eindeutige Adresse brauchen, um angesprochen oder gesteuert werden zu können. Mittels IP-Adresse lässt sich eine Maschine eindeutig identifizieren, sei es als Absender oder als Empfänger von Daten. Bei der geringen Anfangspopulation von Maschinen, die in den 70er-Jahren eine eindeutige IP-Kennung benötigten, erschien ein Adressraum mit über 4 Milliarden Adressen mehr als ausreichend, um auf lange Zeit für alle Eventualitäten gewappnet zu sein. Frühe IP-Benutzer wie Berkeley oder Digital bekamen damals mal eben 16 Millionen IP-Adressen zugewiesen. Das Ende der freien Adressen wird aufgrund des rasanten technologischen Fortschritts dennoch schneller erreicht als absehbar war (auch wenn wir im Augenblick davon noch relativ weit entfernt sind). Denn wenn auch Autoradios, Kühlschränke und Videorecorder Internet-Zugang haben sollen, dann ist die Reserve schnell verbraucht. Mit einigen Zahlen lässt sich die Falle, der die weitblickende Planung von IPv4 zum Opfer fiel, verdeutlichen: Über einen Zeitraum von nur 20 Jahren stieg die Anzahl der Rechner im Internet von 213 Rechnern im Jahre 1981 auf über 400 Millionen Rechner im Jahr 2001 an.

Das starke Wachstum setzte 1990 durch die schnelle Verbreitung des World Wide Web und einen gleichzeitigen Preisverfall der IT-Komponenten ein. Eigentlich müsste der 32 Bit große Adressraum zur weltweiten Adressierung ausreichen. Immerhin können mit 32 Bit über 4 Milliarden verschiedene Adressen gebildet werden. Allerdings wurde der IPv4-Adressraum durch die ursprüngliche Einteilung in Adressklassen mit festen Bitgrenzen sehr ineffizient ausgenutzt. Zu Beginn der Vergabe von Adressen ging man recht großzügig vor, sodass große Teile des Adressraums ungenutzt bleiben. Die Internet Engineering Task Force geht davon aus, dass bei einem gleichbleibenden Wachstum die Adressen bis zum Jahr 2010 reichen werden. Ein weiterer Nachteil, der sich aus der Adressierung ergibt, ist das flache Adressierungsschema. Durch die zweistufige Einteilung in Klassen wird bei den Adressen nur zwischen Netzbereich (Net_ID) und Rechnerbereich (Host_ID) unterschieden. Ein Router im Backbone muss im Prinzip jedes einzelne Netz kennen, um die Pakete zustellen zu können. Dies führt zu riesigen Routing-Tabellen, die an der Grenze des technisch Realisierbaren angekommen sind. Erschwerend kommen die manuellen Administrationsaufgaben hinzu. Um einen IP-Knoten an einem Netz betreiben zu können, müssen einige Parameter und Adressen konfiguriert werden. Die gebräuchlichste Methode für die Konfiguration ist das manuelle Eingeben aller Parameter und Adressen. Eine manuelle Konfiguration aller einzelnen Rechner in einem Netz ist aufwendig, teuer und fehlerträchtig.

Stiefmütterlich behandelte Sicherheit

Die Sicherheitsfragen wurden bei IPv4 nur unzureichend behandelt. Es wurden keine Mechanismen im Protokoll implementiert, die eine Verschlüsselung oder Echtheitsüberprüfung der Daten ermöglichen. Das Internet wurde für den Transport von reinen Datenpaketen entwickelt. Eine steigende Kommerzialisierung des Internets erfordert aber ein sicheres Protokoll. Im Laufe der Zeit und als Folge der kommerziellen Nutzung kamen immer mehr zeitkritische Anwendungsbereiche hinzu wie die Übertragung von Sprache und Video. Diese Anforderungen waren für IPv4 nicht vorgesehen und lassen sich in das bestehende Protokoll auch nur schwer implementieren.

Großzügig bemessener Adressraum bei IPv6

Zum Glück arbeitet man seit Mitte der 90er-Jahre intensiv an Abhilfeszenarien, die in Form von IP Version 6 (IPv6) ihr endgültiges Aussehen bekommen hat. Wobei man hinsichtlich der zukünftigen Größe des freien Adressraums noch viel großzügiger vorgegangen ist als bei IPv4:

  • Die Anzahl der Adressen wurde bei IPv6 wurde nicht nur verdoppelt oder verzehnfacht, sondern gleich auf 2128 erhöht. Diese Zahl ist astronomisch; es gibt viel mehr IPv6-Adressen als Atome im Universum (auch wenn die Schätzungen darüber von 266 bis ca. 280 divergieren). Man muss sich also keinen Zwang antun und bei der IP-Adresszuweisung sparen, sondern kann wieder genau so verschwenderisch mit Adressen umgehen, wie das unter IPv4 lange üblich war.
  • Für den unwahrscheinlichen Fall, dass man irgendwann doch zu verschwenderisch war, sieht IPv6 auch noch automatische Umnummerierungen vor (d. h. zum Beispiel, dass der IP-Bereich einer Organisation verschoben werden kann, ohne dass ein Administrator eingreifen und z. B. alle Endgeräte umbenennen muss).

Skalierbare Architektur in IPv6

Innerhalb der IETF steuerte die Arbeitsgruppe Internet Protocol Next Generation (IPNG) die Entwicklung der Internet-Protocol-Version 6. Diese Arbeiten wurden im Jahr 1997 zum Draft-Standard erhoben. Bei der Entwicklung von IPv6 wurde von Anfang an versucht, eine möglichst skalierbare Architektur zu erhalten, um Anforderungen, die momentan noch nicht absehbar sind, einfach in dem Protokoll implementieren zu können.Nach Jahren der Erfahrung mit IPv4 stellte sich erfreulicherweise heraus, dass eigentlich alles ganz akzeptabel funktioniert. Das Internet ist immerhin größer geworden, als seine Erfinder je gedacht hatten. Und dank der Nutzung privater IP-Netze, NATs, VPNs und Firewalls ist die Zahl der IP-Adressen in Benutzung nicht einmal genau feststellbar.

Weglassen unnötiger Aufgaben in IPv6

Trotzdem hat das Protokoll Ecken und Kanten, die man bei einer Generalüberholung gleich mit entfernen kann. So sind z. B. bei IPv4 Router damit beschäftigt, Checksummen zu prüfen und Pakete zu fragmentieren. Das sind grundsätzlich keine schwierigen Aufgaben, aber bei dem enormen Durchsatz heutiger Leitungen ist es wichtig, die Arbeit des Routers zu minimieren. IPv6 hat daher keine Prüfsumme im IP-Header (sondern im TCP-Header, d. h. kaputte Pakete werden immer noch von den Endpunkten erkannt), und Router fragmentieren zu große Pakete nicht mehr, sondern schicken eine Fehlermeldung zum Endpunkt. Der kann dann die maximale Paketgröße, die MTU (Maximum Transmission Unit), entsprechend anpassen. Dieses Verfahren heißt Path MTU Discovery und existiert in leicht abgewandelter Form auch in IPv4. (Dort muss man ein „Don’t Fragment“-Bit setzen, um den Effekt zu erhalten.) Dieses Verfahren ist aber nur empfohlen und nicht wie bei IPv6 Pflicht.

Verlust von ICMP-Meldungen

Manchmal sorgen kaputte Firewalls oder Transfernetze mit reservierten IP-Adressen (10.*, 172.16.* und 192.168.*) dafür, dass ICMP-Meldungen komplett verloren gehen, wodurch die Path MTU Discovery fehlschlägt und TCP-Verbindungen „hängen bleiben“. IPv4 definiert die kleinste MTU mit 68 Bytes sehr niedrig. Wenn ein Host merkt, dass Path MTU Discovery fehlschlägt, muss er sich also auf 68 Bytes Paketgröße beschränken, was Router und Bandbreite unnötig belastet. Bei IPv6 ist die kleinste MTU auf 1280 Bytes erhöht worden.

Routerentlastung

Als weitere Maßnahmen zur Entlastung der Router ist die Header-Länge fest (bei IPv4 ist sie variabel lang) und die wichtigen Felder sind 64-Bit-aligned. Falsches Alignment bremst heutige Prozessoren beim Speicherzugriff um bis zu den Faktor 3 aus. Die Flags wurden ganz aus dem Header entfernt; dafür kann man bei IPv6 Optionen in Zwischenheadern zwischen IP und UDP/TCP einfügen. Außerdem ist das Feld „TTL“ in „Hop Limit“ umbenannt worden, was seiner Bedeutung auch bei IPv4 entspricht. Zusätzlich (siehe MPLS) gibt es ein „Flow Label“-Feld, über das man viel schnelleres Routing hätte implementieren können, wenn es nicht kürzlich durch MPLS überflüssig gemacht worden wäre.

Administrator-Support

Das Protokoll muss natürlich auch den Administratoren und Endbenutzern deutliche Vorteile bringen, damit es überhaupt eine Chance hat. Für beide Gruppen ist es wichtig, die Support-Probleme zu lösen, die IPv4 verursacht, wenn Leute an ihren Rechnern Konfigurationen vornehmen müssen, um im Web surfen zu können. Die erste Idee war eine Anpassung des alten BOOTP-Protokolls. Herausgekommen ist DHCP, vorläufig für IPv4. Das ist noch nicht ausreichend, weil DHCP servergebunden ist. Die IPv6-Ingenieure haben daher zwei Szenarien definiert, die IPv6 lösen soll:

  • eine Zahnarztpraxis, in der gerade zwei Rechner gekauft und zusammengebaut wurden, und der Arzt will jetzt Daten zwischen beiden austauschen
  • eine Messehalle mit 10.000 Rechnern, die alle an einem bestimmten Tag Punkt acht Uhr morgens ans Internet angeschlossen werden sollen

Es wurde also eine Autokonfiguration gesucht, die völlig ohne Benutzereingaben auskommt.

Autokonfiguration

Hier hat IPv6 tatsächlich Pionierarbeit geleistet. Bei IPv6 hat man nicht nur eine IP-Nummer pro Interface, sondern es gibt Link-Local-, Site-Local- und ganz normale globale IP-Nummern. Der Clou ist, dass die Link-Local-Adresse direkt aus der Ethernet-MAC (oder sonstigen Layer-2-MAC) berechnet wird, d.h. jedes Gerät hat für jeden Link automatisch eine Link-Local-Adresse. IPv6 sieht auch noch eine Kollisionserkennung vor, die allerdings den Rückfall auf manuelle Intervention zur Folge hat. Mit dieser Link-Local-Adresse kann das Endgerät dann auf dem Link kommunizieren und z.B. per Multicast die Router finden. Wenn die Router bekannt sind, lässt sich das Endgerät von ihnen seine globalen IP-Adressen geben. Bei IPv6 kann man pro Router mehrere IP-Adressen haben und über alle gleichzeitig erreichbar sein. Der Host sucht sich automatisch die richtige Route und den richtigen Router.

IPv6 ist mehr als IPv4

Warum hat sich dann IPv6 noch nicht flächendeckend und überall durchgesetzt?

Schon durch die bei der verbesserten Administration einzusparenden Kosten amortisiert sich ja in größeren Konzernen die Anschaffung für neue Router und andere Infrastruktur in nur wenigen Monaten. Die Antwort ist einfach: Etliche der Vorteile von IPv6 wurden der Reihe nach auf IPv4 zurückportiert, allerdings nicht immer mit Erfolg. So gibt es bei der Adresskonfiguration inzwischen auch Regeln für IPv4, wie vorzugehen ist, wenn kein DHCP-Server gefunden wird. Diese Regeln sind sogar schon in Windows Me implementiert worden.

Mobile IPv6

Allerdings reichen die Vorteile von IPv6 weiter als nur bis zur Autokonfiguration! Das betrifft zum Beispiel die Arbeitsgruppe bei der IETF, die sich mit Mobile IPv6 beschäftigt. Die Idee ist, dass man seinen Laptop auf einer Konferenz einfach wie gewohnt anstöpselt (oder, wie es heute üblich ist, per Funknetz Internet-Zugang bekommt) und dann mit seiner IP von zu Hause aus weiterarbeitet. Wenn man den Laptop zu Hause nicht ausgeschaltet, sondern nur im Suspend-Modus schlafen gelegt hat, dann sollten sogar die TCP-Verbindungen noch bestehen!

ICMP-Umleitungsnachricht

Netzwerkspezialisten fragen sich natürlich, wie das mit Routing-Protokollen in Einklang zu bringen sein soll, die Adressen aggregiert betrachten und in arge Performance-Probleme geraden würden, wenn jede IP anders zu routen wäre. Die offensichtliche Lösung wäre der Aufbau von IP-Tunneln zwischen dem heimischen Netz und dem Konferenznetz, aber dann würde der Traffic ja doppelt über das Netz gehen. Bei IPv6 hat man daher extra für diesen Zweck eine ICMP-Umleitungsnachricht eingeführt, mit der der Laptop auf der Konferenz einen Agenten-Rechner im heimischen Netz mitteilen kann, unter welchen IPs er gerade erreichbar ist, und der Agent kann dann ankommende Verbindungen dorthin umleiten.

Das erfordert natürlich enorme Sicherheit, und die wird auch gegeben. Denn der Agent leitet nicht einfach auf Zuruf Verkehr um, sondern mit kryptografischen Methoden wird für eine starke Authentifizierung gesorgt.

Sicherheit

Die kryptografische AuthentisierungAuthentisierungkryptografisch ist denn auch einer der vielen Vorteile von IPv6, gepaart mit Verschlüsselung zur Sicherung der Privatsphäre. Das Schlagwort hierfür ist IPsec. Zwar ist auch IPsec inzwischen für IPv4 definiert und in regem Einsatz (wenn auch bislang hauptsächlich im Tunnel-Modus für VPNs und nicht Punkt-zu-Punkt, wie es bei IPv6 eigentlich gedacht ist). Aber da IPv6 von Ingenieuren der IETF und nicht von der Marketing-Abteilung von Microsoft definiert wurde, kommt „richtige“ Kryptografie zum Einsatz, d.h. die Verfahren sind offen und erprobt, haben auch schon mehrere Jahre offengelegen und sind in dieser Zeit von fast allen Experten eingesehen und kritisiert worden. Wenn man also von IPsec eine vernünftige Implementierung bekommt, gibt es auch für große Zweifler keinen Grund für Misstrauen dem Verfahren gegenüber. In diesem Zusammenhang erwähnenswert ist, dass DES sofort aus der Liste der symmetrischen Chiffren genommen wurde, als vor ein paar Jahren das Knacken der Hardware-DES der EFF publik wurde.

Hinzu kommen einige Neuerungen, die eher für große Firmen interessant sind (und sehr langfristig auch für das Internet), aber keinen sofortigen Gewinn durch ihre bloße Anwesenheit erbringen: Multicast und Quality of ServiceMulticastIPv6Quality of ServiceIPv6.Auch Multicast und Quality of Service sind umgehend zu IPv4 zurückportiert worden. Multicast ist ein Verfahren zur effizienteren Bandbreitenausnutzung bei der Übertragung an mehr als einen Empfänger (d.h. besonders für Video- und Audio-Streaming mit hoher Bandbreite wichtig), und Quality of Service fasst Protokolle und Methoden zusammen, mit denen einzelne Datenströme bevorzugt behandelt werden können. Die Idee ist, dass der Anwender für den Radioempfang über IP bezahlt und den Datenstrom dann auch ohne Paketverlust, Rauschen oder Verzögerungen zugestellt bekommt. Aber auch für andere Anwendungen ist geringer temporaler Jitter wünschenswert, insbesondere bei den immer erfolgreicheren IP-Telefonen.

Bei IPv6 hat Multicast dank der breiteren Adressen stärkere Flexibilität. 4 Bit der Adresse sind für den Scope reserviert und sagen aus, wie weit eine Multicast-Ausstrahlung propagiert werden soll.

Praktische Auswirkungen

IPv6 bringt gravierende Effizienzsteigerungen für Router. Die Funktion des Flow-Labels entspricht weitgehend dem, was man inzwischen über MPLS auch prototollunabhängig erreicht. Router müssen auch nicht mehr fragmentieren. Und damit, dass Router im laufenden Betrieb und ohne manuellen Eingriff des Administrators den Adressbereich verändern können, hat man das größte Problem im praktischen Einsatz aus der Welt geschafft. Die Routing-Tabellen können dadurch deutlich verkleinert werden, denn bei den IPv4-Routingtabellen gibt es fragmentierte Adressbereiche (d.h. der Gesamtbereich gehört ISP XY, aber ein Unterbereich Z gehört einem Kunden, der inzwischen zu einem anderen ISP umgezogen ist, d.h. der nicht über ISP XY geroutet wird) und große Bereiche, die aus historischen Gründen jemandem gehören, der sie gar nicht oder nur sehr eingeschränkt nutzt. Wenn man diesen Bereich aber aufteilt, dann wäre er nicht mehr als Aggregat durch eine Route zusammenfassbar, und die weltweite Routing-Tabelle würde explodieren. Alle diese Kalamitäten vermeidet RenumberingRenumberingIPv6 sehr elegant.

Vorteile für die Anwender

Aber nicht nur die Routing-Effizienz kann so gesteigert werden. Viele Kunden wechseln den ISP nicht, obwohl er schlechte Leistung zu überhöhten Preisen bietet, weil sie die Kosten für die Adressumstellung fürchten. Solche Kunden haben dem ISP gegenüber keinerlei Druckmittel in der Hand. Mit Renumbering ändert sich das.

Aber auch im LAN bietet IPv6 Effizienzsteigerungen. So gibt es keinen Broadcast mehr. Alle früher über Broadcast abgewickelten Protokolle werden bei IPv6 über Multicast implementiert. Ein Beispiel ist ARP. ARP ist das Protokoll, mit dem man bei IPv4 die MAC-Adresse (d.h. die eindeutige Nummer der Ethernet-Karte) zu einer IP herausfindet. Bei IPv6 wird diese Funktionalität über Neighbor-Solicitation-Pakete implementiert. Das funktioniert dann so, dass man aus der IP-Adresse, zu der man die MAC-Adresse sucht, mittels einer Funktion aus dem Standard eine Multicast-Gruppe errechnet, und an diese schickt man dann die Anfrage. Jeder Host ist laut Standard gezwungen, sich bei der Multicast-Gruppe zu subscriben, die zu seiner IP gehört. Der Effekt ist, dass in großen, geswitchten Ethernets Neighbor-Discovery-Pakete praktisch nur auf den Strängen zu sehen sind, bei denen der Host sich tatsächlich befindet.

Signifikante Bandbreite wird beim ARP-Verkehr z.B. dann verbraucht, wenn ein sehr großes geswitchtes Ethernet mit einem Wireless LAN verbunden wird, das nur ein Hundertstel der Bandbreite hat. Dann kann es bei IPv4 vorkommen, dass das Wireless LAN zu einem signifikanten Teil durch ARP-Anfragen gefüllt wird. Verschärft wird diese Situation durch Portscans, wie sie bei Hacker-Conventions und LAN-Parties üblich sind. In solchen Fällen sind Wireless-LAN-Anbindungen gewöhnlich vollständig mit ARP-Verkehr ausgelastet. Bei IPv6 stünde in diesem Fall die volle Bandbreite weiterhin zur Verfügung.Ähnlich geht es bei der Selektion der Router zu. Während man bei IPv4 IGMP als eigenes Protokoll neben ICMP umgesetzt hat, ist Multicast Listener Discovery ein Subtyp von ICMPv6.

Supercomputererweiterung

Bei IPv6 gibt es außerdem eine „Jumbogram“ genannte Erweiterung für die Supercomputing-Fraktion. Die hat nämlich erwogen, für die Verbindungen zwischen den Teilen eines Clusters oder einer NUMA-Maschine IPv6 einzusetzen. Diese Verbindungen zeichnen sich durch eine enorme Bandbreite aus, sodass Paketgrößen von über 64 Kilobytes sinnvoll werden. Die Jumbogram-Extension erlaubt genau das.

Quellennachweis

Mathias Hein
aus dem Werk “LAN-Analyse und -Troubleshooting”


zu weiteren Themen aus dem Bereich der Netzwerktechnik:

Grundlagen der Verkabelung     Anwendungsneutrale Gebäudeverkabelung

Heute schon gescrimpt?     Wieder gut aufgelegt?     Übertragungsmedien

Netzwerk-Hardware     Power over Ethernet (PoE)     Grundlagen TCP/IP

IP-Adressen     Subnetzmasken     Domain Name Servie (DNS)

UDP-Protokoll     Glossar und Abkürzungen