IPv6 over IPv4 Tunnels: Manual, GRE, and 6to4 Compared

Sometimes you have IPv6 islands that need to talk to each other, but the network in between is IPv4-only and you cannot change it (a provider core, a legacy WAN, a merged network you do not fully control). The answer is to wrap IPv6 packets inside IPv4 and carry them across the gap. This article configures a manual IPv6-over-IPv4 tunnel on real Cisco IOS XE 17.18, proves it with a real ping across an IPv4-only core, and compares the three tunnel types you need to know: manual, GRE, and 6to4. It is part of the PingLabz IPv6 routing and services guide and builds on the GRE tunneling cluster.

The idea: IPv6 as the payload, IPv4 as the transport

Every tunnel is encapsulation. An IPv6-over-IPv4 tunnel takes a complete IPv6 packet and puts an IPv4 header in front of it. To the IPv4 core, the packet is just IPv4 traffic between two tunnel endpoints; the IPv6 payload is opaque and irrelevant. At the far end, the router strips the IPv4 header and hands the original IPv6 packet to its IPv6 stack. The two tunnel endpoints behave as if they share a direct IPv6 link, even though many IPv4 hops separate them.

The crucial mental split is between the underlay (the IPv4 network doing the actual forwarding) and the overlay (the IPv6 adjacency riding on top). The overlay only works if the underlay can deliver packets between the two endpoint addresses. Hold on to that distinction, because it is the source of the single most common tunnel failure, covered at the end.

Configuring a manual tunnel

A manual (also called configured or static) tunnel is point-to-point: you explicitly set both a source and a destination, so it carries traffic between exactly two known endpoints. Here is the working configuration from EDGE1 on the lab, tunneling to BR1 across the IPv4 core:

interface Tunnel0
 ipv6 address 2001:DB8:99:AAAA::1/64
 tunnel source Loopback0
 tunnel destination 10.255.0.3
 tunnel mode ipv6ip

Four lines do the work. The ipv6 address gives the tunnel interface an IPv6 identity, so the two ends form an IPv6 subnet (here 2001:DB8:99:AAAA::/64). tunnel source Loopback0 and tunnel destination 10.255.0.3 define the IPv4 endpoints of the underlay: the local loopback and the remote router's loopback. Using loopbacks rather than physical interfaces is deliberate, a loopback stays up as long as any path to the router exists, so the tunnel does not flap when a single physical link goes down. The line that sets the encapsulation is tunnel mode ipv6ip: this is native IPv6-in-IPv4, which uses IP protocol number 41 with no additional tunnel header. It is the leanest possible encapsulation, and it is what "manual IPv6 tunnel" means on IOS.

What the tunnel interface actually shows

Once the underlay can reach both endpoints, the tunnel comes up. Here is the real interface state:

EDGE1#show interface Tunnel0
Tunnel0 is up, line protocol is up
  Tunnel source 10.255.0.1 (Loopback0), destination 10.255.0.3
  Tunnel protocol/transport IPv6/IP
  Tunnel transport MTU 1480 bytes

Read the two lines that matter. Tunnel protocol/transport IPv6/IP confirms the tunnel is carrying IPv6 as its protocol directly inside IPv4 as its transport, which is exactly what tunnel mode ipv6ip requests (protocol 41, no GRE). And Tunnel transport MTU 1480 bytes tells you the overhead: the underlay uses a standard 1500-byte MTU, the IPv4 header consumes 20 bytes, and the remaining 1480 bytes are available to the IPv6 payload. There is no GRE header here, so you lose only the 20 bytes of the IPv4 header. Remember that 1480 figure; it changes with GRE.

Proving it: IPv6 across an IPv4-only path

The whole point of the tunnel is that IPv6 reachability now exists where the underlay speaks only IPv4. The proof is a real ping from EDGE1 to BR1's tunnel address:

EDGE1#ping 2001:DB8:99:AAAA::2 repeat 4
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 3/3/4 ms

Four exclamation marks, 100 percent success. Those IPv6 echo requests were encapsulated in IPv4 at EDGE1, forwarded hop by hop across the IPv4 core (which never saw an IPv6 packet), decapsulated at BR1, answered, and returned the same way. From the IPv6 point of view, EDGE1 and BR1 are directly connected neighbors on the 2001:DB8:99:AAAA::/64 subnet. From the core's point of view, this was ordinary protocol-41 IPv4 traffic between two loopbacks.

The three tunnel types compared

Manual is one of three encapsulation styles you should recognise. They differ by exactly one configuration line and by what they can carry.

The practical differences: manual is the lean default when you have a known pair of endpoints and only need unicast IPv6. GRE costs four extra bytes of overhead (MTU drops from 1480 to 1476) but it can carry multicast, which means you can run an IPv6 IGP such as OSPFv3 or EIGRP for IPv6 over the tunnel and let it exchange routes dynamically. That single capability is why GRE is often the better choice for anything beyond a static pair. 6to4 is automatic and multipoint: it derives a 2002::/16 IPv6 prefix from the tunnel's IPv4 source address and needs no explicit destination, which sounds convenient but comes with real operational problems around relay reliability. It is deprecated and being retired, so treat it as exam knowledge and legacy documentation, not a design you would deploy today.

The gotcha that will waste your afternoon: underlay reachability

Here is the failure mode that catches everyone. A tunnel interface can show up/up and still not pass a single packet. The reason is the underlay. Because the tunnel is encapsulated in IPv4 and sent between the two endpoint addresses, those two addresses must be mutually reachable in the IPv4 routing table. On the lab, the tunnel stayed down until CORE1 had IPv4 routes to both loopbacks; without underlay reachability, there is nowhere for the encapsulated packets to go.

What makes this deceptive is that the line protocol on a manual tunnel can come up based on the local source being valid, independent of whether the remote endpoint is actually reachable. So you see up/up, assume the tunnel is healthy, and then the ping fails. When that happens, do not stare at the IPv6 configuration. Check two things in order. First, can the local endpoint ping the remote endpoint over IPv4 (ping 10.255.0.3 from EDGE1)? If not, it is an underlay routing problem: fix the IPv4 route to the far loopback. Second, if IPv4 reachability is fine but large packets or real applications fail while small pings succeed, suspect MTU and fragmentation: the encapsulation ate into the payload budget (1480 for manual, 1476 for GRE) and something in the path is not handling the reduced MTU or is dropping the fragments. The rule to remember: an up/up tunnel that will not pass traffic is almost always an underlay routing or MTU problem, not an overlay one.

Why GRE wins when you need dynamic routing

The single most useful practical difference between manual and GRE tunnels is multicast, and the reason it matters is dynamic routing protocols. OSPFv3 and EIGRP for IPv6 both rely on multicast to discover neighbors and exchange updates. A manual ipv6ip tunnel carries unicast only, so you cannot run an IGP across it; you are limited to static IPv6 routes pointing at the tunnel. That is fine for a single pair of endpoints with a handful of prefixes, but it does not scale and it does not react to failures.

Switch the same tunnel to tunnel mode gre ip and multicast rides across, so you can enable OSPFv3 or EIGRP for IPv6 on the tunnel interface and let the two sides learn each other's IPv6 prefixes dynamically. Now, if a downstream link changes, the IGP reconverges automatically instead of waiting for you to edit static routes. The cost is four bytes of overhead and a slightly lower MTU (1476 instead of 1480). For anything beyond a static point-to-point pair, that trade is almost always worth it, which is why GRE, not manual, is the workhorse for IPv6 island interconnect in production.

MTU and fragmentation, in a bit more detail

Tunnels shrink the usable payload, and that has real consequences for applications. With a 1500-byte physical MTU, a manual tunnel leaves 1480 bytes for the IPv6 packet and GRE leaves 1476. A host that still tries to send 1500-byte IPv6 packets will produce frames that do not fit once encapsulated. IPv6 does not allow routers to fragment in transit (unlike IPv4), so the tunnel source must either fragment the IPv4-encapsulated packet or rely on Path MTU Discovery to tell the origin host to send smaller packets. When PMTUD is broken (often because an overly aggressive firewall drops the ICMPv6 "packet too big" messages), you get the classic symptom: small pings succeed, but web pages hang and large transfers stall. The fix is usually to lower the TCP MSS on the tunnel interface with ipv6 tcp adjust-mss 1440 (or similar), which clamps TCP segment sizes so they fit inside the tunnel without relying on PMTUD. Keep this in mind whenever a freshly built tunnel pings clean but real traffic misbehaves.

A security note before you deploy

A tunnel is a hole through your perimeter by design: it carries IPv6 traffic that your IPv4 firewalls may not inspect. Because native ipv6ip and GRE tunnels are unauthenticated and unencrypted, anyone who can reach the tunnel destination over IPv4 and spoof the source could, in principle, inject traffic. For a tunnel that crosses any untrusted network, protect the underlay with IPsec (for example, a GRE-over-IPsec design) so the encapsulated IPv6 is both authenticated and encrypted. On a fully private, trusted core, a plain tunnel is acceptable, but make the decision consciously rather than by default.

Key Takeaways

• IPv6-over-IPv4 tunnels encapsulate whole IPv6 packets inside IPv4 so IPv6 islands can cross an IPv4-only core. Keep the underlay (IPv4 transport) and overlay (IPv6 adjacency) distinct in your head.
• A manual tunnel uses tunnel mode ipv6ip (protocol 41, no extra header, MTU 1480) and is point-to-point between two explicit endpoints. It carries unicast only, no multicast.
• GRE (tunnel mode gre ip) is one line different, costs 4 bytes (MTU 1476), and crucially carries multicast, so you can run an IPv6 IGP over it. 6to4 (tunnel mode ipv6ip 6to4) is automatic and multipoint but deprecated.
• show interface Tunnel0 confirms the encapsulation (Tunnel protocol/transport IPv6/IP) and the transport MTU. A real repeat ping proved 100 percent IPv6 delivery across an IPv4-only path.
• An up/up tunnel that will not ping is almost always an underlay problem: the two endpoint IPv4 addresses must be mutually reachable in the IPv4 table, and MTU/fragmentation is the second thing to check.

Tunnels bridge IPv6 islands over an IPv4 core. When the problem is instead an IPv6-only client reaching IPv4-only content, you need translation, which is the NAT64 article next. For the full picture, return to the IPv6 guide.