Zusammenfassung

  • ARINs aktuelle Reg-RWS-Methode erlaubt für einen WhoWas-NET-Bericht eine IPv4- oder IPv6-Adresse; das ReadMe beschreibt ebenfalls IPv6-Netzbereiche. Beides belegt Schnittstelle und Format, nicht den Inhalt des erzeugten Archivs.
  • In ACSP 2025.4 und 2026.5 baten Nutzer um IPv6-Historie. ARIN überwies die Wünsche in die interne Priorisierung und schloss die öffentlichen Vorgänge, ohne Liefertermin oder gemeinsame Release-Kennung.
  • Ein datensparsamer Fähigkeitsbeleg könnte eine kontrollierte IPv6-Adresse mit Annahme, Ticketabschluss, Aufbewahrungshorizont, Objektklassen, bekannten Lücken, Version und Korrekturdatum verbinden.

Der erste Erfolg kommt zu früh, um die entscheidende Frage zu beantworten. Ein berechtigter Nutzer übergibt ARINs WhoWas-Methode eine IPv6-Adresse. Der Wert entspricht der erwarteten Form, der Dienst legt ein Ticket an, und die spätere Abholung des Berichts ist vorbereitet. Für die Eingabeschicht ist damit viel bewiesen.

Für die Geschichte hinter der Adresse ist noch nichts bewiesen.

Das angehängte Dokument kann eine vollständige Folge früherer Registrierungsänderungen enthalten. Es kann leer sein, weil nie ein öffentlicher Wechsel stattfand. Es kann erst nach dem gesuchten Ereignis beginnen, eine alte Beziehung zwischen Netz, Organisation und POC nicht enthalten oder für bestimmte IPv6-Kohorten dünner ausfallen. Ein erfolgreicher Aufruf unterscheidet diese Ursachen nicht.

ARINs heutige Dokumentation stellt die Ebenen so nah nebeneinander, dass eine vorschnelle Gleichsetzung naheliegt. In den Reg-RWS-Methoden muss das Feld IPADDRESS eine IPv4- oder IPv6-Adresse enthalten. Das WhoWas-ReadMe definiert Net Range als Bereich aus IPv4- oder IPv6-Adressen. Die Serviceseite verspricht berechtigten Nutzern historische Registrierungsinformationen für eine IP-Adresse oder ASN und bezeichnet den Bericht als gesamte öffentliche Historie der Ressource.

Gleichzeitig baten Community-Mitglieder im Mai 2025 und März 2026 ausdrücklich darum, IPv6-Historie in WhoWas aufzunehmen. ARIN nannte die Ergänzung nützlich und gab beide Vorschläge in die interne Priorisierung und Implementierungsplanung. Die ACSP-Vorgänge wurden anschließend geschlossen. Ein datierter Verweis auf eine ausgelieferte Version oder einen End-to-End-Test fehlt.

Das kann bedeuten, dass die Funktion nach der zweiten Antwort ausgerollt wurde und die aktuelle Dokumentation bereits den neuen Zustand beschreibt. Es kann bedeuten, dass Eingabe und Berichtsformat IPv6 beherrschen, die historische Population aber Grenzen hat. Möglich ist auch eine teilweise Abdeckung nach Zeitraum oder Objektart. Diese Recherche hatte keinen genehmigten WhoWas-Zugang und führte keine Abfrage aus. Sie behauptet daher weder Erfolg noch Ausfall. Sie stellt fest, dass der öffentliche Nachweis die drei Schichten nicht bindet.

Ein operativer Bruch brachte die Frage auf

ACSP 2025.4 wurde am 9. Mai eingereicht. Der Autor berichtete von einer nachgelagerten Stelle, deren IPv6-Ressource nicht mehr korrekt zugeordnet war. Er wollte frühere Registrierungsangaben finden und beschrieb WhoWas als Dienst, der nur Präfixabfragen für IPv4 unterstütze. Gewünscht war Funktionsgleichheit zwischen den Adressfamilien.

