Auf der Website der Internet Engineering Task Force (IETF) ist ein Entwurf für ein Internet Protocol Version 8 (IPv8) erschienen. Der Draft versteht sich als radikale Neuausrichtung nach IPv6 und hat in der Netz- und Sicherheitscommunity eine intensive Debatte ausgelöst. Neben technischen Fragen sorgt insbesondere der mutmaßlich umfangreiche Einsatz generativer KI bei der Erstellung des Dokuments für Diskussionen.
Adresskonzept von IPv8: 64-Bit-Raum zwischen IPv4 und IPv6
Der IPv8-Entwurf schlägt vor, die IP-Adresslänge auf 64 Bit zu erweitern und dabei die aus IPv4 bekannte Punktnotation beizubehalten. Statt vier Oktetten wie bei 1.1.1.1 wären es acht Oktette im Format 1.1.1.1.1.1.1.1, jeweils mit Werten von 0 bis 255. Damit entstünde ein Adressraum von 264 Adressen, also rund 18,4 Quintillionen eindeutigen IPs – deutlich mehr als die etwa 4,29 Milliarden Adressen von IPv4, aber weit unter dem 128‑Bit‑Adressraum von IPv6 mit ca. 3,4×1038 Adressen.
Versprochene Rückwärtskompatibilität zu IPv4 und ihre Grenzen
Als zentrales Argument führt der Entwurf an, IPv4 als echtes Teilmengenformat von IPv8 zu behandeln: Ein spezieller Präfix (Route-Prefix 0) soll signalisieren, dass ein Address-Block wie ein klassischer IPv4‑Adressraum interpretiert wird. In der Praxis würde jedoch jedes bestehende Gerät ein Paket mit dem Feld IP-Version = 8 als unbekannt einstufen und im Regelfall verwerfen. Router, Switches, Betriebssysteme und Firewalls müssten ihre Netzwerk-Stacks aktualisieren, um IPv8 überhaupt verarbeiten zu können.
Der Draft selbst verlangt zudem neue Socket-APIs, neue DNS-Record-Typen, angepasste Varianten von ARP und ICMP sowie Erweiterungen für Routing-Protokolle wie BGP, OSPF oder IS-IS. Diese Änderungen stehen im Widerspruch zum Versprechen, vorhandene Infrastruktur könne unverändert weiterbetrieben werden, und würden in der Realität eine groß angelegte Migrationswelle mit entsprechenden Betriebs- und Sicherheitsrisiken auslösen.
Zone Server und OAuth2: Anwendungssicherheit im Netzwerkkern
Weit über die Adressierung hinaus entwirft IPv8 ein völlig neues Architekturmodell. Funktionen wie Telemetrie, Authentifizierung, Namensauflösung, Zeitsynchronisation, Zugriffskontrolle und Adressübersetzung sollen in einer zentralen Plattform, dem Zone Server, gebündelt werden. Jeder verwaltete Netzwerkknoten soll sich über OAuth2 mit JWT‑Tokens authentifizieren, bevor er am Verkehr teilnehmen darf.
Damit werden Mechanismen, die bisher typischerweise auf dem Anwendungs-Layer (Schicht 7) des OSI-Modells liegen, in den Netzwerk-Layer (Schicht 3) verlagert. Ein Großteil der heute eingesetzten Infrastruktur – etwa einfache Access-Switches, IoT-Geräte oder industrielle Steuerungssysteme – ist nicht darauf ausgelegt, komplexe Protokolle wie OAuth2 zu sprechen oder JSON-Web-Tokens kryptografisch zu verifizieren. Dies würde Hardware-Upgrades, stärkere CPUs und aufwändigere Software mit sich bringen.
Erweitere Angriffsfläche durch Zentralisierung und Tokenpflicht
Aus Sicht der Cybersicherheit erhöht das vorgeschlagene Design die Angriffsoberfläche deutlich. Zentralisierte Zone Server werden zu attraktiven Single Points of Failure: Ein erfolgreicher Angriff auf den Server oder die zugehörige OAuth-Infrastruktur könnte erlauben, Tokens zu manipulieren, große Netzsegmente zu deautorisieren oder Traffic zielgerichtet umzuleiten. Gleichzeitig steigt die Komplexität des Schlüssel- und Token-Managements erheblich – ein Bereich, der bereits heute in vielen Organisationen zu Fehlkonfigurationen und Sicherheitsvorfällen führt.
Bewertung des IPv8-Entwurfs durch die Fachcommunity
Status eines Internet-Drafts und Rolle der IETF
Wichtig ist der formale Rahmen: Ein Internet-Draft bei der IETF ist weder Standard noch offizieller Standard-Entwurf. Jeder kann einen Draft einreichen; seine Veröffentlichung bedeutet weder Billigung noch eine Priorisierung durch IETF-Arbeitsgruppen. Internet-Drafts verfallen automatisch nach etwa sechs Monaten, wenn sie nicht aktiv weiterentwickelt werden. Für Unternehmen ist daher entscheidend, den Status eines Dokuments genau zu prüfen und ihn nicht mit einem Request for Comments (RFC) zu verwechseln.
Unbekannter Autor und mutmaßliche KI-Erstellung
Als Autor wird James Thain von One Limited (Bermuda) genannt, eine im IETF-Kontext bislang unbekannte Person und Organisation. Innerhalb weniger Tage erschienen mehrere Revisionen von IPv8 sowie zahlreiche Begleitentwürfe zur Zone-Server-Architektur und zum Routing. Analysen mit Tools wie GPTZero deuten darauf hin, dass große Teile des Textes mit generativer KI erstellt wurden (geschätzter KI-Anteil rund 76 %). KI-Nutzung ist im Draft-Prozess zwar nicht untersagt, erhöht aber die Notwendigkeit strenger technischer und sicherheitstechnischer Peer Reviews, um scheinbar plausible, aber inhaltlich fehlerhafte Vorschläge zu identifizieren.
Versionsnummer 8 bereits historisch vergeben
Hinzu kommt, dass die IP-Versionsnummer 8 bereits in den 1990er-Jahren im Rahmen des experimentellen P Internet Protocol (PIP) verwendet wurde. Eine erneute Nutzung derselben Versionsnummer würde die Auswertung von Protokolltraces, forensische Analysen und Legacy-Interoperabilität zusätzlich verkomplizieren, weil Tools und Archive unterschiedliche Protokolle unter derselben Nummer führen müssten.
In Summe zeigt der IPv8-Draft, wie wichtig transparente Standardisierungsprozesse und eine mehrstufige Fachbegutachtung in Zeiten generativer KI sind. Sicherheitsverantwortliche sollten neue IETF-Initiativen frühzeitig monitoren, ihren Draft-Status, die technische Architektur und insbesondere neue Vertrauensanker wie Zone Server kritisch bewerten. Vor jeder Einführung neuer Netzwerkprotokolle empfiehlt sich eine Risikoanalyse zu zusätzlichen Ausfallpunkten, Token- und Schlüsselkompromittierung sowie zu Auswirkungen auf bestehende Filter-, Monitoring- und Forensik-Werkzeuge. Organisationen, die in Schulung, Mitarbeit in IETF-Arbeitsgruppen und eine sorgfältige Prüfung neuer Internet-Drafts investieren, stärken nachhaltig die Resilienz und Cybersicherheit ihrer Netzinfrastruktur.
