IPv6 in Mobilfunknetzen: 464XLAT, NAT64 und DNS64 einfach erklärt

Stellen Sie sich eine seltsame Szene vor. Sie öffnen auf Ihrem Handy einen Dienst zur IP-Überprüfung, und er zeigt eine IPv4-Adresse. Aber wenn Sie in die Netzwerkeinstellungen desselben Geräts schauen, prangt dort eine lange IPv6-Adresse. Wie kann das sein? Das Gerät lebt in einer IPv6-Welt, doch die Website vermerkt in ihren Logs selbstbewusst vier durch Punkte getrennte Dezimalzahlen. Wo fand der Austausch statt?

Das ist kein Bug und keine Magie. Es handelt sich um ein sorgfältig gestaltetes Übersetzungssystem, das Mobilfunkanbieter seit über einem Jahrzehnt weltweit aufbauen. Und wenn Sie mit mobilen Proxys, Web Scraping, Multi-Accounting arbeiten oder einfach verstehen möchten, was mit Ihrem Traffic passiert, ist es entscheidend, diese Mechanik zu verstehen.

In diesem Leitfaden gehen wir den gesamten Weg eines Datenpakets von der App auf Ihrem Handy bis zur Zielwebsite. Wir analysieren 464XLAT nach Komponenten, verstehen die Rolle von NAT64 und DNS64, sehen, wo genau die ausgehende IPv4-Adresse geboren wird, und lernen, den Verbindungsstapel selbst zu diagnostizieren. Dies ist kein oberflächlicher Überblick. Es ist eine tiefgehende Betrachtung für alle, die nicht nur wissen wollen, was passiert, sondern auch wie und warum.

Einleitung: Warum das Handy IPv6 bekommt, die Website aber IPv4 sieht

Beginnen wir mit dem Kern des Paradoxons. Ein modernes Smartphone in einem Mobilfunknetz eines großen Anbieters ist fast immer per IPv6 verbunden. Noch mehr: Es hat oft überhaupt keine echte IPv4-Adresse auf der Funkschnittstelle. Der Betreiber vergibt sie einfach nicht. Das ist eine bewusste Entscheidung, bedingt durch die akute Knappheit an Adressraum.

Aber das Internet ist nicht homogen. Eine riesige Anzahl von Websites, APIs und Diensten ist noch immer nur über IPv4 erreichbar. Sie haben keinen AAAA-Eintrag im DNS, ihre Server hören nicht auf IPv6. Wenn das Handy ausschließlich IPv6 sprechen könnte, könnte es die Hälfte des Internets nicht öffnen. Ein Widerspruch entsteht: Das Gerät spricht eine neue Sprache, aber der Gesprächspartner versteht nur die alte.

Die Lösung dieses Widerspruchs ist das Hauptthema unseres Gesprächs. Die Technologie 464XLAT zusammen mit den Mechanismen NAT64 und DNS64 baut eine unsichtbare Brücke. Das Gerät sendet Pakete über IPv6, und irgendwo tief im Netzwerk des Betreibers werden diese Pakete in IPv4 umgewandelt und mit einer echten IPv4-Adresse zum Zielserver geschickt. Der Server antwortet, und der Rückweg durchläuft dieselbe Transformation in umgekehrter Reihenfolge.

Deshalb sieht die Zielwebsite IPv4. Deshalb gibt ein mobiler Proxy, der auf einem echten Handy oder Modem des Betreibers läuft, nach außen eine IPv4-Adresse ab, obwohl im Gerät IPv6 herrscht. Der Austausch findet nicht auf dem Handy und nicht auf der Website statt. Er geschieht in einem Zwischenknoten im Netzwerk des Betreibers, der PLAT genannt wird.

Was Sie erfahren, wenn Sie bis zum Ende lesen:

• Wie der IPv4-Adressmangel entstanden ist und warum er die Betreiber zur Umstellung auf IPv6 gezwungen hat
• Was APN-Typen sind und wie sich IPv4v6 von reinem IPv6 unterscheidet
• Wie 464XLAT Schritt für Schritt funktioniert, wo CLAT lebt und wo PLAT
• Wie NAT64 und DNS64 eine Website ohne AAAA-Eintrag erreichbar machen
• Woher die ausgehende IPv4-Adresse eines mobilen Proxys kommt
• Wie Happy Eyeballs dafür sorgt, dass der Prüfdienst mal IPv4, mal IPv6 anzeigt
• Praktische Diagnosebefehle für den Verbindungsstapel
• Warum das Subnetz /64 als ein einzelner Client wahrgenommen wird und was das für Accounts bedeutet

Lassen Sie uns gleich die Grenzen abstecken. Wir sprechen ausschließlich über Netzwerkmechanik. Wir diskutieren nicht, was günstiger zu kaufen ist und welches Protokoll aus kommerzieller Sicht besser ist. Dies ist eine technische Anleitung, kein Marktüberblick.

Grundlagen: IPv4-Adressmangel, Umstellung auf IPv6 und APN-Typen

Um die gesamte Konstruktion zu verstehen, beginnen wir mit dem Fundament. Und das Fundament ist hier einzig und allein die katastrophale Knappheit an IPv4-Adressen.

Warum IPv4 zu Ende ging

Das IPv4-Protokoll verwendet 32-Bit-Adressen. Das ergibt etwa 4,3 Milliarden eindeutige Kombinationen. Als das Protokoll 1981 standardisiert wurde, schien das eine astronomische Zahl. Wer hätte sich vorstellen können, dass es mehr Geräte als Menschen auf der Erde geben würde?

Die Realität war hart. Smartphones, Tablets, Smartwatches, Kühlschränke, Kameras, Autos – alles braucht Adressen. Anfang der 2010er Jahre begannen die regionalen Internet-Registrare, ihre freien Blöcke zu erschöpfen. Heute ist es praktisch unmöglich, einen großen Block öffentlicher IPv4-Adressen zu bekommen, und auf dem Sekundärmarkt kosten sie zig Dollar pro Stück.

Für einen Mobilfunkanbieter mit zig Millionen Teilnehmern ist das ein grundlegendes Problem. Jedem Smartphone eine eigene öffentliche IPv4-Adresse zu geben, ist physisch unmöglich. Es gibt einfach nicht genug Adressen.

Wie IPv6 das Problem löst

Das IPv6-Protokoll verwendet 128-Bit-Adressen. Die Anzahl möglicher Kombinationen ist so groß, dass das menschliche Gehirn sie nicht erfassen kann – etwa 340 Undezillionen Adressen. Vereinfacht gesagt: Man könnte jedem Atom auf der Erdoberfläche mehrere Adressen geben und hätte immer noch welche übrig.

Der Betreiber erhält von der Registrierungsstelle einen riesigen IPv6-Block und verteilt ihn mit enormem Spielraum an die Teilnehmer. Typische Praxis ist es, jedem Teilnehmergerät ein ganzes Subnetz /64 zuzuweisen. Das sind, wohlgemerkt, 18 Trillionen Adressen für ein einziges Telefon. Merken Sie sich diese Tatsache, sie wird im Abschnitt über Multi-Accounting eine wichtige Rolle spielen.

Was ist APN und warum sind seine Typen wichtig?

APN steht für Access Point Name, also der Name des Zugangspunkts. Es ist ein Konfigurationsprofil, das dem Telefon mitteilt, wie es sich mit dem paketvermittelten Netz des Betreibers verbinden soll. Wenn das Smartphone eine Datenverbindung aufbaut, fordert es vom Netz die Erstellung einer Sitzung mit einem bestimmten Protokolltyp an.

Es gibt drei Haupttypen von PDN- oder PDP-Kontexten:

• IPv4 – dem Gerät wird nur eine IPv4-Adresse zugewiesen. Klassisches veraltetes Schema. Funktioniert, erfordert aber Adressen, die es nicht gibt.
• IPv6 – dem Gerät wird nur ein IPv6-Präfix zugewiesen. Überhaupt kein IPv4 an der Schnittstelle. Maximal sparsam für den Betreiber.
• IPv4v6 – Dual-Stack. Das Gerät fordert beide Adresstypen gleichzeitig innerhalb einer Sitzung an.

Hier liegt ein feiner Unterschied. Selbst wenn das Telefon IPv4v6 anfordert, kann der Betreiber nur den IPv6-Teil vergeben und den IPv4-Teil verweigern oder eine private Adresse über Übersetzungsmechanismen zuweisen. Viele große Betreiber sind so konfiguriert, dass der Teilnehmer standardmäßig reines IPv6 erhält, während die Kompatibilität mit dem IPv4-Internet durch die bereits beschriebene Technologie 464XLAT sichergestellt wird.

Eine Analogie, die hilft. Stellen Sie sich vor, die ganze Welt wäre auf eine neue Kommunikationssprache umgestiegen, aber viele alte Einrichtungen nehmen Dokumente nur in der alten Sprache an. Der Staat kann nicht jedem Bürger einen persönlichen alten Pass ausstellen – es gibt nicht genug. Also gibt er allen neue Dokumente und stellt an den Eingängen der alten Einrichtungen einen Übersetzer. Dieser Übersetzer ist 464XLAT.

Tiefgang: 464XLAT nach Komponenten

Jetzt sind wir bereit, die Technologie selbst zu sezieren. Der Name 464XLAT wird als four-six-four translation gelesen. Die Zahlen spiegeln das Wesen wider: Das Paket beginnt sein Leben als IPv4 innerhalb einer App, reist als IPv6 durchs Netz und wird am Ausgang wieder zu IPv4. XLAT ist eine Abkürzung für translation.

Grundlage ist der Standard für die Adressübersetzung zwischen Protokollen, beschrieben in IETF-Spezifikationen. Aber 464XLAT fügt eine Architektur aus zwei Komponenten hinzu, die paarweise arbeiten.

CLAT – Übersetzer auf dem Gerät

CLAT steht für Customer-side translator, also Übersetzer auf Kundenseite. Er lebt direkt auf Ihrem Smartphone, eingebaut in das Betriebssystem. Unter Android übernimmt ein spezieller Dienst diese Funktion, in anderen Systemen entsprechende Module.

Die Aufgabe von CLAT ist eine, aber wichtig. Wenn eine App auf dem Telefon ein IPv4-Paket senden möchte – zum Beispiel, weil sie hartnäckig einen IPv4-Socket verwendet oder direkt eine IP-Adresse anspricht – fängt CLAT dieses IPv4-Paket ab und verpackt es in IPv6. Technisch führt er eine Header-Übersetzung nach dem Algorithmus der zustandslosen Übersetzung durch, indem er die IPv4-Quell- und Zieladresse mithilfe eines bekannten Präfixes in entsprechende IPv6-Adressen umwandelt.

CLAT erstellt auf dem Gerät eine virtuelle Netzwerkschnittstelle, der eine private IPv4-Adresse zugewiesen ist. Die Apps sehen diese Adresse und glauben, sie lebten in einer normalen IPv4-Umgebung. Sie ahnen nicht einmal, dass unter der Haube längst alles auf IPv6 umgezogen ist.

PLAT – Übersetzer im Netzwerk des Betreibers

PLAT steht für Provider-side translator, Übersetzer auf Anbieterseite. Dies ist ein leistungsstarker Knoten irgendwo im Kern des Netzes des Betreibers, der die NAT64-Funktion implementiert. Hier findet die endgültige Umwandlung statt.

PLAT empfängt IPv6-Pakete, die vom Gerät kommen, und extrahiert daraus die Informationen über das ursprüngliche IPv4-Ziel. Anschließend führt er eine zustandsbehaftete Übersetzung durch: Er wandelt das IPv6-Paket zurück in ein IPv4-Paket, setzt als Quelladresse eine der öffentlichen IPv4-Adressen des Betreibers aus seinem Pool ein und sendet das Paket ins normale IPv4-Internet.

Das Schlüsselwort ist zustandsbehaftet, also mit Speicherung des Zustands. PLAT führt eine Tabelle der Zuordnungen, damit die Antwortpakete vom Server korrekt zu dem Gerät zurückkommen, das die Verbindung initiiert hat. Das ist im Grunde dasselbe Prinzip wie beim klassischen NAT, nur zwischen verschiedenen Protokollen.

Warum zwei Übersetzer?

Es stellt sich die berechtigte Frage: Wozu braucht man CLAT auf dem Gerät, wenn PLAT sowieso alles übersetzt? Die Antwort liegt in Apps, die kein IPv6 können.

Viele Apps sind mit harter IPv4-Nutzung geschrieben. Sie fordern IPv4-Sockets an, arbeiten mit IPv4-Literaladressen, einige Protokolle wie alte Implementierungen übertragen IP-Adressen innerhalb der Nutzlast. Wenn auf dem Gerät nur reines IPv6 vorhanden wäre, würden solche Apps einfach kaputtgehen. CLAT gibt ihnen die Illusion einer vollwertigen IPv4-Umgebung, bleibt dabei aber unsichtbar.

Das Zusammenspiel funktioniert also so: CLAT löst das Kompatibilitätsproblem auf dem Gerät, PLAT löst das Kompatibilitätsproblem im Internet. Zusammen bilden sie eine nahtlose Brücke.

NAT64 und DNS64: Wie eine Website ohne AAAA-Eintrag zum Leben erweckt wird

Wir haben die Paketübersetzung geklärt. Aber es gibt noch ein grundlegendes Problem – wie erfährt das Gerät überhaupt, wohin es das IPv6-Paket schicken soll, wenn die Zielwebsite nur in der IPv4-Welt existiert und keinerlei IPv6-Eintrag hat?

Hier kommt das Duo NAT64 und DNS64 auf die Bühne. Sie arbeiten eng zusammen, und das eine ohne das andere zu verstehen, ist unmöglich.

Das Problem des fehlenden AAAA-Eintrags

Im Domain Name System werden Adressen verschiedener Protokolle in verschiedenen Eintragstypen gespeichert. Die IPv4-Adresse wird in einem Eintrag vom Typ A gespeichert. Die IPv6-Adresse wird in einem Eintrag vom Typ AAAA gespeichert, der als Quad-A ausgesprochen wird.

Wenn ein reines IPv6-Gerät eine Website öffnen möchte, fragt es beim DNS nach einem AAAA-Eintrag. Aber wenn die Website keine IPv6-Infrastruktur hat, hat sie auch keinen AAAA-Eintrag. Es gibt nur einen A-Eintrag mit der IPv4-Adresse. Das Gerät erhält eine leere Antwort und sollte theoretisch sagen: Website nicht erreichbar. Aber das geschieht nicht, dank DNS64.

Wie DNS64 funktioniert

DNS64 ist ein spezieller DNS-Resolver des Betreibers mit einer Superkraft. Wenn das Gerät nach einem AAAA-Eintrag für eine Domain fragt, es aber keinen echten AAAA-Eintrag gibt, gibt DNS64 nicht auf. Er macht Folgendes:

