IPv6 einrichten: Dual-Stack Setup für Linux-Server

IPv6 ist seit 1998 spezifiziert. Wir haben jetzt 2026, und IPv4-Adressen sind weitgehend aufgebraucht — neue Adressen für mein Heim-Internet gibt's nur noch CGNAT-basiert. Trotzdem läuft die Mehrheit des Web-Traffics noch IPv4. Der Wechsel zieht sich, weil sich beide Protokolle nicht direkt verstehen und niemand in einem reinen IPv6-Netz auskommen kann, ohne IPv4 für irgendwas zu brauchen.

Für einen Server bedeutet das praktisch: Dual-Stack. Der Server bekommt eine IPv4 und eine IPv6, beide gleichzeitig erreichbar. Die meisten VPS-Provider machen das mittlerweile als Default — aber man muss wissen, wie man die IPv6-Seite richtig nutzt.

Was Dual-Stack heißt

Beide Protokolle parallel: jeder Service lauscht auf v4 und v6, jede DNS-Antwort enthält A- und AAAA-Records, Clients wählen je nach Verbindung. In modernen Browsern und OS ist die Logik "Happy Eyeballs": probiere v6 und v4 parallel, nimm das, was zuerst antwortet.

Folge: wenn deine v6-Konfiguration kaputt ist, merkst du es lange nicht — Clients fallen auf v4 zurück. Die ersten Symptome sind oft langsame Verbindungen, weil ein paar Sekunden auf den v6-Timeout gewartet wird, bevor v4 versucht wird.

Subnetting: was die /64 wirklich bedeutet

Bei IPv4 ist man Adressen-knausern gewohnt. Bei IPv6 funktioniert das anders. Die Standard-Subnet-Größe ist /64 — das sind 2^64 Adressen pro Subnet. Mehr als alle IPv4-Adressen weltweit, in einem Subnet.

Mein VPS-Hoster gibt mir ein /64. Das heißt: ich kann auf einem einzelnen Server beliebig viele IPv6-Adressen vergeben, ohne den Provider fragen zu müssen.

Praktisch: für jeden virtuellen Host, jeden Container, jede Anwendung kann ich eine eigene v6 nehmen. Das ist nicht "kostbar", das ist "vorhanden". Eine v6 pro Mailserver-Instanz, eine pro Webserver-vhost, eine fürs Backup-Script — kein Konflikt.

Konfiguration unter Debian/Ubuntu

Bei modernen Systemen mit netplan:

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 5.75.x.y/24
        - 2a01:abcd::1/64
      gateway4: 5.75.x.1
      gateway6: fe80::1
      nameservers:
        addresses: [8.8.8.8, 2001:4860:4860::8888]

netplan apply, dann ip -6 addr zur Verifikation.

Wichtig: das Default-Gateway für IPv6 ist oft eine Link-Local-Adresse (fe80::1), nicht eine globale. Das verwirrt beim ersten Mal. Der Hoster gibt das normalerweise mit der Zugangsinfo mit.

ip6tables und nftables

iptables und ip6tables sind getrennte Welten — eine Firewall-Regel für v4 schützt v6 nicht. Wer UFW nutzt, hat das automatisch erledigt:

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

UFW konfiguriert v4 und v6 parallel — nichts extra zu tun.

Wer raw nftables schreibt: zwei Tables sind nötig, oder eine inet-Table, die beide Protokolle abdeckt:

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif lo accept
        tcp dport { 22, 80, 443 } accept
    }
}

inet statt ip6 oder ip — gilt für beide.

Reverse DNS für IPv6

Ein häufig vergessener Punkt: PTR-Records (Reverse DNS) für IPv6. Ohne PTR-Record wird deine Mail von vielen Servern abgelehnt, auch wenn SPF/DKIM/DMARC perfekt sind.

dig -x 2a01:abcd::1

Sollte deinen Hostnamen zurückgeben. Wenn nicht: beim Hoster den Reverse-DNS-Eintrag setzen. Bei Hetzner, OVH und den meisten anderen geht das im Web-Interface.

Häufige Fallen

Services binden nur auf 0.0.0.0 statt auch auf v6. PostgreSQL, MariaDB, Redis — viele binden per Default nur auf IPv4. In den Configs 0.0.0.0 durch :: ersetzen, oder beide explizit angeben.

Firewall-Regeln nur auf v4. Wer iptables -A INPUT -p tcp --dport 22 -j ACCEPT schreibt und vergisst, das gleiche für ip6tables zu tun, hat einen offenen Port auf v6, den er nicht erwartet.

MTU-Probleme. IPv6 hat eine Mindest-MTU von 1280. Manche Tunnel-Konfigurationen sind kaputt und fragmentieren falsch — Symptom: bestimmte Sites sind über v6 nicht erreichbar, aber Pings funktionieren. tracepath6 example.com zeigt die effektive MTU.

Lohnt sich das?

Für reine Server-Workloads: ja, ohne Frage. Mehr Adressen, weniger NAT-Probleme, langfristiger der Standard-Pfad.

Eine Sache, die mir IPv6 in der Praxis tatsächlich gebracht hat: keine Angst mehr vor Port-Konflikten. Statt 30 Container auf 30 Ports zu verteilen, kriegt jeder seine eigene IPv6 und lauscht auf 80 oder 443. Das macht Konfigurationen lesbarer.