Der Fall zeigt, warum ein heutiger Whois- oder RDAP-Eintrag nicht reicht. Der aktuelle Datensatz beantwortet, was das Register jetzt veröffentlicht. Er rekonstruiert nicht automatisch, welche Organisation zu einem früheren Zeitpunkt mit einem Netz verbunden war, wann eine Registrierung entfernt wurde oder wie sich Kontaktrelationen änderten. Gerade nach Rückgabe, Entzug oder Neuzuordnung wird die Zeitachse zum eigentlichen Beweismittel.

Am 21. Mai 2025 erklärte ARIN, IPv6-Informationen seien eine nützliche Ergänzung. Der Wunsch werde in die Liste vorgeschlagener Verbesserungen aufgenommen, warte dort auf Priorisierung und gehe in den internen Prozess für Planung und Umsetzung. Danach erhielt der Vorgang den Status „Closed“. Dieser Status bezeichnet nach dem Begleittext den Abschluss des öffentlichen Vorschlagswegs, nicht die Produktionsfreigabe. Weder der Nutzer noch ARIN nannten einen Termin.

Am 31. März 2026 folgte ACSP 2026.5. Der Einreicher wollte die Geschichte von IPv6-Bereichen sehen, insbesondere wenn Organisationen mit entzogenem Adressraum arbeiteten, und erwartete Details wie bei IPv4 und ASN. ARIN verwies am 2. April auf den Vorschlag des Vorjahres und sagte, die Wiederholung werde bei der Priorisierung des Entwicklungsaufwands berücksichtigt. Auch dieser Vorgang ging in den internen Prozess und wurde geschlossen.

Die Wiederholung ist ein Nachfragebeleg, aber kein Produktionstest. Ein Nutzer kann einen stillen Rollout übersehen, eine notwendige Berechtigung nicht besitzen oder mit „IPv6-Unterstützung“ eine engere Lücke meinen. Auch ARINs Antwort benennt nicht, ob der noch zu bewertende Aufwand Parser, Berichtsgenerator, Datenmigration oder Beziehungsabdeckung betraf. Ohne gemeinsame Version bleibt der technische Umfang des Vorschlags unbestimmt.

Syntax, Schema und gespeicherte Ereignisse

Die Eingabeschicht ist sauber beschrieben. „Request WhoWas NET Report“ verlangt eine einzelne Adresse und akzeptiert weder einen Handle noch ein CIDR-Präfix als Ersatz. Bei Erfolg kommt ein Ticket Payload zurück. Später wird der Ticketstatus abgefragt und der angehängte Bericht geladen.

Damit existieren zwei getrennte Resultate. Zuerst wird die Anfrage angenommen. Danach erzeugt ein historisches System die Ausgabe. Der erste Erfolg sagt nicht, ob der zweite Vorgang Ereignisse findet, wie weit er zurückreicht oder welche Beziehungen er rekonstruiert. Ein gültiger leerer Bericht kann ebenso gut ein korrektes Ergebnis wie ein Hinweis auf eine Grenze sein.

Das Schema bildet die nächste Ebene. Im ReadMe kann Net Range IPv4 oder IPv6 aufnehmen; Ereignisse umfassen Erstellung, Änderung und Entfernung einer Registrierung. Der Bericht besitzt also die Sprache, um IPv6-Geschichte auszudrücken. Doch ein Schema ist keine Bestandsaufnahme. Felder können vor einer vollständigen Migration eingeführt werden. Dasselbe Format kann Datenkohorten mit unterschiedlicher Tiefe bedienen. Repräsentierbarkeit ist nicht Vollständigkeit.

Die breite Zusage steht auf der WhoWas-Seite. Eine Adresse kann im Laufe der Zeit Teil mehrerer Netze gewesen sein, diese können an verschiedene Organisationen vergeben worden sein, und jede Organisation kann eigene POCs besitzen. Deshalb sei der Bericht größer und komplexer als eine aktuelle Whois-Antwort. Die Seite veröffentlicht jedoch keine getrennte IPv4/IPv6-Matrix, keinen frühesten IPv6-Zeitpunkt und keine Testadresse mit bekannter Vergangenheit.

