Wednesday, March 31, 2010

IPv6 deprecates NAT that is popular in IPv4 world - Is this really true?

I am not sure though.  There is no doubt that there are large number of IP addresses available in IPv6 world.  Though NAT was started due to the IPv4 address resource exhaustion, it has been used for many other purposes such as
  •  Avoid renumbering of the majority of network in corporations when they change their service provider or when the companies get merged.  When the service provider is changed or companies get merged, only few devices such as routers,  firewalls & NAT devices , IPSec VPN devices and Server such as DNS need to be updated.  Rest of the network addressing can remain same as NAT devices front end the network to external world.
  • When corporate networks have multiple ISP connections,  two scenarios are possible - There is load balancing of connections across multiple ISP connections and failover of connections to other ISP network in case of failure of primary ISP connection.  In both cases,  in IPv4 world, NAT devices take care of balancing and routing the traffic to appropriate ISP connections, that is, end hosts are not aware of this. End hosts are always assigned with fixed private IP addresses and NAT device takes care of translating those addresses with IP address of the ISP connection on which the packets are going to be transferred to.  In case of IPv6 network, without NAT support, each end host should take care of this on their own. This may be possible when every host runs routing protocol, but not sure whether it is practical.  By doing NAT in IPv6 world, this would be similar to IPv4 world and the burden of balancing and failing over the connection resides with NAT devices.
  • Security by obscurity is one another thing IPv4 NAT is providing which will be lost in IPv6 if every end host communicates with the external world on its own.
To me, above problems can be solved in some fashion or other such as Provider Independent IP addresses. This might increase the burden on the Internet core routers as there would be large number of routes. Though at this time, I am not sure whether this is practical, but I am sure some solution would be found.

But main reason I would believe NAT would continue to exist is due to Server Load balancing devices (And ADC devices).   SLB devices are expected to find out the least loaded server and award the connection to that server.  It is expected that connections are destined to one IP address (This IP address is called Virtual IP address) and server identifies the least loaded real server and redirects the connection to that server. Redirection of the connection typically involves Destination NAT where the DIP of the original connection packets are replaced with the real server IP address and vice versa on SIP (Source IP) for packets going from real server to client.  Also to ensure that the packet from the server passes through the same SLB device, source NAT is also applied with 'source IP' replaced with IP address of SLB device.  Since 'source IP' seen by real server is same even though connections came from multiple clients, there is a possibility of two different clients using the same source port. Hence source port translation is also required at the SLB device.  Due to this, I believe all considerations which are applicable for IPv4 NAT are valid here in Ipv6 world too.

One can say that there are other alternatives to address translation such as DNS based load balancing where different DNS requests are given with different real server IP addresses. But this is not accurate and there is a possibility of some real servers getting loaded more than others.  Another solution that can be suggested is to do only MAC translation.  Though this works, but it works only if both SLB device and real servers are on the same link.
Due to limitations on different approaches, Load balancing with NAT would continue to be required in many deployments.  So, don't rule out NAT even when we all move to IPv6.

If you believe I am wrong here, please drop a comment.

No comments: