<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 section { text-align: left; padding: 20px 40px !important; } .reveal h2 { font-size: 34px !important; margin-bottom: 10px !important; } .reveal ul li { font-size: 26px !important; line-height: 1.25 !important; margin-bottom: 6px !important; } .reveal code { font-size: 24px !important; } </style> ## Ziel: Zentrale Adressverwaltung mit DHCPv6 - **Maximale Kontrolle** über IP-Adressvergabe - **Keine automatische Adressbildung** durch Hosts (A=0) - **DHCPv6 verwaltet komplett** Adressen + Konfiguration - **Flags im Router Advertisement**: - **A=0**: Keine SLAAC-Adressbildung - **M=1**: DHCPv6 für Adressvergabe - **O=1**: Zusätzliche Konfiguration per DHCPv6 --- **Vorteile:** - Zentrale Verwaltung aller Adressen - Volle Kontrolle über Adresszuweisung - Einheitliche Konfiguration aller Clients --- ## Phase 1: Router Discovery **Host-Initialisierung:** 1. Link-Local-Adresse bilden (`fe80::/64`) 2. DAD durchführen für Link-Local 3. Router Solicitation senden **Router Advertisement (RA):** - Enthält Information: -- A-Flag = 0 → Keine SLAAC -- M-Flag = 1 → DHCPv6 für Adressen -- O-Flag = 1 → Weitere Info per DHCPv6 - Host erkennt: "Ich brauche DHCPv6 für komplette Konfiguration" --- ## Phase 2: DHCPv6 Solicit/Advertise **DHCPv6 Solicit (Host → Server)** - Ziel: `ff02::1:2` (Alle DHCPv6-Server/Relays) - Enthält: Client-DUID (Identifier) - Frage: "Gibt es DHCPv6-Server?" **DHCPv6 Advertise (Server → Host)** - Nur von DHCPv6-Servern die antworten können - Enthält: Server-DUID - Signal: "Ich kann dir Adressen zuweisen" --- ## Phase 3: Adressanforderung (Request/Reply) **DHCPv6 Request (Host → Server)** - Explizite Anfrage für IPv6-Adresse - Enthält gewünschte Konfigurationsparameter - Client-DUID identifiziert den Host **DHCPv6 Reply (Server → Host)** - Zuweisung der IPv6-Adresse - Enthält typischerweise: - **IPv6-Adresse** + Präfix-Länge - **Gültigkeitsdauer** (Preferred/Valid Lifetime) - **DNS-Server**, Domänennamen - Weitere Optionen --- ## Phase 4: Adressbestätigung und -verwaltung **Renew/Rebind (Client-initiiert)** - Client fragt Adressverlängerung an (bei 50% Lifetime) - Bei keinem Reply: Versuch bei anderen Servern - Bei Erfolg: Reply mit aktualisierten Zeiten **Release (Client-initiiert)** - Freiwillige Adressfreigabe - Wird bei Herunterfahren gesendet **Reconfigure (Server-initiiert)** - Server kann Client zu Konfigurationsupdate auffordern - Client muss dann Renew-Prozess starten --- ## Detaillierter Ablauf im Überblick - Host-Start - Link-Local + DAD - RS → RA (A=0, M=1, O=1) - DHCPv6 Solicit → Advertise - DHCPv6 Request → Reply - Adresse aktiv + regelmäßige Renews --- ## Zeitliche Abfolge - RA liefert Netz-Parameter, aber keine Adresse - DHCPv6 liefert komplette Konfiguration - Beide Protokolle arbeiten zusammen --- ## Konfigurationsbeispiel **Router Advertisement:** - Präfix: 2001:db8:1000:1::/64 - A-Flag: 0 (keine SLAAC) - M-Flag: 1 (DHCPv6 für Adressen) - O-Flag: 1 (DHCPv6 für weitere Info) - Router Lifetime: 1800 Sekunden --- ## DHCPv6 Reply IPv6-Adresse: 2001:db8:1000:1::100/64 Valid Lifetime: 86400 Sekunden (1 Tag) Preferred Lifetime: 14400 Sekunden (4 Stunden) DNS-Server: 2001:db8::53 Domain: example.com --- ## M=1/O=1/A=0 DHCP + SLAAC **(Stateful DHCPv6):** - ✅ Zentrale Adressverwaltung - ✅ Volle Kontrolle über Zuordnung - ✅ Einheitliche DNS/Konfiguration - ✅ Nachverfolgbarkeit der Clients - ❌ Server-Infrastruktur benötigt - ❌ Höhere Komplexität --- ## M=0/O=0/A=1 DHCP + SLAAC **Reine SLAAC (A=1):** - ✅ Einfache Implementierung - ✅ Kein Server benötigt - ✅ Schnelle Adressbildung - ❌ Keine zentrale Kontrolle - ❌ Begrenzte Konfigurationsmöglichkeiten