The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for July 1988 (348 messages, 243693 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 02:45:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Wanted: suggestions for an Internet Bibliography

In conjunction with the "Lessons of the Internet" session at SIGCOMM '88,
I am compiling a bibliography of published papers, books, etc. that
have interesting things to say about the Internet and the Internet
Protocols.  For example, books such as Douglas Comer's "Internetworking
with TCP/IP" and papers such as Lixia Zhang's on TCP Timers, or the
upcoming paper by Van Jacobson, are the kind of thing I want.  Also,
anything that provides real data on how the Internet is used, such as
the measured load on networks or gateways, is good.

I'm only interested in formally published papers (journals or
conference proceedings), technical reports, books, and other similar
items.  Informal publications, such as RFCs, IENs, and IDEAs, contain a
lot of useful information, but they are already well-catalogued,
there are an awful lot of them, and they aren't in most libraries.

I'm also only looking for papers that say something interesting about
the Internet.  A paper that simply proposes a protocol is not
particularly interesting; a paper that argues for a new or modified
protocol based on experience with the Internet is interesting.  In
essence, I am looking for the literature of the Internet as an
experiment, not the standards that define how it is supposed to work.

Please mail your answers to me (do not send them to TCP-IP); I will
make the results available (probably as an RFC or something like that).

Thanks
-Jeff

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 04:31:51 GMT
From:      rcc@k1bc.UUCP (Bob Clements)
To:        comp.protocols.tcp-ip
Subject:   TYPE L


Here's a late-filed followup on "TYPE L".

A couple of weeks ago there were some messages about "TYPE L".
There was some confusion as to what it was really for.  The comments
said that "L" stood for "Logical".  That's wrong.

When FTP was first invented there were a fair number of systems
on the (then brand-new) ARPANET which were not 8-bit (or 16 or 32)
machines.  In particular, there were 36 bit DEC machines and
36 bit Honeywell/Multics machines.   Each of these machines had
its own natural way of storing 8 bit bytes.  The storage technique
on the DEC-10 machines stored 32 bits in a 36-bit word, leaving
four unused bits at the right-hand end of a word.

So if you fetched a file from a DEC-10 in 8-bit mode, you could
get 32 of each 32 bits that way. But you might want all 36 bits,
as in a graphics file or some such. How to distinguish them?
The two types "I" and "L" were invented.  Type "I" for Image
said that you wanted all the bits.  The DEC-10 did some shifting
and gave you 72 bits (9 octets) from each two words.

On the other hand, if all you wanted was a stream of 8-bit bytes,
you didn't care about the extra four bits. You used TYPE "L",
which stood for LOCAL.  It meant that each machine would
store the bytes in the most efficient way for its own architecture.

Each TYPE was guaranteed reversible. If you stored the bytes in
TYPE I and got them back in TYPE I you would get the same file.
Similarly for TYPE L.  But in between, they might be stored
differently, depending on the machine hardware.  Un*x FTP's
implementor invented the "tenex" command as a shorthand for
TYPE L 8, since BBN-TENEX (progenitor of TOPS20) was the most
common operating system for DEC-10s on the ARPANET.

So there's today's ancient history lesson.  
Sorry to dredge all that up, but I wrote the first TENEX FTP
and I felt an urge to explain.

/Rcc
clements@bbn.com

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 07:10:20 GMT
From:      dannyb@kulcs.uucp (Danny Backx)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

In article <297@scolex> timon@sco.COM (timon) writes:
>
>		a puzzle for the net:
>
>AT+T chose not to define an addressing scheme for their
>TLI library.  Instead they require the user program to pass
>to the transport a pointer to an undefined address structure.
>This requires that the user program know what address structure
>the transport is expecting, and therefore makes each user
>program transport specific.

I don't think what you describe is a BAD thing, I think it is a good thing !
Suppose they had defined an addressing scheme in their TLI. In that case you
could only work with that addressing scheme.

What they do now isn't really transport specific. Your programs shouldn't be
using adresses. They should use host names, and transform these host names
into addresses using (e.g.) calls to a name server. These calls provide you
with something, and you can pass a pointer to that something to TLI.

So, in summary : apart from TLI, only the name server should know about
address structures.

  -- Danny

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Katholieke Universiteit Leuven 
 Tel: +32 16 200656 x 3544              |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@blekul60.BITNET         |        Belgium     

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 07:39:04 GMT
From:      richier@imag.UUCP (Jean-Luc Richier)
To:        comp.protocols.tcp-ip
Subject:   Re:  gateways and more-than-one-IP-net on one ethernet

In your mail
   "Re:  gateways and more-than-one-IP-net on one ethernet" dated 30 Jun,
you say :
/*
 * 
 * Get rid of the Level 2 Bridge(s).  Put IP routers in their place.
 * Don't have two networks on the same LAN.  I define LAN as a network
 * of hosts all sharing the same network address.
 * 
 * phil wood (cpw@lanl.gov)
 * 
*/
I agree with. I do not like this construction. However I a not the
administrator of this structure, and I have to live with it. I cannot
modify the basic concept: 2 LAN linked by a level bridge (When I look to
"classical" networks in France, I must be grateful to have at least a
TCP/IP LAN, and not the "good" solutions such as DECNET or SNA)
Therefore I must survive, and all I can obtain is to put software on some
of the machines of the LAN.
A good solution would be a a kernel patch to allow adding routes in the
kernel according interface and not proxy-arp deaIP addresses, or a proxy
arp daemon, to fake route protocols

Do you know of such solution. I know that somebody (Barry Shein at Boston
University) has written a proxy arp deamon for sun, but I have been unable
to contact him. Do you have seen any such software on some site??

Thank 
   Richier

richeir@imag.UUCP      richier@imag.fr

-- 

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      07/01/88 15:40:16
From:      Keith R. Hacke <M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Help on TCP/IP for HP
Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs?
We have more than 255 devices to ultimately tie together. HP's "TCP/IP" won't
do it (they only support class C addresses)! What other TCP implementations
will work on the HP? We will be using Kinetics boards with Synoptics ethernet
tranceivers built-in on the Macs. All the systems will be on ethernet

But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP
implementations exist for HPs?


Thanks
Keith Hacke
MCAIR Telecommunications

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 13:45:53 GMT
From:      hertzer@rusvx2.rus.uni-stuttgart.dbp.de.UUCP
To:        comp.protocols.tcp-ip
Subject:   comer's book in Germany

We paid 76,- DM (Deutsche Mark) for Comer's book with ISBN 0-13-470188-7

Joerg Hertzer
Rechenzentrum Universitaet Stuttgart
Allmandring 30
D-7000 Stuttgart 80
West Germany

Phone:   +49 711 685 5803
Telefax: +49 711 682357
Telex:   7255445 (univ d)

EARN/Bitnet: ZRFP@DS0RUS1I
EAN: HERTZER@RUSVX2.RUS.UNI-STUTTGART.DBP.DE

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 17:36:21 GMT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, richier@imag.imag.fr
Subject:   Re: gateways and more-than-one-IP-net on one ethernet


  route add NETWORK YOURADDRESS 0

where NETWORK is an additional network on the same Ethernet and
YOURADDRESS is the address of your machine's interface on
that Ethernet.  This declares the additional network as being
directly connected.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 17:44:08 GMT
From:      ERINA@ICNUCEVM.BITNET (Erina Ferro)
To:        comp.protocols.tcp-ip
Subject:   New OZONE mailing list!

A new computer conference is being formed. Please ignore this message
if you have already received it. Sorry for duplicates.
Please DO NOT ignore this message if it is the first time you read it!
PLEASE FORWARD THIS MESSAGE TO EVERYBODY COULD BE INTERESTED.

This mail is sent you by a group of researchers of the Italian National
Council (C.N.R.), working at the CNUCE Institute, in order to wake up the
sensitivity of people working in the scientific institutions about the
extremely serious problem of the pollution in the world.
As you certainly know, the hole in the ozone, the "hot-house effect",
the acid rains and the toxic waste are disasters provoked by man
by using the Nature as a "never-ending" resource.
Everybody can verify other effects of the pollution, in the cities,
in the seas, in the rivers, etc.
We think that the scientific community must create an opinion movement
able to force some decisions at political level.
We think we are still in time to do something to save Nature
with the help of everybody.
A computing conference is going to be opened and you can partecipate by sending
your ideas to the following address:
OZONE@ICNUCEVM.CNUCE.CNR.IT or
OZONE%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or
OZONE%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT

In order to be included to the list of the partecipants to the conference,
send a mail message to: LISTSERV@ICNUCEVM.CNUCE.CNR.IT or
                        LISTSERV%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or
                        LISTSERV%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT

containing only the following line:

SUB OZONE <first name> <surname>

If you need info about the computing conference send a mail message to the
same address containing only the following line:

HELP


Please, inform your collegues about this conference.

Thank you for your collaboration.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 17:47:33 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

in article <297@scolex>, timon@sco.COM (timon) says:
> 
> 
> 		a puzzle for the net:
> 
> AT+T chose not to define an addressing scheme for their
> TLI library.  Instead they require the user program to pass
> to the transport a pointer to an undefined address structure.
> This requires that the user program know what address structure
> the transport is expecting, and therefore makes each user
> program transport specific.

I think you missed something, as I did.  The "address" structure
in question is a standard "netbuf" structure.  To write a transport
non-spesific program you must do one extra step, but this is no
big deal; to whit:

When you issue "t_open" on the provider, you will receive a set of
"default" options for the provider, among these are the maximum
size, in characters, of an address and the maximum sizes of
the various data types.  These will dictate your address et al.

It is important to remember that the "addresses" refered to by
this are the _names_ assigned to the endpoint in question and
_not_ the physical address/serial_number of the board, to whit:
the address may be associated with different hardware at different
times.  As such addresses are arbitrary character strings, usually
numonic, with several "suggested guidleines" for safe naming.
The transport provider bears the burden of translating this
into a media-dependant address, and as such this is not the
problem of your software.  The media-address may also be retreived
through one call (I forget which...)

Because the options related to data-packet size et al are prone
to change after connection ("negotiable pramaters") to be
transport independant you should issue t_getinfo and adjust
your sizes accordingly.  This is _IMPORTANT_ when you are
using a hetrogenous machine types on the same transport, or when
you are bridging between network types.  t_getinfo returns
the "smalest restricted maximums" and therefore prevents
misshaps.

Like dialing a phone, the actual address you use depends on
what you want to reach, and therefore the user has to know
something about what is expected, but the lower-level group
and sub-group or serial-number issues are not really a valid
issue when you are writing the application.  If you are
writing a driver, great things can be done for you by aquiring
the network programmers guide (marginally helpful) and an
"unpublished" refrence you can get free with your source code
licence or by request (don't know how much) which I call the
magic book, and they _sometimes_ call the "porting rules"
though this is exactly what they are not, this doccument
is teh one which actually gets around to telling you things
you need to know but are only hinted at in the other
documentation.

"Conssume... enjoy...  Tomorrow is for the testing..."

Rob.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 18:47:47 GMT
From:      stever@videovax.Tek.COM (Steven E. Rice, P.E.)
To:        comp.protocols.tcp-ip
Subject:   Detachable power cords (was "15-pin ethernet connectors")

In article <489@cvaxa.sussex.ac.uk>, Aled Morris
(aledm@cvaxa.sussex.ac.uk) writes:

> . . .
 
> There are worse connectors...and those are the 3 pin mains leads,
> with absolutely NO RETAINER WHATSOEVER [god, they make me so ANGRY :-)]
> Forget about "ie0: ethernet jammed", one jerk (pun intended) and the
> machine goes down, lock stock and disk heads.  Proividing FSCK does not
> make up for saving 50 cents on a decent screw-in cable lock.

Detachable power cords with no locking mechanism are a safety factor.
A few year back, many "twist-lock" connectors were used for power cords,
but fires were caused by cords damaged when someone tripped over a cord
that was securely plugged into the wall on one end and locked into an
instrument on the other end.  Many instruments came crashing off tables,
under similar provocation.

Those whose business is safety generally consider aggravation preferable
to injury. . .

					Steve Rice

-----------------------------------------------------------------------------
* Every knee shall bow, and every tongue confess that Jesus Christ is Lord! *
new: stever@videovax.tv.Tek.com               [phone (503) 627-1320]
old: {decvax | hplabs | uunet | uw-beaver}!tektronix!videovax!stever

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 22:40:16 GMT
From:      M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke)
To:        comp.protocols.tcp-ip
Subject:   Help on TCP/IP for HP

Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs?
We have more than 255 devices to ultimately tie together. HP's "TCP/IP" won't
do it (they only support class C addresses)! What other TCP implementations
will work on the HP? We will be using Kinetics boards with Synoptics ethernet
tranceivers built-in on the Macs. All the systems will be on ethernet

But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP
implementations exist for HPs?


Thanks
Keith Hacke
MCAIR Telecommunications

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 88 22:43:08 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   new domain chart

A new domain chart is now available.  The domain system is much bigger
than it was last year (the previous chart).  To print the new chart
you need a postscript printer, paper cutter, tape, and a chair to
stand on so you can hang it up.  The file pathname is
  PS:<MKL>DOMAIN.PS
You can get it via anonymous FTP from SRI-NIC.ARPA or by sending
mail to SERVICE@SRI-NIC.ARPA and putting "SEND filename" in the
subject line.  It is a little over 100 kbytes.
An ascii list is also available as filename "PS:<MKL>DOMAIN.LIST".
-------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 88 01:22:01 GMT
From:      guy@gorodish.Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

> It is important to remember that the "addresses" refered to by
> this are the _names_ assigned to the endpoint in question and
> _not_ the physical address/serial_number of the board, to whit:
> the address may be associated with different hardware at different
> times.  As such addresses are arbitrary character strings, usually
> numonic, with several "suggested guidleines" for safe naming.

Guess again.  Check out the manual page for "t_connect":

	In "sndcall", "addr" specifies the protocol address of the destination
	transport user, ...

Protocol addresses are generally NOT names and are generally NOT mnemonic; if I
want to know that "seismo.css.gov" is 192.12.141.25, I have to look it up.
"seismo.css.gov" is the name of the machine; its protocol address in the
Internet protocol family is the byte string represented in printed form as
192.12.141.25.  (The byte string itself would probably contain 4 bytes with the
decimal values 192, 12, 141, and 25.)  The fact that the address is referred to
by a "char *" does not mean it is necessarily a string of printable characters;
it's just a string of bytes ("char" means several things in C, including
"byte").

There may well be protocols in which the protocol address is some form of name
that a human can deal with without too much pain, but neither the Internet
transport/network protocols nor the ISO transport/network protocols have
addresses of that form.

Translating "user-friendly" names to protocol addresses is generally the
responsibility of some layer of software other than the transport-layer or
network-layer protocol implementation.  Some protocol families have protocols
for doing this; the Internet protocol family has the domain name server
protocol, which is implemented atop transport-layer protocols (TCP or UDP).
Other mechanisms can be used, such as searching a file (the "host table") or
making queries to other sorts of name servers (e.g., a Yellow Pages server).

Presumably, if one had, say a procedure that took a host name, a service name,
and a protocols family name, and returned the appropriate byte string for the
address of that service on that host in that protocol family, one could write a
transport-independent program to access that service, assuming the service ran
atop several transport layers and didn't depend on particular features of
specific transports.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 88 03:06:24 GMT
From:      kgeisel@nfsun.UUCP (kurt geisel)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: SLIP, telnet and ftp on Mac

Phil Karn, KA9Q, has written an implementation of TCP/IP for amateur radio
experimenters to communicate over packet radio networks.  However, it also
happens to be a full implementation of TCP/IP, telnet, ftp, etc. with SLIP
and ether support.  I use it for everyday stuff because in my opinion it is
better than PC/IP and some other ports I have seen.  I remember something
something about a Mac version floating around.  Try calling his Opus BBS:
719-495-2061.

+--------------------------------------------------------------------------+
| Kurt Geisel, Intelligent Technology Group, Inc.                          |
| Bix: kgeisel                                                             |
| ARPA: kgeisel%nfsun@uunet.uu.net            US Snail:                    |
| UUCP: uunet!nfsun!kgeisel                    65 Lambeth Dr.              |
|                                              Pittsburgh, PA 15241        |
| Know Future                                                              |
 +--------------------------------------------------------------------------+

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 88 22:08:25 GMT
From:      winter@Apple.COM (Patty Winter)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: SLIP, telnet and ftp on Mac

In article <218@nfsun.UUCP> kgeisel@nfsun.UUCP (kurt geisel) writes:
>Phil Karn, KA9Q, has written an implementation of TCP/IP for amateur radio
>experimenters to communicate over packet radio networks.  However, it also
>happens to be a full implementation of TCP/IP, telnet, ftp, etc. with SLIP
>and ether support.  I use it for everyday stuff because in my opinion it is
>better than PC/IP and some other ports I have seen.  I remember something
>something about a Mac version floating around.  Try calling his Opus BBS:
>719-495-2061.

That BBS is actually Bdale Garbee's in Colorado Springs. Phil's code is
also available via anonymous ftp from louie.udel.edu.

Phil originally wrote the code in the DOS environment. A Macintosh port 
of it by Mikel Matthews has been around since early this year, and Mikel
is just releasing another version Right About Now. He's getting very busy 
with work, however, so some other hams with Macintosh programming 
experience are going to be helping with further improvements. Some of them
are on the net, so if you have any Macintosh-specific questions, you might
try asking them here. Phil doesn't have a Macintosh himself, so it's 
difficult for him to answer questions about the Macintosh version. 

I'm informally keeping a list of everyone who's planning on helping with
the Macintosh code, so if you want to know who else is doing what, feel 
free to drop me your name and net address. I'm *not* coordinating anything; 
the tradition with Phil's code is that anyone who wants to hack on it is 
utterly welcome to do so. I'm simply trying to keep track of who's doing 
what so that when someone has a specific question, I can say "write to 
so-and-so; he should be able to help." Not being a programmer myself, I
figure this is as good a way as any to make myself useful in promoting
this excellent software. (Yes, I use it myself over amateur radio. I
personally haven't used it on Ethernet or AppleTalk, but I know people
who have.)


Patty

                       Patty Winter N6BIS  [44.4.0.44]        
DOMAIN: winter@apple.com              UUCP: {decwrl,nsc,sun,dual}!apple!winter

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 88 04:02:33 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, mckenzie@LABS-N.BBN.COM
Subject:   Re: ISO VTP

If you'd like to submit an RFC describing ISO VTP, I'd be happy to
look at it.  As long as descriptions of ISO protocols are not
available online, I don't think they're going to make much headway in
the Internet community.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 88 17:14:13 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP

It would be nice if the NIC were to furnish the ISO documents
on-line.  Of course, this would require a significant amount
of storage, as they tend to be much more wordy than the
equivalent RFCs... :-)

-Philip

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 88 21:31:00 GMT
From:      hollandm@prlhp1.prl.philips.co.uk (Martin Holland)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Name Server for Local Site.


I am looking for a machine to act as a name server for our local site.
We have a large, diverse number of machines running TCP/IP. (e.g. IBM,
HP, SUN, Apollo, PC, VAX) over our local Ethernet.  Trying to keep all
the local Hostname Tables in step with each other is becoming a real bind.
We thought of using the IBM system as a name server as their implementation
of TCP/IP allows for a name server. However it transpires that a prerequisite
is SQL to contain the database. We don't have SQL and the cost is horrendous. 
Does anyone know of any name server software that can either be installed
onto one of the existing machines or perhaps a stand-alone system perhaps
based on a PC which isn't too expensive.
Thanks in advance.
M. C. Holland.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 05:02:00 GMT
From:      YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279)
To:        comp.protocols.tcp-ip
Subject:   Excelan/EXOS device driver under Untrix-2.0.


  We have a VAX-11/785 running Unix-4.3 (BSD) and using an EXOS card as an
interface to ethernet running the TcpIp protocol (in the dumb mode of EXOS).
We'll replace the BSD o.s. with Ultrix in the future. Has anyone ported the
EXOS device driver from BSD to Ultrix?
                                 Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
Israeli DECnet:  HUJICC::YEHAVI                       H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jul 88 09:24:50 EDT
From:      Samuel Macias <UDLA%TECMTYVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Subscribe
SUBSCRIBE TCP-IP Samuel Macias
Thanks
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jul 88 09:49:57 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: ISO VTP

>It would be nice if the NIC were to furnish the ISO documents
>on-line.  Of course, this would require a significant amount
>of storage, as they tend to be much more wordy than the
>equivalent RFCs... :-)

Also, they tend to be copyrighted (at least my copy of IS 7498 - the
basic reference model - is). And rights for copying are assigned to
the "local" national standards org (ANSI in the USA).
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 11:53:28 EDT
From:      Marc Kaplan <KAPLAN@ibm.com>
To:        tcp-ip@sri-nic.arpa
Subject:   RFC 1054 and multi-cast protocols
In rfc1054, S. Deering mentions "algorithms and protocols used within and
between multicast routers ... will be specified in separate documents"

Where/how can I get these "documents"?  And where/how can I contact
S. Deering.

Marc.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jul 88 15:55:33 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        kaplan@ibm.com
Cc:        deering@pescadero.stanford.edu, tcp-ip@sri-nic.ARPA
Subject:   re: RFC 1054 and multi-cast protocols

> In rfc1054, S. Deering mentions "algorithms and protocols used within and
> between multicast routers ... will be specified in separate documents"

> Where/how can I get these "documents"?  And where/how can I contact
> S. Deering.

Marc:

    Unless Steve has something up his sleeve, with the exception of his
paper to be given at the upcoming SIGCOMM, there are, as yet, no
documents specifying how multicast routing is done between routers.

    As we speak, there is very active work being done by BBN and
Stanford to test out two differents protocols and sets of algorithms
for routing between multicast agents.  The plan is to write up the
results of these experiments in August.

Craig
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue,  5 Jul 88 8:02 +0300
From:      Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU>
To:        info-vax@kl.sri.com, tcp-ip@sri-nic.arpa
Subject:   Excelan/EXOS device driver under Untrix-2.0.
  We have a VAX-11/785 running Unix-4.3 (BSD) and using an EXOS card as an
interface to ethernet running the TcpIp protocol (in the dumb mode of EXOS).
We'll replace the BSD o.s. with Ultrix in the future. Has anyone ported the
EXOS device driver from BSD to Ultrix?
                                 Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
Israeli DECnet:  HUJICC::YEHAVI                       H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 13:24:50 GMT
From:      UDLA@TECMTYVM.BITNET (Samuel Macias)
To:        comp.protocols.tcp-ip
Subject:   Subscribe

SUBSCRIBE TCP-IP Samuel Macias
Thanks

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 13:49:57 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP


>It would be nice if the NIC were to furnish the ISO documents
>on-line.  Of course, this would require a significant amount
>of storage, as they tend to be much more wordy than the
>equivalent RFCs... :-)

Also, they tend to be copyrighted (at least my copy of IS 7498 - the
basic reference model - is). And rights for copying are assigned to
the "local" national standards org (ANSI in the USA).

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 88 18:26:09 EDT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        tcp-ip@sri-nic.arpa
Subject:   large corporate networks
I am writing a paper on our practical experiences in managing Bellcore's
internal computer network. It now consists of several dozen Ethernets
interconnected by DEC Lan Bridges, Vitalink Translans, point-to-point T1
interlocation links multiplexed on dedicated DS-3 fiber, and a few IP
gateways. It now serves roughly 1,000 hosts, almost all of which speak
TCP/IP and related protocols.

I believe this to be one of the largest networks of its type, and I
would like to compare it to other corporate computer networks. Can
anyone give me a feel for what other large companies have in the way of
internal computer networks? I'd interested primarily in dedicated, high
speed (>= 56 kbps) networks with 500 hosts or more.  Slow speed "data
PBXes" (e.g., Datakit and similar toys) designed primarily for terminal
switching don't count.

Thanks,

Phil Karn
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 88 21:54:33 PDT
From:      suned1!efb@elroy.jpl.nasa.gov (Ev Batey-NSWSES-805/982-5881)
To:        tcp-ip@SRI-NIC.ARPA
Subject:   New list for Mot. SYS113x / V68 (ATT SysV) with TCP

I've looked and looked for living members of the Motorola System 113x cult
who run Motorola / AT&T System V Unix / V68 R2/R3.x and have TCP/IP or any
part of it.  We have several with CMC ENP-10 and are involved in development.
Unless someone knows of a prior existing list I volunteer to start this one.
To address the list mail to sys-1131.  For admin (ADD / DELETE)
sys-1131-request via these paths:

hplabs!motsj1!unicon!suned1!sys-1131
sun!tsunami!suned1!sys-1131
suned1!sys-1131@elroy.JPL.Nasa.Gov

 Everett F. Batey II         }   {UUCP:  sun!tsunami!suned1!efb
                                         suned1!efb@elroy.JPL.Nasa.Gov
 USNSWSES - Code 4V33        }   {ARPA:  efbatey@NSWSES.ARPA
 Port Hueneme,CA  93043-5007 }   {DDD:   805/982-5881 983-1220(ans)

 SoCalif SUN Local User Group - Vta-SantaBarbara-SanLuisObispo DECUS

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 16:46:39 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP

In article <8807051529.AA07979@ucbvax.Berkeley.EDU> 
 KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) writes:
>  [quoting P. Prindeville]
>>It would be nice if the NIC were to furnish the ISO documents
>>on-line.  Of course, this would require a significant amount
>>of storage, as they tend to be much more wordy than the
>>equivalent RFCs... :-)
>
>Also, they tend to be copyrighted (at least my copy of IS 7498 - the
>basic reference model - is). And rights for copying are assigned to
>the "local" national standards org (ANSI in the USA).

And they, in turn, assign the rights to sell the printed documents to
publishers like Omnicom, who make money selling ISO standards and
drafts.  Not likely to go on-line anytime soon when Omnicom is making
money selling printed copies.  Ah, when will we have royalty
procedures for on-line publishing??

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 17:37:48 GMT
From:      mfidelma@bbn.com (Miles Fidelman)
To:        comp.protocols.tcp-ip
Subject:   Network Time

FYI:

I recently came across a large military network that has an interesting
approach to maintaining network time: Each switching center has a Loran-C
receiver from which they derive time and clocking. Since the Loran system
maintains a very accurate clock (it's intrinsic to proper operation), this
all seems to work.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 17:42:03 GMT
From:      kumar@hpindda.HP.COM (Krishna Kumar)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on TCP/IP for HP

Mr.Hacke,

In response to your note:

>... HP's "TCP/IP" won't
>do it (they only support class C addresses)! 

Well, this certainly is news to me. I supported TCP/IP, on the 3000 for two
years, and there is no limitation on the address type supported. All three
classes are supported. You might want to read the manuals to get the facts.

>But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What other TCP
>implementations exist for HPs?

The "junk" TCP/IP transport (Phase II) has been used
successfully by HP's proprietary Network Services and recently by The
Wollongong Group to develop ARPA services (FTP, TELNET and SMTP). Note that
though the services were developed by Wollongong, the Transport is HP's
"junk" TCP/IP. This product which has been developed on the aforementioned
"junk" TCP/IP is called WIN/H3000 and you should contact Susan Trombetta,
The Wollongong Group, 1129 San Antonio Road, Palo Alto, CA 94303-4374.
Note that you still need HP's "junk" TCP/IP for the WIN/H3000
product to run. There are no other TCP implementations for the HP3000 other
than the "junk" TCP/IP.

>Has anyone networked HP computers (3000s) with IBM PCs and Apple Macintoshs?

HP is considered a leader in the marketplace for PC to mini integration. You
should contact the field/sales office close to you to find what solutions HP
has to offer.

Warm Regards,
Krishna Kumar,
Business Networking Division,
Hewlett-Packard, Cupertino, CA.

=============================================================================
Disclaimer: All opinions expressed are entirely mine and not those of HP.
=============================================================================

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 18:08:57 GMT
From:      wunder@sde.hp.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on TCP/IP for HP


   HP's "TCP/IP" won't do it (they only support class C addresses)!

This is not true.  I just counted 100 HP3000's on HP's class A
network.  There are another 30 on MILNET.  If the documents don't say
how to configure a class A, complain to your field office.  Many of
the NS/3000 documents assume a single LAN (for historical reasons),
but the software knows better.

   Has anyone networked HP computers (3000s) with IBM PCs and Apple
   Macintoshs?  We have more than 255 devices to ultimately tie together.

For IBM PCs, there is a pile of HP software, with names like
OfficeShare, PrintCentral, AdvanceMail, and Business System Plus.
These use TCP/IP over 802.3 (not Ethernet!), and some non-ARPA
services (i.e. proprietary protocols on top of TCP/IP).

Wollongong offers FTP, Telnet, and SMTP for the 3000.  Again, the link
layer only talks 802.3, not Ethernet.  Gateways from cisco will talk
802.3 to the 3000, and will forward the packets in Ethernet to systems
on the other side of the gateway.  HP-UX hosts set up for gatewaying
will do the same thing.  At this time, that is the only way to talk to
an Ethernet-only host.

As for Macs, I don't know.  I guess that Telnet from the Mac to the
Wolly package on the 3000 would be best.  The trick is getting an HP
terminal emulator on that Mac talking through Telnet.  We do have
several Macs in our department, but I don't know what we've learned
about connecting the two (I don't use either the Mac or the 3000).

   But, HP's "TCP/IP" (I don't think it is a real TCP/IP) is junk! What
   other TCP implementations exist for HPs?

I don't know of any other implementations for current MPE.  There was
a limited implementation for MPE-III, and that was last seen at White
Sands Missle Range.

Walter Underwood
HP Software Development Environments

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 5 July 1988 22:50:54 EDT
From:      Eugene.Hastings@morgul.psc.edu
To:        nsfnet@nnsc.nsf.net, tcp-ip@sri-nic.arpa, nwg@merit.edu
Cc:        pscnet@morgul.psc.edu, net-maintainers@te.cc.cmu.edu
Subject:   Network facilities out at PSC, Saturday July 9th
[Apologies to those who see this multiple times, but I figured it's better to
see it 3 times than none. Gene]

On Saturday, July 9th, the chilled water to part of the PSC facilities will be
shut off, interrupting all long distance communications save direct dialup and
GTE TELENET. The outage is scheduled to last from 8AM to 4PM, but we hope to
have some services restored as early as 2:00PM.

Affected systems are: 
	PSN#21, 
	PSC NSS (we may or may not be able to keep the IDNX powered), 
	PSC-GW (10.4.0.14/128.182.1.1), 
	PSC-GW2 (10.1.0.21/128.182.1.7/129.250.15.7), 
	PSCMU-FW (128.182.1.8/128.2.1.1),
	PSC Fuzzball (128.182.1.2), 
	BELADY (DECNET), 
	MI-Router, 
	Pitt-Router.

This means all communications in or out of Mellon Institute, INCLUDING: 
	Transit traffic between ARPANET-NSFNET-PSCNET-SURANET-PRPNET
	Any DECNET, LAT or TCP/IP between terminals or workstations at 
	 Mellon Institute and systems at Westinghouse; 
	ALL exterior TCP/IP traffic to Westinghouse, except from Alcoa; 
	ALL exterior DECNET traffic to Westinghouse, except from Pitt; 
	ALL transit PSCNET traffic (OSU, Case or UMich to ARPA or NSFNET); 
	Transit CCNET (DECNET) traffic to or from the University of
	 Pittsburgh;
	PRPNET traffic to PSC or the University of Pittsburgh;
	INTERNET mail to or from PSC;
	Domain service which relies on CHARON.PSC.EDU (128.182.65.6)

Downtime will start at 8AM, and while we hope to have some service back by 1:00
or 2:00, events will impose their own schedule.

Since this downtime has been imposed on us, we are going to take full advantage
of it, by performing our change to a class C network number on our routing
net. 128.182.1.x will be largely replaced by 192.5.146.x. The new assignments
are:
	PSC-GW.PSC.EDU  10.4.0.14, 192.5.146.1, 129.250.15.7
	PSC-GW2.PSC.EDU 10.1.0.21, 192.5.146.2
	PSCMU-FW.PSC.EDU 192.5.146.3, 128.2.1.1
	PSC.NSF.NET      192.5.146.42

	MI-RTR.PSC.EDU 192.5.146.6, 128.182.66.1, 128.182.15.1, 128.182.16.1,
			128.167.31.2
	PITT-RTR       192.5.146.7, 130.49.5.76

	NSS		192.5.146.254

We will be changing the name servers like mad to maximize confusion :-)


- - - - End forwarded message - - - -
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 88 07:37:33 HST
From:      bill@uhccux.uhcc.hawaii.edu (William J. King)
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  large corporate networks
WHY ARE WE GETTING TWO COPIES OF TCP/IP NEWTOWK MAIL??


-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 22:21:13 GMT
From:      rochester!ritcv!cxf@cu-arpa.cs.cornell.edu  (Charles Fung)
To:        tcp-ip@sri-nic.arpa
Subject:   How can I run Proxy ARP on SUN3 gateways
I need to run Proxy ARP on a SUN3/180 to support machines that don't know
about subnets yet. I saw some diffs for BSD4.3 source on the net but
unfortunately my gateway is a SUN. Has anybody out there hacked out some
mods for the SUN OS already? We are currently running 3.5.

Thanks in advance for any help.

---------------------------------------------------------------------------
                                      Charles Fung
                                      Systems analyst
                                      Rochester Institution of Technology
                                      School of Computer Science
                                      Rochester NY
                                      UUCP: seismo!rochester!ritcv!cxf
                                      CSNET: cxf@RIT
				      MILNET: cxf@CS.RIT.EDU
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 22:56:08 GMT
From:      ubvax!vsi1!wyse!mips!djl@ames.arc.nasa.gov  (Dan Levin)
To:        tcp-ip@sri-nic.arpa
Subject:   FTP performance figures

I am trying to get a handle on modern ethernet performance (ok, so so are
a couple of hundred other people...).

FTP binary mode was always one useful measure, and so I am after some numbers.
I would appreciate any results of the following command (or equivalent on your
system):

ftp> binary
200 type set to I
ftp> get /vmunix /dev/null  #(you V guys and gals can use /unix)
?????? bytes received in ?.? seconds (????? Kbytes/s)

I am most interested in commercial UNIX boxes running classical user-mode
FTP servers.  I need to know the hw/sw configuration of both ends of
the transaction.  What I am really after is the fastest implementation out
there.  I will post the results if I get enough to notice.

Just to get the ball rolling:

70 Kbytes/Sec.       About what an 11/780 running 4.2 would do
100 Kbytes/Sec.      Pretty good 680?0 UNIX box
??? Kbytes/Sec.      Pretty good modern UNIX box
1000 Kbytes/Sec.     Max practical Ethernet throughput
1250 Kbytes/Sec.     Max theoretical Ethernet throughput

Thanks,

-- 
			***dan

{decwrl,pyramid,ames}!mips!djl         djl@mips.com (No, Really! Trust Me.)
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 88 23:51:19 GMT
From:      mre@beatnix.UUCP (Mike Eisler)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

In article <118@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes:
>In article <297@scolex> timon@sco.COM (timon) writes:
>>This requires that the user program know what address structure
>>the transport is expecting, and therefore makes each user
>>program transport specific.
>
>I don't think what you describe is a BAD thing, I think it is a good thing !
>Suppose they had defined an addressing scheme in their TLI. In that case you
>could only work with that addressing scheme.
>
>What they do now isn't really transport specific. Your programs shouldn't be
>using adresses. They should use host names, and transform these host names
>into addresses using (e.g.) calls to a name server. These calls provide you
>with something, and you can pass a pointer to that something to TLI.

Designing a name server to serve two or more network processes using
the same transport protocol, but a different transport address scheme is
hard. For example RFS from AT&T relies on a name server that will run
on top of any TLI-based transport. When the name server is brought up,
it reads a file containing host names and TLI addresses in ASCII-hex
format. An RFS client must contact the RFS name server to get the address of an
RFS server. Well, what if an RFS client and RFS server both support TCP/IP,
but different implementations (eg. Lachman and Wollongong) with different
address formats? The address of the file server will be incompatible with
the client's TCP/IP implementation.

Obviously you can work around this by:
	- by not using a name server and instead supply addresses at mount
		(connection) time
		+ but you lose the nicety of a central name server

	- complicating the name server so that each server has
		multiple addresses. When a client contacts the name
		server, it could switch on the address of the client to
		match it to the correct version of the server address.

Life would have been simpler had AT&T defined addressing formats for
*each* the commonly used protocol suites (DoD/IP, OSI, XNS, DEC NET,
SNA, etc.), as well as establishing a registration service.

I would have also preferred that the TLI address be expanded from the
current opaque one-tuple to an opaque two-tuple. The first field would
be the address of "where" the peer is, and the second field would have
been the address of "what" the peer is. For example, this would make
implementing Sun's NFS over TLI easier, where you have to contact three
services (the "whats": PORTMAP, MOUNT, NFS) on the same host (the
"place") to establish an NFS "circuit."

	-mre

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 00:37:27 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   telnet...

I may be flamed at for suggesting this (and perhaps deservedly so), but
I really wish telnet had a "DON'T TELNET-ANYMORE" option.  Most telnet
server/client interactions happen at connection startup, and then they
stay the same until the connection closed.  Unfortunately, since telnet
options can occur anywhere within the data stream, both telnet processes
have to carefully examine every character to see whether it might be an
IAC.  I wish a host could set the connection up the way that it wanted,
and then say "that's it, no more telnet negotiations from me".  (Of course,
this would make the most sense in binary mode, so that you would not have
to worry about end-of-line nonsense either.)

Any comments?
Bill Westfield
cisco Systems.
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 00:51:03 GMT
From:      morgan@jessica.stanford.edu (RL "Bob" Morgan)
To:        comp.protocols.tcp-ip,comp.edu,comp.dcom.lans
Subject:   Network simulation for teaching?


I am preparing a class in Computer Networking for a group of students
at an industrial site.  I'm comfortable with deluging them with lots
of reading and lecture, but they're expecting some lab work as well.
It was said that they would like to "write a server."  I've taught
this material to undergrads before, and have observed that writing a
simple client (like a UDP echo client) from scratch can be challenging
enough.  The rub in this case is that the only machine to work with
for class purposes is *not* networked, apparently for security
reasons.

So: does anyone have any sort of network simulation code that would
allow students to observe/fiddle with/write network-like code on a
single machine?  It's running a BSD/Unix variant.  (How I can get the
code onto the machine is another story . . .).

Thanks,

- RL "Bob Morgan

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 08:40:00 EST
From:      "_GOLD::SWEENY" <sweeny%_gold.decnet@gold.bacs.indiana.edu>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   TN3270 for Suns & VMS Vaxen
What kinds of TN3270 products (commercial or 'public') exist for
Suns and VMS Vaxen?  If you have experience or knowledge of more
than one, how do they compare?  thanks bunches,
	Brent Sweeny
	Indiana University Academic Computing
	sweeny@gold.bacs.indiana.edu
	sweeny@iubacs (bitnet)

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 88 10:52:57 pdt
From:      Walter Underwood <wunder@sde.hp.com>
To:        tcp-ip@sri-nic.arpa, comp.protocols.tcp-ip
Subject:   Re: large corporate networks
   It now serves roughly 1,000 hosts, almost all of which speak TCP/IP
   and related protocols.

   I believe this to be one of the largest networks of its type, and I
   would like to compare it to other corporate computer networks.

Sorry, not even close.  The HP Internet has about 7500 hosts
worldwide (US, Europe, and Japan).  We have about 120 gateways, over
200 subnets, and nearly all links are 56Kbit or above.  Our link to
Japan is 19.2Kbits, but we plan to upgrade it.  We are testing a
couple of T1 links, and may be installing some cross-country T1 next
year, depending on funding.

In the US, most of our links are channels on T1s that were bought for
our voice network.  In Europe, we use 64Kbit X.25 service.  We also have
two satellite connections.

DEC and Xerox have corporate networks with over 10,000 hosts, but
they are not TCP/IP (DECNET and XNS, natch).  My guess is that the HP
Internet is the largest private TCP/IP network, where "private" and
"TCP/IP" are necessary qualifiers in order to say "largest".

The HP Internet was my first project after coming to HP.  It was all
modems and UUCP three years ago.

Walter Underwood
HP Software Development Environments
Palo Alto, CA
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 05:01:57 GMT
From:      oliveb!jerry@ames.arc.nasa.gov  (Jerry Aguirre)
To:        tcp-ip@sri-nic.arpa
Subject:   4.3BSD permanent arp entries arn't
We were concerned about one host spoofing another and I thought
that presetting the ethernet address in the ARP table would provide some
protection.  Granted that someone can spoof the actual ethernet address
but that requires more effort.

What I found was that it didn't work.  I used "arp -s" to set the
ethernet address and it went into the table.  The man page says you have
to specify "temp" or it will be permanent.  In actuality you have to use
the undocumented "perm" keyword to make it permanent.

But even when I marked it permanent the ethernet address would change to
the value of the system attempting to connect.  To test this I set the
ethernet address to a value one off from the real system value:

	arp -s jerry-oatc 2:60:8c:41:97:19 perm

I then attempted to rlogin from jerry-oatc to the system where the
permanent arp entry was set.  It suceeded and a subsequent arp showed
that the ethernet address, still flagged as permanent, had changed to
the correct value.

So, does "perm" mean always keep SOME value around or does it mean keep
the specified value around?  After we decide maybe we can update the man
page to reflect the "perm" keyword and describe what it really does.
				Jerry Aguirre
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 06:44:14 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP

Perhaps ANSI in the USA won't allow the ISO standards to be put on-line
(are they really that short-sighted?), how about an Internet site in
some other country: Canada is the obvious choice. Maybe Australia will
be on the Internet some day. What is the situation with making
material for which you have local copyright available to a world 
network?

Anyway we don't want the standard ISO documents on-line. They're
incomprehensible (except for the CLN documents which are nice). What
we want is a description of the protocols that us ordinary folk can
read.

Bob Smart

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 10:45:12 GMT
From:      mangler@cit-vax.Caltech.Edu (Don Speck)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 15 pin ethernet connector

I don't recall any trouble with the slide latches on Xerox 3 Mb/s Ethernet
transceiver cables.  The cable was a lot more flexible, though.

Don Speck   speck@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed,  6 Jul 88 16:30:34 EST
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Unix help...
I am in the process of venturing into the world of Unix. In trying to set
up an AT&T 3B, I have noticed that /etc/route and /etc/routed do not exist. 
Do these files have to exist in order to let the 3B know about the default
gateway. We can Telnet to all nodes on the Ethernet but have a problem with
connecting to any node on other networks. I have included the default gateway 
in the /etc/hosts and /etc/networks files without results. Any suggestions??
The 3B is running Unix V5. Also, I know there are lots of Unix books out there,
can anyone recommend a good one??

We are having problems receiving mail from the tcp-ip list. Please respond
to my address indicated below...thanks

Keith Heilner
Heilner_k@sitvxb
Heilner_k@vaxb.stevens-tech.edu
------------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 13:35:59 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  telnet...

Are you suggesting that one eliminate line mode and only use binary mode?  Or
are you suggesting that there be an integration of TELNET and the local systems
terminal driver?

Merton Campbell Crockett

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 13:40:00 GMT
From:      sweeny%_gold.DECnet@GOLD.BACS.INDIANA.EDU ("_GOLD::SWEENY")
To:        comp.protocols.tcp-ip
Subject:   TN3270 for Suns & VMS Vaxen

What kinds of TN3270 products (commercial or 'public') exist for
Suns and VMS Vaxen?  If you have experience or knowledge of more
than one, how do they compare?  thanks bunches,
	Brent Sweeny
	Indiana University Academic Computing
	sweeny@gold.bacs.indiana.edu
	sweeny@iubacs (bitnet)

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 14:32:03 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.edu,comp.dcom.lans
Subject:   Re: Network simulation for teaching?

One can write network applications local to a single BSD machine.
Just use the loopback interface and address (usually 127.0.0.1).

-Ron

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 14:38:02 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP


 >Also, they tend to be copyrighted (at least my copy of IS 7498 - the
 >basic reference model - is). And rights for copying are assigned to
 >the "local" national standards org (ANSI in the USA).
 
There is a loophole--draft standards may be distributed free of charge
in order to "further the cause of standardization."  There is precedent
for publishing draft standards as RFCs (8473 [ISO IP], for instance).
The trick is getting whoever has the machine-readable source for the
text to create straight ASCII for public consumption (and of course
the diagrams and such disappear).
 

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 14:40:15 GMT
From:      mm06@bunny.UUCP (Michael Murphy)
To:        comp.protocols.tcp-ip
Subject:   Are there IP-over-PDN X.25 implementations on SunLink X.25?


	Well, are there?  The IP-over-X.25 I mean is the one in
use by some csnet members ("x25net").  I am given to understand
that this is a different animal from DDN X.25.  Csnet has an implementation
for Unibus and Q-bus vaxes using ACC cards, but we won't be able to
use this.  There is a description of the protocol in a 1982 paper by
D. Comer and J. Korb "CSNET Protocol Software:  The IP-To-X.25
Interface"; I do not know where this was published.

	And now for the Obligatory Request: please mail directly
to me; I will post a summary of the replies.  

---
mike murphy	mm06@gte.com	{harvard,vaxine}!bunny!mm06

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 15:17:00 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Network Time

Miles,

Your network is hardly unique. MCI currently synchronizes about a dozen
plesiochronous "islands" in their digital telephone network using LORAN-C,
Sprint plans to do the same and AT&T plans eventually to use the Global
Positioning Satellite (GPS). LORAN-C provides timing to within some tens
of nanoseconds (for things like digital telephone synchronization) and
in principle can provide UTC verification to wihtin a couple of
milliiseconds. It does not provide a UTC timecode, which must be
disambiguated by other means. There are no LORAN-C receivers known to
me that are designed expressly for time service, as against position
service, although some may be capable of rho-rho navigation, which
requires a much more precise local clock than the usual hyperbolic
navigation.

Most folk are expecting GPS to become the system of choice. I do not
know if its designers are sensitive to the time-distribution issue.

Dave

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 16:47:31 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP

I assume you aren't repulsed by the idea of the ISO trying to
make money on standards?  I believe that they should be able to
charge a "handling fee" for printed copies, but if one eliminates
(or subsidizes) this cost, what is it to them?

-Philip

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 16:54:10 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  telnet...

Bill, 

There are Telnet controls (eg IP, AO, AYT...) that can appear at any time
in the stream, and a correct implementation must check for them.  An
implementation that does not is not implementing the Telnet protocol
(RFC-764).

Bob Braden

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 17:53:43 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   telnet...

A "DON'T TELNET ANYMORE" option can save you a whole lot on
efficiency.  I don't just mean taking a couple of conditionals out of
the main loop in a telnet server.

For example, on the ITS operating system, the supdup server was only
involved in starting up a connection.  Once the connection was
established, a system call tied the network connection to the
pseudo-tty that the command interpreter was on, and the server process
was no longer in the loop.  

If there was a way to make sure that no more telnet options processing
would need to be done, a similar thing could be done with telnet on
other operating systems, saving 2 process-switches per character.
					-Mark

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 19:01:30 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Network simulation for teaching?

Bob,  You are in luck.  A BSD implementation of TCP/IP should work just dandy
hooked up to no network at all in the physical sense.  All the code is written 
so that the source and destination processes can be on any machine including
the same machine.  You may have to fiddle with a config file to get it
to "loop back" properly, but it should all work.

Dan
-------

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 88 19:23:52 GMT
From:      zgel05@apctrc.UUCP (George E. Lehmann)
To:        comp.protocols.tcp-ip
Subject:   flooded with routing updates?

Tulsa, Oklahoma
Keywords: 


Has anyone else had problems with excessive routes showing up at their site?
On three occassions in the past thirty hours we have suddenly discovered
500-700 internet addresses in our Sun's route tables.  Things generally go
poorly until we kill off the router daemons, flush the tables and restart
/etc/in.routed.  Any comments or similar occurrences?

-- 
George Lehmann,  ...!uunet!apctrc!zgel05
Amoco Production Co., PO BOX 3385, Tulsa, Ok  74102  ph:918-660-4066
Standard Disclaimer: Contents are my responsibility, not AMOCO's.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 00:04:41 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP

>There is a loophole--draft standards may be distributed free of charge
>in order to "further the cause of standardization."  There is precedent
>for publishing draft standards as RFCs (8473 [ISO IP], for instance).
>The trick is getting whoever has the machine-readable source for the
>text to create straight ASCII for public consumption (and of course
>the diagrams and such disappear).
> 

Could something be done to generate a Postscript copy of it? Most people
can at least get access to such a device somewhere close by.... And it should
not be difficult to argue that distributing these documents across the
Internet *would* indeed further the cause of standardization. Who could ``do
something" to make this happen? ANSI? NBS?

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 88 08:33:41 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "George E. Lehmann" <apctrc!zgel05@UUNET.UU.NET>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: flooded with routing updates?
     ... we have suddenly discovered 500-700 internet addresses 

George,

Any hint of whether they are registered nets (have names in the file
NIC:<netinfo>hosts.txt)?  Which routing protocols are you running?  

     ... restart /etc/in.routed.

Who do you run RIP with?  "Who do you trust?"

Mike Brescia
BBNCC Gateway Dev.
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 88 13:01:58 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Network Management Documents

    As many of you know, two working groups of the Internet Engineering Task
Force have been working madly to finalize documents describing proposed
standards for network management in TCP-IP networks.  These efforts are
a result of the recommendations in RFC 1052.

    This note is to let you know that one of these two working groups,
the Management Information Base (MIB) Working Group, is about to report
two documents to the RFC editor.  The first document describes the
structure of management information, how management data is structured
and represented in the MIB.  The second document describes the required
management instrumentation of a TCP-IP system.  It is expected that
these documents will eventually become Internet standards.

    We are currently in the last stages of the comment period on the
documents.  Comments can be sent to me (as WG chair) until *Wednesday
July 13th.*  For those people interested in reviewing the documents, they
are available on-line by anonymous FTP:

    Structure of Management Information: 
	at SRI-NIC.arpa: <ietf>idea0023-00.txt

    Management Information Base
	at NNSC.NSF.NET: pub/idea0024-01.txt

*PLEASE NOTE* that at this stage in the comment period we are only accepting
comments which help us clarify definitions.  Unless you believe we have made
a truly gross technical error please do not suggest that we add additional
instrumentation or restructure the MIB.

Craig Partridge
Chair IETF MIB Working Group
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 06:43:36 GMT
From:      MRC@PANDA.PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet...

The performance problem you refer to (2 process switches/character) is
an artifact of the design of the Telnet server and operating system and
not a problem in the Telnet protocol itself.

In WAITS, Tenex, and TOPS-20, the Telnet server is in the same context
as the terminal driver (that is, it is part of the operating system).
A Telnet terminal is a special type of software terminal.  It is not a
pseudo-terminal because there is no controlling job.  It's more like a
physical terminal, but instead of the characters coming from a hardware
RS232 line scanner they're coming from the TCP/IP driver.

I believe a similar design is used by Unix; I don't believe Unix has a
Telnet server running at process level.
-------

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 88 11:08:37 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        William Westfield <BILLW@MATHOM.CISCO.COM>, tcp-ip@SRI-NIC.ARPA
Subject:   Re: telnet...
Since Bill Westfield asked for flames:     :-)

>I really wish telnet had a "DON'T TELNET-ANYMORE" option.  Most telnet
>server/client interactions happen at connection startup, and then they
>stay the same until the connection closed.  Unfortunately, since telnet
>options can occur anywhere within the data stream, both telnet processes
>have to carefully examine every character to see whether it might be an
>IAC.  I wish a host could set the connection up the way that it wanted,
>and then say "that's it, no more telnet negotiations from me".  (Of course,
>this would make the most sense in binary mode, so that you would not have
>to worry about end-of-line nonsense either.)
>
>Any comments?

Why use Telnet if you don't want it?  It certainly isn't that difficult
to keep scanning for IAC, and Telnet is certainly not a very complex
protocol.  And you always have the option of rejecting any changes in
options if you don't want to deal with them.

In what circumstances would you want to use this feature?  In a general
interactive environment, it would seem like you'd want to keep your
options open.

What concerns me, though, is that some Telnet implementations apparently
assume that no more options will be negotiated after the startup, and then
stop working when they encounter software that sends them, such as echo
toggles for password suppression.

Doug Nelson
Michigan State University
Computer Lab
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 88 14:10 PDT
From:      Dale Smith <DSMITH@oregon.uoregon.edu>
To:        tcp-ip@sri-nic.arpa, big-lan@SUVM.BITNET
Subject:   NI5210 in a Toshiba T3200?
I am getting ready to go out and buy a portable machine, a fast ethernet
board, and FTP software's LANwatch to use as a network monitor for our
campus network.  The major question is, does anyone have any experience
running the NI5210 in machines with a fast bus (12Mhz), and specifically,
is there anyone out there running an NI5210 in the Toshiba T3200?

Any comments on this proposed configuration are welcome.

Thanks,

Dale Smith, Assistant Director of Network Services

Internet: dsmith@oregon.uoregon.edu
BITNET:	dsmith@oregon.bitnet
Voice:	(503) 686-4394
USmail:	University of Oregon
	Computing Center
	Eugene, OR  97403-1212
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 09:59:06 GMT
From:      swb@TCGOULD.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 for Suns & VMS Vaxen

tn3270 is a product of Greg Minshall, not a class of programs (it
carries a Berkeley copyright).  It works fine on Suns.  The only
question is how you want your keys mapped.  We have a
"tn3270.sun3.bin.tar[.Z]" FTPable from devvax.tn.cornell.edu -- I'm
not sure how up to date the executable is but the keymapping is quite
nice (I believe Melanie Nesheim put it together before going to work
for Thinking Machines).  To be sure of getting an up-to-date
executable you should go to Berkeley.

For VMS, all I know of is that TWG distributes tn3270 to run under
Eunice.  There has to be something better somewhere, but all I find is
rumors.  I'd really like to hear about a native 3270 emulator for VMS
too.
							Scott

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 88 18:20:22 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        mar@ATHENA.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: telnet...
     A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency.  

Yes, making a direct path from the net driver to the terminal driver is much
more efficient.  You do need the escape route however.  10 years ago (or was
that when it was done in ITS) there was talk of having the telnet server throw
such a switch, which meant "pass everything transparently between terminal and
net until you see a special character".  That would be IAC in the direction of
net->term and one of BREAKSET in the term->net direction.  Once the escape
character was encountered the server would have to interpret again, until it
was satisfied to put the path in transparent mode again.

     If there was a way to make sure that no more telnet options processing
     would need to be done, a similar thing could be done with telnet on
     other operating systems, saving 2 process-switches per character.

Since there is always option processing going on, you just invoke the server
for the characters it needs to handle.  IAC-IAC doubling would be expensive,
but how often do you transfer the character 0xFF?

Regards,
Mike
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 12:33:41 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: flooded with routing updates?


     ... we have suddenly discovered 500-700 internet addresses 

George,

Any hint of whether they are registered nets (have names in the file
NIC:<netinfo>hosts.txt)?  Which routing protocols are you running?  

     ... restart /etc/in.routed.

Who do you run RIP with?  "Who do you trust?"

Mike Brescia
BBNCC Gateway Dev.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 88 21:11:33 PDT
From:      melohn@Sun.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: large corporate networks
In article <8807061752.AA04284@sde.hp.com> wunder@SDE.HP.COM (Walter Underwood) writes:
>Sorry, not even close.  The HP Internet has about 7500 hosts
>worldwide (US, Europe, and Japan).  We have about 120 gateways, over
>200 subnets, and nearly all links are 56Kbit or above.  Our link to
>Japan is 19.2Kbits, but we plan to upgrade it.  We are testing a
>couple of T1 links, and may be installing some cross-country T1 next
>year, depending on funding.
>
>DEC and Xerox have corporate networks with over 10,000 hosts, but
>they are not TCP/IP (DECNET and XNS, natch).  My guess is that the HP
>Internet is the largest private TCP/IP network, where "private" and
>"TCP/IP" are necessary qualifiers in order to say "largest".

Sun's Wide Area Network (SWAN), has HP beat; as of 2 minutes ago we
had more than 7700 registered IP hosts on more than 500 registered
networks and subnets worldwide. We are also most likely the fastest
growing private net as well, with a growth rate of some 200 nodes a
month!  We have links from 9600 baud up to T1 speeds, using Sun
Ethernet gateways, Sunlink Internetwork Routers, and Sunlink X.25
software to tie nodes from Japan and the far east to the US, Canada,
and Europe.
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 14:49:35 GMT
From:      hrp@rothko.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   telnet...

Mark,

But who is going to take care of NVT if not a telnet server?  A very
lightweight telnet server perhaps. . . .

				Hal

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 15:08:37 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet...

Since Bill Westfield asked for flames:     :-)

>I really wish telnet had a "DON'T TELNET-ANYMORE" option.  Most telnet
>server/client interactions happen at connection startup, and then they
>stay the same until the connection closed.  Unfortunately, since telnet
>options can occur anywhere within the data stream, both telnet processes
>have to carefully examine every character to see whether it might be an
>IAC.  I wish a host could set the connection up the way that it wanted,
>and then say "that's it, no more telnet negotiations from me".  (Of course,
>this would make the most sense in binary mode, so that you would not have
>to worry about end-of-line nonsense either.)
>
>Any comments?

Why use Telnet if you don't want it?  It certainly isn't that difficult
to keep scanning for IAC, and Telnet is certainly not a very complex
protocol.  And you always have the option of rejecting any changes in
options if you don't want to deal with them.

In what circumstances would you want to use this feature?  In a general
interactive environment, it would seem like you'd want to keep your
options open.

What concerns me, though, is that some Telnet implementations apparently
assume that no more options will be negotiated after the startup, and then
stop working when they encounter software that sends them, such as echo
toggles for password suppression.

Doug Nelson
Michigan State University
Computer Lab

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 15:30:53 GMT
From:      ted@gouldnl.UUCP (Ted Lindgreen)
To:        comp.protocols.tcp-ip
Subject:   Re: NAMED and IP forwarding

>What version of UTX is it that supports NAMED and IP forwarding?
UTX 2.0 and later supports IP forwarding (provided that you
have configured it in the CONFIGURATION file.
NAMED is supported on UTX/32S 1.1, UTX/32 2.1 and UTX/32 3.0
-- 
| Ted Lindgreen                           ...!mcvax!gouldnl!ted |
| Gould European Unix Support Centre             ted@gouldnl.nl |
| Maarssenbroek, The Netherlands     (USA) ...!gould!tlindgreen |

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 15:37:10 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP

>Could something be done to generate a Postscript copy of it? Most people
>can at least get access to such a device somewhere close by.... And it should
>not be difficult to argue that distributing these documents across the
>Internet *would* indeed further the cause of standardization. Who could ``do
>something" to make this happen? ANSI? NBS?
 
I would suggest talking to the chairperson of whichever ANSI committee
handles VTP.  To find out which committee, talk to the ANSI X3 Secretariat
at the Computer and Business Equipment Manufacturers Association (CBEMA)
in Washington, DC.  The chairperson could shed light on the current
state of the document and who the document editor is.
 
The document editor will likely be the only person who could provide
any machine-readable text, and the particular format is up to the editor
(since ISO takes camera-ready hardcopy for publication and doesn't
really care how it was generated).

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 16:18:34 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  telnet...

>From: braden@venera.isi.edu
>There are Telnet controls (eg IP, AO, AYT...) that can appear at any time
>in the stream, and a correct implementation must check for them.  An
>implementation that does not is not implementing the Telnet protocol
>(RFC-764).
This is precisely Bill's point.  He argues that in some applications
the higher level protocol knows that it will never generate or listen
to such controls after a particular point in the session, and therefore
could improve efficiency by saying "don't bother to check any more", but
can't unless the Telnet protocol definition were changed.

This seems to me to be one of many possible negotiable "performance
options".  One might also have negotiations that specified typical
chunk sizes for transmissions (e.g. size of the Unix write() buffer.
In no way related to MSS or anything like that, obviously) -- useful in
helping the receiver do buffer management, expected average data rate,
expected connection lifetime, ad nauseum.  I don't believe that Telnet
should implement any such negotiations because I see them all as minor
performance tuning that greatly complicates the protocol.  But I do
think they should be considered as a group since they all share the
characteristic that the applications protocol knows something about the
stream traffic pattern that doesn't help the TCP level very much, but
might help the remote applications level.

Now, a LAT-like protocol that multiplexed several virtual terminal
sessions (perhaps several telnet streams?) on a single sequenced packet
protocol connection.  THAT would be something to more seriously
investigate as a standardized performance enhancement for connecting
IP terminal servers to hosts.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 17:01:58 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Network Management Documents


    As many of you know, two working groups of the Internet Engineering Task
Force have been working madly to finalize documents describing proposed
standards for network management in TCP-IP networks.  These efforts are
a result of the recommendations in RFC 1052.

    This note is to let you know that one of these two working groups,
the Management Information Base (MIB) Working Group, is about to report
two documents to the RFC editor.  The first document describes the
structure of management information, how management data is structured
and represented in the MIB.  The second document describes the required
management instrumentation of a TCP-IP system.  It is expected that
these documents will eventually become Internet standards.

    We are currently in the last stages of the comment period on the
documents.  Comments can be sent to me (as WG chair) until *Wednesday
July 13th.*  For those people interested in reviewing the documents, they
are available on-line by anonymous FTP:

    Structure of Management Information: 
	at SRI-NIC.arpa: <ietf>idea0023-00.txt

    Management Information Base
	at NNSC.NSF.NET: pub/idea0024-01.txt

*PLEASE NOTE* that at this stage in the comment period we are only accepting
comments which help us clarify definitions.  Unless you believe we have made
a truly gross technical error please do not suggest that we add additional
instrumentation or restructure the MIB.

Craig Partridge
Chair IETF MIB Working Group

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 17:42:41 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Grist for someone's mill

If you send an ICMP echo request packet with IP Precedence = Flash Override
and no IP TOS flag bits set, you back a reply with:

Precedence = Routine from:
	vax.ftp.com		Ultrix 2.0
	gaak.lcs.mit.edu	hacked 4.3bsd
	aim.rutgers.edu		TWG VMS
	uunet.uu.net		Sequent Balance
	sun.com			SUNOS 4?

Precedence = Flash Override from:
	xx.lcs.mit.edu		TOPS-20
	big-blue.lcs.mit.edu	VM Wiscnet?
	ibm.com			VM (IBM's 5798 FAL?)
	ucbvax.berkeley.edu	4.3bsd?

Precedence = Flash Override & the Low Delay bit set from:
	oac.ucla.edu		UCLA MVS

James VanBokkelen
FTP Software Inc.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 17:52:35 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: flooded with routing updates?

In article <471@apctrc.UUCP> zgel05@apctrc.UUCP (George E. Lehmann) writes:
>Tulsa, Oklahoma
>
>Has anyone else had problems with excessive routes showing up at their site?
>On three occassions in the past thirty hours we have suddenly discovered
>500-700 internet addresses in our Sun's route tables.
>-- 
>George Lehmann,  ...!uunet!apctrc!zgel05

	One way to get lots of routes showing up in a host is to be on
an Ethernet with several gateways that are connected to different
regional or backbone networks.  If you want to do robust routing, your
host needs a route to each reachable net and that number is getting
pretty large today.

	We have a jvnc-net router and an arpa-net router and we have
hundreds of routes advertised by our jvnc-net router on a local
Ethernet that has a few hosts on it (soon to be moved).  Our arpa-net
router is quiet, but the default, so we save advertising all the
arpa-net routes.  There is only one subnet with the external gateways
on it, so there are only three routers that must keep these huge
tables.  Everyone else on campus can default to a router that is on
that subnet.


	Kent England, Boston University

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 17:58:17 GMT
From:      streeter@NSIPO.ARC.NASA.GOV
To:        comp.protocols.tcp-ip
Subject:   mailing list


Please add my name to your distribution list.  If there is an alternative
net address that this request should have gone to, sorry.  This is the only
address I presently know of.

     streeter@nsipo.arc.nasa.gov

Thanks, Roxanne

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 18:32:26 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   default broadcast address

A typical situation for many of us is a subnetted class B network
running a variety of IP-based hosts, including many that are 4.3BSD and
4.2BSD based.  In such an environment, one settable parameter on the
4.3BSD systems and others is the "broadcast address".   There are many
possible values for this; I am curious what other sites set it to.

It is clearly desirable for all machines on a given subnet to agree on
the broadcast address.  4.xBSD generates ICMP errors or erroneosly
forwards Ethernet broadcasts with IP addresses it does not recognize as
IP broadcasts; even the latest Tahoe 4.3BSD code recognizes as IP
broadcasts only {net,0,0}, {net,subnet,0}, 255.255.255.255, 0.0.0.0,
and the set broadcast address (and not both {net,-1,-1} and
{net,subnet,-1} even though both are legal!).  Earlier releases
recognize only a subset of these.  By getting everybody to agree you'll
eliminate all those erroneous ICMP unreachables and ARP requests for
your subnet broadcast address.  You might even avoid a serious
broadcast storm...

What is not clear is what in an imperfect world to try to get
everybody to agree to.  Some possibilities:
	{net,0,0}	the 4.2BSD standard, and still the SunOS 4.0
			default (according to "man ifconfig").  Some
			people use this for backwards compatibility
			with 4.2, but it is a violation of the IP spec
			and 4.2 implementations are disappearing (right?).
	{net,subnet,-1}	i.e. the subnet broadcast address.  The 4.3
			Tahoe default if you set a subnet mask but no
			broadcast address.  Not too good if you plan to
			change your subnet mask or if there is confusion
			over what it is (e.g. if you're trying heterogenous
			sized subnets).
	{-1,-1,-1}	i.e. the local broadcast address.  Some IP
			implementations insist on generating this address,
			so it might also be a reasonable choice of standard.
	{net,-1,-1}	i.e. the network broadcast address.  Has the
			advantage of being immune to mis-set subnet mask
			problems.  But not a good choice if you have
			routers that explode letter bombs and you want
			broadcasts to be subnet-local.

In the past, I've standardized on {net,subnet,-1}.  Charles Hedrick, the
first of us to have analyzed the broadcast storm problem, has in the past
recommended {net,0,0} as a concession to 4.2BSD [Chuck, am I taking your
name in vain?].

So, my questions:  (1) What have other sites standardized on?  (2) What
are the disadvantages, if any, of standardizing on the subnet broadcast
address?

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 20:08:17 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   RFCs, ISO DISs and ASCII copies...


	The trick is getting whoever has the machine-readable source for the
	text to create straight ASCII for public consumption (and of course
	the diagrams and such disappear).

(I will no doubt get flamed, but...)

There are obvious undeniable advantages to providing the RFCs, IDEAs,
etc in ASCII line-printer-ready format.  Yet there is also the need
to express things that can't be described adequately or as concisely
using just text.  I think it is time that we move towards using a
page description language for giving tables, state diagrams, etc.

-Philip

PS:	Can anyone think of a language?  :-)

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 21:05:28 GMT
From:      pwl@tc.fluke.COM (Paul Lutt)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Strange Network Traffic (Booting a Sun)

We recently purchased an Excelan LANalyzer board and Compaq PC for
analyzing our local ethernet.  While familiarizing myself with this
test instrument, I decided to watch my Sun workstation (a diskless
Sun-3/60) boot single user.  I'm seeing some interesting behavior that
I hope someone out in netland can explain.  Here is the scenario:

======================================================================

    1) The client workstation uses TFTP to boot the "boot" program.
       (Everything looks reasonable so far.)

    2) The boot program loads in vmunix through "nd" calls to the
       server.  (Still looks reasonable.)

    3) Vmunix starts up.  One of the first things it does is send out
       a very strange looking ARP request:

       Packet #1172: client -> ether-broadcast
                     ARP request (0.0.38.80 -> 0.0.38.80)

       The source and destination internet addresses are totally bogus.
       As expected, no ARP reply is ever received for this bogus request.

    4) The client then sends a reverse ARP request to find out its own
       internet address.  The server replies with the correct information.

    5) Now another funny packet.  The client sends out a strange ARP
       request:

       Packet #1175 client -> ether-broadcast
		    ARP request (client -> client)

       The client has just asked what its own ethernet address is!  This
       same request appears at least twice during the booting process.

======================================================================

Note that the workstation boots normally.  I'm just curious why such
strange requests are being made.

As a side note, there was a recent posting in comp.sys.sun stating that
some nd error messages seen during booting are due to net mask traffic
directed at the booting workstation.  I can confirm that this is
probably true.

During the booting sequence, the client sends a ICMP request for the
local net mask.  In our case, all the systems on the network using
TCP/IP try to respond.  Most systems start out by sending an ARP
request to the client to get its ethernet address so that they can then
send the mask.  During the trace I ran, upwards of sixty systems sent
ARP requests, followed by ICMP replies containing the net mask.  It
seems likely that such volumes of traffic directed at a workstation
might indeed exhaust the buffer pool.

Thanks to anyone who can shed some light on this.  I sometimes think we
were better off NOT knowing what was going on deep in the bowels of the
network.  :-)
--
	Paul Lutt
Domain:	pwl@tc.fluke.COM
 Voice:	+1 206 356 5059
  UUCP:	{uw-beaver,microsof,sun}!fluke!pwl
 Snail:	John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA  98206

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 21:10:00 GMT
From:      DSMITH@OREGON.UOREGON.EDU (Dale Smith)
To:        comp.protocols.tcp-ip
Subject:   NI5210 in a Toshiba T3200?

I am getting ready to go out and buy a portable machine, a fast ethernet
board, and FTP software's LANwatch to use as a network monitor for our
campus network.  The major question is, does anyone have any experience
running the NI5210 in machines with a fast bus (12Mhz), and specifically,
is there anyone out there running an NI5210 in the Toshiba T3200?

Any comments on this proposed configuration are welcome.

Thanks,

Dale Smith, Assistant Director of Network Services

Internet: dsmith@oregon.uoregon.edu
BITNET:	dsmith@oregon.bitnet
Voice:	(503) 686-4394
USmail:	University of Oregon
	Computing Center
	Eugene, OR  97403-1212

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 21:34:34 GMT
From:      hom@sjsumcs.UUCP (Hom Bahmanyar)
To:        comp.protocols.tcp-ip
Subject:   A host sending an ARP request to itself?

We have an ethernet in our Math & Computer Science Department that has a
Sequent Balance, a Convergent Technologies Miniframe, and more than 50
PC compatibles on it.  The Sequent and the PC's work perfectly on the
network (for example with PC-NFS); however, the Convergent machine has
some problems with the network:  Commands such as telnet and ftp to or
from the Convergent machine always fail but other commands such as rwho
and ruptime from the Sequent show the Convergent host as being on the
network.  Also the Convergent host never responds to pings from the
Sequent or the PC's.  After we checked all the network setup files and
couldn't find anything wrong, I wrote a simple ethernet monitor program
for one of the PC's that receives all the packets directly from the PC's
3c501 ethernet controller and displays them on the screen.  To my surprise,
I saw that the Convergent host was sending an ARP request about every 5
seconds to itself to resolve its own IP address.  That is, in the ARP
packet there were:
	sender's physical addr:		Convergent host's ethernet addr
	sender's IP addr:		Convergent host's IP addr
	target's physical addr:		0 0 0 0 0 0
	target's IP addr:		Convergent host's IP addr

But why would the Convergent host want to resolve its own address when
it already knows its ethernet address?

Any help you can give me on this will be greatly appreciated.

----

Hom Bahmanyar	(408) 924-5107
San Jose State University, Math & Computer Science Department
San Jose, CA 95192-0103
...!{sun,ames,pyramid,hplabs}!sjsumcs!hom

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 22:20:22 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet...


     A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency.  

Yes, making a direct path from the net driver to the terminal driver is much
more efficient.  You do need the escape route however.  10 years ago (or was
that when it was done in ITS) there was talk of having the telnet server throw
such a switch, which meant "pass everything transparently between terminal and
net until you see a special character".  That would be IAC in the direction of
net->term and one of BREAKSET in the term->net direction.  Once the escape
character was encountered the server would have to interpret again, until it
was satisfied to put the path in transparent mode again.

     If there was a way to make sure that no more telnet options processing
     would need to be done, a similar thing could be done with telnet on
     other operating systems, saving 2 process-switches per character.

Since there is always option processing going on, you just invoke the server
for the characters it needs to handle.  IAC-IAC doubling would be expensive,
but how often do you transfer the character 0xFF?

Regards,
Mike

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 22:33:59 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Are there IP-over-PDN X.25 implementations on SunLink X.25?

Yes, in a nutshell.  The method for transmitting IP packets over
X.25 requires: (a) the User Data field in the Call request contains
0xCC as the first octet and (b) the IP datagrams be sent over the VC
aligned on packet boundaries, with packets greater than the maximum
X.25 PDU being sent as complete-packet-sequences (ie. M bit on for
all but the last packet of the seq).

We use an ACC X.25 card to do this, and we speak to the original
X25net hardware, which is an Interactive Systems (INcard).  I have
heard of people using the SUNlink X.25 S/W (in PDN, *not* DDN
mode) with success.  In fact, SUN has their own internal internet
spanning North America and parts of Europe/Japan using IP over
X.25.

For more information, contact your SUN rep.

As for the Comer/Korb paper, it was published by CSNet.  It is
available via anonymous FTP from sh.cs.net, as the file "dn5"
(or something like that).  I can mail it to you if you need it.

Hope this helps,

-Philip

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 88 23:32:08 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   TCP support for Precedence

Wanted: Non-omnicompitent, non-omniscient TCP enhancer with newly-developed
TCP support for IP Precedence seeks another sophisticated real-world
implementation for testing, object: Negotiating a connection at Flash
Override or even higher.  Ability to speak IP Security (Old, Basic and/or
Extended) a plus.

Testing against my own code only (poking around the Internet hasn't yet turned
up a host that that will do this) lacks a certain satisfaction.  If there were
any Multices left, I would try there first, but alas...

James VanBokkelen
FTP Software Inc.
jbvb@vax.ftp.com
(617) 868-4878

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 88 01:26:31 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   review of Comer TCP/IP book

I acquired a copy of "Internetworking with TCP/IP" at Usenix and finished
reading it on assorted airplanes.  I have sufficiently mixed feelings
about it that I think it worthwhile to review it in detail.

Background:  I'm not a real TCP/IP guru, but might qualify as an apprentice
guru.  I learned about it originally by reading the RFCs (gak) and I work
on and maintain our local version, a variant of the KA9Q implementation.
I can't claim to be intimately familiar with all the details or to have
read the whole Protocol Handbook, but I know the outlines of most of it
and have combat experience with some of it.

The book emphasizes overall understanding of the protocols, although it
does cover a fair amount of detail.  The really fine points are punted to
the RFCs, for the most part.  It is meant to be useful as both a textbook
and a reference book, and generally strikes a happy medium.  It contains
coherent discussions of a number of issues that are hard to find in one
place otherwise.  Its appendix of implementation hints is worth the price
of the book all by itself, if you're going to be implementing TCP/IP.  It
is competently produced, with few botches (although some that remain are
serious, e.g. errors in RFC numbers in some of the Further-Reading sections
and a disastrous typo in Figure 4.1, the ONLY place where the decoding of
Internet addresses is explained precisely).

I wish I could recommend this book unreservedly.  Alas, I can't.

The fact is, this book has serious flaws.  First, most serious, and quite
possibly the cause of the others, is that it appears to have been put
together hastily as an expansion of a knowledgeable professor's skeletal
lecture notes.  The result is that while individual sections are okay,
they are not tied together well.  In particular, there are many cases
where something is referred to as if it had already been explained, when
in fact the explanation comes later or is entirely missing.  The appendix
on the Berkeley interface refers offhandedly to the fact that a connection
is characterized by both its endpoints, and hence more than one connection
can be active on the same port -- but this important and subtle concept is
NEVER discussed in the text proper!  The discussion of the name server
protocol suddenly starts using variable-length strings without explaining
how they are encoded... that comes later, in the section on the compressed
name format!  The chapter on ARP never does explain the PROTOCOL field.
These are not isolated examples; this sort of thing happens continually,
and makes the book very frustrating to read sequentially.  I already knew
enough to make this only an aggravating nuisance; a real novice would, I
think, find it very troublesome without external help.

Okay, so this hurts it as a textbook.  Is it useful as a reference book?
Same answer:  yes and no.  The trouble with it as a reference book is that
too many details are left out.  There are several references to the Karn
algorithm for RTT estimation, but it is never discussed; describing it
precisely and giving an outline of why it's good would take only a page
or two.  The three-way handshake for TCP connection establishment is
explained, but the handshaking for closing a connection is never really
explained; the state diagram from RFC 793 would take only a couple of
pages to show and tersely explain, but this is never done.  The urgent
pointer is brushed off in one sentence that does not really explain how
it works.  While it isn't really realistic to expect a book of this size
to replace the Protocol Handbook, this book would be an order of magnitude
more useful as a reference if it included 10% more detail.

A lesser, related problem is inconsistent level of detail.  The lower-
level protocols are explained in considerable detail, while the high-level
ones are crowded into a chapter or two that permits only a hint at the
overall flavor of a few of them.  The level of detail is inconsistent
even within discussions, with detailed message formats sometimes given
and then accorded only a quick hand-waving explanation.

One last annoyance in using the book as a reference is that the textbook-
oriented exercises at the end of each chapter sometimes raise important
points that one would hope a reference book would discuss more explicitly.
The implementation-hints appendix resolves some, but not all, of these
loose ends.

Overall, this book would be acceptable as a textbook for a course taught
by a knowledgeable professor who can fill in the gaps and smooth down the
rough edges, or as a self-study text for a bright student who knows
something about the topic already and has access to a copy of the Protocol
Handbook.  I cannot recommend it for self-study in general, and as a
reference its usefulness is limited.  It seems to me that many of the
problems arise from it being prepared in haste.  I would look forward
eagerly to a second edition, slightly expanded, thoroughly revised for
completeness, coherence, and consistency, and preferably tested on an
unassisted novice before publication.  That second edition could be a
truly superb first book on TCP/IP; the first edition is rather mediocre,
and is the clear choice only because there is no other.  It's really
unfortunate that the publishers are succumbing to the computer builders'
bad habit of letting their customers debug their products.

All that being said, this book *is* a lot better than nothing.  I learned
quite a bit from it, despite the problems.  If you are considering buying
it, either for yourself or a course, I would say "go ahead... cautiously".
-- 
                                     |  Henry Spencer @ U of Toronto Zoology
                                     | {ihnp4,decvax,uunet!mnetor}!utzoo!henry

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 88 09:37:41 PDT
From:      braden@venera.isi.edu
To:        kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa
Subject:   Re: flooded with routing updates?
	
		One way to get lots of routes showing up in a host is to be on
	an Ethernet with several gateways that are connected to different
	regional or backbone networks.  If you want to do robust routing, your
	host needs a route to each reachable net and that number is getting
	pretty large today.

This is not a requirement for "robust routing."  An Internet host should
only need to know a few default gateways, and take Redirects to find out
about the others.  This is just another example why hosts wiretapping
gateway IGP's is not a part of the Internet architecture, and is
often a bad idea.

Bob Braden
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 03:42:53 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Strange Network Traffic (Booting a Sun)

In at least some versions of the Sun software, the systems ended up
using an Internet address that was their system serial number.  This
was done during early stages of kernel operation, before the system
knew its Internet address.  Typically the serial numbers were small,
so you'd get an address that looked like 0.0.x.y.  In some releases,
this entry was never removed from the routing table.  Once the system
came up, it was interpreted as a default route.  I'm not sure whether
these things are still happening under current releases.  This is a
moderately dangerous practice.  0.0.x.y should be interepreted as
meaning "this net, host x.y".  It is certainly possible that there
could already be an x.y on the current network.  I'd be very surprised
if this practice continued into release 4.0

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 03:53:25 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet...

Unfortunately Mark is for once giving Unix more credit than it is due.
Berkeley's TCP/IP includes a telnetd that runs as a user process.  It
reads characters from a net connection and copies them into a pty, and
visa versa for the echo.  There is kernel support available that makes
this unnecessary, but as far as I know, the only vendor that has decided
to distribute this code is Pyramid (and it isn't released yet).  This
makes an enormous difference to responsiveness of a telnet connection
on a heavily loaded machine.  So it's worth doing on our Pyramid
timesharing systems.  It has not seemed necessary for our other
systems (primarily Suns), which are either single-user or have only a
few users.  In my opinion the best implementation (which is what our
Unix code does) is a combination of the two approaches.  There is a
telnet daemon.  It is used to do connection opening and closing and
handles all option and control sequence processing.  It uses an ioctl
to crosspatch the network to the pty.  The kernel then handles passing
characters as long as they are "easy".  When it detects an IAC from
the network (the beginning of a telnet option of some sort), the
crosspatch is broken and control returns to the daemon.  Thus the
kernel handles the normal case, for which performance is important,
but need not be complicated by negotiations, etc.  This code is
available, but so far no one has reported success in getting it to run
on machines other than the Pyramid and some other unnamed system which
I assume is not a VAX.  A number of people have taken copies of it and
not told me the results.  I'd be happy to send it to you, but only if
you are serious about doing the kernel work necessary to get it to
work, and telling me the results.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jul 88 09:27:14 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ISO VTP


>Anyway we don't want the standard ISO documents on-line. They're
>incomprehensible (except for the CLN documents which are nice). What
>we want is a description of the protocols that us ordinary folk can
>read.

Perhaps we can get Jon Postel to (re)edit them?
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 11:40:30 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   RFCs, ISO DISs and ASCII copies...

The Internet Engineering Task Force IDEA Series has adopted Postscript
as the page description language of choice.  While a submitter *must*
provide a straight ASCII document, he *may* also provide a postscript
version with it.

Mike

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 15:56:00 EDT
From:      "NRL::MCGUIRE" <mcguire%nrl.decnet@nrl.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   HELP ON TELNET?


I am looking for ANY help on using TELNET to connect to other computers
and to other networks (ie. BITNET).  I can't figure out all those
@, %, ! symbols in the mail address.  

I've heard about gateways, but don't know how to use them.

Can anyone help me out, or tell me where to find more information? 

Thanks.

T. McGuire


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jul 88 17:13:42 EDT
From:      Frank Kastenholz <KASTEN%MITVMA.MIT.EDU@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   TCP/IP/Ethernet on a Tandem
Does anybody know what is available viz-a-viz TCP/IP and Ethernet for a
Tandem TXP?

Suggest that y'all respond directly to me - i'll summarize on the net if
desired.

Thanks
Frank Kastenholz
EPPS/Eastman Kodak
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 13:27:14 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP



>Anyway we don't want the standard ISO documents on-line. They're
>incomprehensible (except for the CLN documents which are nice). What
>we want is a description of the protocols that us ordinary folk can
>read.

Perhaps we can get Jon Postel to (re)edit them?

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 14:51:36 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Grist for someone's mill

James,

Interesting. Try a nearby fuzzball (e.g. dcn1.arpa), which should return
exactly what you send. Now, try all the critters with something TCPish
and see what happens. Finally, slip in a source-route and see what comes
back. Glad you brought this up. We never have really pinned down the
specs in this area.

Dave

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 14:53:26 GMT
From:      goggi@rhi.hi.is (Gardar Georg Nielsen)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet

Does anyone know what changes I will have to make on NCSA Telnet Version 2.1
to fix the bugs for Microsoft C 4.0 or 5.0 compiling.

-- 
-----------------------------------------------------------------------------
Gardar Georg Nielsen                     Internet :  goggi@rhi.hi.is
University of Iceland                    UUCP     :  ..!mcvax!hafro!rhi!goggi

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 16:29:03 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP support for Precedence

James,

Mike St Johns, where are you now that we need you? A plea for security-
capable implementations has surfaced on these wavelengths before. Also,
try Ed Cain (caini@edn-unix.arpa), who might have some players at the
Protocol Testing Laboratory. I suspect you will have instant enthusiasm
and maybe even an implementation or two.

Dave

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 16:59:33 GMT
From:      kwe@BU-IT.BU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: flooded with routing updates?


	From braden@venera.isi.edu Fri Jul  8 12:35:55 1988
	[I said:]
		One way to get lots of routes showing up in a
		host is to be on an Ethernet with several gateways
		that are connected to different regional or backbone
		networks.  If you want to do robust routing, your host
		needs a route to each reachable net and that number is
		getting pretty large today.
	
	[Bob said:]
        This is not a requirement for "robust routing."  An Internet
	host should only need to know a few default gateways, and take
	Redirects to find out about the others.  This is just another
	example why hosts wiretapping gateway IGP's is not a part of
	the Internet architecture, and is often a bad idea.
	
	Bob Braden
	
Sorry.  I should have said [meant to say] "If you want to do robust
routing, your local router(s) need a route to each reachable net and
that number is getting pretty large [450 nets]."  We have a local
backbone and the router that talks to the external gateways really
needs to hear about all the nets that each external gateway knows
about.  It would be nice if it could find out reasonable metrics from
the external gateways, but that's a research topic.  For now, we
kludge configured metrics to get from egp to local and from jvnc
ciscoIGRP to local and thereby make decisions on a gateway basis
instead of a network basis.

	Of course, only one of our local backbone routers really needs
all the info.  All the other local routers can default to this local
authoritative router and the authoritative router can keep track of
450 nets split between the arpa-net and the regional-net.  We have a
strictly hierarchical backbone, so a default works nicely.  Now the
authoritative router defaults to arpanet but takes all the jvncnet
routes it can get.

	I have a problem with the statement "host should only need to
know *a few* default gateways".  How does a host learn about more than
one default gateway?  How does a host dynamically learn anything about
routers without participating in the gateway protocol??  [I know the
answer "ES-IS protocol".  I mean today.  now.]

	Kent England, Boston University

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 17:59:23 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: flooded with routing updates?


	
		I have a problem with the statement "host should only need to
	know *a few* default gateways".  How does a host learn about more than
	one default gateway?  How does a host dynamically learn anything about
	routers without participating in the gateway protocol??  [I know the
	answer "ES-IS protocol".  I mean today.  now.]
	
		Kent England, Boston University
	
Kent,

A proposal for an ICMP Gateway Discovery Query/Report pair has undergone
extensive review in an IETF WG, and is nearing (I hope!) RFC stage.
There is also a trial implementation underway.  So, this problem should
be solved soon. Meanwhile, we have to depend upon host configuration
information, as we always have.

Bob Braden

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 18:30:49 GMT
From:      lm@laidbak.UUCP (Larry McVoy)
To:        comp.protocols.tcp-ip
Subject:   Re: review of Comer TCP/IP book

In article <1988Jul8.012631.15892@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

[ Henry's notes about Comer's book being so-so but better than nothing ]

>                                     |  Henry Spencer @ U of Toronto Zoology

For what it's worth, I had a similar impression to the book.  I've ported
TCP/IP so I have some knowledge but there is a lot I was hoping to have 
cleared up by Comer's book.  Unfortunately, I too am finding myself resorting
to the RFC's for much of the detail.  I'd say the book is a good thing to
skim when one is starting out, but is a long way from being "the" reference.

It's unfortunate, in a strange sort of way, that Prof. Comer did such an
outstanding job with the Xinu books - it lead us to expect only the very
best and perhaps made us a bit more critical of this offering than we 
otherwise might have been.
-- 

Larry McVoy      (laidbak!lm@sun.com | ...!sun!laidbak!lm | 800-LAI-UNIX x286)

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jul 88 23:33:47 CDT
From:      David Lippke <LIPPKE%UTDALVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP simulator wanted
We've recently put some effort into benchmarking various combinations of
  TCP/IP software and ethernet controllers on IBM mainframes running VM.
  The results of this testing have now been analyzed to death and we're
  preparing for a second series of tests later this year.

Most of the performance problems of the current software/hardware in this
  area are related to a long latency from packet reception to the processing
  of that packet by the software (i.e., this latency tends to be much
  greater than the transmit-commit to network latency).

I'm currently trying to quantify the effect that cutting one latency or
  another will have on TCP performance.  I think I may be homing in on
  some decent conclusions and I plan on creating some live tests,
  but it would be much easier to try out my theories if I had access
  to some software which would simulate two interconnected TCPs.

I'm not after anything too complex; something that will simulate a single
  established connection and let me adjust various parameters would be a
  useful starting point.

Anyone have something even remotely applicable?

Kind Regards,
              David Lippke
              The University of Texas at Dallas
              214-690-2632
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 19:56:00 GMT
From:      mcguire%nrl.DECnet@NRL3.ARPA ("NRL::MCGUIRE")
To:        comp.protocols.tcp-ip
Subject:   HELP ON TELNET?



I am looking for ANY help on using TELNET to connect to other computers
and to other networks (ie. BITNET).  I can't figure out all those
@, %, ! symbols in the mail address.  

I've heard about gateways, but don't know how to use them.

Can anyone help me out, or tell me where to find more information? 

Thanks.

T. McGuire

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 20:12:31 GMT
From:      ut-emx!boerner@sally.cs.utexas.edu  (Brendan B. Boerner)
To:        tcp-ip@sri-nic.arpa
Subject:   pc network security

Hello,
What can anyone tell me about PC Network security concerns?  i.e.
Suppose I have an IBM PC Token-Ring network.  What do I have to worry
about?  And if the net is hooked up to our campus Ethernet (actually
Broadband), what other security issues raise their ugly heads?

I am not concerned with the problems associated with one particular
type of PC network, so if you have experience with anything of this
nature, or if you know of people who did, for any PC network,
please let me know.

If I get anything interesting, I will summarize.
Much obliged.

Brendan
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 20:27:55 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Netman & Internet Engineering Task Force

Can someone from one of these groups explain the organizational
relationship, sponsorship, membership, reporting relationship,
liasons with other standards organizations, and any other info
that might be useful for someone or some organiztion desiring to
stay up-to-date, obtain documentation, and possibly work his/her
way into a participating role?


Larry Swift                     UUCP: {peora,uunet}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981           She's old and she's creaky, but she holds!

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 21:13:42 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP/Ethernet on a Tandem

Does anybody know what is available viz-a-viz TCP/IP and Ethernet for a
Tandem TXP?

Suggest that y'all respond directly to me - i'll summarize on the net if
desired.

Thanks
Frank Kastenholz
EPPS/Eastman Kodak

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 21:16:56 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

I recomend AGAINST using the subnet in the broadcast address.
This makes it impossible for systems to send a broadcast until
after they know the proper netmask.  If the system is a diskless
machine trying to boot off the net, it would normally do this by
sending a broadcast ICMP MASK REQUEST or BOOTP.  But it can't do
this until AFTER it knows the broadcast address...

Using the local broadcast address (-1, or 0) seems the best solution,
though it seems to annoy older unix systems.

Bill Westfield
cisco Systems.
-------

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 21:55:08 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  A host sending an ARP request to itself?

It's probably trying to tell the world that it itself (its own IP address)
is at its own Ethernet address... just in case they forgot or otherwise
got confused.  It could also be checking for impostors on the same net,
claiming to be the same IP address as its own.

ARP request packets don't just list the requested IP address;
they also include the requestor's IP and link-layer (e.g. Ethernet) address.

A feature of the algorithm in RFC 826 is that, on receiving an ARP request,
you check whether the -sender's- IP address is in the local ARP table.  If so,
update the table to associate [sender-IP-address, sender-link-layer-address].
(And, of course, also check whether to respond to the ARP request, but that's
another matter.)

This makes it possible to change a host's link-layer address
and notify the world of the fact just by broadcasting any ARP request.
Anyone who thought they knew what the address was will automatically
update their tables.

(Of course it also makes it possible for any bozo who can generate a
bogus ARP packet to cut you off from the world.  This might be a rationale
for sending ARPs periodically, though 5 second intervals seem pretty extreme.)

Further, ARPing for your own IP address should bring a response from anyone
who thinks they're at that address too.  BSD systems print
"duplicate IP address!!" messages when they detect this situation.

	Stuart Levy

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 22:37:14 GMT
From:      tucker%vger@XENURUS.GOULD.COM (Tim Tucker)
To:        comp.protocols.tcp-ip
Subject:   Re: NAMED and IP forwarding

>What version of UTX is it that supports NAMED and IP forwarding?
>UTX 2.0 and later supports IP forwarding (provided that you
>have configured it in the CONFIGURATION file.
>NAMED is supported on UTX/32S 1.1, UTX/32 2.1 and UTX/32 3.0

I have used a copy of UTX/32S 1.1 and it doesn't support NAMED or EGP.

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 88 23:08:16 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

in article <836@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
> Xref: nusdhub comp.dcom.lans:310 comp.protocols.tcp-ip:951 comp.protocols.iso:39
> RFS server. Well, what if an RFS client and RFS server both support TCP/IP,
> but different implementations (eg. Lachman and Wollongong) with different
> address formats? The address of the file server will be incompatible with
> the client's TCP/IP implementation.

Well, if this is the case, or even if it's not, every protocol
suit served by the "listener" (part of the TLI et. al.) possesses
a unique "service code" which uniquely identifies that service
on that protocol.  When the requests come throught the listener
they are sorted out by code, protocol (i.e. TLI driver), and address.

The address formats (primitive) are handled by the kernel driver
(if it wernt, the TLI would never _get_ the message) and the
address names (user-level) are passed, designated, and controled
by the systems-adminstrators, and as such can be and are "character
strings" in free form.

When you spesify an address like 255.255.255.255 (for instance) the
TLI library passes a "request for translation" down to the driver.
For TCP/IP (I thing) this would become two couplets of byte values;
to whit: FF FF FF FF.  For STARLAN they would either be returned as
the character string (unaltered) or an 802.3 tri-couplet (6 byte)
address, I dont remember which.  More or less at this point you don't
ever touch this address again.

You (the application) don't need to know the addressing format for
your provider any more than you need to know the sixteen tones
used in DTMF dialing to use a Touch-Tone(r) phone.  You provide
the free-form address as a string, and the rest of the system does
it's best to make the connection you want, but like the PSTN
(Public Switched Telephone Network) if you don't know the number
you want, you probably arn't gonna get through!

By providing it as a "string" of ascii characters, the user and
programmer dosn't have to know if the provider is expecting
a string, binary, hex, or whatever, the TLI driver for that
device _HAS_ to know that, so the two workout the difference
without you having to get your hands dirty.  N'cest pa?

(besides how else than as a string are you going to generate 0.0.0.0 ?)

Rob.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 03:21:10 GMT
From:      grzesiak@a3bee2.UUCP (John Grzesiak )
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   EXELAN.....


 If someone could help me here.... I have a couple of boards that I'd
be interested in knowing some history on , amoung other things. The first
board I would be interested in knowing about is Exelan's EXOS203 for q-bus.
I have a couple of these in my q-bus system and have never had the need
to use them. I have tried to find information on Exelan , but have had no
luck in finding an address. Also I would like to find cabling and driver
board specs for these. The second board (or more accurately.board set) is
the 3-COM ethernet boards for q-bus. I have 2 sets of these in a q-bus
unix system, and have never used these. What I need here is cabling and
tranceiver info. In any case any tips or manuals, specs or whatever else
anyone knows about these would be appreciated. Thanks in advance.

John Grzesiak
    at yale!spock!a3bee2!grzesiak

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 03:41:20 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: default braodcast address

Hi.

Those considering this issue, please read RFC-1009 pages 14, 15, 35, 36,
44, 45.

--jon.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 03:49:22 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO VTP


     It is so tempting to simply flame at you two (Kastenholz and Smart)
     but rather than do so I will explain, calmly, the errors of your
     ways.  Consider this a pronouncement of The Truth. 

     It is a mistake to, as Robert Smart suggests,

>	Anyway we don't want the standard ISO documents on-line. They're
>	incomprehensible (except for the CLN documents which are nice). What
>	we want is a description of the protocols that us ordinary folk can
>	read.

     re-edit the ISO documents and then distribute them.  The ISO
     documents use a consistent OSI terminology and are perfectly
     comprehensible from the basis of that framework.  Three years ago I
     was unable to read an OSIfied document and make sense out of it.
     Today I am able to, and can tell you that the network layer
     documents aren't really any better or worse than any of the other
     OSI documents with respect to readability.  In fact, if you want to
     read a truly outrageous document, get a copy of "The Internal
     Organization of the Network Layer" (the IONL), which will convince
     any thinking person that the TCP/IP architecture is vastly superior
     to the full-blown OSI network layer.

     The reason why the ISO documents are copyrighted is not so Omnicom
     can make a paltry sum of money on each standard (the ~$1000 figure
     is for their update service in which they filter the output of
     standards bodies for you and send you the things that you are
     interested in seeing).  The real reason is so that

	NO ONE WILL EDIT THEM AND MAKE THE CLAIM THAT THE RESULT IS
	RELATED TO THE ORIGINAL STANDARD

     The problem with having anyone edit them is that you lose meaning
     and misinform.  OSI documents make sense once you learn the lingo.
     It is more formal than the language used in the DARPA/NSF Internet
     community (plain English) but it is not as bad as the way the Inca
     of Peru used to write things down (they stored information on
     strings, carefully knotted in a specific manner and with colored thread).

     Now, having told you The Truth, keep in mind that I think that it
     would be nice for someone to write a moderately lengthy explanation
     of what each OSI standard is saying, and to write that in a more
     easy to understand format.  It would be less accurate, but would be
     useful for getting across the gist of things.  However, editing
     standards and the like is simply the wrong way to do it.

/mtr

ps:  The word "OSIfy" is a new word that I invented earlier this year.
     The precise meaning is:

	"to obscure, to make unclear for no good reason"

     It is often used in the context of the output of standards
     committees, although its use is not limited to committees which
     produce OSI standards.  In fact, some might claim that MILSTD 1778
     is an OSIfied version of RFC793.

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 04:33:47 GMT
From:      LIPPKE@UTDALVM1.BITNET (David Lippke)
To:        comp.protocols.tcp-ip
Subject:   TCP simulator wanted

We've recently put some effort into benchmarking various combinations of
  TCP/IP software and ethernet controllers on IBM mainframes running VM.
  The results of this testing have now been analyzed to death and we're
  preparing for a second series of tests later this year.

Most of the performance problems of the current software/hardware in this
  area are related to a long latency from packet reception to the processing
  of that packet by the software (i.e., this latency tends to be much
  greater than the transmit-commit to network latency).

I'm currently trying to quantify the effect that cutting one latency or
  another will have on TCP performance.  I think I may be homing in on
  some decent conclusions and I plan on creating some live tests,
  but it would be much easier to try out my theories if I had access
  to some software which would simulate two interconnected TCPs.

I'm not after anything too complex; something that will simulate a single
  established connection and let me adjust various parameters would be a
  useful starting point.

Anyone have something even remotely applicable?

Kind Regards,
              David Lippke
              The University of Texas at Dallas
              214-690-2632

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 07:51:57 GMT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

I don't think there is a single answer to the best broadcast address.
In general I recommend 255.255.255.255 on networks where the machines
can deal with it.  On those where they can't, probably {net,0,0} is
the only one that will work.  We're slowly being able to move to
255.255.255.255.

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 09:48:50 GMT
From:      mb@ttidca.TTI.COM (Michael Bloom)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   mbuf leaks

Can anyone suggest good techniques for tracking down mbuf leaks?

This is for a port I've done of the 4.3-tahoe tcp to a sys5r3 box.  I
believe the problem to be somewhere in the ethernet driver, as the
leakage did not appear until after adding it. (Previous testing via
the loopback device did not reveal any problems.)

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 12:18:26 GMT
From:      mb@ttidca.TTI.COM (Michael Bloom)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: mbuf leaks

A couple of hours ago, in article <2881@ttidca.TTI.COM> I wrote:
>	Can anyone suggest good techniques for tracking down mbuf leaks?

The problem was simple: turned out to be an "m_free" where there
should have been an "m_freem". While unneeded at present, i'd still be
interested in learning of other peoples network debugging techniques.

A new question: Has anyone tried rewriting the mbuf allocation
routines and macros to internally use streams data structures? This
looks like it might be a workable approach to converting the BSD TCP
to streams, without having to change too much of the rest of the code.

If I can find out soon enough whether or not s5r4 tcp will be streams
based, I may end up doing such a conversion to get a head start prior
to r4 availability.  I know I've asked this before, but I've gotten no
replies: does anyone know if this will be the case?

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 14:10:48 GMT
From:      swb@TCGOULD.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange Network Traffic (Booting a Sun)

I've been told that the client's ARP request for its own address is to
make sure nobody else is using it, and that if someone actually
responds the client will refuse to network.  If true, that's a nice
sanity check.
						Scott

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 14:42:58 GMT
From:      nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ")
To:        comp.protocols.tcp-ip
Subject:   RFCs, ISO DISs and ASCII copies...

"languages" to distribute documents in standardized form and to do
joint editing:
SGML/ISO8879, CGM/ISO8632, ISO8613 part 7, ccitt T.147 are good for
joint editing(standardized graphic markup language), comp.graph.meta files...

since there will be an iso transition (sic)  these distributions could
be already in some iso standardized form. AND: this would be a step to a
real distributed document archiving, editing and distribution facility
(perhaps somebody might look at a project called DAPHNE in germany?).
                                                                             
And tex  is even running on ataris, ibm compatibles, amigas, so even the
lowest end equipped people could participate (tex and a 9 needle printer!).


michael

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 21:41:18 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Name Server for Local site

It ought to be a relatively simple matter to build the current Bind
domain server for use on a Sun, HP, Unix Vax or Apollo.  The source
is public-domain, and available for anonymous FTP on the Internet
(but I'm not sure where - neither ucbvax nor ucbarpa seem to have it).
I think it has also been distributed on netnews.  If you can't get it
any other way, we include Bind 4.7.3 and the matching Sendmail.MX (uses
MX records) in one of our public-domain source diskettes (our part PC-801).

If you want a dedicated machine, or a supported product, we ported Bind
v4.7.3 (the last version before the current 4.8, which itself has gone
through some bug fixes since it was first available) to our DOS socket
library.  Of course, it runs in the foreground on a dedicated PC, but it
doesn't need hard disk (unless you want to log things and support high
query rates simultaneously).  It will initiate zone transfers, but it
won't accept incoming requests, so it isn't a good primary server for a
dynamic, multi-server domain.  I don't know if Unix Bind supports TCP
queries, but if it does, we've never tested them on the PC (UDP only).

Unmodified 4.7.3 on our Ultrix 2.0 uVax will handle about 45 queries
per second (local addresses in its cached database).  Our port to DOS
will support about 37 queries per second, on an 8Mhz AT clone with a
good Ethernet card in it, less on slower machines and with poorer cards.

James VanBokkelen
FTP Software Inc.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 21:52:35 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Grist for someone's mill

dcn1.arpa returned the precedence I sent in a PING (which is widely perceived
to be 'right', but is explicitly disallowed by RFC-792, pg 2).  However, it
does not escalate its precedence when I open a 'finger' TCP connection to it.
(it does request High Throughput, though, which I didn't send).  Recent
discussion of TCP and Precedence reveals that RFC-793 and MIL-STD-1778 disagree
as to whether an actively-opening TCP can raise its precedence.  One authority
I've talked to thinks the MIL-STD is right, and the opener can raise, but
not everyone has been heard from.

Sorry, I am not yet equipped to play with IP options, but I'll keep the
fuzzies in mind when I start (Basic Security first).

jbvb

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 88 22:27:57 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   a proposed modification to ARP

Abstract:  ARP on Ethernet should use an Ethernet multicast address
	rather than the Ethernet broadcast address.

As MAC-level bridges become more common and cheaper, the average size
of a single logical Ethernet (the span of an Ethernet broadcast packet)
is growing, as is the average number of machines on the Ethernet.  Not
all of these machines speak IP; DECnet, Novell IPX, XNS IDP, and
several other protocols are extremely popular.  Politeness dictates
that one protocol not get in another's way.  I think IP hosts should be
grateful, for example, that DEC uses Multicast rather than broadcast
for most DECnet "broadcasts", and hence that the typical IP-only host
doesn't have to do any work to throw away DECnet traffic it doesn't
care about.  We aren't so polite -- we pollute the cable with ARP
packets and IP broadcasts.  As the networks get bigger, the cost of
using broadcasts rises at least geometrically.

Doing away with IP broadcasts might be hard.  We don't yet understand
the issues of IP multicast well enough to make it a required part of
IP, but will probably end up with some fairly complex IP multicast;
this suggests that we not hastily adopt a simple scheme that is not
sufficiently general.  ARP, though, would be easy.  I propose that a
well-known Ethernet multicast address be reserved for ARP, and that it
be used instead of the broadcast address.  For backwards compatibility
with existing implementations, presumably a multicast ARP that failed
to generate a reply after a reasonable time would trigger an ARP to the
broadcast address.

Note that the imminent publication of a "how to be a perfect host" RFC
makes this a propitious time for such an extension to the ARP spec.

As a side benefit of moving ARP to multicast, one could then have an
extended Ethernet with bridges that refused to pass broadcast packets,
but that still looked to ARP and hence IP like one big network (note
that IP does *not* require that IP broadcasts reliably get to all hosts
on a network, or even require that IP broadcast be implemented.  The
one application I care about that uses IP broadcast, RIP, can easily be
made to cope with a partial-broadcast Ethernet since the number of
gateways << number of hosts).  Breaking a big Ethernet into smaller
broadcast domains clearly further reduces the problem of Ethernet
broadcasts on an extended Ethernet.

Comments?

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 00:58:57 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   review of Comer TCP/IP book


Although I might be a tad unobjective I think people are missing the
point (especially when I see people who have already done TCP/IP ports
or otherwise dealt with networks in hand to hand combat say the book
wasn't of total use to them.)

Hang around the hallways of the ACE conference and listen to folks who
came because they don't know a TCP from a UDP and have no mental model
to begin to understand such things (typically their problem is that
they don't know where the software/hardware boundaries are, which is
not surprising if you think about it), or deal with students in a
systems course (like one I teach here) trying to understand what all
the fuss is about and missing the point repeatedly, or do consulting
for a firm just getting into networking and try to just "quickly" go
over how a network works and why they need these pieces and
sophisticated consultants to design it and piece it together (um, why
can't we just PLUG ONE IN...like a disk or something...well, I agree,
but it ain't so, yet, at least not if you want more than an office or
two hooked together.)

If you think any of those folks can't benefit greatly from going thru
Doug's book (and, conversely, could much benefit from a stack of RFC's
plopped in front of them) then I think you're out of touch with his
likely customers. And there's plenty in there to fill most "guru's"
holes also (I freely admit there's more in there on EGP than I've had
the time or patience to educate myself on, hey, we all have limits.)

There's two necessary things to education: First, to provide the right
questions, second, to provide the answers to those questions. I think
Doug's book goes a lot further in providing the first part (the
questions, the model to investigate, the motivations) than anything
else I've seen thus far on Internetworking, and plenty far enough on
part two (the answers) for a person to thereafter find their own way,
at least after going thru the book they might think to ASK for an RFC.

Beyond that, it's nice to know that it won't be the last book on
networking.

	-Barry Shein, Boston University

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 01:07:08 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re:  Name Server for Local site

>It ought to be a relatively simple matter to build the current Bind
>domain server for use on a Sun, HP, Unix Vax or Apollo.  The source
>is public-domain, and available for anonymous FTP on the Internet
>(but I'm not sure where - neither ucbvax nor ucbarpa seem to have it).

I just checked and it's in ``~ftp/pub/4.3" on ``ucbarpa.Berkeley.Edu". The
version currently there is dated April 21.

I had no problems compiling it under SunOS4.0. However, I haven't gotten the
various network programs such as ``ftp", ``rlogin", .... to work properly
with the nameserver. I tried moving 4.3BSD osurces over and after resolving
some problems with ``signal", I got everything compiled. However, only
``finger" appears to work correctly. ``Ftp" certainly doesn't. Anyone made
the modifications to 4.3BSD sources to get them to work properly with the
nameserver and SunOS4.0?

Torben

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 01:24:36 GMT
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: Name Server for Local site

In article <8807092141.AA19885@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes:
>It ought to be a relatively simple matter to build the current Bind
>domain server for use on a Sun, HP, Unix Vax or Apollo.  The source
>is public-domain, and available for anonymous FTP on the Internet
>(but I'm not sure where - neither ucbvax nor ucbarpa seem to have it).

You didn't look hard enough: arpa.berkeley.edu:pub/4.3/bind.4.8.tar.Z

4.8 is known to run on Apollos under SR10.0; if you build libresolv.a
into a single object module (using `ld -r'), and then `inlib' it, it
magically replaces the gethostbyname in libc, so you don't even have
to relink the utilities which call gethostbyname.  (SR10 includes a
slightly older version of bind).

					- Bill

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 01:57:25 GMT
From:      jgd@csd1.milw.wisc.edu (John G Dobnick)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

In article <12412750860.11.BILLW@MATHOM.CISCO.COM>, BILLW@MATHOM.CISCO.COM
(William Westfield) writes:

[... elided text...]
> Using the local broadcast address (-1, or 0) seems the best solution,
                                    ^^^^^^^^^^
[...]
> Bill Westfield
> cisco Systems.

In the interests of precision, that should read (255.255.255.255, or 0.0.0.0).
On *my* machine, "-1" is 255.255.255.254, as it is 1's complement.

This is an easy trap to fall into, and vendors especially should be
particularly careful about this.
-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: <backbone>!uwvax!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu

All the world's not a VAX, nor is it all 2's complement!
-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: <backbone>!uwvax!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 02:41:25 GMT
From:      gamiddleton@watmath.waterloo.edu (Guy Middleton)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

This is an important question for us, as we plan to convert our campus to a
new set of addresses very soon (next week).  Once we decide on a broadcast
address, it will be difficult to change our minds.  I had been planning on
using the current 4.3 default of (I believe) {net,subnet,-1}, but recent
comments seem to indicate that 0xffffffff may have advantages for diskless
machines trying to discover their identities.  More last-minute advice would
be appreciated; after next Sunday, there will be no going back for us...

 -Guy Middleton, University of Waterloo Institute for Computer Research
						gamiddleton@math.waterloo.edu

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 06:08:51 GMT
From:      jgd@csd1.milw.wisc.edu (John G Dobnick)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

I insert foot in mouth in article <6184@uwmcsd1.UUCP>, where I say:

> This ["-1" is all 1 bits] is an easy trap to fall into, and vendors
> especially should be particularly careful about this.

Jon Postel in article <8807090341.AA04490@bel.isi.edu> replies:

> ... please read RFC-1009 pages 14, 15, 35, 36, 44, 45.

Indeed, RFC 1009 states in the text that "-1" is "all one bits".  I stand
corrected on this matter.

Assuming "-1" is "all ones" is, to me, a 2's complement bias.  Coming from a
1's complement environment, I misinterpreted this and shot my mouth off.
Sorry, folks.  I'm just learning about all this network stuff.

[I still have a problem with some wording in RFC1009, but am not sure this
is the proper place to raise it.  Can someone advise me on this?]
-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: <backbone>!uwvax!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu
-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: <backbone>!uwvax!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1988 13:14-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        jqj@hogg.cc.uoregon.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: a proposed modification to ARP
I agree completely with the suggestion of using Ethernet multicast,
instead of broadcast, for ARP.  Not only would it reduce the unnecessary
interrupt load on non-IP hosts, but it might also allow some IP hosts
to disable reception of Ethernet broadcasts (which is possible with
some Ethernet interfaces), thus avoiding everyone else's broadcast
pollution.

Whenever I have suggested this in the past, someone has always raised
the point that not all Ethernet interfaces are capable of receiving
specific multicast address.  However, every interface that I have
encountered provides at least the capability of receiving ALL
multicasts;  there may be interfaces in the PC world that don't even
do that -- they could get by with the broadcast-on-retransmission
scheme that you proposed for backwards compatibility.  Modern
Ethernet chips, such as the LANCE and the Intel chip, do provide
the necessary multicast support, as must any interface that is
expected to support DECnet or the new ISO protocols.

I suggest that different Ethernet multicast addresses be used for
ARP-for-IP, ARP-for-CHAOS, etc., to improve the precision of the
multicast.

A more radical suggestion for improving the precision (for which I cannot
claim credit -- I regret that I have forgotten who suggested it to me) is
to allocate a block of Ethernet addresses for ARP-for-IP, and define a
mapping function from IP address into Ethernet address within the block.
For example, say a block of Ethernet multicast addresses of the form
A-B-C-?-?-? were set aside for this purpose.  The IP address w.x.y.z
could be defined to map to the Ethernet address A-B-C-x-y-z.  A host
wishing to resolve the address of w.x.y.z would send its ARP request to
A-B-C-x-y-z.  Only those hosts whose IP addresses end in x.y.z would
need to listen to that Ethernet multicast address.

    Doing away with IP broadcasts might be hard.  We don't yet understand
    the issues of IP multicast well enough to make it a required part of
    IP, but will probably end up with some fairly complex IP multicast;
    this suggests that we not hastily adopt a simple scheme that is not
    sufficiently general.

In RFC-1054, I propose an IP multicasting scheme that could immediately
replace all current uses of IP broadcast on directly-connected networks.
Of course I am biased, but I believe that the host requirements
specified in that RFC are not very complex -- the real complexity lies
in the multicast routers, which are not necessary for multicasting to
immediate neighbors only.  As for its generality, I would welcome any
and all comments on the proposed scheme.  The End-to-End Protocols task
force is promoting RFC-1054 as a possible Internet standard; if anyone
is unhappy with the proposal, they should speak up now.

Steve Deering
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 15:52:10 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Name Server for Local Site.

The Berkeley name server will run on most Berkeley UNIX derivatives
like your Sun (and your VAX, if it is running BSD or Ultrix).  The
VAX, if running Wollongong's VMS will also run their version of
the name server (probably also BIND, but I've never had to look at
it to find out).

-Ron

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 16:00:57 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

The difficulty (for UNIX systems at least) with choosing 255.255.255.255
(or 0.0.0.0 or {net,constant,constant}) as a broadcast address arises
when you try to put broadcast-based applications on multi-homed hosts or gw's.
To broadcast on a particular net -- or for that matter on all nets -- what
address should be used?  Using the {net,subnet,constant} form at least ensures
that every interface has a distinct broadcast address and that a route exists
for that address.

It might be possible for applications to send to {net,subnet,constant}
and for the IP layer to detect that a broadcast was intended and translate
it into some other broadcast address before transmission.  This would
be pretty disgusting, however, and is anyway not done by any software I know of.

Do any of the sites choosing 255.255.255.255 as a standard broadcast address
have a solution?

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 20:14:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

I agree completely with the suggestion of using Ethernet multicast,
instead of broadcast, for ARP.  Not only would it reduce the unnecessary
interrupt load on non-IP hosts, but it might also allow some IP hosts
to disable reception of Ethernet broadcasts (which is possible with
some Ethernet interfaces), thus avoiding everyone else's broadcast
pollution.

Whenever I have suggested this in the past, someone has always raised
the point that not all Ethernet interfaces are capable of receiving
specific multicast address.  However, every interface that I have
encountered provides at least the capability of receiving ALL
multicasts;  there may be interfaces in the PC world that don't even
do that -- they could get by with the broadcast-on-retransmission
scheme that you proposed for backwards compatibility.  Modern
Ethernet chips, such as the LANCE and the Intel chip, do provide
the necessary multicast support, as must any interface that is
expected to support DECnet or the new ISO protocols.

I suggest that different Ethernet multicast addresses be used for
ARP-for-IP, ARP-for-CHAOS, etc., to improve the precision of the
multicast.

A more radical suggestion for improving the precision (for which I cannot
claim credit -- I regret that I have forgotten who suggested it to me) is
to allocate a block of Ethernet addresses for ARP-for-IP, and define a
mapping function from IP address into Ethernet address within the block.
For example, say a block of Ethernet multicast addresses of the form
A-B-C-?-?-? were set aside for this purpose.  The IP address w.x.y.z
could be defined to map to the Ethernet address A-B-C-x-y-z.  A host
wishing to resolve the address of w.x.y.z would send its ARP request to
A-B-C-x-y-z.  Only those hosts whose IP addresses end in x.y.z would
need to listen to that Ethernet multicast address.

    Doing away with IP broadcasts might be hard.  We don't yet understand
    the issues of IP multicast well enough to make it a required part of
    IP, but will probably end up with some fairly complex IP multicast;
    this suggests that we not hastily adopt a simple scheme that is not
    sufficiently general.

In RFC-1054, I propose an IP multicasting scheme that could immediately
replace all current uses of IP broadcast on directly-connected networks.
Of course I am biased, but I believe that the host requirements
specified in that RFC are not very complex -- the real complexity lies
in the multicast routers, which are not necessary for multicasting to
immediate neighbors only.  As for its generality, I would welcome any
and all comments on the proposed scheme.  The End-to-End Protocols task
force is promoting RFC-1054 as a possible Internet standard; if anyone
is unhappy with the proposal, they should speak up now.

Steve Deering

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1988 04:37-PDT
From:      TAC.1912-SCTC@E.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP Between LAN Node and DDN Foreign Host
We  are  in  the process of configuring several local  area  networks 
which  will  be  linked together through another host  serving  as  a 
router.   We  also  have  a DDN host  for  Milnet  connectivity.   In 
considering the configuration,  the question was raised as to how  an 
FTP  can  be done between a LAN user and a foreign host  on  DDN.   A 
picture of the system is given below.  

Each LAN has a DEC MicroVax II for the server.  Each MV2 is connected 
to  a DEC 8650 via DECNet or dial-up access.   There is a second  VAX 
8650  serving as the DDN host.   The 8650s are connected by DECNet as 
well.  All machines are running Ultrix-32 with TCP/IP. 


 _______       ________        ________    +=======+    ___________
|       |     |        |      |        |   {       }   |           |
|  MV2  |_____|  VAX   |______|  VAX   |___{  DDN  }___|  FOREIGN  |
|_______|  |  |  8650  |  |   |  8650  |   {       }   |   HOST    |
    |      |  |________|  |   |________|   +=======+   |___________|
 ___|____  |______________|
|        |    (alternate)
|  Z248  |    (  route  )
|  USER  |    (possbile )
|________|


Problem:   A user on a Zenith Z-248 logs into the MV2 and then  wants 
to  do an FTP beteen the MV2 and a DDN foreign host.   Is there a way 
to  make  the two VAX 8650s function in such a manner  that  the  FTP 
occurs  directly  between the MV2 and foreign host rather than  using 
the  DDN  host as an intermediary  (i.e.  requiring  two  FTPs)?   If 
software can be written to do this function, where can it be obtained 
if already written?

Please send all responses directly to me,  not the TCP-IP  group.

TAC.1912-SCTC@ISIE.ARPA  (Check the header to be safe).


STEVEN P. LONG, Capt, USAF            (804) 764-6502
1912 CSGP/MCN                          AV   574-6502
Langley AFB, VA 23669

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 88 23:54:16 GMT
From:      leres@ace.ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   Re:  A host sending an ARP request to itself?

Stuart Levy writes:
> It's probably trying to tell the world that it itself (its own IP address)
> is at its own Ethernet address... just in case they forgot or otherwise
> got confused.  It could also be checking for impostors on the same net,
> claiming to be the same IP address as its own.

I think the best reason for gratuitously broadcasting an arp reply
for yourself is to force hosts you were talking to (say, before you
shutdown, swapped your ethernet interface, and rebooted) to learn your
new hardware ethernet address.

		Craig

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 02:02:35 GMT
From:      narten@cs.purdue.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

Is broadcast traffic associated with ARP responsible for so much
traffic that it must be stamped out? Or is it the case that tuning
existing implementations so as not to time out entries so fast, etc.
would suffice?

For instance:

A typical implementation of ARP sends out an ARP request whenever a
packet is destined for a host that has no entry in the local ARP
cache.  If a particular machine is down, many hosts start ARPing for
it simultaneously.  Moreover, if the machine is heavily used (a file
server for instance) many useless broadcasts are sent out.  On our
local nets, ARP traffic is pretty minimal as long as all machines are
up.  When one goes down however, ARPs increase dramatically.
Incidentally, NFS is the worst offender at generating many consecutive
ARPs (TCP backs off and eventually gives up).

Adding an additional HOST_DEAD state to the ARP tables could be used
to handle these cases; ARPs for dead hosts would be limited to no more
than one every minute or so.  A sophisticated algorithm would arp very
frequently initially, but use a backoff to increase the delay between
successive ARPs as the number of consecutive non-responses increases.
This scheme also has the beneficial side effect of allowing IP to
return ICMP host unreachables for dead machines.

4.3 BSD ARP times out unaccessed cache entries every 20 minutes.  Is
there any good reason not to increase the value to several hours or
longer?  Broadcasts are expensive and memory is cheap.
-- 
Thomas Narten
narten@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!narten

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 88 11:19:56 PDT
From:      cire@clash.cisco.com
To:        "Torben N. Nielsen" <torben@dorsai.ics.hawaii.edu>
Cc:        jbvb@vax.ftp.com, tcp-ip@sri-nic.arpa, mcvax!ukc!stl!stc!idec!prlhp1!holland@uunet.uu.net
Subject:   Re: Name Server for Local site
>> I had no problems compiling it under SunOS4.0. However, I haven't gotten the
>> various network programs such as ``ftp", ``rlogin", .... to work properly
>> with the nameserver. I tried moving 4.3BSD osurces over and after resolving
>> some problems with ``signal", I got everything compiled. However, only
>> ``finger" appears to work correctly. ``Ftp" certainly doesn't. Anyone made
>> the modifications to 4.3BSD sources to get them to work properly with the
>> nameserver and SunOS4.0?
>> 
>> Torben

On implementations I've seen the interface to the name server was imbeded
in different gethostbyname and similar routines.  These routines are
contained in libc, libnet, libBSD, or some similar library set.  Where is
vendor dependent.  These libraries need to have the name server version
put into them or you need to link with the appropriate object prior to
linking with the library.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 11:37:00 GMT
From:      TAC.1912-SCTC@E.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   FTP Between LAN Node and DDN Foreign Host

We  are  in  the process of configuring several local  area  networks 
which  will  be  linked together through another host  serving  as  a 
router.   We  also  have  a DDN host  for  Milnet  connectivity.   In 
considering the configuration,  the question was raised as to how  an 
FTP  can  be done between a LAN user and a foreign host  on  DDN.   A 
picture of the system is given below.  

Each LAN has a DEC MicroVax II for the server.  Each MV2 is connected 
to  a DEC 8650 via DECNet or dial-up access.   There is a second  VAX 
8650  serving as the DDN host.   The 8650s are connected by DECNet as 
well.  All machines are running Ultrix-32 with TCP/IP. 


 _______       ________        ________    +=======+    ___________
|       |     |        |      |        |   {       }   |           |
|  MV2  |_____|  VAX   |______|  VAX   |___{  DDN  }___|  FOREIGN  |
|_______|  |  |  8650  |  |   |  8650  |   {       }   |   HOST    |
    |      |  |________|  |   |________|   +=======+   |___________|
 ___|____  |______________|
|        |    (alternate)
|  Z248  |    (  route  )
|  USER  |    (possbile )
|________|


Problem:   A user on a Zenith Z-248 logs into the MV2 and then  wants 
to  do an FTP beteen the MV2 and a DDN foreign host.   Is there a way 
to  make  the two VAX 8650s function in such a manner  that  the  FTP 
occurs  directly  between the MV2 and foreign host rather than  using 
the  DDN  host as an intermediary  (i.e.  requiring  two  FTPs)?   If 
software can be written to do this function, where can it be obtained 
if already written?

Please send all responses directly to me,  not the TCP-IP  group.

TAC.1912-SCTC@ISIE.ARPA  (Check the header to be safe).


STEVEN P. LONG, Capt, USAF            (804) 764-6502
1912 CSGP/MCN                          AV   574-6502
Langley AFB, VA 23669

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 13:12:54 GMT
From:      hassler@ASD.WPAFB.AF.MIL (Barry D. Hassler)
To:        comp.protocols.tcp-ip
Subject:   Anyone familiar with Allen-Bradley?

Anyone familiar with the Allen-Bradley line of network  equipment
(MAC-level bridges, IP routers, etc)? I'd appreciate any comments
anyone might have.

Please respond directly to me,  I'll  summarize  back  if  I  get
enough responses.

Thanks,

Barry D. Hassler
System Software Analyst
Control Data Corp
Integration Services Division

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 14:33:19 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

A more interesting question is how to force hosts to discard ARP entries
for dead machines.  Currently, most implementations keep the ARP entry
for some time interval after the last transmission to a host, not the
last reception from it.  Thus, if a host goes down because of a broken
Ethernet board, some of its partners will retain the old (and now bogus)
address for hours, if contact attempts are sufficiently frequent.  Some
better solution is needed, perhaps akin to the way 4.3bsd quashes a cached
route when the round-trip time gets too long.  It's hard to see a good way
to do that without violating layering, though.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 14:41:27 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

> 4.3 BSD ARP times out unaccessed cache entries every 20 minutes.  Is
> there any good reason not to increase the value to several hours or
> longer?  Broadcasts are expensive and memory is cheap.

     If 4.3 still has the bug where it doesn't update its ARP entry for an
IP address everytime it receives an ARP from that IP address, then those of
us who occasionally change ethernet interfaces would rather see this time
shortened than increased.  Except for this, I think an ARP timeout of many
hours is reasonable.

					David Bridgham

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 14:57:04 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   TFTP mode strings


I am writing a TFTP file transfer program for a proprietary communications
server. There appears to be some discrepancy between the TFTP document (IEN
133) and the packages that I have seen in use.

Basically, the IEN calls for three type of files- netascii, binary, and mail.
In addition to these types, I have seen "image", "octet", and "test" in the 
MIT package for the PC. I am not sure, but I think that I have seen other
modes in other packages.

My intent is to support netascii and binary file transfers. Mail mode is not 
well defined for my communications server (we have no embedded mail facility).
The test mode also doesn't apply for this application. This leads me to my 
question. What other text strings should I expect to see in the mode field of
a TFTP file access request? Is IEN 133 (dated Jan. 29 1980) the correct 
document to be referencing ? If it is, why are there conflicting text strings 
for binary mode ?


Thanks
Bill VerSteeg

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 15:03:50 GMT
From:      edm@nwnexus.WA.COM (Ed Morin)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Name Server for Local Site.

In article <504@prlhp1.prl.philips.co.uk> hollandm@prlhp1.prl.philips.co.uk (Martin Holland) writes:
>the local Hostname Tables in step with each other is becoming a real bind.
                                                                      ^^^^

AAAAARRRRRRGGGGGGHHHHHH!  (The same from Berkeley could solve some of your
problems...)

Ed Morin
Northwest Nexus Inc.
edm@nwnexus.wa.com

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 15:23:13 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   a proposed modification to ARP

I think that moving the ARP boradcast to a Ethernet Multicast address
still assumes too much on the part of our overworked Ethernet
interfaces.  There are still interfaces that have no multicast filter,
only mutlicast on/off (SEEQ chip, used on 3C501).  There are
interfaces with a severely limited number of multicast filters (the
ones that don't use hash tables).  There are interfaces whose
performance plummets when you enable any multicast address, because
they do a linear search of the table on every packet.

All of these interfaces will have a much more difficult existence if
we change ARP to use a multicast.  The ones that have only on/off will
be even more burdened, not only will they receive ARP (and rwho), now
they will receive all the DECnet routing traffic they never wanted to
hear.  This will keep their single receive buffer constantly full of
rubbish, so that the real traffic will never get in.

ARP is in a lot of PROMs now, and PROMs are "forever".  It's probably
too late.  People have too much invested in PROMs and interfaces to
try changing ARP.

I think that in most networks, more broadcast traffic is routing than
is ARP.  RIP, rwho, ruptime, et. al. are the problem, not ARP.

Lets not design (or ad-hoc, as Berkeley did) ANY more physical
broadcast protocols.  From now on, we use multicast.  Does DCA want to
shell out the $1000 to IEEE for an address block?  That will get us
2^24 multicast addresses of the IP community.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 17:20:18 GMT
From:      daver@hpindda.HP.COM (Dave Richards)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

> Adding an additional HOST_DEAD state to the ARP tables could be used
> to handle these cases; ARPs for dead hosts would be limited to no more
> than one every minute or so.  A sophisticated algorithm would arp very
> frequently initially, but use a backoff to increase the delay between
> successive ARPs as the number of consecutive non-responses increases.
> This scheme also has the beneficial side effect of allowing IP to
> return ICMP host unreachables for dead machines.

I like this idea.  LAN traces of our local network have illustrated
that such a "state" is quite necessary.  NFS and TCP traffic for
down hosts generates sooo many ARPs, it's an nightmare.

> 4.3 BSD ARP times out unaccessed cache entries every 20 minutes.  Is
> there any good reason not to increase the value to several hours or
> longer?  Broadcasts are expensive and memory is cheap.

A number is just a number.  But...  20 minutes isn't that short a
time-period, with respect to most LANs.  Also, directed ARP requests
for cache entries being timeed-out, is one way of easing the burden on
the network, ehile sllowing the cache entry to die in a moderate period
of time.

	Dave Richards

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 88 16:35:16 ECT
From:      JKOFOED%NORUNIT.BITNET@CUNYVM.CUNY.EDU
To:        tcp-ip@sri-nic.ARPA
Subject:   Simulation of TELNET sessions.
In Norway, at the University of Trondheim, we are going to evaluate
several different solutions for connecting IBM-4381 to ethernet
and communication based on TCP/IP. Our main interest is solutions
for TELNET server emulating IBM-3270 for different types of
ASCII terminals, ASCII printers and other ASCII hosts.
The system must be able to handle a total of about 100 parallell
sessions from TELNET clients.

It's not easy to organize a test group of 100 real people,
patiently using TELNET on our command :-). - We rather must try
with virtual people, a simulation program, simulating a lot of
TELNET clients communicating with the IBM host.

To write such a program is neither a small nor trivial task.
Does anyone know if such a program is available for either
UNIX or VAX/VMS? How can we get a copy? Is it free or can we
buy or rent it?  If the source is available, which language is
used?

- Thanks a lot!

Best wishes,
Jan Erik.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 18:02:08 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   TCP support for Precedence

I'm here, I'm here, and listening in.  I've been talking with people
actually trying to implement the security nonsense.  Its amazing how
many different ideas people have about how security should work or how
it does.  Mike

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 18:19:56 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Name Server for Local site

>> I had no problems compiling it under SunOS4.0. However, I haven't gotten the
>> various network programs such as ``ftp", ``rlogin", .... to work properly
>> with the nameserver. I tried moving 4.3BSD osurces over and after resolving
>> some problems with ``signal", I got everything compiled. However, only
>> ``finger" appears to work correctly. ``Ftp" certainly doesn't. Anyone made
>> the modifications to 4.3BSD sources to get them to work properly with the
>> nameserver and SunOS4.0?
>> 
>> Torben

On implementations I've seen the interface to the name server was imbeded
in different gethostbyname and similar routines.  These routines are
contained in libc, libnet, libBSD, or some similar library set.  Where is
vendor dependent.  These libraries need to have the name server version
put into them or you need to link with the appropriate object prior to
linking with the library.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 18:48:03 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet 2.2 release


NCSA Telnet version 2.2 release notice (July 5, 1988)

NCSA Telnet is a combined telnet client and FTP server program for
Macintosh and MS-DOS PCs.  It emphasizes a convenient, powerful
user interface and can be configured to match the characteristics
of your TCP/IP hosts.  We have included support for a wide variety of 
Ethernet options.  Complete user documentation is available; printed,
or in Macintosh Microsoft Word format files.

NCSA Telnet is available via anonymous FTP or by placing an order, see
appended message.  Any volunteers for BITNET posting?

We hope you enjoy using our program.

Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)
Gaige B. Paulsen             gaige@ncsa.uiuc.edu

National Center for Supercomputing Applications (NCSA)
University of Illinois, Urbana-Champaign

posted to tcp-ip,pcip -- flames/bugs to telbug@ncsa.uiuc.edu


Please distribute the following notice to anyone who is interested:
------------------------------------------------------------------

NCSA Telnet Information				July 5, 1988



NCSA Telnet is now in the public domain.


Features included in version 2.2 of NCSA Telnet:
(* means new in version 2.2)

DARPA standard telnet 
Built-in standard FTP server for file transfer
VT102 emulation in multiple, simultaneous sessions
Full subnetting support
Tektronix 4014 graphics emulation
Scrollback for each session
Domain name lookup with default domain suffix
*RARP for dynamic IP address assignment
Full color support (PC and *Macintosh II)
*Font and size support (Macintosh)
*MacBinary FTP transfer (Macintosh)
*New Ethernet board support (PC, PS/2)



How to obtain a copy:

1) From a friend

The documentation, program and source code are now in the public domain.  
Copy, modify, distribute and be happy.

2) Anonymous FTP from   ftp.ncsa.uiuc.edu   (128.174.20.50) 

You may want to ftp the README file(s) to determine which files to transfer to 
your home machine.

For the PC version, you have your choice of tar files which contain the 
documentation, the programs and supporting files.  For each tar file, there is 
also a compressed tar file with the same contents. After the files are 
extracted from the tar file, some transfer method (e.g. kermit, NCSA Telnet) 
should be used to download the files to the PC.  The documentation is 
available in line printer format and Macintosh Microsoft Word format.  
Remember to download .EXE files in binary mode.

The Macintosh version consists of several files encoded with Stuff-It.   The 
BinHex (.HQX) version is a duplicate copy for those who need a non-binary 
distribution.  Download the selections you need with a binary transfer method 
(kermit, NCSA Telnet) and extract the individual files.  The documentation is 
in Microsoft Word 3.X format.
 

 3) Diskette or Tape

 On-disk copies and printed manuals are available for a small fee which covers 
 materials, handling and postage.   The anonymous FTP tape covers the contents 
 of all disks.  Orders can only be accepted if accompanied by a check in U.S. 
 dollars made out to the University of Illinois.  You can get an order form by 
 contacting:

 NCSA Telnet orders 
 152 Computing Applications Building
 605 E. Springfield Ave.
 Champaign, IL 61820



 Hardware required:

 PC: 	IBM PC, PC/XT, PC/AT, or compatible. 
	3COM 3C501 Etherlink board.
	or IBM RT PC Baseband adapter.
	or Ungermann-Bass PC-NIC board.
	or MICOM NI5210 Ethernet board.
	or Western Digital WD8003E board.

 PS/2: 	IBM PS/2, models with MCA.
	3Com 3C523 Etherlink/MC board.
	or Ungermann-Bass NICps/2 board.

 Mac: 	Macintosh Plus, SE or Macintosh II.  
	FastPath from Kinetics Inc.  Walnut Creek, CA   (415) 947-0998 and
		Kinetics gateway software or Stanford KIP (Croft) gateway 
		software.
	or
	EtherSC or Etherport SE or Etherport II from Kinetics and
		Kinetics EtherTalk software.
	or 
	EtherTalk board from Apple and 
		Apple EtherTalk software for the Macintosh II.
	or
	alternate EtherTalk compatible systems for the Macintosh.


 Electronic Mailing List:

 Mail to telnet-request@ncsa.uiuc.edu to be added to the list of recipients.  
 To post messages to the list, mail to telnet@ncsa.uiuc.edu.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 19:33:42 GMT
From:      haas@utah-gr.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP simulator wanted

In article <8807100545.AA19765@ucbvax.Berkeley.EDU> LIPPKE@UTDALVM1.BITNET
 (David Lippke) writes:
>We've recently put some effort into benchmarking various combinations of
>  TCP/IP software and ethernet controllers on IBM mainframes running VM.
>  The results of this testing have now been analyzed to death...

Could you be good enough to post your results?

Thanks in advance  -- Walt Haas    haas@cs.utah.edu   utah-cs!haas

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 88 22:54:45 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

The CMU router has an implementation of ARP which deals with ARP and dead hosts
very effectively.  We use two timers and a counter instead of the usual
implementation with one timer.  The first timer is like that in BSD UNIX.
Every time an arp cache entry is referenced, the timer is reset to some "large"
value.  If the timer goes off (because no packets were SENT to the host), the
entry is removed.  I think Berkeley uses 5 minutes for this timeout and we use
20 minutes.  Because of our additional timer and counter, this could easily be
hours (days).

Our other timer and counter work as follows.  When an arp entry is refreshed
(created/updated), the second timer is reset to some "small" timeout, say two
minutes, and the counter is reset to zero.  If the timer goes off (because no
ARP requests or replies were RECEIVED from the host), the timer is reset and
the counter is incremented.  If the counter is less than a small constant such
as two, a point-to-point ARP request is sent directly to the host (i.e. it is
NOT broadcast).  If the host is still alive, it will answer it causing the
timer to be reset and the counter to be reset.  If the host is dead, changed
it's ethernet address, moved, etc. it will NOT reply, causing the timer to go
off again.  If the retransmission counter ever reaches two (for example), the
entry is removed.  In this way, arp entries are continuously (but slowly)
tested for accuracy, and the router is very resilient to ARP or hardware
problems.  We rarely see a bad ARP entry persist for more than a few minutes.

Drew

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 01:06:21 GMT
From:      dzoey@TERMINUS.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP mode strings

> From: dcatla!dnwcv@gatech.edu  (William C. VerSteeg)
> Subject: TFTP mode strings


> There appears to be some discrepancy between the TFTP document (IEN
> 133) and the packages that I have seen in use.

Um, try reading RFC783 (June 1981) for the definitive (ugh) tftp
treatment.

> Basically, the IEN calls for three type of files- netascii, binary, and mail.

TFTP encodes "netascii", "octet" or "mail" into the request packet.  I've
never seen "mail" implemented.  Image, binary & test were never encoded
in the packet and were just used for user-interface/debugging purposes.

The thing to watch out for are retransmit wars.  You can get into a mode
where you are transmitting two packets for each packet you really want
to send if you blindly ack all the packets that are retransmitted.  I wound up 
just relying on a timer and ignoring the retransmits.

Be careful of some older TFTP implementations.  There was a bug in the
4.2 TFTP that made it confused when it received retransmitted packets.
Since 4.2 begat such a large amount of derivitives, some implementations
may still exhibit this problem.  The problem was fixed in 4.3.

There are lots of implementations existing to test against.  Have fun.

                            Joe Herman
                            PC/IP @ Maryland

dzoey@terminus.umd.edu

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 01:10:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   re: default broadcast address

First, try to follow the robustness principle: hosts should accept
AS BROADCASTS all the possible (i.e., legal or formerly legal)
broadcast addresses.  For example, on a Class A network with an
8-bit subnet field, these addresses might be expected:

SCOPE			ILLEGAL			LEGAL
----------------	----------------	------------------
wildcard		0.0.0.0			255.255.255.255
net-broadcast		net.0.0.0		net.255.255.255
subnet-broadcast	net.subnet.0.0		net.subnet.255.255

Note that this is especially important because there are some things
that a host must never do in response to a broadcast packet (such as
send an ICMP Destination Unreachable), and so these must all be recognized
as broadcasts (this is even more important than accepting them).

Second, hosts should never send all-zeros addresses (unless the
LAN administration has decided to temporarily disobey the standard
until they can find a vendor that sells proper software).

Third, in a world where rules 1 and 2 are obeyed, most hosts should
be configured to send broadcasts to 255.255.255.255, to avoid having
to configure one more thing on a per-host basis.  The exception here
is that on multihomed hosts (and on gateways) there may be applications
which want to broadcast to one, but not all, of the connected subnets.
On these hosts, broadcasts should be addressed to the subnet-broadcast
addresses.

Fourth, I don't know of any implementations of the reverse-path-forwarding
mechanism I proposed in RFC922, so there is probably no reason to use a
net-broadcast address on a subnetted network.  Again, this assumes that
everyone is playing by the rules.

Finally, it appears true that on most LANs, rules 1 and 2 are violated
by at least one host.  In such cases, the best solution is to pick a
broadcast address that all the hosts can live with, and resign yourself
to the occasional broadcast storm or dropped broadcast.

An important point is: there is a big difference between what a host
should recognize/accept (everything), what a host should send (legal
things), and what should be used (the most legal thing for which every
host won't screw up and probably will accept).

-Jeff Mogul (mogul@decwrl.dec.com)

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 01:36:30 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

I'm not sure if you are really suggesting using 2^24 multicast addresses or
not.  While quite precise, it would probably be be overkill.  Considering that
many (most?) of the ethernet chips which support more than 1 multicast address
actually support 64, a good compromise between only 1 address and 2^24
addresses might be to reserve 64.  Some sort of fast hashing function could be
used to map an IP address to one of 64 buckets.  This probably rules out the
hashing function (CRC's) used by many of the chips themselves.  How hard is it
to get lots of multicast addresses?  Is it possible to buy 2^24 addresses?

Drew

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1988 0822-EDT
From:      gdwatt1@TYCHO.ARPA  (Glenn D. Watt)
To:        tcp-ip at sri-nic.ARPA
Subject:   Comer's TCP/IP (List of Errors ?)

Has anyone compiled a list of typos/errors in Comer's TCP/IP book?
I have noticed a few, but I'd like to get a complete list if possible.
I think the book is very good, and if combined with the Tanenbaum Computer
Networks book, you have an excellent base for undergraduate or graduate study!

Glenn Watt
-------

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 88 11:37:16 EDT
From:      dab@PTT.LCS.MIT.EDU
To:        dcatla!dnwcv@gatech.edu  (William C. VerSteeg)
Cc:        tcp-ip@sri-nic.arpa
Subject:   TFTP mode strings
The current document for TFTP is RFC-783 dated June 1981.  Three transfer
modes are specified: netascii, octet, and mail.  A footnote on octet says
"this replaces the 'binary' mode of previous versions of this document".

Mail mode exists because the group who created the protocol had a machine
which did not yet have a TCP (but did have IP and UDP).  MIT-Multics was
set up to forward mail with TFTP.  THe machine has since grown a TCP and
an SMTP.

The image mode you see in the code was because of a mistake.  There were
several implementations before someone noticed that we hadn't followed the
spec we'd written (at least six implementations were done by the same
group that wrote the spec).  So with very red faces we fixed those
implementations we could to accept either image or octet.

Test mode was just for the PCs.  It sends bogus data and throws it away at
the other end.  We just wanted to see how fast we could make the PCs go.

						David Bridgham
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 09:42:11 GMT
From:      smart@ditmela.UUCP
To:        comp.protocols.tcp-ip
Subject:   Multi-protocol wide area networks

When creating a wide area network for the academic and research 
community it seems desirable to be able to run a variety of middle
level protocols: TCP/IP, DECNET, OSI, UUCP, ACSnet. The only
choice I know of that can do this is X.25. The trouble with an
X.25 network for TCP/IP and DECNET is that you have to have a
host to gateway between each local ethernet and the wide area
network. What I would like is an X.25 switch which knows how to
do TCP/IP and DECNET and OSI/CLN gatewaying to a local ethernet.
Something like this:


   host-------X.25-switch---------wide area network
    |             |
 ----------------------------
      ethernet

Hosts that want to be connected to the X.25 network could be, but
most would get their network access from their LAN connection.

Is there anything like this around? Or planned? Or does somebody
have a better idea?

Bob Smart

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 12:22:00 GMT
From:      gdwatt1@TYCHO.ARPA (Glenn D. Watt)
To:        comp.protocols.tcp-ip
Subject:   Comer's TCP/IP (List of Errors ?)


Has anyone compiled a list of typos/errors in Comer's TCP/IP book?
I have noticed a few, but I'd like to get a complete list if possible.
I think the book is very good, and if combined with the Tanenbaum Computer
Networks book, you have an excellent base for undergraduate or graduate study!

Glenn Watt
-------

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1988 21:25-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: a proposed modification to ARP
	From Thomas Narten:
	Is broadcast traffic associated with ARP responsible for so much
	traffic that it must be stamped out? ...

ARP has often been responsible for broadcast storms, which some people
would like to stamp out.  Moving it to from broadcast to multicast
would reduce the number of potential victims of a storm (especially
if using an address hashing scheme, as I proposed).

Even when ARP is behaving itself, there is a pollution argument against
using broadcast: no single (well-behaved) broadcast application causes a
significant burden on uninterested hosts, but as the number of broadcast
applications continues to grow, and the number of hosts running those
applications on a single (possibly bridged-)LAN continues to grow,
the cumulative burden becomes serious.  To control it, you have to try to
stop as many offenders as possible.

It seems to me that the cost of cleaning up this pollution is almost
negligible, unlike the cost of cleaning up coal-burning factories or
semiconductor fabrication facilities or cars.  Just replace one
48-bit address with another, and set your multicast filter accordingly.

But, as John Shriver points out:

	... There are still interfaces that have no multicast filter,
	only mutlicast on/off (SEEQ chip, used on 3C501).  There are
	interfaces with a severely limited number of multicast filters (the
	ones that don't use hash tables).  There are interfaces whose
	performance plummets when you enable any multicast address, because
	they do a linear search of the table on every packet.

That's unfortunate, but does that mean everybody with a decent filter
has to continue to suffer?  If the users of a particular interface find
that accepting all multicasts is too burdensome, they can continue to
accept only broadcasts, as long we specify that ARP retransmissions be
sent as broadcasts, and the retransmission interval is reasonably short.
Furthermore, the lack of a decent filter does not prevent them from
*sending* multicast ARP requests.  I don't think that we should let
the weaknesses of these obsolete interfaces prevent us from moving
forward, especially given that we can accomodate them well enough until
they are replaced.

	... The ones that have only on/off will be even more burdened, not
	only will they receive ARP (and rwho), now they will receive all
	the DECnet routing traffic they never wanted to hear.  This will
	keep their single receive buffer constantly full of rubbish, so
	that the real traffic will never get in.

But it's OK to make the DECnet hosts receive all the IP rubbish they
never wanted to hear?

	ARP is in a lot of PROMs now, and PROMs are "forever".  It's probably
	too late.  People have too much invested in PROMs and interfaces to
	try changing ARP.

As pointed out, old implementations would continue to work.

	... Does DCA want to shell out the $1000 to IEEE for an address
	block?  That will get us 2^24 multicast addresses [for] the IP
	community.

It has already been done.  2^23 of them have been allocated to IP multicast
(see RFC-1054).  The other half are reserved by the Internet Numbers Czar
for possible future uses, of which ARP might conceivably be one.

	From Drew Daniel Perkins:
	I'm not sure if you are really suggesting using 2^24 multicast
	addresses or not.  While quite precise, it would probably be be
	overkill.  Considering that many (most?) of the ethernet chips
	which support more than 1 multicast address actually support 64,
	a good compromise between only 1 address and 2^24 addresses might
	be to reserve 64. ...

You are right, you can hash to as many or as few addresses as you want,
but I don't understand what the size of an address filter has to do with
it -- each host need listen to only one multicast address for ARP, the
one to which its own IP address hashes (unless the host has more than
one IP address assigned to a single interface).  The algorithm I suggested
gives a perfect hash and is trivial to implement.  2^24 is actually the
unit of allocation of multicast addresses from the IEEE; as John Shriver
mentioned, such a block of addresses costs $1000.  (What a numbers racket!)
Alternatively, you could apply to the Numbers Czar for a smaller block --
only .006 cents an address :-)

By the way, if you decide to use only a single Ethernet multicast
address for ARP, I suggest that you use 01-00-5E-00-00-01.  That is
the Ethernet address that corresponds to the IP multicast address
224.0.0.1, to which all multicast-capable IP hosts are expected to
listen.  Might as well conserve filter slots, where possible.

Steve
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 14:49:45 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   TFTP mail mode (ancient history)

TFTP mail did exist, and was implemented, back when TCP and NCP were
coexisting.  Here is the header from a peice of mail that went that
way:

 Date: 15 Sep 1982 1652-EDT (Wednesday)
 From: "lwa%MIT-CSR" at MIT-Multics
 Subject: Re: Re: Unix driver for Interlan Ethernet interface
 To: mo at LBL-UNIX (Mike O'Dell [system])

MIT-Multics was speaking NCP mail.  MIT-CSR did not have IP/TCP/SMTP,
but did have IP/UDP/TFTP.  MIT-Multics was forwarding the mail to CSR
using the TFTP Mail mode.  When NCP was being cut off, an SMTP was
written for MIT-CSR in a weekend.

While MIT-CSR is no longer running SMTP (it's essentially a TIU
running V6 UNIX off one RK05 disk), the TFTP still might accept mail.
MIT-Multics is gone, NCP no longer exists outside of DoD, and we use
@'s in mail addresses now.

One certainly does not want to implement mail mode in a new TFTP
server. 

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 15:37:23 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   re: default broadcast address

>> First, try to follow the robustness principle: hosts should accept
>> AS BROADCASTS all the possible (i.e., legal or formerly legal)
>> broadcast addresses.

Hosts should also accept AS BROADCASTS any packet that was sent to the
link layer broadcast (and mulitcast???) address regardless of what the
IP address was.
						David Bridgham

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jul 88 21:17 EST
From:      "Mark D. Eggers (219) 239-7258"      <CF4A8X%IRISHMVS.BITNET@CORNELLC.CCS.CORNELL.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   tn3270 and Ultrix 2.2
I am gradually getting Ultrix 2.2 to be a useful network
system.  However, I have not been able to get the latest
version of tn3270 to run properly. I have tried both the
generic 4.3 makefile (__putchar defined more than once), and
the 4.2 makefile (reverse video output, improper handling of
<CRLF>, and a host of other small problems). I am using the
latest version from ucbarpa.berkeley.edu (obtained this
afternoon).

The binaries obtainable from devvax.tn.cornell.edu for Sun
3s work fine on a Sun in conjunction with an IBM 3033
running MVS/SP and ACCES/MVS 2.0, so I think that ACCES/MVS
can deal with tn3270 porperly.

Any clues would be greatly appreciated.

Mark Eggers

BITNET:    cf4a8x@irishmvs
Internet:  eggers@dirac.cc.nd.edu
           cf4a8x@irishmvs.cc.nd.edu
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 01:09:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Two V2.0 sites 2000 miles apart

We have two sites separated from each other by a continent.

Both sites have (1) 10MHz DECNet, (2) 10 MHz Local Area Transport, LAT,
(3) TCP/IP 10 MHz, and, will someday want to share some NFS mounts.

I have one 9600 baud line currently remoting one 16 channel stat mux.  I
have some weak hope of some day getting another line.  I have an ever growing
number of users on VT100/200s trying to do full screen data base apps 
over this 9600b service.

NOT looking for the outfit which has hardware for one protocol at a time
.. and messes with the network layer.

My users need much more flexibility.  Not asking for vendor tauts.

Who has real protocol transparent bridging products in service which can
COST EFFECTIVELY transport all the protos above, together?  

Maybe use parallel routes with load sharing?  I can not get next to the
$50K per end type solutions!  

Is that here and performing for any of you this year??  Thanks .. Ev

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!suned1!efb |
         | USNSWSES - Code 4V43   } { ARPA:  efbatey@NSWSES.ARPA    |
         | * SO CAL Sun LUG * DECUS * 805/982-5881 * 805/983-1220 * |
         ------------------------------------------------------------

------
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 17:31:48 GMT
From:      doug@MSC2.TN.CORNELL.EDU (Doug Neuhauser)
To:        comp.protocols.tcp-ip
Subject:   PC FTP for NI-5210-8 interface

I am looking for a TCP/IP implementation, in particular user FTP (publicly
accessible) that works with the Micom-Interlan NI-5210-8 PC Ethernet
interface.  Can anybody refer me to one?  I believe KAQ9 may support this,
but alas, I don't know where to get KAQ9.  
Thanks.

Doug Neuhauser,
Materials Science Center, Cornell University
Internet:	doug@msc2.tn.cornell.edu
BITNET:		doug@crnlmsc2.BITNET UUCP:		...!cornell!msc2!doug

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 18:10:59 GMT
From:      hedrick@athos.rutgers.edu.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

You asked how to use a broadcast address of -1 on hosts with more than
one interface.  I don't know whether this is what actually happens in
4.3BSD, but I know what *should* happen.  The application should use
net.subnet.-1.  This lets the routing code choose the right interface
and route.  If it turns out to be a directed broadcast to some remote
network, the packet should be sent to the right gateway using that
address as the destination.  If it turns out the net.subnet is
directly connection, when the packet is about to go out the interface
(right before generating the checksum, hopefully), the address should
be changed to the preferred broadcast address for that interface.
That way they can all be -1 or 0, etc., but your application can still
specify which interface to use.  This seems to be what cisco gateways
do.  We set the broadcast addresses to 255.255.255.255, but it never
has trouble forwarding directed broadcasts, so it must be able to tell
which interface to use.

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 19:05:00 GMT
From:      Andrew-Birner%ZENITH.CP6%LADC@BCO-MULTICS.ARPA (Andrew Birner)
To:        comp.protocols.tcp-ip
Subject:   Questions on TCP-IP (vs. DECNET)


 We are testing the waters of TCP-IP, before jumping in with both feet;
unfortunately, the water looks rather murky from here, and we'd like to learn
a bit more about the bottom conditions before taking the plunge.  Our VAX
system manager, Mark Shumaker, has asked me to submit the following for
comments, suggestions, and/or flamage; e-mail replies may be directed to me at
the reply-to address for this message, which should be:

    <Zenith/A_Birner%LADC@BCO-MULTICS.ARPA>

Please do not direct replies to the address shown as sending this message, as
there is a one-way pipe in the path (a regretable political necessity).

==============================================================================

     {At the risk of starting another war....}

 We have a VAX-11/780, a VAX-8650, and a varying number of PC's and
 clones networked; DECnet has been our primary (and only) network
 product.  Now we need access to some other environments:  Prime
 2250/Primos (Ugh!), Honeywell DPS-66/CP-6 (Yay!), and possibly
 Mentor/UN*X (---!) systems.  The common networking scheme for
 all these suckers is TCP/IP.  Our (the Systems Manager's) intent
 has been to put together a subsidiary TCP/IP network which
 will allow transfer of files from the Prime, Honeywell, and Mentor
 to the 780 (our network control and file server node), with the PC
 and 8650 users then having DECnet access to the files.  There are
 no current requirements for anything other than file transfer
 on this subsidiary network.

 One of our more vocal users is promoting the thesis that TCP/IP
 should be our primary (indeed, only) network product.  I need to
 investigate this further.  Can anyone help me with:

 1) I keep hearing horror or war stories about interoperability
    among different implementations of the TCP protocols, even
    with the basic FTP and TELNET.  At the TCP/IP pre-symposium
    seminar at Anaheim '87, the speaker said that some user
    patching of TCP code would most probably be required in
    heterogeneous multi-vendor networks to assure interoperability
    (paraphrasing).  Can anyone comment on this matter, particularly
    since in at least one of our environments, the vendor will
    not disclose source code?

 2) Does anyone know of a product (hardware, software, or both) that
    acts as a DECnet-to-TCP bridge?  This looks like it should be a
    fairly simple thing to do, at least for the 'basic' protocols,
    but then I don't plan to do it myself so it *should* look easy...

 3) Can anyone put me into contact with the System Manager at a
    multi-vendor TCP/IP site (both hardware and software from dif-
    ferent sources, preferably including Prime, VAX, PC's, and at
    least one other) which is running satisfactorily and which did
    not have to do major modifications to the TCP code?

 4) We are using DECnet utilities for:

    a) File transfers from PC to PC, VAX to VAX, PC to VAX, VAX to PC.

    b) Virtual disk partitions on the VAX for the PC's for working
       storage, for archiving PC data, and for backups of PC data.

    c) SETHOST scripts imbedded in .BAT files in the PC's to allow
       the PC users to perform certain actions in the VMS environment
       without necessarily being aware that the process is not on the PC.

    d) Transparent File Access functions imbedded in C programs in the
       PC's for getting directories, files, and data from files on
       remote nodes (PC and VAX).

    e) In development are Transparent Task-to-Task applications that
       run on the PC's and communicate with a process on the VAX.

    f) Remote print and plotter outputs to computer-room devices.

    What are our chances of finding reasonably bug-free TCP software
    for the VAX and PC's which will allow us to continue these usages?

 5) I have heard some bad reviews of the Wollongong TCP/IP VAX product,
    and that some (unnamed) University has a much better one.  Can
    anyone comment on the status of VAX TCP implementations?  And is
    VMS V5 supposed to have one?

 This looks like quite a lot of questions, but the matter is serious
 to us and I want to do justice to the investigation.  I will be
 grateful for any assistance, suggestions, or comments.  Post them
 here, or mail them to me, or contact me directly at (312) 391-7908.
 Thank you.

 Mark Shumaker
 Zenith Electronics Corp.

==============================================================================

- Andy -

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 20:29:57 GMT
From:      riddle@ut-sally.UUCP (Prentiss Riddle)
To:        comp.mail.uucp,comp.sys.att,comp.os.vms,comp.protocols.tcp-ip
Subject:   Getting their Vax/VMS to talk to our 3B15...?

[Copious apologies for asking what must be a common question in so many
newsgroups, but I don't know enough about the answer to narrow it down
any better...]

We have an AT&T 3B15 running System V release 2.1; across the street
there is a Vax running VMS.  Where would one begin to look for the
hardware and software necessary to get the two to talk to one another? 
Neither machine is currently on a LAN; their Vax is on BITNET and a
statewide DECNET, and our 3B15 does all of its meager networking by UUCP. 

References either to published articles or to vendors would be
appreciated.  Please reply *by mail only* to the address listed
*below*; I am posting this from a guest account and I'm sure no one
wants these newsgroups cluttered with followups. 

-- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
-- Opinions expressed are not necessarily those of my employer.
-- riddle%woton.uucp@cs.utexas.edu  uunet!ut-sally!cs.utexas.edu!woton!riddle
-- Shriners Burns Institute, 610 Texas Ave. Rm. 4-8, Galveston, TX 77553 USA
-- telephone (409)-761-4701			FAX (409)-761-4003

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 21:03:48 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

The "correct" IP address to use in broadcast packets seems to have
become a perennial issue.  So once again I'll point out that, in my
opinion, hosts should treat any packet as a broadcast if it comes in
with the LINK level broadcast address (e.g., all 1's on Ethernet). The
IP destination address field in such packets should be completely
IGNORED.

An "out of band" indication of whether a given packet is a broadcast or
not should be passed up along with the packet to the IP layer, and from
there to the various transport protocols. (Certain protocols, e.g. TCP,
have good reason to refuse to respond to broadcast packets).

This is the only way I know to keep gateways from forwarding broadcasts
from hosts with the "incorrect" IP broadcast address.  When you think
about it, much of an IP header (including the destination address field)
is meaningless in the context of a broadcast packet anyway since
broadcasts are not supposed to pass through gateways.

Phil

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 88 23:00:50 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re: Name Server for Local site

Eric,

	Yes, the stuff is imbedded in the library. The problem I'm having
is that it *looks* like the nameserver Sun is distributing is pre-4.8 and
I wanted to use BIND4.8 and take advantage of the newer features and the
bug fixes. However, I do not yet have sources (on order...) for SunOS4.0 and
just bringing up the new nameserver doesn't cut it. I *believe* Sun has
interfaced the libraries to YP and that they do something non-standard through
that.... And I *don't* run YP at all. So I thought the easiest thing to do
was to just port the 4.3BSD sources over - compiling them against my
now separate nameserver library..... But it isn't that easy; at least not
with the version of the 4.3BSD sources I have from the original distribution
tape.... The Sun binaries definitely do not appear to work with BIND4.8...
Just looking to see if anyone else has a similar problem and maybe a 
solution :-)....

						---Torben

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 00:18:15 GMT
From:      Don_nmn_Mohidin@cup.portal.COM
To:        comp.protocols.tcp-ip
Subject:   tcp-ip mailing list

Please add me to your list for tcp-ip information.
my net address is don_nmn_mohidin@cup.portal.com .
Thanks in advance.
don mohidin

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 02:17:00 GMT
From:      CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers  239-7258", 219)
To:        comp.protocols.tcp-ip
Subject:   tn3270 and Ultrix 2.2

I am gradually getting Ultrix 2.2 to be a useful network
system.  However, I have not been able to get the latest
version of tn3270 to run properly. I have tried both the
generic 4.3 makefile (__putchar defined more than once), and
the 4.2 makefile (reverse video output, improper handling of
<CRLF>, and a host of other small problems). I am using the
latest version from ucbarpa.berkeley.edu (obtained this
afternoon).

The binaries obtainable from devvax.tn.cornell.edu for Sun
3s work fine on a Sun in conjunction with an IBM 3033
running MVS/SP and ACCES/MVS 2.0, so I think that ACCES/MVS
can deal with tn3270 porperly.

Any clues would be greatly appreciated.

Mark Eggers

BITNET:    cf4a8x@irishmvs
Internet:  eggers@dirac.cc.nd.edu
           cf4a8x@irishmvs.cc.nd.edu

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 03:48:26 GMT
From:      morgan@Jessica.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address


What applications use the IP broadcast address?

- RL "Bob"

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 07:50:19 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   telnet SUPRESS-TELNET option...

Well, the conversation has died down somewhat, so its time to
respond to several peoples comments.

braden@VENERA.ISI.EDU complains:

    There are Telnet controls (eg IP, AO, AYT...) that can appear at any
    time in the stream, and a correct implementation must check for them.

Yes, Yes, I understand all that.  What I am proposing is that a telnet
server/client be able to say "I promise that I will never send any more
option negotiations OR telnet controls.  In effect, I am turning off the
telnet protocol, and from now on will be sending you just data."  Most
servers certainly never send IP, AYT, etc, and my experience says that
AO is not very effective.  Most clients do not locally trap signals locally
and send the equivalent telnet control (though this may change ala the
Cray local edit option).  The actual options would look something like:

    DO SUPPRESS-TELNET requests that the receiver no longer use the telnet
	protocol.

    WILL SUPPRESS-TELNET offers to no longer use the telnet protocol.

    DON'T SUPPRESS-TELNET demands that the receiver continue to use telnet.

    WONT SUPPRESS-TELNET demand to continue using the telnet protocol.

The only strangeness is that once the option is successfully negotiated,
there is no way for it to be turned off.


mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) asks:

    Are you suggesting that one eliminate line mode and only use binary
    mode?  Or are you suggesting that there be an integration of TELNET
    and the local systems terminal driver?

No, line mode would still be there.  If line mode was in effect before
the SUPPRESS-TELNET option was negotiated, it would remain in effect.
I was suggesting that SUPPRESS-TELNET would provide the biggest gain
in binary mode, since in addition to no longer scanning the datastream
for IACs, you would also no longer have to handle special End of line
conditions (eg CR-NULL --> CR).

The suggestion has nothing to do with integrating telnet into the
local terminal driver.  However, one of the spinoff features of the
option would be that this would become much easier.  (A program could
do the initial option negotiation, and then just "attach" the tcp
connection to the terminal driver.  The terminal driver would no
longer have to know anything about the telnet protocol.)


    From: Doug Nelson <08071TCP%MSU.BITNET@cunyvm.cuny.edu>

    Why use Telnet if you don't want it?  It certainly isn't that difficult
    to keep scanning for IAC, and Telnet is certainly not a very complex
    protocol.  And you always have the option of rejecting any changes in
    options if you don't want to deal with them.

The reason for using telnet that it is a standard protocol, and has the
capability of negotiating things (eg local echo) that I need to
negotiate.  The reason for getting rid of the telnet protocol after I am
done with negotiating these options is that scanning for IACs is more
difficult than you think.  The telnet protocol requires that the telnet
process look at every character.  While this may not be much to a telnet
server whose operating systems eventually have to look at every character
anyway, it can make a big difference to something like a terminal server.
One of the motivations for my original message was that we have recently
been working on improving performance in the cisco Terminal Server.  After
this work, I noticed that our TTY-daemon process (this is the process that
would feed a printer from a tcp connection, for example) used a factor of
50 (fifty!) less CPU time on a TCP stream than it did on a telnet connection
(using straight-forward implementations of each - the stream dealt with
things a segment at a time, and the telnet dealt with them a character at
a time.  Admittedly, there are obvious improvements we can make to the
telnet process, but the fact that the obvious implementation is so bad
points strongly to a place in the protocol where improvements can be made.

    In what circumstances would you want to use this feature?  In a general
    interactive environment, it would seem like you'd want to keep your
    options open.

At cisco, we have half a dozen or so 38.4bps graphics terminals that spend
their time connected to a CAD package running on a DEC20.  Once the connection
has been set up, no telnet options are negotiated, and no telnet escapes are
sent.  We also have two laserwriters running at 38.4kbps.  Although one
usually talks tcp streams to these, telnet can be used for interactive
purposes.  Many of our customers use our terminal servers in "milking
machine" mode, where telnet sequence are never sent after initial
negotiations.

    What concerns me, though, is that some Telnet implementations apparently
    assume that no more options will be negotiated after the startup, and then
    stop working when they encounter software that sends them, such as echo
    toggles for password suppression.

Really?  I didn't know of any vendors that did this.  Care to name names?
The SUPPRESS-TELNET option is clearly more valuable to systems that operate
in remote-echo, character-at-a-time mode.  This is most systems, however.
It would be an OPTION that could be refused, and it would operate
independently in each direction.


    From: Mark Crispin <MRC@PANDA.PANDA.COM>

    The performance problem you refer to (2 process switches/character) is
    an artifact of the design of the Telnet server and operating system and
    not a problem in the Telnet protocol itself.

    In WAITS, Tenex, and TOPS-20, the Telnet server is in the same context
    as the terminal driver (that is, it is part of the operating system).

Which is not to say that tops20 virtual terminals could not be made much
more efficient if they didn't have to look for IACs and such.  The tops20
terminal driver is not exactly an example of efficiency - every character
is carefully examined and massaged several times on both input and output.
If it had to do extra process wakeups in addition to this, it would be
even worse.

Bill Westfield
cisco Systems
-------

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 16:03:00 PDT
From:      Mike Anello <mja@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE: mbuf leaks

	I don't know anyone who has rewritten mbuf allocation to use
	streams data structures, but I do know that you need to do a lot
	more work to convert BSD TCP to streams than you realize. The mbuf
	stuff is simple compared to creating true STREAMS drivers or modules
	that conform to the STREAMS architecture. Your approach may be a start
	but I believe that you have a long way to go. You should get a copy of
	the AT&T Streams Programmer Guide. This will surely show you how the
	rest of the work beyond mbuf conversion is very extensive.

	Mike Anello
	The Wollongong Group

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 09:09:00 GMT
From:      efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY")
To:        comp.protocols.tcp-ip
Subject:   Two V2.0 sites 2000 miles apart


We have two sites separated from each other by a continent.

Both sites have (1) 10MHz DECNet, (2) 10 MHz Local Area Transport, LAT,
(3) TCP/IP 10 MHz, and, will someday want to share some NFS mounts.

I have one 9600 baud line currently remoting one 16 channel stat mux.  I
have some weak hope of some day getting another line.  I have an ever growing
number of users on VT100/200s trying to do full screen data base apps 
over this 9600b service.

NOT looking for the outfit which has hardware for one protocol at a time
.. and messes with the network layer.

My users need much more flexibility.  Not asking for vendor tauts.

Who has real protocol transparent bridging products in service which can
COST EFFECTIVELY transport all the protos above, together?  

Maybe use parallel routes with load sharing?  I can not get next to the
$50K per end type solutions!  

Is that here and performing for any of you this year??  Thanks .. Ev

         ------------------------------------------------------------
         | Everett F. Batey II    } { UUCP:  sun!tsunami!suned1!efb |
         | USNSWSES - Code 4V43   } { ARPA:  efbatey@NSWSES.ARPA    |
         | * SO CAL Sun LUG * DECUS * 805/982-5881 * 805/983-1220 * |
         ------------------------------------------------------------

------

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 88 20:20:15 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Mark Lottor <MKL@SRI-NIC.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: icmp overload
>     24% of all the packets we receive are ICMP messages.  Of those, 13% are
>     unreachables and 7% are redirects.

Mark, can you tell if they are host- or net- unreachables?  Which gateways are
sending you the ICMP replies?  Can you tell if either the unreachables or the
redirects happen contrary to what you would expect from "routing by
inspection"?  In other words, are they caused because you are trying to send
bunches of mail to hosts which are, in fact, down?

Sorry, no answers.  Only questions?
Mike
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 14:26:58 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   a proposed modification to ARP

In Re:
>   Date: Mon, 11 Jul 88 21:36:30 -0400 (EDT)
>   From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>
>
>   I'm not sure if you are really suggesting using 2^24 multicast addresses or
>   not.  While quite precise, it would probably be be overkill.
I'm pretty sure that's what he had in mind, it's the obvious number
(see below).  It may be overkill, but it doesn't hurt anything and
helps the "bother as few hosts as possible" philosophy of the original
message, in general only the intended host will actually have to
process each ARP "broadcast".
>				...  Considering that many (most?) of
>   the ethernet chips which support more than 1 multicast address
>   actually support 64, a good compromise between only 1 address and
>   2^24 addresses might be to reserve 64.
But the point was that each host only needs to listen to ONE of these
addresses, the one it's IP address maps into, any ARPs sent to the
others would be ignored.  With this algorithm you get the hardware to
do the ignoring, saving on CPU time and interrupt overhead, possibly
even on context switches.
>				...  Some sort of fast hashing
>   function could be used to map an IP address to one of 64 buckets.
>   This probably rules out the hashing function (CRC's) used by many
>   of the chips themselves.  How hard is it to get lots of multicast
>   addresses?  Is it possible to buy 2^24 addresses?
It isn't possible to buy fewer than 2^24, that's the smallest package
available :-)  When you buy Ethernet addresses, you buy a 24 bit
prefix, and you get to assign the other 24 bits as you see fit.  This
seems like exactly the kind of scheme that fits this well.

>   Drew

Mike

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 19:28:28 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   icmp overload

Over the last two days (at least), 24% of all the packets we receive
are ICMP messages.  Of those, 13% are unreachables and 7% are redirects.
This seems really excessive.  Is anyone else seeing stuff like this?
-------

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 22:00:06 GMT
From:      jerryp@cmx.npac.syr.edu (Jerry Peek)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted
Subject:   Re: Where do you suppose I could get egp or gated?

Mark Fedor of NYSERNet gave a paper on "gated" at the summer USENIX.
There's a copy in the Proceedings.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 88 23:03:00 GMT
From:      mja@TWG.COM (Mike Anello)
To:        comp.protocols.tcp-ip
Subject:   RE: mbuf leaks


	I don't know anyone who has rewritten mbuf allocation to use
	streams data structures, but I do know that you need to do a lot
	more work to convert BSD TCP to streams than you realize. The mbuf
	stuff is simple compared to creating true STREAMS drivers or modules
	that conform to the STREAMS architecture. Your approach may be a start
	but I believe that you have a long way to go. You should get a copy of
	the AT&T Streams Programmer Guide. This will surely show you how the
	rest of the work beyond mbuf conversion is very extensive.

	Mike Anello
	The Wollongong Group

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 00:20:15 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: icmp overload

>     24% of all the packets we receive are ICMP messages.  Of those, 13% are
>     unreachables and 7% are redirects.

Mark, can you tell if they are host- or net- unreachables?  Which gateways are
sending you the ICMP replies?  Can you tell if either the unreachables or the
redirects happen contrary to what you would expect from "routing by
inspection"?  In other words, are they caused because you are trying to send
bunches of mail to hosts which are, in fact, down?

Sorry, no answers.  Only questions?
Mike

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 01:18:01 GMT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: Name Server for Local Site.


	I am looking for a machine to act as a name server for our
	local site.  We have a large, diverse number of machines
	running TCP/IP. (e.g. IBM, HP, SUN, Apollo, PC, VAX) over our
	local Ethernet.

There is no reason you need to FTP sources and compile, unless you have
lots of spare time (or expect the experience to be educational).  The
Domain Name Server has shipped for almost two years as part of the
basic Sun Operating System (since SunOS 3.2).  The version in SunOS
4.0, which has been shipping for several months, is based on BIND
4.7.3.  The current release under development is based on BIND 4.8.
You can obtain an up-to-date version of BIND 4.8 through Sun customer
service (ask for the "name server kit" patch tape).

Yellow Pages is another network name service that Sun, DEC, HP, and
some other vendors are using to name users, groups, aliases, etc.  in
addition to machines.  This is in standard SunOS, PC-NFS, Ultrix 2.0,
plus others.  There is a mechanism that causes the YP server to
optionally use the domain name resolver to look up names outside of the
current domain.  Unfortunately this was broken in SunOS 4.0; the fix is
in the name server kit.

While I am at it, let me address a few of the other issues recently
discussed on the TCP-IP list. Regarding ARPs: the 0.x.y.z request is an
artifact of the old software you are using.  SunOS 4.0 got rid of the
Network Disk protocol entirely and uses NFS for booting.  ARPs for self
serve two purposes: warn you if someone else on the net is also set to
your IP address, and more importantly flush the caches of other people
on the net with your previous Ethernet address. Remember DECnet (and
sometimes XNS) requires you to change your Ethernet address.  You need
this ARP or else your server will continue to send to the old address
when you reboot.

The current release in development has a simple timer that limits
ARP broadcasts to one per second.  It also has NFS timers that are
automatically determined instead of requiring a user to guess at them.
Most NFS implementations already have exponential backoff.

On broadcasts: our solution: accept all six kinds of broadcasts, but
default to SENDING the old one (net.0 or net.subnet.0) until we can be
reasonable assured that all SunOS 3.2 or earlier systems are gone.

	-- Bill Nowicki
	   Sun Microsystems

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 11:38:00 PDT
From:      Jerry Scott <jerry@TWG.COM>
To:        fitch <fitch@dockmaster.arpa>
Cc:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE: Wollongong, Recvfrom, and UDP
You are obviously using the QIO interface to the Wollongong software
rather than the SOCKET interface.  The SOCKET interface takes care
of the extra two bytes.  Since those wishing to port code to VMS
using the Wollongong software usually start with code using the
SOCKET interface, no modifications are necessary.  Don't know who
is porting networking code written in Ada using QIO's.  If people
are doing that then yes some modification will be necessary.

Jerry

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 88 14:41:32 EDT
From:      lou@wnyosi2.arpa
To:        tcp-ip@nic
Cc:        lclaudio
Subject:   UUCP over TAC
	I have an interest in uucp file transfer over Telnet 
going through a TAC to connect to a host.  I am sending the file from
a Unisys 5000/50 using System V unix operating system to a Sun using 
4.2 BSD. unix operating system.  The transfer was successful using a 
2400 Hayes compatible modem.  When tried over the network uucp failed to
start the protocol at the remote site after achieving a connection and a 
login at the remote site.  Received a message (alarm 1) through (alarm 25)
before timing out. The LOGFILE message was startup failed.  My ultimate
question is, has anyone done a uucp transfer successfully and is there
something I'm missing.  All documentation on uucp is very sketchy.
The ultimate goal of my uucp testing is to be able to transfer files
through a TAC to sites overseas.

Please respond directly to me because I'm not on the distribution list.


					Louie C. Manganiello
					NARDAC Wash.
					Washington Navy Yard
					Washington D.C. 20374 
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 88 21:44:52 PDT
From:      cire@clash.cisco.com
To:        mcc@etn-wlv.eaton.com (Merton Campbell Crockett)
Cc:        Fitch@dockmaster.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: Wollongong, Recvfrom, and UDP
>> Date: Thu, 14 Jul 88 13:49:24 PDT
>> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
>> To: Fitch@DOCKMASTER.ARPA, tcp-ip@SRI-NIC.ARPA
>> Subject: Re:  Wollongong, Recvfrom, and UDP
>> 
>> Don't understand why you're proud that you can read MACRO when you have to!
>> MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is
>> totally obscure.

Let's not get religious here.  Sure MACRO is explicit but that is different
than clarity.  MACRO is clear when you understand it.  I think this is
generally true for any language (computer that is).  To someone that doesn't
know the machine the MACRO is for a program will be very obscure.  But
that isn't true for the higher level languages.  That is once you understand
the language.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 15:22:35 GMT
From:      trwrb!ryding@ucbvax.Berkeley.EDU  (Mark A. Ryding)
To:        tcp-ip@sri-nic.arpa
Subject:   CMU-TEK Availability
-------------
Hello,
	I am looking for a source to get the CMU-TEK TCP/IP package 
for VAXen.  An Anonymous ftp location would be sufficient.  Any pointers
would be greatly appreciated.


Mark Ryding
{trwrb!ryding}
{ryding@trwrb.arpa}
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 15:34:00 GMT
From:      Fitch@DOCKMASTER.ARPA
To:        comp.protocols.tcp-ip
Subject:   Wollongong, Recvfrom, and UDP


I've had a few problems writing some UDP code under Wollongong's
protocol suite for VMS.  Now I think I know why.  In the man-like
documentation and in the QIO Programmer's Guide section of the
Wollongong documentation, the recvfrom procedure takes a from parameter
that is described as

       struct sockaddr_in *from

that is the socket structure we all know and love.  However, this does
NOT get filled in correctly.  I know the host I'm receiving from and the
info returned in from is half right; i.e., two out of four IP address
bytes are correct.

It turns out that you need to pass a pointer to a structure like

      struct sock_from {
               unsigned short from_len;
               struct sockaddr_in from_dat;
      }

The point is that from_len gives you two extra bytes which somehow makes
a difference.  Nevermind that the recvfrom call STILL needs a from_len
parameter of its own.

What I'm leaving out here is the only reason I discovered this is that
after my Ada bombed (yes, there is a whole mess of pragmas and other
stuff between me an the eventual QIO calls which is why it took me so
long to track down the bug) I started taking a closer look at the
Wollongong sample UDP code.  I originally didn't pay too much attention
to the example because it was written in MACRO (which I will
confess/brag that I can read if I have to) and because the comments in
the code were wrong (saying TCP instead of UDP, saying the server
connected to the remote...).  In the MACRO, the extra two bytes were
passed in the recvfrom call (but note that these bytes are NOT required
in the sendto call.  The C examples used connected sockets and didn't
need to spec the from parameter.  However, if you look in the C include
file, the sock_from type is defined, but it is never used in the
examples.

1) To be polite, I will ask if I am just confused.

2) If the answer to 1 is NO, then WHY IS THIS SO?

3) The obvious impact is that UDP code or anything else that uses
   recvfrom will have to get modified to work on Wollongong.

4) I will probably try to funnel these questions to Wollongong through
   the sub-cons on our project that deal with them, but I would
   like some feedback if anyone else has written UDP code under
   Wollongong and if there is some reason all of this happens.

Thanks.

--Jack Fitch -at Dockmaster.arpa

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 17:44:51 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  telnet SUPRESS-TELNET option...

While I can see some justification for using TELNET for your CAD/CAM termin-
als, I don't see why you would want to use TELNET for a print server.  I
would think a preferable procedure would be to use FTP to transfer files to
the print server and let the print server print the files at its leisure
using any algorithms it wishes to set priorities on the jobs submitted--unless
it is *not* a print server but just a common printer attached to a terminal
port.

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 17:58:36 GMT
From:      mark@cbnews.ATT.COM (Mark Horton)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

In article <1084@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>It is important to remember that the "addresses" refered to by
>this are the _names_ assigned to the endpoint in question and
>_not_ the physical address/serial_number of the board, to whit:
>the address may be associated with different hardware at different
>times.  As such addresses are arbitrary character strings, usually
>numonic, with several "suggested guidleines" for safe naming.
>The transport provider bears the burden of translating this
>into a media-dependant address, and as such this is not the
>problem of your software.  The media-address may also be retreived
>through one call (I forget which...)

I've used TLI too.  What are you describing above?

I once did a port of a working TCP/IP/socket application (built around
the Wollongong WIN/3B2 1.1 distribution) to TCP/IP/TLI (WIN 2.0.)  I
found that I had to pass a struct sockaddr_in to t_bind, and I had to
build the struct myself using gethostbyname, getservbyname, and the
like.  It seemed like TLI only replaced the bottom half of the socket
interface, all the addressing stuff was still socket specific, which
means none of it would work for TLI on some other transport.

In general, for clients and servers, you have to specify not only the
remote host address, but also the port name/number.  Determining both
of these quantities is going to be transport specific.  For example,
to write a generic TLI "remote login" application ala cu, for TCP/IP
I have to somehow tell it to use the TELNET port, #25 (unless I want
to use rlogin or supdup or something else.)  For Datakit, I have to
get the default port, whose name I think is "login".  For OSI it will
no doubt be something else.  And of course these applications all
have different protocols in the session, presentation, and application
layer.

	Mark

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 18:01:21 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Netman & Internet Engineering Task Force

Larry,  The NETMAN geneology is as follows:

NETMAN is a working group of the Internet Engineering Task Force (IETF).
(The IETF is one of a dozen or so Task Forces of the Internet Activities
Board (IAB) and is concerned with near term issues of the entire suite
of protocols surrounding TCP/IP.) (The IAB is the governing body of technical
researchers and implementors that guides research and approves all standards
effortsfor the Internet suite of protocols.)

Membership of the NETMAN group is open to all who are interested in developing
networkmanagement protocols for TCP/IP networks that use the OSI network 
management framework.  (The basic rationale is that someday we will have to
manage both styles of network entities, so we may as well  do one that
encompasses both suites.)  The actual membership of the NETMAN group is
about 25 organizations, mostly vendors, but some big users also.  The group
has been meeting for over a year by now and has developed a large amou8nt
of documentation.  It is planning a demonstration of its progress to date
in late September of this year.

The chair of the NETMAN group is Lee LaBarre of Mitre Corp. Net address
is cel@mitre-bedford.arpa .

This is a very short summary of what NETMAN is and where it fits.

Further information can be found in the monthly newsletter ConneXions.
Specifically:
"The Network Managment Working Group", Amatzia Ben-Artzi, November, 1987.
"An Overview of the IAB", Jon Postel, December, 1987.
"Network Management Standards", Vint Cerf, June, 1988.

Also,  RFC 1052, "IAB Recommendations for the Development of Internet
Network Managment Standards" is excellent reading on this subject.

Hope this helps you.  In short,  the work in this field is being done by
numerous people who are working very hard to make it possible to 
successfully run large networks.

Dan
-------

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 18:38:00 GMT
From:      jerry@TWG.COM (Jerry Scott)
To:        comp.protocols.tcp-ip
Subject:   RE: Wollongong, Recvfrom, and UDP

You are obviously using the QIO interface to the Wollongong software
rather than the SOCKET interface.  The SOCKET interface takes care
of the extra two bytes.  Since those wishing to port code to VMS
using the Wollongong software usually start with code using the
SOCKET interface, no modifications are necessary.  Don't know who
is porting networking code written in Ada using QIO's.  If people
are doing that then yes some modification will be necessary.

Jerry

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 18:41:32 GMT
From:      lou@WNYOSI2.ARPA
To:        comp.protocols.tcp-ip
Subject:   UUCP over TAC


	I have an interest in uucp file transfer over Telnet 
going through a TAC to connect to a host.  I am sending the file from
a Unisys 5000/50 using System V unix operating system to a Sun using 
4.2 BSD. unix operating system.  The transfer was successful using a 
2400 Hayes compatible modem.  When tried over the network uucp failed to
start the protocol at the remote site after achieving a connection and a 
login at the remote site.  Received a message (alarm 1) through (alarm 25)
before timing out. The LOGFILE message was startup failed.  My ultimate
question is, has anyone done a uucp transfer successfully and is there
something I'm missing.  All documentation on uucp is very sketchy.
The ultimate goal of my uucp testing is to be able to transfer files
through a TAC to sites overseas.

Please respond directly to me because I'm not on the distribution list.


					Louie C. Manganiello
					NARDAC Wash.
					Washington Navy Yard
					Washington D.C. 20374 

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 20:07:53 GMT
From:      mre@beatnix.UUCP (Mike Eisler)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

In article <1096@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>in article <836@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
>> Xref: nusdhub comp.dcom.lans:310 comp.protocols.tcp-ip:951 comp.protocols.iso:39
>> RFS server. Well, what if an RFS client and RFS server both support TCP/IP,
>> but different implementations (eg. Lachman and Wollongong) with different
>> address formats? The address of the file server will be incompatible with
>> the client's TCP/IP implementation.
>
>When you spesify an address like 255.255.255.255 (for instance) the
>TLI library passes a "request for translation" down to the driver.
>For TCP/IP (I thing) this would become two couplets of byte values;
>to whit: FF FF FF FF.  For STARLAN they would either be returned as
>the character string (unaltered) or an 802.3 tri-couplet (6 byte)
>address, I dont remember which.  More or less at this point you don't
>ever touch this address again.

RFS gives you the choice of specifying an ASCII string that is passed
directly to TLI unaltered, or a string of hexadicamal digits preceded
by \x.  RFS will convert each pair of digits to an ASCII byte,
construct the byte string, and pass it to TLI.  You do NOT specify 4
byte addresses in  "IP dot" format (255.255.255.255).  First of all,
RFS doesn't "dot" format. Second, they are inadequate.  The address of
a service in the TCP/IP world requires the network/host number (4
bytes), and the port number (2 bytes), both in network byte order. Thus
what you encode for RFS and pass to TLI is a string of bytes that at a
minimum contains the aforementioned 6 bytes. However, neither TLI nor
RFS define how these bytes are laid out for TCP/IP, though AT&T has
defined a format for Starlan.  It is up to the implementor of the
protocol (eg. Lachman or Wollongong implementing TCP/IP), define how he
wants the bytes of the address laid out for t_bind() and t_connect()
calls.

Well, there are already two obvious ways an implementor could lay them
out:
	h h h h p p 	or
	p p h h h h

Also:   h h p h h p . In other words, 6! = 720 permutations.  But wait,
there's nothing that says we can't have other bytes thrown in for good
measure. Look at the BSD sockaddr_in format. It is 16 bytes:  Bytes 1
and 2 are the family (AF_INET), 2 and 3 are the port
number (network order), 4,5,6,7 are the network/host number (network
order), and 8-16 are zeroes. This happens to be the format that Lachman
uses, presumably because it was the only defined way in lieu of AT&T
not defining one. Also, it makes it easier to implement sockets over
STREAMS.  I understand that the Wollongong format is similar Lachman's,
but different.  Any amount of difference will be enough to prevent the
use of a common name server for a network of RFS clients and servers
using different implementations of TCP/IP under TLI.

Let me prove this to you by example:
	svc	is the name of a RFS server running Lachman TCP
	clnt1	is the name of a RFS client running Wollongong TCP
	clnt2	is the name of a RFS client running Wollongong TCP

clnt2 contacts the name service for the address of svc to send a
mount request too. This works because the name server stores svc's
TCP/IP address in Lachman format, and so clnt2 can t_connect()
to that address.

clnt1 now wants to mount a resource of svc's as well. He contacts
the name server, and gets svc's address. He tries a t_connect()
and promptly gets an error, because the Wollongong TCP/IP
implementation can't understand an address in the format used by Lachman.

Note that this breaks even though the name server and the RFS clients
treat addresses as opaque objects.

>
>You (the application) don't need to know the addressing format for
>your provider any more than you need to know the sixteen tones
>used in DTMF dialing to use a Touch-Tone(r) phone.  You provide
>the free-form address as a string, and the rest of the system does
>it's best to make the connection you want, but like the PSTN
>(Public Switched Telephone Network) if you don't know the number
>you want, you probably arn't gonna get through!

Yeah, but regardless of whether I use rotary, or touch tone, and whether
the party I'm calling uses rotary or touch tone, we both agree on what
our phone numbers are, and what the order of the digits are. Because of
this, we can use a common name service called the telephone book.

	-Mike Eisler

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 20:49:24 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong, Recvfrom, and UDP

Don't understand why you're proud that you can read MACRO when you have to!
MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is
totally obscure.

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 21:14:50 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address


	
	Assuming "-1" is "all ones" is, to me, a 2's complement bias.  Coming from a
	1's complement environment, I misinterpreted this and shot my mouth off.
	Sorry, folks.  I'm just learning about all this network stuff.
	
	[I still have a problem with some wording in RFC1009, but am not sure this
	is the proper place to raise it.  Can someone advise me on this?]
	-- 
	John G Dobnick
	Computing Services Division @ University of Wisconsin - Milwaukee
	UUCP: <backbone>!uwvax!uwmcsd1!jgd
	INTERNET: jgd@csd4.milw.wisc.edu

John,

We plead guilty of 2's-complement bigotry.  I actually did not know there
are still 1's complement machines in the world, in fact...

Please send along any and all comments and suggestions on RFC0-1009 to
us.  We are starting to think about the first revision.

     Bob Braden  
     braden@isi.edu

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 21:53:13 GMT
From:      pst@comdesign.uucp (Paul Traina)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   UUCP Over TCP/IP (why?)

Pardon my ignorance,  but I'm confused about running uucp over TCP links.

My question is why?  The ftp/smtp/bsmtp interface seems much better for
handling files & mail, and for those who run it, the rsh interface seems
better than uux.  So, I ignorantly ask,  why do some folk run uucp over TCP?
There must be some sort of intelligent reason it was added...(?)

My only guess would be for folks running TCP terminal servers hooked into
dial-in/dial-out modems .. the remote site dials into the modem, goes via
tcp to the host, and runs uucp as if the modem was direct-connected to
the host.

Since I don't run 4.3 myself (Sun, where are you? Get real.) I don't have
the benefit of a 4.3 doc set to explain why I want TCP/UUCP.

-- 
work:					home:
  comdesign!pst@pyramid.com		  pst@ai.ai.mit.edu
  {uunet|pyramid}!comdesign!pst		  ...!ucbvax!ucsbcsl!nessus!pst
  					  pst@sbitp.bitnet

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 88 23:29:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

Phil Karn writes:
    In my opinion, hosts should treat any packet as a broadcast if it
    comes in with the LINK level broadcast address (e.g., all 1's on
    Ethernet). The IP destination address field in such packets should
    be completely IGNORED.

I'm not sure this is precisely right.  There are really two different
reasons to recognize incoming packets as broadcast:
    (1) Proper broadcasts should be accepted and passed to the
    	appropriate receiver process.
    (2) Certain things should never be done with packets that are
	received as broadcasts, link-level or IP-level.

"BOOTP" packets, etc., come under reason 1.  Not sending ICMP
error messages in response to broadcasts comes under reason 2.

The remaining question is: what should be done with a packet that
is received as a link-layer broadcast but is addressed to an IP
address which is not believed to be a broadcast address.  Simply
"ignoring" the IP address would be a mistake because the packet
might be meant for a different host.  In my opinion, a (non-gateway)
host should simply drop any packet with a destination that is not
either one of its own IP addresses, or one of its IP broadcast
addresses.  In addition, all hosts (gateway or not) must remember
whether a packet was received as a link-level broadcast, to avoid
violating the rule in reason 2 (above).

So what should a gateway do if it receives an IP packet that it
would normally forward, but the packet was a link-level broadcast?
Drop it?  Forward it?  Forward it and send a redirect, if necessary?
The conservative approach would be "drop it", but perhaps someone
is trying to discover a gateway in a brain-damaged sort of way.
Again, simply "ignoring" the IP address is probably wrong.
Suggestions?

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 00:00:56 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: default broadcast address


	
	>> First, try to follow the robustness principle: hosts should accept
	>> AS BROADCASTS all the possible (i.e., legal or formerly legal)
	>> broadcast addresses.
	
	Hosts should also accept AS BROADCASTS any packet that was sent to the
	link layer broadcast (and mulitcast???) address regardless of what the
	IP address was.
							David Bridgham
	
Well, now, I would not put it quite that way.  To be an acceptable
IP broadcast datagram, it must have a recogizable IP broadcast address
in its destination field.  The problem we need to solve is the havoc
(broadcast storms, etc) created by datagrams which arrive by local
network broadcast but do not have a recognizable IP broadcast address.
The discussions in the IETF Host Requirements Working Group have 
concluded that the best thing to do with such datagrams is SILENTLY
IGNORE THEM.

Bob Braden

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 00:50:00 GMT
From:      deering@pescadero.stanford.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

[This message seems not have made it out to the tcp-ip list, so this
 is a retransmission.  Sorry if anyone gets a duplicate.  -- Steve]

	From Thomas Narten:
	Is broadcast traffic associated with ARP responsible for so much
	traffic that it must be stamped out? ...

ARP has often been responsible for broadcast storms, which some people
would like to stamp out.  Moving it to from broadcast to multicast
would reduce the number of potential victims of a storm (especially
if using an address hashing scheme, as I proposed).

Even when ARP is behaving itself, there is a pollution argument against
using broadcast: no single (well-behaved) broadcast application causes a
significant burden on uninterested hosts, but as the number of broadcast
applications continues to grow, and the number of hosts running those
applications on a single (possibly bridged-)LAN continues to grow,
the cumulative burden becomes serious.  To control it, you have to try to
stop as many offenders as possible.

It seems to me that the cost of cleaning up this pollution is almost
negligible, unlike the cost of cleaning up coal-burning factories or
semiconductor fabrication facilities or cars.  Just replace one
48-bit address with another, and set your multicast filter accordingly.

But, as John Shriver points out:

	... There are still interfaces that have no multicast filter,
	only mutlicast on/off (SEEQ chip, used on 3C501).  There are
	interfaces with a severely limited number of multicast filters (the
	ones that don't use hash tables).  There are interfaces whose
	performance plummets when you enable any multicast address, because
	they do a linear search of the table on every packet.

That's unfortunate, but does that mean everybody with a decent filter
has to continue to suffer?  If the users of a particular interface find
that accepting all multicasts is too burdensome, they can continue to
accept only broadcasts, as long we specify that ARP retransmissions be
sent as broadcasts, and the retransmission interval is reasonably short.
Furthermore, the lack of a decent filter does not prevent them from
*sending* multicast ARP requests.  I don't think that we should let
the weaknesses of these obsolete interfaces prevent us from moving
forward, especially given that we can accomodate them well enough until
they are replaced.

	... The ones that have only on/off will be even more burdened, not
	only will they receive ARP (and rwho), now they will receive all
	the DECnet routing traffic they never wanted to hear.  This will
	keep their single receive buffer constantly full of rubbish, so
	that the real traffic will never get in.

But it's OK to make the DECnet hosts receive all the IP rubbish they
never wanted to hear?

	ARP is in a lot of PROMs now, and PROMs are "forever".  It's probably
	too late.  People have too much invested in PROMs and interfaces to
	try changing ARP.

As pointed out, old implementations would continue to work.

	... Does DCA want to shell out the $1000 to IEEE for an address
	block?  That will get us 2^24 multicast addresses [for] the IP
	community.

It has already been done.  2^23 of them have been allocated to IP multicast
(see RFC-1054).  The other half are reserved by the Internet Numbers Czar
for possible future uses, of which ARP might conceivably be one.

	From Drew Daniel Perkins:
	I'm not sure if you are really suggesting using 2^24 multicast
	addresses or not.  While quite precise, it would probably be be
	overkill.  Considering that many (most?) of the ethernet chips
	which support more than 1 multicast address actually support 64,
	a good compromise between only 1 address and 2^24 addresses might
	be to reserve 64. ...

You are right, you can hash to as many or as few addresses as you want,
but I don't understand what the size of an address filter has to do with
it -- each host need listen to only one multicast address for ARP, the
one to which its own IP address hashes (unless the host has more than
one IP address assigned to a single interface).  The algorithm I suggested
gives a perfect hash and is trivial to implement.  2^24 is actually the
unit of allocation of multicast addresses from the IEEE; as John Shriver
mentioned, such a block of addresses costs $1000.  (What a numbers racket!)
Alternatively, you could apply to the Numbers Czar for a smaller block --
only .006 cents an address :-)

By the way, if you decide to use only a single Ethernet multicast
address for ARP, I suggest that you use 01-00-5E-00-00-01.  That is
the Ethernet address that corresponds to the IP multicast address
224.0.0.1, to which all multicast-capable IP hosts are expected to
listen.  Might as well conserve filter slots, where possible.

Steve

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 03:03:34 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: PC FTP for NI-5210-8 interface

In article <8807121731.AA07491@msc2.TN.CORNELL.EDU> doug@MSC2.TN.CORNELL.EDU (Doug Neuhauser) writes:
>I am looking for a TCP/IP implementation, in particular user FTP (publicly
>accessible) that works with the Micom-Interlan NI-5210-8 PC Ethernet
>interface.  Can anybody refer me to one?  I believe KAQ9 may support this,
>but alas, I don't know where to get KAQ9.  

I have a driver for the ni5210 for KA9Q.  I have given the changes to
bdale, and he says that it will appear in the next version.  Phil is
also working on supporting FTP Software's packet driver spec.  As soon
as I can find time, I'll get a copy of it (from louie.udel.edu,
pub/ka9q, the version on louie is *always* a beta version, caveat
betaor) and write a driver for the ni5210.

There's also NCSA Telnet, which provides a FTP server in their 'telnet'
program.  It supports the 3c501, NI5210 and recently the wd8003.
NCSA Telnet is available from host 128.174.20.50 (ftp.ncsa.uiuc.edu).
-- 
nelson@clutx.bitnet, nelson@clutx.clarkson.edu, uunet!clutx.clarkson.edu!nelson

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 04:44:52 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong, Recvfrom, and UDP

>> Date: Thu, 14 Jul 88 13:49:24 PDT
>> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
>> To: Fitch@DOCKMASTER.ARPA, tcp-ip@SRI-NIC.ARPA
>> Subject: Re:  Wollongong, Recvfrom, and UDP
>> 
>> Don't understand why you're proud that you can read MACRO when you have to!
>> MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is
>> totally obscure.

Let's not get religious here.  Sure MACRO is explicit but that is different
than clarity.  MACRO is clear when you understand it.  I think this is
generally true for any language (computer that is).  To someone that doesn't
know the machine the MACRO is for a program will be very obscure.  But
that isn't true for the higher level languages.  That is once you understand
the language.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jul 88 08:50:04 EDT
From:      dlove@wnyosi2.arpa
To:        tcp-ip@nic
Cc:        lou
Subject:   Re:  UUCP over TAC
Paul Traina writes:

>>Pardon my ignorance,  but I'm confused about running uucp over TCP links.

>>My question is why?  The ftp/smtp/bsmtp interface seems much better for
>>handling files & mail, and for those who run it, the rsh interface seems
>>better than uux.  So, I ignorantly ask,  why do some folk run uucp over TCP?
>>There must be some sort of intelligent reason it was added...(?)

>>My only guess would be for folks running TCP terminal servers hooked into
>>dial-in/dial-out modems .. the remote site dials into the modem, goes via
>>tcp to the host, and runs uucp as if the modem was direct-connected to
>>the host.

>>Since I don't run 4.3 myself (Sun, where are you? Get real.) I don't have
>>the benefit of a 4.3 doc set to explain why I want TCP/UUCP.

Yes,  there is an intelligent reason for the question that addresses a 
specific problem.  The problem that is being addressed by lou@wnyosi2.arpa 
is that remote users who do not have host access to the MILNET need to be able 
to transfer files to a host on the MILNET.  These remote users are world-wide.  
Therefore,  UUCP via a TAC (therefore TELNET) is being explored,  not 
UUCP via TCP. 

We have tried Kermit via a TAC,  and are exploring UUCP as an alternative
solution.  Any other possible solutions to this problem would be greatly 
appreciated.

						Donnie R. Love
         					NetWorks One
						Washington Navy Yard
						Washington D.C. 

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 05:25:28 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   ISODE 4.0 announcement

Appologies in advance for posting this to three lists, but I only send
this message out every 9 months or so...

/mtr
///////

			  A N N O U N C E M E N T


    The next release of the "ISO Development Environment" will be
    available on 24 July 1988.  This release is called

				   ISODE 4.0

    This software supports the development of certain kinds of ISO/CCITT/ECMA
    protocols and applications.  Here are the details:

  - ISODE is not proprietary, but it is not in the public domain.  This was
    necessary to include a "hold harmless" clause in the release.  The upshot
    of all this is that anyone can get a copy of the release and do anything
    they want with it, but no one takes any responsibility whatsoever for any
    (mis)use.

  - ISODE runs on native Berkeley (4.2, 4.3) and AT&T (SVR2, SVR3) systems,
    in addition to various other UNIX-like operating systems.  No kernel
    modifications are required.

  - Current modules include:
	OSI transport service (TP0 on top of TCP, X.25, and CONS;
	    TP4 for SunLink OSI)
	OSI session, presentation, and association control services
	ASN.1 abstract syntax/transfer notation tools, including:
	    remote operations stub-generator (front-end for remote operations)
	    structure-generator (ASN.1 to C)
	    element-parser (basic encoding rules)
	OSI reliable transfer and remote operations services
	OSI DIS file transfer, access and management

  - ISODE 4.0 consists of final "IS" level implementations with a few
    exceptions.  FTAM is still DIS, and ROSE and RTSE are current to the last
    circulated drafts (March, 1988).  ISODE also contains implementations of
    the 1984 X.400 versions of ROS and RTS.  ISODE is aligned with the U.S.
    Government OSI Profile (GOSIP).

  - Future modules planned for the next release include:
	OSI message handling system
	OSI directory
	OSI virtual terminal ("telnet" class)
	MHS/SMTP gateway
	FTAM/FTP gateway

  - Although the ISODE is not "supported" per se, it does have a problem
    reporting address, Bug-ISODE@TWG.COM.  Bug reports (and fixes) are welcome
    by the way. 

  - The discussion group ISODE@SRI-NIC.ARPA is used as an open forum on ISODE.
    Contact ISODE-Request@SRI-NIC.ARPA to be added to this list.

  - The primary documentation for this release consists of a four volume
    User's Manual (approx. 800 pages) and a set of UNIX manual pages.  The
    sources to the User's Manual are in LaTeX format.  In addition, there are
    a number of notes, papers, and presentations included in the documentation
    set, again in either LaTeX or SLiTeX format.

  - Although ISODE is an openly available implementation of the upper-layers of
    OSI, it is primarily a development environment.  As such, it contains many
    tools and libraries to aid the development process.  The most recent
    addition is described in "The Applications Cookbook" which is Volume 4 of
    the User's Manual.  The Cookbook has several recipies for automating the
    implementation of OSI applications which use remote operations.  This
    includes use of a stub-generator for remote operations macros, a structure-
    generator to produce equivalent C structs for the ASN.1 type definitions
    used by the application, and so on.  Experience has shown that use of
    these tools can drastically accelerate the process of building distributed
    applications.

    For more information, contact:

        The Wollongong Group
        Attn: Marshall T. Rose
        1129 San Antonio Road
        Palo Alto, CA  94303
	USA

        +1-415-962-7100

    There are several ways to get a distribution:

 1. FTP
    If you can FTP to the DARPA/NSF Internet, you can use anonymous FTP to
    spam.istc.sri.com [10.2.0.107] and retrieve the file portal/isode-4.tar in
    BINARY mode.  This is a 9.25MB tar image.  The file portal/isode-4.tar.Z
    is the tar image after being run through the compress program (3MB).  

 2. NIFTP
    If you run NIFTP over the public X.25 or over JANET, and are registered in
    the NRS at Salford, you can use NIFTP with username "guest" and your own
    name as password, to access UK.AC.UCL.CS to retrieve the file
    <SRC>isode-4.tar.  This is a 9.25MB tar image.  The file <SRC>isode-4.tar.Z
    is the tar image after being run through the compress program (3MB).

 3. NORTH AMERICA
    For mailings in NORTH AMERICA, send a check or purchase order for 350 US
    Dollars to:

	University of Pennsylvania
	Department of Computer and Information Science
	Moore School
	Attn: David J. Farber (ISODE Distribution)
	200 South 33rd Street
	Philadelphia, PA 19104-6314
	USA

        +1-215-898-8560

    The tape will be written in tar format at 1600bpi, and returned with a
    documentation set.  Do not send tapes or envelopes.  Documentation only is
    the same price.

 4. EUROPE (tape and documentation)
    For mailings in EUROPE, send a cheque or purchase order for 200 Pounds
    Sterling to:

        Department of Computer Science
        Attn: Soren Sorensen
        University College
        Gower Street
        London, WC1E 6BT
        UK

	+44-1-387-7050  x3680

    Specify either (a) 1600bpi 1/2-inch tape, or (b) Sun 1/4-inch
    cartridge tape.  The tape will be written in tar format and returned
    with a documentation set via DHL.  Do not send tapes or envelopes.
    Documentation only is the same price.

 5. EUROPE (tape only)
    Tapes without hardcopy documentation can be obtained via the European
    UNIX User Group (EUUG). The ISODE 4.0 distribution is called EUUGD14.
    
          EUUG Distributions
          c/o Frank Kuiper
          Centrum voor Wiskunde en Informatica
          Kruislaan 413
          1098 SJ  Amsterdam
          The Netherlands

    For information only:
          Tel: +31-20-5924056 (or: +31-20-5929333)
          Telex: 12571 mactr nl
	  Telefax: +31-20-5924199
          Internet: euug-tapes@cwi.nl (euug-tapes@mcvax.uucp)

    Specify one of:
	- 1600bpi 1/2-inch tape:			 90 Dutch Guilders
	- 800bpi 1/2-inch tape:				120 Dutch Guilders
	- Sun 1/4-inch cartridge tape (QIC-24 format):	150 Dutch Guilders
	- 1/4-inch cartridge tape (QIC-11 format):	150 Dutch Guilders

    If you require DHL this is possible and will be billed through.  Note that
    if you are not a member of EUUG, then there is an additional handling fee
    of 300 Dutch Guilders (please enclose a copy of your membership or
    contribution payment form when ordering).  Do not send money, cheques,
    tapes or envelopes, you will be invoiced.  Tapes and invoice will be sent
    separately. 

 6. AUSTRALIA and NEW ZEALAND
    For mailings in AUSTRALIA and NEW ZEALAND, send a cheque for 150 dollars
    Australian to:  

	CSIRO DIT
	Attn: George Michaelson
	55 Barry St
	Carlton, 3053
	Australia

	+61-3-347-8644

    The tape will be written in tar format at 1600bpi, and returned with a
    documentation set.  Do not send tapes or envelopes.  Documentation only is
    the same price.

 7. FTAM on the JANET or PSS
    The sources are available by FTAM at UCL over X.25 using JANET
    (00000511160013) or PSS (23421920030013) with TSEL "258" (ascii encoding).
    Use the "anon" user-identity, supply any password, and retrieve the file
    src/isode-4.tar.  This is a 9.25MB tar image.  The file src/isode-4.tar.Z
    is the tar image after being run through the compress program (3MB).

 8. FTAM on the DARPA/NSF Internet
    The sources are available by FTAM at SRI over the DARPA/NSF Internet at
    host spam.istc.sri.com [10.2.0.107] (TCP port 102 selects the OSI transport
    service) with TSEL 258 (numeric encoding).  Use the "anon" user-identity,
    supply any password, and retrieve the file portal/isode-4.tar.  This is a
    9.25MB tar image.  The file portal/isode-4.tar.Z is the tar image after
    being run through the compress program (3MB).  

    For distributions via FTAM, the file service is provided by the FTAM 
    implementation in ISODE 4.0, which is a DIS implementation with a few 
    pieces of critical information taken from the IS.  Note that although this
    FTAM is a DIS implementation, the rest of the stack (i.e., association 
    control, presentation, and so on) is composed of an IS implementation.

    If you wish to use the FTAM implementation in ISODE 3.0, which was a DIS
    implementation both of FTAM and the rest of the stack, use TSEL 256 instead
    (ascii encoding at UCL, and numeric encoding at SRI).  This older service
    is temporary and is provided for bootstrap purposes only.

    For distributions via either FTAM or FTP, there is an additional file
    available for retrieval, called isode-ps.tar.Z which is a compressed tar
    image (2.75MB) containing the entire documentation set in PostScript
    format.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 06:00:39 GMT
From:      sms@ETN-WLV.EATON.COM (Steven M. Schultz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Wollongong, Recvfrom, and UDP

>Don't understand why you're proud that you can read MACRO when you have to!
>MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is
>totally obscure.

	and in a pinch even the rudimentary assembler that's provided with
	Unix systems is a pleasant switch.

	ummm, C is perfectly clear, don't mistake unfamiliarity with lack
	of clarity - please.  Ada is a language designed by a committee
	which brings to mind the old Alan Sherman quote: "a camel is a
	horse designed by a committee".

	Steven M. Schultz
	sms@etn-wlv.eaton.com

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 06:20:12 GMT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions on TCP-IP (vs. DECNET)


We use both DECnet and TCP/IP.  (Indeed I wrote the DECnet code for
the cisco gateways, and also do a lot of TCP/IP software work.)  I no
longer feel quite as strongly about TCP/IP's advantages as I used to,
though I'd still choose it in most situations.  What it mostly comes
down to is this: If you have a moderate size network, particularly
with a fairly simple topology, and you are willing to lock yourselves
into DEC, then their network products work very well.  (Indeed in many
cases DECnet is noticably easier to configure than IP, though part of
that is because any single-vendor system is easier to deal with than a
multi-vendor system.)  Otherwise, you should use IP.  I see the
comparison as follows:

DECnet:

It is fairly easy to configure.  It is well-integrated into the VAX
system, so some remote system management stuff is much easier to do,
and remote file access is more transparent.  It is generally cheaper.
This is the up side, and is generally sufficent for small institutions
that are locked into DEC, or into combinations that DEC supports (e.g.
DEC and IBM).  For the down side:

DECnet routing tends to be slightly unstable.  In many configurations
it doesn't matter, but I have heard reports from a site that has many
overseas lines that routing changes cause a cascade of routing
broadcasts that makes life very unpleasant for a while.  I have also
heard a report from Berkeley that having many routers on a single
Ethernet causes trouble, because the hellos synchronize, and produces
spikes of broadcast traffic that can exceed the capacity of some
Ethernet controllers to handle.  

Another problem for large configurations is that 16 bits is not enough
address space.  There are several national or international DECnet
networks.  Their growth is limited by the availability of area
numbers.  A given machine can talk to at most one such network.  If
your campus wants to be involved in more than one, you'll probably
have to do some sort of ad hoc partition of your routing.  

DECnet does not have some of the robustness features of IP, e.g.
the ability to deal with packet corruption.  (This should not be
an issue, as serial lines are done on top of DDCMP, which does
good error control.  But in large networks, you really do want
end to end error control.)

And obviously DECnet will tend to lock you into DEC.  The specs are
public, and there are now implementations for various other systems.
But you'll still probably find yourself using DEC routers, terminal
servers, etc.  (By the way, LAT is particularly noxious in this
respect.  The protocol for it is not public.  This means that even
other vendors that support DECnet do not support LAT.  So I recommend
avoiding LAT even in networks that use DECnet.)

IP:

The up side of IP is that just about everybody supports it, or at
least can point you to a software house that does.  It seems to have a
wider variety of services available (finger, rwho, etc.).  Its mail
systems tend to be designed to handle more complex configurations.
(Interfacing DEC's mail system into an environoment with DECnet, IP,
and BITnet is always a real trip.)  Some of the newer services seem to
have no equivalent on DECnet, e.g. the network file system.  I haven't
heard or X or NeWS over DECnet, though I'd think DEC might have an X
over DECnet for its VMS-based workstations.  The community of people
who are doing interesting projects in workstation system software
seems to be working mostly with IP.  IP is designed to handle very
large and complex networks.  32 bits of address space is enough for
the next few years.

The downside is in many ways the converse of the upside.  Because it
is supported by many vendors, and because it is designed for complex
networks, you have more chance that vendors' implementations will not
communicate, and more setup options.  In general interoperability is
much better than it was 5 years ago.  I haven't had to fix bugs that
caused interoperability problems for several years.  The main
remaining problem is that not all implementations support subnets, and
as a corrollary they may not agree on a broadcast address.  This can
be solved, as the new implementations can be set to use the old
broadcast address, and commercial gateways use proxy ARP to deal with
implementations that don't understand subnets.  However you do have to
know something about your implementations, so it complicates setup.

Setting up IP is a bit more complex, because routing isn't as
automatic.  There is no standard routing protocol.  (There is one that
most people implement -- RIP -- but it isn't an official standard.)
This means that you have to think about your routing design.  Once you
know what you are doing, it's easy to set up machines, but it does
mean you have to spend time figurng out the technology and deciding
how to use it in your case.  The serious IP gateways have a zillion
setup options.  However a DECnet router does too.  I think they're
about comparable in complexity.  However they tend to be used in
different cases.  The complex IP gateway options are normally used
when you are setting up a network that connects many organizations
with differing routing strategies and contraints about who will talk
to whom.

To answer your specific questions: (1) I doubt that patching is needed
these days, as long as you get current, supported software.  (2) The
smoothest DEC/IP bridge is an Ultrix system with software intended to
do just that.  However any machine that has both DECnet and TCP/IP can
act as a bridge if you don't expect too much.  (3) We are probably a
good reference site, but you might be better off finding a place that
has used Ultrix's DECnet/IP gatewaying software. (4) I think you can
find IP software that will do what you are doing, but I'm not sure
you'd find the changeover worth doing.  I'd add IP to a reasonable set
of machines, and start using it for new things, but I'm not sure I'd
erase all my DECnet software.  In particular, I'd modify your proposal
by putting IP on the 8650 also, and one at least one PC just so you
can play with it.  There are a number of IP implementations for the
PC, so you should talk to someone who knows more about them.  (5) We
still use Wollongong for VMS.  They have gotten a lot better recently,
and are now aggessively following the latest Berkeley technology.

Ideologically pure solutions sound real neat, but probably aren't the
best in the long run.  DECnet is just fine for the machines it
supports, particularly in a small network.  Unless you have to spend a
lot of time administering it, there's no reason to remove it.  But if
you depend solely on DECnet, there's a lot of good technology you
won't be able to use.  The IP community is a lot of fun, gets you a
lot of flexibility in a number of directions, but it also takes a
commitment of time to learn the technology.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 1988 14:02-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        jqj@hogg.cc.uoregon.edu
Cc:        tcp-ip@sri-nic.arpa, DCP@quabbin.scrc.symbolics.com
Subject:   Re: a proposed modification to ARP
  From me:
    By the way, if you decide to use only a single Ethernet multicast
    address for ARP, I suggest that you use 01-00-5E-00-00-01.  That is
    the Ethernet address that corresponds to the IP multicast address
    224.0.0.1, to which all multicast-capable IP hosts are expected to
    listen.  Might as well conserve filter slots, where possible.

  From David Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>:
    I just barfed up my breakfast.  Have they stopped teaching modularity
    and functional boundaries in computer science classes?

Have they stopped teaching civility in kindergarten?

  From jqj@hogg.cc.uoregon.EDU:
    I'm not sure I agree.  I'd like to keep ARP conceptually distinct from
    IP, so as long as ARP is also used for Chaos and potentially for other
    protocols, it would be desirable to have one more multicast address just
    for it.  ...

Sorry, I was less clear than I should have been.  I was referring to the
use of ARP for IP addresses, as I mentioned in my first message.  Clearly,
ARP for Chaos addresses should use a different multicast address, given
that the set of hosts running Chaos is not necessarily the same as the set
of hosts running IP.

The idea is that one Ethernet multicast address identifies the set of
all local hosts running IP.  Any application that wishes to send to that
particular set of hosts should use that address, regardless of ether-type
or higher-level protocol (just as the unicast Ethernet address used to
reach a single host does not depend on the higher-level protocol [with the
unfortunate exception of DECnet]).  Currently, both IP broadcast and ARP
use the same address, FF-FF-FF-FF-FF-FF, which identifies a larger set of
hosts than necessary; I have suggested a more accurate address to use.

In fewer words, link-level addressing is orthogonal to protocol type.  

Of course, ARP-for-IP *could* use a different multicast address than that
used for the IP all-hosts group, but they would identify exactly the same
set of hosts.  Given that most current Ethernet interfaces have a small,
fixed number of multicast filter slots or hash buckets, it's worthwhile
to avoid the redundancy.

(On the other hand, if you adopt the address hashing scheme we have been
discussing, the sets of ARP targets will differ from the set of all IP
hosts, so different multicast addresses are appropriate.  In return for
using up another filter slot, you get many fewer unnecessary interrupts.)

When this same topic came up a year or so ago, David Plummer (the gentleman
with the vomit on his lap) objected to using multicast for ARP-for-IP, on
the grounds that ARP was independent of IP and should not need to know
anything specific to IP.  (I regret that I no longer have a copy of his
message from that discussion; I'm sure he will correct me if I am
misrepresenting his objection.)  In my view, the hardware-level destination
address is simply another parameter to ARP, just like the hardware and
protocol addresses that go in the ARP fields.

Steve Deering
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 10:28:58 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multi-protocol wide area networks

Bob, there are gateways around which support ethernet interfaces which
do what you want.  Unisys makes a gateway which supports ethernet
and x.25 interfaces, along with other types of interfaces.

dennis

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 12:24:22 GMT
From:      keith@spider.UUCP
To:        comp.protocols.tcp-ip
Subject:   TFTP mode strings

The problem with the TFTP standard is that although RFC 783 was published
in 1981, the 1985 DDN protocol handbook still contains the superceded IEN 133,
and has no reference to RFC 783. Somehow I managed to get as far as
implementing TFTP without ever seeing RFC 783 !!
(It is used for booting in our SpiderPort TCP/IP Ethernet terminal server.)

Fortunately, there were plenty of implementations to test against, which
made it clear the mode strings defined in IEN 133 were not those in
real use - so SpiderPort uses "octet" mode.

Can I suggest any future editions of the protocol handbook rectify this ?


Keith Mitchell

Spider Systems Ltd.		keith@spider.co.uk
65 Bonnington Road		keith%spider@uk.ac.hw.cs
Edinburgh, Scotland		keith%spider.co.uk@uunet.uu.net
+44 31-554 9424			...!uunet!ukc!spider!keith

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 12:50:04 GMT
From:      dlove@WNYOSI2.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  UUCP over TAC

Paul Traina writes:

>>Pardon my ignorance,  but I'm confused about running uucp over TCP links.
 
>>My question is why?  The ftp/smtp/bsmtp interface seems much better for
>>handling files & mail, and for those who run it, the rsh interface seems
>>better than uux.  So, I ignorantly ask,  why do some folk run uucp over TCP?
>>There must be some sort of intelligent reason it was added...(?)
 
>>My only guess would be for folks running TCP terminal servers hooked into
>>dial-in/dial-out modems .. the remote site dials into the modem, goes via
>>tcp to the host, and runs uucp as if the modem was direct-connected to
>>the host.
 
>>Since I don't run 4.3 myself (Sun, where are you? Get real.) I don't have
>>the benefit of a 4.3 doc set to explain why I want TCP/UUCP.

Yes,  there is an intelligent reason for the question that addresses a 
specific problem.  The problem that is being addressed by lou@wnyosi2.arpa 
is that remote users who do not have host access to the MILNET need to be able 
to transfer files to a host on the MILNET.  These remote users are world-wide.  
Therefore,  UUCP via a TAC (therefore TELNET) is being explored,  not 
UUCP via TCP. 

We have tried Kermit via a TAC,  and are exploring UUCP as an alternative
solution.  Any other possible solutions to this problem would be greatly 
appreciated.

						Donnie R. Love
         					NetWorks One
						Washington Navy Yard
						Washington D.C. 

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 13:13:40 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   UUCP Over TCP/IP (why?)


>Pardon my ignorance,  but I'm confused about running uucp over TCP links.
>
>My question is why?

Very simple, to accomodate application layer software written for UUCP
in the least invasive way without having to rewrite it all including,
as you guessed, store and forward pieces that can travel over both
TCP/UUCP links and vanilla UUCP/serial links without modification.

The emphasis is on "without having to rewrite...", the approach works
quite well, especially for the last few hops around a LAN after it
arrives (often over a serial line) at the campus, or the first few
hops going out, as the case may be.

	-Barry Shein, Boston University

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 13:45:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP


    Date: 12 Jul 1988 21:25-PDT
    From: Steve Deering <deering@pescadero.stanford.edu>

    By the way, if you decide to use only a single Ethernet multicast
    address for ARP, I suggest that you use 01-00-5E-00-00-01.  That is
    the Ethernet address that corresponds to the IP multicast address
    224.0.0.1, to which all multicast-capable IP hosts are expected to
    listen.  Might as well conserve filter slots, where possible.

I just barfed up my breakfast.  Have they stopped teaching modularity
and functional boundaries in computer science classes?

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 14:15:03 GMT
From:      raj@PURDUE.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)


------- Forwarded Message

Return-Path: comer
Received: from merlin.cs.purdue.edu by gwen.cs.purdue.edu; (5.54/3.16)
	id AA01528; Thu, 14 Jul 88 20:21:12 EST
Received: by merlin.cs.purdue.edu; (5.54/3.16)
	id AA16478; Thu, 14 Jul 88 20:21:10 EST
Date: Thu, 14 Jul 88 20:21:10 EST
From: comer (Douglas Comer)
Message-Id: <8807150121.AA16478@merlin.cs.purdue.edu>
To: raj
Subject: Re:  Comer's TCP/IP (List of Errors ?)

Yes, here it is.  I asked Narten to post it to the TCP/IP mailing list
(twice) but he didn't.  I just found that out on the trip when i told him
I'm still getting lots of duplicates.

Doug
-----------------
				E R R A T A				5/6/88
				    for

			Douglas Comer,
			Internetworking with TCP/IP -
			Principles, Protocols, and Architecture
			Prentice-Hall Inc., 1988 (printing 1)
			ISBN 0-13-470154-2  025

Page	Line			      Problem
-----	----	-----------------------------------------------------------
cover		boundary missing between Wisconsin and Michigan; boundary
		incorrect between Washington & Oregon
contents	Section 2.6 starts on bottom of page 22, not 23
  5	 20	ink spot over "n" in "common"
 23	 -4	first footnote belongs on page 22
 36		diagram has right side of rightmost box missing
 40		In Figure 4.1, Class C prefix should be "1 1", not  "1 0"
 40	 23	incorrect value for 2 to 16th power  "65636" => "65536"
 68		Minimum MTU may be confusing: gateways are required to handle
		datagrams up to the MTU size supported by the networks to
		which they attach; 576 is only a minimum MTU they handle
140		Figure 12.7 is misleading: CODE field is 6 bits long
107	 14	"Dissembler" => "Dissassembler"
190	 -7	"Mark Feder" => "Mark Fedor"
190	 -7	"gated" should be italicized
253	 -3	incorrect apostrophe "like'gateways" => "like gateways"
272	 12	"a separate system has" => "a separate system call has"
276	 -9	"16-bite" => "16-bit"
295	-14	"less then 100-n" => "less than 100-n"
305	 -9	In the title of RFC 980 "Order Form" => "Order Information"
index		Reference for "DARPA" should be page 22, not 23
index		Uppercase and lowercase index entries are treated as
		different, resulting in mulitple listings (e.g., "time to
		live" and "Time To Live")
throughout	ISO is not a direct acronym in any language, so
		"International Standards Organization" should be
		"International Organization for Standardization"
throughout	"Network Operations Center" is sometimes "Network Operation Center"
throughout	ARPANET packet switch referenced inconsistently as:
			"Packet Switch Node,"
			"Packet Switched Node," and
			"Packet Switching Node"
throughout	X.400 is a CCITT recommendation, not an ISO standard.  The
		joint ISO/CCITT work is called MHS.  The latest CCITT
		recommendation is "1988 X.400" or "X.400(88)".
throughout	Although TP4 is analogous to TCP in some senses, it is NOT
		stream oriented

RFC changes:

   Yes, I know RFCs continue to evolve.  The reader is warned that no
printed list will remain current; we encourage anyone interested in RFCs
to obtain the latest version of the index (see appendix 3 for details).

Typos and suggestions:

   There will definitely be a revision of the text.  Send typos and
suggestions for changes to:

		tcp-typos@purdue.edu

Thanks to everyone who submitted the above.  Also, note the date on this
list -- it was compiled so I could get changes into the second printing.
There is lots more that I haven't had time to process yet.  --Doug

------- End of Forwarded Message

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 17:03:36 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   a proposed modification to ARP

This entire discussion of ARP and using a multicast address has one
assumption that has not been raised.  The idea is to send the first
ARP request as a Multicast, and then send retransmissions as
Broadcast.  This assumes that the ARP implementation in question is
stateful, and has retransmissions.  Not all ARP implementations meet
this criteria.  Of course, these implementations could always send to
the broadcast.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 18:18:16 GMT
From:      kerr@oodis01.ARPA (Grant Kerr)
To:        comp.protocols.tcp-ip
Subject:   Re: UUCP Over TCP/IP (why?)


In article <387@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes:
>Pardon my ignorance,  but I'm confused about running uucp over TCP links.
>
>My question is why?  The ftp/smtp/bsmtp interface seems much better for
>handling files & mail, and for those who run it, the rsh interface seems
>better than uux.  So, I ignorantly ask,  why do some folk run uucp over TCP?
>There must be some sort of intelligent reason it was added...(?)

One reason is that uucp over tcp adds fault tolerance over just plain uucp.
You can setup your L.sys to try a network tcp connection first and if that fails
due to network problems then it (uucp) can also try other means namely a
dialup modem.  If you are using smtp only and the network is down then the 
mail waits.
-- 
Grant Kerr
Control Data Corporation 
INTERNET: kerr@oodis01.arpa
UUCP: ames!lll-tis!oodis01!kerr

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 21:02:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP


  From me:
    By the way, if you decide to use only a single Ethernet multicast
    address for ARP, I suggest that you use 01-00-5E-00-00-01.  That is
    the Ethernet address that corresponds to the IP multicast address
    224.0.0.1, to which all multicast-capable IP hosts are expected to
    listen.  Might as well conserve filter slots, where possible.

  From David Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>:
    I just barfed up my breakfast.  Have they stopped teaching modularity
    and functional boundaries in computer science classes?

Have they stopped teaching civility in kindergarten?

  From jqj@hogg.cc.uoregon.EDU:
    I'm not sure I agree.  I'd like to keep ARP conceptually distinct from
    IP, so as long as ARP is also used for Chaos and potentially for other
    protocols, it would be desirable to have one more multicast address just
    for it.  ...

Sorry, I was less clear than I should have been.  I was referring to the
use of ARP for IP addresses, as I mentioned in my first message.  Clearly,
ARP for Chaos addresses should use a different multicast address, given
that the set of hosts running Chaos is not necessarily the same as the set
of hosts running IP.

The idea is that one Ethernet multicast address identifies the set of
all local hosts running IP.  Any application that wishes to send to that
particular set of hosts should use that address, regardless of ether-type
or higher-level protocol (just as the unicast Ethernet address used to
reach a single host does not depend on the higher-level protocol [with the
unfortunate exception of DECnet]).  Currently, both IP broadcast and ARP
use the same address, FF-FF-FF-FF-FF-FF, which identifies a larger set of
hosts than necessary; I have suggested a more accurate address to use.

In fewer words, link-level addressing is orthogonal to protocol type.  

Of course, ARP-for-IP *could* use a different multicast address than that
used for the IP all-hosts group, but they would identify exactly the same
set of hosts.  Given that most current Ethernet interfaces have a small,
fixed number of multicast filter slots or hash buckets, it's worthwhile
to avoid the redundancy.

(On the other hand, if you adopt the address hashing scheme we have been
discussing, the sets of ARP targets will differ from the set of all IP
hosts, so different multicast addresses are appropriate.  In return for
using up another filter slot, you get many fewer unnecessary interrupts.)

When this same topic came up a year or so ago, David Plummer (the gentleman
with the vomit on his lap) objected to using multicast for ARP-for-IP, on
the grounds that ARP was independent of IP and should not need to know
anything specific to IP.  (I regret that I no longer have a copy of his
message from that discussion; I'm sure he will correct me if I am
misrepresenting his objection.)  In my view, the hardware-level destination
address is simply another parameter to ARP, just like the hardware and
protocol addresses that go in the ARP fields.

Steve Deering

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 21:37:30 GMT
From:      Willett@SCIENCE.UTAH.EDU (Lon Willett)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet SUPRESS-TELNET option...

William Westfield <BILLW@MATHOM.CISCO.COM> proposes a SUPPRESS-TELNET
option as follows:

>    DO SUPPRESS-TELNET requests that the receiver no longer use the telnet
>	protocol.
>
>    WILL SUPPRESS-TELNET offers to no longer use the telnet protocol.
>
>    DON'T SUPPRESS-TELNET demands that the receiver continue to use telnet.
>
>    WONT SUPPRESS-TELNET demand to continue using the telnet protocol.
>
>The only strangeness is that once the option is successfully negotiated,
>there is no way for it to be turned off.

There is another strangeness here: it is (almost) impossible to turn off
TELNET protocol in both directions, since once it has been negotiated in
the one direction, negotiation can't be completed the other one (The
exception to this isn't worth mentioning).  The correct strategy is to
turn it off in both directions once it has been negotiated in a single
direction.

He then makes a case for greatly improved efficiency, which I don't
quite buy.  He writes:

>Admittedly, there are obvious improvements we can make to the
>telnet process, but the fact that the obvious implementation is so bad
>points strongly to a place in the protocol where improvements can be made.

Does the necessity of checking for an IAC really account for much of the
overhead?  I was under the impression that the primary overhead involved
in TELNET is the amount of network servicing that must be done.  For
example, on this machine, the telnet server will receive the data,
usually a single character, wrapped in a TCP packet wrapped in an IP
packet wrapped in an ethernet packet.  So the steps in processing are:

	1 -- receive the ethernet packet from the ethernet interface,
	and determine that it is meant to go to the IP driver, and turn
	it over to the IP driver.

	2 -- the IP driver determines the packet is valid (destination
	host is this one, header checksum is OK, etc), and that the
	packet is meant for the TCP driver, and turns it over to the
	TCP driver.

	3 -- the TCP driver does all its processing (sequencing,
	checksum, etc.), then turns it over to the TELNET driver.

	4 -- the TELNET driver checks for IACs, etc, and (assuming it is
	not an option negotiation) passes it to the terminal driver.

	5 -- the terminal driver does its stuff.

Obviously, it is preferable to do all this with no process context
switches.  But as long as the TELNET user process sends data one (or a
few) character(s) at a time, it seems like it will be very inefficient.
All the TCP sequencing, IP processing, and calculations of 2 checksums
would seem to dwarf the time spent scanning for IACs.

So yes, the protocol has flaws.  The main one is that TCP/IP (or any
protocol which is based on sending fairly large, complex packets) is not
a good way to handle terminal I/O.  The *right* way to deal with this is
to do the editting locally, so that the data can be sent a block at a
time, instead of a character at a time.  Look at the plethora of TELNET
options designed to do just that.

Finally:
>The suggestion has nothing to do with integrating telnet into the
>local terminal driver.  However, one of the spinoff features of the
>option would be that this would become much easier.  (A program could
>do the initial option negotiation, and then just "attach" the tcp
>connection to the terminal driver.  The terminal driver would no
>longer have to know anything about the telnet protocol.)

True, this option would make it easier to integrate the SUPPRESS-TELNET
TELNET processing into the terminal driver.  This strikes me as being
the major justification which could be given for such an option.  But as
long as your terminal driver is being modified to handle a TCP
connection at all, it seems that it wouldn't be difficult to also
include a simple minded TELNET implementation.

--Lon Willett (Willett@Science.Utah.Edu)
-------

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 22:06:05 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

> *Excerpts from ext.in.tcp-ip: 12-Jul-88 Re: default broadcast address*
> *Charles Hedrick@princeto (991)*
 
> I don't know whether this is what actually happens in
> 4.3BSD, but I know what *should* happen.  The application should use
> net.subnet.-1.
 
> That way they can all be -1 or 0, etc., but your application can still
> specify which interface to use.
I don't think this is appropriate for all implementations.  The ip layer
shouldn't be second guessing the application.  Some applications may want to
send to -1 and some may want to send to net.subnet.-1.  4.3BSD is broken
because it doesn't allow an application to send to -1 yet still specify which
interface to use.  It could use some out-of-band indication such as bind() or
an ioctl().  I.e. if you bind() to the address of a particular interface (vs.
INADDR_ANY) and send to -1 it could route the packet to the interface of the
address to which you are bound.

Drew

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 22:54:02 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

in article <666@cbnews.ATT.COM>, mark@cbnews.ATT.COM (Mark Horton) says:
> Xref: nusdhub comp.dcom.lans:345 comp.protocols.tcp-ip:1043 comp.protocols.iso:42
> 
> I've used TLI too.  What are you describing above?

I begin to think That I don't know enough about TCP/IP to fully understand
what you are exactly trying to accomplish, or its spesific problems/
detils; but here goes...

TLI is (as I deal with it any way) a basic way of providing description
and contlrol of (aledgedly) any transport media.  It's purpose is to
make a through-the-media pipeline through which data may be passed
with total reliability (Session/Virtual circut) or of providing a
method of asserting data on a media with the implicit intent that the
device on the other end is listening for such data, and applications
will handle the details from there.

TCP/IP is a media protocol which involves addressing and connection
metenence.  It is inteneded that other protocols would be implemented
_above_ some or all of TCP/IP.

If my perceptions are correct then trying to write a TCP/IP driver
over a "TLI device" is a non-sequetor.  The order, top to bottom,
of the stream should be: TLI over TCP/IP over STREAMS Device; such
that you have a STREAMS conformant TCP/IP driver for your ethernet
board, and then you push a custom made TLI-to-TCP/IP STREAMS module
on the stream before you hand the connection to a TLI conformant
application.

For instance, with STARLAN on a 3B2 there is the program "pumped"
onto the board, two kernel drivers (NAU and SRM) the 'adm' program
which assembles the STREAM durring startup, hands a hook to the
'listener' and then goes deamon.

Were you to put TCP/IP _above_ the TLI you would already have been
issued the sub device numbers, and already possess the connection
(in remote startup) or be insulated form same (originating a call)

The WHOLE POINT of the TLI is to remove the details of the connection
from the application.  A TLI conformant program only needs know
two or three things; 1) an address in "plain english" (c.f.
something that a user could be prompted for at the keyboard);
2) A service code (If and only if the address can provide more than
one service); and 3) the file-system name of a provider.
The TLI device is "opened" (cloned as necessary); the plain english
address is passented to the driver for translation; the driver
translates this to an address which will be useful to the rest
of the process (whatever that might be!) and returns a pointer
to same if necessary; the user submits a "bind" request by passing
the dirver the above address and the service code (and optional
init data if necessary) and is returned "success" or "failure"
code dependant on wethaer the conection went through (etc.).
After successful compleetion of the connect, the user only
has to provide whatever data, it thinks it wants the other end
to receive, to the TLI and it is received as is at the other end.
Optionally, after successful bind, the user program may
i_push some modules on the stack before useint the connection.

To implement rlogin under TLI you would simply do the following:
write rlog-serve shuch that:
	Accepts first unit as "name"
	uses read()/write() to prompt/deal with password verification.
	{ read() from TLI and write() to shell standin &&
	  read() from standin and write() to TLI}
	close local files
	exit.
write rlogin such that:
	It takes destination machine name as option.
	knows the service code for rlog-serve
	opens provider
	passes TLI the address in a bind request
	on success i_push(es) the read()/write() interface on the
		STREAM (I forget the name, but you get it free)
	{ read() form stdin and write() to TLI  &&
	  read() from TLI and write() to standout}
	close all files when done
	exit.
Add rlog-serve to the listener database on every machine which
will accept rlogin requests (you need to know the serviec code
to do this.) while you are doing this you record in the database
that the listener should i_push the read()/write() module on
the stream before starting rlog-serve.

If you do the three steps above you have rlogin.  The remote shell
stuff works exactly the same way.  What more do you need?


If you want TCP/IP and TLI stuff on the same media, you would make
a TCP/IP STREAMS deiver for the media.  The program which oversees
the TCP/IP workings establishes a TCP/IP address for the TLI
functions (much like 'adm' on the STARLAN network.) and routes
the TLI functions up through a multiplexing STREAMS driver to
where the TLI stuff can get it's hands on it.  To whit:

Listener	Cloneable Module Hooks
|		|  |  |  |  |  |  |  |  |  |
 -+------------------------------------------
 |
 TLI to TCP/IP request format translator. {Multiplexing Kernel Module}
	|
	|	TCP/IP Overseer {Deamon} (establishes all this on startup)
	|	Other TCP/IP Entry Pionts
	|	| | | | | | | | | | | | | |
 -+---------------------------------
	 |
	TCP/IP Driver  {Multiplexing Kernel Module}
	Media Driver {Kernel Module}
	Interface {Hardware}

To do it the other way would be a total mess.  It is _expressly_
stated that TLI is a uniform service which 'insulates' the
application form the _media dependant_ details of establishing
and maintaining a connection.  I would assume that there
must therefore be a media dependant protocol on the other
(deeper) end of the module.  It would also seem that this
'other' protocol could be anything! (X.25; TCP/IP; STARLAN;
whatever).

(Or maby not, considering I don't really know the innards
of TCP/IP.  It may also end up that TCP is on the same
level as TLI and that IP may be below both of them equally.
Or TCP and TLI may be available over any media and things
like TCP/STARLAN and TLI/IP may be possible?????????????
I can't really know until I find out more about TCP/IP;
but This is my understanding of all the elements involved.)

Rob.

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 23:10:12 GMT
From:      HOSTMASTER@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   [Sharon O. Beskenis <sdo@phoebe.larc.nasa.gov>: TCP-IP MAiling List Problems???]

This is for you
                ---------------

Return-Path: <sdo@phoebe.larc.nasa.gov>
Received: from phoebe.larc.nasa.gov by SRI-NIC.ARPA with TCP; Thu, 14 Jul 88 06:06:48 PDT
Received: Thu, 14 Jul 88 09:10:40 EDT by phoebe.larc.nasa.gov (3.2/1.2)
Date: Thu, 14 Jul 88 09:10:40 EDT
From: Sharon O. Beskenis <sdo@phoebe.larc.nasa.gov>
Message-Id: <8807141310.AA21795@phoebe.larc.nasa.gov>
To: hostmaster@sri-nic.arpa
Subject: TCP-IP MAiling List Problems???

Hi!  I had been receiving the tcp-ip mailing list at the following
address:
	sdo@csab.larc.nasa.gov

Things have been happy until sometime on July 8.  After that date, I
have not received any further messages from this list but some
associates on another net are getting their mail.  We are getting
our mail from various other sites around the world so I am sure that
we do not have a problem.

I would appreciate it if you could check into this for me.  Also, I
am interested in running the domain name server here at NASA LaRC.
Please put me in contact with the appropriate person at SRI-NIC so
that I can get all the necessary information for setting up a domain,
etc.

Thanks a lot for your help.

Sharon Beskenis
NASA Langley Research Center
MS 478
Hampton, VA 23665
(804)865-3535
-------

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 23:14:18 GMT
From:      hans@umd5.umd.edu (Hans Breitenlohner)
To:        comp.protocols.tcp-ip
Subject:   Re: Help on TCP/IP for HP

In article <8807051808.AA14880@sde.hp.com> wunder@sde.hp.COM (Walter Underwood) writes:
>
>Wollongong offers FTP, Telnet, and SMTP for the 3000.  Again, the link
>layer only talks 802.3, not Ethernet.  Gateways from cisco will talk
>802.3 to the 3000, and will forward the packets in Ethernet to systems
>on the other side of the gateway.  
>
I have been told that, in addition to the 802.3/Ethernet problem, HP 3000s
also use some mechanism other than ARP for address resolution.  Is this
correct, and could you shed some more light on this?  There are other
routers now which support 802.3, will they work with HP software?

Can you give any information as to if and when HP3000s will talk
to Ethernets, and if ARP will be supported at that time?

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 88 23:53:19 GMT
From:      HOSTMASTER@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   recent message

I mistakenly sent off a message that should have gone to the TCP-IP
list maintainer.  Please ignore it.

Michelle
-------

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jul 88 08:32 ADT
From:      John Sherwood <SHERWOOD%DALAC.BITNET@CORNELLC.CCS.CORNELL.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   SUN ACK storm
Fellow Netlanders:

We have been seeing some heavy (bogus?) ethernet packet traffic
from a SUN4 running 3.2 SUNOS:


DEST   SRC     SUMMARY

SUN4   VMS     ARP C PA=[129.173.1.20] PRO=IP
VMS    SUN4    ARP R PA=[129.173.1.20] HA=AA0004001E14 PRO=IP
SUN4   VMS     TCP D=25 S=32523 SYN SEQ=3205758976 LEN=0 WIN=4096
VMS    SUN4    TCP D=32523 S=25 SYN ACK=3205758977 SEQ=9828161 LEN=0 WIN=4096
SUN4   VMS     TCP D=25 S=32523     ACK=9828162 WIN=4096
VMS    SUN4    TCP D=32523 S=25     ACK=3205758977 WIN=4096
VMS    SUN4    SMTP R PORT=32523 220 Golly wosh!  Sendmail 5.51++/Vxxi....
SUN4   VMS     TCP D=25 S=32523     ACK=9828229 WIN=4029
VMS    SUN4    TCP D=32523 S=25     ACK=3205758977 WIN=4096
SUN4   VMS     SMTP C PORT=32523 HELO DALAC<0D><0A>
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4084
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4085
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4086
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4087
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4088
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4089
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4090
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4091
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4092
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4093
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4094
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4095
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4096
VMS    SUN4    SMTP R PORT=32523 250 Hello dalac.UUCP, .....
SUN4   VMS     TCP D=25 S=32523     ACK=9828284 WIN=3974
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4096
SUN4   VMS     SMTP C PORT=32523 MAIL FROM:<SHERWOOD@DALAC><0D><0A>
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4068
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4069
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4070
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4071

...and so on (VMS is node DALAC, a VAX 8800 running CMU 6.3 TCP/IP
code; SUN4 is DALCS, the 3.2 SUNOS culprit).

As you can see, the SUN is very concerned about keeping the other
system up to date about its window size, so much so that it generates
about 2000 packets/second of ACK's (one for every byte of data). The
trigger is always SMTP mail heading to the SUN4 from some other system.
We see the problem with either CMU 6.2, CMU 6.3 or BSD 4.3 as the
client system. The client isn't too happy having to deal with all this
extra traffic and generally manages to have a rotten day.

SUN has been no help with this problem so far. We are waiting to
upgrade to SUNOS4.0 as a possible fix, but that is not possible until
CommonLisp is available.

Any ideas? Is this a known bug? Is it better in 4.0? Are there
workarounds?

Thanks

John Sherwood
Dalhousie University
Halifax, Nova Scotia
SHERWOOD@DALAC       (NetNorth/BITNET/EARN)
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 88 11:32:00 GMT
From:      SHERWOOD@DALAC.BITNET (John Sherwood)
To:        comp.protocols.tcp-ip
Subject:   SUN ACK storm

Fellow Netlanders:

We have been seeing some heavy (bogus?) ethernet packet traffic
from a SUN4 running 3.2 SUNOS:


DEST   SRC     SUMMARY

SUN4   VMS     ARP C PA=[129.173.1.20] PRO=IP
VMS    SUN4    ARP R PA=[129.173.1.20] HA=AA0004001E14 PRO=IP
SUN4   VMS     TCP D=25 S=32523 SYN SEQ=3205758976 LEN=0 WIN=4096
VMS    SUN4    TCP D=32523 S=25 SYN ACK=3205758977 SEQ=9828161 LEN=0 WIN=4096
SUN4   VMS     TCP D=25 S=32523     ACK=9828162 WIN=4096
VMS    SUN4    TCP D=32523 S=25     ACK=3205758977 WIN=4096
VMS    SUN4    SMTP R PORT=32523 220 Golly wosh!  Sendmail 5.51++/Vxxi....
SUN4   VMS     TCP D=25 S=32523     ACK=9828229 WIN=4029
VMS    SUN4    TCP D=32523 S=25     ACK=3205758977 WIN=4096
SUN4   VMS     SMTP C PORT=32523 HELO DALAC<0D><0A>
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4084
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4085
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4086
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4087
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4088
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4089
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4090
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4091
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4092
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4093
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4094
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4095
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4096
VMS    SUN4    SMTP R PORT=32523 250 Hello dalac.UUCP, .....
SUN4   VMS     TCP D=25 S=32523     ACK=9828284 WIN=3974
VMS    SUN4    TCP D=32523 S=25     ACK=3205758989 WIN=4096
SUN4   VMS     SMTP C PORT=32523 MAIL FROM:<SHERWOOD@DALAC><0D><0A>
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4068
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4069
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4070
VMS    SUN4    TCP D=32523 S=25     ACK=3205759017 WIN=4071

...and so on (VMS is node DALAC, a VAX 8800 running CMU 6.3 TCP/IP
code; SUN4 is DALCS, the 3.2 SUNOS culprit).

As you can see, the SUN is very concerned about keeping the other
system up to date about its window size, so much so that it generates
about 2000 packets/second of ACK's (one for every byte of data). The
trigger is always SMTP mail heading to the SUN4 from some other system.
We see the problem with either CMU 6.2, CMU 6.3 or BSD 4.3 as the
client system. The client isn't too happy having to deal with all this
extra traffic and generally manages to have a rotten day.

SUN has been no help with this problem so far. We are waiting to
upgrade to SUNOS4.0 as a possible fix, but that is not possible until
CommonLisp is available.

Any ideas? Is this a known bug? Is it better in 4.0? Are there
workarounds?

Thanks

John Sherwood
Dalhousie University
Halifax, Nova Scotia
SHERWOOD@DALAC       (NetNorth/BITNET/EARN)

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 88 17:15:22 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

That's a great idea!  (To select an interface for broadcast by bind()ing
the socket first.)  You could even handle the fact that there's
no route for e.g. 255.255.255.255, by invoking the check-for-bound-socket-
on-broadcast code only when the route lookup fails.  If on the other hand the
route lookup succeeds, you must have specified some net-specific destination.

	Stuart

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 88 19:09:32 GMT
From:      dougm@ico.ISC.COM (Doug McCallum)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

In article <1104@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>in article <666@cbnews.ATT.COM>, mark@cbnews.ATT.COM (Mark Horton) says:
>> Xref: nusdhub comp.dcom.lans:345 comp.protocols.tcp-ip:1043 comp.protocols.iso:42
>> 
>> I've used TLI too.  What are you describing above?
>
>I begin to think That I don't know enough about TCP/IP to fully understand
>what you are exactly trying to accomplish, or its spesific problems/
>detils; but here goes...

You have a few things slightly confused.  I'll try to explain where in the
text.

>TLI is (as I deal with it any way) a basic way of providing description
>and contlrol of (aledgedly) any transport media.  It's purpose is to
 ...
>device on the other end is listening for such data, and applications
>will handle the details from there.

I can agree with this.  TLI provides a set of basic functions for establishing
and maintaining "transport" connections.

>
>TCP/IP is a media protocol which involves addressing and connection
>metenence.  It is inteneded that other protocols would be implemented
>_above_ some or all of TCP/IP.

This is where you are wrong.  Although the mapping of TCP/IP to the
ISO Reference Model isn't perfect, TCP is basically a transport protocol.
It is not a media protocol by any means.  It provides all the reliability
you assume the transport TLI wants will provide.

>
>If my perceptions are correct then trying to write a TCP/IP driver
>over a "TLI device" is a non-sequetor.  The order, top to bottom,
>of the stream should be: TLI over TCP/IP over STREAMS Device; such
>that you have a STREAMS conformant TCP/IP driver for your ethernet
>board, and then you push a custom made TLI-to-TCP/IP STREAMS module
>on the stream before you hand the connection to a TLI conformant
>application.

You wouldn't normally write a TCP/IP driver over a TLI device (but
I can see a case where you might).  All the previous discussion seemed
to be saying that a TCP/IP device would support TLI directly.  That is,
it conforms to the AT&T "Transport Provider Interface" specification which
the TLI library and modules expect.  Since TCP can be implemented to the 
TPI specification, no special conversion module is required.
>
>Were you to put TCP/IP _above_ the TLI you would already have been
>issued the sub device numbers, and already possess the connection
>(in remote startup) or be insulated form same (originating a call)

Huh?  I missed something.  When did TCP get moved above TLI.
The discussion started out about addressing being a problem with TLI
since it doesn't specify any particular format or even set down guidelines.
In all of this, TCP was below TLI and TLI was being discussed as the
way to write applications that would run over TCP/IP.

>
>The WHOLE POINT of the TLI is to remove the details of the connection
>from the application.  A TLI conformant program only needs know
>two or three things; 1) an address in "plain english" (c.f.
>something that a user could be prompted for at the keyboard);

Nowhere in the TLI specification or documentation does it state
this.  In fact, in the "Network Programmer's Guide", the example
given uses an "integer" and not something a user would normally
want to enter in at a keyboard.

I think you've missed the point of TLI or been biased by the one
transport layer implementation you seem to have used.  TLI provides a
way for an application to establish transport layer connections.
Addressing is specific to the transport protocol being used.

>2) A service code (If and only if the address can provide more than
>one service); and 3) the file-system name of a provider.

In the sense you are referring to them (RFS and the listener service)
service codes are specific to an "application" and not a transport.
The application is the listener service.  Other applications will
work differently.

>The TLI device is "opened" (cloned as necessary); the plain english
>address is passented to the driver for translation; the driver

This is not normally the case.  Look at some of the other transport
providers that AT&T uses.  They don't all work this way.  In any case,
hostname to internal address translation wouldn't be done in the
transport protocol and asking a user to enter a 12-digit hex number or
a 32-digit hex number isn't what I would call plain english.

>translates this to an address which will be useful to the rest
 ...
>To implement rlogin under TLI you would simply do the following:
>write rlog-serve shuch that:
 ...
>write rlogin such that:
 ...
>Add rlog-serve to the listener database on every machine which
>will accept rlogin requests (you need to know the serviec code
>to do this.) while you are doing this you record in the database
>that the listener should i_push the read()/write() module on
>the stream before starting rlog-serve.

And it wouldn't work with systems that weren't based on TLI.  Other
systems won't implement the listener service.  The listener service is
a session layer specific to some of AT&T's applications.  The rest of
the world doesn't work that way and the rest of the world's
applications outnumber the few AT&T applications.

>If you want TCP/IP and TLI stuff on the same media, you would make
>a TCP/IP STREAMS deiver for the media.  The program which oversees

Now you are confusing TLI with the transport itself.  Using TLI
as a program interface should not and must not get in the way of
using the transport protocol.  Once you get on the media, TLI is
totally irrelevant.  If it isn't, someone did something wrong.

>the TCP/IP workings establishes a TCP/IP address for the TLI
 ...
>(deeper) end of the module.  It would also seem that this
>'other' protocol could be anything! (X.25; TCP/IP; STARLAN;
>whatever).
>
>(Or maby not, considering I don't really know the innards
>of TCP/IP.  It may also end up that TCP is on the same
>level as TLI and that IP may be below both of them equally.
>Or TCP and TLI may be available over any media and things
>like TCP/STARLAN and TLI/IP may be possible?????????????

TCP is basically a transport.  IP is basically a network layer.
TLI is neither - it is a program interface for a tranport layer.
The issue that you missed is that TLI doesn't specify how addresses
for a specific transport should look.  Actually, TLI shouldn't
do this, there should be an address format registry that says
how to format addresses for a specific transport.

You should also be aware that Starlan is the media in you examples.
There is a transport protocol called URP sitting above the media
dependent part.  

Sorry to be so verbose, but the article prompted a comment since
it was so confused.

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 88 21:13:06 GMT
From:      gkn@M5.SDSC.EDU (Gerard K. Newman)
To:        comp.protocols.tcp-ip
Subject:   RE:  Re: Questions on TCP-IP (vs. DECNET)


	From:	 hedrick@topaz.rutgers.edu  (Charles Hedrick)
	Subject: Re: Questions on TCP-IP (vs. DECNET)
	Date:	 15 Jul 88 06:20:12 GMT
	Organization: Rutgers Univ., New Brunswick, N.J.

	DECnet routing tends to be slightly unstable.

This is true to some extent, in that a serial line attached to (say)
a DECSA router can cause lots of triggered routing updates on an
ethernet.  But I've also seen some amazingly unstable routing caused
by unstable serial lines on IP gateways.

	Interfacing DEC's mail system into an environoment with DECnet,
	IP, and BITnet is always a real trip.

Yes, it is, although there is some very good software out there which
will do just that.  My 4 protocol mail gateway (DECnet, IP, BITNET, and
MFENET) handles about 5K messages per week with very little non-automated
attention.

	Some of the newer services seem to have no equivalent on DECnet,
	e.g. the network file system.  I haven't heard or X or NeWS over
	DECnet, though I'd think DEC might have an X over DECnet for its
	VMS-based workstations.

DEC markets a product called DFS which is a distributed file system,
but it isn't really based on DECnet.  Likewise, the VAXcluster file
system isn't based on DECnet, but it too is a distributed file system.
DECWINDOWS is DEC's X-Windows product which supports X11R2 on top of
DECnet.  It is not yet out of field test.

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:	  SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:	  Gerard K. Newman
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138-5608
Phone:	  619.534.5076

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 88 13:16:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   More on HP 3000 (MPE/V) TCP/IP
Since I am not a representative of HP, I cannot issue any comments about
their product plans.  Certainly, HP is aware of the interoperability issues
with their current implementation.  They follow a form of IP-over-802.2
that was a candidate for being a standard (and was published in an early
standard) but which was recently superceded.  And, yes, they use a
different -- and more powerful -- protocol than ARP.

Bottom line, for now, is that the only gateway that you can use is one that
was tailored precisely for interoperabilty with HP
HP's product.  I am only aware of cisco and Wollongong offering such
products.

Dave Crocker

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jul 1988 13:01:37 EDT
From:      Arif Diwan <AD%BROWNVM.BITNET@MITVMA.MIT.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   15 pin ethernet connectors
I agree with Ben Woznick's comment "... worst human engineered..." about
the sliding lock and posts on the 15 pin ethernet connectors (IEEE 802.3
standard??). Then again the old RS232C screw and threaded inserts are not
satisfactory either. Connectors used on MACs, PS/2s etc are OK but
I believe its time someone comes up with a decent connector design -
push it in and it locks securely, press on the sides gently and pull and
it pops out - similar to some IBM printer connectors but better.
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 88 15:53:41 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet SUPRESS-TELNET option...

The reason search for IAC's is a performance issue is because without
it one need not look at individual characters.  Billw works for cisco.
They make terminal servers.  Their terminal servers are not bound by
performance limitations in the Berkeley implementation.  I don't know
how far Billw has gone in optimization, but in principle, they could
get the Ethernet interface to DMA a packet into memory, do a bit of
header processing, and then hand the packet to a DMA serial output
device, without ever looking at the characters at all.  Obviously this
isn't an issue for echoing single characters.  But for screen
refreshes, output on graphics terminals, output to printers, etc., a
reasonable TCP should be able to produce full packets.  Even for the
Berkeley code, processing characters individualy could matter.  It is
true that with a straight-forward implementation, there are a number
of context swaps.  But for large amounts of output data, you should be
able to get the whole screen refresh, or at least a substantial
portion of it, in one activation of telnetd.  In that case, the
efficiency with which it can process the characters may matter.  We
did see noticable differences in CPU time used by telnetd vs rlogind
before we put all of that stuff in the kernel.  In principle, rlogind
can simply do a read from the pty into a buffer and a write from the
same buffer to the network, where telnetd must look at the characters.

I'm not saying whether I think it's a good idea to have an option that
disables IAC checking.  But I can certainly see why Bill believes
there are performance implications.  My guess is that a carefully
tuned implementation can minimze those implications.  (e.g. one could
use something like index(buffer,IAC) to see whether there is an IAC
present, and then work at tuning index in assembly language.)  It's
always a matter of judgement as to whether it is a better idea for the
protocol design to encourage that kind of trickiness or not.  The
tradeoff of course is that to prevent it we complicate the protocol,
and make it likely that implementors won't bother to tune the case
where IAC's are left enabled.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 00:20:00 PST
From:      "TERVAX::EFBATEY" <efbatey%tervax.decnet@nswses.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        efbatey
Subject:   Re: UUCP Over TCP/IP (why?)

Reply-To: <efbatey@NSWSES.ARPA>
Message-Id: <880717233931.1602@tervax>
Comment: < USNSWSES*SOCALSunLUG*DECUS*805/982-5881/983-1220 >

 
Hi Paul,   Remember me .. I'm the poor guy with all the Motorola's constrained
by CMC's not quite tcp .. ( TELNET, FTP .AND. .NOT. SMTP ) .. Yes, there
are hardware / software implementors who can't produce a full TCP/IP suite
I have five such brain dead which desparately want to talk to to my Berk
(Sun_3s) which do speak SMTP.  

Any offers of UUCP over TCP between Sun_3 and SysV Rel 3.3 on Motorola V68
welcomed .. /Ev/

      -------------------------------------------------------------------
      | Everett F. Batey II    } { UUCP:  suned1!efb@elroy.JPL.NASA.GOV |
      | USNSWSES - Code 4V33   } { ARPA:  efbatey@NSWSES.ARPA           |
      |    * SO CAL Sun LUG * DECUS * 805/982-5881 * 805/983-1220 *     |
      -------------------------------------------------------------------
------
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 88 18:32:56 GMT
From:      asjoshi@phoenix.Princeton.EDU (Amit S. Joshi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Ethernet Printer driver using KA9Q code

Hi,
 
Some people had requested a small printer driver that I had written
using the KA9Q code as the interface to the ethernet. Here it is.
Unshar it and compile. I only know that it compiles using Turbo C v1.5
It also need the KA9Q TCP/IP code. ( I know that it works with my port
to Turbo C of Ver 870829.6).
 
Have fun
 

Amit Joshi	BITNET	|	Q3696@PUCC.BITNET
		USENET	| {seismo, rutgers}\!princeton\!phoenix\!asjoshi
"There's a pleasure in being mad... which none but madmen know!" - St.Dryden
 

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  EPRINT.C EPRINT.DOC EPRINT.SH GENERIC.C GENERIC.H MAKE.LIB
#   MAKEFILE READ.ME SYSTEM.RC TICK.C TICK.H
# Wrapped by ibmpc@laphroig.UUCP on Sun Jul 17 14:15:33 1988
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f EPRINT.C -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"EPRINT.C\"
else
echo shar: Extracting \"EPRINT.C\" \(6794 characters\)
sed "s/^X//" >EPRINT.C <<'END_OF_EPRINT.C'
X/*	eprint.c -  a simple print utility  Author: Amit Joshi */
X
X/**
X
X	This is a sample demo program to show how the use of
X	the generic connections simplifies connecting to the 
X	net. You need Phil Karn's KA9Q TCP/IP package, and the 
X	4 files "generic.c", "generic.h", "tick.c" and "tick.h"
X	which have the interface functions.
X	
X	January 1988
X	Amit Joshi
X**/
X
X/** 
X	Revision History:
X	v1.1	March 1988 - added query on printfile option.
X			   - no longer have to perform netservice
X			   - ^C works properly now.
X	v2.0    July 1988  - added wildcards support.
X			   - added recursive directory printing support.
X**/
X
X#define	VERSION	"2.00"
X
X#include <stdio.h>
X#include <stdlib.h>
X#include <string.h>
X#include <dir.h>
X#include <dos.h>
X#include <errno.h>
X#include <sys\stat.h>
X#include <string.h>
X#include <net\generic.h>
X
X#define	PAGEFEED	'\f'
X
X#define	NULLCHAR	(char)NULL
X#define	YES		1
X#define	NO		0
X#define	MAXNAME		80
X
Xextern int errno;
X
Xchar printfailed[] = "Couldn't connect to printer\r\n";
Xint done = 0,closed =1,opened = 0;
Xstatic char **files;
Xstatic int nfiles = 0;
Xstruct generic *gn, *open_generic();	
Xchar next = '\0';
Xint opt[] = {0,0,0,0 };
Xint skip = 0;
Xchar *default_printer = "otto";
X
Xvoid prt_dir();
Xvoid prt_file();
Xvoid print_file();
X
Xvoid
Xpout(gn,bp,cnt)
Xstruct generic *gn;
Xstruct mbuf *bp;
Xint16 cnt;
X{
X	int c;
X	FILE *fd;
X	char *cp;
X	
X	cp = bp->data;
X
X	if ((fd = (FILE *)gn->user) == NULLFILE)  {
X		if (closed == YES) exit(1);
X		else return;
X	}
X	
X	while (cnt != 0) {
X		/* while there is buffer space get characters */
X		if ((c = getc(fd)) == EOF) {
X			/* done current file - flush page */
X			*cp++ = PAGEFEED;
X			bp->cnt++;
X			cnt--;
X			/* check for more files */
X			done = 1;
X			gn->user = (int *)NULLFILE;
X			return;			
X		} else {
X			*cp++ = c;
X			bp->cnt++;
X			cnt--;
X		}
X	}
X}
X
Xpsend() {
X	char *buf[BUFSIZ];
X	struct mbuf *bp, *qdata();
X	FILE *fd;
X	int cnt;
X	
X	if ((fd = (FILE *)gn->user) == NULLFILE)  {
X		if (closed == YES) exit(1);
X		else return;
X	}
X	
X	if ((cnt = sizeof(char)*fread(buf,sizeof(char),BUFSIZ,fd)) != 0) {
X		bp = qdata(buf,(int16)cnt);
X		send_tcp((struct tcb *)gn->tcb,bp);
X	}
X	
X}
X
X/* State change upcall routine */
Xvoid
Xpstate(gn,new)
Xstruct generic *gn;
Xchar new;
X{
X	/* Only interested if connection has been closed */
X	switch (new) {
X#ifdef	DEBUG
X		case LISTEN: printf("\nlistening\n");break;
X		case SYN_SENT: printf("\nsyn sent\n"); break;
X		case SYN_RECEIVED: printf("\nsyn received\n"); break;
X#endif	DEBUG
X		case ESTABLISHED: 
X			printf("connected\n"); 
X			opened = YES;
X			break;
X		case CLOSED:
X			closed = 1;
X#ifdef  DEBUG		
X			printf("Debug: closed\n");
X#endif  DEBUG	
X			break;
X		default: 
X#ifdef  DEBUG
X			printf("pstate, default : new = %d\n",new);
X#endif  DEBUG		
X			break;
X	}
X}
X
Xpopen(char *prtname) {
X	/* open a connection to the printer */
X	gn = open_generic(NULLPORT,PRINTER_PORT,prtname,NULLVFP,pout,pstate);
X	if (gn == NULLGN) {
X		printf("Couldn't connect to printer %s\n", prtname);
X		exit(1);
X	}
X	printf("Opening connection to printer %s ...",prtname);
X	fflush(stdout);
X	opened = NO;
X	closed = NO;
X	while(opened == NO && closed == NO) ;
X	if (closed == YES) exit(1);
X
X}
X
Xpclose() {
X	
X	if (closed == YES) return;
X	
X	close_generic(gn);
X	
X	printf("Done: Waiting to close connection to printer\n");
X	fflush(stdout);
X	
X	while(closed == NO) ;
X	
X}
X
Xvoid
Xprint_file(char *f){
X	
X	char dr[MAXDRIVE],dir[MAXDIR],fn[MAXFILE],fe[MAXEXT],dum[MAXPATH+5];
X	int done;
X	struct ffblk ffblk;
X	
X	fnsplit(f,dr,dir,fn,fe);
X	
X#define	FERR	"ERROR: Path or file name = %s not found\n"
X
X	done = findfirst(f,&ffblk,FA_DIREC);
X	if (done && (errno == ENOENT) && (!opt[1])) {
X		printf(FERR,f);
X	}
X		
X	while (!done) {
X		fnsplit(ffblk.ff_name,dum,dum,fn,fe);
X		fnmerge(dum,dr,dir,fn,fe);
X		if (ffblk.ff_attrib & FA_DIREC) {
X			prt_dir(dum,ffblk.ff_name);
X		} else {
X			prt_file(dum);
X		}
X		done = findnext(&ffblk);
X	}
X}
X
Xvoid
Xprt_file(char *fn)
X{	
X	char c;
X	FILE *file;
X	
X	/* Make sure we have the printer */
X	if (closed == YES) popen(default_printer);
X	
X	if (fn == NULL) {
X		file = stdin;
X	} else 	{
X		/* Do we want to print this file */
X		if (opt[1]) {
X			printf("print %s (y/n) ?",fn); fflush(stdout);
X			while (((c=getch()) != 'y') && (c != 'n'));
X			printf("%c\n",c); fflush(stdout);
X		} else c = 'y';
X		if (c != 'y') return; /* Don't print this file */
X		if ((file = fopen(fn,"r")) == NULL) {
X			if (!opt[3]) {
X				printf("Couldn't open %s\n",fn);
X         			exit(1);
X		        }
X		}
X	}
X
X	gn->user = (int *)file;	
X	if (fn != NULL) printf("Printing file: %s ...",fn);
X	fflush(stdout);
X	psend();
X	while (!done) ;
X	done = 0;
X	if (fn != NULL) {
X		printf(" \n");
X		fclose(file);
X	}
X}
X
Xvoid
Xprt_dir(char *f, char *fn){
X
X	int c;
X	char *temp;
X	void print_file();
X
X	if (!strcmp(fn,".")) return;
X	if (!strcmp(fn,"..")) return;
X	
X	if (!opt[2]) {
X		if (!opt[3]) {
X			printf("%s is a directory, print anyway (y/n) ?",f);
X			while (((c=getch()) != 'y') && (c != 'n'));
X			printf("%c\n",c);
X		} else c = 'y';
X	} else c = 'y';
X	if (c == 'y') {
X		c = strlen(f);
X		strcat(f,"\\*.*");
X		print_file(f);
X		f[c] = NULLCHAR;
X	}
X	
X}
X
Xparseopt(char *f) {
X	
X	if ((*f == '-') && (!skip)) {
X		if (*(++f) == NULLCHAR) {
X			skip = 1;
X		} else while (*f != NULLCHAR) {
X			switch(*f) {
X				case '?': usage('?');
X				case 'p':
X					if (*++f == NULLCHAR) {
X						next = 'p';
X					}  else {
X						if (closed == NO) pclose();
X						popen(f);
X					}
X					return;
X				case 'i':opt[0] = 1;opt[1] = 1;break; 
X				case 'r':opt[0] = 2;opt[2] = 1;break;
X				case 'f':opt[0] = 3;opt[3] = 1;break;
X				case '-':opt[opt[0]] = 0;opt[0] = 0;break;
X				default: if (!opt[1]) usage(*f);
X			}
X			f++;
X		}
X	} else {
X		if (next) {
X			switch(next) {
X				case 'p': 
X					if (closed == NO) pclose();
X					popen(f);
X				default:
X			}
X			next = 0;
X		} else {
X			nfiles++;
X			print_file(f);
X		}
X	}
X}
X
Xusage(char c) {
X	if (c != '?') printf("Unknown option : \"%c\n\"",c);
X	printf("Usage:eprint [-?] [-p<printer>] [-i[-]] [-] <files>\n");
X	printf("\t-?\tPrint this message\n");
X	printf("\t-i[-]\tQuery every file\n");
X	printf("\t-r[-]\tRecursively print contents of directories\n");
X/*	printf("\t-f[-]\tPrint quietly\n");*/
X	printf("\t-\tUse next argument as a file name\n");
X	printf("\t-p <printername>\t Printer to use\n");
X	printf("\t\t\t\t Default  printer is %s\n",default_printer);
X	printf("\t<files>\t files to print. No files => use stdin\n");
X	printf("\nv%s (c) Princeton LCA\n",VERSION);
X	exit(0);
X}
X
Xmain (int argc, char *argv[]) {
X	
X	char *f,*prtopt;
X	int i;
X	
X	(void)remove_cbrk(NULLVFP);   /* NEVER use ^C with the net BAD */
X	prtopt = getenv("PRTOPT");
X	for (f = strtok(prtopt," ");f != NULL; f = strtok(NULL," ")) {
X		parseopt(f);
X	}
X	
X	for (i = 1; i < argc; i++) {
X		f = argv[i];
X		parseopt(f);
X	} 
X	if (!nfiles) {
X		parseopt("-i-");	/* turn off interactive mode */
X		prt_file(NULL);
X	}
X	pclose();
X}
X 
END_OF_EPRINT.C
echo shar: Missing newline added to \"EPRINT.C\"
if test 6794 -ne `wc -c <EPRINT.C`; then
    echo shar: \"EPRINT.C\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f EPRINT.DOC -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"EPRINT.DOC\"
else
echo shar: Extracting \"EPRINT.DOC\" \(4833 characters\)
sed "s/^X//" >EPRINT.DOC <<'END_OF_EPRINT.DOC'
XNAME
X	eprint - print files over the ethernet.
X
XVERSION
X	2.0 July 1988
X
XSYNOPSIS
X	eprint [-?] [-ri[-]] [-pprintername] <files>
X
XDESCIRPTION
X	Eprint prints named files or directories. Unless the '-r' option is
X	specified it asks before printing directories. Options can be stacked
X        and can turned off and on for selective portions of the command line
X        using the turn on/off feature
X
X	Eprint depends links in all the TCP/IP routines from the KA9Q package
X	that it needs and is standalone. It however requires a file called
X	"system.rc" to be located in the root directory in order to resolve
X	host names and certain other TCP/IP setup information. The contents
X	of the "system.rc" file are similar to the "autoexec.net" file
X	in the KA9Q TCP/IP package.
X	
X	An evironment variable lookup is available. Set the environment
X	variable "PRTOPT" from DOS to your favourite settings.The DOS command:
X		set PRTOPT=arguments
X	will set the environment string to the arguments, which are exactly
X	like those by the command itself (including filenames). First the
X	environment options are evaluated, filenames given there are printed
X	and then the usual command string is parsed. A typical use would be 
X	to put the following command in the autoexec.bat file
X
X		set PRTOPT=-i
X
X	A generic option line would look like:
X
X		eprint options files option- files option2- files option files
X
X	The options apply to files following the options and can be turned
X	off by using '-' after the option (see examples).
X       
X
X	-?	Give a short usage note. 
X
X	-r[-]	Print directories recursively. If a directory is encountered 
X		it is printed and all its contents (including subdirectories)
X		are printed. '-r' turns the option on and '-r-' turns the 
X		option off.
X
X	-i[-]	Print interactively. Queries before printing every file.
X		'-i' turns the option on and '-i-' turns the option off.
X	
X	-[-]	Use the next argument as a filename. This is to allow use
X		of file names which begin with a '-'. '-' turns the option
X		on and '--' turns the option off (can't think of any use of
X		'--' since it is a noop!).
X
X	<files>	Names of files to be printed. Wild cards are allowed. For 
X		names begining with '-' see option '-'. Directories are
X		not deleted unless '-r' option is specified. NOTE: If no
X		file name is specified the standard input is used. However
X		since it does not about EOF's from the keyboard (^D or ^Z)
X		this is useful only for pipes and redirected output.
X
XEXAMPLES
X	All examples assume that PRTOPT is not set to anything.
X
X		eprint a *.opt
X	will print the file "a" and all files "*.opt". Directories will not
X        be printed.
X
X		eprint -r dirname
X	will print "dirname" even if it is a directory.
X
X		eprint -r dirs1 -r- dirs2 
X	will print "dirs1" even if it is a directory but will not print 
X	"dirs2" if it is a directory. The option '-r-' is read as follows
X		'-' + 'r-'  => option symbol + don't print directories
X
X		eprint - -r
X	will print a file "-r". Note here because of the '-' option "-r"
X	is used as a filename rather than as an option.
X
XNOTES
X	The option on/off feature is not available in Unix(tm).
X	The environment option is not available in Unix(tm).
X	This version fixes a bug in v1.00 :
X		When a nonexistent single file was asked to be deleted
X		the program correctly found there was no file but then
X		tried to delete the file as if it were read-only.
X	This version fixes a bug in v1.10 :
X		When a multiple directory deletion was attempted the
X		entire disk was wiped out. 
X
XBUGS
X	1. ^C does not work. It may abort the program but will not
X	   reset interrupt vectors and so should not be used. It is
X	   an inherent problem with the KA9Q TCP/IP package.
X	2. When the amount of data to be printed is a lot and the 
X	   printer buffer is full then sometimes the program will 
X	   hang. This is because typically when the printer is 
X	   processing data it does not reply to queries and causes
X	   it's own TCP/IP to time out while the eprint program
X	   does not know this and so it keeps tyring (since it started
X	   the whole thing). One way around is not to use the collated
X	   mode. This bug has been seen on the Imagen 2308 printer using
X	   v3.2 TCP/IP software.
X	Notify all bugs to Q3696@PUCC.BITNET or 
X	{seismo, rutgers}\!princeton\!phoenix\!asjoshi.
X
XACKNOWLEDGEMENTS
X	The program was written using Turbo C v1.5. The command is based on
X	the idea of "iprint", a very basic ethernet printer driver for
X	imagen printers available in binary with the MIT TCP/IP package.
X	This version has been written using the KA9Q TCP/IP package.
X	The program and this manual page are completly written by me.
X	Thanks go to Phil Karn for the great TCP/IP package and very
X	readable code.
X	Thanks also to Borland for the inexpensive, fast C compiler.
X	Thanks to Dennis Linse for pointing some serious shortcomings
X	in v1.1.
END_OF_EPRINT.DOC
if test 4833 -ne `wc -c <EPRINT.DOC`; then
    echo shar: \"EPRINT.DOC\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f EPRINT.SH -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"EPRINT.SH\"
else
echo shar: Extracting \"EPRINT.SH\" \(0 character\)
sed "s/^X//" >EPRINT.SH <<'END_OF_EPRINT.SH'
END_OF_EPRINT.SH
if test 0 -ne `wc -c <EPRINT.SH`; then
    echo shar: \"EPRINT.SH\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f GENERIC.C -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"GENERIC.C\"
else
echo shar: Extracting \"GENERIC.C\" \(7890 characters\)
sed "s/^X//" >GENERIC.C <<'END_OF_GENERIC.C'
X/* Main network program - provides both client and server functions */
X#ifdef	TURBOC	/* The length of the command line causes problems */
X#include "tcdefs.h"
X#endif
X#ifndef	CLEAN
X#define	NSESSIONS	10	/* Maximum interactive client sessions */
X#endif
X#ifndef	STARTUP
X#define	STARTUP	"/system.rc"	/* File to read startup commands from */
X#endif
X
X#ifdef	TURBOC
X#include <stdlib.h>
X#include <alloc.h>
X#endif
X
X#include <stdio.h>
X#include "generic.h"
X
Xextern struct interface *ifaces;
Xextern char major_rev[], minor_rev[];
Xextern struct mbuf *loopq;
X
Xint mode;
XFILE *logfp;
Xchar badhost[] = "Unknown host %s\r\n";
Xint32 gateway;
X
X#ifdef	TRACE
X#include "trace.h"
Xint32 trace;
X#endif
X
X/* Command lookup and branch table */
Xint 	doipaddr(),doexit(),dohostname(),
X	dowindow(),doroute(),
X	domss(),doattach(),
X	dottl(),go(),
X	dogateway();
X
Xstatic struct cmds cmds[] = {
X	/* The "go" command must be first */
X	"",		go,		0, NULLCHAR,	NULLCHAR,
X	"attach",	doattach,	2,
X		"attach <hardware> <hw specific options>", NULLCHAR,
X	"exit",		doexit,		0, NULLCHAR,	NULLCHAR,
X	"gateway",	dogateway,	0, NULLCHAR,	NULLCHAR,
X	"hostname",	dohostname,	0, NULLCHAR,	NULLCHAR,
X	"ipaddr",	doipaddr,	0, NULLCHAR,	NULLCHAR,
X	"mss",		domss,		0, NULLCHAR,	NULLCHAR,
X	"route",	doroute,	0, NULLCHAR,	NULLCHAR,
X	"ttl",		dottl,		0, NULLCHAR,	NULLCHAR,
X	"window",	dowindow,	0, NULLCHAR,	NULLCHAR,
X	NULLCHAR,	NULLFP,		0,
X		"Unknown command; type \"?\" for list",   NULLCHAR, 
X};
X
Xchar hostname[HOSTNAMELEN];	
Xint32 resolve();
Xint16 lportavail = 1001;
Xchar net_inited = 0;
Xchar prompt[] = "net> ";
Xchar nospace[] = "No space!!\r\n";	/* Generic malloc fail message */
Xchar notval[] = "Not a valid TCB\r\n";
Xchar finished = 0,wait_to_close = 0;
Xstruct generic *session;
X	
Xstruct generic *
Xopen_generic(lport,fport,fhost,in,out,state)
Xint16 lport,fport;	/* local and foreign ports */
Xchar *fhost;		/* foreign host name */
Xvoid (*in)();		/* called when ready to process data */
Xvoid (*out)();		/* called when ready to send data */
Xvoid (*state)();	/* called when state changes */
X{
X	void g_state(),grcv_char(),gsend_char();
X	char *inet_ntoa();
X#ifdef	TURBOC
X	void *calloc(),*malloc();
X#else
X	char *calloc(),*malloc();
X#endif
X	int32 resolve();
X	struct generic *gn;
X	struct tcb *tcb;
X	struct socket lsocket,fsocket;
X	
X	if (!net_inited) 
X		if (net_init())
X			return NULLGN;
X	
X	lsocket.address = ip_addr;
X	if (lport == NULLPORT) lsocket.port = lportavail++;
X	else lsocket.port = lport;
X	if ((fsocket.address = resolve(fhost)) == 0) {
X		printf(badhost,fhost);
X		return NULLGN;
X	}
X	
X	if (fport == NULLPORT) {
X		printf("badport %d",fport);
X		return	NULLGN;
X	} else fsocket.port = fport;
X		
X		/* Allocate a session descriptor */
X	if((gn = (struct generic *)calloc(1,sizeof(struct generic))) == NULLGN){
X		printf(nospace);
X		return NULLGN;
X	}
X	gn->in = in;
X	gn->out = out;
X	gn->state = state;
X	
X	tcb = open_tcp(&lsocket,&fsocket,TCP_ACTIVE,0,
X		grcv_char,gsend_char,g_state,0,(int *)gn);
X	gn->tcb = tcb;
X	session = gn;
X	return gn;
X}
X
Xint
Xclose_generic(gn)
Xstruct generic *gn;
X{
X	if (gn != NULLGN)
X		close_tcp(gn->tcb);
X}
X
Xint
Xsend_generic(gn,bp)
Xstruct generic *gn;
Xstruct mbuf *bp;
X{
X	if (gn != NULLGN)
X		if (gn->tcb != NULLTCB)
X			send_tcp(gn->tcb,bp);
X}
X
X/* Generic receiver upcall routine */
Xvoid
Xgrcv_char(tcb,cnt)
Xregister struct tcb *tcb;
Xint16 cnt;
X{
X	struct mbuf *bp;
X	struct generic *gn;
X	
X	if((gn = (struct generic *)tcb->user) == NULLGN){
X		/* Unknown connection; ignore it */
X		return;
X	}
X
X	if(recv_tcp(tcb,&bp,cnt) > 0)
X		if (gn->in != NULLVFP) gn->in(gn,bp,cnt);
X}
X
X/* State change upcall routine */
Xvoid
Xg_state(tcb,old,new)
Xregister struct tcb *tcb;
Xchar old,new;
X{
X	struct generic *gn;
X	char notify = 0;
X	extern char *tcpstates[];
X	extern char *reasons[];
X	extern char *unreach[];
X	extern char *exceed[];
X	void (*state)();
X
X	/* Can't add a check for unknown connection here, it would loop
X	 * on a close upcall! We're just careful later on.
X	 */
X	gn = (struct generic *)tcb->user;
X	if ((state = gn->state) != NULLVFP) notify = 1;
X	
X	switch(new){
X	case CLOSE_WAIT:
X		close_tcp(tcb);
X		break;
X	case CLOSED:	/* court adjourned */
X		if(tcb->reason == NETWORK){
X			printf("%s (%s",tcpstates[new],reasons[tcb->reason]);
X			switch(tcb->type){
X			case DEST_UNREACH:
X				printf(": %s unreachable",unreach[tcb->code]);
X				break;
X			case TIME_EXCEED:
X				printf(": %s time exceeded",exceed[tcb->code]);
X				break;
X			}	
X			printf(")\r\n");
X			fflush(stdout);
X		}
X		del_tcp(tcb);
X		if(gn != NULLGN)
X		free_generic(gn);
X	break;
X	default:
X		break;
X	}	
X	if(notify) state(gn,new);
X}
X
X/* Delete generic structure */
Xstatic
Xfree_generic(gn)
Xstruct generic *gn;
X{
X	if(gn != NULLGN) {
X		free((char *)gn);
X	}
X}
X
Xvoid
Xgsend_char(tcb,cnt)
Xstruct tcb *tcb;
Xint16 cnt;
X{
X	struct generic *gn;
X	struct mbuf *bp;
X	char *cp;
X	int c;
X	
X	if ((gn = (struct generic *)tcb->user) == NULLGN) {
X		/* Unknown connection */
X		return;
X	}
X		
X	if ((bp = alloc_mbuf(cnt)) == NULLBUF) {
X		/* just don't do a thing here */
X		return;
X	}
X	
X	if (gn->out != NULLVFP) 
X		gn->out(gn,bp,cnt);
X	
X	if(bp->cnt != 0)
X		send_tcp(tcb,bp);
X	else
X		free_p(bp);
X}
X
Xint
Xnet_init()
X{
X	static char inbuf[BUFSIZ];	/* keep it off the stack */
X	int cmdparse();
X	FILE *fp;
X	struct mbuf *bp;
X
X#ifdef	TURBOC
X#define	INITERR	"Can't initialize network: %s\n"
X	void c_break();		/* clean up on system abort */
X	void net_exit();	/* clean up on exit */
X	void net_service();	/* net background service routine */
X
X#if	(INSTALL_TIMER != 0)
X	if (install_timer(net_service)) {
X		printf(INITERR, "can't install timer");
X		return 1;
X	}
X#endif	INSTALL_TIMER
X	if (install_cbrk(c_break)) {
X		printf(INITERR,"can't install ctrl brk function");
X		return 1;
X	}
X	if (atexit(net_exit)) {
X		printf(INITERR,"too many exit functions\n");
X		return 1;
X	}
X#endif	TURBOC
X	ioinit();
X	if((fp = fopen(STARTUP,"r")) != NULLFILE){
X		while(fgets(inbuf,BUFSIZ,fp) != NULLCHAR){
X			cmdparse(cmds,inbuf);
X		}
X		fclose(fp);
X	}
X	net_inited = 1;
X	return 0;
X}
X
X/* Clean up everthing before exiting or else pay the price */
Xvoid
Xnet_exit() {
X	net_inited = 0;		/* I'm pessimistic */
X	iostop(0);
X}
X
Xvoid
Xnet_service() {
X	static int n_ticks = 0;
X	struct mbuf *bp;
X	struct interface *ifp;
X
X#if	(INSTALL_TIMER != 0)
X	/* Service net every INSTALL_TIMER ticks to avoid  */
X	/* DOS stack failiures */
X	if (n_ticks++ <= INSTALL_TIMER) return; else n_ticks = 0;
X#endif	INSTALL_TIMER
X
X	/* Service the loopback queue */
X	while((bp = dequeue(&loopq)) != NULLBUF)
X		ip_recv(bp,0);
X	
X	/* Service the interfaces */
X	for(ifp = ifaces; ifp != NULLIF; ifp = ifp->next){
X		if(ifp->recv != NULLFP)
X			(*ifp->recv)(ifp);
X	}
X	
X	grcv_char(session->tcb,0);	/* get any pending input */
X
X	/* Service the clock if it has ticked */
X	check_time();
X}
X
Xgo(){}	/* This needed by the command parser routine! */
X
X#ifdef	TURBOC
Xvoid
Xc_break(void)
X{
X	fprintf(stderr,"Aborting : wait for cleanup ...\n");
X	net_inited = 0;
X	iostop(1); /* clean up dos only */
X}
X#endif
X
X
Xstatic
Xdogateway(argc,argv)
Xint argc;
Xchar *argv[];
X{
X	char *inet_ntoa();
X	int32 n;
X
X	if(argc < 2){
X		printf("%s\r\n",inet_ntoa(gateway));
X	} else if((n = resolve(argv[1])) == 0){
X		printf(badhost,argv[1]);
X		return 1;
X	} else
X		gateway = n;
X	return 0;
X}
Xstatic
Xdoexit(argc,argv)
Xint argc;
Xchar *argv[];
X{
X	iostop();
X	exit(0);
X}
Xstatic
Xdohostname(argc,argv)
Xint argc;
Xchar *argv[];
X{
X	char *strncpy();
X
X	if(argc < 2)
X		printf("%s\r\n",hostname);
X	else 
X		strncpy(hostname,argv[1],HOSTNAMELEN);
X	return 0;
X}
X/* List of supported hardware devices */
Xint ec_attach();
X
Xstruct cmds attab[] = {
X#ifdef	PC_EC
X	/* 3-Com Ethernet interface */
X	"3c500", ec_attach, 7, 
X	"attach 3c500 <address> <vector> arpa <label> <buffers> <mtu>",
X	"Could not attach 3c500",
X#endif
X	NULLCHAR, NULLFP, 0,
X	"Unknown device",
X	NULLCHAR,
X};
X
X/* Attach an interface
X * Syntax: attach <hw type> <I/O address> <vector> <mode> <label> <bufsize> [<speed>]
X */
Xdoattach(argc,argv)
Xint argc;
Xchar *argv[];
X{
X	return subcmd(attab,argc,argv);
X}
END_OF_GENERIC.C
if test 7890 -ne `wc -c <GENERIC.C`; then
    echo shar: \"GENERIC.C\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f GENERIC.H -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"GENERIC.H\"
else
echo shar: Extracting \"GENERIC.H\" \(887 characters\)
sed "s/^X//" >GENERIC.H <<'END_OF_GENERIC.H'
X#ifndef	__GENERIC_H__
X#define	__GENERIC_H__
X
X#include "machdep.h"
X#include "mbuf.h"
X#include "netuser.h"
X#include "timer.h"
X#include "internet.h"
X#include "icmp.h"
X#include "iface.h"
X#include "ip.h"
X#include "tcp.h"
X#include "cmdparse.h"
X#include "pc.h"
X#ifdef	TURBOC
X#include "tick.h"
X#endif
X
X#define	GENERIC_PORT	1024
X#define	NULLPORT	(int16)NULL	
X#define HOSTNAMELEN 32		/* changed from 16 by Bdale 860812 */
X
Xstruct generic {
X	struct tcb *tcb;
X	void (*in)();		/* called when ready to process data */
X	void (*out)();		/* called when ready to send data */
X	void (*state)();	/* called when state changes */
X	
X	int *user;		/* pointer for use by the user */
X};
X#define	NULLGN	(struct generic *)NULL
X
X/* This is a list of the standard internet ports using TCP */
X#define	PRINTER_PORT	35
X
X/* Set netservice rate : 0 => don't use clock ticks  */
X#define	INSTALL_TIMER	2
X
X#endif	__GENERIC_H__
END_OF_GENERIC.H
echo shar: Missing newline added to \"GENERIC.H\"
if test 887 -ne `wc -c <GENERIC.H`; then
    echo shar: \"GENERIC.H\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f MAKE.LIB -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"MAKE.LIB\"
else
echo shar: Extracting \"MAKE.LIB\" \(7174 characters\)
sed "s/^X//" >MAKE.LIB <<'END_OF_MAKE.LIB'
X#	
X#	Makefile for KA9Q TCP/IP package for PC clones with Aztec C
X#
X#	Modified by Amit Joshi to suit Turboc C v1.0
X#
X#	-	Moved all switches to the "tcdefs.h" to handle the
X#		long commandline problem.
X#
X# switches:
X#	define the ones you want in the CFLAGS definition...
X#
X#	TRACE		- turn on tracing/debugging code
X#	SERVERS		- include code for application servers
X#	AMIGA		- include Amiga specific code
X#	MSDOS		- include Messy-Dos specific code
X#	ETHER		- include ethernet specific code
X#	UNIX		- Use UNIX file format conventions
X#	CPM		- Use CP/M file format conventions
X#
X# Hardware driver flags:
X#
X#	SLIP		- include serial line IP stuff
X#	PC_EC		- include 3Com Ethernet board driver for IBM-PC
X#	AX25		- include AX.25 stuff
X#	HAPN		- include HAPN stuff
X#	EAGLE		- include Eagle card driver
X#	PC100		- include PC-100 board driver (incomplete ??)
X#	AMIGA_AE100	- include Ameristar AE-100 Ethernet board driver
X#	AMIGA_ARCNET	- include Ameristar Arcnet board driver
X#
X#	DATE            - include code to datestamp FTP and SMTP actions
X
X#
X# CFLAGS for typical IBM-PC installation
X#
X# OPTFLAGS=-DSERVERS -DMSDOS -DPC_EC -DAX25 -DTRACE -DETHER -DSLIP -DHAPN -DDATE -DEAGLE -DTURBOC
X
X#
X#	CLEAN		- do not include ftp or telnet code but just make a 
X#			  generic TCP/IP utility library.
XMODEL=l
XCFLAGS=-DCLEAN -O
X#
X# CFLAGS for typical Amiga installation
X#
X# CFLAGS= -DSTARTUP="\"S:net.start\"" -DSERVERS -DAMIGA -DAMIGA_AE100 -DTRACE -DETHER  -I../../include
X#
X#	Removed alloc.obj from  NETOBJS since using Turbo C routines -ASJ
X#	Moved ec*.obj from NETOBJS to PCOBJS to avoid double declarations -ASJ
X#
XNETOBJS= ax25cmd.obj ax25.obj ax25dump.obj \
X	slip.obj kiss.obj \
X	arpcmd.obj arp.obj \
X	ipcmd.obj ip.obj iproute.obj \
X	icmpcmd.obj icmp.obj \
X	udpcmd.obj udp.obj \
X	tcpcmd.obj tcpuser.obj tcptimer.obj tcpout.obj tcpin.obj tcpsubr.obj \
X	trace.obj enetdump.obj \
X	ax25dump.obj arpdump.obj ipdump.obj \
X	icmpdump.obj udpdump.obj tcpdump.obj \
X	timer.obj ttydriv.obj cmdparse.obj mbuf.obj netuser.obj \
X	misc.obj pathname.obj generic.obj
X
XPCOBJS= pc.obj dirutil.obj eccmd.obj enet.obj \
X	ec.obj ecvec.obj pc100.obj pc100vec.obj hapn.obj hapnvec.obj \
X	asyvec.obj pcgen.obj eagle.obj eaglevec.obj tick.obj
X
XAPPOBJS= ftpserv.obj ftpcli.obj ftp.obj smtpserv.obj smtpcli.obj \
X	telnet.obj tnserv.obj smisc.obj 
X
XNLIB= $(LIB)\net
X
Xall:	net.lib pc.lib app.lib
X
Xnet.exe:  pc.lib net.lib makefile main.obj version.obj app.lib
X	$(LINK) $(STDOBJFILES) main version,net,,pc net app $(STDLIBFILES) $(LFLAGS)
X
Xinstall: $(NLIB)\net.lib $(NLIB)\pc.lib $(NLIB)\app.lib
X        @echo $(MODEL) > $(NLIB)\model
X	@copy *.lib $(NLIB)
X
Xapp.lib: $(APPOBJS)
X	$(LB) $@ -+ $? ;
X
Xnet.lib: $(NETOBJS)
X	$(LB) $@ -+ $? ;
X
Xpc.lib: $(PCOBJS)
X	$(LB) $@ -+ $? ;
X
Xlibka9q.a: $(NETOBJS) $(APPOBJS)
X	ar rv libka9q.a $(NETOBJS) $(APPOBJS)
X	ranlib libka9q.a
X
Xnet.amiga: makefile $(NETOBJS) $(APPOBJS) amiga.o
X	ld -r -d -o net.amiga $(NETOBJS) $(APPOBJS) amiga.0 ../../lib/alib.a
X
X$(NLIB)\pc.lib: pc.lib
X$(NLIB)\net.lib: net.lib
X$(NLIB)\app.lib: app.lib
X
Xclean:	
X	rm -f *.obj *.exe *.sym *.map *.bak -i *.lib
X
Xarp.obj: arp.c machdep.h mbuf.h timer.h iface.h enet.h ax25.h arp.h tcdefs.h
Xarpcmd.obj: arpcmd.c machdep.h mbuf.h timer.h enet.h ax25.h arp.h cmdparse.h tcdefs.h
Xarpdump.obj: arpdump.c machdep.h mbuf.h timer.h arp.h tcdefs.h
Xasyvec.obj: asyvec.c tcdefs.h
Xax25.obj: ax25.c machdep.h mbuf.h iface.h timer.h arp.h slip.h ax25.h tcdefs.h
Xax25cmd.obj: ax25cmd.c machdep.h mbuf.h ax25.h tcdefs.h
Xax25dump.obj: machdep.h mbuf.h ax25.h trace.h tcdefs.h
Xcmdparse.obj: cmdparse.c machdep.h trace.h cmdparse.h tcdefs.h
Xeagle.obj: eagle.c machdep.h mbuf.h iface.h eagle.h ax25.h tcdefs.h
X#	cc -E300 eagle.c
Xeaglevec.obj: eaglevec.c tcdefs.h
Xec.obj: ec.c machdep.h mbuf.h enet.h ec.h iface.h timer.h pc.h arp.h trace.h tcdefs.h
Xeccmd.obj: eccmd.c machdep.h mbuf.h ec.h tcdefs.h
Xecvec.obj: ecvec.c tcdefs.h
Xenet.obj: enet.c machdep.h mbuf.h enet.h tcdefs.h
Xenetdump.obj: enetdump.c machdep.h mbuf.h enet.h trace.h tcdefs.h
Xftp.obj: ftp.c machdep.h mbuf.h netuser.h timer.h tcp.h ftp.h session.h tcdefs.h
Xftpcli.obj: ftpcli.c machdep.h mbuf.h netuser.h icmp.h timer.h tcp.h ftp.h session.h cmdparse.h tcdefs.h
Xftpserv.obj: ftpserv.c machdep.h mbuf.h netuser.h timer.h tcp.h ftp.h tcdefs.h
Xtelnet.obj: telnet.c machdep.h mbuf.h timer.h internet.h icmp.h netuser.h tcp.h telnet.h session.h tcdefs.h
Xgeneric.obj: generic.c machdep.h mbuf.h netuser.h timer.h internet.h icmp.h iface.h ip.h tcp.h ftp.h telnet.h session.h cmdparse.h pc.h trace.h tcdefs.h generic.h
Xhapn.obj: hapn.c machdep.h mbuf.h iface.h hapn.h ax25.h trace.h tcdefs.h
Xhapnvec.obj: hapnvec.c tcdefs.h
Xicmp.obj: icmp.c machdep.h mbuf.h internet.h timer.h iface.h ip.h icmp.h tcdefs.h
Xicmpdump.obj: icmpdump.c machdep.h mbuf.h internet.h icmp.h trace.h tcdefs.h
Xip.obj: ip.c machdep.h mbuf.h timer.h internet.h iface.h ip.h icmp.h tcdefs.h
Xipcmd.obj: ipcmd.c machdep.h mbuf.h internet.h timer.h netuser.h iface.h ip.h cmdparse.h tcdefs.h
Xipdump.obj: ipdump.c machdep.h mbuf.h internet.h timer.h iface.h ip.h trace.h netuser.h tcdefs.h
Xiproute.obj: iproute.c machdep.h mbuf.h internet.h timer.h netuser.h ip.h icmp.h iface.h trace.h tcdefs.h
Xkiss.obj: kiss.c machdep.h mbuf.h iface.h kiss.h tcdefs.h
Xmain.obj: main.c machdep.h mbuf.h netuser.h timer.h icmp.h iface.h ip.h tcp.h ftp.h telnet.h session.h cmdparse.h pc.h trace.h tcdefs.h
Xmbuf.obj: mbuf.c machdep.h mbuf.h tcdefs.h
Xnetuser.obj: netuser.c machdep.h netuser.h tcdefs.h
Xpc.obj: pc.c machdep.h mbuf.h internet.h iface.h pc.h cmdparse.h tcdefs.h
Xpcgen.obj: pcgen.c tcdefs.h
Xpc100.obj: pc100.c machdep.h mbuf.h iface.h pc100.h ax25.h trace.h tcdefs.h
Xpc100vec.obj: pc100vec.c tcdefs.h
Xslip.obj: slip.c machdep.h mbuf.h iface.h ax25.h slip.h pc.h trace.h tcdefs.h
Xsmisc.obj: smisc.c machdep.h mbuf.h netuser.h timer.h tcp.h tcdefs.h
Xsmtpcli.obj: smtpcli.c machdep.h netuser.h mbuf.h timer.h tcp.h smtp.h trace.h tcdefs.h
Xsmtpserv.obj: smtpserv.c machdep.h mbuf.h netuser.h timer.h tcp.h smtp.h tcdefs.h
Xtcpcmd.obj: tcpsubr.c machdep.h timer.h mbuf.h netuser.h internet.h tcp.h tcdefs.h
Xtcpdump.obj: tcpdump.c machdep.h mbuf.h netuser.h internet.h timer.h tcp.h trace.h tcdefs.h
Xtcpin.obj: tcpin.c machdep.h timer.h mbuf.h netuser.h internet.h tcp.h icmp.h iface.h ip.h tcdefs.h
Xtcpout.obj: tcpout.c machdep.h timer.h mbuf.h netuser.h internet.h tcp.h tcdefs.h
Xtcpsubr.obj: tcpsubr.c machdep.h timer.h mbuf.h netuser.h internet.h tcp.h tcdefs.h
Xtcptimer.obj: tcptimer.c machdep.h timer.h mbuf.h netuser.h internet.h ip.h tcp.h tcdefs.h
Xtcpuser.obj: tcpuser.c machdep.h timer.h mbuf.h netuser.h internet.h tcp.h tcdefs.h
Xtelnet.obj: telnet.c machdep.h mbuf.h timer.h internet.h icmp.h netuser.h tcp.h telnet.h session.h tcdefs.h
Xtnserv.obj: tnserv.c machdep.h mbuf.h timer.h internet.h icmp.h netuser.h tcp.h telnet.h session.h tcdefs.h
Xtrace.obj: machdep.h mbuf.h trace.h tcdefs.h
Xtick.obj: tick.c tick.h 
Xtimer.obj: timer.c machdep.h timer.h tcdefs.h
Xudp.obj: udp.c machdep.h mbuf.h netuser.h udp.h internet.h tcdefs.h
Xudpcmd.obj: udpcmd.c machdep.h mbuf.h netuser.h udp.h internet.h tcdefs.h
Xudpdump.obj: udpdump.c machdep.h mbuf.h netuser.h internet.h udp.h tcdefs.h
Xversion.obj: version.c tcdefs.h
END_OF_MAKE.LIB
if test 7174 -ne `wc -c <MAKE.LIB`; then
    echo shar: \"MAKE.LIB\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f MAKEFILE -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"MAKEFILE\"
else
echo shar: Extracting \"MAKEFILE\" \(180 characters\)
sed "s/^X//" >MAKEFILE <<'END_OF_MAKEFILE'
X# use the LIBS definition to compile eprint.c
XLIBS= $(LIB)\net\pc.lib $(LIB)\net\net.lib
XCFLAGS= -G -r -Z 
X#CFLAGS=-DDEBUG -M -y
XMODEL=l
X
Xall: eprint.exe
X
Xeprint.exe: eprint.c
X###
END_OF_MAKEFILE
if test 180 -ne `wc -c <MAKEFILE`; then
    echo shar: \"MAKEFILE\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f READ.ME -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"READ.ME\"
else
echo shar: Extracting \"READ.ME\" \(2309 characters\)
sed "s/^X//" >READ.ME <<'END_OF_READ.ME'
X
XI needed an ethernet driver for some of my research work here 
XThe only compiler I had was Turbo C and so a long time ago
XI ported the KA9Q codeto Turbo C. This is an old version 
X(major ver = 870829, minor = 6). To use it in a more straight
Xforward manner I wrote a small "generic" interface. To test it
Xout I wrote a small printer driver for our imagen. As it was used
Xin the lab it got more features and became bigger. Some time ago
XI thought it might be of some use to others. So here it is:
X
XThis package has the files needed to compile the eprint program.
XIt does not have the KA9Q TCP/IP code. You will have to get it 
Xfrom some other place. It contains:
X	generic.c	- interface code to the TCP/IP package.
X	generic.h	- include file for interface code.
X	tick.c		- background timer and ^C handler.	
X	tick.h		- include file for tick.c
X	eprint.c	- the printer driver code.	
X	make.lib	- the make file for the TCP/IP package. (see note). 
X	makefile	- the makefile for the eprint program.
X	eprint.doc	- manual page for the eprint program.
X	read.me		- this file.
X	system.rc	- sample system setup file.
X
XThe generic.* files are written to simplyfy interfacing to the KA9Q TCP/IP
Xpackage.
XRather than keep in a loop to service the network a small set of functions
Xwas written to install and start a timer that ran installed functions. The 
Xsame package also installs ^C (cbrk) handlers in a fashion similar to the 
Xatexit() function for exits. These functions are available in the files 
Xtick.* . These functions are completely Turbo C dependent and are completely
Xindependent of the rest of the package.
XThere is a file 'make.lib' which is provided to give an idea of which KA9Q
XTCP/IP code goes into which libraries - my arrangement is slightly different.
X'eprint.c' is the code for the printer driver routines, and 'makefile' is the 
Xmakefile for the program.
XThis program has been tested and is running fine on IBM PC/AT's (8 and 10 Mhz)
XIBM PC/XT's . It does not work with the fast mode with an Orchid turbo board
Xfor the XT.
X
XThere are I'm sure bugs - i'll be happy to try to fix those that I can.
XThe usual caveats apply - it is supplied strictly AS IS with no warranties
Xfor any purpose.
X 
XHave fun
XAmit Joshi	INTERNET | ...{seismo, rutgers}\!princeton\!phoenix\!asjoshi
X		BITNET   | Q696@PUCC.BITNET
X 
END_OF_READ.ME
if test 2309 -ne `wc -c <READ.ME`; then
    echo shar: \"READ.ME\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f SYSTEM.RC -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"SYSTEM.RC\"
else
echo shar: Extracting \"SYSTEM.RC\" \(351 characters\)
sed "s/^X//" >SYSTEM.RC <<'END_OF_SYSTEM.RC'
X# Attach interfaces
X# Syntax: attach <hw type> <I/O address> <vector> <mode> <label>
X#                <bufsize> <mtu> [<speed>]
X#
X# attach to the ethernet board
Xattach 3c500 0x300 3 arpa ec0 5 1500
X#
X# 	Remainder of configuration
X#
Xhostname amelia.princeton.edu
Xttl 16
Xipaddr [128.112.30.6]
Xroute add default ec0
Xgateway leonardo
Xwindow 1500
Xmss 256
X
END_OF_SYSTEM.RC
if test 351 -ne `wc -c <SYSTEM.RC`; then
    echo shar: \"SYSTEM.RC\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f TICK.C -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"TICK.C\"
else
echo shar: Extracting \"TICK.C\" \(5922 characters\)
sed "s/^X//" >TICK.C <<'END_OF_TICK.C'
X/*	tick.c - installs a function which is called every clock tick */
X/*	(c) - Amit Joshi, Princeton University
X
X	This code may be used freely for any noncommercial use. It may NOT
X	be used in any commercial package without written permission from
X	the author. This clause is to protect me from legal hassles with
X	the university about code developed here. This code is supplied
X	"AS IS" i.e. with no warranty. Do not remove this notice. Any
X	modifications should be clearly noted before redistribution.
X**/
X
X/**	Amit Joshi
X	MAE Dept., Engg. Quad.
X	Princeton University
X	December 1987
X**/
X
X/**
X	The __tick__() and dosbusy() functions have been stolen from the
X	"rdir.c" code by Dean D. McCrory. The __tick__() has been
X	rewritten (and renamed from timer_handler()) to be more general.
X	Amit Joshi
X	January 1988
X**/
X
X/**     Most recent version, including stack stuff
X        June 1988
X**/
X
X#include <stdlib.h>
X#include <stdio.h>
X#include "tick.h"
X
X/*
X *
X * Fred's rad "own stack" stuff
X *
X */
X
X#define  STACKSIZE	10000
X
X	char	my_stack[STACKSIZE];
Xconst	char	*stp = my_stack + STACKSIZE - 10;
X
Xvolatile static unsigned	oldss, oldsp;
X
X#define	set_stack()	{	disable();		\
X				oldss = _SS;		\
X				oldsp = _SP;		\
X				_SS = FP_SEG(stp);	\
X				_SP = FP_OFF(stp);	\
X				enable();		\
X			}
X
X#define	reset_stack()	{	disable();		\
X				_SS = oldss;		\
X				_SP = oldsp;		\
X				enable();		\
X			}
X
X
X/* Stuff for to handle the ctrl break functions */
Xstatic int __nc_brks = 0;
Xstatic char _abort = 1;
Xstatic void (* __c_brks[NCBRKS])(void);
X
X/* Stuff to run timers */
Xstatic void interrupt (* __otimer)(void) = NULLIVFP;
Xstatic int __ntimers = 0;
Xstatic void (* __timers[NTIMERS])(void);
Xstatic char far * dosbusy_fl;    /* dos maintains this */
X
X/* The functions used in this file */
Xstatic int __cbrk(void);
Xstatic void __clean_timer(void);
Xstatic void interrupt __tick__(void);
Xstatic char far * getdosbusy(void);
X
Xstatic int __cbrk(void) {
X	int nf;
X
X	if (_abort) {
X		for (nf = 0; nf < __nc_brks; ++nf) (* __c_brks[nf] ) ();
X		return(0);
X	} else return(1);
X}
X
Xstatic void __clean_timer(void) {
X	if (__otimer == NULLIVFP) return;	 /* nothing set yet */
X	setvect(TIMER_INT,__otimer);
X}
X
X
X
X
X
X/* __tick__ ()
X *
X * This function intercepts the hardware timer interrupt.  It checks the
X * dosbusy flag and runs through a list of timer driven functions if safe
X * to do so.
X */
X
Xvolatile	int	in_fl = 0;
X
Xstatic void interrupt __tick__(void)
X{
X	int	timer;
X
X/* if the following statement is NOT coded, the 8259 blocks all hardware
X * interrupts including the keyboard interrupt.  Since we wait for a key
X * in list_directory(), this causes the PC to lock up.  This one took
X * a while to figure out
X */
X	outportb (0x20, 0x20);	/*	send eoi to 8259	*/
X
X	(*__otimer) ();		/* chain to previous timer handler */
X
X	if (! in_fl && ! *dosbusy_fl) {
X		in_fl = 1;                 /* we are in our ISR */
X/*
X *
X * run through the list of timers
X *
X */
X
X		set_stack();	/* use our own big gnarly stack	*/
X
X		for (timer = 0; timer < __ntimers; ++timer) {
X			if (__timers[timer] != NULLVFP) {
X				(*__timers[timer]) ();
X			}
X		}
X
X		reset_stack();	/* give back wimpy stack	*/
X
X		in_fl = 0;
X	}
X	return;                    /* return from ISR */
X}
X
X/* getdosbusy ()
X *
X * Gets the Dos busy flag through interrupt 34h.  This Dos function returns
X * the busy flag address in es:bx.  This is an UNDOCUMENTED feature of Dos,
X * however it has worked in Dos versions 2.11 - 3.30 for me - Dean McCrory.
X */
Xstatic char far * getdosbusy (void)
X{
X   struct SREGS sregs;        /* segment registers */
X   union REGS regs;           /* normal registers */
X
X   regs.h.ah = 0x34;          /* get dos busy flag address (UNDOCUMENTED) */
X   intdosx (&regs, &regs, &sregs);
X   return (MK_FP (sregs.es, regs.x.bx));
X}
X
Xint	install_timer(void (*func)(void))
X{
X	int i = 0;
X	void __clean_timer();
X	void interrupt __tick__();
X
X	/* check if the function is already installed */
X
X	if (!__ntimers) {
X		__otimer = getvect(TIMER_INT);
X
X		/* Get address of DOS busy flag. */
X
X		dosbusy_fl = getdosbusy();
X
X		if (atexit(__clean_timer)) return 2;
X		install_cbrk(NULLVFP);
X		setvect(TIMER_INT,__tick__);
X	}
X
X	/* are we already installed ? */
X
X	for (i=0; i < __ntimers; i++) if (__timers[i] == func) return(0);
X
X	/* enough space for another function ? */
X
X	if (__ntimers >= NTIMERS) return(1);
X	__timers[__ntimers++] = func;
X	return(0);
X}
X
Xint remove_timer(void (*func)(void))
X{
X	int i = 0;
X
X	if (func == NULLVFP) {
X		__clean_timer();
X		__ntimers = 0;
X		return(0);
X	}
X
X	if (!__ntimers) return(1);	/* No timers return func not there */
X
X	do {
X		/* have we found the function ? */
X		if (__timers[i] == func) {
X			/* is it the last one in the chain ? */
X			if (i++ == __ntimers) {
X				__timers[i-1] = NULLVFP;
X			} else {
X				/* move the chain backwards */
X				do {
X					__timers[i-1] = __timers[i]; i++;
X				} while(i <= __ntimers);
X			}
X			__ntimers--;
X			return(0);
X		} else i++;
X	} while (i < __ntimers);
X	return(1);
X}
X
Xint install_cbrk (void (* func)(void))
X{
X	int i = 0;
X
X	if (!__nc_brks) {
X		setcbrk(1);	/* ensure that ctrl break is enabled */
X		ctrlbrk(__cbrk);
X		_abort = 1;
X	}
X
X	if (func == NULLVFP) {
X		_abort = 1;
X		return(0);
X	}
X
X	for (i = 0; i < __nc_brks; i++)	if (__c_brks[i] == func) return(0);
X
X	/* enough space for another function ? */
X
X	if (__nc_brks >= NCBRKS) return(1);
X	__c_brks[__nc_brks++] = func;
X	return(0);
X}
X
Xint remove_cbrk (void (* func)(void))
X{
X	int i = 0;
X
X	if (func == NULLVFP) {
X		_abort = 0;
X		return(0);
X	}
X
X	if (!__nc_brks) return(1);	/* No timers return func not there */
X
X	do {
X		/* have we found the function ? */
X		if (__c_brks[i] == func) {
X			/* is it the last one in the chain ? */
X			if (i++ == __nc_brks) {
X				__c_brks[i-1] = NULLVFP;
X			} else {
X				/* move the chain backwards */
X				do {
X					__c_brks[i-1] = __c_brks[i]; i++;
X				} while(i <= __nc_brks);
X			}
X			__nc_brks--;
X			return(0);
X		} else i++;
X	} while (i < __nc_brks);
X	return(1);
X}
END_OF_TICK.C
echo shar: Missing newline added to \"TICK.C\"
if test 5922 -ne `wc -c <TICK.C`; then
    echo shar: \"TICK.C\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f TICK.H -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"TICK.H\"
else
echo shar: Extracting \"TICK.H\" \(1464 characters\)
sed "s/^X//" >TICK.H <<'END_OF_TICK.H'
X/*	tick.h - the include file for timer and c_brk function installation */
X/*	(c) - Amit Joshi, Princeton University 
X
X	This code may be used freely for any noncommercial use. It may NOT
X	be used in any commercial package without written permission from
X	the author. This clause is to protect me from legal hassles with
X	the university about code developed here. This code is supplied
X	"AS IS" i.e. with no warranty. Do not remove this notice. Any 
X	modifications should be clearly noted before redistribution.
X**/
X
X/**	Amit Joshi
X	MAE Dept., Engg. Quad.
X	Princeton University
X	December 1987
X**/
X
X/**
X	Change the values defined for NTIMERS and NCBRKS to increase 
X	number of timer and cbrk functions installed.
X
X	Amit Joshi
X	January 1988
X**/
X
X#ifndef	__TICK_H__
X#define	__TICK_H__
X
X#include <dos.h>
X
X/* Change the following definitions to increase number of timers and cbrks */
X#define	NTIMERS	3	/* number of timers installable */
X#define	NCBRKS	3	/* number of cbrks installable */
X
X#define NULLIVFP	(void interrupt (*)())NULL
X#define	NULLVFP		(void (*)())NULL
X#define NULLFP		(int (*)())NULL 
X
X/* The hardware interrupt works in all models. */
X#define	HARDTIMER	1	 
X
X#ifdef	HARDTIMER
X#define	TIMER_INT	0x08
X#else
X#define TIMER_INT	0x1C 	
X#endif
X
X/* user callable functions */
Xint	_Cdecl		install_timer(void (*func)());	
Xint	_Cdecl		install_cbrk(void (*func)());
Xint	_Cdecl		remove_timer(void (*func)());
Xint	_Cdecl		remove_cbrk(void (*func)());
X
X#endif	__TICK_H__
END_OF_TICK.H
if test 1464 -ne `wc -c <TICK.H`; then
    echo shar: \"TICK.H\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of shell archive.
exit 0
-- 
Amit Joshi	BITNET	|	Q3696@PUCC.BITNET
		USENET	| {seismo, rutgers}\!princeton\!phoenix\!asjoshi
"There's a pleasure in being mad... which none but madmen know!" - St.Dryden

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 00:01:00 GMT
From:      Fitch@DOCKMASTER.ARPA
To:        comp.protocols.tcp-ip
Subject:   Wollongong/recvfrom summary


We can put the Wollongong/recvfrom question to rest.  I have what I need
to know concerning QIOs plus an understanding of the Crusades (see
comment 4).

1) The QIO interface DOES require the extra two bytes in the recvfrom
from
   parameter.  "The returned "sockaddr" structure is preceeded by
   a 16-bit length.  Here is the reasoning -- the networking code under VMS
   uses "DIRECT-IO" which involves locking down pages.  The QIO support for
   this allows you lock down a primary buffer (the read/write buffer) and
   one secondary buffer.  The real UNIX way is to have 3 areas -- the
   read/write buffer, the returned sockaddr and the returned length.  But
   this is exceedingly difficult to do with VAX/VMS QIOs."  [David Kashtan].

2) The extra two bytes are not necessary if you go through the C library
   and not the QIOs.  As the Wollongong folks picked up, I was obviously
   using the QIOs.  The C library smooths out some rough edges and also gives
   you a few more functions.  [Jerry Scott].
   The Ada interface I was using imported the QIOs directly instead of getting
   to them via the C library; thus anything you would get for free via the
   library (such as the two byte work around) was lost and was killing my code.

3) The real problem was that the documentation makes the QIOs look like
they
   implement the socket interface (the spare two bytes are used in an example
   MACRO program, but the normal sockaddr is used in the documentation.)
   I have messages from Wollongong asking for more detail, so I can pursue
   this off of tcp-ip.

4) Finally, it is no wonder there were Crusades if people then took
religion
   as seriously as we take programming languages today.  My comment on being
   able to read MACRO brought as much mail as the socket/QIO issue.  MACRO, C,
   and Ada all got praise and flames.  The funny part is that my intention was
   to emphasize that I had to read the code ITSELF and ignore the comments.

--Jack Fitch@Dockmaster.Arpa

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 02:21:30 GMT
From:      treese@athena.mit.edu (Win Treese)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Hesiod Name Service now available


Project Athena is pleased to announce the availability of a preliminary
version of the Hesiod name server.  Hesiod is a general-purpose name server
layered atop the BIND domain name server from the University of California
at Berkeley.  It was described at the Winter '88 USENIX conference by
Steve Dyer, one of the original implementors.

The distribution is available on athena-dist.mit.edu (18.71.0.38) for anonymous
ftp.  There are both compressed and uncompressed tar archives in
pub/hesiod.tar and pub/hesiod.tar.Z.

Communication about Hesiod takes place on the mailing list
hesiod@athena.mit.edu.  For more information about Hesiod, or to be
added to the mailing list, please send mail to hesiod-request@athena.mit.edu.

	Win Treese
	DEC/Cambridge Research Lab/Project Athena
	treese@athena.MIT.EDU

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 88 10:55:08 -0400
From:      Mike Brescia <brescia@park-street>
To:        Steve Deering <deering@PESCADERO.STANFORD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   multicast address(es) for ARP (was: a proposed modification ...)
An idea I have heard is to use as the multicast address for
"ARP-FOR-PROTOCOL-X" is <4-bytes-of-multicast-prefix><X>, i.e.
    ARP-for-IP     01-00-5e-00-08-00
    ARP-for-CHAOS  01-00-5e-00-08-04.

If you are a host listening for ARP on protocol X, you fire that up.  That
means IP requires 2 multicast filter slots to get off the ground (1 for ARP,
one for 'IP-all-hosts'), plus any other multicast groups that it may join,
plus multicast groups for other protocols (ISO-all-hosts, etc...)

Mike Brescia
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 09:15:27 GMT
From:      jmg@cernvax.UUCP (jmg)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

In article <8807131426.AA04434@gaak.LCS.MIT.EDU> map@GAAK.LCS.MIT.EDU (Michael A. Patton) writes:
>It isn't possible to buy fewer than 2^24, that's the smallest package
>available :-)  When you buy Ethernet addresses, you buy a 24 bit
>prefix, and you get to assign the other 24 bits as you see fit.  This
>seems like exactly the kind of scheme that fits this well.

When we asked for, and got, our own Ethernet addresses (from Xerox)
we got just 4096, i.e. the last three bytes only were free for us.
Of course, we are not a major manufacturer, but only a small-time
producer of a few home-built controllers.

I have no idea whether there are other possibilities!

-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 09:18:37 GMT
From:      jmg@cernvax.UUCP (jmg)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP


Of course, I meant the last three nibbles (12 bits total), not bytes, in
the follow-up which I just sent.
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 14:55:08 GMT
From:      brescia@park-street (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   multicast address(es) for ARP (was: a proposed modification ...)

An idea I have heard is to use as the multicast address for
"ARP-FOR-PROTOCOL-X" is <4-bytes-of-multicast-prefix><X>, i.e.
    ARP-for-IP     01-00-5e-00-08-00
    ARP-for-CHAOS  01-00-5e-00-08-04.

If you are a host listening for ARP on protocol X, you fire that up.  That
means IP requires 2 multicast filter slots to get off the ground (1 for ARP,
one for 'IP-all-hosts'), plus any other multicast groups that it may join,
plus multicast groups for other protocols (ISO-all-hosts, etc...)

Mike Brescia

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 15:00:23 GMT
From:      goldstei@MITRE.ARPA (Steve Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Los Alamos' High Speed Channel--Info anybody?

Folks,

June '88 Defense Science (pg 18) tells of LANL's High Speed Channel development by
Don Tolmie, Michael McGowen, and Gene Dornhoff.  "The HSC appears headed toward
quick adoption as a computer industry standard. ... HSC is a package of wires 
that carries about 800 million bits of computer information each second ...
Tolmie says the superfast link has attracted the interest of 80 
manufacturers ...  including ... IBM, Digital, and Cray... 
American National Standards Istitute...
is expected to make it an industry standard for high-speed computer  communic-
ations by late 1988...The HSC is surprisingly simple in concept and design...
iMcGowen ... and the others adaptedn a ... link they had been using for 
about 10 years, making it shorter, doubling its wires, and increasing the speed.And by converting ... to fiber optics, ...their distances can be increased 
almost indefinitely"

I guess I have been asleep at the switch.  Anybody have any info/thoughts to
share on this development?  How does it fit into the IP world (or does it)?

All info appreciated--even flames for my being so out of touch!

e

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 15:02:26 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   a proposed modification to ARP

> I just barfed up my breakfast.  Have they stopped teaching modularity
> and functional boundaries in computer science classes?

ARP is one of the quintessentially elegant protocols.  An enormous
amount of power is provided for a very simple implmentation.  Let's
keep it that way.

Let's also remember that ARP runs on 5 networks other than Ethernet
(Experimental Ethernet, AX.25, ProNET, Chaosnet, and ARCNET) that
don't have multicast, only broadcast.

Of course I could be a real killjoy and note that ARP won't be needed
on ISO networks, routers will send you redirects instead.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 15:02:41 GMT
From:      mfidelma@bbn.com (Miles Fidelman)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   LAN to ISDN Interface Standards


Does anybody out there know what's happening in the IEEE 802.9 (LAN to
ISDN Interface) committee? For that matter does anybody have a feel
for how 802.6 Metropolitan Area Networks will link to ISDN?

Thanks much,

Miles

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 15:20:40 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Group designs.. :-)


   Date: Thu, 14 Jul 88 23:00:39 PDT
   From: sms@etn-wlv.eaton.com (Steven M. Schultz)

    "a camel is a horse designed by a committee".

And don't forget: "An elephant is a mouse built to MIL-Spec."

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 17:06:06 GMT
From:      cam%columbia-pdn@ACC-SB-UNIX.ARPA (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Token ring IP encapsulation

Folks,

Where are the particulars specified regarding transmission of IP datagrams over
Token Ring (802.5) networks (eg. RFC's, IDEA's, etc.)?

Is there a necessity to support the optional RI (Routing Information) field
in the MAC header when IP is used ("optional" meaning the RI field is not 
always present in the MAC header)? This field supports link-level source
routing (ala IBM).

I presume that IP packets must actually be encapsulated in LLC framing and
that in turn is encapsulated in MAC framing. Correct? Comments?

Again, pointers to documents where this is specified / described would be
most appreciated.

Chris Markle - ACC
cam%columbia-pdn@acc-sb-unix.arpa

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 17:36:58 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   a proposed modification to ARP

>Of course I could be a real killjoy and note that ARP won't be needed
>on ISO networks, routers will send you redirects instead.
 
Address resolution is normally done by the ES-IS protocol, ISO 9542.
Hosts (ESs) and routers (ISs) periodically multicast Hellos to one
another, providing the net-subnet mapping (NSAP-SNPA in the parlance).
Hosts can listen to the other hosts' ES hellos if desired, thus learning
the mapping directly;  otherwise they can bounce the packets off of a
router and get a redirect.
 
The packet overhead of redirects vs. ARP is the same, and there are a couple
of advantages to the ISO approach.  First, no broadcasts are necessary to
resolve the address (and hosts only have to listen to IS multicasts and
thus aren't bothered by other hosts' address resolution).  Second, it is
unnecessary to hold on to the data packet while the address is being
resolved, which reduces implementation complexity and other fuzzy issues
(how long to hold onto the packet before giving up?).
 
For isolated nets with no routers, hosts multicast data packets with
unresolved net addresses to other hosts (essentially a broadcast since
there are only hosts on the wire), and the destination host sends an
ES hello directly to the sender for future reference.
 
Dave Katz
Merit/NSFnet

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 88 18:39:47 GMT
From:      adelman@WARBUCKS.AI.SRI.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   VMS TCP/IP software news


    As many of you probably have heard, David Kashtan accepted a
position with another company to work on their TCP project.  I would
like to announce, however, that this is not happening.

    After much thought and many discussions, David and I have joined
together to form a new company, called TGV.

    TGV has acquired a license from SRI International to the MultiNet
family of software (including MM-32 and Software Tools Mail
Gateway-II). TGV will market and maintain the software. We will also
offer maintenance and other services to the existing MultiNet
customers.

    David and I can still be reached, for the time being, at SRI.


					    Kenneth Adelman
					    TGV

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 08:20:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re: TN3270 for VMS
This is in reply to Scrott Brim's query of 7 July.

A "native" version of tn3270, running over the WIN/TCP for VMS, is
operational and entering beta testing.  It should be generally available
shortly.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 04:05:42 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

in article <7324@ico.ISC.COM>, dougm@ico.ISC.COM (Doug McCallum) says:
> Xref: nusdhub comp.dcom.lans:352 comp.protocols.tcp-ip:1080 comp.protocols.iso:44
> 
> In article <1104@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>>in article <666@cbnews.ATT.COM>, mark@cbnews.ATT.COM (Mark Horton) says:
>>> Xref: nusdhub comp.dcom.lans:345 comp.protocols.tcp-ip:1043 comp.protocols.iso:42
>>If my perceptions are correct then trying to write a TCP/IP driver
>>over a "TLI device" is a non-sequetor.  The order, top to bottom,
>>of the stream should be: TLI over TCP/IP over STREAMS Device; such
>>that you have a STREAMS conformant TCP/IP driver for your ethernet
>>board, and then you push a custom made TLI-to-TCP/IP STREAMS module
>>on the stream before you hand the connection to a TLI conformant
>>application.
> 
> You wouldn't normally write a TCP/IP driver over a TLI device (but
> I can see a case where you might).  All the previous discussion seemed
> to be saying that a TCP/IP device would support TLI directly.  That is,
> it conforms to the AT&T "Transport Provider Interface" specification which
> the TLI library and modules expect.  Since TCP can be implemented to the 
> TPI specification, no special conversion module is required.

In my recolection, the originator of this thread said that he was
"trying to write a TCP/IP <something> which would run over TLI,"
and was having a bitch of a time because "There was no preset way
of handling addresses" in TLI.

As far as an address being something that a user can be "prompted
for"  any user who wants to talk to machine 'X' had better know
the "address" of machine X, or some alias which will relate.
If the user has to type "AA093749823FEBCC836628973DA31.22" or
"Go\nFind\nThe\nMachine\nThat\nHas\nService\nX" to
get there, they can type this at their console, they can not,
however, type in the spesification of a 45 byte structure and
media spesific addressing scheme... As far as passing this
"legible" address to the TLI provider, this is _exactly_ what
takes place; If the dirver has to translate this to get the
afor mentioned structure, fill a 50 byte real number, or go out
and get name service, that is what it does, no questions asked.
Hence teh value of the aledged uniformity.

The idea is (according to the manuals) to have a layer which
accepts a single string/sequential structure from above
and does to it what is necessary to the media/protocol below.
Either the TLI layer is made sufficiently intellegent to take
the input as a string, or the whole point of a uniform
interface goes right out the window.

To whit: (from definition of M_PROTO message T_INFO_ACK of the
	TLI internals definition from the "porting rules" doccument)

ADDR_size	(a return value of) -2 spesifies that the transport
		provider  does not provide  user access to transport
		spesific addresses.

T_ERROR_ACK  Return coed TBADADDR:
	Indicates that _protocol_ address was in incorrect format
	or the address contained incorrect illegal information...

These two imply (wrongly?) that the TLI is for insulation from the
uglies, instead of the "this is just another library" outlook.


> Sorry to be so verbose, but the article prompted a comment since
> it was so confused.

The article _was_ confused because so was I.  If the TLI is the
difinition of an "OSI Transport Layer" then the presence of TCP/IP
as the layer below this makes sense, in the sense that TLI
is capable of being implemented _over_ TCP/IP.  The original
statement of the original poster that he wanted to place TCP/IP
_over_ TLI made no sense to me... further, there would also be
no point in writing said "application" if what he actually needs
is TCP/IP information.

Trying to put TCP/IP into TLI (a real squeze, and since TLI is
supposed to be an _optional_ way of hiding the mess anyway...)
I did not see what the problem was beyond bad choice of environment
on the programmers part.

The whole thread of putting something very TCP/IP into TLI and then
bitching about the loss of direct address fiddling seems riduclous.
Hence my quest for understanding.

Rob.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 88 12:33:09 PDT
From:      cire@clash.cisco.com
To:        jas@proteon.com (John A. Shriver)
Cc:        DCP@quabbin.scrc.symbolics.com, tcp-ip@sri-nic.arpa
Subject:   Re: a proposed modification to ARP
>> Date: Mon, 18 Jul 88 11:02:26 EDT
>> From: jas@proteon.com (John A. Shriver)
>> To: DCP@quabbin.scrc.symbolics.com
>> Cc: tcp-ip@sri-nic.arpa
>> Subject: a proposed modification to ARP
>> Status: O
>> 
>> ARP is one of the quintessentially elegant protocols.  An enormous
>> amount of power is provided for a very simple implmentation.  Let's
>> keep it that way.

Here here.  I also have a question.  If ARP was built to use
multicasts wouldn't that just replace one problem with another
one?  The hosts on the network would have to be properly configured
to use an appropriate multicast or group of multicasts.  How well
will this interoperate with other vendor's implementations?  Is
all this worth it?

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue 19 Jul 88 09:54:19-EDT
From:      RichDeJordy, x295 <RAD@VAX01.AMS.COM>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        rad@VAX01.AMS.COM
Subject:   ACSnet access
I hope someone on this list can help me.  

I have a user who is attempting to reach someone by electronic mail.  The 
person in question is on ACSnet and we are on Arpanet.  The address 
which we were given is

	user@MONCSBRUCE.OZ (ACSNET)

I've tried various stategies to send mail to this host.  My mailer won't
accept this as is.  After searching through variou header files, I eventually
tried routing it through uu.net, but received no reply, so I assume it never
got there.  Can anyone tell my is there is a gateway or something out there
that will route this for me?

	(Oh yes, I tried all permutations of .oz and .au that I could
	think of as well, still having my mailer tell me that they were
	unknown hosts.)

Thanks in advance, 
Richard DeJordy
Systems Programmer
American Mathematical Society
Post Office Box 6248
Providence, RI 02104
(401) 272-9500

RAD@MATH.AMS.COM on the Internet
-------
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 09:41:08 GMT
From:      steve@edm.UUCP (Stephen Samuel)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Re: UUCP Over TCP/IP (why?)

From article <387@comdesign.UUCP>, by pst@comdesign.uucp (Paul Traina):
> Pardon my ignorance,  but I'm confused about running uucp over TCP links.
> 
> My question is why?  The ftp/smtp/bsmtp interface seems much better for
> handling files & mail, and for those who run it, the rsh interface seems
> better than uux.  So, I ignorantly ask,  why do some folk run uucp over TCP?

Simple: Why do people use fortran on a MIPS?? 
	Because it still works, and people are used to it.

For a lot of things, it's much easier to add TCP support under UUCICO
than it is to rewrite everything else that is used to the UUCP interface
program set.

It's a lot easier being able to go from a serial line connection to
an ethernet connection by changing one line in L.sys (or Systems)
than it is to teach everybody how to use the "new and improved" stuff
Besides -- UUCP is kinka fire-and-forget. Who cares what protocol it uses
as long as it works.
rsh/ftp/rcp require a supporting UID on the remote system, and that's not
necessarily easy to arrange. They also need a bit more babysitting than FAF
UUCP.

-- 
-------------
 Stephen Samuel 			Disclaimer: You betcha!
  {ihnp4,ubc-vision,mnetor,vax135}!alberta!edm!steve
  BITNET: USERZXCV@UOFAMTS
-- 
-------------
 Stephen Samuel 			Disclaimer: You betcha!
  {ihnp4,ubc-vision,mnetor,vax135}!alberta!edm!steve
  BITNET: USERZXCV@UOFAMTS

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 16:44:00 EST
From:      "BARRY NEWTON" <newton@enh.nbs.gov>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        <newton@vax.cam.nbs.gov>
Subject:   IBM S/3x networking
Is anybody out there aware of a tcp-ip implementation for the System/36 or
any machine in that series?  I don't have much hope when there's nothing
in the Vendor's Guide, but this note seemed worth a shot.  Thanks.

Barry L. D. Newton
National Bureau of Standards

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 13:54:19 GMT
From:      RAD@VAX01.AMS.COM (RichDeJordy@SRI-NIC.ARPA, x295)
To:        comp.protocols.tcp-ip
Subject:   ACSnet access

I hope someone on this list can help me.  

I have a user who is attempting to reach someone by electronic mail.  The 
person in question is on ACSnet and we are on Arpanet.  The address 
which we were given is

	user@MONCSBRUCE.OZ (ACSNET)

I've tried various stategies to send mail to this host.  My mailer won't
accept this as is.  After searching through variou header files, I eventually
tried routing it through uu.net, but received no reply, so I assume it never
got there.  Can anyone tell my is there is a gateway or something out there
that will route this for me?

	(Oh yes, I tried all permutations of .oz and .au that I could
	think of as well, still having my mailer tell me that they were
	unknown hosts.)

Thanks in advance, 
Richard DeJordy
Systems Programmer
American Mathematical Society
Post Office Box 6248
Providence, RI 02104
(401) 272-9500

RAD@MATH.AMS.COM on the Internet
-------

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 15:20:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 for VMS

This is in reply to Scrott Brim's query of 7 July.

A "native" version of tn3270, running over the WIN/TCP for VMS, is
operational and entering beta testing.  It should be generally available
shortly.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 16:07:07 GMT
From:      rbj@NAV.ICST.NBS.GOV (Root Boy Jim)
To:        comp.protocols.tcp-ip
Subject:   UUCP Over TCP/IP (why?)

? From: bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein)

? >Pardon my ignorance,  but I'm confused about running uucp over TCP links.
? >
? >My question is why?

? Very simple, to accomodate application layer software written for UUCP
? in the least invasive way without having to rewrite it all including,
? as you guessed, store and forward pieces that can travel over both
? TCP/UUCP links and vanilla UUCP/serial links without modification.

? The emphasis is on "without having to rewrite...", the approach works
? quite well, especially for the last few hops around a LAN after it
? arrives (often over a serial line) at the campus, or the first few
? hops going out, as the case may be.

I would have to agree with Barry here. The `news' system works with UUCP,
not with TCP/IP. I have been living with ARPANET mailing lists and am
restricted to a subset of the newsgroups, which may be a blessing.

? 	-Barry Shein, Boston University

	(Root Boy) Jim Cottrell	<rbj@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	The opinions expressed are solely my own
	and do not reflect NBS policy or agreement
	Careful with that VAX Eugene!

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 17:31:54 GMT
From:      westine@VENERA.ISI.EDU (Ann Westine)
To:        comp.protocols.tcp-ip
Subject:   ACSNET Access


>I have a user who is attempting to reach someone by electronic mail.  The 
>person in question is on ACSnet and we are on Arpanet.  The address 
>which we were given is   	user@MONCSBRUCE.OZ (ACSNET)
 
>I've tried various stategies to send mail to this host.  My mailer won't
>accept this as is.  After searching through variou header files, I eventually
>tried routing it through uu.net, but received no reply, so I assume it never
>got there.  Can anyone tell my is there is a gateway or something out there
>that will route this for me?

Richard,

ACSNET is an Australian Network. Try one of the following paths:

   munnari.oz.au!moncsbruce.ua.oz!username@SEISMO.CSS.GOV
   munnari.oz.au!moncsbruce.ua.oz!username@UUNET.UU.NET

Ann 

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 19:33:09 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

>> Date: Mon, 18 Jul 88 11:02:26 EDT
>> From: jas@proteon.com (John A. Shriver)
>> To: DCP@quabbin.scrc.symbolics.com
>> Cc: tcp-ip@sri-nic.arpa
>> Subject: a proposed modification to ARP
>> Status: O
>> 
>> ARP is one of the quintessentially elegant protocols.  An enormous
>> amount of power is provided for a very simple implmentation.  Let's
>> keep it that way.

Here here.  I also have a question.  If ARP was built to use
multicasts wouldn't that just replace one problem with another
one?  The hosts on the network would have to be properly configured
to use an appropriate multicast or group of multicasts.  How well
will this interoperate with other vendor's implementations?  Is
all this worth it?

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 19:35:20 GMT
From:      hks@santra.HUT.FI (Harri Salminen)
To:        comp.protocols.tcp-ip
Subject:   Re: Multi-protocol wide area networks

X.25 isn't the only alternative for multiprotocol large WANs.  Even
the X.25 equipment is expensive (not to mention public X.25) and
supports in most cases only 64Kbit/s host connections.  In addition
you'll need routers. I know though that DCA X.25 switches should have
TCP/IP router for ethernet. 

I've been much involved in planning a internordic (Denmark, Finland,
Iceland, Norway, Sweden) network to be called NORDUnet which will be
based on using extended Ethernet (ISO8802/3 if you like) as the
multiplexing WAN backbone (Translan bridges which have priority
queues, loops, filtering etc.) and connecting dedicated routers and X.25
switches (ISO CONS NS) to it. It gives the largest flexibility in
supported protocols and doesn't have low speed limits or "Virtual
Circosis". Supported protocols will include OSI CNLS and CONS (X.25
88), TCP/IP (everybody wants good SERVICE now), DECNET (we have quite
large ones being harmonized) and NJE (EARN/BITNET). Common lines to
rest of Europe and US are planned too. 

We're going to use Cisco routers that already (or very soon) support
Dod IP, DECNET, ISO CNLS NS (ISO IP) (maybe chaos and XNS) and should
be, at least soon, behaving like bridges for others.  Using just
Ciscos (or other multiprotocol routers like Proteon, WellFleet etc.)
might be enough for you since they probably can handle all protocols
you need. Cisco has also X.25 support for IP but I haven't found yet
anyone supporting ISO CONS (X.25 88) switch in the same box with all
the other protocols we need. Haven't seen a TP0/TP4 gateway either but
I hope somebody can design one. Our national network is currently a
LARGE (over 16 organizations) bridged ethernet but we are breaking it
up with these new multiprotocol router/bridges (brouters?). 

If you like to run CONS OSI (X.25 88) on ethernet many switch and
software vendors are developing it so you can soon choose to use CONS
or CNLS as you wish. In Europe it at least seems to be huge
"religious" battle instead of technical one, so we're trying to support
both (at least internationally). If you choose to use X.25 as backbone
and 64Kbit/s is enough today be prepared to buy multiple routers and
expensive switches. If you happen to like SNA (like the Germans) you can
even set up a X.25 network (and telephone network for that matter) over
SNA backbone with XI and SNI. It's up to your preferences but
I wouldn't like to maintain that SNA/XI/SNI network.

Aren't standards fun. You can use them as building blocks as you wish and
not just as the manual says but have to know what you're doing ;-)

In case somebody is interested in our network project a draft report is
available from my listserv by sending a command "GET NORDUNET XEARN"
(or INFO GENINTRO first) to LISTSERV@FINHUTC.HUT.FI (FINHUTC.BITNET).
It misses the pictures and some appendixes but you'll get the picture :-)
We've also a list called NDNNET-I where we might sometimes announce
about something, to which you can subscribe with the command "SUB
NDNNET-I Your Name". Contact me when everything fails or you have
specific questions or comments about the report or project.

Harri

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 88 20:14:33 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet SUPRESS-TELNET option...

In my PC implementation, the Telnet receive code first scans a receive
buffer for the IAC character using the memchr() C library routine. This
is a fast binary search routine implemented in assembler; it is
analogous to the strchr() (aka index) routine for ascii strings. If the
search fails, the entire buffer is written directly to the screen
driver. If the search succeeds, then the usual character-by-character
processing is done, and stdio output buffering keeps the number of
output driver calls to a reasonable minimum.

This buys a little, but not all that much since the PC's screen output
routine probably accounts for most of the CPU cycles anyway.

Phil

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 04:26:17 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   some interim notes on the bsd network speedups

I told the potential beta-tests for our new 4bsd network code
that I hoped to have a version of the code out by the end of
July.  (BTW, we've got all the beta testers we can handle --
please don't apply.)  It looks like that's going to turn into
the end of August, in part because of SIGCOMM and in part
because Sun puts sending source to academic customers on the
bottom of its priority list.  I thought I'd flame about the
latter and give a bit of a status report on the new code.

I've been trying to put together a beta distribution for the
"header prediction" bsd network code.  This effort has been
stymied because it's impossible to get current source from Sun.
The code involves major changes to the 4.3bsd kernel.  The only
local machines I can use to develop new kernels are Suns --
everything else is either multi-user or has pathetic ethernet
hardware.  But the only Sun kernel source I've got is the doubly
obsolete Sun OS 3.5/4.2 BSD.  It would be a massive waste of
time to upgrade this system to 4.3 BSD just so I can develop
the next BSD -- Bill Nowicki did the upgrade a year ago and
binaries of the new system (totally worthless to me) are
shipping as Sun OS 4.0.  [I'm not the only one suffering this
problem -- I understand Craig Partridge's multicast work is
suffering because he can't get 4.3-compatible Sun source.  I
think he gave up & decided to do all his development on 4.3bsd
Vaxen.  And I think I heard Chuck Hedrick say 4.0 has all the
rlogin, URG and nameserver bugs that we fondly remember fixing
in 3.x.  And he has to get source before the academic year
starts or they won't be able to switch until a semester break.
And Mike Karels is saying "I told you so" and suggesting I buy
some CCIs.  Pity that Sun can't figure out that it's in their
best interest to do TIMELY source distribution to the academic
and research community -- their software development base gets
expanded a few hundred-fold for the cost of making tapes.]

Anyway, now that I've vented my spleen, there are some interim
results to talk about.  While waiting for either useful source
or a better hardware platform to show up, I've been cleaning up
my original mods and backing out changes one and two at a time
to gauge their individual effect.  Because network performance
seems to rest on getting a lot of things happening in parallel,
this leave-one-out testing doesn't give simple good/bad answers
(I had one test case that went like

	Basic system:	600 KB/s
	add feature A:	520 KB/s
	drop A, add B:	530 KB/s
	add both A & B:	700 KB/s

Obviously, any statement of the form "feature A/B is good/bad"
is bogus.)  But, in spite of the ambiguity, some of the network
design folklore I've heard seems to be clearly wrong.

In the process of cleaning things up, they slowed down.  Task-
to-task data throughput using TCP between two Sun 3/60s dropped
from 1 MB/s (about 8.6 Mb/s on the wire) to 890 KB/s (about 7.6
Mb/s on the wire).  I know where the 11% was lost (an
interaction between "sosend" and the fact that an AMD LANCE chip
requires at least 100 bytes in the first chunk of data if you
ask it to chain -- massive braindamage on AMD's part) and how to
get it back (re-do the way user data gets handed to the
transport protocol) but need to talk with Mike Karels about the
"right" way to do this.

Still, 890 KB/s represents a non-trivial improvement over the
stock Sun/4bsd system:  Under identical test conditions (same
socket & user buffer sizes, same MSS and MTU, same machines),
the best tcp throughput I could get with an out-the-box Sun OS
3.5 was 380 KB/s.  I wish I could say "make these two simple
changes and your throughput will double" but I can't.  There
were lots and lots of fiddley little changes, none made a huge
difference and they all seemed to be necessary.

The biggest single effect was a change to sosend (the routine
between the user "write" syscall and tcp_output).  Its loop
looked something like:

    while there is user data & space in the socket buffer
	copy from user space to socket
    call the protocol "send" routine

After hooking a scope to our ethernet cable & looking at the
packet spacings, I changed this to

    while there is user data & space in the socket buffer
	copy up to 1K (one cluster's worth) from user space to socket
	call the protocol "send" routine

and the throughput jumped from 380 to 456 KB/s (+20%).  There's
one school of thought that says the first loop was better
because it minimized the "boundary crossings", the fixed costs
of routine calls and context changes.  This same school is
always lobbying for "bigger":  bigger packets, bigger windows,
bigger buffers, for essentially the same reason: the bigger
chunks are, the fewer boundary crossings you pay for.  The
correct school, mine :-), says there's always a fixed cost and a
variable cost (e.g., the cost of maintaining tcp state and
tacking a tcp packet header on the front of some data is
independent of the amount of data; the cost of filling in the
checksum field in that header scales linearly with the amount of
data).  If the size is large enough to make the fixed cost small
compared to the variable cost, making things bigger LOWERS
throughput because you throw away opportunities for parallelism.
Looking at the ethernet, I saw a burst of packets, a long dead
time, another burst of packets, ... .  It was clear that while
we were copying 4 KB from the user, the processor in the LANCE
chip and tcp_input on the destination machine were mostly
sitting idle.

To get good network performance, where there are guaranteed to
be many processors that could be doing things in parallel, you
want the "units of work" (loop sizes, packet sizes, etc.) to be
the SMALLEST values that amortise the fixed cost.  In Berkeley
Unix, the fixed costs of protocol processing are pretty low and
sizes of 1 - 2 KB on a 68020 are as large as you'd want to get.
(This is easy to determine.  Just do a throughput vs. size test
and look for the knee in the graph.  Best performance is just to
the right of the knee.)  And, obviously, on a faster machine
you'd probably want to do things in even smaller units (if the
overhead stays the same -- Crays are fast but hardware
strangeness drives the fixed costs way up.  Just remember that
if it takes large packets and large buffers to get good
performance on a fast machine, that's because it's broken, not
because it's fast.)

Another big effect (difficult to quantify because several
changes had to be made at once) was to remove lots of
more-or-less hidden data copies from the protocol processing.
It's a truism that you never copy data in network code.  Just
lay the data down in a buffer & pass around pointers to
appropriate places in that buffer.  But there are lots of places
where you need to get from a pointer into the buffer back to a
pointer to the buffer itself (e.g., you've got a pointer to the
packet's IP header, there's a header checksum error, and you
want to free the buffer holding the packet).  The routine "dtom"
converts a data pointer back to a buffer pointer but it only
works for small things that fit in a single mbuf (the basic
storage allocation unit in the bsd network code).  Incoming
packets are never in an mbuf; they're in a "cluster" which the
mbuf points to.  There's no way to go from a pointer into a
cluster to a pointer to the mbuf.  So, anywhere you might need
to do a dtom (anywhere there's a detectable error), there had to
be a call to "m_pullup" to make sure the dtom would work.
(M_pullup works by allocating a fresh mbuf, copying a bunch of
data from the cluster to this mbuf, then chaining the original
cluster behind the new mbuf.)

So, we were doing a bunch of copying to expedite error handling.
But errors usually don't happen (if you're worried about
performance, first you make sure there are very, very few
errors), so we were doing a bunch of copying for nothing.  But,
if you're sufficiently insomniac, in about a week you can track
down all the pullup's associated with all the dtom's and change
things to avoid both.  This requires massive recoding of both
the TCP and IP re-assembly code.  But it was worth it:  TCP
throughput climbed from around 600 KB/s to 750 KB/s and IP
forwarding just screamed:  A 3/60 forwarding packets at the 9
Mb/s effective ethernet bandwidth used less than 50% of the CPU.

[BTW, in general I didn't find anything wrong with the BSD
mbuf/cluster model.  In fact, I tried some other models (e.g.,
do everything in packet sized chunks) and they were slower.
There are many cases where knowing that you can grab an mbuf and
chain it onto a chunk of data really simplifies the protocol
code (simplicity == speed).  And the level of indirection and
fast, reference counted allocation of clusters can really be a
win on data transfers (a la kudp_fastsend in Sun OS).  The
biggest problem I saw, other than the m_pullup's, was that
clusters are too small:  They need to be at least big enough for
an ethernet packet (2K) and making them page sized (8K on a Sun)
doesn't hurt and would let you do some quick page swap tricks in
the user-system data copies (I didn't do any of these tricks in
the fast TCP.  I did use 2KB clusters to optimize things for the
ethernet drivers).]

An interesting result of the m_pullup removals was the death of
another piece of folklore.  I'd always heard that the limiting
CPU was the receiver.  Wrong.  After the pullup changes, the
sender would be maxed out at 100% CPU utilization while the
receiver loafed along at 65-70% utilization (utilizations
measured with a microprocessor analyzer; I don't trust the
system's stats).  In hindsight, this seems reasonable.  At the
receiver, a packet comes in, wanders up to the tcp layer, gets
stuck in the socket buffer and an ack is generated (i.e., the
processing terminates with tcp_input at the socket buffer).  At
the sender, the ack comes in, wanders up to the tcp layer, frees
some space, then the higher level socket process has to be woken
up to fill that space (i.e., the processing terminates with
sosend, at the user socket layer).  The way Unix works, this
forces a boundary crossing between the bottom half (interrupt
service) and top half (process context) of the kernel.  On a
Sun, and most of the other Unix boxes I know of, this is an
expensive crossing.  [Of course, the user process on the
receiver side has to eventually wake up and empty the socket
buffer but it gets to do that asynchronously and the dynamics
tend to arrange themselves so it processes several packets on
each wakeup, minimizing the boundary crossings.]

Talking about the bottom half of the kernel reminds me of
another major effect.  There seemed to be a "sound barrier" at
550 KB/s.  No matter what I did, the performance stuck at 550
KB/s.  Finally, I noticed that Sun's LANCE ethernet driver,
if_le.c, would only queue one packet to the LANCE at a time.
Picture what this means:  (1) driver hands packet to LANCE, (2)
LANCE puts packet on wire, (3) end of packet, LANCE interrupts
processor, (4) interrupt dispatched to driver, (5) go back to
(1).  The time involved in (4) is non-trivial, more than 150us,
and represents a lot of idle time for the LANCE and the wire.
So, I rewrote the driver to queue an arbitrary number of packets
to the LANCE, the sound barrier disappeared, and other changes
started making the throughput climb (it's not clear whether this
change had any effect on throughput or just allowed other
changes to have an effect).

[Shortly after making the if_le change, I learned why Sun might
have written the driver the silly way they did:  Before the
change, the 6 back-to-back IP fragments of an NFS write would
each be separated by the 150us interrupt service time.  After
the change, they were really back-to-back, separated by only the
9.6us minimum ethernet spacing (and, no, Sun does NOT violate
the ethernet spec in any way, shape or form.  After my last
message on this stuff, Apollo & DEC people kept telling me Sun
was out of spec.  I've been watching packets on our ethernet for
so long, I'm starting to learn the middle name of every bit.
Sun bits look like DEC bits and Sun, or rather, the LANCE in the
3/50 & 3/60, completely complys with the timings in the blue
book.)  Anyway, the brain-dead Intel 82586 ethernet chip Sun
puts in all its 3/180, 3/280 and Sun-4 file servers can't hack
back-to-back, minimum spacing packets.  Every now and again it
drops some of the frags and wanders off to never-never land
("iebark reset").  Diskless workstations don't work well when
they can't write to their file server and, until I hit on the
idea of inserting "DELAY" macros in kudp_fastsend, it looked
like I could have a fast TCP or a functional workstation but not
both.]

Probably 30% of the performance improvements came from fixing
things in the Sun kernel.  I mean like, really, guys:  If the
current task doesn't change, and it doesn't 80% of the time
swtch is called, there's no need to do a full context save and
restore.  Adding the two lines

	cmpl    _masterprocp,a0
	jeq     6f              | restore of current proc is easy

just before the call to "resume" in sun3/vax.s:swtch got me a
quick 70 KB/s performance increase but felt more like a bug fix
than progress.  And a kernel hacker that does 16-bit "movw"s and
"addw"s on a 68020, or writes 2 instruction dbra loops designed
to put a 68010 in loop mode, should be shot.  The alu takes the
same 3 clocks for a 2 byte add or a 4 byte add so things will
finish a lot quicker if you give it 4 bytes at a time.  And
every branch stalls the pipe, so unrolling that loop to cut down
on branches is a BIG win.

Anyway, I recoded the checksum routine, ocsum.s (now oc_cksum.s
because I found the old calling sequence wasn't the best way to
do things) and its caller, in_cksum.c, and got the checksumming
time down from 490us/KB to 130us/KB.  Unrolling the move loop in
copyin/copyout (the routines that move data user to kernel and
kernel to user), got them down from 200us/KB to 140us/KB.  (BTW,
if you combine the move with the checksum, which I did in the
kludged up, fast code that ran 1 MB/s on a 15MHz 3/50, it costs
200us/KB, not the 300us/KB you'd expect from adding the move
and sum times.  Pipelined processors are strange and wonderful
beasts.)

From these times, you can work out most of the budgets and
processing details:  I was using 1408 data byte packets (don't
ask why 1408).  It takes 193us to copy a packet's worth of data
and 184us to checksum the packet and its 40 byte header.  From
the logic analyzer, the LANCE uses 300us of bus and memory
bandwidth reading or writing the packet (I don't understand why,
it should only take half this).   So, the variable costs are
around 700us per packet.  When you add the 18 byte ethernet
header and 12 byte interpacket gap, to run at 10 Mb/s I'd have
to supply a new packet every 1200us.  I.e., there's a budget of
500us for all the fixed costs (protocol processing, interrupt
dispatch, device setup, etc.).  This is do-able (I've done it,
but not very cleanly) but what I'm getting today is a packet
every 1500us.  I.e., 800us per packet fixed costs.  When I look
with our analyzer, 30% of this is TCP, IP, ARP and ethernet
protocol processing (this was 45% before the "header prediction"
tcp mods), 15% is stalls (idle time that I don't currently
understand but should be able to eventually get rid of) and 55%
is device setup, interrupt service and task handling.  I.e.,
protocol processing is negligible (240us per packet on this
processor and this isn't a fast processor in today's terms).  To
make the network go faster, it seems we just need to fix the
operating system parts we've always needed to fix:  I/O service,
interrupts, task switching and scheduling.  Gee, what a surprise.

 - Van

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 06:38:02 GMT
From:      percy@amdcad.AMD.COM (Percy Irani)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 and Ultrix 2.2


Gee, and I thought only we were having problems with Ultrix 2.2.
Yes, TN3270 works fine from bsd4.x, Sun's, and *even* Apollo's!!!
Yet with Ultrix 2.x, it has a problem!!! I sincerely hope someone
in DEC looks into it!!

After all DEC says - "DIGITAL has it now" (what??)

-- 
Ignorance is bliss but can be embarassing at times!

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jul 88 15:36:16 PDT
From:      cire@clash.cisco.com
To:        doug@icase.arpa (Doug Peterson)
Cc:        sun-spots@rice.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Sun OS
>> Date: Wed, 20 Jul 88 08:59:30 EDT
>> From: doug@icase.arpa (Doug Peterson)
>> To: sun-spots@rice.edu, tcp-ip@sri-nic.arpa
>> Subject: Sun OS
>> 
>> It strikes me that the time is near for such individuals to converge
>> and produce the Berkeley equivalent of an OS for a distributed
>> computing system such as a collection of diskless Sun workstations
>> connected to a file server, which is in turn a gateway to another network.
>> It seems that such a group could incorporate all the improvements which
>> have been learned about both in networking and client/server situations,
>> and produce a more performance oriented operating system, and make it
>> available to the academic/research community.
>> 
>> Too often (I think), I've seen postings to this list complaining of a
>> Sun OS (problem/feature/bug), with a response from Sun to the effect that
>> it's not an issue (ehternet connectors? name resolver?). I'm beginning
>> to sense a slight overtone of '...If our system doesn't do what it's
>> supposed to for you, well...'
>> 

This is exactly one of the reasons that Stallman is doing GNU.

-c
cire|eric
Eric B. Decker
cire@clash.cisco.com

*** This are my opinions and they are not for sale.  They are ***
***   not the opinions official or otherwise of my employer   ***
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 16:31:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Supress-Telnet Option Discussion
No doubt, I am missing something quite basic in the discussion about
the Suppress-Telnet option.  Would someone please describe to me why it
would not be better -- and vastly simpler -- simply to have a straight
TCP connection to the remote host's pseudo-terminal driver?  I.e., bypass
the telnet protocol engine entirely.

Dave

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 09:41:16 GMT
From:      he@idt.unit.no (Haavard Eidnes IDT)
To:        comp.protocols.tcp-ip
Subject:   UUCP Over TCP/IP (why?)

Jim Cotrell on TCP-IP Jul 20th:

> I would have to agree with Barry here. The `news' system works with UUCP,
> not with TCP/IP. 

I thought that NNTP (NetNews Transport Protocol, created at Berkeley),
was exactly `news' over TCP/IP. (Or is NNTP only applicable in a
situation where you have common administration of the machines
involved?) You have to re-install more software than if you just
introduced TCP/IP at the UUCP level, though.

Haavard Eidnes, Division of Computer Systems and Telematics
		Norwegian Institute of Technology

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 12:59:30 GMT
From:      doug@ICASE.ARPA (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   Sun OS

I've seen a lot of negative comments about Sun's unwillingness to
port (incorporate) 4.3BSD networking capabilities into their operating
system. Those that are incorporated seem to also include the 4.2/3 bugs.
These unhappy people are also the mainstay of the network knowledge base
in the community.

It strikes me that the time is near for such individuals to converge
and produce the Berkeley equivalent of an OS for a distributed
computing system such as a collection of diskless Sun workstations
connected to a file server, which is in turn a gateway to another network.
It seems that such a group could incorporate all the improvements which
have been learned about both in networking and client/server situations,
and produce a more performance oriented operating system, and make it
available to the academic/research community.

Too often (I think), I've seen postings to this list complaining of a
Sun OS (problem/feature/bug), with a response from Sun to the effect that
it's not an issue (ehternet connectors? name resolver?). I'm beginning
to sense a slight overtone of '...If our system doesn't do what it's
supposed to for you, well...'

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090
 

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 14:15:41 GMT
From:      gc@EWOK.AMD.BNL.GOV (Graham Campbell)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet SUPRESS-TELNET option...


	From: thumper!karn@faline.bellcore.com  (Phil R. Karn)
	Organization: Bell Communications Research, Inc
	Subject: Re: telnet SUPRESS-TELNET option...
	To: tcp-ip@sri-nic.arpa
	
	In my PC implementation, the Telnet receive code first scans a receive
	buffer for the IAC character using the memchr() C library routine. This
	is a fast binary search routine implemented in assembler; it is
	          ^^^^^^^^^^^^^
Nooo, binary search works on ordered lists, you don't sort the buffer first
do you? :-)
	analogous to the strchr() (aka index) routine for ascii strings. 
	 ...............
Graham

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 16:16:42 GMT
From:      karn@THUMPER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet SUPRESS-TELNET option...

Sorry, my wording was misleading. I meant to say that memchr() is a
linear search function that operates on arbitrary binary data, as
opposed to strchr() or index() which operates only on C style ascii
character strings.

Phil

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 88 00:01 PDT
From:      Leonard D Woren <LDW@MVSA.USC.EDU>
To:        Tcp-Ip@SRI-NIC.ARPA
Subject:   New List -- TCP/IP for MVS
A new mailing list has been created for discussion of MVS TCP/IP
implementations.  It is NOT intended for bits-and-bytes discussions as
take place on this list.  It is a LISTSERV-based list, so subscriptions
may be entered by sending a message to LISTSERV@USCVM.BITNET (or
LISTSERV@VM.USC.EDU) with a one line message body of
   SUBscribe MVSTCPIP Your Name
VM.USC.EDU is not in HOSTS.TXT, so flatlanders will have to use an
Interbit gateway.  If you are not on Bitnet and subscribe to this
list, be sure that your return address is reachable through Interbit.
Problems accessing the list may be addressed to me at either address
below.

Please repost this message anywhere that might be useful.  Similar
messages will be posted to some Bitnet lists, like IBMTCP-L.

Leonard D. Woren <LDW@USCMVSA.BITNET>
<LDW%MVSA.USC.EDU@Oberon.USC.EDU>
University of Southern California

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 18:24:00 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Arpanet congestion?

This is for the "IthoughtIhadSeenEverything" department.

There is a serial link of MIT which provides internet access for host
807f1964 to the Internet.  In order to ftp files from this host to a
host off the MILNET, a user using SunOS 4.0 must start a periodic ICMP
ECHO to 807f1964 in parallel with the ftp 'get'. 

The question I have is, "What is the peer hardware/software configuration of
the serial link?"   I want to make sure that the Laboratory does not procure
same.

Phil Wood  cpw@lanl.gov

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 18:26:16 GMT
From:      iain@marlow.uucp (Iain Devine)
To:        comp.protocols.tcp-ip
Subject:   IDEA's

I am looking for a way of getting IDEA's 11 and 12
can anyone suggest a source (via ftp/email ) in the U.K
Thanks
Iain

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 20:44:35 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: some interim notes on the bsd network speedups

>....  And I think I heard Chuck Hedrick say [Sun] 4.0 has all the
>rlogin, URG and nameserver bugs that we fondly remember fixing
>in 3.x.  And he has to get source before the academic year
>starts or they won't be able to switch until a semester break.

It's not enough to get the source before Sept 1.  I need to get it
soon enough that I can fix all the problems and get through an
internal release cycle before Sept. 1.  That time has now been passed.
We are committed to 3.2 on our student machines until January 89.  We
are backing out of 4.0 on some of our student test machines, and
praying that we get source soon enough that we don't have to back out
of the rest.  We have 3/60's that require software more recent that
our standard 3.2, but without source we can't bring up 4.0.  So we are
now having to put together a release based on 3.2 with pieces of 3.5
added, all because we can't get the source at the same time as the
binary.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 23:31:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Supress-Telnet Option Discussion

No doubt, I am missing something quite basic in the discussion about
the Suppress-Telnet option.  Would someone please describe to me why it
would not be better -- and vastly simpler -- simply to have a straight
TCP connection to the remote host's pseudo-terminal driver?  I.e., bypass
the telnet protocol engine entirely.

Dave

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 88 23:45:32 GMT
From:      valdis@sun.mcs.clarkson.EDU
To:        comp.protocols.tcp-ip
Subject:   ISODE 4.0

Ahh.. I'd comment more on this package, except it isn't FTP'able from
spam.istc.sri.com as the announcement letter stated.  Is this a problem
getting a stable connection or just an oversight?

				Valdis Kletnieks
				Sr. Systems Programmer
				Clarkson University

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 05:57:45 GMT
From:      guy@gorodish.Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

> As far as an address being something that a user can be "prompted
> for"  any user who wants to talk to machine 'X' had better know
> the "address" of machine X, or some alias which will relate.
> If the user has to type "AA093749823FEBCC836628973DA31.22" or
> "Go\nFind\nThe\nMachine\nThat\nHas\nService\nX" to
> get there, they can type this at their console, they can not,
> however, type in the spesification of a 45 byte structure and
> media spesific addressing scheme... As far as passing this
> "legible"

The "legible" deserves to be in quotes here; no way is something such as
"AA093749823FEBCC836628973DA31.22" usable.  Sorry, if *I* want to send mail, I
send it to "jblow@blow.com", not "jblow@AA093749823FEBCC836628973DA31.22".

As for "media-specific addressing schemes", I assume that by "media" you mean
"transport protocols" as opposed to "physical networks"; typically, the
network-layer protocol will isolate you from having to deal with link-layer
addressing.  My machine's Internet address is "192.9.90.60" (a 4-byte string,
with the four numbers there being the values of the four bytes), regardless of
whether you're talking to it over a local Ethernet, a Sun Internetwork Router
connection, a SLIP connection, or two tin cans and a string.

> address to the TLI provider, this is _exactly_ what
> takes place; If the dirver has to translate this to get the
> afor mentioned structure, fill a 50 byte real number, or go out
> and get name service, that is what it does, no questions asked.

Wrong.  The TCP and IP drivers in the STREAMS/TLI TCP/IP implementations I know
of do *NOT* "goes out and get (the) name service", nor do they "translate" an
ASCII string into a byte string.  The code that *calls* TLI has to convert that
hexadecimal monstrosity to a string of bytes, with the first byte having e.g.
the hex value 0xAA, and stuff that down into the transport layer.

> Hence teh value of the aledged uniformity.

"Alleged" is the correct word here.  There's no uniform way of doing this
ASCII string to address translation in S5R3 as it is distributed.  In fact, I
don't think there's any way to do that translation in S5R3 as it's distributed,
period.

> The idea is (according to the manuals) to have a layer which
> accepts a single string/sequential structure from above
> and does to it what is necessary to the media/protocol below.
> Either the TLI layer is made sufficiently intellegent to take
> the input as a string, or the whole point of a uniform
> interface goes right out the window.

OK, then, the whole point of a uniform interface just went out the window.  TLI
does not take the input as a string in the TCP/IP implementations I know of.
What it takes is a *byte* string, containing the address in what is likely to
be a *binary* form (I had the impression that Datakit took human-readable
strings; could this be the source of some of the confusion?).

> To whit: (from definition of M_PROTO message T_INFO_ACK of the
> 	TLI internals definition from the "porting rules" doccument)
> 
> ADDR_size	(a return value of) -2 spesifies that the transport
> 		provider  does not provide  user access to transport
> 		spesific addresses.
> 
> T_ERROR_ACK  Return coed TBADADDR:
> 	Indicates that _protocol_ address was in incorrect format
> 	or the address contained incorrect illegal information...
> 
> These two imply (wrongly?) that the TLI is for insulation from the
> uglies, instead of the "this is just another library" outlook.

No, you are *inferring* wrongly that the TLI insulates you from the uglies.  An
address can be in "incorrect format" without that "format" having to be some
human-readable format.  The address is in the form of a count and a byte
string, with the count specifying how many bytes are in the string.  If you
pass a 1-byte address to TCP or UDP, it should reject it as being in an
incorrect format because TCP and UDP addresses are 6 bytes long (4 bytes of IP
address, 2 bytes of port number).

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 07:01:00 GMT
From:      LDW@MVSA.USC.EDU (Leonard D Woren)
To:        comp.protocols.tcp-ip
Subject:   New List -- TCP/IP for MVS

A new mailing list has been created for discussion of MVS TCP/IP
implementations.  It is NOT intended for bits-and-bytes discussions as
take place on this list.  It is a LISTSERV-based list, so subscriptions
may be entered by sending a message to LISTSERV@USCVM.BITNET (or
LISTSERV@VM.USC.EDU) with a one line message body of
   SUBscribe MVSTCPIP Your Name
VM.USC.EDU is not in HOSTS.TXT, so flatlanders will have to use an
Interbit gateway.  If you are not on Bitnet and subscribe to this
list, be sure that your return address is reachable through Interbit.
Problems accessing the list may be addressed to me at either address
below.

Please repost this message anywhere that might be useful.  Similar
messages will be posted to some Bitnet lists, like IBMTCP-L.

Leonard D. Woren <LDW@USCMVSA.BITNET>
<LDW%MVSA.USC.EDU@Oberon.USC.EDU>
University of Southern California

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 88 13:54 EST
From:      "Mark D. Eggers"                            <CF4A8X%IRISHMVS.BITNET@CUNYVM.CUNY.EDU>
To:        t235301@dm0lrz01
Cc:        tcp-ip@sri-nic.arpa
Subject:   tn3270 and Ultrix 2.2
Well, I think that I have everything working now - thanks to
the help from the net.

Things to do:

In the DEFINES line of the makefile_4.2, put at least the
following.

-DNOT43 -DPUTCHAR -DSO_OOBINLINE

Change LIBCURSES to read
../curses/vax/libcurses.a

Change all occurences of <curses.h> to "....../curses.h",
where ....../ is the path to curses.h that comes with the
distribution.

There are two files (I think) with <curses.h> in them -

telnet.c       (change to ../curses/curses.h)

sys_curses/termout.c     (change to ../../curses/curses.h)

Please note that I am using version 3 (beta) obtained from
ucbarpa.berkeley.edu, and am basing my path descriptions on
the result of untarring that distribution.

As far as I can tell, everything seems to work properly,
without changes to the original curses.h or the termcap
file.

Thanks for all the assistance.

/mde/

PS - I haven't tried graphics yet . . . . .
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 11:51:40 GMT
From:      kre@munnari.oz (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: ACSNET Access

In article <8807191731.AA07235@venera.isi.edu>, westine@VENERA.ISI.EDU (Ann Westine) writes:
> ACSNET is an Australian Network. Try one of the following paths:
> 
>    munnari.oz.au!moncsbruce.ua.oz!username@SEISMO.CSS.GOV
>    munnari.oz.au!moncsbruce.ua.oz!username@UUNET.UU.NET


Please don't... First, seismo no longer implements a gateway to anywhere,
and should no longer be used by anyone not communicating with a user at
the CSS.

Second, "moncsbruce.ua.oz" would place "moncsbruce" in the University
of Adelaide, which it isn't, just "moncsbruce.oz", or "moncsbruce.monash.oz"
works fine.

Third, while that revolting mixture of !'s and @'s is actually what a
return address looks like when Australian mail is seen on the internet,
I would never recommend it to anyone.

If you have a mailer that doesn't handle nameserver MX records, then you
should use

	username%moncsbruce.oz.au@uunet.uu.net

in the period while you are waiting for your mailer upgrade.

Then, just use

	username@moncsbruce.oz.au

Robert Elz				postmaster@munnari.oz.au

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 16:11:05 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Our Serial Link

807f1964 is a Microvax running Ultrix 2.0, with SLIP added.  The modems are
v.32, 9.6Kb.  The other end of the link is on MIT's subnet 10 (ProNet-10),
and is a Microvax running the MIT "C-gateway code".  Both ends of the link
use DHV-11s.  The Ultrix TCP (unmodified) has occasionally shown a willingness
to fill the SLIP transmit queue with retransmissions, but I have never heard
any other reports of your symptoms.

If you want to tinker, give me a call, and we can see how it works fetching
files from a PC on the LAN that the Ultrix Microvax serves as a gateway for.
I can also run LANWatch, and see exactly what is going on at the packet level.

James VanBokkelen
FTP Software Inc.

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 18:19:39 GMT
From:      steve@umiacs.UMD.EDU (Steven D. Miller)
To:        comp.protocols.tcp-ip
Subject:   3.2 on the 3/60


   I just passed this along to Charles Hedrick, and I'll pass it along to
any others that might think the information useful:  I've ported SunOS 3.2
to the 3/60.  (Hedrick's rule used to be "a 3/60 is a 3/160"; my rule is "a
3/60 is a 3/160, except for the onboard SCSI, where it's a 3/50, and the
hi-res monochrome, where it's a 3/260, and the cgfour, where it's like
nothing else in 3.2.)  I have the ported version running on color, hi-res,
and normal mono 3/60s with local disk, though I think it will work on other
3/60 variants, and it should work fine on other hardware supported in SunOS
3.2.

   I have instructions for those who might wish them.  If you don't have
sources, though, my instructions won't help you a bit.  (Sorry.)  I know
that my 3.2, for which I have sources and to which I've added almost-
reasonable subnet support, works better on a subnetted network than what
comes right off the tape...  and Sun didn't tell us that we needed a System
V Release 3.0 license to get SunOS 3.4 or later sources until many months
after we'd placed our order.

	-Steve

Spoken: Steve Miller    Domain: steve@mimsy.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 18:54:00 GMT
From:      CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers")
To:        comp.protocols.tcp-ip
Subject:   tn3270 and Ultrix 2.2

Well, I think that I have everything working now - thanks to
the help from the net.

Things to do:

In the DEFINES line of the makefile_4.2, put at least the
following.

-DNOT43 -DPUTCHAR -DSO_OOBINLINE

Change LIBCURSES to read
../curses/vax/libcurses.a

Change all occurences of <curses.h> to "....../curses.h",
where ....../ is the path to curses.h that comes with the
distribution.

There are two files (I think) with <curses.h> in them -

telnet.c       (change to ../curses/curses.h)

sys_curses/termout.c     (change to ../../curses/curses.h)

Please note that I am using version 3 (beta) obtained from
ucbarpa.berkeley.edu, and am basing my path descriptions on
the result of untarring that distribution.

As far as I can tell, everything seems to work properly,
without changes to the original curses.h or the termcap
file.

Thanks for all the assistance.

/mde/

PS - I haven't tried graphics yet . . . . .

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 20:19:04 GMT
From:      ian@spider.UUCP
To:        comp.protocols.tcp-ip
Subject:   default broadcast address

I'm surprised to hear that RFC 922 isnt generally supported (I implemented
it for our routers).  RFC 1009 certainly pushes it, it's straightforward to 
implement, and without it you can't handle network broadcasts over subnets.  

I can see an issue with network broacasting from an embedded gateway or
multihomed host with two (or more) interfaces onto subnets of the same
network, viz. what IP source address do you use for the multiple
outgoing datagrams?

If a network broadcast is transmitted on an unbound socket, do you use the 
local IP address for each interface?  In this case you get different datagrams 
transmitted on each interface.  A consequence of the suboptimality of reverse 
path forwarding is that hosts on some subnets will receive one datagram 
(with varying IP source address) and hosts on others may receive two datagrams 
with different IP source addresses.  The number of datagrams and source
address of the datagrams received by a particular host may change as the 
routing tables change.  Multihomed hosts suffer from identity crises,
I suppose.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 20:32:43 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   European Language Standardization

This came across the wire today. For some strange reason, it reminds
me just a bit of the international protocol standards game. --Phil


Official Opposes Single European Language
           PARIS (AP) _ A Cabinet minister said Thursday that European
integration should not be taken as far as developing a single
European language _ because she said the language inevitably would
be English.
           Minister for European Affairs Edith Cresson said Europeans
should work together to defend French as well as Italian, German
and other languages ``because language is also culture and we must
be able to talk to each other.''
           Interviewed on RTL radio, the minister said plans to eliminate
the borders among the 12 European Economic Community countries
should not apply to language.
           ``There should not be a single language in Europe, because it
would inevitably be English,'' she said.
           ``Children in the Netherlands or Denmark all speak a foreign
language and sometimes two,'' she said. ``There is no reason why
our children, if we start them young learning languages in an
attractive and lively way, could not do it.''

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 88 20:48:15 GMT
From:      tcplog@CHAKRA.CS.UMD.EDU (The TCP Logger)
To:        comp.protocols.tcp-ip
Subject:   Instrumenting a TCP Implementation

Hi,

We, at the Department of Computer Science, University of Maryland, have
done an instrumentation of TCP/IP. Here is the abstract from the
Technical Report describing our work:

"We describe an instrumentation of TCP/IP that monitors different aspects of
a TCP connection, provides information about its performance, and displays
relationships between a variety of variables that reflect the state of the
connection.  We define interface events for a TCP/IP connection, describe
how traces are obtained, how application processes initiate trace
collection, and how performance parameters are computed from these traces.
Data presentation tools are provided to generate different types of graphs.
The instrumentation has been done on a SUN 3/50 running UNIX (SUN OS 3.0
with 4.3BSD networking code)."

Interested persons can get a copy of the Report by sending mail to
	tcplog@chakra.cs.umd.edu 

or to any of the following:
	dheeraj@tove.umd.edu
	subbu@tove.umd.edu
	shankar@mimsy.umd.edu

Please quote the following numbers in your request:

CS-TR 2063 and UMIACS-TR 88-50

-Dheeraj Sanghi
Systems Design and Analysis Group,
Department of Computer Science
University of Maryland, College Park.

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 00:36:25 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

in article <60781@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) says:
> Xref: nusdhub comp.dcom.lans:361 comp.protocols.tcp-ip:1113 comp.protocols.iso:47
> 
> "Alleged" is the correct word here.  There's no uniform way of doing this
> ASCII string to address translation in S5R3 as it is distributed.  In fact, I
> don't think there's any way to do that translation in S5R3 as it's distributed,
> period.

Here is a "for instance" where you are wrong.

ALL starlan addressing uses the 802.3 six-byte couplet for addressing
purposes.  Further RFS gets "name service" for all the available
resources, but not the machine names.  When any TLI conformant
application requests, including RFS, want to make a connection
they pass a "name"  e.g. "nusdhub.serve" to the TLI interface.
somewhare below this, the TLI and or STARLAN driver groups fardle
around and recover the machine address (802.3) and then establishes
the connection.

Even though the (admittedly three layers) receives the "name string"
the addressing used after the address determination phase is the
byte string.  At no point does the "uucp" "cu" or RFS task enquire
about the six byte string.

The fact that all you have ever seen of TCP/IP drivers written as
TLI conformant functions pass the four byte addresses as actual
bytes instead of a string like "109.90.42.6" is simply sad.  In
essence this breaks the aledged uniformity.  To implement the
TCP/IP and TLI over the same media, the primitive kernel driver
should be TCP/IP, and then a streams module which can convert
TLI requests into TCP/IP should be written.  TCP/IP _is more_
complex, and therefore, to implement both TLI should be an
optional addition onto the TCP/IP.  Then you place 109.90.42.6
in your Systems file;  you spesify the TLI<->TCP/IP converter
module as the first-push-in-the-list;  and you spesify the cloning
module for TCP/IP as the device.  Bam, you are TLI conformant.
The simple task of converting the string to the 4-byte couplet
is not beyond the scope of a STREAMS module, and you have full
function from bot modules.

Similarly, you might write the drivers as two seperate tasks, and
assemble a multiplexing stream on media initalization where both
drivers drive the down-stream media as necessary, but respond
to TLI or TCP/IP as necessary when working upstream.  This _is_
what streams modules are for you know.

To do TCP/IP _over_ TLI is simply stupid.

>> The idea is (according to the manuals) to have a layer which
>> accepts a single string/sequential structure from above
>> and does to it what is necessary to the media/protocol below.
>> Either the TLI layer is made sufficiently intellegent to take
>> the input as a string, or the whole point of a uniform
>> interface goes right out the window.
> 
> OK, then, the whole point of a uniform interface just went out the window.  TLI
> does not take the input as a string in the TCP/IP implementations I know of.
> What it takes is a *byte* string, containing the address in what is likely to
> be a *binary* form (I had the impression that Datakit took human-readable
> strings; could this be the source of some of the confusion?).

As I said, doing TCP/IP _over_ TLI is stupid.  They are *comprable*
in form and purpose, and TLI _is_ designed to be more "elementary"
than TCP/IP.  Trying to squese TCP/IP through TLI is like hooking
100amp wire to a 15amp breaker;  It is _NOT_ the way these things
are supposed to be done.

>> To whit: (from definition of M_PROTO message T_INFO_ACK of the
>> 	TLI internals definition from the "porting rules" doccument)
>> 
>> ADDR_size	(a return value of) -2 spesifies that the transport
>> 		provider  does not provide  user access to transport
>> 		spesific addresses.
>> 
>> T_ERROR_ACK  Return coed TBADADDR:
>> 	Indicates that _protocol_ address was in incorrect format
>> 	or the address contained incorrect illegal information...
>> 
>> These two imply (wrongly?) that the TLI is for insulation from the
>> uglies, instead of the "this is just another library" outlook.
> 
> No, you are *inferring* wrongly that the TLI insulates you from the uglies.  An
> address can be in "incorrect format" without that "format" having to be some
> human-readable format.  The address is in the form of a count and a byte
> string, with the count specifying how many bytes are in the string.  If you
> pass a 1-byte address to TCP or UDP, it should reject it as being in an
> incorrect format because TCP and UDP addresses are 6 bytes long (4 bytes of IP
> address, 2 bytes of port number).

The *purpose* of TLI _is_ to insulate you form the uglies;  That is
why things like uucp and cu have been re-written to be TLI conformant;
so simple ASCII strings may be spesified in the ASCII files (Systems,
Dialers, Dialcodes, Devices... remember them?) and allow these versions
of uucp and cu to be used with any media (please no more corrections on
my use of 'media,' this is the broad and general usage menaing 'whatever-
is-necessary-below-this-point')  Depending on what is required, you might
need to set an address like "109.94.60.2:rlogin" to properly implement
TLI through TCP/IP, or perhaps place something similar in the Dialers
spec, but I don't really know because I have not expended any energy on
the topic outside this conversation.

All of this is much the purpose of the "adm" program which assembles
the STREAMS modules which eventually make /dev/starlan operate
the STARLAN product.  I would assume the correct "adm" program
for an ethernet and/or internet support would activate two STREAMS
multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.

Rob.

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 1988 06:23-EDT
From:      CERF@A.ISI.EDU
To:        goldstei@MITRE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Los Alamos' High Speed Channel--Info anybody?
The IAB got a full briefing on the LANL work by Don Tolmie. They have
developed a hrdware standard for linking computers with 800 Mb/s
cross-bar switches. The standard is the interface between the
computer and the switch and is going through ANSI standardization.

The design uses multi-port RAMS. Do you have Tolmie's address/phone
at LANL? It is worth calling him.

Vint
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 06:14:44 GMT
From:      dave@stcns3.stc.oz (Dave Horsfall)
To:        comp.protocols.tcp-ip
Subject:   Re: ACSNET Access

In article <8807191731.AA07235@venera.isi.edu> westine@VENERA.ISI.EDU (Ann Westine) writes:
>
>>I have a user who is attempting to reach someone by electronic mail.  The 
>>person in question is on ACSnet and we are on Arpanet.  The address 
>>which we were given is   	user@MONCSBRUCE.OZ (ACSNET)
>
>
>Richard,
>
>ACSNET is an Australian Network. Try one of the following paths:
>
>   munnari.oz.au!moncsbruce.ua.oz!username@SEISMO.CSS.GOV
>   munnari.oz.au!moncsbruce.ua.oz!username@UUNET.UU.NET
>
>Ann 

Close, but not close enough.  SEISMO stopped working ages ago, and that "ua"
(au mispelt?) could send it via the University of Adelaide...

Try one of the following, depending on whether you bang or domain (capitals
not necessary):

user%moncsbruce.OZ.AU@uunet.UU.NET, ...munnari!moncsbruce.OZ.AU!user

A fairly recent issue of CACM ("Notable Computer Networks") had an article
on it, but I think it still mentioned SEISMO.

Now, watch me get flamed by the local ACSnet "experts" ...

-- 
Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz
dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave
	WordStar 4 - The thinking person's word processor

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 07:11:29 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Token ring IP encapsulation


802.2 IP encapsulation on 802.3, 4, and 5 are covered in RFC1042.

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 10:23:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Los Alamos' High Speed Channel--Info anybody?

The IAB got a full briefing on the LANL work by Don Tolmie. They have
developed a hrdware standard for linking computers with 800 Mb/s
cross-bar switches. The standard is the interface between the
computer and the switch and is going through ANSI standardization.

The design uses multi-port RAMS. Do you have Tolmie's address/phone
at LANL? It is worth calling him.

Vint

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 11:53:09 GMT
From:      whna@cgchd1.uucp (Heinz Naef)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   BOOTP (RFC 951) Server for SunOS - anyone?

Did anyone implement BOOTP (The Bootstrap Protocol), as specified in RFC 951,
under SunOS 3.x?

Are you willing to provide the sources, either via e-mail or by posting them
to the net?

Thanks!

Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.62, P.O.Box, CH-4002 Basel, Switzerland
uucp: cgch!whna - bitnet: whna%cgch.uucp@cernvax.bitnet
                  phone: (+41) 61 697 26 75 - fax: (+41) 61 697 32 88

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 14:13:59 GMT
From:      valdis@SUN.MCS.CLARKSON.EDU
To:        comp.protocols.tcp-ip
Subject:   Whoops on ISODE 4.0

Mea Culpa...

My screwup - I read the first few lines of the note rather quickly, and
misread 'July 24' as 'June 24'.  I guess I must have had some sort of 
conditioned response since most announcements I see are of the 'is now
available' variety, and subconsciously decided the mail took 3 weeks to
get here (rare, but not unheard of..)

I'll try again Monday night.... :-)

				Valdis Kletnieks

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 14:41:07 GMT
From:      PULLEN@VAX.DARPA.MIL (Mark Pullen)
To:        comp.protocols.tcp-ip
Subject:   ARPANET Status Update


The  purpose  of  this  message is to provide members of the Arpanet and
Internet user communities with a  progress  report  on  current  changes
being  made  to  the  Arpanet,  as  well as some information about their
potential impact on network users.  As  an  earlier  message  to  tcp-ip
explained, DARPA plans to gradually phase out the Arpanet and replace it
with  a  higher-speed,  research-oriented internet (the Defense Research
Internet, or DRI).  While work on the  DRI  is  progressing,  the  first
phase  of  Arpanet  restructuring  has  been  implemented  and is nearly
complete.  Plans for a second phase are presently being finalized.   The
goal  of  these  initial  phases  is  a  near-term  reduction of Arpanet
operational costs through  the  elimination  of  selected  Arpanet  PSNs
(packet switching nodes) and leased interswitch trunks.  What follows is
a  summary  description  of  the  principal  actions taken under Phase I
restructuring. 

The  most  significant  aspect of Phase I restructuring is the temporary
use of channel streams derived from the DARPA Wideband Satellite Network
to maintain adequate cross-country connectivity  in  the  Arpanet  while
PSNs  and leased terrestrial lines comprising existing paths are removed
from service (during Phase II restructuring, cross-country  trunks  will
be moved off the Wideband Network and onto 56kb/s lines derived from the
terrestrial  backbone  being implemented for the DRI).  Special software
has been written for Butterfly Satellite  Imps  (BSATs),  which  enables
them  to  accept  subnetwork  packets from an Arpanet PSN trunk port and
encapsulate them in Wideband Network stream messages for transmission to
a distant PSN.  Three such trunks, terminated at sites where Arpanet and
Wideband Network  nodes  are  physically  collocated,  were  established
during the first week of May, 1988:  BBN to ISI, DCEC to ISI and DCEC to
SRI.  The intervening weeks have been spent tuning their performance. 

During the same time period, Phase I disconnect orders have been  issued 
for several of the longest and most expensive leased terrestrial trunks, 
along with a small number of PSNs.  Once these trunk and  PSN  deletions 
are complete (this should occur within the next  few  weeks),  only  one
terrestrial  cross-country  path   will  remain  in the Arpanet.  Trunks 
comprising the last remaining  terrestrial  path are currently scheduled 
to be removed by October 1, 1988.  At this point, the Arpanet will  rely 
heavily on  the  Wideband  Network,  plus  two  VSAT  satellite  trunks, 
to carry traffic between the east and west coasts of  the United States.  
This will make the quality of Arpanet  service  more  dependent  on  the 
Wideband Net.

By placing the Wideband  Net in  this  critical  role, we may experience
significant network congestion if there are Wideband Net outages. In the
event such an outage actually  occurs,  every  effort  will  be  made to
restore  service  to normal as soon as possible. The use of the Wideband
Net in this capacity is a transitional cost saving  measure  until  more 
cost effective leased land  lines  are  purchased.  They are anticipated 
to be installed by Dec 1988.  DARPA has plans to bring up early versions
of  the  Defense  Research  Internet  using  some  existing Wideband Net
equipment soon afterward.   This  will  produce  significant improvement
for users in the high load areas (directly supported by this experiment) 
and  indirectly  by  reducing  Arpanet load for all of the other Arpanet 
users.

Please be patient. Change is often  a  painful  process.  There will  be 
problems in  service  during  transition,  but  this effort is necessary
to enable future progress.

Mark Pullen, DARPA/ISTO


-------

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 16:51:06 GMT
From:      TENCATI@GPVAX.JPL.NASA.GOV
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and VMS

Greetings,

I have a question, and an appeal for developers of VMS TCP/IP products if
no answer is possible.

Is there a product, or a way under VMS to get the source address of a TCP/IP
connection entered into the accounting files?

As many of you probably read in the papers, we were hit by a hacker about a
month ago.  This penetration was accomplished over the Internet.  Unlike our
SPAN connection which is DECnet, we have no way of "tracing" a connection once
it is broken, because the TCP/IP product we are running is not part of VMS, and
therefore does not communicate with VMS' accounting package.   

Under DECnet, after an interactive user logs out, I have a record showing
the remote node and remote userid associated with the connection.   Under
TCP/IP, unless I am diligent and run NETSTAT, I have no way of tracing the
connection.  All accounting shows is a login on terminal NTY1 or XXA1, but
no information about the IP address of the source node.

It seems to me that with a little cooperation between DEC and the vendors, that 
a simple addition to LOGINOUT.EXE and/or the TELNET server would cause this
information to be recorded, provided accounting was enabled.  The benefits of 
having this information should be self evident.

Anybody have any constructive ideas on this subject?

Regards,

Ron Tencati
Jet Propulsion Laboratory
Pasadena, Ca.  

TENCATI@VLSI.JPL.NASA.GOV
TENCATI@GPVAX.JPL.NASA.GOV

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 18:30:47 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   UPGRADE OF MILNET PSNS


                  ANNOUNCEMENT OF MILNET PSN UPGRADE

This is a notice that PSN 7.0 software containing the implementation
of the new End-to-End protocols will be released to the MILNET within
the next few weeks.  The earliest possible date would be 5 August
1988.  More information will follow as it becomes available.

-------

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 18:56:48 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TLI transport specific addresses

in article <843@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
> Xref: nusdhub comp.dcom.lans:365 comp.protocols.tcp-ip:1120 comp.protocols.iso:49
>>You (the application) don't need to know the addressing format for
>>your provider any more than you need to know the sixteen tones
>>used in DTMF dialing to use a Touch-Tone(r) phone.  You provide
>>the free-form address as a string, and the rest of the system does
>>it's best to make the connection you want, but like the PSTN
>>(Public Switched Telephone Network) if you don't know the number
>>you want, you probably arn't gonna get through!
> 
> Yeah, but regardless of whether I use rotary, or touch tone, and whether
> the party I'm calling uses rotary or touch tone, we both agree on what
> our phone numbers are, and what the order of the digits are. Because of
> this, we can use a common name service called the telephone book.


Mike,

I don't know if you read teh entire thread, but your last comment is
_EXACTLY_ my point in making the telephone analogy.

The whole PURPOSE behind TLI is that you *should* pass any address
you want to use to TLI as a string; and the TLI driver for whatever
the network is, should do all the work of figuring out how the provider
needs the address (in binary) and changing the string to binary.

I don't know why you jumped off on the RFS tangent; who cares about
RFS per se, it was the addressing that was at issue...

The diference between "255.255.255.255" (the string) and 0FFFFFFFFx
(four bytes of binary) is quite essential and obvious.  The difference
between "nusdhub.serve" and the six byte 802.3 serial number/address
of this mahine (which I don't remember, and don't care about because
I have and use TLI) is even more obvious and reasonable.  One can
be included in the UUCP support files, prompted for as input,
supplied as a command argument, and passed around in a non-ambigous
format (between human people); the other can not.  TLI is intended
to use string addresses, and applications which _only_ pass/accept
memory structures are simply broken.

If you look back through thi thread, you will find that all of this
was started when one individual stated that it was stupid that AT&T
didn't invent a universal address structure and build it into TLI.
They did, they call it the string buffer; you know a length and an
offset, also known as a netbuf structure to the TLI library.

The thread was further complicated when this same individual lamented
the fact that he couldn't implement *all* of TCP/IP _over_ TLI.
Even attempting to implement TCP/IP _over_ TLI is stupid.  The
Whole point of TLI is to *dispose* of as many of the internal
issues of things like TCP/IP, in order to create a more simple
and basic programmer interface for the programmer who dosn't
want to specialize in networking.

Implementing TLI _over_ some or all of a TCP/IP transport provider
makes sense, but trying to do it the other way around is dumb.  Remember
the "more-restrictive-shell-above-lesser-restrictive-environment" rule
of systems design and arcitecture?

Rob.

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 19:04:19 GMT
From:      amdahl!ems!quest!cnt!rod@ames.arc.nasa.gov  (rod merry)
To:        tcp-ip@sri-nic.arpa
Subject:   SNMP mailing list?
Is there a mailing list for SNMP?
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 21:01:38 GMT
From:      guy@gorodish.Sun.COM (Guy Harris)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

> The fact that all you have ever seen of TCP/IP drivers written as
> TLI conformant functions pass the four byte addresses as actual
> bytes instead of a string like "109.90.42.6" is simply sad.

Excuse me, but this is nonsense; the difference between "actual bytes" and
"109.90.42.6" is trivial relative to the difference between "sun.com" and
"10.7.0.2".  If TLI forced me to pass a string like "109.90.42.6" to it, that
would be every bit as sad as if it forced me to pass that address down in
binary form.

> In essence this breaks the aledged uniformity.  To implement the
> TCP/IP and TLI over the same media,

You don't "implement TLI over a medium".  TLI/TPI is, in effect, an *interface*
that "transport providers" implement.  You implement a "TLI/TPI-conformant TCP"
or a "TLI/TPI-conformant UDP" or a "TLI/TPI-conformant ISO TP4" or a "TLI-TPI
conformant XNS SPP" or....

> the primitive kernel driver should be TCP/IP, and then a streams module
> which can convert TLI requests into TCP/IP should be written.

No, you implement a driver that provides the TCP or UDP protocol and that
conforms to the requirements of TPI and TLI.  That driver is what "converts
TPI/TLI requests into TCP".

> TCP/IP _is more_ complex, and therefore, to implement both TLI should be an
> optional addition onto the TCP/IP.

TCP and TLI are completely different types of things, so it's hard to say one
is "more complex" than the other, except to say "TLI supports functions TCP
doesn't provide" (which is true) or "TCP provides functions TLI doesn't
support" (which is also true).

> Then you place 109.90.42.6 in your Systems file;

I refuse to put something as gross as "109.90.42.6" into any configuration file
for a network utility; if I can't put the *name* of the machine there, that's
unacceptable.  There are, I believe, many *thousands* of hosts on the DARPA
Internet; I know there are thousands of hosts on Sun's network.  Sometimes
hosts may change their addresses but not their names.  Administering a network
of that size by using addresses rather than names would simply be impractical.

> The simple task of converting the string to the 4-byte couplet
> is not beyond the scope of a STREAMS module,

No, but it's not very useful, either.  What you *really* want is a mechanism
that can convert what you might call a "service specification" (i.e., "UUCP on
host 'sun.com' over TCP") into an address in whatever form the protocol
requires.  UUCP (which, I infer from your mention of a "Systems" file, is the
service to which you're referring here) would then ask for that service, and
hand *that* to TLI.


> All of this is much the purpose of the "adm" program which assembles
> the STREAMS modules which eventually make /dev/starlan operate
> the STARLAN product.  I would assume the correct "adm" program
> for an ethernet and/or internet support would activate two STREAMS
> multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.

Are you actually familiar with TCP or IP, or is your only TLI/TPI experience
with, e.g., STARLAN?  If you haven't worked with TCP, you should probably study
up on it first, and preferably on TLI-conformant TCP implementations, so you
can discuss implementations of things other than STARLAN meaningfully, and
support for multiple protocols in general, meaningfully.  If all you know is
STARLAN, you're unlikely to know what's involved in protocol independence....

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 88 22:45:02 GMT
From:      goldstei@MITRE.ARPA (Steve Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Los Alamos' High Speed Channel--Info anybody?

Vint,

"Do you have Tolmie's address/phone
at LANL?"

No, I don't.  Can/will you oblige?

Thanks,

Steve

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 88 13:36:29 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Multi-protocol wide area networks.

We are in learning mode about creating wide area networks. The
shortage of good solutions is shown by the NORDUNET plan. They are
going to create a wide area ethernet (via mac-level bridges) with no 
hosts on it, only routers for mid-level protocols like IP and DECNET 
plus funny boxes for connecting serial lines through an ethernet!

Let me say what I think is available today, and why it is deficient 
for what we would like to do.

Cisco and Proteon provide boxes which will route IP and DECNET (and 
other protocols of no interest to us) between ethernets. They claim 
they will soon support OSI Connectionless Network routing as well.
I know a little about Proteon P4200s, and assume Ciscos are the same:
the boxes can have ethernet boards and serial line boards. However the 
serial lines can only speak the secret Proteon protocol: so they have 
to lead to another Proteon box.

The first problem with this is that not all points on your network can 
justify a proteon box. If you have a small site with just a few Suns 
or VMS Vaxes then you will want to connect them to the world by just 
running slip out of one of the Suns or Asynch or Synch decnet out of 
one of the VAXes. It would be nice to be able to run these serial 
lines into a Proteon box serial port instead of having to run them 
into some host on your ethernet. The whole point of getting Proteon 
boxes is to avoid having hosts doing packet routing.

Another protocol we would like to support is X.25. It would be nice 
to allow two Proteon boxes to be able to talk to each other over X.25. 
Presumably this would be used as a backup mechanism for connection 
when a leased line malfunctions. But it could also be used as the 
normal method of moving packets between networks that don't have a lot 
to say to each other. Once again there are standards for running IP 
and DECNET over X.25. It would be nice to be able to run connections 
from isolated IP or DECNET nodes into a Proteon box via an X.25 
virtual circuit instead of having to run them through another host.

However we would also like to be able to have our router network act 
as an X.25 network. I.e. host1 can talk X.25 to host2 in:

         X.25 connection      private protocol       X.25
    host1---------------router----------------router-------host2

Why would you want to do this? Well firstly there are plenty of 
implementations now that will run OSI over X.25, so it is a natural 
way to get OSI protocols now. Conversely it is not obvious when there 
will be host implementations of Connectionless, or routing software 
that will allow implementations of X.400 (say) over CLN to talk to 
implementations connected to X.25 networks around the world. Also 
there is a lot of software around that runs over raw X.25 (or via 
non-standard mid-level protocols): such as the Coloured Book suite.

There are now protocols for running X.25 packets over ethernet 
(pinkbook), and over DECNET (PSI-access) and now also over TCP/IP. We 
would, of course, like our X.25 implementation to talk happily with 
these.

Another thing that would be useful would be to have our routers 
connect arbitrary synchronous lines.

  sync line----router------------router----sync line continues

This would allow for connecting IBM and other things through the 
network. Obviously a sync packet entering one end should not be unduly 
delayed before emerging from the other: these packets would have to 
have priority. For longish packets it might well be important to 
arrange for them to start emerging from the far end before they have 
even finished arriving at the receiving end. In which case you better 
arrange to get the rest to the far end in time!

It would also be nice if the router would act as a mac level bridge 
for some or all protocols it doesn't really know about. I gather from 
the nordunet proposal that this is coming.

Well, while we're at it. It would be nice to be able to use the serial 
ports as a serial line concentrator. Users logging in to these ports 
could be connected to their destination in many ways: telnet, rlogin, 
X.29, OSI VT, or just by connecting to another port somewhere. And if 
it was done nicely the user need not even be aware of how the
connection is being made. Protocol transparency: never quite comes off 
in real life.

Would any of the router makers like to comment on these proposals. All 
pie-in-the-sky? Is the NORDUNET wide area ethernet really the only 
way?

Bob Smart  <smart@ditmelb.oz.au> or <smart%ditmelb.oz.au@uunet.uu.net>

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 88 19:43:29 GMT
From:      gkn@M5.SDSC.EDU (Gerard K. Newman)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP and VMS


	From:	 TENCATI@gpvax.JPL.NASA.GOV
	Subject: TCP/IP and VMS
	Date:	 Fri, 22 Jul 88 09:51:06 PDT

	Is there a product, or a way under VMS to get the source address of a TCP/IP
	connection entered into the accounting files?

Ron:

What I did here was to run a program in SYS$SYLOGIN which pops into kernel mode
and plugs CTL$T_NODEADDR with the remote IP address of the connection.  Handily,
CTL$T_NODEADDR is a counted string (believe it or not), and can accomodate a 4
byte IP address instead of the usual 3 byte DECnet address.  While I'm in kernel
mode I also create the job-wide logical names SYS$REM_NODE and SYS$REM_ID.

A small patch to ACC.EXE allows it to display IP addresses in hex (but it has
the side effect of displaying DECnet addresses the same way).

I run the SRI Multinet software here.  I notice from your message header that
you have the Excelan software;  I can send you the code I use, but you'll have
to change it somewhat to do whatever magic is necessary to fetch the IP address
from an inbound terminal connection, as it is doubtless stored in a different
place.

Regards,

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:	  SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:	  Gerard K. Newman
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138-5608
Phone:	  619.534.5076

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 88 20:12:43 GMT
From:      gkn@M5.SDSC.EDU (Gerard K. Newman)
To:        comp.protocols.tcp-ip
Subject:   Argh.


More coffee ... that's *2* byte DECnet addresses, not 3.  Fingers don't
work on weekends...

gkn

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 88 21:50:29 GMT
From:      schoff@NISC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP mailing list?


    Is there a mailing list for SNMP?

Yes there is:

	snmp@nisc.nyser.net

It has been a bit quite lately..

Marty

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jul 88 19:09:13 CDT
From:      Mike Jacobson <SNJACOB%LSUVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  TCP/IP and VMS
Could you please post the code for putting the source address into an
accounting record that you told Ron Tencatti about to INFO-VAX or send
me a copy as well?



                                            Thanks in advance,

                                             Mike Jacobson

Mike Jacobson
Networks Manager
System Network Computer Ccenter
Louisiana State University
Phone: (504)388-1331
ARPAnet: JACOBSON%SNMRJ.SPAN@STAR.STANFORD.EDU
BITNET: SNJACOB@LSUVM
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 00:09:13 GMT
From:      SNJACOB@LSUVM.BITNET (Mike Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP and VMS

Could you please post the code for putting the source address into an
accounting record that you told Ron Tencatti about to INFO-VAX or send
me a copy as well?



                                            Thanks in advance,

                                             Mike Jacobson

Mike Jacobson
Networks Manager
System Network Computer Ccenter
Louisiana State University
Phone: (504)388-1331
ARPAnet: JACOBSON%SNMRJ.SPAN@STAR.STANFORD.EDU
BITNET: SNJACOB@LSUVM

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 02:59:42 GMT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   intro to tcp admin, part 1 of 3











                             Introduction
                                  to
                            Administration
                                of an
                            Internet-based
                            Local Network



                      C                       R

                              C       S
                  Computer Science Facilities Group
                              C       I

                      L                       S


                               RUTGERS
                  The State University of New Jersey
            Center for Computers and Information Services
               Laboratory for Computer Science Research


                             24 July 1988

This  is an introduction for people who intend to set up or administer
a network based on the Internet networking protocols (TCP/IP).

Copyright (C) 1988, Charles L. Hedrick.   Anyone  may  reproduce  this
document,  in  whole  or  in  part,  provided  that:   (1) any copy or
republication of the entire document must show Rutgers  University  as
the  source,  and  must  include this notice; and (2) any other use of
this material must reference this manual and Rutgers  University,  and
the fact that the material is copyright by Charles Hedrick and is used
by permission.



Unix is a trademark of AT&T Technologies, Inc.
 


                          Table of Contents


   1. The problem                                                    1
   2. Routing and Addressing                                         2
   3. Choosing an addressing structure                               3
       3.1 Should you subdivide your address space?                  5
       3.2 Subnets vs. multiple network numbers                      5
       3.3 How to allocate subnet or network numbers                 6
           3.3.1 Dealing with multiple "virtual" subnets  on  one    7
                 network
       3.4 Choosing an address class                                 8
   4. Setting up routing for an individual computer                  9
       4.1 How datagrams are routed                                 11
       4.2 Fixed routes                                             13
       4.3 Routing redirects                                        14
       4.4 Other ways for hosts to find routes                      16
           4.4.1 Spying on Routing                                  16
           4.4.2 Proxy ARP                                          17
           4.4.3 Moving to New Routes After Failures                22
   5. Bridges and Gateways                                          24
       5.1 Alternative Designs                                      25
           5.1.1 A mesh of point to point lines                     26
           5.1.2 Circuit switching technology                       27
           5.1.3 Single-level networks                              27
           5.1.4 Mixed designs                                      28
       5.2 An introduction to alternative switching technologies    29
           5.2.1 Repeaters                                          29
           5.2.2 Bridges and gateways                               30
           5.2.3 More about bridges                                 32
           5.2.4 More about gateways                                34
       5.3 Comparing the switching technologies                     34
           5.3.1 Isolation                                          35
           5.3.2 Performance                                        36
           5.3.3 Routing                                            37
           5.3.4 Network management                                 39
           5.3.5 A final evaluation                                 41
       5.4 Configuring routing for gateways                         44

















                                  i
 


This  document is intended to help people who planning to set up a new
network based on the Internet protocols, or to administer an  existing
one.    It  assumes  a  basic  familiarity  with the TCP/IP protocols,
particularly the structure of Internet addresses.  A companion  paper,
"Introduction  to  the  Internet  Protocols", may provide a convenient
introduction.  This document does not  attempt  to  replace  technical
documentation  for  your  specific  TCP/IP implementation.  Rather, it
attempts to give overall  background  that  is  not  specific  to  any
particular implementation.  It is directed specifically at networks of
"medium" complexity.  That  is,  it  is  probably  appropriate  for  a
network  involving  several dozen buildings.  Those planning to manage
larger networks will need more preparation than you can get by reading
this document.

In  a  number  of  cases,  commands  and output from Berkeley Unix are
shown.  Most computer  systems  have  commands  that  are  similar  in
function to these.  It seemed more useful to give some actual examples
that to limit myself to general talk, even if the  actual  output  you
see is slightly different.



1. The problem


This document will emphasize primarily "logical" network architecture.
There are many documents and articles in the trade press that  discuss
actual  network  media,  such  as  Ethernet, Token Ring, etc.  What is
generally not made clear in these  articles  is  that  the  choice  of
network  media  is  generally  not  all  that critical for the overall
design of a network.  What can be done by  the  network  is  generally
determined more by the network protocols supported, and the quality of
the implementations.  In practice, media are normally chosen based  on
purely  pragmatic  grounds: what media are supported by the particular
types of computer that you have to connect.  Generally this means that
Ethernet is used for medium-scale systems, Ethernet or a network based
on twisted-pair wiring for micro networks, and specialized  high-speed
networks  (typically  token  ring)  for campus-wide backbones, and for
local  networks  involving  super-computer  and   other   very   high-
performance applications.

Thus  this  document  assumes  that  you  have  chosen  and  installed
individual networks such as Ethernet or token ring,  and  your  vendor
has  helped  you connect your computers to these network.  You are now
faced with the interrelated problems of

   - configuring the software on your computers

   - finding a way to connect individual Ethernets, token rings, etc.,
     to form a single coherent network

   - connecting your networks to the outside world

My  primary  thesis in this document is that these decisions require a
bit  of  advance  thought.    In   fact,   most   networks   need   an
                                  1
 


"architecture".   This consists of a way of assigning addresses, a way
of doing routing, and various choices about how  hosts  interact  with
the  network.  These decisions need to be made for the entire network,
preferably when it is first being installed.



2. Routing and Addressing


Many of the decisions that you need  to  make  in  setting  up  TCP/IP
depend upon routing, so it will be best to give a bit of background on
that topic now.  I will return to routing  in  a  later  section  when
discussing  gateways  and  bridges.    In  general,  IP datagrams pass
through many networks while they are  going  between  the  source  and
destination.    Here's  a  typical  example.    (Addresses used in the
examples are taken from Rutgers University.)

              network 1               network 2     network 3
               128.6.4                 128.6.21      128.121
        ============================  ==========  ================
          |              |        |    |      |    |         |
       ___|______   _____|____  __|____|__  __|____|____  ___|________
       128.6.4.2    128.6.4.3   128.6.4.1   128.6.21.1    128.121.50.2
                                128.6.21.2  128.121.50.1
       __________   __________  __________  ____________  ____________
       computer A   computer B   gateway R    gateway S    computer C


This diagram shows three normal computer systems,  two  gateways,  and
three  networks.  The networks might be Ethernets, token rings, or any
other sort.  Network 2 could even be a  single  point  to  point  line
connecting gateways R and S.

Note  that computer A can send datagrams to computer B directly, using
network 1.  However it can't reach computer  C  directly,  since  they
aren't  on  the  same  network.    There  are  several ways to connect
separate networks.  This diagram assumes that gateways are used. (In a
later section, we'll look at an alternative.)  In this case, datagrams
going between A and C must be sent through gateway R, network  2,  and
gateway   S.   Every  computer  that  uses  TCP/IP  needs  appropriate
information and algorithms to allow it to know when datagrams must  be
sent through a gateway, and to choose an appropriate gateway.

Routing  is  very  closely tied to the choice of addresses.  Note that
the address of each computer begins with the  number  of  the  network
that  it's  attached  to.    Thus  128.6.4.2 and 128.6.4.3 are both on
network 128.6.4.  Next, notice that gateways, whose job is to  connect
networks,  have  an  address  on each of those networks.  For example,
gateway R connects networks 128.6.4 and 128.6.21.  Its  connection  to
network  128.6.4 has the address 128.6.4.1.  Its connection to network
128.6.21 has the address 128.6.21.2.

Because of this association between addresses  and  networks,  routing
decisions  can  be  based  strictly  on  the  network  number  of  the
                                  2
 


destination.  Here's what the routing information for computer A might
look like:

       network    gateway     metric

       128.6.4    none        0
       128.6.21   128.6.4.1   1
       128.121    128.6.4.1   2

From  this  table, computer A can tell that datagrams for computers on
network 128.6.4 can be sent directly, and datagrams for  computers  on
networks  128.6.21  and  128.121  need  to  be  sent  to gateway R for
forwarding.  The "metric" is used by  some  routing  algorithms  as  a
measure  of how far away the destination is.  In this case, the metric
simply indicates how many gateways the datagram  has  to  go  through.
(This is often referred to as a "hop count".)

When  computer  A  is  ready  to  send  a  datagram,  it  examines the
destination address.  The network number is taken from  the  beginning
of  the  address  and looked up in the routing table.  The table entry
indicates  whether  the  packet  should  be  sent  directly   to   the
destination or to a gateway.

Note  that  a  gateway  is  simply a computer that is connected to two
different networks, and is prepared to forward packets  between  them.
In  many  cases  it is most efficient to use special-purpose equipment
designed for use as a gateway.  However it is  perfectly  possible  to
use ordinary computers as gateways, as long as they have more than one
network  interface,  and  their  software  is  prepared   to   forward
datagrams.       Most   major   TCP/IP   implementations   (even   for
microcomputers) are designed  to  let  you  use  your  computer  as  a
gateway.  However some of this software has limitations that can cause
trouble for your network.



3. Choosing an addressing structure


The first comment to make about addresses is  a  warning:  Before  you
start  using  a  TCP/IP  network,  you  must  get one or more official
network numbers.  TCP/IP addresses look like this:  128.6.4.3.    This
address is used by one computer at Rutgers University.  The first part
of it, 128.6, is a network number, allocated to Rutgers by  a  central
authority.    Before you start allocating addresses to your computers,
you must get an official network number.  Unfortunately,  some  people
set  up  networks  using  either a randomly-chosen number, or a number
taken from examples in vendor documentation.  While this may  work  in
the  short  run,  it is a very bad idea for the long run.  Eventually,
you will want to connect your network  to  some  other  organization's
network.    Even  if  your  organization  is  highly  secret  and very
concerned about security, somewhere  in  your  organization  there  is
going  to  be  a  research  computer that ends up being connected to a
nearby university.  That university will probably be  connected  to  a
large-scale  national  network.    As  soon  as  one of your datagrams
                                  3
 


escapes your local network, the organization you  are  talking  to  is
going  to  become  very confused, because the addresses that appear in
your datagrams are probably officially allocated to someone else.

The solution to this is simple: get your own network number  from  the
beginning.    It  costs nothing.  If you delay it, then sometime years
from now you are going to be faced with  the  job  of  changing  every
address on a large network.  Network numbers are currently assigned by
the DDN Network Information Center, SRI International, 333  Ravenswood
Avenue,  Menlo  Park, California 94025 (telephone: 800-235-3155).  You
can get a network number no matter what your  network  is  being  used
for.    You  do  not need authorization to connect to the Defense Data
Network in order to get a number.  The main piece of information  that
will  be  needed  when  you apply for a network number is that address
class that you want.  See below for a discussion of this.

In many ways, the most important decision you have to make in  setting
up  a  network  is  how  you  will  assign  Internet addresses to your
computers.  This choice should be made with a view of how your network
is  likely  to grow.  Otherwise, you will find that you have to change
addresses.  When you have several hundred computers,  address  changes
can be nearly impossible.

Addresses  are  critical  because Internet datagrams are routed on the
basis of their address.  For example, addresses at Rutgers  University
have  a  2-level structure.  A typical address is 128.6.4.3.  128.6 is
assigned to Rutgers University by a central authority.  As far as  the
outside  world  is  concerned,  128.6  is  a  single  network.   Other
universities send any packet whose address begins with  128.6  to  the
nearest  Rutgers  gateway.    However within Rutgers, we divide up our
address space into "subnets".  We use the next 8 bits  of  address  to
indicate  which  subnet  a  computer belongs to.  128.6.4.3 belongs to
subnet 128.6.4.  Generally subnets correspond  to  physical  networks,
e.g.  separate  Ethernets,  although as we will see later there can be
exceptions.  Systems inside Rutgers,  unlike  those  outside,  contain
information  about the Rutgers subnet structure.  So once a packet for
128.6.4.3 arrives at Rutgers, the Rutgers network will route it to the
departmental Ethernet, token ring, or whatever, that has been assigned
subnet number 128.6.4.

When you start a network, there are several addressing decisions  that
face you:

   - Do you subdivide your address space?

   - If so, do you use subnets or class C addresses?

   - You do you allocate subnets or class C networks?

   - How big an address space do you need?





                                  4
 


3.1 Should you subdivide your address space?


It  is  not  necessary  to  use  subnets  at  all.   There are network
technologies that allow an entire campus or company to act as a single
large  logical Ethernet, so that no internal routing is necessary.  If
you use this technology, then  you  do  not  need  to  subdivide  your
address  space.    In that case, the only decision you have to make is
what class address to apply for.  However we recommend using either  a
subnet approach or some other method of subdividing your address space
in all cases:

   - In section 5.2 we will argue that internal gateways are desirable
     for networks of any degree of complexity.

   - Even if you do not need gateways now, you may find later that you
     need to  use  them.  Thus  it  probably  makes  sense  to  assign
     addresses  as  if  each  Ethernet or token ring was going to be a
     separate subnet.  This will allow for conversion to real  subnets
     later if it proves necessary.

   - For  network  maintenance  purposes,  it  is  convenient  to have
     addresses whose structure corresponds to  the  structure  of  the
     network.    That  is,  when  you  see  a stray packet from system
     128.6.4.3, it is nice to know that all addresses  beginning  with
     128.6.4 are in a particular building.



3.2 Subnets vs. multiple network numbers


Suppose  that  you have been convinced that it's a good idea to impose
some structure on your addresses.  The  next  question  is  what  that
structure should be.  There are two basic approaches.  One is subnets.
The other is multiple network numbers.

The Internet standards specify what constitutes a network number.  For
numbers  beginning with 128 through 191 (the most common numbers these
days), the first  two  octets  form  the  network  number.    E.g.  in
140.3.50.1, 140.3 is the network number.  Network numbers are assigned
to a particular organization.  What you do with the next two octets is
up  to  you.    You  could  choose  to make the next octet be a subnet
number, or you could use some other scheme entirely.  Gateways  within
your  organization  will  be set up to know the subnetting scheme that
you are using.  However outside your organization, no  one  will  know
that 140.3.50 is one subnet and 140.3.51 is another.  They will simply
know that 140.3 is your organization.  Unfortunately, this ability  to
add additional structure to the address via subnets was not present in
the original TCP/IP specifications.  Thus some software  is  incapable
of being told about subnets.

If  enough of the software that you are using has this problem, it may
be impractical for you to use subnets.  Some organizations have used a
different  approach.   It is possible for an organization to apply for
                                  5
 


several network numbers.  Instead of dividing a single network number,
say  140.3,  into  several subnets, e.g. 140.3.1 through 140.3.10, you
could apply for 10 different network  numbers.    Thus  you  might  be
assigned  the  range  140.3  through 140.12.  All TCP/IP software will
know that these are different network numbers.

While using separate network numbers will work just fine  within  your
organization,  it  has two very serious disadvantages.  The first, and
less serious, is that it wastes address space.  There are  only  about
16,000  possible  class  B addresses.  We cannot afford to waste 10 of
them on your organization, unless it is very large.  This objection is
less  serious because you would normally ask for class C addresses for
this  purpose,  and  there  are  about  2  million  possible  class  C
addresses.

The  more  serious  problem  with using several network numbers rather
than subnets is that it overloads the routing tables in  the  rest  of
the Internet.  As mentioned above, when you divide your network number
into subnets, this division is known within your organization, but not
outside  it.    Thus  systems  outside your organization need only one
entry in their tables in order to be able to reach you.    E.g.  other
universities  have entries in their routing tables for 128.6, which is
the Rutgers network number.  If you use a  range  of  network  numbers
instead  of  subnets,  that  division  will  be  visible to the entire
Internet.  If we used 128.6  through  128.16  instead  of  subdividing
128.6, other universities would need entries for each of those network
numbers in their routing tables.   As  of  this  writing  the  routing
tables  in many of the national networks are exceeding the size of the
current  routing  technology.    It  would  be  considered   extremely
unfriendly  for  any organization to use more than one network number.
This may not be a problem if your network is going  to  be  completely
self-contained,  or if only one small piece of it will be connected to
the  outside  world.    Nevertheless,  most  TCP/IP  experts  strongly
recommend  that  you  use  subnets rather than multiple networks.  The
only reason for considering multiple networks is to deal with software
that  cannot  handle subnets.  This was a problem a few years ago, but
is currently less serious.   As  long  as  your  gateways  can  handle
subnets,  you  can deal with a few individual computers that cannot by
using "proxy ARP" (see below).



3.3 How to allocate subnet or network numbers


Now that you have decided to use subnets or multiple network  numbers,
you  have  to  decide  how  to allocate them.  Normally this is fairly
easy.  Each physical network, e.g. Ethernet or token ring, is assigned
a  separate  subnet  or  network  number.    However  you do have some
options.

In some cases it may make sense to assign several subnet numbers to  a
single  physical  network.   At Rutgers we have a single Ethernet that
spans three buildings, using repeaters.  It is very clear to  us  that
as  computers  are  added  to this Ethernet, it is going to have to be
                                  6
 


split into several separate Ethernets.  In order to  avoid  having  to
change  addresses when this is done, we have allocated three different
subnet numbers to this Ethernet, one per building.    (This  would  be
handy  even  if  we didn't plan to split the Ethernet, just to help us
keep track of where computers are.)  However before doing  this,  make
very  sure  that  the  software  on all of your computers can handle a
network that has three different network numbers on it.

You also have to choose a "subnet mask".  This is used by the software
on  your  systems to separate the subnet from the rest of the address.
So far we have always assumed  that  the  first  two  octets  are  the
network  number, and the next octet is the subnet number.  For class B
addresses, the standards specify that the first  two  octets  are  the
network  number.    However we are free to choose the boundary between
the subnet number and the rest of the address.  It's  very  common  to
have  a  one-octet  subnet  number,  but  that's not the only possible
choice.  Let's look again at a class B address, e.g. 128.6.4.3.  It is
easy to see that if the third octet is used for a subnet number, there
are 256 possible subnets and within each subnet there are 256 possible
addresses.    (Actually,  the  numbers  are more like 254, since it is
generally a bad idea to use 0 or 255 for subnet numbers or addresses.)
Suppose you know that you will never have more than 128 computers on a
given subnet, but you are afraid you might need more than 256 subnets.
(For  example,  you might have a campus with lots of small buildings.)
In that case, you could define 10 bits for the subnet number,  leaving
6  bits for addresses within each subnet.  This choice is expressed by
a bit mask, using ones for the bits used by  the  network  and  subnet
number,  and  0's  for  the  bits  used for individual addresses.  Our
normal subnet choice is given as 255.255.255.0.  If we  chose  10  bit
subnet  numbers  and  6  bit  addresses,  the  subnet  mask  would  be
255.255.255.192.

Generally it is possible to specify the subnet mask for each  computer
as part of configuring its TCP/IP software.  The TCP/IP protocols also
allow for computers to send a query asking what the  subnet  mask  is.
If  your network supports broadcast queries, and there is at least one
computer or gateway on the network that knows the subnet mask, it  may
be  unnecessary  to  set  it on the other computers.  (This capability
brings with it a whole new set of possible problems.   One  well-known
TCP/IP  implementation  would  answer  with the wrong subnet mask when
queried, thus leading causing every other computer on the  network  to
be misconfigured.)



3.3.1 Dealing with multiple "virtual" subnets on one network


Most  software  is written under the assumption that every computer on
the local network has the same subnet number.  When traffic  is  being
sent  to  a  machine with a different subnet number, the software will
generally expect to find  a  gateway  to  handle  forwarding  to  that
subnet.  Let's look at the implications.  Suppose subnets 128.6.19 and
128.6.20 are on the same Ethernet.  Consider the way things look  from
the point of view of a computer with address 128.6.19.3.  It will have
                                  7
 


no problem sending to other machines with addresses 128.6.19.x.   They
are on the same subnet, and so our computer will know to send directly
to them on the local Ethernet.  However suppose it is asked to send  a
packet to 128.6.20.2.  Since this is a different subnet, most software
will expect to find a gateway that handles forwarding between the  two
subnets.  Of course there isn't a gateway between subnets 128.6.19 and
128.6.20, since they are on the  same  Ethernet.    Thus  it  must  be
possible  to  tell your software that 128.6.20 is actually on the same
Ethernet.

For the most common TCP/IP implementations, it  is  possible  to  deal
with  more  than  one subnet on a network.  For example, Berkeley Unix
allows you to define gateways using a command "route  add".    Suppose
that  you  get  from subnet 128.6.19 to subnet 128.6.4 using a gateway
whose address is 128.6.19.1.  You would use the command

  route add 128.6.4.0 128.6.19.1 1

This says that to reach subnet 128.6.4, traffic should be sent via the
gateway  at  128.6.19.1, and that the route only has to go through one
gateway.  The "1" is referred to as the "routing metric".  If you  use
a  metric  of  0, you are saying that the destination subnet is on the
same network, and no gateway is needed.  In  our  example,  on  system
128.6.19.3, you would use

  route add 128.6.20.0 128.6.19.1 0

The  actual  address  used  in place of 128.6.19.1 is irrelevant.  The
metric of 0 says that no gateway is actually going to be used, so  the
gateway  address  is  not used.  However it must be a legal address on
the local network.

Note that the commands in this section are simply examples. You should
look  in  the  documentation for your particular implementation to see
how to configure your routing.



3.4 Choosing an address class


When you apply for an official network number, you will be asked  what
class  of network number you need.  The possible answers are A, B, and
C. This affects how large an address  space  you  will  be  allocated.
Class  A addresses are one octet long, class B addresses are 2 octets,
and class C addresses are 3  octets.    This  represents  a  tradeoff:
there are a lot more class C addresses than class A addresses, but the
class C addresses don't allow as many hosts.  The idea was that  there
would  be  a few very large networks, a moderate number of medium-size
ones, and a lot of mom-and-pop stores that would have small  networks.
Here is a table showing the distinction:

   class  range of first octet   network   rest  possible addresses
     A       1 - 126               p      q.r.s    16777214
     B       128 - 191             p.q      r.s    65534
                                  8
 


     C       192 - 223             p.q.r      s    254

For  example  network  10,  a  class  A network, has addresses between
10.0.0.1 and 10.255.255.254.  So it allows 254**3, or about 16 million
possible  addresses.    (Actually,  network 10 has allocated addresses
where some of the octets are zero, so there are a  few  more  networks
possible.)    Network  192.12.88,  a class C network has hosts between
192.12.88.1 and 128.12.88.254, i.e. 254 possible hosts.

In general, you will be expected to choose the lowest class that  will
provide  you with enough addresses to handle your growth over the next
few years.  In general  organizations  that  have  computers  in  many
buildings  will  probably  need  and be able to get a class B address,
assuming that they are going to use subnetting.  (If you are going  to
use many separate network numbers, you would ask for a number of class
C addresses.)  Class A addresses are  normally  used  only  for  large
public networks and for a few very large corporate networks.



4. Setting up routing for an individual computer


All  TCP/IP  implementations require some configuration for each host.
In some cases this is done in a "system generation".  In other  cases,
various  startup and configuration files must be set up on the system.
Still other systems get configuration information across  the  network
from  a  "server".    While  the  details  differ,  the  same kinds of
information need to  be  supplied  for  most  implementations.    This
includes

   - parameters  describing the specific machine, such as its Internet
     address.

   - parameters describing the network, such as the  subnet  mask  (if
     any)

   - routing software and the tables that drive it

   - startup of various programs needed to handle network tasks

Before  a  machine  is installed on your network, a coordinator should
assign it a host name and Internet address.  If the machine  has  more
than  one  network  interface,  you  must  assign  a separate Internet
address for each.  (In most cases, the same host  name  can  be  used.
The  name  goes  with  the  machine as a whole, whereas the address is
associated with the connection to a specific network.)    The  address
should begin with the network number for the network to which it is to
be attached.  We recommend that you assign addresses starting from  1.
Should  you  find  that you need more subnets than your current subnet
mask allows, you may later need to expand the subnet mask to use  more
bits.  If all addresses use small numbers, this will be possible.

Generally  the  Internet  address  must be specified individually in a
configuration  file  on  each  computer.    However   some   computers
                                  9
 


(particularly  those  without  permanent  disks on which configuration
information could be  stored)  find  out  their  Internet  address  by
sending  a broadcast request over the network.  In that case, you will
have to make sure that some other system is configured to  answer  the
request.    When  a  system  asks  for  its  Internet  address, enough
information must be put into the request to allow  another  system  to
recognize  it  and  to  send  a  response back.  For Ethernet systems,
generally the  request  will  include  the  Ethernet  address  of  the
requesting  system.    Ethernet addresses are assigned by the computer
manufacturers, and are guaranteed to be unique.  Thus they are a  good
way  of  identifying the computer.  And of course the Ethernet address
is also needed in order to send the response back.  If it is  used  as
the basis for address lookup, the system that is to answer the request
will need a table of Ethernet addresses and the corresponding Internet
address.   The only problem in constructing this table will be finding
the Ethernet address for each  computer.    Generally,  computers  are
designed  so  that  they  print  the  Ethernet  address on the console
shortly after being turned on.  However in some cases you may have  to
type a command that displays information about the Ethernet interface.

Generally  the subnet mask should be specified in a configuration file
associated with the computer.    (For  Unix  systems,  the  "ifconfig"
command is used to specify both the Internet address and subnet mask.)
However there are provisions in the IP protocols  for  a  computer  to
broadcast a request asking for the subnet mask.  The subnet mask is an
attribute of the network.  That is, it is the same for  all  computers
on   a  given  subnet.    Thus  there  is  no  separate  subnet  table
corresponding to the Ethernet/Internet address mapping table  used  to
answer  address  queries.    Generally any machine on the network that
believes it knows the subnet mask will  answer  any  query  about  the
subnet mask.  For that reason, an incorrect subnet mask setting on one
machine can cause confusion throughout the network.

Normally the configuration files do roughly the following things:

   - enable each of the network interfaces (Ethernet interface, serial
     lines,  etc.)    Normally  this  involves  specifying an Internet
     address and subnet mask for each, as well as other  options  that
     will be described in your vendor's documentation.

   - establish  network  routing  information, either by commands that
     add fixed routes, or by starting  a  program  that  obtains  them
     dynamically.

   - turn  on  the  name server (used for looking up names and finding
     the corresponding Internet address --  see  the  section  on  the
     domain system in the Introduction to TCP/IP).

   - set various other information needed by the system software, such
     as the name of the system itself.

   - start various "daemons".  These are programs that provide network
     services  to  other  systems on the network, and to users on this
     system.

                                  10
 


It is not practical to document these  steps  in  detail,  since  they
differ for each vendor.  This section will concentrate on a few issues
where your choice will depend upon overall decisions  about  how  your
network  is  to  operate.   These overall network policy decisions are
often not as well documented by the vendors as the details of  how  to
start  specific  programs.    Note that some care will be necessary to
integrate commands that you add for routing, etc.,  into  the  startup
sequence  at  the  right  point.  Some of the most mysterious problems
occur when network routing is not set up before  a  program  needs  to
make  a  network  query,  or when a program attempts to look up a host
name before the name server has finished loading all of the names from
a master name server.



4.1 How datagrams are routed


If your system consists of a single Ethernet or similar medium, you do
not need to give routing much attention.   However  for  more  complex
systems,  each  of  your  machines  needs a routing table that lists a
gateway and interface to use for every possible  destination  network.
A  simple  example of this was given at the beginning of this section.
However it is now necessary to describe the way routing works in a bit
more  detail.  On most systems, the routing table looks something like
the following. (This example was taken from a system running  Berkeley
Unix,  using  the  command  "netstat  -n -r".  Some columns containing
statistical information have been omitted.)

    Destination          Gateway              Flags       Interface

    128.6.5.3            128.6.7.1            UHGD        il0
    128.6.5.21           128.6.7.1            UHGD        il0
    127.0.0.1            127.0.0.1            UH          lo0
    128.6.4              128.6.4.61           U           pe0
    128.6.6              128.6.7.26           U           il0
    128.6.7              128.6.7.26           U           il0
    128.6.2              128.6.7.1            UG          il0
    10                   128.6.4.27           UG          pe0
    128.121              128.6.4.27           UG          pe0
    default              128.6.4.27           UG          pe0

The example system is connected to two Ethernets:

      controller  network   address     other networks
         il0      128.6.7   128.6.7.26    128.6.6
         pe0      128.6.4   128.6.4.61    none

The first column shows the designation  for  the  controller  hardware
that  connects the computer to that Ethernet.  (This system happens to
have controllers from two different vendors.  The first one is made by
Interlan,  the  second  by Pyramid.)  The second column is the network
number for the network.  The third column is this computer's  Internet
address  on  that  network.   The last column shows other subnets that
share the same physical network.
                                  11
 


Now let's look at the routing table.  For the moment,  let  us  ignore
the  first  3  lines.   The majority of the table consists of a set of
entries describing networks.    For  each  network,  the  other  three
columns  show  where  to send datagrams destined for that network.  If
the "G" flag is present  in  the  third  column,  datagrams  for  that
network  must  be sent through a gateway.  The second column shows the
address of the gateway to be used.  If the "G" flag  is  not  present,
the  computer  is  directly  connected to the network in question.  So
datagrams for that network should be sent using the  controller  shown
in  the  third  column.    The  "U"  flag  in  the third column simply
indicates that the route specified by that line is up,  i.e.  that  no
errors have occured indicating that the path is unusable.

The  first  3  lines  show "host routes", indicated by the "H" flag in
column three.    Routing  tables  normally  have  entries  for  entire
networks or subnets.  For example, the entry

    128.6.2              128.6.7.1            UG          il0

indicates  that  datagrams  for  any computer on network 128.6.2 (i.e.
addresses 128.6.2.1 through 128.6.2.254) should  be  sent  to  gateway
128.6.7.1  for  forwarding.   However sometimes routes apply only to a
specific computer, rather than to a whole network.  In  that  case,  a
host  route  is used.  The first column then shows a complete address,
and the "H" flag is present in column 3.  E.g. the entry

    128.6.5.21           128.6.7.1            UHGD        il0

indicates that datagrams for the specific address 128.6.5.21 should be
sent  to  the gateway 128.6.7.1.  As with network routes, the "G" flag
is used for routes that involve a gateway.   The  "D"  flag  indicates
that  the  route  was  added  dynamically,  based  on an ICMP redirect
message from a gateway.  (See below for details.)

The following route is special:

    127.0.0.1            127.0.0.1            UH          lo0

127.0.0.1 is the address of the "loopback device".  This  is  a  dummy
software  module.  Any datagram sent out through that "device" appears
immediately as input.  It can be  used  for  testing.    The  loopback
address  is  also  handy  for  sending  queries  to  programs that are
designed to respond to network queries, but happen to  be  running  on
the  same  computer.    (Why  bother  to use your network to talk to a
program that is on the same machine you are?)

Finally, there are "default" routes, e.g.

    default              128.6.4.27           UG          pe0

This route is used for datagrams that don't match any other entry.  In
this case, they are sent to a gateway with address 128.6.4.27.

In  most  systems,  datagrams are routed by looking up the destination
address in a table such as the one just described.    If  the  address
                                  12
 


matches  a  specific  host route, then that is used.  Otherwise, if it
matches a network route, that is used.  If no other route  works,  the
default  is  used.   If there is no default, normally the user gets an
error message such as "network is unreachable".

The following sections will describe several ways of setting up  these
routing  tables.    Generally, the actual operation of sending packets
doesn't depend upon which method you use to set up the routes.  When a
packet  is to be sent, its destination is looked up in the table.  The
different routing methods are simply more and less sophisticated  ways
of setting up and maintaining the tables.



4.2 Fixed routes


The  simplest  way  of  doing  routing  is  to have your configuration
contain commands to set up the routing  table  at  startup,  and  then
leave  it  alone.    This  method  is  practical  for relatively small
networks, particularly if they don't change very often.

Most computers automatically set up  some  routing  entries  for  you.
Unix  will  add  an  entry  for the networks to which you are directly
connected.  For example, your startup file might contain the commands

      ifconfig ie0 128.6.4.4 netmask 255.255.255.0
      ifconfig ie1 128.6.5.35 netmask 255.255.255.0

These  specify  that  there  are  two  network  interfaces,  and  your
addresses on them.  The system will automatically create routing table
entries

    128.6.4              128.6.4.4            U           ie0
    128.6.5              128.6.5.35           U           ie1

These specify that  datagrams  for  the  local  subnets,  128.6.4  and
128.6.5, should be sent out the corresponding interface.

In  addition  to  these,  your startup files would contain commands to
define routes to whatever other networks you wanted  to  reach.    For
example,

      route add 128.6.2.0 128.6.4.1  1
      route add 128.6.6.0 128.6.5.35 0

These  commands  specify  that  in  order  to reach network 128.6.2, a
gateway at address 128.6.4.1 should be used, and that network  128.6.6
is  actually  an  additional  network  number for the physical network
connected to interface 128.6.5.35.   Some  other  software  might  use
different  commands  for these cases.  Unix differentiates them by the
"metric", which is the number at the end of the command.   The  metric
indicates  how  many  gateways the datagram will have to go through to
get to the destination.  Routes with metrics of 1 or  greater  specify
the  address of the first gateway on the path.  Routes with metrics of
                                  13
 


0 indicate that no gateway  is  involved  --  this  is  an  additional
network number for the local network.

Finally, you might define a default route, to be used for destinations
not listed explicitly.  This would normally  show  the  address  of  a
gateway   that   has   enough   information  to  handle  all  possible
destinations.

If your network has only one gateway attached to it,  then  of  course
all  you  need is a single entry pointing to it as a default.  In that
case, you need not worry further about  setting  up  routing  on  your
hosts.    (The  gateway  itself needs more attention, as we will see.)
The following sections are intended to provide  help  for  setting  up
networks where there are several different gateways.



4.3 Routing redirects


Most  Internet  experts  recommend  leaving  routing  decisions to the
gateways.  That is, it is probably a bad  idea  to  have  large  fixed
routing  tables  on each computer.  The problem is that when something
on the network changes, you have to go around to  many  computers  and
update  the  tables.    If  changes  happen  because a line goes down,
service may not be restored until someone has a chance to  notice  the
problem and change all the routing tables.

The  simplest way to keep routes up to date is to depend upon a single
gateway to update your routing tables.  This gateway should be set  as
your  default.  (On Unix, this would mean a command such as "route add
default  128.6.4.27  1",  where  128.6.4.27  is  the  address  of  the
gateway.)   As described above, your system will send all datagrams to
the default when it doesn't have any better route.    At  first,  this
strategy  does  not sound very good if you have more than one gateway.
After all, if all you have is a single default  entry,  how  will  you
ever  use  the other gateways in the cases where they are better?  The
answer is that most gateways are able to send  "redirects"  when  they
get  datagrams  for  which  there  is a better route.  A redirect is a
specific kind of message using  the  ICMP  (Internet  Control  Message
Protocol).    It contains information that generally translates to "In
the future, to get to address XXXXX, please use gateway YYYYY  instead
of  me".    Correct  TCP/IP implementations use these redirects to add
entries to their routing table.  Suppose your routing table starts out
as follows:

    Destination          Gateway              Flags       Interface

    127.0.0.1            127.0.0.1            UH          lo0
    128.6.4              128.6.4.61           U           pe0
    default              128.6.4.27           UG          pe0

This  contains  an entry for the local network, 128.6.4, and a default
pointing to the gateway 128.6.4.27.  Suppose there is also  a  gateway
128.6.4.30,  which  is the best way to get to network 128.6.7.  How do
                                  14
 


you find it?  Suppose you have datagrams to send to 128.6.7.23.    The
first  datagram  will go to the default gateway, since that's the only
thing in the routing table.  However the default gateway,  128.6.4.27,
will  notice  that 128.6.4.30 would really be a better route.  (How it
does that is up to the gateway.  However there are some fairly  simple
methods  for a gateway to determine that you would be better off using
a  different  one.)    Thus  128.6.4.27  will  send  back  a  redirect
specifying  that packets for 128.6.7.23 should be sent via 128.6.4.30.
Your TCP/IP software will add a routing entry

    128.6.7.23           128.6.4.30           UDHG         pe0

Any future datagrams for 128.6.7.23  will  be  sent  directly  to  the
appropriate gateway.

This  strategy  would  be a complete solution, if it weren't for three
problems:

   - It requires each computer to have  the  address  of  one  gateway
     "hardwired" into its startup files, as the initial default.

   - If a gateway goes down, routing table entries using it may not be
     removed.

   - If your network uses subnets, and your TCP/IP implementation does
     not handle them, this strategy will not work.

How  serious  the  first  problem is depends upon your situation.  For
small networks, there is no problem modifying startup  files  whenever
something  changes.   But some organizations can find it very painful.
If network topology changes, and a gateway  is  removed,  any  systems
that  have  that  gateway  as their default must be adjusted.  This is
particularly serious if the people who maintain the  network  are  not
the  same  as  those  maintaining  the individual systems.  One simple
appoach is to make sure that the default address never changes.    For
example,  you might adopt the convention that address 1 on each subnet
is the default gateway for  that  subnet.    For  example,  on  subnet
128.6.7,  the  default  gateway  would  always  be 128.6.7.1.  If that
gateway is ever removed, some other gateway  is  given  that  address.
(There  must  always  be  at least one gateway left to give it to.  If
there isn't, you are completely cut off anyway.)

The biggest problem with the description given so far is that it tells
you how to add routes but not how to get rid of them.  What happens if
a gateway goes down?  You want traffic to  be  redirected  back  to  a
gateway  that is up.  Unfortunately, a gateway that has crashed is not
going to issue Redirects.  One solution is  to  choose  very  reliable
gateways.  If they crash very seldom, this may not be a problem.  Note
that Redirects can be used to handle some kinds  of  network  failure.
If  a  line goes down, your current route may no longer be a good one.
As long as the gateway to which  you  are  talking  is  still  up  and
talking  to you, it can simply issue a Redirect to the gateway that is
now the best one.  However you still need a way to detect  failure  of
one of the gateways that you are talking to directly.

                                  15
 


The  best  approach  for  handling  failed gateways is for your TCP/IP
implementation to detect routes  that  have  failed.    TCP  maintains
various timers that allow the software to detect when a connection has
broken.  When this happens, one good approach is  to  mark  the  route

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 03:01:39 GMT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   intro to tcp admin, part 2 of 3


down, and go back to the default gateway.  A similar approach can also
be used to handle failures in the default gateway.  If you  have  mark
two  gateways  as  default,  then  the  software  should be capable of
switching  when  connections  using  one  of   them   start   failing.
Unfortunately,  some  common TCP/IP implementations do not mark routes
as down and change to new ones.  (In particular Berkeley 4.2 Unix does
not.)    However  Berkeley 4.3 Unix does do this, and as other vendors
begin to base products  on  4.3  rather  than  4.2,  this  ability  is
expected to be more common.



4.4 Other ways for hosts to find routes


As  long  as  your  TCP/IP  implementations handle failing connections
properly, establishing one or more default routes in the configuration
file  is  likely  to  be  the simplest way to handle routing.  However
there are two other routing approaches that are worth considering  for
special situations:

   - spying on the routing protocol

   - using proxy ARP



4.4.1 Spying on Routing


Gateways  generally  have  a  special  protocol  that  they  use among
themselves.    Note  that  redirects  cannot  be  used  by   gateways.
Redirects  are  simply ways for gateways to tell "dumb" hosts to use a
different gateway.  The  gateways  themselves  must  have  a  complete
picture of the network, and a way to compute the optimal route to each
subnet.    Generally  they  maintain  this   picture   by   exchanging
information  among  themselves.    There are several different routing
protocols in use for this purpose.  One way for  a  computer  to  keep
track  of  gateways  is  for  it  to listen to the gateways' messages.
There is software available for this purpose for most  of  the  common
routing  protocols.    When  you  run  this  software,  it maintains a
complete picture of the  network,  just  as  the  gateways  do.    The
software  is  generally  designed  to maintain your computer's routing
tables dynamically, so that datagrams are always sent  to  the  proper
gateway.  In effect, the routing software issues the equivalent of the
Unix "route add" and "route delete" commands as the  network  topology
changes.    Generally this results in a complete routing table, rather
than one that depends upon default routes.   (This  assumes  that  the
gateways  themselves  maintain  a  complete table.  Sometimes gateways
keep track of your campus network completely, but use a default  route
for all off-campus networks, etc.)
                                  16
 


Running  routing  software on each host does in some sense "solve" the
routing problem.  However there are several reasons why  this  is  not
normally  recommended  except  as  a  last  resort.   The most serious
problem is that this reintroduces configuration options that  must  be
kept  up to date on each host.  Any computer that wants to participate
in the protocol among the gateways will need to configure its software
compatibly   with   the   gateways.      Modern  gateways  often  have
configuration options that are  complex  compared  with  those  of  an
individual host.  It is undesirable to spread these to every host.

There  is  a  somewhat  more  specialized problem that applies only to
diskless computers.  By its very nature, a diskless  computer  depends
upon the network and file servers to load programs and to do swapping.
It is dangerous for  diskless  computers  to  run  any  software  that
listens  to  network  broadcasts.   Routing software generally depends
upon broadcasts.  For example,  each  gateway  on  the  network  might
broadcast  its  routing  tables  every  30  seconds.  The problem with
diskless nodes is that the software to listen to these broadcasts must
be loaded over the network.  On a busy computer, programs that are not
used for a few seconds will be swapped or paged out.   When  they  are
activated  again,  they  must  be  swapped  or  paged  in.  Whenever a
broadcast is sent, every computer on the network needs to activate the
routing  software  in order to process the broadcast.  This means that
many diskless computers will be doing swapping or paging at  the  same
time.    This  is likely to cause a temporary overload of the network.
Thus it is very unwise for diskless machines to run any software  that
requires them to listen to broadcasts.



4.4.2 Proxy ARP


Proxy  ARP  is  an alternative technique for letting gateways make all
the routing decisions.  It is applicable to any broadcast network that
uses  ARP  or  a similar technique for mapping Internet addresses into
network-specific  addresses  such  as  Ethernet   addresses.      This
presentation  will  assume  Ethernet.    Other  network  types  can be
acccomodated if you replace "Ethernet address"  with  the  appropriate
network-specific  address,  and ARP with the protocol used for address
mapping by that network type.

In many ways proxy ARP it is similar to  using  a  default  route  and
redirects, however it uses a different mechanism to communicate routes
to the host.  With redirects, a full routing table is used.    At  any
given moment, the host knows what gateways it is routing datagrams to.
With proxy ARP, you dispense with  explicit  routing  tables,  and  do
everything  at the level of Ethernet addresses.  Proxy ARP can be used
for all destinations, only for destinations within your network, or in
various  combinations.   It will be simplest to explain it as used for
all addresses.  To do this, you instruct  the  host  to  pretend  that
every  computer  in  the  world  is  attached  directly  to your local
Ethernet.  On Unix, this would be done using a command

      route add default 128.6.4.2 0
                                  17
 


where 128.6.4.2 is assumed to be the Internet address  of  your  host.
As  explained  above,  the  metric of 0 causes everything that matches
this route to be sent directly on the local Ethernet.

When a datagram is to be sent to a local  Ethernet  destination,  your
computer  needs  to  know the Ethernet address of the destination.  In
order to find that, it uses something generally called the ARP  table.
This  is  simply  a mapping from Internet address to Ethernet address.
Here's a typical ARP table.  (On our system, it is displayed using the
command "arp -a".)

    FOKKER.RUTGERS.EDU (128.6.5.16) at 8:0:20:0:8:22 temporary
    CROSBY.RUTGERS.EDU (128.6.5.48) at 2:60:8c:49:50:63 temporary
    CAIP.RUTGERS.EDU (128.6.4.16) at 8:0:8b:0:1:6f temporary
    DUDE.RUTGERS.EDU (128.6.20.16) at 2:7:1:0:eb:cd temporary
    W20NS.MIT.EDU (18.70.0.160) at 2:7:1:0:eb:cd temporary
    OBERON.USC.EDU (128.125.1.1) at 2:7:1:2:18:ee temporary
    gatech.edu (128.61.1.1) at 2:7:1:0:eb:cd temporary
    DARTAGNAN.RUTGERS.EDU (128.6.5.65) at 8:0:20:0:15:a9 temporary

Note  that  it  is  simply  a  list  of  Internet  addresses  and  the
corresponding Ethernet address.  The "temporary"  indicates  that  the
entry  was added dynamically using ARP, rather than being put into the
table manually.

If there is an entry for the address in the ARP table, the datagram is
simply  put  on  the Ethernet with the corresponding Ethernet address.
If not, an "ARP request" is broadcast, asking for the destination host
to  identify  itself.   This request is in effect a question "will the
host with Internet  address  128.6.4.194  please  tell  me  what  your
Ethernet address is?".  When a response comes back, it is added to the
ARP table, and future datagrams  for  that  destination  can  be  sent
without delay.

This  mechanism  was  originally  designed  only  for  use  with hosts
attached directly to a single Ethernet.  If you need to talk to a host
on  a different Ethernet, it was assumed that your routing table would
direct you to a gateway.    The  gateway  would  of  course  have  one
interface  on  your Ethernet.  Your computer would then end up looking
up the address of that gateway using  ARP.    It  would  generally  be
useless  to  expect  ARP to work directly with a computer on a distant
network.  Since it isn't on the same  Ethernet,  there's  no  Ethernet
address you can use to send datagrams to it.  And when you send an ARP
request for it, there's nobody to answer the request.

Proxy ARP is based on the  concept  that  the  gateways  will  act  as
proxies  for  distant  hosts.    Suppose  you  have  a host on network
128.6.5, with address 128.6.5.2.  (computer A  in  diagram  below)  It
wants  to send a datagram to host 128.6.4.194, which is on a different
Ethernet (subnet 128.6.4). (computer C in diagram below)  There  is  a
gateway  connecting  the  two subnets, with address 128.6.5.1 (gateway
R):



                                  18
 


              network 1               network 2
               128.6.5                 128.6.4
        ============================  ==================
          |              |        |    |      |    |
       ___|______   _____|____  __|____|__  __|____|____
       128.6.5.2    128.6.5.3   128.6.5.1   128.6.4.194
                                128.6.4.1
       __________   __________  __________  ____________
       computer A   computer B   gateway R   computer C


Now suppose computer A sends an ARP request for computer  C.  C  isn't
able  to  answer  for  itself.  It's on a different network, and never
even sees the ARP request.  However gateway R can act on  its  behalf.
In  effect,  your  computer  asks "will the host with Internet address
128.6.4.194 please tell me what your Ethernet address  is?",  and  the
gateway   says  "here  I  am,  128.6.4.194  is  2:7:1:0:eb:cd",  where
2:7:1:0:eb:cd is actually the Ethernet address of the gateway.    This
bit  of  illusion  works  just  fine.    Your  host  now  thinks  that
128.6.4.194  is  attached  to  the   local   Ethernet   with   address
2:7:1:0:eb:cd.    Of  course it isn't.  But it works anyway.  Whenever
there's a datagram to be sent to 128.6.4.194, your host  sends  it  to
the specified Ethernet address.  Since that's the address of a gateway
R, the  gateway  gets  the  packet.    It  then  forwards  it  to  the
destination.

Note that the net effect is exactly the same as having an entry in the
routing table saying  to  route  destination  128.6.4.194  to  gateway
128.6.5.1:

    128.6.4.194          128.6.5.1           UGH          pe0

except  that  instead  of  having the routing done at the level of the
routing table, it is done at the level of the ARP table.

Generally it's better to use the routing  table.    That's  what  it's
there for.  However here are some cases where proxy ARP makes sense:

   - when you have a host that does not implement subnets

   - when you have a host that does not respond properly to redirects

   - when you do not want to have to choose a specific default gateway

   - when your software is unable to recover from a failed route

The  technique  was first designed to handle hosts that do not support
subnets.  Suppose that you have a subnetted network.  For example, you
have  chosen  to break network 128.6 into subnets, so that 128.6.4 and
128.6.5 are separate.  Suppose you  have  a  computer  that  does  not
understand  subnets.    It  will  assume that all of 128.6 is a single
network.  Thus it will be difficult to establish routing table entries
to  handle  the  configuration  above.    You  can't tell it about the
gateway explicitly using "route add 128.6.4.0 128.6.5.1  1"  Since  it
thinks  all of 128.6 is a single network, it can't understand that you
                                  19
 


are trying to tell it where to send  one  subnet.    It  will  instead
interpret  this command as an attempt to set up a host route to a host
who address is 128.6.4.0.  The only thing that would work would be  to
establish  explicit  host  routes  for  every individual host on every
other subnet.  You can't depend upon default gateways and redirects in
this  situation either.  Suppose you said "route add default 128.6.5.1
1".  This would establish the gateway 128.6.5.1 as a default.  However
the  system wouldn't use it to send packets to other subnets.  Suppose
the host is 128.6.5.2, and wants to send a  datagram  to  128.6.4.194.
Since  the destination is part of 128.6, your computer considers it to
be on the same network as itself, and doesn't bother  to  look  for  a
gateway.

Proxy  ARP  solves  this  problem by making the world look the way the
defective implementation expects it to look.  Since  the  host  thinks
all  other  subnets  are part of its own network, it will simply issue
ARP requests for them.  It expects to get  back  an  Ethernet  address
that  can  be used to establish direct communications.  If the gateway
is practicing proxy ARP, it will respond with the  gateway's  Ethernet
address.    Thus  datagrams  are  sent  to the gateway, and everything
works.

As you can see, no specific configuration is need  to  use  proxy  ARP
with a host that doesn't understand subnets.  All you need is for your
gateways to implement proxy ARP.    In  order  to  use  it  for  other
purposes, you must explicitly set up the routing table to cause ARP to
be used.  By default, TCP/IP implementations will  expect  to  find  a
gateway  for any destination that is on a different network.  In order
to make them issue ARP's, you must explicitly  install  a  route  with
metric 0, as in the example "route add default 128.6.5.2 0".

It  is  obvious  that  proxy ARP is reasonable in situations where you
have hosts that don't understand subnets.  Some comments may be needed
on  the  other situations.  Generally TCP/IP implementations do handle
ICMP redirects properly.  Thus it is normally practical to  set  up  a
default  route  to  some gateway, and depend upon the gateway to issue
redirects for  destinations  that  should  use  a  different  gateway.
However in case you ever run into an implementation that does not obey
redirects, or cannot be configured to have a default gateway, you  may
be  able  to  make things work by depending upon proxy ARP.  Of course
this requires that you be able to configure the host  to  issue  ARP's
for  all  destinations.    You  will  need  to  read the documentation
carefully to see exactly what  routing  features  your  implementation
has.

Sometimes  you  may  choose  to depend upon proxy ARP for convenience.
The problem with routing tables is that you have  to  configure  them.
The simplest configuration is simply to establish a default route, but
even there you have to supply some  equivalent  to  the  Unix  command
"route  add  default  ...".    Should you change the addresses of your
gateways, you have to modify this command on all  of  your  hosts,  so
that  they  point to the new default gateway.  If you set up a default
route that depends upon proxy ARP (i.e. has metric 0), you won't  have
to  change  your configuration files when gateways change.  With proxy
ARP, no gateway addresses are  given  explicitly.    Any  gateway  can
                                  20
 


respond to the ARP request, no matter what its address.

In  order  to  save  you  from having to do configuration, some TCP/IP
implementations default to using ARP when they have  no  other  route.
The  most  flexible implementations allow you to mix strategies.  That
is, if you have specified a route  for  a  particular  network,  or  a
default route, they will use that route.  But if there is no route for
a destination, they will treat it as local, and issue an ARP  request.
As  long as your gateways support proxy ARP, this allows such hosts to
reach any destination without any need for routing tables.

Finally, you may choose to use proxy ARP because  it  provides  better
recovery  from  failure.  This choice is very much dependent upon your
implementation.  The next section will discuss the tradeoffs  in  more
detail.

In  situations  where  there  are  several  gateways  attached to your
network, you may wonder how proxy ARP allows you to  choose  the  best
one.    As  described  above,  your  computer simply sends a broadcast
asking for the Ethernet address for a destination.   We  assumed  that
the  gateways  would be set up to respond to this broadcast.  If there
is more than one  gateway,  this  requires  coordination  among  them.
Ideally,  the  gateways  will  have  a complete picture of the network
topology.  Thus they are able to determine the best  route  from  your
host  to any destination.  If the gateway coordinate among themselves,
it should be possible for the best gateway  to  respond  to  your  ARP
request.    In  practice,  it  may  not always be possible for this to
happen.  It is fairly easy to design algorithms to  prevent  very  bad
routes.  For example, consider the following situation:

          1             2            3
        -------  A  ----------  B ----------

1,  2, and 3 are networks.  A and B are gateways, connecting network 2
to 1 or 3.  If a host on network 2 wants to talk to a host on  network
1,  it  is  fairly  easy  for  gateway  A to decide to answer, and for
gateway B to decide not to.  Here's  how:  if  gateway  B  accepted  a
datagram  for  network 1, it would have to forward it to gateway A for
delivery.  This would mean that it would take a packet from network  2
and  send it right back out on network 2.  It is very easy to test for
routes that involve this sort of circularity.  It is  much  harder  to
deal with a situation such as the following:

                         1
                  ---------------
                    A        B
                    |        | 4
                    |        |
                  3 |        C
                    |        |
                    |        | 5
                    D        E
                  ---------------
                         2

                                  21
 


Suppose  a  computer  on  network 1 wants to send a datagram to one on
network 2.  The route via A and D is probably better, because it  goes
through  only one intermediate network (3).  It is also possible to go
via B, C, and E, but that path  is  probably  slightly  slower.    Now
suppose  the  computer  on  network  1  sends  an  ARP  request  for a
destination on 2.  It is likely that A and B will both respond to that
request.    B  is not quite as good a route as A. However it is not so
bad as the case above.  B won't have to send the datagram  right  back
out  onto  network  1.    It  is unable to determine there is a better
alternative  route  without  doing  a  significant  amount  of  global
analysis  on  the network.  This may not be practical in the amount of
time available to process an ARP request.



4.4.3 Moving to New Routes After Failures


In principle, TCP/IP routing is capable of handling line failures  and
gateway  crashes.    There  are  various  mechanisms to adjust routing
tables and ARP tables to keep them up to date.    Unfortunately,  many
major  implementations  of  TCP/IP  have  not implemented all of these
mechanisms.  The net result is that you have to look carefully at  the
documentation  for  your  implementation,  and  consider what kinds of
failures are most likely.  You then have to  choose  a  strategy  that
will  work  best  for your site.  The basic choices for finding routes
have all been listed above:  spying on the gateways' routing protocol,
setting  up  a  default  route and depending upon redirects, and using
proxy ARP.  These methods all have their own  limitations  in  dealing
with a changing network.

Spying on the gateways' routing protocol is theoretically the cleanest
solution.  Assuming that the gateways use good routing technology, the
tables  that  they  broadcast  contain  enough information to maintain
optimal routes to all destinations.  Should something in  the  network
change  (a  line  or  a  gateway  goes down), this information will be
reflected in the tables, and the routing  software  will  be  able  to
update the hosts' routing tables appropriately.  The disadvantages are
entirely practical.  However in some situations the robustness of this
approach may outweight the disadvantages.  To summarize the discussion
above, the disadvantages are:

   - If  the  gateways  are  using  sophisticated  routing  protocols,
     configuration may be fairly complex.  Thus you will be faced with
     setting up and maintaining configuration files on every host.

   - Some gateways use proprietary routing protocols.  In  this  case,
     you  may  not  be  able  to  find  software  for  your hosts that
     understands them.

   - If your hosts are diskless, there can be very serious performance
     problems associated with listening to routing broadcasts.

Some  gateways  may  be  able  to  convert from their internal routing
protocol to a simpler one for use by your hosts.  This  could  largely
                                  22
 


bypass  the  first two disadvantages.  Currently there is no known way
to get around the third one.

The problems with default routes/redirects  and  with  proxy  ARP  are
similar:  they  both  have trouble dealing with situations where their
table entries no longer apply.   The  only  real  difference  is  that
different  tables  are involved.  Suppose a gateway goes down.  If any
of your current routes are using that gateway, you may be in  trouble.
If  you  are depending upon the routing table, the major mechanism for
adjusting routes is the redirect.  This works fine in two  situations:

   - where  the  default  gateway  is not the best route.  The default
     gateway can direct you to a better gateway

   - where a distant line or gateway fails.  If this changes the  best
     route,  the  current gateway can redirect you to the gateway that
     is now best

The case it does not protect you against is where the gateway that you
are currently sending your datagrams to crashes.  Since it is down, it
is unable to redirect you to another gateway.  In many cases, you  are
also  unprotected  if  your  default  gateway  goes  down, since there
routing starts by sending to the default gateway.

The situation with proxy ARP is similar.  If the  gateways  coordinate
themselves  properly,  the  right  one  will  respond  initially.   If
something elsewhere in  the  network  changes,  the  gateway  you  are
currently  issuing  can  issue  a  redirect  to  a new gateway that is
better.  (It is usually possible to use redirects to  override  routes
established  by  proxy  ARP.)    Again, the case you are not protected
against is where the gateway you are currently using crashes.    There
is  no  equivalent  to failure of a default gateway, since any gateway
can respond to the ARP request.

So the big problem is that failure of a gateway you are using is  hard
to  recover  from.   It's hard because the main mechanism for changing
routes is the redirect,  and  a  gateway  that  is  down  can't  issue
redirects.    Ideally,  this  problem should be handled by your TCP/IP
implementation, using timeouts.  If a computer stops getting response,
it  should  cancel the existing route, and try to establish a new one.
Where you are using a  default  route,  this  means  that  the  TCP/IP
implementation  must  be  able  to  declare a route as down based on a
timeout.  If you have been redirected to a  non-default  gateway,  and
that  route is declared down, traffic will return to the default.  The
default gateway can then begin handling the traffic, or redirect it to
a  different  gateway.    To  handle  failure of a default gateway, it
should be possible to have more than one default.  If one is  declared
down,  another  will  be used.  Together, these mechanisms should take
care of any failure.

Similar mechanisms can be used by systems that depend upon proxy  ARP.
If a connection is timing out, the ARP table entry that it uses should
be cleared.  This will cause a new ARP request, which can  be  handled
by a gateway that is still up.  A simpler mechanism would simply be to
time out all ARP entries after some period.  Since making  a  new  ARP
                                  23
 


request  has  a very low overhead, there's no problem with removing an
ARP entry even if it is still good.  The next time a datagram is to be
sent,  a  new  request  will  be  made.  The response is normally fast
enough that users will not even notice the delay.

Unfortunately,  many  common  implementations   do   not   use   these
strategies.  In Berkeley 4.2, there is no automatic way of getting rid
of any kind of entry, either routing or ARP.  They do  not  invalidate
routes  on  timeout  nor  ARP  entries.  ARP entries last forever.  If
gateway crashes are a significant problem, there may be no choice  but
to  run  software  that  listens to the routing protocol.  In Berkeley
4.3, routing entries are removed when  TCP  connections  are  failing.
ARP  entries  are  still  not  removed.   This makes the default route
strategy more attractive for 4.3 than proxy ARP.  Having more than one
default  route  may  also allow for recovery from failure of a default
gateway.  Note however that 4.3 only handles timeout  for  connections
using TCP.  If a route is being used only by services based on UDP, it
will not recover from gateway failure.  While the "traditional" TCP/IP
services  use  TCP,  network  file  systems  generally  do  not.  Thus
4.3-based systems still  may  not  always  be  able  to  recover  from
failure.

In  general,  you  should  examine  your  implementation  in detail to
determine what sort of error recovery strategy it uses.  We hope  that
the  discussion in this section will then help you choose the best way
of dealing with routing.

There is one more strategy that some older implementations use.  It is
strongly  discouraged,  but we mention it here so you can recognize it
if you see it.  Some implementations detect gateway failure by  taking
active  measure to see what gateways are up.  The best version of this
is based on a list of all gateways that are currently in use.    (This
can  be  determined  from  the routing table.)  Every minute or so, an
echo request datagram is sent to each such  gateway.    If  a  gateway
stops responding to echo requests, it is declared down, and all routes
using it revert to the default.   With  such  an  implementation,  you
normally supply more than one default gateway.  If the current default
stops responding, an alternate is chosen.  In some cases,  it  is  not
even  necessary  to  choose an explicit default gateway.  The software
will  randomly  choose  any  gateway  that  is   responding.      This
implementation  is  very  flexible  and  recovers  well from failures.
However a large network full of such implementations will waste a  lot
of  bandwidth  on  the  echo  datagrams  that are used to test whether
gateways  are  up.    This  is  the  reason  that  this  strategy   is
discouraged.



5. Bridges and Gateways


This  section  will  deal  in  more detail with the technology used to
construct larger networks.  It  will  focus  particularly  on  how  to
connect  together  multiple  Ethernets,  token rings, etc.  These days
most networks are hierarchical.  Individual hosts attach to local-area
                                  24
 


networks  such  as  Ethernet or token ring.  Then those local networks
are connected via some combination of backbone networks and  point  to
point  links.    A  university might have a network that looks in part
like this:

     ________________________________
     |   net 1      net 2    net 3  |        net 4            net 5
     | ---------X---------X-------- |      --------         --------
     |                         |    |         |                 |
     |  Building A             |    |         |                 |
     |               ----------X--------------X-----------------X
     |                              |  campus backbone network  :
     |______________________________|                           :
                                                         serial :
                                                           line :
                                                         -------X-----
                                                             net  6

Nets 1, 2 and 3 are in one building.  Nets 4 and 5  are  in  different
buildings  on  the  same  campus.  Net 6 is in a somewhat more distant
location.  The diagram above shows nets 1, 2, and  3  being  connected
directly,  with switches that handle the connections being labelled as
"X".  Building A is connected to  the  other  buildings  on  the  same
campus  by  a backbone network.  Note that traffic from net 1 to net 5
takes the following path:

   - from 1 to 2 via the direct connection between those networks

   - from 2 to 3 via another direct connection

   - from 3 to the backbone network

   - across the backbone network from building A to  the  building  in
     which net 5 is housed

   - from the backbone network to net 5

Traffic  for  net  6 would additionally pass over a serial line.  With
the setup as shown, the same switch  is  being  used  to  connect  the
backbone  network  to net 5 and to the serial line.  Thus traffic from
net 5 to net 6 would not need to go through the backbone, since  there
is a direct connection from net 5 to the serial line.

This section is largely about what goes in those "X"'s.



5.1 Alternative Designs


Note  that  there  are alternatives to the sort of design shown above.
One is to use point to point lines or switched lines directly to  each
host.   Another is to use a single-level of network technology that is
capable of handling both local and long-haul networking.

                                  25
 


5.1.1 A mesh of point to point lines


Rather than connecting hosts to a local network such as Ethernet,  and
then   interconnecting  the  Ethernets,  it  is  possible  to  connect
long-haul serial lines directly to the individual computers.  If  your
network   consists   primarily  of  individual  computers  at  distant
locations, this might make sense.  Here would be  a  small  design  of
that type.

          computer 1                computer 2             computer 3
              |                         |                      |
              |                         |                      |
              |                         |                      |
          computer 4 -------------- computer 5 ----------- computer 6

In  the design shown earlier, the task of routing datagrams around the
network is handled by special-purpose switching units shown as  "X"'s.
If  you  run lines directly between pairs of hosts, your hosts will be
doing this sort of routing and switching,  as  well  as  their  normal
computing.    Unless  you  run  lines  directly  between every pair of
computers, some systems will end up handling traffic for  others.  For
example,  in this design, traffic from 1 to 3 will go through 4, 5 and
6.  This is certainly possible, since most TCP/IP implementations  are
capable of forwarding datagrams.  If your network is of this type, you
should think of your hosts as also acting as gateways.   Much  of  the
discussion  below  on  configuring  gateways will apply to the routing
software that you run on your hosts.  This sort  of  configuration  is
not as common as it used to be, for two reasons:

   - Most large networks have more than one computer per location.  In
     this case it is less expensive to set up a local network at  each
     location than to run point to point lines to each computer.

   - Special-purpose  switching  units have become less expensive.  It
     often makes sense to offload the routing and communications tasks
     to a switch rather than handling it on the hosts.

It is of course possible to have a network that mixes the two kinds of
techology.  In this case,  locations  with  more  equipment  would  be
handled  by  a hierarchical system, with local-area networks connected
by switches.  Remote locations with a single computer would be handled
by  point  to  point lines going directly to those computers.  In this
case the routing software used on the remote computers would  have  to
be  compatible  with that used by the switches, or there would need to
be a gateway between the two parts of the network.

Design decisions of this type are typically made after  an  assessment
of  the  level  of network traffic, the complexity of the network, the
quality of routing software available for the hosts, and  the  ability
of the hosts to handle extra network traffic.




                                  26
 


5.1.2 Circuit switching technology


Another  alternative  to  the hierarchical LAN/backbone approach is to
use circuit switches connected to each individual computer.   This  is
really  a  variant  of  the  point  to point line technique, where the
circuit switch allows each system to have what  amounts  to  a  direct
line to every other system.  This technology is not widely used within
the TCP/IP community, largely because the TCP/IP protocols assume that
the  lowest  level  handles  isolated  datagrams.    When a continuous
connection  is  needed,  higher  network  layers  maintain  it   using
datagrams.    This  datagram-oriented  technology  does  not  match  a
circuit-oriented environment very closely.  In order  to  use  circuit
switching  technology,  the IP software must be modified to be able to
build and tear down virtual circuits as appropriate.  When there is  a
datagram  for a given destination, a virtual circuit must be opened to
it.  The virtual circuit would  be  closed  when  there  has  been  no
traffic  to  that  destination  for  some time.  The major use of this
technology is for  the  DDN  (Defense  Data  Network).    The  primary
interface  to  the  DDN is based on X.25.  This network appears to the
outside as a distributed X.25 network.  TCP/IP software  intended  for
use with the DDN must do precisely the virtual circuit management just
described.     Similar   techniques   could   be   used   with   other
circuit-switching  technologies, e.g. ATT's DataKit, although there is
almost no software currently available to support this.



5.1.3 Single-level networks


In some cases new developments in wide-area networks can eliminate the
need  for hierarchical networks.  Early hierarchical networks were set
up because the only convenient  network  technology  was  Ethernet  or
other  LAN's, and those could not span distances large enough to cover
an entire campus.  Thus it  was  necessary  to  use  serial  lines  to
connect  LAN's  in  various  locations.    It  is now possible to find
network technology whose characteristics are similar to Ethernet,  but
where  a  single  network  can  span a campus.  Thus it is possible to
think of using a single large network, with no hierarchical structure.

The  primary  limitations  of  a  large   single-level   network   are
performance  and  reliability  considerations.  If a single network is
used  for  the  entire  campus,  it  is  very  easy  to  overload  it.
Hierarchical   networks  can  handle  a  larger  traffic  volume  than
single-level networks if traffic patterns have a reasonable amount  of
locality.  That is, in many applications, traffic within an individual
department tends to be greater than traffic among departments.

Let's look at a concrete example.  Suppose there are  10  departments,
each of which generate 1 Mbit/sec of traffic.  Suppose futher than 90%
of that traffic is to other systems within the  department,  and  only
10%  is to other departments.  If each department has its own network,
that network only needs to handle 1 Mbit/sec.   The  backbone  network
connecting  the  department also only needs 1 Mbit/sec capacity, since
                                  27
 


it is handling 10% of 1 Mbit from each department.  In order to handle
this  situation  with  a  single wide-area network, that network would
have  to  be  able  to  handle  the  simultaneous  load  from  all  10
departments, which would be 10 Mbit/sec.

The   second  limitation  on  single-level  networks  is  reliability,
maintainability and security.  Wide-area networks are  more  difficult
to  diagnose  and  maintain than local-area networks, because problems
can be introduced from any building to which the network is connected.
They  also  make traffic visible in all locations.  For these reasons,
it is often sensible to handle local  traffic  locally,  and  use  the
wide-area  network  only  for  traffic  that  actually must go between
buildings.  However if you have a situation where  each  location  has
only  one  or  two  computers, it may not make sense to set up a local
network at each location, and a single-level network may make sense.



5.1.4 Mixed designs


In practice,  few  large  networks  have  the  luxury  of  adopting  a
theoretically pure design.

It is very unlikely that any large network will be able to avoid using
a hierarchical design.  Suppose we  set  out  to  use  a  single-level
network.  Even if most buildings have only one or two computers, there
will be some location where there are enough that a local-area network
is justified.  The result is a mixture of a single-level network and a
hierachical network.  Most buildings have  their  computers  connected
directly  to  the  wide-area  network, as with a single-level network.
However in one building there is a local-area network which  uses  the
wide-area  network  as  a  backbone,  connecting to it via a switching
unit.

On the other side of the story, even network designers with  a  strong
commitment  to  hierarchical networks are likely to find some parts of
the network where it simply doesn't make economic sense to  install  a
local-area  network.    So  a  host  is put directly onto the backbone
network, or tied directly to a serial line.

However you should think carefully before  making  ad  hoc  departures
from  your  design  philosophy in order to save a few dollars.  In the
long run, network maintainability is going to depend upon your ability
to make sense of what is going on in the network.  The more consistent
your technology is, the more likely you are to be able to maintain the
network.








                                  28
 


5.2 An introduction to alternative switching technologies


This  section will discuss the characteristics of various technologies
used to switch datagrams between networks.  In effect, we  are  trying
to  fill  in  some  details  about the black boxes assumed in previous
sections.  There are three basic types of switches, generally referred
to as repeaters, bridges, and gateways, or alternatively as level 1, 2
and 3 switches (based on the level of the  ISO  model  at  which  they
operate).    Note however that there are systems that combine features
of more than one of these, particularly bridges and gateways.

The most important dimensions on which switches  vary  are  isolation,
performance, routing and network management facilities.  These will be
discussed below.

The most serious difference is between repeaters  and  the  other  two
types  of  switch.    Until recently, gateways provided very different
services from bridges.  However these two technologies are now  coming
closer  together.  Gateways are beginning to adopt the special-purpose
hardware that has characterized bridges in  the  past.    Bridges  are
beginning to adopt more sophisticated routing, isolation features, and
network management, which have characterized  gateways  in  the  past.
There  are  also systems that can function as both bridge and gateway.
This means that at the moment, the crucial  decision  may  not  be  to
decide  whether  to  use  a  bridge  or  a gateway, but to decide what
features you want in a switch  and  how  it  fits  into  your  overall
network design.



5.2.1 Repeaters


A repeater is a piece of equipment that connects two networks that use
the same technology.  It receives every data packet on  each  network,
and retransmits it onto the other network.  The net result is that the
two networks have exactly the same  set  of  packets  on  them.    For
Ethernet or IEEE 802.3 networks there are actually two different kinds
of repeater.  (Other network technologies may not need  to  make  this
distinction.)

A  simple  repeater  operates at a very low level indeed.  Its primary
purpose is to get around limitations in cable length caused by  signal
loss or timing dispersion.  It allows you to construct somewhat larger
networks than you would otherwise be able to construct.    It  can  be
thought  of  as  simply  a two-way amplifier.  It passes on individual
bits in the signal, without doing any processing at the packet  level.
It even passes on collisions.  That is, if a collision is generated on
one of  the  networks  connected  to  it,  the  repeater  generates  a
collision  on  the  other  network.  There is a limit to the number of
repeaters that you can use in a network.  The  basic  Ethernet  design
requires  that signals must be able to get from one end of the network
to the other within a specified amount of time.    This  determines  a
maximum  allowable length.  Putting repeaters in the path does not get
                                  29
 


around this limit.  (Indeed each repeater adds some delay, so in  some
ways  a repeater makes things worse.)  Thus the Ethernet configuration
rules limit the number of repeaters that can be in any path.

A "buffered repeater" operates at the level  of  whole  data  packets.
Rather  than passing on signals a bit at a time, it receives an entire
packet from one network into an internal buffer and  then  retransmits
it  onto  the other network.  It does not pass on collisions.  Because
such low-level features  as  collisions  are  not  repeated,  the  two
networks continue to be separate as far as the Ethernet specifications
are concerned.  Thus there  are  no  restrictions  on  the  number  of
buffered  repeaters  that can be used.  Indeed there is no requirement
that both of the networks be of  the  same  type.    However  the  two
networks  must  be sufficiently similar that they have the same packet
format.  Generally this means that  buffered  repeaters  can  be  used
between two networks of the IEEE 802.x family (assuming that they have
chosen the same address length), or two networks of some other related
family.    A  pair  of  buffered  repeaters can be used to connect two
networks via a serial line.

Buffered repeaters share with simple repeaters the most basic feature:
they  repeat every data packet that they receive from one network onto
the other.  Thus the two networks end up with exactly the same set  of
packets on them.



5.2.2 Bridges and gateways


A  bridge  differs from a buffered repeater primarily in the fact that
it exercizes some selectivity as to what packets it  forwards  between
networks.    Generally  the  goal  is  to increase the capacity of the
system by keeping local traffic confined to the network  on  which  it
originates.    Only  traffic  intended  for the other network (or some
other network accessed through it) goes through the bridge.    So  far
this  description would also apply to a gateway.  Bridges and gateways
differ in the way they determine what packets to forward.    A  bridge
uses  only  the  ISO level 2 address.  In the case of Ethernet or IEEE
802.x networks, this is the 6-byte Ethernet or MAC-level address. (The
term  MAC-level  address  is  more  general.   However for the sake of
concreteness, examples in this section will assume  that  Ethernet  is
being  used.    You  may generally replace the term "Ethernet address"
with the equivalent MAC-level address for other similar technologies.)
A bridge does not examine the packet itself, so it does not use the IP
address or its equivalent for  routing  decisions.    In  contrast,  a
gateway  bases  its decisions on the IP address, or its equivalent for
other protocols.

There are several reasons why it matters which kind of address is used
for  decisions.    The  most basic is that it affects the relationship
between the  switch  and  the  upper  layers  of  the  protocol.    If
forwarding is done at the level of the MAC-level address (bridge), the
switch will be invisible to the protocols.  If it is done  at  the  IP
level,  the  switch will be visible.  Let's give an example.  Here are
                                  30
 


two networks connected by a bridge:

              network 1          network 2
               128.6.5            128.6.4
        ==================  ================================
          |            |      |            |             |
       ___|______    __|______|__   _______|___   _______|___
       128.6.5.2        bridge       128.6.4.3     128.6.4.4
       __________    ____________   ___________   ___________
       computer A                   computer B    computer C


Note that the bridge does not have an IP address.  As far as computers
A,  B,  and  C  are  concerned,  there  is a single Ethernet (or other
network) to which they are all attached.  This means that the  routing
tables  must  be  set up so that computers on both networks treat both
networks as local.  When computer A opens a connection to computer  B,
it  first  broadcasts  an ARP request asking for computer B's Ethernet
address.  The bridge must  pass  this  broadcast  from  network  1  to
network  2.  (In general, bridges must pass all broadcasts.)  Once the
two computers know each other's Ethernet addresses, communications use
the  Ethernet  address  as the destination.  At that point, the bridge
can start exerting some selectivity.  It will only pass packets  whose
Ethernet  destination  address  is for a machine on the other network.
Thus a packet from B to A will be passed from network 2 to  1,  but  a
packet from B to C will be ignored.

In  order  to  make  this  selection,  the  bridge needs to know which
network each machine is on.  Most modern bridges build up a table  for
each  network,  listing the Ethernet addresses of machines known to be
on that network.  They do this by watching all of the packets on  both
networks.   When a packet first appears on network 1, it is reasonable
to conclude that the Ethernet source address corresponds to a  machine
on network 1.

Note  that a bridge must look at every packet on the Ethernet, for two
different reasons.  First, it may use  the  source  address  to  learn
which  machines  are  on  which  network.  Second, it must look at the
destination address in order to decide whether it needs to forward the
packet to the other network.

As  mentioned  above,  generally bridges must pass broadcasts from one
network to the other.  Broadcasts are often used to locate a resource.
The ARP request is a typical example of this.  Since the bridge has no
way of knowing what host is going to answer  the  broadcast,  it  must
pass   it   on  to  the  other  network.    Some  newer  bridges  have
user-selectable filters.  With them, it  is  possible  to  block  some
broadcasts  and  allow  others.  You might allow ARP broadcasts (which
are  essential  for  IP  to  function),  but  confine  less  essential
broadcasts  to one network.  For example, you might choose not to pass
rwhod broadcasts, which some systems use to keep track of  every  user
logged  into  every  other  system.    You  might  decide  that  it is
sufficient for rwhod to know about the systems on a single segment  of
the network.

                                  31
 


Now let's take a look at two networks connected by a gateway

              network 1                   network 2
               128.6.5                     128.6.4
        ====================      ==================================
          |              |          |              |             |
       ___|______    ____|__________|____   _______|___   _______|___
       128.6.5.2     128.6.5.1  128.6.4.1    128.6.4.3     128.6.4.4
       __________    ____________________   ___________   ___________
       computer A           gateway           computer B    computer C


Note  that  the  gateway  has IP addresses assigned to each interface.
The  computers'  routing  tables  are  set  up  to   forward   through
appropriate  address.    For  example,  computer A has a routing entry
saying that it should use the  gateway  128.6.5.1  to  get  to  subnet
128.6.4.

Because  the  computers  know  about the gateway, the gateway does not
need to scan all the packets on the Ethernet.  The computers will send
packets to it when appropriate.  For example, suppose computer A needs
to send a message to computer B. Its routing table will tell it to use
gateway  128.6.5.1.    It  will issue an ARP request for that address.
The gateway will respond to the ARP request, just as any  host  would.
From then on, packets destinated for B will be sent with the gateway's
Ethernet address.



5.2.3 More about bridges


There are several advantages to using  the  Mac-level  address,  as  a
bridge  does.   First, every packet on an Ethernet or IEEE network has
such an address.  The address is in the same place for  every  packet,
whether  it  is  IP,  DECnet,  or  some  other  protocol.   Thus it is
relatively fast to get the address from the packet.   A  gateway  must
decode  the  entire IP header, and if it is to support protocols other
than IP, it must have software for each such  protocol.    This  means
that  a bridge automatically supports every possible protocol, whereas
a gateway requires specific provisions for  each  protocol  it  is  to
support.

However  there  are  also disadvantages.  The one that is intrinsic to
the design of a bridge is

   - A bridge must look at every packet on the network, not just those
     addressed  to  it.    Thus it is possible to overload a bridge by
     putting it on a very busy network, even if very little traffic is
     actually going through the bridge.

However  there  are another set of disadvantages that are based on the
way bridges are usually built.  It is possible in principle to  design
bridges  that do not have these disadvantages, but I don't know of any
plans to do so.  They all stem from the fact that bridges do not  have
                                  32
 


a complete routing table that describes the entire system of networks.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 03:01:50 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Document: administering a TCP/IP based network


I am about to post to comp.protocols.tcp-ip a document describing how
to configure a TCP/IP-based network.  This is a companion paper to my
Introduction to the TCP/IP Protocols.  I intended a bit more material
on configuration of certain common servers, and dealing with common
types of problems, but it seems worth putting the material in this
document out for comments.

The posting is in three parts, so that none of them goes over the
64Kbyte limit that seems to afflict some of the paths used by the news
system.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 03:02:35 GMT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   intro to tcp admin, part 3 of 3


They simply have a list of the Ethernet addresses that lie on each  of
its two networks. This means

   - A  bridge  can  handle only two network interfaces.  At a central
     site, where many networks converge, this normally means that  you
     set  up  a backbone network to which all the bridges connect, and
     then buy a separate bridge to connect each other network to  that
     backbone.  Gateways often have between 4 and 8 interfaces.

   - Networks  that  use  bridges cannot have loops in them.  If there
     were a loop,  some  bridges  would  see  traffic  from  the  same
     Ethernet address coming from both directions, and would be unable
     to decide which table to put that address  in.    Note  that  any
     parallel  paths  to  the  same direction constitute a loop.  This
     means  that  multiple  paths  cannot  be  used  for  purposes  of
     splitting the load or providing redundancy.

There  are  some  ways  of  getting around the problem of loops.  Many
bridges allow configurations with redundant connections, but turn  off
links  until  there are no loops left.  Should a link fail, one of the
disabled ones is then brought back into service.  Thus redundant links
can  still  buy  you  extra  reliability.    But they can't be used to
provide extra capacity.  It is also possible to build  a  bridge  that
will  make  use  of  parallel point to point lines, in the one special
case where those lines go between a  single  pair  of  bridges.    The
bridges  would  treat  the two lines as a single virtual line, and use
them alternately in round-robin fashion.

The process of disabling redundant  connections  until  there  are  no
loops  left  is  called  a "spanning tree algorithm".  This name comes
from the fact that a tree is defined as a pattern of connections  with
no loops.  Thus one wants to disable connections until the connections
that are left form a tree that "spans" (includes) all of the  networks
in  the  system.  In order to do this, all of the bridges in a network
system must communicate among themselves.  There is an  IEEE  proposal
to  standardize  the protocol for doing this, and for constructing the
spanning tree.

Note that there is a tendency  for  the  resulting  spanning  tree  to
result  in  high  network  loads  on certain parts of the system.  The
networks near the "top of the tree" handle all traffic between distant
parts  of  the  network.  In a network that uses gateways, it would be
possible to put in an extra link between parts  of  the  network  that
have  heavy  traffic between them.  However such extra links cannot be
used by a set of bridges.









                                  33
 


5.2.4 More about gateways


Gateways have their own advantages and disadvantages.   In  general  a
gateway  is more complex to design and to administer than a bridge.  A
gateway must participate in all of the protocols that it  is  designed
to  forward.  For example, an IP gateway must respond to ARP requests.
The IP standards also require it to completely process the IP  header,
decrementing the time to live field and obeying any IP options.

Gateways  are  designed to handle more complex network topologies than
bridges.  As such, they have a different (and  more  complex)  set  of
decisions  to make.  In general a bridge has only a binary decision to
make: does it or does it not pass a given packet from one  network  to
the  other?    However  a gateway may have several network interfaces.
Furthermore, when it forwards a packet, it must decide  what  host  or
gateway to send the packet to next.  It is even possible for a gateway
to decide to send a packet back onto the same network  it  came  from.
If  a  host  is  using the gateway as its default, it may send packets
that really should go to some  other  gateway.    In  that  case,  the
gateway will send the packet on to the right gateway, and send back an
ICMP redirect to the host.  Many gateways  can  also  handle  parallel
paths.   If there are several equally good paths to a destination, the
gateway will alternate among them in round-robin fashion.

In order to handle these decisions, a gateway will  typically  have  a
routing  table  that  looks  very  much  like  a host's.  As with host
routing tables, a gateway's table contains an entry for each  possible
network  number.    For  each network, there is either an entry saying
that that network is connected directly to the gateway, or there is an
entry saying that traffic for that network should be forwarded through
some other gateway  or  gateways.    We  will  describe  the  "routing
protocols"  used to build up this information later, in the discussion
on how to configure a gateway.



5.3 Comparing the switching technologies


Repeaters, buffered repeaters, bridges, and gateways form a  spectrum.
Those  devices  near  the  beginning  of the list are best for smaller
networks.  They are less expensive, and easier to  set  up,  but  less
general.    Those  near  the end of the list are suitable for building
more complex networks.  Many networks will contain a mixture of switch
types,  with  repeaters  being  used  to  connect a few nearby network
segments, bridges used for slightly larger areas  (particularly  those
with low traffic levels), and gateways used for long-distance links.

Note  that  this  document  so  far has assumed that only gateways are
being used.  The section on setting up a host described how to set  up
a  routing  table  listing  the  gateways  to  use  to  get to various
networks.  Repeaters and bridges are invisible to IP.  So  as  far  as
previous  sections are concerned, networks connected by them are to be
considered a single network.  Section 3.3.1 describes how to configure
                                  34
 


a  host  in  the  case  where  several subnets are carried on a single
physical network.  The same configuration should be used when  several
subnets are connected by repeaters or bridges.

As  mentioned  above,  the most important dimensions on which switches
vary are isolation,  performance,  routing,  network  management,  and
performing auxilliary support services.



5.3.1 Isolation


Generally  people  use switches to connect networks to each other.  So
they are normally thinking  of  gaining  connectivity,  not  providing
isolation.  However isolation is worth thinking about.  If you connect
two networks and  provide  no  isolation  at  all,  then  any  network
problems  on  other  networks suddenly appear on yours as well.  Also,
the two networks together may have enough traffic  to  overwhelm  your
network.  Thus it is well to think of choosing an appropriate level of
protection.

Isolation comes in  two  kinds:  isolation  against  malfunctions  and
traffic  isolation.  In order to discuss isolation of malfunctions, we
have to have a taxonomy of malfunctions.  Here are the  major  classes
of malfunctions, and which switches can isolate them:

   - Electrical  faults,  e.g.    a short in the cable or some sort of
     fault that distorts the signal.  All types of switch will confine
     this  to  one  side  of  the switch: repeater, buffered repeater,
     bridge, gateway.  These are worth  protecting  against,  although
     their frequency depends upon how often your cables are changed or
     disturbed.  It is rare for this sort of fault  to  occur  without
     some disturbance of the cable.

   - Transceiver and controller problems that general signals that are
     valid electrically but nevertheless incorrect (e.g. a continuous,
     infinitely  long  packet,  spurious  collisions,  never  dropping
     carrier).  All except the  simple  repeater  will  confine  this:
     buffered  repeater, bridge, gateway.  (Such problems are not very
     common.)

   - Software malfunctions that  lead  to  excessive  traffic  between
     particular  hosts  (i.e.  not  broadcasts).  Bridges and gateways
     will isolate these.  (This type of failure is fairly rare.   Most
     software and protocol problems generate broadcasts.)

   - Software  malfunctions  that lead to excessive broadcast traffic.
     Gateways will isolate these.  Generally bridges will not, because
     they  must pass broadcasts.  Bridges with user-settable filtering
     can protect against some  broadcast  malfunctions.    However  in
     general  bridges  must  pass ARP, and most broadcast malfunctions
     involve ARP.    This  problem  is  not  severe  on  single-vendor
     networks  where  software  is  under  careful  control.   However
     research sites generally see problems of this sort regularly.
                                  35
 


Traffic isolation is provided by bridges and gateways.  The most basic
decision  is  how  many  computers  can  be put onto a network without
overloading its capacity.  This requires knowledge of the capacity  of
the  network,  but  also  how  the hosts will use it.  For example, an
Ethernet may support hundreds of systems if all the  network  is  used
for  is remote logins and an occasional file transfer.  However if the
computers are diskless, and use the network for swapping, an  Ethernet
will  support  between  10 and 40, depending upon their speeds and I/O
rates.

When you have to put more computers onto a network than it can handle,
you split it into several networks and put some sort of switch between
them.  If you do the split correctly, most  of  the  traffic  will  be
between machines on the same piece.  This means putting clients on the
same network as their servers, putting terminal servers  on  the  same
network as the hosts that they access most commonly, etc.

Bridges  and  gateways  generally  provide  similar degrees of traffic
isolation.  In both cases, only traffic bound for hosts on  the  other
side of the switch is passed.  However see the discussion on routing.



5.3.2 Performance


This  is  becoming  less  of  an  issue  as  time  goes  on, since the
technology is improving.  Generally  repeaters  can  handle  the  full
bandwidth  of  the  network.  (By their very nature, a simple repeater
must be able to do so.) Bridges and gateways  often  have  performance
limitations  of  various sorts.  Bridges have two numbers of interest:
packet scanning rate and throughput.  As  explained  above,  a  bridge
must  look  at every packet on the network, even ones that it does not
forward.  The number of packets per second that it can  scan  in  this
way  is  the packet scanning rate.  Throughput applies to both bridges
and gateways.  This is the rate at which  they  can  forward  traffic.
Generally  this  depends  upon  packet  size.   Normally the number of
packets per second that a unit can handle will be  greater  for  short
packets  than  long  ones.    Early models of bridge varied from a few
hundred packets per second to around 7000.  The higher speeds are  for
equipment  that  uses special-purpose hardware to speed up the process
of scanning packets.  First-generation  gateways  varied  from  a  few
hundred packets per second to 1000 or more.  However second-generation
gateways are now available, using special-purpose hardware of the same
sophistication  as that used by bridges.  They can handle on the order
of 10000 packets per second.   Thus  at  the  moment  high-performance
bridges  and gateways can switch most of the bandwidth of an Ethernet.
This means that performance should no longer be a basis  for  choosing
between types of switch.  However within a given type of switch, there
are still specific models with higher or lower capacity.

Unfortunately there  is  no  single  number  on  which  you  can  base
performance estimates.  The figure most commonly quoted is packets per
second.  Be aware that most vendors count a packet  only  once  as  it
goes  through  a gateway, but that one prominent vendor counts packets
                                  36
 


twice.  Thus their switching rates must be deflated by a factor of  2.
Also,  when  comparing  numbers make sure that they are for packets of
the same size.  A simple performance model is

    processing time = switching time + packet size * time per byte

That is, the time to switch a packet is normally a constant  switching
time, representing interrupt latency, header processing, routing table
lookup,  etc.,  plus  a  component  proportional   to   packet   size,
representing the time needed to do any packet copying.  One reasonable
approach to reporting performance is to give packets  per  second  for
minimum  and  maximum  size  packets.    Another is to report limiting
switching speed in packets per second  and  throughput  in  bytes  per
second, i.e.  the two terms of the equation above.



5.3.3 Routing


Routing refers to the technology used to decide where to send a packet
next.  Of course for a repeater this is not an issue, since  repeaters
forward every packet.

Bridges  are  almost  always  constructed with exactly two interfaces.
Thus routing turns into two decisions: (1) whether the  bridge  should
function  at  all,  and  (2)  whether it should forward any particular
packet.  The second decision is usually based on a table of  MAC-level
addresses.    As described above, this is built up by scanning traffic
on both sides of the bridge.  The goal is  to  forward  those  packets
whose  destination is on the other side of the bridge.  This algorithm
requires that the network configuration have  no  loops  or  redundant
lines.    Less  sophisticated  bridges  leave  this  up  to the system
designer.  With these bridges, you must set up your  network  so  that
there  are no loops in it.  More sophisticated bridges allow arbitrary
topology, but disable links until no  loops  remain.    This  provides
extra  reliability.    If  a  link  fails, an alternative link will be
turned on automatically.  Bridges that work  this  way  have  protocol
that  allows them to detect when a unit must be disabled or reenabled,
so that at any instant the set  of  active  links  forms  a  "spanning
tree".   If you require the extra reliability of redundant links, make
sure that the bridges you use can disable  and  enable  themselves  in
this  way.    There is currently no official standard for the protocol
used among bridges, although there  is  a  standard  in  the  proposal
stage.    If you buy bridges from more than one vendor, make sure that
their spanning-tree protocols will interoperate.

Gateways generally allow arbitrary network topologies, including loops
and  redundant  links.    Because  gateways  may  have  more  than two
interfaces, they must decide not only when to forward  a  packet,  but
where  to  send  it  next.  They do this by maintaining a model of the
entire network topology.  Different routing techniques maintain models
of greater or lesser complexity, and use the data with varying degrees
of sophistication.   Gateways  that  handle  TCP/IP  should  generally
support  the  two  Internet  standard  routing protocols: RIP (Routing
                                  37
 


Information Protocol) and EGP (External Gateway Protocol).  EGP  is  a
special-purpose protocol for use in networks where there is a backbone
under a separate administration.  It allows exchange  of  reachability
information  with  the  backbone  in  a  controlled way.  If you are a
member of such a network, your gateway must  support  EGP.    This  is
becoming  common  enough  that it is probably a good idea to make sure
that all gateways support EGP.

RIP is a protocol designed to handle routing within small to  moderate
size networks, where line speeds do not differ radically.  Its primary
limitations are:

   - It cannot be used with networks where any path goes through  more
     than  15  gateways.  This range may be further reduced if you use
     an optional feature for giving a slow line a weight  larger  than
     one.

   - It  cannot  share  traffic  between parallel lines (although some
     implementations allow this if the lines are between the same pair
     of gateways).

   - It cannot adapt to changes in network load.

   - It  is  not well suited to situations where there are alternative
     routes through lines of very different speeds.

   - It may not be stable in networks where lines or gateways change a
     lot.

Some  vendors supply proprietary modifications to RIP that improve its
operation with EGP or increase the maximum path length beyond 15,  but
do  not  otherwise modify it very much.  If you expect your network to
involve gateways from more  than  one  vendor,  you  should  generally
require  that  all of them support RIP, since this is the only routing
protocol that is generally available.  If you expect  to  use  a  more
sophisticated  protocol  in  addition,  the  gateways  must  have some
ability to translate between their own protocol and RIP.  However  for
very large or complex networks, there may be no choice but to use some
other protocol throughout.

More sophisticated routing protocols are possible.  The  primary  ones
being considered today are cisco System's IGRP, and protocols based on
the SPF (shortest-path first) algorithms.  In general these  protocols
are designed for larger or more complex networks.  They are in general
stable under a wider  variety  of  conditions,  and  they  can  handle
arbitrary combinations of line type and speed.  Some of them allow you
to  split  traffic  among  parallel  paths,  to  get  better   overall
throughput.    Some newer technologies may allow the network to adjust
to take into account paths that are overloaded.  However at the moment
I  do  not  know of any commercial gateway that does this.  (There are
very serious problems with maintaining stable  routing  when  this  is
done.) There are enough variations among routing technology, and it is
changing rapidly enough, that you should discuss your proposed network
topology  in  detail with all of the vendors that you are considering.
Make sure that their technology can  handle  your  topology,  and  can
                                  38
 


support  any  special  requirements  that you have for sharing traffic
among parallel lines, and for adjusting topology to take into  account
failures.    In  the  long  run,  we expect one or more of these newer
routing protocols to attain the status of a standard, at least on a de
facto basis.  However at the moment, there is no generally implemented
routing technology other than RIP.

One additional routing topic to consider is policy-based routing.   In
general routing protocols are designed to find the shortest or fastest
possible path for every packet.  In some cases, this is  not  desired.
For  reasons  of  security, cost accountability, etc., you may wish to
limit certain paths to certain uses.   Most  gateways  now  have  some
ability to control the spread of routing information so as to give you
some administrative control over the way routes are used.    Different
gateways  vary  in the degree of control that they support.  Make sure
that you discuss any requirements that you have for control  with  all
prospective gateway vendors.



5.3.4 Network management


Network  management  covers  a  wide variety of topics.  In general it
includes gathering statistical data and status information about parts
of  your network, and taking action as necessary to deal with failures
and other changes.  There are several things that a switch can  do  to
make this process easier.  The most basic is that it should have a way
of gathering and reporting statistics.  These should  include  various
sorts  of packet counts, as well as counts of errors of various kinds.
This data is likely to be  most  detailed  in  a  gateway,  since  the
gateway  classifies  packets using the protocols, and may even respond
to certain types of packet itself.  However bridges and even  buffered
repeaters  can  certainly  have counts of packets forwarded, interface
errors, etc.  It should be  possible  to  collect  this  data  from  a
central monitoring point.

There is now an official Internet approach to network monitoring.  The
first stages use a related set of protocols, SGMP and SNMP.   Both  of
these  protocols  are designed to allow you to collect information and
to make changes in configuration parameters  for  gateways  and  other
entities on your network.  You can run the matching interface programs
on any host in your network.    SGMP  is  now  available  for  several
commercial  gateways,  as  well as for Unix systems that are acting as
gateways.  There is a  limited  set  of  information  which  any  SGMP
implementation  is  required to supply, as well as a uniform mechanism
for vendors to add information of their own.  By late 1988, the second
generation  of  this  protocol, SNMP, should be in service.  This is a
slightly more sophisticated protocol.  It has with it a more  complete
set  of  information that can be monitored, called the MIB (Management
Information Base).  Unlike the somewhat  ad  hoc  collection  of  SGMP
variables,  the  MIB is the result of numerous committee deliberations
involving a number of vendors and users.  Eventually  it  is  expected
that  there  will  be  a  TCP/IP  equivalent  of CMIS, the ISO network
monitoring service.  However CMIS, and its protocols,  CMIP,  are  not
                                  39
 


yet  official  ISO  standards,  so  they are still in the experimental
stages.

In general terms all of these protocols  accomplish  the  same  thing:
They  allow you to collect criticial information in a uniform way from
all vendors' equipment.  You send commands as  UDP  datagrams  from  a
network  management  program  running  on  some  host in your network.
Generally the interaction is fairly simple,  with  a  single  pair  of
datagrams exchanged: a command and a response.  At the moment security
is fairly simple.  It  is  possible  to  require  what  amounts  to  a
password  in  the  command.   (In SGMP it is referred to as a "session
name", rather  than  a  password.)  More  elaborate,  encryption-based
security is being developed.

You  will  probably  want to configure the network management tools at
your disposal to do several different things.  For short-term  network
monitoring,  you will want to keep track of switches crashing or being
taken down for maintenance, and of failure of communications lines and
other  hardware.  It is possible to configurate SGMP and SNMP to issue
"traps" (unsolited messages) to a specified host or list of hosts when
some of these critical events occur (e.g. lines up and down).  However
it is unrealistic to expect a switch to notify you  when  it  crashes.
It  is  also  possible  for  trap  messages  to be lost due to network
failure or  overload.    Thus  you  should  also  poll  your  switches
regularly  to  gather  information.    Various displays are available,
including a map of your network where  items  change  color  as  their
status  changes, and running "strip charts" that show packet rates and
other items through selected switches.  This software is still in  its
early  stages,  so  you  should  expect  to  see a lot of change here.
However at the very least you should expect to be notified in some way
of  failures.    You  may  also  want  to  be  able to take actions to
reconfigure the system in  response  to  failures,  although  security
issues make some mangers nervous about doing that through the existing
management protocols.

The second type of monitoring you are likely  to  want  to  do  is  to
collect information for use in periodic reports on network utilization
and  performance.    For  this,  you  need  to  sample   each   switch
perodically,  and  retrieve numbers of interest.  At Rutgers we sample
hourly, and get the number of packets forwarded for IP and  DECnet,  a
count  of reloads, and various error counts.  These are reported daily
in some detail.  Monthly summaries are produced giving traffic through
each  gateway,  and a few key error rates chosen to indicate a gateway
that is being overloaded (packets dropped in input and output).

It should be possible to use monitoring techniques of this  kind  with
most  types  of switch.  At the moment, simple repeaters do not report
any statistics.  Since they do not generally have processors in  them,
doing  so  would  cause  a  major  increase in their cost.  However it
should be possible to do network management  for  buffered  repeaters,
bridges,  and  gateways.    Gateways  are  the  most likely to contain
sophisticated network management software.  Most gateway vendors  that
handle  TCP/IP  are  expected  to  implement  the monitoring protocols
described above.    Many  bridge  vendors  make  some  provisions  for
collecting performance data.  Since bridges are not protocol-specific,
                                  40
 


most  of  them  do  not  have  the  software  necessary  to  implement
TCP/IP-based  network management protocols.  In some cases, monitoring
can be done only by typing commands to  a  directly-attached  console.
(We have seen one case where it is necessary to take the bridge out of
service to gather this data.) In other cases, it is possible to gather
data  via  the  network, but the monitoring protocol is ad hoc or even
proprietary.

Except for very small networks, you should probably insist that all of
the devices on your network collect statistics and provide some way of
querying them remotely.  In the long run,  you  can  expect  the  most
software  to be available for standard protocols such as SGMP/SNMP and
CMIS.  However proprietary monitoring tools may be sufficient as  long
as they work with all of the equipment that you have.



5.3.5 A final evaluation


Here  is  a summary of the places where each kind of switch technology
is normally used:

   - Repeaters are normally confined to a single building.  Since they
     provide  no traffic isolation, you must make sure that the entire
     set of networks connected by repeaters can carry the traffic from
     all  of  the  computers  on  it.  Since they generally provide no
     network monitoring tools, you will not want to use repeaters  for
     a link that is likely to fail.

   - Bridges  and gateways should be placed sufficiently frequently to
     break your network into pieces for which the  traffic  volume  is
     manageable.   You may want to place bridges or gateways in places
     where traffic would  not  require  them  for  network  monitoring
     reasons.

   - Because  bridges must pass broadcast packets, there is a limit to
     the size network you can construct using them.  It is probably  a
     good  idea to limit the network connected by bridges to a hundred
     systems or so.  This number can be increased somewhat for bridges
     with good facilities for filtering.

   - Because  certain  kinds  of  network  misbehavior will be passed,
     bridges should be used only among portions of the network where a
     single group is responsible for diagnosing problems.  You have to
     be crazy to use a bridge  between  networks  owned  by  different
     organizations.    Portions  of your network where experiments are
     being done in network technology should always be  isolated  from
     the rest of the network by gateways.

   - For  many  applications  it is more important to choose a product
     with the right combination  of  performance,  network  management
     tools,  and  other  features  than  to  make the decision between
     bridges and gateways.

                                  41
 


@section(Configuring Gateways)

This section deals with configuration  issues  that  are  specific  to
gateways.   Gateways than handle TCP/IP are themselves Internet hosts.
Thus the  discussions  above  on  configuring  addresses  and  routing
information  apply to gateways as well as to hosts.  The exact way you
configure a gateway will depend upon the vendor.  In some  cases,  you
edit  files  stored  on  a  disk  in  the gateway itself.  However for
reliability reasons most gateways do not have disks of their own.  For
them, configuration information is stored in non-volatile memory or in
configuration files that are uploaded from one or more  hosts  on  the
network.

At  a  minimum, configuration involves specifying the Internet address
and address mask for  each  interface,  and  enabling  an  appropriate
routing   protocol.    However  generally  a  few  other  options  are
desirable.  There are often parameters in  addition  to  the  Internet
address that you should set for each interface.

One important parameter is the broadcast address.  As explained above,
older software may react badly when broadcasts are sent using the  new
standard  broadcast  address.  For this reason, some vendors allow you
to choose a broadcast address to be used on each interface.  It should
be  set  using  your  knowledge  of  what computers are on each of the
networks.  In general if the computers  follow  current  standards,  a
broadcast  address  of  255.255.255.255 should be used.  However older
implementations may behave better with other  addresses,  particularly
the  address  that  uses  zeros for the host number.  (For the network
128.6 this would be 128.6.0.0.  For compatibility with  software  that
does  not  implement subnets, you would use 128.6.0.0 as the broadcast
address even for a subnet such as  128.6.4.)  You  should  watch  your
network  with  a  network  monitor  and  see  the  results  of several
different broadcast address choices.  If you make a bad choice,  every
time  the  gateway  sends a routing update broadcast, many machines on
your network will respond with ARP's or ICMP errors.  Note  that  when
you  change  the  broadcast  address  in  the gateway, you may need to
change it on the individual computers as well.  Generally the idea  is
to  change  the  address on the systems that you can configure to give
behavior that is compatible with systems that you can't configure.

Other interface parameters may be necessary to deal with peculiarities
of  the  network  it is connected to.  For example, many gateways test
Ethernet interfaces to make sure that the cable is connected  and  the
transceiver  is  working correctly.  Some of these tests will not work
properly with the older Ethernet version 1 transceivers.  If  you  are
using  such  a  transceiver,  you would have to disable this keepalive
testing.  Similarly, gateways connected by a serial line  normally  do
regular  testing  to  make sure that the line is still working.  There
can be situations where this needs to be disabled.

Often you will have to enable features of the software that  you  want
to  use.    For  example, it is often necessary to turn on the network
management protocol explicitly, and to give it the name or address  of
a host that is running software to accept traps (error messages).

                                  42
 


Most  gateways  have  options  that relate to security.  At a minimum,
this may include setting password for making changes remotely (and the
"session  name"  for  SGMP).  If you need to control access to certain
parts of your network, you will also need  to  define  access  control
lists or whatever other mechanism your gateway uses.

Gateways  that load configuration information over the network present
special issues.   When  such  a  gateway  boots,  it  sends  broadcast
requests of various kinds, attempting to find its Internet address and
then to load configuration information.  Thus it is necessary to  make
sure  that there is some computer that is prepared to respond to these
requests.  In some cases, this is a dedicated  micro  running  special
software.   In other cases, generic software is available that can run
on a variety of machines.  You should consult your vendor to make sure
that  this  can be arranged.  For reliability reasons, you should make
sure that there is  more  than  one  host  with  the  information  and
programs  that  your  gateways  need.   In some cases you will have to
maintain several different files.  For example, the gateways  used  at
Rutgers use a program called "bootp" to supply their Internet address,
and they then load the code and configuration information using  TFTP.
This  means  that  we  have to maintain a file for bootp that contains
Ethernet and Internet addresses for each gateway, and a set  of  files
containing  other configuration information for each gateway.  If your
network is large, it is worth taking some trouble to  make  sure  that
this  information remains consistent.  We keep master copies of all of
the configuration information on a single computer, and distribute  it
to  other  systems  when it changes, using the Unix utilities make and
rdist.    If  your  gateway  has  an  option  to  store  configuration
information  in  non-volatile memory, you will eliminate some of these
logistical headaches.  However this presents its own  problems.    The
contents  of  non-volatile  memory should be backed up in some central
location.  It will also be harder for network management personnel  to
review  configuration  information  if  it  is  distributed  among the
gateways.

Starting  a  gateway  is  particularly   challenging   if   it   loads
configuration  information  from  a  distant  portion  of the network.
Gateways that  expect  to  take  configuration  information  from  the
network  generally  issue broadcast requests on all of the networks to
which they are connected.  If there is a  computer  on  one  of  those
networks  that  is  prepared  to  respond  to  the request, things are
straightforward.  However some gateways may  be  in  remote  locations
where  there  are  no  nearby  computer  systems  that can support the
necessary protocols.  In this case, it is necessary to arrange for the
requests  to  be  routed  back  to network where there are appropriate
computers.  This requires what is strictly speaking a violation of the
basic  design philosophy for gateways.  Generally a gateway should not
allow broadcasts from one network  to  pass  through  to  an  adjacent
network.    In  order  to  allow  a  gateway to get information from a
computer on a different network, at  least  one  of  the  gateways  in
between  will  have  to  be configured to pass the particular class of
broadcasts used to retrieve this information.  If you have  this  sort
of  configuration,  you should test the loading process regularly.  It
is not unusual to find that gateways do not  come  up  after  a  power
failure  because  someone changed the configuration of another gateway
                                  43
 


and made it impossible to load some necessary information.



5.4 Configuring routing for gateways


The final topic to be considered is configuring routing.  This is more
complex  for  a gateway than for a normal host.  Most Internet experts
recommend that routing be left to the gateways.  Thus hosts may simply
have  a  default  route that points to the nearest gateway.  Of course
the gateways themselves can't get by with this.   They  need  to  have
complete routing tables.

In  order to understand how to configure a gateway, we have to look in
a bit more detail at how gateways communicate routes.  When you  first
turn  on a gateway, the only networks it knows about are the ones that
are  directly  connected  to  it.    (They  are   specified   by   the
configuration  information.)   In order to find out how to get to more
distant parts of the network, it engages  in  some  sort  of  "routing
protocol".    A routing protocol is simply a protocol that allows each
gateway to advertise which networks it can get to, and to spread  that
information  from  one  gateway to the next.  Eventually every gateway
should know how to get to every network.  There are  different  styles
of routing protocol.  In one common type, gateways talk only to nearby
gateways.  In  another  type,  every  gateway  builds  up  a  database
describing  every  other  gateway  in  the system.  However all of the
protocols have some way for each gateway in the system to find out how
to get to every destination.

A  metric is some number or set of numbers that can be used to compare
routes.  The routing table is  constructed  by  gathering  information
from other gateways.  If two other gateways claim to be able to get to
the same destination, there must be some way of deciding which one  to
use.   The metric is used to make that decision.  Metrics all indicate
in some general sense the "cost" of a route.  This may be  a  cost  in
dollars of sending packets over that route, the delay in milliseconds,
or some other measure.  The simplest metric is just  a  count  of  the
number  of  gateways  along  the  path.  This is referred to as a "hop
count".  Generally this metric  information  is  set  in  the  gateway
configuration files, or is derived from information appearing there.

At  a minimum, routing configuration is likely to consist of a command
to enable the routing protocol that you want to  use.    Most  vendors
will have a prefered routing protocol.  Unless you have some reason to
choose another, you should use that.  The normal reason  for  choosing
another  protocol  is  for  compatibility with other kinds of gateway.
For example, your network may be  connected  to  a  national  backbone
network  that  requires  you to use EGP (exterior gateway protocol) to
communicate routes with it.  EGP is only appropriate for that specific
case.    You  should  not use EGP within your own network, but you may
need to use it  in  addition  to  your  regular  routing  protocol  to
communicate  with a national network.  If your own network has several
different types of gateway, then  you  may  need  to  pick  a  routing
protocol  that  all of them support.  At the moment, this is likely to
                                  44
 


be RIP (Routing Information Protocol).  Depending upon the  complexity
of  your  network,  you  could  use  RIP  throughout it, or use a more
sophisticated protocol among the gateways that support it, and use RIP
only at the boundary between gateways from different vendors.

Assuming  that  you  have  chosen a routing protocol and turned it on,
there are some additional decisions that you may need to make.  One of
the  more  basic configuration options has to do with supplying metric
information.  As indicated above, metrics are numbers which  are  used
to decide which route is the best.  Unsophisticated routing protocols,
e.g. RIP, normally just count hops.  So a route that passes through  2
gateways  would  be  considered better than one that passes through 3.
Of course if the latter route used 1.5Mbps lines and the  former  9600
bps  lines,  this  would  be  the  wrong  decision.  Thus most routing
protocols allow you to set parameters to take this sort of thing  into
account.  With RIP, you would arrange to treat the 9600 bps line as if
it were several hops.  You would  increase  the  effective  hop  count
until  the  better route was chosen.  More sophisticated protocols may
take the bit rate of the line into account automatically.  However you
should  be on the lookout for configuration parameters that need to be
set.    Generally  these  parameters  will  be  associated  with   the
particular  interface.   For example, with RIP you would have to set a
metric value for the interface connected to the 9600 bps line.    With
protocols  that  are  based on bit rate, you might need to specify the
speed  of  each  line  (if  the   gateway   cannot   figure   it   out
automatically).

Most  routing  protocols  are  designed  to let each gateway learn the
topology of the entire network, and to choose the best possible  route
for  each  packet.    In some cases you may not want to use the "best"
route.  You may want traffic to stay out of a certain portion  of  the
network  for  security  or  cost  reasons.   One way to institute such
controls is by specifying routing options.  These options  are  likely
to be different for different vendors.  But the basic strategy is that
if the rest of the network doesn't know about a  route,  it  won't  be
used.    So  controls normally take the form of limiting the spread of
information about routes whose use you want to control.

Note that there  are  ways  for  the  user  to  override  the  routing
decisions made by your gateways.  If you really need to control access
to a certain network, you will have to do two separate  things:    Use
routing  controls  to  make sure that the gateways use only the routes
you want them to.  But also use access control lists on  the  gateways
that are adjacent to the sensitive networks.  These two mechanisms act
at different levels.  The routing controls affect what happens to most
packets:  those  where  the  user  has not specified routing manually.
Your routing mechanism must be set up to choose  an  acceptable  route
for  them.   The access control list provides an additional limitation
which prevents users from supplying their own  routing  and  bypassing
your controls.

For  reliability  and  security reasons, there may also be controls to
allow you to list the gateways from which you will accept information.
It  may  also  be possible to rank gateways by priority.  For example,
you might decide to listen to routes from within your own organization
                                  45
 


before   routes  from  other  organizations  or  other  parts  of  the
organization.  This would  have  the  effect  of  having  traffic  use
internal  routes  in preference to external ones, even if the external
ones appear to be better.

If you use several different routing protocols, you will probably have
some  decisions  to  make regarding how much information to pass among
them.  Since multiple routing  protocols  are  often  associated  with
multiple  organizations,  you  must be sure to make these decisions in
consultation  with  management  of  all  of  the  relevant   networks.
Decisions  that  you  make may have consequences for the other network
which are not immediately obvious.  You might think it would  be  best
to  configure  the gateway so that everything it knows is passed on by
all routing protocols.  However here are some reasons why you may  not
want to do so:

   - The  metrics  used  by  different  routing  protocols  may not be
     comparable.  If you  are  connected  to  two  different  external
     networks,  you  want to specify that one should always be used in
     preference to the other, or that the nearest one should be  used,
     rather  than  attempting  to  compare metric information received
     from the two networks to see which has the better route.

   - EGP is particularly sensitive, because the  EGP  protocol  cannot
     handle  loops.    Thus  there  are  strict  rules  governing what
     information may be communicated to a backbone that uses EGP.   In
     situations  where  EGP  is being used, management of the backbone
     network should help you configure your routing.

   - If you have slow lines in your network (9600 bps or slower),  you
     may  prefer  not  to send a complete routing table throughout the
     network.  If you are connected to an external  network,  you  may
     prefer  to treat it as a default route, rather than to inject all
     of its routing information into your routing protocol.





















                                  46

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 04:45:33 GMT
From:      jsq@longway.TIC.COM (John S. Quarterman)
To:        comp.protocols.tcp-ip
Subject:   Re: ACSNET Access

In article <644@stcns3.stc.oz> dave@stcns3.stc.oz (Dave Horsfall) writes:
>A fairly recent issue of CACM ("Notable Computer Networks") had an article
>on it, but I think it still mentioned SEISMO.

Quarterman, John S. and Hoskins, Josiah C., "Notable Computer Networks,"
Communications of the ACM, Volume 29, no. 10, pp. 932-971,
Association for Computing Machinery, New York, October 1986.

Seismo ceased being a gateway in September 1987, so, yes, NCN still
mentioned it.  The examples you gave using UUNET will probably work.
Machines that understand MX records shouldn't have to indirect, though,
since OZ.AU is a legitimate domain with servers and a forwarder.

I'm near completion of a book that will be an update and expansion
of the article: John S. Quarterman, The Matrix: Computer Networks
and Conferencing Systems Worldwide, Digital Press, 1988.  For example,
I'm working on the ACSnet section now, with its developers.

Suggestions, comments, etc., welcome.

John S. Quarterman		tel: +1-512-320-9031
Texas Internet Consulting	fax: +1-512-320-5821
701 Brazos, Suite 500		jsq@longway.tic.com
Austin, TX 78701-3243		uunet!longway!jsq
U.S.A.				DASnet: [DET1TC]jsq
				CompuServe: 76176,664

PS: If you can't reach jsq@longway.tic.com, jsq@cs.utexas.edu should work.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jul 88 15:27:57 edt
From:      snorthc@nswc-g.ARPA
To:        stev@vax.ftp.com, tcp-ip@sri-nic.arpa
Subject:   Re:  cabletron widgets . . . . . .
Per your req for address of Cabletron :
	cabletron
	10 main st
	Gonic, N.H. 03867
	(603) 332-9400

Ditto on the glowing reports.

	Stephen Northcutt

#include "disclaimer.h"
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 14:13:46 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   cabletron widgets . . . . . .


after hearing many glowing reports about cabletron trancievers(SP?),
i sent our purchasing person off in search of one to see if they are
as good as people say. sadly enough, the purchasing person could not 
find any. can any of you tell me their phone number, or the phone number
of their MASS/North East dist?

thanx muchly . . . . 

stev knowles
ftp software

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 18:31:38 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   INTEROP 88: 3rd TCP/IP Conference and Exhibition



INTEROP 88: The 3rd TCP/IP Interoperability Conference and Exhibition
will be held at the Santa Clara Convention Center and Doubletree Hotel
from September 26 through 30th, 1988.  The format is 2 days of tutorials
followed by 3 days of technical session (16 in all).  For the first time,
there will also be an Interoperability exhibition where vendors will show
TCP/IP systems on a "Show and Tel-Net" which additionally will be connected
to the Internet.

A number of vendors, known as the "Netman" group will be demonstrating
an experimental network management system based on the  ISO CMIP/CMIS
protocols.

For more information on the conference contact:

Advanced Computing Environments
480 San Antonio Road, Suite 100
Mountain View, CA 94040
(415) 941-3399
-------

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 19:27:57 GMT
From:      snorthc@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  cabletron widgets . . . . . .

Per your req for address of Cabletron :
	cabletron
	10 main st
	Gonic, N.H. 03867
	(603) 332-9400

Ditto on the glowing reports.

	Stephen Northcutt

#include "disclaimer.h"

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 19:56:46 GMT
From:      mre@beatnix.UUCP (Mike Eisler)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

In article <1110@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>The fact that all you have ever seen of TCP/IP drivers written as
>TLI conformant functions pass the four byte addresses as actual
>bytes instead of a string like "109.90.42.6" is simply sad.  In

First of all, it is NOT adequate to pass 4 bytes. You need the Internet
address plus the 2 bytes of port number that TCP service is listening.
I'll agree that 109.90.42.6 is a commonly used, standard, clean way to
pass an address to a driver.  But I know of no commonly used form
concatenates port numbers and "dot" addresses.

>essence this breaks the aledged uniformity.  To implement the

What unformity? Where is there a standard written for specifying addresses
to TCP/IP TLI conformant streams drivers? 

>TCP/IP and TLI over the same media, the primitive kernel driver
>should be TCP/IP, and then a streams module which can convert
>TLI requests into TCP/IP should be written.  TCP/IP _is more_
>complex, and therefore, to implement both TLI should be an
>optional addition onto the TCP/IP.  Then you place 109.90.42.6

What does complexity of TCP/IP have to do with whether TLI should be an
option. What's complex, the protocol implementation, or the interface?
If starlan and TCP/IP can both use the same interface, TLI, then they
their interfaces are equally complex, and so by your logic all TLI
compliant protocols should be implemented as two halves, your symbolic
"uniforum half" and the half that everybody currently implements. Bye, bye
performance.

>As I said, doing TCP/IP _over_ TLI is stupid.  They are *comprable*

By this statement, I think you mean that to implement a TCP/IP
protocol in user-land on top of some TLI compliant media driver (eg.
X.25, ethernet, etc.) is stupid. I'm not so sure I agree. Somebody
may want to proto-type a TCP/IP implementation first on a particular
computer, before investing in the increased costs of kernel
development and debugging, especially on a 3b2. :-)

>in form and purpose, and TLI _is_ designed to be more "elementary"
>than TCP/IP.  Trying to squese TCP/IP through TLI is like hooking

Hey what exactly are you talking about anyway? TLI is comparable to TCP/IP?
TLI is an interface. TCP/IP is a protocol. TCP/IP under TLI
is an implementation.

>The *purpose* of TLI _is_ to insulate you form the uglies ...
 
>... Depending on what is required, you might
>need to set an address like "109.94.60.2:rlogin" to properly implement

You are assuming that this is the standard address representation for
the login service residing on 109.94.60.2. I've never seen this format
before. Vendors could implement infinite, incompatible variations of
this ascii string format, eg: rlogin:109.94.60.2, 513.109.94.60.2,
2.1.109.94.60.1, 109.95.60.1:2.1, etc.

>TLI through TCP/IP, or perhaps place something similar in the Dialers
>spec, but I don't really know because I have not expended any energy on
>the topic outside this conversation.
>
>All of this is much the purpose of the "adm" program which assembles
>the STREAMS modules which eventually make /dev/starlan operate
>the STARLAN product.  I would assume the correct "adm" program
>for an ethernet and/or internet support would activate two STREAMS
>multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.

First you said that the *purpose* of TLI is to insulate you from
"uglies" than you say that it is the purpose of the of "adm" program.
Which is it?  The "adm" program isn't on my copy of 5.3 source, so I
assume it is something specific to starlan that assembles streams
drivers and modules, and/or does name resolution. The various STREAMS
TCP packages have similar tools and services to do the same, but
difference is that Starlan has virtually one manufacturer and is
proprietary to AT&T.  AT&T can therefore enforce a standard address
encoding that will be recognizable to all applications that use it on
all machines that use those applications, eg. RFS. And I guess it is
the "adm" program that embodies this enforcement.

TCP has perhaps a half dozen or so suppliers of STREAMS
implementations, each with their own "adm" thing and address encoding
formats. The point is that without a well-defined, agreed upon
standard, regardless of whether the encoding uses nice ASCII strings,
or binary strings, each implementer is going to use his own encoding
mechanism, resulting in incomptabilities.

Telling me that TLI has solved this problem for me, because it solves
it for the protocol you use (starlan), doesn't cut it. I'm using an
open protocol that others are free to implement.  If AT&T wants TLI to
be the standard, then they should enhance it to define specifics for
commonly used protocols (TCP, ISO/OSI/ X.25, SNA, DECNET). AT&T did
this for starlan, why can't they do it for TLI?

Sockets, for all the trashing people have done on them, do define and
enforce address encodings for at least two protocols (XNS, TCP). Hence,
everybody can rlogin, telnet, rcp, ftp, smtp, NFS, RPC, etc. to each
other, as long as these things are built on sockets. That's not the
case for RFS built on TLI over TCP.

	-Mike Eisler

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 20:24:33 GMT
From:      mre@beatnix.UUCP (Mike Eisler)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI transport specific addresses

In article <1111@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>in article <843@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
>>>the free-form address as a string, and the rest of the system does
>>>it's best to make the connection you want, but like the PSTN
>>>(Public Switched Telephone Network) if you don't know the number
>>>you want, you probably arn't gonna get through!
>> 

I said:

>> Yeah, but regardless of whether I use rotary, or touch tone, and whether
>> the party I'm calling uses rotary or touch tone, we both agree on what
>> our phone numbers are, and what the order of the digits are. Because of
>> this, we can use a common name service called the telephone book.

Rob says:
>
>The whole PURPOSE behind TLI is that you *should* pass any address
>you want to use to TLI as a string; and the TLI driver for whatever
>the network is, should do all the work of figuring out how the provider
>needs the address (in binary) and changing the string to binary.
>

Rob,
	Try to follow this analogy: Suppose my phone number is
	234-5678.  234 is analagous to an IP machine address. 5678 is
analagous to a port number. In the telephone world, I walk up to a
phone, enter 234, then 5678, and expect things to work as expected.
What we have been trying to tell you, is that in the underspecified
TCP/TLI world, we don't know how to enter the digits. On vendor A's
implementation we might enter 2345678, on B's 5678234, and on crazy Z's
it might be something as silly as 8 3 5 6 3 4 2 1. So how can I write
an application to lookup your name, R. White in the phone book, and
send that name to the protocol driver via TLI, and expect it to be
portable to all implementations of TCP/IP. The application either has
to know the various ways of encoding digits, or there has to be an
encoding agreement, or each machine has it's own version of the phone
book that matches the enconding used by its TCP/IP implementation.  And,
I don't really care if you encode in ASCII or binary. It's still a
problem.

>I don't know why you jumped off on the RFS tangent; who cares about
>RFS per se, it was the addressing that was at issue...

I got onto it because it is an example of something that runs on TLI,
independent of the *type* of protocol, uses a central name servicer,
and doesn't work when interoperating between different vendor
*implementations* of a protocol. It is an empirical demonstration that
your reasoning over the past few weeks is broken. 

>If you look back through thi thread, you will find that all of this 
>was started when one individual stated that it was stupid that AT&T 
>didn't invent a universal address structure and build it into TLI.  
>They did, they call it the string buffer; you know a length and an 
>offset, also known as a netbuf structure to the TLI library.  

The address structure is only universal in that it is opaque. The
individual may have said the above, but what he really meant is that
AT&T should have defined a standard address format for TCP, for SNA,
for ISO/OSI, for DECNET, etc., just has they did for their own protocol,
starlan.

	-Mike Eisler

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 88 21:06:24 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   thanx . . . . .


my, my, the message hasnt even gotten back here yet, and already i have 
gotten several responses with cabletron's address. thanx for the help.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 88 02:45:00 EST
From:      "BARRY NEWTON" <newton@enh.nbs.gov>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        <newton@vax.cam.nbs.gov>
Subject:   S/3x Networking
Thanks!  At this point several people have referred me to Mitek Corp, who have
products we will at least consider seriously.  Much obliged.

Barry L. D. Newton
National Bureau of Standards

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 88 01:47:44 GMT
From:      spdcc!eli@bloom-beacon.mit.edu  (Steve Elias)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: cabletron widgets ?
i don't know if these cabletron tranceivers are the best 
widgets around...  we've seen problems on a few test networks
that occur far more frequently if the cabletron transceiver is
used.  if we use DEC transceivers, our error rates drop dramatically.

steve elias
Chipcom Corp
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jul 88 10:13:11 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   tech reports for CCR bibliography

As the new editor of ACM SIGCOMM Computer Communication Review, I'm
trying to find ways to upgrade the newsletter.  One experiment I'm
planning for the next issue is an expanded bibliography.  Currently
CCR prints a list of recent papers in computer communication in
major journals -- I'm trying to expand that converage by including
including technical reports, conference proceedings, books and reviews
of papers and books on computer communication.  The bibliography also
includes abstracts of papers from journals or proceedings which are not
generally available.

I would like to encourage people who are publishing technical reports to
e-mail to me the citation and abstract for each tech report so it can be
included in the CCR bibliography.  Authors of books are also encouraged
to let me know when their book comes out.  The next issue will cover
publications since July 1st -- so anyone who had something published
earlier this month is also invited to send a note.

Thanks,

Craig

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 88 07:45:00 GMT
From:      newton@ENH.NBS.GOV ("BARRY NEWTON")
To:        comp.protocols.tcp-ip
Subject:   S/3x Networking

Thanks!  At this point several people have referred me to Mitek Corp, who have
products we will at least consider seriously.  Much obliged.

Barry L. D. Newton
National Bureau of Standards

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 88 09:30:20 GMT
From:      trier@freja.dk (Jens Trier Rasmussen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25 under Unix ?


Does anyone out there known of a product which supports TCP/IP over
X.25 on Unix, more precisely Ultrix from DEC, but all 4.2/3 BSD products
are interesting.

Please send information about the product and the distributor to me.

Kind Regards

    Jens Trier Rasmussen

trier@diku.dk

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 88 14:13:11 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   tech reports for CCR bibliography


As the new editor of ACM SIGCOMM Computer Communication Review, I'm
trying to find ways to upgrade the newsletter.  One experiment I'm
planning for the next issue is an expanded bibliography.  Currently
CCR prints a list of recent papers in computer communication in
major journals -- I'm trying to expand that converage by including
including technical reports, conference proceedings, books and reviews
of papers and books on computer communication.  The bibliography also
includes abstracts of papers from journals or proceedings which are not
generally available.

I would like to encourage people who are publishing technical reports to
e-mail to me the citation and abstract for each tech report so it can be
included in the CCR bibliography.  Authors of books are also encouraged
to let me know when their book comes out.  The next issue will cover
publications since July 1st -- so anyone who had something published
earlier this month is also invited to send a note.

Thanks,

Craig

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 88 14:55:43 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: cabletron widgets . . . . . .

Cabletron's US phone is 603-332-9400 in East Rochester, New Hampshire.
-------

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 02:58:34 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI transport specific addresses


	OK, I give up.  I've been out-jargoned.  I've been trying to follow
this conversation for a week or two, but I still can't figure out what
"TLI" is.  Can somebody please tell me?
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 05:00:43 GMT
From:      jom@belltec.UUCP (Jerry Merlaine)
To:        comp.protocols.tcp-ip
Subject:   FDDI Addressing a' la' RFC 1042

Dear Friends,

RFC 1042 describes standards for setting up addresses and ARPing and
whatnot for IEEE 802.3 (OSI funkey Ethernet), 802.4 (MAP), 
and 802.5 (Token Ring).  Is there any work going on in writing similar
standards for the new fiber optic standards, FDDI (Fiber Distributed
Data Interface) and QSPX (Draft 802.6 Metropolitan Area Network,
I forget what it stands for)?

Any words of wisdom from the Wise Old Men?  FDDI chips are almost
here so it's time to get cracking...

Jerry O. Merlaine
Bell Technologies
pacbell.com!belltec!jom

--------------------------------------------------------
These are not my opinions.  I channel for Elvis Presley.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jul 88 11:28:08 EDT
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   New Internet Diagram (PostScript) Available via FTP
      New Version of Internet Domain Diagram Now Available

A new version of the Internet Domain Diagram suitable for PostScript
compatible laser printers is now available via anonymous FTP from
omnigate.clarkson.edu (128.153.4.2) from the directory PostScript

There are two versions each in compressed and noncompressed form:

	domain.3x2.ps  (120K) and domain.3x2.ps.Z  (30K)
	domain.2x1.ps  (120K) and domain.2x1.ps.Z  (30K)

Both versions show the same information, in the same format. However,
simply enlarging the smaller of the two does NOT create the same
internal dimensions of the larger one (IE: the line thickness would change)
and would produce undesirable effects.
The first version uses six pages (3x2 grid) the second (less readable but 
legible) uses two pages.  Both versions print with some overlap so 
that it is possible to tape them together seamlessly.

Note: The current Internet Diagram, available from SRI-NIC.ARPA requires
nine pages.  

Each file is composed of 'compiled' postscript which is NOT 
conforming postscript. The code was 'compiled' by running the original
PostScript code through a NeWS psh and can be printed on the 
average PostScript laser printer in approximately five 
minutes per page.  The fonts /Helvetica and /Helvetica-Bold are all
the required fonts.

The original PostScript code is not available, but may be in the future.

For those who are interested, here's how the printouts where created:

The original code has embedded in it arrays within arrays which
describe any tree like topology.  The postscript code attempts to maximize
the size of printed objects while traversing the tree and determining
each objects orientation.

The code was originally designed to provide an automatic method for 
generating Clarkson University's Ethernet diagram.  

The code is composed of four major parts:

	1. Prologue, subroutine definitions.
	2. Data. usually machine generated
	3. local definition mods (modifies data section)
	4. Trailer - printout format specifics (ie: size etc)

In the case of the Internet Diagram the data section was obtained
from the domain.list file from SRI-NIC.arpa.  For the Clarkson
University diagram we obtain the data from the same database which
feeds our Nameserver.

You can also FTP a copy of the Clarkson University diagram from the
PostScript directory the file is  clarkson.2x1.ps (60K) and 
clarkson.2x1.ps.Z (15K).
This diagram uses distinct symbols for hosts,routers,bridges etc
Also included are various line and laser printers.

Clarkson University makes no representation or warranty as to the suitability
or reliability of these files.  You may copy them for your own use.

You may direct inquiries or suggestions (always welcome) to 
bkc@omnigate.clarkson.edu

Please remember that these diagrams were not meant to be visually
appealing, but rather provide a quick means to automatically regenerate
our current network diagram without painstaking redrawing by hand.

Brad Clements  (bkc@omnigate.clarkson.edu)
Network Engineer
Clarkson University
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 10:08:47 GMT
From:      howellg@idec.stc.co.uk (Gareth Howell)
To:        comp.protocols.tcp-ip,rec.ham-radio.packet
Subject:   RFC availability

I am looking for a source of RFCs.  My company has a limited store of
them, but some of the less used ones, like EGP GGP etc. are not in it.
I don't have Internet access so cannot ftp them; can someone indicate
their willingness to mail me a couple, preferably from a UK or EU site
to save mail costs.  If you can help, can you email me with an index
please.
73 Gareth

-- 
Gareth Howell  <howellg@idec.stc.co.uk>  G6KVK @ IO91vx
ICL Financial Services, London, England, Tel:+44 (0)1 638 5622
howellg%idec%ukc@mcvax.uucp, mcvax!ukc!idec!howellg@uunet.uu.net
G6KVK @ G4SPV (uk packet 144.650MHz) 44.131.19.1 g6kvk@g6kvk.ampr.org

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 15:25:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP


    Date: Tue, 19 Jul 88 12:33:09 PDT
    From: cire@clash.cisco.com

    >> Date: Mon, 18 Jul 88 11:02:26 EDT
    >> From: jas@proteon.com (John A. Shriver)
    >> 
    >> ARP is one of the quintessentially elegant protocols.  An enormous
    >> amount of power is provided for a very simple implmentation.  Let's
    >> keep it that way.

    Here here.  I also have a question.  If ARP was built to use
    multicasts wouldn't that just replace one problem with another
    one?  The hosts on the network would have to be properly configured
    to use an appropriate multicast or group of multicasts.  How well
    will this interoperate with other vendor's implementations?  Is
    all this worth it?

I speak here as the author of ARP to give some historical perspective on
the issue at hand.  When ARP was developed (6 years ago), the world was
a lot different than it is today.  Proteon barely existed, if it existed
at all.  Sun wasn't.  I don't think IBM had introduced their PC yet, and
it certainly didn't have networking at the time.  I think 4.2bsd hadn't
come out yet, and it's TCP was still in flux.  For that matter, I think
the ARPAnet was still running NCP.  Ethernet cards were available for
PDP11s (remember them?) from Interlan and 3Com, and for MultiBus from
Interlan.  There may have been others, but that was about it.  VMEBus
was probably in committee.  Multicast addresses were defined in the
spec, but there were no hints how to use them, or what capabilities
boards should provide for multicast (e.g., in the way of specifying
individual or group addresses to listen for).  Due to all of this,
networks were a lot smaller.

Times have changed.  Personal computers and personal workstations are
now commonplace.  The Ethernet spec was revised.  A lot more companies
and products exist.  TCP/IP is incorporated into a lot of systems (e.g.,
4.3bsd).  A lot of different Ethernet interfaces exist.  They all have
various forms of address filtering capabilities, both for multicasting
and normal addresses (e.g., I understand many PC cards require the PC to
get interrupted and do the address filtering in software!).  Networks
are a LOT LOT bigger and broadcasts are on people's mind, whether it's a
real problem or not.

In hindsight, it was a mistake not to have a checksum.  There were a few
other things that could have been done better that various of us have
noticed and learned over the years.  Multicast was just not a
consideration, partly because occaisional broadcasts didn't seem like
they would be a problem (perhaps a mistake) and partly because multicast
was so ill-defined.  One of the people helping me with the protocol may
have suggested multicasting; I can't remember.  Adding state to (or
suggesting state for) ARP was not even thought of, probably because the
protocol works without state and state may have been discarded because
it added (seeminly) unneeded complexity.

I have nothing against somebody figuring out how to effectively use
multicast and/or suggested state algorithms.  I think people do have to
consider the following things:
 - Existing implementations must not break.  It's too hard to get
   vendors to change things on a flag day.
 - Don't unnecessarily link ARP with IP.  I barfed because that's what
   it looked like somebody was suggesting.  The xx-xx-xx-xx-yy-yy
   multicast address suggestion where xx-xx-xx-xx means ARP and yy-yy is
   the protocol being ARPed for seems reasonable.

ARP was designed to be protocol-independent and hardware-independent.
Please keep it that way.

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 15:28:08 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   New Internet Diagram (PostScript) Available via FTP


      New Version of Internet Domain Diagram Now Available

A new version of the Internet Domain Diagram suitable for PostScript
compatible laser printers is now available via anonymous FTP from
omnigate.clarkson.edu (128.153.4.2) from the directory PostScript

There are two versions each in compressed and noncompressed form:

	domain.3x2.ps  (120K) and domain.3x2.ps.Z  (30K)
	domain.2x1.ps  (120K) and domain.2x1.ps.Z  (30K)

Both versions show the same information, in the same format. However,
simply enlarging the smaller of the two does NOT create the same
internal dimensions of the larger one (IE: the line thickness would change)
and would produce undesirable effects.
The first version uses six pages (3x2 grid) the second (less readable but 
legible) uses two pages.  Both versions print with some overlap so 
that it is possible to tape them together seamlessly.

Note: The current Internet Diagram, available from SRI-NIC.ARPA requires
nine pages.  

Each file is composed of 'compiled' postscript which is NOT 
conforming postscript. The code was 'compiled' by running the original
PostScript code through a NeWS psh and can be printed on the 
average PostScript laser printer in approximately five 
minutes per page.  The fonts /Helvetica and /Helvetica-Bold are all
the required fonts.

The original PostScript code is not available, but may be in the future.

For those who are interested, here's how the printouts where created:

The original code has embedded in it arrays within arrays which
describe any tree like topology.  The postscript code attempts to maximize
the size of printed objects while traversing the tree and determining
each objects orientation.

The code was originally designed to provide an automatic method for 
generating Clarkson University's Ethernet diagram.  

The code is composed of four major parts:

	1. Prologue, subroutine definitions.
	2. Data. usually machine generated
	3. local definition mods (modifies data section)
	4. Trailer - printout format specifics (ie: size etc)

In the case of the Internet Diagram the data section was obtained
from the domain.list file from SRI-NIC.arpa.  For the Clarkson
University diagram we obtain the data from the same database which
feeds our Nameserver.

You can also FTP a copy of the Clarkson University diagram from the
PostScript directory the file is  clarkson.2x1.ps (60K) and 
clarkson.2x1.ps.Z (15K).
This diagram uses distinct symbols for hosts,routers,bridges etc
Also included are various line and laser printers.

Clarkson University makes no representation or warranty as to the suitability
or reliability of these files.  You may copy them for your own use.

You may direct inquiries or suggestions (always welcome) to 
bkc@omnigate.clarkson.edu

Please remember that these diagrams were not meant to be visually
appealing, but rather provide a quick means to automatically regenerate
our current network diagram without painstaking redrawing by hand.

Brad Clements  (bkc@omnigate.clarkson.edu)
Network Engineer
Clarkson University

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 15:30:50 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   FDDI Addressing a' la' RFC 1042

FDDI uses the 802.2 DLC, and does not have source routing.  It should
be like 802.3 or 802.4.  802.2 class 1 UI, and SNAP.  FDDI does have
rather large packets, 4500 bytes, enough for 4096 bytes of data and
all the headers you can imagine.

There may be some discussions about some of the IP type of service,
precedence, etc., and the fancier modes for sending packets in FDDI.

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 18:02:48 GMT
From:      rwhite@nusdhub.UUCP (Robert C. White Jr.)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

I am begining to suspect that I am exchanging POV with more than one
other individual.

For clarity, the thread to date is based on one posters lament about how
dificult it was (for him) to write a TCP/IP interface which runs under
TLI.  Please re-read this sentince about a millino times--or at least until
it soaks in throughly--before proceeding.

Either that, or the postings are not being read, they are being "sampled."

Similarly, you should at _least_ include the *entire* sentince on which
you comment.  Other wise all you are doing is foistering you on distortions
of meaning on the readers.  A prepositional phrase, or dependant clause
all by itself does not an idea express...


in article <61066@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) says:
> Xref: nusdhub comp.dcom.lans:370 comp.protocols.tcp-ip:1132 comp.protocols.iso:52
> 
>> The fact that all you have ever seen of TCP/IP drivers written as
>> TLI conformant functions pass the four byte addresses as actual
>> bytes instead of a string like "109.90.42.6" is simply sad.
> Excuse me, but this is nonsense; the difference between "actual bytes" and
> "109.90.42.6" is trivial relative to the difference between "sun.com" and
> "10.7.0.2".  If TLI forced me to pass a string like "109.90.42.6" to it, that
> would be every bit as sad as if it forced me to pass that address down in
> binary form.

True; I do understand that.  This relates bact, however, to the "lament"
that TLI (e.g. AT&T) did not spesify a "universal structure"  (read to mean
memory structure as in C or assem) which would interface to *every* kind
of underlying protocol. (and went on to name: X.25, SNA, URP, TCP/IP [sic]
and a couple of ones I didn't know)  Put simply, such a structure would
be preposterous and unworkable, therefore the "structure" stteled on was
the "string."  (e.g. a netbuf structure filled with an "arbitrary" string
of characters meaningful to the application and the TLI driver.)

To this end, what I wrote was *exactly* as menaingful as I intended.
We have laready been through the:  "But my address is 198.3.54.6 and
not nusdhub.serve, so whay should I pass the latter" argument.  I
therefore, used the "addressing scheme" of choice (to my audience).

>> In essence this breaks the aledged uniformity.  To implement the
>> TCP/IP and TLI over the same media,
> You don't "implement TLI over a medium".  TLI/TPI is, in effect, an *interface*
> that "transport providers" implement.  You implement a "TLI/TPI-conformant TCP"
> or a "TLI/TPI-conformant UDP" or a "TLI/TPI-conformant ISO TP4" or a "TLI-TPI
> conformant XNS SPP" or....

To this I must simply reply: "READ THE SPECS!"

TLI may be implemented OVER *ANYTHING*;  I even went so far as to explain
that I was using the -loose- *ENGLISH* version of the word 'MEDIA.'  To
whit you may (were you to desire to) implement the following:  TLI _over_
verification suit _over_ X.25 _over_ normal tty driver _over_ physical
port _contected to_ a modem _connected to_ Tymenet.  You may also make
A TLI module which you may push above a TCP/IP endpoint to make the
afore-mentioned TCP/IP driver-tree a "TLI CONFORMANT 'PROVIDER'": which
is ALL the specs require of you.

>> the primitive kernel driver should be TCP/IP, and then a streams module
>> which can convert TLI requests into TCP/IP should be written.
> No, you implement a driver that provides the TCP or UDP protocol and that
> conforms to the requirements of TPI and TLI.  That driver is what "converts
> TPI/TLI requests into TCP".

I KNOW the way is should be done when you have no other constraints.
What I described conforms to the constraints provided.  READ THE THREAD.

Several articles back I went over (with pictures) TCP/IP- and TLI-cloning
drivers over an overseer over a "media"; TLI-cloning driver over TCP/IP
driver over "media"; et al ad nausium...  Check your archive.

>> TCP/IP _is more_ complex, and therefore, to implement both TLI should be an
>> optional addition onto the TCP/IP.
> TCP and TLI are completely different types of things, so it's hard to say one
> is "more complex" than the other, except to say "TLI supports functions TCP
> doesn't provide" (which is true) or "TCP provides functions TLI doesn't
> support" (which is also true).

No kidding???!!!???  Of course they are, but the basis of all this was
someone who wanted to implement TCP/IP *over* TLI (patently dumb)
and the waters you just re-muddied were almost clear.

>> Then you place 109.90.42.6 in your Systems file;
> 
> I refuse to put something as gross as "109.90.42.6" into any configuration file
> for a network utility; if I can't put the *name* of the machine there, that's
> unacceptable.  There are, I believe, many *thousands* of hosts on the DARPA
> Internet; I know there are thousands of hosts on Sun's network.  Sometimes
> hosts may change their addresses but not their names.  Administering a network
> of that size by using addresses rather than names would simply be impractical.

Yes, I know about address names, verses real addresses.  I am trying to
keep the examples simple and well defined.

Once again, If you simply say:  "But I'll just throw away my spesifications
and the desire of my employer and do it this way" all sorts of things become
a lot easier.  Similarly, if you just say:  "This example is to basic, it
allows someone form another environment to _understand_ so I better
re-muck it up"  you can justify all sorts of "better" things to say.

The spesific issue *WAS* using the four byte address (c.f. to string
or to structure) and my use of uucp as an example was to keep things
both (1) on track to my audience, and (2) simple and aimed at my audience.

>> The simple task of converting the string to the 4-byte couplet
>> is not beyond the scope of a STREAMS module,
> No, but it's not very useful, either.  What you *really* want is a mechanism
> that can convert what you might call a "service specification" (i.e., "UUCP on
> host 'sun.com' over TCP") into an address in whatever form the protocol
> requires.  UUCP (which, I infer from your mention of a "Systems" file, is the
> service to which you're referring here) would then ask for that service, and
> hand *that* to TLI.

I don't know weather you have read the specs for UUCP as relates to
a TLI conformant provider.

>> All of this is much the purpose of the "adm" program which assembles
>> the STREAMS modules which eventually make /dev/starlan operate
>> the STARLAN product.  I would assume the correct "adm" program
>> for an ethernet and/or internet support would activate two STREAMS
>> multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.
> Are you actually familiar with TCP or IP, or is your only TLI/TPI experience
> with, e.g., STARLAN?  If you haven't worked with TCP, you should probably study
> up on it first, and preferably on TLI-conformant TCP implementations, so you
> can discuss implementations of things other than STARLAN meaningfully, and
> support for multiple protocols in general, meaningfully.  If all you know is
> STARLAN, you're unlikely to know what's involved in protocol independence....

No, I am not farmilliar with the internal details of TCP/IP;  my question
about TCP/IP is mostly how this thread got started.  As far as TLI is
concerned, I have been through the "porting rules" doccument--which
contains a description of *all* of the STREAMS requirements and
functional spesifications necessary to make any STREAM represent a
'TLI conformant provider'  (this includes state and precidence tables)--
and know exactly what is and is not required of a system for it to be
TLI conformant.

The essence of the discusion is:

(1) Q: What structure should be passed to TLI?  A: A "human readable"
	string.

(2) Q: How can I [sic] implement a TCP/IP interface over a TLI network?
	A:  You can't; you don't want to; the whole point of TLI is
		to allow/create a "simple and uniform" interface
		which will work with any provider.

(3) Q: How am I supposed to do address translation under TLI?
	A:  You don't; the driver writer has built the soft-to-
		hard address translation into the driver (if it
		is in fact conformant).


Rob.

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 20:35:43 GMT
From:      mankin@gateway.mitre.ORG
To:        comp.protocols.tcp-ip
Subject:   BSD 4.3 network applications


Will BSD 4.3 FTP and TELNET source be released with a Berkeley
copyright a la the Jacobson TCP?  I thought I heard something on
those lines.  Thanks.

Allison
mankin@gateway.mitre.org

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 88 21:11:37 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI transport specific addresses

Transport Level Interface.  SysV's answer to Berkeley Sockets
(And More!!! :-)

-Philip

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jul 88 17:59:51 -0700
From:      Keith McCloghrie <kzm@TWG.COM>
To:        The TCP Logger <tcplog@chakra.cs.umd.edu>
Cc:        tcp-ip@sri-nic.arpa, kzm@TWG.COM
Subject:   Re: Instrumenting a TCP Implementation
Hi,

Your message said :

> We, at the Department of Computer Science, University of Maryland, have
> done an instrumentation of TCP/IP. Here is the abstract from the
> Technical Report describing our work:
>
> "We ....
>                ... code)."
>
> Interested persons can get a copy of the Report by sending mail to
> 	tcplog@chakra.cs.umd.edu 
>
> Please quote the following numbers in your request:
>
> CS-TR 2063 and UMIACS-TR 88-50
>

I would be interested in obtaining a copy.  If this is possible by 
e-mail or ftp please reply to <kzm@twg.com>.  If not, my USmail 
address is :

    Keith McCloghrie
    Director, Software Engineering
    The Wollongong Group
    1129 San Antonio Road,
    Palo Alto, Ca. 94303.

Thank-you,
Keith.


-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 16:57:03 GMT
From:      sas@pyrps5 (Scott Schoenthal)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

[ I have removed comp.protocols.iso from the Newsgroup distribution -- sas ]

In article <1116@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>The essence of the discusion is:
>
>(1) Q: What structure should be passed to TLI?  A: A "human readable"
>	string.

I have tried to follow your "thread" and I must take exception to this
statement.  The point (as I see it) of the addressing discussion is that
the structure of the address (in ISO jingo, the TSAP) that is passed
to TLI is opaque.  It is up to the implementation of the TLI-conformant
transport provider as to how this is interpreted.  Mike Eisler raised the
point that different transport provider implementations that support
the same protocol (he used TCP/IP addressing as an example) could interpret
the address in different, arbitrary manners.

What is lacking is the definition of an addressing structure (be it
packed BCD, hexadecimal arrays, or ASCII strings) to be used for different
communication protocol families (e.g., OSI, XNS, TCP/IP, etc) within the TLI
framework.

That, sir, is the point.

>(3) Q: How am I supposed to do address translation under TLI?
>	A:  You don't; the driver writer has built the soft-to-
>		hard address translation into the driver (if it
>		is in fact conformant).

The question itself is a non sequitur.  A more reasonable way of stating what
I think you mean is:

	"How does an application programmer form address structures
	to pass to a TLI conformant provider while using the TLI
	user-library functions?"

And the answer is (once again) that the format of the structure depends on the
implementation of the provider.  The provider renders the
address structure passed to it (which is defined as part of the implementation
of the provider) into whatever internal formats or uses it requires.

Rob,  I suggest that, if possible, you should somehow get access to System V
source code.  I think that the points made by Guy, Mike, and others will
become more obvious.  It is unfortunate that the publically available
documentation does not make these issues more clear.

sas
----
Scott Schoenthal   			sas@pyrps5.pyramid.com
Pyramid Technology Corp.		{sun,hplabs,decwrl}!pyramid!sas

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 17:53:43 GMT
From:      brent%terra@Sun.COM (Brent Callaghan)
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP software

Nevil Brownlee at the University of Auckland, New Zealand
asked me to forward a request for info about TCP/IP software:

	A PC TCP/IP implementation I'd heard about
	is one from NCSA, i.e.
	
	   National Centre for Supercomputing Applications
	   University of Illinois, Urbana,
	   Champaign, Illinois.
	
	The people at University of New South Wales told me that it's
		a) public domain
		b) available for the Mac (via the Kinetics box)
		   as well as the PC, and
		c) very good.
	
	Could you please try to find me an email address where
	I can enquire about it?
	
	Another topic of interest is TCP/IP drivers for the
	DEC DEPCA ethernet card and the Western Digital ethernet card.  ??

If you can help please E-mail directly to him:

	aucc4341.aukuni.ac.nz!CCC024D@comp.vuw.ac.nz

	Thanks

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 6188

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 18:29:25 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: default broadcast address

>> First, try to the robustness principle: hosts should accept
>> AS BROADCASTS all the possible (i.e., legal or formerly legal)
>> broadcast addresses.
 
>Hosts should also accept AS BROADCASTS any packet that was sent to the
>link layer broadcast (and mulitcast???) address regardless of what the
>IP address was.
					David Bridgham
	
>Well, now, I would not put it quite that way.  To be an acceptable
>IP broadcast datagram, it must have a recogizable IP broadcast address
>in its destination field.  The problem we need to solve is the havoc
>(broadcast storms, etc) created by datagrams which arrive by local
>network broadcast but do not have a recognizable IP broadcast address.
>The discussions in the IETF Host Requirements Working Group have 
>concluded that the best thing to do with such datagrams is SILENTLY
>IGNORE THEM.
 
>Bob Braden

From a security aspect:
    Anything that can cause havoc (broadcast storms) can cause denial of
service.  Anything that may be silently ignored (by some folks) has the
potential of being used (by other folks) as part of a covert channel.

From a management aspect:
    I hope the people working on network management will devise
procedures that will allow a site or network manager or security officer
to create an audit record of "normal" and abnormal errors, at every
layer in the stack.

Regards - Craig

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 18:33:39 GMT
From:      dougm@ico.ISC.COM (Doug McCallum)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)

In article <1116@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>I am begining to suspect that I am exchanging POV with more than one
>other individual.

You are.  There are 3-4 of us.

>For clarity, the thread to date is based on one posters lament about how
>dificult it was (for him) to write a TCP/IP interface which runs under
>TLI.  Please re-read this sentince about a millino times--or at least until
>it soaks in throughly--before proceeding.

Ok, in your sentence, the operative word is "under".  That is, TCP/IP
interface is "under" the TLI.  That's pretty clear.

>Either that, or the postings are not being read, they are being "sampled."

You might follow your own advice.

...
>True; I do understand that.  This relates bact, however, to the "lament"
>that TLI (e.g. AT&T) did not spesify a "universal structure"  (read to mean
>memory structure as in C or assem) which would interface to *every* kind
>of underlying protocol. (and went on to name: X.25, SNA, URP, TCP/IP [sic]
>and a couple of ones I didn't know)  Put simply, such a structure would
>be preposterous and unworkable, therefore the "structure" stteled on was
>the "string."  (e.g. a netbuf structure filled with an "arbitrary" string
>of characters meaningful to the application and the TLI driver.)

No one suggested a "universal structure".  What is needed and was
suggested was  a structure for each address family.  It wasn't worded
exactly that way, but that is what was said.  Who settled on the
"string" as the official form of address?  You may have.  The Starlan
software may have, butI have not found it anywhere in the
documentation.  Please cite volume, chapter and verse so I can be
enlightened.

>To this end, what I wrote was *exactly* as menaingful as I intended.
>We have laready been through the:  "But my address is 198.3.54.6 and
>not nusdhub.serve, so whay should I pass the latter" argument.  I
>therefore, used the "addressing scheme" of choice (to my audience).

Actually, your audience seems to be disagreeing with you.

...
>I KNOW the way is should be done when you have no other constraints.
>What I described conforms to the constraints provided.  READ THE THREAD.

But the constraints are yours and not TLI or AT&T's.  Could you point
me at something that documents how things are supposed to be done?

...
>> is "more complex" than the other, except to say "TLI supports functions TCP
>> doesn't provide" (which is true) or "TCP provides functions TLI doesn't
>> support" (which is also true).
>
>No kidding???!!!???  Of course they are, but the basis of all this was
>someone who wanted to implement TCP/IP *over* TLI (patently dumb)
>and the waters you just re-muddied were almost clear.

Now, if your earlier sentence (included here for context)
    >For clarity, the thread to date is based on one posters lament about how
    >dificult it was (for him) to write a TCP/IP interface which runs under
    >TLI.  Please re-read this sentince about a millino times--or at least until
    >it soaks in throughly--before proceeding.

states what started this, then how do you get TCP/IP being implemented
over TLI from TCP/IP "under" TLI?  Before telling others to "read",
you should do the same.

...
>Yes, I know about address names, verses real addresses.  I am trying to
>keep the examples simple and well defined.

But your examples only work in the simple and well defined universe.
They don't work in the real universe the rest of us have to deal with.

>Once again, If you simply say:  "But I'll just throw away my spesifications
>and the desire of my employer and do it this way" all sorts of things become
>a lot easier.  Similarly, if you just say:  "This example is to basic, it
>allows someone form another environment to _understand_ so I better
>re-muck it up"  you can justify all sorts of "better" things to say.

Are you speaking as the authoritative voice of what AT&T wants people
to do with TLI addressing?  Again I ask, point me at any published
specification that states that "strings" are what is specified.  If
you look on page 3-7 of the "AT&T UNIX(tm) System V Network
Programmer's Guide", you will find a documented counter-example to
your claim of strings being the specified address format.  If you are
interpreting the fact that the netbuf structure defines the "buf"
field to be type "char *", well, "char *" is frequently used as a
pointer to anything.

I should also mention that when I worked on TCP support during the 386
V.3 port, we had to change the address convention used to conform to
what AT&T required.  That address format was a specific format for the
struct sockaddr_in structure, it was not an ASCII string.  Come to
think of it, the "official" port supported ISO protocols with a very
"binary" representation.  This is documented in the "AT&T UNIX System
V/386 System Administrator's Reference Manual"  section tp4(7).

...
>I don't know weather you have read the specs for UUCP as relates to
>a TLI conformant provider.

I have, what is it supposed to tell me that contradicts what the
author said?  You can either put in a phone number (in ASCII) or use
\nnn notation to put in what you need.  In other wrds, where RFS
(which uses a different host file altogether) allows \xABCD, UUCP
would require specifying in octal with the \nnn notation.

...
>No, I am not farmilliar with the internal details of TCP/IP;  my question
>about TCP/IP is mostly how this thread got started.  As far as TLI is
>concerned, I have been through the "porting rules" doccument--which
>contains a description of *all* of the STREAMS requirements and
>functional spesifications necessary to make any STREAM represent a
>'TLI conformant provider'  (this includes state and precidence tables)--
>and know exactly what is and is not required of a system for it to be
>TLI conformant.

I've been through the porting rules as well.  Not everyone ahs access
to them.  It is not supposed to be necessary to have the porting rules
to do a Streams driver which is TLI conformant although it certainly
helps.  Where does it mention how an address is supposed to look?  It
doesn't mention it anywhere where I could find it.

>The essence of the discusion is:

I assume that the A: are your interpretations and may not necessarily
be correct?

>(1) Q: What structure should be passed to TLI?  A: A "human readable"
>	string.

Prove it.  Give document, chapter, page and line.

>(2) Q: How can I [sic] implement a TCP/IP interface over a TLI network?
>	A:  You can't; you don't want to; the whole point of TLI is
>		to allow/create a "simple and uniform" interface
>		which will work with any provider.

This isn't the issue so don't confuse things any further.

>(3) Q: How am I supposed to do address translation under TLI?
>	A:  You don't; the driver writer has built the soft-to-
>		hard address translation into the driver (if it
>		is in fact conformant).

The real answer is that you can't with TLI at all.  You need software
that is not provided with V.3.

Since your the one so insistant on being correct and having
documentation to prove it, please do so.  My documentation does not
seem to have it.  Give published dates also.  Perhaps what an outsider
can get is not the same as an insider.

		Doug McCallum
		Interactive Systems Corp.
		dougm@ico.isc.com

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 19:22:53 GMT
From:      dougm@ico.ISC.COM (Doug McCallum)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)


In an earlier article I mentioned that there should be a name server
to do the conversion.  I didn't intend to imply a single name server
to handle "all" address formats or that only a single format should be
allowed, rather, I feel that a name server functional interface should
be specified.  Each protocol implementation would then provide an
appropriate name server that the standard interface could access.
Each application woudl be implemented using the standard interface.

Finding which name server isn't difficult since you have to specify
the protocol via the first parameter to "t_open" anyway.  That would
be enough information to provide a standard way of finding and
accessing a specific name server.  It would also be possible to query
each resident name server and see if it could resolve the address or
not.

When a name is resolved, the resolver function would return a possible
list of opaque addresses.  It would also have to return the size of
the address to provide a way to determine end of an address and a
count of how many addresses were returned.  Some protocols might not
support or need multiple addresses while something like TCP/IP does.

A universal functional interface need not return a single fixed size
standard format object.  The application does not need to know how to
parse the address.  Some applications might, but then they would not
be particularly portable in any event.  Most applications would just
hand the address to t_connect and wait for a connect or fail.  This
would not be that hard to specify or even very difficult to implement.

You would have thought that AT&T would have understood the need of
name servers and related tools that become an absolute necessity with
large networks.

      			Doug McCallum
			Interactive Systems Corp.
			dougm@ico.isc.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 19:33:32 GMT
From:      rusty@VIOLET.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   van jacobson tcp/ip code on ultrix 2.2-1?

Has anybody installed Van Jacobson's "turbo" tcp/ip code on
Ultrix V2.2-1?  If so, did you need to make any changes?

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 88 20:22:53 GMT
From:      hollandm@prlhp1.prl.philips.co.uk (Martin Holland)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Remote Ethernet Bridge to Link Sites

One of our factory sites about 10 miles away has a group of Suns wishing
to connect with some Suns on out local Ethernet. They want E/Mail,UUCP
remote login and fast file transfer for Mbyte files.  Their suggestion
is to install a remote bridge linking both Ethernets. I am worried about
security on our site as well as the possibility of the remote site
producing faults on our site. Am I worring about nothing?
Has anyone any ideas?  The sites are currently linked by DecNet over a
9600 baud line but this could be uprated to 64K if necessary. The only
other links are by Case DCX which is a distributed terminal multiplexor
system for RS232. (probably not fast enough).
All ideas would be welcome (the cheaper the better)

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jul 88 09:02:01 -0700
From:      Keith McCloghrie <kzm@TWG.COM>
To:        tcp-ip@sri-nic.arpa
Cc:        kzm@TWG.COM
Subject:   Re: Instrumenting a TCP Implementation
I apologise for bothering the net with my previous message.  Immediately
after my fingers had typed the send command, I was kicking myself for
forgetting to edit the CC: line.  Of course, I was also faced with the
dilemma of whether to compound my mistake by sending out an apology.

Such is the power of e-mail these days that 19 characters on a CC: line 
can wake up hundreds/thousands of mailboxes, and even more people.
Does anybody know how many people read tcp-ip ?  It would be interesting 
to find out.  I guess the only way would be to ask each individual/group 
of recipients to mail in a response, and add up the numbers.  Is there 
any automation for this, i.e. email-survey-response processing code ?

Keith.
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 88 00:59:51 GMT
From:      kzm@TWG.COM (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: Instrumenting a TCP Implementation

Hi,

Your message said :

> We, at the Department of Computer Science, University of Maryland, have
> done an instrumentation of TCP/IP. Here is the abstract from the
> Technical Report describing our work:
>
> "We ....
>                ... code)."
>
> Interested persons can get a copy of the Report by sending mail to
> 	tcplog@chakra.cs.umd.edu 
>
> Please quote the following numbers in your request:
>
> CS-TR 2063 and UMIACS-TR 88-50
>

I would be interested in obtaining a copy.  If this is possible by 
e-mail or ftp please reply to <kzm@twg.com>.  If not, my USmail 
address is :

    Keith McCloghrie
    Director, Software Engineering
    The Wollongong Group
    1129 San Antonio Road,
    Palo Alto, Ca. 94303.

Thank-you,
Keith.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 88 09:33:17 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip,rec.ham-radio.packet
Subject:   Re: RFC availability

In article <1049@idec.stc.co.uk> howellg@idec.stc.co.uk (Gareth Howell) writes:
>I am looking for a source of RFCs.  My company has a limited store of
>them, but some of the less used ones, like EGP GGP etc. are not in it.
>I don't have Internet access so cannot ftp them; can someone indicate
>their willingness to mail me a couple, preferably from a UK or EU site
>to save mail costs.

The info-server at SRI-NIC allows anyone to pick up RFC's by email. You
don't need to have Internet access (or speak FTP). Here's the details:


    NIC Mail Services					November 1987
    
       This is an automated service provided by the DDN Network Information
    Center.  It allows access to NIC documents and information via ordinary
    electronic mail.  This is especially useful for people who do not have
    access to the NIC via a direct Internet link, such as BITNET, CSNET
    and UUCP sites. 
    
       To use the mail service, send a mail message to SERVICE@SRI-NIC.ARPA.
    In the SUBJECT field, request the type of service you wish followed by
    any needed arguments.  The message body is normally ignored.  Large files
    will be broken into smaller separate messages.  The information you
    request will be sent back to you as soon as possible.
    
    The following services are currently available:
    
    HELP		This message; a list of current services.
    RFC nnn		nnn is the RFC number or the word INDEX.
    IEN nnn		nnn is the IEN number or the word INDEX.
    NETINFO xxx	xxx is a file name or the word INDEX.
    SEND xxx	xxx is a fully specified file name.
    HOST xxx	Returns information about host xxx.
    WHOIS xxx	Returns information about xxx from the WHOIS service.
                    Use "WHOIS HELP" for information on how to use WHOIS.
    
    Example SUBJECT lines:
    HELP
    RFC 822
    RFC INDEX
    NETINFO DOMAIN-TEMPLATE.TXT
    SEND RFC:ASSIGNED-NUMBERS.TXT
    HOST SRI-NIC.ARPA
    WHOIS LOTTOR, MARK
    
    Send comments or suggestions to SUGGESTIONS@SRI-NIC.ARPA.
    Send questions and bug reports to NIC@SRI-NIC.ARPA.

For people in the UK, UCL keep most of the RFC's on-line and they are
readily available. They can be accessed by anonymous NIFTP and I think
there's also an info-server that will allow you to pick RFC's up by
email. Sadly, I can't put my hands on the file that had all the details
of how to fetch RFCs from UCL.

		Jim
-- 
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 88 16:02:01 GMT
From:      kzm@TWG.COM (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: Instrumenting a TCP Implementation

I apologise for bothering the net with my previous message.  Immediately
after my fingers had typed the send command, I was kicking myself for
forgetting to edit the CC: line.  Of course, I was also faced with the
dilemma of whether to compound my mistake by sending out an apology.

Such is the power of e-mail these days that 19 characters on a CC: line 
can wake up hundreds/thousands of mailboxes, and even more people.
Does anybody know how many people read tcp-ip ?  It would be interesting 
to find out.  I guess the only way would be to ask each individual/group 
of recipients to mail in a response, and add up the numbers.  Is there 
any automation for this, i.e. email-survey-response processing code ?

Keith.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 88 16:13:19 GMT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP over X.25 under Unix ?

> From mcvax!dkuug!freja!trier@uunet.uu.net Fri Jul 29 08:33:17 1988
> Date: 26 Jul 88 09:30:20 GMT
> To: tcp-ip@sri-nic.arpa
> From: mcvax!dkuug!freja!trier@uunet.uu.net  (Jens Trier Rasmussen)
> Subject: TCP/IP over X.25 under Unix ?
> Message-ID: <3949@freja.dk>
> Organization: DIKU, U of Copenhagen, DK
> 
> Does anyone out there known of a product which supports TCP/IP over
> X.25 on Unix, more precisely Ultrix from DEC, but all 4.2/3 BSD products
> are interesting.
> 
> Please send information about the product and the distributor to me.
> 
> Kind Regards
> 
>     Jens Trier Rasmussen <trier@diku.dk>

Hej Jens,

	Vi har et produkt ved navn ACP6250 som g|r n|jagtig hvad du beder
om p} en UNIBUS VAX. En version kaldet ACP5250 er for Q-Bus.

	Vort produkt er oprindelig beregnet for tilslutning til DDN
(Defense Data Network) hvor X.25 adressen kan *beregnes* ud fra IP adressen,
men vi har tilf|jet hvad vi kalder "PDN feature" hvor X.25 adressen hentes
ved tabelopslag.

	Vort produkt virker sammen med 4.3BSD, Ultrix, Wollongong's VMS
TCP/IP produkt, Network Solutions' VMS produkt, SRI's VMS produkt etc.
S}vidt jeg ved, findes der endnu ingen driver for CMU's VMS produkt,
men dette skulle v{re temmelig simpelt at tilf|je.

	Vi arbejder p} en udvidelse, der vil tillade dig at modtage
X.29 terminalservice p} det samme X.25 kredsl|b.

	Vores skandinaviske distribut|r er Macrotek i Stockholm,
tlf +46 87330220, telefax +46 87332244.

	K{rlig hilsen

	Lars Poulsen
	ACC Customer Service

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 88 17:36:41 GMT
From:      ecc@spice.cs.cmu.edu (Eric Cooper)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Wanted: refs on UNIX networking performance

I'm looking for published studies of where the time is spent during UNIX
network communication. I'm interested in studies of any implementation,
protocol family, and physical network. I'll summarize the citations I
receive if anyone is interested. Thanks.

					Eric Cooper
					ecc@cs.cmu.edu

					Computer Science Department
					Carnegie Mellon University

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 88 19:27:10 GMT
From:      phil@scs.Carleton.CA (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   DNS request times?

Posted for ml@gandalf.uucp...

We're implementing a TCP/IP-based terminal server in our switch, and we're
  thinking of making it compatible with the DOMAIN NAME SERVER architecture.
  We'd like to know (for ARPAnet connected sites), what "typical" times are
  to resolve a name that exists, and one that doesn't (that is, one that
  has to go all the way up to the NIC and get bounced).
Please send your results to:
...!spl1!scs!gandalf!ml

Marcus Leech
Gandalf Data Ltd.

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 88 00:19:41 GMT
From:      ucsdhub!jack!nusdhub!rwhite@ucsd.edu  (Robert C. White Jr.)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
More or less at this point I think I am going to do the following:

	1) Admit that the evidence indicates I am wrong.
	2) Apologize for the tone of my previous posting.
	3) Go for a long weekend away from my job and computer
		on the grounds that my attitude indicates excessive stress.
	4) Re-assert my sense of falibility.
	5) Set tuesday asside for an epic re-reading of the material.
	and
	6) Resign myself for feeling stupid for a while.

Rob.

Disclaimer:  Sometimes it is tough to admit that you are *not*
	the all seeing, all knowing, master of time, space, and
	demension. ;-)
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 88 16:39:59 GMT
From:      nigel@modcomp.UUCP (Nigel Gamble)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   OSI and TLI

There seems to be some confusion as to the position of the TLI (Transport
Layer Interface) in a typical comms protocol stack.  The TLI was defined
by AT&T for UNIX System V because the OSI standards only specify the
data that must flow between protocol layers in a very general way. Note
that the DATA itself is precisely defined, but not the details of how
it is passed from one layer to another.  OSI does not define exactly what
the interface looks like in terms of a particular set of library routines
in a particular programming language on a particular operating system;
it is up to each implementor to define these details for themselves.  
However, it is obviously better if a standard for these details exists
for a particular OS, so that layers implemented by different people can
be easily slotted together.  Hence AT&T defined the TLI for UNIX System V,
which provides the 'glue' between the Session layer and the Transport layer.

Note that the TLI is only the first to be defined of SEVEN possible
xLI's.  This was probably because it is strategically the most 
important, in terms of the number of existing (non OSI) protocols
which can, nevertheless, be implemented so as to be accessible via
the TLI (such as TCP/IP), or to run over the TLI (such as uucp,
RFS, FTP etc.).  This has the obvious advantage that existing
applications do not have to be changed at all to be able to run
over both TCP/IP and the newer OSI Transport protocols.

Perhaps the following diagram showing the standard ISO/OSI (International
Standards Organization/ Open Systems Interconnection) 7 layer reference
model may help to clarify the issue.
	_________________
	|		|\
	| Application	| \
	|_______________|  \     ( Ideally, these should be standard
	|		|   \    ( OSI protocol layers, but anything
	| Presentation	|    >-- ( that is able to use the Transport
	|_______________|   /    ( Layer Interface (such as uucp in
	|		|  /     ( SVR3) can replace them
	| Session	| /
	|_______________|/______ ( TLI provides a standard INTERFACE
	|		|\       ( to the Transport layer
	| Transport	| \
	|_______________|  \
	|		|   \    ( Ideally, these should be standard
	| Network	|    \   ( OSI protocol layers, but anything
	|_______________|     \__( that provides approximately the same
	|		|     /  ( functionality (such as TCP/IP) can
	| Link		|    /   ( replace them
	|_______________|   /
	|		|  /
	| Physical	| /
	|_______________|/

You can see that, whereas PROTOCOL layers are represented by BOXES in
the diagram, the TLI is represented by a horizontal LINE between two
boxes.  If (or when?) each of the other horizontal lines is defined
in terms of a standard set of interface routines in the UNIX environment,
then, as well as a TLI, we will also have an ALI, PLI, SLI, NLI, LLI and
PhLI.
-- 
Nigel Gamble            "Everything should be made as simple as possible,
MODCOMP/AEG              but not simpler."  Albert Einstein.
uunet!modcomp!nigel

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 88 01:32:32 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Remote Ethernet Bridge to Link Sites

If you want cheap and you already have a 9600 baud DECNET link,
investigate Wollongong's DBridge software.  We used it over a
19.2K line.  What it does is encapsulate IP packets in DECNET
packets and send them across.  It worked well enough for mail.

-Ron

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 88 16:34:00 EDT
From:      <enger@gburg.scc.com>
To:        "kzm" <kzm@twg.com>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   Accidentally including the CC line

GEE, sure wish my WIN/TCP mail system would accidentally allow me to reply
back to the CC: field once in a while :-)

Bob

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 88 17:09:00 EDT
From:      <enger@gburg.scc.com>
To:        "kzm" <kzm@twg.com>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   How many people receive TCP-IP

An easy way to get a start at the determination is to look at the
main distribution list at the NIC.  Telnet to SRI-NIC.ARPA port 25
and type EXPN TCP-IP.  I believe this will indicate the direct recipients.

Fortunately/unfortunately, some of those direct recipients are mail exploders.
You can perform the above process iteratively to get some idea of the ultimate
number of recipients.  You will be limited unfortunately, by the fact that
not all mail systems support the EXPN command.  Guess who doesn't?  
Undoubtedly a FEATURE to enhance security :-) .

My good natured ribbing should not be missconstrued as dissatisfaction with
the product.  TWG has already delivered product incorporating the 
Jacobson window adjustment upgrades.  A company that incorporates important 
upgrades like that in a timely fashion IS OK IN MY BOOK.

Bob Enger
Contel Federal Systems

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 88 20:34:00 GMT
From:      enger@GBURG.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Accidentally including the CC line


GEE, sure wish my WIN/TCP mail system would accidentally allow me to reply
back to the CC: field once in a while :-)

Bob

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 88 21:09:00 GMT
From:      enger@GBURG.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   How many people receive TCP-IP


An easy way to get a start at the determination is to look at the
main distribution list at the NIC.  Telnet to SRI-NIC.ARPA port 25
and type EXPN TCP-IP.  I believe this will indicate the direct recipients.

Fortunately/unfortunately, some of those direct recipients are mail exploders.
You can perform the above process iteratively to get some idea of the ultimate
number of recipients.  You will be limited unfortunately, by the fact that
not all mail systems support the EXPN command.  Guess who doesn't?  
Undoubtedly a FEATURE to enhance security :-) .

My good natured ribbing should not be missconstrued as dissatisfaction with
the product.  TWG has already delivered product incorporating the 
Jacobson window adjustment upgrades.  A company that incorporates important 
upgrades like that in a timely fashion IS OK IN MY BOOK.

Bob Enger
Contel Federal Systems

END OF DOCUMENT