IPv6: Fundamente richtig legen

Kommentieren Drucken

Die Welt der Netze steht vor der nächsten großen Umstellung. Das Internet Protocol der Version 6 (IPv6) wird kommen. Daran zweifelt niemand mehr ernsthaft. IPv6 wird an den Grenzen keines Unternehmens halt machen. Jedes Unternehmen muss sich auf IPv6 vorbereiten. Wenn die Fundamente richtig gelegt werden, wird die Umstellung auf IPv6 weitgehend schmerzfrei verlaufen. Anderenfalls drohen instabile Zustände und ein großer Migrationsaufwand.

Aber welche sind die richtigen Fundamente? Die ersten Erfahrungen aus der Praxis liegen vor. Alle Unternehmen können von diesen Erfahrungen lernen. Und sie sollten das tun. Die Zeit dafür ist jetzt. Bevor äußere Zwänge zum überstürzten Handeln zwingen, müssen die Verantwortlichen für die IT-Infrastruktur die geplante und gut durchdachte Einführung von IPv6 im eigenen Unternehmensnetz vorbereiten. Der erste Schritt ist der Aufbau von Know-how über IPv6. Einiges bei IPv6 unterscheidet sich vom Pendant unter IPv4. Und da ist noch die lange Phase des Nebeneinanders der beiden Protokolle. Dieselben Systeme und Anwendungen können beide Protokolle nutzen. Dies sollte kontrolliert und gesteuert erfolgen. Alles dem Zufall zu überlassen kann heilloses Durcheinander, Ausfälle und viel Arbeit bedeuten.

Deshalb ist es wichtig, dass die Experten im Unternehmen die Unterschiede zwischen IPv4 und IPv6 kennen. Ferner ist es von Bedeutung zu wissen, welche Probleme und Unwägbarkeiten es in einer dualen Umgebung mit beiden Protokollen geben kann.

Die letzten Zweifler überzeugen

Noch sind nicht alle, auf deren Stimme und Einfluss es in der IT ankommt, davon überzeugt, dass man sich mit IPv6 befassen muss. Immer seltener, aber häufig genug hört man das Argument, dass ein Protokoll, von dem schon seit fast 20 Jahren gesprochen wird, noch lange auf sich warten lassen wird. Vor allem weil viele Anwendungen und Systeme IPv6 noch nicht unterstützen, brauche man sich mit diesem Protokoll gar nicht zu befassen. So das Argument der Zweifler. Zu diesen gehören leider auch viele, die über IT-Budgets entscheiden und die Prioritäten in Unternehmen setzen. Diese Zweifler sind der Meinung, die Unternehmens-IT habe dringendere Aufgaben zu bewältigen. Die dringenden Probleme seien wichtiger als ein Protokoll einzuführen, das zurzeit von den meisten Applikationen und Geräten noch gar nicht unterstützt werde.

Wahrscheinlich lassen sich diese Zweifler von der rhetorischen Frage kaum beeindrucken, die lautet: Warum muss eine Aufgabe erst zu einer dringenden werden, bevor sie angepackt wird? Es gilt nun man: Dringenderes zuerst.

Was vielleicht überzeugender auf die Zweifler wirkt, ist der Hinweis, dass die IPv6-Einführung insgesamt nicht als „Big Bang“ durchgeführt werden muss. Das Stichwort heißt „Lifecycle“. Die IPv6-Umstellung betrifft die Gesamtheit der IT-Systeme: Switches, Router, Sicherheitskomponenten, Server, Endgeräte, Betriebssysteme, Middleware und Anwendungssoftware. Es ist unvorstellbar, dass die Umstellung all dieser Komponenten auf IPv6 nach einem Stichtagsprinzip gelingen kann. Deshalb ist mit einer langen Umstellungsphase zu rechnen. Vor diesem Hintergrund ist es geschickter, die IPv6-Umstellung nicht losgelöst, sondern im Zuge vom normalen Lebenszyklus der Komponenten vorzusehen. Konkret bedeutet dies: Ist die Ablösung einer Anwendung, eines Systems, einer Middleware zu einem bestimmten Termin ohnehin vorgesehen, ist dieser Termin der geeignetste Zeitpunkt der Umstellung auf den dualen Betrieb mit IPv4 und IPv6 bzw. auf reinen Betrieb mit IPv6.

Auf diese Weise wird die Hemmschwelle gesenkt, die viele Unternehmen bisher von der Beschäftigung mit IPv6 abgehalten hat. IPv6-Einführung als Begleiterscheinung des normalen Lifecycles der IT-Komponenten lässt sich einfacher durchsetzen als ein Umstellungsprojekt mit eigenem hohem Budget.

Aber die Dringlichkeits- und Budgetüberlegungen sind nicht die einzigen Argumente gegen IPv6. Auch technische Argumente werden manchmal bemüht. So wird behauptet, die Adressknappheit als Hauptmotivation für die Einführung von IPv6 sei ein Phantom. Das Argument lautet konkret, global gültige IPv4-Adressen seien schon seit den 1990er Jahren knapp, und man habe gelernt, damit umzugehen. Diese Position weist auf die Abhilfe durch Network Address Translation (NAT) hin, die angeblich das Problem der Adressknappheit eliminiere. (siehe Bild 1)

In ihrer Not haben sogar die Service Provider für die eigenen Netze NAT eingeführt. Wer die IPv4-Adresse seines mobilen Gerätes im öffentlichen Netz überprüft, stellt oft fest, dass die Adresse einem privaten Adressraum wie 10.0.0.0/8 oder 100.64.0.0/10 entstammt. Im Umkehrschluss bedeutet dies, dass die heutigen Applikationen auf eine global eindeutige Adresse nicht angewiesen sind.

Diese Argumentation lässt außer Acht, dass die Service Provider mit Skalierbarkeits- und Betriebsproblemen im Zusammenhang mit NAT kämpfen. Der Verkehr im Netz explodiert. Dies gilt auch für die Anzahl paralleler Verbindungen. NAT-Komponenten, die die rapide steigende Zahl der Verbindungen in Tabellen verwalten, werden zu Nadelöhren im Netz. Immer mehr solche Komponenten müssen betrieben werden. Dies bedeutet mehr Aufwand für die Service Provider und oft auch Ärgernis für ihre Kunden.

