Vor zwei Wochen hat ein Kunde angerufen. "Wir kriegen von unserem Rechenzentrum nur noch ein /28 IPv4 — für 30 Server." Fünf Minuten später hatte ich ihm das /28 mit dem bitcalc Subnetz-Rechner aufgemalt und gezeigt, dass bei 14 nutzbaren Adressen und 30 Servern ohne IPv6 gar nichts mehr geht. Der Umstieg ist kein Projekt für 2028. Er ist jetzt.

Dieser Artikel ist kein "IPv6 verstehen"-Crashkurs. Er ist eine pragmatische Anleitung für Admins, die den Umstieg tatsächlich machen müssen — mit den Fehlern, die ich selbst gemacht habe, und den Entscheidungen, die unter Zeitdruck fallen.

IPv6-Adressaufbau: 128 Bit, 8 Blöcke, Netzwerkpräfix und Interface-ID

Das Adressformat: 128 Bit, die keiner ausschreibt

Eine IPv6-Adresse hat 128 Bit, geschrieben als acht Gruppen zu je vier Hex-Zeichen: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Führende Nullen pro Block dürfen weg, und eine Folge von Null-Blöcken wird mit :: abgekürzt — genau einmal pro Adresse. Die Adresse von oben wird zu 2001:db8:85a3::8a2e:370:7334.

Der wichtige Teil für dich als Admin ist die Aufteilung: Die ersten 64 Bit sind das Netzwerkpräfix (typischerweise bekommst du ein /48 oder /56 vom Provider). Die letzten 64 Bit sind die Interface-ID — die kann per SLAAC, DHCPv6 oder manuell vergeben werden. Ein /64 ist das kleinste praxisrelevante Subnetz, weil SLAAC ohne /64 nicht funktioniert.

Was viele übersehen: Dein Provider gibt dir meist ein /56. Das sind 256 /64-Subnetze. Du kannst also VLAN 10 das Subnetz 2001:db8:1:a::/64 geben, VLAN 20 2001:db8:1:14::/64 und so weiter — ohne jemals wieder NAT zu brauchen.

Dual-Stack: Der einzig realistische Weg

Die Idee "wir schalten IPv4 ab und machen nur noch IPv6" klingt verlockend, scheitert aber an der Realität. GitHub hatte bis 2025 keinen IPv6-Support. Teile von AWS brauchten bis 2024 dafür. Und dein Drucker von 2017 kann IPv6 vielleicht, aber der alte Sensor im Lager eher nicht.

Dual-Stack heißt: Jedes Gerät bekommt eine IPv4- und eine IPv6-Adresse. Der Server lauscht auf beiden Stacks. Der DNS liefert A- und AAAA-Records. Happy Eyeballs (RFC 8305) sorgt dafür, dass Clients IPv6 bevorzugen, aber bei Timeout auf IPv4 zurückfallen — in der Praxis fällt das nach 250 ms.

Dual-Stack-Ablauf: Client fragt DNS nach A und AAAA, probiert IPv6 zuerst, fällt nach 250ms auf IPv4 zurück

In meinem Setup läuft das auf einem nginx so:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;
    # ...
}

Das [::]:80 ist die IPv6-Entsprechung von 0.0.0.0:80. Ohne die zweite listen-Direktive ist dein Server nur über IPv4 erreichbar — und das fällt oft erst Monate später auf, wenn jemand mit einem reinen IPv6-Anschluss kommt.

SLAAC vs. DHCPv6: Die Entscheidung, die alle falsch treffen

Bei IPv4 ist das einfach: DHCP oder statisch. Bei IPv6 hast du drei Optionen, und jede hat ihre Tücken.

SLAAC (Stateless Address Autoconfiguration) lässt den Router das Präfix per Router Advertisement (RA) ankündigen, und der Client baut sich die Adresse selbst — entweder per EUI-64 (MAC-Adresse in die Interface-ID gerechnet) oder per RFC 7217 (Privacy-Adressen, die regelmäßig wechseln). Vorteil: kein DHCP-Server nötig. Nachteil: Du hast keine Kontrolle darüber, welche Adresse ein Client bekommt. Für Server ist SLAAC deshalb meist falsch.

DHCPv6 Stateful funktioniert wie IPv4-DHCP: Der Server teilt Adressen zu, du hast zentrale Kontrolle, und du kannst den Clients auch DNS-Server und NTP mitschicken. Der Haken: Android unterstützt DHCPv6 nicht. Google hat sich 2012 entschieden, dass DHCPv6 für Clients "unnötige Komplexität" ist. Wenn also Android-Geräte in deinem Netz sind, brauchst du SLAAC zusätzlich — für die Adresse — und DHCPv6 nur für Optionen wie DNS.

DHCPv6 Stateless kombiniert beides: SLAAC für die Adressen, DHCPv6 nur für DNS/NTP/Domain-Search. Das ist der Sweet Spot für die meisten Netze mit gemischten Clients.

Meine Empfehlung: Server bekommen statische IPv6-Adressen (entweder manuell oder per DHCPv6-Reservierung). Clients bekommen SLAAC + Stateless DHCPv6. Und: Das M- und O-Flag im Router Advertisement steuert, was der Client macht — M=1 heißt "frag DHCPv6 nach der Adresse", O=1 heißt "frag DHCPv6 nach Optionen".

Firewall-Regeln: IPv6 ist nicht IPv4 mit mehr Bits

Der häufigste Fehler bei der IPv6-Migration: IPv4-Firewall-Regeln 1:1 zu kopieren. IPv6 funktioniert anders. Kein NAT, keine RFC-1918-Adressen, jeder Host hat eine öffentlich routbare Adresse. Das ist großartig für Peer-to-Peer, aber es bedeutet auch: Deine Firewall ist die einzige Schutzschicht.

Was du mindestens brauchst:

# ICMPv6 — nicht blockieren! Ohne ICMPv6 kein Path MTU Discovery, kein NDP
ip6tables -A INPUT -p icmpv6 -j ACCEPT

# Etablierte Verbindungen erlauben
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH von intern
ip6tables -A INPUT -p tcp --dport 22 -s 2001:db8:1::/48 -j ACCEPT

# Alles andere drop
ip6tables -A INPUT -j DROP

ICMPv6 zu blockieren ist der Klassiker, den jeder beim ersten Mal macht. Dann wunderst du dich, warum Pakete mit 1.500 Byte MTU nicht durchgehen, obwohl der Pfad 1.280 Byte kann. Path MTU Discovery läuft über ICMPv6 Type 2 ("Packet Too Big"). Blockierst du das, blockierst du TCP.

DNS: AAAA-Records und die Fallstricke

Für jeden A-Record brauchst du einen AAAA-Record — wenn der Dienst über IPv6 erreichbar sein soll. Aber: Ein AAAA-Record ohne funktionierenden IPv6-Dienst ist schlimmer als gar keiner. Clients mit IPv6 versuchen dann zuerst IPv6, kriegen einen Timeout, fallen nach 250 ms auf IPv4 zurück. Bei 20 Requests pro Seitenaufbau sind das 5 Sekunden Latenz.

Mein Ansatz: AAAA-Records erst setzen, wenn der Dienst bewiesenermaßen über IPv6 erreichbar ist. Getestet mit curl -6 https://example.com von einem externen Host. Und: Den AAAA-Record genauso monitoren wie den A-Record. Bei meinem letzten Arbeitgeber ist ein halbes Jahr lang der AAAA-Record für das Kundenportal ins Leere gelaufen — aufgefallen ist es erst, als ein Kunde mit reinem IPv6-Anschluss sich beschwert hat.

Die Sache mit dem Downloadzeit-Rechner

Spannend wird es bei der Frage, ob IPv6 schneller oder langsamer ist. Theoretisch sollte IPv6 schneller sein: kein NAT, flachere Routing-Tabellen, kein Checksum-Recalculation bei jedem Hop. In der Praxis habe ich mit dem bitcalc Downloadzeit-Rechner nachgemessen: Ein 500-MB-Transfer über IPv4 brauchte 47 Sekunden (ca. 85 Mbit/s effektiv), derselbe Transfer über IPv6 41 Sekunden (ca. 97 Mbit/s). 15 % schneller — nicht weltbewegend, aber messbar.

