IPv6 Header Structure

IPv6 was designed with a fundamental challenge: how do you create a protocol that can accommodate features not yet imagined while maintaining the simplicity needed for wire-speed processing? The answer lies in a single, elegant 8-bit field: the Next Header.

The Next Header field serves a dual purpose that makes IPv6 remarkably flexible. It identifies the type of header immediately following the current one—whether that's another IPv6 extension header or the upper-layer protocol payload. This simple chaining mechanism replaces IPv4's rigid, embedded options with a modular, extensible architecture where new functionality can be added without modifying the base protocol.

The Next Header field occupies byte 6 of the IPv6 base header (bits 48-55). It immediately follows the Payload Length field and precedes the Hop Limit field:

Dual Functionality

The Next Header field serves two distinct purposes:

1. Protocol Identification (when pointing to transport layer)

When the Next Header value indicates TCP (6), UDP (17), or another transport protocol, it functions identically to IPv4's Protocol field—it tells the receiving host which protocol handler should process the payload.

2. Extension Header Chaining (when pointing to extension headers)

When the Next Header value indicates an extension header type (e.g., Routing = 43, Fragment = 44), it signals that additional IPv6-layer header processing is required before reaching the transport payload.

Comparison with IPv4

IANA maintains the registry of assigned Next Header values. Key values fall into three categories: extension headers, transport protocols, and special values:

The power of the Next Header field lies in its ability to chain multiple extension headers together. Each extension header contains its own Next Header field, pointing to the next header in the chain:

Chain Structure

IPv6 Base Header (NH = 0)
    ↓
Hop-by-Hop Options Header (NH = 43)
    ↓
Routing Header (NH = 44)
    ↓
Fragment Header (NH = 6)
    ↓
TCP Header
    ↓
Application Data

Each header's Next Header field points forward. The final extension header points to the transport protocol (TCP=6, UDP=17, etc.) or to 59 (No Next Header) for raw payloads.

Required Processing Order

RFC 8200 specifies the order in which extension headers should appear (and be processed):

1. Hop-by-Hop Options (if present, MUST be first)
2. Destination Options (for intermediate destinations, with Routing Header)
3. Routing Header
4. Fragment Header
5. Authentication Header (AH)
6. Encapsulating Security Payload (ESP)
7. Destination Options (for final destination only)
8. Upper-layer Header (TCP, UDP, ICMPv6, etc.)

This order ensures predictable processing—each entity knows what to expect next.

Why Order Matters

• Hop-by-Hop first: Every router must see it; can't be hidden behind other headers
• Routing before Fragment: Routing decisions made on complete packet, not fragments
• ESP last among security: Encryption covers everything after ESP header
• Destination Options position: Determines whether intermediate or final destination processes

Different network entities process extension headers differently based on their roles:

Router Processing

For transit traffic (not destined to the router itself):

1. Parse IPv6 base header
2. Check Next Header field
3. If Next Header = 0 (Hop-by-Hop): Process options, continue
4. If Next Header ≠ 0: Skip all extension headers, route based on Destination Address
5. Decrement Hop Limit, forward

Critical Insight: Routers typically only examine the base header and Hop-by-Hop options. All other extension headers are processed by the destination. This enables fast-path forwarding.

Destination Processing Algorithm

function processIPv6Packet(packet):
    current_header = packet.ipv6_header
    next_header_value = current_header.next_header
    offset = 40  // Base header is 40 bytes
    
    while True:
        if next_header_value in TRANSPORT_PROTOCOLS:
            // Reached upper layer
            deliverToTransport(packet, offset, next_header_value)
            return
        
        elif next_header_value == 59:  // No Next Header
            // Payload is raw or jumbogram padding
            handleNoNextHeader(packet, offset)
            return
        
        elif next_header_value in EXTENSION_HEADERS:
            // Process this extension header
            ext_header = parseExtensionHeader(packet, offset, next_header_value)
            processExtensionHeader(ext_header)
            
            // Move to next header
            offset += ext_header.length
            next_header_value = ext_header.next_header
        
        else:
            // Unknown header type
            sendICMPv6ParameterProblem(packet, offset)
            return

Unknown Next Header Handling

If a node encounters an unrecognized Next Header value, it MUST send an ICMPv6 Parameter Problem message (Type 4, Code 1 = unrecognized Next Header type) pointing to the offending field, then discard the packet.

The special value 59 indicates "No Next Header"—nothing meaningful follows. This might seem unusual, but it serves important purposes:

Use Cases for No Next Header

1. Jumbogram Padding

