IPv6-Adressierung: /48, /56, /64 – was ist sinnvoll für Kunden?

Die Frage, welche IPv6-Adressierung für Kunden sinnvoll ist – /48, /56 oder /64 – gehört im Telco-Umfeld zu den wichtigsten Designentscheidungen für einen stabilen IPv6-Rollout. Sie wirkt auf fast alles: Kundenerlebnis (z. B. Heimnetz, Smart Home, Gastnetz, Business-Segmente), Betrieb (Provisionierung, Support, Migrationen), Sicherheit (Segmentierung, Firewall-Policy), Skalierung (Prefix Delegation Pools) und nicht zuletzt auf die strategische Positionierung von Produkten (Residential, Business, IoT, Wholesale). Obwohl IPv6 „sehr viel“ Adressraum bietet, ist die Entscheidung nicht beliebig. Zu klein delegierte Prefixe können Kunden einschränken und zu Supportfällen führen („Ich kann mein Netz nicht sinnvoll segmentieren“). Zu groß delegierte Prefixe sind in der Regel kein technisches Problem – können aber Governance, Pool-Struktur und Dokumentationsaufwand erhöhen, wenn die Produktlandschaft unklar ist. In der Praxis haben sich klare Standards bewährt: /64 als Standardgröße für einzelne Layer-2-Segmente, /56 (oder /60) als typische Delegationsgröße für Residential-Kunden und /48 häufig für Business-Kunden, Standorte oder anspruchsvolle Kundenarchitekturen. Dieser Artikel erklärt praxisnah, was hinter den Präfixlängen steckt, welche Kriterien in Provider-Netzen wirklich zählen und wie Sie die richtige Größe pro Kundentyp festlegen, ohne später teure Umstellungen machen zu müssen.

Grundlagen: Was bedeutet /48, /56 und /64 in IPv6 überhaupt?

IPv6-Adressen sind 128 Bit lang. Die Präfixlänge (z. B. /64) beschreibt, wie viele Bits davon das Netz identifizieren. Je kleiner die Zahl nach dem Slash, desto größer ist der Adressraum. Wichtig: Im Kundenkontext geht es selten um „Hosts pro Netz“, sondern um die Anzahl der Subnetze, die ein Kunde sinnvoll aufteilen kann – etwa für LAN, WLAN, Gastnetz, IoT, VoIP oder getrennte Sicherheitszonen.

• /64: Standardgröße für ein einzelnes IPv6-Subnetz (ein LAN-/VLAN-Segment). Innerhalb eines /64 hat man extrem viele Adressen; relevant ist eher die Funktionalität von SLAAC und Neighbor Discovery.
• /56: enthält $2^8$ = 256 einzelne /64-Subnetze. Das ist für Residential und viele KMU-Szenarien sehr komfortabel.
• /48: enthält $2^16$ = 65.536 einzelne /64-Subnetze. Das ist „site“-tauglich und oft der Business-Standard für Standorte.

Warum /64 so oft „nicht verhandelbar“ ist

In IPv6 ist /64 die Standardgröße für ein Subnetz, weil viele Mechanismen (insbesondere SLAAC) davon ausgehen, dass die Interface-ID 64 Bit umfasst. Es gibt Spezialfälle, aber für Kunden-LANs und typische Segmente ist /64 die bewährte Standardgröße. Deshalb delegiert man Kunden in der Regel nicht nur ein /64 „für alles“, sondern ein größeres Präfix, aus dem sie mehrere /64 bilden können.

Zwei völlig unterschiedliche Fragestellungen: „Subnetzgröße“ vs. „Delegationsgröße“

Ein häufiger Denkfehler ist, /48, /56 und /64 als Alternativen für „das Kundennetz“ zu sehen. In der Providerpraxis gibt es zwei Ebenen:

• Subnetzgröße im Kundensegment: fast immer /64 pro Segment (LAN, VLAN, WLAN).
• Delegationsgröße für den Kunden (Prefix Delegation): das ist die Frage /48 vs. /56 vs. /60 – also wie viele /64 der Kunde intern aufteilen darf.

Für Telcos ist daher die Kernentscheidung: Wie groß ist das delegierte Präfix pro Anschluss – und welche Produktklassen bekommen welche Größe?

Residential-Kunden: Warum /56 häufig der beste Kompromiss ist