Ferner legt IPv4 der Cloud Ketten an. Eine Cloud lebt von der Skalierbarkeit, auch was die Anzahl der in der Cloud realisierbaren Server betrifft. Jede, auch jede virtuelle, Maschine in der Cloud braucht mindestens eine IP-Adresse, über die sie erreichbar ist. Diese Adresse sollte eine öffentliche sein. Hinter NAT verborgen kann ein Server nur ca. 60.000 gleichzeitige Verbindungen unterstützen, weil die zur Indizierung genutzte Portnummer nur 2**16 Werte ermöglicht. Nicht von ungefähr zahlte Microsoft 7,5 Millionen Dollar für ca. 666.000 IPv4-Adressen aus der Konkursmasse von Nortel. Jeder Cloud-Betreiber braucht eine schnell wachsende Zahl von öffentlichen Adressen.

Übrigens gibt es die NAT-Restriktion auch beim ausgehenden Zugriff aus einem Unternehmensnetz auf einen öffentlichen Server. Eine öffentliche IP-Adresse kann per NAT nur ca. 60.000 gleichzeitige Verbindungen mit demselben Server erlauben.

Es gibt auch Sicherheitsbedenken gegen IPv6. Hier lautet das Argument, die Nutzung privater IPv4-Adressen sei ein Sicherheitsvorteil. Eine private Adresse sei von außen nicht erreichbar, und das könne nur gut sein. Wer so argumentiert, verkennt, dass die direkte IP Connectivity für die meisten der heutigen Angriffsmuster nicht erforderlich ist. Oder anders formuliert: Es ist um die Sicherheit des Unternehmens nicht gut bestellt, wenn sich das Unternehmen nur auf private Adressen im internen Netz setzt. Dem Autor sind Unternehmen bekannt, die seit über zwei Jahrzehnten keine anderen als global gültige IPv4-Adressen einsetzen. Die Netze dieser Unternehmen gehören zu den sichersten, die der Autor kennt. Den IP-Durchgriff ins Unternehmensnetz hinein zu verhindern gehört zu den leichtesten Sicherheitsaufgaben und ist auch ohne NAT zu lösen. Heutige Angriffe sind viel komplexer und nutzen erlaubte Kanäle, um selbst bei Anwendung von NAT in das Unternehmensnetz zu gelangen. (siehe Bild 2)

Eine weitere Argumentationslinie gegen die Einführung von IPv6 im Unternehmensnetz besteht darin, IPv6 als eine reine Internet-Angelegenheit zu bezeichnen. Wer so argumentiert, sieht die Notwendigkeit des neuen Protokolls im öffentlichen Netz ein, um im gleichen Atemzug diese Notwendigkeit in Unternehmensnetzen abzustreiten. Man könne doch im internen Netz ein anderes Protokoll nutzen als im Internet, wo sei das Problem? Diese Argumentation baut darauf, dass die Anbieter von Hardware und Software IPv4 unbegrenzt unterstützen werden. Die Erfahrung der letzten Jahrzehnte spricht aber dagegen. Sobald die seit einigen Jahren schnell wachsende IPv6-Nutzung im Internet IPv4 überflügelt, wird die duale Welt infrage gestellt. Viele Entwicklungen in der IT greifen vom Verbraucher- auf den Unternehmensmarkt über. So war das bei PCs, Smartphones, Tablets, und so wird es bei IPv6 sein. Das Leben auf der IPv4-Insel der Glückseligen, während ringsherum Milliarden von Geräten über IPv6 kommunizieren und das Internet of Things alles erfasst, was mit Strom oder Batterie arbeitet, wird irgendwann nicht mehr möglich sein. Es werden Systeme und Applikationen kommen, die nur IPv6 und kein IPv4 mehr unterstützen. Erste Anzeichen dafür gibt es schon. Microsoft schränkt den Support für Windows-Systeme ein, auf denen IPv6 abgeschaltet ist.

IPv6-Adresskonzept ausarbeiten
Ist es gelungen, die letzten Zweifler im eigenen Unternehmen zu überzeugen, muss man zur Vorbereitung der IPv6-Einführung zunächst konzeptionelle Arbeit leisten. Dazu gehört die Ausarbeitung eines Plans für die im Unternehmen zu nutzenden IPv6-Adressen.

IPv6 wird an einigen Prinzipien des Netzdesigns nichts ändern. Zu diesen Prinzipien gehört die Einteilung der Netze in Subnetze. Auch IPv6-Subnetze müssen über Router miteinander kommunizieren. Deshalb werden automatisch generierte Link-Local Addresses (LLAs) nicht ausreichen. LLAs erlauben nur die Kommunikation in einem Subnetz.

Geroutete IPv6-Adressen sind entweder Global Addresses (GAs) oder Unique Local Addresses (ULAs), wie aus dem Bild 3 hervorgeht. GAs sind mit öffentlichen IPv4-Adressen vergleichbar. Sie sind weltweit gültig. Ein Gerät mit einer GA kann direkt auf der IP-Ebene mit jedem anderen Gerät im Internet kommunizieren. ULAs sind mit privaten IPv4-Adressen vergleichbar. Sie werden im Internet nicht geroutet. ULAs sind nur innerhalb der Grenzen eines Unternehmens eindeutig.

Das IPv6-Adresskonzept muss die Entscheidung für den Einsatz von GAs oder ULAs im Unternehmensnetz fällen und begründen. Diese Entscheidung kann nur unternehmensspezifisch gefällt werden. Wer die Notwendigkeit der direkten IP-Verbindung eines Gerätes mit externen Netzen ausschließt, kann für dieses Gerät eine ULA vorsehen. Proxies auf Transport- oder Applikationsebene ermöglichen bekanntlich Geräten ohne direkte IP-Verbindung den Zugriff auf das Internet. Es ist aber zu bedenken, dass die heutige Middlebox-Architektur, zu denen Firewalls und Proxies gehören, nicht von Ewigkeit sein muss. Sie skaliert nicht und ist schwer zu betreiben. Aus diesem Grund gibt es zurzeit Überlegungen, Middlebox-Funktionalität mit einer anderen Architektur zu erreichen. Dies könnte im Sicherheitsbereich zum Beispiel darin bestehen, dass die Sicherheitsregeln von einer Vielzahl Netzkomponenten durchgesetzt werden. Eine denkbare Sicherheitsarchitektur kann die heutige Praxis, am Perimeter innere und äußere Sessions zu entkoppeln, durch eine andere ersetzen. Es ist denkbar, dass für die Durchsetzung der Sicherheitsregeln die Entkopplung der Sessions am Perimeter und damit die Verhinderung der direkten IP-Kommunikation nicht erforderlich sein werden. Private Adressen erzwingen jedoch eine solche Entkopplung. Ein Adresskonzept mit global gültigen Adressen ist damit flexibler und zusammen mit jeder denkbaren Sicherheitsarchitektur einsetzbar.

