Before continuing with this article, please read Part 1 if you have not done so already as we have already discussed the underlying concepts of 6rd there. What we will be doing here in Part 2 is the configuration of 6rd on Cisco routers using the network diagram below:
As you can see, I have retained the example we used throughout the last article. I have configured basic configuration on all the routers and they all have IPv4 connectivity as shown below:
Now, let’s get on with the 6rd tunnel configuration. Since I would be configuring the 6rd parameters manually, I don’t have to do anything on the 6RD_ISP router. The configuration on the CE routers is as follows:
interface Tunnel1 no ip address tunnel source FastEthernet1/0 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 8 tunnel 6rd prefix 2001:DB8::/32 tunnel 6rd br 10.3.3.2
Let me explain each element of the configuration above: the tunnel source is Fa1/0, which is the interface that connects the CEs to the ISP router. For example, 6RD_CE1’s Fa1/0 has an IP address of 10.1.1.2. We use the tunnel mode ipv6ip 6rd command to specify 6rd as the tunneling type. Like I mentioned in the last article, Cisco began supporting this command from IOS version 15.1(3)T. The tunnel 6rd ipv4 prefix-len command is used to specify the IPv4 mask length, i.e. the number of bits that are common in the IPv4 addresses of all CEs and BRs in the 6rd domain.
CCNA Training – Resources (Intense)
In Cisco terms, the IPv4 address bits that are common in the 6rd domain are known as IPv4 common prefix. In our case, I want to keep things simple and I have used 8 bits to match the first “10” decimal places in all our IPv4 addresses even though those addresses have 14 bits in common. The tunnel 6rd prefix is used to specify the 6rd prefix along with its length. Finally, the tunnel 6rd br command specifies the IPv4 address of the 6rd border relay router.
Note: Cisco also supports the IPv4 common suffix which is a common tail portion of the IPv4 addresses of all CE and BR routers in the 6rd domain. If we were to use it in our own example, the IPv4 common suffix will be “2” because all the IPv4 addresses of our CE and BR routers end with 2. Therefore, the IPv4 common suffix length will be 8 bits. You can specify the IPv4 common suffix length using the tunnel 6rd ipv4 suffix-len command.
At this point, our CE routers have enough information to calculate their 6rd delegated prefixes which they would use in their individual site. Now, instead of an administrator manually calculating the 6rd delegated prefix, Cisco provides a way to use the 6rd delegated prefix calculated by the router in our IPv6 address assignment. This is through the use of general prefixes. Rather than specifying the general prefix, we will use the keyword 6rd followed by the interface name. For example, I can add the following configuration on my CE routers:
ipv6 general-prefix DELEGATED_PREF 6rd Tunnel1
Having specified this, I can now use the general prefix name for IPv6 address assignment as follows:
interface lo0 ipv6 address DELEGATED_PREF 0:0:0:0010::1/64
Hint: The 6rd delegated prefix is 56 bits long, meaning I have 8 bits to use for the subnet. In this case, I have used “00010000” as the subnet ID which is equivalent to “10” in hexadecimal.
Therefore, if I check the IPv6 address assigned to my loopback interface, I will see that the router has used the 6rd delegated prefix.
You will notice that the above confirms the 6rd delegated prefix we calculated in our last article (the leading zeroes in individual fields have been removed, e.g. 0101 became 101). We can also check the delegated prefix by using the show tunnel 6rd command.
The configuration on the BR router is similar to the configuration for the CE routers; the difference is that we don’t need to specify a BR IPv4 address (since the BR router should have native IPv6 connectivity).
interface Tunnel1 no ip address tunnel source FastEthernet1/0 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 8 tunnel 6rd prefix 2001:DB8::/32
There are still a few other configurations to make on our CE and BR routers. The first thing we need to do is create a static route for the 6rd prefix (not the 6rd delegated prefix) going through the tunnel. We did something similar in our 6to4 configuration when we created a static route for 2002::/16.
ipv6 route 2001:db8::/32 tunnel 1
The other thing we need to do only on the CE routers is to create a default route pointing to the BR router. This default route will be used for all communication outside the 6rd domain.
ipv6 route ::/0 2001:DB8:303:200::
How did I know the 6rd address of the BR router? You can use the show tunnel 6rd command on the BR router like we did above or you can use the show tunnel 6rd prefix command to determine the 6rd delegated prefix for a particular destination. For example, from CE1, I can determine the 6rd delegated prefix for the BR router as shown below:
I don’t need to concern myself with the interface ID part of the next-hop address (the BR) because that static route contains enough information to allow the CE to retrieve the relevant IPv4 address to use to encapsulate the IPv6 traffic in IPv4.
There is one last thing we failed to do which I will now highlight. Let’s check our IPv6 routing table:
As you can see, only the LAN side (lo0) of our CE router is showing up in our IPv6 routing table; there is no route for our tunnel interface. In fact, if we run the show ipv6 interface tu1 command, no information will be displayed:
This is happening because even though we have configured the tunnel for 6rd, we have not enabled IPv6 on the tunnel. There is no IPv6 address on that tunnel interface, and neither have we entered the ipv6 enable command. One way we can go about this is to add the ipv6 enable command under all our tunnel interfaces.
Another way is to configure the tunnel interfaces with the IPv6 Subnet-Router anycast address for the 6rd delegated prefix.
The added benefit of this second method is that the tunnel interfaces will now be reachable via that Subnet-Router anycast router, which may be helpful for debugging (like ping).
Cool! Let’s now test and look into tunnel endpoint determination. We explained the process in the previous article but here, we will see the packets with Wireshark. Let me ping CE2’s LAN interface from CE1’s LAN interface.
As you can see, the ping was successful. If we look into one of the ping packets with Wireshark, you will see that the tunnel destination has been determined to be 10.2.2.2. Notice also that 6rd performs Protocol 41 encapsulation like the others.
Now, what if I want to ping an IPv6 address external to the 6rd domain? For example, if I ping the IPv6 network connected to the BR router (i.e. 2001:c034:adbf::/64), it goes through:
If we look at the Wireshark capture, you will notice that the tunnel destination is now the 6rd BR router.
Great! We have now come to the end of our 6rd configuration.
IPv6 rapid deployment is a very neat way to provide IPv6 services over an IPv4 infrastructure. By using a prefix block from the SP’s assigned prefix, 6rd customers are not immediately distinguishable from other native IPv6 hosts. 6rd overcomes the challenges of 6to4 because the border relay routers (known as relay routers in 6to4) are solely controlled by the SP.
I hope you have found this article useful and I look forward to the next article in the series.
References and further reading
RFC 5969: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification: http://tools.ietf.org/html/rfc5969
RFC 7059: A Comparison of IPv6-over-IPv4 Tunnel Mechanisms: http://tools.ietf.org/html/rfc7059
IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-665758.html
IP Version 6 Addressing Architecture: Required Anycast Address: http://tools.ietf.org/html/rfc4291#section-2.6.1