Teste deine IPv6-Performance: curl -4 -o /dev/null -w "%{speed_download}\n" https://speed.hetzner.de/100MB.bin vs. curl -6 .... Die Differenz in Bytes/s gibst du in den Downloadzeit-Rechner ein und siehst sofort, was das für deine täglichen Transfers bedeutet.

Der Migrationsplan: Nicht alles auf einmal

Eine IPv6-Migration in einem Schritt ist Selbstmord. Mein Plan für die letzten drei Projekte sah so aus:

Woche 1-2: Provider-Präfix beantragen, Reverse-DNS für das /48 einrichten, eine Test-VLAN mit IPv6 aufsetzen. Woche 3-4: DNS (AAAA für alle internen Dienste), Monitoring (ICMPv6-Pings auf alle Hosts), Firewall-Regeln schreiben und auf einem Testserver prüfen. Woche 5-6: Alle Server auf Dual-Stack: IPv6-Adressen vergeben, nginx/Apache anpassen, pro Server testen. Woche 7-8: Öffentliche Dienste umstellen (AAAA-Records setzen). Clients im Büro auf Dual-Stack.

Nach jeder Phase: eine Woche Puffer für das, was kaputtgeht. Und es geht immer was kaputt. Bei einem Kunden hat der SSL-Terminator nach der IPv6-Konfiguration keine Zertifikate mehr ausgeliefert, weil das SNI-Matching nur auf IPv4 lauschte. Der Loadbalancer hat die IPv6-Requests brav an den Backend-Server durchgereicht, der sie dann mit einem Default-Zertifikat beantwortete — und der Browser zeigte eine Zertifikatswarnung.

8-Wochen-Migrationsplan: Provider-Präfix, Test-VLAN, DNS, Dual-Stack Server, öffentliche Dienste, Clients

Was ich heute anders machen würde

Drei Dinge. Erstens: ULA-Adressen (Unique Local Addresses, fd00::/8) von Anfang an einplanen. Ja, IPv6 braucht kein NAT, aber ein internes Adressschema, das unabhängig vom Provider-Präfix ist, macht das Leben einfacher. Wenn der Provider irgendwann ein neues Präfix vergibt, musst du nur die öffentlichen Adressen ändern — die internen ULA-Adressen bleiben gleich.

Zweitens: NPTv6 (Network Prefix Translation) ist kein Verbrechen. Manche tun so, als wäre NAT66 ein Sakrileg, aber wenn dein Uplink-Provider dir nur ein statisches /64 gibt und du mehrere interne Subnetze hast, ist NPTv6 die pragmatische Lösung. Es ist 1:1 (nicht many-to-one wie bei IPv4-NAT), also kein Port-Mapping, kein State-Tracking-Wahnsinn.

Drittens: Privacy Extensions (RFC 4941) auf Servern deaktivieren. Auf Clients super, auf Servern katastrophal. Der Server wechselt alle paar Stunden seine IPv6-Adresse — und deine Firewall-Regeln und DNS-Records laufen ins Leere. Bei systemd-networkd: [Network] IPv6PrivacyExtensions=no.

Fazit

IPv6 ist nicht die Zukunft. Es ist die Gegenwart, die wir zu lange ignoriert haben. Der Umstieg ist Arbeit, aber planbar. Dual-Stack funktioniert, SLAAC + Stateless DHCPv6 ist der Sweet Spot, und ICMPv6 blockierst du genau einmal — danach nie wieder.

Nächster Schritt: Log dich auf deinem Edge-Router ein und prüf, ob dein Provider dir überhaupt ein IPv6-Präfix zuweist. Wenn nicht: Provider wechseln oder Tunnelbroker wie Hurricane Electric (tunnelbroker.net) nutzen. Das ist nicht ideal, aber besser als abwarten.