Tunneling: Bridging IPv4 Islands with IPv6

Imagine you have two IPv6-capable networks—perhaps your corporate headquarters in one city and a branch office in another. Both networks support IPv6 internally. But the wide-area links between them, provided by a legacy carrier, only support IPv4. How do you establish IPv6 connectivity?

This is the island problem: isolated IPv6 'islands' surrounded by an IPv4 'ocean'. You cannot simply route IPv6 packets across IPv4 infrastructure—routers along the path don't understand the protocol and will drop the packets.

The solution is tunneling: encapsulate the IPv6 packet inside an IPv4 packet, send it across the IPv4 network, and de-encapsulate it at the destination. To the IPv4 network, it looks like ordinary IPv4 traffic. To the endpoints, it provides end-to-end IPv6 connectivity.

Tunneling is a technique where one protocol's packets are encapsulated as the payload of another protocol. In the context of IPv6 transition, we're primarily concerned with IPv6-in-IPv4 tunneling: wrapping complete IPv6 packets inside IPv4 packets for transit across IPv4 infrastructure.

The Encapsulation Process

When an IPv6 packet enters a tunnel:

1. Original IPv6 packet is prepared for transmission
2. Tunnel ingress router prepends a new IPv4 header
3. IPv4 Protocol field is set to 41 (indicating IPv6 payload)
4. IPv4 source/destination addresses identify the tunnel endpoints
5. Encapsulated packet traverses IPv4 network
6. Tunnel egress router removes the IPv4 header
7. Original IPv6 packet continues toward final destination

The IPv4 'wrapper' is invisible to the transported IPv6 payload. The encapsulated packet arrives exactly as it was sent, except for hop limit decrements and potential fragmentation.

Protocol 41: The Tunneling Identifier

The key to IPv6 tunneling is IP Protocol 41. In the IPv4 header's Protocol field (and IPv6's Next Header field), the value 41 specifically means 'IPv6 encapsulation.' This tells the receiving router that the payload is a complete IPv6 packet, not TCP, UDP, or another transport protocol.

When an IPv4 router (or firewall) sees Protocol 41, it knows the payload structure and can either forward the packet as-is or, if it's a tunnel endpoint, de-encapsulate the IPv6 packet.

Understanding the exact structure of a tunneled packet is essential for configuration, troubleshooting, and capacity planning.

IPv6-in-IPv4 Encapsulated Packet

+-------------------------------------------+
|          IPv4 Header (20 bytes)           |
| - Source: Tunnel Ingress IPv4 Address     |
| - Destination: Tunnel Egress IPv4 Address |
| - Protocol: 41 (IPv6)                     |
| - TTL: Set by tunnel ingress              |
+-------------------------------------------+
|          IPv6 Header (40 bytes)           |
| - Source: Original IPv6 Source            |
| - Destination: Original IPv6 Destination  |
| - Hop Limit: Decremented normally         |
| - Next Header: TCP/UDP/ICMPv6/etc         |
+-------------------------------------------+
|         Original Payload                  |
| (TCP/UDP segment, ICMPv6 message, etc)    |
+-------------------------------------------+

Header Overhead Analysis

Tunneling adds exactly 20 bytes of overhead (the IPv4 header) to every packet. This has significant implications:

• Original IPv6 packet: 40 bytes header + payload
• After encapsulation: 20 bytes IPv4 + 40 bytes IPv6 + payload
• Total overhead: 60 bytes of headers (vs 40 for native IPv6)

TTL and Hop Limit Handling

A critical question: what happens to the TTL (IPv4) and Hop Limit (IPv6) fields during tunneling?

At Tunnel Ingress:

• The IPv4 header's TTL is set independently (typically 64 or 255)
• The IPv6 packet's Hop Limit is preserved unchanged (or copied to IPv4 TTL)
• Some implementations copy the inner Hop Limit to the outer TTL

During Transit:

• IPv4 routers decrement the outer TTL
• The inner IPv6 Hop Limit is untouched (opaque payload)

At Tunnel Egress:

• The outer IPv4 header is removed
• The IPv6 Hop Limit should be decremented by 1 (tunnel counts as one hop)
• Some implementations don't decrement, making the tunnel 'invisible' to traceroute

Why This Matters:

• Tunnels can create 'hidden hops' that don't appear in path analysis
• If inner TTL isn't decremented, routing loops could persist longer
• Different implementations handle this differently—verify your equipment's behavior

The Maximum Transmission Unit (MTU) problem is one of the most challenging aspects of tunneling. When you add 20 bytes of IPv4 header, you reduce the effective MTU for the inner IPv6 packet.

The Mathematics of Tunnel MTU

Consider a standard Ethernet network:

• Physical MTU: 1500 bytes
• IPv4 header overhead: 20 bytes
• Effective inner MTU: 1500 - 20 = 1480 bytes

For IPv6 inside the tunnel:

• IPv6 minimum MTU: 1280 bytes (required by RFC 8200)
• Outer path MTU must be at least: 1280 + 20 = 1300 bytes

If the outer IPv4 path has any link with MTU less than 1300 bytes, the tunnel cannot guarantee delivery of minimum-sized IPv6 packets without fragmentation.

Path MTU Discovery Challenges

IPv6 relies on Path MTU Discovery (PMTUD) to optimize packet sizes, and IPv6 routers are not allowed to fragment—only the source can fragment. This creates a problem:

1. Host sends large IPv6 packet (e.g., 1400 bytes)
2. Tunnel ingress encapsulates → 1420 bytes total
3. Intermediate IPv4 router has MTU of 1400 → packet too big
4. Router should send ICMP 'Packet Too Big' with MTU 1400
5. Host receives ICMP and learns: inner MTU should be 1400 - 20 = 1380

But here's the problem: The ICMP message references the outer IPv4 header. The original host (which only sees IPv6) needs this translated:

• Tunnel egress must intercept ICMP Packet Too Big
• Calculate correct inner MTU (outer MTU - 20)
• Generate ICMPv6 Packet Too Big for the IPv6 source

If any of this translation fails (firewalls blocking ICMP, incorrect calculation), PMTUD breaks and connections hang on large packets—the infamous 'black hole' problem.

The simplest form of tunneling is the manually configured tunnel (also called 'configured tunnel' or 'point-to-point tunnel'). Both endpoints are explicitly configured with each other's addresses.

Characteristics of Configured Tunnels

• Explicit endpoint configuration: Administrator specifies source and destination IPv4 addresses
• Point-to-point topology: Each tunnel connects exactly two endpoints
• Static or dynamic routing: IPv6 routing over the tunnel can use any routing protocol
• Permanent or on-demand: Tunnel exists as a logical interface, always available

Configuration Requirements

At each endpoint, you must configure:

1. Tunnel source: The local IPv4 address used for encapsulation
2. Tunnel destination: The remote endpoint's IPv4 address
3. Tunnel mode: IPv6-in-IPv4 (ip6ip, ipv6ip, or similar vendor syntax)
4. IPv6 address: The IPv6 address for the tunnel interface itself
5. Routing: Static routes or routing protocol for reachable IPv6 prefixes

Example: Point-to-Point Tunnel Configuration

Scenario: Connect two sites with IPv6 over an IPv4 WAN.

• Site A: IPv4 192.0.2.1, IPv6 network 2001:db8:a::/48
• Site B: IPv4 198.51.100.1, IPv6 network 2001:db8:b::/48

Conceptual Configuration (Router A):

interface Tunnel0
  tunnel source 192.0.2.1
  tunnel destination 198.51.100.1
  tunnel mode ipv6ip
  ipv6 address 2001:db8:ffff::1/126
  
ipv6 route 2001:db8:b::/48 Tunnel0

Conceptual Configuration (Router B):

interface Tunnel0
  tunnel source 198.51.100.1
  tunnel destination 192.0.2.1
  tunnel mode ipv6ip
  ipv6 address 2001:db8:ffff::2/126
  
ipv6 route 2001:db8:a::/48 Tunnel0

With this configuration, any IPv6 traffic destined for the remote site is:

1. Routed to the Tunnel0 interface
2. Encapsulated in IPv4 with Protocol 41
3. Sent to the remote endpoint's IPv4 address
4. De-encapsulated and routed into the remote IPv6 network

While configured tunnels work well for site-to-site connectivity, they don't scale for individual hosts. If every IPv6 host needed manually configured tunnels to every possible destination, deployment would be impossible.

Automatic tunnels solve this by deriving tunnel endpoint addresses from the destination IPv6 address itself, eliminating per-tunnel configuration.

The Concept of Automatic Tunneling

In automatic tunneling:

1. The tunnel destination IPv4 address is embedded within the IPv6 address
2. No explicit endpoint configuration is needed
3. Any node can tunnel to any other node with an appropriate address
4. Tunnels are created 'on the fly' as needed

The two primary automatic tunneling mechanisms are:

• 6to4: Uses the 2002::/16 prefix with embedded IPv4 addresses
• ISATAP: Intra-Site Automatic Tunnel Addressing Protocol for enterprises