Globale Adressen sind entweder providerunabhängig (Provider Independent, PI) oder aus dem zusammenhängenden Block eines Providers (Provider Aggregatable, PA). PA-Adressen haben den Nachteil, dass beim Providerwechsel die Adressen geändert werden müssen. Dies klingt aufwändiger als es vielleicht sein wird. IPv6 erlaubt aufgrund der vierfachen Zahl der Bits pro IPv6-Adresse eine strikte Trennung des vom Provider zugewiesenen Präfixes von den Bestandteilen der Adresse, die für die interne Strukturierung des Netzes und unter Umständen auch für die Klassifizierung von Gerätetypen und für Sicherheitsregeln verwendet werden. Das providerspezifische Präfix kann sich ändern, ohne dass man die weiteren Bits antasten muss. Zum Beispiel kann man ein 48 Bit langes, vom Provider A zugewiesenes Präfix durch ein gleich langes (oder kürzeres, in diesem Fall bis zum 48. Bit beliebig auffüllbares) Präfix ersetzen, das von einem Provider B zugewiesen wird. (siehe Bild 4)

Dabei kann man die restlichen 80 Bits auf allen Endgeräten, Routern, Firewalls etc. unverändert lassen. Das Ersetzen des Präfixes beschränkt sich auf Änderungen an Systemen, auf denen das Präfix eingestellt wird. Im Falle der Nutzung des Dynamic Host Configuration Protocol (DHCP) sind dies die DHCP-Server, im Falle von Stateless Address Autoconfiguration (SLAAC) die Router. Ein Unterschied zu IPv4 besteht darin, dass es mit IPv6 realistisch wird, von jedem Provider eine auch für die interne Verwendung genügende Zahl von Adressen zu bekommen. Unter IPv4 kann man wegen der mittlerweile herrschenden akuten Adressknappheit bei einem Providerwechsel nie sicher sein, einen zusammenhängenden Adressblock durch einen anderen mindestens gleich großen ersetzen zu können.

Auch wenn beim Wechsel von einem zum anderen Provider nur das Providerpräfix von PA-Adressen geändert werden muss, kann das Vermeiden des damit verbundenen Aufwands und Betriebsrisikos eine Motivation für den Einsatz von PI-Adressen sein. Für global agierende Unternehmen sind PI- besser als PA-Adressen geeignet. Man stelle sich den Aufwand vor, der im globalen Netz eines Unternehmens entsteht, auch wenn sich nur in einer Region ein Präfix ändert. Möglicherweise muss auch einiges in anderen Regionen geändert werden. Auch wenn durch konsequente Nutzung des Domain Name System (DNS) alles außer der Einstellung des Präfixes selbst auf DHCP-Servern und Routern automatisch gehen sollte, sind zumindest die Planung des Wechsels und die entsprechenden Vorkehrungen gegen die damit verbundenen Risiken ziemlich aufwändig.

Woher bekommt man PI-Adressen? In der Regel sind die Regional Internet Registries (RIRs) für die Vergabe von PI-Adressen zuständig. Réseaux IP Européens (RIPE) ist die RIR für Europa. Andere Regionen wie Nordamerika, Lateinamerika, Afrika und Asien haben ihre eigenen RIRs. Für ein global agierendes Unternehmen stellt sich die Frage, ob es pro Region einen eigenen Adressbereich beantragt oder PI-Adressblöcke überregional einsetzt. Wenn das Unternehmen in einer Region einen eigenen Internet-Anschluss nutzt, müssen die dafür genutzten PI-Adressen im Internet geroutet werden. Es ist nicht selbstverständlich, dass Provider Adressen abweichend vom weltweiten regionalen Schema routen. Denn angesichts der potenziell sehr hohen Anzahl von IPv6-Netzen kann ein Provider anstreben, ganze Weltregionen jeweils über aggregierte Adressen zu erreichen. Wenn Abweichungen von diesem Schema zur Regel werden, können die Routing-Tabellen Dimensionen annehmen, die die heute für IPv4 eingesetzten Tabellen um Größenordnungen übertreffen.

Vor diesem Hintergrund besteht die zukunftssicherste Variante für ein global agierendes Unternehmen darin, jeden regionalen Internetanschluss mit Adressen aus der betreffenden Region zu betreiben (Bild 5). Dies erhöht zwar den Aufwand für die Beantragung von Adressen, stellt aber sicher, dass die Erreichbarkeit der Internetanschlüsse des Unternehmens nicht von der Routing-Politik der Provider abhängt. Ferner stehen dem Unternehmen mit mehreren regionalen Blöcken insgesamt mehr Adressen zur Verfügung.

Was die Größe der den Unternehmen zugewiesenen Adressblöcke betrifft, gibt es eine gute Nachricht. Unternehmen erhalten in der Regel maximal 48 Bits lange Präfixe. Zieht man von den verbliebenen 80 Bits den standardmäßig 64 langen Host Identifier ab, verbleiben zwischen dem zugewiesenen Präfix und dem Host Identifier 16 Bits. Diese 16 Bits ermöglichen die Bildung von 65536 Subnetzen. Der Luxus, eine solche Anzahl von Subnetzen jeweils mit einem Maximum von beispielsweise 256 Adressen bilden zu können, ist unter IPv4 nur wenigen Unternehmen vorenthalten, die Class-A-Adressen zur Verfügung haben. RIRs vergeben darüber hinaus auch größere Adressblöcke, d.h. kleinere Präfixe als /48, wenn das Unternehmen den Bedarf begründen kann. Je nach Branche, in der das Unternehmen tätig ist, sind verschiedene Szenarien denkbar, in denen der Bedarf an Adressen in den nächsten Jahren um Größenordnungen steigen kann. Im Produktionsbereich ist dieser Trend bereits seit Jahren feststellbar. Als vierte industrielle Revolution wird die Einführung des Internet of Things (IoT) in der Fertigung bezeichnet. Nicht nur die Produktionsmaschinen, sondern auch die Produkte sollen kommunikationsfähig werden. Kommunikation wurde dabei in den letzten Jahrzehnten immer mehr zur IP-Kommunikation.

