« PGA: Personal Google Assistant | Main | Hmm »
May 11, 2003
IP Address Thunking: NAT=bad, Part 1
In the early 90's, PC's used 16-bit processors, which normally could only access 64KB of memory. Through a process called "thunking", they were able to access 4GB, by accessing 32-bit addresses with a 2-step addressing process. Several technologies tried to make this transparent to application developers, PC technicians and users. Phar Lap was a very popular 32-bit development environment for DOS-based applications, Windows 3.1 had "Win32s," and Windows95 used thunking to support many 16-bit functions that were retained from Windows3.1. WindowsNT and later operating systems are native 32-bit and work only on 32-bit processors (Intel 386 or later), so they do not need to thunk.
But thunking was not transparent. For the developer, thunking makes development much more complicated. For the user, thunking probably isn't very visible, but it can make things more confusing (ie which version of software works with which version of Win32s) and much less reliable. Most importantly, for PC technicians, thunking was a support nightmare, especially under Windows. There was no end to the crashes, diagnostic complexities and support issues. Windows95 was a welcome improvement, and Windows2000 finally resolved most of the reliability problems.
Something similar to 32-bit thunking is widely used on the Internet today. It's called "Network Address Translation," or NAT. As more people have connected to the Internet, the 32-bit address space provided by IPv4 quickly became insufficient. NAT provides something like a 64-bit thunk, where an entire network can be addressed using "private" addresses, then a NAT gateway translates those to a few "public" addresses visible to the rest of the network.
NAT was created as a temporary solution for address shortages until the network could migrate to IPv6. In the process, NAT somehow became the solution instead of the band-aid, and now many people wonder if there's any reason to move to IPv6.
This is a short-sited perspective. Unfortunately, it has become more popular recently as NAT continues to placate the IPv4 limitations. I read lots of articles about the issues NAT has to address, and how NAT impacts the network, but few or none of those articles even mention IPv6 as as possible alternate solution.
NAT has problems analogous to those we experienced with PC thunking. These result from the NAT gateway having to make changes to packets as they pass from the private address space to the public. Some applications are oblivious to the address change, but many applications break completely with NAT. Voice, video, security, network filesystem, VPN and many other types of applications expect the packet to arrive unaltered. For these applications to work with NAT, the gateway must have application-specific capabilities, which often include encryption interception. The NAT gateway becomes an application and security gateway for dozens and eventually hundreds of network applications.
The functionality, performance and reliability of the network are increasingly dependent on NAT gateways. These devices are increasingly complex while at the same time much less mature than traditional network devices (routers, etc). Their impact on the network is supposed to be transparent, so they are invisible to the devices communicating through them. This adds up to NAT gateways being the greatest cause of network problems, but being the least-noticeable device in the network.
Jim has written about NAT recently, as have I.
This week, I will be writing more about the dangers of NAT, and why we should be focused on moving to IPv6 instead of making NAT work better.
Posted by pete at May 11, 2003 4:49 PM
Comments
What about those networks which you want to remain unroutable, except, maybe, through a gateway device? In other words, a private network may really be private, NAT is being used to keep it *private*, not to extend the bounds of the IPv4 address space.
Posted by: Will at May 12, 2003 5:05 PM
Good point. I will address this sometime this week (probably Part 3).
Posted by: Pete Kruckenberg at May 12, 2003 5:32 PM
Nice summary. Thank you for posting it.
Posted by: ip address at February 13, 2004 4:36 AM
why SN-IPv6-WindowsXP.bat doesnt finish his work?
tracing route to orange.kame.net (2001:200:08002:203:47ff:fea5:3085) from 2001:c20:ffff:2b:25d over a maximum of 30 hopes:
and at 6 it stops & write nothink
how to make ipv6 work on irc with it
pleace help
sorry my enlish low
Posted by: VOkiets at April 7, 2004 3:44 PM