1. Er fragt beim autoritativen Server den normalen A-Eintrag ab und erhält die IPv4-Adresse der Website
2. Er nimmt diese IPv4-Adresse und synthetisiert daraus einen künstlichen AAAA-Eintrag
3. Für die Synthese bettet er die 32 Bits der IPv4-Adresse in ein spezielles IPv6-Präfix ein
4. Er gibt diesen synthetisierten AAAA-Eintrag ganz normal an das Gerät zurück

Das Gerät erhält eine gültige IPv6-Adresse und sendet freudig Pakete dorthin. Es weiß nicht und soll nicht wissen, dass diese Adresse künstlich ist.

Das synthetisierte Präfix 64:ff9b::/96

Damit sind wir bei einem der bekanntesten Artefakte des gesamten Systems angelangt. Für die Synthese von Adressen wird ein speziell reserviertes Präfix 64:ff9b::/96 verwendet. Es wird Well-Known Prefix genannt, also allgemein bekanntes Präfix, und ist genau für die NAT64-Übersetzung standardisiert.

Die Mechanik ist einfach und elegant. Das Präfix belegt die ersten 96 Bits der Adresse. Die verbleibenden 32 Bits entsprechen genau der Größe einer IPv4-Adresse. DNS64 hängt einfach die IPv4-Adresse der Website an das Ende des Präfixes an.

Wenn die Website beispielsweise eine IPv4-Adresse hat, die aus vier Zahlen besteht, sieht die synthetisierte IPv6-Adresse wie das Präfix 64:ff9b aus, gefolgt von diesen vier Zahlen, die in den letzten 32 Bits codiert sind. Wenn ein solches Paket bei PLAT ankommt, sieht der Knoten das bekannte Präfix, versteht, dass es sich um eine NAT64-Übersetzung handelt, extrahiert die letzten 32 Bits und erhält die echte IPv4-Zieladresse. Danach sendet er ein normales IPv4-Paket.

Einige Betreiber verwenden anstelle des allgemein bekannten Präfixes ihr eigenes Netzwerkpräfix aus ihrem Adressraum. Die Logik ist dieselbe, nur der konkrete Wert der ersten Bits ändert sich.

Wie das Zusammenspiel funktioniert

Setzen wir das Puzzle zusammen. DNS64 ist dafür verantwortlich, dass das Gerät eine IPv6-Adresse für den Zugriff auf das IPv4-Internet erhält. NAT64 in Gestalt von PLAT ist dafür verantwortlich, dass das Paket mit dieser Adresse tatsächlich den IPv4-Server erreicht. Eines ohne das andere ist nutzlos: DNS64 erstellt eine Adresse, die nur NAT64 verarbeiten kann, und NAT64 verarbeitet nur die Adressen, die DNS64 synthetisiert hat.

Und was passiert mit Websites, die einen echten AAAA-Eintrag haben? Hier ist es einfacher. DNS64 sieht den echten AAAA-Eintrag und gibt ihn ohne Synthese weiter. Das Gerät verbindet sich direkt per IPv6 mit der Website und umgeht die gesamte Übersetzungsmaschinerie. Das ist der optimale direkte Weg.

Der Weg eines Pakets von der App zur Website bei 464XLAT: Schema in Worten

Es ist Zeit, die gesamte Mechanik in einem einzigen schrittweisen Schema zusammenzuführen. Verfolgen wir ein einzelnes Paket von seiner Geburt in der App bis zur Ankunft auf dem Ziel-IPv4-Server und zurück. Das ist die Route, die der Traffic eines mobilen Proxys nimmt.

Hinweg: Vom Telefon zur Website

1. Schritt 1. Die App möchte sich verbinden. Die App auf dem Telefon beschließt, eine Website zu öffnen, die nur IPv4 hat. Sie fragt den DNS nach der Adresse.
2. Schritt 2. DNS64 synthetisiert die Adresse. Der Resolver des Betreibers findet keinen echten AAAA-Eintrag, nimmt den A-Eintrag, bettet die IPv4-Adresse in das Präfix 64:ff9b::/96 ein und gibt den synthetisierten AAAA-Eintrag zurück.
3. Schritt 3. Die App sendet das Paket. Es gibt zwei Varianten. Wenn die App über IPv6 arbeitet, sendet sie sofort ein IPv6-Paket an die synthetisierte Adresse. Wenn die App hart an IPv4 gebunden ist, sendet sie ein IPv4-Paket an die virtuelle CLAT-Schnittstelle.
4. Schritt 4. CLAT übersetzt IPv4 in IPv6. Im Falle einer IPv4-App fängt der CLAT-Dienst das Paket ab und wandelt es nach den Regeln der zustandslosen Übersetzung in ein IPv6-Paket um, wobei dasselbe NAT64-Präfix verwendet wird.
5. Schritt 5. Das Paket fliegt über das Funknetz. Jetzt ist es ein reines IPv6-Paket. Es passiert die Basisstation und das Kernnetz des Mobilfunkbetreibers. Innerhalb des gesamten Funkteils lebt nur IPv6.
6. Schritt 6. Das Paket erreicht PLAT. Im Kern des Netzes steht der PLAT-Knoten mit der NAT64-Funktion. Er sieht ein Paket mit einem Ziel, das mit dem NAT64-Präfix beginnt.
7. Schritt 7. PLAT übersetzt IPv6 in IPv4. Der Knoten extrahiert die letzten 32 Bits der Zieladresse – das ist die echte IPv4 der Website. Dann setzt er als Quelle eine öffentliche IPv4 aus seinem Pool ein und vermerkt die Zuordnung in der Zustandstabelle.
8. Schritt 8. Das Paket geht ins Internet. Jetzt ist es ein normales IPv4-Paket. Es reist durch das globale Netz zum Zielserver.
9. Schritt 9. Die Website sieht IPv4. Der Server erhält eine Verbindung von der öffentlichen IPv4-Adresse des Betreibers. In den Logs wird genau diese IPv4 festgehalten. Das ist der Moment der Wahrheit: Die Website erfährt nie, dass das Paket ursprünglich in einer IPv6-Umgebung geboren wurde.

Rückweg: Von der Website zum Telefon

1. Schritt 10. Der Server antwortet. Die Website sendet ein Antwort-IPv4-Paket an die öffentliche Adresse, die sie gesehen hat.
2. Schritt 11. PLAT findet die Zuordnung. Der NAT64-Knoten schaut in seine Zustandstabelle, ermittelt, welchem Gerät die Verbindung gehört, und stellt die IPv6-Adresse wieder her.
3. Schritt 12. Rückübersetzung in IPv6. PLAT verwandelt die IPv4-Antwort in ein IPv6-Paket und sendet es durch das Kernnetz zurück zum Telefon.
4. Schritt 13. CLAT gibt IPv4 an die App zurück. Wenn die App ursprünglich über IPv4 gearbeitet hat, übersetzt CLAT auf dem Gerät die IPv6-Antwort zurück in IPv4 und gibt sie über die virtuelle Schnittstelle an die App weiter.
5. Schritt 14. Die App erhält die Antwort. Für die App sieht alles wie ein normaler IPv4-Austausch aus. Der Kreis schließt sich.

Halten Sie einen Moment inne und bewundern Sie die Eleganz dieser Konstruktion. Das Paket hat viermal seine Protokollidentität gewechselt, zwei Übersetzer passiert, und die Endpunkte – die App und die Website – ahnen nichts davon. Jeder sieht nur seine vertraute IPv4-Welt.

