IPv6 Prefix Delegation (PD): Design für FTTH und Mobile

IPv6 Prefix Delegation (PD) ist im Provider-Umfeld der zentrale Mechanismus, um Kundenanschlüssen nicht nur eine einzelne IPv6-Adresse zu geben, sondern ein ganzes IPv6-Präfix für das Heim- oder Standortnetz bereitzustellen. Gerade in FTTH-Netzen (Fiber to the Home) und in mobilen Netzen (LTE/5G) ist PD entscheidend, weil moderne Kundenumgebungen längst nicht mehr „ein LAN“ sind: Router, Mesh-Systeme, IoT-Netze, Gast-WLANs, Homeoffice-Segmentierung und teilweise sogar kleine Business-Setups benötigen mehrere /64-Subnetze – sauber getrennt und dauerhaft stabil. Prefix Delegation löst genau dieses Problem: Die CPE (Residential Gateway) oder ein mobiler Router bekommt per DHCPv6 ein delegiertes Prefix (z. B. /56 oder /60), und kann daraus intern mehrere /64-Netze bereitstellen. Damit PD im Telco-Betrieb ohne Kundenausfälle funktioniert, muss es jedoch wie ein End-to-End-Service designt werden: Prefixgrößen und Pools, BNG/PGW/UPF-Integration, Lease- und „Sticky“-Verhalten, Redundanz, Logging, Security sowie CPE-/Endgerätetests müssen zusammenpassen. Dieser Artikel zeigt praxisnah, wie Sie IPv6 Prefix Delegation für FTTH und Mobile robust designen – mit Best Practices für Präfixgrößen, Pool-Struktur, Betriebsprozesse und Troubleshooting.

Was ist Prefix Delegation – und warum ist es mehr als „DHCPv6 für Router“?

Bei Prefix Delegation delegiert ein Provider einem Kundenrouter ein IPv6-Präfix, typischerweise größer als /64, damit der Router daraus eigene /64-Subnetze für interne Segmente erzeugen kann. Das ist ein anderer Use Case als „eine IPv6-Adresse für ein Interface“. PD ist damit die Grundlage für Skalierung im Kundennetz: mehrere SSIDs, VLANs, IoT-Zonen, Gastnetze und separate Trust-Level werden ohne Workarounds möglich.

• PD delegiert Prefixe: der Kunde bekommt ein Netz, nicht nur eine Adresse.
• /64 bleibt Standard pro Segment: interne Segmente (LAN/WLAN/VLAN) sind in der Regel /64.
• Der Router wird Verteiler: CPE nutzt das delegierte Prefix, um interne Prefixe zu announcen (meist via Router Advertisements).
• Provider kontrolliert Policy: Delegationsgröße, Stabilität, Lease und Pool-Scope sind Provider-Entscheidungen.

FTTH vs. Mobile: Warum PD-Design unterschiedlich ausfallen kann

FTTH-Anschlüsse sind typischerweise stationär, lange online und haben stabile CPEs. Mobile Anschlüsse sind dynamischer: Endgeräte wechseln Zellen, Sessions werden häufiger neu aufgebaut, und die Kundenseite kann vom Smartphone-Tethering bis zum 5G-Router reichen. Diese Unterschiede beeinflussen Delegationsgröße, Sticky-Verhalten, Logging und Failover-Strategien.

• FTTH: stabile Standortbindung, hohe Erwartung an Prefix-Stabilität, viele Heimnetzsegmente.
• Mobile: häufigere Sessionwechsel, potenziell wechselnde Ankerpunkte, Bedarf an robustem Reconnect-Verhalten.
• CPE-Vielfalt: FTTH meist Provider-CPE; Mobile oft BYOD oder sehr heterogen.
• Policy-Integration: Mobile hat oft stärkere Integration in Subscriber-Policy und Charging.

Präfixgröße festlegen: /56, /60, /64 – was ist sinnvoll?

Für PD ist die zentrale Frage: Wie viele /64-Subnetze soll ein Kunde intern bilden können? Das ergibt sich aus der Differenz zur /64-Grenze. Ein /56 enthält 256 /64, ein /60 enthält 16 /64. Ein delegiertes /64 erlaubt praktisch keine Segmentierung, weshalb es für Router-Setups häufig zu knapp ist.

