Reine IPv6 Netze – buettemeyer.net

Nachdem ich neulich meine HE IPv6 Zertifizierung gemacht habe, dachte ich, es wäre Zeit für den nächsten Schritt. Ich möchte zukünftig auf reines IPv6 setzen, um mir den doppelten administrativen Aufwand für die Dual-Stack Konfiguration zu ersparen: jeweils 2 IPs, DNS-Einträge, DHCP-Bereiche, Reverse-Lookup Zonen etc., das nervt ja auf die Dauer schon.

Also bei einer Test-VM IPv4 deaktiviert und geschaut, was passiert. Erwartungsgemäß geht sehr viel, aber eben nicht alles. Auch große und von mir häufig benutzte Sites funktionieren nicht: Stackexchange, Xing, Azure / O365 und, in Corona Zeiten besonders tragisch, das RKI. Als dann auch Firefox noch sagte, ich müsse mir meine Updates manuell herunterladen, weil zwar der Web-Server (www.mozilla.org) IPv6 spricht, der Update-Server (download.mozilla.org) aber nicht, war klar: eine IPv6-Überganstechnologie muss her!

Technologien

Eigentlich sogar 2 verschiedene Technologien, ich nenne das mal *64: v6 unterscheidet sich natürlich auf der Netzwerkebene von v4 (andere Adressen und Header) aber auch DNS auf der Anwendungsschicht hat ja andere Eintragstypen (AAAA statt A bei v4). Wir brauchen also NAT64 (sprich: NAT-sechs-vier), um die IP Pakete umzuschreiben, und zusätzlich noch DNS64 (sprich: DNS-sechs-vier) , um die DNS Einträge umzuschreiben.

Und das ganze muss natürlich zusammenspielen, damit der NAT64-Router weiß, welche Pakete er umschreiben muss. Nämlich nur die Pakete für Ziele, die ausschließlich über v4 Adressen verfügen. Die IETF hat dafür in RFC 6052 einen eigenen Präfix reserviert: 64:ff9b::/96. Das sieht erst mal seltsam aus, sind v6 Netze nicht immer /64? Normalerweise schon, sonst kann es Probleme mit der Autokonfiguration geben. Aber das ist ja kein Netz, sondern ein abstraktes Konstrukt, welches nur für das Zusammenspiel von DNS64 und NAT64 benötigt wird. Und es ist ein /96er Präfix, weil damit noch 32 Bit übrig bleiben, um eine v4 Adresse in einer v6 Adresse zu kapseln. Sprich: aus der v4 Adresse 192.168.100.200 wird die v6 Adresse 64:ff9b::c0a8:64c8. Die letzten 2 Blöcke, nach dem Doppelpunkt, repräsentieren dabei die v4 Adresse in hexadezimaler Schreibweise. Jeweils 2 hexadezimale Werte (2 * 4 = 8 Bit) der v6 Adresse repräsentieren dabei ein Oktett der v4 Adresse, also 192 = c0, 168 = a8 usw. Dezimal zu hexadezimal zu konvertieren ist sicherlich nicht jedermanns Sache, deshalb spezifiziert der RFC dankenswerter Weise eine alternative Schreibweise. Ein ping 64:ff9b::192.168.100.200 funktioniert auch, Glück gehabt 🙂

Funktionsweise

Man kann also v4 Adressen in v6 Adressen kapseln und das verwendete Präfix ist für das Zusammenspiel zwischen DNS64 und NAT64 wichtig. Aber was passiert denn genau, wenn ein reiner v6 Client auf einen reinen v4 Server zugreifen möchte? Im Prinzip das gleiche wie bei einem normaler Zugriff über v4 oder v6, nur dass die *64 Komponenten Dinge umschreiben. Für die Endgeräte sollte das ganze also transparent erfolgen und eine Konfiguration der Endgeräte ist nicht erforderlich. Hier sind die einzelnen Schritte:

Der Client möchte auf die Web-Site www.kann-nur-v4.example zugreifen und schickt eine Anfrage für den Hostnamen an seinen rekursiven DNS64-Server. Der Typ der Anfrage ist AAAA, der v6 Client möchte ja eine v6 Adresse bekommen.
Der rekursive DNS64-Server leitet die Anfrage an den DNS-Server für die Domäne kann-nur-v4.example weiter und bekommt nur eine v4 Adresse (Typ A) zurück, z.B. 203.0.113.100.
Der DNS64-Server verwendet das konfigurierte Präfix 64:ff9b::/96 um die v4 Adresse in eine v6 Adresse umzuschreiben und antwortet auf die Anfrage des Clients mit dem AAAA Eintrag 64:ff9b::cb00:7164.
Der Client baut eine TCP-Verbindung zu 64:ff9b::cb00:7164 auf und schickt das Paket an den NAT64-Router.
Der NAT64-Router sieht anhand des Präfixes, dass es sich um eine gekapselte v4 Adresse handelt, packt das v6 Datagramm aus, verpackt das darin enthaltene TCP-Segment in ein v4 Datagramm mit der Ziel-IP 203.0.113.100.und leitet es über das v4 Netz weiter. Zusätzlich nimmt er einen Eintrag in seiner NAT64-Tabelle vor, um die Antwortpakete zuordnen zu können.
Der Webserver bekommt das v4 Datagramm und schickt seine Antwort an die v4 Adresse des NAT64-Routers.
Der NAT64-Router bekommt das Antwortpaket, schaut in seiner NAT64-Tabelle nach und stellt fest, dass das Paket übersetzt werden muss. Er ersetzt den v4 Header durch einen v6 Header mit den Informationen aus der NAT64-Tabelle und leitet es über das v6 Netz an den Client weiter.
Der Client bekommt das Antwortpaket und der Nutzer kann sich www.kann-nur-v4.example anschauen.

