QoS in IPv6 ist im Kern kein anderes Konzept als in IPv4 – und genau darin liegt im Dual-Stack-Betrieb die größte Gefahr: Viele Netze behandeln IPv6 „fast genauso“, aber nicht vollständig identisch. Das Ergebnis sind schwer erklärbare Qualitätsunterschiede, bei denen Voice & Video über IPv4 stabil laufen, über IPv6 jedoch ruckeln, knacken oder bei Peak-Last stärker schwanken. Die Ursachen sind selten „IPv6 an sich“, sondern fast immer inkonsistente QoS-Policies: DSCP wird bei IPv6 nicht korrekt klassifiziert oder gemappt, Trust Boundaries greifen nur in IPv4, ACLs/Policies matchen IPv6-Traffic nicht, oder Tunnel- und Übergabepunkte (z. B. DS-Lite, MAP-T, IPsec, EVPN/VXLAN, SRv6) ändern den Header so, dass Markierungen nicht mehr wirken. Professionelles QoS in IPv6 bedeutet deshalb: DSCP und Priorisierung im Dual-Stack Betrieb konsequent end-to-end planen, identische Klassenmodelle für v4 und v6 nutzen, Markierung und Remarking an den gleichen Trust Boundaries durchführen, die gleichen Queue- und Scheduler-Profile anwenden und die typischen IPv6-spezifischen Stolperfallen (Extension Header, ND/ICMPv6, Tunnel-Overlays) in Policies und Monitoring mitdenken. Dieser Artikel erklärt praxisnah, wie Sie DSCP in IPv6 korrekt einsetzen, wie Priorisierung im Dual-Stack zuverlässig funktioniert und wie Sie vermeiden, dass IPv6 zur „Second-Class“-Route für Echtzeittraffic wird.
DSCP in IPv6: Gleiches Feld, andere Header – was Sie wissen müssen
In IPv6 gibt es wie in IPv4 ein Feld für die DiffServ-Markierung. Technisch ist es im IPv6-Header als „Traffic Class“ enthalten, das – wie bei IPv4 – DSCP und ECN umfasst. Für QoS bedeutet das:
- DSCP-Semantik bleibt gleich: EF ist EF, AF ist AF, Best Effort bleibt Best Effort – unabhängig von IPv4 oder IPv6.
- Klassifizierung muss IPv6 verstehen: Geräte müssen IPv6-Header korrekt auswerten und DSCP/Traffic Class matchen.
- ECN bleibt relevant: wenn Sie Congestion-Avoidance-Mechanismen nutzen, sollten Sie sicherstellen, dass ECN nicht unbeabsichtigt verändert wird.
Das eigentliche Problem im Dual-Stack ist daher nicht „DSCP gibt es nicht“, sondern „DSCP wird nicht überall gleich behandelt“.
Warum QoS in Dual-Stack oft auseinanderläuft
Dual-Stack bedeutet: IPv4 und IPv6 laufen parallel über dieselben Links – aber häufig über unterschiedliche Policies und manchmal sogar über unterschiedliche Pfade. Die häufigsten Gründe für QoS-Abweichungen sind:
- Policy-Lücken: QoS-Policies matchen nur IPv4-ACLs/Prefix-Listen oder nur IPv4-Interfaces.
- Unvollständige Templates: Core-/PE-Templates wurden für IPv4 ausgerollt, IPv6 kam später „dazu“.
- Andere Übergabepunkte: IPv6 wird über andere Aggregationspfade, andere BRAS/BNG, andere CGN/AFTR-Knoten geführt.
- Unterschiedliches Trust-Verhalten: Markierungen werden bei IPv4 akzeptiert, bei IPv6 neutralisiert (oder umgekehrt).
- Tunnel/Translation: DS-Lite, MAP-T oder andere Mechanismen verändern Header und können DSCP-Mapping beeinflussen.
Diese Unterschiede sind oft nicht offensichtlich, weil Monitoring häufig IPv4-zentriert bleibt und IPv6 nur „mitläuft“ – bis Echtzeittraffic betroffen ist.
IPv6-spezifisch: ICMPv6, Neighbor Discovery und warum es QoS braucht
In IPv6 ist ICMPv6 nicht optionaler „Ping-Kram“, sondern essenziell für den Betrieb: Neighbor Discovery (ND), Router Advertisements, Path MTU Discovery und weitere Funktionen basieren darauf. Wenn ICMPv6 durch QoS oder Policies unabsichtlich degradiert wird, kann das indirekt auch Echtzeitqualität beeinflussen (z. B. durch Path-MTU-Probleme oder instabile Nachbarschaften).
- ICMPv6 muss funktionieren: nicht blockieren, nicht in die „unterste“ Klasse drücken, wenn es zu Instabilität führt.
- Control-Klasse sinnvoll: Viele Telco-Designs geben Control/Signaling eine hoch priorisierte, aber gewichtete Klasse.
- PMTUD-Effekte: MTU-Probleme erzeugen Retransmits, Fragmentation-Workarounds und Throughput-Jitter, was Video empfindlich stören kann.
Praxisregel: QoS in IPv6 sollte eine definierte Behandlung für Control-Traffic vorsehen – inklusive ICMPv6 – damit das Netz stabil bleibt.
Klassenmodell im Dual-Stack: Ein Standard für IPv4 und IPv6
Der wichtigste Schritt für konsistentes QoS ist ein einheitliches Klassenmodell, das unabhängig vom IP-Protokoll gilt. Ein bewährtes Telco-/Enterprise-Schema ist:
- Voice Media: DSCP EF, LLQ/Low Latency Queue, strict priority mit Limit.
- Signaling/Control: hoch priorisiert, gewichtet (inkl. wesentlicher ICMPv6/Control-Flows).
- Interaktives Video: AF-Klasse, gewichtet mit garantierten Anteilen, keine strict priority.
- Best Effort: Standardverkehr, fair und mit kontrollierten Puffern.
- Background: niedrig priorisiert.
Dann gilt die zentrale Regel: Jede Klasse muss im Dual-Stack identisch klassifiziert, identisch gemappt (DSCP/CoS/MPLS-TC) und identisch geschedult werden.
Trust Boundary in Dual-Stack: Markierungen in IPv6 genauso kontrollieren wie in IPv4
Viele Netze haben eine saubere Trust Boundary für IPv4, vergessen aber IPv6. Das ist riskant, weil DSCP in IPv6 genauso missbraucht werden kann. Daher gelten dieselben Trust-Modelle:
- Untrusted: Kundenmarkierungen neutralisieren; Premium nur in managed Services.
- Conditional Trust: Markierungen akzeptieren, aber normalisieren und profilieren; Überschuss remarken.
- Trusted: nur für kontrollierte Quellen (Managed CPE, definierte Wholesale-NNIs).
Im Dual-Stack sollten Trust Boundary und Remarking-Regeln pro Interface/UNI identisch gelten – unabhängig davon, ob das Paket IPv4 oder IPv6 ist.
DSCP-Matching: Die häufigste Dual-Stack-Falle in Policies
In der Praxis sind QoS-Policies häufig an Klassifizierungsregeln gebunden: ACLs, class-maps, firewall filter, traffic policies. Ein klassischer Fehler ist, dass IPv4-Regeln sauber matchen, IPv6-Regeln aber fehlen oder abweichen.
- Nur IPv4-ACLs: IPv6 wird nicht klassifiziert, landet im Default.
- Nur DSCP-Match für IPv4: IPv6 Traffic Class wird nicht ausgewertet.
- Service-Ports falsch interpretiert: z. B. RTP/SRTP über IPv6 wird nicht erkannt, weil die Regel IPv6 nicht umfasst.
Best Practice ist, QoS-Klassifizierung primär über DSCP und definierte Trust-Policies zu machen – und die Regeln in v4 und v6 als zwingendes Paar zu pflegen.
DSCP und Overlays/Tunnel im IPv6-Umfeld: Wo Markierungen verloren gehen
Im Dual-Stack begegnen Sie häufig Tunneln und Overlays. Jede Kapselung wirft die Frage auf: Wird DSCP im inneren Header in den äußeren Header kopiert (Propagation), oder wird er neu gesetzt (Rewrite)? Typische Szenarien:
- EVPN/VXLAN (IPv4 oder IPv6 Underlay): Underlay queuet oft nach äußerem Header; inneres DSCP muss propagiert oder gemappt werden.
- IPsec: Verschlüsselung kann Markierungsbehandlung verändern; je nach Implementierung wird DSCP kopiert, genullt oder policy-basiert gesetzt.
- DS-Lite/MAP-T: Übergänge zwischen IPv4 und IPv6 verändern Header; DSCP-Mapping muss bewusst geplant sein.
- SRv6: Segment Routing mit IPv6-Headern; QoS kann an SRv6-spezifischen Übergängen besondere Mappings erfordern.
Designregel: Für jeden Tunneltyp muss klar dokumentiert sein, wie DSCP behandelt wird (copy, map, rewrite) – und wie das Underlay daraus Queues macht.
802.1p CoS und MPLS-TC im Dual-Stack: Layer-übergreifende Konsistenz
In Metro/Access kann 802.1p CoS (PCP) entscheidend sein, im MPLS-Core MPLS-TC/EXP. Dual-Stack heißt dabei: IPv4 und IPv6 müssen auf dieselben L2/L3/LSP-Klassen abgebildet werden.
- DSCP->CoS: IPv4 und IPv6 DSCP werden identisch auf PCP gemappt.
- DSCP->MPLS-TC: IPv4 und IPv6 DSCP werden identisch in TC/EXP übersetzt.
- Core-Templates: TC/PCP werden überall gleich gequeued, sonst entsteht ein QoS-Loch.
Wenn Dual-Stack QoS „nicht gleich“ ist, liegt die Ursache häufig genau in diesen Mappings, nicht im IP-Protokoll selbst.
Queueing und Scheduling: Identische Behandlung ist wichtiger als identische Zahlen
Selbst wenn Sie DSCP-Werte identisch setzen, muss die eigentliche Behandlung identisch sein: gleiche Queues, gleiche Gewichte, gleiche Limits. Sonst entsteht eine verdeckte Ungleichbehandlung.
- Voice: LLQ/strict priority mit Limit, unabhängig von IPv4/IPv6.
- Video: gewichtete Queue, garantierte Anteile, keine strict priority.
- Best Effort: fair, Puffer kontrollieren, Bufferbloat vermeiden.
- Burst-Handling: Shaping an rate-limitierten Links, Queue-Limits, optional Congestion Avoidance.
Ein häufiger Dual-Stack-Bug ist, dass IPv6 zwar in dieselbe Klasse markiert wird, aber auf bestimmten Interfaces in andere Hardware-Queues gemappt ist, weil Templates nicht konsistent sind.
Typische Symptome, wenn IPv6-QoS „anders“ ist als IPv4
- Voice knackt nur bei IPv6-Calls: EF wird in IPv6 nicht korrekt klassifiziert oder verliert Mapping in einem Segment.
- Video ruckelt über IPv6: Video-AF läuft in Best Effort oder wird durch Policer/Shaping anders behandelt.
- Nur zu Peak-Zeiten schlecht: Microbursts treffen IPv6 stärker, weil IPv6-Pfad über andere Engpässe läuft oder weil Queue-Limits abweichen.
- PMTUD/MTU-Effekte: IPv6 Pfade reagieren empfindlicher, wenn ICMPv6/PMTUD gestört ist; Throughput und Video-QoE pendeln.
Diese Symptome sind fast immer auf Policy- und Mapping-Inkonsistenzen zurückzuführen, nicht auf IPv6 als Technologie.
Monitoring im Dual-Stack: QoS muss für IPv6 genauso sichtbar sein
Viele Teams überwachen QoS nur für IPv4. Dann bleiben IPv6-Probleme lange unsichtbar. Für belastbares Monitoring sollten Sie pro Klasse und getrennt nach IPv4/IPv6 sehen können:
- Traffic pro Klasse: Volumen und Peaks für v4 und v6, um Drift zu erkennen.
- Queue-Drops pro Klasse: Drops in Voice sind kritisch, unabhängig vom Protokoll.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko; Perzentile sind wichtiger als Mittelwerte.
- Policer-Hits/Remarking: zeigen Profilüberschreitungen und Missmarkierung – getrennt für v4/v6.
- QoE-KPIs: MOS/R-Faktor, Jitter/Loss aus RTP/RTCP, Video-Freeze-Events – nach IP-Version korrelieren.
Ein praxistauglicher Betriebssatz bleibt: Drops in der Voice-Klasse sind ein Incident – egal ob IPv4 oder IPv6.
Praxis-Blueprint: DSCP und Priorisierung im Dual-Stack zuverlässig umsetzen
- Ein Klassenmodell für beide Stacks: EF für Voice, AF für Video, Control, BE, Background – gleiche Bedeutungen.
- Trust Boundary identisch: gleiche Regeln für IPv4 und IPv6 an UNI/NNI/PE; Kundenmarkierungen normalisieren.
- QoS-Templates dual pflegen: jede IPv4-Policy hat ein IPv6-Äquivalent (oder eine gemeinsame, protokollunabhängige Policy).
- DSCP-to-CoS/TC konsistent: gleiche Mappings für v4 und v6 in Metro (CoS) und Core (MPLS-TC).
- Tunnel-Strategie definieren: DSCP-Propagation (copy/map/rewrite) für EVPN/VXLAN, IPsec, DS-Lite, SRv6 dokumentieren.
- Burst-Handling standardisieren: Shaping an Engpässen, Queue-Limits, Video gewichtet, Voice LLQ mit Limit.
- Monitoring dual-stack-fähig machen: KPIs pro Klasse getrennt nach v4/v6, Perzentile, Queue-Telemetrie.
Häufige Fragen zu QoS in IPv6
Muss ich DSCP in IPv6 anders setzen als in IPv4?
Die Semantik ist gleich. Entscheidend ist, dass Ihre Geräte IPv6 Traffic Class korrekt auswerten und dass Ihre Policies v6 genauso klassifizieren, remarken und queuen wie v4.
Warum wird DSCP über das Internet oft nicht respektiert?
Weil viele Netze DSCP an Übergängen neutralisieren oder intern neu interpretieren. Das gilt für IPv4 und IPv6 gleichermaßen. QoS ist am zuverlässigsten in Netzen, die Sie kontrollieren (Enterprise, Carrier-Backbone, managed Services, definierte Interconnects).
Was ist der häufigste Dual-Stack-QoS-Fehler?
Unvollständige Policies: IPv4 hat saubere Classifier und Mappings, IPv6 nicht. Dadurch landet IPv6-Echtzeittraffic im Default oder verliert Markierungen an Übergängen. Ein konsequentes Template- und Mapping-Management ist der sicherste Weg, diese Fehler dauerhaft zu vermeiden.