IPv6 Jumbograms (packets > 65,535 bytes, using Hop-by-Hop Jumbo Payload option) may have padding bytes at the end. The final extension header can point to 59, indicating the remaining bytes are padding, not a protocol payload.

2. IPsec ESP Without Upper Layer

Some IPsec configurations encrypt the entire original packet, including its IPv6 header. The outer (tunnel mode) IPv6 header's ESP may point to 59 when the encrypted content is a complete packet rather than a transport payload.

3. Raw Data Tunneling

Tunneling protocols might carry non-IP payloads. The Next Header value 59 signals that what follows is raw data without further protocol structure.

Processing No Next Header

if (next_header == 59):
    remaining_bytes = payload_length - current_offset + 40
    if (remaining_bytes > 0):
        // Remaining bytes exist but no protocol to process them
        // Could be padding, raw data, or encrypted content
        handleRawPayload(remaining_bytes)
    else:
        // No payload at all (unusual but valid)
        return

Security Implications

Packets with NH=59 may bypass certain firewall rules that expect transport-layer headers for filtering. Security policies should explicitly handle this case—either allowing or blocking based on context.

While we'll cover extension headers in depth in a later module, understanding their basic structure helps clarify Next Header usage:

Common Extension Header Format

Most extension headers (except Fragment) share a common format:

Length Calculation

The Header Extension Length field counts 8-byte units minus one:

• Length = 0 → Header is 8 bytes total
• Length = 1 → Header is 16 bytes total
• Length = 2 → Header is 24 bytes total
• Formula: total_bytes = (HdrExtLen + 1) * 8

This encoding ensures minimum granularity of 8 bytes, aligning with 64-bit architecture requirements.

Fragment Header Exception

The Fragment Header is always exactly 8 bytes and has a different format:

Note there's no length field—Fragment headers are always 8 bytes.

The Next Header mechanism and extension header chains introduce both opportunities and challenges:

Performance Concerns

RFC 7045 Recommendations

RFC 7045 provides guidance on extension header handling:

1. Forwarding nodes SHOULD forward packets with extension headers they don't understand
2. Firewalls SHOULD be configurable to block or allow specific extension header types
3. Operators SHOULD consider blocking packets with unusual extension header combinations
4. Implementations MUST handle at least [Hop-by-Hop, Destination, Routing, Fragment, AH, ESP] headers

Practical Filtering Approaches

Let's examine real-world packet structures and their Next Header chains:

Example 1: Simple TCP Packet

Packet Analysis:
  IPv6 Header (40 bytes)
    Next Header: 6 (TCP)
    
  TCP Header (20+ bytes)
    Source Port: 443
    Destination Port: 52847
    
  TCP Payload
    HTTPS encrypted data

Simplest case—base header points directly to TCP.

Example 2: Fragmented UDP Packet

Fragment 1 of 3:
  IPv6 Header (40 bytes)
    Next Header: 44 (Fragment)
    
  Fragment Header (8 bytes)
    Next Header: 17 (UDP)
    Fragment Offset: 0
    More Fragments: 1
    Identification: 0x12345678
    
  UDP Header (partial) + Data
    First 1232 bytes of original UDP datagram

Example 3: IPsec ESP Tunnel Mode

Outer IPv6 Header (40 bytes)
  Source: VPN Gateway A
  Destination: VPN Gateway B
  Next Header: 50 (ESP)
  
ESP Header (8 bytes)
  SPI: 0xABCDEF01
  Sequence: 1234
  
Encrypted Payload (contains):
  Inner IPv6 Header
    Source: Original Sender
    Destination: Original Receiver
    Next Header: 6 (TCP)
  
  TCP Header + Data (encrypted)
  
ESP Trailer (padding + auth)

The outer Next Header = 50 indicates ESP. After decryption, the inner packet has its own complete header chain.

Example 4: Complex Chain

IPv6 Header (NH=0)
  ↓
Hop-by-Hop (NH=60) - Router Alert option
  ↓
Destination Options (NH=43) - Padding
  ↓
Routing (NH=44) - Segment Routing
  ↓
Fragment (NH=51) - If fragmented
  ↓
AH (NH=6) - Authentication
  ↓
TCP - Application data

Maximum chain—unusual but valid for specialized applications.

The Next Header field is the linchpin of IPv6's extensible architecture—a simple 8-bit field enabling unlimited protocol evolution.

Module 3: IPv6 Header Complete

You've now mastered all five core IPv6 base header fields beyond addresses:

This foundation prepares you for the next module on Extension Headers, where we'll explore each extension type in detail—Hop-by-Hop Options, Routing, Fragment, and more.