Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!ATHOS.RUTGERS.EDU!hedrick From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges Message-ID: <8712110808.AA18036@athos.rutgers.edu> Date: 11 Dec 87 08:08:30 GMT References: <8712101742.AA23362@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 57 >Another test: see if the IP network number changes when the packet is >forwarded. A bridge must not change anything in the IP header, while a >gateway "must" change the IP destination address. One hopes the IP network number doesn't change when a gateway forwards a packet. The only thing that would normally change is TTL. The problem with trying to define these things is that there are hybrid beasts, e.g. bridges that allow the user to specify filtering using boolean operations on arbitrary bytes in the header. One could (and indeed probably should) set up such a bridge so it did not pass IP broadcasts. There seems to be a continuum possible. I have evidence that as time goes on, we're going to see a lot more points in that continuum. E.g. boxes that act as true gateways for IP packets and bridges for everything else, and bridges whose routing is as complex as an IP router, but applied to the MAC address instead of the IP address. I'd say that to qualify as an IP gateway by modern standards you need to process correctly most of the fields in the IP header, including decrementing the TTL, doing type of service routing, implementing source quench, source routing, record route, etc., and doing fragmentation. The claim that a bridge is all you need is equivalent to the following claims: - that everything in the IP header other than source and destination is unnecessary. - that it makes sense to build routing on top of an address with no internal structure. (That is, the MAC addresses have no pattern to them. IP gateways normally have to figure out a route to each network that they can reach. A bridge has to keep track of distinct MAC addresses. The thought of a gateway that knows every address in the Internet is absurd. So in effect the bridge's knowledge may be just a cache. But then you need a way to find a route initially. There are many such schemes, but they all run into trouble for very big networks.) - that ICMP functions, e.g. unreachable, and source quench, are unnecessary. (I don't mention redirects, because they obviously are unnecessary in a system using bridges.) In short, that the IP network layer is unnecessary. In my opinion, you can survive without a full network layer in a small, homogeneous system. So I have no problem with using LANbridges to connect a few Ethernets (though I wouldn't do it myself). But if the network layer is unnecessary, how come every protocol has one, and attempts to do routing at the MAC layer end up reinventing them (e.g. the IBM MAC-level source routing, and other ISO MAC-level network functions)? Again, I have no doubt that there are uses for LANbridges and similar gadgets. But at some point you have to draw the line, and start using the facilities that the protocol designers have supplied for you. The question is where that line is. One has a suspicion that when you start having a network of bridges running a full-scale routing protocol, there's a good chance you've crossed the line. On the other hand, there may be cases where for various practical reasons, such a product would actually be useful.