We'll cover 6to4 in depth on the next page. Here, let's understand the general automatic tunneling concept.

IPv4-Compatible Addresses (Historical)

The original automatic tunneling mechanism used IPv4-compatible IPv6 addresses (::IPv4 format, e.g., ::192.0.2.1). This has been deprecated (RFC 4291) and should not be used, but understanding it helps explain the evolution:

IPv4-compatible address format (DEPRECATED):
::192.0.2.1 = 0000:0000:0000:0000:0000:0000:c000:0201
                                         ^^^^^^^^^^^^^^
                                         IPv4 embedded in low 32 bits

When a host wanted to tunnel to ::198.51.100.1, it would:

1. Extract the low 32 bits → 198.51.100.1
2. Use that as the IPv4 tunnel destination
3. Encapsulate and send

This was deprecated because it created significant security vulnerabilities and routing confusion.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)

ISATAP (RFC 5214) is designed for intra-enterprise use, allowing IPv6-capable hosts to communicate automatically over an IPv4-only corporate network.

ISATAP Address Format:

Prefix:0:5efe:IPv4-address
Example: 2001:db8:1:1:0:5efe:192.168.1.100
                  ^^^^^^^^^^^^^^^^^
                  IPv4 embedded in interface ID

How ISATAP Works:

1. Enterprise configures an ISATAP router with an IPv6 prefix
2. Hosts discover the prefix and form ISATAP addresses
3. Host-to-host traffic: extract IPv4 from destination, tunnel directly
4. Host-to-external: send to ISATAP router for de-encapsulation

ISATAP is considered deprecated for new deployments. Native IPv6 or controlled tunneling mechanisms are preferred.

Why Deprecated?

• Security vulnerabilities (source address spoofing)
• Complex troubleshooting
• Tunnel asymmetry issues
• Better alternatives available (native IPv6, DHCPv6)

Generic Routing Encapsulation (GRE) provides an alternative to Protocol 41 tunneling, offering additional flexibility at the cost of slight overhead.

GRE Overview

GRE (RFC 2784) is a general-purpose encapsulation protocol that can carry any payload protocol over IP. Unlike Protocol 41 (which specifically means 'IPv6 payload'), GRE explicitly identifies its payload type, allowing a single tunnel to carry multiple protocols.

GRE Header Structure:

+------------------+------------------+
|  Flags/Version   | Protocol Type    |
|    (2 bytes)     |   (2 bytes)      |
+------------------+------------------+
| Optional: Checksum, Key, Sequence  |
+------------------------------------+

Protocol Type Values:

• 0x0800 = IPv4
• 0x86DD = IPv6
• 0x0806 = ARP

GRE for IPv6 Tunneling

When using GRE to tunnel IPv6:

1. Original IPv6 packet is prepared
2. GRE header is added (Protocol Type = 0x86DD)
3. IPv4 header is added (Protocol = 47 for GRE)
4. Combined packet traverses IPv4 network
5. At egress: IPv4 header removed, GRE header removed, IPv6 forwarded

When to Use GRE vs Protocol 41

Use Protocol 41 (6in4) when:

• You only need IPv6 encapsulation
• Minimal overhead is important
• Simple configuration is preferred
• Firewall/NAT isn't an issue

Use GRE when:

• You need to carry multiple protocols through one tunnel
• You want keyed tunnels for site identification
• You need sequence numbers for debugging or reordering detection
• Your infrastructure is already GRE-based

Note on NAT: Neither Protocol 41 nor GRE works well through NAT. Both use IP protocols (not UDP ports) that NAT devices typically don't understand. For NAT traversal, you need UDP-based tunneling like Teredo.

Tunnels introduce unique security challenges. By encapsulating traffic, tunnels can potentially bypass security controls designed for native traffic.

Security Risks of Tunneling

1. Firewall Bypass If a firewall inspects IPv4 traffic but doesn't understand Protocol 41 or GRE, encapsulated IPv6 traffic passes through unexamined. Malicious IPv6 content is invisible to the IPv4 firewall.

2. Unauthorized Tunnel Endpoints Anyone who knows your tunnel configuration (especially with automatic tunneling) could send traffic to your network. Without proper ingress filtering, spoofed tunnel traffic can penetrate your perimeter.

3. Traffic Injection Attackers can craft packets with forged outer IPv4 addresses and deliver malicious IPv6 payloads to your tunnel endpoint. Without authentication, the endpoint accepts these packets.

4. Information Leakage Tunnel traffic reveals your IPv4 infrastructure. An observer can map your tunnel endpoints and learn about your network topology.