Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: ethernet interface perversity Message-ID: <870805102757.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 5-Aug-87 10:27:00 EDT Article-I.D.: KOYAANIS.870805102757.2.DCP Posted: Wed Aug 5 10:27:00 1987 Date-Received: Sat, 8-Aug-87 01:40:26 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 57 Date: Tue, 4 Aug 87 17:03 EDT From: "I am only an egg." *FLAME ON* It seems very dumb that I need at least one gateway node on one ethernet wire so that nodes on that wire can all talk to each other when some of the nodes run with different internet numbers. What does this have to do with Ethernet numbers? Judging by the rest of the message, you may be a little confused. My guess is that the reason you need a gateway is because the structure of the Internet implementation on the system(s) you are running requires it, and has little to do with Ethernet. I'm guessing that if your IP were convincible that A.B.C.0 and X.Y.Z.0 were both on the same cable, then A.B.C.D would send an ARP for X.Y.Z.W and communicate directly instead of sending it to a gateway that is on both A.B.C.0 and X.Y.Z.0. Although my problem is really an administrative one (I don't run the whole network here, I just get dumped on when it doesn't work), I don't see why I should be having a problem at all. I read ARP, rfc 826, and it talks about an address translation table. Note the use of the word TABLE. In this age of micro-processors it seems more than feasible to put some real table driven ARP intelligence out there so that interface boards can RESPOND TO MORE THAN ONE BLOODY ADDRESS. How many addresses? If you are going to relate hardware addresses with network protocols, you need to respond to at least as many addresses as there are protocols. One way to interpret the current situation is that we already have such a scheme! "Addresses" are 64 bits long. 24 are assigned to a hardware manufacturer, 24 are assigned by the hardware manufacturer (these two give the 48 bit Ethernet address we know of today), and 16 describe the protocol (the Ethernet type field). Using this interpretation, boards already respond to 64K "addresses." I suppose someone is going to ask how big the table should be. I don't know. Memory is cheap. It could easily be big enough to handle 16 or 32 network numbers. It could even be content addressable and thus FAST. Allowing for 16 or 32 network numbers (or more) should reduce the frequency of ether_type$ADDRESS_RESOLUTION packets to small for most cases. Again, only if you relate hardware addresses to protocol addresses, as DEC did. If the Ethernet were designed this way from the start, perhaps we wouldn't be in this bind. Unfortunately, there are at least two problems back then: (1) Content addressable memories weren't commodity, and (2) algorithmic translation only works well if the protocol address length is sufficiently smaller than the hardware address length. With L(IP) being 4 and L(Ether) being 6, this leaves 2 bytes to denote it as an IP address. Some people believe that IP addresses are too small; being bigger makes the problem worse. The practical problem is convincing every implementation to change at this late date. *FLAhavfonts