Im Februar 2011 vergab die IANA (Internet Assigned Numbers Authority) ihre letzten freien IPv4-Adressblöcke an die regionalen Vergabestellen. In Europa (RIPE NCC) war der Pool 2019 erschöpft. IPv4-Adressen werden heute auf Sekundärmärkten gehandelt — einzelne Adressen für 30–60 Dollar, größere Blöcke entsprechend mehr. Das Netz läuft weiter, weil NAT das Grundproblem kaschiert. Aber der Druck wächst, und für Selbsthoster ist IPv6 längst kein optionaler Exotismus mehr.
Warum IPv4 knapp ist und bleibt
IPv4 bietet 32-Bit-Adressen, also etwa 4,3 Milliarden mögliche Adressen. Klingt nach viel — bis man bedenkt, dass allein China mehr als 1,4 Milliarden Menschen hat, die alle ans Netz wollen. Dazu kommen IoT-Geräte, Cloudinfrastruktur, und der grundsätzliche Anspruch, dass jedes Gerät direkt erreichbar sein sollte.
NAT (Network Address Translation) war die Brückenlösung: Ein Router mit einer öffentlichen IP teilt sie mit Dutzenden oder Hunderten privater Geräte. Das funktioniert für ausgehende Verbindungen gut, macht eingehende Verbindungen aber komplex (Port-Forwarding, UPnP, Hole-Punching). Für Server, VoIP, Peer-to-Peer und IoT ist NAT ein ständiges Hindernis.
IPv6: Zahlen die den Kopf schweben lassen
IPv6 nutzt 128-Bit-Adressen: 2¹²⁸ mögliche Adressen, also etwa 3,4 × 10³⁸. Konkret: Jeder Quadratmillimeter der Erdoberfläche könnte 665 Billiarden IPv6-Adressen bekommen. Praktisch bedeutet das: Jedes Gerät bekommt seine eigene, weltweit eindeutige Adresse — NAT wird überflüssig.
Eine typische IPv6-Adresse sieht so aus: 2a01:4f8:c17:1337::1. Das doppelte Doppelpunkt (::) ist eine Kurzschreibweise für eine Folge von Null-Blöcken. Die Länge schreckt zunächst ab, ist aber in der Praxis seltener manuell einzugeben als IPv4-Adressen.
Hetzner und IPv6: Was man bekommt
Hetzner vergibt an Dedicated Server standardmäßig ein /64-Subnetz — das sind 2⁶⁴ Adressen, also 18,4 Trillionen. Für einen einzelnen Server mehr als genug, um jedem Dienst, Container und VM eine eigene öffentliche IP zu geben. Hetzner Cloud-Instanzen erhalten eine einzelne IPv6-Adresse sowie ein /64-Subnetz.
# IPv6-Adresse und Subnetz anzeigen
ip -6 addr show
ip -6 route show
# Erreichbarkeit testen
ping6 google.com
ping6 2a00:1450:4001:82b::200e # Google direktDual-Stack: IPv4 und IPv6 parallel
Der sinnvolle Übergang ist Dual-Stack: Ein Server ist sowohl über IPv4 als auch IPv6 erreichbar. Clients verbinden sich dann über das jeweils verfügbare Protokoll — moderne Betriebssysteme bevorzugen IPv6 wenn vorhanden (RFC 6724, Happy Eyeballs).
Für Nginx-Konfiguration bedeutet Dual-Stack:
server {
listen 80;
listen [::]:80; # IPv6
listen 443 ssl;
listen [::]:443 ssl; # IPv6
server_name example.com;
# ...
}Die eckigen Klammern sind IPv6-Pflicht in URLs und Konfigurationen: http://[2a01:4f8::1]/.
DNS: AAAA-Records
IPv4-Adressen werden in DNS als A-Records hinterlegt. IPv6 verwendet AAAA-Records ("Quad-A"):
# /etc/bind/zones/example.com oder Cloudflare-UI
example.com. IN A 203.0.113.1
example.com. IN AAAA 2a01:4f8:c17:1337::1Wer beide Records setzt, ist automatisch Dual-Stack. Clients mit IPv6 bevorzugen AAAA, alle anderen fallen auf A zurück.
Der häufigste Fehler: Die IPv6-Firewall vergessen
Das ist der kritischste Punkt. Wer seine iptables/nftables-Regeln sorgfältig gepflegt hat, schützt damit nur IPv4. IPv6-Traffic läuft über ip6tables (iptables-Legacy) oder nftables (empfohlen). Wer das vergisst, hat einen Server, der auf IPv6 vollständig offen ist — während er glaubt, geschützt zu sein.
# nftables: Vollständige Dual-Stack-Firewall
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Loopback immer erlauben
iifname lo accept
# Established/Related
ct state established,related accept
# ICMP (für IPv6 essentiell!)
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
# SSH
tcp dport 22 accept
# HTTP/HTTPS
tcp dport { 80, 443 } accept
# Alles andere verwerfen
}
chain forward { type filter hook forward priority 0; policy drop; }
chain output { type filter hook output priority 0; policy accept; }
}Wichtig: ICMPv6 bei IPv6 niemals blockieren. IPv6 ist fundamental auf ICMPv6 angewiesen — Neighbor Discovery (das IPv6-Äquivalent zu ARP), Path MTU Discovery und Router Solicitation funktionieren alle über ICMPv6. Wer ICMPv6 blockt, bekommt seltsame, schwer debuggbare Verbindungsprobleme.
Vorteile für Selbsthoster
Der konkreteste Vorteil von IPv6 für Selbsthoster: Kein NAT, kein Port-Forwarding mehr. Jeder Dienst auf jedem Container bekommt eine eigene öffentliche Adresse. Ein Proxmox-Host mit 10 VMs kann jeder VM ihre eigene IPv6-Adresse geben — ohne Konflikte, ohne Port-Mapping-Tabellen, ohne NAT-Hairpin-Probleme.
Praktisch: Wenn ein Heimserver hinter einem Router sitzt, der IPv6 und DHCPv6-PD (Prefix Delegation) unterstützt, bekommt der gesamte Heimnetzbereich ein eigenes öffentliches Subnetz. Fritzbox und Ubiquiti unterstützen das, viele andere Router inzwischen auch.
IPv6-only: Noch nicht reif
Vollständig auf IPv4 zu verzichten ist für öffentliche Dienste noch nicht sinnvoll. Nicht alle Netze, Provider und Endgeräte unterstützen IPv6 zuverlässig — insbesondere in Unternehmensnetzen und auf mobilen Geräten älterer Generation. Dual-Stack ist der realistische Status quo für die nächsten Jahre.
Fazit
IPv6 ist nicht mehr Zukunftsmusik — es ist die Gegenwart für alle, die Server betreiben. Hetzner liefert IPv6 kostenlos mit, die Konfiguration ist nicht schwieriger als IPv4, und der Nutzen (besonders für Selbsthoster) ist real. Der einzige echte Mehraufwand: Die IPv6-Firewall-Regeln nicht vergessen. Wer heute mit Dual-Stack startet, ist für die nächste Dekade gerüstet.
Stateless Address Autoconfiguration (SLAAC)
IPv6 hat gegenüber IPv4 einen erheblichen Vorteil bei der Adresszuweisung: SLAAC (Stateless Address Autoconfiguration). Ein Interface kann seine eigene IPv6-Adresse basierend auf dem Netzwerkpräfix (vom Router per Router Advertisement erhalten) und der eigenen MAC-Adresse (oder einem zufälligen Suffix) automatisch konfigurieren — ohne DHCP-Server.
# SLAAC-Adressen anzeigen
ip -6 addr show scope global
# Router Advertisement empfangen (Debug)
rdisc6 eth0
# Privacy Extensions aktivieren (randomisiertes Interface-ID)
# /etc/sysctl.conf
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2Privacy Extensions sind wichtig: Ohne sie enthält die IPv6-Adresse die MAC-Adresse des Interfaces (EUI-64), was Tracking ermöglicht. Mit Privacy Extensions rotiert die globale Adresse regelmäßig.
Statisches IPv6 auf Hetzner Dedicated
# /etc/network/interfaces (Debian/Ubuntu)
iface eth0 inet6 static
address 2a01:4f8:c17:1337::1
netmask 64
gateway fe80::1
# Oder explizite Gateway-Adresse
# gateway 2a01:4f8:c17::1
# Alternativ mit ip6tables-Firewall und Systemd-Netzwerkkonfiguration
# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Network]
Address=2a01:4f8:c17:1337::1/64
Gateway=fe80::1
IPv6AcceptRA=noIPv6 in Docker und Containern
Docker unterstützt IPv6, hat es aber standardmäßig deaktiviert — ein häufiger Fehler der dazu führt, dass Container auf IPv4 limitiert sind auch wenn der Host dual-stack ist.
# /etc/docker/daemon.json
{
"ipv6": true,
"fixed-cidr-v6": "fd00:dead:beef::/48",
"experimental": true,
"ip6tables": true
}
# Docker Compose: IPv6 für ein Netzwerk aktivieren
networks:
webnet:
enable_ipv6: true
ipam:
config:
- subnet: fd00:dead:beef::/48Für Proxmox LXC-Container gilt: Das Subnetz des Hosts (/64) kann aufgeteilt werden, sodass jeder Container eine eigene öffentliche IPv6-Adresse bekommt. Das ist einer der überzeugendsten Vorteile von IPv6 für Selbsthoster — keine Port-Weiterleitung mehr nötig.
IPv6-Troubleshooting: Häufige Probleme
# Ping6 funktioniert nicht: Firewall prüfen
ip6tables -L -n -v
# ICMPv6 muss erlaubt sein!
# Neighbor Discovery funktioniert nicht
# (Äquivalent zu ARP bei IPv4)
ip -6 neighbor show
# MTU-Probleme (häufig bei Tunneln)
# IPv6 minimum MTU: 1280 Bytes
# Path MTU Discovery testen:
tracepath6 google.com
# Routing-Tabelle
ip -6 route show
# DNS-Auflösung für IPv6
dig AAAA google.com @1.1.1.1Zukunft: IPv6-only und NAT64
Mobilfunknetze gehen bereits auf IPv6-only über. Apple erfordert seit 2016 IPv6-Unterstützung für iOS-Apps im App Store. Der Übergang beschleunigt sich — in einigen Jahren werden IPv4-only-Server schlicht nicht mehr erreichbar sein für einen wachsenden Teil der Nutzer.
NAT64/DNS64 ist die Übergangstechnologie: IPv6-only-Clients können über einen NAT64-Gateway auf IPv4-only-Server zugreifen. Das ist für Selbsthoster relevant, die ihre Infrastruktur zukunftssicher aufstellen wollen.
DHCPv6 vs. SLAAC: Wann welches?
IPv6 kennt zwei Adresszuweisungsmethoden. SLAAC (Stateless Address Autoconfiguration) ist zustandslos — Adressen werden automatisch aus dem Router-Präfix und einem Interface-Identifier gebildet, kein Server nötig. DHCPv6 ist zustandsbasiert — ein DHCPv6-Server vergibt Adressen aus einem Pool, ähnlich wie DHCP bei IPv4.
Für Heimnetzwerke und einfache Setups reicht SLAAC. Für Unternehmensumgebungen, die bestimmten Geräten feste Adressen zuweisen wollen, oder für DNS-Konfiguration (SLAAC liefert keine DNS-Server, DHCPv6 schon), ist DHCPv6 sinnvoller. In der Praxis nutzen viele Netzwerke beides: SLAAC für die globale Adresse, DHCPv6 für DNS-Server-Information.
# Stateless DHCPv6 (nur DNS, keine Adressvergabe)
# dnsmasq Konfiguration:
dhcp-range=::1,::FFFF,constructor:eth0,ra-only
dhcp-option=option6:23,[2606:4700:4700::1111],[2606:4700:4700::1001] # DNS
# ISC-DHCP-Server für DHCPv6
subnet6 2a01:4f8:c17:1337::/64 {
range6 2a01:4f8:c17:1337::100 2a01:4f8:c17:1337::1ff;
option dhcp6.name-servers 2606:4700:4700::1111;
}IPv6 in der Praxis: Ping-Diagnose
# IPv6-Konnektivität testen
ping6 -c4 ipv6.google.com
# Trace zum Ziel
traceroute6 ipv6.google.com
# Lokale Link-Adresse des Gateways finden
ip -6 neigh show # Wie ARP-Tabelle bei IPv4
# MTU-Pfadentdeckung
ping6 -c1 -s 1400 ipv6.google.com # Großes Paket
ping6 -c1 -s 1480 ipv6.google.com # Noch größer
# Alle IPv6-Adressen des Interfaces
ip -6 addr show dev eth0Globaler IPv6-Adoptionsstand
Google veröffentlicht kontinuierlich Statistiken zur IPv6-Adoption unter seinen Nutzern. Stand 2026: Über 45% aller Google-Anfragen kommen bereits über IPv6. Deutschland liegt mit etwa 55–60% IPv6-Adoption bei Endnutzern im europäischen Spitzenfeld — getrieben durch Telekom und Vodafone, die ihre Mobilfunknetze bereits IPv6-first betreiben.
Der Anteil reiner IPv4-only-Nutzer schrumpft kontinuierlich. Für Selbsthoster, die öffentliche Dienste betreiben, ist das eine klare Aussage: Wer heute kein IPv6 anbietet, ist für einen wachsenden Teil der Nutzer schlechter erreichbar als IPv6-fähige Konkurrenten.
Reverse DNS bei IPv6: PTR-Records im /64-Subnetz
Für IPv4 ist ein PTR-Record (Reverse-DNS) Standard — Mailserver prüfen ihn obligatorisch. Bei IPv6 ist das komplexer: Ein /64-Subnetz hat 18,4 Trillionen mögliche Adressen. PTR-Records für alle zu erstellen ist unmöglich. Stattdessen delegiert Hetzner die Reverse-DNS-Zone für das gesamte /64-Subnetz an den Kunden, der dann selbst PTR-Records für genutzte Adressen erstellen kann.
# Hetzner Robot: Reverse-DNS für IPv6-Adresse setzen
# Über das Robot-Panel: Server → IPs → IPv6-Netz → Reverse-DNS
# Über die Hetzner Cloud API:
curl -X PUT -H "Authorization: Bearer $HCLOUD_TOKEN" -H "Content-Type: application/json" -d '{"ip": "2a01:4f8:c17:1337::1", "dns_ptr": "mail.example.com"}' https://api.hetzner.cloud/v1/servers/123/actions/change_dns_ptr
# PTR-Record prüfen
dig -x 2a01:4f8:c17:1337::1 PTRFür Mailserver ist der PTR-Record auch bei IPv6 Pflicht. Wenn man mehrere Server-IPs für E-Mail nutzt (z.B. für bessere Zustellbarkeit durch IP-Rotation), braucht jede IP einen eigenen PTR-Record.
IPv6 Security: Unterschätzte Angriffsvektoren
IPv6 bringt neue Angriffsvektoren mit, die bei IPv4 nicht existierten. Der häufigste: Router Advertisement (RA) Spoofing. Da Hosts bei SLAAC auf Router Advertisements vertrauen, kann ein Angreifer im lokalen Netz ein gefälschtes RA senden und sich als Default-Gateway einschleusen — ein Man-in-the-Middle-Angriff auf Protokollebene.
# Schutz: RA Guard auf Switches (wenn unterstützt)
# Oder auf Hosts: RA-Akzeptanz einschränken
# /etc/sysctl.conf
net.ipv6.conf.all.accept_ra = 0 # Keine RAs akzeptieren
net.ipv6.conf.eth0.accept_ra = 1 # Außer auf dem WAN-Interface
# IPv6-Firewall: ICMP6 gefiltert zulassen
# Nicht alle ICMPv6-Typen blind durchlassen!
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP # Auf internen InterfacesIPv6 Routing im Heimnetz: Fritzbox-Konfiguration
Die Fritzbox unterstützt IPv6 und DHCPv6-Prefix-Delegation bereits seit Jahren. Konfiguration: Heimnetz → Netzwerk → IPv6-Adressen → "Unterstützung für IPv6 aktiv" und "ULA-Präfix zuweisen". Der ISP delegiert ein /56-Präfix, die Fritzbox verteilt daraus /64-Subnetze an die Heimnetzgeräte.
Für Selbsthoster bedeutet das: Jedes Gerät im Heimnetz bekommt eine öffentliche IPv6-Adresse. Port-Forwarding für IPv6 ist nicht nötig — aber die IPv6-Firewall der Fritzbox (standardmäßig aktiv und restriktiv) muss entsprechend geöffnet werden für Dienste, die von außen erreichbar sein sollen.
IPv6-Adoption in Deutschland: Der aktuelle Stand
Deutschland gehört zur IPv6-Avantgarde in Europa. Die großen deutschen Provider — Deutsche Telekom, Vodafone, 1&1 — betreiben ihre Netzwerke bereits Dual-Stack oder sogar IPv6-first. Mobilfunk-Verbindungen unter diesen Providern sind seit Jahren primär IPv6. Das bedeutet: Wer einen öffentlichen Dienst betreibt und kein IPv6 anbietet, ist für einen substanziellen Teil der deutschen Mobilfunk-Nutzer über einen NAT64-Pfad erreichbar — mit mehr Latenz als direkte IPv6-Verbindungen.
Der Aufwand für Dual-Stack ist überschaubar: AAAA-Record setzen, IPv6-Firewall konfigurieren, Dienste auf IPv6 lauschen lassen. Das dauert auf einem gut konfigurierten Server weniger als eine Stunde. Die Alternative — IPv6 weiter ignorieren — wird mit jedem Monat teurer, weil der IPv4-only-Anteil der Nutzer schrumpft und die Erreichbarkeit über NAT64 nie so gut ist wie direkte IPv6-Verbindungen.
IPv6 ist keine Zukunftstechnologie — es ist die Gegenwart für einen wachsenden Teil der Nutzer. Wer öffentliche Dienste betreibt und heute noch IPv4-only ist, verliert bereits Erreichbarkeit und Performance gegenüber IPv6-fähigen Alternativen. Der Aufwand für Dual-Stack ist eine einmalige Investition von wenigen Stunden. Die Rendite: bessere Erreichbarkeit, kein NAT-Overhead, und eine Infrastruktur die für die nächste Dekade gerüstet ist.
Der Schritt zu Dual-Stack beginnt mit einem AAAA-Record. Wenn der Dienst danach für IPv6-Clients erreichbar ist, ist der wichtigste Teil getan. Alle weiteren Details sind iterative Verbesserungen — aber der erste AAAA-Record ist der entscheidende.