There’s a lot of talk about IPv6 replacing IPv4, but we won’t just wake up one day and find that the whole Internet has changed to IPv6; there has to be a way to transition smoothly from IPv4 to IPv6 because of the huge investment we already have in IPv4. In fact, will IPv4 ever be completely phased out? That’s something to think about. In this series, we will be considering one of the IPv4-to-IPv6 transition tools—tunneling.

Overview of IPv4-to-IPv6 Transition Tools

Generally speaking, there are three major tools to aid in the transition from IPv4 to IPv6: dual stack, tunneling, and translation. Dual stack, also known as dual IP layer, is when a node can communicate using IPv4 and IPv6 in parallel. Dual stack is specified in RFC 4213.

Tunneling involves carrying IPv6 packets in IPv4 packets so that two IPv6 domains (hosts, nodes, networks, etc.) separated by an IPv4 infrastructure can communicate. There are different IPv6 tunneling mechanisms, which will be our focus for this series.

CCNA Training – Resources (Intense)

The last transition tool, Translation, provides a way to translate between IPv4 and IPv6 headers. Network Address Translation-Protocol Translation (NAT-PT), the original specification for translation, had many issues and was eventually deprecated; however, there are other translation mechanisms, such as the one specified in RFC 6145.

Configured Tunnels

Configured tunnels represent one of the oldest tunneling mechanisms; the latest specification for this tunneling mechanism is in RFC 4213. Configured tunnels are also called manual tunnels, 6in4, static tunnels, or protocol 41 tunnels. They provide a point-to-point tunnel between the two IPv6 domains over an IPv4 infrastructure, as shown below:

These tunnels will carry IPv6 traffic encapsulated within IPv4 packets, requiring that both tunnel endpoints must be dual stack. The encapsulation of IPv6 traffic within an IPv4 packet is as depicted below:

Because the tunnel options have to be manually set up, configured tunnels are not as flexible as the other automatic tunnel mechanisms; however, these tunnels are stable and straightforward to troubleshoot.

Hint: If you are familiar with GRE tunnels, then configured tunnels should not be too far off to you because they are similar in operation. The difference is that GRE tunnels can encapsulate other protocols than IPv6.

Let’s configure a manual tunnel using the network scenario below. Between the CE routers and the PE routers, only IPv6 will be enabled. Between the PEs, only IPv4 will be enabled. Therefore, the CEs are IPv6-only nodes while the PEs are IPv4/IPv6 nodes or dual stack devices.

The base configuration (without the tunnel) on the PE routers is as follows:

PE1

ipv6 unicast-routing
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:DB8:1:A000::1/64
!
interface FastEthernet0/1
 ip address 192.168.10.1 255.255.255.252
!

PE2

ipv6 unicast-routing
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:DB8:1:B000::2/64
!
interface FastEthernet0/1
 ip address 192.168.10.2 255.255.255.252
!

As can be seen from the configuration above, I have enabled IPv6 routing on the PEs; enabled IPv6 on the interfaces connected to the CEs (Fa0/0); and enabled IPv4 on the interfaces connecting the PEs together (Fa0/1). Keep in mind that, in our scenario, the tunnel endpoints (the PEs) are connected together but, in reality, they could be in two different geographical locations as long as they have IPv4 connectivity.

The configuration on the CE routers is as follows:

CE1

interface FastEthernet0/0
 no ip address
 ipv6 address 2001:DB8:1:A000::10/64
!
ipv6 route ::/0 FastEthernet0/0 2001:DB8:1:A000::1

CE2

interface FastEthernet0/0
 no ip address
 ipv6 address 2001:DB8:1:B000::20/64
!
ipv6 route ::/0 FastEthernet0/0 2001:DB8:1:B000::2

I have not enabled IPv6 routing on the CEs, so they are acting like IPv6 hosts. Also, I have configured a default route on both CEs to their respective PE routers.

To configure the tunnel between our PE routers (running Cisco IOS), we need to specify at least four elements: the tunnel’s IPv6 address, the tunnel source, the tunnel destination and the tunnel mode. The tunnel source and destination addresses are IPv4 addresses. For configured tunnels in Cisco, the tunnel mode is ipv6ip.

PE1

interface Tunnel1
 no ip address
 ipv6 address 2001:DB8:1:AB00::1/64
 tunnel source FastEthernet0/1
 tunnel destination 192.168.10.2
 tunnel mode ipv6ip
!

PE2

interface Tunnel1
 no ip address
 ipv6 address 2001:DB8:1:AB00::2/64
 tunnel source FastEthernet0/1
 tunnel destination 192.168.10.1
 tunnel mode ipv6ip
!

It only makes sense that the tunnel will have an IPv6 address because you won’t be able to route the IPv6 traffic using IPv4 routing protocols (or IPv4 static routes). In our case, I will use static routes on the PE routers to route traffic between the two IPv6 domains. Therefore, I will add a static route on PE1 for 2001:db8:1:b000::/48 pointing to its tunnel interface and also a static route on PE2 for 2001:db8:1:a000::/48 pointing to its tunnel interface.

Hint: You can also run a dynamic routing protocol such as EIGRPv6 on the tunnel.

Now, I will ping CE2 from CE1. The traffic will flow from CE1 to its default gateway (PE1), then through the tunnel to PE2, which will then forward it to CE2. At the same time, I will capture traffic on PE2’s fa0/1 interface.

Let’s take a look at one of the captured packets:

Can you see the encapsulation? Focusing on the IP layer and above, we have ICMPv6 encapsulated by an IPv6 header, which is in turn encapsulated by an IPv4 header. The IPv4 header is shown in detail below:

First, notice that the header length is 20 bytes, meaning that there are no options in this IPv4 header. Also of note is the protocol field, which has a value of 41, meaning that IPv6 is encapsulated. When PE2 receives the packet through the tunnel and sees that the protocol field is 41, it knows that the packet is carrying IPv6 traffic. According to the RFC, the decapsulator (PE2 in this case) must first verify that the tunnel source address is correct before processing the packet further. This prevents against address spoofing attacks. If the address is correct, PE2 will reassemble the packet (if fragmented), remove the IPv4 header and then process the embedded IPv6 packet.

Summary

As we have seen, configured tunnels are quite simple to configure but, due to the fact that we have to set up its parameters, it may not be a flexible solution. However, because of its stability, it is useful for regular connection between IPv6 domains.

In the next article, we will consider automatic IPv4-compatible IPv6 tunnels. I hope you have found this article insightful.

References and Further Reading

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