Die netten Menschen von Wikipedia haben auch eine Grafik dazu.

Das ganze ist natürlich stark vereinfacht, wer sich für Binding Information Bases (oben schlicht NAT64-Tabelle genannt), 5-Tupel oder die Unterschiede in den Implementierungen von TCP, UDP und ICMP interessiert, dem sei der RFC ans Herz gelegt.

Es ist auch möglich, ein NAT64-Präfix aus seinem eigenen Netz zu verwenden, oder sogar mehrere Präfixe für verschiedene v4 Netze. Die obige Beschreibung geht auch davon aus, dass die *64 Funktionen auf den bereits bestehenden DNS-Servern und Routern implementiert werden, was nicht zwangsläufig der Fall sein muss. Zudem gibt zahlreiche weitere Funktionen wie z.B. autodiscovery, auf die ich hier nicht eingehen möchte.

Implementierung

Ich habe eine heterogene Umgebung, soll heißen, meine DNS-Server laufen unter Windows Server 2019 und meine Router laufen unter Debian 10 (Buster).

Windows DNS64

Windows unterstützt schon länger DNS64, vermutlich ein Überbleibsel von DirectAccess, einer Microsoft-proprietären VPN-Technologie mit IPv6 im VPN-Tunnel. Allerdings ist diese Funktionalität nicht über die GUI erreichbar, aber es gibt eine Reihe von (Get, Set, Enable, Disable, Reset)-NetDnsTransitionConfiguration Kommandos und Get-NetDnsTransitionMonitoring zur Überwachung. Seltsamerweise nutzt Microsoft in der Standardeinstellung jedoch das Präfix 69:FF9B::/96 statt des well-known prefix, warum auch immer. Ich hatte mich aber sowieso dafür entschieden, einen eigenen Präfix zu verwenden, im Beispiel 2001:db8:cafe:64::/96. Das ergibt dann folgendes Kommando:

Set-NetDnsTransitionConfiguration -PrefixMapping "2001:db8:cafe:64::/96,0.0.0.0/0" -State Enabled

Get-NetDnsTransitionConfiguration

State               : Enabled
AcceptInterface     : 
SendInterface       : 
OnlySendAQuery      : False
LatencyMilliseconds : 300
AlwaysSynthesize    : False
ExclusionList       : {0:0:0:0:0:ffff::/96}
PrefixMapping       : {2001:db8:cafe:64::/96,0.0.0.0/0}

-PrefixMapping legt das *64 Präfix und das v4 Präfix, für das es verwendet werden soll (alle) fest. -State aktiviert die DNS64 Funktionalität.

So sollte es zumindest sein, aber: zu früh gefreut! Immer noch keine AAAA Einträge für azure.com 🙁 Also schnell eine Anfrage im Microsoft Q&A Forum gepostet und nun heißt es abwarten oder viel Geld an M$ für Support bezahlen….

BIND DNS64

…oder schnell einen BIND Nameserver installieren, wenn einem das warten zu lange dauert. Dazu die Datei /etc/bind/named.conf.options wie folgt anpassen:

acl translator {
        # Please list all the translator's addresses here.
        localhost;
};

options {

        <DIE VORHANDENEN OPTIONEN BEIBEHALTEN UND ZUSÄTZLICH:>

        dns64 2001:db8:cafe:64::/96 {
                mapped { !10/8; !172.16/12; !192.168/16; any; };
                clients { !translator; any; };
        } ;
};

Debian NAT64

Debian kennt wie immer mehrere Methoden, um NAT64 zu implementieren. Die beiden bekanntesten scheinen TAYGA und Jool zu sein.

TAYGA existiert scheinbar schon ewig: deren Homepage hat Kommentare zu Linux 2.6.34 und einen Link zu einem Bug aus 2011. Außerdem ist das ein Prozess im Userspace, nicht im Kernel, was sich nachteilig auf die Geschwindigkeit / Systemlast auswirken könnte. Irgendwas mit context-switching und so, ich kenne mich auf den unteren Schichten von Linux auch nicht so gut aus 🙁

Jool hingegen ist eine Kombination aus einem Kernel-Modul und Userspace Werkzeugen um das zu bedienen. Das sieht ganz gut aus und ist einigermaßen aktuell, die letzte Version 4.1.5 ist weniger als ein halbes Jahr alt. Dazu wird es aktiv weiterentwickelt und hat Unterstützung durch das mexikanische NIC (Network Information Center) und eine non-profit Bildungseinrichtung namens Tecnológico de Monterrey. Allerdings setzt es bei Debian mindestens Version 11 / Bullseye voraus

Eine Quick & Dirty Kurzanleitung dazu gibt es auf ServerFault.