IPv6 Tunnelling

The Internet is going through its most fundamental change since its inception almost half a century ago. We are currently living through the fundamental transition of the Internet from IPv4 to IPv6.

There are several reasons for this change, the most prominent of which is that Regional Internet Registries (RIRs) have exhausted or are on the verge of exhausting their IPv4 pool of subnets.  

IPv6 was officially defined and published in RFC 2460 in late 1998. World IPv6 Launch Day was declared on June 6, 2012; however, according to Google, world IPv6 adoption is still around 40% as of the date of this writing.

As you can see, the transition is literally taking decades for reasons that we will not go into here. What this means is that IPv4 is still around and is expected to be around for a long time yet. It is estimated that IPv4 will still have a substantial presence on the worldwide Internet well into the early 2030s.

Practically speaking, the current situation means that we must develop robust and mature mechanisms on our networks to accommodate the simultaneous operation of both IPv4 and IPv6. One such mechanism is IPv6 tunnelling, a feature that allows IPv6 packets to be encapsulated within IPv4 packets. In its most fundamental form, this essentially allows you to tunnel IPv6 traffic between two IPv6 networks over IPv4 infrastructure. There are various methods of achieving this, some with confusingly similar names, which we will cover here. We will also examine how to employ IPv6 tunnelling in a specific simple scenario.

{{banner-13="/design/banners"}}

Summary of key concepts

IPv6 tunnelling is a vital tool in the arsenal of methods used to enable the transition process from IPv4 to IPv6. Some of the most important concepts involved with IPv6 tunnelling are described in the table below and will be examined in detail in this article.

IPv6 tunnelling, explained

In the following sections, we will explore IPv6 tunnelling in depth to understand what it is, how it works, and how it can be implemented.

IPv6 transition mechanisms

Different regions of the Internet are transitioning to IPv6 at different times and different rates. This means that, for some time, there has been a need for the coexistence of IPv4 and IPv6, and this situation will continue. 

How does IPv6 tunnelling help achieve this coexistence? Imagine you have an enterprise network for which you have purchased a range of public IPv6 addresses.

You use those IP addresses for the internal hosts of your network, both user devices and network services. However, the physical location of your enterprise does not have any ISPs that offer IPv6 infrastructure: The Internet in your area only supports IPv4. What do you do?

You implement IPv6 tunnelling, as shown in the diagram. In the above scenario, the enterprise edge router is one IPv6 tunnelling endpoint, where IPv6 packets are encapsulated into IPv4 packets, sent over the IPv4-only Internet, and received by another router that acts as the other endpoint of the tunnel. Once they reach that endpoint, the packets are decapsulated and sent on their way within the IPv6 infrastructure.

Routers that play the role of tunnelling endpoints are also called dual-stack routers because they support both the IPv4 and IPv6 protocol stacks.

IPv6 Encapsulation into IPv4

An IPv6 packet is composed of a header and a payload. The header contains the source and destination IPv6 addresses as well as additional information that pertains to security, routing, quality of service, and other features specific to IPv6. When such a packet reaches a dual-stack router for encapsulation, an IPv4 header is added to the IPv6 packet. The IPv6 packet essentially becomes the payload of the IPv4 packet. The following diagram depicts this encapsulation:

The IPv4 header contains the source and destination IPv4 addresses that correspond to the two tunnelling endpoints, while the IPv6 header contains the source and destination IPv6 addresses of the actual hosts communicating with each other.

{{banner-9="/design/banners"}}

Types of IPv6 tunnelling

So far, we’ve described the fundamental concepts behind IPv6 tunnelling. Now let’s look at the various “flavors” of IPv6 tunnelling that can be implemented, depending on the needs of a particular network. Some of the most common tunnelling techniques include the following.

Be careful with the naming conventions of these methodologies. Note, in particular, the difference between terms such as 6to4 and 6in4. There is even a method called 6over4, which we won’t go into here. We mention it simply to emphasize the fact that the terms can quickly become confused if one is not cautious.

Manually configured tunnels

This technique allows you to statically create an IPv4 tunnel that can carry IPv6 traffic. There are two types:

• The first type, often called 6in4, is a manually created tunnel as described in RFC 4213 that defines how to encapsulate IPv6 into IPv4 packets.
• The second type is Generic Routing Encapsulation (GRE) tunnelling, which is a tunnelling method that rides on top of IPv4 and is not used exclusively for IPv6. It can be used to tunnel many different protocols.

Dynamic multipoint IPv6 tunnelling

This is a method where IPv6 packets can be transmitted over an IPv4 network without the need to configure explicit tunnels. The word “dynamic” in the name simply means that tunnels are dynamically created, and IPv4 endpoint addresses are dynamically determined. There are two flavors of this method:

• Automatic 6to4 tunnelling is a method that determines the IPv4 address of the endpoint from the IPv6 address. It uses the specific IPv6 prefix 2002::/16 for this purpose.
• Intra-site automatic tunnel addressing protocol (ISATAP) defined in RFC 5214 is a similar method but employs a server-client model where an ISATAP server router dynamically creates tunnels to one or more client routers.

