Loading learning content...
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.
By the end of this page, you will understand the mechanics of IPv6-in-IPv4 tunneling: encapsulation formats, tunnel endpoint configuration, MTU considerations, different tunneling methods (manual vs automatic), and the trade-offs that make tunneling both powerful and complex.
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.
When an IPv6 packet enters a tunnel:
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.
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.
| Protocol Number | Protocol Name | Description |
|---|---|---|
| 1 | ICMP | Internet Control Message Protocol |
| 6 | TCP | Transmission Control Protocol |
| 17 | UDP | User Datagram Protocol |
| 41 | IPv6 | IPv6 Encapsulation |
| 47 | GRE | Generic Routing Encapsulation |
| 50 | ESP | Encapsulating Security Payload |
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.
Many firewalls and NAT devices don't understand Protocol 41. They may block it entirely, break it during translation, or fail to properly track stateful connections. This is one reason why more complex tunneling mechanisms (like Teredo, which uses UDP) were developed for traversing NAT.
Understanding the exact structure of a tunneled packet is essential for configuration, troubleshooting, and capacity planning.
+-------------------------------------------+
| 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) |
+-------------------------------------------+
Tunneling adds exactly 20 bytes of overhead (the IPv4 header) to every packet. This has significant implications:
| Scenario | Header Bytes | Overhead vs Native IPv4 |
|---|---|---|
| Native IPv4 | 20 bytes | Baseline |
| Native IPv6 | 40 bytes | +20 bytes |
| IPv6-in-IPv4 Tunnel | 60 bytes | +40 bytes |
| IPv6-in-IPv4 with GRE | 64-68 bytes | +44-48 bytes |
| IPv6-in-IPv4-in-IPsec | 80+ bytes | +60+ bytes |
A critical question: what happens to the TTL (IPv4) and Hop Limit (IPv6) fields during tunneling?
At Tunnel Ingress:
During Transit:
At Tunnel Egress:
Why This Matters:
Tunnels can make network path analysis misleading. A traceroute may show 3 hops, but if hop 2 is actually a tunnel traversing 15 routers, you have no visibility into those 15 routers. This makes troubleshooting significantly harder. Document your tunnels thoroughly!
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.
Consider a standard Ethernet network:
For IPv6 inside the tunnel:
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.
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:
But here's the problem: The ICMP message references the outer IPv4 header. The original host (which only sees IPv6) needs this translated:
If any of this translation fails (firewalls blocking ICMP, incorrect calculation), PMTUD breaks and connections hang on large packets—the infamous 'black hole' problem.
To avoid PMTUD issues with TCP, configure MSS (Maximum Segment Size) clamping at tunnel endpoints. This rewrites TCP SYN packets to advertise a smaller MSS, preventing endpoints from sending segments too large for the tunnel. For example, clamp to 1420 bytes (1480 - 40 IPv6 header - 20 TCP header) to ensure TCP data fits within a 1500-byte outer MTU.
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.
At each endpoint, you must configure:
Scenario: Connect two sites with IPv6 over an IPv4 WAN.
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:
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.
In automatic tunneling:
The two primary automatic tunneling mechanisms are:
We'll cover 6to4 in depth on the next page. Here, let's understand the general automatic tunneling concept.
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:
This was deprecated because it created significant security vulnerabilities and routing confusion.
Automatic tunnels create security exposure: any IPv4 address can receive tunnel traffic if it matches the embedded address. Attackers can spoof tunnel traffic, and automatic tunnels can create surprising paths through your network. Modern deployments prefer controlled mechanisms with explicit authorization.
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:
ISATAP is considered deprecated for new deployments. Native IPv6 or controlled tunneling mechanisms are preferred.
Why Deprecated?
Generic Routing Encapsulation (GRE) provides an alternative to Protocol 41 tunneling, offering additional flexibility at the cost of slight overhead.
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:
When using GRE to tunnel IPv6:
| Feature | Protocol 41 (6in4) | GRE |
|---|---|---|
| Overhead | 20 bytes (IPv4 only) | 24-28 bytes (IPv4 + GRE) |
| Multi-protocol | IPv6 only | Any protocol (IPv4, IPv6, MPLS, etc.) |
| Keying | Not supported | Optional 4-byte key field |
| Sequencing | Not supported | Optional sequence number |
| Checksum | IPv4 only | Optional GRE checksum |
| NAT traversal | Poor (Protocol 41 blocked) | Poor (Protocol 47) |
| Vendor support | Universal | Universal |
Use Protocol 41 (6in4) when:
Use GRE when:
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.
In service provider networks, GRE keys can identify different customers using the same tunnel endpoint. Each key creates a logically separate tunnel, allowing one physical router to terminate tunnels for multiple customers while keeping their traffic isolated.
Tunnels introduce unique security challenges. By encapsulating traffic, tunnels can potentially bypass security controls designed for native traffic.
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.
Remember: tunnels are an 'outer shell' that security devices must understand. A tunnel endpoint accepts packets based on their outer IPv4 addresses—if those are spoofed, malicious traffic enters your IPv6 network. Treat tunnel interfaces with the same suspicion as internet-facing interfaces.
For organizations and individuals who lack native IPv6 connectivity from their ISP, tunnel brokers provide a valuable service: free or low-cost IPv6 connectivity via configured tunnels.
A tunnel broker is a service that:
How It Works:
| Provider | Prefix Size | Protocol | Notable Features |
|---|---|---|---|
| Hurricane Electric (tunnelbroker.net) | /48 or /64 | 6in4 | Free, global PoPs, certification program |
| SixXS | /48 | Various | Defunct (closed 2017) |
| NetAssist | /48 | 6in4 | Ukrainian provider |
| IP4Market | /48 | 6in4 | Commercial, SLA available |
Hurricane Electric is the most widely used free tunnel broker, with tunnel servers on multiple continents. Their service includes:
Tunnel brokers are explicitly a transition technology. As native IPv6 deployment grows, the need for tunnel brokers diminishes. Many brokers report declining usage as more ISPs offer native IPv6. For production use, always prefer native IPv6 connectivity from your provider.
Tunneling provides the critical capability to connect IPv6 'islands' across IPv4 infrastructure. Let's consolidate what we've learned:
What's Next:
Next, we'll explore 6to4—a specific automatic tunneling mechanism that uses the 2002::/16 prefix. 6to4 was designed to make IPv6 transition 'zero configuration' by embedding IPv4 addresses directly in IPv6 addresses, enabling any v4-connected host to create tunnels automatically. While largely deprecated now, understanding 6to4 is essential for grasping the evolution of transition technologies.
You now understand IPv6 tunneling fundamentals: encapsulation mechanics, packet structure, MTU challenges, manual vs automatic tunneling, GRE alternatives, security considerations, and tunnel broker services. This foundation prepares you for understanding specific mechanisms like 6to4, Teredo, and NAT64.