IPv6 in Heim- und Firmennetzen

1. Warum IPv6 in der Praxis relevant ist

IPv6 ist längst kein Spezialthema mehr. Viele Provider liefern öffentliche Präfixe standardmäßig aus, Mobilfunknetze bevorzugen IPv6 und zahlreiche Dienste funktionieren im Dual-Stack-Betrieb unauffällig im Hintergrund. Probleme entstehen meist nicht durch IPv6 selbst, sondern durch halb fertig eingeführte Designs: Präfixe werden verteilt, aber DNS, Firewall und Monitoring bleiben gedanklich bei IPv4 stehen.

Wer IPv6 sauber einführt, gewinnt:

  • globale Adressierbarkeit ohne NAT als Pflichtbestandteil,
  • einfachere Netztrennung in /64-Segmenten,
  • klare End-to-End-Konnektivität für VPN, Monitoring und moderne Dienste,
  • bessere Vorbereitung auf Cloud-, Mobilfunk- und Multi-Site-Szenarien.

2. Zentrale IPv6-Bausteine verstehen

Für stabiles Design muss man ein paar IPv6-Mechanismen bewusst einordnen:

  • GUA (Global Unicast Address): öffentlich routbare Adresse aus dem vom Provider delegierten Präfix.
  • ULA (Unique Local Address): private interne Adresse, ähnlich der Rolle von RFC1918, aber mit anderer Semantik.
  • Link-Local: automatisch pro Interface vorhanden, wichtig für Nachbarschaft und Router-Kommunikation.
  • SLAAC: Hosts bilden ihre Adressen selbst anhand von Router Advertisements.
  • DHCPv6: liefert zusätzliche Optionen oder bei manchen Plattformen auch Adressverwaltung.
  • Router Advertisement (RA): teilt Präfix, Gateway-Rolle und Konfigurationshinweise mit.
  • Prefix Delegation (PD): der Provider delegiert ein Präfix, etwa /56 oder /60, an den Router.
  • NDP: IPv6-Pendant zu ARP, zentral für Neighbor Discovery und Adressauflösung.

Wichtig: Ein /64 pro Broadcast-Domäne ist kein Luxus, sondern der normale Betriebsmodus von IPv6. Viele Mechanismen setzen genau das voraus. Zu kleine Subnetze wie /80 oder /120 wirken auf den ersten Blick ordentlich, führen aber oft zu unerwartetem Verhalten.

3. Sauberes IPv6-Design im Heimnetz

Im Heimnetz sollte die Firewall oder der Router ein delegiertes Präfix vom Provider erhalten und dieses sinnvoll auf VLANs oder Segmente verteilen. Ein häufiges Muster ist ein /56, aus dem pro VLAN jeweils ein /64 abgeleitet wird:

2001:db8:1234:ab00::/56

2001:db8:1234:ab01::/64  LAN
2001:db8:1234:ab02::/64  Server
2001:db8:1234:ab03::/64  IoT
2001:db8:1234:ab04::/64  Gastnetz

Für Clients ist SLAAC plus stabile DNS-Einträge oft der pragmatischste Weg. Server, Hypervisor und Infrastrukturkomponenten bekommen entweder statische IPv6-Adressen oder reservierte Zuordnung über die Plattform selbst. ULA kann ergänzend sinnvoll sein, wenn interne Erreichbarkeit auch bei Provider- Wechsel oder Tunnelbetrieb stabil bleiben soll.

  • Clients: meist SLAAC mit Privacy Extensions oder stable private addresses.
  • Server: statische GUA plus optional ULA für interne Betriebsprozesse.
  • IoT: eigenes VLAN mit restriktiven Regeln, auch wenn Adressen global aussehen.

Der größte Denkfehler ist, IPv6 mit "automatisch offen ins Internet" gleichzusetzen. Nicht NAT schützt, sondern die Stateful Firewall. Die Regelwerke müssen also genauso sauber geplant werden wie bei IPv4.

4. IPv6 in kleinen und mittleren Firmen

In Firmennetzen sollte IPv6 nicht als Nebenprojekt laufen, sondern denselben Dokumentations- und Betriebsstandard wie IPv4 bekommen. Dazu gehören ein Präfixplan, DNS-Standards, Firewall-Richtlinien und ein klares Verständnis, wo SLAAC genügt und wo DHCPv6 oder statische Adressen sinnvoller sind.

Typische Empfehlungen:

  • pro VLAN ein /64 reservieren und nicht "auf Kante" planen,
  • Infrastruktur und Server mit festen Adressen oder klaren Adressregeln versehen,
  • RA Guard und DHCPv6 Guard auf Access-Switches nutzen, falls die Plattform es unterstützt,
  • Management-Netze bewusst von Client- und Gäste-Segmenten trennen,
  • Monitoring und Logging von Anfang an dual-stack-fähig aufbauen.

Bei Multi-Site-Setups lohnt sich ein eigener interner Adressplan mit ULA zusätzlich zu den globalen Präfixen, insbesondere wenn Tunnel, Standortkopplungen oder Providerwechsel eine Rolle spielen. ULA ersetzt GUA aber nicht, wenn echte externe Erreichbarkeit gefordert ist.

5. DNS, Firewall und Segmentierung

Ein technisches IPv6-Rollout ist erst dann gelungen, wenn auch die Betriebsdienste mitziehen:

  • DNS: AAAA-Records bewusst pflegen, Reverse DNS intern nicht vergessen.
  • Firewall: Regeln für IPv6 explizit definieren, nicht stillschweigend von IPv4 ableiten.
  • VPN: Tunnel und ACLs dual-stack testen; viele Ausfälle verstecken sich hier.
  • Monitoring: Erreichbarkeit, Prefix-Änderungen, Neighbor-Tabelle und ICMPv6 im Blick behalten.

ICMPv6 darf nicht "vorsorglich" pauschal blockiert werden. Router Advertisements, Neighbor Discovery, Path MTU Discovery und diverse Fehlermeldungen hängen daran. Zu harte Filter machen IPv6 schnell unzuverlässig.

Für Services gilt dieselbe Disziplin wie bei IPv4: Was von außen erreichbar sein soll, bekommt klare Regeln und idealerweise einen Reverse Proxy oder ein Gateway davor. Alles andere bleibt standardmäßig gesperrt.

6. Migration ohne halbfertigen Dual Stack

Der beste Weg ist meist ein stufenweises Dual-Stack-Rollout:

  1. Präfix-Plan und VLAN-Zuordnung festlegen.
  2. Core-Router und Firewall dual-stack-fähig machen.
  3. Resolver, Reverse Proxy, Monitoring und zentrale Server auf IPv6 testen.
  4. Erst danach Client-VLANs aktivieren.

Dual Stack bedeutet nicht "alles doppelt und ungeprüft". Jede neue IPv6-Erreichbarkeit erweitert den Angriffs- und Betriebsraum. Wer AAAA-Records veröffentlicht, sollte sicher sein, dass Firewall, TLS, Monitoring und Applikation auf IPv6 wirklich funktionieren.

Anti-Patterns:

  • IPv6 am Router einschalten, aber kein Regelwerk pflegen.
  • Öffentliche Präfixe auf Server verteilen, ohne DNS und Zertifikate anzupassen.
  • ULA und GUA wild mischen, ohne Zielbild für Routing und DNS.
  • NAT66 als Standardlösung betrachten, obwohl das eigentliche Problem in der Policy liegt.

7. Troubleshooting

Viele IPv6-Probleme haben wenig mit Routing und viel mit RAs, Firewalls oder DNS zu tun. Eine feste Reihenfolge spart Zeit:

  1. Hat das Interface eine Link-Local- und eine erwartete globale Adresse?
  2. Kommen Router Advertisements am Client an?
  3. Ist der Default Gateway vorhanden?
  4. Funktionieren ICMPv6 und DNS?
  5. Blockiert eine IPv6-spezifische Firewall-Regel den Verkehr?
ip -6 addr
ip -6 route
ip -6 neigh
resolvectl status
ping -6 2001:4860:4860::8888
dig AAAA example.org +short
sudo tcpdump -ni any icmp6

Typische Fehlerbilder:

  • Adresse vorhanden, aber kein Internet: Default-Route oder Firewall fehlerhaft.
  • Einzelne Ziele gehen, andere nicht: häufig PMTU- oder DNS-Problem.
  • Nur manche Geräte betroffen: unterschiedliches Verhalten bei SLAAC/DHCPv6 oder Privacy Extensions.
  • Verbindungen brechen sporadisch ab: Präfixwechsel, fehlerhafte RAs oder kaputte Stateful-Regeln.

8. Zusammenfassung

IPv6 funktioniert am besten, wenn man es nicht wie "IPv4 mit längeren Adressen" behandelt. Gute Ergebnisse entstehen durch /64-Segmente, saubere RAs, explizite Firewalls und eine bewusste DNS-Strategie.

Für Heim- und Firmennetze ist Dual Stack der realistische Einstieg. Wer ihn sauber umsetzt, reduziert späteren Migrationsstress und vermeidet die typischen blinden Flecken, die bei halb aktivierten IPv6-Setups fast zwangsläufig entstehen.