Die interne Strukturierung des verfügbaren IPv6-Adressraums ist von der Größe des verfügbaren IPv6-Adressraums sowie der Anzahl und der Größe der Standorte des Unternehmens abhängig. Eine konsequentere Zusammenfassung von Subnetzen ist unter IPv6 möglich. Damit lassen sich die Routing-Tabellen mit den unhandlicheren IPv6-Adressen verkleinern.

Die interne Strukturierung des Adressraums kann nach rein geografischen Aspekten erfolgen. Ergänzend können einige Bits für eine Kodierung des Gerätetyps verwendet werden. Die Notwendigkeit der Kodierung von Gerätetypen wird nicht einheitlich bewertet. Einige Unternehmen gehen davon aus, dass die heute unterscheidbaren Gerätetypen langfristig nicht unbedingt Bestand haben werden. Aus dieser Ungewissheit leiten diese Unternehmen ab, dass eine Verwendung einiger Bits der IPv6-Adresse als Gerätecode nicht sinnvoll ist. Andere Unternehmen erwarten zum Beispiel eine dauerhafte Unterscheidung zwischen dem Client- und dem Server-Bereich. Ein Code, der die Unterscheidung zwischen Client und Servern auf sehr einfache Art ermöglicht, kann manche Sicherheitsregel übersichtlicher machen.

Festlegung der Methoden der Konfiguration von Hosts

Unter IPv6 ist DHCP nicht die einzige Methode für die automatische Zuweisung von Adressen. DHCP-Unterstützung ist nicht einmal zwingender Bestandteil des von Endgeräten zu unterstützenden IPv6-Funktionsumfangs. Dafür müssen alle Endgeräte SLAAC unterstützen.

Einige Unternehmen haben unter IPv4 die Vorteile der zentralen Verwaltung der Adressen schätzen gelernt. Diese Unternehmen legen Wert darauf, auch IPv6-Adressen in einer zentralen Datenbank zu dokumentieren. Gegen die 1:1-Übertragung der Methoden der Konfiguration der Endgeräte von IPv4 auf IPv6 spräche nichts, wenn alle Endgeräte die DHCP-Methode unterstützten. Dies ist leider nicht der Fall. Vor allem die Entwickler von Android sträuben sich immer noch gegen die Implementierung von DHCPv6 für Android. Da viele mobile Endgeräte auf Android basieren, müssen Unternehmen, die solche Endgeräte einsetzen, diese entweder manuell konfigurieren oder SLAAC einsetzen. Eine gemischte Adresszuweisung über DHCP und SLAAC im selben Subnetz ist nicht möglich, weil die Steuerung der Nutzung eines dieser Verfahren durch ein Endgerät anhand von Router Advertisments (RAs) erfolgt, die pro Subnetz die eine oder andere Methode vorgeben. (siehe Bild 6)

Die Nutzung von SLAAC ist mit oder ohne Security Extensions möglich. Ohne Security Extensions wird die MAC-Adresse eines Endgeräts als Teil des 64 Bits langen Host Identifier übernommen. Das Bewegungsprofil des Gerätes ist somit für alle seiner Kommunikationspartner sichtbar. Ein solches Bewegungsprofil verrät vielleicht mehr als von manchen Unternehmen toleriert werden kann. Security Extensions für SLAAC ermöglichen statt der Übernahme der MAC-Adresse die Nutzung wechselnder, nichts über das Gerät verratender Werte im Host Identifier.

IP-Adressen sind nicht die einzigen Parameter, die auf Geräten eingestellt werden müssen. Eine funktionierende IP-Konfiguration muss auf jeden Fall auch die Information enthalten, unter welcher oder welchen Adressen das Gerät den Domain Name Service erreichen kann. Je nach Funktionsumfang von Geräten ist die Einstellung der DNS-Adresse über DHCP oder über Informationen in RAs möglich. Alternativ können Geräte Anycast nutzen, um DNS zu erreichen.

Festlegungen der Methoden für die IPv6-Konfiguration von Endgeräten müssen die Besonderheiten der eingesetzten Endgeräte berücksichtigen.

Was ändert sich im LAN Design?

Da die Umstellung von IPv6 auf IPv4 nicht über Nacht, sondern möglichst im Zuge des normalen Lebenszyklus von Systemen und Applikationen erfolgen wird, ist mit einem langen Nebeneinander der beiden Protokolle zu rechnen. Diese Situation ist nicht unbekannt. Bis in die 1990er Jahre wurden Netze im Multiprotokollmodus betrieben. Neben IP gab es noch Systems Network Architecture (SNA) für die Kommunikation mit Großrechnern, Internetwork Packet Exchange (IPX) für den Zugriff auf Netware File Server des Herstellers Novell, DECnet von Digital Equipment Corporation und noch ein paar andere Protokolle, die mittlerweile fast in Vergessenheit geraten sind. Nach und nach stellten die Hersteller ihre Systeme auf IP um. Der Multiprotokollbetrieb wich dem einfacheren reinen IP-Betrieb.

Wenn nun IPv6 eingeführt wird, während IPv4 weiter zu nutzen ist, ersetzt der Modus mit zwei Protokollen die bisherige Monokultur mit IPv4. Zumindest die Netzkomponenten, vor allem die Routing-Instanzen, müssen auf den dualen Modus umgestellt werden. Auf Routern und Layer-3-Switches erfolgt dies dadurch, dass jede Netzschnittstelle neben der IPv4-
Adresse noch eine IPv6-Adresse erhält (siehe Bild 7). Zusätzlich müssen Routing-Mechanismen für IPv6 eingestellt werden.

