Atom Feed
Comments Atom Feed

Similar Articles

2010-04-24 10:31
OpenWrt Take 2 - native IPv6 on DG834 v3 (using AAISP)
2010-01-23 18:41
OpenWrt with native IPv6 on DG834 v2 (using AAISP)
2015-06-20 15:14
Home Lab Project: Network Bridges for KVM - NAT, Host-only, Isolated
2011-08-24 19:10
TEMPer under Linux (perl) with Cacti
2009-01-04 00:34
Easy Squeezy

Recent Articles

2019-07-28 16:35
git http with Nginx via Flask wsgi application (git4nginx)
2018-05-15 16:48
Raspberry Pi Camera, IR Lights and more
2017-04-23 14:21
Raspberry Pi SD Card Test
2017-04-07 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
2017-03-28 13:07
Kubernetes to learn Part 4

Glen Pitt-Pladdy :: Blog

IPv6 NAT .... or not as the case may be

People are at last starting to take notice of IPv6, and one question that comes up time and again is one of IPv6 having NAT (Network Address Translation).  NAT is widely used with IPv4 to split the IP of a DSL router to all the nodes it serves, and the same for corporate networks etc.

The reply to people in forums wanting NAT for IPv6 is almost universally the same: You don't need NAT with IPv6 as there are loads of addresses and besides NAT causes problems with a lot of protocols (eg. VoIP) so is a bad thing and should not be used.

That's true.... for the very narrow range of scenarios of boxes behind some router sharing a single internet connection, but there is a lot more to NAT than that. There are some scenarios where it could be very useful:

Small networks with failover

Many small companies have a DSL router and NAT themselves behind that. All is fine until their DSL link fails (and all to common scenario).... At that point it would be useful to have a cheap backup DSL link with a different ISP and/or an alternative connection all together (eg. 3G).

With IPv4 that's all rather easy - just NAT the company network behind the backup device and everything continues working. If the backup internet connection is on a static address then you can even use 1-to-1 or reverse NAT to re-map services to backup addresses too so for example would be available as if the primary connection failed. Routers/Firewalls that do this type of failover are common and available from loads of vendors at costs easily in reach of small companies who depend on having internet connection at all times.

Without NAT, IPv6 can't do this. Admittedly, if you are prepared to go to a load of extra cost and hassle, you could get a connection where your address range is routed with BGP and configure it to route via the secondary connection when the primary fails, but that's no longer a practical solution for a small business who can afford a couple of cheap DSL connections and wants an automatic switch-over between them.

To use the IPv6 on the secondary connection otherwise would require re-configuring the network onto a new address range and then back again when the primary network comes back. Just not practical!

Test networks

I spend a fair amount of my time working with simulated networks to test things out before deployment. Virtualisation tools like VMWare allow creation of "Teams" which are groups ov virtual machines (VMs) linked together with virtual networks. I have also done the same thing on a larger scale with KVM and a managed switch with VLANs to build complex network scenarios with a mix of virtual and real nodes working together in the same test environment.

These can be used to mimic real life scenarios like a webserver in a datacentre and client machines. For example, to deploy a new server, you can set it up in one of these test environments with the real IP address and all the networks you need around it to test it before deploying it into a datacentre. Another scenario is to be able to test configuration changes in an identical environment before putting them onto the live servers.

NAT allows the same IP addresses as the real servers to be used for testing and hide them from the real world. The test nodes still have internet access like the real servers, but hidden behind NAT they can be routed to from inside the test environment without affecting anything.

Remove the NAT as in IPv6 and we have a problem - we can only have one of each IPv6 address on the internet. The test nodes can no longer have internet access as the returned packets would go to the real servers instead.

The point

I would agree strongly that NAT is a very bad thing when it's used as a cheap skate way of sharing an internet connection with multiple machines, or as I am sure we will see as the IPv4 address shortages start to bite, being used as a means to avoid or delay doing the work to get IPv6 implemented.

The important thing to remember is that there are many other good uses for NAT other than these simplistic scenarios of misuse of NAT. I have just put the two scenarios that I have come across most recently working with IPv6, but I'm sure there are many others out there who face similar problems with networks they manage.

Fortunately, there are some implementations of IPv6 NAT for Linux under way and hopefully these will be adopted into the mainstream kernel when they are ready. They will certainly be welcome on some of the networks I run.