Was das alles für Proxys bedeutet: Wo die ausgehende Adresse entsteht

Jetzt wenden wir die ganze Theorie auf die Praxis der mobilen Proxys an. Dies ist der wichtigste Abschnitt für alle, die mit Traffic arbeiten.

Wo die ausgehende Adresse entsteht

Ein mobiler Proxy ist im Wesentlichen ein Einstiegspunkt ins Netz über ein echtes mobiles Gerät oder ein Modem, das mit dem Betreiber verbunden ist. Wenn Sie Traffic über einen solchen Proxy leiten, verlässt er das Internet genauso, wie der Traffic vom Telefon ausgehen würde.

Und wir wissen bereits, was mit diesem Traffic passiert. Er durchläuft 464XLAT, erreicht PLAT, und dort wird ihm eine öffentliche IPv4-Adresse aus dem Pool des Betreibers zugewiesen. Genau diese PLAT-Adresse wird zur ausgehenden Adresse Ihres Proxys. Sie entsteht nicht auf dem Gerät, nicht auf dem Modem, sondern im NAT64-Knoten im Kernnetz des Betreibers.

Deshalb hat ein mobiler Ausgang normalerweise IPv4. Das Gerät selbst lebt in IPv6, aber der Punkt, von dem der Traffic ins globale Internet zu IPv4-Websites austritt, ist PLAT, das IPv4 ausgibt.

Was die Zielwebsite letztendlich sieht

Die Zielwebsite sieht die öffentliche IPv4-Adresse des Betreibers. Das ist die Adresse eines CGN- oder NAT64-Knotens, hinter dem sich viele Teilnehmer verbergen können. Die Website sieht weder die interne IPv6-Adresse des Geräts noch die virtuelle IPv4 der CLAT-Schnittstelle. Nur die externe IPv4 von PLAT.

Das ist ein grundlegender Punkt. Mobile Proxys werden dafür geschätzt, dass ihre IPv4-Adressen wie Adressen echter Teilnehmer aussehen – weil sie technisch gesehen genau das sind. Viele reale Nutzer teilen sich dieselbe öffentliche IPv4 über einen einzigen PLAT. Aus Sicht der Zielwebsite ist eine solche Adresse nicht von einem gewöhnlichen Mobilfunkkunden zu unterscheiden.

Wann die Website IPv6 sehen kann

Aber nicht immer wird die ausgehende Adresse IPv4 sein. Wenn die Zielwebsite einen echten AAAA-Eintrag und eine vollwertige IPv6-Infrastruktur hat, verbindet sich das Gerät direkt über IPv6, unter Umgehung von PLAT. In diesem Fall sieht die Website die IPv6-Adresse aus dem Subnetz, das dem Teilnehmer zugewiesen wurde.

Deshalb kann ein und derselbe mobile Proxy verschiedenen Websites unterschiedliche Adresstypen liefern. Einer Website ohne IPv6 – öffentliche IPv4 über NAT64. Einer Website mit IPv6 – echte IPv6 direkt. Das ist kein Fehler, sondern das normale Verhalten eines Dual-Stack-Systems.

Checkliste zum Verständnis der ausgehenden Adresse

• Gerät im IPv6-Netz – ja, fast immer bei großen Betreibern
• Ausgehende Adresse zu IPv4-Websites – öffentliche IPv4 des PLAT-Knotens des Betreibers
• Ausgehende Adresse zu IPv6-Websites – echte IPv6 aus dem Teilnehmer-Subnetz
• Wo die Übersetzung stattfindet – im PLAT im Kernnetz, nicht auf dem Gerät
• Was die IPv4-Website sieht – gemeinsame IPv4-Adresse des Betreibers, von mehreren Teilnehmern geteilt

Dual-Stack und Happy Eyeballs: Warum die Prüfung mal IPv4, mal IPv6 anzeigt

Sie sind sicher schon darauf gestoßen, dass ein IP-Prüfdienst bei wiederholten Anfragen unterschiedliche Adressen anzeigt – mal IPv4, mal IPv6. Das ist verwirrend. Schauen wir uns an, warum das passiert.

Was ist Dual-Stack?

Dual-Stack bedeutet, dass das Gerät gleichzeitig über eine IPv4- und eine IPv6-Adresse verfügt und beide Protokolle nutzen kann. In der Mobilfunkumgebung wird dies oft durch einen IPv4v6-APN oder durch eine Kombination aus nativem IPv6 plus CLAT realisiert, das ein lokales IPv4 bereitstellt.

Wenn der Client die Wahl zwischen zwei Protokollen hat, stellt sich die Frage: Welches soll für eine bestimmte Verbindung verwendet werden? Früher wurde das grob gelöst und führte zu Verzögerungen. Wenn der IPv6-Pfad defekt war, wartete der Browser lange auf einen Timeout, bevor er auf IPv4 zurückfiel. Die Nutzer litten unter langsamen Ladezeiten.

Der Happy-Eyeballs-Algorithmus

Um dieses Problem zu lösen, wurde der Algorithmus Happy Eyeballs entwickelt, was man mit „glückliche Augen“ übersetzen könnte. Seine Essenz ist, nicht im Voraus zu raten, welches Protokoll besser ist, sondern einen Wettbewerb zu veranstalten.

So funktioniert er in groben Zügen:

1. Der Client fragt für die Domain sowohl den A- als auch den AAAA-Eintrag gleichzeitig ab
2. Nach Erhalt der Adressen beider Protokolle beginnt er fast parallel, Verbindungen aufzubauen
3. Der IPv6-Versuch startet in der Regel zuerst mit einem kleinen Vorsprung von einigen zehn oder hundert Millisekunden
4. Wenn die IPv6-Verbindung schnell hergestellt wird, wird sie verwendet
5. Wenn IPv6 trödelt oder nicht antwortet, wechselt der Client fast sofort auf IPv4
6. Der Gewinner des Rennens wird für die Datenübertragung genutzt, die verlierende Verbindung wird geschlossen

Der Algorithmus bevorzugt IPv6, wenn es gut funktioniert, lässt aber nicht zu, dass es die Arbeit verlangsamt, wenn etwas schiefgeht. Daher der Name – die Augen bleiben glücklich, weil es keine Verzögerungen gibt.

Warum die Prüfung unterschiedliche Adressen anzeigt

Jetzt ist klar, woher die Unbeständigkeit kommt. Wenn Sie einen IP-Prüfdienst öffnen, passiert Folgendes:

• Wenn der Dienst sowohl A- als auch AAAA-Einträge hat, kommt Happy Eyeballs zum Einsatz
• Je nachdem, welche Verbindung im Rennen zu einem bestimmten Zeitpunkt gewinnt, sehen Sie entweder IPv4 oder IPv6
• Netzwerkzustand, Auslastung, Verbindungscache – all das beeinflusst den Ausgang des Rennens
• Bei der nächsten Anfrage kann das Rennen anders ausgehen, und die Adresse ändert sich

Das ist kein Fehler des Proxys und keine Instabilität der Verbindung. Es ist das erwartete Verhalten von Dual-Stack unter der Steuerung von Happy Eyeballs. Wenn Sie ein vorhersagbares Ergebnis benötigen, müssen Sie die Protokollversion erzwingen – dazu mehr im nächsten Abschnitt.

Praktischer Einblick

Viele glauben fälschlicherweise, ein mobiler Proxy sei instabil, wenn sie im Prüfdienst springende Adressen sehen. In Wirklichkeit ist das ein gesundes Verhalten moderner Netzwerke. Wenn Sie nur den IPv4-Ausgang sehen möchten, rufen Sie Dienste ohne AAAA-Eintrag auf oder erzwingen Sie IPv4 auf Client-Ebene. Dann stabilisiert sich das Bild.

Praxis: Wie man den verwendeten Stapel einer Verbindung überprüft

Theorie ohne Praxis ist tot. Lassen Sie uns mit konkreten Befehlen ausrüsten, um mit eigenen Augen zu sehen, was mit Ihrer Verbindung passiert. Alle Werkzeuge sind standardmäßig in den meisten Systemen verfügbar.

Adressen der Schnittstellen anzeigen

Als Erstes sollten Sie sich ansehen, welche Adressen den Netzwerkschnittstellen zugewiesen sind. Für IPv6 verwenden Sie den Befehl:

• ip -6 addr – zeigt alle IPv6-Adressen auf allen Schnittstellen
• ip -4 addr – analog für IPv4
• ip addr – zeigt alles auf einmal

Achten Sie auf die Adresstypen. Globale IPv6-Adressen beginnen normalerweise mit 2000::/3. Lokale Link-Local-Adressen beginnen mit fe80 und werden nicht nach außen geroutet. Wenn Sie ein globales IPv6 sehen, hat das Gerät volle IPv6-Konnektivität. Wenn Sie auch eine private IPv4 auf einer separaten Schnittstelle sehen, ist das höchstwahrscheinlich die CLAT-Schnittstelle.

Erreichbarkeit mit Ping prüfen

Um zu prüfen, ob ein bestimmtes Protokoll funktioniert, hilft Ping:

• ping6 Adresse oder ping -6 Adresse – Prüfung der IPv6-Konnektivität
• ping -4 Adresse – Prüfung der IPv4-Konnektivität

Wenn Ping über IPv6 zu einem globalen Knoten funktioniert, haben Sie eine funktionierende IPv6-Konnektivität. Wenn nur IPv4 funktioniert, ist IPv6 entweder nicht konfiguriert oder nicht funktionsfähig.

Protokoll in curl erzwingen

Das stärkste Werkzeug zur Diagnose von Web-Traffic ist curl mit den Schlüsseln zur Protokollauswahl:

• curl -4 Adresse – erzwingt die Verwendung von IPv4
• curl -6 Adresse – erzwingt die Verwendung von IPv6
• curl -v Adresse – ausführlicher Modus, zeigt an, welche Adresse tatsächlich verwendet wurde

Durch die Kombination der Schlüssel können Sie genau ermitteln, welche Adresse die entfernte Website sieht. Senden Sie eine Anfrage mit -4 an einen Dienst, der Ihre IP zurückgibt, und Sie sehen den reinen IPv4-Ausgang. Senden Sie mit -6 – Sie sehen IPv6, falls verfügbar. Auf diese Weise trennen Sie den Einfluss von Happy Eyeballs und sehen das tatsächliche Bild für jedes Protokoll.

Test mit einem reinen IPv6-Endpunkt

Ein besonders wertvoller Trick ist, einen Dienst anzurufen, der ausschließlich über IPv6 erreichbar ist, ohne A-Eintrag. Wenn eine solche Verbindung zustande kommt, haben Sie garantiert native IPv6-Konnektivität und nicht nur Übersetzung. Wenn die Verbindung selbst bei erzwungenem -6 nicht zustande kommt, gibt es keinen echten IPv6-Ausgang nach außen, und Ihre gesamte IPv6-Aktivität dreht sich um das NAT64-Präfix.

Praktisches Prüfszenario:

1. Führen Sie curl -6 auf einem reinen IPv6-Endpunkt aus – prüfen Sie native IPv6-Konnektivität
2. Führen Sie curl -4 auf einem Dienst zur IP-Ermittlung aus – sehen Sie den ausgehenden IPv4 über PLAT
3. Vergleichen Sie die Adressen – wenn der IPv6-Ausgang aus dem Teilnehmer-Subnetz und der IPv4-Ausgang aus dem Pool des Betreibers stammt, liegt ein vollwertiger Dual-Stack mit 464XLAT vor

So erkennen Sie das NAT64-Präfix

Um herauszufinden, ob Ihr Netzwerk NAT64 verwendet, können Sie sich die synthetisierten Adressen ansehen. Fragen Sie einen AAAA-Eintrag für eine Domain ab, die definitiv kein IPv6 hat, und betrachten Sie die Antwort. Wenn eine Adresse zurückkommt, die mit 64:ff9b beginnt, ist das ein deutliches Zeichen für die Arbeit von DNS64 und NAT64. Einige Systeme haben eingebaute Mechanismen zur Erkennung des NAT64-Präfixes, die genau so funktionieren: Sie fragen einen bekannten Namen ab und sehen sich die Struktur der Antwort an.

Checkliste zur Stapeldiagnose

• ip -6 addr – gibt es ein globales IPv6?
• ip -4 addr – gibt es IPv4 und ist es eine private CLAT-Adresse?
• ping -6 zu einem globalen Knoten – funktioniert IPv6-Konnektivität?
• curl -4 auf IP-Dienst – welche IPv4 sieht die Website?
• curl -6 auf reinen IPv6-Endpunkt – gibt es natives IPv6?
• AAAA-Abfrage für eine reine IPv4-Domain – ist das Präfix 64:ff9b sichtbar?

Kompatibilität: Warum ein Subnetz /64 als einzelner Client wahrgenommen wird

Wir kommen zu einer Frage von enormer praktischer Bedeutung für alle, die mit mehreren Konten arbeiten. Es geht darum, wie Plattformen mit IPv6-Verbindungen umgehen.

Warum manche Plattformen IPv6 schlechter behandeln

Historisch haben viele große Plattformen ihre Betrugserkennungs- und Reputationssysteme für IPv4 aufgebaut. Aufgebaute Datenbanken, Reputations-Scores, Regeln zur Ratenbegrenzung – alles auf 32-Bit-Adressen zugeschnitten. IPv6 kam später, und nicht alle Systeme haben sich gleichermaßen angepasst.

Es gibt auch einen strukturellen Grund. Bei IPv4 ist jede Adresse eine knappe Ressource, hinter der normalerweise ein einzelner Knoten oder ein Knoten hinter NAT steht. Bei IPv6 gibt es so viele Adressen, dass ein einzelner Client seine Adresse problemlos tausendmal pro Stunde innerhalb seines Subnetzes wechseln kann. Das bricht mit der gewohnten Logik, dass Adresse = Client-Identifikator ist.

Daher haben Plattformen einen besonderen Umgang mit IPv6 entwickelt, und es ist entscheidend, diesen zu verstehen.

Wie ein Subnetz /64 interpretiert wird

Erinnern Sie sich an das, was wir im Abschnitt über die Grundlagen gesagt haben: Der Betreiber weist jedem Teilnehmer ein ganzes Subnetz /64 zu. Das ist eine gigantische Anzahl von Adressen für ein einziges Gerät.

Intelligente Reputationssysteme verstehen das. Anstatt jede einzelne IPv6-Adresse zu bewerten, aggregieren sie das gesamte Subnetz /64 und betrachten es als eine einzige Kennung. Die Logik ist einfach: Da das gesamte Subnetz einem Teilnehmer gehört, sollte es auch wie ein einzelner Client behandelt werden.