Wer aus dem Beispiel 2001:DB8:: eine vollständige Historie ableitet, macht aus einem Parser eine Archivprüfung. Wer aus dem Vorschlag von 2026 auf völlige Nichtverfügbarkeit schließt, macht aus einem Verwaltungsvorgang eine Live-Messung. Beide Schlüsse sind nicht belegt. Jede Behauptung braucht die passende Prüfebene.

Eine leere Historie braucht einen Grund

Bei Archiven ist Abwesenheit das schwierigste Ergebnis. Vielleicht hat die Adresse tatsächlich nie eine öffentliche Änderung erlebt. Vielleicht lag sie früher in einem anders begrenzten Elternetz. Vielleicht fällt das Ereignis vor den Aufbewahrungsbeginn. Vielleicht wurde die Netzzeile migriert, nicht aber die frühere Organisations- oder Kontaktbeziehung. Vielleicht fehlt die Berechtigung. Vielleicht ist die IPv6-Funktion noch nicht für diese Klasse verfügbar.

Für eine Abuse-Ermittlung entscheidet der damalige Verantwortliche, nicht der heutige. Bei einem Transfer zählt die Kette zwischen früherem und neuem Inhaber. Ein Betreiber muss einem Kunden erklären können, warum eine Zuweisung verschwunden ist. Juristische Prüfungen brauchen einen datierten öffentlichen Registerzustand. „Kein Ereignis“ und „kein gespeichertes Ereignis“ führen in all diesen Fällen zu unterschiedlichen Handlungen.

„Entire public history“ hat daher notwendige Grenzen. Öffentlich schließt geschützte Angaben aus. Geschichte beginnt an einem Aufbewahrungs- oder Migrationspunkt. Vollständig kann alle erhaltenen öffentlichen Ereignisse meinen, nicht jede reale Tatsache über Netzbetrieb. Eine klare Definition schwächt das Versprechen nicht; sie macht es professionell verwendbar.

Ohne solche Gründe entsteht privates Erfahrungswissen. Teams notieren, dass ältere Jahre unsicher seien, bestimmte POC-Verbindungen fehlten oder ein leerer IPv6-Bericht grundsätzlich eskaliert werden müsse. Dieses Wissen hat keine Version und keine belastbare Herkunft. Es kann eine bereits behobene Lücke fortschreiben oder eine aktuelle verdecken.

Planungsübersicht und Release-Liste sind keine Laufzeitprüfung

ARIN bezeichnet die Seite „Planned Functionality“ selbst als allgemeinen Überblick. Für 2026 nennt sie Hochverfügbarkeit, technischen Schuldenabbau, policy- und gebührenbedingte Änderungen, Website-Verbesserungen, SOC 2 Type 2 sowie Routing-Security-Produkte. IPv6-Historie in WhoWas erscheint nicht als eigener Punkt.

Die Release-Seite führt den ursprünglichen WhoWas-Dienst im März 2012 und WhoWas-Berichte über Reg-RWS im Mai 2012. In den sichtbaren Einträgen für 2025 und 2026 wird eine IPv6-Erweiterung nicht ausdrücklich genannt. Mehrere Releases fassen allerdings kleinere Verbesserungen und Fehlerbehebungen zusammen.

Aus dieser Stille folgt kein Nicht-Rollout. Ein Überblick ist kein vollständiger Backlog, eine Release-Zusammenfassung kein Commit-Verlauf. Eine kleine Funktion kann unter einem größeren Paket erscheinen oder zwischen datierten Einträgen dokumentiert werden. Feststellbar ist nur, dass die ausgewerteten Seiten keine gemeinsame öffentliche Referenz liefern.

Falls die Fähigkeit bereits produktiv ist, würde ein Link von den ACSP-Seiten auf Version und Dokumentationsänderung reichen. Bei Teilabdeckung wäre eine Matrix nach Zeitraum und Objektklasse besser als ein Ja/Nein-Siegel. Beschreibt die heutige Dokumentation nur die gewünschte Schnittstelle, sollte sie Eingabe und verfügbare Historie auseinanderhalten.

Der Testfall sollte niemandem gehören

