The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for May 1990 (395 messages, 213025 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/05.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 May 90 01:26:35 GMT
From:      xanadu!michael@apple.com  (Michael McClary)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <10309@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes:
>How about:  
>	This mechanism will ensure that only files in the directories
>	"under" the chroot-point are acessable:
>
>	if program is not setuid-root,
>		program exits forthwith

Note that it's not sufficient to limit a chroot to going leafword on a
tree but leave it executable by non-root users.  A generally-executable
chroot lets a user build a directory tree like this:

	user_home
	  user_root
	    etc
	      passwd

then chroot to user_root and exec login.
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 03:35:43 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: seeking info on Acces Control List (ACL) mods to inetd
In article <2006@tuminfo1.lan.informatik.tu-muenchen.dbp.de> k2@charly.bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
> >   Has anyone hacked inetd to consult an Access Control List or other
> >   security extensions, ...
> >Yes.  HP-UX has had this extension for several years.  We use the
> >file /usr/adm/inetd.sec.  I've appended a sample to this message.
> Is it possible to post the modifications to inetd ?
> Or will it be propietary code?
> I think there is some interest on the net for ACL's on inetd

Well, you could pick up my auth package, which was sent out today on
comp.sources.unix. If you use attachport rather than inetd to handle
connections, you can set these things up without much trouble:

#!/bin/sh
# Untested. Should allow connections from anyone at 128.9.0.32,
# anyone in 192.48.96.*, and authenticated root at 128.122.128.22.
# Should disallow connections from hacker@128.9.0.32 as well as all
# unauthenticated connections from 128.9.0.32.

# We should really test for PROTO=TCP first, since other communications
# mechanisms might not have the same REMOTE format. Instead we'll
# assume (ha!) that we're only invoked from the Internet.

if /usr/ucb/printenv REMOTE | /usr/bin/egrep -s \
'^((.*@128\.9\.0\.32)|(.*@192\.48\.96\.[^\.]*)|(root@128\.122\.128\.22))$'
then if /usr/ucb/printenv REMOTE | /usr/bin/egrep -s \
'^((shmoe@128\.9\.0\.32)|(@128\.9\.0\.32))$'
     then exit 1    # perhaps log error somewhere
     else exec /etc/whateverd
     fi
else exit 2   # perhaps log error somewhere
fi

Notice how you can test for the username as easily as the host.

To better simulate the HP/UX functionality, you'd have to write a
program that would take those ``inetd.sec'' files, parse them, and check
REMOTE accordingly. Anyone like writing text processing programs? ... If
there's enough interest I'll do this and send it out.

---Dan
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 04:21:38 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Remote Netstat
In article <9004262255.AA14530@chico> mja@chico.simpact.com (Mike Anello) writes:
> Does any have a public domain version of a remote netstat program available ?
> I know about SNMP but I need something even simpler. Thanks.

Pick up auth and authutil from comp.sources.unix. Install auth; follow
the client-server examples in authutil. The basic idea is

server% attachport -vp 52000 /usr/ucb/netstat -n &
client% authtcp server 52000 /bin/sh -c '/bin/cat <&6'

You can make arbitrarily complicated clients and servers. The authtcp
client receives its connection in fd 6; the attachport server receives
each connection in fds 0 and 1. Unless you specify -R to attachport, the
server will see the client's user@in.et.num.ber in environment variable
REMOTE, and vice versa for specifying -R to authtcp. (If the connection
is unauthenticated, user will be blank.)

---Dan
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 11:38:10 GMT
From:      cucstud!tfd!tons61!harrys@uunet.uu.net  (Harry Skelton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <10309@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes:
>harrys@tons61.UUCP (Harry Skelton) writes:
>>allow the local site to include security measures for such a problem. Like
>>a chroot() before any work is done, or allocate spool directories that work
>>like the chroot command/uucp environments.  This would resolve all of these
>>problems.
>
>How about:  
>	This mechanism will ensure that only files in the directories
>	"under" the chroot-point are acessable:
>
>	if program is not setuid-root,
>		program exits forthwith
>	if program is setuid-root
>		program changes directory to chroot-point
>		program changes root to chroot-point
>		program gives up privilege by setting euid to uid.
>
>	Note that this does not protect the system from any manipulations
>	that the program does to the directorys below the chroot-point, only
>	limits changes to files outside that area.
>
>Corrections and suggestions welcome!

Add to the list:
	o make config file much like HDB to control available commands
	  for a particular user(s) (i.e. be able to limit CWD, etc)
	
	o allow for separate log files for each user (config?)

	o allow for 'secure' files although readable by anyone
	- be able to exclude files from a user
	- be able to include files for a user

	o Add dual logfile/console logging of transmistions
	- record user commands
	- add record output for accounting purposes

	o allow limits on amount of data passed or time consumed
	- modification to RFC's necessary for new result codes
	- changes in FTP commands to include overide protections?

    Changes other than security....

	o Add protocols other than ethernet connections
	- add uucp transmitions interfaces
	- add xmodem/ymodem/zmodem transmitions interfaces

	o Add new binary standards
	- header/noheader options (good for Mac Binary and other such codes)
	- compress/nocompress options (for 56k/38.6k links, etc..)
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 13:59:24 GMT
From:      mcsun!ukc!mucs!cns!ran@uunet.uu.net  (Bob Nutter)
To:        tcp-ip@nic.ddn.mil
Subject:   What do FIN_WAIT_2 & CLOSE_WAIT mean?
Could anyone elighten me with regards to the meanings of FIN_WAIT_2
and CLOSE_WAIT (and for that matter ESTABLISHED) when they appear in
the socket state column for the default netstat output? We can't seem
to find an explanation in any of our documentation. One of our (apollo
dn4000) nodes has a *lot* of FIN_WAIT_2 entries and seems to be
slowing down, hence the need to figure this out. Please reply by email.


Thanx in advance,

bob

------------------------------------------------------------------------------
bob nutter, computer officer |  (Witty message on vacation)
dept. of computation, UMIST  |
po box 88, m60 1qd uk        |
tel:+44 61 200 3386          |
email:ran@cns.umist.ac.uk    |
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 May 90 19:02:20 GMT
From:      zaphod.mps.ohio-state.edu!samsung!xylogics!transfer!lectroid!jjmhome!banyan!gordon@tut.cis.ohio-state.edu  (Gordon Lee@Eng@Banyan)
To:        tcp-ip@nic.ddn.mil
Subject:   PC-LAN connection to Usenet
In article <2745@psueea.UUCP> dmatlock@eecs.UUCP (Delbert Matlock) writes:
>In article <4950@netxcom.DHL.COM> cmoussav@dhlmis.DHL.COM (C. Ognibene-Moussavi) writes:
>>I am asking the following question on behalf of my husband - at his work 
>>there is only a LAN - he would like to know what hardware, software and
>>phone number he needs for a dial-up connection to Usenet - he would like
>>to be able to read the newsgroups and post to them as well.
>
>Actually, I'de like to know if there is an implementation out there that
>will run on a DOS or OS/2 based LAN.  To be specific, a 3+Open LAN Manager
>network.  This LAN could easily be fitted with any protocols (TCP/IP) or
>gateway equipment (X.25) needed, but I would like to avoid having to put
>a 386 UNIX box on the network for just running Usenet.
>

I haven't heard of any implementations, but certainly wouldn't be conceptually
difficult to write one.  I've been thinking about this problem for the last
two weeks or so.

For cases where you have an Internet connection, it is possible to write
an NNTP server for an OS/2 machine.  The NNTP protocol can run over any 
stream oriented transport protocol, of course the protocol of choice would
be TCP/IP stack since NNTP implementations within USENET are usually talking 
TCP/IP, (I haven't heard of an implementation which uses a different protocol).
But NNTP could also be spoken over named pipes to transfer news to other 
OS/2 NNTP services.

For that matter, it is possible to write an NNTP service for a DOS machine.
Boot the pc, mount a large network file volume, fire up the NNTP server and
leave the machine running on a continuous basis.  The server fills the network 
volume up with USENET news.  The directory structure would follow the same
scheme found under UNIX implementations.   Write a newsreader for DOS,
and use it from other PC's to read news on the network file volume, no network
code in the newsreader, it is doing sinple read system calls to the network 
file volume as if it were a local disk.  Write an NNTP xmit client program 
to run under DOS and you can also post news.
But where do you put the .newsrc file ?  Oh, I dunno, punt for now, put it
anywhere and then point an environment variable to it.

Then of course, you'd also want to port all the other netnews support tools
and utilities, like expire, and have something like cron to make them run on
a schedule.  And of course you'd have to leave the PC's running 
during the scheduled times.

It all adds up to a large project made up of a lot of pieces, some of which
are small though.  Of course the whole thing rests on the assumption that
you have network file volumes and a TCP/IP stack, but both of these have
been commercially available for quite a while.

I'd be interested in hearing of experiences or implementations from
anyone else has looked at this problem,

but please, no flames about DOS and/or OS/2, I am not interested in any
Operating System holy wars.  I am only interested in the communications
aspects of the problem.

  - Gordon


-- 
=============================================================================
Gordon Lee                 gordon@banyan.com
Banyan Systems, Inc.
Westboro, MA 
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 00:32:48 GMT
From:      paperboy!snorkelwacker!ira.uka.de!smurf!wrkof!dksoft!dirk@think.com  (Dirk Koeppen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP and UDP socket write limits
Where can I find information about the length I can write to a UDP or
TCP socket. On my system (386/ix) I found out (try and error method)
that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are
limited to 4096 byte per write. There are some calls to increase the
SOCK_STREAM buffer size but can I rely that another system will accept
> 4096 byte packets ? Can't I let the kernel do the fragmentation ?

cu,
Dirk Koeppen
dirk@incom.de
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 May 90 07:41:30 EST
From:      seadog!stan@uu.psi.com (Stanfield L. Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Local bridge w/SNMP
>Date: 23 Apr 90 20:24:12 GMT
>From: Mitch Wood
>Organization: Federal Express Corp., Memphis, TN
>Subject: LoNeed Local Bridge w/SNMP
>
>Does anyone have a suggestion for a Local Bridge with SNMP support?
>
>thanx in advance
>Mitch Wood`
>

Emerging Technologies Inc has a PC-based local bridge which supports SNMP.
Its a hybrid bridge (it supports concurrent IP router and MAC-level
bridging), and it can support up to 4 Ethernet networks. It uses the 
Western Digital WD8013E 16-bit card. Runs on any 25mhz AT, and the 
software is fairly inexpensive (about $1K).

 They are on Email: etinc!info@uu.psi.com

Stan

-----------------------------------------------------------------
Real Name : Stanfield L. Smith           USmail : CNS Enterprises
Internet  : stan@seadog.cns.com                 : P.O. Box 1127
UUCP      : uupsi!seadog!stan                   : Lk Ronkonkoma
Phone     : 516-737-2238                        : New York 11779
-----------------------------------------------------------------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 May 90 14:21:59 CDT
From:      cei001@uc.msc.umn.edu
To:        tcp-ip@NIC.DDN.MIL
Subject:   IP based job submission services..
I'm am sure that this story has been told before but I can't find it 
in the archives:

A large organization decides to get its act together and connect the
numerous machines with an open and robust communication network based on
TCP/IP.  Everything gets installed just fine, and the next day people are
telnet'ing and ftp'ing to their hearts content. (Sounds great, doesn't it?)

Now along comes a user who wants to do "batch" processing.  He'd like to 
"submit" a job to another system.  Imagine his surprise to find no popular
IP service for this. He protests the "new" network and in order to avoid 
deinstalling the entire net, the organization quickly establishshes a RJE
network (or equivalent) of sync lines  between the very same host.

Is it possible that there is some answer to this problem, and it just hasn't
made it out to the commercial market yet?  The only two published services
I can find is the (old?) RJE spec, and the NQS code.  Are there other common
ones that I'm missing?

I am interested in who's running what out there in field for this problem..

Now for the one little question I had (and I will repost this to IBMTCP list):

Is there any sites that have a method for IP systems to submit MVS jobs?

(On most other systems, ftp [or mail!] and some deamons will work..)
-------
John Curran  
Engineering Computer Services
Asea Brown Boveri 
(203) 285-652                      cei001@uc.msc.umn.edu
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 12:48:52 GMT
From:      mcsun!ukc!axion!masalla.fulcrum.bt.co.uk!igb@uunet.uu.net  (Ian G Batten)
To:        tcp-ip@nic.ddn.mil
Subject:   Bootp, Rarpd Wanted

I'm looking for sources to either an implementation of bootp or, failing
that, rarp.  It's for System 5, but I'd be happy with anything Unix-y!

Thanks for any pointers

ian
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 19:29:54 GMT
From:      mcsun!unido!fauern!fauern!eckert@uunet.uu.net  (Toerless Eckert)
To:        tcp-ip@nic.ddn.mil
Subject:   FAX over IP software wanted.
Sorry, i lost all my pointers on this subject.
Can anyone give me a hint, where to find such a beast ?

Thanks
-- 

Toerless Eckert     Internet: eckert@informatik.uni-erlangen.de
                    X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 May 90 23:15:57 GMT
From:      spdcc!ima!minya!jc@husc6.harvard.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Addressing SNMP proxy agents
Hi, y'all.  My question today is triggered by a request by the folks I'm
working for that I see if our SNMP agents can be made to act as proxies
for machines that don't talk IP.  On perusing rfc1085, I get the impression
that it is supposed to be possible.  On the other hand, I don't quite know
enough to be able to say for sure how the code should be modified, if it
is even possible.

Several times in the past, I've written proxy agents for other configurations,
but then I've always had the advantage of writing both the client and the
agent code, so of course I could make them understand each other.  In this
case, I'm just the proud posessor of the source code to the agent, which is
expected to talk to assorted SNMP clients from assorted vendors.  This isn't
too surprising; this is what SNMP is all about, after all.

My problem is that I can't quite determine from the rfcs just what sort of
byte string (ASN.1, of course) to expect from a client that has sent me a
message.  The current agent only understands addresses like:
	40 4 16 121 0 95
where 40=IPaddress, 4 is the size, and the address is 16.1212.0.95.  We've
gotten a couple of sessions together to bat about ideas, and the ways this
might be extended to indirect through a proxy, well, let's say that if you
have N people in the discussion, you probably have N*log(N) ways of doing
the job.

What I'm interested in is hearing how others expect this to work.  If you
are writing an application that deals with proxy agents, what sort of
addresses will you be sending my agent?

To make things more concrete, suppose that behind the above proxy agent,
which is listening on the SNMP port, we have a bunch of machines on the
local FOOnet, and they have n-byte addresses.  These could be represented
in various ways, such as a string:
	4 3 54 71 71
where 4=string, 3 is its size, 54='f', 71='o', etc.  The easiest way to
combine this with the agent's IP address would be as a 7-octet string:
	40 7 16 121 0 95 54 77 71
This is, of course, far too simple-minded for any self-respecting hacker 
(oops, I mean professional software engineer) to even consider, so obviously
it's not correct, and we must think of another method.  One possibility 
is to combine them into an ASN.1 sequence:
	30 14 40 4 16 121 0 95 54 77 71 4 3 54 71 71
Many other possibilities come easily to mind, especially after a few
drinks (or perhaps something stronger than ethanol :-).  I'd like to
find out which (if any) are "correct", and also which are likely to
be encountered in the Real World.  (Note the implicit admission that
these aren't synonymous.)

On reading rfc1085, I find mention of something called a "presentation
selector", though I can't find anything that tells me how to recognize
one when it bites me.  There's also a comment mentioning a 16-bit port 
number, as well as something about a set indicating which transport 
services are available.  I speculate that this has something to do 
with the problem but I can't quite decide what.

The whole problem is, of course, isomorphic to the older problem of
routing to indirectly reach machines that can't be reached directly.
We know lots of ways of doing this, and it's obvious that the SNMP
people, as well as the CMIP people, have considered it.  They even
seem to have decided that they've solved the problem.  Now someone
should be getting across to dummies like me just what the solution(s)
might look like.

I'd prefer email responses, since I've been sort of falling behind in
reading all the netnews that I should...

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 12:07:48 -0700
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        uunet!think.com!barmar@uunet.UU.NET (Barry Margolin)
Cc:        tcp-ip@nic.ddn.mil, hwajin@uunet.UU.NET
Subject:   Re: TCP and UDP socket write limits
>     
>     In article <982@dksoft.incom.de> dirk@dksoft.incom.de (Dirk Koeppen) writes:
>     >that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are
>     >limited to 4096 byte per write. There are some calls to increase the
>     >SOCK_STREAM buffer size but can I rely that another system will accept
>     >> 4096 byte packets ? Can't I let the kernel do the fragmentation ?
>     
>     There's should be no necessary relationship between kernel buffer size and
>     packet/datagram sizes for stream sockets.  Stream sockets are byte streams,
>     and they can be packetized arbitrarily.  During TCP connection setup each
>     side tells the other the largest packet size it's willing to accept.  Also,
>     while the connection is open windows are increased and decreased to
>     accommodate the receiver's available buffer space.  There kernel will have
>     to buffer data and/or block the sending process in order to accommodate the
>     other system's limits.
>     
>     Barry Margolin, Thinking Machines Corp.

the socket level buffering is mostly independent of the protocol level buffering.
tcp connection goes through max segment negotiation at the connection setup
time but this is unrelated to the socket level buffer size; it is more 
dependent upon the mtu of the interface you're using.  (see in tcp_mss()
in tcp_input.c in 4.3 bsd tahoe tcp/ip implementation).  the receive side
tcp buffer window adjustments are related to the socket level buffer
space.  tcp uses the size of socket level buffers in calculating its receive
window size.  the socket level buffers are mbufs whose size can be adjusted
via setsockopt() commands SO_RCVBUF and SO_SNDBUF.  the default values for
these buffers in stock 4.3 bsd tahoe tcp/ip are: tcp-receive (4K), 
tcp-send (4k), udp-receive (4k), udp-send (2k).  if not enough space is
available at the socket level and you're sending large piece of buffer
you'll get an EMSGSIZE error.

hwajin
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 00:36:53 GMT
From:      usc!samsung!munnari.oz.au!metro!bunyip!cuscus.cc.uq.oz.au!ggm@ucsd.edu  (George Michaelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Could MX <pref> be made to do more?
craig@NNSC.NSF.NET (Craig Partridge) writes:

>> this means.... your mail sits in the local queue.
>Why are all the MX RRs on the wrong side of the pipe?? 

Good question. In general, one does not have control over the MX
records of ones elders and betters (c/f kre@munnari.oz.AU) 
or (being less flippant) of distant hosts. 

>In general, your lowest MXs ought to be very close to your system.  So
>if you miss munnari, you oughtta be getting an MX nearby.

I'm confused by the "your" in there. Whose MXs should be close to me?
*my* MX records are: 0 myself 100 munnari 200 uunet.uu.net

but thats how I assert people should reach me. In sending stuff outwards
its "their" MX I'm using and for a.n.other's MX records you are dependant
on the sanity of the individual unknown sysop. 

Munnari, in offering wildcard MXs for "big" networks is doing me a favour
so I don't want to cause any ill feeling there. Do they need gentle hints
about extending their MX structure?

	-George
--
	George Michaelson
Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD Australia 4067. 
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 May 90 09:09:18 PDT
From:      braden@venera.isi.edu
To:        cei001@uc.msc.umn.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  IP based job submission services..

	Is there any sites that have a method for IP systems to submit MVS jobs?

	(On most other systems, ftp [or mail!] and some deamons will work..)

The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS,
supports batch submission via SMTP.

Bob Braden

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 02:35:59 GMT
From:      spdcc!ima!minya!jc@husc6.harvard.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there SNMP Certification Testing?
In article <EMV.90Apr20103423@duby.math.lsa.umich.edu>, emv@math.lsa.umich.edu (Edward Vielmetti) writes:
> In article <9004200313.AA22741@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>    ... Now add
>    a full-time neutral coordinator, ready to work with the various 
>	communities,from small startups, to the researchers, to big dinosaurs, 
>	to users, and we might catalyze the process.
> 
> Ah, but who will pay the salary of this full-time coordinator?  You're not
> going to find too many volunteers for the task.
> sounds like real work (but interesting) to me.

Yah; I've been volunteering for such a lab at various places for years,
and I've even been told I'd be good at it.  ("Man, you sure know how to
find ways to make things fail!" ;-)  So far, everyone thinks it's a real
good idea, but they want someone else to pay for it.

And people wonder why our stuff doesn't interoperate very well.

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 08:50:17 cst
From:      (strick) <strick@ttuvm2.ttu.edu>
To:        TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU
Subject:   Re:  IP based job submission services..
>        Is there any sites that have a method for IP systems to submit MVS jobs?
>
>        (On most other systems, ftp [or mail!] and some deamons will work..)
>
>The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS,
>supports batch submission via SMTP.
>
>Bob Braden

How can I get more information about UCLA ACP?

strick

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 03:48:21 GMT
From:      spdcc!ima!minya!jc@husc6.harvard.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Is the hostname "foo" or "foo.bar.com"?
While I'm at it, I'll ask another question that has triggered a raging
religious war at work.  The subject summarizes it, but I oughta give
some more details.

At this site, and at several others I've seen, there are some machines
on which if you type a 
	hostname
command you get a response like:
	foo.bar.com
while on other machines, you would get only
	foo
with the domain junk added by the mailer.  The managers of each sort
of machine generally insist that they are doing it right, and it's the
idiots who do it the other way that are responsible for all the network
screwups that result.

I've just spent an hour or so perusing the RFCs, and I can see why there
is a question.  There seems to be no unambiguous definition of "hostname"
that I can find.  There are several apparently-relevant passages, but it
doesn't take a fine legal mind to pick holes in the wording of any of them.
For instance, in RFC883 we find:

|   The labels must follow the rules for ARPANET host names.  They must
|   start with a letter, end with a letter or digit, and have as interior
|   characters only letters, digits, and hyphen.  There are also some
|   restrictions on the length.  Labels must be 63 characters or less.
|
|   For example, the following strings identify hosts in the ARPA
|   Internet:
|
|      F.ISI.ARPA     LINKABIT-DCN5.ARPA     UCL-TAC.ARPA

This is at first glance self-inconsistent.  At second glance, we see that
it in fact doesn't state the rules for a "hostname"  It says that "labels"
contain only letters, digits, and hyphen.  Leaving aside the question as
to whether two hyphens might be legal, we just note that the "foo.bar.com"
faction would simply say "Fine, the *label* `foo' follows the rules, and
the hostname is `foo.bar.com'."  But the above examples aren't actually
stated to be hostnames; they are rather "strings [that] identify hosts",
something to which both factions would readily agree.  The "foo" faction
would note that "foo.bar.com" identifies a host, and consists of two main 
portions:  "foo" is the hostname, and "bar.com" is the (2-level) domain.

My only contribution to this battle so far is to mention that I've seen cases
in which a mailer would take a name like "foo.bar.com" and append the domain
"bar.com" to it, giving "foo.bar.com.bar.com".  Then there's the fun you can
have if JNET is involved: "com.bar.foo.bar.com".  This is clearly brain damage
on the part of the mailer; it can be fixed easily by telling the kernel that
its hostname is "foo".  This also satisfies my penchant for less typing, so
I tend to go with it.  But it'd be nice to know which (if any) is correct.
It'd also be nice to have an official document to point to to settle the
debate when it rears its time-wasting head again.

There is also the problem with a hostname of foo.bar.com, in that many common
commands (such as who) truncate the hostname to N bytes, where N is typically
in the 10-16 range.  The truncated output of such programs can't be used as 
input to others, because the "hostnames" don't match anything in /etc/hosts, 
although that's where they came from.  Of course, this can happen with the
short form, since the RFCs state that 40-char names are legal, but have you
tried using one?

Part of the basis of the battle is that both factions "prove" their point
of view in terms of /etc/hosts.  The "foo" crowd says that a proper entry
looks like:
	16.37.91.42	foo foo.bar.com baz fliorph
while the "foo.bar.com" faction insists that the entry should read:
	16.37.91.42	foo.bar.com foo baz fliorph
It's easy to show that BSD systems (and sendmail) require that the first
field of the localhost's entry by the same as the output of the hostname
command.  If this isn't true, things can get very weird.  But experiment
doesn't seem to say which is the One True Host Entry.  It does show that
if both ends of a conversation do it differently, things can also get a
bit weird.

Anyone know what the answer to this is?  (If history is any guide, I'd 
expect followups proving that both are correct, and I'll have one more
entry in my growing list of Why Networks Are So Messed Up. ;-)

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 11:30:23 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        jc@minya.uucp
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Is the hostname "foo" or "foo.bar.com"?

John:

I think the proper answer to your question is:
    
	``who cares what hostname says?''

Hostname is simply a UNIX program to let you give your host a name.  It
has no standing in the Internet protocol suite.

What the RFCs are about is what comes out of your system.  On that subject,
they're pretty clear (see RFCs 1122 and 1123).  You're supposed to deliver
fully qualified domain names to the outside world.  If you want to lie
internally to your users and call yourself "foo" that's your problem --
just make sure that when the mail comes off your host, it reads
"foo.bar.com"

That having been said, there's considerable annecdotal evidence that using
just "foo" is a mistake.  Users assume that the name space is universal,
and will do things like tell their colleagues at other companies that
their e-mail address is "joe@foo" -- which isn't true, the actual address
is "joe@foo.bar.com"  The result is upset and confused users -- if they
learn to think of their host as "foo.bar.com" they won't make this
mistake.  [Hunt-and-peck typists will grumble briefly about the extra
typing and then write their own shell scripts so they can connect to
their favorite hosts by just typing "foo"]

Craig
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 11:03:37 cst
From:      (strick) <strick@ttuvm2.ttu.edu>
To:        TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU
Subject:   ACP basic info...
>The UCLA ACP software is available from UCLA for a $500 handling fee,
>it includes most but all of the source code... the JOB Submittal code
>is not available in source form as it was funded by IBM Federal Systems
>Division.
>
>I'll be away until the end of the month, if you have any other questions
>or wish to secure our code, with the limitations outlined, we can talk
>more then.
>
>-- Denis DeLaRoca
>   UCLA Office of Academic Computing

Thanks for your response.  My director has OK'd payment of the $500.

I need to find out What language(s) the code is written in.  Also, what
hardware does the program use to connect to ethernet?

Steve Strickland
Mgr. Network Services
Texas Tech University

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 05:06:23 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP and UDP socket write limits
In article <982@dksoft.incom.de> dirk@dksoft.incom.de (Dirk Koeppen) writes:
>that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are
>limited to 4096 byte per write. There are some calls to increase the
>SOCK_STREAM buffer size but can I rely that another system will accept
>> 4096 byte packets ? Can't I let the kernel do the fragmentation ?

There's should be no necessary relationship between kernel buffer size and
packet/datagram sizes for stream sockets.  Stream sockets are byte streams,
and they can be packetized arbitrarily.  During TCP connection setup each
side tells the other the largest packet size it's willing to accept.  Also,
while the connection is open windows are increased and decreased to
accommodate the receiver's available buffer space.  There kernel will have
to buffer data and/or block the sending process in order to accommodate the
other system's limits.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 17:07:57 -0700
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        uunet!ucsd.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!@uunet.UU.NET, enea!mats@uunet.UU.NET (Mats Josefsson)
Cc:        tcp-ip@nic.ddn.mil, hwajin@uunet.UU.NET
Subject:   Re: The best TCP/IP implementation to base a port on?
>     
>     We're in the process of implementing the TCP/IP protocol suite on a
>     Motorola 680x0 based system. It is running a Real-Time Operating
>     system radically different from Unix (more about that below).
>     

what is the name of the OS?  i work for wind river systems which develops &
sells a realtime OS and development environment called VxWorks for 
a wide variety of motorola 680x0 based VME SBC's.  VxWorks comes complete 
with 4.3 bsd tahoe tcp/ip, socket interface, NFS client implementation, RPC, etc.

>     It should be possible to boot our system from a Unix host over
>     Ethernet (this will require a minimal implementation of ARP/RARP,
>     BOOTP and TFTP, right?).
>     

you'll definitely need ARP and TFTP (or FTP), but not necessary either BOOTP
or RARP unless you don't know your Internet address at the time you boot your
machine.  if you're putting in the tcp/ip code in your EPROM,
when the board powers up you can change the boot parameters (via a command
line interface) or just use the default parameters to initialize the 
network device with a set Internet address, in which case you don't have
to use RARP or BOOTP to get boot info.  if you don't know the file name
your loading or need some vendor specific info at boot time, you'll need 
to use BOOTP rather than RARP.  overall, this is not a hard problem compared to
the rest of the work you'll need to do to port/implement tcp/ip on your OS.

>     1. Which TCP/IP implementation would be the best to start from? My
>        understanding is that we could use the 'BSD 4.3-Tahoe'
>        implementation. It is free (with some restrictions), implements
>        most of the required functionality, and it is widely used. I'm sure
>        there are several other alternatives.
>     

the 4.3 bsd tahoe tcp/ip code is one of the best implementation (if not the
best).  many people are familiar with it and many are still working on 
some incredible optimization work.

>     The Real-Time OS we are using supports processes with hard
>     priorities, messages between processes, shared memory, semaphores,
>     timers, interrupt handlers etc.  It is very fast. Process switch and
>     message sending takes about ten microseconds (on a 25 MHz MC68020).
>     

gee... this sounds awful familiar to our system (minus tcp/ip and other
networking stuff) ... 8-)

hwajin bae
wind river systems,
emeryville, california, usa

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 May 90 11:53:24 CDT
From:      pdurrant@ub.d.umn.edu (Paul Durrant)
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Is the hostname "foo" or "foo.bar.com"?
Mr. Chambers,

    I'd appreciate learning what responses you get to the question
on the subject line.

Thanks, Paul Durrant
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 09:03:17 GMT
From:      paolo@semto.sem.it (Paolo Zeppegno)
To:        comp.protocols.tcp-ip
Subject:   help with ntp

Hi, here is a very simple question.

I have a very small network, just a couple of machines (more to come
real soon now) running ultrix 3.1. I have compiled ntp and I would like
to have the clocks in my network synchronized. How do I do it? My brain
is probably dead, but the doc is very hard to understand.  Keep in mind
that I have no access to any reference clock.

Thanks a lot in advance.
	Paolo Zeppegno

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 May 90 16:32:12 EDT
From:      Bob Haring-Smith <RHH@brownvm.brown.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Tektronix emulation
Does anyone know of software permitting Tektronix emulation over tcp/ip?
The sorts of connections for which I'm interested in this are PC to
MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT.  Thanks.
                                           --Bob
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 14:19:52 GMT
From:      netnews.upenn.edu!eniac.seas.upenn.edu!tao@rutgers.edu  (Chun Tao)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270
I'm looking for the sources of tn3270 wrote by Mark Solomon from U. of Wisc.
(not Berkeley version).  Anyone can tell me where I can get this.  Please
e-mail to tao@eniac.seas.upenn.edu.  Thanks.

Regards,
Chun Tao


Chun Tao
tao@mickey.nic.kingston.ibm.com
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 14:50:17 GMT
From:      strick@TTUVM2.TTU.EDU (strick)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP based job submission services..

>        Is there any sites that have a method for IP systems to submit MVS jobs?
>
>        (On most other systems, ftp [or mail!] and some deamons will work..)
>
>The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS,
>supports batch submission via SMTP.
>
>Bob Braden

How can I get more information about UCLA ACP?

strick

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 15:30:23 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Is the hostname "foo" or "foo.bar.com"?


John:

I think the proper answer to your question is:
    
	``who cares what hostname says?''

Hostname is simply a UNIX program to let you give your host a name.  It
has no standing in the Internet protocol suite.

What the RFCs are about is what comes out of your system.  On that subject,
they're pretty clear (see RFCs 1122 and 1123).  You're supposed to deliver
fully qualified domain names to the outside world.  If you want to lie
internally to your users and call yourself "foo" that's your problem --
just make sure that when the mail comes off your host, it reads
"foo.bar.com"

That having been said, there's considerable annecdotal evidence that using
just "foo" is a mistake.  Users assume that the name space is universal,
and will do things like tell their colleagues at other companies that
their e-mail address is "joe@foo" -- which isn't true, the actual address
is "joe@foo.bar.com"  The result is upset and confused users -- if they
learn to think of their host as "foo.bar.com" they won't make this
mistake.  [Hunt-and-peck typists will grumble briefly about the extra
typing and then write their own shell scripts so they can connect to
their favorite hosts by just typing "foo"]

Craig

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 19:32:31 GMT
From:      new@louie.udel.edu  (Darren New)
To:        tcp-ip@nic.ddn.mil
Subject:   Estelle Specifications On-Line
This is an announcement of the availability of specifications written
in the Estelle formal description technique. 


These specifications are provided as a public service.  The only requirement
for obtaining any specifications so available are the following:
1) Your name, organization, state, and country are provided in the
   request.  This is to allow us to send updates and to stay in touch
   with other users of Estelle. It would be best to specify enough
   information that anyone worldwide could contact you via postal mail.
   This list will be distributed only to others on the same list; if you
   so specify, we will avoid distributing your information at all.
2) Your email address is provided. Contact us if email is inapproriate;
   we will try to accomodate your needs.
3) You agree to the disclaimer below.


We also have various tools and memoranda concerning Estelle. Contact
GROPE@UDEL.EDU for details. The NIST also provides an assortment of
tools; see below.

It is hoped that others will contribute specifications of real-world
protocols. Appropriate credit will of course be given and any copyright
restrictions will be observed. I hope this will become a major resource
in the research and engineering community.

In addition, additions to the "people" list and the "biblio" list are
welcome.

Points of contact at University of Delaware:
  amer@udel.edu		-- Prof. Paul Amer -- Advisor
  new@udel.edu          -- Graphical Representation of Protocols in Estelle
  chun@udel.edu         -- Test Sequence Generation from Estelle
  chamber@udel.edu      -- Adding Broadcast, RendezVous, and Real-Time
                           to Estelle.
  est-specs@udel.edu    -- Currently aliases to new@udel.edu. This is where
                           to send requests for specs. This may eventually
                           become automated or moved to another individual.
  grope@udel.edu        -- Requests about Graphical Representation Of
                           Protocols in Estelle (aka GROPE).

Unless otherwise noted in the individual specification, the following
conditions are taken to apply:

This specification and all derivative works are copyright 1990 by the
University of Delaware. All Rights Reserved.

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the names of the copyright holder or author not be
used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission.

BOTH THE AUTHOR AND THE COPYRIGHT HOLDER DISCLAIM ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER OR THE
AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.


The specifications which are commented as "compilable" means that the
specification has been checked and found to be statically correct
using the version of PET available 5/1/90 from NIST. It does NOT mean
that the specification is an official standard, nor does it mean that
the specification is complete or correct relative to the English 
version of the standard. Even some of the "non-compilable" specs
can be compiled with the NBS prototype compiler.

  WISE is available directly from National Institute of Standards
  and Technology (NIST, formerly NBS), without whose help GROPE would
  never have come to be.
    >From: Rachid Sijelmassi <sijel@apm1.ncsl.nist.gov>
    >Organization: National Institute of Standards and Technology (NIST)
    >Sub-Organization: National Computer Systems Laboratory
    >
    >The latest version of WISE is available by anonymous FTP
    >from osi.ncsl.nist.gov.  The code for WISE is part of
    >the OSIkit package, so you can take all or part of it.
    >Once you are on osi.ncsl.nist.gov, go to pub/osikit.
    >You will find the Estelle-to-C compiler (estpc.tar),
    >the ASN1 tool (asnfvt.tar), Wizard (estwizard.tar),
    >WISE (estwise.tar) and the manuals (mansrc.tar).
  Please note that to translate from Estelle to Smalltalk,
  estwizard.tar will be needed in addition to estwise.tar.

Files you should receive:
  README		-- This file
  biblio		-- A bibliographic database of FDT infomation
                           (Scribe/LaTeX format)
  people		-- Other people to whom this has been sent
  vtp.e			-- ISO Virtual Terminal Protocol
  sess.e		-- ISO Session Layer
  ntp.tex		-- RFC1119 Network Time Protocol
  ip.e			-- CLNP in Estelle
  ab.e			-- Alternating Bit (again)
  bump.e		-- R. Tenney's bumpgame 
  fep.e			-- The Fact Exchange Protocol

 Thanks for your interest!       -- Darren


------------------------------------------------------------
These people are already on the list and will receive the
first batch of specs:

alex@comsys.COM  -- IF I CAN GET TO YOU! MY HOST DOES NOT KNOW COMSYS.COM
dabbous@mirsa.inria.fr
thomson@unix.sri.com
calvert@cs.utexas.edu
mondain@iro.umontreal.ca

Others are expected shortly as the result of mailing this announcement
to various conference-proceedings lists.   Thank you  -- Darren
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 May 90 20:32:12 GMT
From:      RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith)
To:        comp.protocols.tcp-ip
Subject:   Tektronix emulation

Does anyone know of software permitting Tektronix emulation over tcp/ip?
The sorts of connections for which I'm interested in this are PC to
MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT.  Thanks.
                                           --Bob

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 02:30:28 GMT
From:      law@louie.udel.edu  (Jeff Law)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is the hostname "foo" or "foo.bar.com"?
In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>John:
>I think the proper answer to your question is:
>	``who cares what hostname says?''
>
>Hostname is simply a UNIX program to let you give your host a name.  It
>has no standing in the Internet protocol suite.

>That having been said, there's considerable annecdotal evidence that using
>just "foo" is a mistake.  Users assume that the name space is universal,
>and will do things like tell their colleagues at other companies that
>their e-mail address is "joe@foo" -- which isn't true, the actual address
>is "joe@foo.bar.com"  The result is upset and confused users -- if they
>learn to think of their host as "foo.bar.com" they won't make this
>mistake.  [Hunt-and-peck typists will grumble briefly about the extra
>typing and then write their own shell scripts so they can connect to
>their favorite hosts by just typing "foo"]
agreed.  you wouldnt believe how true this is...  we found out the hard way,
we've changed all the machines we run to return fully qualified hostnames...

interesting side effects are that braindamaged mail agents work much better
with the rest of the world now.   you will never see a mail message like

From: Joe User <user@supid>

from any of our machines...  whatever you set hostname to will be returned 
as the official name when gethostname is called..   mucho better!

now i wont mention what YP and some braindamaged shell scripts that only
looked for unqualified hostnames think of this change :)

jeff


-- 
Jeff Law
University of Delaware  PHONE: (302)-451-8005 work, (302) 731-1462 home
E-Mail: law@ee.udel.edu, UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!law
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 May 90 11:03 CDT
From:      "Paul W. Fakler" <PWF@vx.acs.umn.edu>
To:        tcp-ip@nic.ddn.mil, bobr@dbm1.mpc.af.mil
Subject:   Re:  Bad domain name
>From:  Robert Reed <bobr@dbm1.mpc.af.mil>
>As one of the AF.MIL domain name servers, I have noticed that you are one
>of the 100 sites that are sending queries for the address of 
>
>    GENTER-ADAM.AF.MIL
>
>As this name is not in the domain, and has never been, these queries are
>a large overhead with no payback.  We receive an average of 1500 per hour
>just for this host.
>
>Please help us trace down where these queries are originating from.  Any info
>will be welcome, address of originating host, or a copy of mail that is 
>generating the request.

I checked out the information in the nameserver on vx.acs.umn.edu, and found
a record for GENTER-ADAM.AF.MIL listed as one of the root name servers!

> set q=ns
> .
Server:  vx.acs.umn.edu
Address:  128.101.63.1

(root)  server name = GENTER-ADAM.AF.MIL
(root)  server name = NS.NASA.GOV
...

Unless it happens again, I am assuming for the moment that a typo got into the 
configuration file on one of the root servers, and GENTER-ADAM.AF.MIL should 
have been GUNTER-ADAM.AF.MIL.  When I restarted the name server, the cache was 
initialized correctly (and had a root server record for GUNTER-ADAM.AF.MIL).

Paul Fakler.



My cache initialization file follows:
------------------------------------------------------------------------------
$ORIGIN .
                    99999999    IN      NS      NS.NIC.DDN.MIL.
                    99999999    IN      NS      C.NYSER.NET.
                    99999999    IN      NS      NS.NASA.GOV.
                    99999999    IN      NS      TERP.UMD.EDU.
                    99999999    IN      NS      A.ISI.EDU.
                    99999999    IN      NS      AOS.BRL.MIL.
;
NS.NIC.DDN.MIL.     99999999    IN      A       192.67.67.53
C.NYSER.NET.        99999999    IN      A       192.33.4.12
NS.NASA.GOV.        99999999    IN      A       128.102.16.10
NS.NASA.GOV.        99999999    IN      A       192.52.195.10
TERP.UMD.EDU.       99999999    IN      A       128.8.10.90
A.ISI.EDU.          99999999	IN	A	128.9.0.107
AOS.BRL.MIL.        99999999    IN      A       192.5.25.82
AOS.BRL.MIL.        99999999    IN      A       128.20.1.2
--------------------------------------------------------------------------------
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 May 90 18:38 PDT
From:      "Henry W. Miller" <HMILLER%SCU.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.MIL
Subject:   Ingres certification of TCP/IP
        We are in the process of augmenting our current TCP/IP software with
a version that is "Ingres certified".  I can't seem to get a decent answer
to what this means.  Can anyone out there fill me in?

        Thanks in advance,

-HWM
----------
Henry W. Miller
U.S. Bureau of Reclamation
Assistant Systems Manager, Mid Pacific Region
2800 Cottage Way, MP-1100
Sacramento, CA  95825
(916) 978-5108 / FTS 460-5108
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 13:29:01 GMT
From:      aecom!naftoli@uunet.uu.net  (Robert N. Berlinger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rlogin and security
In article <9004300749.AA01275@ISIS.U-STRASBG.FR> pansiot@isis.u-strasbg.FR
(Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur
Strasbourg FRANCE) writes:
>
>I know that rlogin is not secure, but its worse than what i thought.
>Basically with rlogin anybody can break into your computer (at leasr Sun,
>Silicon Graphics,...) provided you have entries in your /etc/passwd with
>*  as a password. I thought * was used to forbid login, it is quite the
>contrary.
>Is this a well known Bug of rlogin?  Is there a Fix ?

I'm running SunOS 4.1 and don't have the same behavior.  Perhaps you left
the default /etc/hosts.equiv in place, which opens the host
to all other hosts in the NIS.
-- 
Robert N. Berlinger                 |Domain: naftoli@aecom.yu.edu        
Supervisor of Systems Support       |UUCP: ...uunet!aecom!naftoli
Scientific Computing Center         |CompuServe: 76067.1114@compuserve.com
Albert Einstein College of Medicine |AppleLink: D3913@applelink.apple.com
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 16:20:36 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is the hostname "foo" or "foo.bar.com"?
In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>[Hunt-and-peck typists will grumble briefly about the extra
>typing and then write their own shell scripts so they can connect to
>their favorite hosts by just typing "foo"]

Most TCP/IP's that I have abused (er ah used) have a feature that lets
you say telnet foo when you mean telnet foo.bar.com.  That is they add
the current domain to the name if there are no dots (some do even if
there are).  Others there is a list of domains to append to the
hostname when trying.   The only draw back to doing a "hostname
foo.bar.com" in your rc.local (or where ever) file is that the default
csh prompt is "foo.bar.com% " rather than "foo% ".

Warner Losh		imp@Solbourne.COM
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 16:27:13 GMT
From:      mcsun!cernvax!chx400!hslrswi!aut!huber@uunet.uu.net  (Daniel Huber)
To:        tcp-ip@nic.ddn.mil
Subject:   Connect AS/400 and UNIX (TCP/IP). HOW?

Hi

We have some UNIX Computers : 30 Sun's (SunOS 4), 34 HP's (HP-UX 7.0),
2 NCR's (SysV.2), 2 Plexus (SysV.2), some PC's (Interactiv UNIX), 
about 50 Mac's (MultiFinder) and about 120 PC's (MSDOS).
All are connected together with ETHERNET 802.3 (TCP/IP). Some Mac's 
with AppleTalk (there is actually a GatorBox in test for AppleTalk - 
TCP/IP connectivity).

Then I have an AS/400 and 2 System/36. ;-( 

My problem is: 
	How can I connect the AS/400 and /36's to the UNIX-TCP/IP
	world.

I've tried with an ASTEK-Box (Mytek). Works ok (ftp, telnet), but we 
need more.

We want something like NFS.

How can I realise that.

-	Is it true that AS400 supports TCP/IP ? 

-	Can I directly connect an AS400 to 802.3 ?

-	Is there a product for "NFS" filesystems, from and to AS400 
	( UNIX <-> AS400) ?

-	I heard something about OS/2 EE 1.2. What's that ? 
	(could be a similar thing as OS/2-LanManager for sharing AS400
	disk with OS/2-PC's ? Or perhaps a gateway between SNA and 
	TCP/IP ?)

-	If OS/2 EE is a software (like LanManager), does it run with 
	Microsoft's LanManager for OS/2, so I'm able to export AS400
	directories via OS/2 EE and OS/2-LanManager to LanManager/X
	an then to other users. 
	Utopia ? Who knows ?

     

Please e-mail, if you can help me.

Thanks

	Daniel
-- 
Daniel Huber		Tel.	+41 31 52 96 64
Ascom Autelca		Fax.	+41 31 52 77 45
CH-3073 Guemligen	email:	huber@aut.uucp
Switzerland		uucp:	uunet!mcsun!cernvax!hslrswi!aut!huber
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 18:02:00 GMT
From:      usc!snorkelwacker!spdcc!xylogics!transfer!lectroid!jjmhome!cpoint!frog!barr@ucsd.edu  (Chris Barr)
To:        tcp-ip@nic.ddn.mil
Subject:   /etc/hosts used for 2 protocols' addresses
I'd like to use an IP-format /etc/hosts file to lookup network addresses
used by a another protocol run on the same host.  (The addresses happen to
be Ethernet card hardware addresses.)  I wonder if anyone else has
faced this question of entering a second network address in /etc/hosts.
TCP/IP will continue to use the same /etc/hosts file.

The simplest extension seems to be using the comment field for the 2nd
protocol's address  ----------------
                                    |
                                    v
nnn.nnn.nnn.nnn  name  name ...   # 0xnn0xnn0xnn0xnn0xnn0xnn

A new entry in /etc/protocols doesn't make sense, because this protocol 
doesn't use IP.

Thanks, in advance, for any comments.

barr@frog
{!harvard !mit-eddie} !frog!barr
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 20:37:19 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Tektronix emulation
In article <9005040701.AA12937@ucbvax.Berkeley.EDU>, RHH@BROWNVM.BROWN.EDU (Bob
Haring-Smith) writes:
> Does anyone know of software permitting Tektronix emulation over tcp/ip?
> The sorts of connections for which I'm interested in this are PC to
> MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT.  Thanks.
>                                            --Bob

There are a couple of packages that you might want to look at.  One is the
NCSA telnet for the PC and Mac that does tektronix 4014 emulation.  Our product
TCP/Connect II does 4014 emulation on the PC and Mac, as well as IBM 3278
emulation.

We also have a package called InterCon Telnet Driver which runs on the Mac
and allows VersaTerm Pro (tek 4105 emulation) and MicroPhone II to run over
a telnet session.

You can get NCSA telnet from zaphod.uiuc.edu (I believe).

You can get info on TCP/Connect II and the Telnet Driver by dropping a note
to comment@intercon.com or to me.

Hope that helps.--
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 21:57:31 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!mike@ucsd.edu  (Mike Trogni)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA Telnet availability
In article <2641E7FF.3E13@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes:
>
>You can get NCSA telnet from zaphod.uiuc.edu (I believe).
>

actually its available from ftp.ncsa.uiuc.edu which is Cname for zaphod.ncsa.
uiuc.edu (128.174.20.50).

- mike
--
mike@uxa.cso.uiuc.edu
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 May 90 23:27:41 GMT
From:      phoenix!phoenix.princeton.edu!eho@princeton.edu  (Eric Ho)
To:        tcp-ip@nic.ddn.mil
Subject:   PPP ??
I'm not sure if these are the right newsgroups to send to but I'm interested
in knowing current developments concerning PPP.  I would be very much
appreciated if anyone can give me any pointers on this.
--

Eric Ho  
Princeton University
eho@clarity.princeton.edu
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 01:16:51 GMT
From:      excelan!manoj@ames.arc.nasa.gov  (manoj @ Prod Mktg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Tektronix emulation
In article <9005040701.AA12937@ucbvax.Berkeley.EDU>, RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) writes:
> Does anyone know of software permitting Tektronix emulation over tcp/ip?
> The sorts of connections for which I'm interested in this are PC to
> MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT.  Thanks.

A number of coompanies offer tektronix term. emulators that write to int14
or int6b and can be used as is on top of tcp/ip networks that have int14 & 6b
support..

With LAN WorkPlace for DOS (Novell's TCP/IP for DOS), these are some of the
3rd party term emulators..
	walker richer quinn, seattle, WA
	kea systems, vancouver , canada
	softronics,
	grafpoint, saratoga, ca 
	persoft,
	polygon,
	diversified computer systems

thx..
	manoj goel,                             	0 0
        Product Marketing                        	 ^  
        Novell/Excelan Inc., San Jose, CA            	\_/	
  (408) 473-8369 (voice) / 433-0775 (fax)     Internet: manoj@novell.com 
___________________________________________________________________________
	"For every vision, there is an equal but opposite revision"

          __  
        ((__ \ 
           \\ ! 
            !!!  
        o_@@--.\  
        (___,  /
         ___! !             	Regards!
        / .-! !   _) 
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 01:23:15 GMT
From:      van-bc!mplex!fff@ucbvax.Berkeley.EDU  (Fred Fierling)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: The best TCP/IP implementation to base a port on?
In article <9005040007.AA13233@yuba.WRS.COM>, hwajin@yuba.UUCP (Hwa Jin Bae) writes:
> >     1. Which TCP/IP implementation would be the best to start from? My
> >        understanding is that we could use the 'BSD 4.3-Tahoe'
> >        implementation. It is free (with some restrictions), implements

From where can you get BSD 4.3-Tahoe TCP/IP? 
-- 
Fred Fierling   uunet!van-bc!mplex!fff    Tel: 604 875-1461  Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC   V5T 1A7,  Canada
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 01:38:00 GMT
From:      HMILLER@SCU.BITNET ("Henry W. Miller")
To:        comp.protocols.tcp-ip
Subject:   Ingres certification of TCP/IP


        We are in the process of augmenting our current TCP/IP software with
a version that is "Ingres certified".  I can't seem to get a decent answer
to what this means.  Can anyone out there fill me in?

        Thanks in advance,

-HWM
----------
Henry W. Miller
U.S. Bureau of Reclamation
Assistant Systems Manager, Mid Pacific Region
2800 Cottage Way, MP-1100
Sacramento, CA  95825
(916) 978-5108 / FTS 460-5108

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 02:19:10 GMT
From:      CCECHAN@NUSVM.BITNET (Luther Chan)
To:        comp.protocols.tcp-ip
Subject:   How to turn RIP off in Sun 3/50??

Dear Networkers,

Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4?
Please tell where is the file contain the switch and the file name.

Thank you in advance!

Luther

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 02:19:52 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is the hostname "foo" or "foo.bar.com"?
In article <376@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
> It's easy to show that BSD systems (and sendmail) require that the first
> field of the localhost's entry by the same as the output of the hostname
> command.

I know of a few thousand hosts running 4.3BSD networking code and sendmail
which violate this rule, and send and receive mail all over the Internet,
UUCP, BITNET, and beyond.  These machines are configured so that `hostname`
returns "foo", but the moral equivalent of gethostbyname("foo") returns an
pointer to foo.bar.com as the first name.


Vernon Schryver
vjs@sgi.com
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 02:29:41 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@ucsd.edu  (Don Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Bad domain name
In article <9D496D584DDFE0551B@UMNACVX.BITNET> PWF@VX.ACS.UMN.EDU ("Paul W. Fakler") writes:
>>From:  Robert Reed <bobr@dbm1.mpc.af.mil>
>>As one of the AF.MIL domain name servers, I have noticed that you are one
>>of the 100 sites that are sending queries for the address of 
>>
>>    GENTER-ADAM.AF.MIL
>>
>>As this name is not in the domain, and has never been, these queries are
>>a large overhead with no payback.  We receive an average of 1500 per hour
>>just for this host.
>>
>>Please help us trace down where these queries are originating from.  Any info
>>will be welcome, address of originating host, or a copy of mail that is 
>>generating the request.
>
>I checked out the information in the nameserver on vx.acs.umn.edu, and found
>a record for GENTER-ADAM.AF.MIL listed as one of the root name servers!
>
>> set q=ns
>> .
>Server:  vx.acs.umn.edu
>Address:  128.101.63.1
>
>(root)  server name = GENTER-ADAM.AF.MIL
>(root)  server name = NS.NASA.GOV
>...
>
>Unless it happens again, I am assuming for the moment that a typo got into the 
>configuration file on one of the root servers, and GENTER-ADAM.AF.MIL should 
>have been GUNTER-ADAM.AF.MIL.  When I restarted the name server, the cache was 
>initialized correctly (and had a root server record for GUNTER-ADAM.AF.MIL).

Ah, GENTER-ADAM.AF.MIL is back again.  I haven't seen that one in a couple
of months.  Last week it was SRI-NIC.ARPA and BRL-AOS.ARPA.  I don't think
the fault lies with the root name servers, it is mainly due to
misconfiguration the name servers for some of the subdomains, typically
in-addr.arpa subdomains.

Let's say that hosts X and Y are listed as the name servers for
xxx.128.in-addr.arpa.  Now lets assume that Y thinks that GENTER-ADAM
is one of the root name servers.  If host Z queries host Y for the
PTR record for aaa.bbb.xxx.128.in-addr.arpa, and host Y is *not*
actually a name server for xxx.128.in-addr.arpa, then host Y will
respond with a referral message.  In this example the message will
contain an empty answer section, a list of the root name servers
in the authority section, and the addresses of these name servers
in the additional section.  Now host Z will believe that
GENTER-ADAM.AF.MIL is a root name server.  If Z is also listed
as a name server for a zone that it is not actually a server for,
it will in turn pass on this information.

I have also observed hosts returning a list of the root name
servers in the authority section when in fact they are authoritative
name servers for the domain, but I don't know whether this is
due to broken software or some other type of misconfiguration.

Let's stamp out DTB's (DNS Transmitted Bogosities)!

Now as far as the large number of queries to the root name servers
is concerned, there appears to be a nasty bug in BIND 4.8.1,
and probably other versions as well.  When a resolver is referred
to a name server in order to the answer a query and it does not
have the address of the name server, the resolver must start
a second query for the address of the name server.  In BIND,
if the result of the query for the address of the name server
is a CNAME, it is not smart enough to follow the CNAME to
get the address.  If the result is NXDOMAIN, this information
is not cached.  Now if one of the name servers that BIND doesn't
have an address for is one of the *root* name servers, this will
probably happen quite a lot considering that BIND has to consult
the root name servers in order to look up the address of one of the
root servers.  It gets worse if there are other problems, like
unreachable name servers if BIND's clients don't understand
how to correctly deal with temporary failure and keep retrying.
I've seen its rubber band get wound pretty tight.

I keep hearing rumors of a new version of BIND, but I haven't
seen any official word.  Having negative caching and a few
bug fixes would help the situation a lot.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Sat, 05 May 90 18:27:20 -0700
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        uunet!ucbvax.Berkeley.EDU!van-bc!mplex!fff@uunet.UU.NET (Fred Fierling)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: The best TCP/IP implementation to base a port on?
> >From where can you get BSD 4.3-Tahoe TCP/IP? 
> -- 
> Fred Fierling   uunet!van-bc!mplex!fff    Tel: 604 875-1461  Fax: 604 875-9029

via anonymous ftp or uucp from uunet machine.
look under the directory: /usr/spool/ftp/bsd-sources

hwajin
wind river systems


-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Sat, 05 May 90 09:17:48 SST
From:      Luther Chan <CCECHAN%NUSVM.BITNET@CUNYVM.CUNY.EDU>
To:        Vivian Neou <TCP-IP@SRI-NIC.ARPA>
Subject:   How to turn RIP off in Sun 3/50??
Dear Networkers,

Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4?
Please tell where is the file contain the switch and the file name.

Thank you in advance!

Luther
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Sat, 05 May 90 17:42:24 EDT
From:      "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: IP based job submission services..
On Wed, 2 May 90 14:21:59 CDT <cei001@UC.MSC.UMN.EDU> said:
>Now along comes a user who wants to do "batch" processing.  He'd like to
>"submit" a job to another system.  Imagine his surprise to find no popular
>IP service for this. He protests the "new" network and in order to avoid
>deinstalling the entire net, the organization quickly establishshes a RJE
>network (or equivalent) of sync lines  between the very same host.

John,  Another approach is simply to run NJE as an application on top of
TCP/IP.  This is being done by about 100 sites worldwide, using the
BITNET II protocol (for NJE over TCP) developed at Princeton University
and implemented for IBM VM systems by Princeton University (VMNET); for
VMS systems by Joiner Associates (JNET TCP NJE) and Hebrew University of
Jerusalem (HUJI-NJE); and for Berkeley Unix systems by Harvard University
(UREP TCP/IP) and Technion-Haifa.
  Lee Varian  lvarian@pucc.princeton.edu
  Princeton University
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 17:18:00 GMT
From:      ogicse!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!gupta@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   protocol tester wanted


I'm looking for a C package that can be used to test various protocols over
a network. I'm currently trying to port x-kernel, but am wondering if there
are any other packages (preferably ones that don't simulate an entire kernel!)
that will do the job.

Please email all replies to rohit@uiuc.edu because I do not read this group.

Thanks in advance!
Rohit


NOTE: this is being cross-posted to a couple of groups, my apologies if you see
it more than once...

-------------------------------------------------------------------------------
Internet:rohit@uiuc.edu   UUCP:uunet!uiucuxc!ux1!gupta   BITnet:GUPTA@UIUCVMD

"There are no good wars, with the following exceptions:  the American
Revolution, World War II, and the Star Wars Trilogy..."
                                                -- Bart Simpson
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 19:18:11 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Bridges not passing bcasts (update)
In article <7594@uswat.UUCP>, matthews@uswat.uswest.com (John Matthews) writes:
> Please give a little detail if possible. What other bridges does everyone
> know about that learn these bad source addresses?


I can also confirm the reports, but what you really need to know is that this
bad behaviour is the result of a bug in V2.0 ROMs. If you get your ROMs
updated, the problem will go away.
					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 May 90 21:42:24 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: IP based job submission services..

On Wed, 2 May 90 14:21:59 CDT <cei001@UC.MSC.UMN.EDU> said:
>Now along comes a user who wants to do "batch" processing.  He'd like to
>"submit" a job to another system.  Imagine his surprise to find no popular
>IP service for this. He protests the "new" network and in order to avoid
>deinstalling the entire net, the organization quickly establishshes a RJE
>network (or equivalent) of sync lines  between the very same host.

John,  Another approach is simply to run NJE as an application on top of
TCP/IP.  This is being done by about 100 sites worldwide, using the
BITNET II protocol (for NJE over TCP) developed at Princeton University
and implemented for IBM VM systems by Princeton University (VMNET); for
VMS systems by Joiner Associates (JNET TCP NJE) and Hebrew University of
Jerusalem (HUJI-NJE); and for Berkeley Unix systems by Harvard University
(UREP TCP/IP) and Technion-Haifa.
  Lee Varian  lvarian@pucc.princeton.edu
  Princeton University

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 May 90 20:50:38 GMT
From:      minya!jc@eddie.mit.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is the hostname "foo" or "foo.bar.com"?
In article <18464@nigel.udel.EDU>, law@udel.EDU (Jeff Law) writes:
> In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
> >John:
> >I think the proper answer to your question is:
> >	``who cares what hostname says?''

For starters: sendmail, rsh, rcp, telnet, gethostbyname(), ...

> >Hostname is simply a UNIX program to let you give your host a name.  It
> >has no standing in the Internet protocol suite.

If true, then how could SMTP ever possibly work?  One of the documentable
anomalies is host foo.bar.com calling bletch.org's SMTP port, and one of 
them rejecting the other because they disagree on the hostname convention.
If there were a paragraph in an RFC I could point to, perhaps I could say
"All you guys doing it *that* way are wrong."  But it looks like I can't
say that, so the turkeys will continue insisting they're right, and the
anomalies will continue.

> agreed.  you wouldnt believe how true this is...  we found out the hard way,
> we've changed all the machines we run to return fully qualified hostnames...
> 
> now i wont mention what YP and some braindamaged shell scripts that only
> looked for unqualified hostnames think of this change :)

But this is the whole point of the question.  Personally, I think that any
software that can't handle both conventions is braindamaged.  But I can't
correct them all; I don't have the time or the source code.  

Perhaps I could ask it this way:  Suppose we were to uniformly adopt one
convention of the other.  Is there a straighforward way to identify the
programs that have problems with it, and diddle their config files so they
work correctly?  If this can be answered for one convention or the other,
that would also answer the original question, at least for pragmatists
like me.

BTW, are you aware that there are systems being sold that limit hostnames
(sometimes doubling as sysnames or nodenames) to 16 bytes?

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 May 90 23:08:41 GMT
From:      phri!news@nyu.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   How to discover current list of DNS root servers

	If I want to find out the most current list of DNS root servers,
does it suffice to run nslookup and do the following?

> server suspected.root.server
> set type=ns
> .
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Mon,  7 May 90 14:24:36 -0500 (CDT)
From:      Wayne Richardson <wdr+@rchland.ibm.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Connect AS/400 and UNIX (TCP/IP). HOW?
 Daniel,

 In response to your specific questions:

 1) Yes, there is a new LP for the AS/400 called TCP/IP Connectivity
    Utilities.  It started shipping 1/26/90.  The S/36 is still only
    available through Business Partners (like Mytek).

 2) The AS/400 only attaches through 802.5 (Token-Ring) in the
    initial release, but native Ethernet V2 and 802.3 are coming
    very soon (there are SOD's for them now).

 3) NFS Server is also a Statement-of-Direction, but is farther
    out than 802.3.

 For everyone, there is an excellent list of all the IBM platforms
 and what they support in the way of TCP/IP, OSI, LU6.2, etc.
 It is a list that came out when the RS/6000 was announced and is
 titled, "IBM Interoperability for SAA and AIX environments".

 The Date on it is 900215, and the Number is 290-070.

 It talks about everything from SAA compilers to SNMP to X.400
 and should be available through the IBM branches.  It may answer
 a lot of questions like yours.

         Bob Dick
         TCP/IP DCG 51E/015-2, (507) 253-3014
         Rochester, Minnesota  55901
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 09:26:01 GMT
From:      mcsun!hp4nl!tnosoes!tom@uunet.uu.net  (Tom Vijlbrief)
To:        tcp-ip@nic.ddn.mil
Subject:   A SUSPICIOUS SECURE GATEWAY
I modified a version of Phil Karns KA9Q internet package
so it acts as a suspicious secure gateway.

The goal of this gateway is to establish security of a local network
at the gateway instead of securing every host on your local network.

One would for example disallow excess to rlogin, rsh, ftp and telnet
because many users have bad passwords.

I'll make the binary and sources available to those who are
interested. 

The README follows. (start reading at 'Security Features' if
you are only interested in the secure gateway extensions)

I would like to receive suggestions and comments about this package.
=====================================================================
Microsoft C 4.00 Changes to KA9Q
================================

The assembler files are translated to a format suitable for the
MASM assembler.

The clocktick rate has been increased from 1 tick per second to
10 ticks per seconds. (This is useful for fast transmission paths
like ethernet).

A little bug in the ping command (Concerning echo timing) has been fixed.

One can now specify TCP receive window and mss sizes which are different
from the send sizes. The is needed for dumb ethernet cards (3C501, 3C503)
which are easily overrun when a fast TCP peer (e.g. a Sun) sends bursts
of ethernet packets.
'tcp rwin 512' and 'tcp rmss 512' are appropriate values.

Some little improvements has been made to the TCP timeout mechanisms.

The file 'autoexec.net' is now searched for in the working directory and
subsequently in the root. (This allows easy customization for different
users).

Command line arguments are now interpreted as NET commands.
(It used to be the name of a startup file).
These commands are executed after the default startup file has been
read. Multiple command may be given when delimited by ';'.
The FTP server now recognizes printer names, so you can use NET
as a print server. (e.g.: put text lpt1).
Function keys are transmitted as \033[ sequences. (Useful for emacs, etc).

Four additional commands has been added:

	funkeys [on|off]

funkeys on will disable Functionkey-10 so one can use emacs. Abort is
by means of CTRL-FN10 when funkeys are on.

	rsh host command

will execute a shell command on the specified host by means of the 
rexecd(8) or rshd(8) daemon.

	uprsh file host command

acts like rsh but gives file as standard input.

	buprsh file host command

acts like rsh but gives binary file as standard input.
Before a rsh command may be given you should identify yourself
by means of the name command. ("name username password" or
"name username RSH localname" for use of rshd instead of rexed).


examples:

DOS PROMPT> net rsh rainbow date

will show the date on the unix host rainbow and return to DOS.

DOS PROMPT> net uprsh \mail\greeting rainbow mail tom

will mail the contents of DOS-file \mail\greeting to tom from host
rainbow.

DOS PROMPT> net buprsh \dos\del.com rainbow cat ">" binfile

will copy the contents of DOS-file \dos\del.com to "binfile"
in your home directory on host rainbow.


A new server has been added. This server allows a tcp-stream to
a serial line (COMx) or the screen of a PC. (Could be used for a 
remotely accessible printer).

start com 20000 1 silent

This starts the server which listens on port 20000 and directs all
incoming data to the first attached serial line. (Use 0 for the screen).
In the attach command one should specify the COM-port, baudrate, etc.
(E.g.: "attach asy 0x3f8 4 slip sl0 1024 576 9600").
If the fourth argument is omitted then diagnostic output will be
printed on the screen. (E.g.: "Incoming com session from.....")


A WD8003E ethernet driver has been added.


This version of the KA9Q internet package has been tested on a
IBM-AT communicating with Suns running SunOS 3.2/3.5/4.0.3 and Masscomps.
Slip has also been tested.

SMTP mail has been tested.

The log command now has an onscreen option which duplicates messages
on the screen. The logfile is now cyclic and will be rewritten after
500kB of messages. When net is started it will begin writing at the
start of the logfile. The best strategy is to start with a logfile
with a (random) contents of about 501kB. This will garantee that
messages can be logged even if the disk is completely full.

The NET program can act as a real gateway by giving an ethernet interface
a different IP address:

gateway ec0 [131.34.2.8]

On this gateway interface is only ping (= ICMP Echo Request) allowed.

SECURITY Features
=================

This version of net can act as a secure gateway between a local net
and an external IP network.

It allows connections to be initiated from the local network(s) to the
external network(s) but it disallows all connection attempts from the
external networks(s) the the local network(s).

Note that the gateway itself is always accesible over all interfaces.
So it can act as FTP server for the external insecure networks.
(This has ofcourse a negative impact on its performance as a
secure internetwork router.)
Be carefull to configure the file '\ftpusers` before you start FTP service
with the 'start ftp' command. Disallow access to the root directory or the
NET binary!


The insecure external network interface has to be attached with a name
that starts with 'Se' (Secure).

The local network(s) has to be specified with the command:

secure localnet <network>[/<bits>]

Example: secure localnet [140.24.67]/24

This will add the specified network to the list of protected (local) networks.

The protection is established by examination of packets which enter the network
over the 'Secure' interface:

1:
==
A packet which has an IP-source which matches one of the specified local
networks is considered a faked packet and is simply dropped. A warning
is written in the logfile.

2:
==
Every UDP packet with a port destination number < 1024 is rejected
with an ICMP Port Unreachable message.

3:
==
Every TCP packet with a port destination number < 1024 is rejected
with an ICMP Port Unreachable number.

4:
==
ICMP redirect packets are dropped.

5:
==
Source Routed packets are rejected with an ICMP Parameter Problem.


Local networks (or hosts) can be completely isolated from the external networks
by specifying a 'sink' route. The will reject EVERY packet with an
IP-source or IP-destination that matches the specified sink route with
an ICMP Host Unreachable message.

Example:

route add lonely sink
route add [140.24.67.128]/25 sink

A local network can be completely isolated with the exception of 1 or more
specific hosts by:

route add [197.25.45.0]/25 sink
route add [197.25.45.128]/25 sink
route add [197.25.45.212] ec0
route add [197.25.45.213] ec0

Tracing
=======

The command: secure trace on
will trace incoming packets on the 'Secure' interface. Remember that
turning trace on has a negative impact on routing performance.

Creating (dangerous) exceptions
===============================

It is possible to allow TCP connections to special hosts in order to
establish anonymous FTP connections or incoming mail.

This can be very dangerous because many older Unix FTP- and SMTP-
(= sendmail) daemons have dangerous security holes. A safe alternative
is to use a PC which runs this NET program as anonymous FTP server.

Many mail SMTP (and FTP) daemons have the famous Morris internet worm holes.
Do not allow connections until you are certain that your version is
secure. The safest way to assure this is to install the latest
Berkeley sendmail and ftpd sources which are publicly available.
The use of mail-aliases which resolve to programs (like |uudecode) is
also considered insecure.

This is an extract of:
===============================================================================
			    CERT Advisory
			    March 19, 1990
		      Internet Intruder Warning
-------------------------------------------------------------------------------
3) Exploit holes in sendmail.

   Make sure you are running the latest sendmail from your vendor.
BSD 5.61 fixes all known holes that the intruder is using.  


4) Exploit bugs in old versions of FTP; exploit mis-configured
   anonymous FTP

   Make sure you are running the most recent version of FTP which is
the Berkeley version 4.163 of Nov.  8 1988.  Check with your vendor
for information on configuration upgrades.  Also check
your anonymous FTP configuration.  It is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.).  Note especially that you should not use your
system's standard password file as the password file for FTP.

9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
entries.  Some alias files include an alias named 'uudecode'; if this
alias exists on your system, and you are not explicitly using it, then
it should be removed.
=========================End of extract===============


After you have convinced yourself that your Unix servers are really
secure you can execute an secure allow command.

Example: secure allow mailhost TCP 25

This will allow TCP connections to be established over the Secure
interface to tcp port 25 on host 'mailhost'. 25 is the TCP port number
of the SMTP mail daemon.

The general syntax is:

secure allow <host/ALL> <TCP/UDP/RPC-UDP> <port/ALL> [source-host]

If no source-host is specified then it defaults to ALL.

RPC-UDP specifies a filter which examines UDP packets and determines
if these packets are RPC calls to a RPC based server. The port number
contains the RPC program number which should be filtered.

Example:

sec allow ALL RPC-UDP 100012 ALL


One can also specify disallows:

secure disallow <host/ALL> <TCP/UDP/RPC-UDP> <port/ALL> [source-host]

Example:

secure disallow ALL RPC-UDP ALL

NOTE that 'disallow' specifiers always overrule 'allow' specifiers
except 'allows' which have specified all four fields without any 'ALL' wildcard.

===============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23				Phone: +31 34 63 562 11
3769 ZG  Soesterberg			E-mail: tnosoes!tom@hp4nl.nluug.nl
The Netherlands				or: uunet!hp4nl.nluug.nl!tnosoes!tom
===============================================================================
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 May 90 11:26:21 N
From:      virchaux%CLSEPF51.BITNET@CUNYVM.CUNY.EDU (Jacques Virchaux)
To:        tcp-ip@nic.ddn.mil
Subject:   Upgrade kit LAN100 -> LAN150
Does anyone know if there is a kit available to upgrade a LanBridge 100 to a
LanBridge 150. DEC offers an exchange rather expensive and there are only
two PROMs to change and one wire to add !
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 12:54:32 GMT
From:      daemon@tut.cis.ohio-state.edu  (Bob Dixon)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM Batch Job Submission via tcp/ip
The ACC implementation of tcp/ip (called Access/Mvs) allows easy submission
of batch jobs via ftp, using the "site submit" option.

                                        Bob
-------
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 14:39:42 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!terminator.cc.umich.edu!bryan@ucsd.edu  (Bryan Beecher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How to discover current list of DNS root servers
In article <1990May6.230841.11143@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
>
>	If I want to find out the most current list of DNS root servers,
>does it suffice to run nslookup and do the following?
>
>> server suspected.root.server
>> set type=ns
>> .

The only way to make sure you've got the current list of root
servers is to pick up a copy of NETINFO:ROOT-SERVERS.TXT from
the NIC.  The suspected.root.server could have all kinds of
bogus NS RR's for root in its cache along with the list of
correct ones (which could be incomplete or incorrect itself).
--
Bryan Beecher, U-M Information Technology Division  (+1 313 747 4050)
Domain:	bryan@terminator.cc.umich.edu  Path: mailrus!terminator!bryan
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 16:13:53 GMT
From:      mcsun!cernvax!chx400!hslrswi!aut!huber@uunet.uu.net  (Daniel Huber)
To:        tcp-ip@nic.ddn.mil
Subject:   UUCP over TCP/IP with HP9000/835S (HP-UX 7.0) ?????
I tried to set up uucp connections to other computers on our ethernet.
But UUCP over TCP/IP seems not working with HP-UX 7.0 and 835S.
I have HDB on both sides, or uucp version 2.
HP9000/835S called is "aut" (HDB), other machine is NCR Tower 650 SysV.2 
(HDB) called "telsys", or a Plexus P75 SysV.2 (uucp V2) called "autte".

Here are my File entrys:

Systems:
telsys Any telsys Any nophone "" \d "" \r ogin: nuucp ssword: uucpuucp
autte Any autte Any nophone "" \d "" \r ogin: nuucp ssword: uucpuucp

Devices:   I tried many different entrys
telsys - - Any TCP
or
telsys TCP - Any TCP
or
telsys TCP - - TCP
and more....
(similar entrys for autte)


Permissions:
#entry for system called "telsys"
MACHINE=telsys LOGNAME=nuucp \
SENDFILES=yes REQUEST=yes CALLBACK=no \
READ=/usr/spool/uucppublic \
WRITE=/usr/spool/uucppublic \
COMMANDS=rmail:uux:uucp:pr

#entry for system called "autte"
MACHINE=autte LOGNAME=nuucp \
SENDFILES=yes REQUEST=yes CALLBACK=no \
READ=/usr/spool/uucppublic \
WRITE=/usr/spool/uucppublic \
COMMANDS=rmail:uux:uucp:pr

And that's what Uutry means:

# ~uucp/Uutry -r telsys
/usr/lib/uucp/uucico -r1 -stelsys  -x5 >/tmp/telsys 2>&1&
tmp=/tmp/telsys
mchFind called (telsys)
conn(telsys)
Device Type telsys wanted
mlock - succeeded
generic open failed, errno = 9
getto ret -1
Call Failed: CAN'T ACCESS DEVICE
exit code 101
Conversation Complete: Status FAILED




What's wrong? 
Does HP not support UUCP over TCP/IP ?


Please e-mail, if you can help me.

Thanks
	Daniel
-- 
Daniel Huber		Tel.	+41 31 52 96 64
Ascom Autelca		Fax.	+41 31 52 77 45
CH-3073 Guemligen	email:	huber@aut.uucp
Switzerland		uucp:	uunet!mcsun!cernvax!hslrswi!aut!huber
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 16:23:16 GMT
From:      hpfcso!hpldola!hpctdlb!hpctdkp!jeff@hplabs.hp.com  (Jeff Hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re: question about caching in UDP based RPC
>Caching can be thought of as a kludge which is needed to try to give
>UDP the same reliablity as TCP.  Why not use TCP directly?

I am not sure I follow your reasoning here. I believe that RPC provides
the necessary retransmission feature. Therefore, it is RPC which is 
attempting to provide the reliability of TCP, caching is a separate 
issue. 

TCP may be more desirable because it is usually tied more directly to 
the operating system and would perform better under heavy loads than
RPC/UDP (less likely to suffer retransmissions). Also, it would not
double buffer an RPC request because it only keeps around 1 copy of 
an incoming packet.

>Your cache will not ensure execute at most once behavior.  Think about
>a server and three clients.  The server gets an RPC from client 1,
>then 2, then 3.  But it must trash the cache from client 1 in order 
>to store client 3's result.  Now it gets a resend from client 1; it
>will execute the service routine a second time.
>The trick to caching UDP/RPC results it to cache exactly one result for 
>each client the server has.  The cost is 8K per client, max.  You never
>need to cache more than one response from each client, since a client 
>will only send a new RPC only if the old one has been completed.

This is a good idea. I believe there are some exceptions to the 1 reply
per request rule, however. I believe the "spray" application will blast
a host with a number of packets before requiring a reply. 

Also, keep in mind that this caching scheme will not work for RPC/TCP
connections where batched RPC is being used. Again, multiple requests 
will be received before a response is required.



*** These opinions are my own, blah, blah, blah ***********

jeff@hpctdlb.hp.com
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 17:21:22 GMT
From:      news@psuvax1.cs.psu.edu  (Daniel Ehrlich)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How to turn RIP off in Sun 3/50??
In article <9005050218.AA16274@ucbvax.Berkeley.EDU> CCECHAN@NUSVM.BITNET (Luther Chan) writes:

Luther> Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4?
Luther> Please tell where is the file contain the switch and the file name.

If you run routed there are two choices.  1) Stop running routed, in which
case you need to install a default route in rc.local at boot time. 2) Run
routed with the '-q' switch which says do not under any conditions send RIP
packets.

Hope this helps.

--
Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 May 90 19:10:20 GMT
From:      bywater!arnor!news@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   RE: IP based job submission services..
John Curran (cei001@uc.msc.umn.edu) writes:

>
> Is there any sites that have a method for IP systems to submit MVS jobs?
>
> John Curran

While IBM's TCP/IP for MVS does not provide this function today, we are
currently working on code which will allow remote job submission via FTP
and will distribute it via normal service channels when it is complete.

Bill Rubin
IBM TJ Watson Research
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 02:42:44 GMT
From:      CCECHAN@NUSVM.BITNET (Luther Chan)
To:        comp.protocols.tcp-ip
Subject:   SUN 3/50 PROBLEM: HELP

Hi,

Thanks for the two reply on my previous question about turn the RIP off.

Now I have a problem when the Sun 3/50 bootup, note I have not changed any-
thing yet.  The Sun 3/50 in here asked for Internet address after the selftest
but unable to abort the request.  The ethernet connector was terminated
without any external connection.  It act as a stand alone with a SCSI harddisk.
The harddisk did fail once and later it was working again. The symptom was
not the same as when the harddisk fail(was the handdisk unable to spin reported
).  I can get into the PROM but I do not know what can I do except reset the
system.   Anyone has any idea what can I do to make the request of
internet address by passed. (Note I have not been able to get to the login
prompt).

Luther Chan
PS. I am from National University of Singapore. This message has nothing to
do with the University. I am acting on my own opinion.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 05:08:55 GMT
From:      mailrus!cs.utexas.edu!samsung!munnari.oz.au!ditmela!yarra!melba.bby.oz.au!gnb@tut.cis.ohio-state.edu  (Gregory N. Bond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: help with ntp
In article <800@semto.sem.it> paolo@semto.sem.it (Paolo Zeppegno) writes:

   I have a very small network, just a couple of machines (more to come
   real soon now) running ultrix 3.1. I have compiled ntp and I would like
   to have the clocks in my network synchronized. How do I do it? My brain
   is probably dead, but the doc is very hard to understand.  Keep in mind
   that I have no access to any reference clock.

This is what I did here.  I run a network of some 20 Suns.

I used the talking telephone clock over a period of a week or so to
find a server with the smallest clock drift (in free-running mode, no
ntp or rdate etc).  It turned out (by luck) that my workstation has
the lowest drift of any I measured.

So I run my workstation as an NTP stratum-3 server, synced to the
local clock.   A second stable workstation syncs to my machine and
its own internal clock (at stratum-4) so will take over the time
server role if my machine dies.

All the file servers on my net (and the backup master) are synced to
my machine, and to one other server.

All diskless clients are synced to their respective file servers.

This means that I can set the absolute time from my workstation, and
the rest of the net will track it.  And my clock drifts only a few
seconds a week, so the effort is minimal.

Greg.

some ntp.conf files:

my workstation (the master):
----
#       ntp.conf file for baby - the master clock server
precision -7
tickadj 10
#       Use my clock as a reference
peer    /dev/null       LOCL    3       -5      local
------

One file server:
---
#       ntp slave server configuration
tickadj 10
precision -6

peer baby
peer sid
---

The backup server
---
# bottle : the backup time server
tickadj 10
precision -6

peer baby
peer melba
peer	/dev/null	LOCL	4	-5	local
-----
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 05:23:36 GMT
From:      cs.utexas.edu!execu!sequoia!sequoia.execu.com!dewey@tut.cis.ohio-state.edu  (Dewey Henize)
To:        tcp-ip@nic.ddn.mil
Subject:   Broadcasts and YP service(s)
Perhaps the collective wisdom of the net will come to my ignorant aid...

Our network is an 'interesting' collection of various machines,
including Suns, a Sequent, and an HP.

We are running YP (NIS now I guess).

In the past, we used one of the Suns, the Sequent, and the HP
(under HP-UP) as YP servers.  The Sun was/is the master, the
other two slaves.  Things went pretty well until recently when
we started added more machines and we noticed some pretty big
slowdowns.

Tracking things for a while, it became apparent that machines
that had bound to the HP for a YP server were getting slowed
down a LOT by the responses from it.  Since it was already as
unloaded as possible, I wanted to take it out of the YP server
business (I've got other machines I can draft later).

HOWEVER, if it doesn't come up with the ypserv daemon, it
doesn't seem to be able to find a ypserver anywhere.  Once they
are up, however, I can use ypset to redirect them to using other
servers and kill off the HP's ypserv daemon and go on merrily
about my business.

The only thing I can figure out is that the sequent and sun use
a broadcast of 130.211.200.0 (class B, subnetted) while the HP
appears to use 130.211.200.255.  I can't figure out any way to
make the HP use anything else, since the ifconfig on it doesn't
know about the broadcast parameter.

Ideas?  Suggestions?  Help!?

Thanks in advance.  I'm sure this is in TFM somewhere, but I
haven't been able to find it after looking all afternoon.

Dewey
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Tue 8 May 90 13:32:24-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        shelby!cis!interran@eos.arc.nasa.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
    I want the ping to tell me whether or not an attempt to connect to the
    TCP port would succeed (i.e., whether or not the TCP port's in use).
    How do I find out if a given TCP port on a given host is in use without
    affecting the remote program's behavior?

This is next to impossible.

The problem is that in theory, you can have any number of connections to
a particular tcp port, as long as the source host and/or port are different.
Thus you can have many connections to the SMTP or Telnet ports of a host,
and you can't easilly tell how many more will be accepted.

Of course, some host/port combinations are "stupid", and will accept only
one connection to a particular port.  (The obvious example being a port
tied to a particular line on a tcp terminal server.)  If you KNOW that
the port you are trying to reach is of this type, your best bet may be
to use a network managment protocol (eg SNMP) to see if that port already
has a connection.  Of course, this may be more expensive in many ways than
just trying the TCP connection...

Bill Westfield
cisco Systems.
-------
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue,  8 May 90 14:52:04 -0400 (EDT)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil, phoenix!phoenix.princeton.edu!eho@princeton.edu (Eric Ho)
Subject:   Re: PPP ??
> Excerpts from internet.tcp-ip: 4-May-90 PPP ?? Eric Ho@princeton.edu (264)

> I'm not sure if these are the right newsgroups to send to but I'm interested
> in knowing current developments concerning PPP.  I would be very much
> appreciated if anyone can give me any pointers on this.


The most recent developments:
1.  The IESG has recommended to the IAB that PPP be advanced to Draft
Standard status.
2.  Draft proposals for 802.3 and 802.5 Bridging and OSI Network Layer
over PPP have been submitted.
3.  Two PD implementations are available, one for 4.3 BSD the other for
KA9Q on PCs.  Another two for SunOs will become available shortly.
4.  A number of manufacturers have already implement/ported or plan to
implement/port PPP very soon.

Drew
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 May 90 21:09:18 -0700
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        uunet!mathom.cisco.com!BILLW@uunet.UU.NET
Cc:        shelby!cis!interran@eos.arc.nasa.gov, tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
>     I want the ping to tell me whether or not an attempt to connect to the
>     TCP port would succeed (i.e., whether or not the TCP port's in use).
>     How do I find out if a given TCP port on a given host is in use without
>     affecting the remote program's behavior?
> 
> This is next to impossible.
> 

using ping which uses ICMP for something like this is inconsistent.  ICMP
is at the same level as IP (network layer in osi terms) and has no relevant
information about the transport level concept of a "port" per se although
some transport protocol implementations make use of ICMP "port unreachable"
message type to tell the remote machine when there's no one bound to a
particular target port requested by incoming packets.

> The problem is that in theory, you can have any number of connections to
> a particular tcp port, as long as the source host and/or port are different.
> Thus you can have many connections to the SMTP or Telnet ports of a host,
> and you can't easilly tell how many more will be accepted.
>

i think the original question is asking for a way to tell whether or not it is
possible to make a connection.  a connection attempt will hang if there's
an existing connection between TCP sockets that are bound to the same
combinations of the port numbers (i.e. the case where the source port and
destination port combination is already being used by an existing connection
between the machines in question).  that is, i don't think he's asking 
for the number of max connections a server process is willing to accept on a
given listener port.  assuming that i'm interpreting his question correctly,
i'll say that pretty much the only way is to use the non-blocking I/O
on the socket (via FIONBIO ioctl command) and selecting on the writing
side of the socket with a set time limitation (an argument to select).
you'll do a ioctl of FIONBIO on the socket and then issue a connect on 
the socket and then select on the writing side for a give time.  if the
select times out you have not successfully connected to the remote machine
within a given amount of time.  you can try two things at this time:
(a) increase the time interval, or (b) try to use a different port number
on your side.  and try again until you succeed.  this procedure will help
when the remote machine refuses time out zombie sockets that are hung up
by some previous connections that are terminated inconsistenly.

hwajin,
wind river systems
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 09:45:56 GMT
From:      shelby!cis!interran@eos.arc.nasa.gov  (John Interrante)
To:        tcp-ip@nic.ddn.mil
Subject:   pinging a remote TCP port to see if it's in use
I would like to "ping" a program listening to a TCP port to find out
if it's alive without actually creating a connection to that program's
TCP port.  I want the ping to tell me whether or not an attempt to
connect to the TCP port would succeed (i.e., whether or not the TCP
port's in use).  How do I find out if a given TCP port on a given host
is in use without affecting the remote program's behavior?  (I don't
want the remote program to have to accept a new connection and then
tear it down.)

John Interrante    interran@lurch.stanford.edu
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 May 90 16:48:15 PDT
From:      Paul Mockapetris <pvm@ISI.EDU>
To:        swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!terminator.cc.umich.edu!bryan@ucsd.edu (Bryan Beecher)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: How to discover current list of DNS root servers
> In article <1990May6.230841.11143@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
> >
> >	If I want to find out the most current list of DNS root servers,
> >does it suffice to run nslookup and do the following?
> >
> >> server suspected.root.server
> >> set type=ns
> >> .
> 
> The only way to make sure you've got the current list of root
> servers is to pick up a copy of NETINFO:ROOT-SERVERS.TXT from
> the NIC.  The suspected.root.server could have all kinds of
> bogus NS RR's for root in its cache along with the list of
> correct ones (which could be incomplete or incorrect itself).
> --
> Bryan Beecher, U-M Information Technology Division  (+1 313 747 4050)
> Domain:	bryan@terminator.cc.umich.edu  Path: mailrus!terminator!bryan

I'd maintain that doing the query is EXACTLY the right way to get the
current list of root servers IF the suspected.root.server is chosen
from a reputable set.  Just as you know that NIC.DDN.MIL is the host
to FTP the NETINFO:ROOT-SERVERS.TXT file from, you could just as
easily know one machine that is a root server, say NS.NIC.DDN.MIL or
whatever.

paul
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 May 90 14:37:09 EDT
From:      BDK@UNB.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: IP based job submission services..
What about retreiving jobs? Is it in the same package?
Brian Kaye
University of New Brunswick
>
> While IBM's TCP/IP for MVS does not provide this function today, we
> are currently working on code which will allow remote job submission
> via FTP and will distribute it via normal service channels when it is
> complete.
> Bill Rubin
> IBM TJ Watson Research
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 May 90 09:36:05 SST
From:      Luther Chan <CCECHAN%NUSVM.BITNET@CUNYVM.CUNY.EDU>
To:        Vivian Neou <TCP-IP@SRI-NIC.ARPA>
Subject:   SUN 3/50 PROBLEM: HELP
Hi,

Thanks for the two reply on my previous question about turn the RIP off.

Now I have a problem when the Sun 3/50 bootup, note I have not changed any-
thing yet.  The Sun 3/50 in here asked for Internet address after the selftest
but unable to abort the request.  The ethernet connector was terminated
without any external connection.  It act as a stand alone with a SCSI harddisk.
The harddisk did fail once and later it was working again. The symptom was
not the same as when the harddisk fail(was the handdisk unable to spin reported
).  I can get into the PROM but I do not know what can I do except reset the
system.   Anyone has any idea what can I do to make the request of
internet address by passed. (Note I have not been able to get to the login
prompt).

Luther Chan
PS. I am from National University of Singapore. This message has nothing to
do with the University. I am acting on my own opinion.
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 12:46:12 GMT
From:      mcsun!unido!quando!wichert@uunet.uu.net  (Peter Wichert)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for fast file-transfer on ethernet

Hi,

I want to do a fast file-transfer between hosts using ethernet.

I have implemented a file-transfer based on the BSD socket interface
with TCP protocol. My problem is that the transmission rate is too slow,
so to speed things up I want to do the same with UDP protocol, but UDP
is unreliable.

What I'm looking for is an interface that supports reliable byte/sec streams
using UDP.

What does rcp use?, it is a lot faster than ftp'ing?

Any ideas ????

Many Thanks, for any replies.

Please DON'T send sources, send me mail first...

-- 
 Peter Wichert  UUCP:     {backbone}!unido!quando!wichert OR wichert@quando.uucp
  Quantum GmbH  Bitnet:   UNIDO!quando!wichert OR wichert%quando@UNIDO(.bitnet)
    Dortmund    internet: wichert%quando%unido.UUCP@mcsun.cwi.nl
    Germany     internet: wichert@quando.quantum.de
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 14:15:34 GMT
From:      sparkyfs!arsocomvax.socom.mil!news@ames.arc.nasa.gov  (Ted Nolan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PC-LAN connection to Usenet
>In article <4950@netxcom.DHL.COM> cmoussav@dhlmis.DHL.COM (C. Ognibene-Moussavi) writes:
>I am asking the following question on behalf of my husband - at his work 
>there is only a LAN - he would like to know what hardware, software and
>phone number he needs for a dial-up connection to Usenet - he would like
>to be able to read the newsgroups and post to them as well.

I think Lauren Weinstein wrote a  complete netnews/uucp (commercial) package
for DOS PCs a couple of years ago.  It may be that you could put this on one
PC and have the rest get at it over the LAN.  According to whois, his address
is:

Weinstein, Lauren (LW2)         Lauren@RAND.ORG
   Vortex Technology
   P.O. Box 1323
   Topanga, CA 90290
   (213) 455-9300



				Ted Nolan
				ted@usasoc.soc.mil
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 15:23:10 GMT
From:      usc!srhqla!nrcvax!bvs@ucsd.edu  (Bill Versteeg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
In article <INTERRAN.90May8024556@lurch.Stanford.EDU> interran@lurch.Stanford.EDU (John Interrante) writes:
>I would like to "ping" a program listening to a TCP port to find out
>if it's alive without actually creating a connection to that program's
>TCP port.


If the machine in question speaks SNMP, the information is available.
The easiest way to get it is using "snmpnetstat host_name community_string -a".
If you don't have snmpnetstat, a snmpwalk of the tcp group will do.

If the machine does not speak SNMP, you could log onto the machine and
use "netstat -a". 

Yet another example of why EVERYONE SHOULD IMPLEMENT SNMP!!!!


Bill VerSteeg
-- 
Bill VerSteeg
Network Research Corporation
170 Watermill Falls 
Alpharetta Ga. 30201					bvs@nrc.com
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 15:33:31 GMT
From:      usc!cs.utexas.edu!oakhill!guri@ucsd.edu  (Gurvinder Singh Ahluwalia)
To:        tcp-ip@nic.ddn.mil
Subject:   NNTP-socket-based News Interface (Eg: "rrn")

I am looking for a NNTP-based news reader interface like "rrn".
Currently we have a "rrn" binary in place [as also the "rn" 
scheme]. The "rrn" interface we have is either not complete
or terribly out-dated unless what we suffer from is due to an 
inherent drawback of "rrn". I do not know.

"rrn" we have does not give any WRITE capabilites to users, i.e.
one cannot follow-up ('f' or 'F') or reply ('r' or 'R') to a 
posting. Quite logically it follows that one also cannot 'postnews' 
through "rrn".

What I am interested in is any or all of the following:

1.	A cleaner and more complete implementation of "rrn", 
and/or more generally,
2.	An IP socket-based (NNTP or other) Bulletin Board/News Reader 
	interface that works.

Are there any out there running or aware of such implementations?

We have the GNU Emacs package that comes with a built in
NNTP-based news reader interface. Emacs is something that many 
do not use and we are looking for a more common-place alternative 
that would keep the user-learning curves and migration to new 
Bulletin Board features simple and minimal.

I would also like to hear if the capabilities we lack in "rrn"
are endemic to it or is there someone running "rrn" with write 
capabilities (say, comparable to "rn") other than thru GNU Emacs.
Also, it is not clear whether the "rrn" deficiency we face is in 
the client part or server or both.

I would prefer EMail. If there is interest, I shall consolidate
responses and post.

-----
Gurvinder Ahluwalia		Internet: guri@apogee.sps.mot.com
Software Engineer 		UUCP	: <world>oakhill!apogee!guri@cs.utexas.edu
Global Networking		Phone	: 512/891-3310
MOTOROLA - SPS
Austin, TX 78735
-----
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 18:56:37 GMT
From:      usc!cs.utexas.edu!oakhill!guri@ucsd.edu  (Gurvinder Singh Ahluwalia)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
In article <INTERRAN.90May8024556@lurch.Stanford.EDU> interran@lurch.Stanford.EDU (John Interrante) writes:
>I would like to "ping" a program listening to a TCP port to find out
>if it's alive without actually creating a connection to that program's
>TCP port.  I want the ping to tell me whether or not an attempt to
>connect to the TCP port would succeed (i.e., whether or not the TCP
>port's in use).
... stuff deleted ...
>
>John Interrante    interran@lurch.stanford.edu

	I don't belive you can do this thru ping. ping is an echo
	program at the Network Layer (IP) (without a Transport Layer, 
	if you may). It does not take port connections into its folds.
	It uses "raw sockets" to interface between the Application and
	Network Layers.

	If you figure out a something to the contrary, I would like
	to know.

	Gurvinder.

----------
Gurvinder Ahluwalia		Internet: guri@apogee.sps.mot.com
Software Engineer		UUCP	: {}oakhill!apogee!guri@cs.utexas.edu
Global Networking		Phone	: 512/891-3310
Motorola SPS
Austin, TX
----------
#include	<std/disclaimer>
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 21:07:26 GMT
From:      cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!briand@tut.cis.ohio-state.edu  (brian donat)
To:        tcp-ip@nic.ddn.mil
Subject:   gated

Hello, 

Some time ago, somebody brought up a discussion aobut Dave Mill's 
Fuzzballs.   I'd like to dig up some further info on cost metrics,
so if anybody knows of any good references on this topic, could 
you please advise me. 

Also, I don't seem to be able to access 'devvax.tn.cornell.edu'
and would like to obtain gated.   Can anybody help me here? 

--briand
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 21:15:29 GMT
From:      ftp!fks@BLOOM-BEACON.MIT.EDU  (Frances Selkirk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Tektronix emulation
In article <1306@excelan.COM>, manoj@excelan.COM (manoj @ Prod Mktg) writes:

> With LAN WorkPlace for DOS (Novell's TCP/IP for DOS), these are some of the
> 3rd party term emulators..
> 	walker richer quinn, seattle, WA
> 	kea systems, vancouver , canada
> 	softronics,
> 	grafpoint, saratoga, ca 
> 	persoft,
> 	polygon,
> 	diversified computer systems

These packages are a good way to get many terminal emulator, especially 
those for graphics terminals. FTP Software's PC/TCP also supports INT-14
emulators. Any other compatible telnets/rlogins out there? 

To the list of companies making INT-14 emulators, you should add Pericom
and Mitek. Again, any others present or known?

						Enjoy!

							Frances


-- 

Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      8 May 90 22:09:18 GMT
From:      oliveb!orc!bu.edu!bu-it!kwe@apple.com  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <1158@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes:
> I modified a version of Phil Karns KA9Q internet package
> so it acts as a suspicious secure gateway.
> 
> The goal of this gateway is to establish security of a local network
> at the gateway instead of securing every host on your local network.
> 
> One would for example disallow excess to rlogin, rsh, ftp and telnet
> because many users have bad passwords.
> 

	Source address "authentication" is very weak security.  If you
allow any ftp connections to any host on your net, a way will be found
to attempt ftp connections to all your hosts.

	The path to good internet security is to build security hooks into
the protocol suite and the applications software and implement a robust
authentication protocol, like Kerberos or the Privacy Enhanced Mail protocol.
There are no shortcuts.  [Jon Rochlis from MIT has pounded this point
of view into my head.]

	The IETF is addressing this need by requiring security (among
other things) to be accounted for in every new protocol proposal.  Sort
of like a security environmental impact statement.  Steve Crocker of 
Trusted Information Systems is the Area Director of Security in the
IETF.  He is worrying about all kinds and levels of security.  This 
is a very active area of research in the IETF, in other words.  It
is affecting PPP, OSPF, BGP to name a few new protocols.  Stay tuned.

	Meanwhile, if you want to use this modified KA9Q, just be
aware of how weak this approach really is.

	--Kent
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 May 90 14:13:08 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        johns@hpwade.UUCP
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
Actually, there are at least three non-proprietary implementations of
SNMP available, of which you described one.  Parties interested in
hearing more about SNMP are invited to join the snmp list (drop a note
to snmp-request@nisc.nyser.net.)

/mtr
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 May 90 14:32:55 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        HAGGAR@bnr.ca (Haggar Alsaleh, H.)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IEEE 802.1 Network Management.
There is a "transmission working group" that is working on defining MIBs
for things below the IP (e.g., 802.3).  If you want to get on the
mailing list, send a note to trans-wg-request@nisc.nyser.net.

For the last couple of years, it has generally been felt that management
protocols specific to the data-link layer are not all that helpful.  The
reason is:

    If you have a well-engineered management protocol for your protocol 
    suite (e.g., the SNMP for the Internet suite of protocols), then the 
    additional amount of work required to implement the protocols
    between the data-link protocol and the management protocol, should
    be quite small.   In the case of the SNMP, you implement both the IP
    and the UDP.  Minimal implementations of these are straight-forward.

    Once you have these protocols in place, management requests can be
    fielded across an internet, instead of restricting them to the local
    LAN.  As such, you can do remote management of your LAN using the
    same applications and techniques that you use locally.  This gives
    you tremendous leverage!

    Of course, not all management protocols are this well-engineered.
    As such, other management frameworks may not enjoy this advantage.
    In brief, true power in a well-designed system comes from simplicity
    in design, not over-wrought complexity.

So, the answer to your question is: look at trans-wg if you're
interested in 802 managed objects ... and use the SNMP to manage them!

/mtr

Thank-you for your support! --the SNMP PAC	(-:
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 May 90 11:12:13 GMT-0400
From:      ad@cis.brown.edu (Arif Diwan)
To:        TCP-IP@nic.ddn.mil
Subject:   Returned mail: User unknown



							>>>Original Msg<<<
Most TCP/IP's that I have abused  (er ah used) have a feature that lets you say telnet  
foo when you mean telnet foo.bar.com. That is they add the current domain to the  
name if htere are no dots (some do even if  there are). Others there is a list of domains  
to append to the hostname when trying. The only draw back to doing a "hostname  
foo.bar.com" in your rc.local (or where eveer) file is that the default csh prompt is  
foo.bar.com%" rather than "foo%".
								>>EOM<<<

Actually the default prompt is usually set in the .cshrc file and one could use  
something similar to :

	set host="`whoami`@`hostname`"
        set host=`expr $host : '\([@a-zA-Z0-9]*\)'`
        set prompt="${host}> "

and the prompt would not be a problem either.

We have over a 1000 nodes and we use fully qualified 4 level domain names in most  
cases (We use 3 level names for major routers and just Brown.EDU for our main  
nameserver/router/etc). Within each sub-domain, we only have to specify the "1st"  
label, and never more than 2 labels to refer to any host within Brown.EDU using the  
usuall network client programs (telnet, ftp etc). We are using bind4.8.2+ resolver code.



-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 May 90 11:39:32 GMT-0400
From:      ad@cis.brown.edu (Arif Diwan)
To:        tcp-ip@nic.ddn.mil
Subject:   GENTER-ADAM.AF.MIL && BIND && root nameservers ...

							>>>Original Msg<<<
.... there appears to be a nasty bug in Bind 4.8.1 ...
								>>>EOM<<<

you should use bind4.8.2. You can get bind4.8.2.tar.Z from netlab.cis.brown.edu. It is  
in the pub directory.
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 May 90 11:45:56 GMT-0400
From:      ad@cis.brown.edu (Arif Diwan)
To:        tcp-ip@nic.ddn.mil
Subject:   Find out the current list of root nameservers

Roy -
	You got it right:

nslookup
> server suspected.root.server
> set type=ns
> .

This will give you the suspected server's current root cache.

You may want to compare that with ns.nic.ddn.mil 
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 05:24:17 GMT
From:      dna@psuvax1.cs.psu.edu  (Douglas N. Arnold)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP ??
> ... current developments concerning PPP.  I would be very much
> appreciated if anyone can give me any pointers on this.

>>  Two PD implementations are available, one for 4.3 BSD the other for
>>  KA9Q on PCs.  Another two for SunOs will become available shortly.

Available where?
--
Douglas N. Arnold                         dna@math.psu.edu
Dept. of Mathematics, Penn State Univ.    (814) 865-0246
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 07:20:09 GMT
From:      mcsun!hp4nl!tnosoes!tom@uunet.uu.net  (Tom Vijlbrief)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
kwe@bu-it.bu.edu (Kent England) writes:

>In article <1158@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes:
>> I modified a version of Phil Karns KA9Q internet package
>> so it acts as a suspicious secure gateway.
>> 
>> The goal of this gateway is to establish security of a local network
>> at the gateway instead of securing every host on your local network.
>> 
>> One would for example disallow excess to rlogin, rsh, ftp and telnet
>> because many users have bad passwords.
>> 

>	Source address "authentication" is very weak security.  If you
>allow any ftp connections to any host on your net, a way will be found
>to attempt ftp connections to all your hosts.

What do you mean ? Can you be a little bit more specific?

Authentication is not done on source address at all. One should
disallow all FTP connections from the outside world, except to a
special host. If this host is the PC which runs the gateway software
than you can be sure that NO ONE WILL EVER access a FTP server on any
other host on your local network from the outside internet.

The idea is to make inaccessible well known ports from the outside
internet except those you need to establish mail and FTP connections.

Filtering is done on destination port number, there is no way you
can break this if it is properly implemented. Prove me wrong.


>	The path to good internet security is to build security hooks into
>the protocol suite and the applications software and implement a robust
>authentication protocol, like Kerberos or the Privacy Enhanced Mail protocol.
>There are no shortcuts.  [Jon Rochlis from MIT has pounded this point
>of view into my head.]

This is nice but it does not help when it is not implemented
in vendors software. Kerberos and other authentication protocols
are needed when possible intruders
have access to your local physical layer (your ethernet backbone).

If you don't need or want remote logins and remote shells to be initiated
from the outside world at all, then there is no need for kerberos or
other more secure protocols. My approach is sufficient and works for
all TCP/IP hosts on your local network without the need to install
new software. Again prove me wrong.

>	The IETF is addressing this need by requiring security (among
>other things) to be accounted for in every new protocol proposal.  Sort
>of like a security environmental impact statement.  Steve Crocker of 
>Trusted Information Systems is the Area Director of Security in the
>IETF.  He is worrying about all kinds and levels of security.  This 
>is a very active area of research in the IETF, in other words.  It
>is affecting PPP, OSPF, BGP to name a few new protocols.  Stay tuned.

>	Meanwhile, if you want to use this modified KA9Q, just be
>aware of how weak this approach really is.

I hope you can indicate REAL holes in my security approach, otherwise
your statement is really weak, instead of the modified KA9Q. (I don't
want to be offensive but I really figured out many different ways of
attack and iterated my gateway implementation till it was secure. 
I really like (constructive) criticism, so I can make it better).


>	--Kent

Tom
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed 9 May 90 14:25:11-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        usc!cs.utexas.edu!oakhill!guri@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
Please, people:  "ping" is not a specific network protocol - it is a
concept.  The unix "ping" command happens to use ICMP ECHO packets,
but there are also XNS, CLNS, Appletalk, Chaosnet, PUP equivilents
of ping, as well as conceptually similar concepts for UDP, TCP, and
so on.  The original request asked for a way of determining the status
of a particular TCP port, which is more or less within the scope of
"pinging" - I don't think there was any intentiion of using ICMP for this.

BillW
-------
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 08:32:28 GMT
From:      usc!samsung!munnari.oz.au!bruce!goanna!dmh@ucsd.edu  (Darren Hosking)
To:        tcp-ip@nic.ddn.mil
Subject:   Too many tftp requests causes "Connection Refused"

I have cross posted this to comp.windows.x because the problem was highlighted
by a lab of X terminals and someone may have had a similar problem.

We have a lab full of X terminals that all use tftp to fetch the downloadable
server and fonts. If I start one X terminal at a time the terminal boots up
(and fetches its fonts) without any problems, however, if I start several at
once the machine that they are all trying to tftp from comes up with the
following console messages:

May  7 15:29:41 yallara.oz tftpd[2009]: tftpd: read: Connection refused
May  7 15:29:42 yallara.oz tftpd[2015]: tftpd: read: Connection refused
May  7 15:29:44 yallara.oz tftpd[2019]: tftpd: read: Connection refused
...
May  7 15:29:54 yallara.oz tftpd[2072]: tftpd: read: Connection refused
May  7 15:29:55 yallara.oz inetd[169]: tftp/udp server failing (looping), servic
e terminated

After which inetd will no longer run tftpd. The X terminals report errors
when the above happens.

This problem occurs on an Encore Multimax running UMAXV 2.2J, a VAX 11/750
running 4.3 BSD, and a Sony 1850 running 4.3 BSD. However, the problem does
NOT occur on an Encore running 4.3 BSD (R4_0.0). Tftpd appears to be failing
in recvfrom() and is returned "Connection Refused".

My question is this, why do lots of tftp's work on one machine and not most
others? Is there are kernel configurable parameter that will increase the
backlog of UDP packets (if this is the problem)?

The problem can be recreated without using X terminals by using two shell 
scripts that generates several tftp requests for a small file on a particular
machine in the background. For example:

#! /bin/csh
# Filename: t
#
foreach f (1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0)
tf &
end

#! /bin/csh
# Filename: tf
#
tftp MACHINENAME << EOF
get /FILENAME
q
EOF


	Thanks in advance, dmh

Darren Hosking				ACSnet: dmh@goanna.oz	 
Department Of Computer Science		ARPA:   dmh%goanna.oz.au@uunet.uu.net
RMIT					CSNET:  dmh%goanna.oz.au@australia
GPO Box 2476V				UUCP:   ...!uunet!goanna.oz.au!dmh
Melbourne Vic., Australia 3001
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 May 90 13:09:00 EDT
From:      Haggar (H.) Alsaleh <HAGGAR@BNR.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   IEEE 802.1 Network Management.




Is anybody looking at alternative network management protocol
such us IEEE 802.1b, I have the standard but I need more info
If you could help or know where I could find it, I would very
much appreciate it.

                                    Thanks
                                    Haggar Alsaleh
                                    1150 E. Arapho Rd.
                                    Richardson, TX 75081.
                                    (214) 997-4806.

                                    Haggar@bnr.ca

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 12:52:13 GMT
From:      hpda!hpwala!hpwade!johns@ucbvax.Berkeley.EDU  (John Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
In article <INTERRAN.90May8024556@lurch.Stanford.EDU> interran@lurch.Stanford.EDU (John Interrante) writes:
>I would like to "ping" a program listening to a TCP port to find out
>if it's alive without actually creating a connection to that program's
>TCP port.  I want the ping to tell me whether or not an attempt to

  Well, this may not exactly be the answer you are looking for but ...

If your target machine is running SNMP (i.e. snmpd) and you have the
snmpwalk program on your source machine you can do the following to
query SNMP for an available service :

$ snmpwalk <target> <community-name> \
  tcp.tcpConnTable.tcpConnEntry.tcpConnState.0.0.0.0.25

Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState.0.0.0.0.25.0.0.0.0.0
INTEGER: listen(2)

(This example would check to see if the SMTP [sendmail] port is
listening.  To check for another service port, just put its number in
place of the 25.)

  I believe that the SNMP package is available from CMU (I do not have
the FTP address available).

>John Interrante    interran@lurch.stanford.edu

  Hope this helps,
	John Silva   johns@hpwarf.hp.com
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 15:18:14 GMT
From:      grebyn!pat@decuac.dec.com  (Pat Bahn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP based job submission services..
JTM in OSI does this,  course that means someone would actually have to
implement it.  then put in the bridges to TCP.  Any volunteers?

-- 
=============================================================================
Pat @ grebyn.com  | If the human mind was simple enough to understand,
301-948-8142      | We'd be too simple to understand it. -Emerson Pugh  
=============================================================================
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 17:34:20 GMT
From:      pollux!ccruss@ucdavis.ucdavis.edu  (Russ Hobby)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ingres certification of TCP/IP

Hi Henry,

Funny you should bring this up. Although I can't answer you specific
question on Ingres, I do have a comment. One problem we have with SQL
databases running over TCP/IP networks is that each vendor is starting
to do it their own way. From the users porint of view, this won't do!
Thus, I have just formed an Internet Engineering Task Force Working
Group to standardize SQL over IP.  The WG has the goals of getting the
vendors together and agreeing on a standard. After that the WG will
move on to Z39.50 over the Internet.

The chair of the WG is Cliff Lynch and if you are interested following the
WG or partisipating, you can write to him at lynch@postgres.berkeley.edu


Russ Hobby                              INTERNET: rdhobby@ucdavis.edu  
IETF Area Director - Applications       BITNET:   RDHOBBY@UCDAVIS  
                                        UUCP:  ...!ucbvax!ucdavis!rdhobby 
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 18:29:03 GMT
From:      eru!luth!sunic!tut!jh@bloom-beacon.mit.edu  (Juha Heinanen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP ??
In article <YaFlJIe00iU4E5A3w0@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes:

   2.  Draft proposals for 802.3 and 802.5 Bridging and OSI Network Layer
   over PPP have been submitted.

Any idea if the latter is going to be submitted also to ISO?  The
current ISO standard (8880-3) lists ISO 8473 over ISO 7809 BAC in the
Point-to-Point case.
--
--	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 20:44:09 GMT
From:      sgi!pchin%midautumn.wpd.sgi.com@ucbvax.Berkeley.EDU  (Phil Chin)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Kermit Protocol Manual
Any one know where I can get the following manuals from?

	"Kermit, A File Transfer Protocol", Frank de Cruz
	"Kermit Protocol Manual", Frank de Cruz


Thanks
Philip
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 21:04:41 GMT
From:      att!cbnewsh!fsi@ucbvax.Berkeley.EDU  (furrokh.s.irani)
To:        tcp-ip@nic.ddn.mil
Subject:   comparision of sockets to tli

	Does anyone have a comparision of the 'TLI' interface versus
the 'socket' interface?

	Please email to att!odyssey!fsi. Thanks v. much.

-Furrokh S. Irani
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 21:52:51 GMT
From:      cbmvax!grr@uunet.uu.net  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Lantastic vs. the World - Problems?
One of our user areas here has decided that they want to use one of those
PC network products call "Lantastic" with WD8003 Ethernet cards.  Up to
now our LAN has been exclusivly TCP/DECnet/XNS and we've standardized on
3c503 cards for PC's.

The apparent reason for going with the WD8003 cards is lack of Netbios
support for the 3c503.  I find this somewhat hard to argue with.

Has anyone had any interoperbility problems with Lantastic and traditional
protcols on the same Ethernet?  I know there shouldn't be, but I'd like be
sure before these guys commit (me) to a bunch of new hardware and software.

Is the Lantastic stuff yet another unique proprietary protocol or is it
related to something more generic?

Apologies to tcp/ip folk who find this somewhat peripheral...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 May 90 22:56:17 GMT
From:      agate!shelby!cis!interran@ucbvax.Berkeley.EDU  (John Interrante)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: pinging a remote TCP port to see if it's in use
I got about four types of responses:

   1.  There is no way to get this information from the TCP protocol layer.

   [ Everybody agreed on this one. ]

   2.  If you have a way to bypass the TCP protocol layer and access the
   raw packet layer, you can send a SYN to the remote port.  If there is
   no server listening on the other end, but the host is reachable, you
   should get a RST back.  If there is a server listening on the other
   end, then the remote TCP will set up a connection block to handle your
   SYN and return a SYN ACK.  The remote TCP will not have reached
   established state yet, so the listening server should still be
   unaffected.  You would tear down your connection block and send a RST.
   The other end will tear down its connection block when it gets the
   RST.  If your RST gets lost, the other end will retransmit the SYN ACK
   and your TCP will send a RST (as usual).

   Another person had a similar response with slightly different details:

   You can send and receive arbitrary packets behind TCP's back with
   Sun's Network Interface Tap (NIT) facility.  You would synthesize the
   initial TCP SYN packet, listen for the SYN-ACK, and send an ABORT if
   one is received (to prevent the connection from being accepted).  If
   no SYN-ACK is received, despite repeated retransmissions of the
   initial SYN, the remote port is not accepting connections.

   [ This is what I wanted to know.  Unfortunately, it's too OS-specific
   to be worth implementing in my portmapper. ]

   3.  A network management protocol such as SNMP can tell you if a port
   already has a connection.  Etc.

   [ No mention was made of a programmer-level interface to the network
   management protocol.  Even if there was one, I wouldn't use it because
   it's not a standard part of most Unix systems (yet). ]

   4.  You can avoid a connection that hangs (because there's already an
   existing connection between the same TCP ports on both machines) by
   ioctling the socket with FIONBIO to put it in non-blocking I/O,
   issuing a connect on the socket, and then selecting on the socket
   for a ready to write condition with a timeout set.  If the select
   times out, you have not successfully connected to the remote machine
   within that amount of time and you have the choice of increasing the
   time interval or using a different port on your side.

   [ This answer was very interesting even though it wasn't what I was
   asking for.  If you use ANYPORT (i.e., a zero port), you're supposed
   to get an unused port on your side.  Would or wouldn't ANYPORT prevent
   this kind of problem from occurring? ]

A couple of people were curious why I wanted to know how to validate a
port number.  I don't mind explaining that the reason I asked was to
improve a portmapper I wrote for InterViews programs making RPC calls.
We couldn't use Sun's /etc/portmap because we wanted servers to
register their TCP port numbers under a variable-length string of
characters (i.e., a name), not a tuple of integers (i.e., a program
number and a version number).  I noticed that SunOS 4.1's /etc/portmap
will let you register the port number of a non-existent server, but it
will unregister the port number and give you zero when you try to ask
for the non-existent server's port number.  I set a breakpoint in a
server to find out how portmap validated the server's port number and
I know that the server never noticed a new connection.  Yet portmap
definitely WAS validating port numbers in some way because I never got
a port number for a non-existent server.  I checked the public RPC
sources on gatekeeper.dec.com but the source for portmap didn't
include this kind of code so that's why I posted my question.  I
wanted to be able to validate port numbers in my portmapper too
because it would prevent clients from trying to connect to a server
that crashed after registering its port number with the portmapper.

I want to thank everybody who replied to my question.  You all were
very helpful in letting me know that the way Sun's /etc/portmap
validates port numbers is too OS-specific to be worth duplicating.

John Interrante    interran@lurch.stanford.edu
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 00:25:06 GMT
From:      usc!cs.utexas.edu!execu!sequoia!sequoia.execu.com!dewey@ucsd.edu  (Dewey Henize)
To:        tcp-ip@nic.ddn.mil
Subject:   1's broadcast vs 0's broadcast (summary and thanks)
In article <15346@sequoia.execu.com> I asked about a problem with YP and
IP broadcasts.  I recieved a good bit of help from folks out there, and
wanted to thank you all!

The overall concensus was that the 1's broadcast was the only good way to
go to be sure of continued compliance.  (We had been using the 0's broadcast
as a relic from our first couple Sun-2's - amazing how a network can grow.)

It also appears that HP has support for broadcast selection in their (later?
latest) OS upgrade/release, should someone find themselves in the corner
I was in.

I did do a convert on all the machines around to all 1's though, and was
then able to remove the HP from the YP/NIS server business.  In the middle
we had one nice ARP storm as some clients got confused, but it all settled
out and without the HP slowing the other machines down, our net is more
responsive now.

Thanks to those that posted suggestions, and I'd like to especially thank
the following folks who wrote me with references and suggestions:

WLV.IMSD.CONTEL.COM!mcc Merton Campbell Crockett
mlb.semi.harris.com!del Don "Truck" Lewis
ongs.LANCE.ColoState.Edu!steved Steve Dempsey
idt.unit.no!he Haavard Eidnes
tuegate.tue.nl!rcjoep Joep Brand
uhura.cc.rochester.edu!leadley Scott Leadley

Regards,

Dew
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 01:21:07 GMT
From:      snorkelwacker!bu.edu!mirror!adelie!minya!jc@uunet.uu.net  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is the hostname "foo" or "foo.bar.com"?

From mail Tue May  8 03:37 EDT 1990
>From cfisun!ima!haddock.ima.isc.com!ico!stan!imp  Tue May  8 03:37:53 1990 remote from adelie
Received: by minya.uucp (smail2.5)
	id AA27964; 8 May 90 03:37:53 EDT (Tue)
Received: by adelie.Adelie.COM (5.57/smail2.2/02-18-87)
Received: from ima.UUCP by cfisun.cfi.com (4.1/SMI-4.0)
	id AA14084; Mon, 7 May 90 14:34:34 EDT
Received: from haddock.ima.isc.com by ima.ima.isc.com (5.61/1.35f)
	id AA03828; Mon, 7 May 90 13:20:34 -0400
Received: from ico by haddock.ima.isc.com (5.61/1.36)
	id AA22163; Mon, 7 May 90 13:20:58 -0400
Received: by ico.isc.com (5.61/1.35)
	id AA00739; Mon, 7 May 90 11:14:36 -0600
Received: by stan.UUCP (smail2.5)
	id AA06715; 7 May 90 10:55:23 MDT (Mon)
Received: from dancer.Solbourne.COM (dancer-gw) by Solbourne.COM (4.0/SMI-4.0)
	id AA06706; Mon, 7 May 90 10:55:18 MDT
Received: by dancer.Solbourne.COM (4.0/SMI-4.0)
	id AA04231; Mon, 7 May 90 10:55:17 MDT
Date: Mon, 7 May 90 10:55:17 MDT
From: cfisun!ima.ima.isc.com!Solbourne.COM!ico.isc.com!imp (Warner Losh)
Message-Id: <9005071655.AA04231@dancer.Solbourne.COM>
To: minya!jc
Subject: Re: Is the hostname "foo" or "foo.bar.com"?
Newsgroups: comp.protocols.tcp-ip
In-Reply-To: <380@minya.UUCP>
References: <9005032308.AA14782@ucbvax.Berkeley.EDU> <18464@nigel.udel.EDU>
Organization: Solbourne Computers Inc.
Cc: 

| give me details and I will quote you RFC's.  EVERY SMTP IMPLENETATION
| MUST ACCEPT MAIL THAT IS GIVEN TO IT, EVEN IF IT LOOKS "Forged".

Hmmm....If this is true, then there isn't, and never will be a compliant
implementation, unless someone finds a way to build a computer with
unlimited memory.  All existing implementations are guaranteed to not
accept mail when their file system is full.

I've also been amused on many occasions by sendmail's "I refuse to
talk to myself" message.  This is one of the cleverest screwups, in
which the mail actually makes it to the destination machine, and is
rejected in a totally demented fashion.  I suppose this could be a
violation of the RFC, but my impression is that the authors of the
program intended it to act that way, and they don't consider it a
violation (or a bug).  It's just a screwup on the part of the machine's
administrator.  "If you'd done it right, you wouldn't have problems."

| >BTW, are you aware that there are systems being sold that limit hostnames
| >(sometimes doubling as sysnames or nodenames) to 16 bytes?
|
| Those hosts are brain dead.  They do not conform to the internet
| standard of 256 characters in a host name.  Limits on nodename that
| never leave the machine are fine, but limits that are exported are as
| bogus as 14 character file names. :-)

I'm not sure I totally agree.  Sure, I think the limit should be larger.
But as for the idea that the designers of system X (e.g., the Internet)
should come along and tell the designers of system Y (e.g., Sys/V) that
"You don't do it our way, so you're brain dead", well, I'll reserve
judgement.  I've seen too much of this sort of thing, and it's a game
that nobody wins.

This is a Sys/V machine with a 9-byte limit to the sysname and the
nodename.  I would have made the limit larger, but in fact, it isn't
a problem.  These names clearly aren't supposed to include domain info.
It makes a lot more sense to have the domain junk added by the mailer.
One effect the small limit has had is that people who ported BSD software
had to make sure it all allowed short names.  I've found this to be a
real advantage against the BSD-based systems where I must constantly
type very long names.

An interesting case arises when (as is true here) a machine is in more
than one domain (.edu and .com), and there's no "correct" domain for
the machine as a whole.  This situation is the main reason (other than
being a lazy typist ;-) that I personally prefer non-domainized hostnames.
If your machine always identifies itself as being in exactly one domain,
a lot of problems arise that are more easily solved if it doesn't know
its own domain.  It's useful to be able to partition the problems, and
say that domains are email artifacts that are best localized in the
mail software.

In any case, I'm not trying to insult anyone (well, maybe a few :-).
I'm looking at complicated software that doesn't work very well, people
are saying incompatible things about the "right" way to do it, and I'd
like to find out if there is indeed a right way.

So far, the answer seems to be that various pieces of software decide
that different ways are right, the standards don't give answers, so
it'll remain a mess for some time.  (It'll probably get straightened
out when IBM comes along and says how we'll do it, and we'll be stuck
with a bumbling, incompetent email system for the next 5 decades. ;-)

Sigh.
-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 07:36:16 EDT
From:      Robert Craig <ROBERT@VM1.MCGILL.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip for Prime
I remember seeing a few months ago a message (I think it
was on this list) concerning TCP/IP for Primes.  We have
a department with a Prime which they desperately want to
connect, but can't afford the outrageous price for the
ethernet adapter and TCP/IP that Prime wants to charge.
The message seemed to imply that there were implementations
of TCP/IP other than that sold by the vendor, which might
cost significantly less.

I've looked in the vendors' guide from the nic, but all I find
in there is the stuff sold by Prime.

Robert Craig                          domain: robert@vm1.mcgill.ca
Network Analyst                       bitnet: robert@mcgill1
McGill University Computing Centre    Tel: (514) 398-3710 (office)
805 Sherbrooke St. W.                 FAX: (514) 398-6876
Montreal, Quebec H3A 2K6              CORISQ: (514) 398-RISQ
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 09:47:11 EDT
From:      melling@gateway.mitre.org
To:        tcp-ip@nic.ddn.mil
Cc:        infsecur@smiley.mitre.org
Subject:   IETF Security

I am interested in finding out the role of the IETF security group (?)
and which security issues it is dealing with in particular. What is its
role/charter concerning security services? 


Phil Mellinger

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Thu 10 May 90 10:43:08 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        pollux!ccruss@ucdavis.ucdavis.edu
Cc:        tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
Subject:   Re: Ingres certification of TCP/IP
Russ, THis is interesting.  I thought there was a vendor coalition of SQL 
providers that is called the SQL access group and that they were coming
up with interoperability standards.  Are they missing something you folks
have latched on to?  Roger Sippl of Informix is the chair of this group.

Dan
-------
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 13:55:50 PDT
From:      postel@venera.isi.edu
To:        phri!news@nyu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   What is the IAB?
Roy Smith:

Please see RFC-1120 for an explanation of the IAB.

--jon.
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 14:10:15 PDT
From:      postel@venera.isi.edu
To:        phri!news@nyu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   What is the IAB?

Roy Smith:

   The Internet Activities Board (IAB) is the coordinating committee for
   Internet design, engineering and management.  The Internet is a
   collection of over a thousand packet switched networks located
   principally in the U.S., but also includes systems in many other
   parts of the world, all interlinked and operating using the protocols
   of the TCP/IP protocol suite.  The IAB is an independent committee of
   researchers and professionals with a technical interest in the health
   and evolution of the Internet system.  Membership changes with time
   to adjust to the current realities of the research interests of the
   participants, the needs of the Internet system and the concerns of
   the U.S. Government, university and industrial sponsors of the
   elements of the Internet.

   IAB members are deeply committed to making the Internet function
   effectively and evolve to meet a large scale, high speed future.  All
   IAB members are required to have at least one other major role in the
   Internet community in addition to their IAB membership.  New members
   are appointed by the chairman of the IAB, with the advice and consent
   of the remaining members.  The chairman serves a term of two years.

   [From RFC-1120]

--jon.

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 11:36:16 GMT
From:      ROBERT@VM1.MCGILL.CA (Robert Craig)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip for Prime

I remember seeing a few months ago a message (I think it
was on this list) concerning TCP/IP for Primes.  We have
a department with a Prime which they desperately want to
connect, but can't afford the outrageous price for the
ethernet adapter and TCP/IP that Prime wants to charge.
The message seemed to imply that there were implementations
of TCP/IP other than that sold by the vendor, which might
cost significantly less.

I've looked in the vendors' guide from the nic, but all I find
in there is the stuff sold by Prime.

Robert Craig                          domain: robert@vm1.mcgill.ca
Network Analyst                       bitnet: robert@mcgill1
McGill University Computing Centre    Tel: (514) 398-3710 (office)
805 Sherbrooke St. W.                 FAX: (514) 398-6876
Montreal, Quebec H3A 2K6              CORISQ: (514) 398-RISQ

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 13:02:29 GMT
From:      Mills@udel.edu
To:        brian donat <cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!briand@tut.cis.ohio-state.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  gated
briand,

I'm not sure what you mean by cost metrics on the fuzzlings, but if you
want more information, see my paper in SIGCOMM 88 and/or the info in
the SRI Vendor's Guide. If that doesn't work, light a match in a dark
corner of your junkbox and whisper "fuzzbug" and see if an old backplane
comes to life.

Dave
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 13:20:15 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!kaarne.tut.fi!jja@ucsd.edu  (Ahola Jari)
To:        tcp-ip@nic.ddn.mil
Subject:   Microsoft's ? SMB protocol - info needed.
Hello all!

Im in a desperate need of information concerning a PC protocol called SMB
(Send Message Block ??) possibly by Microsoft. This protocol is at least
used by DCA's networking software and I know that there is servers for
Unix machines using this protocol. But I haven't succeeded to find any
other information except what's in this message. 

So if YOU have any single piece of information about SMB, drop me a line.
I'm especially  interested to get my hands in the specification of SMB.

-jja


Jari 'jja' Ahola      |Tampere University of Technology, Signal Processing Lab
Opiskelijankatu 16A12 |P.O. Box 527, 33101 Tampere, Finland
33720 Tampere, Finland|Tel (intl) 358 31 162708 (work)/358 31 174009 (home)
Puh. 931-174009       |Net address: jja@tut.fi, AHOLA@FINTUTA (BITNET), bix:jja
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 15:02:07 GMT
From:      PIRARD@BLIULG11.BITNET (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for Kermit Protocol Manual

>	"Kermit, A File Transfer Protocol", Frank de Cruz
Digital Press
DEC
12 Crosby Drive
Bedford
Massach 01730
Order EY-6705E-DP
>	"Kermit Protocol Manual", Frank de Cruz
The file KPROTO.DOC, maybe still missing the latest features.
Open the mass of data with HELP mail to KERMSRV@CUVMA on BITNET.

Andr).

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 15:07:44 GMT
From:      phri!news@nyu.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   What is the IAB?

	At the recent PSI Internetworking Tutorial, I asked two people who
should have known the answer, "Exactly what *is* the Internet Activities
Board?" and in both cases all I got were some random moderately derogatory
comments but no real answer (which I found somewhat annoying, BTW).

	So, can anybody on this list answer my question?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 17:22:59 GMT
From:      bu.edu!bu-it!kwe@uunet.uu.net  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
In article <1990May10.150744.12108@phri.nyu.edu>,
roy@alanine.phri.nyu.edu (Roy Smith) writes:
> 
> 	At the recent PSI Internetworking Tutorial, I asked two people who
> should have known the answer, "Exactly what *is* the Internet Activities
> Board?" and in both cases all I got were some random moderately derogatory
> comments but no real answer (which I found somewhat annoying, BTW).
> 
> 	So, can anybody on this list answer my question?
> --

	Some wires must have gotten crossed.  It would be very strange indeed
for anyone in PSI to take this view, since several of the principals at PSI
have been involved in TCP/IP standards, including SNMP and "ISO-on-TCP", and
that work would be exactly nowhere without the IAB.  Strange, indeed.

	The IAB is sponsored by the Federal Networking Committee (formerly
the Federal Research Internet Coordinating Committee or FRICC).  The FNC
is made up of government agencies (DARPA, NSF, DoE, NASA, HHS, et al) that
fund research and education networks, like NSFnet, ESnet, NSI, et al.

	The IAB has two steering committees reporting to it, one of which
is responsible for the Internet Engineering Task Force.  The IETF is where
the engineering work of TCP/IP gets done, thru the WGs and the RFC process.  
IETF meets quarterly and the last meeting was just last week at PSC 
in Pittsburgh.

	The IETF is open and you can learn more by subscribing to
ietf-request@venera.isi.edu.  Vint Cerf is the Chair of the IAB and Phill
Gross is the Chair of the IETF and perhaps they may have some words to
say about the IAB.

	You can also learn a great deal more about the IAB by ftp'ing
to nnsc.nsf.net and looking thru the directories there.  There are
charters and reports from all the IETF working groups, as well as 
drafts that might eventually be submitted as RFCs.  Most WGs have
active mailing lists that you can subscribe to and that info is on
NNSC.

	The IAB and IETF are open, very open in my opinion.  All you
have to do is roll up your sleeves and decide to join the process and
everyone will be delighted to have you participate in whatever you
find interesting.  It is much easier to participate in the IETF than
any other standards process that I am aware of.  Only vendors can
afford ANSI, IEEE, and OSI (exaggeration, perhaps, but there are few
users in those bodies).  On the other hand, IETF is overwhelmingly
attended by users and network managers, although vendors are well
represented and take particular interest in those issues that affect
their bottom lines.

	That's enough from me, but the IAB/IESG/IETF don't do as well
as others at self promotion, so perhaps this exposition will be
useful to some.

	As they say, enjoy.

	Kent England, Boston University
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 May 90 17:38:01 GMT
From:      hsi!stevens@uunet.uu.net  (Richard Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Microsoft's ? SMB protocol - info needed.
The references in

	%T OS/2 to UNIX LAN
	%A M. R. M. Dunsmuir
	%B UNIX Networking
	%E S. G. Kochan and P. H. Wood
	%I Howard W. Sams and Company
	%C Indianapolis, Ind.
	%P 237-284
	%D 1989

state that "Server Message Block, Protocol Specification (Core,
Extended, XENIX)" is published by Microsoft and is available
from the OEM marketing department at Micrsoft.

	Richard Stevens
	Health Systems International, New Haven, CT
	   stevens@hsi.com
           ... { uunet | yale } ! hsi ! stevens
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 14:48:31 +0200
From:      root%ISIS.U-STRASBG.FR(Operator)@CUNYVM.CUNY.EDU
To:        tcpipl@UNKNOWN.DOMAIN
Cc:        hajjam@OSIRIS1.BITNET
Subject:   Setting multicast addresses

I am currently working on multicast protocols over Ethernet .
Now my question:
how is it possible to set multicast (ethernet) addresses, using streams,
on a sun 3, SunOS4.0.3  ?
If this is not possible using streams, are there any other simple solutions ?

Thanks for your help

moha

hajjam@osiris1.u-strasbg.fr

Universite louis Pasteur, Strasbourg  , France
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 May 90 17:02:07 +0200
From:      Andr'e PIRARD <PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Looking for Kermit Protocol Manual
>	"Kermit, A File Transfer Protocol", Frank de Cruz
Digital Press
DEC
12 Crosby Drive
Bedford
Massach 01730
Order EY-6705E-DP
>	"Kermit Protocol Manual", Frank de Cruz
The file KPROTO.DOC, maybe still missing the latest features.
Open the mass of data with HELP mail to KERMSRV@CUVMA on BITNET.

Andr).
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 15:00:02 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        john@pcsbst.pcs.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: In search of SNMP Sources
Get a copy of RFC1147 which should contain all the information you need.
Also, please direct further questions regarding the SNMP, products,
etc., to the snmp list.  You can join by sending a note to
snmp-request@nisc.nyser.net

Thanks,

/mtr
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 09:30:00 EST
From:      "Carla" <bazemore@nrl3.arpa>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   TCP-IP BULLETIN BOARD TOPIC
I am the Bulletin Board manager at the Naval Research Laboratory's
Central Computing Facility.  I would like to subscribe to your
topic board, TCP-IP.   Please add the mailing address,
CCF_BITNET@CCF.NRL.NAVY.MIL, to your distribution list.

If additional information is required, please send mail to
BAZEMORE@CCF.NRL.NAVY.MIL.

Thank you,

Carla Bazemore
(202) 767-3884

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 11:25:45 EDT
From:      Don Merritt <don@BRL.MIL>
To:        Joerg Hertzer <zrfp0128%awssn3.rus.uni-stuttgart.de@relay.cs.net>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  "ttcp" program
>In a c program I found the following coment:
>
>/*
> *    This program is based on the "ttcp" program originally developed by
> *    T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
> *    Due to the large number of changes, however (asynchio, data checking,
> *    random length and offset, fake-data option, ...), it has effectively
> *    been completely rewritten.
> */
>
>Where can I get the original ttcp program or the mentioned improved version?


The original ttcp program is available for anonymous ftp from
vgr.brl.mil (26.2.0.29) in pub/ttcp.c

Don

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 09:35:13 GMT
From:      zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer)
To:        comp.protocols.tcp-ip
Subject:   "ttcp" program

In a c program I found the following coment:

/*
 *    This program is based on the "ttcp" program originally developed by
 *    T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
 *    Due to the large number of changes, however (asynchio, data checking,
 *    random length and offset, fake-data option, ...), it has effectively
 *    been completely rewritten.
 */

Where can I get the original ttcp program or the mentioned improved version?

Thanks for your help


Joerg Hertzer
Computer Center University Stuttgart
Allmandring 30
D-7000 Stuttgart 80
West Germany
Phone:   ++49-711-685-5803
Fax:     ++49-711-682357
E-Mail: zrfp0128@awssn3.rus.uni-stuttgart.de  (favored)
        hertzer@rus.uni-stuttgart.dbp.de
        S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de
        ZRFP@DS0RUS1I.bitnet

"Life is satire"

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 17:10:47 PDT
From:      postel@venera.isi.edu
To:        mussar@bnr.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Obtaining PPP (draft) spec

Hi.

The PPP Specificarion id RFC-1134.

--jon.
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 16:11:05 EDT
From:      BDK@UNB.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: tcp/ip for Prime
I don't have an answer for you but am interested in the replies.
Brian Kaye
University Of New Brunswick

On  Thu, 10 May 90 09:57:29 ADT  Robert Craig <ROBERT@VM1.MCGILL.CA>
writes:

> I remember seeing a few months ago a message (I think it
> was on this list) concerning TCP/IP for Primes.  We have
> a department with a Prime which they desperately want to
> connect, but can't afford the outrageous price for the
> ethernet adapter and TCP/IP that Prime wants to charge.
> The message seemed to imply that there were implementations
> of TCP/IP other than that sold by the vendor, which might
> cost significantly less.
>
> I've looked in the vendors' guide from the nic, but all I find
> in there is the stuff sold by Prime.
>
> Robert Craig                          domain: robert@vm1.mcgill.ca
> Network Analyst                       bitnet: robert@mcgill1
> McGill University Computing Centre    Tel: (514) 398-3710 (office)
> 805 Sherbrooke St. W.                 FAX: (514) 398-6876
> Montreal, Quebec H3A 2K6              CORISQ: (514) 398-RISQ
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 20:27:24 PDT
From:      LiBai!tinker@ames.arc.nasa.gov (Don Tinker)
To:        zrfp0128%awssn3.rus.uni-stuttgart.de@ames!RELAY.CS.NET
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   "ttcp" program

>
>In a c program I found the following coment:
>
>/*
> *    This program is based on the "ttcp" program originally developed by
> *    T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
> *    Due to the large number of changes, however (asynchio, data checking,
> *    random length and offset, fake-data option, ...), it has effectively
> *    been completely rewritten.
> */
>
>Where can I get the original ttcp program or the mentioned improved version?


What you have is a copy of a program "tsock", written by the folks at
Ultra Network Technologies (my company) in order to test
high-performance i/o through high-performance networks.  I'll mail you
a copy, and because this is the third or fourth request for it I've
gotten lately, I'll see about putting it on someplace ftp-able-to.


Don Tinker				tinker@ultra.com
Senior Field Support Engineer		{core}!ames!ultra!tinker
UltraNetwork Technologies Inc. 		(703) 821-8393
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 18:41 CDT
From:      Buckaroo Bonzai and the Team of Baker Street Irregulars, <ELEE6WK@jetson.uh.edu>
To:        NEXT-L@BROWNVM.BITNET, INFO-UNIX@BRL.ARPA, TCP-IP@NIC.DDN.MIL, DLV@CUNYVMS1.BITNET, GAELIC-L@IRLEARN.BITNET, Info-Mac@sumex-aim.stanford.edu, space+@andrew.cmu.edu, I-PACRAD@UIUCVMD.BITNET, Packet-Radio@UCSD.Edu, Info-IBMPC@WSMR-SIMTEL20.ARMY.mil
Subject:   this is a test... disregard if you receive this
this is a test.. please disregard if you get this... my mail router here
at the university of houston has died a death or two.
william sanders, a subscriber to this list
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 14:30:00 GMT
From:      bazemore@CCF3.NRL.NAVY.MIL ("Carla")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP BULLETIN BOARD TOPIC

I am the Bulletin Board manager at the Naval Research Laboratory's
Central Computing Facility.  I would like to subscribe to your
topic board, TCP-IP.   Please add the mailing address,
CCF_BITNET@CCF.NRL.NAVY.MIL, to your distribution list.

If additional information is required, please send mail to
BAZEMORE@CCF.NRL.NAVY.MIL.

Thank you,

Carla Bazemore
(202) 767-3884

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 14:37:12 GMT
From:      crdgw1!gecrdvm1!hathawa@uunet.uu.net  (Barry Hathaway)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 for Suns

This is a reposting of an earlier note in hopes that someone can help me
find a tn3270 that works correctly.   HELP!  Thanks in advance.

Recently I retreived the latest version (4.1.1) of tn3270 from Berkeley
and have been playing around it.  The reason I went to the new version
was that our prior version had cursor positioning problems.  When users
would tn3270 to our VTAM session manager (Netview/Access Services) on MVS the
cursor would appear 1 position to the left of the first (userid) unprotected
field on the screen - so if the user wanted to enter his userid he would have
to move the cursor one position to the right.  This only seemed to happen
with this particular application.  Happily, Version 4.1.1 fixed that problem;
however, it introduced a much more serious problem - improper highlighing.
(Note: the termcap entry is set up to do bold instead of reverse video.)
In some, but important, applications some things are hightligted when they
are not supposed to be.  I have seen this most in IDMS applications.
For example: in one application the date and time appears in the upper right
corner of the screen and the lower portion of the screen contains a number
of unprotected fields, and some highlighted fields.  When you press enter
or a PF key the application does some things and updates the time in the
upper right corner.  When it does this the seconds become highlighted.
If one waits until the minute changes then the minutes will also become
highlighted.  This is only one example, but it happens often.  Apparently
some strange cursor positioning orders are generated by IDMS.  This did not
seems to happen in the older version (unknown version) of tn3270.
Any ideas?  Is anyone else having the same problem?
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 May 90 11:35:13 +0200
From:      Joerg Hertzer <zrfp0128%awssn3.rus.uni-stuttgart.de@RELAY.CS.NET>
To:        tcp-ip@NIC.DDN.MIL
Subject:   "ttcp" program
In a c program I found the following coment:

/*
 *    This program is based on the "ttcp" program originally developed by
 *    T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery.
 *    Due to the large number of changes, however (asynchio, data checking,
 *    random length and offset, fake-data option, ...), it has effectively
 *    been completely rewritten.
 */

Where can I get the original ttcp program or the mentioned improved version?

Thanks for your help


Joerg Hertzer
Computer Center University Stuttgart
Allmandring 30
D-7000 Stuttgart 80
West Germany
Phone:   ++49-711-685-5803
Fax:     ++49-711-682357
E-Mail: zrfp0128@awssn3.rus.uni-stuttgart.de  (favored)
        hertzer@rus.uni-stuttgart.dbp.de
        S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de
        ZRFP@DS0RUS1I.bitnet

"Life is satire"
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 15:09:59 GMT
From:      mcsun!unido!fauern!tumuc!guug!pcsbst!john@uunet.uu.net  (John Ludbrook (Marketing))
To:        tcp-ip@nic.ddn.mil
Subject:   In search of SNMP Sources
Hi Networkers,
		I am currently seeking SNMP Source to run on
	UNIX V.3.2 and have only the names of the following companies/
	institutes ( but no contacts) :

			Epilogue Technologies
			MIT ( Network Manager Lab.?)
			Perfomance Systems International
			SNMP Research
			Netlabs
			Carnegie Mellon University

	Can anyone help out with names, phone/fax nos., mail addresses etc?

				appreciate your help. john ludbrook
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 15:18:31 GMT
From:      hercules!sparkyfs!arsocomvax.socom.mil!news@apple.com  (Ted Nolan)
To:        tcp-ip@nic.ddn.mil
Subject:   4.3BSD VAX/sendmail vs Sperry 5000/MMDF?
I'm having kind of a strange problem.  For our mailhost and gateway, we
have a Vax 11/780 running (fairly vanilla) 4.3BSD (with a recent sendmail).
This vax sits on our ethernet and has an ACC ACP6250 connection to our 
MILNET PSN.

Recently we've had users trying to send mail to a couple of
Serry-5000/80 Unix systems running MMDF as the SMTP server.  The mail
never gets there, sitting queued on a "Bad file number".

Here's the strange part.  From the vax, I can telnet to both of these hosts
with no problem (quite a good connection as a matter of fact).  However, if
I try to manually talk to the SMTP server (for example):
		
		telnet fulda-emh1.army.mil 25

I get:
		Trying...
		Connected to fulda-emh1.army.mil.
		Escape character is '^]'.
		Connection closed by foreign host.

And the connection closes immediately, before getting any response from MMDF.
This is apparently the same thing sendmail sees when it declares a "bad file
number".  But, if I try the same thing from one of our Suns, which all use
the vax as a gateway, I get a connection with no problem:

		telnet 26.14.0.175 25
		Trying 26.14.0.175 ...
		Connected to 26.14.0.175.
		Escape character is '^]'.
		220 s5000 Server SMTP (Complaints/bugs to:  mmdf@fulda-emh1.army.mil)

Are there any known problems between 4.3 and Sperry?  Since telnet
doesn't work on port 25 either, I don't really think it's a sendmail/mmdf
problem..


				Thoughts appreciated,

				Ted Nolan
				ted@usasoc.soc.mil
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 16:49:02 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bigsur!bcars53!mussar@ucsd.edu  (G. Mussar)
To:        tcp-ip@nic.ddn.mil
Subject:   Obtaining PPP (draft) spec
Can anyone tell me where to find the PPP spec. Is it sitting as an RFC
at the NIC? Email to either of the addresses should reach me (but I have
never tried them myself).

Thanks in advance.
--
-------------------------------------------------------------------------------
Gary Mussar  |Bitnet:  mussar@bnr.ca                  |  Phone: (613) 763-4937
BNR Ltd.     |  UUCP:  ..uunet!bnrgate!bcars53!mussar |  FAX:   (613) 763-2626
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 17:37:22 GMT
From:      ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu  (Steve Dempsey)
To:        tcp-ip@nic.ddn.mil
Subject:   BSD networking installation
I've been playing with the [March '89] BSD networking code,
(ftp'd from uunet:bsd-sources/src/network/sys.tar.Z) and
incorporating pieces of it into Ultrix3.1.  I've had a bit
of difficulty getting the ICMP record-route to work correctly.
Specifically, icmp_reflect() in ip_icmp.c contains the
following:

         *      @(#)ip_icmp.c   7.8.1.2 (Berkeley) 3/2/89

        /* Retrieve any source routing from the incoming packet;
         * add on any record-route or timestamp options.
         */
     [much code deleted]
        /* Now strip out original options by copying rest of first
         * mbuf's data back, and adjust the IP length.
         */
        ip->ip_len -= optlen;
        ip->ip_hl = sizeof(struct ip) >> 2;
 /*XX*/ m->m_len -= optlen;
        optlen += sizeof(struct ip);
        bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1),
 /*XX*/       m->m_len - sizeof(struct ip));
    

It's obvious that the variable m in the marked lines is a pointer
to struct mbuf, but m is neither referenced nor declared in this
routine, nor anywhere else that I can find.  I've tried various
things to get this to work and have not yet found a stable
solution; my kernel debugging skills are sorely lacking.

So my questions are: has anyone fixed this, and where might I
find the right code?

        
        Steve Dempsey,  Center for Computer Assisted Engineering
  Colorado State University, Fort Collins, CO  80523    +1 303 491 0630
INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu
UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 17:49:14 GMT
From:      ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu  (Steve Dempsey)
To:        tcp-ip@nic.ddn.mil
Subject:   BSD networking installation

I've been playing with the [March '89] BSD networking code,
(ftp'd from uunet:bsd-sources/src/network/sys.tar.Z) and
incorporating pieces of it into Ultrix3.1.  I've had a bit
of difficulty getting the ICMP record-route to work correctly.
Specifically, icmp_reflect() in ip_icmp.c contains the
following:

         *      @(#)ip_icmp.c   7.8.1.2 (Berkeley) 3/2/89

        /* Retrieve any source routing from the incoming packet;
         * add on any record-route or timestamp options.
         */
     [much code deleted]
        /* Now strip out original options by copying rest of first
         * mbuf's data back, and adjust the IP length.
         */
        ip->ip_len -= optlen;
        ip->ip_hl = sizeof(struct ip) >> 2;
 /*XX*/ m->m_len -= optlen;
        optlen += sizeof(struct ip);
        bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1),
 /*XX*/       m->m_len - sizeof(struct ip));
    

It's obvious that the variable m in the marked lines is a pointer
to struct mbuf, but m is neither referenced nor otherwise declared 
in this routine, nor anywhere else that I can find.  I've tried
various things to get this to work and have not yet found a stable
solution; my kernel debugging skills are sorely lacking.

So my questions are: has anyone fixed this, and where might I
find the right code?

        
        Steve Dempsey,  Center for Computer Assisted Engineering
  Colorado State University, Fort Collins, CO  80523    +1 303 491 0630
INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu
UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 18:10:35 GMT
From:      usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: BSD networking installation

*** /tmp/,RCSt1019886	Fri May 11 13:07:41 1990
--- ip_icmp.c	Tue Jun 13 00:18:11 1989
***************
*** 349,354 ****
--- 349,355 ----
  	register struct in_ifaddr *ia;
  	struct in_addr t;
  	struct mbuf *opts = 0, *ip_srcroute();
+ 	struct mbuf *m = dtom(ip);
  	int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
  
  	t = ip->ip_dst;

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 18:41:31 GMT
From:      voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: comparision of sockets to tli
>From: fsi@cbnewsh.att.com (furrokh.s.irani)
>Organization: AT&T Bell Laboratories
>
>	Does anyone have a comparision of the 'TLI' interface versus
>the 'socket' interface?
>	Please email to att!odyssey!fsi. Thanks v. much.
>-Furrokh S. Irani

Dear Mr. Furrokh Irani:

	Currently, I am not working on 'TLI' or 'socket', but here are the
differences I can think of. 

1. In order to establish a transport endpoint....

TLI:     "t_open" call which can open any minor devices. Those devices can 
         be shared by unrelated processes.

Sockets: "socket" call which uses different parameters such as type, domain,
         protocol. It can not access a minor device which is already opened,
         except if the processes are related.

2. In order to establish a connection...

TLI: 	 "t_listen" call which can be done without accepting a connection. 
	 One can listen multiple times without accepting a connection. 
	 "t_bind" call will set the queue length for the incoming connections.
 	 "t_connect" is used for connection with another transport user.
	 The endpoint should be bound to a protocol address before that.

Sockets: "listen" call which is followed by an "accept". This is necessary
         as "listen" only sets the queue length.
	 "connect" used for connection initiation. It's possible to connect
	 without being bound to a protocol address.

3. In order to accept a connect request... 

TLI:	 "t_accept" can be used. You have to allocate a file descriptor,
         upon which the connection is accepted. This will give more 
	 flexibility of accepting the connection. It also give the option
	 of not accepting, or delaying for the multiple t_listens. It's
	 possible to accept connection request in any order.

Sockets: "accept" can be use, which returns a socket file descriptor.
	 It's not possible to select which connect request to accept.

4. For user date on connection or disconnection...

TLI:	 One can receive the user data in the "t_listen". One can send
	 the user data in both the "t_connect", and the "t_accept".
	 One can both send and receive the user data on all the disconnection
	 primitives. This will be determined by "t_getinfo".

Sockets: There is no concept of sending or receiving the user data on any of
 	 the connection/disconnection primitives.

5. For the asynchronous processing...

TLI:	 It's possible to send connection request, and receive asynchrously
	 thru "t_sndconnect" and "t_rcvconnect".

Sockets: It has similar feature, but one can get errors and will be lost 
	 after an asynchronous operation.


6. For getting address info for an established connection...

TLI:	 It's not possible to get the connection address info, but one
	 can get the connection status.

Sockets: "getsockname", "getpeername" will give the address info.

7. For the data transfer...

TLI: 	 MORE_flag specifies record boundaries.

Sockets: There is no way of reading/writing partial records.

8. For the urgent or out of band data...

TLI:	 The only way is to read all the data, and then find out in the
	 data queue.

Sockets: The socket can be registered to receive a SIGURG signal.

9. For other misc....

TLI: 	 On System V.3, one has to push "tirdwr" module, otherwise Read/Write
	 will fail.

Sockets: Read/Write calls work directly on a socket.

10. Other problems on TLI...

The interactions between the "t_listen" and "t_accept" is too tight.
The "t_snd" should permit a scatter/gather array for an argument.

---

By the way, please don't trust TLI !!  There are a lot other problems on 
TLI implementation besides the above. It was actually poorly designed. But 
still you can migrate to OSI world easily, since it was modelled after 
ISO 8072. That's why I am enjoying OSI protocols now. Thanx. 


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 22:00:40 GMT
From:      snorkelwacker!bu.edu!mirror!redsox!campbell@tut.cis.ohio-state.edu  (Larry Campbell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Microsoft's ? SMB protocol - info needed.
In article <13013@etana.tut.fi> jja@kaarne.tut.fi (Ahola Jari) writes:
-Im in a desperate need of information concerning a PC protocol called SMB
-(Send Message Block ??) possibly by Microsoft.

It's "Server Message Block".  Perhaps this is just too obvious, but
why don't you call Microsoft and ask them?  It's their protocol.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@redsox.bsw.com                 120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02109
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 May 90 22:04:29 GMT
From:      usc!snorkelwacker!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?

	I said:

>	The IAB is sponsored by the Federal Networking Committee (formerly
>the Federal Research Internet Coordinating Committee or FRICC). 

in my response to Roy Smith's question, and some people took pains to
point out to me that sponsor is an unfortunate term.  The IAB is
independent of the FNC, even though the FNC does contribute funds to
the operation of the IAB, and obviously serves a wider constituency
that simply the FNC agencies.  Perhaps "support" is a better term?

	--Kent
	  "not a spokesman for the IAB"
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 01:50:38 GMT
From:      van-bc!mplex!fff@ucbvax.Berkeley.EDU  (Fred Fierling)
To:        tcp-ip@nic.ddn.mil
Subject:   thin ethernet tcpip to printer interface
Does anyone know of a device which:

 - connects a single parallel port of a printer to a thin ethernet

 - allows a host running tcp/ip to spool data to it

 - costs less than $1k ?
-- 
Fred Fierling   uunet!van-bc!mplex!fff    Tel: 604 875-1461  Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC   V5T 1A7,  Canada
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 11:02:09 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!chic@ucsd.edu  (Chris C. L. CHING)
To:        tcp-ip@nic.ddn.mil
Subject:   (HELP!) Question on socket (Datagram)

	Hi, I got a problem of using socket on sun. The "recmsg" call is 
supposed to wait for a message to arrive if no messages are available at 
the socket. But I don't know why it does not do that in my program.
My program terminated normally and received 0 byte. I was running my
program in SunOS 4.0.3 environment.

	Does anyone know how to solve my problem?

	Thanks in advance.

Here is my program
-------------------------------------------------------------------------
#include <stdio.h>
#include <sys/un.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/uio.h>
#include <errno.h>

#define	NAME	"sock"
#define NAMESIZE	256
#define STDOUT	1


extern	int	errno;
caddr_t		malloc();

main()
{
	int sd;
	int fd;
	int nc;
	struct sockaddr_un master;
	struct msghdr *msg;
	struct iovec  *iobuf;

	sd = socket(AF_UNIX, SOCK_DGRAM,0); /* datagram */
        iobuf = (struct iovec *) malloc(sizeof(struct iovec));
	msg = (struct msghdr *) malloc(sizeof(struct msghdr));
        bzero ((char *) msg, sizeof *msg);
	msg->msg_name = (caddr_t) malloc(NAMESIZE);
	msg->msg_namelen = NAMESIZE;
	msg->msg_iov = iobuf;
	msg->msg_iovlen = 1;
	msg->msg_accrights = (caddr_t) malloc(NAMESIZE);
	msg->msg_accrightslen = NAMESIZE;

	master.sun_family = AF_UNIX;
	strcpy(master.sun_path, NAME);
	if (bind(sd, (struct sockaddr *)&master, strlen(master.sun_path) + 
		sizeof(master.sun_family))<0) {
		perror("bind");
	}
	if ((nc = recvmsg(sd, msg, 0))<0)
		perror("recverr");
			
	fd = *((int *) msg->msg_accrights);
	close(sd);
	unlink(NAME);
}
---------------------------------------------------------------------------
|Chris Ching
|The University of Melbourne
|Department of Computer Science
|Parkville, 3052, Australia
|ACSNET: chic@munmurra.cs.mu.OZ.AU
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 14:39:48 GMT
From:      mcsun!unido!uklirb!incas!popper!zessel@uunet.uu.net  (Holger Zessel)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about caching in UDP based RPC (AND bug in UDP Cache?!)
jeff@hpctdkp.HP.COM (Jeff Hughes) writes:

 >>Your cache will not ensure execute at most once behavior.  Think about
 >>a server and three clients.  The server gets an RPC from client 1,
 >>then 2, then 3.  But it must trash the cache from client 1 in order 
 >>to store client 3's result.  Now it gets a resend from client 1; it
 >>will execute the service routine a second time.
 >>The trick to caching UDP/RPC results it to cache exactly one result for 
 >>each client the server has.  The cost is 8K per client, max.  You never
 >>need to cache more than one response from each client, since a client 
 >>will only send a new RPC only if the old one has been completed.

 >This is a good idea. I believe there are some exceptions to the 1 reply
 >per request rule, however. I believe the "spray" application will blast
 >a host with a number of packets before requiring a reply. 
 
There is no need to implement a cache for RPC replies in UDP.
At least RPC3.9 and 4.0 contain a call "svcudp_enablecache" which does
exactly what you want !
Its arguments are the transp and the cachesize. The cache is implemented as a
fifo.
With cache enabled RPC will cache every sent reply until it has to be trashed
as the fifo pointer is at the same cell again.
You don't have to worry about collisions between client replies. The
cache can distinguish between all clients and all their messages using
the RPC transaction id's and the sockaddr_in structure of the clients
(and some other additional values).

I used it successfully in a not-in-kernel implementation of an NFS server.
I first noticed its correct working every time in dbx where clients
always time out when I single step through the server code. I added some
"sent cached reply"-line to RPC which told me it worked.

BUT BEWARE !
In some RPC3.9 the cache is ok. In 4.0 a simple bug was introduced.
Therefore the cache did not work for SunOS4.03. As I had to use
our suns I took RPC4.0 sources and made a really LITTLE patch to them:

In file rpc/svc_udp.c, routine svcudp_recv, which is called by the server
getting packets from the clients.

....getting a packet through recvfrom...
....some xdr managing...
and now: /* comments are mine */
if (su->su_cache != NULL) { /* cache yes/no */
       if (cache_get(xprt, msg, &reply, &replylen)) { /* cache hit ? */

			/* yes ! a hit ! therefore send stored reply ! */
                 (void) sendto(xprt->xp_sock, reply, (int) replylen, 0,
                      (struct sockaddr *) &xprt->xp_raddr, xprt->xp_addrlen);
fprintf(stderr,"Sending cached reply...\n"); /* my debug line !*/
		return (FALSE); /* Here was TRUE before !!! And this was
				   the bug ! Returning true causes the
				   the serverfunction to be called despite
				   a reply was sent already ! */
       }
...


I hope that helps some other people trying to use the cache too.
Keep hacking !
	Holger

>jeff@hpctdlb.hp.com
----------------------------------------------------------------
Holger Zessel, uucp: ...!uunet!unido!uklirb!incas!zessel
	or	zessel@informatik.uni-kl.de
	or	zessel%informatik.uni-kl.de@relay.cs.net (from usa)
Fachbereich Informatik, SFB124-D1
Universitaet Kaiserslautern, West-Germany
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 18:29:43 GMT
From:      bu.edu!polygen!bill@uunet.uu.net  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   rwhod problems with Xenix/286
I installed Xenix/286 2.3.2, and Excelan's LAN Workplace for Xenix/286 and
have noticed a problem.  When the system starts up, everything starts up
great, ecept for the rwhod program.  When the rc script file is excecuted,
I get the following message:
rwhod: send:Bad address
I have all my routing info set up, the Excelan driver works perfectly. Any
help would greatly be apprecited.


+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 18:35:03 GMT
From:      bu.edu!polygen!bill@uunet.uu.net  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   ftp on Xenix/286
I have a 386SX system set up with Xenix/286 2.3.2, and Excelan's LAN Workplace
for Xenix/286.  When I use ftp, after every command, I get "error on read".  During
a get, I get it multiple times.  TFM (as in RTFM :-) doesn't tell me squat.  Telnet works
great, and installation went by flawlessly.  The only other problem is when rwhod gets
installed, but thats a different problem.  Thanks for any help you can give me.


+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 May 90 18:58:06 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser@ucsd.edu  (Jan Engvald)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Lantastic vs. the World - Problems?
In article <11484@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes:
>One of our user areas here has decided that they want to use one of those
>PC network products call "Lantastic" with WD8003 Ethernet cards.  Up to
>now our LAN has been exclusivly TCP/DECnet/XNS and we've standardized on
>3c503 cards for PC's.
>
>The apparent reason for going with the WD8003 cards is lack of Netbios
>support for the 3c503.  I find this somewhat hard to argue with.
>
>Has anyone had any interoperbility problems with Lantastic and traditional
>protcols on the same Ethernet?  I know there shouldn't be, but I'd like be
>sure before these guys commit (me) to a bunch of new hardware and software.
>
>Is the Lantastic stuff yet another unique proprietary protocol or is it
>related to something more generic?

Don't run Lantastic on a big LAN or you can expect interference with
other protocols sooner or later. We have had to forbid Lantastic nets
to be connected to our backbone because it upsets our HP computers
(HP 3000 type).

The reason for this is that Lantastic is NOT runing ethernet 2
protocol (which have protocol id in byte 13-14 of the ethernet
packet), but is using an ISO-like packet (with a length in byte
13-14). However, they don't continue like an ISO-packet, instead of
required headers they have their own data. This confuses for all of
those that uses ISO-packets the right way (or almost right :-).
I know for sure that it affects HP Advancenet used by HP 3000
computers. I expect it will affect DECnet phase 5 too and also
ISO IP protocols.

There are two ways for the Lantastic developers to fix it:

- They can make it an ethernet 2 packet by applying for a unique
  protocol id that they can put into byte 13-14.

- They can add the required ISO headers after byte 14.

I have several times sent the above info to the Lantastic developers
(and Lantastic engineering management have visited me to discuss
it!!), but as of yet they have not changed their protocol. Its a
pity, because Lantastic is otherwise a very good low cost network.

                                             
Jan Engvald, Lund University Computing Center
________________________________________________________________________
   Address: Box 783                E-mail: xjeldc@ldc.lu.se
            S-220 07 LUND     Earn/Bitnet: xjeldc@seldc52
            SWEDEN           (Span/Hepnet: Sweden::Gemini::xjeldc)
    Office: Soelvegatan 18         VAXPSI: psi%24020031020720::xjeldc
 Telephone: +46 46 107458          (X.400: C=se; A=Delta; P=Sunet; O=lu;
   Telefax: +46 46 138225                  OU=ldc; S=Engvald; G=Jan)
     Telex: 33533 LUNIVER S
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 May 90 02:04:05 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: "ttcp" program

Ttcp is handy for tuning a TCP or UDP implementation.

Versions of ttcp can be found in sgi/src on sgi.sgi.com, currently
192.48.153.1.  ttcp.c.brl is the most recent BRL version I've seen.
Ttcp.shar is from last August.  Ttcp.c is our current understanding of what
was acceptable to BRL.  It includes controls for buffer alignment and other
things.  By default it is a file transfer program, needing '-s' to make it
generate and sink data as a test program.

I think there are also versions available from BRL, perhaps on brl.mil.
They are probably newer than sgi:.../ttcp.c.brl.

Ttcp has never appeared in comp.sources.unix, although I understood from
the moderator that it would someday.  If you buy a Silicon Graphics "IRIS",
you'll find ttcp.c among other example and test programs in
/usr/people/4Dgifts.

There was some hassle with the port number.  The original port 2000
conflicted with a certain solar window manager, currently the default
window manager for SGI.  BRL and SGI checked with the Net Gods about
getting an official port number for ttcp, but failed.

Be careful to understand the numbers people give you.  Not long ago a
vendor trying to sell stuff gave me what I thought were some good numbers.
A few weeks later they happened to mention to some of my colleagues that
the numbers were obtained by summing some simultaneous tests.
It is as they say, "lies, damn lies, and benchmarks."


Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 May 90 02:24:43 GMT
From:      watson!sob@tmc.edu  (Stan Barber)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PC-LAN connection to Usenet
In article <798@banyan.UUCP> gordon@banyan.com (Gordon Lee@Eng@Banyan) writes:
>For cases where you have an Internet connection, it is possible to write
>an NNTP server for an OS/2 machine.  The NNTP protocol can run over any 
>stream oriented transport protocol, of course the protocol of choice would
>be TCP/IP stack since NNTP implementations within USENET are usually talking 
>TCP/IP, (I haven't heard of an implementation which uses a different protocol).

The "canonical" NNTP for Unix has supported TCP/IP and DECNET for a very
very long time.

There is an implementation that run on VMS that supports TCP/IP and DECNET.

There are rumors of other implementations (on VM) that may support other
transports.

Please see "news.announce.newusers" for the "USENET: History and Sources"
posting for more information on NNTP and the platforms is it available on.


Maintainer of NNTP and RN/RRN,
--
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: {rutgers,mailrus}!bcm!sob   and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 May 90 04:58:51 GMT
From:      iscden!jbev@boulder.colorado.edu  (J.Bevier @ Home on Hipeak)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip software

	I am looking for public domain software for tcp, ip, tftp,
ftp, and telnet. I am doing a port to a new environment and need
all of the software.  Could someone please direct me to an archive site
or UUCP site were I can download the the software.  

	Thanks,

	Jim Bevier

---
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+=+     From the mountains of Colorado:                       +=+
+=+           when it's not snowing, the sun is shining       +=+
+=+     Jim Bevier    -   J B Systems   (303)-697-1038        +=+
+=+         10136 Horizon View, Morrison, CO 80465            +=+
+=+     jbev@iscden.UUCP   or   ...!boulder!iscden!jbev       +=+
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 May 90 21:08:49 -0400
From:      vcerf@NRI.Reston.VA.US
To:        tcp-ip@nic.ddn.mil
Cc:        jif@venera.isi.edu
Subject:   What is the IAB?
Roy Smith:

Please see RFC 1120 which you can obtain by anonymous FTP
from the DDN NIC (nic.ddn.mil). This RFC will be updated
soon to reflect the addition of several new members to the
IAB (Tony Lauck from Digital Equipment Corporation and
Lyman Chapin of Data General - who is also chairman of
ANSI X3S3.3).

Those interested in IAB actions may find monthly summaries
in the Internet Monthly published by Joyce K. Reynolds and
Jonathan Postel of USC-ISI. The Executive Director of IAB
is Bob Braden also of ISI.

Vint Cerf
Chairman, IAB
Corp. for National Research Initiatives
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 May 90 22:20:49 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY

I have a few comments on the use of gateway filtering for security purposes.

In my opinion, it is suitable only as a temporary, emergency response to an
actual attack, and for "buying time" until the security holes in individual
hosts can be fixed. It is admittedly preferable to going off the Internet
entirely.

As standard operating procedure, however, gateway filtering has two serious
drawbacks:

1. It makes life much more difficult for the legitimate users. You are often
forced to "stage" your operations through a "secure" gateway. This is not
the seamless, easy-to-use network that the Internet was supposed to be all
about.

2. It is not entirely secure, either. The usual goal in gateway filtering is
to allow locally originated connections to go out while keeping externally
originated ones from coming in except to specified hosts. But an IP router
is a connectionless entity, so this can only be done heuristically,
typically by violating layering and examining the destination port fields of
the TCP and UDP headers.

Although it is currently fashionable to think of the "layering violation" as
an obsolete taboo, experience has taught me to stop and think hard before
committing one because they have a way of coming back to bite you, albeit
not for a while.

The problem here is that "only the hosts know for sure" when it comes to the
meaning of a port number.  True, *most* do adhere to Internet convention in
that servers usually listen on ports less than 1000 while clients usually
originate using ports above 1000, so a gateway that discards incoming
packets destined to ports below 1000 *usually* has the desired effect of
allowing outbound traffic while blocking incoming traffic.

But what about hosts that don't follow this convention?  I only recently
discovered that Xylogics AnnexII terminal servers listen on TCP port 5000 in
addition to the standard Telnet port, 23. So if somebody puts up an Annex
box on your "safe" network and doesn't turn on the security option, he has
just made all the hosts on your network accessible from the outside even
though your gateway is supposedly blocking all incoming traffic. And even if
you take care of this specific problem, how do you know that somebody on
some machine somewhere on your network isn't running a homegrown server that
listens on an unrestricted port, creating yet another opening?

I feel very strongly that true Internet security can only be achieved when
it is widely recognized that each host must take the responsibility of
protecting itself instead of relying on other network entities to do it.
Yes, it takes more work to do it right, but the results will be worth it.

Phil
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon 14 May 90 10:26:55-PDT
From:      Ole J. Jacobsen <OLE@CSLI.Stanford.EDU>
To:        tcp-ip@nic.ddn.mil
Cc:        ietf@venera.isi.edu
Subject:   Commercial IP service offerings

Hi,
	One of the sessions planned for INTEROP 90 (Oct 8-12)
deals with commercial IP services, that is companies offering
internet (or Internet) connectivity for a fee. We know about
PSI and UUNET's AlterNet, but we are looking for concrete
information about RBOCs offering similar services. So far, all
I've heard are rumors.  Any information would be greatly appreciated.

Thanks,

Ole
-------
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 May 90 12:22:07 -0400
From:      Michael T. Stolarchuk <mts@terminator.cc.umich.edu>
To:        zessel%popper%incas%uklirb%unido%mcsun.uucp@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: question about caching in UDP based RPC (AND bug in UDP Cache?!)

   >>The trick to caching UDP/RPC results it to cache exactly one result for
   >>each client the server has.  The cost is 8K per client, max.  You never
   >>need to cache more than one response from each client, since a client
   >>will only send a new RPC only if the old one has been completed.

   >This is a good idea. I believe there are some exceptions to the 1 reply
   >per request rule, however. I believe the "spray" application will blast
   >a host with a number of packets before requiring a reply.

I don't really want to get too involved in this discussion, but I have
decided to add my (short) thoughts.  Maybe I'm adding some complexity
to an already noisy issue...

One of the (current) largest uses of RPC's around here is for NFS.
I mentioning that not because I think we ought to tune RPC's for NFS,
but rather to point out that there are RPC's which are used to exchange
large amounts of data.

Painful delays exist.  Partially due to (MOST) RPC's not using windoing
to transmit data... like TCP...

Mostly people make a decision not to do windoing since they assume
they are shipping small amounts of data... I don't windowing will
help NFS too much, since most of the UDP packets it wants to send out
are either 8 or 4k.

But if your needs are 'exchange of large amounts of data in one direction'
and you would like to use an RPC, some attributes of TCP would be
*real nice*.

mts. the snail.
ann arbor, mi.
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 May 90 11:02:13 EDT
From:      jas@proteon.com (John A. Shriver)
To:        tcp-ip@nic.ddn.mil
Subject:   Lantastic vs. the World (& Novell) - Problems?
Oh boy, another protocol using IEEE 802.3 without IEEE 802.2!  Novell
NetWare does that out of the box on "Ethernet" as well.  I bet
Lantastic and Novell NetWare absolutely go crazy trying to share one
Ethernet!  I guess people still don't understand the why's and
wherefores of layered network architectures.

My Sun with ISO didn't crash over NetWare, but it did log one message
to disk for every NetWare broadcast packet.  Ran out of disk space
real fast.

At least you can repair NetWare, using the barely documented ECONFIG
program.  It will change back to using Ethernet frames with type 8137,
at least for most NetWare Ethernet drivers.
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 May 90 14:00:21 GMT-0400
From:      ad@cis.brown.edu (Arif Diwan)
To:        tcp-ip@nic.ddn.mil
Subject:   "pop" Reply to Lloyd Buchanan

							>>>Original msg<<<
...   Is there a BSD/SunOS compatible version ....
								>>>EOM<<<

We have three BSD compatible pop servers:

1. POP II which came from IBM YorkTown which has been hacked around at several  
sites

2. MHPOP by Marshall T. Rose, which we have used

3. MHPOP modified at MIT using Kerberos authentication.

You can get the latter two from athena-dist.mit.edu. If you use the Kerberized version  
you will also need the Kerberos authentication package from athena-dist. We are  
using that with another package from MIT - Techmail. Which runs on the MAC. It is  
great. That is also available from athena-dist via anonymous ftp.
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      14 May 90 13:57:08 GMT
From:      axecore!lloyd@uunet.uu.net  (Lloyd Buchanan)
To:        tcp-ip@nic.ddn.mil
Subject:   pop

Just received a marvelous, though expensive, product for the Macintosh
called TCP/Connect.  For the purpose of receiving mail, this program 
requires a "pop" server.  Never heard of it.

Is there a BSD/SunOS compatible version of this protocol around.

Please email any suggestions.

thanks
-- 
Lloyd Buchanan                          lloyd@Axecore.COM
Axe Core Investors                      uunet!axecore!lloyd
Axe Castle 	                        (914) 333-5226 (phone)
Tarrytown,  NY  10591                   (914) 333-5208 (FAX)
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      14 May 90 17:56:42 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!ns!jmh@tut.cis.ohio-state.edu  (Joel Halpern)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
An article proposed using a filtering gateway to improve security of an internet
connection.  Phil commented that he considers this an emergency measure, and 
pointed out that one telnet server listens on port 5000, which breaks the 
filtering.

I agree with Phil (and several other people) that overall security requires that
hosts be improved.  I will note however that, by assumption, perfect security is
impossible.  There will always be holes.   Ignoring the case where you do not know
what your local servers are doing, a filtering gateway can provide significant
security enhancements.  It is certainly not perfect.  But the statelessness is not
a difficulty, if the filtering can be sufficiently smart.  

We have a router here which filters such that I can initiate FTP sessions outward
from my host, but they can not be initiated inwards.  Similarly with regard to
telnet.  Now,  we have a machine which does have inward access, and if security
were breached on that one could go anywhere.  Therefore, we can focus most of 
our energy on managing that machine well.  (Not that we can neglect everything 
else, but it is ehlpful to know where ones biggest weakness is.)

Joel M. Halpern			jmh@nsco.network.com
Network Systems Corporation
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 May 90 23:32:43 GMT
From:      cayz@louie.udel.edu  (James Cayz)
To:        tcp-ip@nic.ddn.mil
Subject:   Mac <-> SMTP via Enet box info needed

Hi all,

	If this is posted in the wrong place, I do apologize, I tried to pick
the most applicable groups....

	Scenerio:  Localtalk Net, Macs for now, PC probably later, using
LocaltalkPC or LocaltalkPS/2 cards, all on Farallon network.
Ethernet, with a KA9Q-based SMTP server in-place (IBM PC), 2 IBM PC/AT's with
3C501 or 503 cards in them, running (as need be) KA9Q (for mail), and NCSA (for
telnet, etc) (Can't get KA9Q termcap on remote Unix boxes to work right!).

	Questions:  I am looking for Mail for the Macs.  Both Mac<->Mac and
Mac<->Outside world (via Ethernet).  I know that most Mac<->Mac systems require
a server, which I don't have available (I have an AppleShare Server, with the
Printer Spooler in the foreground, and a 128K Mac working not doing anything).
I would like to know:
1) Are there any mac<->mac systems that don't require a server 
	(or maybe use a 128K Mac, or a remote server on the Ethernet?) ???
2) Are there any Mac<->Ethernet smtp systems, given that I get a Fastpath,
	Shiva EtherGate (with TCP/IP) or GatorBox? KA9Q for the Mac???
3) If there are no server-less mac<->mac systems, but there are mac<->smtp
	systems, can I go macA->smtp->macB given some funky routing on my smtp
	router?

	Please, Please, Please mail all replies directly to me,
cayz@louie.udel.edu (Internet).  I don't get to read this groups as often as I
should.....

	Thank you all in advance for your replies.

	James Cayz

|James Cayz can be found via:    USPS: Educational Technology Laboratory
|EMAIL Internet: cayz@louie.udel.edu : 203 Willard Hall Education Building
|PHONE: +1 302 451-6307              : University of Delaware, Newark DE 19716
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 May 90 10:43:25 PDT
From:      braden@venera.isi.edu
To:        iesg@venera.isi.edu, ietf@venera.isi.edu, irsg@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   IAB Monthly Report -- April 1990

IAB Report for April 1990:

A. MEETING

    The IAB held a video teleconference on May 26, 1990.  Minutes of this
    meeting will be published as soon as possible.

B. STANDARDS ACTIONS

   During April, the IAB took the following actions concerning Internet
   standards, following recommendations from the IESG.  These changes
   will be reflected in the next edition of the IAB Official Protocols
   RFC.

   1. Advance to Standard:

       SNMP -- Simple Network Management Protocol (RFC-1098)

       SMI -- Structure and Identification of Management Information
              for TCP/IP-based internets (RFC-1065)
       
       MIB I -- Management Information Base for Network Management
              for TCP/IP-based internets (RFC-1066) 
                 
   2. Advance to Draft Standard:

       RFC-1006 -- ISO Transport Service on top of TCP 
 
       RIP -- Routing Information Protocol (RFC-1058)
      
       NICNAME -- WhoIs Protocol (RFC-954)  
                                                         
   3. Designate as Proposed Standard:
                                              
       MIB II  -- Extensions to MIB
    
       OSPF -- Open Shortest Path First IGP (RFC-1131)
                                            
   4. Retain as Proposed Standard:

       NNTP -- Network News Transfer Protocol (RFC-977) 
    
   5. Move back to Experimental:

       VMTP -- Versative Message Transaction Protocol (RFC-1045)

C. STANDARDS STATUS

    The IAB has held extensive discussions on possible improvements in
    the way that status (e.g., Elective vs. Recommended) and
    applicability is attached to Internet protocol specifications, but
    decision has not yet been reached on these issues.  The intent of
    any change would be to give vendors and users better guidance in
    determining the relevance of each standard.

    The IAB welcomes constructive input from any member of the Internet
    community on these and any other issues relating to the standard-
    ization process.  Send comments to Vint Cerf, chair of the IAB
    (VCerf@NRI.RESTON.VA.US) or to Phill Gross, chair of the IETF
    (PGross@NRI.RESTON.VA.US).

D. WORKING WITH ANSI

    Three members of the IAB, along with interested IETF members, met
    with ANSI X3S3.3 on April 18 and April 20 in Tucson, Arizona.  At
    that meeting we discussed the possibility of introducing several
    new work items for entering IP, ICMP, TCP and UCP into the American
    National Standards track.  A vote by the members of X3S3.3 was put
    off until June 27th, to allow X3S3.3 members to discuss these
    proposals with their respective organizations and to come to
    conclusions about the advisability and feasibility of entering the
    TCP/IP protocols into ANSI.

    Joint work with ANSI is already under way within the IETF OSI area,
    specifically with respect to the IS-IS dual routing protocols (OSI
    and TCP/IP). It is anticipated that joint meetings or, at least,
    colocated IETF and ANSI X3S3.3 meetings, will be scheduled in the
    future.

Bob Braden
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 May 90 12:36:34 MST
From:      cire|eric <cire@cisco.com>
To:        hal@gateway.mitre.org (Hal Feinstein)
Cc:        tcp-ip@nic.ddn.mil, dscott@gateway.mitre.org
Subject:   Re: SNAP on Ethernet

Hal,

Your message appeared very confusing to me.  Perhaps I can clear some
of that up.

SNAP (Sub-Network Access Protocol, don't ask me) is a 5 byte header
appended after the 802.2 header in 802 packets.  Its use is denoted by the
use of the LSAPs 0xAA (170 decimal, internet network order) and Unnumbered
Information.  It consists of two fields, a three byte OUI (organizational
unique identifier) and a prototcol type.  The OUI identifies the prototcol
family that the protocol type field values come from.

One common use of SNAP is to allow the use of ethernet type codes to denote
what kind of information is inside a packet.  You will have a MAC header
(802 mac), 802.2 header (DSAP=0xAA, SSAP=0xAA, CTL=0x3 (UI)), SNAP header
(OUI=0x000000, type field), and protocol data.  The type field for an
OUI of 0 is exactly the same 16 bits of what Ethernet uses.

>> Date: Tue, 15 May 90 10:47:29 EDT
>> From: hal@gateway.mitre.org (Hal Feinstein)
>> Subject: SNAP on Ethernet
>> 
>> The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol 
>> defined by ISO to rides just above the Ethernet LLC layer to indicate 
>> (among other things) the protocol ID of the next higher layer of 
>> protocol (IP, ARP, etc.).  There is talk of using SNAP with IP-on-Ethernet,
>> replacing the current trick (see RFC-1042) used to identify this 
>> next higher protocol layer.   But the jury is out as 
>> far as if and when this replacement will occur.  

RFC-1042 defines how to use SNAP to encapsulate protocols using ethertypes
and notably IP on 802 media.  Since 802.3 is already an 802 media it
already defines how do using snap on 802.3.  At this time few people
do it.

There is no such thing as using SNAP with IP-on-Ethernet.  It is IP on 802.3
which would use 1042 mechanisms including SNAP to incapsulate the IP packet.

There is no jury.  Whether this is implemented or not depends mostly
on vendor implementations in primarily the end nodes.  Yes routers have
to do it too.  However, this stuff already exists and some people are
using it.

>> I'm trying to get a better view of what experiences people have using or
>> planning for SNAP (if they have at all) and what commercial products
>> people have run into (gateways for example) that contemplate introducing
>> it.  Is it worth designing into a future product?  Any information would
>> be highly appreciated.

Cisco already handles SNAP'd protocols.

>> 			Thanks in advance.  -hal@gateway.mitre.org

-c
cisco engineering
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 May 90 10:47:29 EDT
From:      hal@gateway.mitre.org (Hal Feinstein)
To:        -v@gateway.mitre.org, tcp-ip@nic.ddn.mil
Cc:        dscott@gateway.mitre.org
Subject:   SNAP on Ethernet
The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol 
defined by ISO to rides just above the Ethernet LLC layer to indicate 
(among other things) the protocol ID of the next higher layer of 
protocol (IP, ARP, etc.).  There is talk of using SNAP with IP-on-Ethernet,
replacing the current trick (see RFC-1042) used to identify this 
next higher protocol layer.   But the jury is out as 
far as if and when this replacement will occur.  

I'm trying to get a better view of what experiences people have using 
or planning for SNAP (if they have at all) and what commercial products  people
have run into (gateways for example) that contemplate introducing it. 
Is it worth designing into a future  product?  Any information would
be highly appreciated.

			Thanks in advance.  -hal@gateway.mitre.org
				 


 

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 May 90 13:15:08 EDT
From:      Dave_Katz@um.cc.umich.edu
To:        tcp-ip@nic.ddn.mil
Cc:        dscott@gateway.mitre.org
Subject:   SNAP on Ethernet
>The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol
>defined by ISO to rides just above the Ethernet LLC layer to indicate
>(among other things) the protocol ID of the next higher layer of
>protocol (IP, ARP, etc.).  There is talk of using SNAP with IP-on-Ethernet,
>replacing the current trick (see RFC-1042) used to identify this
>next higher protocol layer.   But the jury is out as
>far as if and when this replacement will occur.
 
A few technical nits:  The Subnetwork *Access* Protocol (SNAP) is defined
by IEEE 802.1a and is *5* bytes long.  It rides just above the *802.2*
LLC layer (which in turn runs over 802.3, *not* Ethernet).  The SNAP
protocol is intended to be used by "non-standard" protocols (those
not assigned an LSAP value by IEEE), and includes a 3 octet Organizationally
Unique Indentifier (OUI, otherwise known as the Manufacturer ID in
MAC addresses) and a 2 octet protocol indentifier assigned by the owner
of the OUI.
 
If the OUI field is all zeroes, the protocol identifier field is defined
as carrying the familiar 2 octet Ethernet Type value.  This is the more-
or-less standard way of carrying Ethernet protocols across true 802
media (which cannot use the EtherType field).
 
RFC1042 in fact uses the SNAP "trick" to carry IP and ARP over 802 media,
and RFC1103 (and the Internet Draft that replaces it) specifies the same
for FDDI.
 
The use of SNAP to carry IP over 802 media is extremely unlikely to change.
 
Be careful about the terms "Ethernet" and "802.3"--they refer to the same
media, but different framing conventions.  Ethernet frames carry a 2 octet
type field for higher layer protocol identification, while 802.3 frames
carry a 2 octet length field and a 3 octet 802.2 LLC header.  Both can
run simultaneously on the same wire.
 
There is very little use of 802.3/SNAP for IP, due to interoperability
difficulties with Ethernet/IP.  802.5/SNAP/IP is used exclusively on
token rings, and FDDI/SNAP/IP will be used on FDDI rings.
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 May 90 17:12:19 PDT
From:      braden@venera.isi.edu
To:        hal@gateway.mitre.org, jas@proteon.com
Cc:        -v@gateway.mitre.org, dscott@gateway.mitre.org, tcp-ip@nic.ddn.mil
Subject:   Re:  SNAP on Ethernet

	Not implementing SNAP in an IEEE 802.2 implementation would be
	incredibly shortsighted, unless the only protocol stack you want is
	ISO.

It would also violate the Host Requirements RFC; please see section
2.3.3 of RFC-1122.

Bob Braden

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 May 90 14:40:42 EDT
From:      jas@proteon.com (John A. Shriver)
To:        hal@gateway.mitre.org
Cc:        -v@gateway.mitre.org, tcp-ip@nic.ddn.mil, dscott@gateway.mitre.org
Subject:   SNAP on Ethernet
SNAP is not used on Ethernet.  (It uses Ethernet types.)  You might
see SNAP used on IEEE 802.3, as well as IEEE 802.4 and IEEE 802.5.  In
all cases, it runs on top of IEEE 802.2.  The definition of SNAP will
be in IEEE 802.1a, whenever it is approved.  It's in the current
draft.

Almost all protocols on IEEE 802.2 will use SNAP, since IEEE 802.2
SAP's are only available to protocols defined by established
international standards bodies.  Realize that the (generally unused)
DoD IP SAP in IEEE 802.2 was an *exception* to these rules, and they
would not give out a further SAP for ARP.  (The need for ARP is what
caused us to search out SNAP.)  However, anyone who owns a vendor
block (3-byte prefix of Ethernet/IEEE 802 address) can assign his own
SNAP types.  Also, vendor block 00-00-00 incorporates the existing
Xerox-assigned Ethernet types.

SNAP is only 5 bytes.  The preceeding IEEE 802.2 is 3 bytes.  This
sums to 8 bytes.

Not implementing SNAP in an IEEE 802.2 implementation would be
incredibly shortsighted, unless the only protocol stack you want is
ISO.
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 May 90 14:20:37 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!jh@ucsd.edu  (Juha Heinanen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Commercial IP service offerings
In Finland there has been a commercial IP service called DataNet
offered by the state PTT for about a year now.  It's backbone covers
all major cities in Finland and has many large and small customers.
Another competing IP service called LanLink is starting operation in
September.   You will meet people from both of these in Interop 90.
--
--	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 May 90 16:00:00 GMT
From:      usc!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu  (Nathaniel Mishkin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about caching in UDP based RPC (AND bug in UDP Cache?!)
In article <9005141622.AA17355@terminator.cc.umich.edu>,
mts@TERMINATOR.CC.UMICH.EDU (Michael T. Stolarchuk) writes:
|> Painful delays exist.  Partially due to (MOST) RPC's not using windoing
|> to transmit data... like TCP...
|> 
|> Mostly people make a decision not to do windoing since they assume
|> they are shipping small amounts of data... I don't windowing will
|> help NFS too much, since most of the UDP packets it wants to send out
|> are either 8 or 4k.
|> 
|> But if your needs are 'exchange of large amounts of data in one direction'
|> and you would like to use an RPC, some attributes of TCP would be
|> *real nice*.

Yeah, I'll admit that when I built the first version of our RPC system
(NCS), I said:  "Ah, who'd want to send more than a few K of data in
a remote call anyway; why bother with all the hair?"  But of course,
it's not only the file system types who want to do that, but you run
into these people who want to pass some 1000x1000 array of double precision
floating point numbers from their workstation to their minisuper.  I
heard from them pretty quick.  The latest version of our system does
windowing just like the big boys.  The hard thing is to keep the machinery
that supports all that out of the way of the person who wants to make
a call whose in's and out's can each be represented in one datagram.

                    -- Nat Mishkin
                       Hewlett Packard Company / Apollo Systems Division
                       mishkin@apollo.com
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 May 90 19:36:34 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: SNAP on Ethernet


Hal,

Your message appeared very confusing to me.  Perhaps I can clear some
of that up.

SNAP (Sub-Network Access Protocol, don't ask me) is a 5 byte header
appended after the 802.2 header in 802 packets.  Its use is denoted by the
use of the LSAPs 0xAA (170 decimal, internet network order) and Unnumbered
Information.  It consists of two fields, a three byte OUI (organizational
unique identifier) and a prototcol type.  The OUI identifies the prototcol
family that the protocol type field values come from.

One common use of SNAP is to allow the use of ethernet type codes to denote
what kind of information is inside a packet.  You will have a MAC header
(802 mac), 802.2 header (DSAP=0xAA, SSAP=0xAA, CTL=0x3 (UI)), SNAP header
(OUI=0x000000, type field), and protocol data.  The type field for an
OUI of 0 is exactly the same 16 bits of what Ethernet uses.

>> Date: Tue, 15 May 90 10:47:29 EDT
>> From: hal@gateway.mitre.org (Hal Feinstein)
>> Subject: SNAP on Ethernet
>> 
>> The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol 
>> defined by ISO to rides just above the Ethernet LLC layer to indicate 
>> (among other things) the protocol ID of the next higher layer of 
>> protocol (IP, ARP, etc.).  There is talk of using SNAP with IP-on-Ethernet,
>> replacing the current trick (see RFC-1042) used to identify this 
>> next higher protocol layer.   But the jury is out as 
>> far as if and when this replacement will occur.  

RFC-1042 defines how to use SNAP to encapsulate protocols using ethertypes
and notably IP on 802 media.  Since 802.3 is already an 802 media it
already defines how do using snap on 802.3.  At this time few people
do it.

There is no such thing as using SNAP with IP-on-Ethernet.  It is IP on 802.3
which would use 1042 mechanisms including SNAP to incapsulate the IP packet.

There is no jury.  Whether this is implemented or not depends mostly
on vendor implementations in primarily the end nodes.  Yes routers have
to do it too.  However, this stuff already exists and some people are
using it.

>> I'm trying to get a better view of what experiences people have using or
>> planning for SNAP (if they have at all) and what commercial products
>> people have run into (gateways for example) that contemplate introducing
>> it.  Is it worth designing into a future product?  Any information would
>> be highly appreciated.

Cisco already handles SNAP'd protocols.

>> 			Thanks in advance.  -hal@gateway.mitre.org

-c
cisco engineering

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 May 90 09:38:46 -0400
From:      "Louis A. Mamakos" <louie@sayshell.umd.edu>
To:        tcp-ip@nic.ddn.mil, jmh@ns.network.com (Joel Halpern)
Subject:   Re: A SUSPICIOUS SECURE GATEWAY

> We have a router here which filters such that I can initiate FTP
> sessions outward from my host, but they can not be initiated inwards.
> Similarly with regard to telnet.

I wonder what would happen if I kludged up a client telnet that used a local
port number of 23, and then tried to connect to your TELNET server?  Maybe
you thought about this particular problem, but there are lots of interesting
things you can do with source routed packets.

I know that I can't sleep any better at night knowing that I have a filtering
gateway "protecting" me.  If you want security, you need to take a comprehensive
approach to providing it, not shots in the dark here and there.

louie
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed 16 May 90 18:44:31-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        kwe@bu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
    With FDDI things get more complicated.  FDDI signals in 5 bit symbols.
    Four bits of data go into every five bits on the wire, so a byte takes
    10 bits.
	    :
	    :
    Then;	10**8 bits/sec x (1 frame/675 bits) = 148,000 pps


Well, if you are going to count the 4 to 5 encoding, then you also have
to count the wire data rate as 1.25e8 bps.  The 100 Mbps everyone talks
about is AFTER the funny bit encoding...  I doubt this makes much difference
the the 10x faster generalization.

BillW
-------
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 14:23:08 GMT
From:      e2big.dec.com!shlump.nac.dec.com!killie.enet.dec.com!colliton@decuac.dec.com
To:        tcp-ip@nic.ddn.mil
Subject:   tcp protocol

  Is there a field in the tcp protocol or other protocol that will  allow
  me to collect/rollup stats (frames, byte , duration ) on active between ports
  by user.  I do not wish  to identify  the user but  log the start of 
active  and
  collect stats  to the end of the active.
 
                                      Luke
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 16:13:08 GMT
From:      mailrus!accuvax.nwu.edu!delta.eecs.nwu.edu!morrison@uunet.uu.net  (Vance Morrison)
To:        tcp-ip@nic.ddn.mil
Subject:   56K, T1 Boards for PC : cheap bridge/IP router

Hello


Here are the results from my question on synchronous serial (56K or T1) 
cards for the IBM-PC.  Actually I got many more requests for this information
than reply's giving information, so the list below is not that long.
I am certainly willing to post an adendum to this list if anyone else
knows of any leads that do not apear below.

For those intrested in cheap bridges or routers, check my comment
below on Emerging Technologies.  They are commercially selling a
product very simmilar to PCroute/bridge (but developed independantly).
Note that I have no knowledge of how good or bad this product is and
have no stake in its success.   I merely present the information
because I believe it may be on interest to those who for whatever
reason can't/won't use PCroute/bridge.


Vance

-----------------------------------------------------------------------
From: "John D. Balogh" <JDB@ecl.psu.edu>

Check out the Proteon p4100 router options. That box is approximatly a PC with 
some option cards (Ethernet, Token Ring, SIO (Slow {56K}, Fast {T1}). 
I would assume that Proteon selected "good" SIO cards for thier box.

-----------------------------------------------------------------------
From: macy@fmsystm.UUCP

I understand Dialogic makes such a beast.  They have offices
in Austin, TX and in the Boston area.


---------------------------------------------------------------------------

From: "Dennis E. Baasch" (516)271-4525 <dennis@etinc.UUCP>


	Regarding your request for high speed synchronous cards for a PC,
Emerging Technologies has several cards which might meet your requirements.
We have both 8 and 16-bit cards, with each card a few different options. 
The 8-bit card will run any speed up to 1.544mbs, while the 16-bit card
will run 2.048mbs. We're coming out with a new 8-bit card (which will be
100% software compatible with the existing one) in a couple of months.
	Both cards have a LAPB/HDLC chip which provide co-processor like
functionality with a high-speed access shared memory interface. The cards
are capable of about 3500 frames per second at 1.544mbs.
	There are 2 development type products available for the cards, both
with 'C' language interfaces and drivers for MS-DOS or SCO XENIX. One is
an HDLC development system, and the other is a full X.25 development system.
Both use the same drivers for the cards, and both can support up to 4 cards
per machine. The X.25 driver allows individual cards to be run in HDLC mode,
allowing for mixed-mode applications (like routers) where you need a T1
line and an X.25 line.
	The 8-bit card (8mbs bus transfer rate) with a V.35 interface is
priced at $725 for 56kbs and $925 for T1. The 16-bit card (14mbs transfer
rate) is $995 for 56kbs and $1495. for T1. The HDLC driver is $285 per
CPU, X.25 is $375. per CPU, and there is a one-time fee of $325. for the
'C' libraries for either product.
	For further info, send me your address or give me a call
at (516) 271-4525.

900 Walt Whitman Rd.
Melville, NY. 11747


Note:  Denis is the Network Products manager for Emerging Technologies.

---------------------------------------------------------------------------

From: "Steven P. Donegan" <donegan@usc.edu>

The Sea Level Systems ACB-II card does quite a nice job of sync HDLC handling
at speeds from 0 to 1.544 MBPS. 

Sealevel Communications & I/O
P.O. Box 1808
Easley, SC 29641
803-855-1581

---------------------------------------------------------------------------

Additional Comments:  I check into the cards offered by Emerging Technologies
    and SeaLevel Systems and have some addtional Info on them

	Emerging Technologies:

		From what I could tell Emerging Technologies is actually
		in the buisness of selling a router/bridge that works
		on a IBM PC.  (Basically PCroute/bridge).  However in 
		some ways it is superior.  For example their package has
		SNMP, T1 and X.25 interface (if desired), as well as
		(I assume) support.    There prices are actually pretty
		good (for $2500 you could put together a nice
		ether-ether bridge or router).   They do sell the
		T1 and X.25 cards seperately but the price is reasonably
		steep (since that is not really what they are in the
		business of selling).  They do have XENIX and DOS
		drivers for those who are interested.

	Sea Level Systems:

		The ACB-II card Steve talks about is a nice board 
		and has a good price ($299).  Also for $20 more you
		can get a board that is identical except that it has
		two serial interfaces instead of just one.  

		The literature I have says the ACB-II only goes up
		to about 1.0 MBit/Sec.  This precluded T1 use.  
		However talking with the people at SLS, it seems that
		reasonably easy hardware mods may fix that.  If enough
		people ask, I suspect they would come out with a card
		capable of T1 speeds.  

DISCLAMER:  I am only relying what I read from the literature I have.
	    Thus take all of this with a grain of salt.  If you
	    REALLY want to know, call these people up yourself and ask.


Vance
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 May 90 23:31:59 PDT
From:      Greg Satz <satz@cisco.com>
To:        swrinde!cs.utexas.edu!oakhill!guri@ucsd.edu  (Gurvinder Singh Ahluwalia)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: "LARP" on Port 91 ?
According to the latest Assigned Numbers RFC, protocol number 91 is:

          91     LARP        Locus Address Resolution Protocol     [BXH]

and BXH is:

   [BXH]     Brian Horn          Locus     ---none---

Apparently LARP is a protocol above IP, so any router, including those from
cisco Systems, Inc., should forward those packets just fine.

If you have any further questions about cisco products or technical
issues/interoperability questions, feel free to drop a note to
customer-service@cisco.com.

Greg Satz
cisco

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 18:59:54 GMT
From:      psuvm!ysub!doug@psuvax1.cs.psu.edu  (Doug Sewell)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp-ip source for SysV multi-user environment
I'm looking for tcp-ip source for a small SysV multi-user environment -
sufficient to support telnet in/out, ftp in/out, and e-mail in/out.
There will not be very many concurrent users.

I looked at the KA9Q SysV source (thanks to those that directed me
to vax.cs.pitt.edu) but as far as I could tell could support only one
user at a time.

I've also downloaded the Berkeley source, but I'd rather not attempt
to convert the code to SysV myself.

I will be writing my own driver for a non-standard adapter.

Any help, pointers, and recommendations are welcome.  Please reply to
me directly at one of the addresses below (doug@ysub.ysu.edu is probably
best).  I have FTP available, but no UUCP.

Doug Sewell, Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
E-mail: DOUG@YSUB.BITNET, DOUG@YSUB.YSU.EDU, ...!uunet!ysub.bitnet!doug
>> I am not a wizard.  What I do isn't magic.  I am a computer professional.
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 19:05:38 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bu.edu!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Max FDDI frame rate on the glass

	I was wondering what the maximum packet per second rate an
FDDI network would experience if 3 million monkeys were running
telnet, ie minimum sized frames, across an FDDI backbone.  I made some
calculations, with help from Ram Das Rao, who knows all about FDDI
frames, even if he hasn't seen many.  :-)

	With Ethernet the computation goes like so:

Interframe gap of 9.6 us = 96 bits = 12 bytes
Preamble                              8
MAC                                  14
Data                                 46 min (that covers IP and TCP mins)
CRC                                   4
                                     --
Total                                84 bytes/frame

This is the absolute minimum frame size that an Ethernet can support
on the wire, taking account of the interframe gap and all real bits.

Then; 10**7 bits/sec x (1 byte/8 bits) x (1 frame/84 bytes) = 14,880 pps.

Maximum sized packets fill up the wire at about 800 pps.

Those should be familiar numbers to most of you.  With FDDI things get
more complicated.  FDDI signals in 5 bit symbols.  Four bits of data
go into every five bits on the wire, so a byte takes 10 bits.  There
is also no interframe gap required in a token ring protocol.

	For FDDI the calculations go like:

Preamble (PA/SD/FC) =   19 symbols = 95 bits
MAC                     12 bytes   =120 bits
Data     (TCP min)      41 bytes   =410     (there is no FDDI min value)
FCS/ED/FS               10 symbols = 50
                                    ---
Total                               675 bits/frame  (min size)

Then;	10**8 bits/sec x (1 frame/675 bits) = 148,000 pps

	FDDI supports about 4k bytes as the maximum frame size.  That
is approximately 4000 bytes at 10 bits/byte;

	10**8 bits/sec x (1 frame/40,000 bits) = 2500 pps.  So, max
sized packets fill up the wire at a 2500 pps rate, versus about 800
for Ethernet.

	Conclusion:

	Guess what?  FDDI is 10x more than Ethernet, almost exactly.
Who would have thought?  [So we aren't talking 3 million monkeys- more
like a quarter million would do the job.]

	I thought you might be interested in the 150 kpps number for
future reference.  Sock it away up in the gray matter along with 15
kpps for Ethernet.  Or just know that the 10x approximation is
actually pretty good, all things considered.

	--Kent
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 20:41:23 GMT
From:      swrinde!cs.utexas.edu!oakhill!guri@ucsd.edu  (Gurvinder Singh Ahluwalia)
To:        tcp-ip@nic.ddn.mil
Subject:   "LARP" on Port 91 ?

Has anyone heard of a protocol called LARP? 

Context in which I have encountered this is IBMs Transparent Cluster
Facility (TCF) on the 4381 running VM/AIX. IBM indicates it employs
port  # 91. 

For those out there aware of this and also running cisco routers,
I would like to go a step further to find out compatibility of this
protocol on ciscos, including access/passage of LARP traffic through 
cisc.o Is there something that has to be enabled to allow LARP through
cisco? What is the default?

- Gurvinder

------
Gurvinder Ahluwalia		Internet: guri@apogee.sps.mot.com
Software Engineer		uucp	: {}oakhill!apogee!guri@cs.utexas.edu
Global Networking		Phone	: 512/891-3310
Motorola SPS
Austin, TX.
------
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 May 90 21:10:57 GMT
From:      orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu  (David Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
Kent,

In article <57399@bu.edu.bu.edu> kwe@bu.edu (Kent England) writes:
>         Conclusion:
> 
>         Guess what?  FDDI is 10x more than Ethernet, almost exactly.
> Who would have thought?  [So we aren't talking 3 million monkeys- more
> like a quarter million would do the job.]

Actually, I think it may really be more like 3 million, depending on the 
size of the ring.  Since FDDI allows a device to release the token after 
finishing its transmission (rather than after it receives the message it 
sent), it's possible to have multiple packets on the ring, particularly if 
they're small packets.  Does anyone feel like calculating how many packets 
can be carried per second by FDDI as a function of the number of nodes and 
length of fiber?  I don't know enough about the delay introduced by each 
node to do it.

                               David Walker
                               Network Services Manager
                               UC Irvine
                                 DHWalker@uci.edu
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 May 90 08:21:43 +0900
From:      David C. Hagiwara <Hagiwara@sm.sony.co.jp>
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Info.wanted on Dial up PPP
Does anyone inplemnt "Dial up PPP" ? 
Are there any RFCs describing the matter on dialing ?

(I have got the PPP of Perkins from CMU)

					Takashi Hagiwara
					(Hagiwara@Sm.Sony.Co.Jp)

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 00:52:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   RE: pinging a remote TCP port to see if it's in used

John Interrante,

>port number.  I don't mind explaining that the reason I asked was to
>improve a portmapper I wrote for InterViews programs making RPC calls.
>We couldn't use Sun's /etc/portmap because we wanted servers to
>register their TCP port numbers under a variable-length string of
>characters (i.e., a name), not a tuple of integers (i.e., a program
>number and a version number).  I noticed that SunOS 4.1's /etc/portmap
>will let you register the port number of a non-existent server, but it

        Do u mean non-existent server as those server dies/crashes after
registerred the port number to portmap?

>will unregister the port number and give you zero when you try to ask
>for the non-existent server's port number.  I set a breakpoint in a
>server to find out how portmap validated the server's port number and
>I know that the server never noticed a new connection.  Yet portmap
>definitely WAS validating port numbers in some way because I never got
>a port number for a non-existent server.  I checked the public RPC
>sources on gatekeeper.dec.com but the source for portmap didn't
>include this kind of code so that's why I posted my question.  I
>wanted to be able to validate port numbers in my portmapper too
>because it would prevent clients from trying to connect to a server
>that crashed after registering its port number with the portmapper.

        Since your server resides in the same host as portmap and your
server port number is kept by portmap, what you can do is to create a
dummy socket and bind this socket to the server port number. If the
bind fails and returns an error saying that the port number is in used, then
the server is still alive. If the binding is successful, then most likely
that particular server is dead since port number cannot be re-used. Note that
this technique can apply to check both UDP and TCP servers.

- Beng Hang Tay (email: taybengh@nusdiscs)
  Dept. Info. and Comp. Sc.
  National University of Singapore (NUS)

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 May 90 05:02 EDT
From:      Fitch@DOCKMASTER.NCSC.MIL
To:        tcp-ip@NIC.DDN.MIL
Subject:   COMTEN TCP
I would like to talk with someone about COMTEN TCP.  COMTEN's are
front-ends for IBM mainframes made by NCR.  I believe they also market a
TCP.  Right now I'm looking for basic product info.  Please provide a
phone number if you care to help.  Thanks.

--Jack (Fitch -at dockmaster.ncsc.mil) (301)738-8018
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 May 90 08:14:02 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bu.edu!kwe@UCSD.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Max FDDI frame rate on the glass
 > 	For FDDI the calculations go like:
 > 
 > Preamble (PA/SD/FC) =   19 symbols = 95 bits
 > MAC                     12 bytes   =120 bits
 > Data     (TCP min)      41 bytes   =410     (there is no FDDI min value)
 > FCS/ED/FS               10 symbols = 50
 >                                     ---
 > Total                               675 bits/frame  (min size)
 > 
 > Then;	10**8 bits/sec x (1 frame/675 bits) = 148,000 pps
 > 
 > 	FDDI supports about 4k bytes as the maximum frame size.  That
 > is approximately 4000 bytes at 10 bits/byte;
 > 
 > 	10**8 bits/sec x (1 frame/40,000 bits) = 2500 pps.  So, max
 > sized packets fill up the wire at a 2500 pps rate, versus about 800
 > for Ethernet.

Kent,

The FDDI signalling rate is 125,000,000 bits per second.
With the 4/5 encoding, that comes to 100,000,000 effective
data bits per second. This comes to just over 185Kpps
for the telnet monkeys and 3032pps for the 4096
data byte packets.

Frank Kastenholz
Racal Interlan


-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 May 90 16:52 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   RE: pinging a remote TCP port to see if it's in used
John Interrante,

>port number.  I don't mind explaining that the reason I asked was to
>improve a portmapper I wrote for InterViews programs making RPC calls.
>We couldn't use Sun's /etc/portmap because we wanted servers to
>register their TCP port numbers under a variable-length string of
>characters (i.e., a name), not a tuple of integers (i.e., a program
>number and a version number).  I noticed that SunOS 4.1's /etc/portmap
>will let you register the port number of a non-existent server, but it

        Do u mean non-existent server as those server dies/crashes after
registerred the port number to portmap?

>will unregister the port number and give you zero when you try to ask
>for the non-existent server's port number.  I set a breakpoint in a
>server to find out how portmap validated the server's port number and
>I know that the server never noticed a new connection.  Yet portmap
>definitely WAS validating port numbers in some way because I never got
>a port number for a non-existent server.  I checked the public RPC
>sources on gatekeeper.dec.com but the source for portmap didn't
>include this kind of code so that's why I posted my question.  I
>wanted to be able to validate port numbers in my portmapper too
>because it would prevent clients from trying to connect to a server
>that crashed after registering its port number with the portmapper.

        Since your server resides in the same host as portmap and your
server port number is kept by portmap, what you can do is to create a
dummy socket and bind this socket to the server port number. If the
bind fails and returns an error saying that the port number is in used, then
the server is still alive. If the binding is successful, then most likely
that particular server is dead since port number cannot be re-used. Note that
this technique can apply to check both UDP and TCP servers.

- Beng Hang Tay (email: taybengh@nusdiscs)
  Dept. Info. and Comp. Sc.
  National University of Singapore (NUS)
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 06:31:59 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: "LARP" on Port 91 ?

According to the latest Assigned Numbers RFC, protocol number 91 is:

          91     LARP        Locus Address Resolution Protocol     [BXH]

and BXH is:

   [BXH]     Brian Horn          Locus     ---none---

Apparently LARP is a protocol above IP, so any router, including those from
cisco Systems, Inc., should forward those packets just fine.

If you have any further questions about cisco products or technical
issues/interoperability questions, feel free to drop a note to
customer-service@cisco.com.

Greg Satz
cisco

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 May 90 10:58:39 EDT
From:      Bill Streilein <bstreile@wellfleet.com>
To:        philipp@gipsi.gipsi.fr
Cc:        tcp-ip@nic.ddn.mil
Subject:   Arp on point-to-point

Phillipe,

We solve this problem by running ARP over 
our point-to-point links.  Although there's
a direct connection to a specific host/gateway on
the other side, this allows dynamic mapping.

Bill Streilein / bstreile@wellfleet.com / Wellfleet Communications, Inc
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 07:04:03 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David
Walker) writes:
+---------------
|               ...  Since FDDI allows a device to release the token after 
| finishing its transmission (rather than after it receives the message it 
| sent), it's possible to have multiple packets on the ring, particularly if 
| they're small packets.  Does anyone feel like calculating how many packets 
| can be carried per second by FDDI as a function of the number of nodes and 
| length of fiber?
+---------------

According to the FDDI MAC spec I have (ANSI draft X3T9.5/88-139 Revision 1),
the maximum (idle-net) ring latency "D_Max" is 1.617 milliseconds, thus
the longest permitted ring has 20212.5 bytes of delay in the ring. This
is enough for about 4.5 maximum-length frames, or 631 claim frames, or
just under 266 TCP/IP "ack" packets (assuming RFC 1103 encapsulation).

This is why you don't wait for your message to come back. Ring throughput
would be horrible if you did.

-Rob


p.s.
The delay is a combination of fiber (speed-of-light) delay and station
(MAC entity) delay. There is a max of 1000 "MAC entities" and a max of 2km
between "PHY entities". (Loosely speaking, "PHY" is the optoelectronics,
and "MAC" is the byte-level state machine. These aren't one-to-one, because
you can have "single-attach stations" = 1 PHY / 1 MAC, "dual-attach" =
2 PHY / 1 MAC, "dual-MAC" = 2 PHY / 2 MAC, and "concentrator"= n+2 PHY/1 MAC.)

The spec shows how this delay can results from 200km of fiber (100 km
"circumference", to allow for ring "wrap" on failure) and 1000 stations,
assuming 5.085ns/m in the fiber and 600ns (15 symbols) in the PHY/MAC.

If on the other hand, you max out the distance between stations with
single-MAC dual-attach stations, you get another set of numbers. Since
a given fiber must be less than 2km, we have one 0.6us station delay
(15 symbols, including PHY, MAC, elasticity buffer, etc.) and 20.34us
fiber delay (2 fibers, 2km, 5.085ns/m) per hop. That gives 1617/20.94
or 77 stations max, for a 154km (duplex) circumference (308km of fiber).
(I'm not sure this configuration is permitted. Anybody know?)

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 May 90 13:31:08 CST
From:      POSTMASTER <CCBUSTER@VM.CC.OLEMISS.EDU>
To:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   AEDAVIS
Please remove AEDAVIS@VM.CC.OLEMISS.EDU or AEDAVIS@UMSVM from this list.  He
is no longer here.
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 10:33:05 GMT
From:      mcsun!hp4nl!tnosoes!tom@uunet.uu.net  (Tom Vijlbrief)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes:


>> We have a router here which filters such that I can initiate FTP
>> sessions outward from my host, but they can not be initiated inwards.
>> Similarly with regard to telnet.

>I wonder what would happen if I kludged up a client telnet that used a local
>port number of 23, and then tried to connect to your TELNET server?  Maybe
>you thought about this particular problem, but there are lots of interesting
>things you can do with source routed packets.

Filtering is done on destination port number (at least in my
adapted KA9Q) and not on host source port number. If you read the
posted README you would see that source-routed packets are rejected.

>I know that I can't sleep any better at night knowing that I have a filtering
>gateway "protecting" me.  If you want security, you need to take a comprehensive
>approach to providing it, not shots in the dark here and there.

You are correct, but how can you be sure that a local network
with dozens of Unix boxes with different administrators are
correctly installing their machines ? (E.g. not export NFS-filesystems
to the world as is the default).
How can you be sure that hunderds of users have non trivial passwords, etc.

Eliminating access to NFS, rlogin, telnet, FTP, ... from the outside
world to all the machines (or a selected group of machines) does
certainly make ME sleep much better.

I think that inspecting each host on your network is an example
of "shots in the dark here and there". Is a secure gateway not
an example of a comprehensive approach because it does effect all hosts on your
local network? (The KA9Q-gateway for examples catches by default all
RPC calls, so for example rwalld calls are catched. Did you
for example disable the rwalld on every host on your local
network ? And would did you do about source-routed packet attacks ?)


Tom
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu 17 May 90 15:45:34-CDT
From:      AFDDN.BEACH@GUNTER-ADAM.AF.MIL
To:        tcp-Ip@nic.ddn.mil
Cc:        AFDDN.BEACH@GUNTER-ADAM.AF.MIL
Subject:   CLNS and routing (IS-IS) and ES-IS
Help....
         .
           .
Can anybody tell me where to get any info at all on proposed routing 
protocols and implementations of them for the GOSIP world.  I assume
OSPF will be used.  What I'd really like is pointers to discussions
of how the routing would operate and clues on what implementations
might look like.  I'd also like any comments on resource utilization.
I think the ISO address formats look a lot harder to deal with than IP.

Please send responses directly to me so as not to clutter up this list...
AND if there's another list I should be talking to, feel free to flame
as long as you tell me the list's address.

Going from TCP/IP is like teaching a sho'nuff southern boy to talk with
a french accent.  It ain't easy!

Darrel B.
-------
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 12:53:26 GMT
From:      fernwood!portal!cup.portal.com!thad@uunet.uu.net  (Thad P Floryan)
To:        tcp-ip@nic.ddn.mil
Subject:   Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
{Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW}
{unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip}


If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
happy with the performance?

My experiences recently show the 10Mbit/S Ethernet to be an order of magnitude
SLOWER than the 1Mbit/S StarLAN between the same two systems under identical
load conditions, etc.   These tests were run on the SAME two systems with both
networks' cards and software installed.

To test, I alternated between:

	ftp> put /unix     (or get /unix  depending on the direction)
and
	uuto unix tlabs3!thad

multiple times.  For uucp I've set up ",e" protocol; for the TCP/IP stuff
there isn't anything than can be set (yeah, I've read all the docs).

With uucp over StarLAN (1BASE5), the average tranfer is 40,000 to 50,000 bytes
per second, end-to-end, disk-to-disk.

With ftp over Ethernet (10BASE2 (ThinNet)), the average transfer is 5,000 to
8,000 bytes/second, end-to-end, disk-to-disk, though I once, just once, had
a peak of 24,000 bytes/second.

The only conclusion I can draw is that the Wollongong WIN/3B Applications
Package, version 1.4, for the UNIXPC/3B1 is seriously flawed.  Some of the
support programs (e.g. telnet, sendmail, etc.) are buggy beyond belief, but
this level of "performance" is so poor I wonder if there's something I might
be missing.

And, yes, I did check whether the SQE (heartbeat) signal is enabled; it's not
(when it WAS enabled for another set of tests, the transfer rates dropped to
about 400 bytes/second, TWO orders of magnitude less than the StarLAN).

I placed a simple Ethernet monitor (POWER, Collision, Transmit, Receive LEDS)
on the AUI cables, and it looks like there's a 1/2 second of activity followed
by several seconds of NO activity ANYPLACE on the net ... this inactivity
would explain the poor overall transfer performance, but the question is "WHY?"
I'm convinced there's nothing wrong with the hardware.

I also ran some tests using the "loopback" mode, again using ftp with the same
file, and there wasn't any appreciable change in performance.

Also, if anyone knows how/where to get the Ethernet software for a Motorola
6300 (similar to the 3B1) for placement in /usr/sys/LAN/* in order to do a
sysgen, I'd appreciate hearing about that, too.  My Motorola 6300 does have
the comm expansion card with the Ethernet D-15 (and the board uses the Lance
chip set, same as does the 3B1).

Thad

Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 May 90 18:29:52 CDT
From:      stanley@visual1.tamu.edu (Stanley Guan)
To:        tcp-ip@nic.ddn.mil
Subject:   stanley@visual1.tamu.edu
Please remove me from this list.
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 14:54:50 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!jackv@ucsd.edu  (Jack F. Vogel)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: "LARP" on Port 91 ?
In article <3315@apogee.oakhill.UUCP> guri@oakhill.UUCP (Gurvinder Singh Ahluwalia) writes:
>
>Has anyone heard of a protocol called LARP? 
 
Well, yes you might say I've heard of it, considering we invented it :-}.
Locus has two officially registered IP protocol's, LARP is, as you noted
number 91, another is number 87 which is an IP packet containing what is
called a net message which is an inter-kernel communication packet. The
former is used to initialize TCF it resolves an address to a TCF site
number. The later lays the foundation for TCF. Since the registration
of these protocols was relatively recent some sniffers will see the
packets but not give you a protocol name.

>For those out there aware of this and also running cisco routers,
>I would like to go a step further to find out compatibility of this
>protocol on ciscos, including access/passage of LARP traffic through 
>cisc.o Is there something that has to be enabled to allow LARP through
>cisco? What is the default?
 
We use Proteon routers here at LCC but I know that Cisco is in use at a
couple of locations running AIX370. I don't believe there is anything
that you need to do to the router, it should pass the packets through
by default, it is just an IP packet.

Disclaimer: I speak for myself, not my employer.

-- 
Jack F. Vogel			jackv@locus.com
AIX370 Technical Support	       - or -
Locus Computing Corp.		jackv@turnkey.TCC.COM
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 17:55:33 GMT
From:      mcsun!unido!zgdvda!zhang@uunet.uu.net  (Ning Zhang)
To:        tcp-ip@nic.ddn.mil
Subject:   help wanted for installing MIT/CMU PC/IP public domain package on NI5210

Sorry for crossposting. Please reply me by email (unido!zgdvda!zhang or
zhang@agd.fhg.de), since I have no access to these newsgroups.

We just received a public domain PC/IP package, which was originally developed
at the Lab of CS at MIT and later enhanced by CMU. I compiled this TCP/IP
package on a Compaq At with MSC 5.0 without any problem. Since the default
configuration did not support Interlan NI5210A ethernet card, I relinked
the whole exe commands with the NI5210A driver library (instead of the
old NI5010 driver library), which was developed by at B. N. Davis at
Darbick Instructional Software Systems in 1988, also without any problem.
Then I had to customize the netdev.sys file to set up correct parameters
about the hardware, internet address, etc., and also turned all debug options
on. The RACAL Interlan ethernet card we have is NI5210A-8-V (REV AA). The
IO address was configured as 0x360, the base memory address was 0xC0000 and
the interrupt vector was at IRQ2 level. I would think I had correctly set
up all parameters. Then I changed my config.sys file for installing
netdev.sys and rebooted the pc. After the machine came up again, I simply
tried the iping command, but it didn't work. It complained that "Error: 
board not responding". This message came from the i_init.c file in the
NI5210 driver directory. I also tried hopelessly by changing the DMA channel
numbers.

I thought I might have done something wrong during the compiling or
configuration.  Here I ask you PC/IP gurus to enlight me about the problem.

Enclosed here is the first few lines of the "i82586.h" about the version I have.

	/* See permission and disclaimer notice in file "bnd-note.h" */
	#include	"bnd-note.h"
	/*  Copyright 1986 by Carnegie Mellon  */
	/*  See permission and disclaimer notice in file "cmu-note.h"  */
	#include	<cmu-note.h>
	/*  Copyright 1984 by the Massachusetts Institute of Technology  */
	/*  See permission and disclaimer notice in file "notice.h"  */
	#include	<notice.h>
	/* This header file includes register descriptions of the Ethernet
	   boards for the IBM PC based on the Intel 82586 chip (hence known as
	   "the ethernet"). */

As we are in a poor institute and cannot afford to buy a expensive package
for network monitoring, we only need two program included in this PD PC/IP
package, i.e. netwatch, monitor. If you know PD stuff else for this purpose,
please also let me know.

Thanks in advance,

Ning Zhang	unido!zgdvda!zhang	zhang@agd.fhg.de
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 19:31:08 GMT
From:      CCBUSTER@VM.CC.OLEMISS.EDU (POSTMASTER)
To:        comp.protocols.tcp-ip
Subject:   AEDAVIS

Please remove AEDAVIS@VM.CC.OLEMISS.EDU or AEDAVIS@UMSVM from this list.  He
is no longer here.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 20:35:14 GMT
From:      shlump.nac.dec.com!delni.dec.com!mcclellan@decuac.dec.com  (Rolf McClellan)
To:        tcp-ip@nic.ddn.mil
Subject:   Announcing biz.dec.ip--a newsgroup on DEC's TCP/IP products

This posting is to announce a USENET newsgroup for the discussion 
of products from Digital Equipment Corporation that support the 
Internet protocol suite (TCP/IP).

The newsgroup will be unmoderated, but will be read regularly by 
employees of Digital, including some of the engineers who develop 
TCP/IP networking products, as well as marketing and field 
support personnel.

The goal of the newsgroup is to provide a forum for the exchange 
of information from user-user, as well as user-Digital, and 
Digital-user.

Digital employees intend to contribute to the newsgroup by 
posting detailed product descriptions and specifications similar 
to Digital's Software Products Descriptions (SPDs), and by trying 
to answer questions about the applicability and use of Digital's 
TCP/IP products.  There is no intention of posting the sort of 
marketing literature that simply extols product virtues in 
general terms. The newsgroup is also not intended as an 
alternative to normal channels for product support. However, 
every attempt will be made to respond in some way to postings 
that are addressed to Digital.

Because of the unavoidable commercial nature of product 
descriptions and application notes, it was felt that the 
newsgroup should be established as biz.dec.ip. In spite of this, 
it is hoped that the nature of the newsgroup will be very similar 
to user-sponsored newsgroups.





Rolf McClellan         mcclellan@delni.enet.dec.com
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 May 90 21:03:26 GMT
From:      amdcad!pepsi!ohara@ucbvax.Berkeley.EDU  (Bob O'Hara)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes:

   [stuff from Kent's earlier post deleted.]

>
>Actually, I think it may really be more like 3 million, depending on the 
>size of the ring.  Since FDDI allows a device to release the token after 
>finishing its transmission (rather than after it receives the message it 
>sent), it's possible to have multiple packets on the ring, particularly if 
>they're small packets.  Does anyone feel like calculating how many packets 
>can be carried per second by FDDI as a function of the number of nodes and 
>length of fiber?  I don't know enough about the delay introduced by each 
>node to do it.
>
>                               David Walker
>                               Network Services Manager
>                               UC Irvine
>                                 DHWalker@uci.edu

David,
   Kent was pretty close.  You have probably seen my response to him just
prior to this posting.  You are correct that there may be many frames on the
ring simultaneously, but any one node will only see the one passing
immediately in front of it.  Therfore, a node needs to support only 100 Mbps
into and out of the ring.  Only if a node has multiple connections to the
ring (i.e. a dual MAC, dual attachment station) would it need anything beyond
100 Mbps.  The FDDI standard does specify a maximum latency for each node and
a delay figure for the fiber, so it is possible to calculate (approximately,
since bits in the preamble can be eaten and created as a frame goes round the
ring) how many bits and from that how many frames are on a ring.  I think the
equation would look like this:

 n = number of stations, l = length of fiber in meters.

  # of data bits on the ring = ((n * 756ns) + (l * 5ns/m)) / 10ns per bit

These numbers are taken from ANSI X3.148-1988, the Physical protocol sublayer
standard.  Divide the number of bits by your favorite average frame length
and you will have your answer.

 -Bob

Bob O'Hara                          Net:   ohara@pepsi.amd.com
Advanced Micro Devices, Inc.        Phone: +408-749-2321
P.O. Box 3453  MS 70                Fax:   +408-749-2825
Sunnyvale, Ca. 94088-3000
Disclaimer: Everyone needs a disclaimer and I disclaim this one.
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 03:10:50 GMT
From:      hercules!dirt.cisco.com!kph@apple.com  (Kevin Paul Herbert)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: CLNS and routing (IS-IS) and ES-IS
At cisco, we just released support for CLNS routing based on a
proprietary protocol, ISO IGRP. We support ES-IS, so we'll autoconfigure
and do dynamic routing based on addresses learned from end systems,
although our routing won't interroperate in the same CLNS area with
routers using IS-IS (although, to our knowledge, there are no IS-IS
routers today).

If you want to learn more about the features and capabilities of ISO
IGRP, we can move this discussion to comp.dcom.sys.cisco.

Kevin
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 04:49:32 GMT
From:      news-server.csri.toronto.edu!torsqnt!hybrid!robohack!woods@rutgers.edu  (Greg A. Woods)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
> {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW}
> {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip}
> 
> If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
> happy with the performance?
>
> The only conclusion I can draw is that the Wollongong WIN/3B Applications
> Package, version 1.4, for the UNIXPC/3B1 is seriously flawed.  Some of the
> support programs (e.g. telnet, sendmail, etc.) are buggy beyond belief, but
> this level of "performance" is so poor I wonder if there's something I might
> be missing.

Please don't infer too much from my posting, BUT....  Everything I've
ever heard about Wollongong WIN/TCP products leaves a lot to be
desired.  Certainly they are over-priced ($7,500 for binaries, $35,000
for sources for a 3b2 at announcement).  A colleague who has seen the
sources of early versions says they are a very sorry sight.

I'm not entirely surprised to hear that the WIN/3B1 version suffers
from poor performance, especially given that it was never marketed to
any degree.  I'm not too surprised to hear of any nasty bugs either,
and I would consider the several second pauses between activity to be
a bug too!.  You might consider porting much of the BSD4.3 code....
-- 
						Greg A. Woods

woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h]   +1 416 595-5425 [w]   VE3-TCP   Toronto, Ontario; CANADA
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 07:58:00 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov  (Oberman, Kevin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: CLNS and routing (IS-IS) and ES-IS
In article <12590478782.15.AFDDN.BEACH@GUNTER-ADAM.AF.MIL>, AFDDN.BEACH@GUNTER-ADAM.AF.MIL writes...
>Can anybody tell me where to get any info at all on proposed routing 
>protocols and implementations of them for the GOSIP world.  I assume
>OSPF will be used.  What I'd really like is pointers to discussions
>of how the routing would operate and clues on what implementations
>might look like.  I'd also like any comments on resource utilization.
>I think the ISO address formats look a lot harder to deal with than IP.
> 
>Please send responses directly to me so as not to clutter up this list...
>AND if there's another list I should be talking to, feel free to flame
>as long as you tell me the list's address.
> 
>Going from TCP/IP is like teaching a sho'nuff southern boy to talk with
>a french accent.  It ain't easy!

The IS-IS standard is currently in DP (Draft Proposal) status. It is DP 10589.
I'm posting to the list because I suspect lots of people are not familiar with
the status of this (unless they read the OSI group).

The full title of the beast is "Intermediate system to Intermediate system
Intra-Domaon routeing exchange protocol for use in Conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO 8473)". The
spelling and caps ARE exact to the best of my proof reading.

The proposal is similar to OSPF in concept, but very different in detail. It is
far from certain that IETF will recommend OSPF as the Internet standard, but it
looks to be the front-runner.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri 18 May 90 16:40:04-PDT
From:      VANCE@TGV.COM (L. Stuart Vance)
To:        tcp-ip@nic.ddn.mil
Subject:   Interesting uses of networking
I'm putting together a talk on interesting uses of networking, and am looking
for good stories/applications that people have run across.  I'm very familiar
with two:

o TCP (Mr. Romkey's Toaster Control Protocol)
o An SNMP controlled CD player

If anyone has any information on other uses (in particular, I'd like to find
people with information on the coke machine wired up to a DEC-20[?] at MIT[?]
and/or the geographic coordinates server at [I believe] MERIT), I'd be most
interested in talking you.

Many thanks,
----Stuart
-------
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 12:20:25 GMT
From:      pandora!scj@bellcore.com  (Steve Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
>In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>> {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW}
>> {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip}
>> 
>> If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
>> happy with the performance?

...

>I'm not entirely surprised to hear that the WIN/3B1 version suffers
>from poor performance, especially given that it was never marketed to
>any degree.  I'm not too surprised to hear of any nasty bugs either,
>and I would consider the several second pauses between activity to be
>a bug too!.  You might consider porting much of the BSD4.3 code....
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Two points:

1.  If anyone begins the port of BSD code, I suggest using Alex Crain's
    UnixPC socket implementation *OR* spending the time to re-write the
    BSD code using TLI as provided with the WIN/3B package.  Having used
    (both UnixPC and 3B2) WIN/3B, my personal opinion is that the concept
    of socket emulation is 90% of the reason WIN/3B is a poor performer.
    (most socket calls are actually TLI calls wrapped with a function that
    is supposed to behave like a socket call).  In the case of the UnixPC,
    I hope to be proven wrong but it looks like TLI may done using *sockets*
    at the kernel level!  (If true, this means socket "calls" invoking TLI
    "calls" invoking socket calls -- blecch!)

    (Anyone with decent Motorola 68k assembler and device driver experience
     want to take a look at a disassembled socket.o? :-) I'm having trouble
     making sense of the assembler code).

2.  Although well known in sun (workstation) circles, the fact that rwhod and
    routed are BIG cpu hogs seems lost on Wollongong - NO mention of the
    potentially anti-social behavior of these bad boys in the manual!  The
    Moral?  Don't run these guys unless you need them, our UnixPC's are
    already anaemic by today's standards.

BTW, NFS for the UnixPC (WIN/3B or ??) is in my queue (right after I finish
my gas project 8-(  ).
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 12:52:21 GMT
From:      pmf@mimsy.umd.edu  (Paul M. Franceus)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes:
>sent), it's possible to have multiple packets on the ring, particularly if 
>they're small packets.  Does anyone feel like calculating how many packets 
>can be carried per second by FDDI as a function of the number of nodes and 
>length of fiber?  I don't know enough about the delay introduced by each 
>
...
>                               David Walker

     I don't believe that the maximum frame rate depends on the latency of the 
ring.  The FDDI still only transmits at 100Mb/sec (125 Mb/sec if you are 
being technical.)  The latency in the ring may decrease the maximum number 
of usable frames per second, and there may be many frames in transit at 
any time.
     If you ignore IP and TCP overhead (don't forget the 802.2 and
SNAP headers) the FDDI can go much faster than 14,000 pps.  The maximum 
frame rate is really something around 480,000( given the 17 Byte min frame and
the preamble). 

Paul Franceus
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 12:59:57 GMT
From:      pmf@mimsy.umd.edu  (Paul M. Franceus)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY

      While Gateway filtering is not a cure-all,  Host based security is
not a cure all either.  In any security architecture it is important that
each piece of the system do its part.  Any individual "secure" component
of a system will not give "total" security.  Security will not be achieved
unless you have mapped out a security architecture where each part of the
system does its piece.  It is important also, for functions to overlap 
somewhat to provide a layered security approach.

Filtering gateways can be an important part of such a security architecture.

Paul Franceus
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 May 90 17:35:51 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        Campus-Size LAN Discussion Group <BIG-LAN@SUVM>, Don Lewis <LEWIS@UMSLVMA>
Cc:        "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Dial up access to Internet facilities
>  We are in the process of evaluating terminal severvs that provide
>TCP/IP support for dialup users.  We are currently having a philosphical
>discussion on what users should have acces to once dialed in.  We,
>University of Missouri - St. Louis, are part of a TCP/IP network that is
>associatied with MIDnet.  I have no problems allowing users access to
>our local TCP/IP host plus the other hosts in the U. of Mo. network.
>Should dialup users have access to the Internet?  There is something
>about allowing this type of access that doesn't sound right to me.
>Should this be a concern?  How are other institutions handling this
>type of access?

Yes, this should be a concern.  As I understand it, NSFnet policy is
that unlimited access is not permitted.  You would have to check to see
if MIDnet has its own policy.

What this policy seems to translate to in practice is that you should
only permit "known" users to have access outside of your local net (and
perhaps your regional net, if it is within their guidelines).  This
generally means that terminal servers should be restricted to local use,
requiring dial-up users to access a workstation or larger system and
identify themselves (as something other than "guest", hopefully!) in
order to have unlimited Internet access.

Here at MSU, we are part of two regional networks - Merit and CICnet.
Our dial-up lines have unlimited access to any hosts at MSU or within
the Merit Network, but not CICnet or beyond.  This is true of all the
dial-up lines within the Merit Network and its member institutions
as well.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 14:48:20 GMT
From:      haven!umbc3!umbc5.umbc.edu!alex@ames.arc.nasa.gov  (Alex S. Crain)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:

>I'm not entirely surprised to hear that the WIN/3B1 version suffers
>from poor performance, especially given that it was never marketed to
>any degree.  I'm not too surprised to hear of any nasty bugs either,
>and I would consider the several second pauses between activity to be
>a bug too!.  You might consider porting much of the BSD4.3 code....
>-- 
>						Greg A. Woods

	Just a passing note, the uipc driver thats going around is
directly derived from BSD, all you need to do is add the driver for
the ethernet card and the af_inet code, available from uunet. I
haven't looked at the code in awhile, but I did finish most of the top
level, and a few things were added later. I had always planned to add
a slip interface, but it never got finished because of hardware
problems on my end (I may find some time for it this summer, in
between rebuilding my Harley, rehabbing my house, getting married, etc
... ).

t#################################		           :alex.
#Disclamer: Anyone who agrees   #                 Systems Programmer
#with me deserves what they get.#    University of Maryland Baltimore County
#################################	    alex@umbc3.umbc.edu
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 15:33:21 GMT
From:      swrinde!emory!km@ucsd.edu  (Ken Mandelberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <23377@bellcore.bellcore.com> scj@pandora.UUCP (Steve Johnson) writes:
>In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
>>In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>
>2.  Although well known in sun (workstation) circles, the fact that rwhod and
>    routed are BIG cpu hogs seems lost on Wollongong - NO mention of the
>    potentially anti-social behavior of these bad boys in the manual!  The
>    Moral?  Don't run these guys unless you need them, our UnixPC's are
>    already anaemic by today's standards.
>


The problem with rwhod on Suns is not really that it is a CPU hog, but
relates to diskless workstations. On a Sun network with well
synchronized clocks all the diskless workstations send out a broadcast
packet at almost the same moment once a minute, with their own load
info. Each one receives all its fellows  packets and tries to write the
updated info to the /usr/spool/rwho directory, each to a separte file.
These files are all NFS so each takes several additional packets for
the write. The broadcasts don't really hurt much, its the NFS writes.
If you have N machines there are N^2 NFS writes per minute, all at
about the same moment. This causes many collisions and retries.

On our diskless Suns we patched rwho to do the broadcasts but not
update its own /usr/spool/rwho. Only the server updates this directory,
and it is mounted on all the clients.  This cuts out the NFS packets
entirely, there  are just N broadcast packets a minute.

For the 3B1, there is nothing to do since /usr/spool/rwho is already
local.

With this in place, with in execess of 50 rwhod machines on our net,
rwhod consumes on the order of 10 seconds an hour. If all you have is
diskfull machines (like 3B1s) that would be what you should expect with
no patches.  In fact I got the 10 second estimate from "ps" on one of
our 3B1s. Even if you have unpatched diskless Suns and 3B1s, the 3B1s
would not see high cpu usage on rwhod, just the Suns. However, everyone
would suffer the network congestion for the NFS writes.

If N gets very large (say 1000), and the clocks are very well
synchronized (say with timed), the broadcasts and collisions alone
would kill you (even with the patch). The very large /usr/spool/rwho
directory on the server would also degrade performance on the
server and thrash the inode cache. Rwhod clearly doesn't scale well,
but is really not much of a problem (with the patch) on relatively
small nets.
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 17:45:13 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!dan@ucsd.edu  (Dan Schlitt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
In article <57064@bu.edu.bu.edu> kwe@bu-it.bu.edu (Kent England) writes:
:In article <1990May10.150744.12108@phri.nyu.edu>,
:roy@alanine.phri.nyu.edu (Roy Smith) writes:
:> 
:> 	At the recent PSI Internetworking Tutorial, I asked two people who
:> should have known the answer, "Exactly what *is* the Internet Activities
:> Board?" and in both cases all I got were some random moderately derogatory
:> comments but no real answer (which I found somewhat annoying, BTW).
:> 
:> 	So, can anybody on this list answer my question?
:> --
:
:	Some wires must have gotten crossed.  It would be very strange indeed
:for anyone in PSI to take this view, since several of the principals at PSI
:have been involved in TCP/IP standards, including SNMP and "ISO-on-TCP", and
:that work would be exactly nowhere without the IAB.  Strange, indeed.
:
I have my doubts about Roy's interpretation too.  However one should
also note the anonymous critique of the governance of the Internet
that was published in Goodfellow's newsletter.  Participation in the
IAB and the IETF can't be read as 100% support.
-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan@sci.ccny.cuny.edu              City College of New York
dan@ccnysci.uucp                   New York, NY 10031
dan@ccnysci.bitnet                 (212)690-6868
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 19:23:13 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!bbn.com!mmcintos@tut.cis.ohio-state.edu  (Martin M. McIntosh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
The maximum throughput of a FDDI ring *does* depend on the propagation
delay, as many people have pointed out. More accurate, the throughput
depends on the delay between adjacent stations, since no traffic can
enter the ring as the token is passed. The TTRT will also have some
effect on the throughput, since this will determine the rate that the
token must be passed.

If you assume that each station will send for the entire TTRT, the
next station cannot send until

one-ring-rotation + time-to-next-station

after the TTRT expires. If the stations can only send one frame (each
monkey types slowly) per token, the time between frames will be

time-to-next-station

until the TTRT expires and then the time will be equal to the above.If
you want a lower bound on PPS, pick a ring with

- TRT set to expire just before the last bit of the frame is transmited
- maximim ring size 
- only two stations (one terminal with monkey and one server not sending)

This will get one frame per *two* rotations of the ring.

The maximum throughput will be a small ring with large TTRT and lots
and lots of stations all sending frames until the TTRT expires.

I would recommend reading "Analysis and Tuning of the FDDI Media
Access Protocol", D. Dykeman and W. Bux, IEEE Journal on Selected Areas
in Communications, July 1988. This provides very good analytic
solutions to throughput on FDDI. At least it was confirmed by some
simulation work that I have done.

[much of this information was included in a past posting by myself. I
am sorry for any duplication]

Martin McIntosh
Bolt Beranek and Newman
Network Analysis
mmintosh@BBN.COM
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 19:55:43 GMT
From:      zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!david@tut.cis.ohio-state.edu  (David H. Wolfskill)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM MVS[/XA or /ESA] TCP/IP Implementations
I am seeking information about implementations of the TCP/IP protocol
suite for use in an MVS/XA (or MVS/ESA) environment on an IBM 3090.
(This is for my employer, who shall remain mercifully nameless.  :-)

I have heard reports that there may be implementations other than the
IBM one that may be worth examining; I would appreciate knowing:

* Who the vendors are
* What experiences folks have had with the products (and the vendors)

(Naturally, I am also interested in folk's experiences with the IBM
product, although I already am aware of its existence....)

I much prefer mail; I will certainly post a summary if more than a
couple of folks request it -- probably around the middle of June (unless
I get inundated by responses well before then).  If you can't reach me
any other way, my (work) telephone number is (714) 385-4055.

Thank you,
david
-- 
David H. Wolfskill
uucp: ...{spsd,zardoz,felix}!dhw68k!david	InterNet: david@dhw68k.cts.com
CompuServe: >internet:david@dhw68k.cts.com
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 May 90 20:06:09 GMT
From:      "Douglas P. Ambort" <douglas@TWG.COM>
To:        tcp-ip@nic.ddn.mil
Cc:        fernwood!portal!cup.portal.com!thad@uunet.uu.net
Subject:   Re. Wollongong TCP/IP
Ouch!  Mr. Floryan's  indictment of AT&T's implementation of a very old 
outdated version of Wollongong TCP/IP, ported a long time ago by AT&T 
to its 3B1's is harsh.  Given the 3B1, his indictment may not be  
altogether off base; but it could be misconstrued by netnews readers as 
a general indictment of all Wollongong TCP/IP (past, present, future, 
and on good, bad or indifferent platforms).  And such an indictment 
would not only be unfair, but misinformed.

Wollongong continues to upgrade its TCP/IP with _significant_ enhancements.   
And AT&T continues to select Wollonong as its TCP/IP vendor of choice, 
for current and future platforms.  Why? Because of our TCP/IP's performance 
and  features, our commitment to continued enhancement, and because of 
the solid OEM support we provide.

In this case of the (the 3B1 shortcomings described by Mr. Floryan), 
AT&T has simply chosen not to upgrade an ancient TCP/IP 
on a platform that has been retired. Perhaps AT&T is concentrating on 
new platforms?  
If you want to see the best TCP/IP in its class, check out the TCP/IP 
on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines.
It's Wollongong's.  And we're proud of it.

On the other hand, if someone must rail against an old TCP/IP 
implementation on (let's face it) 'old iron', go ahead.
You could just as easily criticise the skinny tires on a Model T
for not being steel belted radials.
Time passes. Technology progresses.  And so has Wollongong's TCP/IP!

.--------------------------------------------------------------------.
| Douglas Ambort                          The Wollongong Group, Inc. |
| Product Manager                              1129 San Antonio Road |
| INTERNET: douglas@twg.com                      Palo Alto, CA 94303 |
| 						      (415) 962-7248 |
| 					         FAX: (415) 969-5547 |
`--------------------------------------------------------------------'




-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      18 May 90 21:35:51 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up access to Internet facilities

>  We are in the process of evaluating terminal severvs that provide
>TCP/IP support for dialup users.  We are currently having a philosphical
>discussion on what users should have acces to once dialed in.  We,
>University of Missouri - St. Louis, are part of a TCP/IP network that is
>associatied with MIDnet.  I have no problems allowing users access to
>our local TCP/IP host plus the other hosts in the U. of Mo. network.
>Should dialup users have access to the Internet?  There is something
>about allowing this type of access that doesn't sound right to me.
>Should this be a concern?  How are other institutions handling this
>type of access?

Yes, this should be a concern.  As I understand it, NSFnet policy is
that unlimited access is not permitted.  You would have to check to see
if MIDnet has its own policy.

What this policy seems to translate to in practice is that you should
only permit "known" users to have access outside of your local net (and
perhaps your regional net, if it is within their guidelines).  This
generally means that terminal servers should be restricted to local use,
requiring dial-up users to access a workstation or larger system and
identify themselves (as something other than "guest", hopefully!) in
order to have unlimited Internet access.

Here at MSU, we are part of two regional networks - Merit and CICnet.
Our dial-up lines have unlimited access to any hosts at MSU or within
the Merit Network, but not CICnet or beyond.  This is true of all the
dial-up lines within the Merit Network and its member institutions
as well.

Doug Nelson
Network Software Manager
Michigan State University

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      19 May 90 00:08:04 GMT
From:      usc!orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu  (David Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
In article <24484@mimsy.umd.edu> pmf@mimsy.umd.edu (Paul M. Franceus) 
writes:
>      I don't believe that the maximum frame rate depends on the latency 
of the 
> ring.  The FDDI still only transmits at 100Mb/sec (125 Mb/sec if you are 
> being technical.)  The latency in the ring may decrease the maximum 
number 
> of usable frames per second, and there may be many frames in transit at 
> any time.
>      If you ignore IP and TCP overhead (don't forget the 802.2 and
> SNAP headers) the FDDI can go much faster than 14,000 pps.  The maximum 
> frame rate is really something around 480,000( given the 17 Byte min 
frame and
> the preamble). 
> 
> Paul Franceus

Thanks, Paul.  I can see that I misunderstood Kent's original question.  
What I'm interested in is what *aggregate* packet rate can be carried by 
FDDI for *multiple* sources (i.e., the monkeys are not all at one node), 
so your 480K is what I was looking for.  Of course, none of us would ever 
expect to actually achieve that rate any more than we'd expect to achieve 
14,000 pps on an Ethernet.  

All of the other discussion of the maximum rate that's available to a 
*single* node is sure interesting, though; I had no idea that FDDI was so 
(mis)tunable.

                               David Walker
                               Network Services Manager
                               UC Irvine
                                 DHWalker@uci.edu
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      19 May 90 05:39:20 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   Quote without comment



Advertisement in the October 7, 1989 issue of the British magazine
"New Scientist", page 15:

"The International Organization for Standardization (ISO) is seeking, for its
new project based on OSI LAN with distributed environment including servers
and VM and VMS hosts (PC or PS/2 user terminals), an experienced

        NETWORK SYSTEMS SPECIALIST
	
familiar with the hardware/software aspects of LAN, network management and
operating systems, terminal emulation and host coupling, OSI protocols
INCLUDING TCP/IP [my emphasis - Phil], X.400 and X.25, to be responsible
for overall implementation of the network system. Please apply with cv to
ISO Personnel Services, Case postale 56, CH-1211 Geneva 20, Switzerland."
	
	--Phil
	

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 May 90 15:10:24 GMT
From:      vmp!sonyd1!blilly!bruce@uunet.uu.net  (Bruce Lilly)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <23377@bellcore.bellcore.com> scj@pandora.UUCP (Steve Johnson) writes:
 [ several lines from other postings deleted ]
>Two points:
>
>1.  If anyone begins the port of BSD code, I suggest using Alex Crain's
>    UnixPC socket implementation *OR* spending the time to re-write the
>    BSD code using TLI as provided with the WIN/3B package.  Having used
>    (both UnixPC and 3B2) WIN/3B, my personal opinion is that the concept
>    of socket emulation is 90% of the reason WIN/3B is a poor performer.
>    (most socket calls are actually TLI calls wrapped with a function that
>    is supposed to behave like a socket call).  In the case of the UnixPC,
>    I hope to be proven wrong but it looks like TLI may done using *sockets*
>    at the kernel level!  (If true, this means socket "calls" invoking TLI
>    "calls" invoking socket calls -- blecch!)
>
Forget it. The Wollongong ``emulation'' of TLI is extremely buggy -- it does
not comply with any of the standards (SVID, POSIX, X/OPEN). It is so
brain-damaged that I have found it impossible to write even a trivial program
with it. The biggest problem is that asynchronous events are returned as a
bit map, rather than one-at-a-time events in a queue. As a result, it is
possible (even very likely) for a function to fail due to an asynchronous
event, with no way to recover because of other ``events'' in the bit map.

[ more lines deleted ]
>2.  Although well known in sun (workstation) circles, the fact that rwhod and
>    routed are BIG cpu hogs seems lost on Wollongong - NO mention of the
>    potentially anti-social behavior of these bad boys in the manual!  The
>    Moral?  Don't run these guys unless you need them, our UnixPC's are
>    already anaemic by today's standards.
>
Routed from Wollongong doesn't even work AT ALL. It dies after not finding
a non-existent symbol in the kernel's nlist.

>BTW, NFS for the UnixPC (WIN/3B or ??) is in my queue (right after I finish
>my gas project 8-(  ).


-- 
	Bruce Lilly		uunet!vmp!sonyd1!blilly!bruce
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Saturday, 19 May 1990 23:54:28 EDT
From:      Gene.Hastings@boole.ece.cmu.edu
To:        emv@math.lsa.umich.edu (Edward Vielmetti)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: archives of ietf "network joint management" list ?

I am the chair of tha Network Joint Management working group of the IETF. 

There is no formal archive of the mailing list <njm@merit.edu>, but there
are public agendae and reports from meetings, and specific documents online
in multiple places. Is there specific information you're seeking?

Gene Hastings
Pittsburgh Supercomputing Center
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 May 90 22:21:49 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!barsoom!tih@ucsd.edu  (Tom Ivar Helbekkmo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
douglas@TWG.COM ("Douglas P. Ambort") writes (among other things):
>Time passes. Technology progresses.  And so has Wollongong's TCP/IP!

Yeah, you're right about that.  We used to call it "Willgowrong" here,
but after receiving our last upgrade (to version 5.1 for VAX/VMS),
we've had to reevaluate.  It's a darn good package, and well
documented.  Congratulations!

-tih
-- 
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      20 May 90 00:39:32 GMT
From:      zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@tut.cis.ohio-state.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   archives of ietf "network joint management" list ?
hi.  I'm trying to find the site which archives the IETF
"network joint management" mailing list.  So far no luck.
Can someone help?

thanks.

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu
moderator, comp.archives
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 May 90 08:48:37 -0700
From:      Stan Stead <stan@anes.ucla.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Dealing with systems without nameservice.
Greetings:
	We are running 4.3 BSD.  We currently use nameservice.  However,
a site that we wish to exchange mail and files, while connected to the 
internet, does not use nameservice.  We can access the site by internet
number, but not by name.  Is there anyway to "hot-wire" an address 
(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
is if named is not running.  Please reply to my email address directly.
Thank you.
	Stan
Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL:	(213) 206-6238
ARPA:	stan@anes.ucla.edu
BITNET:	stan@anes.UCLA.EDU
UUCP:	{randvax | ucla-cs}\
			    !ucla-an!stan
UUCP:	{att|decvax}!hermix/
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 May 90 22:36:30 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <1173@tnosoes.UUCP> tom@tnosoes.UUCP (Tom Vijlbrief) writes:
>[...] but how can you be sure that a local network
>with dozens of Unix boxes with different administrators are
>correctly installing their machines ? (E.g. not export NFS-filesystems
>to the world as is the default).
>How can you be sure that hunderds of users have non trivial passwords, etc.

One way is to build and use "sweep" programs that regularly test each
machine on your local network for a list of specific security holes.  For
maximum effectiveness, you should not rely solely on your domain database or
host tables for a list of machines to sweep; you should also look for
unregistered "squatters" by monitoring ARP packets, probing your entire IP
address space, etc.

According to my conversations with the folks at CERT, all of the break-ins
to computers on the Internet over the past year have exploited holes that
have been well known for some time. I've found it fairly easy to construct
programs that automatically test large numbers of machines for these known
holes. The hard problem, as it turns out, lies not in generating a list of
vulnerable systems, but in getting the administrators of those machines to
update their software or to fix their system configurations.  Gateway
filtering is useful as a TEMPORARY protective measure while this process
continues, but it does NOT lessen in any way the need to fix the vulnerable
hosts.

In my opinion, host security is both necessary and sufficient to prevent
break-ins.

Phil
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 01:22:55 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
>Yes, this should be a concern.  As I understand it, NSFnet policy is
>that unlimited access is not permitted.

We have been unable to find any definite statement of policy in this
area.  However a number of system managers have gotten tired of
responding to complaints about intrusions from their terminal servers,
and have instituted restrictions.  I have a feeling that over the
course of the next year or so even without a definite policy, the
number of unrestricted terminal servers is going to fall off to nearly
zero.  Another policy issue is preventing people from telnetting in
and then out in an attempt to obscure their identity by going through
many sites.  I believe there is a growing concensus that this should
be stopped in some way.

If anyone knows of more definite policies in this area I'd like to
hear about them.
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 May 90 08:33:03 EDT
From:      hal@gateway.mitre.org (Hal Feinstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Wither Ethernet?

It has been suggested by some standards gurus that in the future
all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead
(or possibly dying)  protocol.  That a couple of vendors (like Sun or CISCO)
supporting "dual stacks" (that is both protocols)  are simply 
startling  a changing marketplace. There really will not be two different
standards.  Now I've found strong avocates who disagree and say that 
ethernet will be around and, others who say that current ethernet users
will stay with ethernet (because they already have it installed) but
*future* installations will use ISO/IEEE802.  I have not seen any rush to 
man ethernets lifeboats at the trade shows so I wonder if
what the standards gurus are saying is true?  Have you faced this
questions also? If you have I'd appreciate hearing from you.

                                        Hal
 


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Mon 21 May 90 14:43:11-PDT
From:      William Chops Westfield <BILLW@MATHOM.CISCO.COM>
To:        mmorse@note.nsf.gov
Cc:        tcp-ip@NSF.GOV
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
cisco routers have supported very general packet access list mechanisms
for some time.  I believe that the ciscos can do everything the modified
KA9Q can do, as well as other things (although in a rather more complex
manner).  Similar access list mechanisms are supported for otehr protocols.

Bill Westfield
cisco Systems.
-------
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 May 90 13:49:48 EDT
From:      Michael Morse <mmorse@note.nsf.gov>
To:        tcp-ip@NSF.GOV
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
Are any commercial router vendors considering implementing this kind
of security?

--Mike
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 May 90 21:35:36 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        tcp-ip@nic.ddn.mil
Subject:   ATT and TWG Products

My group is responsible for the installation and distribution of a number of
different software products on a number of different platforms.  I appreciate
the alerts of problems with an application in a given software environment on
a given hardware system.

I don't appreciate, generalized, bashing of a specific product or vendor
without stating the equivalent of name, rank, and serial number.  It strikes
me as being counter-productive to the goals that one wants to achieve--namely,
a solution to a specific problem,

If you have a plaint concerning a product, please be specific about the part,
model, or other identification of the product,  Also be clear about the en-
vironment in which you are using the product.

Now that I've aired my beef, please continue with reporting of problems.
This allows me to approach the vendor to verify that the problem has been
resolved or to suggest to my customers other products that do not exhibit
the problems.

Merton

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 11:00:30 GMT
From:      vsi1!teda!ditka!kls@apple.com  (Karl Swartz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU
>happy with the performance?

Well, at present there's just ditka, without even a transceiver cable
connected to the back.  The other machine expected to be on my Bedroom
Area Network (BAN) doesn't have a board yet.

And I'm still unhappy with the network performance of with LOSE/3B (er,
WIN/3B) package.  Shortly after installing the stuff I noticed that my
UUCP connections were taking dramatically longer.  Looking at xferstats
the reason became apparent -- while outgoing TrailBlazer traffic was
going at full speed, incoming traffic had dropped from 1100 BPS down to
around 200 - 300 BPS, with one large news batch turning in an astoundingly
bad 84 BPS.

Further investigation revealed that incoming characters were dropping
like crazy.  Hmmmm ... all the HFC control signals were still there and
seemed to be doing the right things.  Besides, with g-protocol and the
stock 3 windows, it shouldn't matter.  The only way to lose in this
case would be the device driver simply not responding in time.  Yet the
characters dropped even when nothing else was happening on the machine,
not even any activity shown by Metermaid.

Thinking about recent changes, I disabled the WIN/3B stuff, and low and
behold, uucp ran at full speed again.  Still no observable change in
the Metermaid.

I turned WIN/3B back on, and bits started spewing all over the floor
again.  As a further experiment, I disabled all the TCP/IP daemons
(fingerd, ftpd, rlogind, rshd, and telnetd) but left the driver and
other stuff running.  That returned uucp to normal.

So, running one or more of these daemons somehow screws up incoming
uucp ports.  I haven't tried to figure which one or ones is at fault.

For reference, ditka is a 3B1 with 3.5 MB and two disks using the
ICUS upgrade, running the 3.51dG1 kernel, which is almost 3.51m.  I
normally run the TrailBlazer Plus (4.0 ROMs) on tty000 but also gave
it a try on the combo board's tty002 with similar results.

>With uucp over StarLAN (1BASE5) ...

Too bad their uucp doesn't run over TCP connections as it will with
Starlan.  And it's not just a documentation issue -- I ran strings
on uucico and there's nothing in there that would suggest TCP support.
:-(  (This is HoneyDanBer; I could care less about broken uucp.)

-- 
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 11:12:31 GMT
From:      vsi1!teda!ditka!kls@apple.com  (Karl Swartz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <3333@umbc3.UMBC.EDU> alex@umbc5.umbc.edu.UUCP (Alex S. Crain) writes:
>Just a passing note, the uipc driver thats going around is
>directly derived from BSD, all you need to do is add the driver for
>the ethernet card and the af_inet code, available from uunet.

Well, I've grabbed some of the higher level BSD code and started
looking at the effort required to port it.  Things like inetd, ping,
and BIND for starters.  And the BSD lpr package as I hate, despise,
loath, and am otherwise disgusted by the System V lp rubbish.

Alas, I've never done device drivers ... surely somebody must be able
and willing to fill in this missing piece?!  I'll happily do as much
higher level stuff as I can.

>I had always planned to add a slip interface ...

SLIP was high on my list of wants.  Ethernet has diminished my desire
for it but I'd still like to have it.  How 'bout it, folks?  Seems we
have several nice pieces here needing some attention.  Here's your
big chance to save the world!  :-)

>in between rebuilding my Harley, rehabbing my house, getting married, etc

Minor problems, Alex.  Get on with the important things!  :-)

-- 
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 12:55:41 GMT
From:      taber@pstjtt.enet.dec.com
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   Re: Quote without comment


In article <23433@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes...
>        NETWORK SYSTEMS SPECIALIST
>	
>familiar with the hardware/software aspects of LAN, network management and
>operating systems, terminal emulation and host coupling, OSI protocols
>INCLUDING TCP/IP [my emphasis - Phil], ...

Yeah, so?  OSI's TP4 is almost exactly TCP/IP -- that's no secret.  


		                >>>==>PStJTT
			Patrick St. Joseph Teahan Taber

Mail address:  Nahhhhh, you don't want to send me mail....

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 17:39:02 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
>If you want to see the best TCP/IP in its class, check out the TCP/IP 
>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines.
>It's Wollongong's.  And we're proud of it.

So AT&T threw out the Lachman-based one they supply standard with S5R4
and supply a Woolongong-based release instead?
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 20:30:56 GMT
From:      sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!fiuggi!fiuggi!dds@ucsd.edu  (Dennis D. Sherod)
To:        tcp-ip@nic.ddn.mil
Subject:   RFI -- TCP/IP in Fortran
Please don't make me explain why I need this info ;-}

I would like to know if anyone has ever done a TCP/IP implementation
in Fortran (flavor not important).  I need some of the utilities (ftp,
telnet, r*, smtp) as well as the kernel pieces.

Again, please don't ask.
--
Dennis Sherod, Data General Corporation   UUCP: ..!uunet!spsd!d_sherod
2603 Main St., Ste. 360, Irvine, CA 92714 ARPA: d_sherod@irvine.dg.com
FAX: +1 714 250 6061                      VOICE: +1 714 250 6005 x4233
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 May 90 08:30:50 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        menges@menges.UUCP
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP Application Query
Check out RFC1147.  In addition there are now unlicensed SNMP
implementations: MIT, CMU, and ISODE.  Please direct further questions
to the SNMP list (send a note to snmp-request@nisc.nyser.net to
subscribe).

/mtr
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      21 May 90 23:48:34 GMT
From:      ekrell@ulysses.att.com (Eduardo Krell)
To:        comp.protocols.tcp-ip
Subject:   Re: Re. Wollongong TCP/IP

In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:

>So AT&T threw out the Lachman-based one they supply standard with S5R4
>and supply a Woolongong-based release instead?

Not so, a quick scan at the header files shows that they all contain:

 * System V STREAMS TCP was jointly developed by Lachman Associates and
 * Convergent Technologies.

    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 00:01:52 GMT
From:      cs.umn.edu!wsmith@ub.d.umn.edu  (Warren Smith [Randy])
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <23444@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
> ....
>In my opinion, host security is both necessary and sufficient to prevent
>break-ins.
>
>Phil

I'll agree with necessary, but I'm not so sure about sufficient.  Just
because most break-ins so far have used known bugs doesn't mean they
always will.  The suspicious secure gateway seems to add an extra layer
of security that can complement host security.  Then of course, there
is always the question of who the "known" bugs are known to.

-Randy
-- 
Randy Smith
wsmith@umn-cs.cs.umn.edu
...!rutgers!umn-cs!wsmith
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 00:16:42 GMT
From:      andante!cbnewsm!cbnewsd!cage@EDDIE.MIT.EDU  (charles.gerlach)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
Enough is enough.

The 3B1 WIN release you are complaining about is over 4 years old.  To
the best of my knowledge, there has never been another release for the
3B1.  (To say the 3B1 is "mature" is probably an understatement.)

But in the meantime, there have been 2 major releases to the WIN/3B and
WIN/386 product lines.  To imply that what you got has any resemblance
to the current releases is stretching it a bit. 

I agree with you when you talk about the problems with the 3B1 WIN 
release.  After 4 years, it would be unrealistic to expect it not to 
have any.  I totally disagree when you extrapolate these problems to
cover the entire WIN/3B product line to date.  To take the 3B1 WIN
release as a fair representation of the current products is wrong.

I think your real problem is what do you do now?  How do you 
solve your problems?  Unfortunately I don't have a solution. 
Hopefully someone else does.  It just that bashing AT&T or TWG
is not productive and does not get you closer to a solution. It
may make you feel better but ...

Well thanks for listening.

			Chuck Gerlach
			AT&T Bell Labs
			cag@iwlcs.att.com
			...!att!iwlcs!cag
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 01:29:55 GMT
From:      mailrus!sharkey!cfctech!kevin@tut.cis.ohio-state.edu  (Kevin Darcy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
In article <9005182006.AA00073@dragon.twg.com> douglas@TWG.COM ("Douglas P. Ambort") writes:
>Ouch!  Mr. Floryan's  indictment of AT&T's implementation of a very old 
>outdated version of Wollongong TCP/IP, ported a long time ago by AT&T 
>to its 3B1's is harsh.  Given the 3B1, his indictment may not be  
>altogether off base; but it could be misconstrued by netnews readers as 
>a general indictment of all Wollongong TCP/IP (past, present, future, 
>and on good, bad or indifferent platforms).  And such an indictment 
>would not only be unfair, but misinformed.

He (Thad Floryan) criticizes the "latest" version of TCP/IP software 
publically available (and, if I'm not mistaken, still sold, perhaps only by 
Wollongong directly) for a still-existing base of 3B1's, based on his own 
personal experiences and professional expertise. I don't know what *you* would 
qualify as an "informed indictment"...?

>In this case of the (the 3B1 shortcomings described by Mr. Floryan), 
>AT&T has simply chosen not to upgrade an ancient TCP/IP 
>on a platform that has been retired. Perhaps AT&T is concentrating on 
>new platforms?  

How convenient for Wollongong to blame AT&T for not updating the product, 
while AT&T can cite the unfeasibility of doing so, given the state of the
original version (perhaps even give that as one of the marketing reasons that 
the UNIX PC line was discontinued). At some point, I would think that one or 
the other party would admit their mistake - either Wollongong for providing a 
flawed product, or AT&T for distributing it without adequate updates.

>If you want to see the best TCP/IP in its class, check out the TCP/IP 
>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines.
>It's Wollongong's.  And we're proud of it.

Sorry, I don't have a 6386, I have a 3B1, along with a lot of other "cult
diehards" who haven't joined the 80x86 tribe. I just bought a 3B1 ethernet 
card, and was looking forward to running TCP/IP on it to see what makes it 
tick. Now I hesitate. Would I be learning the *wrong* things from this setup? 
Is this really the ancestor of Wollongong's later products?
 
>On the other hand, if someone must rail against an old TCP/IP 
>implementation on (let's face it) 'old iron', go ahead.

And what happens when 3B2's or WGS's become 'old iron'? Cast them off in the
same manner?

I don't accuse Wollongong of being opportunistic and of only hyping their 
latest, sexiest implementations of TCP/IP on AT&T products, but if Mr. Ambort's
attitude is representative of Wollongong's as a whole, it seems to be bordering
very close to that...

>You could just as easily criticise the skinny tires on a Model T
>for not being steel belted radials.

But, then again, software and tires differ in significant ways: one seemingly
small deficiency or bug can render software useless for a given environment. 
It's not a question of *performance*, but (as I understand Mr. Floryan's 
comments), one of *functionality*. Those old tires *did work*, in other words.

(Since this is at this point mainly a vendor-support and 3B1 performance issue,
respondents please do not follow up to comp.protocols.tcp-ip. Thank you.)

DISCLAIMERS: I speak only for myself (*not* at all for Chrysler); a concerned
3B1 owner who has not yet used the product, but heard of its shortcomings
secondhand.

------------------------------------------------------------------------------
kevin@cfctech.cfc.com 		    | Kevin Darcy, Unix Systems Administrator
...[mailrus!]sharkey!cfctech!kevin  | Technical Services (CFC)
Voice: (313) 948-4863 		    | Chrysler Corporation
Fax:   (313) 948-4975 		    | 27777 Franklin, Southfield, MI 48034
------------------------------------------------------------------------------
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 01:35:24 GMT
From:      ekrell@ulysses.att.com (Eduardo Krell[dgb])
To:        comp.protocols.tcp-ip
Subject:   Re: Re. Wollongong TCP/IP

In article <12981@ulysses.att.com> I wrote:

>Not so, a quick scan at the header files shows that they all contain:
>
> * System V STREAMS TCP was jointly developed by Lachman Associates and
> * Convergent Technologies.

This is what I saw in the SVR4 source distribution. The binaries shipped
with the AT&T machines are from Wollongong, though. Go figure ...
-- 
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

{att,decvax,ucbvax}!ulysses!ekrell	Internet: ekrell@ulysses.att.com

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 03:08:44 GMT
From:      cs.utexas.edu!uwm.edu!rpi!image.soe.clarkson.edu!news@tut.cis.ohio-state.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <May.20.21.22.54.1990.4008@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:

   I have a feeling that over the course of the next year or so even
   without a definite policy, the number of unrestricted terminal
   servers is going to fall off to nearly zero.

That's too bad, because when I've gone travelling in the past, I've called
the local university, asked for their terminal server's phone number, and
telnetted back to Clarkson to check my mail.  It's a shame that that kind
of service has to go away...

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 May 90 08:31:09 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   TCPIP for the 3B1
I find all this talk about WINTCP and BSD and 3B1s very interesting, but
it leaves one very big question (at least to me.)  Where does one look to
find an ethernet card for a 3B1??  I have a pair of them that I would love
to put on my ethernet and then start writing some decent software for them.
I would have to write it myself, cause I sure couldn't afford to buy it
from Wolongong!!!

Any ideas about where I can find real cheap ethernet cards for a couple of
3B1s???


bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 04:26:51 GMT
From:      mojo!smaug@mimsy.umd.edu  (Kurt Lidl)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dealing with systems without nameservice.
In article <9005211548.AA13756@ucla-an.anes.ucla.edu> stan@ANES.UCLA.EDU (Stan Stead) writes:
>	We are running 4.3 BSD.  We currently use nameservice.
>Is there anyway to "hot-wire" an address 
>(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
>is if named is not running.  Please reply to my email address directly.

I was thinking about hacking in some changes to our version of libc
gethost*() routines.  We are currently running SunOS 4.0.3c on our
Suns, but are looking at upgrading to 4.1...  Sun has been good
enough to tell us all how to make our own dynamically run libraries
and I was thinking about putting in the U of Toronto's version of
the resolver routines.

One of the things that we have noticed is that if the nameservers
are down, with the current version of libc (from uunet), nothing
works.  We have a small /etc/hosts file on all our machines that is
kept up to date...

What it all boils down to is this:  If I alter the gethost*()
routines to try the nameservers first, and then, if they fail, check
the /etc/hosts files, will anything go terribly wrong?  I am
wondering why the current routines don't fall back on the hosts in
/etc/hosts?

Thanks.  E-Mail is preferred, but I also read this newsgroup.

							-Kurt
--
/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!smaug    | phrase the question very carefully. */
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 04:53:58 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Max FDDI frame rate on the glass
Anyone not yet saturated by the FDDI (mis)tuning discussion should also check
out traffic posted recently on "comp.dcom.lan" on the same subject. (Some of
the stuff may duplicate what has been said here recently, but not all.)

-Rob


-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 07:05:17 GMT
From:      wichert@quando.UUCP (Peter Wichert)
To:        comp.protocols.tcp-ip
Subject:   tcp problem auf MX500

Hallo,

Ich habe das Problem, eine tcp-ip Verbindung mit Siemens MX500 Rechnern
aufzubauen.
In unserem Netz gibt es diverse Rechner verschiedener 
Hersteller (HP, Nixdorf, Sun), und zwischen allen laeuft das
Programm (Client/Server).

Auf der MX500 liefert aus mir unerklaerlichen Gruenden das 'connect'
die Fehlermeldung "connection refused", was natuerlich nicht viel aussagt.

ftp, rlogin usw. funktioniert, lokale Verbindungen innerhalb
der MX500 klappen auch, nur zu anderen Rechnern per eigenen Sockets 
geht's nicht.

Hat jemand eine Idee ????
-- 
 Peter Wichert  UUCP:     {backbone}!unido!quando!wichert OR wichert@quando.uucp
  Quantum GmbH  Bitnet:   UNIDO!quando!wichert OR wichert%quando@UNIDO(.bitnet)
    Dortmund    internet: wichert%quando%unido.UUCP@mcsun.cwi.nl
    Germany     internet: wichert@quando.quantum.de

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 08:14:45 GMT
From:      mcsun!ukc!acorn!tenset!paul@uunet.uu.net  (Paul Andrews)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet drivers & Novell (confused...)
I'm getting confused about whats needed to run IPX over a packet driver
on a Novell diskless workstation (as you can probably guess, I haven't
tried it yet but I will have to in the future).

A document that comes with 6.x of the packet drivers says you need to run
romrel because simply delaying the card initialisation by the packet driver
doesn't work.

A recent posting of a mod to the 5.x head & tail.asm suggested that a delay
was sufficient.

I know that there may be many variables here, but can people with experience
of this let me know which approach worked for them? I guess for a true
comparison you would really have had to use John's mods in case he does
something different for the initialisation delay, but anyway...

I was in the process of making a similar mod to the 6.x head and tail.asm
that John had made to 5.x, I wouldn't have got it working without Johns
posting though. I have an addition that you can turn of the 802.3<->DIX
translation with an optional command line switch if you want to run in
'pure' mode. If anyone is interested in having the mod, mail me and I'll
arrange it. All the mods are ifdef'd so you can assemble the original code
using an assembler switch.

- Paul
-- 
------------------------------------------------------------------
| Paul Andrews             | Post: Tenset Technologies Limited,  |
| paul@tenset.uucp         |       Norfolk House,                |
| Phone: +44 223 328886    |       301 Histon Road,              |
| Fax:   +44 223 460929    |       Cambridge CB4 3NF, UK.        |
------------------------------------------------------------------
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Tue May 22 08:44:40 1990
From:      cctal!andrew@relay.EU.net
To:        tcp-ip@nic.ddn.mil
Cc:        cctal!andrew@relay.EU.net
Subject:   Background Ethernet under MS-DOS?
Does any one know of a way or a product to give background file transfer
over Ethernet with an Ethernet card in a PC running MS-DOS?
I am looking for the Ethernet equivalent of the program "Backmail" which 
gives this sort of function over modem dialup.

background while foregound word processor (Wordperfect) continues.
Thanks
Replies+Interest--->Summary to net
Andrew
Hardie

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 May 90 13:46:51 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        Stan Stead <stan@anes.ucla.edu>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>, "Kurt J. Lidl" <smaug@eng.umd.edu>
Subject:   Re: Dealing with systems without nameservice.
From Stan Stead:
>        We are running 4.3 BSD.  We currently use nameservice.  However,
>a site that we wish to exchange mail and files, while connected to the
>internet, does not use nameservice.  We can access the site by internet
>number, but not by name.  Is there anyway to "hot-wire" an address
>(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
>is if named is not running.

The real answer is for them to set up name service.  I can't think of
any good reason for sites attached to the internet to not be running
name service, or to find a site that can run name service for them.

And from Kurt Lidl:
>One of the things that we have noticed is that if the nameservers
>are down, with the current version of libc (from uunet), nothing
>works.  We have a small /etc/hosts file on all our machines that is
>kept up to date...

If the name servers go down too frequently, you may want to set up
more name servers, at least in caching mode.

>What it all boils down to is this:  If I alter the gethost*()
>routines to try the nameservers first, and then, if they fail, check
>the /etc/hosts files, will anything go terribly wrong?  I am
>wondering why the current routines don't fall back on the hosts in
>/etc/hosts?

This topic has been discussed.  The answer is that for most applications
(Telnet, FTP, etc.) the worst that will happen is that you will use
the wrong address for a host due to old information.  For mail, it can
be worse - an SMTP mailer will likely bounce some mail because the host
isn't listed in the hosts file.  Or it may mis-deliver it due to the
use of old information, or the failure to take MX records into account.

Doug Nelson
Michigan State University
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 11:50:43 GMT
From:      usc!samsung!emory!hubcap!ncrcae!secola!syackey@ucsd.edu  (Steve Yackey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>If you want to see the best TCP/IP in its class, check out the TCP/IP 
>>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines.
>>It's Wollongong's.  And we're proud of it.
>
>So AT&T threw out the Lachman-based one they supply standard with S5R4
>and supply a Woolongong-based release instead?

no, when you buy 5.4 you get lachman tcp.
when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp.
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 12:08:35 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <NELSON.90May21230840@image.clarkson.edu>,
nelson@sun.soe.clarkson.edu (Russ Nelson) says:
>That's too bad, because when I've gone travelling in the past, I've called
>the local university, asked for their terminal server's phone number, and
>telnetted back to Clarkson to check my mail.  It's a shame that that kind
>of service has to go away...

Actually, you can still check your mail, but for the price of a toll call
back to your own terminal server.

Maybe this is the price we have to pay for added security?

/Pete
--
Peter M. Weiss                   |  (this line intentionally left blank)
31 Shields Bldg (the AIS people) | 2 4 6 8 We don't want to calculate!
University Park, PA USA 16802    | Disclaimer -* +* applies herein
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 12:39:34 GMT
From:      zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!hybrid!robohack!woods@tut.cis.ohio-state.edu  (Greg A. Woods)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes:
> I agree with you when you talk about the problems with the 3B1 WIN 
> release.  After 4 years, it would be unrealistic to expect it not to 
> have any.  I totally disagree when you extrapolate these problems to
> cover the entire WIN/3B product line to date.  To take the 3B1 WIN
> release as a fair representation of the current products is wrong.

I assume, from what I see on the References line, that you are
refering to the "flame" I wrote.  I must appologize if it sounded like
I was flaming AT&T or the current WIN/3B product.  I've never seen the
WIN/3B1 software, and I'm unlikely to ever get much direct experience
with it.  The WIN/3B I was refering to was either for the 3B2 or some
non-AT&T machine.  It was also at least two years old.  However, I do
know that there are still sites hobbling along on with it.  They don't
know any better solution, and they do flame AT&T and TWG.

It is unfortunate that AT&T chose the original WIN/3B.  The original
WIN/3B has tainted my feelings, and I'm unlikely to ever try any
current version.
-- 
						Greg A. Woods

woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP
+1 416 443-1734 [h]   +1 416 595-5425 [w]   VE3-TCP   Toronto, Ontario; CANADA
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 13:31:09 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   TCPIP for the 3B1

I find all this talk about WINTCP and BSD and 3B1s very interesting, but
it leaves one very big question (at least to me.)  Where does one look to
find an ethernet card for a 3B1??  I have a pair of them that I would love
to put on my ethernet and then start writing some decent software for them.
I would have to write it myself, cause I sure couldn't afford to buy it
from Wolongong!!!

Any ideas about where I can find real cheap ethernet cards for a couple of
3B1s???


bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 13:35:32 GMT
From:      thorin!menges!menges@mcnc.org  (John Menges)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP Application Query
I've been away from network management for a while and need an update
on what's available in the way of SNMP applications for under, say,
$2500.  A year ago I'd have chosen Nysernet's SNMP distribution,
possibly augmented by CMU's or MIT's public domain stuff.  Is anything
else available now?
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 14:23:16 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!jhunix!ereiamjh@ucsd.edu  (Tom B. O'Toole)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes:
>Enough is enough.
>The 3B1 WIN release you are complaining about is over 4 years old.  To
>the best of my knowledge, there has never been another release for the
>3B1.  (To say the 3B1 is "mature" is probably an understatement.)
If it's so "mature" (translation "we won't support you any more"), shouldn't
it at least work? It doesn't make much sense to declare something "mature"
if it's obviously so immature...  I also find it suspect that something 
that is not all THAT old should have been retired over 4 years ago. The VAX
11/780 is much older and new software releases are still coming out for that
platform. An eye towards compatibility can work wonders...

>I totally disagree when you extrapolate these problems to
>cover the entire WIN/3B product line to date.  To take the 3B1 WIN
>release as a fair representation of the current products is wrong.
Is the release of WIN/3b for the 3b/4000 considered current? It still
has myriad problems. But I guess that doesn't matter because the 3b/4000
is now "mature", right??? Everyone should move on to yet another platform
which is not binary compatible at the OS or applications level.

>
>I think your real problem is what do you do now?  How do you 
>solve your problems?  Unfortunately I don't have a solution. 
For starters, maybe AT&T should stop moving rapidly from platform to
non-compatible platform, stating that each is the next "great thing"
only to abandon it two years down the road. But since they keep doing
this, I agree, there isn't a solution; the user is totally hosed.

>Hopefully someone else does.  It just that bashing AT&T or TWG
>is not productive and does not get you closer to a solution. It
>may make you feel better but ...
People will feel even better when AT&T and TWG don't deserve to be
bashed, but for now, it's the only "solution" they have...

>Well thanks for listening.
Is AT&T?
-- 
Tom O'Toole - ecf_stbo@jhuvms.bitnet     "Internet is the wide area network
JHUVMS system programmer       protocol packaged with TCP/IP that unix systems
Homewood Computing Facilities  rely on to communicate remotely with each other"
Johns Hopkins University, Balto. Md. 21218                   -Digital Review
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 14:32:05 GMT
From:      paperboy!meissner@think.com  (Michael Meissner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dealing with systems without nameservice.
In article <1990May22.042651.1911@eng.umd.edu> smaug@eng.umd.edu (Kurt
Lidl) writes:

| I was thinking about hacking in some changes to our version of libc
| gethost*() routines.  We are currently running SunOS 4.0.3c on our
| Suns, but are looking at upgrading to 4.1...  Sun has been good
| enough to tell us all how to make our own dynamically run libraries
| and I was thinking about putting in the U of Toronto's version of
| the resolver routines.
| 
| One of the things that we have noticed is that if the nameservers
| are down, with the current version of libc (from uunet), nothing
| works.  We have a small /etc/hosts file on all our machines that is
| kept up to date...
| 
| What it all boils down to is this:  If I alter the gethost*()
| routines to try the nameservers first, and then, if they fail, check
| the /etc/hosts files, will anything go terribly wrong?  I am
| wondering why the current routines don't fall back on the hosts in
| /etc/hosts?

While this may not apply to Suns, other systems provide means that a
system manager can configure the order hosts are searched (/etc/hosts,
yp, and DNS).  I know both DG/UX and Ultrix provide this capability
(in a slightly different fashion).  Here is the appropriate man page
from Ultrix:


     NAME
          svcorder - designate the order and selection of services

     SYNTAX
          /etc/svcorder

     DESCRIPTION
          The file designates the order and selection of name services
          that will be queried to resolve host names and addresses.
          The queries to the services are made through the interface.

          The file must exist if your system accesses host names and
          addresses by database lookup services such as Yellow Pages
          (YP) or BIND.  You do not need the file if you only have
          local access, that is, if you are using only the local file
          to obtain host name and address information.

          The service names are defined in the file.

          The order in which the service names are placed in the file
          indicates the order that they are queried to resolve a given
          name or address.  The following example shows the contents
          of the file if YP will be queried first, then BIND, and then
          the local service, if YP cannot resolve the data: yp bind
          local The file must have an entry for Otherwise, your system
          cannot resolve any queries in the event that the lookup
          services, other than local, are down.

          If you set up a database lookup service such as YP or BIND,
          be sure that the file exists.  Create the file if it does
          not.  The and commands do this automatically.

     FILES
          /etc/hosts
          /usr/include/netdb.h
          /etc/svcorder

     SEE ALSO
          gethostent(3n), hosts(5), bindsetup(8), ypsetup(8yp)
          Guide to the BIND Service
          Guide to the Yellow Pages Service

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 17:46:51 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Dealing with systems without nameservice.

From Stan Stead:
>        We are running 4.3 BSD.  We currently use nameservice.  However,
>a site that we wish to exchange mail and files, while connected to the
>internet, does not use nameservice.  We can access the site by internet
>number, but not by name.  Is there anyway to "hot-wire" an address
>(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
>is if named is not running.

The real answer is for them to set up name service.  I can't think of
any good reason for sites attached to the internet to not be running
name service, or to find a site that can run name service for them.

And from Kurt Lidl:
>One of the things that we have noticed is that if the nameservers
>are down, with the current version of libc (from uunet), nothing
>works.  We have a small /etc/hosts file on all our machines that is
>kept up to date...

If the name servers go down too frequently, you may want to set up
more name servers, at least in caching mode.

>What it all boils down to is this:  If I alter the gethost*()
>routines to try the nameservers first, and then, if they fail, check
>the /etc/hosts files, will anything go terribly wrong?  I am
>wondering why the current routines don't fall back on the hosts in
>/etc/hosts?

This topic has been discussed.  The answer is that for most applications
(Telnet, FTP, etc.) the worst that will happen is that you will use
the wrong address for a host due to old information.  For mail, it can
be worse - an SMTP mailer will likely bounce some mail because the host
isn't listed in the hosts file.  Or it may mis-deliver it due to the
use of old information, or the failure to take MX records into account.

Doug Nelson
Michigan State University

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 19:05:12 GMT
From:      vmp!sonyd1!bruce@uunet.uu.net  (Bruce Lilly)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW
In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes:
>Enough is enough.
>
>The 3B1 WIN release you are complaining about is over 4 years old.  To
>the best of my knowledge, there has never been another release for the
>3B1.  (To say the 3B1 is "mature" is probably an understatement.)
>
>But in the meantime, there have been 2 major releases to the WIN/3B and
>WIN/386 product lines.  To imply that what you got has any resemblance
>to the current releases is stretching it a bit. 
>
>I agree with you when you talk about the problems with the 3B1 WIN 
>release.  After 4 years, it would be unrealistic to expect it not to 
>have any.  I totally disagree when you extrapolate these problems to
>cover the entire WIN/3B product line to date.  To take the 3B1 WIN
>release as a fair representation of the current products is wrong.

If one's sole experience with WIN/3B is the version for the 3B1, and
neither Wollongong nor AT&T has issued a fixdisk or other update for
the product, then it is reasonable to expect that the vendor(s) are
not interested in correcting the problems, and therefore the product
IS probably representative of other products from the vendor(s).

>I think your real problem is what do you do now?  How do you 
>solve your problems?  Unfortunately I don't have a solution. 
>Hopefully someone else does.  It just that bashing AT&T or TWG
>is not productive and does not get you closer to a solution. It
>may make you feel better but ...

The real problem is what should AT&T and Wollongong do now? Speaking
for myself, I will certainly not buy any other Wollongong/AT&T
product unless and until they ``make good'' that which I have
purchased. Although the 3B1 has been discontinued, AT&T has
supported it with fixdisks. A similar policy regarding the
AT&T/Wollongong WIN/3B product for the 3B1 would go a long way
towards easing the current hard feelings toward the product.

It would seem to be in AT&T's interest to ensure that the product
works reasonably (especially the TLI routines -- AT&T's answer to
Berkeley-style networking) since AT&T's name is on the product.
Similarly, it is in Wollongong's interest to make a reasonable
effort to correct the product's deficiencies in order to AVOID
the impression that all Wollongong products are similarly
deficient. This is simply good business practice.

Finally, I don't recall seeing any ``bashing'' of either AT&T
or Wollongong -- simply the result of frustrations caused by
a clearly deficient product.

Disclaimer: these are my opinions, not my employer's.
-- 
	Bruce Lilly, Product Manager,      | bruce@sonyd1.Broadcast.Sony.COM
	Digital Television Tape Recording, | uunet!{sonyusa,vmp}!sonyd1!bruce
	Sony Communications Products Co.   | lilb@sony.compuserve.com (slow)
	Telephone: 1(201)833-5693	       | FAX: 1(201)833-9279
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 19:53:20 GMT
From:      pete@sinix.UUCP (Pete Delany)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,bit.listserv.tcpip-l,comp.lang.postscript,comp.windows.news
Subject:   NeFS - Network Extensible File System

Carl Smith <cs@Eng.Sun.COM> mentioned that:
   >
   > The NFS version 3 protocol (now called NeFS - Network extensible 
   > File System) is available as a PostScript file via anonymous     
   > FTP as                                                           
   >                                                                  
   >      ./public/nefs.doc.ps on titan.rice.EDU (128.42.1.30).      
   >                                                                  
   > the file is ~250K and generates 52 pages.

Is there a recient posting on usenet and if not could someone post one
to make it easily available?  It would take a non-trivial amount of work
to FTP a copy and get it here. It sounds very important, and more than
worthy of a posting.  For those that have read the new NFS spec, any 
opinion?  Sounds a bit like Microsoft focusing more on Windows 3.0 than
OS2 (See Wall Street Journal 22-May-90).

-pete

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 20:36:34 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dealing with systems without nameservice.
Perhaps gethostbyname() should use intra-machine IPC (e.g., UNIX-domain
sockets) to connect to the nameserver. This would have the advantage of
strict modularity: you could change the name lookup mechanism without
even recompiling any programs. It also wouldn't require the burden of
shared libraries.

/dev/hostbyname, maybe.

> One of the things that we have noticed is that if the nameservers
> are down,

Gasp! Your nameservers go down? This can't be the ultra-reliable DNS
we're talking about here?

---Dan
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      22 May 90 22:15:30 GMT
From:      cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!atha!lyndon@tut.cis.ohio-state.edu  (Lyndon Nerenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   is "localhost" an official name?
I seem to recall reading in an RFC somewhere that the loopback interface
must have loopback[.domain] as it's name, or as an alias. Is this in
fact the case? If so, I would appreciate a reference ...

-- 
Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
    {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 00:15:17 GMT
From:      mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
Phil Karn and Louie Mamakos have come down pretty hard against
filtering in routers.  Phil sez
    In my opinion, host security is both necessary and sufficient to prevent
    break-ins.

Well, we've had a fair amount of experience with a screening gateway
between thousands of hosts inside DEC and the cruel world out there.
(People who want to know the details: see my paper in Proc. USENIX
Summer '89.)  Anyone who thinks that it is possible to keep that many
hosts secure (most of them run by people who aren't interested in
keeping them secure, and probably wouldn't know how to do it) is dreaming.

Of course these machines can and should be fixed; at the same time,
we would be fools to believe that they all ever will be.

The advantage of the screening gateway is that we reduce the size of
the set of must-be-secure hosts from 10K or 100K down to around 10
or 100.  I assert that it is possible to build a screening gateway
that will guarantee that only these hosts are exposed to attacks from
the network.  (This is not to say that all implementations are secure,
of course!)

There is always the temptation to push the limits of this guarantee.
For example, we do allow certain kinds of packets to flow between
the Internet and random DEC hosts.  This is done in the belief that
what we are doing is safe, but ultimately it is a tradeoff between
possibly impairing security and definitely impairing functionality.
If we discover that we have misunderstood the security implications,
we can pull the plug on this bypass at one place: the screening
gateway.  We don't have to run around to 100K hosts and fix them all,
and we don't have to unplug from the network entirely while we
try to discover what happened.

Louie sez
    I know that I can't sleep any better at night knowing that I have a
    filtering gateway "protecting" me.  If you want security, you need
    to take a comprehensive approach to providing it, not shots in the
    dark here and there.
I do sleep better knowing that the screening gateway is there.  We've
had machines attacked by numerous and occasionally clever hackers,
but as far as we know (we could be wrong) the hosts inside the screen
have been untouched by such attacks as the Morris Worm and the
Australians earlier this year.  In both those instances, I can point
to specific ways in which the screen prevented the problem from
spreading.  I would not want to say that any of these hackers would
have been stopped forever by the screen, and I would not want to
say that I am sure that the screen protects me ... but I do sleep
better.  (I know that the lock on my front door could be picked,
but I wouldn't get as much sleep if it were removed!)

In summary, a screening gateway is NOT a "shot in the dark", and it
IS part of a "comprehensive approach" to security.  I claim that
for the time being, it is a required part of any approach that could
be claimed to be comprehensive; you can't rely on one mechanism for
security.  Think of an ocean liner: the captain had better not let
the ship hit an iceberg, but when it happens (and it does!) those
watertight bulkhead doors may well save the passengers.

-Jeff
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 May 90 07:28:54 -0400
From:      Stephen Wolff <steve@cise.nsf.gov>
To:        psuvm!pmw1@PSUVAX1.CS.PSU.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Dial up access to Internet facilities
In article <NELSON.90May21230840@image.clarkson.edu>,
nelson@sun.soe.clarkson.edu (Russ Nelson) says:
>That's too bad, because when I've gone travelling in the past, I've called
>the local university, asked for their terminal server's phone number, and
>telnetted back to Clarkson to check my mail.  It's a shame that that kind
>of service has to go away...

Dial-up access is now offered as a commercial service in some cities.  It's
all a part of the Internet's growing up...  -s

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 May 90 10:23:41 pdt
From:      Walter Underwood <wunder@hp-ses.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
   Jeff Mogul:
   The advantage of the screening gateway is that we reduce the size of
   the set of must-be-secure hosts from 10K or 100K down to around 10
   or 100.

HP does exactly the same thing.  I think of it as similar to
international borders.  If you are flying into the US, you must land
at an international airport.  You can't land at any random airstrip.
Maybe 1% of the airports in the US are set up with customs agents and
all that border jazz.  Same thing for hosts in HP.  Less than 1% are
"open subnet hosts", and those get special attention.

We don't issue visas, though.  That is Jeff's department.

wunder

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 03:47:21 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <435@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul) writes:
>[...] I assert that it is possible to build a screening gateway
>that will guarantee that only these hosts are exposed to attacks from
>the network.  (This is not to say that all implementations are secure,
>of course!)

How sure are you? You have a pretty big network, probably much larger than
ours, and if it's at all like ours I bet you don't keep perfect track of
*everything* that might be attached to it.  Are you willing to bet that in
some remote backwater of your network there isn't an unprotected Cisco
terminal server or a Xylogics Annex box connected to a bunch of outside
modem lines?  How about the BSD workstation or PC running KA9Q or PCroute
that somebody sets up in his office between his Ethernet tap and his office
phone to give himself unpassworded, ad-hoc SLIP access from home?  And are
you willing to bet that every host on your network with outside dialups is
completely secure? I think it's a rare organization whose ONLY possible
route to the outside world is through exactly one IP router.

I think that filtering IP routers are like the Maginot Line. The latter did
exactly what it was designed to do. It's just that the Germans had plenty of
other routes for attacking the West, so they simply went around it.

Phil
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 06:46:39 GMT
From:      eru!luth!sunic!mcsun!inria!irisa!leconte@bloom-beacon.mit.edu  (Thierry Leconte)
To:        tcp-ip@nic.ddn.mil
Subject:   C source of sftp (RFC913) wanted
I'm looking for public domain C sources of the Simple File Transfer
Protocol (RFC 913) or any other simple file transfer protocol that use
exclusively tcp (and not udp ).

Please answer by email

Thanks in advance

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|   Thierry LECONTE     |      ,      ,---   ,---         |
|     INRIA/IRISA       |     /      /      /---          |
|  Campus de Beaulieu   |    (___   (___   (___           |
|  35042 RENNES CEDEX   |                                 |
|        FRANCE         | GOTHIC project (INRIA/BULL)     |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Tel: 99 36 20 00      e-mail: Thierry.Leconte@irisa.fr  |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 May 90 11:19 EDT
From:      PARCHAMB@ecs.umass.edu
To:        tcp-ip@nic.ddn.mil
Subject:   mailing list
Please Remove my name from the mailing list 
Thanks,
Peter
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 11:26:19 GMT
From:      mojo!smaug@mimsy.umd.edu  (Kurt Lidl)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dealing with systems without nameservice.
Doug Nelson (08071TCP@MSU.BITNET) writes:
>And from Kurt Lidl:
>>One of the things that we have noticed is that if the nameservers
>>are down, with the current version of libc (from uunet), nothing
>>works.  We have a small /etc/hosts file on all our machines that is
>>kept up to date...
>
>If the name servers go down too frequently, you may want to set up
>more name servers, at least in caching mode.

The particular incident that started this line of questioning on my
part was dealing with a one second power glitch that nailed the SOA
nameserver and the two caching nameservers for our network.  All the
dataless clients that were hit came up first (just a local hard
disk to fsck, compared to a couple of gigabytes of storage on the
nameserving machines), and then failed to add the default gateway
when "route" was unable to get the address of the gateway from the
nameservers.

I guess the real solution to the problem is giving the SOA
nameserver have a UPS of its own. (Aha!  The solution involves
spending money.  Luckily, it is not my money.)

>>[my naive question was here]
>This topic has been discussed.

Are there a comprehensive sets of archives that I can FTP from
someplace or another?  I assume that someone must archive this
group for posterity's sake.  (I don't remember seeing a "Commonly
Asked Questions" message, or any announcements of a archive site for
this newsgroup.  Maybe I just missed them.)

>Doug Nelson

I would also like to take this opportunity to thank all of the
individuals who responded to my questions in a most helpful manner.  

Jim Guyton		guyton@rand.org
Richard Dunbar		rdunbar@dftsrv.gsfc.nasa.gov
Tony Nardo		trn@warper.jhuapl.edu
Steve Miller		steve@umiacs.umd.edu
Doug Nelson		08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu
			(reply posted to tcp-ip as well as mailed)

The general concensus was that having the gethost*() routines fall
back on the /etc/hosts file is "iffy at best".  I may try the
modifications for the heck of it, at least for the simple address
lookup call.  Several of the responses pointed out that bad
interactions would happen with MX-record things and so forth...
Steve pointed out that keeping anything in the /etc/hosts file that
was not under my administrative control would be a *bad* thing to
do.  I agree with this whole-heartedly.  If I have any really
outrageous problems with the modifications, I will let the list know
about them.  Also, if anyone can give a really good reason NOT to
make these changes, please mail me.  The worst that has been pointed
out to me was the possibility of some bounced mail.  Thanks again.
--
/* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!smaug    | phrase the question very carefully. */
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 May 90 18:54:09 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu (Steve Dyer)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

Steve and Steve,

PSI does not offer Internet access through its free dialups scattered
throughout the US, the access is restricted to its customer base
by using validated network numbers.
This service has been advertised through our brochure since Janaury.

Aside from any economic considerations in providing an Internet wide
terminal service there are two issues that are of signifcant concern
to us:

1) Is it appropriate for any organization to provide this service in
	consideration of the security issues, and appropriate use
	of many people's network.
2) What are the legal/monetary liability issues for an organization
	who's customer did something "bad".

Essentially we're concerned about being good Internet citizens here,
we could price, bill, and deliver Internet access dialups throughout
the US.  But is that a good thing?

I believe that a number of network providers may require active
filtering against this type of dialup to protect themselves.  Our
current customers certainly ask and we provide the addresses
for that purpose.

Marty
------------------------
 In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen 
Wolff) writes:
 >Dial-up access is now offered as a commercial service in some cities.  It's
 >all a part of the Internet's growing up...  -s

 And when they start advertising so that potential clients actually *know*
 about it, then the Internet will really have passed adolescence. :-)

 I'd love to hear more about this.  I hope such services don't require that
 you have a direct hookup to their own network in order to take advantage
 of the dialups (i.e., TACACS at the dialup point only authorizes you iff
 you are in their databases, and you only get into their databases if your
 site is spending big bucks for a direct connection to their network.)

 That is, as a NEARnet/CENTnet site, I'd hardly have a preexisting arrangement
 with PSI, UUNET, MERIT, etc.  Maybe we need something like cellular
 "roaming"...

 -- 
 Steve Dyer
 dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
 dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 12:49:08 GMT
From:      att!dptg!mtune!rkh@ucbvax.Berkeley.EDU  (Robert Halloran)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
In article <539@secola.Columbia.NCR.COM> syackey@secola.UUCP (steve yackey) writes:
>In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>>If you want to see the best TCP/IP in its class, check out the TCP/IP 
>>>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines.
>>>It's Wollongong's.  And we're proud of it.
>>
>>So AT&T threw out the Lachman-based one they supply standard with S5R4
>>and supply a Woolongong-based release instead?
>
>no, when you buy 5.4 you get lachman tcp.
>when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp.

The SVr4 source package includes Lachman TCP/IP code.

Binary distributions for AT&T 3B (and probably 386 - haven't seen it) have 
TWG binaries included.

On the 6386, the Micom/Interlan package we OEM'd  has been replaced with TWG.

						Bob Halloran
=========================================================================
UUCP: att!mtune!rkh				Internet: rkh@mtune.dptg.att.com
Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed.
Quote: "Remember, kids, if some weirdo in a blue suit offers you some DOS,
	   JUST SAY NO!!!" 
=========================================================================
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 14:45:43 GMT
From:      mitel!sce!cognos!dy4!paul@uunet.uu.net  (Paul Burry)
To:        tcp-ip@nic.ddn.mil
Subject:   Request for protocol overhead references

	We are interested in any information that may be available regarding
the processing overhead associated with network protocols such
as TCP/IP, TP4, etc.

	In particular, we are interested in the amount of processing required
per unit of data transferred via these protocols.

	Could someone please refer me to any relevant articles?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Paul Burry 			PHONE:  (613)-596-9911
UUCP: ...!cognos!dy4!paul	POST:	Dy4 Systems Inc., 21 Fitzgerald Road,
or    ...!cognos!dy4!seu13!paul	Nepean, Ontario, Canada K2H 9J4

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Paul Burry 			PHONE:  (613)-596-9911
UUCP: ...!cognos!dy4!paul	POST:	Dy4 Systems Inc., 21 Fitzgerald Road,
or    ...!cognos!dy4!seu13!paul	Nepean, Ontario, Canada K2H 9J4
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 15:20:48 GMT
From:      mcsun!hp4nl!ncsbv!peter@uunet.uu.net  (Peter Jannesen)
To:        tcp-ip@nic.ddn.mil
Subject:   PC-LAN and TCP-IP
A client of use has a tokenring network running IBM's pc-network.
We would like to add to this network a UNIX box running 386/ix or SCO-UNIX.
The only thing we want is a telnet session to the UNIX box.
So I have the following questions:

1. Is there a tokenringcard driver for 386/ix or SCO-UNIX?

2. Is there a streams devices driver in sources avaible for UNIX. (To adopt
   this driver to the tokenring card).

3. Is there a driver for the tokenringcard from IBM which is capable to 
   run PC-LAN and TCP-IP on the same time.

4. which products are availble to run TELNET/TCP-IP on a PC. How much memory
   use those product.

===============================================================================
Peter Jannesen
Network Communication Systems (N.C.S), The Netherlands
Phone:  +31104130093				 Fax:    +31104146452
Address: Westbaak 96
	 3012 KM Rotterdam, The Netherlands
===============================================================================
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 May 90 22:15:01 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        snorkelwacker!spdcc!dyer@think.com (Steve Dyer)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

> On this topic, I am concerned about the balkanization of the Internet
> in the interest of "security" without attention being payed to what
> customers want.

I think that laying the blame for the balkanization of the Internet
at the feet of security is a pretty superficial analysis.  Most of
the balkanization is an effect of the very concept of "regional networks"
which have customers tied together by a national network which effectively
has no customers.  Some indviduals might posit that the model is exhausted and
that national/international networks that
have customers directly is the future for
the Internet.

> Clearly a dialup facility which restricts access to
> members of a particular commercial network (like PSI) is one very
> proper service, and I'm glad it's offered to its customers, but it
> doesn't yet address the needs of people associated with regional
> networks trying to stay in touch when they're out of town.

Given that it is free to its customer base (a point that seems to
have been overlooked) others might perceive it as a value added that
a "competitor" doesn't have.  You might even sell it that way to
prospective customers....  :-)

> Thus, I
> applaud the efforts of CERFnet and UUNET to offer authenticated,
> for-fee access to Internet as a whole.  I can guarantee that I'll
> be interested in using their services whereas Marty's (if I understand
> him correctly) just looks like an interesting service.

You don't understand me correctly.  Essentially we've been waiting
for the time that a prescedent is set, permission is granted, or
a consensus may be achievable in the Internet community.  That time may
be now, and the PSI blitzkreig may descend.

I'll of course let you know in the least crass commercial manner that
I can, if it is of interest.....

Marty
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 16:38:25 GMT
From:      snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes:
>Dial-up access is now offered as a commercial service in some cities.  It's
>all a part of the Internet's growing up...  -s

And when they start advertising so that potential clients actually *know*
about it, then the Internet will really have passed adolescence. :-)

I'd love to hear more about this.  I hope such services don't require that
you have a direct hookup to their own network in order to take advantage
of the dialups (i.e., TACACS at the dialup point only authorizes you iff
you are in their databases, and you only get into their databases if your
site is spending big bucks for a direct connection to their network.)

That is, as a NEARnet/CENTnet site, I'd hardly have a preexisting arrangement
with PSI, UUNET, MERIT, etc.  Maybe we need something like cellular
"roaming"...

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 16:48:07 GMT
From:      hercules!heap.cisco.com!byrd@apple.com  (Bruce Byrd)
To:        tcp-ip@nic.ddn.mil
Subject:   MAC with SLIP

I'm trying to find software packages for the MAC that support SLIP
(commercial and public domain).  Can you send me an email if you
know of any (besides cisco's public domain version).

Thx,

Bruce Byrd
cisco Systems
byrd@cisco.com
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 17:40:34 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
>>So AT&T threw out the Lachman-based one they supply standard with S5R4
>>and supply a Woolongong-based release instead?
>
>no, when you buy 5.4 you get lachman tcp.
>when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp.

Lots of people seem to have misread what I said.  In the hope that
nobody who hasn't yet had the opportunity to do so does so, I'll note
that I said

> ...the Lachman-based one they supply standard with S5R4...

*explicitly acknowledging* that "when you buy 5.4 you get lachman tcp",
and that what I was asking was whether AT&T, when building the S5R4
release that they supply as the OS for their 386-based machines, threw
out the Lachman-based TCP/IP supplied in source form with S5R4 source,
and replaced it with Woolongong's version.  The answer to that question
is "yes, they did". 
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 18:25:53 GMT
From:      cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <23521@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
>I think that filtering IP routers are like the Maginot Line. The latter did
>exactly what it was designed to do. It's just that the Germans had plenty of
>other routes for attacking the West, so they simply went around it.

If one wishes a complete and accurate analogy, one should note that the
original planners of the Maginot Line specified that it should cover the
routes the Germans ended up using... it was cut back by the politicians to
save money.
-- 
Life is too short to spend    |     Henry Spencer at U of Toronto Zoology
debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 18:29:34 GMT
From:      rick@uunet.uu.net  (Rick Adams)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
UUNET plans to offer access to any Internet site from any Compuserve Dialup
in the continental US.

All access will require an individual login/password for accountability and
authorization to use the Internet will be verified before the account is
established.

Performance is "acceptable". Certainly better than the MILNET TACs, but
not quite as good as a direct modem connection.

We plan to charge $5 per connect hour (in increments of 1 minute).

We could start tomorrow if I could figure out how to bill for it.
Its not worth sending out invoices for only $5.

--rick
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 18:31:48 GMT
From:      zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Wither Ethernet?
In article <9005211233.AA15946@gateway.mitre.org> hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes:
>It has been suggested by some standards gurus that in the future
>all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead
>(or possibly dying) protocol...

Um, what do you mean by "Ethernet"?  If you're referring to the hardware,
all three flavors -- Ethernet 1, Ethernet 2, and 802.3 -- are pretty much
cable-compatible and there is no issue here.  Half the people with Ethernet
networks probably don't even know exactly which flavor all their boxes are.
Or care.

If you're thinking of the 802.2 protocol stuff as opposed to Ethernet
packet-type codes, or the OSI protocol stack as opposed to TCP/IP (neither
of which is tied to Ethernet in any way), then to borrow a phrase from
the past, if this is so, it's one of the few known protocols that is dying
out on a steep upward curve.
-- 
Life is too short to spend    |     Henry Spencer at U of Toronto Zoology
debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 21:04:43 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!ogicse!plains!lodin@ucsd.edu  (Joe Schmo)
To:        tcp-ip@nic.ddn.mil
Subject:   Subnetting problems

I have a question relating to subnetting.  We at GM/EDS/Delco are starting
to get our act together and registering all TCP/IP hosts on the company
internetwork.  As far as I know, GM/EDS has been given the class B Internet
Address 130.171.  Delco has been given the address range 130.171.8-15 from 
EDS.  They (EDS) have decided to divide it as such for Delco:

130.171.8.0 - 130.171.11.255 subnet mask 0xfffffc00 broadcast 130.171.11.255
130.171.12.0 - 130.171.12.15 subnet mask 0xfffffff0 broadcast 130.171.12.15
130.171.12.16 - 130.171.12.31 subnet mask 0xfffffff0 broadcast 130.171.12.31
...
130.171.12.128 - 130.171.12.159 subnet mask 0xfffffe0 broadcast 130.171.12.159
130.171.12.160 - 130.171.12.191 subnet mask 0xfffffe0 broadcast 130.171.12.151
...
130.171.14.0 - 130.171.14.63 subnet mask 0xffffffc0 broadcast 130.171.14.63
130.171.14.64 - 130.171.14.127 subnet mask 0xffffffc0 broadcast 130.171.14.127
...
130.171.15.0 - 130.171.14.127 subnet mask 0xffffff80 broadcast 130.171.14.127
130.171.15.128 - 130.171.14.255 subnet mask 0xffffff80 broadcast 130.171.14.255


Essentially what they have done is subdivide our subnet into unequal
networks that would seem to require different netmasks.  I have a gateway
workstation with one LANIC connected to the backbone with address
130.171.8.204 and then I have the network 130.171.12.1-15.  If I set my
netmasks different, 0xfffffc00 on the gateway LANIC and 0xfffffff0 on the
local LANIC, my networking software has problems getting thru the gateway.
If I set them the same (0xfffffc00) then I can get thru the gateway fine, 
but now the the range 130.171.12-15.xx seem to be on the same physical wire.

The machines involved are HP 9000/3XX w/HP-UX 7.0, Sun 386i w/SunOS 4.0.2,
Sun 4 w/SunOS 4.0.3, and eventually Intergraphs.  The HP's are running gated
and the Suns are running routed.

Customer reps with HP and Sun recommended we keep the same netmask on all
machines regardless of the network, and for now that works until I want to
talk to machines in the rest of the 130.171.12-15 range.

Comer's book alludes to being able to have multiple subnets on the same
physical wire with discrete fixed routing tables.  As an experiment, we
tried this (metric 0) and it didn't work.  It also said something
about netmask information being kept in the routing tables, but I haven't
seen that in dumps from routed and gated.  I could only see it in ifconfig
information.

From what I can determine, we may need to go to multiple virtual subnets on
one network like described in "Introduction to Administration of an
Internet-based Local Network".  Yet this seems to imply that all subnets will
be of the same size.

I'm not sure of the planning or analysis that went into this method of
address allocation, but it seems to be improper.  I understand that will a
company of our size, there will be tradeoffs in any decision involving
networking adminstration.  We have small local department networks and large
company-wide networks, that in some instances, are all connected on the same
physical wire.  EDS has traditionally been an IBM house, so I'm not sure of
their TCP/IP networking experience (go ahead and send flames), and I
question their network administrative tactics.

Please send any answers (:-), comments, references, or experiences to:


Steve Lodin
Advanced Instrumentation Engineering
      -------------
Delco |Electronics| Corp
      -------------
		 \
		  \
		    It's who we are

Tel:  ATT 317-451-8722      GM 8-322-8722
Domain:  lodin%koiasvr01.uucp@ee.ecn.purdue.edu
   or    swlodin@koess.gm.hac.com
UUCP:    <backbone>![iuvax|pur-ee]!koiasvr01!lodin
GM:      LODIN,SW <KOESS::SWLODIN>
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      23 May 90 22:59:24 GMT
From:      sdcc6!ee299at@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <2936@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes:
>>Dial-up access is now offered as a commercial service in some cities.  It's
>>all a part of the Internet's growing up...  -s
>
>And when they start advertising so that potential clients actually *know*
>about it, then the Internet will really have passed adolescence. :-)
>
>I'd love to hear more about this.  I hope such services don't require that
>you have a direct hookup to their own network in order to take advantage
>of the dialups (i.e., TACACS at the dialup point only authorizes you iff
>you are in their databases, and you only get into their databases if your
>site is spending big bucks for a direct connection to their network.)
>
>
>-- 
>Steve Dyer
>dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
>dyer@arktouros.mit.edu, dyer@hstbme.mit.edu


CERFNet recently announced a dial-up internet access service
from terminal servers at UCLA , UCIrvine , Caltech , SDSC and UCOP(Oakland)
and will be expanding to other sites on demand.
The service also offers SLIP 

A direct connection from your site to CERFNet  is *NOT* required .
In fact we designed this service for those who do not need /cannot afford
the high-end service and those who like to "roam" ( we also offer mail and netnews)
You do need to prove that your use is commensurate with the "Internet Acceptable
Use Policy" and you will need to authenticate yourself whenever you login.

There will be a monthly fee and connect charges of $5/hr.

--pushpendra
pushp@cerf.net
(619) 534-5067
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 00:15:29 GMT
From:      snorkelwacker!spdcc!dyer@think.com  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
On this topic, I am concerned about the balkanization of the Internet
in the interest of "security" without attention being payed to what
customers want.  Clearly a dialup facility which restricts access to
members of a particular commercial network (like PSI) is one very
proper service, and I'm glad it's offered to its customers, but it
doesn't yet address the needs of people associated with regional
networks trying to stay in touch when they're out of town.  Thus, I
applaud the efforts of CERFnet and UUNET to offer authenticated,
for-fee access to Internet as a whole.  I can guarantee that I'll
be interested in using their services whereas Marty's (if I understand
him correctly) just looks like an interesting service.

Of course, there are all sorts of ways to have your cake and eat it
too:  I wouldn't have any problem with using a dialup service which
associated an authenticated dialup account with some restriction on the
target nets (or even hosts) which could be reached.  Thus, an account
whose password was improperly disseminated would not be such a gaping
security hole.  You're talking database lookups rather than static
address matching, of course.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 03:16:38 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   UDP protocol for short messages?
Has anyone implemented a UDP protocol for sending short messages to a resource-
limited host?  If so, I'd like to see how you did it.  I'm working on such
a protocol, and I'd prefer to make new mistakes, rather than repeat any of
yours.  :-)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 May 90 10:12 EDT
From:      dangelo@whuts.att.com
To:        tcp-ip@nic.ddn.mil
Subject:   remove name from list

Please remove my name from the mailing list.
Thank you.

Diana
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 May 90 10:12:34 edt
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        rick@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
Since mail is one of the big uses of the Internet, do most people
that subscribe to dial-up internet already have directly connected
machines in other places at which they receive mail?  Or will
someone start selling permantly attached accounts in addition to
dial-up, so that one can retrieve their mail after they dial-up?

PT
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 May 90 15:10:10 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   re: Dial up access to Internet facilities

I've always felt that the best solution to the dial-up access problem
was to make it easy for people to hook up their PC to your local Ethernet,
get a temporary IP address (via some address assignment protocol) and
voila, they are connected.  One could do similar things with a 
900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address,
you're off].

In other words, the key problem is making it easy for someone with a
PC to get a local IP address and do something.

Craig
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu 24 May 90 14:45:32-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        tcp-ip@nic.ddn.mil
Subject:   Netwatch ???

I heard that there was an ethernet monitor package called netwatch, and
that the latest version was available for anonymous ftp from either
husc6.harvard.edu or lancaster.andrew.cmu.edu.  Unfortunately, I could
not find it in either place.  

Am I blind?
Is it called something other than netwatch?

I got my original info off this mailing list, so please everyone bear with
this repeat question.  Thanks for any help.

-Matt
-------
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 May 90 16:51:54 EDT
From:      Mary Byrne <mbyrne@BBN.COM>
To:        tcp-ip@nic.ddn.mil
Cc:        mbyrne@BBN.COM
Subject:   remove me please
Kindly remove me from the list.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 13:05:36 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!ark1!skister!tdrake@ucsd.edu  (Tim Drake - E41)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP for ROLM 1666, in Fortran ??
Keywords: 

     I am a member of a team seeking to find/make a TCP/IP implemen-
tation for a ROLM 1666 (mainly the FTP portion).  The only languages
available are assembly and FORTRAN.  We have a TCP/IP implementation
for a General Data MV20000 which has a similar OS and the same
controller board as the ROLM.  Unfortunately, this implementation is
written in C.  We will consider any alternative that will aid in the 
development/reuse of a TCP/IP package for a ROLM 1666.  

1)   Does a TCP/IP (at least the FTP portion) already exist for the ROLM
     1666?

2)   Is there a TCP/IP implementation already in FORTRAN (any flavor) for 
     any computer and OS?

3)   Are there any C to FORTRAN translators available?

4)   Does anybody have a C compiler front end that is suitable for a 
     plug-in code generator?

5)   Is there a generic C compiler (or C compiler writing system) that 
     accepts some sort of target computer description?

6)   Is there a near context-free grammar description available for C 
     that is suitable for YACC?

     Please respond to any of these questions if you can.   Thanks!


John J. Zaloudek
Naval Surface Warfare Center    Phone:    (703) 663-8547
Code N44                                  (DSN) 249-8547
Dahlgren, VA  22448             MILNET:   jzaloud@relay.nswc.navy.mil
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 14:12:00 GMT
From:      dangelo@whuts.att.com
To:        comp.protocols.tcp-ip
Subject:   remove name from list


Please remove my name from the mailing list.
Thank you.

Diana

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 14:20:20 GMT
From:      matrix!venkat@uunet.uu.net  (D Venkatrangan)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Urgent Mode.

I am looking for ways to determine where exactly in the sequence space
at the receive side, Urgent Data begins.  The RFC793 on Transmission Contol
Protocol does not appear to be very clear on this.

  TCP also provides a means to communicate to the receiver of data that
  at some point further along in the data stream than the receiver is
  currently reading there is urgent data.  TCP does not attempt to
  define what the user specifically does upon being notified of pending
  urgent data, but the general notion is that the receiving process will
  take action to process the urgent data quickly.

The above paragraph describes the general philosophy.

  Urgent Pointer:  16 bits

    This field communicates the current value of the urgent pointer as a
    positive offset from the sequence number in this segment.  The
    urgent pointer points to the sequence number of the octet following
    the urgent data.  This field is only be interpreted in segments with
    the URG control bit set.

Does this mean than Urgent Data starts at the beginning of this segment and
extends up to current segment's sequence number + urgent data pointer?

  The objective of the TCP urgent mechanism is to allow the sending user
  to stimulate the receiving user to accept some urgent data and to
  permit the receiving TCP to indicate to the receiving user when all
  the currently known urgent data has been received by the user.

  This mechanism permits a point in the data stream to be designated as
  the end of urgent information.  Whenever this point is in advance of
  the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
  must tell the user to go into "urgent mode"; when the receive sequence
  number catches up to the urgent pointer, the TCP must tell user to go
  into "normal mode".  If the urgent pointer is updated while the user
  is in "urgent mode", the update will be invisible to the user.

This again describes when "urgent mode" starts, but not where urgent data
starts.  Do users of TCP, such as Telnet, agree on how many bytes of urgent
data exist and thereby know the start of urgent data?

Is there an update to RFC793 since Sept. 1981 that describes changes if any
to the TCP urgent mechanism?

If one were to implement the TLI API on top of TCP and were to provide the

	t_rcv(fd, buf, nbytes, flagsp)

call, how would they be able to provide T_EXPEDITED data?  TLI appears to
treat normal and expedited data as two independent streams.

Thanks.
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 15:42:07 GMT
From:      fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net  (Kevin Paul Herbert)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for ROLM 1666, in Fortran ??
I suggest checking out use of gcc from project GNU - it is a portable C
compiler designed to be easy to retarget to different host
architectures. Check out the gnu.* newsgroups for more information.

Kevin
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 15:57:20 GMT
From:      bu.edu!bu-it!kwe@uunet.uu.net  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up [blitzkreig]
In article <9005240215.AA01426@psi.com>, 
  schoff@PSI.COM ("Martin Lee Schoffstall") writes:

> ...  That time may
> be now, and the PSI blitzkreig may descend.
> 

	Man the bunkers.
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 17:18:11 GMT
From:      rick@uunet.uu.net  (Rick Adams)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
There already exist several places that will let you have an account
that can send and receive Internet mail. They are not on the
Internet and have no need to be. (Portal and the World are two examples).

The major point of having dialup internet access is for people who
alerady have accounts on Internet machines and need to "call home".
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 18:01:42 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005240215.AA01426@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
> Some indviduals might posit that the model is exhausted and that
> national/international networks that have customers directly is the future
> for the Internet.

This, in fact, seems to be how many people (myself included) view things
even now.  In fact, several people at PSI are probably all too aware that
I'm interested in being a customer of the Internet as a whole, and am
not particularly interested in what PSI can do for me except in pursuit of
that goal :-).  Anyway...

I know that I tend to think of "the Internet" along the same
lines that I think of the interstate highway system.  I know that each
piece is maintained by its oown tax base and personnel, but each piece is
also part an overall system.  When I drive to NYC from DC, I think of it
as "getting on I-95 and heading north until I get to the George Washington
Bridge", not as getting on a series of "X Memorial Highways".  Likewise,
when I was at OSU and FTP'd something from Stanford, I thought of it as
"using the Internet", not "using ORnet and PSCnet and MERIT and BARRnet...".

And, just as I avoid taking toll roads unless I have to, I'd prefer to have
the underlying partitioning of the Internet to be as invisible as possible.

Where this analogy breaks down, of course, is that the interstates are a
public resource (despite their "official" designation as the Defense Highway
System), and the Internet is not.  On the other hand, the interstate system
shows that public access and subsidization is not necessarily a bad thing
either, even for a resource developed by the government.

--
Amanda Walker, InterCon Systems Corporation
--
"Go not to the elves for counsel, for they will say both no and yes."
	--J.R.R. Tolkien, The Lord of the Rings
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 18:34:36 GMT
From:      sdcc6!cerf.net@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005241412.AA08804@chiya.bellcore.com> tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya) writes:
>Since mail is one of the big uses of the Internet, do most people
>that subscribe to dial-up internet already have directly connected
>machines in other places at which they receive mail?  Or will
>someone start selling permantly attached accounts in addition to
>dial-up, so that one can retrieve their mail after they dial-up?
>
>PT

As I said earlier , if you can demonstrate that your use
of the Internet is bonafide , CERFNet will offer you a 
"permanently attached account" on one of our machines  .
Other than helping the "roamers" our intention is to provide 
a low cost service to people with no current Internet access.

In conjunction with our SLIP service, we
are working on providing mail services through POP
and alikes--- bringing the Internet to your portable PC.:-)

--pushpendra
CERFNet
(619) 534-5056  
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 19:10:10 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Dial up access to Internet facilities


I've always felt that the best solution to the dial-up access problem
was to make it easy for people to hook up their PC to your local Ethernet,
get a temporary IP address (via some address assignment protocol) and
voila, they are connected.  One could do similar things with a 
900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address,
you're off].

In other words, the key problem is making it easy for someone with a
PC to get a local IP address and do something.

Craig

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 19:10:58 GMT
From:      paperboy!meissner@think.com  (Michael Meissner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for ROLM 1666, in Fortran ??
In article <18329@hercules.csl.sri.com> kph@dirt.cisco.com (Kevin Paul
Herbert) writes:

| I suggest checking out use of gcc from project GNU - it is a portable C
| compiler designed to be easy to retarget to different host
| architectures. Check out the gnu.* newsgroups for more information.

Reality check time.

I believe that the ROLM 1666 computer is instruction compatible with
the DG MV/Eclipse computers.  I wrote the front end for the DG C
compiler on the MV/Eclipse computers, and then switched over to
working on GNU C for the 88k (and now MIPS + ns32k).  IMHO, it would
be a hericulean effort to port GCC to the MV architecture.

The biggest problem is that the MV has three types of pointers:

    *	bit pointers consisting of a word pointer in one register and
	a bit offset in another, or alternatively, the word pointer
	shifted left 4 bits + the bit offset in one register, which
	restricts the range pointed to;

    *	word pointers (words are 16 bits, but word pointers can also
	load 32 bits in one operation), which have three parts, an
	indirect bit (which isn't always used), a segment field
	(always 7 in normal user code), and the word offset.

    *	byte pointers, which is the word pointer shifted left one bit
	position (loosing the indirect bit), and the byte number
	within the 16-bit word in the least significant bit.

GCC firmly believes that there is only type of pointer (in fact, it
took somebody else a good month or two to just get the 88k compiler
running as a cross compiler on the MV, to straighten out the pointer
kinks in the compiler itself).  The internal language has no means of
expressing the different pointer types, so you would have to always
resprent things as byte pointers, and continually do word <-> byte
pointer conversions.

The second biggest problem is the lack of registers.  The machine only
has 4 integer registers and 4 floating point registers (the stack
registers are present in the machine, but you have to use explicit
instructions to move them to the integer registers to use them as
indexes, except directly after a SAVE).  I suspect that the GCC
algorithms will break down if confronted with so few registers.  The
registers are also not completely regular either -- memory references
involving word pointers can only be done from two registers, etc.

Finally, writing ANY new machine description for GCC is a #!$% of a
lot of work.  It was a year of my time before I felt the 88k port was
reliable, and I was starting from a 3/4 finished port done by a person
who had done 2 other GCC ports previously.

It might be easier, to poke around, and see if the object formats are
compatible and if so, cross develop on the MV.  Or write a translator
from the MV object format to the ROLM, if different.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 19:36:35 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!oss670!tkevans@tut.cis.ohio-state.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP for the MacIntosh?
My boss has just asked about putting Mac's on our TCP/IP Ethernet.  Since I'm
not a regular reader of the Mac groups, can someone give me an E-mail
yell and let me know what's available and what's required to 
implement it?  Thanks.

PLEASE:  Use the E-mail address BELOW, not the one above.
-- 
cc:Mail		Tim K. Evans at ~OSS
UUCP 		...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
INTERNET	tkevans%woodb@mimsy.umd.edu   PHONE:  (301) 965-3286
US MAIL		6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD  21235	
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      24 May 90 20:51:54 GMT
From:      mbyrne@BBN.COM (Mary Byrne)
To:        comp.protocols.tcp-ip
Subject:   remove me please

Kindly remove me from the list.

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 07:31:38 PDT (Friday)
From:      "Jeff_Lloyd.WGC1RX"@Xerox.COM
To:        mcsun!hp4nl!ncsbv!peter@uunet.uu.NET
Cc:        tcp-ip@nic.ddn.MIL
Subject:   Re: PC-LAN and TCP-IP
Peter,

	SCOs Open Desktop product (SCO UNIX 3.2 etc) is shipped with Lachmans'
TCP/IP support. This product supports a nice range of standard
(ish) ethernet cards PLUS Token Ring Boards.

The system (ODT-NET) supports TCP/IP, Streams and IBM Lan Manager
(NetBIOS) protocols. Therefore you can have all these from one ethernet
or Token Ring board !!.

Item 3. See Above.

Item 4 has many options, those that come to mind are,

	Sun's PC-NFS	-	Telnet, FTP et al,
				Ethernet only,
				NFS (Of Course) would work nice with
				Open Desktop (Is as NFS too !)
				Uses Loadsa RAM.

	FTP TCP/IP Package

	Excelan	-	Telnet, FTP etc.
	LAN-Workplace	Ethernet only (I Think)
	for DOS		NetBIOS Support
				IBM LAN Manager support
				can be used to mount PC-Net disks
				from ODT.
				Most of the TCP/IP protocol support is
				down loaded to their board, (it has a 80186)
				this frees up loadsa RAM.

	Many others I can't think of......

Hope this helps
-jeff

BTW:	I Don't work for sco :-) I just develop with ODT.
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Fri May 25 09:24:01 1990
From:      robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;)
To:        tcp-ip@nic.ddn.mil
Subject:   dial-up access to the Internet
It seems to me that the real question of dial-up access for the Internet
stems from folks who travel and need to "phone home".  The most obvious
solution is to have a dial-up modem on their "home" system and stay off
the Internet altogether.  That way, their home system does all the user
verification and auditing.

But that's not how the real world works - right?  I get a the willies about 
letting anyone dial up and get on the Internet without authentication and 
audit trail.  That would seem to invite abuse.  The open-door "guest" account 
is an invitation to disaster (or hassle, if the FBI asks why your system 
allowed the bad guy access to the Internet).  Unfortunately, all sites seem 
to have their share of traveling dignitaries who need to check their email 
in some other corner of the world.

To handle these, we set up a "guest" account which is password protected.
When a user logs into this account, they see a list of systems that they
can connect to.  When a travelling dignitary comes on base, our customer
support folks offer the courtesy of using the guest account, and provide
him with the current password (they also make sure the right "home system"
is currently on the menu).  After he leaves, they change the password on
the account.  No logins to this guest account are allowed over modem or
>from the Internet.  The user must be "on base" to use the account.  Not
only are we controlling guest access, but visitors are impressed by our
"thoughtfulness" in providing them with this "phone home" capability,
without them having to ask for it.

Bob Johnson
Tinker AFB
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 10:05:34 -0500
From:      Guy Almes <almes@rice.edu>
To:        robjohn@ocdis01.af.mil, tcp-ip@nic.ddn.mil
Subject:   Re: dial-up access to the Internet


robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) writes:<<
  But that's not how the real world works - right?  I get a the willies about 
  letting anyone dial up and get on the Internet without authentication and 
  audit trail.  That would seem to invite abuse.  The open-door "guest" account 
  is an invitation to disaster (or hassle, if the FBI asks why your system 
  allowed the bad guy access to the Internet).  Unfortunately, all sites seem 
  to have their share of traveling dignitaries who need to check their email 
  in some other corner of the world.
>>

Bob makes a good point which I'd like to strengthen.  The Federation of
American Research Networks (FARnet) has gone on record as urging its mid-level
networks and the campuses they serve to dis-allow any unauthenticated access
to the Internet.  Specifically, terminal servers that require no authentication
and then allow the caller full access to the Internet must be reconfigured to
either require authentication or to provide access only to a set of hosts on
campus that *do* require authentication.

I also like his later example of how to be both courteous and careful:<<
  To handle these, we set up a "guest" account which is password protected.
  When a user logs into this account, they see a list of systems that they
  can connect to.  When a travelling dignitary comes on base, our customer
  support folks offer the courtesy of using the guest account, and provide
  him with the current password (they also make sure the right "home system"
  is currently on the menu).  After he leaves, they change the password on
  the account.  No logins to this guest account are allowed over modem or
  >from the Internet.  The user must be "on base" to use the account.  Not
  only are we controlling guest access, but visitors are impressed by our
  "thoughtfulness" in providing them with this "phone home" capability,
  without them having to ask for it.
  
  Bob Johnson
  Tinker AFB
>>
This is one example, among many possibilities, of how to be responsible.
	-- Guy Almes

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 07:24:25 EDT
From:      rich@gateway.mitre.org
To:        tcp-ip@nic.ddn.mil
Subject: re: Dial up access to Internet facilities
Date: Thu, 24 May 90 15:10:10 -0400
From: Craig Partridge <craig@NNSC.NSF.NET>
Status: R

Craig Partridge writes...
> I've always felt that the best solution to the dial-up access problem
> was to make it easy for people to hook up their PC to your local Ethernet,
> get a temporary IP address (via some address assignment protocol) and
> voila, they are connected.  One could do similar things with a 
> 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address,
> you're off].

> In other words, the key problem is making it easy for someone with a
> PC to get a local IP address and do something.

> Craig

While at Unisys, myself and others developed and implemented a system that 
did exactly what Craig describes... 

A PC user could dial into a gateway that would give the PC a temporary IP address.
A protocol was also developed that would allow the PC user to update a
modified Domain Name Server with its temporary IP address so that other
hosts could initiate connections to the PC. 

An FTP user protocol, Telnet user protocol, and SMTP server protocol 
implementations were written to run on the PC.

The usefulness is that a user with a portable PC can dial into a 
system and his email would automatically be sent to the PC at the temporary
location.

More information on this system can be found in the conference record of
MILCOM '89, under "PHASE, A Portable Host Access System Environment".


Rich Verjinski           rich@gateway.mitre.org

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 10:35:42 PDT
From:      braden@venera.isi.edu
To:        matrix!venkat@uunet.uu.net, tcp-ip@nic.ddn.mil
Cc:        braden@venera.isi.edu
Subject:   Re:  TCP Urgent Mode.
	From tcp-ip-RELAY@NIC.DDN.MIL Fri May 25 01:59:41 1990
	Date: 24 May 90 14:20:20 GMT
	From: matrix!venkat@uunet.uu.net  (D Venkatrangan)
	Organization: Matrix Computer Systems, Nashua, NH
	Subject: TCP Urgent Mode.
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil


	I am looking for ways to determine where exactly in the sequence space
	at the receive side, Urgent Data begins.  The RFC793 on Transmission Contol
	Protocol does not appear to be very clear on this.

	  TCP also provides a means to communicate to the receiver of data that
	  at some point further along in the data stream than the receiver is
	  currently reading there is urgent data.  TCP does not attempt to
	  define what the user specifically does upon being notified of pending
	  urgent data, but the general notion is that the receiving process will
	  take action to process the urgent data quickly.

	The above paragraph describes the general philosophy.

	  Urgent Pointer:  16 bits

	    This field communicates the current value of the urgent pointer as a
	    positive offset from the sequence number in this segment.  The
	    urgent pointer points to the sequence number of the octet following
	    the urgent data.  This field is only be interpreted in segments with
	    the URG control bit set.

	Does this mean than Urgent Data starts at the beginning of this segment and
	extends up to current segment's sequence number + urgent data pointer?

Yes.  Up to, but not including.  See RFC-1122 p. 84 for more info.


	This again describes when "urgent mode" starts, but not where urgent data
	starts.  Do users of TCP, such as Telnet, agree on how many bytes of urgent
	data exist and thereby know the start of urgent data?

Urgent data starts as soon as an Urgent Ptr appears.

	Is there an update to RFC793 since Sept. 1981 that describes changes if any
	to the TCP urgent mechanism?

	If one were to implement the TLI API on top of TCP and were to provide the

		t_rcv(fd, buf, nbytes, flagsp)

	call, how would they be able to provide T_EXPEDITED data?  TLI appears to
	treat normal and expedited data as two independent streams.

	Thanks.

It's not clear you can map TCP urgent into a user interface that has
two independent streams.  The essential piece of information that the
receiving application has to be able to get is: How many bytes of
urgent data remain to be read?  As long as the answer is non-zero,
the application has to be in "urgent mode"; when the result reaches
zero, normal mode resumes.

Bob Braden

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 10:27 EST
From:      <MLEVIN%TUFTS.BITNET@mitvma.mit.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   multinet problem
We (Tufts U) have an Encore running Umax 4.2 on a network with
a VAX running VMS. The vax has the multinet package, and
I was trying the ttcp.c program supplied in [multinet.examples].
It seems that the only way it works with the sender on VMS
and the reciever on the UMAX system is with the -u option (using
datagrams, instead of SOCK_STREAM). Why? Is there any way to
get it to use the stream protocol? I note that it works fine
without the -u when the vax program recieves, and the Umax sends.
It also works fine when both modules are run on VMS machines.
Any ideas?
                                      Mike Levin
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 10:29:53 EDT
From:      rich@gateway.mitre.org (Richard Verjinski)
To:        tcp-ip@nic.ddn.mil


Craig Partridge writes...
> I've always felt that the best solution to the dial-up access problem
> was to make it easy for people to hook up their PC to your local Ethernet,
> get a temporary IP address (via some address assignment protocol) and
> voila, they are connected.  One could do similar things with a 
> 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address,
> you're off].

> In other words, the key problem is making it easy for someone with a
> PC to get a local IP address and do something.

> Craig

While at Unisys, myself and others developed and implemented a system that 
did exactly what Craig describes... 

****
I feel it necessary to publicly acknowledge the persons
described as "others" in the above statement.

Those people are:  John Swanson, Jose Rodrigues, Jim O'Conner,
                   and Ed Yancy. 
I apologize for not mentioning each person explicitly.

Rich Verjinski          

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 08:32:32 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <9005231723.AA20278@hp-ses.sde.hp.com> wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes:
>HP does exactly the same thing.  I think of it as similar to
>international borders.[...]

That's not a bad analogy, because I absolutely detest having to deal with
customs stations. And I certainly don't depend on US customs to protect my
house (or computer) from being burglarized.

My personal favorite analogy is the Berlin Wall. Shortly after the wall was
opened some East German official was quoted by the AP as saying that the
wall as a whole would stay up because it was "necessary to protect East
Germans against AIDS", among other things.  Unfortunately, this kind of
thinking is not unheard of in the computer security business.

Once again, I argue that there is no substitute for each individual taking
the responsibility for protecting his own local domain. Security mechanisms
are always most effectively implemented as close as possible to whatever
is being protected.

Phil
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 15:38:54 pdt
From:      Walter Underwood <wunder@hpsdel.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: Wither Ethernet?
If find it really amusing that the vendor independent standard, IEEE
802, is mostly used for proprietary protocols (HP, IBM, and Apple),
while the proprietary standard, Ethernet (remember DEC, Intel, and
Xerox?)  carries all the multi-vendor protocols.

Just goes to show that you can't judge a standard by its cover.

wunder

PS:  Nearly all HP equipment can talk Ethernet and ARP these days.
Only one OS, MPE/XL, is still 802-only, and Ethernet is scheduled
for release on that, too.
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 12:51:54 EDT
From:      stine@sparta.com (Robert Havens Stine)
To:        AFDDN.JONSON@GUNTER-ADAM.AF.MIL, tcp-ip@nic.ddn.mil
Subject:   Re:  Netwatch ???
According to RFC 1147, netwatch is:

               Available as a utility program in the pcip distribution
               from host husc6.harvard.edu, in directory pub/pcip.
               Available in a standalone package via anonymous FTP
               from windom.ucar.edu, in file pc/network/netwatch.arc;
               a binary "dearc" program is also available from
               windom.ucar.edu.

Cheers,

Bob Stine
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 17:28:54 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '90 Information

Hi folks:

Postscript copies of the SIGCOMM '90 Program and Registration form can 
FTPed at the following location:

    nnsc.nsf.net:CCR/sigcomm90-prog.ps 
    nnsc.nsf.net:CCR/sigcomm90-reg.ps

For those of you who don't have FTP access or prefer plain text, please
be patient -- plain text copies of the registration materials will be
e-mailed out sometime next week.

Craig

PS: Please note, the SIGCOMM '90 phone number and e-mail address may work
until June 1st.
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 11:22:22 GMT
From:      psuvm!pmw1@cunyvm.cuny.edu  (Peter Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Anonymous FTP case sensitivity
Being an Anonymous FTP neophite, I discovered at least one host
that was case sensitive to the userid _anonymous_.  Is this standard
practice?

/Pete
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 12:48:54 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!roy@ucsd.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none)
In <9005251124.AA00811@mercury.mitre.org> rich@GATEWAY.MITRE.ORG writes:
> A PC user could dial into a gateway that would give the PC a temporary IP
> address.  A protocol was also developed that would allow the PC user to
> update a modified Domain Name Server with its temporary IP address so
> that other hosts could initiate connections to the PC.

	One could set up a Shiva NetModem in dial-in-network-access mode on
an AppleTalk net behind a FastPath running KIP and then anybody with a Mac
could do exactly that.  KIP hands out IP addresses from a pool on a dynamic
basis and all you need at the remote end is a Mac, any of a number of
commercial or free IP packages, and a regular 1200/2400/9600 bps modem.
The only thing missing is the automatic updating of DNS, but if your intent
is to just let the roming user get his/her mail, all you need is an account
on a POP server and DNS doesn't have to know anything.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 15:27:00 GMT
From:      MLEVIN@TUFTS.BITNET
To:        comp.protocols.tcp-ip
Subject:   multinet problem

We (Tufts U) have an Encore running Umax 4.2 on a network with
a VAX running VMS. The vax has the multinet package, and
I was trying the ttcp.c program supplied in [multinet.examples].
It seems that the only way it works with the sender on VMS
and the reciever on the UMAX system is with the -u option (using
datagrams, instead of SOCK_STREAM). Why? Is there any way to
get it to use the stream protocol? I note that it works fine
without the -u when the vax program recieves, and the Umax sends.
It also works fine when both modules are run on VMS machines.
Any ideas?
                                      Mike Levin

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 15:58:40 GMT
From:      silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 daemon?
Does anyone know of a tn3270 daemon, somewhat of a hybrid between
telnetd and (reverse) tn3270?  I'm fairly certain there's no such
animal, but if there is we'd have a good use for it.

Please respond via email...thanks in advance.

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||        hughes@ucs.indiana.edu        ||
||        Indiana University         ||                                      ||
||   University Computing Services   ||   "The person who knows everything   ||
||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
||      Bloomington, IN  47405       ||                                      ||
||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
 \\==========================================================================//
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 16:35:28 GMT
From:      ameristar!rick@sbcs.sunysb.edu  (Rick Spanbauer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>> Thus, I
>> applaud the efforts of CERFnet and UUNET to offer authenticated,
>> for-fee access to Internet as a whole.  I can guarantee that I'll
>> be interested in using their services whereas Marty's (if I understand
>> him correctly) just looks like an interesting service.
>
>You don't understand me correctly.  Essentially we've been waiting
>for the time that a prescedent is set, permission is granted, or
>a consensus may be achievable in the Internet community.  That time may
>be now, and the PSI blitzkreig may descend.

	The plight of many small technical businesses is that we just cannot 
	justify spending $30K+ for access into the Internet for the occasional 
	FTP/smtp transfer.  Were access fees brought inline with the level of 
	service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI 
	and other regionals would see their business pick up substantially.  

	Note that it isn't small business alone that has a problem with
	the high connection costs to the Internet.  Ameristar sells IP/TCP
	network products and every once in a while I ask some of our larger 
	customers ($20M & up) why they are not on the Internet.  The answer is 
	usually that the perceived value of the connection is not in line with 
	the yearly access fee.  In such cases, a low cost dialup SLIP service 
	would go a long way in giving people a chance to experiment with 
	Internet access to evaluate its usefullness to their organization.  
	Dialup SLIP is also a safe way for the regionals to toy with their 
	price/volume curve without having to add infastructure (ie additional 
	or higher capacity links) at the outset of the experiment.  

	One other suggestion I have is that the regionals ought to survey 
	potential customers about the sort of connectivity and services they 
	would purchase as a function of cost.  Good starting sample data sets 
	might be the lists of technical companies that local business 
	organizations or government maintains, or even UUCP maps.

>I'll of course let you know in the least crass commercial manner that
>I can, if it is of interest.....

	Please do make an announcement of any new services PSI introduces.  I 
	for one would like to hear what PSI is doing to moderate access fees 
	without having to ping your sales organization every few months.  

>Marty

					Rick Spanbauer
					Ameristar Technology

Usual disclaimers: my opinions are my own, etc.
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 18:05:51 GMT
From:      zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrdvm1!hathawa@tut.cis.ohio-state.edu  (Barry Hathaway)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tn3270 daemon?
In article <45793@iuvax.cs.indiana.edu>, hughes@silver.ucs.indiana.edu (larry
hughes) says:
>
>Does anyone know of a tn3270 daemon, somewhat of a hybrid between
>telnetd and (reverse) tn3270?  I'm fairly certain there's no such
>animal, but if there is we'd have a good use for it.
>
Many TCP/IP packages for IBM mainframes offer terminal emulation on the host
side - which I guess could be called a tn3270 daemon. Fibronics (aka Sparticus)
KNET package has this as an option.  Simware offers SIM/TCPIP an add-on to
IBM's TCP/IP package which does terminal emulation.
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 18:25:03 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Urgent Mode.
>If one were to implement the TLI API on top of TCP and were to provide the
>
>	t_rcv(fd, buf, nbytes, flagsp)
>
>call, how would they be able to provide T_EXPEDITED data?

TCP doesn't really have expedited data in the same way that, say, TP4
does; it has an urgent pointer.

>TLI appears to treat normal and expedited data as two independent streams.

Yup.  S5R4's streams code implements the notion of a "marked" message
for precisely that reason; that's how it handles the urgent pointer.  It
may also support the notion that the last byte of urgent data is treated
as expedited data, as per, say, 4.2BSD, and 4.3BSD when SO_OOBINLINE
isn't set.
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 19:33:22 GMT
From:      usc!samsung!dali!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!aero!aerospace.aero.org!obrien@ucsd.edu  (Michael O'Brien)
To:        tcp-ip@nic.ddn.mil
Subject:   IP/TCP/UDP benchmarks?
Some folks around here have to benchmark a number of different boxes,
and they've asked me to help with the part that benchmarks TCP/IP and
UDP performance.  Before I go off developing wheels, I'd like to know of
any prior art.  I already know about "ttcp.c" on brl.mil.  Is there
any other IP/TCP/UDP benchmarking software out there?

As always, please respond by email and I'll summarize if there's interest.
--
Mike O'Brien
obrien@aerospace.aero.org
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 20:53:09 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Wither Ethernet?

In article <9005211233.AA15946@gateway.mitre.org>, hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes:
> It has been suggested by some standards gurus that in the future
> all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead
> (or possibly dying)  protocol.

I've never been a worshipper of ``standards'' that try to impose rather
than describe.  802.3 would seem to me to meet that criterion, I'm
afraid.

At least in the TCP/IP world, I don't see that much movement to
802.3 (and away from Ethernet) simply because there's no compelling
reason to.  The current technology is here, it works, and it's
compatible with (almost) everyone else.  I'm sure folks will correct
me if I'm wrong, but I thought that HP was the only major vendor
to try to use 802.3 encapsulation for IP over Ethernet, and that
a few others (i.e., Cisco) would accomdate them, mostly for
compatibility.  Furthermore, as a result, it was hard to talk
to some HP machines.

The 802.3 format -- and in particular the 802.2 goo you're supposed to
use -- makes sense if you're trying to do routing at that layer.
In ``our'' world, there's a better, more flexible way to do routing,
and that's at the IP layer.  So why switch?

The situation is different for other media.  Token ring is inhabited
by bluish PCs, and FDDI was decreed from the outset to use 802.2.
For those, a simpler (or at least different) encapsulation has never
had a chance to take hold.  Thus, 802.2 will rule, even for IP.

The higher levels? I'm *not* going to start another TCP/IP vs OSI flamefest
here today...

		--Steve Bellovin

P.S.  I don't have a very good track record as a prophet; beware...

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 21:04:45 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: A SUSPICIOUS SECURE GATEWAY

In article <9005231723.AA20278@hp-ses.sde.hp.com>, wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes:
> HP does exactly the same thing.

And Bell Labs goes even farther; we have just 2 non-isolated machines
on the Internet.  Application-level gateways do the rest.

Why?  Because in the Real World (whatever that is), our machines are
not secure enough today.  Blame complacent vendors, blame lazy
administrators, blame careless users -- it doesn't matter much,
since the empirical fact remains:  a very significant fraction
of hosts (and not just ours, I might add) are vulnerable.  We,
as a corporation, have chosen not to take the risk of exposure.
Total isolation would be a serious problem; as is, most of what
most people need to do on the Internet -- mail, FTP out, telnet
both ways -- can be handled in a safer fashion.  And most of
the exceptions can be dealt with in other ways -- we do have
a few more hosts that are directly connected to the Internet,
but they're used for special purposes, and don't talk to anything
else internally; they're dead ends.

In the abstract, I mostly agree with Phil Karn -- hosts should
be able to protect themselves.  In fact, I spend a lot of my
time working on mechanisms to help that cause.  In practice,
neither he nor I can administer every machine in our respective
companies.  I'll quote Phil's own article:

	The hard problem, as it turns out, lies not in generating a
	list of vulnerable systems, but in getting the administrators
	of those machines to update their software or to fix their
	system configurations.

It's not a technical problem, but it's very real.  And, given rlogin
and its friends, if one host falls, a lot more will fall with it.

Incidentally, I say ``mostly'' because there's an important class of
device -- dial-out modems -- that is not capable of security today, and
is not likely to be in the forseeable future.  Finding a dialer pool on
the Internet would be a hacker's idea of heaven.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 21:28:54 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '90 Information


Hi folks:

Postscript copies of the SIGCOMM '90 Program and Registration form can 
FTPed at the following location:

    nnsc.nsf.net:CCR/sigcomm90-prog.ps 
    nnsc.nsf.net:CCR/sigcomm90-reg.ps

For those of you who don't have FTP access or prefer plain text, please
be patient -- plain text copies of the registration materials will be
e-mailed out sometime next week.

Craig

PS: Please note, the SIGCOMM '90 phone number and e-mail address may work
until June 1st.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      25 May 90 23:25:56 GMT
From:      van-bc!sl@ucbvax.Berkeley.EDU  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <1990May25.163528.14300@ameristar> rick@ameristar (Rick Spanbauer) writes:
>In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
}	The plight of many small technical businesses is that we just cannot 
}	justify spending $30K+ for access into the Internet for the occasional 
}	FTP/smtp transfer.  Were access fees brought inline with the level of 
}	service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI 
}	and other regionals would see their business pick up substantially.  

van-bc has a dialup SLIP link (9600 bps) into BCNet and it works quite well. 
It's low cost, but effective for an NNTP news feed, mail and the occasion FTP.

We have configured the modems (T2500's in V.32 mode) to auto-dial our private 
phone number on DTR. Every ten minutes we run a script which tests if the link 
is alive. If not we turn it off and on again. This drops the line and redials 
it. 

Works fairly reliably, and the cost is low. Now that we have it we couldn't
do without it.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 May 90 02:14:51 GMT
From:      amelia!orville.nas.nasa.gov!jmccabe@ames.arc.nasa.gov  (James D. McCabe)
To:        tcp-ip@nic.ddn.mil
Subject:   Please help! - History of Networking

I have been tasked to develop a "History of Networking" document that
describes (in gory detail) the significant events of the networking world
since the Big Bang.  I would appreciate any pointers to good historical
literature (besides IEEE journals) about networking hardware and protocols.  
Please send e-mail responses to my address.  Thanks.

Jim D. McCabe
Numerical Aerodynamic Simulation (NAS) Program
NASA/Ames Research Center
jmccabe@nas.nasa.gov
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 May 90 23:00 +0200 (NBI, Copenhagen)
From:      ALLAN ENGELHARDT <ENGELHARDT%nbivax.nbi.dk@CORNELLC.cit.cornell.edu>
To:        TCP-IP@NIC.DDN.mil
Subject:   Will *somebody* PLEASE remove me from this list.
                                                    Copenhagen, 25-MAY-1990

HELP. I did an UNSUB * (NETWIDE and it worked on every other list than
this. Will somebody please delete me from this list?

                                   Allan Engelhardt

Internet:       ENGELHARDT@nbivax.nbi.dk  (nbivax.nbi.dk=129.142.100.3)
HEPnet:         NBIVAX::ENGELHARDT        (NBIVAX=21.106=22105)
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 May 90 10:11:49 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   re: SIGCOMM '90 Information

Hi folks:

    Despite proof reading twice, my little note had an error.

    The SIGCOMM '90 e-mail address and phone number may NOT work until
June 1st (In other words, after June 1 you can expect them to be up and
running).

    My apologies to the University of Pennsylvania people who are working
hard to set up the phone line and e-mail address.

Craig
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 May 90 10:12:52 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:   Netwatch ???
And while we are on the subject, I have heard there is a version of
NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec.
Does anyone have any idea where I might find an EXE for this vesion??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 May 90 14:11:49 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: SIGCOMM '90 Information


Hi folks:

    Despite proof reading twice, my little note had an error.

    The SIGCOMM '90 e-mail address and phone number may NOT work until
June 1st (In other words, after June 1 you can expect them to be up and
running).

    My apologies to the University of Pennsylvania people who are working
hard to set up the phone line and e-mail address.

Craig

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 May 90 15:12:52 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re:   Netwatch ???

And while we are on the subject, I have heard there is a version of
NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec.
Does anyone have any idea where I might find an EXE for this vesion??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 May 90 00:23:12 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        ameristar!rick@sbcs.sunysb.edu (Rick Spanbauer)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
Rick,

Someday I hope to meet you.....  5 years of private and public email
and our paths haven't crossed yet, just swords....    :-)

 	The plight of many small technical businesses is that we just cannot 
 	justify spending $30K+ for access into the Internet for the occasional 
 	FTP/smtp transfer.  Were access fees brought inline with the level of 
 	service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI
 	and other regionals would see their business pick up substantially.  

Aside for PSI/PSINet not being a regional, (think about th N word), I think most
of us have recognized an entry level market. There must be half a dozen
providers who have something that looks like ~$10K with dedicated facilities.
One of the issues on the dialup front is that a major cost is hidden, the
message units that all businesses have to pay.  In many LATA's a 4wire
unconditioned analog circuit costs $100/mo, the cross over point where
the message units are more expensive is probably not too many of the
3 hour periods described below.

Somehow dialup Internet access and SMTP don't go hand and hand in my mind,
my estimate is that your going to have keep a connection open for about 3 hours
every day to have some probablity of synchronizing with all the SMTP
agents pushing mail out of their queues for the site.  Realistically you'll
be running uucp/tcp to a site like UUPSI who is MX'ing for your domain.

 	Note that it isn't small business alone that has a problem with
 	the high connection costs to the Internet.  Ameristar sells IP/TCP
 	network products and every once in a while I ask some of our larger 
 	customers ($20M & up) why they are not on the Internet.  The answer is 
 	usually that the perceived value of the connection is not in line with 
 	the yearly access fee.  In such cases, a low cost dialup SLIP service 
 	would go a long way in giving people a chance to experiment with 
 	Internet access to evaluate its usefullness to their organization.  
 	Dialup SLIP is also a safe way for the regionals to toy with their 
 	price/volume curve without having to add infastructure (ie additional 
 	or higher capacity links) at the outset of the experiment.  

At least you could talk them into getting a good quality UUCP connection
so they can do email.  I'm frightened by the lack of participation of
many vertical industries in communicating with their customers, suppliers,
except through phones. (Have you ever entered voice mail grid lock, where
neither party ever gets through due to synchronization problems, and
the use of voice mail systems as filtering devices.  Someday the only
time you'll ever get an answer is by dialing 1-900.lovenow).

 	One other suggestion I have is that the regionals ought to survey 
 	potential customers about the sort of connectivity and services they 
 	would purchase as a function of cost.  Good starting sample data sets 
 	might be the lists of technical companies that local business 
 	organizations or government maintains, or even UUCP maps.

This has been done, but your sampling focus is a good suggestion.

 	Please do make an announcement of any new services PSI introduces.  I 
 	for one would like to hear what PSI is doing to moderate access fees 
 	without having to ping your sales organization every few months.  

Maybe Kent England will radio you in reports from "The Front", rumored
to have been named "Operation Fortress Beantown", BarHarborAirlines has
guaranteed that they can airlift as many cisco's as they will need to
sustain the battle.  :-)

Marty
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      26 May 90 18:59:41 GMT
From:      swrinde!cs.utexas.edu!mailrus!b-tech!zeeff@ucsd.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
>not secure enough today.  Blame complacent vendors, blame lazy
>administrators, blame careless users -- it doesn't matter much,
>since the empirical fact remains:  a very significant fraction

While it may not matter when deciding to use a "secure" gateway, the cause
matters very much when you go to fix the problems (which I hope you are
still doing).

It doesn't inspire confidence  - even AT&T can't make a Unix they trust.

>Incidentally, I say ``mostly'' because there's an important class of
>device -- dial-out modems -- that is not capable of security today, and
>is not likely to be in the forseeable future.  Finding a dialer pool on

There are these $100 toll restrictors (a little box) that help quite a bit.

-- 
Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      26 May 90 19:47:13 GMT
From:      netnews.upenn.edu!pcpond.cis.upenn.edu!farber@rutgers.edu  (David J. Farber)
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM90 email is operational since 25 May


The email query address is available as of this time. Send any requests etc
to:

	sigcomm90@cis.upenn.edu

Dave

David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele:
215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293;  Cellular:  302-740-
1198 "The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment." -- R. P. Feynman
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      27 May 90 00:41:49 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: A SUSPICIOUS SECURE GATEWAY

In article <46F%_++@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
> It doesn't inspire confidence  - even AT&T can't make a Unix they trust.

AT&T is not a homogeneous place -- for example, we have a lot of Sun
workstations.  (Remember the joint development deal, if nothing else.)
We have an OEM agreement with Pyramid.  We buy other machines for other
reasons.  And the best system in the world can be totally hosed by an
incompetent administrator.  And even on 6386s or 3B2s with good administrators,
sometimes a machine *must* run back releases of the software, with known
bugs not yet fixed.

> >Incidentally, I say ``mostly'' because there's an important class of
> >device -- dial-out modems -- that is not capable of security today, and
> >is not likely to be in the forseeable future.  Finding a dialer pool on
> 
> There are these $100 toll restrictors (a little box) that help quite a bit.

No, they don't.  Why should we prevent ourselves from making long-distance
calls?  We have dial-out modems because we need them and use them, and
often -- generally? -- not for local use.  To give an important case in
point, there's an AT&T office in Tokyo; we call it often via uucp.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 May 90 01:25:50 GMT
From:      attcan!utgpu!utzoo!henry@uunet.uu.net  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
In article <46F%_++@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>It doesn't inspire confidence  - even AT&T can't make a Unix they trust.

More precisely, they can't make a Unix that they can trust when it is
administered by incompetents.  Nobody else can make such a system either.
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      27 May 90 04:03:30 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!rpi!image.soe.clarkson.edu!news@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Netwatch ???
In article <9005262224.AA16033@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:

   And while we are on the subject, I have heard there is a version of
   NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec.
   Does anyone have any idea where I might find an EXE for this vesion??

FTP to sun.soe.clarkson.edu:/pub/ka9q/pcippkt.arc.  Or call (315)268-6667,
log in, change to the TCP/IP area, and download pcippkt.arc

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sun May 27 20:52:36 1990
From:      robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;)
To:        tcp-ip@nic.ddn.mil
Subject:   toll restrictors
There are software products on the market which allow the system administrator 
to automate and control connections to other systems.  We use a product that
automates phone, network and direct connections, and restricts access to 
specified users or groups of users.  The user picks the system they want from 
a menu, and the software handles the connection automatically.  A few seconds 
later, they see the banner and login prompt of the system they wanted to use.

There are two drawbacks.  The administrator must set up access to new systems 
as needed, and must turn off other avenues such as tip, cu, and telnet.   The
product we use replaces telnet, but does not yet replace ftp.  We have limited
ftp access to a specified group of users, and we log their usage.  At our 
site, the advantages far outweigh the disadvantages - simpler for the user, 
less user training/support, and a full audit trail of outbound connections
made from our system.

As background info, we have nearly 1500 users, about 550 people use the system 
each day, and several dozen use our system as a gateway to others.  We plan on
doubling this usage within a year.  We have a Class A Internet address, a
Class C Ethernet connection, outbound modems, and connection to several other
systems through a base-wide broadband LAN.  The product we use allows us to
provide better service to our user community, reduce our training and support 
burden, and provide accountability and auditability.

Bob Johnson, System Administrator
Tinker Air Force Base, Oklahoma
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 May 90 21:01:15 GMT
From:      mailrus!b-tech!zeeff@tut.cis.ohio-state.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
>> There are these $100 toll restrictors (a little box) that help quite a bit.
>
>No, they don't.  Why should we prevent ourselves from making long-distance
>calls?  We have dial-out modems because we need them and use them, and

They don't prevent long distance calls - you just have to program in the 
numbers that are allowed.  Even so, I will admit that that aren't suitable for
all situations.

-- 
Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 May 90 21:58:07 GMT
From:      bbn.com!wbe@apple.com  (Winston Edmond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <90121@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:
>UUNET plans to offer access to any Internet site from any Compuserve Dialup
>in the continental US.

>All access will require an individual login/password for accountability and
>authorization to use the Internet will be verified before the account is
>established.

>We plan to charge $5 per connect hour (in increments of 1 minute).

   Would UUNET be a CompuServe service provider, charging a $5/hr. surcharge,
or are you talking about using the CompuServe network and somehow bypassing
logging in to CompuServe itself?  Is the individual login/password the usual
CompuServe user number and password, or a UUNET login?

>We could start tomorrow if I could figure out how to bill for it.
>Its not worth sending out invoices for only $5.

   There are a number of CompuServe service providers that collect surcharges
directly from CompuServe -- the user gets a single bill, and CompuServe's
billing system keeps track of the surcharges in case the user has questions
about his bill.  This allows a service provider to charge small amounts, like
the $.02 stock quote charge, or the $.90 car profile charge, and still be
able to make money -- you don't have to bill the customer yourself.
 -WBE
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 May 90 10:37:16 -0400 (EDT)
From:      Michael Ginsberg <mg32+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil, Outbound News <outnews+netnews.comp.protocols.tcp-ip@andrew.cmu.edu>, Outbound News <outnews+netnews.comp.unix.questions@andrew.cmu.edu>, Outbound News <outnews+netnews.comp.unix.wizards@andrew.cmu.edu>
Subject:   SLIP - Serial Line Internet Protocol
I would like to be able to transfer data from a networked unix machine to a
portable computer which cannot be put on the network.  Both machines do have
serial ports, and it was suggested that I look into SLIP, the Serial Line
Internet Protocol.  However, I have been very unsucccessful in tracking down
information on how I can go about using SLIP.  Can someone please tell mewhat
I must do to use SLIP?  Is there public domain software out there?  Is it part
of the system already?  Thanks alot for any useful information/pointers.
Please respond via email as I don't read this board.  If there is any/enough
response, I will post a summary.

--Michael Ginsberg, i386 Mach Group, School of Computer Science
Carnegie Mellon University, Pittsburgh, Pennsylvania, USA

---------------------------------------------------------------------------
ARPA:   mg32+@andrew.cmu.edu             |Electrocution, n:
BITNET: mg32@cmccvb                      |    Burning at the stake with
UUCP:   ...!harvard!andrew.cmu.edu!mg32+ |    all the modern improvements.
---------------------------------------------------------------------------

Sex is not the answer.  Sex is the question.  Yes is the answer.
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      28 May 90 17:43:47 GMT
From:      bronze.ucs.indiana.edu!mckimg@iuvax.cs.indiana.edu  (geoffrey mckim)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

>In article <NELSON.90May21230840@image.clarkson.edu>,
>nelson@sun.soe.clarkson.edu (Russ Nelson) says:
>>That's too bad, because when I've gone travelling in the past, I've called
>>the local university, asked for their terminal server's phone number, and
>>telnetted back to Clarkson to check my mail.  It's a shame that that kind
>>of service has to go away...
>
>Actually, you can still check your mail, but for the price of a toll call
>back to your own terminal server.
>
>Maybe this is the price we have to pay for added security?
>
>/Pete
>--
>Peter M. Weiss   


I don't mean to flame but... Obviously one of the primary benefits of something
like the Internet is fast, efficient connections around the world.  Sure, 
if we wanted to, we could all just have cheapo 1200 baud modems on our desks
and dial up whatever machine we want to directly.  But that sort of defeats
the purpose of a high-speed network.

In other words, the easiest way to improve security is to simply disconnect 
all the machines on the network from all others.  But then we've got no 
network eh?  I'm afraid that knee-jerk reactions have long been the hallmark
of those in charge of computer security.  I realize that it will always be 
difficult to balance functionality and security, but I also hope that people
realize that the reason for the network's existence is FUNCTIONALITY.  I for 
one will certainly work to fight the elimination of dial-up terminal servers
connected to the internet.  Let's make our hosts more secure and not 
intentionally cripple the internet.


Geoffrey McKim				*** Standard disclaimers apply ***
Indiana University
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 11:54:56 -0700
From:      chris@salt.acc.com (Chris VandenBerg)
To:        tcp-ip@nic.ddn.mil
Subject:   HPLaserJet Ethernet board?
Good morning all,
		I was asked a question this morning about whether you could
hook an HPLaserJet printer directly onto an Ethernet without using a terminal
server port. I seem to remember hearing that someomne made a card that fit
into the expansion slot that had an Ethernet connector and TCP/IP software righton it. Does anyone else know anything about this type of setup or am I sufferingillusions of connectivity? (:*)
		Thanks in advance,
		Chris VandenBerg ACC (chris@salt.acc.com) 805-963-9431
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 10:05:26 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '90 Advance Program [Text]




                       SIGCOMM '90 - General Information


      SIGCOMM is the annual conference of the ACM Special Interest  Group
      in  Computer Communication.  This year's conference will be held at
      the University City Sheraton Hotel in  Philadelphia,  Pennsylvania,
      September  24-27th.  This program contains the advance schedule for
      the conference, registration information,  and  hotel  information.
      If  you  have  any  questions, feel free to contact the SIGCOMM '90
      conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu.


      SIGCOMM Conference Committee
           General Chair: Prof. David J. Farber (Univ. Pennsylvania)
           Program Chair: Phil Karn (Bellcore)
           Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania)
           Local Arrangements: Dan Finnigan (Univ. Pennsylvania)
           Publicity Chair: Craig Partridge (Bolt Beranek and Newman)
           Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris
             Edmondson-Yurkanan (Univ. Texas), Dr. Vint Cerf (CNRI)

      SIGCOMM Program Committee
      Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf  (CNRI),
      Doug  Comer  (Purdue),  Jon  Crowcroft (Univ. College London), Gary
      Delp (IBM), John Demco (CDNnet),  Magda  El-Zarki  (Univ.  Pennsyl-
      vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ.
      Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington  Univ.
      St.  Louis),  Larry L. Peterson (Univ. Arizona), Steve Pink (SICS),
      Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ.
      Pennsylvania)



                   Tutorials: September 24th [9 AM to 5 PM]

      Tutorial #1: Protocols for High-Speed Networks
      Instructors: Harry Rudin and Van Jacobson

      Part A: High-Performance, Transport-Level Protocols (Rudin)

      Made possible by progress in  fiber-optic  and  VLSI  technologies,
      networks  offering  increasing  transmission capacity at decreasing
      error rates are becoming available.  New applications would benefit
      from this bandwidth but software protocol processing rates have not
      kept up with available raw transmission speed.  The presentation is
      a  comparative  survey of techniques used at the transport layer in
      eight representative protocols, most  of  which  were  designed  to
      improve  the  protocol  processing  rate.   The  protocols  are the
      relevant portions of the APPN, Datakit, Delta-t,  NETBLT,  OSI/TP4,
      TCP,  VMTP, and XTP architectures.  The main functions covered are:
      connection management, acknowledgements, flow  control,  and  error
      handling.

      Part B: Efficient TCP Implementation (Jacobson)

      Network protocol processing time has long been viewed as THE deter-
      miner  of  perceived  network  performance.   For at least one well
      known suite, the TCP and IP Internet protocols, recent  measurement
      has  shown  this  view  to be false:  The protocol *implementation*
      affects perceived performance, as does the way in which the network
      interface hardware interacts with the entire software/hardware sys-
      tem it is a part of.   But there is no inherent  performance  limit
      in  the TCP/IP protocols themselves.  In fact, a Unix TCP/IP imple-
      mentation has been constructed  that  runs  at  a  essentially  the
      information-theoretic  minimum  time  for  the  the  problem  being
      solved.
      This tutorial will describe an efficient TCP/IP  implementation  in
      agonizing  detail.   It  will describe where time goes in a typical
      implementation and what can be done  in  the  protocol  and  system
      software  to  reclaim  that  time.  It will discuss how the network
      interface hardware affects processing time and what hardware archi-
      tectures lead to cheap, efficient processing.
      Familiarity  with  the  TCP  and  IP  protocols  will  be  assumed.
      Although the implementation described will be based on a real, pro-
      duction, Berkeley Unix TCP/IP, no Unix  kernel  expertise  will  be
      assumed,  only  familiarity with operating system issues and imple-
      mentations.

      Harry Rudin received the B.E. and D.Eng. degrees from Yale  Univer-
      sity, where he also taught until 1964.  He worked at Bell Telephone
      Laboratories in the area of data communications until 1968.   Since
      then  he has been doing research in computer communications systems
      at the  Zurich  Research  Laboratory,  IBM  Research  Division,  in
      Rueschlikon,  Switzerland.   His interests are high-speed protocols
      and the use of formal description techniques for protocol  develop-
      ment.   He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a
      graduate course on computer networks at the Swiss Federal Institute
      of  Technology  in  Zurich, and is a senior editor of Computer Net-
      works and ISDN Systems magazine.

      Van Jacobson received a MS in Physics and a BS in Mathematics  from
      the  University of Arizona in 1972.  Since then he has been a Staff
      Scientist in the Real  Time  Systems  Group  of  Lawrence  Berkeley
      Laboratory, developing high performance, distributed, data acquisi-
      tion and control systems.  Since 1984 his research has concentrated
      on  network  protocols  and  the  dynamics of large-scale networks.
      Since 1985 he has served as an adjunct lecturer in Computer Science
      at the University of California, Berkeley, and Stanford University.

      Tutorial #2: Object-Oriented Network Management and Control

      Instructors: Aurel Lazar and Mark W. Sylor

      The objective of this tutorial is to present a structured  approach
      to  problems  arising  in  network management and control.  Object-
      oriented modeling of communication networks.  Knowledge representa-
      tion,  entity/relationship  models for data representation.  Models
      of network management and control.  Managed and  managing  objects.
      Performance management.  Computational models for data abstraction.
      The OSI Information Model  and  the  Management  Information  Base.
      Knowledge  based monitoring and control.  Modeling examples of real
      networks.  DECnet - EMA Entities, TCP/IP - MIB definitions.   Exam-
      ples  will  also be drawn from AT&T's UNMA and IBM's Netview.  Sup-
      porting capabilities and architectures: testing, down/line loading,
      event logging, time service and naming.

      Aurel A. Lazar is a Professor of Electrical Engineering and  Direc-
      tor  of  the  Telecommunication  Networks  Laboratory  at  Columbia
      University.  He received the Dipl.-Ing.  degree  in  communications
      engineering  (Nachrichtentechnik)  from  the  Technische Hochschule
      Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the
      Ph.D.  degree  in  information  sciences and systems from Princeton
      University, Princeton,  NJ,  in  1980.   During  the  80's  he  was
      involved  in  the  design and implementation of integrated networks
      supporting video, voice and data services.  Most recently,  he  was
      the  chief architect of MAGNET II a metropolitan area network based
      on Asynchronous Time Sharing.  Currently he is leading  the  design
      and  implementation of a real-time traffic control architecture for
      integrated networks.

      Mark W. Sylor is a member of the Enterprise Management Architecture
      group  at  Digital Equipment Corperation in Littleton, MA, where he
      works on the EMA Entity Model,  and  the  Phase  V  DECnet  Network
      Management  Specification. He has been a member of the ISO and ANSI
      committees working on OSI System Management, and was  formerly  the
      ANSI T5.4 ad-hoc group leader on the Structure of Management Infor-
      mation (SMI).  Mark has been involved with the design and implemen-
      tation of many of Digital's Network Management systems, in particu-
      lar the NMCC/DECnet Monitor, where he was  the  principle  designer
      and development supervisor.  Mark earned a B.A. degreee at S.U.N.Y.
      at Geneseo in 1971 and an M.S. degree at the  University  of  Notre
      Dame in 1975, both in Mathematics.



                     Technical Program: September 25-27th

      MONDAY, September 24th
      RECEPTION [7 PM to 9 PM]


      TUESDAY, September 25th

      Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30]

      Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith
       Random Drop Congestion Control, A. Mankin (Mitre)
       A Stop-and-Go Queueing Framework for Congestion  Management,  S.J.
       Golestani (Bellcore)
       Virtual Clock: a new traffic control algorithm for packet  switch-
       ing networks, L. Zhang (Xerox PARC)
       Dynamic Adaptive Windows for High Speed Data Networks: Theory  and
       Simulations, D. Mitra (AT&T Bell Laboratories)

      Lunch [12:00 - 1:30]

      Session #2: Applications and  Distributed  Systems  [1:30  -  3:00]
      Chair: Larry Peterson
       Efficient At-Most-Once Messages Based on Synchronized  Clocks,  L.
       Shrira, J. Wroclawski, B. Liskov (MIT)
       Uniform Access to Internet Directory Services,  D.  Comer  (Purdue
       Univ.) and R.E. Droms (Bucknell Univ.)
       A Data Processing Performance Model for the OSI Application  Layer
       Protocols, T. Shiroshita (NTT)

      Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft
       A Simple Multiple Access Protocol for Metropolitan Area  Networks,
       J.O. Limb (Hewlett-Packard)
       The BBN Dual Bus Protocol: Performance in a Wide Area Network,  W.
       Edmond, K. Seo, M. Leib, C. Topolcic (BBN)
       Machnet: A Simple Access Protocol for High Speed or Long Haul Com-
       munications, P. Jacquet, P. Muhlethaler (INRIA)

      SIGCOMM Business Meeting [5:15 - 6:00]


      WEDNESDAY, September 26th

      Session #4: Multimedia  Protocols  and  Protocol  Testing  [9:00  -
      10:30] Chair: Guru Parulkar
       Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler,
       G. Weiss (Brooklyn College)
       Link Access Blocking in Very  Large  Multi-Media  Networks,  J.-F.
       Labourdette, G. Hart (Columbia Univ.)
       Protocol Conformance Test Generation Using Multiple UIO  Sequences
       with Overlapping, B. Yang, H. Ural (University of Ottawa)

      Session #5: High-Speed Switching [11:00  -  12:30]  Chair:  Zygmunt
      Haas
       Gauss: a simple high  performance  switch  architecture  for  ATM,
       R.J.F. de Vries (PTT Research, Netherlands)
       Protocol Implementation on  the  Nectar  Communication  Processor,
       E.C.  Cooper,  P.A.  Steenkiste,  R.D. Sansom, B.D. Zill (Carnegie
       Mellon Univ.)
       Pulsar: Non-blocking Packet Switching with  Shift-Register  Rings,
       G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois)

      Lunch [12:30 - 2:00]

      Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain
       A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox
       PARC)
       Shortest Path First with Emergency Exits, Z.  Wang,  J.  Crowcroft
       (University College London)
       Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer-
       buch (MIT)

      Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge
       Transport Protocol Processing at GBPS rates, N. Jain, M.  Schwartz
       (Columbia University)
       Architectural Considerations for a New  Generation  of  Protocols,
       D.D. Clark, D.L. Tennenhouse (MIT)
       Multiplexing Issues in Transport Protocol Design,  D.C.  Feldmeier
       (Bellcore)

      Banquet [6:30 - 8:00]


      THURSDAY, September 27th

      Session #8: Routing [9:00 - 10:30] Chair: Steve Pink
       Avoiding Name Resolution Loops and Duplications in Group  Communi-
       cations,  L.  Liang,  G.W. Neufeld, S.T. Chanson (Univ. of British
       Columbia)
       Design  of  Inter-Administrative  Domain  Routing   Protocols   L.
       Breslau, D. Estrin (USC)
       Topology Distribution Cost vs. Efficient  Routing  In  Large  Net-
       works, A. Bar-Noy, M. Gopal (IBM Watson)

      Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco
       Efficient Use of Workstations for Passive Monitoring of Local Area
       Networks, J. Mogul (DEC)
       Performance Analysis of FDDI Token Ring Networks: Effect of Param-
       eters and Guidelines for Setting TTRT, R. Jain (DEC)
       Frame Content Independent Stripping for Token Rings, H.  Yang,  K.
       K. Ramakrishnan (DEC)

      Lunch [12:30 - 2:00]

      Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack
       Fast Connection Establishment in High Speed Networks, I. Cidon, I.
       Gopal, A. Segall (IBM Watson and Technion)
       Reliable Broadband Communications Using a Burst Erasure Correcting
       Code, A.J. McAuley (Bellcore)
       An Inclusive Session Protocol for Distributed  Applications,  V.S.
       Sunderam (Emory Univ.)





      SIGCOMM '90 wishes to  thank  our  host  site,  the  University  of
      Pennsylvania  for  its  considerable  support  in  putting  on this
      conference.

      SIGCOMM '90 would also like to acknowledge the generous support  of
      the   following   corporations:  Advance  Computer  Communications,
      Bellcore, FTP Software,  Digital  Equipment  Corporation's  Network
      Systems Lab, and Interop Inc.

      Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich,
      in Zurich, Switzerland.

*******************************************************************************

		    SIGCOMM '90 Advance Registration Form

    mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania,
	329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA

NAME ____________________________________

AFFILIATION _____________________________

ADDRESS _________________________________

     ____________________________________

     ____________________________________

Phone: __________________________________

E-mail: _________________________________

SIGCOMM/ACM Member # ____________________


Tutorials: 	before 9/1          after 9/1

    Members        $175               $230
    Non-Members    $230               $280
    Students       $100               $100   
    [student tutorial rates on space available basis]

	    Tutorial #1 ___  or Tutorial #2 ___                    $_____


Conference:     before 9/1          after 9/1

    Members        $230               $280
    Non-Members    $280               $330
    Students       $100               $100

								   $_____

							Total      $_____


    dietary restrictions   ___ kosher  ___ vegetarian



*******************************************************************************

		    SIGCOMM '90 Hotel Registration Form

    mail to: University City Sheraton Hotel, 36th and Chestnut St,
	    Philadelphia, PA 19104  (215-387-8000)

	Registration must be received 8/23 to ensure these rates


NAME ____________________________________     ___ Single $80 + tax

AFFILIATION _____________________________     ___ Double $90 + tax

ADDRESS _________________________________     Univ. of Pennsylvania CIS rate

     ____________________________________

     ____________________________________     

Phone: __________________________________ 

Arrival Date: ___________________________

Departure Date: _________________________


to guarantee arrival after 4PM please provide credit card information

Card Name & Number _______________________________   Expires _______

Name on Card _________________________________   Signature _________________

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 09:15:25 EDT
From:      stev@vax.ftp.com
To:        swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!dan@ucsd.edu  (Dan Schlitt)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
>I have my doubts about Roy's interpretation too.  However one should
>also note the anonymous critique of the governance of the Internet
>that was published in Goodfellow's newsletter.  Participation in the
>IAB and the IETF can't be read as 100% support.

>Dan Schlitt                        Manager, Science Division Computer Facility


well, i am not on the IAB. i am an active participant in the IETF though. i
am currently the PPP working group chair. while i do not support the actions
of the organizations 100%, i do believe the process is the best one out
there, and i also believe that one person, with well thought out arguements,
and careful planning, can make a diffrence. i can also say that the
IAB/IETF/IESG has never tried to shut me up, they has asked me to talk about
something later, but always at reasonable times. they also have called on me
many times at the IETF meetings to let me say my piece. it may not have
always been in their best interest, and i am sure there have been times they
wished i didnt open my mouth, but they do seem to put up with people with
disenting opinions if these people are willing to work in the system to fix
the problems they see.


could be worse, i am told that the ISO people have to submit their
statements in written form. they would get to miss my booming voice wafting
out over the lecture hall. . . . :)

stev knowles
IETF PPP working group chair
ftp software
stev@ftp.com

"Maybe they are all Bozo's on this bus, but they are *our* clowns, not
someone elses!"


-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 13:04:25 PDT
From:      estrin@usc.edu (Deborah Estrin)
To:        paul%dy4%cognos%sce%mitel.uucp@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Request for protocol overhead references
I believe that Dr. Liba Svobodova et. al. had a paper in Computer
Networks and ISDN Systems (late '89 or early '90) with performance
measures for TCP and TP4...
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 13:22:55 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up access to Internet facilities



 >I think that "fast connections around the world" does not mean that we
 >have to allow anyone with a modem and terminal to telnet/rlogin into any
 >host at will on the Internet.  Doesn't compute.

dont agree - we have just been checking how fast you can clock a line
based on the copper used for UK phones, and managed 200kbps without
much trouble - i.e. multiple basic rate ISDNs (without even needing
much tcp header compression) will make a X and NFS to 20 million UK homes
feasible before the year 2000 - if anyone thought building such a
wacky service ... if they do, security on my VCR is gonna be
ultra-tight (i dont want some hacker making me miss my favourite
show)...

jon {p.s. this is not entirely serious:-}

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 14:05:26 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '90 Advance Program [Text]





                       SIGCOMM '90 - General Information


      SIGCOMM is the annual conference of the ACM Special Interest  Group
      in  Computer Communication.  This year's conference will be held at
      the University City Sheraton Hotel in  Philadelphia,  Pennsylvania,
      September  24-27th.  This program contains the advance schedule for
      the conference, registration information,  and  hotel  information.
      If  you  have  any  questions, feel free to contact the SIGCOMM '90
      conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu.


      SIGCOMM Conference Committee
           General Chair: Prof. David J. Farber (Univ. Pennsylvania)
           Program Chair: Phil Karn (Bellcore)
           Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania)
           Local Arrangements: Dan Finnigan (Univ. Pennsylvania)
           Publicity Chair: Craig Partridge (Bolt Beranek and Newman)
           Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris
             Edmondson-Yurkanan (Univ. Texas), Dr. Vint Cerf (CNRI)

      SIGCOMM Program Committee
      Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf  (CNRI),
      Doug  Comer  (Purdue),  Jon  Crowcroft (Univ. College London), Gary
      Delp (IBM), John Demco (CDNnet),  Magda  El-Zarki  (Univ.  Pennsyl-
      vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ.
      Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington  Univ.
      St.  Louis),  Larry L. Peterson (Univ. Arizona), Steve Pink (SICS),
      Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ.
      Pennsylvania)



                   Tutorials: September 24th [9 AM to 5 PM]

      Tutorial #1: Protocols for High-Speed Networks
      Instructors: Harry Rudin and Van Jacobson

      Part A: High-Performance, Transport-Level Protocols (Rudin)

      Made possible by progress in  fiber-optic  and  VLSI  technologies,
      networks  offering  increasing  transmission capacity at decreasing
      error rates are becoming available.  New applications would benefit
      from this bandwidth but software protocol processing rates have not
      kept up with available raw transmission speed.  The presentation is
      a  comparative  survey of techniques used at the transport layer in
      eight representative protocols, most  of  which  were  designed  to
      improve  the  protocol  processing  rate.   The  protocols  are the
      relevant portions of the APPN, Datakit, Delta-t,  NETBLT,  OSI/TP4,
      TCP,  VMTP, and XTP architectures.  The main functions covered are:
      connection management, acknowledgements, flow  control,  and  error
      handling.

      Part B: Efficient TCP Implementation (Jacobson)

      Network protocol processing time has long been viewed as THE deter-
      miner  of  perceived  network  performance.   For at least one well
      known suite, the TCP and IP Internet protocols, recent  measurement
      has  shown  this  view  to be false:  The protocol *implementation*
      affects perceived performance, as does the way in which the network
      interface hardware interacts with the entire software/hardware sys-
      tem it is a part of.   But there is no inherent  performance  limit
      in  the TCP/IP protocols themselves.  In fact, a Unix TCP/IP imple-
      mentation has been constructed  that  runs  at  a  essentially  the
      information-theoretic  minimum  time  for  the  the  problem  being
      solved.
      This tutorial will describe an efficient TCP/IP  implementation  in
      agonizing  detail.   It  will describe where time goes in a typical
      implementation and what can be done  in  the  protocol  and  system
      software  to  reclaim  that  time.  It will discuss how the network
      interface hardware affects processing time and what hardware archi-
      tectures lead to cheap, efficient processing.
      Familiarity  with  the  TCP  and  IP  protocols  will  be  assumed.
      Although the implementation described will be based on a real, pro-
      duction, Berkeley Unix TCP/IP, no Unix  kernel  expertise  will  be
      assumed,  only  familiarity with operating system issues and imple-
      mentations.

      Harry Rudin received the B.E. and D.Eng. degrees from Yale  Univer-
      sity, where he also taught until 1964.  He worked at Bell Telephone
      Laboratories in the area of data communications until 1968.   Since
      then  he has been doing research in computer communications systems
      at the  Zurich  Research  Laboratory,  IBM  Research  Division,  in
      Rueschlikon,  Switzerland.   His interests are high-speed protocols
      and the use of formal description techniques for protocol  develop-
      ment.   He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a
      graduate course on computer networks at the Swiss Federal Institute
      of  Technology  in  Zurich, and is a senior editor of Computer Net-
      works and ISDN Systems magazine.

      Van Jacobson received a MS in Physics and a BS in Mathematics  from
      the  University of Arizona in 1972.  Since then he has been a Staff
      Scientist in the Real  Time  Systems  Group  of  Lawrence  Berkeley
      Laboratory, developing high performance, distributed, data acquisi-
      tion and control systems.  Since 1984 his research has concentrated
      on  network  protocols  and  the  dynamics of large-scale networks.
      Since 1985 he has served as an adjunct lecturer in Computer Science
      at the University of California, Berkeley, and Stanford University.

      Tutorial #2: Object-Oriented Network Management and Control

      Instructors: Aurel Lazar and Mark W. Sylor

      The objective of this tutorial is to present a structured  approach
      to  problems  arising  in  network management and control.  Object-
      oriented modeling of communication networks.  Knowledge representa-
      tion,  entity/relationship  models for data representation.  Models
      of network management and control.  Managed and  managing  objects.
      Performance management.  Computational models for data abstraction.
      The OSI Information Model  and  the  Management  Information  Base.
      Knowledge  based monitoring and control.  Modeling examples of real
      networks.  DECnet - EMA Entities, TCP/IP - MIB definitions.   Exam-
      ples  will  also be drawn from AT&T's UNMA and IBM's Netview.  Sup-
      porting capabilities and architectures: testing, down/line loading,
      event logging, time service and naming.

      Aurel A. Lazar is a Professor of Electrical Engineering and  Direc-
      tor  of  the  Telecommunication  Networks  Laboratory  at  Columbia
      University.  He received the Dipl.-Ing.  degree  in  communications
      engineering  (Nachrichtentechnik)  from  the  Technische Hochschule
      Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the
      Ph.D.  degree  in  information  sciences and systems from Princeton
      University, Princeton,  NJ,  in  1980.   During  the  80's  he  was
      involved  in  the  design and implementation of integrated networks
      supporting video, voice and data services.  Most recently,  he  was
      the  chief architect of MAGNET II a metropolitan area network based
      on Asynchronous Time Sharing.  Currently he is leading  the  design
      and  implementation of a real-time traffic control architecture for
      integrated networks.

      Mark W. Sylor is a member of the Enterprise Management Architecture
      group  at  Digital Equipment Corperation in Littleton, MA, where he
      works on the EMA Entity Model,  and  the  Phase  V  DECnet  Network
      Management  Specification. He has been a member of the ISO and ANSI
      committees working on OSI System Management, and was  formerly  the
      ANSI T5.4 ad-hoc group leader on the Structure of Management Infor-
      mation (SMI).  Mark has been involved with the design and implemen-
      tation of many of Digital's Network Management systems, in particu-
      lar the NMCC/DECnet Monitor, where he was  the  principle  designer
      and development supervisor.  Mark earned a B.A. degreee at S.U.N.Y.
      at Geneseo in 1971 and an M.S. degree at the  University  of  Notre
      Dame in 1975, both in Mathematics.



                     Technical Program: September 25-27th

      MONDAY, September 24th
      RECEPTION [7 PM to 9 PM]


      TUESDAY, September 25th

      Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30]

      Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith
       Random Drop Congestion Control, A. Mankin (Mitre)
       A Stop-and-Go Queueing Framework for Congestion  Management,  S.J.
       Golestani (Bellcore)
       Virtual Clock: a new traffic control algorithm for packet  switch-
       ing networks, L. Zhang (Xerox PARC)
       Dynamic Adaptive Windows for High Speed Data Networks: Theory  and
       Simulations, D. Mitra (AT&T Bell Laboratories)

      Lunch [12:00 - 1:30]

      Session #2: Applications and  Distributed  Systems  [1:30  -  3:00]
      Chair: Larry Peterson
       Efficient At-Most-Once Messages Based on Synchronized  Clocks,  L.
       Shrira, J. Wroclawski, B. Liskov (MIT)
       Uniform Access to Internet Directory Services,  D.  Comer  (Purdue
       Univ.) and R.E. Droms (Bucknell Univ.)
       A Data Processing Performance Model for the OSI Application  Layer
       Protocols, T. Shiroshita (NTT)

      Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft
       A Simple Multiple Access Protocol for Metropolitan Area  Networks,
       J.O. Limb (Hewlett-Packard)
       The BBN Dual Bus Protocol: Performance in a Wide Area Network,  W.
       Edmond, K. Seo, M. Leib, C. Topolcic (BBN)
       Machnet: A Simple Access Protocol for High Speed or Long Haul Com-
       munications, P. Jacquet, P. Muhlethaler (INRIA)

      SIGCOMM Business Meeting [5:15 - 6:00]


      WEDNESDAY, September 26th

      Session #4: Multimedia  Protocols  and  Protocol  Testing  [9:00  -
      10:30] Chair: Guru Parulkar
       Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler,
       G. Weiss (Brooklyn College)
       Link Access Blocking in Very  Large  Multi-Media  Networks,  J.-F.
       Labourdette, G. Hart (Columbia Univ.)
       Protocol Conformance Test Generation Using Multiple UIO  Sequences
       with Overlapping, B. Yang, H. Ural (University of Ottawa)

      Session #5: High-Speed Switching [11:00  -  12:30]  Chair:  Zygmunt
      Haas
       Gauss: a simple high  performance  switch  architecture  for  ATM,
       R.J.F. de Vries (PTT Research, Netherlands)
       Protocol Implementation on  the  Nectar  Communication  Processor,
       E.C.  Cooper,  P.A.  Steenkiste,  R.D. Sansom, B.D. Zill (Carnegie
       Mellon Univ.)
       Pulsar: Non-blocking Packet Switching with  Shift-Register  Rings,
       G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois)

      Lunch [12:30 - 2:00]

      Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain
       A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox
       PARC)
       Shortest Path First with Emergency Exits, Z.  Wang,  J.  Crowcroft
       (University College London)
       Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer-
       buch (MIT)

      Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge
       Transport Protocol Processing at GBPS rates, N. Jain, M.  Schwartz
       (Columbia University)
       Architectural Considerations for a New  Generation  of  Protocols,
       D.D. Clark, D.L. Tennenhouse (MIT)
       Multiplexing Issues in Transport Protocol Design,  D.C.  Feldmeier
       (Bellcore)

      Banquet [6:30 - 8:00]


      THURSDAY, September 27th

      Session #8: Routing [9:00 - 10:30] Chair: Steve Pink
       Avoiding Name Resolution Loops and Duplications in Group  Communi-
       cations,  L.  Liang,  G.W. Neufeld, S.T. Chanson (Univ. of British
       Columbia)
       Design  of  Inter-Administrative  Domain  Routing   Protocols   L.
       Breslau, D. Estrin (USC)
       Topology Distribution Cost vs. Efficient  Routing  In  Large  Net-
       works, A. Bar-Noy, M. Gopal (IBM Watson)

      Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco
       Efficient Use of Workstations for Passive Monitoring of Local Area
       Networks, J. Mogul (DEC)
       Performance Analysis of FDDI Token Ring Networks: Effect of Param-
       eters and Guidelines for Setting TTRT, R. Jain (DEC)
       Frame Content Independent Stripping for Token Rings, H.  Yang,  K.
       K. Ramakrishnan (DEC)

      Lunch [12:30 - 2:00]

      Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack
       Fast Connection Establishment in High Speed Networks, I. Cidon, I.
       Gopal, A. Segall (IBM Watson and Technion)
       Reliable Broadband Communications Using a Burst Erasure Correcting
       Code, A.J. McAuley (Bellcore)
       An Inclusive Session Protocol for Distributed  Applications,  V.S.
       Sunderam (Emory Univ.)





      SIGCOMM '90 wishes to  thank  our  host  site,  the  University  of
      Pennsylvania  for  its  considerable  support  in  putting  on this
      conference.

      SIGCOMM '90 would also like to acknowledge the generous support  of
      the   following   corporations:  Advance  Computer  Communications,
      Bellcore, FTP Software,  Digital  Equipment  Corporation's  Network
      Systems Lab, and Interop Inc.

      Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich,
      in Zurich, Switzerland.

*******************************************************************************

		    SIGCOMM '90 Advance Registration Form

    mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania,
	329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA

NAME ____________________________________

AFFILIATION _____________________________

ADDRESS _________________________________

     ____________________________________

     ____________________________________

Phone: __________________________________

E-mail: _________________________________

SIGCOMM/ACM Member # ____________________


Tutorials: 	before 9/1          after 9/1

    Members        $175               $230
    Non-Members    $230               $280
    Students       $100               $100   
    [student tutorial rates on space available basis]

	    Tutorial #1 ___  or Tutorial #2 ___                    $_____


Conference:     before 9/1          after 9/1

    Members        $230               $280
    Non-Members    $280               $330
    Students       $100               $100

								   $_____

							Total      $_____


    dietary restrictions   ___ kosher  ___ vegetarian



*******************************************************************************

		    SIGCOMM '90 Hotel Registration Form

    mail to: University City Sheraton Hotel, 36th and Chestnut St,
	    Philadelphia, PA 19104  (215-387-8000)

	Registration must be received 8/23 to ensure these rates


NAME ____________________________________     ___ Single $80 + tax

AFFILIATION _____________________________     ___ Double $90 + tax

ADDRESS _________________________________     Univ. of Pennsylvania CIS rate

     ____________________________________

     ____________________________________     

Phone: __________________________________ 

Arrival Date: ___________________________

Departure Date: _________________________


to guarantee arrival after 4PM please provide credit card information

Card Name & Number _______________________________   Expires _______

Name on Card _________________________________   Signature _________________

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 14:31:45 GMT
From:      mcsun!cernvax!chx400!hslrswi!aut!ruef@uunet.uu.net  (Bernhard Ruef)
To:        tcp-ip@nic.ddn.mil
Subject:   NFS for NCR TOWER

Well, the subject line says it all:
Does anybody know about the availability of NFS for a NCR TOWER 32/[46]X0
running System V.3 (Release 3.00.01 in NCR speak) ?

Yes, I do know that this question has been asked before in comp.sys.ncr
but I haven't yet seen a satisfactory, i.e. definite answer :-)

Cheers
-Beni

-- 
Bernhard D. Ruef        Ascom Autelca AG      CH-3073 Guemligen/Switzerland
E-mail: ruef@aut.UUCP   FAX: +41 31 527 745   Voice mail: +41 31 529 602

"UNIX is the answer - what was the question ?"
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 15:01:47 GMT
From:      usc!jarthur!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@ucsd.edu  (Bill Daniels)
To:        tcp-ip@nic.ddn.mil
Subject:   Query - Ethernet collisions
We recently acquired an Exelan LANalyzer.  During our first uses of it,
we noticed that about 40% of the packets on one ethernet segment (which
is remotely bridged to another) show up as "Collision detected in preamble".
This segment is not busy necessarily when this happens.  The actual number of
collisions reported seems fairly constant even as traffic picks up.  On
a very quiet net (~ 2 packets / sec.) I see about 20 errors over ~ 30 secs.
When the segment is a little more active (~ 1000 packets / sec.) the error
rate is just about the same.  

I have tried disconnecting the devices that the errors are associated with
but the collisions just move to the packets associated with other devices.

Any clues?

bd
-- 
bill daniels
federal express, memphis, tn
{hplabs!csun,mit-eddie!premise}!fedeva!bill
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 22:34:26 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        ka9q.bellcore.com!karn@bellcore.com (Phil Karn)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?

Phil,

Your almost correct....

> Perhaps the most important thing about the IAB is its "fly before buy"
> policy. For a protocol to reach internet standard status, it must first be
> implemented and widely used, and there must be a substantial body of
> perational experience.

CMOT was elevated to DIS without the above.

Marty
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 15:58:46 GMT
From:      cica!ssw@iuvax.cs.indiana.edu  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   When is an ethernet full?

When is an ethernet full?  We have a campus backbone composed of a
chipcom  10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over
broadband (buffered repeaters).  The UB and chipcom networks are bridged
to form one logical networks.  According to our Network General sniffer, 
we constantly maintain about 10-15 percent utilization or (300 - 1000
packets per second).   How much more traffic can this network support
before performance falls off measurably?  Any ideas?  

Thanks,

Steven Wallace
Indiana University
wallaces@ucs.indiana.edu
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 14:22:55 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        "Martin L. Schoffstall" <schoff@uu.psi.com>
Cc:        uupsi!iuvax.cs.indiana.edu!bronze.ucs.indiana.edu!mckimg@uu.psi.com, tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities


 >I think that "fast connections around the world" does not mean that we
 >have to allow anyone with a modem and terminal to telnet/rlogin into any
 >host at will on the Internet.  Doesn't compute.

dont agree - we have just been checking how fast you can clock a line
based on the copper used for UK phones, and managed 200kbps without
much trouble - i.e. multiple basic rate ISDNs (without even needing
much tcp header compression) will make a X and NFS to 20 million UK homes
feasible before the year 2000 - if anyone thought building such a
wacky service ... if they do, security on my VCR is gonna be
ultra-tight (i dont want some hacker making me miss my favourite
show)...

jon {p.s. this is not entirely serious:-}
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 16:53:31 GMT
From:      oliveb!orc!bbn.com!craig@apple.com  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?
> When is an ethernet full?  ....
> According to our Network General sniffer, 
> we constantly maintain about 10-15 percent utilization or (300 - 1000
> packets per second).   How much more traffic can this network support
> before performance falls off measurably?  Any ideas?  

The best place I know of to start answering this question is Boggs,
Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233.  The
gist of that article is that you can drive the Ethernet all the way
to its rated capacity assuming you are careful in the way you lay out
your network, and all your systems have good Ethernet hardware.

In practice of course, many of the systems won't have good Ethernet
hardware (for example, Jacobson's talk at SIGCOMM '88 indicated he'd
found an Ethernet chipset that could only go about 6 Mbits/sec).  So
you need to find some people out there with some good practical experience
about when some of their systems start breaking down, to figure out when
your network will die due to poor hardware/software.

Craig
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 17:24:02 GMT
From:      usc!cs.utexas.edu!uwm.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005270423.AA19852@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
 ...
> At least you could talk them into getting a good quality UUCP connection
> so they can do email.  I'm frightened by the lack of participation of
> many vertical industries in communicating with their customers, suppliers,
> except through phones. (Have you ever entered voice mail grid lock, where
> neither party ever gets through due to synchronization problems, and
> the use of voice mail systems as filtering devices.  Someday the only
> time you'll ever get an answer is by dialing 1-900.lovenow).
> 
 ...
>  	Please do make an announcement of any new services PSI introduces.  I 
>  	for one would like to hear what PSI is doing to moderate access fees 
>  	without having to ping your sales organization every few months.  
> 
> Maybe Kent England will radio you in reports from "The Front", rumored
> to have been named "Operation Fortress Beantown", BarHarborAirlines has
> guaranteed that they can airlift as many cisco's as they will need to
> sustain the battle.  :-)
> 
> Marty

	Glad to!  [BTW, it's not "Operation Fortress Beantown".  Only
folks from elsewhere and local sportswriters call Boston Beantown.  :-]

	We got the three inches of water pumped out of the main bunker
and the dehumidifier is fixed now, so it's bearable down here.  I have
a pretty good view of the harbor and Logan airport.  PSI has been airlifting
in dial-up servers, but we shot down most of them, since the visibility
was pretty poor and PSI didn't pay for good IFR gear.  Better luck next
time, Marty.  :-)

	Seriously, though, I share Marty's concern about a lack of interest
in commercial enterprises in supporting business using modern internetworks.
It would seem obvious to me what the benefits are, so perhaps we just need
to be more aggressive in touting the capabilities of the technology we know
and love.  Marty will see to that, as far as he can, since his livelihood
depends on it.  I see a definite interest on the part of commercial
organizations
wishing to join the research and education (R&E) Internet, but I see much
less interest from them in joining a purely commercial internet service-
they don't seem to understand who they would be able to talk to on a purely
commercial internet.  Come to think of it, neither do I.  But certainly
there is a lot of interest from commercial outfits in becoming a part of
our R&E Internet and in exploiting that technology to talk to the existing
base of constituents.

	NEARnet has had a phenomenal response from commercial organizations
joining NEARnet and the Internet.  There are a lot of research labs in the
Boston area, and they are very eager to be a part of the R&E Internet.
Perhaps it is just that they are able to move more quickly allocating budget
to the NEARnet connection, and are therefore able to connect more quickly
than some of our colleagues in the academic field in New England.  We'll see.

	Like the PSI folk, NEARnet is aware of an untapped potential base
for lower cost access to the Internet, from both the commercial organizations
and from academic organizations.  As might be expected, this is due mostly
to a scale pyramid=  there are simply more small sites than large.

	NEARnet is committed to broadening its base of support to include
smaller sites at lower cost.  We are chafing against technical issues in
being able to offer high quality service at lower costs, since we balance
hardware and people costs, and people costs are not really that bandwidth
sensitive.  We also have strict standards on quality of service, and we
do not wish to compromise these standards in offering less costly access,
since we know that later on our customers would regret the compromise as
much as we.  Then there is the issue of just what is part-time access;
is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what?  We have
to keep in mind what services we provide and we have to make sure that
our clients understand what they can and can't do with new service offerings.

	All in all, though we have been able to keep costs quite
reasonable, so far as we can tell in comparing costs with our neighbors.

	As far as keeping up with new service offerings, you should
keep an eye on comp.newprod.  PSI always posts announcements of new service
offerings there, and NEARnet will as well.

	Must get back to work; we have air raid drills scheduled for 2pm
this afternoon and my anti-aircraft gun needs greasing.  I'll radio in 
future reports so long as my lines to Princeton aren't cut.

	--Kent England, Boston University
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 18:41:46 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
I have to agree with Stev Knowles. The IAB/IETF is the *only* standards body
that actually seems to work. I've never seen an important technical decision
made by anyone other than the members of the working group in charge of a
given topic, and anyone with a technical interest is free to join and
contribute.

Perhaps the most important thing about the IAB is its "fly before buy"
policy. For a protocol to reach internet standard status, it must first be
implemented and widely used, and there must be a substantial body of
operational experience.

If only other standards organizations could follow this principle the world
would be a far better place.

Phil
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 18:42:25 GMT
From:      usc!cs.utexas.edu!uwm.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu@ucsd.edu  (Rusty Smith, MACC)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?
In article <1141@cica.cica.indiana.edu>, ssw@cica.cica.indiana.edu (Steve 
Wallace) writes...

> 
>When is an ethernet full?  We have a campus backbone composed of a
>chipcom  10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over
>broadband (buffered repeaters).  The UB and chipcom networks are bridged
>to form one logical networks.  According to our Network General sniffer, 
>we constantly maintain about 10-15 percent utilization or (300 - 1000
>packets per second).   How much more traffic can this network support
>before performance falls off measurably?  Any ideas?  
>

We have a similar setup here. There are about 50 Chipcom's connected to
our broadband backbone. All but 3 are coupled to DEC Lanbridges to
keep local traffic local. We have had similar 1 minute averages and
peaks of 3-4 times as much. As far as we can tell everyone is 
satisfied with the performance with these numbers. We have had
other performance problems not caused by traffic volume.

Rusty Smith			Internet:  rsmith@vms.macc.wisc.edu
MACC Data Communications	Bitnet:    rsmith@wiscmacc
(608)  263-6307			Univ. of Wisconsin @ Madison
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 19:11:25 GMT
From:      shelby!portia.stanford.edu!jessica.stanford.edu!morgan@eos.arc.nasa.gov  (RL "Bob" Morgan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

> Somehow dialup Internet access and SMTP don't go hand and hand in my
> mind, my estimate is that your going to have keep a connection open
> for about 3 hours every day to have some probablity of synchronizing
> with all the SMTP agents pushing mail out of their queues for the
> site.  Realistically you'll be running uucp/tcp to a site like UUPSI
> who is MX'ing for your domain.

Indeed, SMTP's assumption that everybody's connected all the time
doesn't work well with occasionally-connected hosts.  It would seem
that the time is ripe for some sort of extension to SMTP to do
receiver-initiated transfers to meet this need.  Of course you'll
still need the MXing host to hold your mail for you.  Presumably
getting away from uucp is one of the points of all this.

Note that POP doesn't make it for the small-business customer.  I want
my address to be "morgan@mybusiness.com" not "morgan@barrnet.net".  I
also want to manage my own accounts on my own multi-user system, not
ask my provider every time I need a new one.

 - RL "Bob" Morgan
   Networking Systems
   Stanford
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 21:28:21 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?
>When is an ethernet full?  We have a campus backbone composed of a
>chipcom  10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over
>broadband (buffered repeaters).  The UB and chipcom networks are bridged
>to form one logical networks.  According to our Network General sniffer, 
>we constantly maintain about 10-15 percent utilization or (300 - 1000
>packets per second).   How much more traffic can this network support
>before performance falls off measurably?  Any ideas?  

I'd like to see you get data with a bit more time resolution.  It's a
bit unusual for networks to run at 10-15% all the time, day and night.
More typically, there's a long-term variation over the course of a
day, with more traffic during the day than night, and short-term
variation as people boot machines, transfer big files, or do other
things that cause a short-term demand for bandwidth.  If you're
running at 10% 24 hours a day, this suggests either a very odd mix of
users and applications, or that most of your bandwidth is going to
broadcast packets produced by rwhod or things of that nature.  I have
heard of networks with a constant broadcast load of that sort.  In
that case, replacing some or all of your bridges with routers might be
more useful than trying to increase the bandwidth.  In general I'd
expect a peak to average ratio of about 10 to 1.  That is, if you are
averaging 10% usage, you are probably using 100% during brief periods.
So you're about at capacity.  If your 10% is made up mostly of a
continuous background of broadcast packets, this might not be the
case.  But if you've really got that much broadcast traffic, you've
got other problems.  Like your hosts are all spending significant CPU
dealing with it.  If your 10% represents the maxima of your peaks,
rather than a true average, then you're probably in good shape and
still have some room to grow.
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 21:45:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Public domain TCP/IP Software for VAX?


        Hi, Netlander!
        Does anybody know whether there is any public domain software
TCP/IP for VAX? Please reply to me directly, I will summarize if there
is enough interest.

p/s: please inlcude the anonymous FTP site if there is

- Beng Hang Tay (email: taybengh@nusdiscs)
  Dept. of Info. Sys. and Comp. Sc.
  NATIONAL UNIVERSITY OF SINGAPORE

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 22:12:16 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>Indeed, SMTP's assumption that everybody's connected all the time
>doesn't work well with occasionally-connected hosts.  It would seem
>that the time is ripe for some sort of extension to SMTP to do
>receiver-initiated transfers to meet this need.

No extension is needed: see the TURN command.  However, most SMTP
implementation don't enable this command for security reasons.  To make it
secure you need a way of authenticating the calling SMTP.  One possibility
would be to allow it only in cases where the name given in the HELO command
corresponds to the address being used by the transport layer; however, not
all transport layers make this available (what do you do if SMTP is being
done over dialup lines?).

>Note that POP doesn't make it for the small-business customer.  I want
>my address to be "morgan@mybusiness.com" not "morgan@barrnet.net".  I
>also want to manage my own accounts on my own multi-user system, not
>ask my provider every time I need a new one.

MX records solve the first problem.

However, I'm not sure why you need any of this.  What's wrong with the
MX'ing host periodically trying to connect to the occasionally-connected
hosts?  Much of the time it will just time out, but when it succeeds it can
forward all the accumulated mail.  This is the default behavior, so no
extensions are necessary.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      29 May 90 23:36:15 GMT
From:      netcom!hinton@apple.com  (Greg Hinton)
To:        tcp-ip@nic.ddn.mil
Subject:   What is VMTP?
I've read bits & pieces about something called VMTP.  From what I've seen,
it appears to be a reliable counterpart of UDP.
Can someone explain in more depth exactly what VMTP is and/or provide
easily available references?
Are there any implementations under UNIX?

Thanks.
-- 

Greg Hinton
DOMAIN: hinton@netcom.uucp
UUCP: uunet!apple!netcom!hinton
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 00:10:09 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> I see a definite interest on the part of commercial organizations
> wishing to join the research and education (R&E) Internet, but I see much
> less interest from them in joining a purely commercial internet service-
> they don't seem to understand who they would be able to talk to on a purely
> commercial internet.  Come to think of it, neither do I.

In our case, at least, one of the reasons that a connection to what you call
the R&E Internet would/will be so valuable is that a lot of the people that
we want to communicate with are already there.  I suspect that the companies
that are currently most interested in the Internet fall into one of two
categories:

 1. Companies whose customer base is largely already on the Internet.
    TCP/IP vendors, supercomputer vendors, and so on.  We fall into this
    category, for example.

 2. Companies that want to reap the benefits of wide-area networking
    without having to develop their own infrastructure.  Some bicoastal
    computer corporations fall into this category, for example.

As the number of companies in category 2 increase, the perceived value
of a purely commercial internet will also increase.  At some point, also,
commercial service providers may increase its value by allowing it to
mediate services that the R&E Internet cannot or by policy will not support.

--
Amanda Walker
--
This posting is cursed.  As you read it you will be confuset by ther
printeb wertz.  Yer intelijen will vabni ..... XRT! XRT!
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 01:59:32 GMT
From:      zaphod.mps.ohio-state.edu!mips!cmic!garvey@tut.cis.ohio-state.edu  (Joe Garvey)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip services <--> decnet connectivity, help wanted
I need to connect a DEC (decnet) system to an HP unix system. My objective
is to make the remote login, and file transfer services work.

I can make the required physical connections of the LAN's involved...
However, I assume a direct connection won't work. I need some kind of
protocol tranlator in the middle.

For a number of reasons, each machine must think it's working in its native
services (decnet or arpa-berkeley).

Can I use a PC and some netware?
Does someone make a translator?
Can I directly connect the two networks, and put some software package on
my HP (9000/370)? It's out of the question to add software to the
DEC machines (PDP/RSTS) ;-(.
I've got some PC's and terminal servers using the arpa-berkeley tools, what
about them?

Am I crazy? :-)

E-mail response preferred. ... normal stuff about summarizing ...

Thanx.

--

Joe Garvey                       UUCP: {apple,backbone}!versatc!mips!cmic!garvey
California Microwave             Internet: garvey%cmic@mips.com
990 Almanor Ave                  HP Desk: garvey (cmic@mips.com) /hp1900/ux
Sunnyvale, Ca, 94086             800-831-3104 (outside CA)
408-720-6439 (let it ring)       800-824-7814 (inside CA)
-----------[000349][next][prev][last][first]----------------------------------------------------
From:      lefty@obelix.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re:  Query - Ethernet collisions
In <98@fedeva.UUCP>, Bill Daniels 
<usc!jarthur!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@ucsd.edu> 
writes:

> We recently acquired an Exelan LANalyzer.  During our first uses of it,
> we noticed that about 40% of the packets on one ethernet segment (which
> is remotely bridged to another) show up as "Collision detected in preamble".
> This segment is not busy necessarily when this happens.  The actual number 
> of collisions reported seems fairly constant even as traffic picks up.  On
> a very quiet net (~ 2 packets / sec.) I see about 20 errors over ~ 30 secs.
> When the segment is a little more active (~ 1000 packets / sec.) the error
> rate is just about the same.  
> 
> I have tried disconnecting the devices that the errors are associated with
> but the collisions just move to the packets associated with other devices.
> 
> Any clues?

My immediate guess would be a marginal terminator somewhere...

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: Lefty@twg.com        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 02:25:24 GMT
From:      zaphod.mps.ohio-state.edu!samsung!sol.ctr.columbia.edu!cica!ssw@tut.cis.ohio-state.edu  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?
A little more info.

     We have about 45 IP subnets all behind cisco routers.  We
route appletalk phase I, DECnet, and bridge IPX.  Between the
hours of 9am to 5pm we see a pretty steady 10 - 15 percent load.
Sometimes this drops to 2 percent but only for very brief
periods.

Steven Wallace
wallaces@ucs.indiana.edu
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 02:35:49 GMT
From:      sumax!ctsx!dms@beaver.cs.washington.edu  (Dave Stanhope)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet access
Is it possible (assuming correct usage) to get access to the Internet
via the commercial X25 networks (Telenet and/or Tymnet).  The connection
would use TCP/IP over X25.  Any comments would be appreciated!

Reply to:

    ..!uwbeaver!sumax!ctsx!dms

                    Thanks, Dave S.
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 May 90 13:45 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Public domain TCP/IP Software for VAX?

        Hi, Netlander!
        Does anybody know whether there is any public domain software
TCP/IP for VAX? Please reply to me directly, I will summarize if there
is enough interest.

p/s: please inlcude the anonymous FTP site if there is

- Beng Hang Tay (email: taybengh@nusdiscs)
  Dept. of Info. Sys. and Comp. Sc.
  NATIONAL UNIVERSITY OF SINGAPORE
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 May 90 10:13:29 PDT
From:      postel@venera.isi.edu
To:        netcom!hinton@apple.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  What is VMTP?
Hi.

See RFC-1045 and the papers by Cheriton in various places (e.g., Sigcomm
conference proceedings).

--jon.
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 07:57:00 EDT
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   LanTastic NOS and TCP/IP
Date sent:  30-MAY-1990 07:56:35 

Hi,
	Does anyone know/have/hear of a gateway from Lantastic to TCP/IP?

Dave

================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 05:29:38 GMT
From:      nsc!pyramid!athertn!joshua@decwrl.dec.com  (Flame Bait)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking For Commercial RPC Protocols
About a year and a half ago I wrote a paper comparing RPC protocols from
Sun, Apollo, and Netwise.  I'm now updating and expanding this paper,
since there have been many changes to all of those RPC systems over the 
last year and a half.

I'm looking for other commercial RPC protocols to compare.  If you know of
a such a product, please send me the companies address, phone, and email.
By commercial, I mean widely available and supported.  I may include non
commercial RPCs if they are especially interesting or important.

RPC = Remote Procedure Call 

Joshua Levy
--------                Quote: "If you haven't ported your program, it's not
Addresses:                      a portable program.  No exceptions."  
joshua@atherton.com          
{decwrl|sun|coherent}!athertn!joshua   work:(408)734-9822   home:(415)968-3718
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 07:16:22 GMT
From:      eru!luth!sunic!mcsun!ub4b!syteke!jim@BLOOM-BEACON.MIT.EDU  (Jim Sanchez)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?
One thing you want to be SURE and remember is that the ethernet on
broadband stuff has a significant distance limitation.  If your campus
cable system is a as large as I suspect, then the 10broad36 channel is
probably working more as csma than csma/cd and the effective channel
capacity is ~2 Mb not 10 Mb.  That is why we use 802.4 for backbone
applications it also uses much less bandwidth.  The UB stuff is also
just CSMA (if my memory serves me).  In both cases, the effective
channel capacity is approximately 35% of the data rate.  If you
calculate the maximum number of packets on an 802.3 channel it is
about 13,000 and scale accordingly I don't think you are overloaded
based on your numbers.  However, this is a tricky thing to find out.
-- 
Jim Sanchez          | jim@syteke.be (PREFERRED)
                     | OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems   | OR uunet!mcsun!ub4b!syteke!jim 
Brussels  
-- 
Jim Sanchez          | jim@syteke.be (PREFERRED)
                     | OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems   | OR uunet!mcsun!ub4b!syteke!jim 
Brussels  
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      30 May 1990 17:12-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        netcom!hinton@apple.com  (Greg Hinton)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What is VMTP?
> I've read bits & pieces about something called VMTP.  From what I've seen,
> it appears to be a reliable counterpart of UDP.
> Can someone explain in more depth exactly what VMTP is and/or provide
> easily available references?

VMTP is a transport-layer protocol that provides a reliable request/response
or RPC style of service, rather than the reliable stream service of TCP or
the unreliable datagram service of UDP.  As others have pointed out, it
has been described in several papers by David Cheriton of Stanford; the
protocol specification can be found in RFC-1045.

> Are there any implementations under UNIX?

Yes, there is an implementation for 4.3BSD and derivitives (SunOS, Ultrix)
that may be obtained by anonymous FTP from host gregorio.stanford.edu,
in the vmtp-ip directory.  The software is free but covered by a
Stanford license agreement, which can be found in the file vmtp.LICENSE
in that directory.

Steve Deering
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 May 90 17:48:40 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        jbloom@uhasun.hartford.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
Jon,

I think the counter argument is that if it doesn't work reliably/well
especially in the beginning then people won't rely on it to provide
communications for their everyday needs.  If they don't use it
everyday then it is luxury suitable for axing at the appropriate
belt-tightening time.

Marty
---------------
> Speaking as one who is trying to figure out how to convince management that
> $10k/yr would be well spent, I would be willing to accept service limitations
> for a lower-cost net access.  If the service truly is as useful to the
> organization as I believe it would be, the demonstration of that usefulness
> might just break loose the dollars for a higher quality ($10K) connection.  So
> providing low-cost, restricted service connections may well have the effect
> of enhancing the number of sites getting full-service connections eventually.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 May 90 15:34:19 EDT
From:      stev@vax.ftp.com
To:        "Martin Lee Schoffstall" <schoff@psi.com>
Cc:        tcp-ip@nic.ddn.mil, ka9q.bellcore.com!karn@bellcore.com (Phil Karn)
Subject:   Re: What is the IAB?
>CMOT was elevated to DIS without the above.

>Marty

after the abuse they got, i *doubt* that will ever happen again.


i never said it was perfect. they *do* do some stupid things. but, then
again, so do i . . . . .  .


-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 11:57:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   LanTastic NOS and TCP/IP

Date sent:  30-MAY-1990 07:56:35 

Hi,
	Does anyone know/have/hear of a gateway from Lantastic to TCP/IP?

Dave

================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 12:20:44 GMT
From:      mailrus!bbn.com!craig@uunet.uu.net  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>
>Indeed, SMTP's assumption that everybody's connected all the time
>doesn't work well with occasionally-connected hosts.  It would seem
>that the time is ripe for some sort of extension to SMTP to do
>receiver-initiated transfers to meet this need.  Of course you'll
>still need the MXing host to hold your mail for you.  Presumably
>getting away from uucp is one of the points of all this.

CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
a script every night which brings up the dial-up line, and then opens
a connection to a port on relay.cs.net and tells it to start delivering
mail to the site.  The application at that connection starts up the
appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
where a channel typically has messages destined for a particular site),
which delivers the mail to the site.  [Note there's no security problem
here -- anyone can start up the channel, but the channel will only deliver
to the proper remote system(s)]

Craig
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 May 90 19:03:58 -0400
From:      schoff@psi.com (Marty Schoffstall)
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   new mailing list of Commercial Internetworking Issues

A new mailing list has been created:

	comint@psi.com (to post, and respond)
	comint-request@psi.com (to be added)

To discuss commercial aspects of participation in the Internet.

Marty
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 13:20:11 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@ucsd.edu  (Jon Bloom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> 
> 	NEARnet is committed to broadening its base of support to include
> smaller sites at lower cost.  We are chafing against technical issues in
> being able to offer high quality service at lower costs, since we balance
> hardware and people costs, and people costs are not really that bandwidth
> sensitive.  We also have strict standards on quality of service, and we
> do not wish to compromise these standards in offering less costly access,
> since we know that later on our customers would regret the compromise as
> much as we.  Then there is the issue of just what is part-time access;
> is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what?  We have
> to keep in mind what services we provide and we have to make sure that
> our clients understand what they can and can't do with new service offerings.
>
Speaking as one who is trying to figure out how to convince management that
$10k/yr would be well spent, I would be willing to accept service limitations
for a lower-cost net access.  If the service truly is as useful to the
organization as I believe it would be, the demonstration of that usefulness
might just break loose the dollars for a higher quality ($10K) connection.  So
providing low-cost, restricted service connections may well have the effect
of enhancing the number of sites getting full-service connections eventually.

Jon
 
--
Jon Bloom, KE3Z -- jbloom@uhasun.hartford.edu
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 15:47:42 GMT
From:      fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net  (Kevin Paul Herbert)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip services <--> decnet connectivity, help wanted
The easiest thing to do would be to get a DECstation 3100 (or something
else running Ultrix) and use the DECnet-Internet gateway software. I
don't know many product specifics, but I know that you can use it for
remote login and file transfer. You should also be running at least
DECnet/E V4.0 (RSTS/E V9.3) as previous versions had some problems
dealing with Ultrix, if I recall correctly.

I've always thought it would be *fun* to put up TCP/IP on RSTS, though.
It really wouldn't be that hard to do for someone that was good with
RSTS monitor internals.

Kevin
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 16:35:44 GMT
From:      kmeyer@decwrl.dec.com  (Kraig Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is VMTP?
In article <12637@netcom.UUCP> hinton@netcom.UUCP (Greg Hinton) writes:
||I've read bits & pieces about something called VMTP.  From what I've seen,
||it appears to be a reliable counterpart of UDP.
||Can someone explain in more depth exactly what VMTP is and/or provide
||easily available references?
||Are there any implementations under UNIX?

VMTP was developed as a transport protocol for the V distributed system
at Stanford.  Try "VMTP as the Transport Layer for High-Performance
Distributed Systems" by David Cheriton and Carey Williamson, IEEE
Communications Magazine, June 1989, p. 37.

****************************************************
Kraig Meyer                        kraig@wrl.dec.com
On parole from the University of Southern California
My views do not necessarily represent those of DEC.
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 16:36:19 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
In article <9005300234.AA07597@psi.com>, schoff@PSI.COM ("Martin Lee
Schoffstall") writes:
> CMOT was elevated to DIS without the above.

It was my understanding that this was done by the ISO, not the IAB.  The
IAB has no authority to designate things DIS or IS.

--
Amanda Walker
InterCon Systems Corporation
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 16:42:29 GMT
From:      frooz!cfa250!cliff@husc6.harvard.edu  (Cliff Stoll)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A SUSPICIOUS SECURE GATEWAY
From henry@utzoo.uucp (Henry Spencer):
> they can't make a Unix that they can trust when it is
> administered by incompetents.  Nobody else can make such a system either.

I second that!
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 May 90 23:51:30 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        intercon!news@uunet.uu.net (Amanda Walker)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?

> It was my understanding that this was done by the ISO, not the IAB.  The
> IAB has no authority to designate things DIS or IS.

No, the "Internet" has a somewhat parallel concept with

	Draft Internet Standards (DIS)
	Internet Standards (IS)

Which is outlined in one of the RFC's, the process of standardization
is somewhat obscure.

Marty
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 17:14:47 GMT
From:      bu.edu!bu-it!kwe@eddie.mit.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <118@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu
(Jon Bloom) writes:
> In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> > We also have strict standards on quality of service, and we
> > do not wish to compromise these standards in offering less costly access,
...
> >
> Speaking as one who is trying to figure out how to convince management that
> $10k/yr would be well spent, I would be willing to accept service limitations
> for a lower-cost net access.  If the service truly is as useful to the
> organization as I believe it would be, the demonstration of that usefulness
> might just break loose the dollars for a higher quality ($10K)
connection.  So
> providing low-cost, restricted service connections may well have the effect
> of enhancing the number of sites getting full-service connections eventually.
> 
	We hear you.

	Let me elaborate on some of the costs hidden in a NEARnet service fee.
Consider these representative of a mid-level network service provider.  I
certainly don't mean this as an advertisement, but as explanation of the costs
of internetworking.  It might be helpful for someone starting from a UUCP or
BITnet point of view.

	Cost of the router on your end.  NEARnet requires that the demarcation
point be on the local LAN and not somewhere on the leased line.  In
other words,
NEARnet has to own and control the router at your site.  You have to pay for
that.  But this has proved critical to achieving service objectives.

	Cost of the router on our end.  It takes a lot of hardware to make
the NEARnet core work and provide access to NSFnet and other services.

	Leased line charges.  Leased lines are expensive and difficult to
move and change.  Fractional T1 is helping that a little, but still, we are
in large part unable to provide distance-insensitive fees, and some of our
clients pay large fees because of geography.

	Depreciation.  What does your service provider do for you when your
router is obsolete and can no longer function in an Internet?  Do they make
you pay for a new one?  NEARnet builds depreciation into its fee schedules,
so you pay for the cost of hardware and software continually, and not in a
lump sum, or worse, never.  Depreciation is critically important to a
network service provider being able to keep up with the technology.

	People costs.  It is very expensive in man-hours to run a mid-level
network, but we have found that it does not pay to scrimp on people.  I
think new network management tools will help, particularly as we gain control
of the wide area network, but it is still an expense that we feel is justified
to provide a sufficiently high level of service.  NOCs should be 24 hours
a day, seven days a week, and that will never be cheap.

	User services.  We have found it absolutely critical to be able to
offer some minimal user services to our members.  This is extremely important
to some of our clients.  Some of these services are things like name servers
for their domains and help with registration and connected-status.  But it
also includes a committment from NEARnet to take responsibility for tracking
down, identifying, and, to the extent possible, fixing users' connectivity
problems, no matter where in the Internet the problem is lurking.  This is
a service available to anyone, anywhere.  Finger @nic.near.net for details.
It also includes Dan Long's time and effort in the IETF in the User 
Connectivity Problems Working Group to try to spread this capability and 
commitment throughout the Internet.

	All this adds up to quite a chunk of change.  Makes UUCP look pretty
good, eh?      :-)

	I understand, though, that money is money and it still costs too much.
I believe the NSF is sympathetic, as they are still considering proposals for
grants to connect qualified sites to the Internet.  You may be able to turn to
the NSF for grant aid.

	It's all part of the Internet growing up, running like a business,
going private, etc.  And NEARnet is not the only mid-level network
service provider
working these issues.  More and more operational people are getting into the
IETF and there is the Federation of American Research Networks which is
populated
by the mid-level networks, among others, and is working on these sorts
of issues.

	--Kent England
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 May 90 22:07:16 EDT
From:      farber@pcpond.cis.upenn.edu (David J. Farber)
To:        stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
In reply to:

Date:    Wed, 30 May 90 15:34:19 -0400Subject: Re: What is the IAB?
From:    stev@vax.ftp.com
To:      "Martin Lee Schoffstall" <schoff@psi.com>
cc:      tcp-ip@nic.ddn.mil, karn@ka9q.bellcore.com (Phil Karn)

>CMOT was elevated to DIS without the above.

>Marty

after the abuse they got, i *doubt* that will ever happen again.

.....
============================================

If it was the wrong thing, then why haven't they rescinded the CMOT status?


Dave
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 19:12:00 GMT
From:      att!cbnewsh!eric@ucbvax.Berkeley.EDU  (eric.l.asbeck)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM 5250 support on TCP/IP
I want to connect a TCP/IP workstation and 5250-based applications
on an AS/400.  5250 is the default or native data stream supported
on the IBM AS/400 and the IBM S/3x (as opposed to the 3270 data
stream used for MVS and VM systems).  The workstation is on Ethernet
and runs HP-UX, which is compatible with UNIX System 5.2 and BSD 4.2.
The AS/400 is on a Token Ring and I know how to bridge the Token Ring
to the Ethernet.

Based on what I've learned so far, one of the following might work
if I can find the necessary components:

	1) "TN 5250" extensions to Telnet.  I know that RFC 1041
	   defines a Telnet 3270 Regime Option which supports the
	   3270 data stream within the Telnet protocol.  I've not
	   been able to find a similar regime option for the 5250
	   protocol stream.  I also understand that IBM does not
	   presently include Telnet as part of its TCP/IP support
	   on the AS/400, but that they have made a Statement of
	   Direction for it.

	2) An X-Windows 5250 emulation package for the workstation
	   which can talk directly to the AS/400 or go through an
	   intermediary system.  I'd prefer a full-blown X application,
	   but I'd consider a character-based application accessed
	   by something like xterm.

	3) Support of APPC/LU6.2 on HP-UX over the workstation's
	   Ethernet interface.  Ideally this would include support
	   for the 5250 data stream under LU6.2, but I'd be happy
	   just to find a vendor that provides the LU6.2 support.

Any pointers or suggestions would be greatly appreciated.

I don't regularly subscribe to this newsgroup, so I'd appreciate
your replying directly to me via email at the address given below.

Thanks in advance!

Eric Asbeck
AT&T Bell Labs
ela@homxb.att.com or att!homxb!ela
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 0:05:41 EDT
From:      "Robert J. Reschly Jr." <reschly@BRL.MIL>
To:        tcp-ip@nic.ddn.mil
Subject:   Namespace clashes (was: What is the IAB?)

      Good evening,

   A quick point worth noting.  I read Marty's note about CMOT being
advanced to DIS; thinking, "Yeah, it did get advanced to Draft Internet
Standard status".  I later read Amanda's note about Draft International
Standards under the same thread; again nodding in agreement. Only when I
read the next followup (again referring to Draft Internet Standards) did
I tumble -- namespace clash.

   I would propose PINS, DINS and INS where 'IN' comes from "InterNet"
but fear that is still to close to ISOese.  Maybe PIPS, DIPS, and IPS
with 'IP' coming from "Internet Protocol".  By tucking in the extra
word, the likelyhood of these acronyms being collapsed back to TLAs
(Three Letter Acronyms) is reduced.

				Later,
				    Bob 
   --------
IP: reschly@BRL.MIL   UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly
U.S. Army Ballistic Research Lab. / Systems Eng. & Concepts Analysis Div. /
Networking & Systems Dev. Team / ATTN: SLCBR-SE-A (Reschly) /
Aberdeen Proving Grounds, MD  21005-5066 / (301)278-6808   AV: 298-6808

****  For a good time, call: (303) 499-7111.   Seriously!  ****

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 22:23:00 GMT
From:      mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?

       When is an ethernet full?  ....
       According to our Network General sniffer, 
       we constantly maintain about 10-15 percent utilization or (300 - 1000
       packets per second).   How much more traffic can this network support
       before performance falls off measurably?  Any ideas?  
    
    The best place I know of to start answering this question is Boggs,
    Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233.  The
    gist of that article is that you can drive the Ethernet all the way
    to its rated capacity assuming you are careful in the way you lay out
    your network, and all your systems have good Ethernet hardware.

Thanks for the plug, Craig ... but I think you have misconstrued
our results, at least in trying to apply them to the question at hand.

True, "you can drive the Ethernet all the way to its rated capacity"
(well, at least 95% of the way) if what you are trying to do is to
make full use of the bandwidth.  This is NOT the same thing as saying
that you will have a useful network if the average load is 95%.  In
fact, as I found out last night (while running some TCP benchmarks
on our lab's main Ether) if you use 90%+ of the network between one set
of hosts, other hosts are going to suffer badly.

The reason is queueing delay.  Think of an arbitrary host with a
stream of packets it wants to send.  If the load on the network is
100%, then its output queue will grow forever and the effective delay
will become infinite.  Actually, I think you can show that the
asymptote for infinite delay happens at a load below 100%, for any
finite inter-arrival time for new packets.

What then is the "right" level at which to declare an Ethernet "full"?
That depends.  If you are running a real-time application that can
never accept a delay > 1.2 milliseconds, then you may not be able
to use an Ethernet at all.  If you are only using the net to carry
non-interactive traffic (like electronic mail) then you might get
away with an average load above 90%.  In the usual "NFS+xterm+other
stuff" kind of environment that we run, I've seen 5-second load
averages above 50% without hearing users complain, although I would
probably complain myself if the load stayed this high all the time.
If your average load (calculated over one-second intervals, as is
the usual practice) is only 15%, then you are probably not going
to notice any problems.

The point of our paper is not that you should run your net at 50%
(or 70% or 90%) utilization; we even said ``Don't try this at home.''
The point is that an Ethernet is no worse when carrying high loads
than other 10Mbit/sec multi-access LANs.
    
    In practice of course, many of the systems won't have good Ethernet
    hardware (for example, Jacobson's talk at SIGCOMM '88 indicated he'd
    found an Ethernet chipset that could only go about 6 Mbits/sec).  So
    you need to find some people out there with some good practical experience
    about when some of their systems start breaking down, to figure out when
    your network will die due to poor hardware/software.

In general, even the hosts with the full-speed ethernet interfaces
won't be using them at full speed (because most protocols are
flow-controlled at some level, and the ultimate data sources and
sinks seldom run at 10Mbits/sec.)  If you are worried about worst-case
scenarios, such as somebody like David Boggs or myself running network
benchmarks on your net, then you might want to pay attention to the
capabilities of your host interfaces.  But in most cases, your network
load comes from a composite of many slower sources, and what matters
is how many hosts you have and what fraction of them are going to
be active at once.

-Jeff
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      30 May 90 22:25:44 GMT
From:      cs.utexas.edu!texbell!moxie!hack@tut.cis.ohio-state.edu  (Greg Hackney)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NFS for NCR TOWER
In article <1332@telsys.aut.UUCP> ruef@aut.UUCP (Bernhard Ruef) writes:
>
>Does anybody know about the availability of NFS for a NCR TOWER 32/[46]X0
>running System V.3 (Release 3.00.01 in NCR speak) ?
>Bernhard D. Ruef        Ascom Autelca AG      CH-3073 Guemligen/Switzerland
>E-mail: ruef@aut.UUCP   FAX: +41 31 527 745   Voice mail: +41 31 529 602

I'm curious too. A friend at Cornell said he seemed to recollect a PD
version of NFS than ran outside the kernel.
--
Greg
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 00:12:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: What is VMTP?

> I've read bits & pieces about something called VMTP.  From what I've seen,
> it appears to be a reliable counterpart of UDP.
> Can someone explain in more depth exactly what VMTP is and/or provide
> easily available references?

VMTP is a transport-layer protocol that provides a reliable request/response
or RPC style of service, rather than the reliable stream service of TCP or
the unreliable datagram service of UDP.  As others have pointed out, it
has been described in several papers by David Cheriton of Stanford; the
protocol specification can be found in RFC-1045.

> Are there any implementations under UNIX?

Yes, there is an implementation for 4.3BSD and derivitives (SunOS, Ultrix)
that may be obtained by anonymous FTP from host gregorio.stanford.edu,
in the vmtp-ip directory.  The software is free but covered by a
Stanford license agreement, which can be found in the file vmtp.LICENSE
in that directory.

Steve Deering

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 01:07:48 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up access to Internet facilities

There's no reason, of course, why the dial-up hub can't call out.  As
long as the time to complete the call (including login) is less than
30 seconds or so, most TCPs won't care (too much).

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 01:25:50 GMT
From:      zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!aland@tut.cis.ohio-state.edu  (Colonel Panic)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re. Wollongong TCP/IP
In article <539@secola.Columbia.NCR.COM> syackey@secola.UUCP (steve yackey) writes:
>>So AT&T threw out the Lachman-based one they supply standard with S5R4
>>and supply a Woolongong-based release instead?
>
>no, when you buy 5.4 you get lachman tcp.
>when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp.

Uh, the 6386 definitely does not come with WIN/TCP automatically.  It
is an *option*, as is the Interlan solution.  You can get either
WIN/TCP 3.0 for StarLAN cards or a Racal Interlan s/w-card combo.

Note that AT&T's version of WIN/TCP is still 3.0.  Wollongong sells
3.1 themselves as the current release, and they include drivers for
a number of common ethernet cards (AT&T strips those out).  On my
6386s, I'm running Wollongong's own 3.1 version on WD cards because I have
to use interrupt 2 (=9), and WIN/TCP 3.0 doesn't handle that interrupt
properly...

--
Alan Denney # Informix # aland@informix.com # {pyramid|uunet}!infmx!aland

 "These tests will have no effect on your grades.  They will merely
  determine your future social status and financial success, if any."
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 01:40:41 GMT
From:      cs.umn.edu!wsmith@ub.d.umn.edu  (Warren Smith [Randy])
To:        tcp-ip@nic.ddn.mil
Subject:   Re: When is an ethernet full?
In article <56724@bbn.BBN.COM> craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) writes:
>> When is an ethernet full?  ....
>
>The best place I know of to start answering this question is Boggs,
>Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233.  The
>gist of that article is that you can drive the Ethernet all the way
>to its rated capacity assuming you are careful in the way you lay out
>your network, and all your systems have good Ethernet hardware.
>
....
>
>Craig

One thing to remember - while Boggs, Mogul and Kent's article shows that
the Ethernet will run right up to saturation (~95% depending on packet
size and number of stations), it does not fully address the matter of
delay.  Delay increases as your Ethernet becomes more heavily loaded.
BMK's measurement of delay does not include measurement of queueing
delays, and thus underestimates the real delays that will be seen by
many hosts (and users) on your network.

I have seen real Ethernets running more than 40% load (averaged over
1 hour!, bursts up in the 80-95% range).  Most of those nets aren't
around any more - they've been split to improve performance.  These
networks were (and are) growing, so they would have had to split at
some point anyway.   When you should split depends on what the needs
are for your network, and what the growth rate is.

-Randy
-- 
Randy Smith
wsmith@umn-cs.cs.umn.edu
...!rutgers!umn-cs!wsmith
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 02:52:44 GMT
From:      deimos.cis.ksu.edu!dino!cs.iastate.edu!hascall@uunet.uu.net  (John Hascall)
To:        tcp-ip@nic.ddn.mil
Subject:   Trying to write a bootp client for Ultrix

   I am working on a bootp client which I hope to use as follows (in
/etc/rc.local):

     ifconfig `bootp-client`

The aim of the program is to produce a string like the following:

     se0 129.186.1.62 netmask 255.255.255.0 broadcast 129.186.1.255

The client program creates a datagram socket, but when it attempts
to bind (to addr=INADDR_ANY, port=BOOTP) it fails unless I preceed
the bind with a SIOCSIFADDR (set address) ioctl call%.  Herein lies the
problem: the whole reason for this program is to discover the address!

If I just stick in a bogus address (say 129.186.0.0) I get the bootp
request sent fine, but I don't receive the reply.  I have tried all
sorts of things but none have worked...

   ...does any one have any ideas on how to make this work?

Thanks again,
John Hascall   hascall@atanasoff.cs.iastate.edu

% according to man side effect of SIOCSIFADDR is to initialize the interface
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 08:55:28 EDT
From:      Frank J. Robey <fjr@ulana.mitre.org>
To:        tcp-ip@nic.ddn.mil
Subject:   Re-posting of question on National Voluntary Lab Program


I posted this question several weeks ago and never received any replies so I'll
assume that there has been no interest in having products undergo this testing.
Haven't any of you that sell products to the Government been asked to certify
your products?? 

>I was wondering if anyone has had any experience with the NVLAP Testing? If
>so, how much work was involved in preparing your component for testing, what
>the results were and how accurate you felt that the tests were.

>Frank J. Robey
>The MITRE Corporation
>fjr@mitre.org
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Thu May 31 13:22:04 1990
From:      robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;)
To:        tcp-ip@nic.ddn.mil
Cc:        ath@ptt.lcs.mit.edu
Subject:   re: toll restrictors
In response to my recent posting about using a software product rather
than a toll restrictor to control outbound connectivity, Andrew Heybey writes:

> I'm curious as to what you mean by "turn off telnet".  Of course, I don't 
> know what sort of system you're running and what sort of capabilities it 
> provides, but on a unix system, telnet is a user program that opens a 
> socket.  If you remove the telnet program, all I have to do to get that 
> capability back is get the source to a telnet program from somewhere and 
> compile it in my home directory.  Voila, I can telnet anywhere I want to.  
> I can do the same with ftp (in fact, I would write a crude ftp first so as 
> to be able to go get a better ftp and telnet from someplace else).  Does 
> your system not allow unprivilidged users to open network connections?  Are 
> you relying on nobody knowing how to write/compile/etc their own program to 
> use the net?  Or does your system have some other mechanism for controlling 
> network access?

Good question - nothing's ever as simple as it sounds, is it?  By 'turn off',
I mean we change permissions so only a trusted group of individuals can use
it - not the user population at large.  We protect telnet, ftp, cu, tip, and
the compilers and debuggers this way.  We also have daily reports showing who
is using these functions.  Rather than digress into a diatribe about system 
administration, I'll just say that our philosophy is not to deny service to 
our users, but to be fully accountable.  Certain users need to use these 
compilers, debuggers and communications (other than we have provided by menu 
access) for valid purposes.  We allow them to use them, but they must prove 
a valid need.  And, they know that we regularly monitor these activities.  
Running the system this way provides full functionality for all users (based 
on a valid need), and yet maintains full accountability of our connectivity 
with other systems.

Bob Johnson, System Administrator
Tinker Air Force Base, Oklahoma
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 10:33:47 EDT
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Subject:   LANWatch dumps of OSI ES-IS, CLNP/TP traffic wanted
I asked this on comp.protocols.iso and got no replies...

I tested our LANWatch product's OSI parsers at InterOp, but when I got
home I discovered that the only CLNP packets I'd saved were an
artifact of a router bug, and weren't adequate as examples or for
further testing.  Any LANWatch owners who have CLNP traffic on their
local nets (802.5 or Ether), and would be willing to make me a few
dump files, please reply via e-mail.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 11:46:30 EDT
From:      stev@vax.ftp.com
To:        intercon!news@uunet.uu.net  (Amanda Walker)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
>In article <9005300234.AA07597@psi.com>, schoff@PSI.COM ("Martin Lee
>Schoffstall") writes:
>> CMOT was elevated to DIS without the above.
>
>It was my understanding that this was done by the ISO, not the IAB.  The
>IAB has no authority to designate things DIS or IS.
>
>--
>Amanda Walker
>InterCon Systems Corporation


marty was refering to Draft Internet Standard, while you are refering to
Draft International Standard.


-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 15:03:10 CDT
From:      MAINT@ASNTSU.asn.net
To:        tcp-ip@nic.ddn.mil
In-Reply-To:  usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF AT ucbvax.Berkeley.EDU
           -- 31 May 90 12:45:41 GMT


I have only been subscribed to this list for a short time and the discussions
seemed to be at a professional level. This looks to me like an unauthorized
hacker. Can I assume this is atypical of this list?

It seems someone is adding fuel to the flames being sent about dial-up
access to the internet. This certainly points out the need for tracability
if it is unauthorized.

>HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND
>MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R
>NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!!
>I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON
>IC0WABUNGA!!
>
>------
>BIFF@BIFFVM.BIT.NET
>BIFF+@ANDREW.CMU.EDU
>BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 May 90 22:06:50 -0700
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        "Martin Lee Schoffstall" <schoff@psi.com>
Cc:        jbloom@uhasun.hartford.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

	 
	 .
	 .
	 .
	 I think the counter argument is that if it doesn't work reliably/well
	 especially in the beginning then people won't rely on it to provide
	 communications for their everyday needs.  If they don't use it
	 everyday then it is luxury suitable for axing at the appropriate
	 belt-tightening time.
	 
	 Marty


Marty, I think John was trying to espouse the "crack dealer's" approach
to Internetting.  First, you give them a little something either free or
very low in cost.  Then, once they are hooked, you stick it to them with
high cost, high performance solutions, and by this time, they are screaming
for more and can't do without.  They will pay and and pay at this point.

Those of us who work in the government side of networking don't use this exact
tactic, but I know of many large organizations who were "hooked" this way...

					Thanks,
					    Milo
	 
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 12:08:39 GMT
From:      galbp!bagend!bvsatl!root@gatech.edu  (Super user)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Query - Ethernet collisions
In article <98@fedeva.UUCP>, bill@fedeva.UUCP (Bill Daniels) writes:
> We recently acquired an Exelan LANalyzer.  During our first uses of it,
> we noticed that about 40% of the packets on one ethernet segment (which
> is remotely bridged to another)

> Any clues?
> 
> bill daniels
> federal express, memphis, tn
> {hplabs!csun,mit-eddie!premise}!fedeva!bill

I had a similiar problem in the past. After much hair pulling, we
found that you can not cascade DELNIs. That is, don't put the
drop cable from a DELNI into a DELNI more than one level deep.

While this may not be your problem, it sounds similiar. If this is not
it, you may want to check cable lengths, cable types (ie rg58), etc.


Bill VerSteeg
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Thu May 31 12:30:44 1990
From:      cctal!andrew@relay.EU.net
To:        tcp-ip@nic.ddn.mil
Cc:        cctal!andrew@relay.EU.net
Subject:   SLIP Information
SLIP fans, old and new
Having been watching the traffic for the past few weeks and noticed all
the people looking for more info on SLIP, I think it's high time something 
was done about this, so (I'll probably regret this) I volunteer!
Apart from the fact that I am looking for the same thing (and have had 
some modest success) I think it is a worthwhile exercise.

So, I will undertake to prepare a summary for the net on SLIP and its 
availability and use. What I want to do this is info from SLIP users.
All those of you out there using SLIP, please email me summaries of:
   Equipment
   Configuration
   SLIP software version, where you got it etc
   Usage
   Problems
   Any other info
In particular, I think people wanting SLIP are looking for the PC + modem 
to Brand X UNIX box solution - feel free to correct me if I am wrong.

No summary of SLIP would be complete without reference to ka9q and ppp, 
so info from actual users of these is solicited as well.

Please do not send source code, RFCs, or long specifications of any sort, 
user experiences and known locations (USA, UK and Europe) of SLIP code is 
what is wanted.

Look forward to hearing from you

Andrew Hardie
London, England

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 12:45:41 GMT
From:      usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF@ucbvax.Berkeley.EDU  (THE BIFFMAN COMETH)
To:        tcp-ip@nic.ddn.mil
Subject:   C0WABUNGA!!
HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND MY
MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R
NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!!
I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON
IC0WABUNGA!!
 
------ 
BIFF@BIFFVM.BIT.NET
BIFF+@ANDREW.CMU.EDU
BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 14:52:05 GMT
From:      csusac!csuchico.edu!robin@ucdavis.ucdavis.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip services <--> decnet connectivity, help wanted
In article <18409@hercules.csl.sri.com> kph@dirt.cisco.com (Kevin Paul Herbert) writes:
>The easiest thing to do would be to get a DECstation 3100 (or something
>else running Ultrix) and use the DECnet-Internet gateway software. I
>don't know many product specifics, but I know that you can use it for
>remote login and file transfer. You should also be running at least
>DECnet/E V4.0 (RSTS/E V9.3) as previous versions had some problems
>dealing with Ultrix, if I recall correctly.
>
>I've always thought it would be *fun* to put up TCP/IP on RSTS, though.
>It really wouldn't be that hard to do for someone that was good with
>RSTS monitor internals.
>
>Kevin

I also spent a long time looking for a TCP/IP implementation for RSTS.
After giving up on that, I looked at the solution described above, i.e.
an Ultrix VAX as a gateway.  All you need to run on it is DECnet-Ultrix.
This automatically does conversion between DECnet protocols and TCP/IP
protocols (according to DEC). Get DEC's "Local Area Network Solutions
Guidebook" and read page 74.

Well, in the end we decided that this solution was too indirect and
ended up replacing our three RSTS systems with a VAX 6310!  Too bad
there wasn't a real TCP/IP solution for RSTS.  I kinda miss it...

Robin Goldstone,  Systems Software Specialist
California State University, Chico  Computing Services
robin@csuchico.edu
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 15:29:58 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Namespace clashes (was: What is the IAB?)
In article <9005310005.aa26406@SPARK.BRL.MIL>, reschly@BRL.MIL ("Robert J.
Reschly Jr.") writes:
> I read Marty's note about CMOT being
> advanced to DIS; thinking, "Yeah, it did get advanced to Draft Internet
> Standard status".  I later read Amanda's note about Draft International
> Standards under the same thread; again nodding in agreement. Only when I
> read the next followup (again referring to Draft Internet Standards) did
> I tumble -- namespace clash.

I do apologize for that--I must admit that I hadn't seen the Internet version
written as a TLA recently, and so the ISO interpretation was in my mental
cache, reinforced by the fact that I think of CMOT as an ISO protocol that
some strange people just happen to run over TCP :-).

Sorry for any confusion...

--
Amanda Walker
InterCon Systems Corporation
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 17:22:34 GMT
From:      silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tn3270 daemon?
In article <90145.140551HATHAWA@gecrdvm1.crd.ge.com> HATHAWA@gecrdvm1.crd.ge.com (Barry Hathaway) writes:
>In article <45793@iuvax.cs.indiana.edu>, hughes@silver.ucs.indiana.edu (larry
>hughes) says:
>>
>>Does anyone know of a tn3270 daemon, somewhat of a hybrid between
>>telnetd and (reverse) tn3270?  I'm fairly certain there's no such
>>animal, but if there is we'd have a good use for it.
>>
>Many TCP/IP packages for IBM mainframes offer terminal emulation on the host
>side - which I guess could be called a tn3270 daemon. Fibronics (aka Sparticus)
>KNET package has this as an option.  Simware offers SIM/TCPIP an add-on to
>IBM's TCP/IP package which does terminal emulation.

Yes, thanks for the information, but I was aware of these.  My question
still stands in spite of them!  Thanks, and I request further responses...

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||        hughes@ucs.indiana.edu        ||
||        Indiana University         ||                                      ||
||   University Computing Services   ||   "The person who knows everything   ||
||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
||      Bloomington, IN  47405       ||                                      ||
||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
 \\==========================================================================//
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 20:03:10 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

In-Reply-To:  usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF AT ucbvax.Berkeley.EDU
           -- 31 May 90 12:45:41 GMT


I have only been subscribed to this list for a short time and the discussions
seemed to be at a professional level. This looks to me like an unauthorized
hacker. Can I assume this is atypical of this list?

It seems someone is adding fuel to the flames being sent about dial-up
access to the internet. This certainly points out the need for tracability
if it is unauthorized.

>HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND
>MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R
>NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!!
>I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON
>IC0WABUNGA!!
>
>------
>BIFF@BIFFVM.BIT.NET
>BIFF+@ANDREW.CMU.EDU
>BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 21:14:14 GMT
From:      elroy.jpl.nasa.gov!usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@decwrl.dec.com  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005302148.AA02245@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>I think the counter argument is that if it doesn't work reliably/well
>especially in the beginning then people won't rely on it to provide
>communications for their everyday needs...

True in general, but one must beware of thinking of "reliably" and "well"
as Booleans.  Uucp mail is unreliable and ungodly slow by Internet
standards, but vast numbers of sites found it reliable *enough* and
workable *enough* to come to rely on it very extensively.

The reason why a zoology department (!) was a major networking hub
at U of T for some years was that everybody else was so obsessed with
Internet (or better) performance that they wouldn't even look at silly
ideas like networking via low-speed modems.  We set up our phone links
and started shipping mail and news, and pretty soon half the campus
had uucp links to us.  Half a loaf is much more nutritious than none.
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      31 May 90 23:14:45 GMT
From:      paperboy!meissner@think.com  (Michael Meissner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005301640.6.142@cup.portal.com> jb.loom@uhasun.UUCP
writes:

| In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
| > 
| > 	NEARnet is committed to broadening its base of support to include
| > smaller sites at lower cost.  We are chafing against technical issues in
| > being able to offer high quality service at lower costs, since we balance
| > hardware and people costs, and people costs are not really that bandwidth
| > sensitive.  We also have strict standards on quality of service, and we
| > do not wish to compromise these standards in offering less costly access,
| > since we know that later on our customers would regret the compromise as
| > much as we.  Then there is the issue of just what is part-time access;
| > is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what?  We have
| > to keep in mind what services we provide and we have to make sure that
| > our clients understand what they can and can't do with new service offerings.
| >
| Speaking as one who is trying to figure out how to convince management that
| $10k/yr would be well spent, I would be willing to accept service limitations
| for a lower-cost net access.  If the service truly is as useful to the
| organization as I believe it would be, the demonstration of that usefulness
| might just break loose the dollars for a higher quality ($10K) connection.  So
| providing low-cost, restricted service connections may well have the effect
| of enhancing the number of sites getting full-service connections eventually.

If all you currently want is SMTP and FTP initially, then uunet may be
a way to start.  They obviously will do mail, but another service they
offer to paying customers is to do anonymous FTP's on request, and
UUCP it to your machine.  When I was at Data General, and the internet
connection was extremely flakey (it did get better before I left), I
begged, pleaded, and such to management to establish such a UUNET
connection and buy the Telebit Trailblazer modem.  I was able to get
GCC releases and prereleases in a timely manner (though there was the
time when I couldn't keep an internet connection or modem connection
open long enough, thanks to the lousy GTE phone service in the RTP
area of North Carolina or the lousy internal DG phone service).

The last time I looked, the uunet charges where $35/month, $2/hour if
you called their local number (using company WATTS lines if you have
them), or $16/hour if you used their 800 number.  A Telebit T2500
modem sells in the range of $1000.  Obviously this is subject to
change, as is their willingness to do anonymous FTP's for you (though
they have most of the stuff people want directly on uunet).
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so

END OF DOCUMENT