The following text is copyright 1993 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.
By: Scott Bradner
So you say you are a purest about networks and you want to run a pure TCP/IP network. You maintain that this is cleaner and easier to manage than having all of "those" protocols running around. Since all of your computers can support TCP/IP, why would anything else be required? People who know how to run TCP/IP networks are more numerous (i.e. cheaper) than those who can deal with the peculiarities of AppleTalk and Novell's IPX, and who knows how DECnet works anyway?
I remember saying the same thing once upon a time. If memory serves, the purity lasted a day or two until it was pointed out quite forcefully that the majority of the major research computer centers on campus ran VMS machines. Oh ,well. Expanding the support to TCP/IP and DECnet would not be too bad.
This is the way the "new" network at Harvard ran for quite a while, with TCP/IP & DECnet the officially supported protocols. Since the Harvard network is one where almost all buildings have their own router port, this decision meant that all inter-building applications had to run over TCP/IP or DECnet. But there were always those pesky users poking at the periphery, wanting to run AppleTalk or Novell's IPX.
There was good reason to not support these other protocols. No one I ever heard of thought that AppleTalk (at that time AppleTalk Phase 1) could be used in a large network without great pain and high overhead. (Well, perhaps some people at Apple thought so.) IPX had about the same reputation.
Well, if you build it, they will try to come. It is now easy to get tunneling functions in a number of AppleTalk and IPX devices. Tunneling is the process of encapsulating one protocol within another. One can tunnel TCP/IP in DECnet and SNA or AppleTalk and IPX in TCP/IP. The result in the latter cases is a data stream that consists of "normal" TCP/IP packets. These packets can be forwarded over a backbone ( or the Internet ) on which the encapsulated protocol is not welcome. The user now has a way around the restrictions on the backbone and at first cut this looks quite nice.
The problem with this is that you, as the manager of the backbone, have no idea what is going on. If (or should I say "when") someone misconfigures one of those tunneled AppleTalk networks, you have no way of using the features in your routers to filter out the problem since all the routers see is IP and not the AppleTalk inside. You are going to get blamed when the encapsulated protocol has a problem but you don't have any control. It is better to bite the bullet and learn to do the routing than let the users do tunneling.
The basic problem with letting users tunnel the protocols you don't want to route is that you can't do preventative medicine. If there is a single most common cause of problems in attempting to extend IPX or AppleTalk support across a widely dispersed corporate network it is that LAN ID's get misconfigured. Chaos is the result if the same IPX network address is used more than once or if overlapping AppleTalk network ranges are used within the same internet. The routers that are used to interconnect the network can be programmed to only accept traffic from, and forward traffic to, the specific list of network (not node) addresses that are registered for a particular port. Implementing these types of traffic filters does take some additional administration but it can almost eliminate the problem of a misconfigured LAN in L.A. taking down the networks in Chicago.
Even if all of the LANs are always in perfect addressing harmony you may not want the whole network to know about all of the services that exist everywhere. Filters can be added to some routers which block selected service advertisements from one area and prevent them from being seen in another.
Some of this filtering can be done if you are in control of the tunneling gateways, but most of the existing products don't have filters as sophisticated as some routers now have and all too often the manager of the backbone network does not have control of these gateways.
Even if all of the above problems are not an issue (The LAN addresses are always perfect and the world should know about every service, or you have total control over all gateways.) you actually may be making the traffic load on your network a bit worse by doing the encapsulation. AppleTalk and IPX were originally designed to work in an environment with relatively few LANs and servers. As the number of LANs and the number of servers expands so does the network load caused by the passing of routing information and service discovery or advertisement information. Tunneling does not make this go away; it actually increases the size of the data packets and thereby the network load by a few percent.
Letting your users resort to tunneling rather than routing the protocols themselves turns you into of a spelunker, exploring unmapped caves in search of what is going wrong with the network hidden under your network.
The Harvard network currently does route AppleTalk (Phase II only), IPX, TCP/IP and DECnet. It works very reliably using a strong set of network addressing standards, heavy filtering in the routers and other good management procedures. (I suppose that it does help more than a little that the standards, filtering and procedures were designed and implemented by some people well versed in actual network management rather than by a person watching the fire from the sidelines -- i.e., not by me)