Das Internet ohne IPv4-Verbindung nutzen

(jamesmcm.github.io)

3 Punkte von GN⁺ 2025-06-30 | 1 Kommentare | Auf WhatsApp teilen

Selbst in einer Situation, in der die IPv4-Verbindung ausgefallen ist, wurde durch IPv6, WireGuard und einen Hetzner-VPS die Nutzung des gesamten Internets möglich
Durch Carrier Grade NAT (großflächiges NAT) trat die Störung nur bei IPv4 auf, während IPv6 unbeeinflusst blieb
Durch die Einrichtung eines WireGuard-Tunnels und das Tunneln des IPv4-Traffics über den VPS konnte eine normale Nutzung von Websites wiederhergestellt werden
Es werden außerdem der Einsatz von Netzwerk-Namespaces und Docker sowie Lösungswege für MTU-Probleme vorgestellt
Hervorgehoben wird die Erfahrung, komplexe Netzwerkprobleme dank Linux und Open-Source-Werkzeugen selbst gelöst zu haben

Überblick

Vor einigen Tagen hatte der Autor nach einem Stromausfall an seinem Heimrouter das Problem, dass die IPv4-Konnektivität unterbrochen war. Glücklicherweise funktionierte die IPv6-Verbindung weiterhin, sodass einige Websites (Google, Meta usw.) erreichbar waren, die meisten Seiten (etwa GitHub) jedoch nicht. Daher fasst er zusammen, wie er mit Linux, WireGuard und einem Hetzner-VPS die vollständige Internetnutzung ausschließlich über IPv6 wiederhergestellt hat.

Ursache der Störung und Hintergrund

Auffälligkeiten in der Netzwerkumgebung entdeckt

Während der Wiederherstellung nach dem Stromausfall zeigte sich, dass IPv6-Server normal erreichbar waren, IPv4-Server jedoch nicht
Auch die Ergebnisse von Diagnosebefehlen wie ping -6 und traceroute zeigten nur Unterschiede je nach IP-Version
Nach einer Anfrage stellte sich heraus, dass im CG-NAT-Layer (Carrier Grade NAT) des Providers ein Problem bei der IPv4-Umsetzung aufgetreten war
Da bis zur Wartung durch den ISP einige Tage zu erwarten waren, wurde eine Eigenlösung erforderlich

Erklärung von NAT und CG-NAT

NAT (Network Address Translation): Ein Verfahren, mit dem mehrere Geräte sich eine öffentliche IPv4-Adresse teilen können
- Der Router ersetzt interne IP-Adressen durch eine öffentliche IP und eindeutige Ports, verwaltet so den Traffic und stellt beim Rückweg anhand der Zuordnung das interne Ziel wieder her
- Dadurch entstehen die Wirkung einer impliziten Firewall und die Notwendigkeit von Port-Forwarding
CG-NAT (Carrier Grade NAT): Eine mehrstufige Struktur, bei der der ISP auf Heimrouter noch einmal NAT zusätzlich anwendet
- Wegen des Mangels an IPv4-Adressen setzt der ISP intern verschachteltes NAT ein
- In einer CG-NAT-Umgebung sind Dienste wie Port-Forwarding noch stärker eingeschränkt
- Dass nur IPv4-Traffic betroffen war, lag genau an Problemen bei der Verarbeitung von IPv4-Paketen in dieser Schicht

Vorteile von IPv6

Der Adressraum von IPv6 ist überwältigend groß, sodass jedem Gerät auch ohne NAT direkt eine Adresse zugewiesen werden kann
- Den meisten Heimroutern wird ein /64-Subnetz zugewiesen, womit Milliarden von Milliarden Adressen nutzbar sind
Separate NAT-Mechanismen sind daher nicht nötig und direkte Kommunikation ist möglich, dafür werden Firewall-Einstellungen umso wichtiger
Da CG-NAT nur auf IPv4 angewendet wird, funktionierte in diesem Fall nur IPv6 normal
Viele Server (z. B. GitHub) sind jedoch noch immer nicht allein über IPv6 erreichbar

IPv4 per WireGuard-Tunnel wiederherstellen

Implementierungsüberblick

