In some ways, the Internet is a lot like El Cerrito. As in El Cerrito, the concerns the Internet community face are serious, urgent, complex-and profoundly uninteresting to those outside that community. As is also the case with El Cerrito's residents, 90 percent of the members of the Internet community live and work in blissful ignorance that most of these tough issues even exist.

From my perspective, one of the most urgent problems the Internet community faces is that IPv4, the protocol that binds us all together, is getting more than a little long in the tooth. The wizards of the Internet Engineering Task Force have managed to keep this aging protocol, limping along far beyond its natural lifetime, mostly by shoehorning added functionality into the core protocol via ingenious manipulation of router protocols and by very, very carefully using the precious few reserved bits in the IP datagram header to point to header extensions.

Today's Internet backbone routers don't support IPv6 and the lower-cost, lesser-function routers used in most connected networks definitely don't support IPv6. Until they do, anyone who wants to use IPv6 in a routed environment has to dual-stack with IPv4 and has to put up with the performance hit of tunneling IPv6 by encapsulating it within IPv4 packets.

So, it's the-chicken-or-the-egg problem and the bottom line is that we won't get to take advantage of that huge address space (or any of the other cool features of IPv6) until Cisco, Bay, 3Com and their small-fry friends start building software that supports it. Luckily though, there's more than one way to flay a feline--or to build a bigger address space.

Some of My Lies Are True

Classless InterDomain Routing (CIDR) was a wonderful thing. By eliminating classful addressing, it temporarily solved the problem of IP address depletion that loomed so large back in 1993. But the raging thirst the world has developed for IP addresses continues unabated and it's causing serious strain on the ability of present-day routers to cope with the growth in the size of the Internet's routing tables. Even the breathing space in the relentless depletion of IP addresses created by the adoption of CIDR won't last more than another decade, at best.

The CIDR specification was finalized in 1993's RFCs 1517-1520. In their May 1994 RFC 1631, Kjeld Egevang and Paul Francis proposed another address extension strategy they called the Network Address Translator (NAT). They proposed that what they called "stub networks" (i.e.--networks that provide no downstream connectivity services for other than their own users) use one of the three IP address blocks allocated by the Internet Assigned Numbers Authority (IANA) as private address space and, essentially, lie about it to the rest of the Internet.

IANA reserved three private address space blocks to permit enterprises that would never be connected to the Internet (or to other enterprises' networks) to use IP addresses that were only guaranteed to be unique within their own network. None of these addresses are ever assigned to Internet service providers or to other Internet-connected autonomous systems. That policy means that, since their hosts will never "see" each other, multiple enterprises can each use the same set of addresses within their private networks. It also means that, if an enterprise that is using a private address block somehow connects to the Internet without first renumbering its hosts, it can't create a conflict with any of the globally-unique addresses that have been assigned to existing Internet-connected hosts.

NAT translates these non-globally-unique, private IP addresses to and from a pool of globally-unique "public" IP addresses that are visible to the Internet.

When a host on the private address space side of the router requests a service from an Internet host, NAT assigns one of its pool of "legal" addresses to the request, modifies the packet by substituting the globally-unique address for the original source address on the private side and forwards the request to the Internet destination host. It performs the same operation in reverse for packets coming in from the Internet host that bear the destination address corresponding to the host on the router's private address side. Once the session ends, the "loaner" public address is returned to the router's pool, so that it can be reused by the next host on the private address side that requests a service from the Internet side of the router.

Of course, there are both advantages and drawbacks to this tool.

The Good, the Bad and the Ugly

With NAT, all IP translation happens at the application layer. Thus, NAT is unsuitable for applications such as virtual private networks (VPNs) that demand connectivity at the network layer. In the case of VPNs, packets routed over the Internet between private-address-based stub networks must be encapsulated within "legal" packets by both border routers, adding considerable overhead, and seriously impacting performance.

By definition, NAT substitutes one IP address for another. That, in turn, changes the IP checksum. NAT must therefore calculate a new checksum and substitute it for the original in both outbound and inbound packets. Among other things, this means that NAT fails for applications that encrypt packet headers or which use the original checksum and/or IP source or destination address as a seed or other component of their encryption algorithm. It also fails for applications that incorporate source and destination IP addresses in the data portion of their packets, unless the particular NAT implementation "knows" that the application does so. For instance, all commercial NAT products "know" that FTP does this very thing.

By design, a NAT router's pool of "legal" addresses is generally a good deal smaller than the total number of hosts on the private side of its connection to the Internet. For most enterprises, this makes perfect sense, since the bulk of their network traffic is purely internal. However, for those enterprises where there is a heavy, continuous demand for access to Internet-based hosts, the fact that NAT has to perform surgery on every inbound and outbound packet can act as a real performance bottleneck.

NAT hides the addresses of hosts on the private side of the router from hosts on the public side. The "legal" address a NAT router assigns to a host on the private side persists only for the duration of a particular application session, so hosts on the public side of the NAT router cannot determine the true address of hosts on the private side.

From a security standpoint, that's a good thing. From a network management perspective, it's a drag. NAT plays merry hell with SNMP, for instance, and it greatly complicates the process of obtaining DNS services from a public-side host. Because NAT works by substituting IP addresses and modifying checksums, it can also cause problems with ICMP-based applications, such as Traceroute.

The good news is that NAT allows the stub network almost unlimited growth within its private address space, while the amount of public address space it consumes can remain fairly small. Better still, because a NAT router's public address space is assigned by an upstream provider, its entire allocation of globally-unique addresses can usually be seamlessly aggregated into the CIDR block organization's ISP. That keeps it from consuming any extra space in the Internet's core routing tables, and that's a very good thing indeed.

The Future Belongs to IPv6

Among the major router vendors, Cisco's Enterprise Plus IOS 11.2.4 supports NAT--but you have to specifically request it. Neither 3Com nor Bay Networks currently supports it (at least, not as far as I can tell from 3Com's poorly-organized and badly broken web site). Bay's site, instead, talks about its commitment to IPv6. On the other hand, most major firewall vendors now incorporate NAT as an adjunct to packet filtering, logging and stateful inspection. Along with the usual UNIX suspects, such as Sun, Raptor Systems, Checkpoint and their ilk, Ukiahsoft's NetRoad firewall NLM supports NAT for Novell IntraNetWare servers (a fact in which you may not be interested, but one that I guarantee will fascinate quite a few of your corporate customers).

I've met any number of true believers who insist that CIDR and NAT and a host of other stop-gap patches to the increasingly creaky IPv4 are preferable to the terra incognita of a wholly new protocol. Heck, there are a lot of SNA partisans left in the world, too. I think both groups are kidding themselves. The truth is that, although NAT offers a present-day solution to problems of scaling and security, in my view, it is essentially a kludge and its limitations augur strongly against its long-term viability.

From my perspective, the best long-term solution to the problems of extensibility, manageability, scalability and transparency is IPv6.

I haven't exactly made that a secret. In fact, when Evangelo Proudroumou (keeper of the PERL for Win32 FAQ) proposed a humorous eight point platform for my City Council campaign, his suggestion for plank six was "El Cerrito will change over completely to IPng by Dec 31, 1997."

Then again, according to Evan, (who knows me entirely too well for someone whom I've never actually met) plank eight should be "We must retrieve the Amulet of Yendor,"--which ought to tell you something about the value we both place on museum pieces.