matt@oddjob.UChicago.UUCP (Matt Crawford) (05/17/84)
Well, thank-you to all those who responded, and here's the first
summary. By all means keep up the chatter, especially if I seem
to have missed an important point.
How many people out there on the net are considering
installation of some sort of local network? Maybe we can
stimulate more reviews and comments on hardware and
software products which have been tried.
---------------------------------------------------------
1. The first question was about mixing bords of different
manufacturers on the same network.
Steve Bellovin provides the following (paraphrased):
As long as all machines use the ethernet Address
Resolution Protocol ("ARP"), everythings fine. Unix 4.1c
and 4.2 use ARP. Basically, a machine using ARP
broadcasts a request meaning "Will the machine of
internet address so-and-so please send me its ethernet
address". When a response comes, then both machines know
each other's ethernet address.
When ARP is not used, the 4.1c/4.2 procedure is to
construct a guess at the destination ethernet address
from the high order 24 bits of the sender's 48-bit
ethernet address (which are manufacturer-specific:
there's the problem!) followed by the low 24 bits of the
destinations 32-bit internet address. The ways around
this are to either reprogram all machines' ethernet boards
address ROMs -- some boards allow this from software, but
the 4.2 drivers I have looked at don't support this feature
-- or to get modified ARP code which allows two extra
possibilities: 1) the insertion of some internet-to-
ethernet address translations "by hand" and 2) one
machine can answer ARP requests on behalf of another
machine. These modifications were posted on net.lan some
weeks ago by Bill Shannon at SUN.
John Quarterman says that according to rumor, DEC's DEUNA
won't talk to 3COM. Also that DEUNA tranceivers won't
connect to standard Belden cable. He suggests getting
Xerox tranceivers.
Russel Yount is mixing 3com and interlan with no problems.
2. About mixing protocol families on a single ethernet:
Nobody reports any problem in doing this as long as all
machines agree on which 16-bit "type code" in the
ethernet header represents which protocol. If everybody
sticks to the standards it should be OK. This doesn't help
machines of different protocols to talk to each other,
however. (see also item 4.)
Darrel Van Buer will be mixing PUP, IP, and XNS on the
same cable, using Xerox, 3Com and Interlan boards. Let
us know how it goes, hey?
3. Are there DECNET-to-IP translators or forwarders?
Who knows? Quarterman says "Work has been done on this
at LBL recently."
4. What is the status of Berkeley's "trailer encapsulation"
system with regard to other software systems?
There's an RFC about trailers (RFC893), but they are in
no way adopted as a standard. Not everybody is convinced
of the claims for their effect on performance. Since
packets with trailers are distinguishable by their ethernet
type code, a host which does not understand them should
simply reject them.
What I will recommend here is this:
We plan to have electrically separate ethernets in
different buildings with gateways to inter-building
connections. (Those may be carried on fiber optics --
lots of lightning in Chicago.) These gateways can then
have trailers disabled on the outside interface nad
enabled on the indoor side, if their software is BSD based.
Then we UNIX users in my department can keep our trailers
while the VMS and TOPS20 crowd do more-or-less as they
please. (Hmmm. Better be sure the gateways do
fragmentation properly...)
5. Should we get network numbers from SRI-NIC?
There's no agreement on this, and I haven't received a
reply from SRI yet. Nobody says we should just ignore
their numbering system, though.
6. There were no replies about the availability of the Excelan
(Exelan?) or other `smart' interfaces.
7. About VMS and TOPS-20 TCP/IP implementations:
Tom Campbell posted an item to the net to the effect the
Woolongong Group's product seemed to work fine under VMS
for communication to SUN's running 4.2
U. of Texas is said to be testing a TOPS-20 TCP product.
8. Concerning RFC's:
Bellovin:
"Write to NIC and ask for the Internet Workbook."
I have sent mail to NIC@SRI-NIC, but no response yet.
Looking through the index to RFC's, several caught my
eye as being relevant. Not all RFC's are actually
Requests For Comments. Many describe a standard which
must be obeyed by any internet implementation.
Quarterman and Van Buer pointed out that 899 is
a somewhat more detailed summary of 800-899, and
either 799 or 800 is a summary of 700-799.
------------------------------------------------------
Index to people cited:
Steve Bellovin ihnp4!ulysses!smb
John Quarterman jsq@ut-sally.arpa
Darrel J. Van Buer ihnp4!sdcrdcf!darrelj
Russell J. Yount ihnp4!vax135!cadre!ry
Tom Campbell LTN@USC-ECL.ARPA
[ To the people I list above: please correct me if I have made any
distortions. ]
___________________________________________________
Matt ARPA: crawford@anl-mcs.arpa
Crawford UUCP: ihnp4!oddjob!mattsmb@ulysses.UUCP (Steven Bellovin) (05/18/84)
From: matt@oddjob.UChicago.UUCP (Matt Crawford) Newsgroups: net.lan Subject: Summary #1 of ethernet information Message-ID: <238@oddjob.UChicago.UUCP> Date: Thu, 17-May-84 11:27:00 EDT John Quarterman says that according to rumor, DEC's DEUNA won't talk to 3COM. Also that DEUNA tranceivers won't connect to standard Belden cable. He suggests getting Xerox tranceivers. Not quite accurate. The 3Com *board* and the DEUNA *board* will talk just fine (I'm typing this in via an rlogin connection between exactly those two boards); however, the DEUNA *board* won't work with the 3Com *transceiver. The reason: the DEUNA meets the Ethernet 2.0 spec, while the 3Com transceiver is a 1.0 version -- and the DEUNA is so "smart" that it detects the difference and thinks there's a failure. In brief tests, I found that the 3Com board would work with a DEC transceiver, but there is some potential for trouble when mixing 1.0 stuff with 2.0 (my thanks to Rob Warnock for a long explanation on this point). --Steve Bellovin