Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Was die Branche bei der IPv6-Einführung noch immer falsch macht
IPv6 ist schon lange genug verfügbar, dass es keine vernünftige technische Abkürzung mehr ist, es als Nebensache zu behandeln. Trotzdem verhalten sich viele IP-bezogene Werkzeuge noch immer so, als sei IPv4 der eigentliche Datenverkehr und IPv6 die Ausnahme, um die man sich kümmert, wenn Zeit übrig bleibt. Das zeigt sich im Kleinen: Logik für Ratenlimits, die um Adressblöcke im IPv4-Stil herum geschrieben ist, ohne ein gleichwertiges, durchdachtes Konzept für IPv6, oder Dokumentation, die in ihren Beispielen stillschweigend ein IPv4-Adressformat voraussetzt und die Verarbeitung von IPv6 als stillschweigenden Nachgedanken behandelt.
Wir haben die Kontingenterfassung auf Netzwerkebene bewusst um beide Adressfamilien herum gebaut, nicht als IPv6-Flicken auf einer IPv4-zentrierten Logik. Jedes Netzwerk erhält ein gemeinsames kostenloses Kontingent, ein /24-Block für IPv4-Adressen und ein /48-Block für IPv6-Adressen, und beide werden als gleichwertige Gruppierungen behandelt, statt dass eine das primäre Design ist und die andere ein Zugeständnis. Der Unterschied zwischen einem /24 und einem /48 ist nicht willkürlich. Er spiegelt wider, wie jede Adressfamilie von den regionalen Internet-Registrierungsstellen, die Blöcke vergeben, tatsächlich zugeteilt wird, sodass die Gruppierung in beiden Fällen praktisch dasselbe bedeutet: ein Netzwerk angemessener Größe.
Hier Fehler zu machen, wiegt gerade für eine API für Standort- und IP-Daten schwer, denn die gesamte Kategorie netzwerk- und IP-basierter Abfragen hängt davon ab, beide Adressformate korrekt zu parsen, abzugleichen und mit Ratenlimits zu versehen. Eine API, die IPv6 stillschweigend als Randfall behandelt, erzeugt eher inkonsistentes Kontingentverhalten, falsche Netzwerkgruppierungen oder schlicht Parsing-Fehler für IPv6-Verkehr, und das genau zu einer Zeit, in der die IPv6-Nutzung weiter wächst und ein nennenswerter Anteil echter Anfragen darüber statt über IPv4 ankommt.
Ein Grund, warum branchenweit zu wenig in dieses Thema investiert wird, ist, dass IPv4-Verkehr für viele Dienste noch immer einen großen Teil des Gesamtvolumens ausmacht, wodurch IPv6-Randfälle im Verhältnis zum Aufwand, sie wirklich richtig zu lösen, als niedrige Priorität erscheinen. Wir finden, diese Überlegung unterschätzt den Trend zu stark. Ein Verkehrsanteil, der weiter wächst, ist mit einer Infrastruktur schlecht bedient, die ihn als dauerhafte Minderheit behandelt, und die Kosten, die IPv6-Verarbeitung richtig zu reparieren, steigen nur, je länger die Kernlogik eines Systems IPv4 als Standard voraussetzt.
Nichts davon ist eine dramatische Behauptung. Es ist die Bitte, IPv6 im tatsächlichen Design von Ratenlimits, Kontingenterfassung und Abfragelogik genauso ernst zu nehmen wie IPv4, und nicht nur in einem Compliance-Häkchen, das besagt, dass eine API IPv6-Adressen technisch ohne Syntaxfehler akzeptiert. Ein Adressformat zu akzeptieren und es mit derselben Sorgfalt zu behandeln wie das gängigere sind zwei verschiedene Leistungen, und viele Infrastrukturen in dieser Branche haben wirklich nur die erste geschafft.