Zehn Vorteile von IPv6!

Das moderne Internetprotokoll IPv6 gilt als so komplex und umständlich, dass manche Administratoren beharrlich beim vertrauten, aber veralteten IPv4 bleiben. Zehn Praxisbeispiele belegen, warum viele Netzwerkanwendungen besser und kostengünstiger auf IPv6 laufen und wie Admins davon profitieren.

Diesen Artikel habe ich initial für die c’t geschrieben, wo er im Heft 07/2022 erschienen ist. Als Autor habe ich dankenswerterweise die Erlaubnis, ihn hier auf meinem Blog ebenso zu veröffentlichen. Eine Übersicht der von mir geschriebenen c’t Artikel gibt es hier.
Note that this post is one of many related to IPv6. Click here for a structured list.

Profi-Admins und viele Netzwerk-Interessierte wissen längst, weshalb IPv4 unzulänglich ist: Dessen Adressraum ist gemessen am weltweiten Bedarf viel zu klein und Netzwerke auf IPv4-Basis laufen nur mit der Krücke Network Address Translation (NAT) weiter – diese bildet teils riesige Netze mit privaten IPv4-Adressen auf wenige oder gar nur eine öffentliche IPv4-Adresse ab. Weiter unten finden Sie mehr Beispiele für Netzwerkprobleme, die allein der IPv4-NAT geschuldet sind.

Aber jeder Admin weiß auch: IPv6 gewinnt zwar weltweit an Zulauf, doch kaum eine Firma wird mit IPv6 auch nur einen Cent mehr einnehmen; es gibt ja keine Geschäftsmodelle, die exklusiv auf IPv6 gründen. Warum also sollte man den Aufwand auf sich nehmen und etablierte IPv4-Methoden und -Werkzeuge einmotten?

Die Antwort zeigt sich auf dem Überstundenzettel des Admins: IPv4 verursacht bei vielen gängigen Anwendungen einen so großen Konzeptions- und Pflegeaufwand, dass sich eine Umstellung auf IPv6 mittelfristig bezahlt macht, weil sich die Netzwerkerweiterung und -pflege spürbar vereinfacht. Auch lassen sich manche Probleme, die IPv4 stellt, nur mit IPv6 lösen. Wenn Sie erst mal IPv6 eingeführt haben, können Sie Adressbrokern eine lange Nase drehen. Denn deren Geschäftsmodell setzt darauf, sich von IPv6-scheuen Unternehmen ihren kleinen Rest noch freier IPv4-Adressen vergolden zu lassen.

Heimnetz-Admins haben hingegen andere Sorgen mit der Umstellung von IPv4 auf IPv6. Unter anderem fehlt den verbreiteten Fritzbox-Routern eine IPv6-Implementierung der VPN-Technik. Da bessert der Hersteller aber nach.

Aller Anfang ist auch für den Firmen-Admin schwer und die erste Hürde stellt sich schon mit der Länge der IPv6-Adressen. “Die sind mir viel zu lang, die kann ich mir nicht merken.” Diesen Satz dürfte jeder Netzwerker oder IT-Admin schon mal gehört haben.

Natürlich sind IPv6-Adressen weit länger als IPv4-Adressen. IPv4-Adressen bestehen aus 4 Byte, die zu vier Blöcken mit Werten von 0 bis 255 unterteilt sind (32 Bit). IPv6-Adressen bestehen aus 16 Byte, die zu je acht Blöcken aus vier Hexadezimalstellen von 0 bis F unterteilt sind (128 Bit).

Doch gerade die Länge ist ein Gewinn, denn damit lassen sich die Adressen besser strukturieren. Das bringt in der Praxis vor allem bei komplexen Netzen in Unternehmen und Institutionen eine Fülle von Vorteilen. Man erkennt nur nicht alle auf den ersten Blick.

Vorteil 1: Zu merkende Präfixe

Viele mittelständische bis große Unternehmen haben im Laufe der Jahre mehrere öffentliche IPv4-Adressbereiche in Betrieb genommen. Zusätzlich verwendet jede Firma im internen Netz mindestens einen der üblichen privaten IPv4-Adressblöcke (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16). Das kann erforderlich sein, um Filialen zu koppeln oder das Netz in Subnetze aufzuteilen, sodass zum Beispiel Versand, Buchhaltung, Forschung, Produktion, Geschäftsleitung und Administration in verschiedene Security-Zonen aufgeteilt sind.

Bildet der Admin solche Strukturen mit IPv4 ab, hantiert er zwangsläufig mit den verschiedenen Präfixen der drei privaten Adressblöcke. Da sie aus obigen Gründen oft noch weiter unterteilt sind, kommt man leicht auf 3 bis 6 Blöcke, mit denen man im Alltag jonglieren muss.

Nicht so bei IPv6: Geschäftskunden erhalten in der Regel einen festen /48-Block und große Netzwerke bekommen leicht auch einen /32-Bereich. In beiden Fällen beträgt die Anzahl der zu merkenden Präfixe: eins! Und das Präfix ist schnell gelernt, weil es ja nur die ersten zwei Hextets umfasst, beispielsweise 2001:db8::/32.

Je nach Größe des Adressblocks schließt sich dann für die Subnetze der Adressraum des dritten oder vierten Hexadezimalblocks an (z. B. 16 Bit). In der Abbildung “IPv4 vs IPv6 Adressvorteile” (oben) wird dieser Unterschied offensichtlich: Bei IPv4 muss man die privaten und öffentlichen Allokationen vor Augen haben, während es mit IPv6 nur eine Zuweisung ist.

Vorteil 2 und 3: Site-to-Site-VPN

Viele Firmengruppen und Unternehmen unterhalten untereinander VPN-Verbindungen (Site-to-Site). Aufgrund des knappen IPv4-Adressraums sind bei allen Firmen private IPv4-Adressen unverzichtbar. Da es aber nur drei unterschiedliche Adressräume für private Netze gibt, ist die Wahrscheinlichkeit hoch, dass zwei Firmen intern denselben Bereich verwenden, beispielsweise 192.168.1.0/24. Dann sind Adresskollisionen und damit Admin-Kopfschmerzen unausweichlich.

Aus diesem Dilemma führen verschiedene Wege: Eine der beiden Firmen könnte ihr Subnetz in einen anderen Bereich verlegen. Doch der Aufwand ist viel zu hoch, fehlerträchtig und je nach verwendeten Diensten vielleicht gar nicht im laufenden Betrieb möglich – es ist jedenfalls für jeden Admin, der mehr als 20, 30 Netzwerkgeräte betreut, eine haarsträubende Vorstellung. Und wenn beide Firmen alle drei privaten IPv4-Adressblöcke nutzen, funktioniert der Weg gar nicht (10/8, 192.168/16 und 172.16/12).

Stattdessen konfiguriert man separate Adressen, die im jeweils anderen Netzwerk nicht vorkommen und richtet sie im VPN-Router mittels internen NATs als Vermittler ein – so sind Adresskollisionen ausgeschlossen, aber auf Kosten der Übersicht. Die Pflege und Fehlersuche ist in solchen Netzen deutlich aufwendiger.

Oft sind sogar ein Source- und ein Destination-NAT erforderlich, damit nicht nur die Hin-, sondern auch die Rück-Route klappt, ohne zu große Netzbereiche auf einer der Seiten belegen zu müssen.

Als Beispiel: Firma A teilt ihren internen Geräten IP-Adressen aus den Bereichen 192.168.0.0/24 und 192.168.10.0/24 zu. Die Partnerfirma B, zu der A ein VPN aufsetzen will, verwendet diese beiden Bereiche ebenso.

Der Client mit der IP-Adresse 192.168.0.5 möchte auf Server 192.168.10.10 von Firma B zugreifen. Da Firma A diesen Adressbereich aber bereits anderweitig verwendet, richtet man ein statisches Destination-NAT aus einem reservierten Block als Vermittler ein: 192.168.110.10 vermittelt dann den eingehenden VPN-Verkehr zum Server von Firma B. Diese kann die IP-Adresse des Firma-A-Clients nicht zurückrouten, weil diese bereits bei Firma B anderweitig in Einsatz ist; sie verwendet intern ebenfalls den Adressbereich 192.168.0.0/24. Also behilft sich Firma B mit einem Source-NAT. Somit sind für eine Client-Server-Verbindung vier Subnetze im Spiel.

Es leuchtet unmittelbar ein, dass solche Umwege aufwendig zu konfigurieren und der Übersicht abträglich sind. Das Troubleshooting von Client-Server-Verbindungen wird schnell zum Albtraum, denn in den Logs stehen auf beiden Seiten diverse IPv4-Adressen, die der Admin gedanklich korrekt zuordnen muss (und besser gleich auf einer Skizze notiert), obwohl für das VPN nur eine IP-Session im Spiel ist.

Mit jedem weiteren Site-to-Site-VPN potenziert sich der Aufwand, weil weitere NAT-Regeln hinzukommen; der IPv4-Adressdschungel wird immer undurchdringlicher. Dann muss man schon zum Aufsetzen der NATs mehr Probleme lösen als zur Konfiguration des VPN. Dabei sind zwei NAT-Regeln nur ein Beispiel. Je nach Infrastruktur können für eine einzige Site-to-Site-Verbindung mehr NATs erforderlich sein. Und Admins, die VPN-Verbindungen zu mehreren Partnern mit identischen IPv4-Subnetzen aufbauen wollen, können gleich auch Haarfärbemittel bestellen.