Das bedeutet, dass ein Wechsel der IPv6-Adresse innerhalb einer /64 für solche Plattformen keine neue Kennung erzeugt. Sie können die letzten Bits der Adresse beliebig oft ändern, aber aus Sicht der Plattform ist es immer noch derselbe Client, weil sich das Präfix /64 nicht ändert.

Was das für die Arbeit mit mehreren Konten bedeutet

Daraus ergibt sich eine wichtige praktische Schlussfolgerung. Wenn Sie versuchen, Konten über verschiedene IPv6-Adressen innerhalb eines Subnetzes /64 zu trennen, werden sie für fortgeschrittene Plattformen wie ein einziger Client aussehen. Unterschiedliche Adressen bringen keine Trennung, wenn das gemeinsame Präfix übereinstimmt.

Vergleichen Sie das mit dem Verhalten von IPv4 über NAT64. Die öffentliche IPv4 des PLAT-Knotens wird von vielen verschiedenen Teilnehmern des Betreibers gemeinsam genutzt. Aus Sicht der Plattform stehen hinter einer IPv4 dutzende reale Menschen. Das ergibt ein völlig anderes Bild der Durchmischung des Traffics.

Wichtige Erkenntnisse für Multi-Accounting:

• Das Ändern der letzten Bits von IPv6 innerhalb einer /64 ändert die Kennung für intelligente Plattformen nicht
• Die relevante Einheit für IPv6 ist das Präfix /64, nicht die einzelne Adresse
• Eine Trennung muss auf der Ebene verschiedener Subnetze /64 erfolgen, nicht durch Adressen innerhalb eines Subnetzes
• IPv4 über NAT64 vermischt Sie mit anderen Teilnehmern des Betreibers, was eine andere Reputationsdynamik ergibt
• Verstehen Sie immer, welches Protokoll tatsächlich für die Verbindung zu einer bestimmten Plattform verwendet wird

Praktische Empfehlung zur Protokollkontrolle

Angesichts all dessen ist es sinnvoll, zu kontrollieren, über welches Protokoll Ihre Verbindung zur Zielplattform läuft. Wenn Sie genau wissen, dass ein IPv4-Ausgang über den Mobilfunkanbieter erforderlich ist, erzwingen Sie IPv4 auf Client-Ebene. Dann erhalten Sie garantiert die gemeinsam genutzte öffentliche Adresse von PLAT, nicht das an Ihr Gerät gebundene IPv6-Subnetz.

Typische Fehler bei der Arbeit mit IPv6 in Mobilfunknetzen

Jetzt sammeln wir an einem Ort die häufigsten Missverständnisse und Fehler. Studieren Sie sie aufmerksam – jeder kann die Arbeit verderben oder zu falschen Schlussfolgerungen führen.

Fehler eins: Annehmen, dass eine IPv6-Adresse auf dem Telefon einen IPv6-Ausgang bedeutet

Viele sehen ein globales IPv6 auf der Schnittstelle und schließen daraus, dass der gesamte Traffic über IPv6 läuft. In Wirklichkeit wird der Traffic zu IPv4-Websites trotzdem am PLAT in IPv4 umgewandelt. IPv6 auf dem Gerät ist der Transport innerhalb des Betreibernetzes, keine Garantie für einen IPv6-Ausgang zu einer bestimmten Website.

Fehler zwei: Ausgehende Adresse und Schnittstellenadresse verwechseln

Die Adresse auf der Netzwerkschnittstelle des Geräts und die Adresse, die die Website sieht, sind zwei verschiedene Dinge. Dazwischen stehen CLAT und PLAT mit Übersetzung und NAT. Beurteilen Sie die ausgehende Adresse niemals nach dem, was ip addr anzeigt. Überprüfen Sie immer mit einem echten externen Dienst.

Fehler drei: Panik wegen springender Adressen bei der Prüfung

Wir haben bereits erklärt, dass Happy Eyeballs dafür sorgt, dass Dual-Stack mal IPv4, mal IPv6 anzeigt. Das ist normal. Betrachten Sie das nicht als Zeichen für einen defekten Proxy. Wenn Sie Stabilität benötigen, erzwingen Sie das Protokoll.

Fehler vier: Glauben, dass ein IPv6-Wechsel innerhalb der /64 eine neue Kennung ergibt

Das ist einer der teuersten Fehler im Multi-Accounting. Intelligente Plattformen aggregieren die gesamte /64. Das Ändern der letzten Bits der Adresse ist aus Sicht der Kontentrennung sinnlos. Die relevante Einheit ist das Präfix.

Fehler fünf: Den APN-Typ ignorieren

Der APN-Typ – IPv4, IPv6 oder IPv4v6 – bestimmt direkt, was mit dem Traffic passiert. Ohne zu wissen, welcher Typ verwendet wird, arbeiten Sie blind. Finden Sie immer die Sitzungskonfiguration heraus.

Fehler sechs: Konnektivität nur mit einem Protokoll testen

Wenn Sie nur IPv4 oder nur IPv6 testen, erhalten Sie ein unvollständiges Bild. Eine echte Diagnose erfordert die separate Prüfung beider Protokolle mit den Schlüsseln -4 und -6 sowie die Ansprache eines reinen IPv6-Endpunkts.

Fehler sieben: NAT64-Präfix mit einer echten IPv6-Website verwechseln

Eine synthetisierte Adresse mit dem Präfix 64:ff9b sieht aus wie IPv6, aber dahinter steht ein IPv4-Server. Wenn Sie sich über eine solche Adresse verbinden, gehen Sie tatsächlich über NAT64 zu einem IPv4-Server, nicht zu einem echten IPv6-Knoten. Ziehen Sie keine Schlüsse über natives IPv6 einer Website aus der Tatsache einer synthetisierten Adresse.

Fehler acht: CLAT und PLAT für dasselbe halten

CLAT lebt auf dem Gerät und führt zustandslose Übersetzung für Apps durch. PLAT lebt im Netz des Betreibers und führt zustandsbehaftete Übersetzung mit NAT durch. Das sind verschiedene Komponenten mit unterschiedlichen Aufgaben. Die Verwechslung erschwert das Verständnis, wo genau die ausgehende Adresse entsteht.

Werkzeuge und Ressourcen für die Arbeit mit dem Protokollstapel

Lassen Sie uns ein Arsenal an Werkzeugen zusammenstellen, die Ihnen helfen, den Netzwerkstapel in der Mobilfunkumgebung zu diagnostizieren und zu verstehen. Alle sind Standard und erfordern keine Exotik.

Kommandozeile

• ip addr und seine Varianten ip -4 addr, ip -6 addr – grundlegendes Werkzeug zum Anzeigen von Schnittstellenadressen
• ping und ping6 – Prüfung der Konnektivität für ein bestimmtes Protokoll
• curl mit den Schlüsseln -4 und -6 – das Hauptwerkzeug zur Diagnose von Webverbindungen und zur Überprüfung der ausgehenden Adresse
• traceroute und traceroute6 – Routenverfolgung, hilft zu sehen, über welche Knoten der Traffic läuft
• dig und nslookup – DNS-Abfragen zur Prüfung von A- und AAAA-Einträgen, Erkennung synthetisierter Adressen
• ip route – Anzeige der Routing-Tabelle für beide Protokolle

Online-Prüfdienste