Mit einem Hetzner-VPS (mit Unterstützung für IPv4- und IPv6-Stack) und WireGuard wurde eine Umgebung aufgebaut, in der trotz reiner IPv6-Internetverbindung wieder vollständiger Internetzugang möglich war
- Auf dem VPS läuft ein WireGuard-Server, zu dem ein Tunnel von den Client-Geräten aufgebaut wird
- Der Traffic wird über IPv6 zum VPS umgeleitet und kann über den VPS alle Websites einschließlich IPv4-Zielen erreichen
- Das Prinzip ähnelt Dual-Stack Lite

Beispiel für Server- und Client-Konfiguration

In der WireGuard-Serverkonfiguration werden sowohl IPv4- als auch IPv6-Traffic verarbeitet
- Enthalten sind Beispiele für Regeln mit MASQUERADE (dynamische IP-Umsetzung) und SNAT (feste IP-Umsetzung)
- Mit direkt zugewiesenem globalem IPv6 ist eine WireGuard-Peer-Verbindung auch ohne NAT sofort möglich
- In den Einträgen PostUp/PostDown können mehrere Befehle angegeben werden, die dann nacheinander ausgeführt werden
Beispiel für die Client-Konfiguration
- Erläuterungen zu direkt zugewiesenen IPv6-Adressen oder Kombinationen mit genattetem ULA
- Mit AllowedIPs auf 0.0.0.0/0, ::/0 lässt sich der gesamte Traffic durch den Tunnel leiten
- Außerdem werden Google-DNS (IPv4, IPv6) und Methoden zur MTU-Einstellung gezeigt

Tunnel funktioniert ordnungsgemäß

Nach Abschluss der WireGuard-Konfiguration auf beiden Seiten funktionierte das Tunneln für IPv4 und IPv6 normal
Dasselbe Verfahren wurde auch auf dem PC seiner Frau angewendet, mit einer unkomplizierten Installation des Linux-WireGuard-Clients
Eine gleichzeitige Verbindung mit dem Firmen-VPN ist jedoch in der Regel nicht möglich, weshalb zusätzliche Netzwerk-Namespaces nötig werden

Netzwerk-Namespaces und Docker

Funktionen und Einsatzmöglichkeiten

Mit Werkzeugen wie vopono lassen sich anwendungsbezogene Netzwerk-Namespaces erstellen und in diesen Namespaces VPN- oder WireGuard-Interfaces direkt zuweisen
- Es müssen zusätzliche MASQUERADE-Regeln gesetzt werden, um internen Traffic zwangsweise durch den WireGuard-Tunnel zu leiten
- Enthalten sind auch Konfigurationstipps zu isoliertem DNS nach außen und gai.conf (DNS-Priorisierung für IPv4)
Gezeigt wird außerdem ein Beispiel dafür, innerhalb des Namespace eine VPN-Verbindung aufzubauen und Anwendungen auszuführen
- Durch das Ausführen mehrerer Dienste im selben Namespace lassen sich Netzwerkkonflikte im Vorfeld vermeiden

Kombination mit Docker-Containern

Der Docker-Daemon verwendet standardmäßig den Netzwerk-Socket des Hosts, daher ist der Zugriff mit einem normalen Start in einem Namespace allein nicht möglich
- Als Workaround werden Unix-Virtualisierungstechniken wie Mount-Namespaces und Bind-Mounts von /sys vorgestellt
- Durch das Starten von dockerd innerhalb des Namespace sowie die Angabe eines separaten Sockets und Datenverzeichnisses konnte die Internetverbindung in Containern wiederhergestellt werden
- Erwähnt wird auch, dass bei komplexen Netzwerk-Bridge-Umgebungen zusätzliche Einstellungen erforderlich sein können

WireGuard-MTU-Probleme (MTU: Maximum Transmission Unit)