WhoWas enthält historische Organisations- und Kontaktdaten. Der genehmigungspflichtige Zugang ist deshalb nachvollziehbar. Ein öffentlicher Beleg sollte keinen echten Kundenbericht offenlegen, sondern eine kontrollierte IPv6-Dokumentationsressource verwenden. Deren erwartete Sequenz könnte Netz-Erstellung, Organisationswechsel, POC-Änderung und Entfernung oder Ersetzung umfassen.

Der Fähigkeitsbeleg würde Version, Datum und Testadresse nennen. Er hielte fest, ob die Eingabe angenommen, das Ticket abgeschlossen, ein Anhang erzeugt, das älteste erwartete Ereignis gefunden und jede vorgesehene Objektklasse ausgegeben wurde. Bekannte Migrationslücken und zeitliche Grenzen kämen in eine eigene Rubrik. Spätere Korrekturen würden den alten Beleg nicht überschreiben, sondern ergänzen.

Ein Hash über Szenario und erwartetes Ergebnis könnte die Provenienz sichern. Das ist kein technisches Schmuckstück. Eine API-Adresse bleibt oft gleich, während Parser, Archivpopulation und Berichtsgenerator wechseln. Der Beleg muss zeigen, welche Generation geprüft wurde und ob sich die Erwartung nachträglich änderte.

Er wäre keine Garantie für jeden realen Datensatz. Er würde weder jede Registerzeile zertifizieren noch Massenabfragen erlauben, die ARIN ausdrücklich nicht vorsieht. Er belegt nur den End-to-End-Satz: Unter einer bekannten Version traf ein gültiger IPv6-Eingang auf einen fertigen Bericht mit bekannten historischen Ereignissen.

Zugangskontrolle konzentriert die Beweismacht

ARIN steuert Berechtigung, Archiv, Berichtserzeugung, Dokumentation, Releases und ACSP. Der Nutzer bestimmt die untersuchte Ressource und zusätzliche Belege. Eine frühere Organisation kann in der Historie erscheinen, ohne über Aufbewahrung und Zugriff zu entscheiden. Die Öffentlichkeit sieht die Beschreibung, nicht das Resultat.

Diese Asymmetrie ist für sensible historische Daten vernünftig. Sie bedeutet zugleich, dass ARIN die Unklarheit am sichersten beseitigen kann. Einzelne Nutzer sollten keine realen Anhänge veröffentlichen, um eine Funktion zu beweisen. Ein synthetischer Fall beim Register ist datensparsamer und vergleichbarer.

Der fehlende Zusammenhang dürfte zwischen Zuständigkeiten liegen. API-Dokumentation pflegt Parameter, Datenbetrieb pflegt Migrationen, ACSP beendet die öffentliche Phase, Release-Autoren wählen sichtbare Änderungen. Jedes Dokument kann lokal korrekt sein. Der Nutzer erlebt jedoch eine Kette und muss wissen, ob ihre Glieder zur selben Version gehören.

Die belastbare Aussage bleibt bewusst schmal

Die Quellen belegen nicht, dass WhoWas IPv6 ablehnt; die aktuelle Methode erlaubt die Adresse. Sie belegen ebenso wenig eine vollständige IPv6-Historie, weil kein kontrollierter Bericht vorliegt und hier kein berechtigter Zugriff stattfand. Eine Frist wurde nicht zugesagt, also ist kein Verzug nachweisbar. „Closed“ ist kein Synonym für „Released“.

Belegt ist etwas Präziseres. Nutzer baten 2025 und 2026 um IPv6-Geschichte. ARIN behandelte sie als nützliche, zu priorisierende Verbesserung. Die heutige Schnittstelle und das Format sprechen bereits IPv6. Den gemeinsamen Release- oder Testbeleg veröffentlicht der untersuchte Bestand nicht.

Ein Fähigkeitsbeleg schließt genau diese Lücke. Ist die Funktion geliefert, macht er den Abschluss sichtbar. Ist sie noch in Arbeit, definiert er einen beobachtbaren Endpunkt ohne erfundenen Termin. Ist sie teilweise vorhanden, macht er Grenzen entscheidungsfähig. Dann muss ein korrekt eröffnetes Ticket nicht länger beweisen, was nur das Archiv selbst beweisen kann.

Quellen