• Dienste zur Ermittlung der externen IP – zeigen, was die entfernte Website sieht
• Reine IPv6-Testendpunkte – prüfen native IPv6-Konnektivität
• Dienste, die IPv4 und IPv6 getrennt anzeigen – helfen, Dual-Stack zu erkennen
• Tools zur Prüfung der IPv6-Unterstützung einer Domain – zeigen das Vorhandensein eines AAAA-Eintrags

DNS-Diagnose

DNS-Abfragen helfen zu verstehen, ob DNS64 arbeitet. Fragen Sie einen AAAA-Eintrag für eine Domain ab, die kein IPv6 hat, und betrachten Sie die Struktur der Antwort. Das Vorhandensein des Präfixes 64:ff9b verrät die Arbeit der Synthese. Dies ist der direkteste Weg, um das Vorhandensein des NAT64-Mechanismus im Netzwerk zu bestätigen.

Framework für die systemische Stapeldiagnose

Ich schlage ein schrittweises Framework vor, das Sie bei der ersten Bekanntschaft mit einem Mobilfunknetz durchführen sollten:

1. Bestandsaufnahme der Adressen. Führen Sie ip addr aus, ermitteln Sie das Vorhandensein eines globalen IPv6 und die Art des IPv4
2. CLAT identifizieren. Suchen Sie nach einer virtuellen Schnittstelle mit privater IPv4 – das ist ein Zeichen für 464XLAT
3. NAT64 prüfen. Fragen Sie einen AAAA-Eintrag für eine reine IPv4-Domain ab, suchen Sie nach dem Präfix 64:ff9b
4. Natives IPv6 testen. curl -6 auf einen reinen IPv6-Endpunkt
5. Ausgehende IPv4 ermitteln. curl -4 auf einen Dienst zur IP-Ermittlung
6. Ausgehende IPv6 ermitteln. curl -6 auf einen Dienst, der IPv6 unterstützt
7. Dual-Stack-Verhalten analysieren. Normale Anfrage ohne Protokollerzwingung, Beobachtung von Happy Eyeballs

Wenn Sie alle sieben Schritte durchlaufen haben, erhalten Sie ein umfassendes Bild: Welche Art von Konnektivität das Netzwerk hat, ob die Übersetzung funktioniert, welche Adressen verschiedene Website-Typen sehen und wie sich der Dual-Stack verhält. Das ist Ihr Standard-Audit.

Fallbeispiele und Ergebnisse: Analyse realer Szenarien

Abstrakte Mechanik lernt sich besser an konkreten Beispielen. Lassen Sie uns einige typische Szenarien durchgehen, die in der Praxis vorkommen.

Fall eins: Die Website sieht in den Logs eine IPv4 für viele Clients

Situation. Ein Analyst untersucht die Logs einer Website und stellt fest, dass von einer IPv4-Adresse eine riesige Anzahl verschiedener Nutzer mit unterschiedlichem Verhalten kommt. Der erste Gedanke – das ist ein Proxy oder ein Botnetz.

Analyse. In Wirklichkeit handelt es sich um die klassische öffentliche IPv4 eines NAT64- oder CGN-Knotens eines großen Mobilfunkbetreibers. Hinter einer solchen Adresse stehen tatsächlich Dutzende oder Hunderte echter Teilnehmer. Ihr Traffic verlässt das Netz über einen einzigen PLAT. Das ist keine Anomalie, sondern der normale Betrieb von 464XLAT unter den Bedingungen der IPv4-Knappheit.

Fazit. Mobilfunkkunden nur anhand ihrer IPv4-Adresse zu bewerten, ist ineffizient. Eine Adresse ist in der Mobilfunkumgebung nicht gleich ein Nutzer. Diese Besonderheit macht mobile IPv4-Adressen so charakteristisch – eine hohe Dichte an echten Nutzern hinter einer Adresse.

Fall zwei: Unbeständige Antwort eines Prüfdienstes

Situation. Ein Betreiber eines mobilen Proxys beschwert sich, dass der IP-Prüfdienst mal IPv4, mal IPv6 anzeigt, und schließt daraus auf eine Instabilität des Proxys.

Analyse. Der Prüfdienst hat sowohl A- als auch AAAA-Einträge. Der Client arbeitet im Dual-Stack. Jede Anfrage löst Happy Eyeballs aus, und je nach Ausgang des Rennens wird ein anderer Adresstyp zurückgegeben. Der Proxy funktioniert absolut stabil, nur das vom Algorithmus gewählte Protokoll ändert sich.

Lösung. Erzwingen Sie das Protokoll mit curl -4 oder entsprechenden Client-Einstellungen. Nach der Fixierung auf IPv4 wurde die Adresse vorhersagbar. Das Stabilitätsproblem erwies sich als eingebildet.

Fall drei: Konten wurden trotz unterschiedlicher IPv6-Adressen verknüpft

Situation. Arbeit mit mehreren Konten über IPv6, jedem Konto wurde eine separate IPv6-Adresse zugewiesen. Dennoch verknüpft die Plattform die Konten miteinander.

Analyse. Alle zugewiesenen Adressen befanden sich innerhalb eines einzigen Subnetzes /64, das der Betreiber dem Gerät zugewiesen hatte. Ein fortschrittliches Reputationssystem aggregierte die gesamte /64 und interpretierte sie als eine einzige Kennung. Unterschiedliche Adressen innerhalb eines Präfixes brachten keine Trennung.

Fazit. Für IPv6 ist die relevante Einheit das Präfix /64, nicht die einzelne Adresse. Eine Trennung erfordert unterschiedliche Präfixe. In diesem Fall wäre es sinnvoller gewesen, über den IPv4-Ausgang von NAT64 zu arbeiten, wo der Traffic mit anderen Teilnehmern des Betreibers vermischt wird.

Fall vier: Eine App, die kein IPv6 kann

Situation. Eine alte App greift direkt auf ein IPv4-Literal zu und müsste in einem reinen IPv6-Netz eigentlich kaputtgehen. Aber sie funktioniert.

Analyse. Auf dem Gerät läuft CLAT. Die App sendet ein IPv4-Paket an die virtuelle Schnittstelle, CLAT übersetzt es in IPv6, dann geht das Paket über PLAT ins IPv4-Internet. Die App lebt in der Illusion eines vollwertigen IPv4 und ahnt nichts von der Übersetzung. Das ist genau die Aufgabe, für die CLAT existiert.

Fazit. 464XLAT gewährleistet die Kompatibilität für veraltete Apps transparent. Deshalb hat die Umstellung der Betreiber auf IPv6 das Ökosystem der IPv4-Software nicht zerstört.

FAQ: Häufig gestellte Fragen

Warum zeigt mein Handy IPv6, aber die Website in den Logs IPv4?

Weil der Austausch im PLAT-Knoten im Kernnetz des Betreibers stattfindet. Das Gerät sendet Traffic per IPv6, aber beim Austritt zu einer IPv4-Website übersetzt der NAT64-Knoten das Paket in IPv4 und setzt die öffentliche Adresse des Betreibers ein. Die Website sieht genau diese ausgehende IPv4, nicht die interne IPv6 des Geräts.

Was ist das Präfix 64:ff9b und woher kommt es?

Es ist ein standardisiertes, allgemein bekanntes Präfix für die NAT64-Übersetzung. DNS64 verwendet es, um künstliche IPv6-Adressen aus IPv4-Adressen von Websites ohne AAAA-Eintrag zu synthetisieren. Die letzten 32 Bits einer solchen Adresse enthalten die echte IPv4, die PLAT bei der Übersetzung extrahiert.

Worin unterscheidet sich CLAT von PLAT?

