Looking for info about migrating IPv4 to IPv6, I found a new tunneling technique I didn’t know about. And with the impending IPocalypse coming, I thought about sharing this info with all of you.
This technique is used to communicate IPv6 islands through an IPv4 core, by using encapsulation of IPv6 in IPv4. It’s very similar to the tunneling technique Automatic 6to4, with two big differences:
- 6RD does not require addresses to have a 2002::/16 prefix; therefore, the prefix can be from the SP’s own address block. This function allows the 6RD operational domain to be within the SP network. Here we get a very interesting point, from the perspective of customer sites and the general IPv6 Internet connected to a 6RD-enabled SP network, the IPv6 service provided is equivalent to native IPv6.
- All 32 bits of the IPv4 destination need not be carried in the IPv6 payload header. The IPv4 destination is obtained from a combination of bits in the payload header and information on the router. Furthermore, the IPv4 address is not at a fixed location in the IPv6 header as it is in 6to4. But before getting in the 6RD technique, let’s remember how Automatic 6to4 tunneling works.
In Automatic 6to4 tunnels, the tunnels determine the appropriate destination address by combining the IPv6 prefix with the globally unique destination 6to4 border router’s IPv4 address, beginning with the 2002::/16 prefix, in this format:
This prefix-generation method leaves another 16 bits in the 64-bit prefix for numbering networks within a given site. And all interface addresses within the border-router must start with this same 2002:border-router-IPv4-address prefix in order to be able to communicate through the Automatic 6to4 tunnel.
In addition to the basic tunnel configuration, the extra step of providing for routing the desired packets over the tunnel is also required. This is usually done using a static route. For example, to route packets destined for prefix 2002::/16 over the tunnel0 6to4 tunnel interface, this static route is configured:
ipv6 route 2002::/16 tunnel 0
With 6RD, ISPs may use their own assigned prefix instead of using 2002 for building the tunnel. So the tunnel address doesn’t start with 2002, but with the prefix that the RIR assigned to the ISP.
The new address structure is:
And even more, 6RD gives the possibility of collapsing the bits of the border-router-IPv4-address field. Let’s imagine that the ISP uses the range 10.0.0.0/8 for addressing all their router loopbacks. So, if the destination of the tunnel is a router on the same domain, the first octet in the IPv4 address doesn’t add any extra info. In this case, 6RD gives the possibility of collapsing this first octet, and adding to the tunnel address only the three last octets of the IPv4 address. Let’s see an example:
So the tunnel would work on this way. If the destination prefix doesn’t match the local ISP prefix, the router understands the destination is out of the 6RD domain, so it will encapsulate the IPv6 in IPv4 using the address on the border-router-IPv4-address field. On the other hand, if the destination prefix does match the local ISP prefix, the router knows that the destination is in the same 6RD domain, so it adds to the border-router-IPv4-address prefix the collapsed info in order to know the IPv4 destination – in our case, it adds 10.
Cisco implements 6RD on release 15.1(3)T
To configure 6RD tunnels on Cisco, these are the steps:
1. interface tunnel 2. ipv6 address 3. tunnel mode ipv6ip 6rd 4. tunnel 6rd prefix 5. tunnel 6rd ipv4 prefix-length suffix-length
Let’s see an example. In this case, the prefix assigned to the ISP by RIPE is 3001:BC00::/32, and the collapsed info are 16 bits of the tunnel source IPv4 address:
interface Tunnel1 ipv6 address 3001:BC00:100::1/32 tunnel source Ethernet2/1 tunnel mode ipv6ip 6rd tunnel 6rd prefix 3001:BC00::/32 tunnel 6rd ipv4 prefix-len 16 suffix-len 8 end
I haven’t been able to test it yet, but I’m looking forward to it. ¿Any of you can comment on your experience with this?
The IPv6 Rapid Deployment – 6RD by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.