Für Privatkunden ist die wichtigste Anforderung nicht „65.000 Subnetze“, sondern genügend Spielraum für saubere Segmentierung ohne Tricks. Moderne Heimnetze sind längst nicht mehr „ein LAN“: IoT-Geräte, Smart Home, Gäste, Work-from-Home, NAS, Kameras und Gaming-Konsolen profitieren von getrennten Zonen. /56 liefert 256 /64-Subnetze und ist damit großzügig genug, ohne dass Provider-Pools unnötig komplex werden.

• Genug Segmentierung: mehrere SSIDs/VLANs, IoT- und Gastnetze, getrennte Trust-Zonen.
• Kompatibel zu CPEs: viele CPEs können /56 sauber delegieren und intern auf /64 verteilen.
• Produktlogik: /56 lässt sich als „Standard“ definieren, /48 als Business-Upgrade.
• Betrieb: weniger Supportfälle als bei zu kleinen Delegationen.

Wann /60 im Residential-Bereich sinnvoll sein kann

Manche Provider nutzen /60 als Residential-Standard, was $2^4$ = 16 /64-Subnetze liefert. Das kann reichen, wenn der Fokus auf einfacher CPE-Konfiguration liegt und die Produktanforderungen niedrig sind. Gleichzeitig steigt das Risiko, dass fortgeschrittene Heimnetz-Setups oder Security-Segmentierung an Grenzen stoßen. Wenn Sie /60 wählen, sollten Sie ein Upgrade-Pfad (z. B. /56) klar vorsehen.

Business-Kunden: Warum /48 als „Site Prefix“ so verbreitet ist

Für Business-Kunden ist /48 oft sinnvoll, weil es einem Standort sehr viel Flexibilität gibt: mehrere VLANs, mehrere Gebäude, Gastnetze, DMZs, Labore, Produktionsnetze, getrennte Mandantenbereiche oder späteres Wachstum ohne Provider-Change. /48 gilt in vielen Designs als „Site“-Größe: Ein Standort bekommt /48, und intern werden /64 pro Segment vergeben – mit sehr viel Reserve.

• Wachstum ohne Umadressierung: neue VLANs/Standorte lassen sich hinzufügen, ohne Präfixwechsel.
• Saubere Hierarchie: Unternehmen können /48 intern in strukturierte Blöcke aufteilen (z. B. pro Gebäude /52).
• Mehrere Standorte: pro Standort ein /48 vereinfacht VPN-/WAN-Designs und Policies.
• Professionelle IT: Business-Kunden erwarten oft diese Flexibilität, besonders bei Managed Services.

Wann ein /64 für Kunden problematisch wird

Ein delegiertes /64 (also „du bekommst genau ein /64“) ist für viele Kunden in der Praxis zu knapp, weil es kaum Segmentierung erlaubt. Selbst wenn einzelne Endgeräte damit funktionieren, entsteht ein Netzdesign, das kaum sauber erweiterbar ist. Außerdem erschwert es häufige CPE-Modelle, die intern mehrere Netze bereitstellen möchten.

• Keine echte Segmentierung: IoT/Gast/Work getrennt wird schwierig oder nur mit unsauberen Workarounds möglich.
• Mehr Supportfälle: Kunden stoßen schneller an Grenzen, besonders mit moderner Heimautomation.
• Schwache Zukunftsfähigkeit: Wachstum erfordert später Umstellung der Delegationsgröße.

Provider-Perspektive: Pools, Aggregation und Betrieb zählen mehr als „Adressraum ist doch genug“

IPv6 ist großzügig, aber Provider müssen dennoch sauber planen. Nicht wegen „Knappheit“, sondern wegen Struktur: regionale Container, PoP-Container, PD-Pools nach BNG/Cluster, Logging/Accounting und klare Produktklassen. Je mehr unterschiedliche Delegationsgrößen Sie im Feld haben, desto komplexer werden Provisionierung, Support und Migrationen.

• Standardisierung: wenige Delegationsprofile (z. B. /56 Residential, /48 Business) sind betriebsfreundlich.
• PD-Pool-Design: Pools nach Region/PoP/BNG strukturieren, damit Scope und Failover klar sind.
• Summarisierung: Delegationsprefixe sollten aus zusammenhängenden Blöcken kommen, damit Aggregation möglich bleibt.
• IPAM-Pflicht: Delegationsbereiche, Owner, Status, Lifecycle, Quarantäne und Recycling müssen dokumentiert sein.

Sticky vs. wechselnde Prefix Delegation: Stabilität für Kunden vs. Flexibilität für Provider

Ein weiterer Schlüsselfaktor ist nicht nur die Größe, sondern die Stabilität: Bekommen Kunden immer wieder das gleiche delegierte Präfix („sticky PD“), oder kann es wechseln? Für viele Anwendungen ist Stabilität wertvoll (z. B. bei Firewall-Regeln, Remote Access, DNS-Setups). Andererseits kann „immer gleich“ Poolmanagement und Migrationen erschweren, wenn Sie wenig Governance haben.

• Sticky PD: besseres Kundenerlebnis, weniger Überraschungen bei Reconnects, aber strengere Pool-Governance nötig.
• Dynamic PD: flexibler im Poolmanagement, aber kann Kundenkonfigurationen beeinflussen.
• Best Practice: definieren, welche Produktklasse Stabilität braucht (Business eher ja; Residential je nach Produkt).

Security und Segmentierung: Präfixgröße beeinflusst Sicherheitsarchitektur

IPv6 ermöglicht echte End-to-End-Erreichbarkeit. Das ist gut, erfordert aber saubere Segmentierung und Firewall-Standards. Größere Delegationen (z. B. /56 oder /48) erleichtern es Kunden, IoT und Gäste strikt zu trennen. Zu kleine Delegationen fördern „alles in einem Netz“ – und das ist häufig schlechter für Sicherheit.

• Mehr /64 bedeutet mehr Zonen: Gastnetz, IoT, Management, Work – sauber trennbar.
• Policy-Klarheit: segmentierte Netze sind leichter kontrollierbar als ein großes „Flachnetz“.
• Provider-Defaults: CPE-Firewall-Defaults und RA/DHCPv6-Profile müssen konsistent sein.

Dual Stack und Produktpolitik: IPv6-Prefixe als Service-Feature

In der Praxis wird die Delegationsgröße Teil der Produktdefinition. Das ist kein „Marketing-Trick“, sondern betriebliche Steuerung: Sie schaffen klare Erwartungen und vermeiden Sonderfälle. Ein einfaches, skalierbares Modell ist häufig:

• Residential Standard: /56 (oder /60), je nach Strategie.
• Residential Premium / Power User: /56 oder /48, plus optionale öffentliche IPv4.
• Business Standard: /48 pro Standort.
• Wholesale: vertraglich definierte Prefixe, oft aggregierbar und strikt dokumentiert.

Typische Fehlerbilder bei falscher Präfixwahl

• Zu klein delegiert: Kunden können nicht segmentieren, mehr Supportfälle, Workarounds entstehen.
• Zu viele Profile: jedes Produkt eine andere Größe, Provisionierung und Support werden unnötig komplex.
• Unstrukturierte Pools: Delegationen aus „irgendwo“ vergeben, Summarisierung bricht, IPAM wird schwierig.
• Stabilität ungeklärt: Kunden erwarten „gleiches Prefix“, bekommen wechselnde Delegationen.
• IPv6 Security vernachlässigt: Präfixe sind da, aber Filter/Defaults sind inkonsistent.

Praxis-Checkliste: /48, /56, /64 sinnvoll für Kunden festlegen

• Segmentstandard setzen: /64 pro LAN/VLAN/Segment als feste Regel.
• Delegationsstandard wählen: /56 häufig als Residential-Standard; /48 häufig als Business-/Site-Standard.
• Upgrade-Pfade definieren: wenn /60 genutzt wird, klare Option auf /56; Business-Optionen für /48.
• PD-Stabilität entscheiden: sticky vs. dynamic je Produktklasse; dokumentieren und kommunizieren.
• Pool-Struktur planen: PD-Pools nach Region/PoP/BNG-Cluster, zusammenhängend und aggregierbar.
• IPAM verpflichtend machen: Prefix-Container, Status, Owner, Lifecycle, Quarantäne und Recycling.
• Security-Defaults prüfen: CPE-Firewall, RA/DHCPv6-Profile, ICMPv6 korrekt behandeln.
• Monitoring etablieren: PD-Erfolgsraten, IPv6-Nutzungsquote, Tickettrends und regionale Auffälligkeiten messen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.