How Does IPv6 Handle Fragmentation?
Fragmentation is a fundamental networking mechanism that allows large packets to traverse networks with varying Maximum Transmission Unit (MTU) sizes. While IPv4 and IPv6 both support fragmentation, IPv6 introduces a radically different approach that shifts responsibility away from intermediate routers to the network's endpoints. Understanding how IPv6 handles fragmentation is crucial for network engineers, administrators, and developers working with modern IP networks.
The Fundamental Shift: End-to-End Fragmentation
The most significant difference between IPv4 and IPv6 fragmentation lies in who performs the fragmentation. This architectural change has profound implications for network performance and design.
IPv4 Fragmentation Model
In IPv4, fragmentation can occur at multiple points along the packet's journey:
- Source hosts can fragment packets before transmission
- Intermediate routers can fragment packets if they encounter a link with a smaller MTU than the packet size
- Routers only avoid fragmentation if the "Don't Fragment" (DF) bit is set in the IP header
This distributed fragmentation model allows packets to be broken up anywhere along the path, which seems convenient but creates several problems:
- Router performance degradation - Fragmentation requires CPU-intensive operations that slow down forwarding
- Increased overhead - Each fragment requires its own IP header, increasing bandwidth consumption
- Security vulnerabilities - Fragmented packets can be used to evade firewalls and intrusion detection systems
- Reassembly complexity - Lost fragments require retransmission of the entire original packet
IPv6 End-to-End Model
IPv6 takes a fundamentally different approach by implementing source-only fragmentation:
- Only the source node can fragment IPv6 packets
- Intermediate routers never fragment - they simply drop oversized packets
- Path MTU Discovery becomes essential rather than optional
When an IPv6 router receives a packet larger than the next hop's MTU, it:
- Drops the packet immediately
- Sends an ICMPv6 "Packet Too Big" (Type 2) message back to the source
- Includes the MTU value of the problematic link in the ICMPv6 message
The source node then adjusts its packet size and retransmits, either by:
- Reducing the packet size to fit within the discovered MTU
- Adding a Fragment Extension Header to create properly-sized fragments
This design decision improves router performance significantly by eliminating fragmentation processing from the forwarding path, allowing routers to focus on their primary task: fast packet forwarding.
The IPv6 Minimum MTU Requirement
IPv6 mandates a minimum link MTU of 1280 bytes. This is a hard requirement that all IPv6-capable network links must support.
Why 1280 Bytes?
This value was chosen to ensure that:
- Essential protocols (like IPsec) have sufficient space for headers and payload
- Fragmentation can be avoided in most scenarios
- A reasonable balance between efficiency and compatibility is maintained
For comparison, IPv4's minimum MTU requirement is only 576 bytes.
Practical Implications
- Source nodes performing Path MTU Discovery will never reduce packet size below 1280 bytes
- If a link cannot support 1280-byte packets, it is not IPv6-compliant
- The recommended MTU for IPv6 networks is 1500 bytes (Ethernet standard)
- Some networks use larger MTUs (jumbo frames up to 9000 bytes) for performance optimization
When testing your network's IPv6 connectivity using tools like test-ipv6.run, MTU-related issues can manifest as connection timeouts or partial connectivity, particularly when accessing sites with different MTU configurations.
Unlike IPv4, which includes fragmentation fields in the base IP header, IPv6 uses an Extension Header approach. The Fragment Header is a separate, optional header that appears only when fragmentation is needed.
The Fragment Extension Header is identified by Next Header value 44 and has the following 8-byte structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field Descriptions
Next Header (8 bits)
- Identifies the header type that follows the Fragment Header
- Points to the first header of the "Fragmentable Part" of the original packet
- Common values: 6 (TCP), 17 (UDP), 58 (ICMPv6)
Reserved (8 bits)
- Set to zero on transmission
- Ignored on reception
- Reserved for future use
Fragment Offset (13 bits)
- Indicates the position of this fragment relative to the start of the original "Fragmentable Part"
- Measured in 8-byte (octet) units
- Range: 0 to 8191 (allowing fragments up to 65,528 bytes)
Res (2 bits)
- Reserved field
- Must be set to zero
M Flag (1 bit)
- "More Fragments" flag
- Set to 1 for all fragments except the last
- Set to 0 for the final fragment
- Indicates whether more fragments follow
Identification (32 bits)
- Unique identifier generated by the source node
- All fragments of the same original packet share the same Identification value
- Used by the receiving host to reassemble fragments into the original packet
- Must be unique for the source-destination pair and protocol for the packet's lifetime
This structure is more compact than IPv4's fragmentation fields and enables efficient processing at the destination.
The Fragmentation Process
When an IPv6 source needs to fragment a packet, it follows this process:
Step 1: Determine Fragmentation Need
The source determines fragmentation is needed when:
- The packet exceeds the known Path MTU
- An ICMPv6 "Packet Too Big" message was received
- The upper-layer protocol cannot reduce payload size
Step 2: Divide the Packet
The source divides the original packet into fragments:
- Calculate fragment size: Each fragment must fit within the Path MTU minus IPv6 header (40 bytes) and Fragment Header (8 bytes)
- Create fragment payloads: Divide the "Fragmentable Part" into chunks aligned on 8-byte boundaries (except the last fragment)
- Preserve unfragmentable headers: Extension headers that must be processed by intermediate nodes (Hop-by-Hop Options, Routing Header) appear before the Fragment Header
For each fragment, the source:
- Copies the base IPv6 header from the original packet
- Inserts a Fragment Extension Header after any unfragmentable extension headers
- Sets the Fragment Offset to indicate this fragment's position
- Sets the M flag (1 for all but the last fragment)
- Uses the same Identification value for all fragments
- Adjusts the IPv6 header's Payload Length field to reflect the fragment size
Step 4: Transmission
Fragments are transmitted as independent IPv6 packets. They:
- May arrive out of order
- May take different paths through the network
- Are treated as regular IPv6 packets by routers (no special handling)
- Must all arrive for successful reassembly
Reassembly at the Destination
The receiving host performs reassembly:
- Identify fragment set: Groups fragments by source address, destination address, and Identification value
- Buffer fragments: Stores received fragments in memory until all arrive
- Check completeness: Uses Fragment Offset and M flag to determine when all fragments are present
- Reassemble: Reconstructs the original packet by combining fragments in order
- Deliver: Passes the complete packet to the upper-layer protocol
Reassembly Timeout
If all fragments don't arrive within a timeout period (typically 60 seconds):
- Incomplete fragments are discarded
- An ICMPv6 "Fragment Reassembly Time Exceeded" message may be sent to the source
- The upper-layer protocol (TCP/UDP) handles retransmission if needed
Path MTU Discovery: The Critical Mechanism
Since IPv6 routers cannot fragment packets, Path MTU Discovery (PMTUD) becomes essential rather than optional. PMTUD is the mechanism by which a host dynamically discovers the smallest MTU along the path to a destination.
How PMTUD Works in IPv6
- Initial transmission: Source sends packets using its local link MTU (typically 1500 bytes)
- MTU bottleneck detection: When a router encounters a packet too large for the next hop, it drops the packet and sends an ICMPv6 "Packet Too Big" message
- MTU cache update: Source receives the ICMPv6 message and stores the smaller MTU value
- Retransmission: Source retransmits using the smaller packet size
- Path changes: If routing changes, the process repeats to discover the new path's MTU
PMTUD Security Considerations
To prevent attackers from poisoning the MTU cache with fake ICMPv6 messages:
- Hosts track destinations to which they've sent traffic
- Only ICMPv6 messages matching tracked destinations are accepted
- Messages are validated to ensure they reference actual sent packets
- Cache entries typically expire after a timeout period
PMTUD Challenges
PMTUD can fail when:
- ICMPv6 filtering: Overzealous firewalls block ICMPv6 "Packet Too Big" messages
- Black hole routing: Packets are silently dropped without ICMPv6 responses
- Incorrect MTU values: Network equipment reports incorrect MTU sizes
These failures can cause connectivity problems that manifest as:
- Connection timeouts for certain websites
- Partial page loads (small requests work, large ones fail)
- SSH connections that hang after authentication
Testing tools like test-ipv6.run help identify these issues by performing comprehensive connectivity tests across different protocols and packet sizes.
IPv6's fragmentation model has significant performance implications:
Benefits
- Improved router performance: Routers forward packets faster without fragmentation overhead
- Better security: Firewalls and IDS systems see complete packets, not just first fragments
- Reduced network overhead: Fewer fragmented packets mean less header overhead
- Simplified router design: Removing fragmentation reduces hardware complexity and cost
Challenges
- PMTUD dependency: Networks must allow ICMPv6 messages for proper operation
- Increased latency: Failed transmissions require round-trip time for ICMPv6 messages and retransmission
- Application awareness: Applications benefit from being MTU-aware to avoid fragmentation
- Transition complexity: Mixed IPv4/IPv6 networks require careful MTU planning
Best Practices
To optimize IPv6 fragmentation handling:
- Allow ICMPv6: Configure firewalls to permit ICMPv6 Type 2 (Packet Too Big) messages
- Use 1500-byte MTU: Standardize on Ethernet's default MTU where possible
- Enable PMTUD: Ensure hosts properly implement Path MTU Discovery
- Monitor MTU issues: Use logging to detect fragmentation-related problems
- Test regularly: Use IPv6 testing tools to verify connectivity and MTU handling
Conclusion
IPv6's fragmentation model represents a significant improvement over IPv4's approach. By restricting fragmentation to source nodes only, IPv6 enables faster router performance, better security, and more predictable network behavior. However, this design makes Path MTU Discovery essential, requiring network operators to ensure ICMPv6 messages flow properly.
Understanding IPv6 fragmentation is crucial for:
- Diagnosing connectivity issues
- Optimizing network performance
- Configuring firewalls correctly
- Designing applications for IPv6 networks
The shift from router-based to end-to-end fragmentation exemplifies IPv6's philosophy of simplifying the network core while adding intelligence at the edges. As IPv6 adoption continues to grow, proper fragmentation handling becomes increasingly important for maintaining reliable, high-performance internet connectivity.
To verify your network properly handles IPv6 fragmentation and Path MTU Discovery, use comprehensive testing tools like test-ipv6.run, which can identify MTU-related issues and other IPv6 connectivity problems.
Related Topics: