Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!AWIWUW11.BITNET!NEUMANN
From: NEUMANN@AWIWUW11.BITNET (Gustaf Neumann)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: 'fake arp' needed for ftp packet driver?
Message-ID: <8902160615.aa20239@louie.udel.edu>
Date: 17 Feb 89 07:08:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 53
X-Unparsable-Date: Thu, 16 Feb 89 12:05:39 WUT


While we are rolling our netbios packet driver starting from Russ
Nelson's work we ran into the following problem:

   Addressing is done in netbios via arbitrary symbolic names. For the
   time being we use the string 'TCPIP' followed by the binary ip
   address. Thus it is not necessary to use arps to send packets
   directly to a specific ip destination. When packets are sent over a
   gateway the netbios name should contain the gateway's ip address.
   This addressing scheme works fine with ka9q and Kelly MacDonalds
   direct (non packet driver) netbios interface, because the gateway's
   ip address is still visible at the driver level.

   The packet driver interface from ka9q knows essentially two
   types of address resolutions:  ethernet style (arp) and none
   at all.

   Our present version of the netbios packet driver is similar to slip
   (no arp); we just pull out the ip destination address from the
   packet passed to driver to construct the netbios name of the
   destination. This works fine without gateways. Obviously, with a
   slip style link address (none at all) the assumption is that every
   node can be reached without further addressing.

   The problem is that this scheme breaks when using gateways. The
   packet driver has no way address the gateway; the ip address we can
   pull out of the packet is the ip address of the final destination,
   not the address of the gateway.

   It seems that we are left with arp-style resolution, which is not
   really needed to determine the link address of the next node. The
   only reason to use arps is to force the ip layer to provide the
   route information. We would introduce a pseudo link level address
   (like the 6-byte ethernet address) which contains only the ip
   address. For send (and receive) operations we will have to strip (or
   provide) the equivalent of a ethernet header including type field.
   When the ip layer sends an arp we would immediately return an arp
   reply just containing the ip address in the link address field.
   During send we then can pull out the gateway ip address out of the
   'destination link address' and use it to construct the netbios name
   of the destination or gateway. Thus the netbios interface would look
   like an ethernet driver with arp and such.

   We hope to keep existing application happy by sticking to a standard
   ethernet header layout.

We are absolutely not amused about these weird contortions.
Does anybody have a simpler solution?

Eagerly awaiting your opinions

Michael A. Haberler       <mah@hpuviea.uucp>
Gustaf Neumann            <neumann@awiwuw11.bitnet>