Der Umstieg auf IPv6 ist sicher auch aufwendig – aber einen Tod muss man sterben. Und wenn man sich einmal für IPv6 entschieden hat, wird Site-to-Site-VPN plötzlich zum Kinderspiel: Dank eindeutiger Adressbereiche auf beiden Seiten sind Adresskollisionen von vornherein ausgeschlossen und gordische NAT-Knoten daher nicht erforderlich. Die Konfiguration und das Troubleshooting solcher VPNs sind weit einfacher. Technisch gesehen muss nur das jeweils andere IPv6-Präfix im eigenen Netz geroutet werden – Ende-zu-Ende-IP-Verbindungen par excellence.

Vorteil 4: Stets genügend Platz in der DMZ

Viele Netzwerke sind organisch gewachsen und die ursprünglichen Konzepte zur Aufteilung des Adressraums genügen den aktuellen Anforderungen nicht mehr, denn auf einmal braucht die Firma mehr Server, als sich im dafür gedachten IPv4-Segment adressieren lassen.

Beispiel: Die Webserver-DMZ nutzt den Bereich 192.168.17.0/28, womit sich mitsamt dem Default-Gateway 14 Server adressieren lassen: 192.168.17.1 – 192.168.17.14. Sollen nun weitere Server hinzukommen, fehlt es an Adressen. Eine Neuaufteilung der Subnetze zur Vergrößerung des DMZ-Adressbereichs ist in großen Netzwerken kaum möglich.

Aber Not macht erfinderisch und risikobereit: Manche Admins legen im gleichen Layer-2-Segment ein zweites IP-Netz an, beispielsweise 192.168.91.64/28. Darin bekommt die Firmen-Firewall eine zweite IP-Adresse, damit sie für das zweite Netz als Default-Gateway arbeiten kann (192.168.91.65). So lassen sich weitere 13 Server adressieren. Das funktioniert zwar, erhöht aber die Komplexität, weshalb man solche Szenarien lieber meidet.

Mit IPv6 kommt man um solche Verknotungen auf absehbare Zeit leicht herum, weil die Adressräume weit größer sind: Mit jedem /64er-Subnetz lassen sich bis zu 2^64 Geräte adressieren. Ausgeschrieben: 18.446.744.073.709.551.616. Der Layer-2-Switch, der so viele MAC-Adressen verwalten kann, muss erst noch gebaut werden. Für MAC-Adressen sind bisher nur Tabellen mit 8192 bis 65.536 Einträgen üblich, und zwar für alle VLANs zusammengenommen.

Vorteil 5: Routing-Tabellen überblicken

Admins, die mit IPv4 aufgewachsen sind, haben verinnerlicht, mit Adressen zu knausern. Oder anders gesagt: kein Netz größer zu machen als unbedingt nötig. Deshalb bestehen unter anderem DMZ-Subnetze aus unterschiedlichen Teilnetzen wie /27, /28 oder /29er, während Gäste-WLANs oft auf /23- oder /22-Blöcke ausgedehnt sind – sehr zum Leidwesen des Netzadmins, der Routing-Tabellen nicht mal eben mit einem grep-Kommando durchforsten kann.

Stattdessen muss er die Subnetzmaske durchblicken. Hat der Admin in der Routing-Tabelle drei Netze, kann er nicht einfach per grep 192.168.23. herausfiltern, welche der Routen denn stimmt. Er muss alle drei anschauen und verstehen. Und wenn die Routing-Tabelle aus mehreren Hundert Einträgen besteht, hilft Drübergucken auch nicht mehr, sondern nur noch spezielle Lookup-Tools, wie sie Router oder Firewalls bieten.

Das ist umständlich. Anders bei IPv6: Die ersten vier Hextets einer IPv6-Adresse bezeichnen immer und eindeutig die Netz-ID. Die Zugehörigkeit von Node-IDs zu einem Netz ist daher unmittelbar ersichtlich, egal, ob in Routing-Tabellen oder Firewall-Logs.

Vorteil 6: Ende-zu-Ende-Verbindungen

