Checkliste zur IPv6-Aktivierung für eine Website

Ziel

Die Website über IPv6 ebenso zuverlässig ausliefern wie über IPv4, ohne dass ein Client eine langsamere oder fehlschlagende Verbindung erlebt, weil ein AAAA-Eintrag veröffentlicht wurde, bevor der dahinterliegende Pfad funktionierte.

Voraussetzungen

Eine zum Host oder Load Balancer geroutete IPv6-Adresse, Kontrolle über die Zone und Shell-Zugriff, um Tests von einem Netzwerk mit IPv6 aus auszuführen.

Schritte

1. Die Adresse auf dem Host konfigurieren und die Firewall dafür separat öffnen; bei iptables ist ip6tables ein eigenes Regelwerk, und ein Host, der nur auf v4 antwortet, weil nie v6-Regeln geschrieben wurden, ist ein verbreiteter Zustand.
2. Den Webserver lauschen lassen. nginx' Dokumentation erklärt, dass ipv6only, standardmässig eingeschaltet, bestimmt, ob ein IPv6-Socket auf der Wildcard-Adresse [::] nur IPv6-Verbindungen oder beide akzeptiert; bei der Standardeinstellung muss listen [::]:443 ssl; von listen 443 ssl; für IPv4 begleitet werden. Neu starten und mit ss -ltn prüfen, dass beide Sockets existieren.
3. Vor der Veröffentlichung des DNS per Adresse testen: curl -6 --resolve example.com:443:[2001:db8::1] https://example.com/ und dasselbe für HTTP-zu-HTTPS-Umleitungen und für jeden Hostnamen; das Zertifikat über v6 prüfen, wie im Artikel zur TLS-Kette beschrieben.
4. Alles hinter der Front prüfen: Reverse Proxys, die die Client-Adresse weiterreichen, Ratenbegrenzung und Missbrauchsregeln, die nach Adresse gruppieren (ein Anschluss hält meist ein ganzes Präfix, sodass sich adressbezogene Limits anders verhalten), Geolokalisierung, Log-Parsing sowie jede Positivliste, die nur IPv4-Adressen enthält.
5. Den AAAA-Eintrag mit einer kurzen TTL veröffentlichen. RFC 3596 definiert AAAA als den Eintragstyp, der eine einzelne IPv6-Adresse speichert; RFC 8305 lässt Dual-Stack-Clients AAAA und A nacheinander abfragen.
6. Protokolle auf v6-Verkehr und Fehler beobachten. RFC 8305 beschreibt, wie Happy-Eyeballs-Clients beide Familien auflösen, IPv6 bevorzugen und nach einer kurzen Verzögerung auf IPv4 zurückfallen, falls der erste Versuch keine Verbindung herstellt; ein Client mit diesem Verhalten tarnt einen defekten v6-Pfad daher als kleine Verzögerung, während ein Client ohne dieses Verhalten auf sein Timeout wartet oder scheitert. Mit curl -6, das die Familie erzwingt, sowie mit einem Browser testen.
7. Monitoring-Sonden hinzufügen, die nur über IPv4 und nur über IPv6 verbinden, damit der Ausfall einer Familie sichtbar wird, statt herausgemittelt zu werden. Die TTL erhöhen, sobald es stabil läuft.

Erwartetes Ergebnis

Beide Adressfamilien liefern identische Inhalte und Zertifikate aus, das Monitoring zeigt sie getrennt an, und keine Regel hinter dem Frontend behandelt v6-Clients versehentlich anders.

Grenzen und Prüfbasis

Mail, SSH und andere Dienste auf demselben Hostnamen erhalten ebenfalls einen AAAA-Eintrag und brauchen dieselbe Prüfung. Die Reihenfolge der Schritte und das Client-Verhalten folgen den zitierten RFCs und der Dokumentation; es werden keine Verkehrsanteile oder Latenzen behauptet.