• /56: sehr komfortabel für Residential und anspruchsvollere Heimnetze (IoT, Gäste, Work-from-Home, mehrere VLANs).
• /60: häufig ausreichend für einfache Heimnetze und viele mobile Router-Use-Cases, aber weniger Reserve.
• /64 als PD: meist nur sinnvoll, wenn der Kunde keine Segmentierung braucht oder wenn Endgeräte keine echte Routerfunktion übernehmen.

Best Practice nach Kundentyp statt „eine Größe für alle“

Ein robustes Produktmodell definiert wenige Delegationsprofile: z. B. /56 für FTTH-Residential als Standard, /48 für Business-FTTH, /60 für mobile Routerprodukte (wenn passend) – und klare Upgrade-Pfade. Zu viele Profile erhöhen Support- und Provisionierungskomplexität.

Pool-Design: Prefix Delegation braucht Container und Scope

IPv6 ist zwar großzügig, aber PD-Pools müssen trotzdem strukturiert sein. Der häufigste operative Fehler ist, PD-Prefixe „aus beliebigen Bereichen“ zu vergeben. Das bricht Summarisierung, erschwert Migrationen und macht Failover riskanter. Bewährt hat sich ein Container-Modell: Region → PoP/BNG-Cluster (FTTH) bzw. Region → Core-Anchor/UPF-Cluster (Mobile) → PD-Pool.

• Regionale Container: ermöglichen Summarisierung und klare Ownership.
• Cluster-Pools: pro BNG-Cluster oder Mobile-Core-Cluster eigene PD-Pools, damit Failover und Kapazität planbar bleiben.
• Reserveblöcke: Platz für Wachstum, Migrationen und Parallelbetrieb einplanen.
• IPAM-Pflicht: PD-Pools mit Status, Owner, Scope und Lifecycle zentral führen.

Sticky PD vs. dynamische PD: Stabilität als Produktmerkmal

Viele Kunden erwarten, dass ihr IPv6-Präfix stabil bleibt, insbesondere bei FTTH. Sticky PD bedeutet, dass ein Kunde nach Reconnect möglichst wieder das gleiche delegierte Prefix erhält. Das verbessert Kundenerlebnis (Firewall-Regeln, Remote Access, DNS-Setups), erfordert aber strengere Pool- und State-Governance. In Mobile-Szenarien kann dynamische PD sinnvoller sein, weil Sessions häufiger neu entstehen.

• FTTH: Sticky PD oft empfehlenswert, weil der Anschluss stationär ist und CPE meist stabil bleibt.
• Mobile: dynamischer Ansatz häufiger praktikabel; Sticky ist möglich, aber komplexer bei Session-Mobilität.
• Lifecycle: Quarantäne und Recycling-Regeln definieren, damit Prefixe nicht zu früh wiederverwendet werden.
• Transparenz: Kundenkommunikation: „stabil“ vs. „kann wechseln“ muss klar sein.

Lease-Zeiten und Renew-Verhalten: Skalierung ohne Renew-Stürme

PD ist DHCPv6-basiert und damit leasegesteuert. Lease-Zeiten beeinflussen Renew-Last und die Stabilität bei kurzen Unterbrechungen. Zu kurze Leases erzeugen unnötige Renew-Last, zu lange Leases binden Prefixe länger, was in der Praxis meist weniger kritisch ist als bei IPv4, aber bei großen Deployments trotzdem relevant sein kann.

• FTTH: eher längere Leases möglich, weil CPE stabil online ist; reduziert Renew-Traffic.
• Mobile: Session-Lifecycle kann kürzer sein; Design muss Reconnects gut verkraften.
• Peak-Events: Stromausfälle (FTTH) oder Core-Events (Mobile) können viele Renew/Requests gleichzeitig auslösen – Kapazität planen.

Grobe Renew-Last-Abschätzung

Wenn N Kunden ein PD-Lease mit Dauer L haben und typischerweise um etwa die Hälfte der Lease-Zeit renewen, entstehen grob $N/(L/2)$ Renew-Versuche pro Zeiteinheit. Diese Abschätzung hilft, BNG/DHCPv6-Serverkapazität und Peak-Effekte einzuordnen.

Integration in FTTH: BNG, DHCPv6 Relay und Access-Identitäten

In FTTH-Topologien wird PD häufig am BNG/BRAS terminiert, während Access und Aggregation VLANs/QinQ transportieren. DHCPv6 Relay spielt eine zentrale Rolle, wenn DHCPv6-Server zentral betrieben werden. Gleichzeitig ist die Identifikation des Anschlusses (z. B. Option-Informationen, Circuit-ID) wichtig, um Kunden zuverlässig zuzuordnen und Sticky PD zu ermöglichen.

• BNG als Policy-Punkt: PD-Profile pro Produktklasse, Bandbreite, Filter, Accounting.
• DHCPv6 Relay: sauberer VRF-Kontext, eindeutige Relay-Source, klare Trust Boundaries.
• Access-Identitäten: eindeutige Zuordnung pro Anschluss (z. B. Port-/Line-ID), damit PD konsistent bleibt.
• Segmentierung: Residential vs. Business vs. Management getrennt, damit Policies sauber bleiben.

Integration in Mobile: PD für Router, Tethering und Fixed Wireless

Im mobilen Netz ist die klassische IPv6-Adressierung für Smartphones oft ohne PD realisierbar, weil das Endgerät selbst kein Heimnetz routet. PD wird jedoch relevant für mobile Router, Fixed Wireless Access und Tethering-Szenarien, in denen ein Gerät mehrere Clients hinter sich bedient. Das Design muss dabei Sessionwechsel und Handover-Effekte berücksichtigen.

• PD für Routerprodukte: klare Produktklasse (z. B. 5G-Router), definierte Delegationsgröße und Stabilitätsregeln.
• Session-Mobilität: Reconnects dürfen nicht zu instabilem Prefix-Churn führen, sonst brechen Heimnetze hinter dem Router.
• Policy/Charging: PD muss in Subscriber-Management und Accounting sauber abgebildet sein.
• Security: Router hinter Mobile braucht saubere Firewall-Defaults und klare RA/DHCPv6-Profile.

Security im PD-Design: Router Advertisements, ICMPv6 und Guard-Mechanismen

IPv6 funktioniert betrieblich nur mit korrekt behandelten Basisprotokollen. Besonders wichtig sind ICMPv6 (für Path MTU, Neighbor Discovery) und Router Advertisements (RA). In Access-Topologien müssen Sie zudem verhindern, dass Rogue RAs oder Rogue DHCPv6-Server auftreten, die Kunden in falsche Netze lenken.

• ICMPv6 funktional behandeln: nicht pauschal blocken; gezielt erlauben, sonst entstehen schwer erklärbare Störungen.
• RA-Guard/DHCPv6-Guard: wo möglich, Trusted/Untrusted-Ports definieren, Rogue-Quellen blocken.
• CPE-Firewall-Defaults: sicherstellen, dass IPv6 nicht „offener“ ist als IPv4, aber auch nicht unnötig bricht.
• Segmentierung: Management/OAM strikt getrennt von Kundensegmenten.

MTU und Overhead: FTTH/Mobile-Transport sauber berücksichtigen

PD selbst erzeugt keine großen Pakete, aber der IPv6-Pfad muss stabil sein. In Provider-Netzen sind QinQ, MPLS oder VXLAN nicht selten. MTU-Mismatches in solchen Umgebungen führen zu typischen Symptomen: IPv6 wirkt „instabil“, obwohl der Fehler im Transport liegt. Deshalb gehört MTU-Policy zum PD-Design.

• End-to-End MTU: über Access, Aggregation, Metro und Edge konsistent planen.
• PMTUD sicherstellen: ICMPv6 muss für Path MTU Discovery funktionieren.
• Standardtests: MTU-Tests und IPv6-Connectivity-Checks als Teil von Rollout und Incident-Runbooks.

Logging und Troubleshooting: PD muss korrelierbar sein