Bereits bei der Spezifikation vor fast 30 Jahren werteten Fachleute die NAT als “short-term solution” und favorisierten ein künftiges Internet-Protokoll mit größerem Adressraum. Denn wenn eine NAT im Spiel ist, können IPv4-Geräte keine Ende-zu-Ende-Verbindungen aufbauen. Deshalb lassen sich Server-Logs nicht umgehend einer Client-Session zuordnen. Der NAT-Router muss den Zustand (state) in der NAT-Tabelle pflegen und unbenutzte Sessions tilgen, andernfalls können irgendwann keine neuen Sessions aufgebaut werden.

Kurzum: Die NAT hat zwar eine Zeit lang geholfen, das Internet-Wachstum aufrechtzuerhalten, aber daran festzuhalten heißt auch, mehr Geld für heutzutage rare IPv4-Adressen ausgeben. Bei eingehenden Verbindungen zu einem Server entfernt sie die öffentliche IPv4-Adresse aus dem Header des Client-Pakets, setzt die private IP-Adresse des Servers ein, notiert sich das und gibt das Paket schließlich zum Server weiter. Das belastet den Router und bremst den Verkehr.

Diesen kosten- und energieträchtigen Rechenaufwand kann man Routern durch den Wechsel auf IPv6 ersparen. Dank weltweit eindeutiger Adressierung aller Endgeräte braucht IPv6 keine NAT – ein Router muss die Pakete nur noch routen. So war ursprünglich auch das IPv4-Internet gedacht.

Wer sich um die Security Sorgen macht, da alle IPv6-Clients adressierbar sind: addressable ≠ accessible! Eine Firewall, die unverlangt eingehende Verbindungen verwirft, stellt sicher, dass interne Geräte der Firma eben nicht von außen erreichbar sind. Anstelle eines einfachen Routers mit seiner durchsatzbegrenzenden NAT kommt eine echte Firewall zum Einsatz. Schon die allermeisten einfachen Router für den Heimbereich sind IPv6-seitig genau so ausgelegt und schützen das Netz ab Werk, also ohne jegliche Benutzerinteraktion. Beispielsweise machen die verbreiteten die Fritzboxen genau das.

Vorteil 7: Kein Split-DNS

Damit externe Clients auf Server mit privaten IPv4-Adressen zugreifen können, die hinter einer NAT stehen, befragen sie zunächst das Domain Name System (DNS) nach der öffentlichen IP-Adresse der angesteuerten Domain. Im öffentlichen DNS stehen keine privaten IPv4-Adressen, sodass dort der angefragte Domainname auf die öffentliche IPv4-Adresse des Routers gemappt ist.

Interne Clients sollen aber möglichst nicht den Weg über die NAT gehen, um den Router zu entlasten. Damit sie den kurzen internen Weg beschreiten, richtet man im Netz einen internen DNS-Server ein, der den Clients die private IPv4-Adresse des Servers liefert, den sie dann direkt kontaktieren. So gibt es aber je nach Position eines Clients unterschiedliche DNS-Server mit unterschiedlichen Antworten auf dieselbe DNS-Anfrage – das ist die klassische und zurecht ungeliebte Split-DNS-Konfiguration mit zwei (oder sogar mehr) Views.

IPv6 benötigt keine NAT, sodass für alle Server die öffentliche IPv6-Adresse direkt auf ihren Netzwerkkarten konfiguriert ist. Deshalb erfolgen IPv6-Zugriffe von Clients auf Server im selben Netz sowieso direkt, weil die Wege zu den Servern in der internen Route stehen. Das erspart das Split-DNS – eine Fehlerquelle weniger.

Vorteil 8: Viele Server auf gleichen Ports

Privatkunden und auch viele Kleinunternehmen erhalten in der Regel Internetanschlüsse mit nur einer öffentlichen IPv4-Adresse– wenn überhaupt, Kabel-Internet mit DS-Lite und Glasfaserzugänge mit CG-NAT lassen grüßen. Mit einer IPv4-Adresse kann man pro TCP/UDP-Port normalerweise nur einen Server betreiben, also zum Beispiel nur einen HTTPS-Server auf 443/TCP oder nur einen SMTP-Server auf 25/TCP.

Wenn auf demselben Anschluss auch IPv6 geschaltet ist, kann man dahinter mehrere Server auf denselben Ports betreiben. Entwickler können so mehrere Server unter verschiedenen IPv6-Adressen für verschiedene Zwecke laufen lassen, zum Beispiel für die Produktion und den Testbetrieb, oder Haupt- und Backup-Server für SMTP- und IMAP-Mail.

Vorteil 9: Infos im Suffix abbilden

Enterprise-Router haben wie andere IPv6-Hosts auch für jedes Interface mindestens zwei IPv6-Adressen, eine Link-lokale und eine globale. Die Suffixe – der Host-Teil, auch IID, hintere 64 Bit – der Adressen generiert ein Router automatisch, wenn man ihn lässt; er leitet sie von der MAC-Adresse des jeweiligen LAN-Interfaces ab (modifiziertes EUI-64-Verfahren für Interface Identifiers in RFC 4291). Diese automatisch generierten Suffixe sind aber schwer zu merken, was zum Beispiel die Fehlersuche erschwert. Womöglich ist das eine der Ursachen, dass sich Admins für IPv6 so schwer erwärmen.

Die Übersicht lässt sich leicht verbessern, indem man im Suffix Gebäude-, Stockwerk-, Abteilungsstrukturen oder gar den Router-Typ manuell abbildet und zwar so, dass Sie sich die Zuordnungen leicht memorieren können. Da man für Server-Host-IDs nur wenige Stellen benötigt, können Sie drei der vier Host-ID Bereiche wegkürzen. Angenommen, das Serverpräfix lautet 2001:db8:f5:1234::/64, dann vergibt man in diesem Subnetz für die Server beispielsweise 2001:db8:f5:1234::a1, 2001:db8:f5:1234::a2, und so weiter. Um die Hosts zu unterscheiden, genügt also ein Blick auf das letzte Hextet der Host-ID.

Auch ist nützlich, dasselbe Suffix in der Link-lokalen Adresse zu verwenden. Wenn Sie die wesentlichen Merkmale in den letzten 32 Bit des Suffix kodieren, können Sie diesen Bereich bei den Routing-Protokollen OSPFv3 und BGP zusätzlich als Router-ID nutzen.

Vorteil 10: Hierarchischer Adressplan

Von den Vorteilen eines hierarchischen IPv6-Adressplans haben wir hier noch gar nicht gesprochen. Beispielsweise gibt es die Möglichkeit, an den Nibble-Boundaries (4-Bit-Blöcke zur Subnetierung) eines /32er-Präfixes die /48er-Sites zu nummerieren. Oder innerhalb eines /48-Blocks die /64er-Subnetze anhand der Organisationseinheiten oder Securityzonen zu ordnen. Das ist ein anderes Thema, dem auch schon ganze Bücher gewidmet sind.

Zur Liste der Vorteile muss man fairerweise noch sagen, dass nicht alle bei jeder Anwendung greifen. Im privaten Heimnetz sind DNS-Views (siehe Vorteil 7) meistens unwichtig, zumal schon die Anzahl an verschiedenen Subnetzen (5) niedrig ist. In großen, weltweit aufgestellten Unternehmen ist wiederum das einfache Routing (2) über VPNs nicht mehr skalierbar beziehungsweise politisch oder organisatorisch schwer umzusetzen.

Dennoch: Die Vorteile des IPv6-Adressraums sind weit größer als die reine Anzahl adressierbarer Endgeräte.

Erste Schritte

Letztlich bleibt der Widerwille gegen hexadezimale IPv6-Adressen ein nicht haltbares Vorurteil. Lassen Sie sich also nicht davon irritieren. Unsere Empfehlung lautet: Starten Sie mit IPv6. Es muss ja nicht gleich das gesamte Firmennetz sein. Ein kleines Labor, das Gäste-WLAN oder eine DMZ genügen, um Erfahrungen zu sammeln. So gewöhnen sich Admins leicht an IPv6-Adressen in Routing-Tabellen, Firewall-Regelwerken und Applikations-Logs. Das verkleinert die Hürde, falls IPv6 morgen zwingend erforderlich wird.

Und wenn Sie sich entschieden haben, IPv4 aufs Reservegleis zu schieben: Planen Sie Ihre IPv6-Infrastruktur am besten von Grund auf neu, ohne Bezugnahme auf Ihre IPv4-Struktur. Viele Netze sind im Laufe der Jahre organisch gewachsen und aus heutiger Sicht nicht mehr optimal strukturiert. Nutzen Sie den Umstieg, um das Dickicht zu lichten.

Die Abbildung Ihrer Prozesse auf IPv6 dürfte in den allermeisten Fällen reibungslos klappen, weil inzwischen der Großteil der Anwendungen auf IPv6 läuft. Kalkulieren Sie Mehraufwand ein, um individuelle Lösungen wie Skripte für IPv6 zu ertüchtigen.

Achten Sie beim Parallelbetrieb von IPv6 und IPv4 darauf, dass alle Sicherheitsrichtlinien umgesetzt sind. Ein beliebter Fehler: Man schränkt zwar den SSH-Login auf der externen Firewall für IPv4 per Access List auf bestimmte IPv4-Quelladressen ein, vergisst aber, den Zugriff für IPv6 zu beschränken, sodass der SSH-Server per IPv6 aus dem gesamten Internet erreichbar ist.