Im internen Netz wird sich der Zuschnitt der Subnetze für IPv6 gegenüber dem für IPv4 dort ändern, wo IPv4-Adressknappheit Entscheidungen diktiert haben, die man mit mehr verfügbaren Adressen anders gefällt hätte. Solange aber die ersten reinen IPv6-Endgeräte auf sich warten lassen, wird es keine reinen IPv6-Subnetze geben. So muss das IPv6-Adresskonzept auf die bestehende Unterteilung in Subnetze abgebildet werden. Die Größe der IPv6-Subnetze wird sich auf jeden Fall gegenüber IPv4 ändern, denn kein IPv4-Subnetz stellt 64 Bits für die Endgeräteadressierung zur Verfügung. 64 Bits stehen nämlich unter IPv6 standardmäßig für Host-IDs zur Verfügung. Aber die Unternehmen werden schon aus Gründen der Sicherheit und Robustheit der Netze in der Regel die Zahl der Geräte pro Subnetz unter 1.000 halten.

Dort wo es keine Endgeräte gibt, zum Beispiel bei Links zwischen zwei Layer-3 Switches, kann man theoretisch auch die 64 Bits, die der Host-ID vorenthalten sind, für die Aufteilung in verschiedene Subnetze nutzen. Dies ist davon abhängig, ob die Layer-3-Switches eine solche Aufteilung unterstützen.

Theoretisch kann man auf Punkt-zu-Punkt-Verbindungen (P2P Links) zwischen zwei Routing-Instanzen auf routebare Adressen verzichten und LLAs einsetzen. Aber LLAs können von außerhalb eines Subnetzes nicht erreicht werden. Damit kann man zum Beispiel die Erreichbarkeit der beiden Enden eines P2P Links nicht über das Netz überprüfen. Deshalb ist es üblicher, wie unter IPv4 routebare IPv6-Adressen auch für P2P Links vorzusehen.

Auf den ersten Blick mag es als Verschwendung erscheinen, auf P2P Links ganze Subnetze mit bis zu 2**64 Adressen zu konfigurieren. Die eigentliche Frage muss aber lauten, wie viele Subnetze man einsparen würde, wenn man dies nicht täte. Das Beispiel in der Bild 8 soll der Klärung dieser Frage dienen.

Wenn man vereinfachend davon ausgeht, dass die Zahl der P2P Links zweimal so hoch ist wie die Zahl der Layer-3-Instanzen, kann man die Größenordnung der Anzahl der P2P Links berechnen. Bei Anwendung einer weiteren Vereinfachung könnte man für die Zahl der Layer-3-Instanzen 25 % der Zahl der Layer-2 Switches annehmen. Und wenn man annimmt, dass die Zahl der Layer-2 Switches gleich 10 % der Anzahl der Endgeräte ist, kann man die Zahl der P2P Links berechnen:

Zahl der P2P Links = 2 * 25 % * 10 % * Anzahl Endgeräte = 5 % * Anzahl Endgeräte

Wenn ein Subnetz durchschnittlich 10 Endgeräte aufnimmt, also die Anzahl der Endgerätesubnetze 10 % der Anzahl der Endgeräte beträgt, ist der Overhead der P2P-Subnetze wie folgt zu berechnen:

Overhead der P2P Links = 5 % * Anzahl Endgeräte / (10 % * Anzahl Endgeräte) = 50 %

Die P2P Links fügen also 50 % Overhead zur Anzahl der Subnetze hinzu. Das klingt viel, ist aber auf den zweiten Blick nur gleichbedeutend damit, dass man von den mindestens 16 Bits, die man zur internen Strukturierung zur Verfügung hat, ein Bit verliert. Dann hätte man sogar so viele Subnetze für P2P Links zur Verfügung wie für Endgeräte, also 100 % statt 50 %.
Der Vorteil, den man dadurch bekommt, ist die Verkleinerung der Anzahl der Einträge in Routing-Tabellen. Schon auf der ersten übergeordneten Layer-3-Instanz kann man nämlich alle Endgeräte- und P2P-Subnetze zusammenfassen und als aggregierte Route behandeln. Die lästigen Einträge für P2P Links, die schon unter IPv4 unangenehm auffallen, verschwinden.

Nun kann es auch Kompromisse geben, wieder vorausgesetzt, die Layer-3-Instanzen unterstützen längere Präfixes als /64. Man könnte zum Beispiel alle P2P Links an einem Standort zusammenfassen, und pro Standort erscheint in den Routing-Tabellen der WAN-Router eine zusätzliche Route für P2P Links. Der ganze Adressraum für P2P Links kann dann wesentlich kleiner sein als der für Endgeräte genutzte Adressraum.

Das im Vergleich zu IPv4 viel größere Reservoir an Adressen ist nicht der einzige Aspekt, unter dem Design-Unterschiede zwischen IPv4 und IPv6 denkbar sind. Man kann zum Beispiel auch darüber nachdenken, für IPv6 ein anderes Routing-Protokoll einzusetzen als für IPv4. Allerdings ist dies zumindest bei den Anwendern von OSPF (Open Shortest Path First) als dem de facto Standard für unternehmensinternes Routing nicht üblich. Da OSPF für IPv6 seit Jahren verfügbar und stabil ist, gibt es oft keinen Grund, verschiedene Routing-Protokolle für IPv4 und IPv6 einzusetzen. In der Regel setzt man zwei verschiedene Instanzen bzw. Prozesse desselben Routing-Protokolls für IPv4 und IPv6 ein. Die beiden Instanzen sind unabhängig voneinander und können auch unterschiedlich eingestellt werden, wenn es sein muss, zum Beispiel was die Metriken betrifft. Wenn es aber keinen zwingenden Grund für Abweichungen gibt, übernimmt man für IPv6 die Einstellungen unter IPv4.

Das gilt auch für das First Hop Redundancy Protocol (FHRP), das für die redundante Gestaltung von Routern in einem Subnetz verwendet wird. (siehe Bild 9)

