According to most in the “know” regarding IPv6, IPv4 is NOT going away in our lifetime. Pockets of the current protocol for networking will continue to exist for the foreseeable future; they might just get smaller and smaller, and more dispersed. Why is this? It is because of the rich transition mechanisms that exist to allow IPv4 and IPv6 to co-exist.
In this post, we are going to cover one of the IPv4 to IPv6 transition mechanisms that we ran out of time for when we conducted an evening session of our CCIE R&S Lab Fundamentals Bootcamp course here at IPexpert. This feature is termed a Manual Configured Tunnels (MCT). It is a statically defined, point-to-point type of method for connected two network areas of IPv6 that might be separated by IPv4-only network devices.
One of the beauties of this Manually Configured Tunnel (MCT) is that they are supported by most of the stacks and routers that you might run into within production networks today. This transition mechanism is specified in RFC 4213. This RFC specifies the methodology for manually configured IPv6-over-IPv4 tunnels for transporting IPv6 packets over an existing IPv4 network.
If you are a fan of history, this simple and direct approach is one of the first transition mechanisms developed with the intent of ensuring that IPv6 packets can be successfully transported through IPv4 only network devices. Manually Configured Tunnels use protocol 41(IPv6) to encapsulate the traffic, and the tunnel encapsulation is determined from the static configuration information present on the tunneling node. The tunneling node can actually be a dual-stack router or host. For MCTs, additional information such as the packets of interests are found out based on the configuration/routing table in the node.
In the Cisco world, you might consider MCTs for stable connections that might require regular communication between two edge routers. In order to create the tunnel, you assign an IPv6 address to the tunnel, and you use the existing IPv4 addresses on your edge dual-stack devices for tunnel source and destination.
Here is an example configuration on two dual-stack Cisco routers. Notice the use of RIPng to enable dynamic routing information to pass through the “sea” of IPv4-only devices:
ROUTERA
ROUTERA(config)# ipv6 unicast-routing
ROUTERA(config)# interface loopback 0
ROUTERA(config-if)# ipv6 rip ROUTERARIPNG enable
ROUTERA(config-if)# exit
ROUTERA(config)# interface tunnel 0
ROUTERA(config-if)# ipv6 address 2001:13::1/64
ROUTERA(config-if)# tunnel source fastethernet0/0
ROUTERA(config-if)# tunnel destination 10.20.20.3
ROUTERA(config-if)# tunnel mode ipv6ip
ROUTERA(config-if)# ipv6 rip ROUTERARIPNG enable
ROUTERA(config-if)# end
ROUTERB
ROUTERB(config)# ipv6 unicast-routing
ROUTERB(config)# interface loopback 0
ROUTERB(config-if)# ipv6 rip ROUTERBRIPNG enable
ROUTERB(config-if)# exit
ROUTERB(config)# interface tunnel 0
ROUTERB(config-if)# ipv6 address 2001:13::3/64
ROUTERB(config-if)# tunnel source fastethernet0/0
ROUTERB(config-if)# tunnel destination 10.10.10.1
ROUTERB(config-if)# tunnel mode ipv6ip
ROUTERB(config-if)# ipv6 rip ROUTERBRIPNG enable
ROUTERB(config-if)# end
Notice how straightforward this configuration is, and also notice the critical importance of the tunnel mode command in order to ensure the use of the Manually Configured Tunnel.
In future blog posts, we will examine other important options for the smooth transition between IPv4 and IPv6.
Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv



