IPv6-Geolokalisierung: warum sie hinter IPv4 zurückbleibt
Die Genauigkeit der IPv6-Geolokalisierung ist in der Regel geringer und weniger konsistent als bei IPv4, weil IPv6-Adressen in sehr großen Präfixen vergeben werden, sich auf Endgeräten häufig ändern und weit weniger Zeit hatten, die Messdaten zu sammeln, auf die Standortdatenbanken angewiesen sind.
Das heißt nicht, dass IPv6-Lookups nutzlos wären. Antworten auf Länderebene sind meist verlässlich, und die Netzwerkzuordnung ist exakt, weil sie aus Registerdaten stammt. Der schwächere Teil ist die Präzision auf Stadtebene, und genau dort werden Entwickler gerne überrascht. Dieser Artikel erklärt die Ursachen und was Sie in einer Anwendung dagegen tun können.
Warum IPv6-Standortdaten schwerer aufzubauen sind
Eine IPv4-Adresse ist eine einzelne knappe Ressource, weshalb Provider und Netzwerke sie tendenziell in kleine, geografisch saubere Blöcke aufteilen, und Messprojekte hatten Jahrzehnte Zeit, diese zu kartieren. IPv6 kehrt die Ökonomie um. Ein Privatkunde erhält üblicherweise ein /56- oder /64-Präfix, das für sich genommen mehr Adressen enthält als das gesamte IPv4-Internet, und ISPs halten Zuteilungen, die groß genug sind, um mit einer einzigen Ankündigung ein ganzes Land abzudecken.
Daraus folgt einiges. Erstens kann ein einzelner großer IPv6-Block Kunden in vielen Städten versorgen, sodass eine Datenbank, die dem ganzen Block einen Standort zuweist, für die meisten davon falsch liegt. Zweitens haben die Verfahren, die den Standort aus Latenz, aus Routing-Daten oder aus nutzerseitigen Korrekturen ableiten, weniger Stichproben pro Präfix. Drittens ist die Nummerierung innerhalb eines Präfixes nicht verlässlich an die Geografie gekoppelt: Zwei benachbarte /48-Blöcke können Kunden an entgegengesetzten Enden eines Landes zugeteilt sein.
Auch die schiere Dünnbesetzung spielt eine Rolle. Bei IPv4 kann man vernünftigerweise hoffen, einen großen Teil der aktiven Adressen beobachtet zu haben. Bei IPv6 ist fast jede Adresse einzigartig für einen Moment und ein Gerät, weshalb Datenbanken von Präfixen verallgemeinern müssen statt von einzelnen Hosts.
Privacy-Adressen, Mobilfunknetze und Tunnel
Endgeräte wechseln aus Datenschutzgründen meist ihre temporären IPv6-Adressen, sodass dasselbe Smartphone im Lauf eines Tages unter vielen Adressen innerhalb eines Präfixes auftauchen kann. Das ist gut für die Nutzer, bedeutet aber, dass jeder Ansatz, der sich eine bestimmte Adresse merken will, fragil ist. Stabil bleibt das Präfix, und ein guter Lookup arbeitet auf dieser Ebene.
Mobilfunkanbieter bringen eine weitere Ebene der Unsicherheit mit. Der Traffic eines Smartphones verlässt das Netz des Anbieters oft an einem regionalen Gateway, sodass die Adresse, die Sie sehen, der Region des Gateways entspricht und nicht dem Gerät. Dasselbe gilt für IPv4 hinter Carrier-Grade NAT, doch IPv6-Mobilfunkpräfixe sind häufig groß und über weite Gebiete geteilt. Unternehmensnetzwerke, VPNs und IPv6-Tunnelbroker können außerdem Präfixe ankündigen, die in einem Land registriert sind, während der Traffic in einem anderen entsteht. Unser Artikel warum ein IP-Standort ein Netzwerk beschreibt und keine Person behandelt diese Überlegung ausführlich.
Schließlich hinkt das Register der Realität hinterher. Ein Präfix, das zwischen Unternehmen oder Regionen neu vergeben wurde, kann sein altes Registrierungsland noch eine Weile behalten. Betrachten Sie das Registrierungsland daher als starken Hinweis und nicht als Beweis dafür, wo der Nutzer sitzt.
Was bei IPv6 verlässlich ist und was nicht
Verlässlich: das Origin-AS, die Organisation, die das Präfix hält, das registrierte Land und ob das Präfix ein reservierter Bereich oder ein Dokumentationsbereich ist. Diese Fakten stammen aus Routing- und Registerdaten und hängen nicht davon ab, den Aufenthaltsort eines Geräts zu erraten. Ungefähr: Stadt, Region, Zeitzone und alle Koordinaten. Betrachten Sie diese als Hinweis auf das vom Netzwerk versorgte Gebiet und nicht als Straßenadresse.
ipto akzeptiert im IP-Lookup IPv4 und IPv6 und liefert für beide dieselben Felder, darunter Land, Stadt, ASN, Organisation und die Flags is_vpn, is_tor, is_abuser, is_datacenter und bogon. Der IPv6-Bereichs- und ASN-Datensatz wird nach bestem Bemühen parallel zum IPv4-Datensatz aufgebaut und täglich aktualisiert, sodass die Abdeckung bei IPv6 dünner sein kann als bei IPv4, und ein fehlendes Stadtfeld ist ein normales Ergebnis, das Sie behandeln sollten. Wir nennen für keines der beiden Protokolle eine konkrete Genauigkeitsquote, und Sie sollten jedem gegenüber skeptisch sein, der das tut, ohne sein Testset zu beschreiben.
Mit der Unsicherheit planen
Praktische Regeln, die sich für Dual-Stack-Anwendungen bewähren:
- Verwenden Sie das Land für Entscheidungen im Compliance-Stil und die Stadt nur für weiche Personalisierung wie einen Standard-Wetterstandort oder ein vorausgefülltes Formularfeld.
- Bevorzugen Sie ASN und Organisation als Signal. Der ASN-Lookup zeigt den Inhaber und die angekündigten Bereiche eines Netzwerks, was über Protokollversionen hinweg stabil ist.
- Führen Sie einen Whois-Lookup über RDAP durch, wenn Sie statt einer Vermutung die registrierte Zuteilung, den Kontakt und die Daten eines Präfixes benötigen.
- Prüfen Sie Reverse-DNS, wenn ein Hostname existiert, da Carrier und Hosting-Unternehmen darin manchmal eine Stadt oder einen Flughafencode codieren. Betrachten Sie das nur als Hinweis.
- Lassen Sie Nutzer ihren Standort korrigieren und speichern Sie die Korrektur beim Konto statt bei der Adresse.
- Cachen Sie bei IPv6 nach Präfix statt nach einzelner Adresse, denn ein /64 gehört in der Regel einem einzelnen Teilnehmer oder Standort.
Testen Sie mit Ihrem eigenen Traffic. Ziehen Sie einen Tag IPv4- und IPv6-Adressen aus Logs, bei denen Sie den tatsächlichen Standort kennen, etwa Lieferadressen abgeschlossener Bestellungen, und vergleichen Sie. Die gemessene Lücke ist die Zahl, die für Ihr Produkt zählt, und sie unterscheidet sich je nach Land und Carrier-Mix.