Nach dem Aufbau der WireGuard-Verbindung waren einige Websites weiterhin nicht erreichbar (z. B. mit SSL), obwohl ping normal antwortete
Durch Ping-Tests mit verschiedenen Paketgrößen wurde festgestellt, dass eine zu hohe MTU dazu führte, dass große Pakete unterwegs verworfen wurden
- Durch das Absenken der MTU auf 1280 war das Problem sofort behoben
MTU bezeichnet die maximale Paketgröße, die auf einmal übertragen werden kann
- Wegen des Overheads von Tunneln/Kapselung ist eine passende MTU-Konfiguration nötig, andernfalls kommt es bei der Übertragung großer Pakete zu Verbindungsstörungen
- Bei IPv6 ist eine Mindest-MTU von 1280 standardmäßig vorgeschrieben

Fazit und praktische Hinweise

Hervorgehoben wird die Erfahrung, mit Linux und Open-Source-Werkzeugen Netzwerkprobleme selbst zu diagnostizieren und zu lösen: vom Aufbau eines WireGuard-VPN-Servers über die Verwaltung von Netzwerk-Namespaces und spezielle Docker-Umgebungen bis hin zum MTU-Troubleshooting
Dienste wie ein Hetzner-VPS gelten als stabil im Verhältnis zum Preis und erleichtern den Betrieb legitimer Netzwerklösungen wie WireGuard
Auch der Wert von Open-Source-Router-Firmware (OpenWRT) und Linux-Netzwerktechniken wird neu bewertet
- Die Flexibilität, das eigene Netzwerk direkt verwalten und anpassen zu können, bietet besonders im Remote-Arbeitsumfeld große Vorteile
- Mit ausreichendem Verständnis und Übung lassen sich auch komplexe Netzwerkstörungen selbst beheben

Referenzmaterial

Tailscale – How NAT Traversal Works
ArchWiki – WireGuard use case example
Unix StackExchange – Docker tricks within namespaces
AskUbuntu – DNS priority configuration

(Weitere Skripte, Konfigurationen, Tipps und Referenzlinks siehe Originaltext)

1 Kommentare

GN⁺ 2025-06-30

Hacker-News-Kommentare

Der Titel wirkt etwas missverständlich, denn eigentlich geht es in diesem Artikel eher um „über einen VPS per IPv6-Tunnel ins IPv4-Internet gelangen“, üblicherweise als 4in6 bezeichnet.
Trotzdem ist es ein interessanter Ansatz.
Wenn bei unserem ISP IPv4 ausfällt, ist sofort alles down, wodurch Support-Probleme vergleichsweise einfach sind. Wenn dagegen IPv6 ausfällt, verhält sich nur manches merkwürdig, etwa langsame Verbindungen oder sporadische Nichterreichbarkeit.
Besonders wenn das Gateway fälschlich annimmt, IPv6 zu haben, erscheint das Problem aus Nutzersicht noch lästiger, weil dann nur einige Funktionen nicht arbeiten.
- Als IPv4 kürzlich kurz ausfiel, habe ich es erst bemerkt, weil Github nicht funktionierte.
  Heutzutage funktionieren die meisten Websites für Endverbraucher über IPv6 problemlos.
  Wer allerdings einen Router hatte, der nur IPv4-DNS bereitstellt, hatte das Problem, dass das Internet komplett weg war.
  Ich wünschte, Microsoft würde dem etwas mehr Aufmerksamkeit schenken.
  Um zu prüfen, ob IPv4 wieder da ist, musste man sich außerdem den dem Router zugewiesenen mDNS-Hostname merken.
- Bei mir zu Hause ist IPv4 ehrlich gesagt schon einmal ausgefallen, und meine Frau hat es nicht einmal bemerkt.
  Google, Facebook, Apple/iCloud und fast alle auf CloudFlare basierenden Dienste funktionieren über IPv6 einwandfrei.
- Meine Erfahrung ist ähnlich.
  IPv6-Probleme sind wirklich schwer zu diagnostizieren und zu reproduzieren, und es endet ständig bei „Auf meinem Rechner funktioniert es doch?“
- Die meisten ISPs blockieren IPv6 noch immer, und auch kleine Unternehmen probieren IPv6 zwar aus, vergessen dann aber Dinge wie AAAA-Records.
  Deshalb erleben Nutzer Situationen, in denen etwas bei Freunden oder im Café mit einem günstigen ISP funktioniert, aber zu Hause nicht.
  Das klingt vielleicht seltsam, aber eine besonders gute Lösung scheint es nicht zu geben; realistisch bleibt nur zu hoffen, dass IPv4 irgendwann verschwindet.
  Es gibt zwar Techniken wie Happy Eyeballs, bei denen gleichzeitig IPv4- und IPv6-Verbindungen versucht und die schnellere gewählt wird, aber in der Praxis treten die Probleme eher auf Anwendungsebene auf, und es fehlt an einer allgemeinen Lösung dafür.
  Ich selbst fahre einen Kompromiss, indem ich IPv6 im Netzwerk aktiviere, aber IPv6-DNS im Browser deaktiviere; zufriedenstellend ist das nicht.
Wer IPv6 nutzen möchte, es aber vom ISP nicht bekommt, kann schon seit sehr langer Zeit den kostenlosen Tunneldienst von Hurricane Electric (HE) nutzen.
Dazu gibt es verschiedene Informationsquellen und Setups, etwa tunnelbroker.net, ipv6.he.net, Fedora-Anleitung, Brandon-Rozek-Blog, DD-WRT-Anleitung, Mikrotik-Forum mit Auto-Update-Skript, RockyLinux-Leitfaden.
- Einen Punkt sollte man beachten: Viele Streaming-Dienste blockieren diesen Tunnel, weil sie ihn ähnlich wie eine VPN-Umgehung behandeln und deshalb regional eingeschränkte Inhalte sperren.
  Dank RA (Router Advertisements) kann jedoch jedes Netzwerkgerät ein IPv6-Netz im /64-Umfang aussenden, sodass mehrere Geräte im Netz IPv6-Adressen nutzen können, selbst wenn der Router den HE-Tunnel nicht direkt unterstützt, vorausgesetzt der Router filtert RA nicht aus Sicherheitsgründen.
  Wenn man zu Hause selbst etwas bereitstellen will, ist es sehr praktisch, das nur mit IPv6 und ohne Port-Forwarding tun zu können.
- Der Dienst von Hurricane Electric ist gut, aber inzwischen liefern ISPs immer öfter standardmäßig IPv6 aus, sodass normale Nutzer Tunneldienste zunehmend verlassen.
  Außerdem blockieren manche Netzwerkdienste he.net-Tunnel inzwischen, weil sie dort Missbrauch oder böswillige Nutzung vermuten, sodass ich IPv6 in meinem Netz letztlich größtenteils wieder abschalten musste.
- Als Hinweis: Der Hurricane-Electric-Tunnel funktioniert nur, wenn man vom ISP zwingend eine öffentliche IPv4-Adresse bekommt.
  Wenn man etwa hinter Carrier-Grade NAT oder einem anderen NAT sitzt, muss man für IPv6 zu Hause eine andere Lösung suchen.
- Ich bin seit fünf Jahren „Kunde“ des kostenlosen 6in4-Tunnels von HE mit OpenBSD.
  Mit rein netzwerkseitiger Konfiguration wie über /etc/hostname.gif0 läuft das dauerhaft zuverlässig.
  Ich nutze es auch für die Kommunikation mit einem absichtlich ohne IPv4 aufgebauten VPS-Cluster bei AWS.
  Da AWS IPv4-Adressen inzwischen aktiv bepreist, hilft dieser Ansatz enorm beim Kostensparen.
Wenn man in einer echten v6-only-Umgebung Zugriff auf v4 braucht, lässt sich das mit einem öffentlichen DNS64+NAT64-Gateway leicht lösen.
Siehe die Liste öffentlicher Provider von nat64.net.
Normalerweise reicht es, einfach den DNS-Server zu ändern.
DNS64 erzeugt für Websites ohne AAAA-Record einen synthetischen AAAA-Record, damit die Verbindung über eine NAT64-Box hergestellt werden kann.
NAT64 nimmt den Traffic dann entgegen und übernimmt Protokollumsetzung plus NAT.
Mit praktischen Beispielen per dig oder curl kann man so sofort Seiten wie Github erreichen.
- In Europa funktioniert nat64.net direkt genutzt ziemlich angenehm.
  Ich habe tatsächlich nur gute Erfahrungen damit gemacht.
- Mit Cloudflare WARP fühlt es sich deutlich schneller an.
  Über WARP kann man auch direkt auf IPv4-Adressen zugreifen.