Im Providerbetrieb brauchen Sie nachvollziehbare Zuordnung: Welcher Kunde hatte wann welches delegierte Prefix? Das ist für Support und Compliance wichtig, besonders in Dual-Stack-Umgebungen und in Kombination mit CGNAT für IPv4. PD-Logging sollte deshalb nicht als Nebenprodukt behandelt werden.

• PD-Lease-Logs: Prefix, DUID/Client-ID, Anschlusskennung, Zeitstempel, Renew/Release.
• Session-Korrelation: BNG- oder Mobile-Core-Session-ID muss mit PD-Leases verknüpfbar sein.
• IPAM-Verknüpfung: PD-Pool-Scope (Region/Cluster) und Lifecycle dokumentiert halten.
• Monitoring-KPIs: PD-Erfolgsrate, Renew-Raten, Fehlerraten, Prefix-Churn, regionale Auffälligkeiten.

Rollout-Strategie: ohne Kundenausfälle durch stufenweise Einführung

PD ist besonders anfällig für CPE-Inkompatibilitäten und Edge-Cases. Deshalb sollten FTTH- und Mobile-PD-Rollouts in Phasen erfolgen: Lab → Pilot → kontrollierte Ausweitung. Wichtig sind klare Rollback-Schalter (Profilbasiert) und eine Segmentierung nach CPE-Modellen oder Produktklassen.

• Pilot nach CPE-Typ: bestimmte Firmwarestände zuerst, um Risiken zu begrenzen.
• Regionale Phasen: PoP-/Clusterweise aktivieren, Monitoring pro Phase.
• Rollback-Mechanismen: PD-Profil zurücksetzen, Delegationsgröße ändern, Sticky-Policy temporär anpassen (kontrolliert).
• Support vorbereiten: Runbooks für „kein PD“, „Prefix wechselt“, „IPv6 ok, DNS nicht“.

Typische Fehlerbilder bei Prefix Delegation und schnelle Ursachen

• Kein delegiertes Prefix: DHCPv6-PD-Policy fehlt, Relay/VRF falsch, Guard blockt, Server unreachable.
• Prefix wechselt häufig: Sticky-Policy fehlt, Identität instabil (DUID/Access-ID), Pool-Design oder Failover inkonsistent.
• Nur ein Teil der Kunden betroffen: CPE-Firmware-Bug, nur ein BNG/Cluster hat falsches Profil, regionale MTU-Probleme.
• IPv6 geht, aber Heimnetz nicht: CPE setzt RA falsch, interne /64-Verteilung inkonsistent, Firewall blockt ICMPv6.
• Mass-Event bricht PD: Renew-Sturm, DHCPv6-Server/BNG überlastet, Logging/Queues kollabieren.

Praxis-Checkliste: PD-Design für FTTH und Mobile stabil aufsetzen

• Delegationsgrößen standardisieren: wenige Profile (z. B. /56 FTTH Residential, /48 Business, /60 Mobile Router), Upgrade-Pfade definieren.
• PD-Pools strukturieren: Region → PoP/BNG-Cluster bzw. Core-Cluster → PD-Pool, Reserven einplanen.
• Sticky-Policy entscheiden: FTTH oft sticky, Mobile je nach Produkt; Quarantäne und Recycling-Regeln definieren.
• Lease- und Kapazitätsplanung: Renew-Last und Peak-Events berücksichtigen, N+1-Reserven einplanen.
• Access-Identitäten sauber führen: stabile Anschlusskennung, Trust Boundaries für DHCPv6/RA, Relay-Design konsistent.
• Security korrekt umsetzen: ICMPv6 funktional erlauben, RA-/DHCPv6-Guards wo möglich, CPE-Defaults prüfen.
• MTU-Policy etablieren: end-to-end MTU und PMTUD sicherstellen, standardisierte Tests.
• Logging und Monitoring: PD-Leases korrelierbar, KPIs für PD-Erfolg, Prefix-Churn und regionale Auffälligkeiten.
• Rollout in Phasen: Lab → Pilot → Skalierung, segmentiert nach CPE/Produkt; profilbasierte Rollbacks vorbereiten.
• IPAM verpflichtend: PD-Pools, Owner, Scope, Status und Lifecycle zentral dokumentieren, keine Ad-hoc Vergaben.

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.