IPv6 Rapid Deployment (RD) — an improvement over 6to4

6RD, defined in RFC 5569, is a stateless mechanism that dynamically creates IPv6 tunnels over the IPv4 infrastructure of an ISP. It is similar to 6to4, and actually improves upon it in some ways:

• It is stateless, which means that there is no device keeping track of specific prefixes that have been encapsulated. 
• Encapsulation is achieved “on the fly” whenever an IPv6 packet is received by the configured router. Once encapsulated, it is sent over the IPv4 network to a border router, which does the decapsulation and forwarding to the IPv6 network.
• It is not limited to using a specific IPv6 prefix but can use the native IPv6 addresses of each subscriber.
• IPv6 RD is typically employed within the network of an IPv4-only ISP that seeks to accommodate customers with IPv6 address spaces.

Implementation examples

In the following sections, we’ll show you how to implement manual 6in4 tunnels as well as automatic 6to4 tunnelling on Cisco routers.

Manual 6in4 IPv6 tunnelling configuration

For our first configuration, let’s consider the following network topology:

R1 and R3 are our dual-stack routers that have IPv6 addresses on their L0 loopback interfaces. R1 and R3 are also connected to an IPv4 infrastructure via R2. We want to create a manual 6in4 IPv6 tunnel so that the loopbacks can communicate with each other. R1 and R3 also have L1 loopback interfaces that will be used to terminate the tunnel.

Assume the above IPv4 and IPv6 addressing has already been configured in all routers and that routing between all IPv4 addresses has been established using a dynamic routing protocol such as EIGRP.

Let’s start by creating the tunnel on R1 and R3 that terminates on the L1 interfaces:

R1(config)#interface tunnel 0
R1(config-if)#tunnel source loopback 1
R1(config-if)#tunnel destination 3.3.3.3
R1(config-if)#tunnel mode ipv6ip

R3(config)#interface tunnel 0
R3(config-if)#tunnel source loopback 1
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#tunnel mode ipv6ip

Now, those who have configured tunnels on Cisco devices will probably be thinking that this is just like a regular GRE tunnel configuration, and they would be correct. However, there is one specific command that you wouldn’t find in a regular GRE tunnel, and that is the tunnel mode ipv6ip command. This is the command that activates the RFC-defined 6in4 IPv6 tunnel.

Let’s take a look at our tunnel from both R1 and R3 using the show interfaces tunnel 0 command:

R1#show interfaces tunnel 0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 1.1.1.1 (Loopback1), destination 3.3.3.3
  Tunnel protocol/transport IPv6/IP

R3#show interfaces tunnel 0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 3.3.3.3 (Loopback1), destination 1.1.1.1
  Tunnel protocol/transport IPv6/IP

Note on the last line that the Tunnel protocol/transport is defined as IPv6/IP, which is what we want.

Our tunnel is now complete, but our IPv6 loopbacks cannot yet communicate. We must configure IPv6 routing, so they can reach each other over the tunnel infrastructure. To do so, let’s enable the routing protocol RIPng on R1 and R3. Here’s the config for these routers:

R1(config)#ipv6 unicast-routing
R1(config)#ipv6 router rip RIPNG
R1(config-rtr)#exit
R1(config)#interface loopback 0
R1(config-if)#ipv6 rip RIPNG enable 
R1(config-if)#exit
R1(config)#interface tunnel 0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 rip RIPNG enable

R3(config)#ipv6 unicast-routing 
R3(config)#ipv6 router rip RIPNG
R3(config-rtr)#exit
R3(config)#interface loopback 0
R3(config-if)#ipv6 rip RIPNG enable
R3(config-if)#exit
R3(config)#interface tunnel 0
R3(config-if)#ipv6 enable 
R3(config-if)#ipv6 rip RIPNG enable

The commands above enable IPv6 routing and advertise the IPv6 addresses that appear on the Loopback 0 interfaces. Let’s take a look at the routing tables of R1 and R3:

R1#show ipv6 route rip           
IPv6 Routing Table - 4 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   2001::3/128 [120/2]
     via FE80::303:303, Tunnel0

R3#show ipv6 route rip  
IPv6 Routing Table - 4 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   2001::1/128 [120/2]
     via FE80::101:101, Tunnel0

Notice that the IPv6 network of the other router is found in the local routing table via RIP. Also note that the exit interface for that particular prefix is the Tunnel0 interface.

We’re all set! Now let’s test our IPv6 connectivity using a ping. We have to make sure that the source of the ping is Loopback 0, which has an IPv6 address:

R1#ping 2001::3 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

IPv6 traffic is now traversing the manually created 6in4 IPv6 tunnel.

Automatic 6to4 tunnelling configuration

For this configuration, we’ll use the same topology as before, but this time we won’t be using loopbacks to terminate the IPv4 tunnel:

Once again, we assume that IPv4 routing has been established between all routers.

The advantage of this method is that when creating the tunnel, we don’t need to know the tunnel destination on R1 or R3; it is created dynamically from the IPv6 address you will use. Here’s the configuration of the tunnel interfaces on R1 and R3:

R1(config)#interface tunnel 0
R1(config-if)#ipv6 address 2002:C0A8:C01::1/64
R1(config-if)#tunnel source fastEthernet 0/0
R1(config-if)#tunnel mode ipv6ip 6to4

R3(config)#interface tunnel 0
R3(config-if)#ipv6 address 2002:C0A8:1703::3/64
R3(config-if)#tunnel source fastEthernet 0/0
R3(config-if)#tunnel mode ipv6ip 6to4

Here we’re using IPv6 addresses on the tunnels, but we’re not specifying the destination, which is inferred from the IPv6 address used. How is this done? All 6to4 addresses have the following format:

The prefix is always 2002: and is reserved on the Internet for use with 6to4 IPv6 tunnelling. The next 32 bits in hexadecimal are equivalent to the IPv4 address. If you check it out, you will see that the C0A8:1703 in hexadecimal is equivalent to 192.168.23.3. Similarly, C0A8:C01 is equivalent to 192.168.12.1.

Another key thing to note here is the tunnel mode being used. It’s ipv6ip with the 6to4 keyword, which tells the router to determine the tunnel endpoint IPv4 address from the IPv6 address.

There’s one last thing to do here: We must enable routing so that the two loopback 0 interfaces can communicate. Note that, unlike the manual tunnels, the automatic 6to4 tunnel will only support static routing or BGP, so let’s configure some static routes:

R1(config)#ipv6 route 2001::3/128 2002:C0A8:1703::3  
R1(config)#ipv6 route 2002::/16 tunnel 0

R3(config)#ipv6 route 2001::1/128 2002:C0A8:C01::1  
R3(config)#ipv6 route 2002::/16 tunnel 0

Now communication is enabled between the loopback interfaces:

R1#ping 2001::3 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Wireshark capture

So what does IPv6 tunnelling look like?  Well, take a look at this Wireshark capture of an IPv6 packet tunnelled within an IPv4 packet.  The addresses are different from the above examples, but it clarifies the concept quite well.  

Notice the 6to4 gateway information found within the IPv6 header. You can further explore this particular pcap capture file using your own Wireshark application to gain more insight into the operation of this feature.

{{banner-10="/design/banners"}}

Considerations for success

IPv6 tunnelling must be applied carefully. As with many such mechanisms, it is important to keep in mind the various limitations of a technique as well as the best practices involved in their implementation. The following are some considerations to keep in mind when designing IPv6 tunnels.

Tunnelling location

It is not always clear what device performs the encapsulation and decapsulation. Depending on the topology and the entities involved, tunnelling may take place completely within an ISP’s network, or the enterprise may participate in the process. You may even want to implement IPv6 tunnelling completely within your organization’s enterprise network: This can be especially useful when migrating a large network from IPv4 to IPv6.

Even if local ISPs don’t offer any tunnelling services, it is possible to use a tunnel broker to create an IPv6 tunnel that will not only carry IPv6 traffic but also be able to advertise IPv6 networks on the Internet using the BGP routing protocol.

Overhead

As with all kinds of tunnelling, IPv6 tunnelling also adds some overhead to the performance of the underlying network. This overhead is in the form of the additional IPv4 header on each and every IPv6 packet. Overhead also comes in the form of CPU and memory usage on the devices performing the tunnelling. Manual tunnels require the least such overhead because their prefixes are hard wired, while automatic and dynamic tunnelling mechanisms use up more memory and CPU cycles to successfully operate. If you want to implement security features, which we’ll talk about in a moment, they add even more overhead. 

This is not to say that the feature becomes prohibitively resource-intensive, but it should be taken into consideration. We suggest that the load on CPU, RAM, and network bandwidth of affected devices be monitored before and after implementation to assess the impact of IPv6 tunnelling on these resources.

Security

As with all tunnels, security features such as encryption can easily be added to ensure the confidentiality of communication. IPSec can be applied to those encapsulation techniques that leverage GRE. 

That said, while security is paramount in general, in this case it is not so vital because IPv6 itself has integrated security features that allow payloads to be secured. Unless an organization seeks to secure the encapsulation process itself, and hide the fact that the IPv4 packets are carrying IPv6 packets, encryption on IPv6 tunnels is generally unnecessary.

Interaction with other network features

When implementing IPv6 tunnelling, you must take other network features into account as well, such as DNS, routing, and multicast. Knowing how these features interact with the particular IPv6 tunnel that you implement is important for ensuring that the network operates correctly. For example, automatic 6to4 does not support IGPs, only static and BGP routing.

{{banner-sre="/design/banners"}}

Conclusion

As we have seen, IPv6 tunnelling is used to transport IPv6 packets over IPv4 infrastructure. There are various methods of employing IPv6 tunnelling that are suitable for different situations and requirements. Some are manually configured, others dynamically create the necessary tunnels, while still others function in a stateless manner, delivering even more flexibility of implementation.

We have also seen some of the limitations and issues involved in IPv6 tunnelling and how they should be considered ahead of implementation.

Nonetheless, IPv6 tunnelling is of vital importance for today’s Internet. As the transition to IPv6 is an ongoing process that will take years, and possibly more than a decade, these features are increasingly implemented on the Internet as well as on enterprise networks.

‍