Es überrascht mich manchmal, dass es IPv6-only-Nutzer gibt.
Früher war in der umgekehrten Situation, also bei IPv4-only und benötigtem IPv6-Zugriff, ein SOCKS5-Proxy (ssh -D) die beste Lösung, sofern man volle Kontrolle über den Server hatte und etwas Schnelles wollte.
Es reicht, nur den Browser auf den SOCKS-Proxy zu setzen.
Systemweit hätte ich eher Sorge, dass dadurch sogar die SSH-Verbindung abreißt.
Bei mir ist es eine ähnliche Situation.
Seit etwa zwei Wochen ist ein Ticket wegen einer IPv4-Störung offen, und ich bekomme nur wiederholt die Antwort, dass sich „bald ein Techniker darum kümmert“.
Weil IPv6 funktioniert, scheint es nicht als Komplettausfall zu gelten.
In Deutschland gibt es in solchen Fällen zwar Verbraucherschutzregelungen zur Entschädigung, aber ich werde erst noch prüfen, ob das auf diesen Fall zutrifft.
Das Problem mit dem im Blog vorgeschlagenen Ansatz ist, dass IP-Bereiche aus Rechenzentren von vielen Diensten blockiert werden, Captchas oder andere Umgehungen verlangen oder wie IPs von VPN-Anbietern behandelt werden; vermeiden lässt sich das kaum.
In meinem Fall musste die Lösung für das ganze Haus gelten, daher habe ich auf dem Router Routing und NAT-Regeln mit Wireguard eingerichtet, was mit einem offenen Gerät wie einem Ubiquiti EdgeRouter zum Glück möglich war.
Mit einer FritzBox wäre das vermutlich viel schwieriger gewesen.
Allerdings ist die Router-Leistung ein Nachteil: Bei vielen Verbindungen wird es langsam, daher überlege ich, auf IPSec mit Hardware-Offloading zu wechseln.
- Auch die FritzBox bietet einen sehr guten GUI-gestützten Einrichtungsprozess für VPN-Verbindungen.
  FritzBox-zu-FritzBox ist zwar die Standardannahme, aber auch ein kompatibles VPN funktioniert.
  Statische IPv4-/IPv6-Routen lassen sich ebenfalls einrichten.
  Das größte Problem ist herauszufinden, welche IPSec-Verschlüsselungseinstellungen die Gegenstelle verlangt. Wireguard ist einfacher, hat dafür aber das Problem fehlender Hardware-Beschleunigung.
  Falls nötig, kann man auch die komplette FritzBox-Konfiguration sichern, direkt bearbeiten und danach nur die Prüfsumme neu berechnen und wieder einspielen.
  AVM versteckt absichtlich eine enorme Menge an Details, die dem Nutzer nicht direkt angezeigt werden.
  Ein Stück weit ist das bewusst so gestaltet, damit man den Router nicht versehentlich kaputtkonfiguriert.
- Zur Lage in Deutschland weiß ich nichts, aber in den Niederlanden kann man, wenn Festnetz und Mobilfunk beim selben ISP sind, bei einer Störung im Festnetz kostenlos mobiles Datenvolumen anfordern.
  Falls möglich, würde ich empfehlen, den ISP nach so einer Option zu fragen.
Auch nach langer Zeit finde ich keinen klaren Grund, alle Geräte und das Home-Lab auf IPv6 umzustellen.
Port-Forwarding und Firewall-Regeln sind wenigstens einigermaßen intuitiv, während ich bei einem Umstieg auf IPv6 mit wochenlangem Troubleshooting, Firewall-Themen und Neuadressierung rechne.
Ich frage mich, was ich dabei übersehe.
- Realistisch betrachtet übersiehst du derzeit fast nichts.
  Wenn Unternehmen wie Google oder Cloudflare die weiter steigenden Kosten für IPv4-Adressen irgendwann nicht mehr tragen wollen, könnten sie Anreize für IPv6 schaffen, zum Beispiel indem IPv4-Verbindungen gedrosselt werden.
  Auch AWS hat früher nur ungenutzte IPv4-Elastic-IPs berechnet, heute wird jede IPv4-Adresse bepreist, auch wenn sie aktiv genutzt wird.
  Wenn du künftig dein Gateway oder deinen Router aufrüstest, ist es sinnvoll, IPv6 einfach mit zu aktivieren; derzeit kann man mit IPv4/IPv6-Dual-Stack bestehende Geräte und Services weiterhin ohne Probleme betreiben.
  Bei der automatischen Adressvergabe in IPv6 war historisch vieles uneinheitlich, aber es scheint sich auf SLAAC einzupendeln, während ISP-seitig DHCPv6 voraussichtlich noch lange genutzt wird.
- Eigentlich ist es gar nicht so schwer.
  Wenn dein Heimnetz nicht besonders komplex ist, reicht ein kurzer Abend, um IPv6 einzurichten.
  Bei Comcast genügt es, im Router die IPv6-Option zu aktivieren; dann holt er sich vom ISP einen Prefix, bewirbt ihn automatisch im Netz, und man muss nur noch die gewünschten Ports in der Firewall freigeben.
- Du übersiehst nichts.
  In Enterprise-Umgebungen bringt IPv6 bei der Einführung mehr Nachteile und Komplexität als Vorteile.
  Ich verwalte ungefähr 3500 Geräte, 7 Gebäude, 2 WANs mit 10 Gbit/s und 1 WAN mit 4 Gbit/s sowie 26 öffentliche IPv4-Adressen.
  Bis heute gab es keinen einzigen Grund, der zwingend IPv6 erforderlich gemacht hätte.
  Dual-Stack erzeugt nur unnötige Last und Komplexität im Netzwerk.
  Ich habe vor Kurzem sogar zweimal versucht, einen festen IPv6-Adressblock zu beantragen, und wurde beide Male abgelehnt.
  Praktisch gibt es keinen Nutzen, und selbst die Zuteilung ist schwierig.
  Laut ARIN-Leitfaden für den ersten IPv6-Antrag gilt man nur dann als antragsberechtigt, wenn mindestens eines davon zutrifft:
  → Zuteilung von IPv4 vorhanden
  → IPv6-Multihoming unmittelbar geplant
  → innerhalb eines Jahres 13 Endstandorte (Büros usw.)
  → innerhalb eines Jahres 2000 IPv6-Adressen
  → innerhalb eines Jahres 200 /64-Subnetze
Ich finde die Apple-App-Store-Richtlinie, dass alle Apps in IPv6-only-Netzen funktionieren müssen, wirklich sehr begrüßenswert.
Für Entwickler kann das beim ersten Mal überraschend sein, aus Sicht der Verbraucher ist so eine Vorgabe aber sehr willkommen.
- Diese Richtlinie verlangt allerdings nicht zwingend, dass die Server-Seite eine IPv6-Adresse haben muss.
- Dann frage ich mich, ob man mit der App Github auch über v6 erreichen kann.
Für die Arbeit betreiben wir mehrere IPv6-only-VPNs, um auf interne Infrastruktur zuzugreifen.
Das größte Problem ist, dass Windows- und macOS-Clients zwingend einen v6-DNS-Server benötigen.
Da sich der Client in einem Netz mit oder ohne v6-Unterstützung befinden kann, betreiben wir innerhalb des VPN selbst einen DNS-Server und verteilen ihn automatisch an die Clients.
Wenn die VPN-Verbindung allerdings getrennt wird, setzt die Wireguard-App den ursprünglichen DNS nicht wieder zurück, was diverse Probleme verursacht.
- Ich habe IPv6-only auch in einem IPv4-only-Netz meines ISP und auf macOS schon problemlos ohne separaten DNS genutzt.
  Ich erinnere mich nicht mehr genau an die Methode, aber macOS funktionierte ohne Probleme, solange nur eine v6-Adresse vergeben wurde.
  Man muss dem Host eine ULA-Adresse zuweisen; das ist einfach, wenn man weiß, wie.
  Die VPN-App könnte ein Skript nutzen, das die ULA direkt zum IPv6-only-Netz hinzufügt.
  Man sollte eine so erzeugte ULA-Adresse allerdings nicht einfach dauerhaft bestehen lassen, weil das Probleme verursachen kann, wenn der Nutzer später in ein anderes v6-Netz wechselt.
