Umbau

Inhaltsverzeichnis

Ende 2009 fiel der Startschuss: Es galt, den Kunden das „neue“ Internet-Protokoll der Version 6 (IPv6) anzubieten. RIPE, die europäische Vergabestelle für IP-Adressen, nahm den Antrag für die Zuweisung eines IPv6-Netzes entgegen. Da der Registrierungsstelle eine zügige Einführung des Protokolls am Herzen liegt, war der Antrag entsprechend schnell bearbeitet. Den meisten Antragstellern weist sie ein /32-Netz zu. Damit stehen für Provider theoretisch so viele Netze zur Verfügung, wie es weltweit insgesamt IPv4-Adressen gibt (gut vier Milliarden). Und jeder Kunde der damit ausgestatteten Provider könnte wiederum ein Vielmilliardenfaches dessen an Adressen nutzen, was IPv4 kennt.

Adressen in Hülle und Fülle

In absehbarer Zeit wird der Vorrat an IPv4-Netzen erschöpft sein. Provider sollen die bisher verteilten Bereiche laut den Vergaberegeln deshalb möglichst effizient nutzen. Es war bislang unmöglich zu planen, wie sie das Netz vergeben oder nach welchen Kriterien sie es einteilen. Dagegen erlaubt die nahezu unendliche Zahl der IPv6-Netze den Providern jetzt erstmals, die Adressen nach eigenen Kriterien zu unterteilen, die ihnen logisch erscheinen.

Im vorliegenden Fall bot sich eine Dreiteilung des /32-Netzes an: Kundenbereiche, internes Netz, auf das Kunden und Mitarbeiter zugreifen, sowie ein den Mitarbeitern vorbehaltener Bereich. Die Administratoren legen fest, welcher Rechner auf welche Netzbereiche Zugriff erhält. Firewall-Setups sind durch die Einteilung jetzt einfacher, da die Filter den Datenverkehr komfortabel nach Netzblöcken sortieren können anstatt nach Dutzenden einzelner Systeme oder Netze. Die passende Verwaltungssoftware fehlt noch – eine schlichte Excel-Tabelle dokumentiert derzeit die Aufteilung des Netzes.

Im Schutze der Nacht

Das Netzwerk verbindet über 10-Gpbs-Backbone-Leitungen mehrere Standorte in Europa miteinander. Für die wesentlichen Carrier-Uplinks und Peerings – also an den Punkten mit dem stärksten Datenverkehr – sind Router der Firma Brocade (ehemals Foundry) im Einsatz. Die wichtigsten Routing-Verbindungen ließen sich innerhalb kurzer Zeit konfigurieren und aktivieren. Der IPv6-Betrieb einschließlich Außenanbindung startete im Rahmen geplanter Updates der Router-Software während nächtlicher Wartungsarbeiten per Reboot.

Einer der drei Uplink-Carrier unterstützt bereits das neue Protokoll. Da der IPv6-Datenverkehr in der Startphase noch gering ist, lässt sich das Routing entsprechend einfach steuern. Neue Ports sind nicht erforderlich, da IPv6 die bestehende physische Infrastruktur – sprich: Kabel und Anschlüsse – wie IPv4 nutzt. Lediglich Netzwerknummern gilt es zu definieren und – analog zu IPv4 – Routing-Verbindungen anzulegen.

Größere Peers verfügen in der Regel bereits über entsprechende IPv6-Verknüpfungen. Zu installieren waren dazu die BGP-Verbindungen zu anderen Providern am DECIX, AMSIX und ECIX. Die grundlegenden Einstellungen ließen sich aus der IPv4-Konfiguration der Router übernehmen. Damit die anderen Provider ihre Konfigurationen anpassen können, benötigen sie Informationen über neue IP-Adressen.

Access Router unter Linux

Der IPv6-Testbetrieb der Access Router verlief bisher ohne Komplikationen. Die meisten Kunden sind an Router angeschlossen, auf denen eine eigens angepasste Linux-Distribution läuft. Der Linux-Kernel unterstützt IPv6 seit der Version 2.2.x. In diesem Fall wird es direkt in den Kernel kompiliert, wahlweise lässt es sich als Modul nachladen (siehe Abb. 1). Die Routing-Software Quagga ermöglicht die Nutzung von BGP und anderen Routing-Protokollen unter Unix, sie ist ebenfalls IPv6-kompatibel. Insgesamt ließen sich die Router von Brocade (NetIron XMR) sowie Linux mit Quagga schnell und auf unkomplizierte Weise einrichten.

