ethernet interface perversity


David C. Plummer (DCP@QUABBIN.SCRC.Symbolics.COM)
Wed, 5 Aug 87 10:27 EDT


    Date: Tue, 4 Aug 87 17:03 EDT
    From: "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>

    *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.

    *FLAME OFF*



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:49 GMT