IPv8 — Ein verspäteter April-Scherz?

Im April 2026 wurde bei der IETF ein Internet-Draft eingereicht, der das Routing-Fundament des Internets neu denken will: IPv8 mit 64-Bit-Adressen, einem zentralen Zone Server, OAuth2-Tokens auf Network-Layer und Egress-Validierung gegen WHOIS. Der Draft hat keinen IETF-Sponsor, ist offenbar zu großen Teilen AI-generiert und enthält drei Architekturmerkmale, die ich aus DevSecOps-Sicht für gefährlich halte: OAuth-Tokens auf der falschen Schicht, einen Single Point of Catastrophe im Zone Server, und eine eingebaute Surveillance-Infrastruktur. Bill Buchanan sieht es freundlicher — aber er hat nur das Lenkrad geprüft, nicht das Auto gestartet.

Als Mitte April in meinen Timelines IPv8 auftauchte, war ich verwundert. Sollte das ein ernstgemeinter Vorschlag sein? Mein erster Reflex war: jemand hat den 1. April verpasst und versucht es jetzt eben doch noch. Mein zweiter Reflex, nachdem ich den Draft tatsächlich gelesen hatte: nein, das ist schlimmer als ein Scherz. Das ist gemeint.

Ich beschäftige mich seit 2002 mit Software-Entwicklung, betreue als DevSecOps-Lead Infrastrukturen, Container-Cluster und Auth-Architekturen. Wenn ein neuer Vorschlag für die Plumbing-Schicht des Internets erscheint, schaue ich genau hin. Vor allem dann, wenn er sich anschickt, Dinge in den Kern des Stacks zu schrauben, die da nichts verloren haben.

Dies hier ist ein längerer Beitrag. Ich gehe das Dokument der Reihe nach durch, kritisch, mit Belegen. Und ich behandle auch den positiven Gegenartikel von Bill Buchanan — einem Kryptografie-Professor, der das Ganze deutlich freundlicher sieht als ich. Spoiler: Ich glaube, er hat sich nur das Lenkrad angeschaut und das Auto nicht gestartet.

Worum geht es überhaupt?

Am 14. April 2026 wurde bei der IETF der Internet-Draft draft-thain-ipv8-00 eingereicht, mittlerweile in Revision -02. Autor: J. Thain von One Limited, einer Firma mit Sitz in Bermuda. Der Vorschlag heißt „Internet Protocol Version 8“ und will — nicht weniger — die Plumbing-Schicht des Internets neu denken.

Die Kernpunkte, wie der Draft sie selbst formuliert:

• 64-Bit-Adressraum mit IPv4-ähnlicher Notation: 1.1.1.1.1.1.1.1
• Die ersten 32 Bit sind ein Routing-Prefix, gebunden an die Autonomous System Number (ASN). Die hinteren 32 Bit sind der Host-Anteil — also faktisch eine IPv4-Adresse pro ASN.
• 100 % Backward-Compatibility mit IPv4: Eine IPv8-Adresse mit Routing-Prefix 0.0.0.0 ist eine IPv4-Adresse.
• Eine zentrale Komponente namens „Zone Server“, die DHCP, DNS, NTP, Authentifizierung, Telemetrie, Access Control und IPv4-Translation in einer Plattform bündelt.
• Jedes verwaltbare Element im Netzwerk authentifiziert sich über OAuth2 mit JWT-Tokens.
• Jedes ausgehende Paket wird am Egress gegen einen DNS8-Lookup und gegen eine WHOIS8-registrierte aktive Route validiert.
• Mandatory zertifizierte NIC-Firmware mit Hardware-Rate-Limits.
• Persistente TCP/443-Verbindung jedes Endgeräts zum Zone Server.
• Neue Varianten von BGP, OSPF, IS-IS, ARP, ICMP und ein neues DNS-Record-Format.

Das ist keine Adressraum-Erweiterung. Das ist ein Komplettumbau des Stacks.

Erste rote Flagge: Die Provenienz

Bevor ich überhaupt zu den technischen Punkten komme, gibt es zwei Dinge, die jeder erst einmal nüchtern zur Kenntnis nehmen sollte.

