## Vorteile eines IPv6-Only Netzes - saubere, konsistente Adressierung mit /64-Subnetzen - einfachere Firewall-Regeln ohne NAT-Konstrukte - einheitliche Sicherheits- und Routing-Policy - bessere Segmentierung und Isolation von Netzen möglich --- ## Nachteile eines IPv6-Only Netzes - externe IPv4-Dienste nicht direkt erreichbar - Altgeräte und Software ohne IPv6-Unterstützung unbrauchbar - höhere Komplexität bei Übergangslösungen - erhöhter Planungs- und Testaufwand bei Umstellung --- ## Technische Umsetzung intern – Netzstruktur - IPv6-Adresskonzept auf Basis öffentlicher Präfixe erstellen - Subnetze klar pro Rolle/VLAN definieren (/64 pro Zone) - Implementierung von OSPFv3 oder BGP für internes Routing - vollständige DNS6-Auflösung (AAAA-Records) implementieren --- ## Technische Umsetzung intern – Firewalls und Sicherheit - eigenständige IPv6-Filterregeln definieren (nicht IPv4-Regeln kopieren) - ICMPv6 essentiell freigeben (z.B. für Path MTU Discovery, Neighbor Discovery) - Einsatz von RA-Guard und DHCPv6 Guard zum Schutz vor Rogue-RAs - vollständige Protokollierung von eingehendem und ausgehendem IPv6-Verkehr --- ## Technische Umsetzung intern – Dienste und Server - alle Server und Dienste IPv6-fähig konfigurieren - SSL/TLS-Zertifikate für IPv6-Endpunkte bereitstellen - Monitoring-Systeme IPv6-kompatibel umstellen (z.B. SNMPv3, Syslog) - DHCPv6 und/oder SLAAC sauber einrichten, je nach Bedarf --- ## Kommunikation von innen nach außen (IPv6-Only → IPv4-Internet) - IPv6-Clients nutzen Forward-Proxies für Protokollübersetzung (z.B. Squid) - Application-Level Translation für Protokolle wie HTTP, HTTPS, FTP - DNS64 erzeugt synthetische AAAA-Einträge aus A-Records - NAT64 übersetzt IPv6-Pakete auf IPv4-Pakete für den ausgehenden Verkehr --- ## Forward-Proxy (nach außen) – technische Details - IPv6-Client sendet Anfrage an lokalen Proxy - Proxy spricht auf Anwendungsebene IPv4 mit dem externen Zielserver - typische Protokolle: HTTP, HTTPS, FTP, SMTP - vollständige Protokollkontrolle und Session-Logging erforderlich --- ## DNS64 – technische Details - DNS64-Server modifiziert DNS-Antworten und erzeugt synthetische AAAA-Records - IPv6-Client erhält eine IPv6-Adresse, die intern eine IPv4-Adresse abbildet - notwendige Voraussetzung für NAT64-Betrieb - Präfix (z.B. 64:ff9b::/96) wird standardisiert eingesetzt --- ## NAT64 – technische Details - NAT64-Gateway empfängt IPv6-Verkehr und wandelt ihn in IPv4-Verkehr um - ermöglicht IPv6-Clients den Zugriff auf IPv4-Server über IP-Ebene - nur für ausgehenden, internen Verkehr zugelassen (BSI-konform) - Beispiele: Tayga, Jool, dedizierte NAT64-Router --- ## Kommunikation von außen nach innen (IPv4-Clients → IPv6-Only-Server) - IPv4-Clients erreichen Reverse-Proxy auf der externen Schnittstelle - Reverse-Proxy nimmt IPv4-Verbindung entgegen - Proxy übersetzt und leitet intern an IPv6-Server weiter - Protokolle wie HTTP, HTTPS, SMTP können unterstützt werden --- ## Reverse-Proxy (von außen) – technische Details - IPv4-Client baut TCP-Verbindung auf Reverse-Proxy auf (Port 80, 443) - Proxy terminiert Verbindung (TLS optional) und öffnet neue IPv6-Verbindung - Beispiele: nginx, HAProxy mit Dual-Stack-Interface - strikte Zugriffskontrolle, ACLs und vollständiges Logging erforderlich --- ## Alternative: IPv4-Frontend-Systeme - dedizierte Server mit IPv4-Adresse, die als Proxy oder Gateway dienen - entgegengenommene Verbindungen werden intern an IPv6-Backends weitergereicht - optionale Zwischenschaltung von Application Gateways - vollständige Isolation der Frontends vom produktiven IPv6-Only-Netz empfohlen --- ## BSI-Bewertung der Übergangslösungen - Forward-Proxies: empfohlen für ausgehenden Clientverkehr - Reverse-Proxies: empfohlen für eingehenden externen Zugriff - DNS64/NAT64: zulässig für internen ausgehenden Verkehr, nicht für eingehenden - keine direkte Annahme von IPv4-Verkehr auf internen IPv6-Systemen erlaubt --- ## BSI-Einschätzung der Übergangstechniken - Forward-Proxy und Reverse-Proxy bei vollständiger Kontrolle empfohlen - NAT64 nur für internen ausgehenden Verkehr intern zulässig - keine direkte IPv4-Kommunikation in IPv6-Only-Zonen erlaubt - VPNs, TLS-Zugänge müssen IPv6-native oder über kontrollierte Proxies realisiert werden --- ## Risiken bei unvollständiger IPv4-Abschaltung - vergessene aktive IPv4-Schnittstellen als Angriffsfläche - unnötig komplexe Monitoring- und Firewallkonfigurationen - verzögerte IPv6-Optimierung des gesamten Netzwerks - unkontrollierter Fallback auf IPv4-Dienste gefährdet Sicherheit --- ## Zusammenfassung - IPv6-Only erhöht langfristig Sicherheit und Effizienz - Externe Kommunikation über streng kontrollierte Proxies absichern - NAT64/DNS64 nur intern und gezielt einsetzen - vollständige IPv4-Abschaltung intern so früh wie möglich anstreben