OpenStack und das Internet Protocol Version 6

Ist OpenStack ready für IPv6?

| Autor / Redakteur: Nicholas Chase / Andreas Donner

Die Openstack Open Source Cloud-Mission lautet, eine allgegenwärtige Open Source Cloud-Computing-Plattform bereitzustellen, die den Bedürfnissen von öffentlichen und privaten Clouds unabhängig von deren Größe gerecht wird, und dabei einfach zu implementieren bleibt und enorm skalierbar ist.
Die Openstack Open Source Cloud-Mission lautet, eine allgegenwärtige Open Source Cloud-Computing-Plattform bereitzustellen, die den Bedürfnissen von öffentlichen und privaten Clouds unabhängig von deren Größe gerecht wird, und dabei einfach zu implementieren bleibt und enorm skalierbar ist. (Bild: OpenStack.org)

Eine der wichtigsten Ergänzungen der kommenden OpenStack-Version, Juno, ist der IPv6-Support bei OpenStack Networking (Neutron). Doch wie vollständig ist er?

Als IPv4 1981 eingeführt wurde, nahm man an, dass seine fast 4,3 Milliarden potenziellen Adressen für die absehbare Zukunft ausreichend sein würden, insbesondere da es nur dazu gedacht war, die Netzwerkkonzepte von DARPA zu testen. Doch die explosionsartige Entwicklung bei den internetfähigen Geräten – insbesondere bei den Smartphones – und die ineffiziente Art und Weise der Adresszuweisung belasteten schnell das System.

Trotz Notfallmaßnahmen, wie Network Address Translation (NAT) und Classless InterDomain Routing (CIDR) wurde der letzte Block mit 16 Millionen Top-Level IPv4- Adressen bereits am 3. Februar 2011 vergeben. Mit dem nun in naher Zukunft hinzutretenden Internet of Things ist eine langfristige Lösung erforderlich.

IPv6 wurde 1998 von der Internet Engineering Task Force (IETF) entwickelt und nutzt 128-Bit-Adressen, wodurch es 3,4×1038 Adressen liefert. Mit IPv6 kommen zudem Vorteile, wie automatisches Host-Addressing und leichtere Neunummerierung des Netzwerks. „IPv6 ist keine Funktion”, sagt Sean Collins, Senior Software Engineer bei Comcast und Leiter des OpenStack IPv6 Sub-Teams, „es ist eine überlebensnotwendige Voraussetzung. Es gibt keine IPv4-Adressen mehr und alle unsere Produkte benötigen es.“

Der Unterschied zwischen IPv4 und IPv6

IPv4-Adressen bestehen aus 32 Bits, üblicherweise in vier Oktetten ausgedrückt, wie z.B. 192.168.0.1 oder 10.28.255.168. Die ersten drei Werte bezeichnen das Subnetz, das vom Netzwerkadministrator oder -anbieter eingerichtet wird und die letzte Zahl stellt den Host selbst dar. IPv6 Adressen jedoch bestehen aus acht hexadezimalen Werten, wie 2001:0db8:85a3:0042:1000:8a2e:0370:7334. Die ersten vier Werte stellen das Subnetz dar, das vom Netzwerkadministrator eingerichtet oder über “Routing Advertisement Messages” von vorgeschalteten Routern empfangen werden kann. Die letzten vier stellen den Host dar.

Abgesehen vom Format der Adressen ist der vielleicht signifikanteste Unterschied zwischen IPv4 und IPv6 (was OpenStack betrifft) die Art und Weise der Adressenzuweisung. IPv4 baut in hohem Maße auf das Dynamic Host Configuration Protocol (DHCP) auf, das einem neuen Host ermöglicht, eine Anfrage nach einer neuen Adresse einfach an das Netzwerk zu senden. Der DHCP-Server liefert eine Adresse sowie Informationen über die DNS-Server und andere Netzwerkinformationen.

In IPv6 können Adressen auf drei verschiedenen Wegen zugewiesen werden:

  • StateLess Address AutoConfiguration (SLAAC): In einer IPv6-Installation können sich Einheiten mithilfe von SLAAC selbst konfigurieren, indem sie die bereitgestellte Subnetz-Adresse nehmen, mit einer aus ihrer MAC-ID konstruierten Host-ID kombinieren und dann prüfen, ob diese Adresse bereits in Gebrauch ist, um die Einzigartigkeit zu bestimmen.
  • Zustandsabhängige DHCPv6: In einer zustandsabhängigen Konfiguration wird das Subnetz vom Administrator eingerichtet und die Host-Adressen werden, genau wie bei einer IPv4-Installation, vom DHCP-Server verwahrt, verfolgt und zugewiesen.
  • Zustandsunabhängige DHCPv6: In einer zustandsunabhängigen Konfiguration wird das Subnetz entweder vom Administrator eingerichtet oder über Routing Advertisement-Nachrichten empfangen und die Host-Adresse wird mithilfe der gleichen Kalkulation berechnet, wie sie sich unter Verwendung von SLAAC ergeben hätte.

OpenStack verfügt eigentlich über zwei verschiedene Netzwerkdienste. Grundlegende Vernetzung kann mithilfe von OpenStacks „Alt“-Netzwerksystem (nova-network) erreicht werden; komplexere Software Defined Networking (SDN)-Aufgaben erfordern das neuere OpenStack Networking (Neutron). Beide unterstützen IPv6 in beschränktem Maße.

Wie OpenStack IPv6 ausführt

Die grundlegendste Aufgabe für OpenStack ist, was IPv6 betrifft, die Zuweisung von IP-Adressen. IPv6 ermöglicht es, dass Hosts ihre eigenen Adressen und ihre eigenen MAC-IDs aus einer Subnetz-Adresse erstellen. Dies gehört zur einfachsten Situation einer Konfiguration bei der externe Hardware, wie vorgeschaltete Router, die Subnetz-Adresse über Routing Advertisement liefert. In dieser Situation arbeitet der Administrator das VLAN zum Anbieter-Netzwerk aus, die Instanz übernimmt das Routing Advertisement und nutzt dann das Subnetz zur Erstellung seiner IP-Adresse.

Ab Icehouse, der aktuellen OpenStack-Version, wird dieses Szenario sowohl im Nova- als auch im Neutron-Netzwerk unterstützt. Neutron bietet zusätzlich die Fähigkeit, Routing Advertisements und Adressierungsmethoden mit separaten Parametern für den ipv6_ra_mode und ipv6_address-Modus zu trennen. Die Schwierigkeit bei dieser Anordnung ist die Tatsache, dass das Subnetz von außerhalb von OpenStack kommt. Was, wenn kein vorgegebenes Provider-Netzwerk, stattdessen aber ein L3-Agent mit IPv6-Routing genutzt werden soll?

Zum Zeitpunkt der Abfassung dieses Beitrags stand die Fähigkeit, sowohl zustandsunabhängige als auch zustandsabhängiges DHCPv6 nutzen zu können, bei Neutron kurz bevor und wird in OpenStacks kommender Version, Juno, verfügbar sein. So unterstützt OpenStack, was die grundlegende Adressierung angeht, IPv6. Aber das ist noch nicht das Ende vom Lied.

Was OpenStack noch braucht

Was bleibt noch, jetzt, da OpenStack IPv6-Adressierung für Instanzen unterstützt? OpenStack besteht aus mehreren Projekten: so besteht der erste Schritt darin, sicherzustellen, dass der IPv6-Support auf Instanzenebene vollständig und in allen Instanzen bestätigt ist, insbesondere in Hinblick auf die neue Distributed-Virtual-Router-Funktion (DVR).

Dann ist es Zeit, sich auf die Netzwerk-Ebene hochzuarbeiten. Damit Neutron IPv6 wirklich unterstützt, muss der L3 Netzwerk-Agent wiederum mehrere Netzwerk-Präfixe unterstützen. Diese Funktion ist für die Arbeit während des Kilo-Zyklus‘ geplant. Während des Kilo-Releases (für April 2015 erwartet) sollte auch die Einführung der Präfix-Delegation stattfinden. Dies bedeutet, dass der Provider statt einer /128-Adresse eine einzige 128-Bit Hostadresse und einen /64-Bit-Wert zuweist. Dieser 64-Bit-Wert ist die Subnetz-Adresse und kann als Subnetz-Präfix für alle Geräte innerhalb eines internen Netzwerks verwendet werden.

Sobald diese Funktion gegeben ist, kann eine der am meisten frustrierenden Aufgaben bei der Nutzung des OpenStack-Netzwerks eliminiert werden: das Herausarbeiten des Subnetzes, das bei der Erstellung eines neuen Netzwerks zu verwenden ist. Statt einen IP-Administrator zu kontaktieren, um herauszufinden, welche Subnetze zur Verfügung stehen, können Nutzer einfach ein Netzwerk-Präfix anfragen und loslegen. Die Präfix-Delegation wird auch echte „geroutete“ Virtual Private Clouds ermöglichen, in denen mehrere Maschinen an verschiedenen Standorten zu einer einzigen Cloud verbunden werden können.

Die letzte fehlende Funktion ist etwas, was nicht OpenStack-spezifisch ist. Aufgrund der fehlenden Interoperabilität zwischen IPv4 und IPv6 kommt es nicht selten vor, dass ein Netzwerk, das intern IPv6 unterstützt, diese Adressierung außerhalb des Netzwerks nicht zur Verfügung stellt. Mit anderen Worten, es handelt sich um ein Netzwerk, das intern voll funktionsfähig und routingfähig aber isoliert ist. Jeder Internetzugriff wird noch von IPv4 abgewickelt.

Zurzeit ist es ebenso möglich, eine OpenStack Cloud mit externer Hardware über IPv6 mit dem Internet zu verbinden, wie es möglich ist, ein Provider-Netzwerk zu nutzen, um ein Subnetz zu erhalten; die Schwierigkeit dieses Prozesses hängt davon ab, wie viele Abschnitte zwischen der Cloud und der entsprechenden Hardware existieren. Um diese Fähigkeit in OpenStack selbst zu ermöglichen, müssten Border Gateway Protocols (BGP) in SDN oder Network Function Virtualization (VFV) eingeführt werden, um der Welt Subnetz-Präfixe zu vermelden. Diese Funktion existierte zum Zeitpunkt dieses Berichts nicht, ist aber für die Juno-Version geplant.

Zusammenfassung

OpenStack verfügt noch nicht über den vollen Support für alle IPv6-Dienste, ist aber auf einem guten Weg. „Die Arbeit im IPv6-Subteam diente dazu sicherzustellen, dass Neutron eine in Zukunft praktikable Netzwerk-Plattform ist“, sagt Collins. Es gibt noch viel Arbeit, um IPv6 auf die Ebene zu heben, auf der es von Software Defined Netzworking verwendet werden kann, doch bereits heute, mit der Oktober-Version von Juno, ermöglicht OpenStack die Verwendung von IPv6 auf der Instanzenebene und bietet so den Support, den die meisten Unternehmen brauchen.

Über den Autor

Nicholas Chase ist Technical Marketing Manager bei Mirantis.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43000419 / TCP / IP)