Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!ogccse!blake!oregon!jqj
From: jqj@oregon.uoregon.edu
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: 'fake arp' needed for ftp packet driver?
Message-ID: <202@oregon.uoregon.edu>
Date: 20 Feb 89 11:35:08 GMT
References: <8902160615.aa20239@louie.udel.edu>
Organization: University of Oregon
Lines: 44

In article <8902160615.aa20239@louie.udel.edu>, NEUMANN@AWIWUW11.BITNET
(Gustaf Neumann) writes:
> 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.

In general, ARP is *not* the only possible way to do address resolution
on a packet-oriented multiple-access network.  It isn't even the only
way it's done for IP: the ARPAnet, X.25-based IP networks,
IP-on-Appletalk, etc., all use their own techniques for doing
IP-to-physical address mapping.  A generic IP implementation needs
different mapping modules for different types of physical network.  The
packet driver spec allows one to ignore differences between Ethernet
interfaces, and in general to encapsulate in the driver differences
between interfaces, but only interfaces to networks that are a lot
like Ethernet.  Asking it to encapsulate IP-on-Netbios is asking too
much.

I think you really need to have an IP implementation that is structured
something like:
                       generic IP module
    broadcast packet net | p-t-p net | NETBIOS net | X.25   | ...
    module               | module    | module      | module |
    Packet | 3C501 | ...
    driver |       |

Note that the packet driver spec also can't do a very good job of
supporting networks with wildly different packet sizes from
Ethernet/802.3, wildly different notions of broadcast (even supporting
Ethernet multicast is strained), wildly different notions of
connectivity (does it support token ring source routing?), wildly
different notions of reliablility/throughput (how would you support IP
over multiple parallel X.25 virtual circuits?), or wildly different
ways to multiplex different protocols on the same network.

The packet driver is a very well designed spec for solving a very real
problem -- too many incompatible interfaces to Ethernet cards.  It can
be extended to interfaces to packet-switched networks that are a lot
like Ethernets, like 802.3.  I don't think you should try to use it to
hide differences between *all* interface cards, though.