We certainly have talked a lot about how IPv6 works and how we can configure it to work on our networks, but what is doing that going to cost us? And how much work is it really going to take?
Good questions for sure, but the answers to them won’t be the same for everyone. This is because how much you are going to end up having to pony up is highly dependent upon what you’ve got going on already in terms of your infrastructure.
Obviously, if you’ve been making your really old routers and switches “last” and therefore have to upgrade every one of them so that they’re IPv6 compliant, that could very well turn out to be a good-sized chunk of change! Oh, and that sum doesn’t even include server and computer operating systems (OSs) and the blood, sweat, and maybe even tears spent on making all your applications compliant.
So, my friend, it could cost you quite a bit! The good news is that unless you’ve really let things go, many OSs and network devices have been IPv6 compliant for a few years we just haven’t been using all their features until now. Then there’s that other question about the amount of work and time. Straight up this one could still be pretty intense. No matter what, it’s going to take you some time to get all of your systems moved over and make sure that things are working correctly. And if you are talking about a huge network with tons of devices, well, it could take a really long time!
But don’t panic that’s why migration strategies of IPv6 have been created to allow for a slower integration. We are going to show you three of the primary transition strategies available to us.
The first is called dual stacking, which allows a device to have both the IPv4 and IPv6 protocol stack running so it’s capable of continuing on with its existing communications and simultaneously run newer IPv6 communications as they’re implemented.
The next strategy is the 6 to 4 tunneling approach; this is your choice if you have an all IPv6 network that must communicate over an IPv4 network to reach another IPv6 network. We’ll surprise you with the third one just for fun!
Dual stacking
This is the most common type of fo migration strategy because, well, it’s the easiest which allows our devices to communicate using either IPv4 or iPv6. Dual stacking lets you upgrade your devices and applications on the network one at a time. As more and more hosts and devices on the network are upgraded, more of your communication will happen over IPv6, and after you’ve arrived everything’s running on IPv6, and you get to remove all the old IPv4 protocol stacks you no longer need.
Plus, configuring dual stacking on a Cisco router is amazingly easy all you have to do is enable IPv6 forwarding and apply an address to the interfaces already configured with IPv4. It’ll look something like this:
Corp(config)#ipv6 unicast-routing
Corp(config)#interface fast Ethernet 0/0
Corp(config-if)#ipv6 address 2001:db8:3c4d:1::/64 eui-64
Corp(config-if)#ip address 192.168.255.1 255.255.255.0But to be honest, its really a good idea to understand the various tunneling techniques because it’ll probably be a while before we all start running IPv6 as a solo routed protocol.
6to4 Tunneling
6to4 tunneling is really useful for carrying IPv6 data over a network that’s still IPv4. It’s quite possible that you’ll have IPv6 subnets or other portions of your network that are all IPv6, and those networks will have to communicate with each other. Not so complicated, but when you consider that you might find this happening over a WAN or some other network that doesn’t control, well, that could be a bit ugly. So what do we do about this if we don’t control the whole tamale? Create a tunnel that will carry the IPv6 traffic for us across the IPv4 network, that’s what.
The whole idea of tunneling isn’t a difficult concept, and creating tunnels really isn’t as hard you might think. All it really comes down to is snatching the IPv6 packet that’s happily traveling across the network and sticking an IPv4 header onto the front of it. Kind of like catch and release fishing, except for the fish doesn’t get something plastered on its face before being thrown back into the stream.
To get a picture of this, take a look at the picture below.
Nice, but to make this happen we’re going to need a couple of dual-stacked routers, which we just demonstrated for you, so you should be good to go. Now we have to add a little configuration to place a tunnel between those routers. Tunnels are pretty simple we just have to tell each router where the tunnel begins and where we want it to end up. Referring to the above picture, we’ll configure the tunnel on each router:
Router1(config)#int tunnel 0
Router1(config-if)#ipv6 address 2001:db8:1:1::1/64
Router1(config-if)#tunnel source 192.168.30.1
Router1(config-if)#tunnel destination 192.168.40.1
Router1(config-if)#tunnel mode ipv6ip
Router2(config)#int tunnel 0
Router2(config-if)#ipv6 address 2001:db8:2:2::1/64
Router2(config-if)#tunnel source 192.168.40.1
Router2(config-if)#tunnel destination 192.168.30.1
Router2(config-if)#tunnel mode ipv6ipWith this in place, our IPv6 networks can now communicate over the IPv4 network. Now, we’ve got to tell you that this is not meant to be a permanent configuration; your end goal should still be to run a total, complete IPv6 network end to end.
One important note here if the IPv4 network that you’re traversing in this situation has a NAT translation point, it would absolutely break the tunnel encapsulation we’ve just created! Over the years, NAT has been upgraded a lot so that it can handle specific protocols and dynamic connections, and without one of these upgrades, NAT likes to demolish most connections. And since this transition strategy isn’t present in most NAT implementations, that means trouble.
But there is a way around this little problem and it’s called Teredo, which allows all your tunnel traffic to be placed in UDP packets. NAT doesn’t blast away at UDP packets, so they won’t get broken as other protocols packets do. So with Teredo in place and your packets disguised under their UDP cloak, the packets will easily slip by NAT alive and well!
NAT-PT
You’ve probably heard that IPv6 doesn’t have any NAT in it, and you’ve heard correctly sort of. By itself, IPv6 doesn’t have a NAT implementation. But that’s only a technicality because there is a transition strategy known as NAT protocol translation (NAT-PT). just know that you really only use this approach as a last resort because it’s not that great of a solution. With it, your IPv4 hosts can only communicate with other IPv4 hosts and those that are native IPv6, with other IPv6 hosts. What do we mean by that? Well, with a tunneling approach we took IPv6 packets and disguised them as IPv4 packets. With NAT-PT there is no encapsulation the data of the source packet is removed from one IP type and repackaged as the new destination IP type. Even though being able to configure NAT-PT is beyond the scope of the CCNA objectives, we still want to explain it to you. And just as it is with NAT for IPv4, there are a couple of ways to implement it.
Static NAT-PT provides a one-to-one mapping of a single IPv4 address to a single IPv6 address (sounds like static NAT). there is also dynamic NAT-PT, which uses a pool of IPv4 addresses to provide a one-to-one mapping with an IPv6 address (sounding like familiar). Finally, there is Network Address Port Translation (NAPT-PT), which provides a many-to-one mapping of multiple IPv6 addresses to one IPv4 address and port number (well, glad we have that cleared up from NAT).
As you can see, we are not using NAT to translate a public and private IPv6 address as we did with IPv4, but rather between IPv4 and IPv6. Again, this should be used as an absolute last resort. In most cases, a tunneling approach will work much better and without the headache of this configuration and system overhead.