===== IPv6 an der RUB ===== Ab sofort ist IPv6 an der RUB flächendeckend verfügbar. Bereits seit 2012 erproben wir das neue Internetprotokoll im ''eduroam'' sowie in einigen Server- und Client-Netzen. Die Internetanbindungen der RUB sowie die eingesetzte Hard- und Software im Bereich des Datennetzes und der Netzverwaltung sind inzwischen IPv6-fähig. Wir möchten an dieser Stelle Netzbetreuern und anderen interessierten Personen einige Informationen an die Hand geben, die den Einstieg erleichtern sollen. ====Aktuelle Jahresstatistiken:==== ===Folgende Grafik zeigt das Verhältnis von IPv4- zu IPv6-Verkehr von/zum Internet:=== {{https://monitor.noc.ruhr-uni-bochum.de/cgi-bin/proxygraph.cgi?what=ipv4_ipv6&range=800day&size=dokuwiki&.png?}} ===Folgende Grafik zeigt nur den IPv6-Verkehr von/zum Internet:=== {{https://monitor.noc.ruhr-uni-bochum.de/cgi-bin/proxygraph.cgi?what=ipv6&range=800day&size=dokuwiki&.png?}} Deutlich zu erkennen ist hier in Etwa eine Verdopplung des IPv6-Traffics pro Jahr, wobei der IPv4-Traffic fast stabil bleibt ~~(Die Reduzierung des IPv4-Traffics Anfang 2017 um 50% beruht auf der Tatsache, dass wir von Januar bis August 2017 den Wohnheim-Traffic nicht mit gezählt haben)~~. An den Wochenenden ist im Allgemeinen weniger Datenverkehr, daher die regelmäßigen Einbrüche. [EDIT 14.08.2020]: Mittlerweile sind die obigen Graphen nicht mehr aussagekräftig weil unser Monitoringsystem aktuell nicht in der Lage ist, den kompletten Traffic zu analysieren. Der Inhalt des Textes stimmt zwar nach wie vor (Verdopplung des IPv6-Traffics pro Jahr), die Grafiken aber nicht. ==== Allgemeines ==== Seit Anfang 2015 werden neue Subnetze im Datennetz der RUB standardmäßig zusätzlich mit IPv6 ausgestattet. Das bedeutet, dass Computer in diesen Subnetzen IPv4- und IPv6-Adressen bekommen sowie diese im Internet auch direkt erreichen können. Das ist erforderlich um -- kurz gesagt -- für die Zukunft gerüstet zu sein. Es gibt inzwischen die ersten Teile des Internets, die mit den an der RUB bisher ausschließlich vergebenen IPv4-Adressen nicht oder zumindest nicht zuverlässig erreichbar sind. Um weiterhin eine bestmögliche Anbindung ans Internet zu erhalten, ist es daher nötig IPv6 einzuführen. Die Einführung geschieht parallel zu den bereits vorhandenen IPv4-Adressen, d.h. es ist in der Regel so, dass an das Netzwerk angeschlossene Geräte sowohl eine IPv4- als auch eine IPv6-Adresse erhalten. Denn Kommunikation zwischen IPv4 und IPv6 ist (ohne "Übersetzer") nicht möglich. Man benötigt also vorerst beides. === ACLs === Es werden zwei ACLs -- eine wie bisher für IPv4 und eine weitere für IPv6 -- benötigt. Da es sich bei IPv4 und IPv6 um vollkommen verschiedene Protokolle handelt, ist die Verarbeitung in der selben ACL nicht möglich. Jedoch unterscheidet sich die ACL-Syntax nicht signifikant von der bereits für IPv4-ACLs bekannten, so dass an dieser Stelle der Einstieg leicht fallen wird. ==== Aufbau von IPv6-Adressen ==== === Schreibweise === IPv6-Adressen sind 128 bit lang und daher erheblich länger als IPv4-Adressen, die lediglich 32-bit lang sind. IPv4-Adressen werden in durch einen Punkt getrennten 8-Bit-Teilen dezimal notiert. IPv6-Adressen werden hingegen hexadezimal notiert, wobei jeweils 16 Bit zusammengefasst und durch einen Doppelpunkt getrennt werden, z.B.: 2001:0db8:0003:1600:0000:0000:0b43:00f6 Die Adressen können mit folgenden Regeln abgekürzt werden: * __Ein__ Bereich, der lediglich aus Nullen besteht, kann komplett ausgespart und durch ''::'' notiert werden * Führende Nullen können pro Block weg gelassen werden Abgekürzt wäre die o.g. IPv6-Adresse also: 2001:db8:3:1600::b43:f6 Das lässt sich immerhin schon wesentlich einfacher lesen und nach ein bisschen Eingewöhnungszeit auch irgendwie merken. === Subnetze / Präfixe === IPv6-Subnetze werden durch Notation der Netzadresse sowie Anhängen der Präfix-Länge mit einem Schrägstrich notiert, z.B.: 2001:0db8:0003:1600:0000:0000:0000:0000/64 Abgekürzt ist es wieder viel einfacher: 2001:db8:3:1600::/64 Das bedeutet, dass das Subnetz ein Präfix von 64 Bit (/64) hat, also die beschriebenen 64 Bit (''2001:db8:3:1600::'') feststehen und das Subnetz beschreiben. Alle Bits dahinter können im Subnetz als Adressen vergeben werden. Das entspricht in diesem Fall weiteren ''128-64=64'' Bits. === Stateless Address Autoconfiguration (SLAAC) === IPv6-fähige Geräte geben sich ihre IPv6-Adresse in der Regel selbst, indem sie die sogenannte //Stateless Address Autoconfiguration// ([[http://tools.ietf.org/html/rfc4862|RFC4862]]) durchführen. Das Verfahren ist wie folgt: Es wird die MAC-Adresse (48 Bits) der Netzwerkkarte genommen, in der Mitte wird hexadezimal ''fffe'' (16 Bits) eingefügt und anschließend wird das //Universal/Local Bit// gesetzt. Das ist das zweite der niederwertigen (low-order) Bits des ersten Bytes der MAC-Adresse. Aus ''00'' wird also ''02''. Das Ergebnis sind 64 Bits, deren Eindeutigkeit dadurch gesichert ist, dass sich die MAC-Adresse der Netzwerkkarte darin befindet. Aus der MAC-Adresse 00:11:22:33:44:55 (bzw. 0011.2233.4455 bzw. 001122334455) wird also folgender //Interface Identifier//: 0211:22ff:fe33:4455 Diesen 64 Bits wird das vom Router per Multicast ausgesendete Präfix voran gestellt, um die IPv6-Adresse auf 128 Bits zu komplettieren: 2001:db8:1:1000:211:22ff:fe33:4455 === Link-Local-Adressen === Der per SLAAC erzeugte Interface Identifier wird auch dazu benutzt, eine sogenannte //Link Local Address// auf dem Interface zu binden. Dazu wird das entsprechende Präfix ''fe80::'' voran gestellt: fe80::211:22ff:fe33:4455 Die Link Local Address funktioniert -- ähnlich wie die bereits von IPv4 bekannten APIPA-Adressen (169.254.x.y) -- nur auf dem Link, d.h. im lokalen Netz (Vlan), in dem sich das Gerät aktuell befindet. === IPv6 Privacy Extensions === Es könnte (aus Netzbetreuer-Sicht) alles so einfach sein, wenn nicht die Privatsphäre wäre. Im Allgemeinen wird es nämlich für problematisch gehalten, dass der Interface-Part (rechte Hälfte) einer per SLAAC automatisch zugewiesenen IPv6-Adresse weltweit eindeutig ist, durch das Vorkommen der MAC-Adresse. Zum Schutz der Privatsphäre gibt es daher die //IPv6 Privacy Extensions// ([[http://tools.ietf.org/html/rfc4941|RFC4941]]). Sie definieren, dass die global gültige IPv6-Adresse auf einem Interface sich regelmäßig (auf den meisten Betriebssystemen alle 2 Stunden) ändert, indem der Interface-Part per Zufall neu generiert wird. Das hat zur Folge, dass es schwierig wird, anhand der Absender-Adresse (z.B. in Webserver-Logs) auf das Gerät zu schließen, von dem aus die Anfrage kam. === Duplicate Address Detection === Im Anschluss an die SLAAC oder die Neugenerierung einer IPv6-Adresse folgt immer eine //Duplicate Address Detection// (DAD, [[http://tools.ietf.org/html/rfc4429|RFC4429]]), mit dessen Hilfe die Eindeutigkeit der IPv6-Adresse auf dem Link, d.h. im Vlan, gesichert wird. Dazu fragt das Gerät mit der neuen IPv6-Adresse per //Neighbor Discovery Protocol// (NDP, [[http://tools.ietf.org/html/rfc4861|RFC4861]]; das, was ARP für IPv4 ist) nach, ob jemand die eigene Adresse hat. Kommt nach zwei Sekunden keine Antwort, wird davon ausgegangen, dass die Adresse frei ist und sie wird dann benutzt. Anderenfalls ist das Verhalten undefiniert. ==== Vergabe von Subnetzen ==== Bei der Vergabe von IPv6-Subnetzen unterscheiden wir grundsätzlich zwischen zwei Arten von Subnetzen: In Client-Vlans werden wir -- falls nicht anders gewünscht -- Router Advertisements senden, so dass die Geräte über den //Stateless Address Autoconfiguration// (SLAAC) Mechanismus ihre IPv6-Konfiguration (IPv6-Adresse und Router-Adresse) in der Regel automatisch erhalten. Hilfsweise wird hierzu noch ein sogenannter //Stateless// DHCPv6-Service benutzt, um die restlichen nötigen Informationen (Nameserver, Zeitserver, DNS-Domain) zur Verfügung zu stellen. In für Server vorgesehenen Subnetzen werden wir keine Router Advertisements senden, so dass SLAAC nicht funktioniert und Server daher von Hand mit der IPv6-Konfiguration ausgestattet werden müssen. Es sei denn, Sie wünschen sich etwas anderes. === Reverse-DNS === Alle IPv6-Adressen an der RUB lassen sich rückwärts in etwas auflösen, das mit ''.ipv6.ruhr-uni-bochum.de'' endet, sofern nicht anderweitig für einen DNS-Eintrag (AAAA-Record) gesorgt wird. Es ist also nicht unbedingt nötig, Reverse-DNS-Einträge für Clients zu pflegen. Für Server hingegen ist auch ein regulärer DNS-Eintrag wichtig, damit man sie unter ihrem Namen per IPv6 erreichen kann. Die Erzeugung von Reverse-DNS Einträgen (PTR-Records) erfolgt in der Regel automatisch, so wie es für IPv4 seit Jahren der Fall ist. ==== Eigene Router / Transfernetze ==== Für den Betrieb von eigenen Routern sind nach wie vor Transfernetze erforderlich. Um IPv6 hinter einem eigenen Router nutzen zu können, benötigen Sie zusätzlich zum eventuell bereits vorhandenen IPv4-Transfernetz auch ein IPv6-Transfernetz. IPv6-Transfernetze bekommen ganz reguläre /64-Präfixe, wobei in der Regel die erste Adresse unserem Router gehört, die zweite Adresse dem eigenen Router, z.B.: 2001:db8:1:10::/64 (<-- Transfernetz) 2001:db8:1:10::1 (<-- RUB-Router; Gateway für eigenen Router) 2001:db8:1:10::2 (<-- Eigener Router; unser Ziel für statische Routen) Alle weiteren Adressen des Transfernetzes bleiben ungenutzt und sind auch in der Regel nicht nutzbar. Wir routen dann -- je nach Bedarf -- ein /56-Präfix (= 256 Subnetze) oder kleiner (/57, /58, ... /64) aus dem /52-Präfix der entsprechenden Einrichtung statisch auf die entsprechende Adresse im Transfernetz. ==== Adressierungsplan der RUB ==== In der RUB werden wir in der Regel mit folgenden Präfix-Längen auskommen: ^ Präfix ^ Einsatzzweck ^ Größe ^ | /44 | In der RUB momentan zur Verfügung stehender Adressraum | 16 PoPs bzw. Router | | /48 | Pro PoP (Gebäude bzw. Router) zur Verfügung stehender Adressraum | 16 Einrichtungen | | /52 | Pro Einrichtung (Fakultät o.ä.) zur Verfügung stehender Adressraum | 4096 Subnetze | | /64 | Pro Subnetz / Vlan / Transfernetz | 1,844674407×10¹⁹ IPv6-Adressen | Folgender Adressraum wird momentan in der RUB verwendet: 2a05:3e00::/44 Daraus wird jedem PoP (Router) ein /48-Präfix zugewiesen, also: 2a05:3e00::/48 (bzw. 2a05:3e00:0::/48) 2a05:3e00:1::/48 2a05:3e00:2::/48 ... 2a05:3e00:f::/48 Aus jedem /48-Präfix weisen wir einzelne /52-Präfixe Institutionen (i.d.R. Fakultäten) zu; maximal 16 pro Gebäude: 2a05:3e00:2::/52 (bzw. 2a05:3e00:2:0000::/52) 2a05:3e00:2:1000::/52 2a05:3e00:2:2000::/52 ... 2a05:3e00:2:f000::/52 Institute, Arbeitsgruppen o.ä., die Einrichtungen untergeordnet sind, bekommen dann von uns Subnetze aus dem entsprechenden /52-Präfix zugewiesen: 2a05:3e00:2:1000::/64 2a05:3e00:2:1001::/64 2a05:3e00:2:1002::/64 ... 2a05:3e00:2:100f::/64 2a05:3e00:2:1010::/64 2a05:3e00:2:1011::/64 ... 12 Bits verbleiben also für die Subnetze, das entspricht maximal 4096 Subnetzen pro Einrichtung. Somit ist es per ACL bzw. Firewall sehr einfach möglich, den Zugriff für alle Subnetze einer Fakultät zu regeln -- eine Anfrage, mit der wir des öfteren konfrontiert werden. Aus dem Adressierungsplan geht bei genauerer Betrachtung jedoch auch hervor, dass IPv6-Adressen -- anders als IPv4-Adressen an der RUB -- fest an den Router gekoppelt sind. Das bedeutet, dass eine Einrichtung (z.B. Fakultät) durchaus mehrere /52-Präfixe haben kann, wenn sie Subnetze in mehreren Gebäuden unterhält. Dennoch wird sich das in den meisten Fällen in Grenzen halten. ==== Literatur ==== Es gibt inzwischen zahlreiche Literatur zu IPv6. Als erste Quelle dienen natürlich Online-Ressourcen: * [[https://de.wikipedia.org/wiki/IPv6]] * [[http://www.ripe.net/internet-coordination/press-centre/understanding-ip-addressing]] Auf Papier gibt es z.B.: * Silvia Hagen: "IPv6. Grundlagen - Funktionalität - Integration" (ISBN-13: 978-3952294222) * erklärt ausführlich Protokolldetails * hilfreich für Firewall-Administratoren