How to configure IPv6 tunneling over IPv4

If you need some help with this, it’s best to your topology and configs on the GNS3Vault forum. We can take a look there…

Hello Rene,
I was testing these two different manual tunneling types in the lab and wanted to confirm what one should see as that expected MTU for GRE vs. the manual tunnel? I know that you state GRE has a higher MTU, but that was not what I observed in the testing. Also not 100%

R6#sh int tunn0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source (GigabitEthernet0/1), destination
   Tunnel Subblocks:
         Tunnel0 source tracking subblock associated with GigabitEthernet0/1
          Set of tunnels with source GigabitEthernet0/1, 1 member (includes iterators), on interface 
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes 


R022DC3N4806#sh int tunn0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source (GigabitEthernet0/1), destination
   Tunnel Subblocks:
         Tunnel0 source tracking subblock associated with GigabitEthernet0/1
          Set of tunnels with source GigabitEthernet0/1, 1 member (includes iterators), on interface 
  Tunnel protocol/transport IPv6/IP
  Tunnel TTL 255
  Tunnel transport MTU 1480 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input 00:00:09, output 00:00:21, output hang never
  Last clearing of "show interface" counters 00:16:08
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo

Also I am not seeing any association with one of my MAC addresses to the link-local address for GRE tunnel that you mention is created with EUI-64 and takes lowest numbered interface MAC address.

R6#sh ipv6 route
IPv6 Routing Table - default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
       H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
       IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
       ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, la - LISP alt
       lr - LISP site-registrations, ld - LISP dyn-eid, a - Application
R   2001:10:22:22::/64 [120/2]
     via FE80::5287:89FF:FEB9:7460, Tunnel0
C   2001:10:66:66::/64 [0/0]
     via Loopback0, directly connected
L   2001:10:66:66::66/128 [0/0]
     via Loopback0, receive
L   FF00::/8 [0/0]
     via Null0, receive

Many thanks for your help to clarify.

Hi Thomas,

The output of the show command for tunnel interfaces has been changed in later IOS versions. What version are you using here?

The MTU of 17916 bytes is the largest MTU that the router can handle which is based on its buffer sizes. The Tunnel transport MTU of 1476 bytes is the actual MTU of the interface, this is smaller to compensate for the overhead of GRE (24 bytes).

About the MAC address, do a “show ip interface tunnel” to see your link local address of this router, then compare it to the MAC addresses of this router.


I am running 15.4(3)M1. Ok - that makes sense. So based upon this GRE tunnel overhead is 24bytes while manual tunnel mode is 20 bytes, so slightly more overhead for the GRE method. As for the link-local, I was looking on the wrong router :slight_smile: - I posted R6 configuration above, but when looking for that link-local of the neighbor I was not on the right router in my lab setup. Many thanks.

Whenever a loopback goes down our IGP (EIGRP in this example) could find another path (if there is another path).

should the above read whenever a physical interface goes down? because a loopback should never go down.

That’s a typo for sure. Just fixed it, thanks for letting me know.

Hi Rene,

You mention (or the other way around) in the first part of this. I am wondering how to encapsulate ipv4 traffic inside an ipv6 tunnel. Let’s say I have 2 global v6 endpoints (routers) but want to setup a v4 GRE tunnel INSIDE the v6 tunnel. I don’t know if this makes sense, or if it’s even possible. Basically I want to be able to use global v6 addresses, in order to still use GRE, such as in a DMVPN situation.

Thanks in advance

Hello Mitchell

Yes, it is possible to encapsulate IPv4 inside an IPv6 tunnel. What Rene has described in this lesson is colloquially referred to as 6in4. What you are referring to is 4in6 which is equally achievable.

You can find out more information about such a tunnel from the following Cisco Documentation.

I hope this has been helpful!


The major differences:

MCT - MTU is 1480, less overhead, supports only a single passenger protocol, mode is ipv6ip.

GRE - MTU is 1476, more overhead, supports multiple passenger protocols, mode is gre.

1 Like

MCT? Is that the manual mode?

Hello Chris

I belive what @zz.alnajjar is referring to is a Manually Configured Tunnel (MCT) although it does not have an official such name. What the manually configured tunnel is, is an IP packet inside an IP packet. A doubly encapsulated packet. If this is configured, the overhead will just be 20 bytes, which is the size of the header of a standard IPv4 packet, thus prodcing an MTU of 1500-20 = 1480. GRE on the other hand has a header of 24 bytes providing an MTU of 1500-24 = 1476.

More info can be found on page 2 of this Cisco Documentation.

I hope this has been helpful!


Rene, I tried using the following lab without configuring a global IPv6 address but it would not work until I configured the global IPv6 address. I’m going to continue to play with this to see if I can figure it out, but in the event I don’t can you tell me if there’s something else I have to do to get this to work with the link-local addresses?

Hello Mike

Rene’s comment about the use of link-local addresses was only for use by the router in order to determine the next hop. In other words, the IP addresses between routers, or the infrastructure addresses, can in deed be link local addresses only. However, the global IPv6 addresses should be configured in order for the end devices to be able to communicate.

Now for this particular lab, the use of global unicast addresses is vital because you must translate between a specific IPv6 range and a specific IPv4 range in order to perform IPv6 tunneling over IPv4. Such tunneling requires that the IPv6 address range be global unicast addresses. Link-local addresses cannot and should not be tunneled. This restriction is further outlined in this RFC:

Because the IP address range being translated is also the IP address subnets that exist between the Banana and Melon routers as well as between the Apple and Kiwi routers, if no tunneling was necessary, these subnets could indeed remain link-local addresses. However, because these ranges are the very ranges that are to be translated, they must be global unicast addresses.

I hope this has been helpful!


It has. Thank you very much for your reply!

1 Like

what is the general-prefix at the end of the configuration files of r1 and r3?


Hello Giovanni

The General Prefix is a feature that is used to easily migrate a router’s IPv6 addresses from one general prefix to another. If you’re not sure what a general prefix is, then that sentence probably sounds cryptic. Take a look at this lesson to find out more about it and it should make sense.

Now in this particular case, the general prefix feature is being used on an interface that is performing 6to4 tunneling. Specifically, what the command does is (according to Cisco):

Defines a general prefix for an IPv6 address.

When defining a general prefix based on a 6to4 interface, specify the 6to4 keyword and the interface-type interface-numberarguments.

When defining a general prefix based on an interface used for 6to4 tunneling, the general prefix will be of the form 2001:a.b.c.d::/48, where “a.b.c.d” is the IPv4 address of the interface referenced.

You can find out more about how this feature is implemented at the following Cisco documentation, which is where the above quote was taken from…

I hope this has been helpful!


So I’ve been looking around some and guess I’m not looking for the right thing… In trying this, how can I make the tunnel dual stack? that is, run both IPv4 and IPv6 over the same tunnel? Initially I had a GRE tunnel that I ran IPv4 over. Looking at this, it switches the tunnel IPv6 over IPv4… or maybe I’m just confusing myself… Initially I was doing the following to “tunnel” my PtP over the public internet (IPSEC is on the interfaces but I don’t think that matters)

interface Tunnel10
 description GRE:: to core-sv7-rtr1
 bandwidth 500000
 ip address
 ip mtu 1476
 ip tcp adjust-mss 1436
 ip ospf network point-to-point
 ip ospf cost 2000
 ipv6 address FE80::FEED:2 link-local
 ipv6 enable
 keepalive 3 2
 tunnel source Port-channel32.10
 tunnel destination
 tunnel key 129

I added the tunnel mode ipv6ip and lost my IPv4 OSPFv2 connection (but then my IPv6 addressing started working). What am I missing?

Hello Marcos

I haven’t actually tried this, but based on my experience, and the research of Cisco documentation and RFCs, I have come up with the following.

The ipv6ip keyword causes the tunnel to be able to encapsulate IPv6 packets over the IPv4 infrastructure. If you have this keyword enabled, the device will expect to receive IPv6 packets and encapsulate them into IPv4 packets. When it doesn’t receive IPv6 packets (but IPv4 packets instead), it considers them incompatible and doesn’t send them over the tunnel. The alternative is to use the tunnel mode ipsec ipv4 command which will enable IPv4 traffic to be encapsulated. You can’t have both, even though you can configure both IPv4 and IPv6 addresses to the tunnel interface. The encapsulation mechanism is where one protocol is not compatible with the other.

The best way to perform this is to create two separate tunnels, one for each protocol (v4 or v6).

I hope this has been helpful!


Ok, so I’ve been experimenting with this on and off and its been frustrating as heck. At this point one of the things I’ve discovered is that regardless of “tunnel key xxx”, it does not actually use that as a selector. Therefore its not possible to create more than one tunnel between two end points. So to use the suggestion to create two tunnels, one for IPv4 and one for IPv6 requires some extra work.

One method I tried was using two different loopbacks (like Loopback0.4 and Loopback0.6) both with different IPv4 addresses on them. Although this worked (as well as just using Loopback0 with secondary addresses) it has rapidly become bulky and messy…

My situation is that for my remote sites, I want to go over the public internet for three different “networks” (ie, my remove routers have a public interface and two internal mini-VRFs). Since the remote site typically is on someone’s DHCP service, I need to connect from there to one of two entry points in my network. To do this for both IPv4 and IPv6, this immediately calls for 4 tunnels (2 IPv4 and 2 IPv6 tunnels). Once those tunnels are established, I can then tunnel the other VRFs over two of those four IPsec tunnels.

By the time I’m done, I’m up to twelve tunnels. Painful… So… Part 1… Establishing two IPv4/IPv6 tunnels to two redundant sites… Any way to make this literally two tunnels rather than 4 now?

If I can solve that, I can reduce the others as well. 12 tunnels however is painful. Additionally how can I set up the VRF tunnels to NOT establish unless the public tunnels are established (is there a tracking method?)


Hello Marcos

First of all concerning the tunnel key xxx command, after doing some experimentation with Rene it turns out that it can be used to distinguish between two or more tunnels that terminate on the same interface. Rene has put together a lesson that covers the use of this specific feature:

Now as for the remote sites, even with the tunnel key feature, your solution is still not quite so scalable. You would reduce the number of needed tunnels by a factor of 2, but it would still not be scalable.

Without actually having gone in to create specific configurations, and after chatting with Rene for inspiration, I have the following guidelines/suggestions that may help you in achieving what you need.

First of all, since you’re using both IPv4 and IPv6, a possible solution would be to create a DMVPN topology for each of the protocol stacks. So with two DMVPN topologies , you can have a scalable solution with three (or any number of) spokes. And DMVPN does support the use of multiple VRFs. This is called VRF Aware DMVPN or VRF Integrated DMVPN.

Alternatively, a less-scalable solution, although for some situations, it may be suitable, and even more elegant, is to use the DMVPN per VRF feature. This assumes however that there will be a limited number of VRFs, but this may be suitable for your situation. Also note that there is a limited number of platforms on which this feature is available, so you may not be able to implement it.

The lessons and links that may help you in your design are the following:

For VRF Integrated DMVPN:


I hope this has been helpful!