<style> .reveal .slides { background: url(https://hedgedoc.xinux.net/uploads/xinux-weiss.png) no-repeat; background-position: right 10px bottom 10px; background-size: 80px; } .reveal ul li { font-size: 28px !important; line-height: 1.3 !important; margin-bottom: 10px !important; } .reveal .slides section { text-align: left; padding: 20px 40px !important; } </style> ## Übergangstechniken und organisatorische Steuerung Steuerung, Dokumentation und Rückbau von Mechanismen zwischen IPv4 und IPv6. --- ## Ziel der Reihe - Festlegung einer **Übergangsstrategie** - Definition von **Betriebs- und Freigabeprozessen** - Sicherstellung von **Transparenz, Nachvollziehbarkeit und Rückbaufähigkeit** --- ## Organisatorische Ausgangslage - IPv4 und IPv6 laufen über Jahre parallel - Übergangstechniken sind **kritische Schnittstellen** - Ziel: kein Dauerbetrieb von Übergangskomponenten - Verantwortung muss eindeutig geregelt sein --- ## Festlegung der Übergangsstrategie - Auswahl genehmigter Verfahren (Dual Stack, NAT64, DNS64, DS-Lite, Proxy) - Entscheidungsgremium: IPv6-Steuerungsteam - Dokument: *„Übergangsrichtlinie IPv4/IPv6“* - Enthält Laufzeit, Zuständigkeiten, Rückbauziel und Review-Fristen - **Jede Technik muss einen klar benannten "Business Owner" haben.** <!-- ERGÄNZUNG --> --- ## Die Gefahr der "stillen Ablösung" <!-- NEUE FOLIE --> - **Dual Stack wird zum Standard, ohne dass IPv4 abgeschaltet wird.** - **NAT64/DS-Lite bleiben als "unsichtbare Krücke" im Betrieb.** - **Ergebnis:** Die Komplexität und Angriffsfläche des Gesamtsystems bleibt dauerhaft erhöht. - **Gegenmittel:** Eine verbindliche **Abschalt-Roadmap für IPv4** pro Anwendung/Netz. --- ## Betriebs- und Sicherheitsrichtlinien - Übergangsgeräte gelten als **sicherheitskritische Infrastruktur** - Logging-, Monitoring- und Auditpflicht - Betrieb nach festgelegtem Change-Prozess - Verantwortlichkeiten klar definiert (Betrieb / Security / Management) - **Regelmäßige Penetration Tests für Übersetzungs-Komponenten (NAT64, Tunnelbroker).** <!-- ERGÄNZUNG --> --- ## Kommunikation und Dokumentation - Alle Übergangsmaßnahmen müssen dokumentiert sein: - Standort, Verantwortliche, Laufzeit, Version - Änderungen nur nach Freigabe - Regelmäßige Information an betroffene Teams - Integration in CMDB und IPv6-Betriebshandbuch - **Ein "Übergangs-Dashboard" visualisiert den Fortschritt hin zu IPv6-Only.** <!-- ERGÄNZUNG --> --- ## Rückbau- und Abschaltstrategie - Übergangstechniken sind **zeitlich befristet** - Rückbaukriterien festlegen (z. B. < 5 % IPv4-Anteil) - Zeitplan und Verantwortlichkeiten dokumentieren - Abschlussbericht und Audit vor Deaktivierung - **Probeläufe ("IPv4-Blackout-Tests") in isolierten Testumgebungen durchführen.** <!-- ERGÄNZUNG --> --- ## Risiken fehlender Steuerung <!-- NEUE FOLIE --> - **Vendor-Lock-in:** Abhängigkeit von speziellen Herstellerlösungen für die Übersetzung. - **Komplexitätsfalle:** Die Gesamtarchitektur wird unwartbar und fehleranfällig. - **Kostenfalle:** Lizenzen und Betriebskosten für Übergangslösungen laufen ewig weiter. - **Sicherheitsblindheit:** Unklarheit, welcher Verkehr welche Übersetzung durchläuft. --- ## Fazit Übergangstechniken sind **organisatorisch zu steuern, nicht technisch dem Zufall zu überlassen**. Nur durch klare Richtlinien, Zuständigkeiten und Rückbauplanung bleibt der Weg von Dual Stack zu IPv6-Only kontrollierbar und prüfbar. **Das ultimative Ziel ist nicht die perfekte Koexistenz, sondern die geordnete Beerdigung von IPv4.** <!-- ERGÄNZUNG -->