Zu beachten ist auch, dass Server, die über ein VPN per IPv6 angesprochen werden und in einer DMZ stehen, einem Sicherheitsrisiko ausgesetzt sind. Bricht der Tunnel zusammen, funktioniert die VPN-Route nicht mehr und der Verkehr geht ersatzweise über die Default Route zum Ziel. Dabei laufen Anwendungen, die nicht von sich aus verschlüsseln, blank übers Internet (z. B. IP-Telefonie oder Mail-Verkehr). Dagegen helfen bei großen Firewalls spezielle Regeln.

Exkurs: Die Nachteile der NAT

Im letzten Jahrtausend gab es tatsächlich eine Phase, als jeder Host im IPv4-basierten Internet seine eigene öffentliche Adresse hatte. Als das Wachstum alle Erwartungen übertraf, zauberten findige Entwickler die Network Address Translation (NAT) aus dem Ärmel und brachten so mittels privaten, öffentlich nicht gerouteten Adressen ein Mehrfaches an Netzwerkgeräten ins Internet, als mit den 4,3 Milliarden IPv4-Adressen möglich ist. Das ist nun der Status: NAT hat sich fürs IPv4-Internet unverzichtbar gemacht.

Doch damit sie zwischen Geräten mit privaten IPv4-Adressen im Netzwerk und Zielen im öffentlichen Internet vermitteln kann, ändert die NAT die Ziel- und Quelladressen von ein- und ausgehenden Datenpaketen, notiert sich für jede einzelne Sitzung die Bezüge und reicht die Pakete dann erst zu ihren Zielen weiter. Daraus entstehen Nachteile, die man teils wiederum mit Behelfen mehr schlecht als recht kompensiert.

Hosts in verschiedenen Netzen, die hinter NATs stehen, können nicht direkt miteinander kommunizieren, da die NATs unaufgefordert eingehende Verbindungen verwerfen. Damit sie wenigstens mittelbar kommunizieren können, braucht man Hilfsprotokolle wie STUN, TURN, ICE oder UPnP. Manche sind umständlich zu konfigurieren und sie funktionieren nicht immer. Beispielsweise gibt es Router, die für ihre interne VoIP-TK-Anlage alle VoIP-Sessions (SIP und RTP) für sich beanspruchen, sodass man dahinter keine eigene VoIP-TK-Anlage betreiben kann.

NAT-Tabellen können nicht beliebig groß sein. Meistens fassen sie nur einige Tausend Einträge, denn Router müssen mit ihrem meist knappen RAM-Angebot haushalten. Deshalb löschen sie inaktive NAT-Einträge bei Platznot. Um Einträge so lange aktuell zu halten, wie die jeweilige IP-Sitzung dauert, müssen Netzwerkgeräte etwa im Minutentakt Pakete zu ihrem Ziel senden, die dem Router signalisieren: “Dieser NAT-Eintrag wird noch benötigt”. Das tun nicht alle Anwendungen. Beispielsweise senden Messaging- oder Notification-Anwendungen Daten nur unregelmäßig, sodass ihr NAT-Eintrag verschwindet. Daher sind manche solcher Clients nicht durchgängig erreichbar oder müssen ihre Verbindung immer wieder neu aufbauen.

Umgekehrt gilt: Wenn die Netzwerkgeräte viele Sitzungen dauerhaft aufgebaut haben, kann die NAT-Tabelle überlaufen, mit der Folge, dass manche Sitzungen unerwartet abbrechen (z. B. VPN-Tunnel).

Zu dem Thema haben Fachleute schon ganze Bücher geschrieben, es gibt sogar ein IETF-Dokument, das ausschließlich den Problemen gewidmet ist, das die NAT verursacht (RFC 3027). Unterm Strich gilt: Die NAT ist okay, solange man auf IPv4 angewiesen ist. Doch die Behauptung, “NAT ist ein Security-Feature” hat nie gestimmt. Wenn möglich, sollte man also auf IPv6 umsteigen, weil sich damit viele Detailprobleme gar nicht erst stellen.

Photo by Tyler Nix on Unsplash.