Cisco, Quagga, Brocade und Systeme mit ähnlicher Syntax unterscheiden IPv6-Sessions über den Befehl address-family. In den Konfigurationen der Router gibt es eine Unterteilung nach Protokollen. Beim Konfigurieren wählt man zuerst das Routing-Protokoll (hier router bgp <AS-Nummer>) und kann dann über den Befehl address-family weiter auswählen, auf welches Protokoll oder welche Routen sich die nachfolgende Konfiguration bezieht, in diesem Fall die der BGP-Sessions. So kann der Netzverwalter auch definieren, ob ein Peer nur IPv4, nur IPv6 oder auch beides beherrschen soll. Letzteres spielt, soweit den Autoren bekannt, in der Praxis allerdings keine Rolle. Per Default gilt die Annahme, dass es um IPv4 geht, darum fehlt der Eintrag für address-family ipv4 (siehe Abb. 2).

Von den Access-Routern erhalten die Kunden Statistiken über den Datenverkehr. Eine Filterregel für jede einzelne IP-Adresse erfasst bei IPv4 auf das Byte genau, wie viel Traffic die Kunden produzieren. Das Prinzip lässt sich allerdings nicht auf IPv6 übertragen, da die Zahl der Adressen zu hoch ist.

Software, Skripte und Nameserver anpassen

Stattdessen bieten sich zwei neue Ansätze an, den Traffic zu messen: erstens anhand der MAC-Adresse. Damit wird unabhängig von der IP-Adresse sichtbar, welcher Anteil auf einen bestimmten Rechner entfällt. Zweitens kommt in Betracht, dass sich der Provider auf die IP-Adressen mit dem stärksten Datenverkehr beschränkt und Beispielpakete oder bestimmte Adressen statistisch auswertet. Die Praxis muss zeigen, welche der beiden Methoden sich wie gut bewährt.

Damit niemand den Überblick über die Netzressourcen verliert, gilt der Dokumentation besonderes Augenmerk. Ein eigens programmiertes Web-Interface mit SQL-Datenbank hilft, die Ordnung zu bewahren. Die gleiche Anwendung nutzen Kunden dafür, ihre Server zu überwachen oder Statistiken über Traffic und Stromverbrauch anzusehen. Teile der Software gilt es nun an die neuen Netzdimensionen anzupassen oder neu zu schreiben.

Basierend auf der RIPE-Datenbank generiert ein Skript IP-Adresslisten für BGP-Verbindungen und vergleicht automatisiert eigene Daten mit denen von RIPE. Solche Skripte, die bisher auf der Syntax von IPv4-Adressen basieren, sind ebenfalls an IPv6 anzupassen.

Wer IPv6 auf sinnvolle Weise nutzen will, benötigt – genau wie beim Vorgängerprotokoll – die Unterstützung des Domain Name System (DNS). Vor allem müssen die Nameserver die IP-Adressen zu Hostnamen liefern. Daneben sollten IP-Adressen wiederum zu Hostnamen führen („Reverse DNS“). Nameserver und DNS-Caches sind über IPv6-Adressen erreichbar.

BIND9, die Nameserver-Software, beherrscht bereits IPv6 – noch nicht jedoch die Software im Web-Interface, die einzelne Nameserver-Zonen generiert. Bis sich das ändert, sind die entsprechenden Einträge von Hand einzupflegen. Da den Kunden nicht nur Datenverbindungen, sondern auch diverse Anwendungen zur Verfügung stehen, müssen auch diese nach und nach IPv6-fähig werden. Dazu gehören eigene Web- und Mailserver für Hosted Exchange und kundeneigene Systeme.

Fazit und Ausblick

Auf der Soll-Seite sind für die Umstellung auf IPv6 bisher nur Personalkosten angefallen. Weder für Tests noch für den Live-Betrieb war neue Hardware anzuschaffen – eine Folge der bereits seit Langem verfolgten Strategie, bei Routern und anderen Investitionen auf deren IPv6-Fähigkeit zu achten. Die Anpassung der Verwaltungssoftware und der Anwendung zur Traffic-Erfassung haben allerdings mehr Zeit beansprucht als ursprünglich vorgesehen.

Allein das Interesse der Kunden an IPv6 ist momentan noch gering. Erstaunlicherweise beantragen selbst Neukunden häufig nur IPv4-Adressen. Sie ziehen es vor, kein IPv6 zusätzlich zu buchen, obwohl es ihnen ohne Aufpreis zur Verfügung stünde. Einige geben an, dass sie noch Software schreiben, die IPv6 nicht vorsieht. Bisher interessieren sich einzig Kunden für den Anschluss an IPv6, die selbst Internet-Provider sind.

Nach derzeitiger Planung wird es in diesem konkreten Anwendungsfall bis zur vollständigen Integration von IPv6 noch bis mindestens Ende 2012 dauern. Das würde sich allerdings ändern, sollte es plötzlich einen IPv6-Boom geben, der verlangte, die Prioritäten anders zu setzen. Das kann passieren, wenn einer der großen Kabel- und DSL-Provider nativ IPv6 anbietet – oder spätestens, wenn es bei einer der Vergabestellen keine IPv4-Adressen mehr gibt. Das könnte bereits 2011 oder 2012 geschehen.

Patrick Kambach

ist Director of IT bei der MESH GmbH.

Rolf Hanßen

ist Network Designer bei der MESH GmbH. (un)