IPv6 tunneling is one of those topics that comes up far more often in real networks than people expect, usually because native IPv6 is not yet available everywhere it is needed. I have deployed IPv6 tunnels in labs for certification study, in transitional enterprise networks where the ISP had not yet delivered native dual-stack, and in scenarios connecting isolated IPv6 islands across an IPv4-only WAN. In this guide I am covering the three tunneling approaches I use most on Cisco routers: GRE tunnels carrying IPv6, 6to4 tunnels, and manually configured IPv6-in-IPv4 tunnels.
Networking Fundamentals: Why Tunneling Exists
IPv6 tunneling exists to solve one core problem: connecting IPv6-capable networks or hosts across infrastructure that only supports IPv4. Rather than waiting for every hop in the path to support native IPv6, a tunnel encapsulates IPv6 packets inside IPv4 packets, letting them traverse the IPv4-only network transparently.
There are several tunneling mechanisms, each with different tradeoffs:
- Manual (configured) tunnels are point-to-point, statically configured, and the most predictable and easiest to troubleshoot — my preferred choice for permanent site-to-site IPv6 connectivity over an IPv4 backbone.
- GRE tunnels carrying IPv6 are similar to manual tunnels but use GRE encapsulation, which has the added benefit of being able to carry multiple protocols and supports routing protocols running directly over the tunnel more flexibly.
- 6to4 tunnels are automatic tunnels that derive the IPv6 prefix from a public IPv4 address, useful for quick connectivity without needing a tunnel broker, but with well-known reliability issues in production due to reliance on public 6to4 relay routers.
- ISATAP is used for intra-site tunneling, letting individual dual-stack hosts obtain IPv6 connectivity over an IPv4-only internal network — I am not covering it in depth here since it is largely legacy at this point, but it is worth knowing it exists.
Configuring a Manual IPv6-over-IPv4 Tunnel
This is my default choice for a permanent, predictable site-to-site IPv6 tunnel.
Router-A(config)# interface Tunnel0
Router-A(config-if)# no ip address
Router-A(config-if)# ipv6 address 2001:db8:1::1/64
Router-A(config-if)# tunnel source GigabitEthernet0/0/1
Router-A(config-if)# tunnel destination 203.0.113.2
Router-A(config-if)# tunnel mode ipv6ip
On the remote router:
Router-B(config)# interface Tunnel0
Router-B(config-if)# no ip address
Router-B(config-if)# ipv6 address 2001:db8:1::2/64
Router-B(config-if)# tunnel source GigabitEthernet0/0/1
Router-B(config-if)# tunnel destination 203.0.113.1
Router-B(config-if)# tunnel mode ipv6ip
Verification:
Router-A# show interface tunnel 0
Router-A# ping ipv6 2001:db8:1::2
I always check show ipv6 interface tunnel0 brief to confirm the tunnel interface has the expected IPv6 address and is in an up/up state before troubleshooting further.
Configuring a GRE Tunnel Carrying IPv6
GRE tunnels are my choice when I also need to run a routing protocol directly over the tunnel, or when I need to carry multiple protocols across the same tunnel infrastructure.
Router-A(config)# interface Tunnel1
Router-A(config-if)# no ip address
Router-A(config-if)# ipv6 address 2001:db8:2::1/64
Router-A(config-if)# tunnel source GigabitEthernet0/0/1
Router-A(config-if)# tunnel destination 203.0.113.2
Router-A(config-if)# tunnel mode gre ip
The key difference from the manual tunnel is tunnel mode gre ip instead of tunnel mode ipv6ip. This adds GRE header overhead (reducing effective MTU by 24 bytes for IPv6-in-GRE-in-IPv4), which I always account for when configuring the tunnel interface MTU and any MSS clamping:
Router-A(config-if)# ipv6 mtu 1476
Router-A(config-if)# ipv6 tcp adjust-mss 1436
Configuring a 6to4 Tunnel
6to4 automatically derives an IPv6 prefix (2002::/16 plus the embedded IPv4 address) from the router’s public IPv4 address, which means it does not require coordination with a remote peer’s specific IPv4 address the way manual and GRE tunnels do.
Router-A(config)# interface Tunnel2
Router-A(config-if)# no ip address
Router-A(config-if)# ipv6 address 2002:CB00:7101::1/64
Router-A(config-if)# tunnel source GigabitEthernet0/0/1
Router-A(config-if)# tunnel mode ipv6ip 6to4
Router-A(config)# ipv6 route 2002::/16 Tunnel2
Note that in the address 2002:CB00:7101::1, the middle portion (CB00:7101) is the hexadecimal representation of the router’s public IPv4 address (203.0.113.1 in this example) — I always calculate this carefully rather than guessing, since a mismatch here means the derived prefix will not correctly map back to the router’s actual public IP.
I use 6to4 sparingly in production because reliability depends heavily on public 6to4 relay infrastructure operated by third parties, which has degraded significantly over the years as native IPv6 adoption has grown. For anything beyond a quick lab exercise, I prefer manual tunnels or a proper tunnel broker service.
Verification and Troubleshooting
Regardless of tunnel type, my verification checklist is consistent:
Router-A# show interface tunnel0
Router-A# show ipv6 interface brief
Router-A# show ip route | include Tunnel
Router-A# show ipv6 route
If the tunnel interface itself is up but pings across it fail:
- Confirm the underlying IPv4 path between tunnel source and destination is reachable with a plain IPv4 ping.
- Check for an ACL along the IPv4 path blocking protocol 41 (IPv6-in-IPv4) for manual tunnels, or protocol 47 (GRE) for GRE tunnels.
- Check for MTU issues — tunneled IPv6 packets are larger than native ones due to the outer IPv4 (and possibly GRE) header, and if fragmentation is blocked somewhere in the path, larger packets will silently fail while small pings succeed, creating a confusing “ping works but the application doesn’t” symptom.
Router-A# ping 203.0.113.2 size 1500 df-bit
I also always check tunnel-specific interface counters after ruling out the basics, since a tunnel interface that shows up/up but reports steadily incrementing “output drops” is often silently discarding oversized packets rather than fragmenting them, especially when the df-bit is set upstream by an application:
Router-A# show interface tunnel0 | include drop
Real-World Enterprise Scenario: Connecting IPv6 Islands Across a Legacy WAN
I worked on a project where two data centers each had fully deployed native IPv6 internally, but the WAN connecting them was provided by a carrier that had not yet delivered native IPv6 transport. Rather than waiting on the carrier’s IPv6 roadmap, I configured manual IPv6-over-IPv4 tunnels between the data center edge routers, running OSPFv3 directly over the tunnel interfaces to extend IPv6 routing between sites.
Router-A(config-if)# ipv6 ospf 1 area 0
This let both sites operate with full IPv6 reachability months before the underlying WAN transport natively supported it, and once native IPv6 transport did become available, migrating away from the tunnel was simply a matter of enabling IPv6 on the physical WAN interfaces and decommissioning the tunnel, with essentially zero disruption to the rest of the IPv6 design.
Common Configuration Mistakes
- Forgetting
tunnel modeentirely, which defaults to GRE and can cause confusing behavior if you intended a manual ipv6ip tunnel - Miscalculating the embedded IPv4 address in a 6to4 prefix
- Not accounting for reduced effective MTU across the tunnel, leading to intermittent large-packet failures
- Leaving tunnel source/destination pointing at an interface or address that changes (e.g., a DHCP-assigned IP), breaking the tunnel silently after a renewal
- Not permitting protocol 41 or 47 through intermediate firewalls along the IPv4 path
Security Best Practices
- Treat tunnel interfaces as untrusted paths and apply IPv6 ACLs just as you would on any other interface
- Avoid 6to4 in production security-sensitive environments due to its reliance on third-party relay infrastructure with limited authentication
- Where possible, prefer IPsec-protected tunnels (or a GRE-over-IPsec combination) for tunnels crossing untrusted or public IPv4 infrastructure
- Disable unused tunnel interfaces rather than leaving them configured but idle, reducing unnecessary attack surface
Performance Tuning
- Explicitly set
ipv6 mtuandipv6 tcp adjust-msson tunnel interfaces to avoid fragmentation-related performance problems - Where routing protocols run over the tunnel, tune hello/dead timers appropriately since tunnel interfaces can have slightly higher latency characteristics than native links
- Monitor tunnel interface counters just like any physical interface — encapsulation/decapsulation errors are a strong early indicator of underlying IPv4 path problems
Frequently Asked Questions
What is the difference between a manual IPv6 tunnel and a GRE tunnel carrying IPv6? A manual tunnel uses IPv6-in-IPv4 encapsulation directly (protocol 41) with no additional header, while a GRE tunnel adds a GRE header (protocol 47), which allows multiprotocol transport but slightly reduces effective MTU.
Is 6to4 still a good choice for production IPv6 connectivity? Generally no — I recommend manual tunnels, a tunnel broker, or native connectivity instead, since 6to4 depends on third-party relay routers with inconsistent reliability.
Why does my tunnel interface show up/up but pings fail? Check the underlying IPv4 reachability between tunnel endpoints first, then check for an ACL or firewall blocking the tunneling protocol (41 for manual, 47 for GRE).
Can I run a routing protocol over an IPv6 tunnel? Yes, both manual and GRE tunnels support routing protocols like OSPFv3 or EIGRP for IPv6 running directly over the tunnel interface.
Summary
IPv6 tunneling remains a practical and often necessary tool for extending IPv6 connectivity across IPv4-only infrastructure. Manual tunnels offer the most predictable and easily troubleshot option for permanent site-to-site connectivity, GRE tunnels add multiprotocol flexibility at the cost of slightly reduced MTU, and 6to4 offers automatic addressing but with reliability tradeoffs that make it less suitable for production use today. Understanding the encapsulation differences and MTU implications of each is the key to deploying and troubleshooting them successfully.
References
- Cisco IPv6 Configuration Guide: Implementing Tunneling for IPv6 — cisco.com
- RFC 4213 — Basic Transition Mechanisms for IPv6 Hosts and Routers
- Cisco IOS IPv6 Command Reference — cisco.com
