In the last article, we discussed the now deprecated IPv4-compatible IPv6 tunnels. We said that one of the limitations of that type of tunnels is the fact that it does not support communication with the native IPv6 internet. Therefore, nodes that want to communicate using IPv4-compatible IPv6 tunnels must both support that automatic tunneling mechanism.

In this article, we will be talking about a more useful tunneling mechanism that is widely deployed in end systems. This is the 6to4 tunneling mechanism.

CCNA Training – Resources (Intense)

6to4 tunnels are similar to IPv4-compatible IPv6 tunnels in the way that they both provide automatic tunneling unlike the manual tunnels that we looked at in the first article. The use case is also to allow IPv6 domains connected to a wide area network (with no native IPv6 support) to communicate with each other. This communication can be between border routers or between a border router and a host. There are basically two types of 6to4 which we will describe briefly:

Router 6to4

This was the initial definition described in RFC 3056. The concept is similar to other tunneling types that we have considered before in that IPv6 traffic is encapsulated inside IPv4 packets (protocol 41 encapsulation). One basic difference is the IPv6 prefix that is used for 6to4 – 2002::/16. This is the prefix block that has been assigned for 6to4 services by IANA.

By taking the 6to4 border router’s public IPv4 address and concatenating it to the 2002::/16 prefix, a 6to4 /48 prefix can be generated for use within the site (i.e. 2002::<public_IP>::/48). The concept can also be extended to individual hosts or small sites which have global IPv4 addresses.

The router 6to4 specification also defines a 6to4 relay router which facilitates communication between 6to4 sites and the native IPv6 Internet. Therefore these relay routers have both 6to4 addresses and native IPv6 addresses. We will take examples later in this article to further explain these concepts.

Anycast 6to4

Anycast 6to4 documented in RFC 3068 is an extension of router 6to4 created to ease the burden of small sites (or hosts) to find a relay router to use for communicating with the native IPv6 internet. Anycast 6to4 proposes a solution in which public relay routers will share the same IPv4 address, 192.88.99.1, which corresponds to 2002:c058:6301::. By using this 6to4 relay Anycast address, 6to4 nodes can route all their IPv6 traffic (except traffic to 6to4 addresses) to the closest relay. Also, these public relay routers will advertise the 2002::/16 prefix to the native IPv6 Internet; therefore, traffic from the native IPv6 Internet to a system using a 6to4 address will be sent to the closest relay router which will then forward the traffic on to the 6to4 system.

It is good to note that even though 6to4 has been widely deployed on end systems and routers, it has some issues especially relating to the use of public relays and connection failures. You can refer to this informational RFC for the issues and advice regarding 6to4 deployment.

6to4 example

Let’s take a configuration example. The network scenario is similar to what we used in the previous article but the IPv6 addresses are different for a reason.

Notice that the IPv6 addresses used in each site is from the 2002::/16 prefix. These addresses are not derived randomly. Let me explain how they came about. The tunnel we want to build is between CE1 and CE2 using their public facing interfaces (i.e. Fa0/1). Focusing on CE1 as an example, the IP address of its Fa0/1 interface is 41.1.1.2.

To derive the 6to4 prefix to be used on CE1’s site, we will take this public IP address and add it to the 2002::/16 prefix. 41.1.1.2 in hexadecimal is “2901 0102”; therefore, the 6to4 prefix will be 2002:2901:0102::/48. This is the prefix that will be used in CE1’s site. As you can see, 2002:2901:0102:100::/64 is a smaller prefix block taken from that 6to4 site prefix block. In the same way, 2002:2902:0202::/48 is the prefix that will be used in CE2’s site and 2002:2902:0202:200::/64 is from that 6to4 site prefix block.

To configure our 6to4 tunnels, we need to set the tunnel mode (ipv6ip 6to4), specify the tunnel source and also configure the 6to4 IPv6 address for that tunnel. As with IPv4-compatible IPv6 tunnels, we will not specify a tunnel destination; the tunnel destination will be derived from the IPv4 embedded in the destination IPv6 address. Thus, 6to4 is a point-to-multipoint tunnel type which treats the underlying IPv4 infrastructure as a Non-Broadcast Multi-Access (NBMA) network.

The configuration on the CE routers is as shown below. The configuration on the ISP router remains unchanged from the previous article:

CE1

interface Tunnel1
 no ip address
 ipv6 address 2002:2901:0102::1/64
 tunnel source FastEthernet0/1
 tunnel mode ipv6ip 6to4
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2002:2901:102:100::1/64
!
interface FastEthernet0/1
 ip address 41.1.1.2 255.255.255.252
!

CE2

interface Tunnel1
 no ip address
 ipv6 address 2002:2902:0202::2/64
 tunnel source FastEthernet0/1
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 no ip address
 ipv6 address 2002:2902:202:200::2/64
!
interface FastEthernet0/1
 ip address 41.2.2.2 255.255.255.252
!

When we configured IPv4-compatible IPv6 tunnels, a ::/96 route was automatically added to the IPv6 routing table going through the tunnel interface. However, for 6to4 tunnels, we need to manually add a static route for the 2002::/16 prefix so that all 6to4 traffic goes through the tunnel.

Therefore, on both CE routers, I will add the following command:

ipv6 route 2002::/16 tunnel1

Now we should have connectivity. The first thing I will check is that the tunnel endpoints are reachable from each other.

CE1 was able to determine the IPv4 tunnel destination address by looking at the “2902:0202” part of that address and thus sending the packet to 41.2.2.2. Now let’s test end-to-end connectivity. I have a host connected behind CE1; I will ping the loopback interface of CE2 from that host.

Let’s briefly talk about the traffic flow. The host sent the traffic to its default gateway which is CE1. CE1 receives the traffic and checks the destination address from its routing table. The closest match for that destination is the static route for 2002::/16 out through the tunnel.

As CE1 decides to route the traffic through the tunnel, it encapsulates it in an IPv4 header, setting the protocol field to 41. The tunnel source is IPv4 address of the tunnel source (Fa0/1) that we configured. The tunnel destination is derived from the “2902:0202” part of the destination address and thus CE1 sends the packet to 41.2.2.2.

Upon receiving the packet, CE2 strips the IPv4 header and forwards the IPv6 traffic on to its destination.

As with IPv4-compatible IPv6 tunnels, we cannot run routing protocols like EIGRPv6 and OSPFv3 over 6to4 tunnels for the same reason given in the previous article. However, BGP can be used the way we did in the previous article.

Summary

In this article, we have discussed and configured 6to4 tunnels which not only allows communication between isolated IPv6 domains, but also supports communication with the native IPv6 Internet through the use of relay routers. In the next article, we will consider an example of how relay routers are used.

6to4 tunnels also have several limitations regarding the way they have been implemented and so, other tunneling mechanisms like 6rd are being recommended. However, 6to4 has been widely deployed and so there are guidelines for the effective deployment of such a solution.

I hope you have found this article useful and I look forward to the next article in this series.

References and further reading

  1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds: http://tools.ietf.org/html/rfc3056
  2. RFC 3068: An Anycast Prefix for 6to4 Relay Routers: http://tools.ietf.org/html/rfc3068
  3. RFC 6343: Advisory Guidelines for 6to4 Deployment: http://tools.ietf.org/html/rfc6343
  4. RFC 2893: Transition Mechanisms for IPv6 Hosts and Routers: http://tools.ietf.org/html/rfc2893
  5. RFC 7059: A Comparison of IPv6-over-IPv4 Tunnel Mechanisms: http://tools.ietf.org/html/rfc7059