6 thoughts on “Zehn Vorteile von IPv6!

  1. Danke für den schönen Artikel. Ich würde auch gerne IPv6 nutzen. Mich hält dabei vor allem das Thema Prefixe auf, was ich noch nicht sonderlich verstanden habe. Könnten Sie dazu vielleicht mal was schreiben?

    Zuhause am (früher DSL) und jetzt Kabel-Anschluss mit einer Fritzbox erhalte ich vom Provider einen Prefix der sich bei jeder Einwahl ändert. Wie gebe ich dann einem Server eine feste IP?

    Im Firmen-Umfeld ist das Problem ähnlich. Zwar bekommt man auf Wunsch feste IPv6 Prefixe, aber dann kann ich ja nie den Provider wechseln? Bzw. wie kommt man an ein PI-Prefix und wie nutzt man diesen mit einem Provider wie z.B. Telekom, Vodafone oder einem Glasfaser-Anbieter?

    Wie würde man außerdem Multi-WAN mit IPv6 umsetzen? (z.B. DSL und Kabel Anschluss) Mit einem NAT und einem Multi-WAN fähigen Router ist das “relativ” einfach, wenn auch teilweise problematisch (z.B. beim Thema DNS).

    Unabhängig davon: wie ist das eigentlich bei LTE? Im IPv4 Bereich machen (soweit ich weiß) alle Provider NAT. Wie ist das bei IPv6?

    Was ich auch noch nicht verstanden habe, ist das Thema Link-Lokal-Adressen. Für was brauche ich die? So wie ich das verstehe, könnte ich mir damit ein lokales Netzwerk bauen um dann wieder Gateways und NATs haben zu können. Das scheint mir aber völlig unsinnig.

    1. Hallo Masgo.

      Haha, da triffst du genau die (wenigen) echt problematischen Themen. ;) Ich versuche mal, etwas Licht rein zu bringen:

      1) Ja, in Deutschland bekommst du als Privatkunde meistens nur einen dynamischen Präfix zugewiesen. Sprich: Nach einem Reboot des Routers bekommst du ein neues /56 zugeteilt. (/56er haben sich etabliert. Je nach Anbieter kann es aber auch größer oder kleiner sein.) Dieses Verhalten ist ganz große Miezekotze! Da kann man nicht um den heißen Brei herum reden. Was bei IPv4 mit einer dynamischen IP Adresse und DynDNS gepaart mit Port-Forwardings funktioniert hat, ist hier ziemlich bescheuert. Zum Glück liefert zum Beispiel AVM mit ihren Fritzboxen da ein gutes Konzept per MyFritz, was für Endgeräte die IPv6 Adressen quasi wie bei DynDNS aktualisieren kann. Solange die Interface-IDs der Endgeräte gleich bleiben, funktioniert das auch. Ebenso kann die Fritzbox IPv6 Firewallregeln für Endgeräte freigeben, die dann eben nur per IID erstellt werden. Noch mehr über die Probleme von dynamischen Präfixen habe ich hier mal geschrieben: https://weberblog.net/ipv6-dyn-prefix-problems/

      2) Zum Glück trifft das Firmenkunden aber nicht. Dort wäre man schlecht beraten, einen Privatkundenanschluss zu nutzen. Firmenanschlüsse hingegen haben immer statische Präfixe, dann meistens auch größere wie zB ein /48er. Die Telekom macht das zum Beispiel so.

      3) Aber auch hier hast du den wunden Punkt getroffen: Multihoming, also das Vorhandensein mehrere ISP Anschlüsse für eine Hochverfügbarkeit bzw. für eine Lastteilung. Wenn du jetzt als Firma von jedem der ISPs einen eigenen PA-Bereich bekommst, hast du halt am Ende ein paar unterschiedliche IPv6-Präfixe, die jeweils nur bei *EINEM* ISP geroutet werden. Also auch mist. Hier hilft es dann tatsächlich nur, ein eigenes Autonomous System (AS), also ein LIR, zu werden und den dann zugeteilten PI-Space zu nutzen. Dieser wird per BGP dann zu den ISP-Anschlüssen propagiert. Egal welcher der ISPs dann ausfällt, wird DEIN Bereich weiterhin über einen der anderen geroutet. Vertragstechnisch sind das dann natürlich andere Arten von Businessanschlüssen. Schließlich müssen die ISPs mit dir BGP sprechen.

      4) Im Mobilfunknetz hast du Internet par excellence, nämlich echtes native IPv6 am Endgerät. Das wird sogar zB bei einem iPhone beim Tethering an dahinterliegende Geräte weitergegeben, also völlig ohne NAT. Selbst schon so erlebt: https://twitter.com/webernetz/status/1526807806396997637

      5) Link-Local Adressen: Hierbei geht es darum, dass jedes Gerät eine funktionsfähige IPv6 Adresse bekommt, noch bevor es überhaupt mit anderen Geräten kommunizieren muss bzw. kann. Wenn jetzt dieses Endgerät vom Router ein RA (Router Advertisement) via den Link-Local Adressen bekommt, kann es danach ja seinen GUA Adresse selsbst erzeugen. Und wenn der Router mehrere Präfixe anbietet, dann findet die RS/RA Kommunikation immer und weiterhin über die LL Adressen statt, eben *unabhängig* von den aktuell genetzten GUA Adressen. Übrigens werden Routen wie die Default Route *immer* per LL eingetragen. Wenn du dir die Routingtabelle deiner Endgeräte mal anschaust wirst du da als Default Route (::/0) als Next-Hop nicht die GUA Adresse des Routers, sondern dessen LL Adresse finden. So einen richtig großen Nutzen hat das im Normalfall (bei nur einem statischen Präfix auf dem Netz) nicht. Sollte aber alle paar Stunden der Präfix sich wechseln, dann erschließt es sich einem schon, dass die RA Meldungen besser von einer unabhängigen Adresse kommen und nicht von einer, die gleich sich selbst für deprecated deklariert.

      So, viel Text. ;) Ich hoffe, ich konnte dir damit etwas weiterhelfen.
      Ciao
      Johannes

      1. Hallo Johannes,
        danke für die ausführliche Antwort.

        Was ich mich gerade gefragt habe: was passiert bei dynamischen Prefixen wenn die DSL Leitung für längere Zeit ausfällt? Behält die Fritzbox den zuletzt vergebenen Prefix und verteilt damit weiterhin IPs?

        Zu den einzelnen Punkten:
        1) Im privaten Umfeld scheint mir alles eher nicht so problematisch. Man muss nur aufhören IPs in irgendwelche Konfigurationen einzutragen (z.B. Drucker, Server, etc.) und muss Hostnamen in der Fritzbox eintragen und dann diese verwenden.

        2) Unser Lokaler Glasfaser-Anbieter vergibt für Firmen 1x statische IPv4 und ein /62er Prefix IPv6. Alles andere ist dann Aufpreispflichtig. Die Deutsche Glasfaser hatte und für einen anderen Standort sogar nur eine statische IPv4 angeboten.

        3) Dieser Punkt ist ein richtiger “Show Stopper” für kleinere und mittlere Unternehmen. Unsere Firma hat mehrere Standorte und immer zwei Leitungen. Teilweise aus Backup-Gründen, teilweise aber auch wir nur maximal DSL 12.000 bekommen. Bei kleinen Standorten ist es dann DSL + LTE im Stand-By (Telekom hat einen guten Tarif für sowas). Bei mittleren sind es entweder 2x DSL oder DSL + Kabel mit Load-Balancing. Bei den großen Standorten ist es dann Glasfaser + DSL oder Kabel. Auch das mit Load-Balancing weil die Telefonie über DSL gehen muss. Die Standorte auf BGP-Fähige Anschlüsse umzustellen ist praktisch unbezahlbar. Ob das bei DSL und Kabel überhaupt angeboten wird weiß ich nichtmal. Bei Glasfaser gab es das zur Wahl, aber ca. 5x Preis.

        4) gut zu wissen.

        5) Danke für die Erklärung.

        1. Hi Masgo,

          was genau die Fritzboxen bei einem nicht-funktionstüchtigen Internet macht, weiß ich gar nicht wirklich. Könnte man ja relativ einfach mal testen. (Ich bin aber nicht immer zu 100 % glücklich mit der Umsetzung von IPv6 bei der Fritzbox, beispielsweise bei der Vergabe von ULAs per default. Hier hatte ich da mal etwas diskutiert: https://twitter.com/webernetz/status/1445640756383731721)

          1) Korrekt ;) Außer man möchte hint der Fritzbox noch einen weiteren Router betreiben, was ich in Form eines Ubiquiti UniFi Netzwerkes tatsächlich mache. Da ist dann das Konzept von dynamischen Präfixen endgültig Grütze. Theoretisch halt über DHCPv6-PD zu lösen, in der Praxis mit solchem Semi-Enterprise Equipment aber unlösbar.

          2) Ich bin ebenso bei der Deutschen Glasfaser und die vergibt zum Glück semi-statische IPv6 Präfixe. Sprich: Ich habe zwar keine entsprechende Option gebucht und somit kein Anrecht darauf, aber faktisch ist mein Präfix seit eh und je der gleiche. Auch nach Router Reboots.

          3) Ja, ist leider so. Kleiner Trost: Für reine Client-Netzwerke ist es ja nicht soo schlimm. Und einen Server mit fester IP-Adresse wäre auch in diesem Fall immer nur über den einen oder den anderen ISP erreichbar gewesen. Da ändert sich also auch nichts beim Umstieg auf v6.

  2. Und nächstes Jahr dann ein Artikel mit dem Titel “Sechs Vorteile von IPv10!”.

Leave a Reply to Johannes Weber Cancel reply

Your email address will not be published. Required fields are marked *