CLAT arbeitet auf dem Gerät und führt eine zustandslose Übersetzung von IPv4 in IPv6 für Apps durch, die IPv4 benötigen. PLAT arbeitet im Netzwerk des Betreibers und führt eine zustandsbehaftete Übersetzung von IPv6 in IPv4 mit NAT durch, wobei es eine öffentliche Adresse einsetzt. CLAT löst die Kompatibilität auf dem Gerät, PLAT die Kompatibilität mit dem IPv4-Internet.

Warum zeigt der IP-Prüfdienst beim Aktualisieren unterschiedliche Adressen?

Aufgrund des Happy-Eyeballs-Algorithmus in einer Dual-Stack-Umgebung. Wenn der Prüfdienst sowohl über IPv4 als auch über IPv6 erreichbar ist, startet der Client ein Rennen der Verbindungen, und zu verschiedenen Zeitpunkten gewinnt ein anderes Protokoll. Das ist normales Verhalten, kein Fehler. Erzwingen Sie das Protokoll mit einem Schlüssel für ein stabiles Ergebnis.

Wie erkenne ich, ob ich einen echten IPv6-Ausgang habe und nicht nur NAT64?

Rufen Sie einen Endpunkt auf, der ausschließlich über IPv6 erreichbar ist, mit dem Befehl curl -6. Wenn die Verbindung zustande kommt, haben Sie native IPv6-Konnektivität. Wenn sie auch bei erzwungenem -6 nicht funktioniert, gibt es keinen echten IPv6-Ausgang, und Ihre gesamte IPv6-Aktivität dreht sich um das synthetisierte NAT64-Präfix.

Warum hilft das Ändern der IPv6-Adresse nicht, Konten zu trennen?

Weil der Betreiber dem Gerät ein ganzes Subnetz /64 zuweist und fortgeschrittene Plattformen dieses gesamte Subnetz als eine einzige Kennung aggregieren. Das Ändern der letzten Bits der Adresse ändert das Präfix nicht, daher ist es für die Plattform immer noch derselbe Client. Die relevante Einheit ist die /64, nicht die einzelne Adresse.

Warum hat ein mobiler Proxy normalerweise einen IPv4-Ausgang und keinen IPv6?

Weil die meisten Zielwebsites keine IPv6-Infrastruktur haben und der Traffic über NAT64 läuft. Der PLAT-Knoten übersetzt die Pakete in IPv4 und weist eine öffentliche Adresse des Betreibers zu. Diese Adresse wird zum Ausgang. Bei Websites mit echtem AAAA-Eintrag kann der Proxy auch direkt per IPv6 ausgehen.

Wie erzwinge ich, dass der Client eine bestimmte Protokollversion verwendet?

Auf curl-Ebene verwenden Sie die Schlüssel -4 für IPv4 und -6 für IPv6. Viele Anwendungen und Bibliotheken haben ähnliche Einstellungen zur Protokollpräferenz. Sie können auch über die Systemeinstellungen zur Priorität der Adressrichtlinie steuern. Das deaktiviert die Nichtdeterminiertheit von Happy Eyeballs und ergibt einen vorhersagbaren Ausgang.

Was sieht die Zielwebsite bei einer Verbindung über ein Mobilfunknetz?

Wenn die Website nur IPv4 hat, sieht sie die öffentliche IPv4-Adresse des NAT64-Knotens des Betreibers, die von vielen Teilnehmern gemeinsam genutzt wird. Wenn die Website echtes IPv6 hat, sieht sie die IPv6-Adresse aus dem dem Teilnehmer zugewiesenen Subnetz. Die internen Adressen des Geräts und die virtuelle CLAT-Adresse sieht die Website nie.

Hat der APN-Typ Einfluss darauf, welche Adresse die Website sieht?

Indirekt ja. Der APN-Typ bestimmt, welche Protokolle dem Gerät zur Verfügung stehen. Bei IPv4v6 oder reinem IPv6 mit CLAT funktioniert die gesamte beschriebene Übersetzungsmechanik. Bei reinem IPv4-APN ist keine Übersetzung nötig, aber diese Variante kommt bei großen Betreibern aufgrund des Adressmangels selten vor.

Fazit: Das Wichtigste zur Mechanik von IPv6 in Mobilfunknetzen

Wir haben einen weiten Weg zurückgelegt. Begonnen mit dem Rätsel – Handy in IPv6, Website sieht IPv4 – und es vollständig gelöst. Lassen Sie uns die wichtigsten Erkenntnisse festhalten.

Erstens und vor allem. Der Mangel an IPv4-Adressen hat die Betreiber zur Umstellung auf IPv6 gezwungen. Die Geräte leben in einer IPv6-Umgebung, oft ohne öffentliches IPv4 auf der Funkschnittstelle. Die Kompatibilität mit dem alten IPv4-Internet wird durch die Technologie 464XLAT sichergestellt.

Zweitens. 464XLAT besteht aus zwei Übersetzern. CLAT auf dem Gerät wandelt den IPv4-Traffic der Apps in IPv6 um. PLAT im Netzwerk des Betreibers wandelt IPv6 zurück in IPv4 und weist eine öffentliche Adresse zu. Genau in PLAT entsteht die ausgehende IPv4-Adresse, die die Website sieht.

Drittens. NAT64 und DNS64 arbeiten paarweise. DNS64 synthetisiert IPv6-Adressen aus IPv4 für Websites ohne AAAA-Eintrag, indem es das Präfix 64:ff9b verwendet. NAT64 in Gestalt von PLAT bringt die Pakete an diese Adressen zu den echten IPv4-Servern. Zusammen machen sie das gesamte IPv4-Internet für ein reines IPv6-Gerät erreichbar.

Viertens. Dual-Stack und Happy Eyeballs erklären, warum die Prüfung mal das eine, mal das andere Protokoll anzeigt. Der Client veranstaltet ein Rennen der Verbindungen und wählt den Gewinner. Für Stabilität erzwingen Sie das Protokoll mit den Schlüsseln -4 oder -6.

Fünftens. Für Multi-Accounting ist es entscheidend zu verstehen: Ein Subnetz /64 wird von intelligenten Plattformen als ein einzelner Client wahrgenommen. Das Ändern der Adresse innerhalb einer /64 ist für die Trennung nutzlos. IPv4 über NAT64 hingegen vermischt Sie mit anderen Teilnehmern des Betreibers.

Welche nächsten Schritte? Machen Sie es sich zur Gewohnheit, in jedem neuen Mobilfunknetz eine systemische Stapeldiagnose nach unserem Framework aus sieben Schritten durchzuführen. Beherrschen Sie curl mit den Schlüsseln -4 und -6 als Ihr Hauptwerkzeug. Überprüfen Sie die ausgehende Adresse immer mit einem echten externen Dienst, nicht anhand der Geräteschnittstelle. Und behalten Sie den Unterschied im Kopf zwischen dem, wo das Gerät lebt, und dem, wo der Traffic tatsächlich ins Internet austritt.

Das Verständnis dieser Mechanik verwandelt Sie von einem Nutzer, der über springende Adressen rätselt, in einen Ingenieur, der genau weiß, was mit jedem Paket passiert. Und Wissen ist bekanntlich Kontrolle. Möge dieser Artikel Ihre Spickzettel für die Funktionsweise von IPv6 in Mobilfunknetzen sein. Kehren Sie zu ihm zurück, wann immer Sie auf ein weiteres Netzwerkrätsel stoßen – und es wird aufhören, ein Rätsel zu sein.