Erstens: Ein IETF-Internet-Draft ist kein Standard. Jeder kann einen Draft einreichen. Das Dokument selbst stellt explizit klar, dass es keinen formalen Status im IETF-Standardisierungsprozess hat. Wenn es kein Working-Group-Backing findet, läuft es nach sechs Monaten automatisch aus. Stand heute hat dieser Draft nicht einmal einen einzelnen IETF-Working-Group-Sponsor.

Zweitens: Tools wie GPTZero schätzen das Dokument zu rund 76 % als AI-generiert ein, einzelne Abschnitte zu 100 %. Der Autor ist in der Networking-Community nicht bekannt — James Thain von einer Firma in Bermuda, die in der Protokoll-Welt keine Spuren hinterlassen hat. Innerhalb weniger Tage erschienen drei Revisionen des Hauptdokuments und rund ein Dutzend Begleit-Drafts (zoneserver-00, whois8-00, routing-protocols-00, support8-00, update8-00, wifi8-00, rine-00, netlog8-00).

Auf Hacker News wurde das Ding zerlegt. Der Tenor: „Probably someone had an Adderall fueled night with an LLM.“ — „Two weeks late for April Fools'?“

Das ist keine Hexenjagd gegen AI-Nutzung. Die IETF verbietet generative AI nicht. Aber wenn jemand vorschlägt, das Routing-Fundament des Internets durch ein zentralisiertes, OAuth-basiertes Konstrukt zu ersetzen, dann erwartet man Substanz, nachprüfbare Spuren, einen Track Record. Hier fehlt all das. Das ist eine Anmerkung zum Vertrauen, nicht zum Inhalt — aber sie färbt jede einzelne Designentscheidung.

Und jetzt zur Substanz.

Die schwerwiegenden technischen Probleme

1. Layer-Violation: OAuth2/JWT auf Network-Layer

Das ist für mich der größte Architekturfehler im gesamten Dokument. Der Draft schreibt: „Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache.“

Übersetzt: Application-Layer-Authentifizierung wird in den Netzwerk-Stack getackert. Das verletzt die OSI-Schichtung an exakt der Stelle, an der sie wichtig ist. IP transportiert Pakete — ohne pro Paket einen Identity-Provider zu konsultieren. Das ist ein Feature, kein Bug.

Konkrete Probleme:

Bootstrapping-Paradox. Ein Gerät braucht ein JWT, um zu kommunizieren. Aber zum Holen des JWT muss es kommunizieren. Der Draft löst das durch lokale OAuth8-Caches auf dem Zone Server — aber damit hat man das Trust-Problem nur verschoben. Wer initial die Cache-Inhalte verteilt, kontrolliert das Netz.

Bearer-Token in der Network-Plane. JWTs sind Bearer-Tokens. Wer sie in die Hände bekommt, kann sie verwenden, ohne irgendetwas weiter beweisen zu müssen. Im Vergleich: mTLS-basierte Authentifizierung erfordert Schlüsselbesitz. Pubkey-Schemata wie OPKSSH (das wir bei uns produktiv einsetzen) basieren auf kurzlebigen Zertifikaten mit nachgewiesenem Schlüsselbesitz — kein Bearer-Modell. Token-Theft auf Network-Layer skaliert in einer Art, die wir auf Application-Layer mit Mühe in den Griff bekommen.

Industrie-Realität. Access-Switches, einfache Router, industrielle Steuerungen, Embedded-Controller — das sind Geräte, die nicht für L7-Auth gebaut sind. JWT-Validierung mit Public-Key-Kryptografie auf jedem Switch-Port? In einer Werkshalle mit 800 Geräten? Das ist nicht einfach „aufwendig“ — das ist eine fundamentale Erhöhung der Angriffsfläche an Stellen, die heute schlicht keine Angriffsfläche haben.

IPv4 und IPv6 haben kein eingebautes Auth-Modell. Auth wird auf der passenden Schicht gemacht: IPsec, TLS, mTLS, SASL. Das ist die richtige Stelle.

2. Zone Server: Single Point of Catastrophe

Der Zone Server konsolidiert DHCP8, DNS8, NTP8, NetLog8, OAuth8, WHOIS8-Resolver, ACL8 und XLATE8 in einer Plattform. Der Draft verkauft das als „Active/Active-Paar mit automatischem Failover“. Das adressiert Verfügbarkeit, aber nicht das eigentliche Problem.

Das eigentliche Problem ist die Konsolidierung von Trust-Domains.

Wer einen Zone Server kompromittiert, kontrolliert in einem einzigen Schlag:

• Identitäten — über den OAuth8-Cache.
• Routing — durch lokale WHOIS8-Validierung und Egress-Kontrolle.
• Namensauflösung — jedes Lookup geht hier durch.
• Zeitsynchronisation — wer NTP kontrolliert, kann zertifikatsbasierte Validierung aushebeln, indem er Uhren manipuliert.
• Egress-Filterung — welche Verbindung überhaupt ins Internet darf.
• Telemetrie und Logs — inklusive der forensischen Spuren des Angriffs.

Das ist das exakte Gegenteil dessen, was wir als Defense in Depth verstehen. Ein vernünftig segmentiertes Netz heute hat unabhängige Trust-Domains: getrenntes DHCP, DNS-Resolver, RADIUS, NTP, IDS — idealerweise von verschiedenen Vendors mit verschiedenen Update-Pfaden. Ein Bug in einem System reißt nicht alles auf.

Ein Zone Server ist eine Box. Eine RCE im DHCP8-Implementierungsteil — und du hast OAuth-Tokens, Routing-Tables und Logs in der Hand. Das ist nicht „aktiv/aktiv-resilient“, das ist „Eier in einem Korb“.

3. WHOIS8/DNS8-Egress-Validierung: Surveillance by Design

Der Draft schreibt: „Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route.“

Das ist nicht nur ein technisches, sondern auch ein Privacy- und Geopolitik-Problem.

Surveillance. Der Zone Server sieht jede einzelne Outbound-Verbindung mit voller DNS-Auflösung im Klartext und mit zeitlicher Korrelation. Das ist eine Aufzeichnungsmaschine, wie sie kein IPv4- oder IPv6-Setup standardmäßig hat. Wer den Server betreibt, hat ein vollständiges Verbindungsprotokoll deines Netzes.

Censorship. Wer die WHOIS8-Datenbank kontrolliert, kontrolliert, welche ASNs überhaupt erreichbar sind. Im aktuellen Modell sind die Regional Internet Registries (RIPE, ARIN, APNIC, LACNIC, AFRINIC) politische Organisationen mit unterschiedlichen Jurisdiktionen. Eine harte Abhängigkeit der globalen Erreichbarkeit von ihren Datenbanken ist eine Waffe, die sich gegen einzelne ASNs, einzelne Länder, einzelne Player einsetzen lässt.

Bricht Non-DNS-Verkehr. Direkte IP-Verbindungen, P2P-Discovery, IPsec-VPN-Initiierung ohne vorherigen DNS-Lookup, ICMP-basierte Tools, Custom-Protokolle — alles potenziell tot oder müsste über Sonderregeln rein. Das End-to-End-Prinzip, also einer der Grundgedanken des Internets, wird hier still beerdigt.

IPv6 hat keinerlei vergleichbare Einschränkung. RPKI, das wir heute für BGP-Sicherheit haben, ist layered und optional — ein RPKI-Ausfall verschlechtert die Sicherheit, aber das Routing funktioniert weiter. IPv8 macht WHOIS8 zur kritischen Infrastruktur im Wortsinn.

4. Mandatory Certified NIC Firmware: Hardware-Lock-In

Ein Detail, das wenig diskutiert wird, aber besonders unangenehm ist: Jede NIC muss zertifizierte Firmware tragen, mit Hardware-Rate-Limits und obligatorischer Update8-Wartung.

Das bedeutet:

• Eine zentrale Stelle (ich nehme an, gekoppelt an die RIRs oder eine neue IANA-Funktion) entscheidet, welche Hardware am Netz teilnehmen darf.
• Open-Source-Implementierungen, eigene Firmware, Custom-Hardware, Hobbyisten-Projekte, alte Geräte — potenziell ausgeschlossen.
• Supply-Chain-Attacks über das Update8-System hätten die Reichweite, von der SolarWinds nur geträumt hat.