Wer dieselbe Situation hat, kann mit einem SSH-Proxy (ssh -D 8080 user@hostname) sehr einfach eine SOCKS-Proxy-Umgebung aufbauen.
Danach muss man im Browser nur localhost:8080 als Proxy eintragen.
- Genau diesen Rat wollte ich auch geben.
  Für eine kurzfristige Lösung ist das extrem einfach, und bei Bedarf eignet es sich auch hervorragend als dauerhaftes Werkzeug.
  Allerdings muss in sshd_config AllowTcpForwarding aktiviert sein.
- Ich nutze diese Methode immer in öffentlichen WLANs.
  So muss ich keinen VPN-Dienst bezahlen oder ihm vertrauen; ich leite einfach alles über den SOCKS-Proxy auf meinem infomaniak-Server.
Persönlich habe ich viele Beschwerden über IPv4, besonders weil mein ISP mich zwangsweise auf IPv4 beschränkt, was noch frustrierender ist.
Dass die Einführung von IPv6 so langsam vorangeht, sehe ich als großes Versagen der Tech-Branche.
Ich frage mich, wer dafür verantwortlich gemacht werden sollte.
Ob es an Router-Herstellern mit schlechter Firmware liegt, an der Führung der ISPs, die weiter auf IPv4 setzen, an Spekulanten mit IPv4-Adressen oder an mangelnder Ausbildung von Netzwerkingenieuren und Support-Personal – ich denke, wir brauchen mehr grundlegende Diskussion über die Ursachen.
So wie das Internet den Übergang von TLS 1.0 vergleichsweise gut geschafft hat, sollte es doch auch von IPv4 wegkommen können.
Vielleicht könnten später so etwas wie KI-Proxys für Legacy-Code eine Lösung sein.
- Der Wechsel weg von TLS 1.0 war leichter wegen des End-to-End-Prinzips.
  Es reichte, wenn Server und Clients das neue Protokoll unterstützten; Geräte dazwischen wie Router oder Switches mussten nur die Netzwerkschicht (IP) sehen und waren von neuen TLS-Versionen nicht betroffen.
  Wenn aber sogar das Protokoll der Netzwerkschicht (IP) geändert wird, betrifft das alle Zwischenkomponenten im Netz.
  Übrigens zeigte sich selbst bei der Einführung von TLS 1.3, dass Middleboxes das End-to-End-Prinzip brechen, Traffic überwachen oder verändern und TLS 1.3 aus Kompatibilitätsgründen teils so tun musste, als wäre es ein TLS-1.2-Reconnect.
- Der Unterschied ist, dass bei TLS nur Server und Client unterstützen müssen und die Geräte dazwischen lediglich TCP-Pakete sehen.
  IPv6 muss dagegen von allen Zwischenkomponenten zwischen Server und Client unterstützt werden und ist damit von einem „kleinsten gemeinsamen Nenner“ abhängig.
  Beim TLS-Upgrade änderte sich nicht so viel Grundlegendes, während IPv6 zu viele Dinge auf einmal verändert hat.
  Rückblickend denke ich manchmal, IPv6 hätte sich vielleicht leichter verbreitet, wenn man einfach nur die Adressen auf 64 Bit vergrößert hätte.
- Realistisch gesehen sind viele Menschen beim Umstieg zurückhaltend, weil der praktische Nutzen zu klein oder fast nicht vorhanden ist.
  Es braucht dafür keine große IPv4-Verschwörung; Aufwand und Risiko stehen einfach in keinem guten Verhältnis zum Gewinn.
- In der Netzwerkbranche gibt es den Witz, IPv6 sei „eine akademische Lösung, die auf ein Engineering-Problem aufgepfropft wurde“.
  Wenn man großflächige Einführung, gleichzeitige IPv4-Kompatibilität und den realen Betrieb samt Wartung berücksichtigt, ist IPv6 schlicht zu komplex.
  IPv4 hat de facto außer der Adressknappheit kein wirkliches Problem, also wird es auch nicht verschwinden.
  Deshalb ist IPv6 in der Praxis vielerorts keine wirklich funktionierende Lösung geworden.