In the last article, we configured a manual tunnel, which is a point-to-point tunnel. In this article, we will be talking about an automatic tunneling mechanism—IPv4-compatible IPv6 tunnels. Although this tunnel type is now deprecated and superseded by another tunneling mechanism (6to4), it is good to have an idea of how it works, since it is still documented and available in some IPv6 implementations such as Cisco.

CCNA Training – Resources (Intense)

IPv4-compatible IPv6 tunnels were initially specified in RFC 2893, along with configured tunnels; however, this tunneling mechanism has now been deprecated because of some limitations, which we will talk about later. They make use of IPv4-compatible IPv6 addresses, which are made up of 96 zeros followed by 32-bit IPv4 addresses. IPv4-compatible IPv6 addresses are meant to be globally unique, meaning that the embedded IPv4 addresses should come from public IPv4 addresses. According to RFC 4291, the format for these addresses is as shown below:

The IPv4-compatible IPv6 tunneling mechanism provides a way to automatically tunnel IPv6 traffic in IPv4 packets. The tunnel destination is not specified but is calculated from the IPv4 address embedded in the destination IPv6 address. Therefore, these tunnels are point-to-multipoint in nature. An example will help clarify things. Let’s use the simple network scenario shown below:

Notice that this network scenario is different from the one we had before. I have changed the network scenario to fit a more realistic profile. In this case, the CE routers are connected to their ISP via IPv4 addresses. Although we use the same router to represent the ISP in our scenario, this will most likely not be the case in reality.

The base configuration on the devices is as follows:

ISP

interface FastEthernet0/0
 ip address 41.1.1.2 255.255.255.252
!
interface FastEthernet0/1
 ip address 41.2.2.1 255.255.255.252
!

CE1

interface Loopback0
 no ip address
 ipv6 address 2001:DB8:1:A000::1/64
!
interface FastEthernet0/1
 ip address 41.1.1.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 41.1.1.1

CE2

interface Loopback0
 no ip address
 ipv6 address 2001:DB8:1:B000::2/64
!
interface FastEthernet0/1
 ip address 41.2.2.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 41.2.2.1

I will now configure the tunnel between the CE routers, specifying the tunnel mode as IPv4-compatible. The only other thing that you need to specify for this tunnel type is the tunnel source. Taking the IPv4 address on the tunnel source interface, the router (or any node) can then form an IPv4-compatible IPv6 address.

The configuration on my CE routers is as follows:

interface Tunnel1
 no ip address
 tunnel source FastEthernet0/1
 tunnel mode ipv6ip auto-tunnel

As you can see from the configuration above, the tunnel mode for IPv4-compatible IPv6 tunnels in Cisco is ipv6ip auto-tunnel. Notice also that we have not specified any tunnel destination. Let’s take a look at the IPv6 routing table of one of the routers.

As you can see from the highlighted section above, the ::/96 prefix block is now reachable via the tunnel. It means that this router will connect to other IPv4-compatible IPv6 addresses via this tunnel. Second, the ::41.1.1.2/128 address has been assigned to the tunnel interface. This is an IPv4-compatible IPv6 address generated by adding the tunnel source’s IPv4 address to the 0:0:0:0:0:0/96 prefix.

To test connectivity, I can ping the other tunnel endpoint. In our case, this will be CE2; however, because this is a point-to-multipoint tunnel, there could be many other tunnel endpoints. The IPv4-compatible IPv6 address of CE2’s tunnel will be ::41.2.2.2/128.

Note that you can specify IPv4-compatible IPv6 addresses as ::<ipv4_address>. You can also specify them in their hexadecimal form. For example, ::41.2.2.2 is the same as ::2902:0202, therefore a ping to that address will also go through:

This conversion will come in handy when we move over to 6to4 tunnels in the next article.

Moving on, our tunnels are up. However, the point is to carry IPv6 traffic between the CEs. As we did in the previous article for our manual tunnel, we will configure a static route for the IPv6 network pointing to the other endpoint. The difference, however, is that we cannot specify only the tunnel as the output interface because the tunnel destination is not defined for IPv4-compatible IPv6 tunnels. Since the tunnel destination must be derived from the embedded IPv4 address in the destination IPv6 address, we must specify the tunnel endpoint’s IPv6 address as the next-hop address.

I will now try to ping CE2’s loopback IPv6 address from CE1’s loopback IPv6 address.

IPv4-compatible IPv6 tunnels also encapsulate IPv6 packets in IPv4 headers and set the protocol field to 41, just as we saw with manual tunnels. We can use Wireshark to confirm this:

Dynamic Routing Protocols through IPv4-compatible IPv6 tunnels

Dynamic routing protocols like EIGRPv6 and OSPFv3 that require neighbor relationships to form via link-local IPv6 addresses will not work through IPv4-compatible IPv6 tunnels. Even though these tunnels have link-local IPv6 addresses, those link-local addresses are not reachable via the tunnels. For example, look at the link-local addresses of our tunnels:

I can’t ping CE2’s tunnel’s link-local address from CE1:

Therefore, there is no way a neighbor relationship will form via EIGRPv6 for example. However, BGP allows neighbor relationships to be formed using global unicast addresses. Therefore, I can use BGP as a routing protocol (for whatever reason you may want to do this). The configuration on both CE routers will be something similar to the following:

CE1

router bgp 1
 bgp router-id 1.1.1.1
 no bgp default ipv4-unicast
 neighbor ::41.2.2.2 remote-as 2
 !
 address-family ipv6
  neighbor ::41.2.2.2 activate
  network 2001:db8:1:a000::/64
  no synchronization
 exit-address-family

CE2

router bgp 2
 bgp router-id 2.2.2.2
 no bgp default ipv4-unicast
 neighbor ::41.1.1.2 remote-as 1
 !
 address-family ipv6
  neighbor ::41.1.1.2 activate
  network 2001:db8:1:b000::/64
  no synchronization
 exit-address-family

I will remove the static routes and look at my BGP routes.

And, of course, I can ping:

Issue with IPv4-compatible IPv6 tunnels

One of the biggest limitations with IPv4-compatible IPv6 tunnels is the fact that they do not support connection to the native IPv6 Internet. For IPv4-compatible IPv6 tunnels to work, the communicating nodes must both support automatic tunneling. For this reason, this type of automatic tunneling has not been widely implemented and a better solution (6to4) replaced it. IPv4-compatible IPv6 addresses have also been deprecated.

Note: 6to4 was not a replacement for IPv4-compatible IPv6 tunnels as such. However, IPv4-compatible IPv6 tunneling was deprecated because 6to4 provided a better approach.

Summary

This brings us to the end of this article, in which we have considered the now deprecated IPv4-compatible IPv6 tunnels. We have seen that this tunneling mechanism provides automatic tunnels by not specifying a tunnel destination. One of its limitations is that it provides no support for the native IPv6 Internet.

Another tunneling mechanism that performs a similar function like IPv4-compatible IPv6 tunnels but also provides support for communicating with the native IPv6 Internet is 6to4, which we will be discussing in the next article. I hope you have found this article insightful.

References and Further Reading

  1. RFC 2893: Transition Mechanisms for IPv6 Hosts and Routers: http://tools.ietf.org/html/rfc2893
  2. RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers: http://tools.ietf.org/html/rfc4213
  3. RFC 7059: A Comparison of IPv6-over-IPv4 Tunnel Mechanisms: http://tools.ietf.org/html/rfc7059