IPv4 und IPv6 haben diese Hürde nicht. Jede halbwegs korrekte Implementierung kann mitspielen. Das ist kein historischer Zufall, das ist die Grundlage des offenen Internets.

5. Persistente TCP/443-Verbindung jedes Endgeräts zum Zone Server

Der Draft fordert eine Dauerverbindung jedes Endgeräts zu einer zentralen Komponente. Aus DevSecOps-Sicht möchte ich dazu Folgendes festhalten:

Diese Architektur ist exakt das Pattern, das wir in Threat-Modellen als bösartig markieren. Persistent Outbound TCP zu einer zentralen Box, von jedem Endgerät, nicht abschaltbar — das ist ein Command-and-Control-Channel by Design. Wer den Zone Server kompromittiert, hat eine Reverse-Shell zu jedem Gerät im Netz. Lateral Movement ist nicht mehr nötig, weil die Bewegung schon eingebaut ist.

Was passiert, wenn die persistente Verbindung ausfällt? Die Spec ist hier vage. „Fail closed“ wäre verheerend für die Verfügbarkeit. „Fail open“ macht die ganze Auth-Architektur sinnlos. Beides ist schlecht.

6. „100% backward compatible“ — die größte Lüge im Dokument

Das ist das Verkaufsargument schlechthin. Es funktioniert nicht.

Jeder existierende IPv4-Router, Switch-ASIC, NIC, Host-Stack oder Firewall, der ein Paket mit Version=8 im IP-Header sieht, kann das nicht parsen und droppt es im Regelfall. Das Version-Field wird hardware-seitig im Forwarding-Pfad geprüft. Eine 8 dort lässt jeden bestehenden Pfad scheitern — es sei denn, er wurde explizit geupdated.

Gleichzeitig fordert das Dokument selbst:

• Neue Socket-API
• Neuer DNS-Record-Type
• Neuer ARP (ARP8)
• Neuer ICMP (ICMPv8)
• Neue BGP/OSPF/IS-IS-Varianten
• Mandatory certified NIC firmware
• Mandatory Zone Servers
• Mandatory OAuth2 auf Switch-Ports
• Persistente TCP/443 von jedem Endgerät

Das ist keine Migration light, das ist eine komplette Hardware- und Software-Erneuerung. „Backward compatible“ gilt hier nur in einem speziell präparierten IPv8-Netz, das so tut, als wäre es IPv4 — nicht zwischen heutiger IPv4-Welt und morgiger IPv8-Welt.

IPv6 hat ehrlich Dual-Stack als notwendig benannt. Hier wird das versteckt.

7. 64 Bit — Rückschritt gegenüber IPv6

64 Bit Adressraum reichen heute. Das ist auch das Argument, das die Befürworter machen, und ich komme gleich zu Bill Buchanans Variante davon. Aber 32 Bit reichten 1981 auch. Das Argument hat einen historischen Loop, der bemerkenswert wenig reflektiert wird.

IPv6 mit 128 Bit ist nicht „eine Adresse für jedes Sandkorn“, sondern erlaubt strukturierte Subnetting-Hierarchien, SLAAC, Privacy Extensions, EUI-64 ohne Adressknappheit. Das ist Architektur-Komfort, nicht Größenwahn.

Pro ASN bietet IPv8 genau eine IPv4-Tabelle, also 2^32 Hosts. Wer ein bisschen IoT, ein bisschen 5G/6G, ein bisschen Edge denkt, weiß, dass das ganz schnell wieder eng wird.

8. Versionsnummer-Konflikt

Ein Detail, aber bezeichnend: Die Versionsnummer 8 wurde bereits einmal vergeben — an das experimentelle Pip-Protokoll aus den frühen 1990ern, heute obsolet. Die Wiederverwendung schafft Tooling-Probleme bei Wireshark, IDS-Signaturen, alten Stacks. Wer Sorgfalt walten lässt, prüft so etwas vor dem Einreichen eines Drafts. Hier ist das nicht passiert.

