When the internet was first developed, the IP addressing scheme was IPv4. This addressing scheme worked really well for about 25 years. After all, it had about 4 billion host addresses. But as the internet grew, we started to see that this was just not going to be enough. Now we have an entire infrastructure that was built on IPv4. While IPv5 addresses have been exhausted, we’ve used band-aid solutions to keep the internet growing. With these band-aids in place, it hasn’t been an easy jump from IPv4 to IPv6.
So how do we get from IPv4 to IPv6—which we all agree has to happen—when there’s still a raging debate about one of the biggest band-aids – Network Address Translation (NAT)- and its place in the mix. Do we need it? Should we stick with it? Let’s start with some basics, and then talk about solutions and strategies, and why is NAT definitely not needed moving forward in an IPv6 internet.
How did we get here?
Internet protocol sits at Layer Three of the OSI model, otherwise known as the “network” layer. Its job is to deliver packets to other networking devices, typically between separate networks. Conceived in the 1970s, there was no way to predict when we’d hit the limits on these protocols. But as we all know, things changed rapidly, with an exponential growth of networking nodes that have since covered the world.
IPv4 is exhausted
How did we get beyond 4 billion devices being used? After all, there’s only 7.8 billion people on earth. Turns out each user tends to own more than one thing that needs an IP address! There’s simply a profusion of connected devices. Cars, cell phones, work computers, home computers, game consoles, household appliances, industrial equipment, and on and on. Oh, and don’t forget about your smart fridge! All of these devices, and more, need IP addresses. Something had to be done.
The purpose of NAT
The original purpose of NAT was to increase the pool of usable IP addresses by re-using them. Instead of all devices having a globally unique IP address, devices on a local network behind a network router or a network firewall could use a pool of private, non-globally unique addresses on the inside, and use a publicly usable address on the outside. NAT identifies a host device, and tracks the host device and its internal IP address. When the packet needs to make a trip outside the local network, a NAT device will then assign it a different address and then route it onto the internet.
For IT pros, it quickly became obvious that NAT could greatly increase the number of hosts that could access the internet without actually using more internet addresses. The issue of address starvation was solved, at least for a while.
But engineers knew NAT was only meant as a stopgap solution until a new addressing scheme could be devised. Because for NAT, there are still a number of challenges. Like scale—NAT involving large numbers of private IPs (think large offices or campuses) can degrade the performance of the network. It also can limit troubleshooting, and affect usability of tunneling protocols such as IPsec.
So, a new solution was coming, but it’s not like the internet was waiting around. IPs were desperately needed, and so the “NAT fix” was quickly and widely adopted.
Say hello to IPv6
The concept of this solution is quite simple: Come up with a totally new IP addressing system that has so many addresses, and is so flexible and functional, that we’ll never run out of addresses and won’t have to change schemes again.
IPv6 offers some tremendous advantages. It offers much more address space, making IP address conflicts non-existent. In fact, it has so many addresses it’s hard to even imagine using all of them (also making proper documentation and management of these addresses critical!). It’s also classless, so it allows upper layer protocols to determine the class of service implicitly and works much better with multicast.
The implementation of IPv6, however, has not been easy. IPv6 was released in 1999, so it’s been out for a while. But here we are in 2021, and still most devices run on IPv4 with NAT. Why did the IPv4 to IPv6 trend stall in it’s infancy.? Because what we currently have is everywhere, and it’s still *mostly* working.
IPv6 has a theoretical limit of 3.4 x 1038 unique IP addresses. That’s 340 trillion trillion trillion IP addresses.
By the time IPv6 rolled out, there were already billions of devices worldwide, and most of them using IPv4 and NAT. With the NAT stopgap was working well, there was little reason to make the switch to IPv6. For IPv6, all of this installed infrastructure would need to be either replaced or upgraded. New equipment. New firmware. New IPv6 training for all the networking technicians and engineers.
What’s NAT got to do with it?
It’s really hard to convince an IT manager (or for an IT manager to convince their management) to replace or upgrade working equipment with a new IP address scheme when they don’t have to right now. Management is going to want a compelling reason to make this type of investment, and explaining the difference between IPv4 and IPv6 might not quite do it. If you don’t have a persuasive argument, they aren’t going to spend the money on new technology and training, experience the technology learning curve, go through a few outages, and possibly get some heat from upper management.
Until now, NAT has solved for simple address starvation very cost-effectively. You want to add a few more users, and can’t get any more public addresses? No problem. There’s Port Address Translation (PAT) that can use the same IP address as NAT, and uses IP protocol ports to differentiate them. So, you actually extend the usefulness of NAT even more. In reality, you’re kicking the can down the road even more, because you can (sorry).
Even network carriers are slowing the rate of adoption by using something called Carrier-Grade NAT or CGNAT to apply similar techniques to the carrier’s subscriber base, which has many single router subscribers on it.
These technologies have effectively slowed the adoption of IPv6, but they won’t for much longer.
Let’s bust some IPv6 myths
There’s a number of myths surrounding NAT and IPv4 that are holding back networks from making the jump to IPv6. Let’s debunk a few, shall we?
No NAT means less security. While NAT is often viewed with security benefits, and NAT certainly does help with security, it’s not necessarily the best security solution out there (not anymore). Many people may think they need NAT to have a security solution, but this is not the case. Threats have evolved significantly, and a network leveraging NAT is not likely to be any more secure than one that’s not, assuming the proper security infrastructure and firewalls policies are in place.
You can use NAT on IPv6, so you should use NAT on IPv6. Let’s be clear: There’s no reason at all to go through the trouble of using NAT with IPv6 and that’s the point. The purpose of NAT was to address IP starvation. And since this issue is solved with IPv6, you don’t need NAT anymore! If you still want to accomplish some additional network privacy for internal network addresses, there’s a technique described in RFC4864 which defines Local Network Protection.
You can do everything on IPv4 that you can do on IPv6. This is simply not true. Setting aside the issue of running out of IP address spaces, and understanding that NAT is not needed in IPv6, there’s still many features added or being added to IPv6 that are not inherent in IPv4. IPv6 greatly enhances multicast routing since it uses a more multicast-like address scheme. IPv6 eliminates the need for DHCP, making administration simpler. IPv6 also has a smaller header with fewer options on it, and with the millions of routers on the internet this can affect performance tremendously. And IPv6 has its own built-in authentication and privacy support without having to run NAT. It kind of sells itself.
Strategies for moving forward
Thinking of developing an IPv6 network transition plan? There’s a few things to keep in mind. These tips should help you keep your plan on track, and avoid problems in the process.
Document your network now
We can’t stress enough how important it is to document what you have now. This is a basic strategy that you should be doing already. But if you know where all your network devices are, which devices are dependent on a specific network address, and which ones can’t be migrated or need updating beforehand, you’ll be much better off when the time comes.
Discuss with management
The time to let your management know about your plans is as soon as possible. Explain the issues of IPv4 vs IPv6 and why you’re thinking about making the change. Senior-level buy-in will help with approving the upgrade process and getting any budget you need. Find people within the organization that can support and champion your cause. Get them on your side before it’s time to make the change.
Have a plan in place
To support the other two initiatives, you should have a plan in place to show anyone that needs to see it. This plan should have your justifications and your estimated impact on the company. Don’t sugarcoat it with rosy budget numbers or stories about migration in a single weekend. Be honest and tell it like it is. Give the reasons and the justifications in plain language. Don’t be afraid to ask for a budget for training and preparation also. If the management refuses, at least you’ve done your part, and you have a plan ready for the next opportunity.
Train everyone you can
Once you get trained, and are more familiar with what the challenges are, start training and talking to anyone with any involvement or responsibility for network connectivity or network administration. Start with your most technical people first. Discuss the issues of IPv4 vs IPv6. Get them on your side to help you with this process. Then keep spreading the knowledge. This is not the time to hold back on valuable “job security” information. You’ll need all of their help and support when the time comes. You can make this a very successful process and a feather in your cap. But if you are in the middle of a migration, and you have kept everyone in the dark and then something goes wrong, you’ll be all alone. Ensure you have your team prepared when the time comes.
Auvik’s network monitoring and management system works across networks without a hitch. Ready to see more? Get your free 14-day Auvik trial here.
Interesting article. One thing that comes to mind is behind a NAT you can’t tell what specific machine made a request and the NAT handles where the result of a query is directed when returned to the public IPv4 address.
What result or effect would this have on privacy or anonymity that a NAT provided?
How would this effect anonymity of a VPN since all addresses are public?