Theoretisch können zwei redundante Router unabhängig voneinander RAs in Endgerätesubnetze senden, sodass jedes Endgerät beide Router kennt. Dann kann ein Endgerät von einem zum anderen Router wechseln, wenn ein Router nicht erreichbar ist. Aber die meisten Netzbetreiber wollen sich nicht auf Mechanismen der Endgeräte für die Realisierung von redundantem Routing verlassen. Das bleibt auch bei IPv6 so. Deshalb gibt es auch unter IPv6 die üblichen Mechanismen für die redundante Auslegung des First Hop für Endgeräte:

  • Virtuelle Switches: Zwei Layer-3-Switches bilden einen virtuellen Switch und stellen aus der Sicht der Endgeräte logisch eine Instanz dar bzw. sind über dieselbe MAC- und IP-Adresse erreichbar. Diese virtuellen Adressen werden automatisch vom zweiten Switch übernommen, wenn der erste ausfällt.
  • FHRP: Die beiden Layer-3-Switches sind unabhängig voneinander und haben auch eigene IP Interfaces pro Subnetz, aber als First Hop bzw. Default Router wird auf den Endgeräten eine Adresse eingestellt, die zu jedem Zeitpunkt von einem der beiden Router bedient wird. Fällt er aus, übernimmt der zweite die Adresse. Diese Umschaltung wird von einem FHRP gesteuert. Es gibt das standardisierte Virtual Router Redundancy Protocol (VRRP) und proprietäre FHRPs. Diese Protokolle sind für IPv6 ebenfalls nutzbar.

IPv6 Routing im WAN

Während LANs in der Regel exklusiv von einem Unternehmen genutzt werden und daher entsprechend dem Bedarf und den Präferenzen des Unternehmens konfiguriert werden können, gibt es im Wide Area Network (WAN) häufig eine Abhängigkeit vom WAN Provider. Bekanntlich bedienen WAN Provider verschiedene Kunden mit derselben Plattform. Diese Plattform muss sehr stabil und robust funktionieren, denn ein Ausfall würde alle mit der Plattform bedienten Kunden des Providers betreffen. Deshalb testen und verifizieren die WAN Provider jeden neuen Mechanismus eingehend und intensiv, bevor sie ihn einsetzen. Wenn die Einführung des Mechanismus den laufenden Betrieb auch nur kurzzeitig unterbrechen kann, dauert es lange, bis man einen geeigneten Zeitpunkt für die Änderung gefunden hat.

Dieser langen Test- und Integrationsphase geschuldet sind einige WAN Provider noch nicht so weit, dass sie zum Beispiel Multi-Protocol Label Switching wirklich im Modus „Multi-Protocol“ betreiben. Bis diese Provider neben IPv4 auch IPv6 über ihre MPLS-Plattform übertragen, kann noch einige Zeit vergehen.

Einem Kunden, der bei der Einführung von IPv6 nicht so lange warten will, bieten sich zwei Optionen:

  • Er nutzt weiterhin den IPv4 Routing Service des Providers. Dann muss IPv6 in IPv4 getunnelt werden. Die Tunnelendpunkte können zum Beispiel Router sein, die die entsprechende Tunnelfunktion unterstützen.
  • Er nutzt einen Layer 2 Service im WAN. Dann ist das Routing unabhängig vom Provider. Die Routing-Instanzen werden im dualen Modus vom Kunden betrieben.

In einem internationalen WAN kann die Beschränkung auf Layer 2 im WAN den Kreis der potenziellen Anbieter im Provider-Markt verkleinern. Herkömmlicher Routing Service auf MPLS-Basis ist immer noch der de facto Standard für internationale WANs.

Internet-Anbindung

Die Internet-Anbindung ist für viele Unternehmen der erste Bereich, der IPv6 unterstützen soll. Dies ist vor allem darauf zurückzuführen, dass sich IPv6 im Moment stärker im Internet als in internen Netzen ausbreitet. Die Internet-Anbindung soll die Kommunikation mit jedem Ziel im Internet ermöglichen. Eine Beschränkung auf IPv4 bei der Internet-Anbindung birgt nicht nur das Risiko, dass irgendwann in Zukunft einige externe Kommunikationsbeziehungen nicht möglich sind. Auch wenn heute jeder eingehende und jeder ausgehende Zugriff über das Internet IPv4 nutzen kann, verzichtet man mit einer eigenen IPv6-Anbindung auf alternative neue Wege und Übertragungspfade, die im Internet auf IPv6-Basis entstehen.

Ferner kann es für einige Unternehmen eine Frage des innovativen Images sein, auch unter IPv6 im Internet Präsenz zu zeigen.

Zunächst muss der Internet Service Provider IPv6-Übertragung unterstützen. Hier ist es ähnlich wie bei WAN-Providern: nicht alle sind so weit, dass sie IPv6 übertragen können. Hier helfen aber auch keine Workarounds wie Tunnels. Wenn man auf eine IPv6-Anbindung an das Internet Wert legt, muss man einen Provider finden, der dazu in der Lage ist.

Je nach IPv6-Adresskonzept übernimmt der Provider über das reine IPv6 Routing auch noch andere Aufgaben in diesem Zusammenhang. Er kann zum Beispiel als Sponsoring Local Internet Registry (LIR) agieren und die Einträge über die Zuordnung eines IPv6-Adressbereichs zum Unternehmen bei der zuständigen RIR pflegen. Wie bei IPv4 auch kann der ISP ferner der Inhaber des Autonomen Systems (AS) sein, über das der Internet-Zugang des Unternehmens geführt wird. Dies ist nicht zuletzt von der Art der Gestaltung der Internet-Anbindung abhängig. Legt ein Unternehmen darauf Wert, über zwei verschiedene ISPs mit dem Internet verbunden sein, besteht eine Option darin ein eigenes AS zu betreiben. Zwischen verschiedenen Autonomen Systemen im Internet wird bekanntlich das Border Gateway Protocol als Routing-Mechanismus verwendet. Das ist unter IPv6 nicht anders als unter IPv4, wie aus der Bild 11 hervorgeht.

Aber reines Routing macht noch keinen Internet-Zugang. Es ist noch zu entscheiden, welche Systeme über IPv6 extern kommunizieren. Hier ist zwischen eingehendem und ausgehendem Zugriff zu unterscheiden.

Für den ausgehenden Zugriff kann man zum Beispiel Web Proxies so konfigurieren, dass sie auch IPv6 nutzen. Gute Web Proxies erlauben die Einstellung von Richtlinien für den Umgang mit zwei Protokollen. Zum Beispiel kann es sinnvoll sein, in der ersten Phase IPv4 zu favorisieren und bei Verfügbarkeit von DNS-Einträgen für beide Protokolle (A Records für IPv4 und AAAA Records für IPv6) IPv4 vorzuziehen. Die Motivation für eine solche Richtlinie kann sein, eventuelle Probleme mit der IPv6-Erreichbarkeit des Zielsystems zu umgehen. Sind IPv6-Routen mittlerweile so stabil, dass man sie von Anfang an gegenüber IPv4 bevorzugt? Leider fällt die Antwort auf diese Frage so differenziert aus wie es denkbare Ziele im Internet gibt. Große Content-Anbieter wie Google haben schon seit Jahren Erfahrungen mit IPv6 und bieten eine weitgehend stabile IPv6-Präsenz. Das kann bei kleineren Anbietern ganz anders aussehen. Es mag sein, dass ein Anbieter über A und AAAA Records bekannt ist, aber noch Probleme mit IPv6 Routing im externen oder internen Netz hat. Hier kann nur die Praxis aufschlussreich sein. In den letzten Jahren haben uns immer weniger Berichte von instabilen IPv6-Routen erreicht.

Auf jeden Fall sollte ein Web Proxy die Möglichkeit unterstützen, bei Nichtverfügbarkeit der Verbindung über ein Protokoll auf das andere umzusteigen. Die Möglichkeit der Feineinstellung entsprechender Time-out-Werte wäre ebenfalls hilfreich.

Bei eingehenden Zugriffen stellt sich umgekehrt die Frage, ob man sowohl der eigenen internen Infrastruktur als auch der externen IPv6-Anbindung so weit vertraut, dass man unter Nutzung von IPv6 Inhalte im Internet präsentiert. Auch hier sind die in den Anfangsjahren hin und wieder vernehmbaren Berichte über nicht erreichbare Inhalte aufgrund instabiler IPv6-Routen einem Status gewichen, in dem man solche Berichte selten zu hören bekommt. Die interne Infrastruktur hat man ohnehin im eigenen Einflussbereich. Das reine IPv6 Routing ist mittlerweile als sehr stabil einzustufen. Problematisch können die Middleboxes werden: Firewalls, Reverse Proxies und Load Balancer. Und am Ende der Kette steht noch ein Endsystem mit einer Anwendung, zum Beispiel ein Web Server, wie in der Bild 12 dargestellt.

Die einfachste Lösung ist eine Translation-Lösung direkt am Internet-Übergang. Dabei werden alle eingehenden IPv6-Verbindungen über das Internet auf einem Gerät, das NAT64 (NAT zwischen IPv6 und IPv4) unterstützt, terminiert und intern als IPv4-Verbindung neu aufgebaut. In weiteren Schritten kann man IPv6 tiefer in das interne Netz hereinlassen. Wann und wie weit, ist davon abhängig, ob die betreffenden Middleboxes unter IPv6 dieselben Funktionen unterstützen wie unter IPv4, und ob sie im dualen Modus stabil und ohne unangenehme Nebenwirkungen betreibbar sind.

Interessant könnte die IPv6-Präsenz im Internet für Virtual Private Networks werden. Mein Kollege Dr. Wetzlar berichtete mir vor Jahren von einem Hotel in der Schweiz, in dem der IPv6-Zugang zum Internet kostenlos und der IPv4-Zugang kostenpflichtig ist. Auf solche Ideen können Provider kommen, wenn sie an der zunehmenden Verlagerung des Verkehrs von IPv4 auf IPv6 interessiert sind.

Nicht nur solche Promotion-Angebote der Provider, sondern auch die Vermeidung von NAT in Providernetzen kann eine Motivation dafür sein, über IPv6 auf das VPN des eigenen Unternehmens zuzugreifen. Voraussetzung ist natürlich die Verfügbarkeit eines IPv6-Zugangs. Ist ein solcher vorhanden, kann man davon ausgehen, dass man ohne NAT bis zum VPN durchkommt. Das kann unter Umständen schneller und leistungsfähiger sein als der IPv4-Weg, der vielleicht Carrier-Grade NAT beim Provider durchläuft.

Eine andere Frage als das im Internet genutzte Medium ist, ob man im VPN-Tunnel IPv4 oder IPv6 überträgt. Das ist von der IPv6-Ertüchtigung der Endgeräte und Systeme auf beiden Seiten abhängig. Es ist erwägenswert, mit der Client-Seite anzufangen und auf dem Client die duale Protokollunterstützung einzuführen. Handelt es sich beim Betriebssystem auf dem Client um eine aktuelle Windows-Version, braucht man nur über den VPN-Tunnel (bei Client-to-Site) oder mittels der Layer-3-Instanzen am Client-Standort (bei Site-to-Site) dem Client die IPv6-Konfiguration zu vermitteln. Dann kann der Client über IPv6 auf jede interne Anwendung und jedes interne System zugreifen, das mit der Zeit verfügbar wird. Nur nach getesteter Verfügbarkeit eines solchen IPv6-Weges sollte auch ein entsprechender Eintrag im DNS angelegt werden, denn sonst läuft der Verbindungsversuch des Clients ins Leere.

Besonderheiten bei Extranets

Einige Unternehmen nutzen neben dem Internet und dem internen Netz noch Extranets. Ein Extranet ist ein nichtöffentliches Netz, das verschiedene Organisationen miteinander verbindet. Es gibt verschiedene Ausprägungen von Extranets. Eine Ausprägung kann vorsehen, dass Systeme des Unternehmens A nie direkt mit Systemen des Unternehmens B kommunizieren, sondern nur über ein bestimmtes System C, das zum Beispiel eine Collaboration Suite bereitstellt. Eine andere Ausprägung kann den direkten Zugriff der Systeme eines Unternehmens auf die Systeme eines anderen Unternehmens vorsehen.

In beiden Fällen ist das IP Routing zu klären. Zwei Unternehmen können zum Beispiel vereinbaren, dass ein gemeinsam genutztes System mit einer Adresse konfiguriert wird, die mit keiner internen Adresse in den beiden Unternehmensnetzen kollidiert. Das ist bei IPv6 einfacher als bei IPv4, weil IPv6 viel mehr Adressen zur Verfügung stellt. Prinzipiell kann sowohl bei IPv4 als auch bei IPv6 eine private wie eine öffentliche Adresse dem gemeinsam genutzten System zugeordnet werden. Im ersten Fall muss die private Adresse so gewählt werden, dass sie in keinem der beiden internen Netze genutzt wird.

Sollen Systeme in den beiden internen Netzen direkt miteinander kommunizieren, stellt sich die Frage, wie tief in das eigene interne Netz die Route zum fremden Netz bekannt gegeben wird. Die einfachste Lösung ist die Nutzung der Default-Route, die es sowohl bei IPv4 als auch bei IPv6 geben kann. Da aber die Default-Route eventuell auch für Ziele im Internet verwendet wird, muss es mindestens ein System geben, das die IP-Adressen des Partnerunternehmens kennt und Pakete an diese Adressen nicht zum Internet, sondern zum Extranet weiter leitet. Wichtig ist auf jeden Fall, dass dies koordiniert passiert. Sendet Organisation A die an Organisation B gerichteten Pakete über das Extranet, darf B die An A gerichteten Pakete nicht über das Internet routen. Denn sonst können Firewalls, die es im Übertragungspfad zwischen zwei Organisationen höchstwahrscheinlich geben wird, mit den Paketen nichts anfangen. Firewalls, die stateful arbeiten, führen Informationen über den Status einer Verbindung. Eine solche Firewall blockiert alle Pakete von Verbindungen, deren Aufbau sie nicht vollständig kennt. (siehe Bild 13)

Komplexer wird es, wenn das Extranet nicht zwei, sondern mehrere Unternehmen miteinander verbindet. Die Koordination mit dem Ziel, das bei jeder Kommunikationsbeziehung die Pakete in beiden Richtungen über dasselbe Extranet gesendet werden, muss dann immer zwischen zwei Unternehmen erfolgen, die das Extranet für die Kommunikation nutzen wollen. Eine andere Möglichkeit besteht darin, dass ein zentraler Koordinator die Liste der über das Extranet erreichbaren Routen pflegt. Jedes Unternehmen, das eines der eigenen Systeme über das Extranet erreichbar machen will, teilt die IP-Adresse des Systems dem zentralen Koordinator mit, der die Adresse im Extranet routet.

IPv6 bedeutet eine große Erleichterung der Kooperation zwischen verschiedenen Unternehmen. Unter IPv4 wird es bei steigender Anzahl der Extranet-Teilnehmer schwieriger, ohne NAT auszukommen, denn die meisten Unternehmen belegen intern denselben privaten Adressraum (in der Regel 10.0.0.0/8) vollständig. Unter IPv6 braucht man nur die Festlegung, dass die unternehmensübergreifende Kommunikation unter Nutzung von GAs erfolgt. Selbst wenn es im Verbund Unternehmen gibt, die ULAs verwenden, kann der zentrale Koordinator dafür sorgen, dass es zu keiner Adresskollision kommt. Es ist ohnehin ratsam, dass jedes Unternehmen, das ULAs nutzen möchte, unter Nutzung von https://www.sixxs.net/tools/grh/ula/ den eigenen ULA-Bereich registriert. Wenn alle Kooperationspartner diesen Schritt durchgeführt haben, kommt es zu keiner Kollision.

Was sich in Sachen Security ändert

Auch wenn viele Mechanismen unter IPv4 und IPv6 ähnlich sind, weisen die beiden Protokolle Unterschiede auf, die zum Teil sicherheitsrelevant sind.

Ein Sicherheitsaspekt betrifft die Konfiguration von Endgeräten. Hier gibt es eine gemeinsame Schwachstelle von IPv4 und IPv6. In der Regel wird DHCP nicht kryptografisch abgesichert. So ist es möglich, dass ein Angreifer mit direktem oder indirektem Zugriff auf ein IP-Subnetz DHCP missbraucht, um die Konfiguration von Endgeräten zu manipulieren. Eine solche Manipulation kann dem Ziel dienen, einen Man-in-the-Middle(MitM)-Angriff durchzuführen. Der MitM kann zum Beispiel sämtliche Kommunikation eines Endgeräts aufzeichnen.

Einige Layer-2 Switches bieten sowohl unter IPv4 als auch IPv6 Sicherheitsmechanismen gegen solche Spoofing-Attacken. Ein Switch kann so eingestellt werden, dass DHCP Responses nur dann weiter geleitet werden, wenn sie über bestimmte Schnittstellen empfangen werden. Typischerweise sind das die Uplinks des Switches.

Bei IPv6 kommt die Möglichkeit hinzu, Endgeräte über RAs und SLAAC zu konfigurieren. Hier können ähnliche Mechanismen greifen. Ein Layer-2 Switch kann so eingestellt werden, dass nur RAs weiter geleitet werden, die über bestimmte Ports empfangen worden sind. (siehe Bild 14)

Im Zusammenhang mit SLAAC wurden in diesem Beitrag die Security Extensions bereits erwähnt. Ihre Einschaltung nimmt nicht nur Angreifern die Möglichkeit, Geräte an deren IP-Adressen leicht zu erkennen. Insbesondere in drahtlosen Netzen, wo Endgeräte nicht mit Switch-Ports verbunden und daran zu erkennen sind, schwirren dann Pakete herum, deren IP-Adressen keinen Aufschluss über die Identität des Gerätes zulassen.

Wenn ein Gerät, das mangels DHCP-Aktivierung in einem Subnetz SLAAC nutzen muss, zwischen dem internen und öffentlichen Netzen wechselt, empfiehlt sich, SLAAC Security Extensions zu nutzen. Dann muss man den Verzicht auf einen Teil der Tracking- und Trace-Möglichkeit im internen Netz in Kauf nehmen.

Erfahrungen austauschen

Die Fortsetzung der Erläuterung der richtigen IPv6-Fundamente würde den Rahmen dieses Beitrages sprengen. Es ist wichtig, dass es bei der Einführung von IPv6 zum Erfahrungsaustausch zwischen Unternehmen kommt. ComConsult leistet dazu ihren Beitrag auf dem diesjährigen Netzwerk- und IT-Infrastruktur Forum. Wir freuen uns auf die Diskussion mit Ihnen!

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.