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.
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.
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.