Oops!… They did it again: IPv6 kann jetzt NAT

Während viele “Experten” NAT noch immer als Sicherheitsfeature preisen, ist es für andere schlicht das Schlimmste, was dem Netz je passiert ist. Ich persönlich gehöre definitiv zu letzteren. Dank NAT und fehlender Netzwerktransparenz gibt es in vielen Firewalls viel größere “Löcher”, als eigentlich nötig wäre. Interne IPs auf IP-Ebene zu verstecken, während sie auf Anwendungsebene wieder sichtbar werden (Header in Mails, SIP – und vielen mehr) ist heutzutage ja meist auch eher witzlos. Der einzig wirkliche Grund für NAT war und ist die Adressknappheit bei IPv4 – und die wollten wir mit IPv6 ja hinter uns lassen. Warum also noch NAT?
Es scheint wohl Gründe dafür zu geben. Jedenfalls war es letzte Woche dann soweit: das experimentelle RFC 6296 “IPv6-to-IPv6 Network Prefix Translation” wurde veröffentlicht. Was vorher unter dem verpönten Namen NAT66 lief nennt sich jetzt also NPTv6, ist noch kein “Internet Standard” – aber wohl schon auf dem besten Weg dorthin. Das lange aufrecht erhaltene Credo “Mit IPv6 wird es kein NAT mehr geben” wurde damit hinfällig. Vermeiden ließ sich eine solche Entwicklung leider ohnehin nicht, und es ist sicher besser wenn offizielle Standards Einzug halten, bevor der Wildwuchs im freien Markt allzu sehr ausartet.
Warum aber will man bei so vielen verfügbaren Adressen denn eigentlich noch ein NAT haben? Der Wunsch nach einfacherem Roaming könnte z.B. ein Grund sein. Oder schlicht die Angst vor Seiteneffekten beim Renumbering, also der Neuvergabe von Adressen für ein ganzes Netzwerk. Dies kombiniert mit dem Wunsch nach dynamischen und täglich wechselnden offiziellen IPs auch bei IPv6 führte nebst anderen Gründen so zum durchaus verständlichem Ruf nach NAT für IPv6.
NPTv6 ist nicht unbedingt mit dem klassischen NAT wie wir es von unserer xDSL-Leitung in der IPv4-Welt kennen vergleichbar. Es ähnelt eher dem 1:1-NAT (one-to-one), bei dem eine interne Adresse exakt einer externen entspricht, und sämtliche Ports 1:1 durchgereicht werden. SOHO-Router verwenden hierfür in der IPv4-Welt auch Ausdrücke wie “Exposed Host” oder “DMZ-Host”. NPTv6 arbeitet ähnlich, allerdings nur auf Präfix-Ebene. Sprich: der komplette Präfix eines Subnetzes (/48, /64…) wird ersetzt – der Teil dahinter bleibt bestehen. Auch dynamische Port-Mappings sind glücklicherweise nicht vorgesehen.
Hier versucht die IETF, einen bei IPv4 gemachten Fehler nicht erneut zu begehen. Damals implementierte jeder NAT nach eigenem Gutdünken. Die IETF untersuchte später die am Markt verfügbaren Lösungen, um wenigstens zu dokumentieren, welche Spielarten von NAT denn im Umlauf seien. Mit IPv6 sollen wichtige Features wie “hairpinning” kein Zufall mehr, sondern werden zwingend vorgeschrieben sein.
Nichtsdestotrotz bleibt ein schaler Beigeschmack: die Hemmschwelle, NAT auch in der IPv6-Welt einzusetzen wurde mit RFC 6296 erheblich heruntergesetzt. Und wir riskieren, dass Provider aus falsch verstandener Bequemlichkeit NPTv6 auf breiter Ebene einsetzen werden. Dabei wäre das Renumbering auch eines ganzen Netzwerks an sich nichts Böses. Und es hat einen entscheidenden Vorteil: Applikationen sind transparenten Adresswechseln nicht mehr blind ausgeliefert.

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.