With all those gray hairs, I've come to realize that we've never really learned from our past. Case in point: We are once again building networks like we did in the old days--isolated islands with limited services to all the other islands. Yes, folks, NAT (Network Address Translation) is bad for your company, and so are access gateways sold as firewalls and centralized services.

Maybe I spend too much time around the IETF bar, but Dr. Scott Bradner, head of Harvard University's Device Test Lab, clearly pointed out one of our basic problems: "There are only a few clues to go around and the Internet is growing geometrically; I leave the math to you." I have encountered many network integrators who see nothing wrong with NATs and firewalls, so they actually look for ways to do more with these productivity bottlenecks when they should be working to eliminate them.

How We Got Here The early days of ARPA saw many networking technologies, most notably NCP (Network Control Protocol) in 1970. NCP had a simple eight-bit address structure. This provided enough addresses when ARPAnet was just a handful of timesharing mainframes. For the next 13 years, NCP was the ARPAnet protocol and developing LANs had to use application-level gateways, or "port expanders," as Dr. Jon Crowcroft, professor of Network Systems at University College of London, remembers them.

Finally, the wholesale move to TCP/IP in 1983 (it was around on LANs and some WANs since 1974) was accomplished via a simple address shift. At the time, it was thought that there would never be more than 200 or so networks in the world, so everyone's eight-bit NCP address became the first octet in their 32-bit IP addresses. Existing networks at MIT got address 18.0.0.0 and the Michigan Educational Research Information Triad (MERIT) got 35.0.0.0. As late as 1981, in the great shift to IP (see RFC 776), designers felt that 256 networks of 16 million hosts was the way to build the Internet.

1983 also saw the proliferation of Unix systems with TCP/IP when the University of California at Berkeley released BSD version 4.2. With that release, the number of networks soared. In response to the boom, network classes were created. Since the upper 128 networks had not been used, they were set up for the Class "B" and "C" networks.

It's often assumed that TCP/IP has always been this way. But if you review the RFCs, this addressing scheme appeared in RFC 790 in late 1981. This is when the Internet founders first adjusted their earlier addressing errors. With 16,000 networks of 64,000 hosts, and 2 million networks of 256 hosts, in theory there should be plenty of networks and addresses for everyone. Application-level gateways should be a relic.

Network Crunch Time, Again But by 1992, there was another network crunch. IANA (Internet Assigned Numbers Authority) was very frugal with its network assignments. Two events triggered the problem: rapid consumption of the Class B networks and growth of the Internet Routing table in BGP version 3.

It's hard to say which caused the greater alarm. The routing table problem was addressed in 1994 with BGP4, but the concerns raised by David Clark of MIT and others in 1988 had become the reality (for more on these concerns, see "Addressing the Needs of Corporate Networks" at www.networkcomputing.com/919/919colmoskowitz. html). The Internet had fragmented and there was no putting it back together again. This became the way of the Internet with the publication of RFC 1597 (Address Allocation for Private Internets) in 1994.