IPv6 Header Structure

The Internet was designed as a best-effort network—every packet receives the same treatment regardless of its content or urgency. While this egalitarian approach served the early Internet well, modern applications have wildly different requirements. A real-time video call cannot tolerate the same delays acceptable for email. A stock trading update must arrive faster than a software update download.

The Traffic Class field in IPv6 addresses this fundamental challenge. This 8-bit field, directly corresponding to IPv4's Type of Service (ToS) field, enables networks to classify packets into priority categories and provide differentiated treatment based on application requirements. It's the primary mechanism through which Quality of Service (QoS) is implemented at the network layer.

The Traffic Class field occupies bits 4-11 of the IPv6 header (immediately after the 4-bit Version field). Though only 8 bits, this field is subdivided into two distinct components with different purposes:

Historical Context: From ToS to DiffServ

In IPv4's original design, the 8-bit Type of Service field was intended for:

• 3 bits: Precedence (priority level)
• 4 bits: Type of Service flags (delay, throughput, reliability, cost)
• 1 bit: Reserved

This design proved problematic—the flags were too coarse, implementations were inconsistent, and the model didn't scale. In the late 1990s, the IETF redefined the field as part of the Differentiated Services (DiffServ) architecture:

• 6 bits: DSCP (Differentiated Services Code Point)
• 2 bits: ECN (Explicit Congestion Notification) — added later in RFC 3168

IPv6's Traffic Class field was designed from the start to use this modern DiffServ interpretation.

DiffServ is the dominant QoS architecture for IP networks. It operates on a simple but powerful principle: classify packets at the edge, treat them consistently throughout the core.

Core Concepts

1. Traffic Classification (Edge)

At network entry points, packets are classified and marked with appropriate DSCP values based on:

• Application type (voice, video, data)
• Service agreement (premium, business, best-effort)
• Source/destination identity
• Traffic characteristics

2. Per-Hop Behavior (Core)

Routers in the network core examine DSCP values and apply Per-Hop Behaviors (PHBs)—standardized treatment policies including:

• Prioritized queuing
• Bandwidth allocation
• Drop probability under congestion

3. Aggregation

DiffServ aggregates many individual flows into a small number of classes, scaling to large networks without per-flow state.

Why DiffServ Scales

Unlike earlier QoS approaches (like IntServ with RSVP) that required per-flow reservation state at every router, DiffServ:

With only 64 possible DSCP values and typically 4-8 distinct PHBs deployed, routers need minimal hardware resources for DiffServ—just a few queues and scheduling policies.

The 6-bit DSCP field allows 64 possible values (0-63). The IETF has standardized several code points while allowing network-specific customization:

Standard Per-Hop Behaviors

Expedited Forwarding (EF) — DSCP 46

EF is designed for traffic requiring:

• Low delay
• Low jitter (delay variation)
• Low loss
• Guaranteed bandwidth

Routers implement EF with a strict priority queue—EF packets are served before any other class. This makes EF ideal for VoIP and real-time video.

Assured Forwarding (AF) — RFC 2597

AF provides four classes (AF1-AF4), each with three drop precedence levels:

AFxy where:
  x = Class (1-4): Higher class = higher priority
  y = Drop Precedence (1-3): Higher = more likely dropped under congestion

For example:

• AF11 (DSCP 10): Class 1, Low drop precedence
• AF13 (DSCP 14): Class 1, High drop precedence (dropped first in Class 1)
• AF41 (DSCP 34): Class 4, Low drop precedence (premium traffic)

The final 2 bits of the Traffic Class field (bits 10-11) carry ECN—a mechanism that allows routers to signal congestion without dropping packets. This is a significant improvement over traditional congestion detection, which relied on packet loss as the signal.

The Problem with Drop-Based Congestion Signaling

Traditionally, when routers experience congestion, they drop packets. Senders detect drops (via timeouts or duplicate ACKs) and reduce sending rate. This works, but:

1. Dropped packets waste all resources used to transmit them across previous hops
2. Drops increase latency (retransmission required)
3. Bursty drops can trigger severe throughput reduction
4. For real-time traffic, drops directly degrade quality

ECN Solution

With ECN, routers mark packets with congestion indication instead of dropping them. The destination echoes this marking to the source, which reduces sending rate without data loss.

ECN-TCP Interaction

TCP uses two flags to support ECN:

1. ECE (ECN-Echo): Set by receiver to inform sender that CE marking was observed
2. CWR (Congestion Window Reduced): Set by sender to acknowledge ECE receipt

Connection Setup:

• SYN: ECE=1, CWR=1 → "I support ECN"
• SYN-ACK: ECE=1, CWR=0 → "I also support ECN"

Data Transfer:

• If receiver sees CE marking: Set ECE in ACKs
• When sender receives ECE: Reduce congestion window, set CWR
• Receiver sees CWR: Stop setting ECE (until next CE)

This signaling prevents the severe throughput drops that occur with packet loss while still achieving congestion control.

Implementing Traffic Class-based QoS requires coordination across network elements:

1. Classification and Marking (Edge Routers)

Classifiers examine packets and assign DSCP values:

Policy: Voice Traffic Classification

IF:
  Protocol = UDP AND
  Destination Port IN (5060-5061, 16384-32767) AND
  Packet Size < 200 bytes
THEN:
  Mark DSCP = EF (46)
  
IF:
  Protocol = TCP AND
  Destination Port = 443 AND
  Source matches known video CDN
THEN:
  Mark DSCP = AF41 (34)

2. Policing and Shaping (Edge)

• Policer: Measures traffic rate, re-marks or drops excess
• Shaper: Buffers traffic to smooth bursts to contracted rate

3. Queuing and Scheduling (Core Routers)

Core routers map DSCP values to queues and apply scheduling:

Common Scheduling Algorithms:

• Strict Priority (SP): Serve highest priority first, always
• Weighted Fair Queuing (WFQ): Allocate bandwidth proportionally
• Class-Based WFQ (CBWFQ): WFQ with minimum bandwidth guarantees
• Low Latency Queuing (LLQ): SP for priority + CBWFQ for others

Let's design a complete QoS policy for an enterprise network supporting voice, video, business applications, and general traffic:

Business Requirements:

• Voice quality (MOS > 4.0) regardless of network load
• Video conferencing without pixelation
• Business apps responsive even during congestion
• Background tasks (backups) shouldn't impact interactive traffic

Implementation on Router Interface:

class-map match-all VOIP
  match dscp ef

class-map match-all VIDEO
  match dscp af41 af42 af43
  
class-map match-all INTERACTIVE
  match dscp af31 af32 af33
  
class-map match-all BUSINESS-DATA
  match dscp af21 af22 af23
  
class-map match-all SCAVENGER
  match dscp cs1

policy-map WAN-EDGE
  class VOIP
    priority percent 10
  class VIDEO
    bandwidth percent 30
    random-detect dscp-based
  class INTERACTIVE
    bandwidth percent 25
    random-detect dscp-based
  class BUSINESS-DATA
    bandwidth percent 15
    random-detect dscp-based
  class SCAVENGER
    bandwidth percent 5
  class class-default
    bandwidth percent 15
    fair-queue

interface GigabitEthernet0/0
  service-policy output WAN-EDGE

This policy ensures voice always gets priority treatment, video and business apps receive guaranteed bandwidth, and scavenger traffic only uses residual capacity.

Service providers use Traffic Class to offer tiered services and maintain SLAs:

Multi-Tenant QoS

ISPs serving multiple enterprise customers must isolate QoS domains while providing consistent treatment:

1. Ingress: Customer traffic arrives with customer-applied DSCP
2. Edge Reclassification: Provider may remap to provider-internal DSCP based on SLA
3. Core Transport: Provider core uses internal DSCP for PHB
4. Egress Restoration: Original customer DSCP restored for customer-facing egress

Cross-Domain QoS Challenges

When traffic crosses multiple providers:

1. DSCP Bleaching: Some providers zero DSCP at boundaries (security, policy)
2. Inconsistent PHBs: Different providers may treat same DSCP differently
3. Peering Limitations: Best-effort peering ignores QoS entirely

Solutions:

• Private peering with QoS agreements
• MPLS VPNs with end-to-end QoS (traffic stays on one provider)
• SD-WAN overlays that hide underlying transport QoS issues

While Traffic Class functions identically to IPv4's redefined ToS field, several IPv6-specific aspects affect QoS implementation:

Tunneling and Traffic Class

When IPv6 packets are tunneled (e.g., 6to4, Teredo, GRE):

Option 1: Copy Traffic Class

Inner IPv6: Traffic Class = 46 (EF)
Outer IPv4: ToS = 46 (EF) → Same treatment

Option 2: Uniform Tunnel Class

Inner IPv6: Traffic Class = 46 (EF)
Outer IPv4: ToS = 0 → Tunnel treated as best-effort

Most implementations copy Traffic Class to outer header to preserve QoS treatment. RFC 2983 provides guidance on this topic.

IPv6 Flow Label + Traffic Class Synergy

The combination enables powerful optimization:

First packet of flow:
  1. Examine Traffic Class → Determine PHB
  2. Examine Flow Label → Cache (Src, Dst, FL) → PHB mapping
  
Subsequent packets:
  1. Lookup (Src, Dst, FL) in cache
  2. Apply cached PHB directly
  3. Skip Traffic Class examination if cached

This reduces per-packet processing while maintaining correct QoS treatment.

The Traffic Class field is IPv6's primary mechanism for Quality of Service, enabling differentiated treatment across networks of any scale.

What's Next

Having covered Traffic Class (QoS) and Flow Label (flow identification), we'll next examine the Hop Limit field—IPv6's replacement for IPv4's Time to Live. Understanding Hop Limit is essential for comprehending packet lifetime, routing loop prevention, and diagnostic tools like traceroute.