Die Gegenposition: Bill Buchanan

Ein paar Tage nach der Einreichung tauchte ein Medium-Artikel von Bill Buchanan auf, Professor für Kryptografie an der Napier University in Edinburgh, OBE und FRSE. Der Mann ist kein Niemand, sein Track Record im Crypto-Bereich ist substanziell. Sein Artikel trägt den Titel „IPv6 Has Failed? Meet IPv8 — IPv4, But Better“ und seine Kernthese ist: 64 Bit ist die Goldilocks-Lösung, IPv4-Notation hat operativen Wert, ASN als Routing-Prefix dezentralisiert das Internet.

Sein Schluss-Satz: „It really is a brilliant way forward.“

Ich mag Buchanans Arbeiten generell, deshalb habe ich den Artikel zweimal gelesen. Mein Eindruck nach dem zweiten Lesen: Er hat sich wirklich nur das Adressing-Schema angeschaut und nichts darüber hinaus.

Wo Buchanan einen Punkt hat

Fair sein: Zwei Argumente in seinem Artikel sind tatsächlich substanziell.

IPv4-Notation hat operativen Wert. Subnetting im Kopf, Routing-Tabellen lesen, Firewall-Regeln schreiben, CIDR-Mathe — Generationen von Admins haben das verinnerlicht. Eine Notation, die das erhält, hat einen realen Schulungs- und Migrations-Vorteil. Das ist kein Nostalgie-Argument, das ist ein Effizienz-Argument. IPv6-Adressen mit ihren Doppelpunkten, Hex und Zero-Compression sind in der Praxis fehleranfällig.

IPv6-Adoption ist tatsächlich zäh. Dual-Stack-Komplexität, NAT64/DNS64-Schmerzen, Provider-seitige Halbherzigkeit, fehlerhafte Default-Konfigurationen — die Probleme sind real. IPv6-Cheerleader unterschätzen sie regelmäßig. Wer 25 Jahre Migration und unter 60 % weltweite Adoption sieht, kann durchaus die Frage stellen, ob das Design das Problem ist.

Diese beiden Punkte sind ernst und sie verdienen Diskussion.

Wo er zu großzügig ist

Aber: Beide Punkte rechtfertigen kein „brilliant way forward“-Urteil über eine Spec, die als Hauptmerkmal eine zentralisierte Management-Plane mit Bearer-Tokens, Hardware-Lock-In und Egress-Surveillance einführt.

Buchanans Artikel adressiert ausschließlich das Addressing. Über die eigentlich gefährlichen 90 % der Spec verliert er kein Wort. Kein Wort zum Zone Server. Kein Wort zu OAuth2/JWT auf Layer 3. Kein Wort zur DNS8/WHOIS8-Egress-Validierung. Kein Wort zur certified NIC firmware. Kein Wort zur persistenten TCP/443-Verbindung. Kein Wort zur AI-Provenienz. Kein Wort zur Tatsache, dass Version=8 von bestehender Hardware gedroppt wird.

Drei spezifische Punkte, an denen er sachlich zu großzügig ist:

„IPv8 dezentralisiert über ASNs.“ Das ist genau verkehrt herum. Die ASN-Prefix-Struktur als solche ist neutral. Aber die Spec hängt globale Erreichbarkeit an WHOIS8-Validierung — jede BGP8-Ankündigung muss gegen eine zentrale Registry verifiziert werden, sonst kommt sie nicht in die Routing-Tabellen. Das ist nicht Dezentralisierung, das ist eine zwingende Abhängigkeit von zentralen RIR-Datenbanken auf Routing-Layer. BGP heute funktioniert auch ohne RPKI. RPKI ist optional und layered. IPv8 macht zentrale Registries zur kritischen Infrastruktur im Wortsinn.

„IPv6 hat versagt.“ Bequeme Rhetorik, aber faktisch fragwürdig. Die Internet Society berichtete am 28. März 2026, dass Googles IPv6-Access-Messung erstmals 50 % überschritten hat. Über die Hälfte des Traffics zu Google läuft IPv6. „Failure“ sieht anders aus. Es ist langsam und schmerzhaft, ja — aber keine gescheiterte Adoption.

„64 Bit reichen.“ Reichen heute. Reichten 1981 auch. Mit IoT, 5G/6G, Edge Computing, vielleicht in zehn Jahren ambient computing — wir brauchen Adressraum für Architektur, nicht nur für die Anzahl der Geräte. IPv6's 128 Bit sind hier vorausschauend, nicht übertrieben.

Buchanan ist Kryptograf, kein Network-Architekt. Sein Artikel liest sich wie eine schnelle, freundliche Reaktion auf ein neues Adressing-Schema, nicht wie eine fundierte Bewertung der Gesamt-Spec. Bei einem Drei-Minuten-Stück ist das nicht verbrecherisch. Aber es ist eben nur der Lenkrad-Test, nicht die Probefahrt.

Was bleibt?

Der IPv8-Vorschlag ist nicht „der nächste IPv6-Killer“. Er ist ein Beispiel dafür, was passiert, wenn man reale operative Pain Points (zähe IPv6-Adoption, wachsende Routing-Tabellen, fragmentiertes Management) mit Architekturentscheidungen aus dem 2026er Enterprise-IT-Buzzword-Bingo verheiraten will: OAuth, JWT, Zentralisierung, „Zone“.

Die drei Punkte, die mich aus Sicherheitssicht am meisten besorgen:

1. OAuth2/JWT auf Network-Layer. Eine fundamentale Layer-Verletzung mit einem Bearer-Token-Skalierungsproblem. JWTs gehören in Application-Layer-APIs, nicht in IP-Stacks.
2. Zone Server als monolithische Trust-Domain. Konsolidierung aller Sicherheitsfunktionen in einer Box ist das Gegenteil von Defense in Depth. Eine RCE dort ist eine RCE überall.
3. Mandatory Egress-Validierung über DNS8/WHOIS8. Surveillance- und Censorship-Infrastruktur by Design, eingebaut in das Routing-Layer.

Hinzu kommt das Provenienz-Problem. Wer würde einer offenbar AI-generierten Spec eines unbekannten Autors aus Bermuda das Plumbing des Internets anvertrauen? Wenn der Draft keine Working-Group-Unterstützung findet, läuft er nach sechs Monaten automatisch aus. Das ist das wahrscheinliche und vernünftige Ende.

Mein Fazit

Das ist kein Ratschlag und keine Empfehlung — das ist mein Hot-Take, nachdem ich den Draft und die Begleitdokumente gelesen habe. Ich glaube nicht, dass dieser Vorschlag in der vorliegenden Form das Internet erreichen wird. Ich würde ihn auch in keiner Infrastruktur einsetzen wollen, die ich kenne. IPv6-Migration weiter verfolgen, IPv4-Bestand sauber halten, RPKI auf BGP-Layer, DNSSEC auf DNS-Layer, mTLS oder OPKSSH auf Service-Layer, Vault für Secrets — das funktioniert. Authentifizierung gehört dorthin, wo sie hin gehört: nicht in den IP-Header. Defense in Depth funktioniert über unabhängige Trust-Domains, nicht über konsolidierte Zone Server.

Wer eine ehrliche Diskussion über IPv6-Schmerzen führen will, soll das tun. Es gibt Verbesserungspotenzial im Routing-Sicherheitsmodell. Es gibt Verbesserungspotenzial bei Management-Tooling. Es gibt Bedarf für sauberere Migrationspfade. Aber das passiert in der IETF, in offenen Working Groups, mit nachvollziehbarem Track Record und mit echtem Layer-Verständnis.

Nicht über einen anonymen Draft mit zentraler Surveillance-Architektur und verstecktem Hardware-Lock-In.

So sehe ich das. Hot-Take, kein Ratschlag.

Quellen

• draft-thain-ipv8-00/01/02 auf datatracker.ietf.org
• Diskussion auf Hacker News (Item 47788857)
• GPTZero-Analyse via Cybernews und HackMag
• Bill Buchanan, „IPv6 Has Failed? Meet IPv8“ auf Medium (April 2026)
• Internet Society IPv6-Adoptionsstatistik März 2026