[comp.protocols.tcp-ip] ethernet interface perversity

JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") (08/05/87)

     Hold it a minute.  I have received many responses from my query 
about network numbers on an ethernet.  Thank you for all the positive 
help for those who gave it but . . .

     I NEVER intended to complain or panic about IP.  I was in search of
verification of something and perhaps I phrased it poorly.  And yes I 
know that one ethernet wire can have large numbers of internet addresses 
floating around on it.

     We did some experimentation with our various ethernet interfaces 
and discovered that something which was hinted at in many of the 
responses seems to be true.  The ethernet interfaces we have will each
respond to only one internet number at a time.  I talked to Micom for
example and they even said as much for their np100 board. 

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

     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.

     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. 

*FLAME OFF*

     I'm just upset with the vendors for giving me ulcers again.  So 
what else is new :-(.

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

(Always vote.  There may not be anything you want to vote for, but
 there might be something you want to vote against.)

DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (08/05/87)

    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.

    *FLAhavfonts

mouse@mcgill-vision.UUCP (der Mouse) (08/15/87)

In article <8708050046.AA07011@ucbvax.Berkeley.EDU>, JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes:
> We did some experimentation with our various ethernet interfaces and
> discovered that something which was hinted at in many of the
> responses seems to be true.  The ethernet interfaces we have will
> each respond to only one internet number at a time.

If this is so it is a software problem.  I can see no reason why UNIX
(say) couldn't be set up to respond to ARP requests for more than one
IP address per interface.  The reason you need a gateway node is that
the software is not currently set up to do this, and thus you need
either a gateway or some serious low-level network code hacking to
allow multiple IP addresses per interface, or alternatively multiple
pseudo-interfaces which all send their packets out on the same physical
interface.

In other words - yes, it will work to have multiple IP networks on the
same cable.  However, you need either a gateway or some
currently-nonexistent software.

					der Mouse

				(mouse@mcgill-vision.uucp)

chris@GYRE.UMD.EDU (Chris Torek) (08/26/87)

(Apparently, someone wants a single Ethernet interface to respond to
ARP requests for several different Internet addresses.)  Jim O'Toole
did something like this under 4.2BSD, with an `IP magic' hook whereby
all IP packets for one IP address were forwarded to a user-level
program.  It takes about 15 minutes to figure out where and what to
write; we then had a user program that provided echo service a la
goonhilly-echo.arpa.

If all you want is for a 4.3 host to respond to multiple IP addresses,
this is even easier.  Configure some unused interface with the alternate
address:

	# ifconfig lo1 a.b.c.d		# or ifconfig sl1 a.b.c.d

Add it to your arp table:

	# arp -s a.b.c.d <your_ethernet_addr> pub

You should be set once the router picks up the address a.b.c.d from
interface sl0, or immediately if a.b.c.d is on the same `network'
as the 4.3 host as far as the sender is concerned.  I tested this,
and gyre (128.8.128.77) did respond to packets for 128.8.128.200.

roy@phri.UUCP (Roy Smith) (08/26/87)

In <862@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
# If this is so it is a software problem.  I can see no reason why UNIX (say)
# couldn't be set up to respond to ARP requests for more than one IP address
# per interface.

	The Kinetics KFPS Ethernet-to-AppleTalk bridge box (at least when
loaded with the Stanford KIP gateway code) is quite capable of responding to
multiple IP addresses using a single ethernet address.  If KIP can do it, I
don't see any reason why a UNIX kernel can't.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016