NAT won't save you from the need to switch to IPv6

Once upon a time, anyone could get a static Internet Protocol (IP) Class C /24 address. That meant you got 256 addresses, well actually since .0 and .255 are set aside, and one address was assigned to your gateway you actually had 253 addresses. But that was more than enough for most small businesses. That was then. This is now.

Today, ISPs don't hand out Class C /24 addresses to just anyone. Instead, you'll need to ask for one, and you'll probably pay extra for it. Today's SOHO default seems to be a Class C /30. That will give you four hosts addresses, with only one of those IP address actually being assignable to a device. Yes, all your PCs and what-not on that network can get to the Internet via NAT (Network Address Translation), but NAT is no more a permanent fix than using duct tape to seal a gas tank leak.

Sure, it will work fine for you for today, but what about tomorrow when you need more addresses? In the long run, as John Curran, president and CEO of ARIN (American Registry for Internet Numbers) explained, "Although NAT works fine for a single enterprise, ISPs know that NAT can't be scaled indefinitely on the scale that they would require to continue to connect customers just via IPv4. This is why they're looking to IPv6 to connect new customers. And while some carrier-scale NAT (between IPv6 and IPv4) will be used during transition to IPv6, we need to focus on making public web sites IPv6 reachable in order to keep the Internet running over the long-term."

There are other reasons as well why NAT won't be enough in the future. Hurricane Electric's IPv6 Evangelist, Owen DeLong told me, "NAT was great as a stop-gap for a limited set of use-cases while we developed a protocol with a larger address space. Indeed, it has bought us a nice 10-12 year cushion on address exhaustion. However, unfortunately, a great deal of mythology has grown up around this 'savior of the day' technology. I think it is best to start by spelling out some of the myths and facts surrounding NAT."

"First," DeLong continued, "NAT introduces a number of problems. Many of these problems have been made invisible to the end user and even to the network administrator deploying NAT, but, if you ask any software vendor that has had to develop software that works in spite of NAT, you'll rapidly find out that it's making software much more expensive, complex, and even larger than it needs to be."

In addition, "NAT makes it hard for users stuck behind NAT to offer any form of service(s) from their machines. While I realize there are those that argue this is a good thing, I will maintain the position that the choice to offer a service to the Internet or not should rest with the owner of the machine in question in most cases. In the cases where it should not, well, a good firewall can still solve the problem without the need for NAT."

Even some of what people see as NAT's advantages don't hold up on closer examination. "NAT does nothing for security," said DeLong. "The entire security benefit most people attribute to NAT actually comes from the stateful inspection of packets that is required in order to maintain state tables for NAT to be able to reverse translations on reply traffic. There are those that argue NAT fails 'closed' and is therefore more secure. A properly designed stateful firewall fails equally 'closed.'"

"So, he continued, "at its core, NAT offers one and only one truly useful feature to the Internet. It allows lots of end-users to hide behind a small number of often one, address(es). However, this only helps end users. It doesn't help for servers, routers, or other infrastructure that must be globally identifiable on the network."

And, that's there the real trouble is coming. "Trying to scale NAT beyond its current state would involve running NAT at the carrier level. This introduces several new problems. One problem: Communications Assistance to Law Enforcement Act (CALEA) compliance with a carrier-level NAT gateway would require vast amounts of disk storage. (More than a petabyte per day for 7 years in some large providers according to some estimates)."

Why so much data? DeLong explained, "In order to identify a subscriber today, you can simply use the one public IP address that corresponds to that end-site's gateway. (Household/business granularity is usually considered sufficient). However, with carrier NAT, you now need the complete state table log and time details. You'll also need more information about the session being investigated, since you'll need the timestamps in order to identify the subscriber in question."

Of course, NAT at that level is also very expensive to deploy and it doesn't scale worth a damn. Worse still, "NAT at the carrier level will also break many of the now common NAT traversal solutions (programs that let you use software that doesn't work well with NAT such as Voice-over-Internet Protocol), resulting in applications that work in the current environment failing in this proposed future environment."

In short, as DeLong concluded, "Yes, there are some unknowns and some other challenges with the migration towards dual stack and eventually the replacement of IPv4. However, there are many more unknowns and a much larger set of challenges contained in doing NAT at the provider level."

And, I might add, with fewer IP address ranges to go around, end-users will soon feel the pain as well in the form of higher ISP fees both for simple connections and for Web hosting. You can use NAT all you want, but in the end you'll be paying more. The days of IPv4 and NAT are numbered.