The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for April 1989 (357 messages, 170467 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/04.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 Apr 89 00:17:58 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

In article <8903301431.AA19142@TIS.COM> balenson@TIS.COM (David M. Balenson) writes:
>Is it possible to implement TCP/IP in a UNIX (Berkeley 4.{2,3}, SunOS{3,4})
>system OUTSIDE of the kernel?  I presume doing so would have a major impact
>on efficiency, but it might be much easier to program.  Does anyone know o
>any such TCP/IP implementations?  Thanks.

Phil Karn's KA9Q TCP/IP implementation can run as a user process
under most flavors of UNIX, although I wager that only those folks
without a TCP/IP implementation on a machine would bother.  I got it
running under XENIX 386 with SLIP last year, although I never really beat
on it hard.  At the time it was a monolithic program and didn't provide
a socket application library, so it was mainly of tutorial interest to me.
I haven't examined it lately.

It is available for non-commercial use via anonymous FTP on bellcore.com
in the pub/ka9q directory.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 89 00:52:49 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

A number of years ago, 3Com marketed a product called UNET, an implementation
of TCP/IP that had IP in the kernel, but TCP in user space on UNIX systems.
It ran on V7, 4.1bsd, and derivatives; I (among others, I think) ported it
to System V of various flavors.  Among the debts the Internet community
owes to this implementation is SLIP; Rick Adams' original SLIP was
designed to be compatible with UNET's equivalent.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 89 03:07:38 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: syntax of remote pathnames?

In article <93400016@p.cs.uiuc.edu> zweig@p.cs.uiuc.edu writes:
+---------------
| /* Written 11:18 pm  Mar 28, 1989 by rpw3@amdcad.AMD.COM
| 	% <F3>
| 	...and the script named "<^A>c<CR>" runs...
|                           ^^^^^^^^^^^^^^^^
| Uh-uh. The script named "<^A>c" runs, since the <CR> tells the shell
| about the end of the input line.
+---------------

Oops! (*blush*) You're right, of course.

("That <CR> just crawled into my hand, honest...")


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 89 05:00:01 GMT
From:      seven@ftam.com (Benjamin M. Levy, FTAM Hardware Inc.)
To:        comp.protocols.tcp-ip
Subject:   LAWNWatch

FTAM Hardware, Incorporated
26 Princess St
Wakefield, MA

Press Release
Hold Until 4/1/89

Press contact:
Benjamin Levy
(617) 246-0900



L A W N W A T C H 
- - - - - - - - -


  The LATEST in LAWN Management systems.


  LAWNwatch allows you to examine the traffic across your LAWN.


  LAWNwatch understands many types of traffic, such as:

    - TCP/IP: Turf Control Procedure for Insect Prevention.

    - ICMP:   Insecticide Control, Managment, and Procuring.

    - SNMP:   Seedling Nurturing and Maintainance Program.

    - SMTP:   Soil Manure Treatment Procedure.

    - TFTP:   Tree Foliage Trimming Practices.

    - FTP:    Fertilizer Transfer Procedure.

    - UDP:    Underground Dirt Placement.

    - ADP:    Aphid Detection Procedure.

    - ATP:    Aphid Termination Procedure.

    - CIA:    Control of Insect Activity.

    - KGB:    Kentucky Grass: Blue.

    - RVD:    Real Virtual Dirt.


    Compatible with pARCNET, TENNIS-Net, DECK-Net, and Vines.
LAWNWatch works with Underground-Bass and Eastern Dig-It-All earthnet
cards.  LAWNWatch is not compatible with IBM's (International Bug and
Mushroom) Toadstool Ring Adapter.

    LAWNWatch is based upon RFC (Request For Compost) 825 written
by J. Post-Hole.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 89 00:07:37 GMT
From:      daveb@geaclib.UUCP (David Collier-Brown)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Unaligned Accesses & comms.


  Well, it looks like for instructions and data with the current
technologies, alignment of data makes good sense and architectural
support for misaligned accesses is not a good use for silicon.

  But what about in the communications realm?  Current packet
formats are rather heavily "packed", sufficiently so that one wants
to treat them as collections of bits of various lengths (usually
even, often powers of two, etc).

  Two possibilities arise:
	Communications will be pushing physical transmission-speed
limits and central processors will continue to get faster, faster.
With processor time available for unpacking, packets will be
densely packed,
   or
	Processing speeds will peak out sooner than transmission
speeds in the near term, and there will be a need to design
communications packet formats so they **aren't** an
expanding-opcode scheme.  In this scenario I'm not suggesting any
holes are likely to appear, but I do expect most of the fields at
the beginning of the (outer!) packet will be of fixed size and
unchanging interpretation.

  Would anyone with very-high-speed comms experience care to comment
on the ratio of development speeds?  And does special-purpose
hardware make any sense in this context...

--dave
-- 
 David Collier-Brown.  | yunexus!lethe!dave
 Interleaf Canada Inc. |
 1550 Enterprise Rd.   | He's so smart he's dumb.
 Mississauga, Ontario  |       --Joyce C-B

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 89 13:51:34 GMT
From:      tar@ksuvax1.cis.ksu.edu (Tim Ramsey)
To:        comp.protocols.tcp-ip
Subject:   Re: LAWNWatch

I get it.  It's a joke, right?

--
Timothy Ramsey                               Kansas State University
BITNET:   tar@KSUVAX1              Dept. of Computing and Information Sciences
Internet: tar@ksuvax1.cis.ksu.edu          Office of Unplanned Reboots
UUCP:  ...!{rutgers,texbell}!ksuvax1!tar     Division of Lost Inodes

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 16:40:51 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Telnet DO Option 30


Telnet option 30 is the "X.3 PAD" option described in RFC-1053.

--jon.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 16:51:06 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Super Cheap IP router (< $1000)


Hello All,

I have developed software for Turning a klunky old IBM XT into
a IP router.  Below is a description of the software I wrote.
The software is available via anonymous FTP from accuvax.nwu.edu
(129.105.49.1) in the directory pub/pcroute.  

We here at Northwestern have found this program to be very useful
Already we have replaced a major Hub in our network with a PCrouter
and others additions/substitutions are planned.  

If you find this program useful, let me know, it helps my ego (:-).


Vance

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

	    PCROUTE - and IP routing program from the IBM PC
		 	     Vance Morrison
			morrison@accuvax.nwu.edu

    Traditionally IP routers have been fairly high performance,
expensive machines.  Typically they run about $5000-$10,000 a unit.
Until now a IP router for under $5000 was just about impossible
to get.  Recent developments in PC hardware, however, has made
it possible to convert a PC to an IP router for a TOTAL of $800-$1000
a unit.  This price is less that the cost of many ethernet boards
and thus it now makes sense to always use dedicated router to
perform IP gatewaying functions.  

---------------------------------------------------------------------
What is PCroute?

    PCroute is software written for an PC/XT (or AT) that will 
allow it to act as a IP router that will gateway between the following
kinds of Physical media.

	Ethernet - Ethernet
	Ethernet - Starlan
	Starlan - Starlan

   In addition to the XT, the only other hardware needed are the
networking cards, which at present run about $200-$250 a piece.  
Since you can buy an XT (without an monitor) for $400, the total
cost for the hardware is $800-$900.  

---------------------------------------------------------------------
What do I need to install PCroute?

	1) An XT computer (does not need monitor)
	2) 2 Western Digital WD8003 network cards
		WD8003E		Ethercard Plus
		WD8003S		Starcard Plus
		WD8003SH	Starlink Plus

---------------------------------------------------------------------
How Fast is PC route?

    Some may argue that a PC simply is not fast enough to be a
good IP router.  This would true if the PC had to do all the work,
but in fact, the ethernet cards do most of the work.  All the
PC needs to do is determine the route, and copy the packet from
one interface to the other.  By programming in assembler and 
optimizing for peak efficiency, the PC is up to the task.  

    Actual tests indicate that that following formula is a
worst case estimate of throughput of PCroute on a 4.77Mhz XT

	packet_delay = .473 + .00393 * len	msec

   Where 'len' is the length of the packet in bytes.  Thus
PCroute has a fix per packet overhead of .473msec and takes
3.93usec/byte to transfer the packet from one network to the
other.  
 




    Thus for the largest packet size (1514) we get throughput of 

	packet_delay = .473 + .00393 * 1514 = 6.4 ms
	throughput = len*8/packet_delay = 1.9 Mbit/sec

    For the smallest packet size (64) we get a throughput of

	packet_delay = .473 + .00393 * 64 = .724 ms
	throughput = len*8/packet_delay = .7 Mbit/sec

   If you were to buy a XT clone, (even the $400 variety) it
would undoubtedly be a 8Mhz or 10Mhz machine, so you should
expect to do 1.6 and 2.0 times better respectively with these
machines.  I most strongly suggest that you get the 10Mhz variety
since they are usually only $30 more and will give you a 12%
performance boost

   In addition the Ethernet boards have an on-board 6.5K packet
buffer.  Thus packets that come at the PCrouter too fast for
it to process will be queued.  The router will start dropping
packets after this 6.5K buffer is exhausted.

   Note that since SUN NFS likes to send 8K blocks in fast spurts
this will sometimes cause the router to drop packets.  I suggest
that you set this block size down to 4K if you expect a lot of
NFS traffic through the router (look for 'wsize' in man fstab).

---------------------------------------------------------------------
What PC route supports?

   PCroute was designed to be as simple as possible yet perform
well as a IP router.  In particular it supports

	1) IP routing with Subsets (however the subnet mask
	   must begin with 255.255)
	2) Static routing with up to 250 routes.
	3) responds to ICMP echo (ping) 
	3) Directed broadcasts 

   The PCrouter also has support for more than two network interfaces,
but this requires recompilation of the code, so for now you will have
to contact me.

---------------------------------------------------------------------
What PC route DOESN'T support?

	1) Dynamic routing (yet)
	2) Booting off the network (BOOTP) (yet)
	3) Any IP services besides routing and ICMP echo.
	4) Any other Ethernet/starlan card besides Western 
	   Digital WD8003

 






---------------------------------------------------------------------
Coming Soon.

	1) RIP Support
	2) Appletalk - Ethernet Support (like a KIP box but you can
	   tunnel IP packets through the Appletalk network) Here at
	   NU we use this so that we can get cheap, reasonably fast
	   network access between buildings.
	3) Network Booting a la BOOTP
	4) The other ICMP functions so that router conforms to RFC1009

---------------------------------------------------------------------
Hints

	1) We found that the 10Mhz XT clones that Jamco and others sell
	   work very well.  One nice feature about these units is their
	   BIOS.  By setting the dip switches in the PC, you can tell it
	   that there is no Monitor.  This also tells the BIOS not to
	   check for a keyboard either.  Thus you don't need to buy either
	   the keyboard or the monitor.  Other XT BIOS ALWAYS check for
	   the keyboard, and thus you have to plug it in even though you
	   never use it.

---------------------------------------------------------------------
Reliability

	The reliability of PCroute has been EXCELLENT.  We have been
	using these routers for months now in three places with 
	absolutely no failures.   If you wish to PING one for yourself
	here are some PC routers on our campus

		129.105.49.13
		129.105.1.1
		129.105.7.1

---------------------------------------------------------------------
Comments and Bug reports

	I am interested in finding out what you think of PCroute and
	how well it performs for you.  I am also interested in hearing
	about any problems you have or bugs in the documentation.
	You should send your comments to 
		
		Vance Morrison <morrison@accuvax.nwu.edu>

	Note that since I am not paid to support this software, I can
	not guarantee that I can respond to your problem, but I will
	try.


						Vance Morrison
						Northwestern University

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Apr 89 23:36:39 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!mcvax!kth!sunic!maxim!prc
From: prc@maxim.ERBE.SE (Robert Claeson)
Newsgroups: comp.protocols.tcp-ip,comp.sys.encore
Subject: Re: An Annex by any other nameserver would smell...
Message-ID: <636@maxim.ERBE.SE>
Date: 3 Apr 89 19:52:43 GMT
References: <68@a.coe.wvu.wvnet.edu> <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>
Organization: ERBE DATA AB
Lines: 15


In article <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes:

> BIND is the name of the Berkeley program that implements the IP
> Domain Name Service on UNIX.  This is really what people ought
> to be using these days, and is really required if you are in a
> large network environment or are connected to the Internet at large.

Where can I find a good implementation of it for System V systems with
sockets and/or TLI?

-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20
EUnet:   rclaeson@ERBE.SE               uucp:   {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET  BITNET: rclaeson@ERBE.SE
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 19:52:43 GMT
From:      prc@maxim.ERBE.SE (Robert Claeson)
To:        comp.protocols.tcp-ip,comp.sys.encore
Subject:   Re: An Annex by any other nameserver would smell...

In article <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes:

> BIND is the name of the Berkeley program that implements the IP
> Domain Name Service on UNIX.  This is really what people ought
> to be using these days, and is really required if you are in a
> large network environment or are connected to the Internet at large.

Where can I find a good implementation of it for System V systems with
sockets and/or TLI?

-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20
EUnet:   rclaeson@ERBE.SE               uucp:   {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET  BITNET: rclaeson@ERBE.SE

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 19:55:40 GMT
From:      doug@ICASE.EDU (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   System V mail

Does anyone know of any features of System V mail (or mailx) which allow
interactive debugging similar to mail -v in Berkely mail? I'm looking
for something a little easier than telnetting to the SMTP port.

I'll summarize to the net.

Thanks in advance.

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 864-2172
FTS: 928-2172
doug@icase.edu

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 20:09:06 GMT
From:      pcg@aber-cs.UUCP (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

In article <8903301431.AA19142@TIS.COM> balenson@TIS.COM (David M.
Balenson) writes:

    Is it possible to implement TCP/IP in a UNIX (Berkeley 4.{2,3},
    SunOS{3,4}) system OUTSIDE of the kernel?

If you want to create a TCP/IP server, you have two problems; how to
make it communicate with the network interface, and how with its
clients.  The first is fairly easy (euphemism). The second is easy, but
requires use of UNIX domain connections.

The server has a UNIX domain port on which it listens for requests to
open TCP/IP connections, etc... On receiving such a request, it creates
a new UNIX domain socket pair, and passes one end to the requestor
using the UNXI domain fd-in-a-message passing facility. It keeps a
table of TCP/IP addresses vs. UNXI domain connections opened.

Whenever the client writes something on its UNIX domain connection to
the server, the table is used in one way, and all data read from that
fd is sent off to the network interface using the associated TCP/IP
address; when data arrives from the network interface, the table is
used to map the TCP/IP address to the appropriate fd.

    I presume doing so would have a major impact on efficiency,

Yes and No. Of course a TCP/IP server (of for that matter, any protocol
server written in that way) means that on every message send you have
two task switches extra and daya copies, but for that there is no other
overhead. If TCP/IP is infrequently used, the server gets paged out, so
more real memory is available.

Overall I'd expect lower performance, but on an OS designed for this
style of implementation this need not be true.

    but it might be much easier to program.

Oh yes, of course. And, most importantly, you can have multiple
servers, and change them dynamically etc...

    Does anyone know o any such TCP/IP implementations?  Thanks.

The key to this whole business is to have the ability to pass fds in
messages from one process to another in the UNIX domain.

This facility has been copied from the excellently designed (by Richard
Rashid) Accent IPC facility, that can be now found in Mach. Also,
Edition 8/System V STREAMS have this ability, precisely for this
reason. Amoeba has an equivalent facility, even if I don't like
the way it is designed.

As far as I know Accent (or even Mach) network IPC is implemented
(optionally) using servers.

Note also that the unimplemented (and exceptionally difficult to
understand) user implemented domains facility of 42BSD (and in some way
wrappers) were "designed" (hackerly -- after all one of the principal
architects was Dr. Joy :-]) to enable this.

Overall, I'd suggest you look at MACH. It was designed (well -- after all
one of the principal architects was Dr. Rashid) around this idea.

You can even look at these fds that get passed around in messages
as capabilities, and build a fully distributed (and secure) capability
based system using this style.
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 20:52:13 GMT
From:      mikes@zephyr.ENS.TEK.COM (Mike Skrydlak)
To:        comp.protocols.tcp-ip
Subject:   Appletalk (flash-card) driver for NCSA telnet for PCs ?

I'm looking for a flash-card driver for NCSA telnet for the PC. I can
anonymous ftp if I get a dotted decimal internet address - we don't
quite have name server access yet.  Thank you again for your support.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 01:42:28 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!tektronix!zephyr!mikes
From: mikes@zephyr.ENS.TEK.COM (Mike Skrydlak)
Newsgroups: comp.protocols.tcp-ip
Subject: Appletalk (flash-card) driver for NCSA telnet for PCs ?
Message-ID: <2765@zephyr.ENS.TEK.COM>
Date: 3 Apr 89 20:52:13 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 3


I'm looking for a flash-card driver for NCSA telnet for the PC. I can
anonymous ftp if I get a dotted decimal internet address - we don't
quite have name server access yet.  Thank you again for your support.
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 89 23:05:00 GMT
From:      7thSon@SLCS.SLB.COM (Chris Garrigues)
To:        comp.protocols.tcp-ip
Subject:   re: Telnet DO Option 30


    Date: Mon, 3 Apr 89 09:40:51 PDT
    From: postel@venera.isi.edu


    Telnet option 30 is the "X.3 PAD" option described in RFC-1053.

    --jon.

Sorry Jon, but he was asking about octal 30 (decimal 24), not decimal
30.  Suns try to negotiate terminal type, RFC-930.

Chris

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 00:07:27 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

In article <583@accuvax.nwu.edu.NWU.EDU> morrison@accuvax.nwu.edu (Vance Morrison ) writes:
>I have developed software for Turning a klunky old IBM XT into
>a IP router...

Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP
for the PC/XT/AT/...?  I can't see any reason why Phil's stuff wouldn't
make a perfectly good router; were you aware of its existence?
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 05:40:40 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Super Cheap IP router (< $1000)
Message-ID: <1989Apr4.000727.2759@utzoo.uucp>
Date: 4 Apr 89 00:07:27 GMT
References: <583@accuvax.nwu.edu.NWU.EDU>
Organization: U of Toronto Zoology
Lines: 10


In article <583@accuvax.nwu.edu.NWU.EDU> morrison@accuvax.nwu.edu (Vance Morrison ) writes:
>I have developed software for Turning a klunky old IBM XT into
>a IP router...

Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP
for the PC/XT/AT/...?  I can't see any reason why Phil's stuff wouldn't
make a perfectly good router; were you aware of its existence?
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 06:11:38 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!ICASE.EDU!doug
From: doug@ICASE.EDU (Doug Peterson)
Newsgroups: comp.protocols.tcp-ip
Subject: System V mail
Message-ID: <8904031955.AA13198@work1.icase.edu>
Date: 3 Apr 89 19:55:40 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 17


Does anyone know of any features of System V mail (or mailx) which allow
interactive debugging similar to mail -v in Berkely mail? I'm looking
for something a little easier than telnetting to the SMTP port.

I'll summarize to the net.

Thanks in advance.

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 864-2172
FTS: 928-2172
doug@icase.edu
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 06:11:39 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!SLCS.SLB.COM!7thSon
From: 7thSon@SLCS.SLB.COM (Chris Garrigues)
Newsgroups: comp.protocols.tcp-ip
Subject: re: Telnet DO Option 30
Message-ID: <19890403230504.1.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>
Date: 3 Apr 89 23:05:00 GMT
References: <8904031640.AA00224@bel.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 13



    Date: Mon, 3 Apr 89 09:40:51 PDT
    From: postel@venera.isi.edu


    Telnet option 30 is the "X.3 PAD" option described in RFC-1053.

    --jon.

Sorry Jon, but he was asking about octal 30 (decimal 24), not decimal
30.  Suns try to negotiate terminal type, RFC-930.

Chris
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 03:35:25 GMT
From:      nomad@agora.UUCP (Lee Damon)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   TCP/IP for OS/2 on PS/2-80-311

Forwarded for a friend... Please reply to me and I'll pass messages
back. Please e-mail to me and I will summarize to the net. Thanks.

--------begin message

Suppose i have a ps/2 model 80 running os/2, version 1.1.
I have an ethernet card (undermann-bass) and I want to run
tcp/ip.  [W]hat [do] I need to buy.

Suppose I want to log in to my ps/2 over tcp/ip.  Can it be done?

Suppose I want to log in to my ps/2 with a modem.  Can it be done?

--------- end message.

nomad
 ================ Lee Damon                                     \
UUCP: {agora,cs.orst.edu,escargot,tessi,verdix}!castle!nomad     \
Internet: nomad@castle.fidonet.org or nomad@cs.orst.edu           \
FidoNet: The Castle BBS, FidoNode 1:105/302, +1-503-641-3161     / \
  Abort the "moral majority" - which is neither!                /   \

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 06:38:44 GMT
From:      news@brian386.UUCP (Wm. Brian McCane)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: Van Jacobson's improved TCP code

In article <291@alias.UUCP> mark@alias.UUCP (Mark Andrews) writes:
>I noticed a note a few months ago that Van Jacobson's new TCP code was
>available from berkeley.edu via anonymous ftp. I do not have internet
>access and was wondering if I could get it via uucp (or could someone send
>it to me ??). Any assistance or information would be GREATLY appreciated.
>

I would also like to have this UUCP information, or be emailed the
source.  Thx MUCH!!!

			brian

-- 
Wm. Brian McCane                    | Life is full of doors that won't open
                                    | when you knock, equally spaced amid
Disclaimer: I don't think they even | those that open when you don't want
            admit I work here.      | them to. - Roger Zelazny "Blood of Amber"

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 10:41:52 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!nuucp
From: nuucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904040336.AA11630@rutgers.edu>
Date: 4 Apr 89 03:36:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!mcvax!kth!sunic!maxim!prc
From: prc@maxim.ERBE.SE (Robert Claeson)
Newsgroups: comp.protocols.tcp-ip,comp.sys.encore
Subject: Re: An Annex by any other nameserver would smell...
Message-ID: <636@maxim.ERBE.SE>
Date: 3 Apr 89 19:52:43 GMT
References: <68@a.coe.wvu.wvnet.edu> <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>
Organization: ERBE DATA AB
Lines: 15


In article <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes:

> BIND is the name of the Berkeley program that implements the IP
> Domain Name Service on UNIX.  This is really what people ought
> to be using these days, and is really required if you are in a
> large network environment or are connected to the Internet at large.

Where can I find a good implementation of it for System V systems with
sockets and/or TLI?

-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20
EUnet:   rclaeson@ERBE.SE               uucp:   {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET  BITNET: rclaeson@ERBE.SE
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 Apr 89 11:32:31 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        "Miles R. Fidelman" <bbn.com!mfidelma@bbn.com>, tcp-ip@sri-nic.arpa
Subject:   Re: RSA for files too?
>Since RSA cryptography is about to show up on the Internet, maybe we
>should look at extending its application to the protection of file
>transers - perhaps by specifying a standard way to generate crypto-checksums
>for inclusion in compressed files.

There is at least one product that does just this, at least for PC-based
files and mail.  It is called MailSafe, and is marketed by RSA Data Security.
Maybe they would be willing to put their checksum/signature protocol in
the public domain.

Doug Nelson
Michigan State University
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 Apr 89 11:50:10 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Tim Ramsey, <uxc!deimos.cis.ksu.edu!ksuvax1.cis.ksu.edu!tar@csd4.milw.wisc.edu>, tcp-ip@sri-nic.arpa
Subject:   Re: LAWNWatch
>I get it.  It's a joke, right?

Yes, Data, that was a joke....
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 13:51:53 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!uucp
From: uucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904040542.AA28316@rutgers.edu>
Date: 4 Apr 89 05:42:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 14


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!tektronix!zephyr!mikes
From: mikes@zephyr.ENS.TEK.COM (Mike Skrydlak)
Newsgroups: comp.protocols.tcp-ip
Subject: Appletalk (flash-card) driver for NCSA telnet for PCs ?
Message-ID: <2765@zephyr.ENS.TEK.COM>
Date: 3 Apr 89 20:52:13 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 3


I'm looking for a flash-card driver for NCSA telnet for the PC. I can
anonymous ftp if I get a dotted decimal internet address - we don't
quite have name server access yet.  Thank you again for your support.
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 11:23:49 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp writes:
+---------------
| In article <583@accuvax.nwu.edu.NWU.EDU> morrison@accuvax.nwu.edu writes:
| >I have developed software for Turning a klunky old IBM XT into a IP router...
| Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP
| for the PC/XT/AT/...?  I can't see any reason why Phil's stuff wouldn't
| make a perfectly good router; were you aware of its existence?
+---------------

Well, for one thing, Phil's code associates an IP address with the *host*,
not with each interface. (See? KA9Q isn't *perfect*... yet.)  That's all
right when you a gatewaying from (say) Ethernet to a SLIP link, but isn't
so hot if you are trying to go Ether-to-Ether.  (Someone at AMD hacked the
KA9Q code to put the IP addresses with the interface, and *is* playing with
it as an experimental IP router. But it's a hack, and not completely general.
Best would be for one of the real KA9Q maintainers to do an "official" fix.)


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 12:32:50 GMT
From:      ted@NADC.ARPA (T. Calkins)
To:        comp.protocols.tcp-ip
Subject:   Collision Avert

Greetings,
   This is not exactly TCP/IP, but related. We are looking for
some design information for Fiber Optic Ethernet equipments. One 
feature that we have seen that has a great deal of appeal is 
Collision Avert whereby two packets arriving at the star simultaneously 
do not annihilate each other. With this feature, the first packet 
always gets out, all other transmitted packets get the standard 
collision signal.  With this feature, supposedly, the Ethernet will 
not saturate at the usual 40-62% of 10Mb/s throughput.

   We would like to get in touch with everyone on this list who has
had experience with any/all equipments that use Collision Avert on
a Fiber Optic Ethernet. We are particularly interested in the results
of any controlled studies that measure performance, both with CA and
without CA. And, if statistics are available that provide for 
predicting overall throughput as the load increases.
 
   Also, we would like the names of companies whose equipments  
provide for the Collision Avert feature.

   Thanks in advance. And, if there is interest, I can summarize
for the list.
                        Respectfully,
 
                        Ted Calkins   ( ted@NADC.ARPA )

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 14:17:27 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

>x   IBM-2741

I love it! The terminal that TELNET GO-AHEAD was designed for isn't on
the Official Terminal Names list!

Ross Patterson
Rutgers University
Center for Computer and Information Services

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 15:32:31 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: RSA for files too?

>Since RSA cryptography is about to show up on the Internet, maybe we
>should look at extending its application to the protection of file
>transers - perhaps by specifying a standard way to generate crypto-checksums
>for inclusion in compressed files.

There is at least one product that does just this, at least for PC-based
files and mail.  It is called MailSafe, and is marketed by RSA Data Security.
Maybe they would be willing to put their checksum/signature protocol in
the public domain.

Doug Nelson
Michigan State University

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 19:43:11 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!nuucp
From: nuucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904041011.AA07474@rutgers.edu>
Date: 4 Apr 89 10:11:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!ICASE.EDU!doug
From: doug@ICASE.EDU (Doug Peterson)
Newsgroups: comp.protocols.tcp-ip
Subject: System V mail
Message-ID: <8904031955.AA13198@work1.icase.edu>
Date: 3 Apr 89 19:55:40 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 17


Does anyone know of any features of System V mail (or mailx) which allow
interactive debugging similar to mail -v in Berkely mail? I'm looking
for something a little easier than telnetting to the SMTP port.

I'll summarize to the net.

Thanks in advance.

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 864-2172
FTS: 928-2172
doug@icase.edu
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 19:48:48 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!faline!thumper!ulysses!att!ucbvax!tness1.UUCP!nuucp
From: nuucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904041011.AA07475@rutgers.edu>
Date: 4 Apr 89 10:11:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!SLCS.SLB.COM!7thSon
From: 7thSon@SLCS.SLB.COM (Chris Garrigues)
Newsgroups: comp.protocols.tcp-ip
Subject: re: Telnet DO Option 30
Message-ID: <19890403230504.1.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>
Date: 3 Apr 89 23:05:00 GMT
References: <8904031640.AA00224@bel.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 13



    Date: Mon, 3 Apr 89 09:40:51 PDT
    From: postel@venera.isi.edu


    Telnet option 30 is the "X.3 PAD" option described in RFC-1053.

    --jon.

Sorry Jon, but he was asking about octal 30 (decimal 24), not decimal
30.  Suns try to negotiate terminal type, RFC-930.

Chris
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 15:50:10 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: LAWNWatch

>I get it.  It's a joke, right?

Yes, Data, that was a joke....

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 16:31:05 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip,comp.sys.encore
Subject:   Re: SysV nameserver

In the anonymous FTP area of host UCSD.EDU [128.54.16.1] there is a
version of BIND that was ported to Unix SysV by one of Peter Honeyman's
"stinking undergrads".  We used it with reasonable success on an AT&T
3B15 and the WIN TCP/IP-1.1 package.  It uses the socket library.

It is pre-4.8 bind.  You should ALSO get the 4.8 bind distribution
and integrate the two if you are planning to do serious nameserver 
work on SysV.  Take the two files
	pub/named.48.tar.Z
	pub/named.SysV.tar.Z

I have not updated it to 4.8 because I can't;  we "upgraded" our 3B15 to
SysV-3.1.1 and WIN TCP/IP-2.1, and now cannot even compile anything that
uses sockets, much less make such work.

[This "upgrade" also broke every one of our existing socket-based tcp/ip 
programs, leaving us a rather large machine that is essentially emasculated
from the Internet.  To date, AT&T has shown little understanding of and 
no progress in fixing the problem.]

If you make a 4.8 nameserver for SysV, ship it back to me and I'll put it 
out there where people can get to it.
	- Brian

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Apr 89 21:27:06 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!jupiter!karn
From: karn@jupiter (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Super Cheap IP router (< $1000)
Message-ID: <15134@bellcore.bellcore.com>
Date: 4 Apr 89 22:35:51 GMT
References: <583@accuvax.nwu.edu.NWU.EDU> <1989Apr4.000727.2759@utzoo.uucp> <25098@amdcad.AMD.COM>
Sender: news@bellcore.bellcore.com
Reply-To: karn@jupiter.bellcore.com (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 35


>Well, for one thing, Phil's code associates an IP address with the *host*,
>not with each interface. (See? KA9Q isn't *perfect*... yet.)

I consider that a feature, not a bug. :-)  Seriously, I have always
considered the Internet approach of giving addresses to interfaces
rather than to hosts to have been a bad move, and my approach of "one IP
address per customer" was a deliberate design decision based on how I
wanted the amateur packet radio TCP/IP network to evolve.

Nevertheless, you can still make my code emulate a conventional Ethernet
router with two distinct addresses by merely enabling proxy ARP. You
assign the router running KA9Q an address on each network. One of these
addresses becomes the host address for the system; the other is entered
into the ARP table with the "publish" subcommand such that it answers
ARP requests for that address with the Ethernet address of the
appropriate interface.

For example, consider a system with two Ethernet interfaces and two IP
addresses as follows:

Interface A:	Ethernet addr 02:60:8c:0:0:1	IP addr 1.2.3.4
Interface B:	Ethernet addr 02:60:8c:0:0:2	IP addr 44.0.0.1

The autoexec.net file would contain, among other things, the following
two lines:

ip address [1.2.3.4]
arp publish [44.0.0.1] ethernet 02:60:8c:0:0:2

This will make the system behave just as it should for purposes of
routing packets. The only precaution you have to make is to use the
router's "primary" IP address whenever you want to talk directly to it
as a host. Of course, it is then operating as a host, not a router...

Phil
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 17:44:03 GMT
From:      smir@PacBell.COM (Sonu Mirchandani)
To:        comp.protocols.tcp-ip,comp.sys.proteon,pb.general
Subject:   Direct T1 connection to Routers


     I had asked for information regarding direct T1 interfaces to
     Routers. I also said that if there was enough interest I would
     summarize. Well...there was a pretty decent amount of interest
     and here's the summary.


     SUMMARY: 


     The request is in context to the setup as shown below:



       ------------+                                   +-----------+
       |           |Router                             |           |
       |Router     |Backplane                          |  Digital  |
       |           |----------+     +--------+         |   Cross   |
       |___________|__T1 card_|     | DSU____|         | Connect   |
                                V.35           4-wire  +-----------+
                                          

           ALL THIS EQUIPMENT IS IN ONE ROOM, PRETTY CLOSE TO EACH OTHER


      Today: The connection from the Router is a V.35 interface (could be
             56kb or T1 speeds). This is then connected to the DSU. On the
             other side of the DSU the signal comes out 4-wire bipolar DSX-1.
             This is then connected to one of the ports on the Digital
             Cross-connect System (DCS). For the purpose of this discussion
             let us call the Router T1 interface an external T1 interface.

       What we'd like to do:
             We would like to use a T1 card for the Router that provides
             the T1 signal not as V.35 but as a 4-wire bipolar DSX-1
             which can then be directly connected into the DCS. That
             will save us the cost of the DSU by interfacing
             directly between the DSX-1 and the router backplane,
             avoiding the intermediate V.35 conversion.

             For the purpose of this discussion, let us call this an
             integrated T1 interface.

------------------------------------------------------------------------------
THE FOLLOWING IS A SUMMARY OF THE RESPONSES THAT WERE SENT TO ME.
-----------------------------------------------------------------------------

          The responses were fairly mixed.  A number of responses
          indicated that an integrated T-1 interface sounded
          desirable, while one indicated that the external T-1
          interface was not that big of a cost concern.  Wellfleet was
          identified as a vendor that was providing an integrated T-1
          interface, but it did not appear to offer a cost advantage
          over the external interface, indicating that they are probably
          just packaging a CSU in their box.  Another possible vendor
          was mentioned (vaguely).

          One response indicated that the phone company liked to see
          external T-1 interface boxes (i.e. DSU/CSUs) when interfacing to
          their lines. That is true, but in this case I too, am a user of the
          DCS, which is on my premise (see diagram above).

          I was made aware of an integrated circuit company that was
          developing an IC for providing the T-1 interface.  This type
          of device should allow the router folks to build direct T-1
          interfaces with a substatial cost savings over the separate
          CSU/DSU arrangements (Dallas Semiconductor is the company name).

          Of course, there are instances where the DCS/T1 mux or a
          that you would plug the Router into.  However, in most other cases
          they are expecting a 4-wire DSX-1 bipolar T1 signal (which is
          what we have and would like to connect our Router directly to).

          In summary, it sounds like there is a fair amount of
          interest in a direct T-1 interface, and it appears that the
          integrated circuits are becoming avaialable to make that
          feasible.  It sounds like users need to let the router
          vendors know that they would like to see this sort of thing.

          Thanx for the info from all of you out there.  I appreciate
          your feedback.

  Sonu Mirchandani
  Pacific Bell
  smir@pacbell.com
  (415) 823-8908



"Standard disclaimer...."

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 22:19:13 GMT
From:      les@chinet.chi.il.us (Leslie Mikesell)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>
>Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP
>for the PC/XT/AT/...?  I can't see any reason why Phil's stuff wouldn't
>make a perfectly good router; were you aware of its existence?

Is there anything similar for OSI protocols?  I would like to split
a 1 Megabit starlan into at least 2 sub-nets but the only thing I
have seen to connect them would be to put 10-1 bridges back to back
(at about $4500 each).  A PC with two boards sounds a lot nicer.

Les Mikesell

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 22:35:51 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

>Well, for one thing, Phil's code associates an IP address with the *host*,
>not with each interface. (See? KA9Q isn't *perfect*... yet.)

I consider that a feature, not a bug. :-)  Seriously, I have always
considered the Internet approach of giving addresses to interfaces
rather than to hosts to have been a bad move, and my approach of "one IP
address per customer" was a deliberate design decision based on how I
wanted the amateur packet radio TCP/IP network to evolve.

Nevertheless, you can still make my code emulate a conventional Ethernet
router with two distinct addresses by merely enabling proxy ARP. You
assign the router running KA9Q an address on each network. One of these
addresses becomes the host address for the system; the other is entered
into the ARP table with the "publish" subcommand such that it answers
ARP requests for that address with the Ethernet address of the
appropriate interface.

For example, consider a system with two Ethernet interfaces and two IP
addresses as follows:

Interface A:	Ethernet addr 02:60:8c:0:0:1	IP addr 1.2.3.4
Interface B:	Ethernet addr 02:60:8c:0:0:2	IP addr 44.0.0.1

The autoexec.net file would contain, among other things, the following
two lines:

ip address [1.2.3.4]
arp publish [44.0.0.1] ethernet 02:60:8c:0:0:2

This will make the system behave just as it should for purposes of
routing packets. The only precaution you have to make is to use the
router's "primary" IP address whenever you want to talk directly to it
as a host. Of course, it is then operating as a host, not a router...

Phil

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 23:40:22 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   RE: "patch" Program for SLIP Installation.


I have a copy of SLIP downloaded from UUNET.UU.NET (same as TITIAN.RICE.EDU)
and the README file refers to a "patch" program to run using
    "if_sl.c.dif"
as input.  This program does not exist on my SUN-3/260 runing 3.5,
or on my VAX running Ultrix 2.3.  Does anybody have more info for me.

Please send to me directly.  I will summarize to the NET.
------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation 
Mail Code 344		Defense Systems Division - Virginia Tech. Cntr.
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22042
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 89 23:42:19 GMT
From:      ml@gandalf.UUCP (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   SEND LOCATION in TELNET


I'm interested in hearing about TELNET implementations that support the
  SEND LOCATION and SEND TERMINAL TYPE options in both the Client and Server
  half of TELNET.

I'm particularly interested in Client implementations that are willing to
  interact with something akin to the DNS RESOLVER to discover the type and
  location of a terminal placing a TELNET call.  We operate a large data
  network in which terminals are connected to hosts via a data-pbx.  We have
  some fairly sophisticated (data)network-management software that arranges
  for a called host to become aware of the location and terminal type of a call
  placed to that host.  We'd like to extend this support to both Client and
  server TELNET.

For those of you who connect all your terminals to TELNET terminal servers,
  I'm interested in hearing about commerical terminal servers that provide
  the SEND TERMINAL TYPE and SEND LOCATION options.

If anyone has any information on TELNET implementations that support this,
  please mail me and I'll post a summary.

If this stuff has been covered before, I apologize.  I've only recently become
  re-connected to USENET after a 6-year drought.

Thanx in advance
Marcus Leech
Gandalf Data Ltd

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 07:13:23 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!killer!ames!lll-winken!uunet!tektronix!psueea!parsely!agora!nomad
From: nomad@agora.UUCP (Lee Damon)
Newsgroups: comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject: TCP/IP for OS/2 on PS/2-80-311
Message-ID: <1438@agora.UUCP>
Date: 4 Apr 89 03:35:25 GMT
Reply-To: nomad@agora.UUCP (Lee Damon)
Followup-To: comp.sys.ibm.pc
Distribution: na
Organization: Organization?  You've got to be kidding!
Lines: 21


Forwarded for a friend... Please reply to me and I'll pass messages
back. Please e-mail to me and I will summarize to the net. Thanks.

--------begin message

Suppose i have a ps/2 model 80 running os/2, version 1.1.
I have an ethernet card (undermann-bass) and I want to run
tcp/ip.  [W]hat [do] I need to buy.

Suppose I want to log in to my ps/2 over tcp/ip.  Can it be done?

Suppose I want to log in to my ps/2 with a modem.  Can it be done?

--------- end message.

nomad
 ================ Lee Damon                                     \
UUCP: {agora,cs.orst.edu,escargot,tessi,verdix}!castle!nomad     \
Internet: nomad@castle.fidonet.org or nomad@cs.orst.edu           \
FidoNet: The Castle BBS, FidoNode 1:105/302, +1-503-641-3161     / \
  Abort the "moral majority" - which is neither!                /   \
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 07:44:43 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!faline!thumper!ulysses!att!osu-cis!tut.cis.ohio-state.edu!ucbvax!NADC.ARPA!ted
From: ted@NADC.ARPA (T. Calkins)
Newsgroups: comp.protocols.tcp-ip
Subject: Collision Avert
Message-ID: <8904041232.AA08836@NADC.ARPA>
Date: 4 Apr 89 12:32:50 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 25


Greetings,
   This is not exactly TCP/IP, but related. We are looking for
some design information for Fiber Optic Ethernet equipments. One 
feature that we have seen that has a great deal of appeal is 
Collision Avert whereby two packets arriving at the star simultaneously 
do not annihilate each other. With this feature, the first packet 
always gets out, all other transmitted packets get the standard 
collision signal.  With this feature, supposedly, the Ethernet will 
not saturate at the usual 40-62% of 10Mb/s throughput.

   We would like to get in touch with everyone on this list who has
had experience with any/all equipments that use Collision Avert on
a Fiber Optic Ethernet. We are particularly interested in the results
of any controlled studies that measure performance, both with CA and
without CA. And, if statistics are available that provide for 
predicting overall throughput as the load increases.
 
   Also, we would like the names of companies whose equipments  
provide for the Collision Avert feature.

   Thanks in advance. And, if there is interest, I can summarize
for the list.
                        Respectfully,
 
                        Ted Calkins   ( ted@NADC.ARPA )
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 07:44:57 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!faline!thumper!ulysses!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Super Cheap IP router (< $1000)
Message-ID: <8127@chinet.chi.il.us>
Date: 4 Apr 89 22:19:13 GMT
References: <583@accuvax.nwu.edu.NWU.EDU> <1989Apr4.000727.2759@utzoo.uucp>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Followup-To: comp.protocols.tcp-ip
Organization: Chinet - Public Access Unix
Lines: 12


In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>
>Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP
>for the PC/XT/AT/...?  I can't see any reason why Phil's stuff wouldn't
>make a perfectly good router; were you aware of its existence?

Is there anything similar for OSI protocols?  I would like to split
a 1 Megabit starlan into at least 2 sub-nets but the only thing I
have seen to connect them would be to put 10-1 bridges back to back
(at about $4500 each).  A PC with two boards sounds a lot nicer.

Les Mikesell
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 07:51:09 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!faline!thumper!ulysses!att!rutgers!elbereth.rutgers.edu!hardees.rutgers.edu!patterso
From: patterso@hardees.rutgers.edu (Ross Patterson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: new terminal names
Message-ID: <Apr.4.10.17.26.1989.22017@hardees.rutgers.edu>
Date: 4 Apr 89 14:17:27 GMT
References: <8YAj6Yy00UoJ41ApYV@andrew.cmu.edu>
Organization: Rutgers Univ., CCIS
Lines: 8


>x   IBM-2741

I love it! The terminal that TELNET GO-AHEAD was designed for isn't on
the Official Terminal Names list!

Ross Patterson
Rutgers University
Center for Computer and Information Services
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 04:51:24 GMT
From:      ccwilliams@wombat.decnet.uq.oz (Mark I. Williams)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   TELNET  Binary option

Folks,
	I have a problem getting the BSD4.3 TELNET to talk to a UNISYS 2200
machine running OS 1100.
	The problem seems to be that the BSD TELNET refuses to negotiate
the binary option, while the particular application we are running on the
UNISYS machine requires the binary option.

	I would give a listing of the options transactions, but the log
file i have is temporarily unavailable. What it boils down to is (from the
BSD end) is:

Received DO BINARY (reply)
SENT	 DON'T BINARY (reply)
REC'D	 WILL BINARY
SENT	 WON'T BINARY

and the connection gets closed.

	Is this because the Telnet provided with BSD (I have tried ULTRIX
2.2 and Mt. Xinu 4.3BSD) doesn't support the binary option?  If this is
the case, are there any implementations available that support the binary
option? (as per RFC 856)

Thanks Muchly,

Mark Williams
-- 
Mark I. Williams	   ACSnet: ccwilliams@wombat.decnet.uq.oz
Network Engineering,	   ARPA:   ccwilliams@wombet.decnet.uq.oz.au	
Prentice Computer Centre,  INFOPSI: ccwilliams@wombat.uq.edu.au(050527372000090)
The University of Queensland.	JANET:ccwilliams@au.edu.uq.wombat

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 09:30:28 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!killer!ames!lll-winken!uunet!tektronix!sequent!roc
From: roc@sequent.UUCP (Ron Christian)
Newsgroups: comp.protocols.tcp-ip,comp.sys.encore
Subject: Re: An Annex by any other nameserver would smell...
Message-ID: <13805@sequent.UUCP>
Date: 4 Apr 89 17:32:53 GMT
References: <68@a.coe.wvu.wvnet.edu> <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>
Reply-To: roc@crg2.UUCP (Ron Christian)
Organization: Sequent Computer Systems, Inc
Lines: 24


In article <Mar.31.13.10.21.1989.3524@ron.rutgers.edu> ron@ron.rutgers.edu (Ron Natalie) writes:
>RWHOD is a pretty lousy program in that each machine broadcasts it's
>users every 3-5 minutes.

Agreed.  Usually turned off.  Performance hit on dickless Suns.

>IEN-116 was the original name server, but it never really hit wide
>use.  It is trivial to implement, and hence you can get it going on
>nearly anything that has UDP on it.

The Bridge terminal server uses this, as does the Visual 640 X-terminal.
Seems to work swell.

>BIND is the name of the Berkeley program that implements the IP
>Domain Name Service on UNIX.  This is really what people ought
>to be using these days, and is really required if you are in a
>large network environment or are connected to the Internet at large.

Is it possible to retrofit BIND to a relitively old version of 4.2BSD?
(Just asking...)



				Ron
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 09:30:29 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!killer!osu-cis!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!nuucp
From: nuucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904041441.AA13083@rutgers.edu>
Date: 4 Apr 89 14:41:52 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 39


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!nuucp
From: nuucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904040336.AA11630@rutgers.edu>
Date: 4 Apr 89 03:36:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!mcvax!kth!sunic!maxim!prc
From: prc@maxim.ERBE.SE (Robert Claeson)
Newsgroups: comp.protocols.tcp-ip,comp.sys.encore
Subject: Re: An Annex by any other nameserver would smell...
Message-ID: <636@maxim.ERBE.SE>
Date: 3 Apr 89 19:52:43 GMT
References: <68@a.coe.wvu.wvnet.edu> <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>
Organization: ERBE DATA AB
Lines: 15


In article <Mar.31.13.10.21.1989.3524@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes:

> BIND is the name of the Berkeley program that implements the IP
> Domain Name Service on UNIX.  This is really what people ought
> to be using these days, and is really required if you are in a
> large network environment or are connected to the Internet at large.

Where can I find a good implementation of it for System V systems with
sockets and/or TLI?

-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20
EUnet:   rclaeson@ERBE.SE               uucp:   {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET  BITNET: rclaeson@ERBE.SE
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 10:46:01 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!faline!thumper!ulysses!ucbvax!MSU.BITNET!08071TCP
From: 08071TCP@MSU.BITNET (Doug Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: RSA for files too?
Message-ID: <8904050804.AA13359@ucbvax.Berkeley.EDU>
Date: 4 Apr 89 15:32:31 GMT
References: <bbn.com!mfidelma@bbn.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 12


>Since RSA cryptography is about to show up on the Internet, maybe we
>should look at extending its application to the protection of file
>transers - perhaps by specifying a standard way to generate crypto-checksums
>for inclusion in compressed files.

There is at least one product that does just this, at least for PC-based
files and mail.  It is called MailSafe, and is marketed by RSA Data Security.
Maybe they would be willing to put their checksum/signature protocol in
the public domain.

Doug Nelson
Michigan State University
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 10:46:03 EDT
From:      tness1!nuucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bellcore!faline!thumper!ulysses!ucbvax!decwrl!vixie
From: vixie@decwrl.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SLIP for Ultrix-32
Message-ID: <VIXIE.89Apr5013036@jove.pa.dec.com>
Date: 5 Apr 89 08:30:36 GMT
References: <8903212059.AA19122@sol>
Sender: news@decwrl.dec.com
Organization: DEC Western Research Lab
Lines: 36
In-reply-to: droms@sol.bucknell.EDU's message of 21 Mar 89 20:59:11 GMT


[Ralph Droms]
# Can anyone give me a pointer to SLIP for "Ultrix-32 V3.0 (Rev 64)"?

There's one there already.  It has three pieces:

	/usr/sys/BINARY.vax/if_sl.o
	/usr/new/slattach
	/etc/sliphosts

The sliphosts file has enough documentation in it to get you going.

By putting the slattach program in /usr/new, Digital is trying to tell you
that it is not supported.  Keep this in mind if you find the driver less
than robust wrt your system's uptime.

I ported the 4.3bsd SLIP driver to Ultrix 3.0 in about an hour.  Mostly it
took some changes to the way buffers were sent upstream into IP, and in
the way things were allocated (see /usr/include/sys/kmalloc.h for the One
True Way to allocate kernel memory in Ultrix).  I also had to call slattach()
from sys/init_main.c, since the Ultrix if_sl.c allocates its interfaces
dynamically (this means they don't appear in "netstat -i" until you open
them) and they didn't need any boot-time initialization.  The 4.3bsd driver
needs to get called at boot time to allocate its if_softc array and initialize
it.  How to modify init_main.c when you don't have sources is a problem, I
admit :-).

The 4.3bsd SLIP driver, once ported, works perfectly with the Ultrix 3.0
/usr/new/slattach program.  This slattach program is awfully nice, in my
somewhat biased opinion, since it will dial up and run a UUCP-ish chat
script for you when you want to connect.  It lacks something when compared
to CSNET's dial-on-demand implementation, but it's a big win over tip(1)
and ~^Z for just getting the interface going.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 08:30:36 GMT
From:      vixie@decwrl.dec.com (Paul A Vixie)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Ultrix-32

[Ralph Droms]
# Can anyone give me a pointer to SLIP for "Ultrix-32 V3.0 (Rev 64)"?

There's one there already.  It has three pieces:

	/usr/sys/BINARY.vax/if_sl.o
	/usr/new/slattach
	/etc/sliphosts

The sliphosts file has enough documentation in it to get you going.

By putting the slattach program in /usr/new, Digital is trying to tell you
that it is not supported.  Keep this in mind if you find the driver less
than robust wrt your system's uptime.

I ported the 4.3bsd SLIP driver to Ultrix 3.0 in about an hour.  Mostly it
took some changes to the way buffers were sent upstream into IP, and in
the way things were allocated (see /usr/include/sys/kmalloc.h for the One
True Way to allocate kernel memory in Ultrix).  I also had to call slattach()
from sys/init_main.c, since the Ultrix if_sl.c allocates its interfaces
dynamically (this means they don't appear in "netstat -i" until you open
them) and they didn't need any boot-time initialization.  The 4.3bsd driver
needs to get called at boot time to allocate its if_softc array and initialize
it.  How to modify init_main.c when you don't have sources is a problem, I
admit :-).

The 4.3bsd SLIP driver, once ported, works perfectly with the Ultrix 3.0
/usr/new/slattach program.  This slattach program is awfully nice, in my
somewhat biased opinion, since it will dial up and run a UUCP-ish chat
script for you when you want to connect.  It lacks something when compared
to CSNET's dial-on-demand implementation, but it's a big win over tip(1)
and ~^Z for just getting the interface going.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 14:38:21 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!killer!ames!mailrus!tut.cis.ohio-state.edu!ucbvax!MSU.BITNET!08071TCP
From: 08071TCP@MSU.BITNET (Doug Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LAWNWatch
Message-ID: <8904050936.AA17458@ucbvax.Berkeley.EDU>
Date: 4 Apr 89 15:50:10 GMT
References: <uxc!deimos.cis.ksu.edu!ksuvax1.cis.ksu.edu!tar@csd4.milw.wisc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 3


>I get it.  It's a joke, right?

Yes, Data, that was a joke....
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Apr 89 15:03:56 EDT
From:      tness1!uucp@texbell.swbt.com
To:        comp-protocols-tcp-ip@rutgers.edu
To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!killer!ames!hc!pprg.unm.edu!unmvax!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!uucp
From: uucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904041751.AA23895@rutgers.edu>
Date: 4 Apr 89 17:51:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!uucp
From: uucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904040542.AA28316@rutgers.edu>
Date: 4 Apr 89 05:42:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 14


To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!tektronix!zephyr!mikes
From: mikes@zephyr.ENS.TEK.COM (Mike Skrydlak)
Newsgroups: comp.protocols.tcp-ip
Subject: Appletalk (flash-card) driver for NCSA telnet for PCs ?
Message-ID: <2765@zephyr.ENS.TEK.COM>
Date: 3 Apr 89 20:52:13 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 3


I'm looking for a flash-card driver for NCSA telnet for the PC. I can
anonymous ftp if I get a dotted decimal internet address - we don't
quite have name server access yet.  Thank you again for your support.
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 13:16:13 GMT
From:      zdwcv@dcatla.UUCP (Wm. C. VerSteeg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)


The notion of a cheap IP router based on a PC is a good one. When
we start talking about implementations, some interesting ideas get thrown 
out.

Is a proxy arp scheme good enough scheme for such a low-end router?
Phil Karn says that his KA9Q can be used as a router by configuring
it for proxy arp. If the intended user group is relatively sophisticated,
and is confining itself to a SMALL network environment, I would say 
that proxy arp is sufficient. But proxy arp is not intended for large
networks. There is no distributed routing algorithm, so it does not
scale well at all. Proxy arp schemes would not work in the internet at 
large, but may be usefull in some limited applications.

Carefully look at your options before you decide to use a package that 
was not designed to be a router as a router. 


Bill VerSteeg

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 15:08:44 GMT
From:      Bruce_Jolliffe@MTSG.UBC.CA
To:        comp.protocols.tcp-ip
Subject:   Dial-Up SLIP IP Address Resolution

We have implemented SLIP as per RFC 1055 in our serial network.
The RFC does not specify how dial-in hosts are to get their IP
addresses. What is the current concensus on how this should be
done?
 
We would like to use a standard mechanism to do this rather than
have to modify each package so that it uses dial-up SLIP
transparently. Currently when you use off the shelf SLIP packages
with dial-up SLIP you have to fiddle a bit to tell the package
what your dynamic IP address is.
 
Both RARP and BOOTP offer mechanisms for returning IP addresses.
We were considering using the BOOTP protocol as described in RFCs
951 and 1084 to return the IP address. Many of the fields that
can be used to return other information would be left as null.
We would put the handling of the BOOTP protocol packets in our
communications processors so that the IP address resolution could
be done at the the point where the connection to the network was
made.
 
        -- Bruce Jolliffe
           Bruce_Jolliffe@mtsg.ubc.ca
           Network Services
           Computing Centre
           University of British Columbia
           (604) 228-5309

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Apr 89 20:21:33 EDT
From:      Marshall Feldman <RLN101%URIACC.BITNET@mitvma.mit.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   TCP-IP for Apple IIe's
One of our students "donated" an Apple IIe to our program.  I am willing
to accept the machine if I can find some way to hook it to our network.
Does anyone out there know how to put one of these beasts on a TCP/IP
Thinnet network?

Thank you for your support.
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 17:04:16 GMT
From:      oconnor@interlan.interlan.COM (Mary O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for OS/2 on PS/2-80-311

could I ask you what the symbol at the end of your message is and the meaning
if any and why it's included ?  Not trying to be nosey just curious.
Thanks,  Mary.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 17:12:53 GMT
From:      gordon@phcoms.philips.nl (Colin Gordon)
To:        comp.protocols.tcp-ip
Subject:   problems using inet daemon

I have a TCP client/server type application which I'm trying to start
from the inetd daemon. I can get the client to connect to my
server machine ok. The inetd daemon passes the connection to my
program as file descriptor 0 ok. I can then shutdown stdout & stderr
and dup them to 0 and succesfully write back to the client.

I can't however do any reads from stdin, which I assume is the
socket connection. The write/send from the client end seem to
be ok.

Does anybody have any idea where I'm going wrong ?
-- 
Colin Gordon, Philips Components, Eindhoven, The Netherlands
Tel: +31-40-723149	Fax: +31-40-723846
UUCP: 	..!mcvax!philmds!phcoms!gordon	gordon@phcoms.philips.nl

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 17:26:47 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

In article <Apr.4.10.17.26.1989.22017@hardees.rutgers.edu> patterso@hardees.rutgers.edu (Ross Patterson) writes:
>>x   IBM-2741
>I love it! The terminal that TELNET GO-AHEAD was designed for isn't on
>the Official Terminal Names list!

Read the Host Requirements draft RFC -- GO-AHEAD is gone, too.  Since
no one is required to support GO-AHEAD any more, it makes sense to
punt the associated terminal type.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 18:30:20 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   MS-DOS TCP/IP

Hi -

     I am porting an IMAP2 (RFC 1064) client from Unix to MS-DOS.  I need to
have a good TCP under it.  As the client routines are portable (even to
TOPS-20!!) I'm not tied to sockets or streams or JFN's :-) in any way; there's
a jacket layer between how my client talks TCP and the actual TCP for this
system.

     I've heard n different stories about which TCP is "best".  Here are my
preferences, and I'd appreciate some guidelines:
 . public domain w/ sources.  Not essential but it would make my job a LOT
   easier.
 . SLIP support over COM1.  One of the desired goals is to be able to take a
   Toshiba laptop, dial up, and start mail hacking.
 . domain support.  Not super-critical but nice to have.
 . a TCP library package that I can link in with my application with a halfway
   reasonable set of calling conventions.

     The leading condenders seem to be KA9Q and NCSA.  Can anyone give me any
reasonable comments to help me pick which one that I can justify to my
management?  This is a secondary task for me (albeit an important one) and I
would rather not have to go through a lengthy evaluation process on my own.

-- Mark --

-------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 18:30:32 GMT
From:      paj@gatech.edu (P. Allen Jensen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Problems on a Data General MV/10000 (AOS/VS)

I am not sure this is the correct place to post this so any suggestions of
other appropriate news-groups would be appretiated.

I am the system manager for an MV10000 running AOS/VS 6.01 and AOS/VS Internet
software (TCP/IP, TELNET and FTP).  We had a small local network consisting of
7 Sun systems, 5 Vax/Unix systems, 2 Vax/VMS Systems, several PC's with telnet
software, and a Multiflow Trace (UNIX) system.  In this configuration,
everything works Ok, the MV10000 can talk to these systems (except the VMS
ones, of course) and can be connected to from these systems.  When we added
a bridge to the Internet (essentially a repeater), the MV systems TCP/IP,
TELNET and FTP all quit working.  The only traffic we see through the bridge
are IP, ARP, RARP, and ICMP.  Broadcast packets are filtered out by the
bridge as are other protocols (Decnet, XNS, etc...).  All of the other systems
in our network work just fine on  the Internet.

Can anyone provied any suggestions as to what the problem might be ?  Any and
all ideas are welcome ! (Please !)

One note - The Data General TCP/IP software has very little in the way of
configuration setup - I can set host ID's and gateway routes but have no
control over broadcast packets, arp, or other "normal" things that
can be controlled in most Unix systems.


Once again - I am desperate for a solution, so any ideas are welcome.

P. Allen Jensen
jensen@gt-eedsp.gatech.edu
gatech!gt-eedsp!jensen
-- 
P. Allen Jensen
DSP Laboratory, Electrical Engineering
Georgia Tech, Atlanta GA 30332-0250

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 19:49:04 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Read Receipts & Return Receipts in E-mail

Some people using MMDF are wanting to implement some sort of features
for returning indicators for when mail is delivered and/or read.
There are good reasons for wanting to do this, and I'm interested
in implementing the "when mail is delivered" version at least.

I know already that we're treading beyond area charted in the standards
and so must rely on de-facto standards.

So -- what are all of the ways people know of for implementing things
of this nature in e-mail?

Off the top of my head ..

	SendMail	supports (only in some versions?) a Return-Receipt-To:
			header line which takes an address(es?) to send
			delivery notification.
		
	Some BITNET mailer	uses an Acknowledge-To: line at the end
			of the body of the message for some unknown purpose.

	ALL-IN-1	Does something of this sort but I don't know what.


Any help would be appreciated.
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- The problem with mnemonics is they mean different things to different people.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 20:37:50 GMT
From:      READER-C@OSU-20.IRCC.OHIO-STATE.EDU (Charles Reader)
To:        comp.protocols.tcp-ip
Subject:   Name of CMU-TEK newsgroup


	Can someone E-Mail me the address of the newsgroup that deals with
CMU-TEK issues.  Please send responses to "READER-C@OSU-20.IRCC.OHIO-STATE.EDU.
Thanks in advance.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 22:34:00 GMT
From:      spagnolo@CRC.SKL.DND.CA (Joe Spagnolo)
To:        comp.protocols.tcp-ip
Subject:   SystemV Mailer

I am in need of a public domain SMTP based mailer for System V Unix 
release 2.2.  The hardware configuration consists of a Unisys 5000/55 
(NCR Tower) system and an Excelan board.  Excelan provides a socket 
interface to its TCP/IP networking facilities.  Can anybody help ?


Joe Spagnolo
spagnolo@crc.skl.dnd.ca

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 89 23:07:22 GMT
From:      peters@CC.MSSTATE.EDU (Frank W. Peters)
To:        comp.protocols.tcp-ip
Subject:   USENET over TCP/IP?

Hello,

     We are an internet only site (that is, not connected to the uucp
network).  We have recently become interested in obtaining a USENET
feed.  I understand that it is possible to do so over tcp/ip links.

     I have the following three questions:

(1)  How much resources in terms of disk space and/or cpu should we expect to
     allocate for a full USENET feed? Would it noticably degrade the
     performance of a Sun 4/260?  Would it require 100 meg of disk space?
     10 meg?  A gigabyte?

(2)  Where do I obtain the necessary programs?  I am assuming that they are
     public domain?

(3)  Where do I start in arranging the administrative details (such as
     getting someone to agree to send us the stuff)?  We are connected
     through SURAnet (part of NSFnet) if that makes a difference.

     Please reply to me directly if you have answers to any of the above 
questions.

                        Thank You
                        Frank Peters

========================================================================
| Systems Programmer                 |   Mississippi State University  |
| Phone:    (601) 325-2942           |   Computing Center and Services |
| Internet:  peters@CC.MsState.Edu   |   Post Office Drawer CC         |
| BITNET:    PETERS@MSSTATE.BITNET   |   Mississippi State, MS.  39762 |
========================================================================
"What if I wanna worry?  What if I *like* being unhappy??"

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 00:21:33 GMT
From:      RLN101@URIACC.BITNET (Marshall Feldman)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for Apple IIe's

One of our students "donated" an Apple IIe to our program.  I am willing
to accept the machine if I can find some way to hook it to our network.
Does anyone out there know how to put one of these beasts on a TCP/IP
Thinnet network?

Thank you for your support.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 00:58:06 GMT
From:      postmaster@tness1.UUCP (Greg Hackney 214+464-2771)
To:        comp.protocols.tcp-ip
Subject:   Sorry for the re-posts


I apologize for the reposts of a bunch of articles
from here at tness1. We updated the active file using
info from Gene Spafford's news.lists "List of
Moderated News Groups", and it had this group
shown as moderated.

It was fixed here today.
--
bellcore!tness1!postmaster

-- 
Greg

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 01:42:04 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

> The shortest way to ask this question is to be somewhat flip about
> it, but I don't mean to be -- it's something I really would like to
> know:
> 	What steps are being taken to ensure that the one group
> 	that holds the keys to secure Internet mail won't be
> 	selling them to the Russians?

as a tangential question, What steps are being taken to ensure the USA
governmental agencies don't restrict access to this facility and prevent
non-US access? if you institute secure SMTP and don't let the rest
of the world use it you can kiss goodbye to a lot of connectivity.

note#1: the above question posits the *holders* of the keying info selling
it to <bad-guy> I'm positing the *providers* of keying info not being 
allowed to distribute keys to <non-USA-guy> which is not the same thing.

note#2: couldn't you have chosen a better <bad-guy>? If the russians
	want to read my e-mail, they'll have to join the queue behind
	the NSA, GCHQ, and my mother. -Come to think of it, GCHQ will
	probably be *selling* the keys to the highest bidder if Maggie
	privatizes them...

avanti popolo!

	-george
-- 
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 01:46:09 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Secure SMTP & X.400


on a slightly more serious note, since secure SMTP will require
post-processing to read, and presumably will look pretty much like
btoa-encoded binary forms, how is this going to tie in with X.400
secure mail forms? anyone doing the gateway code yet?

also, by positing a framework for transmitting encoded body-types in
plain SMTP we can equally propose other complex body-types, and thus
X.400 and OSI can be staved off for a few years yet by concentrating 
on the UA's to de-munge the mail and forgetting all the transport stuff.

whenever I proposed this to developers in the UK, they poo-pooed any
suggestion of passing X.400 in Greybook text or SMTP body's as "backwards
looking" and "non-productive for OSI migration" but if the decoders
are going to go in place anyhow why not extend them a bit?

	-george
-- 
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Apr 89 11:18:11 -0400
From:      Debbie Deutsch <ddeutsch@BBN.COM>
To:        David Herron -- One of the vertebrae <david@g.ms.uky.edu>
Cc:        tcp-ip@sri-nic.ARPA, ddeutsch@BBN.COM
Subject:   Re: Read Receipts & Return Receipts in E-mail
X.400 supports delivery notifications and return-receipts.  

Debbie Deutsch
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 05:20:35 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

>Is a proxy arp scheme good enough scheme for such a low-end router?
>Phil Karn says that his KA9Q can be used as a router by configuring
>it for proxy arp...[]..Proxy arp schemes would not work in the internet at 
>large, but may be usefull in some limited applications.

You misunderstood the reason I suggested you use proxy arp. The idea was to
use it only to circumvent the "one IP address per system" design inherent in
my code. Proxy arp allows the package to reply properly to ARP requests for
its secondary IP address.

You could, of course, go further and use my proxy arp as a general routing
mechanism, but in this case the objections you raise become valid. There
is, however, no routing algorithm code in my package, although there is
talk of adding OSPFIGP.

Phil

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 15:16:12 GMT
From:      pc@ctt.bellcore.com (Peter Clitherow)
To:        comp.protocols.tcp-ip
Subject:   Webster protocol at SRI


Some while ago, i wrote a little piece of code that used socket 103 at
SRI-NIC to do Webster lookup of words.  The server has been barfing for
the last month with messages suggesting it's not going to serve me at
all.  Am i trying to use a service that was never supposed to be used,
and has now been officially removed?  What's the get?

Peter Clitherow, Bellcore,
  444 Hoes Lane, Room 1H-213,
  Piscataway, NJ 08854

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 15:18:11 GMT
From:      ddeutsch@BBN.COM (Debbie Deutsch)
To:        comp.protocols.tcp-ip
Subject:   Re: Read Receipts & Return Receipts in E-mail

X.400 supports delivery notifications and return-receipts.  

Debbie Deutsch

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 15:37:35 GMT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names


> >x   IBM-2741
 
> I love it! The terminal that TELNET GO-AHEAD was designed for isn't
> on the Official Terminal Names list!

As someone who was slightly involved with this issue ( 1/2 :-} ), I'd
like to argue that the TELNET GO-AHEAD was "designed" for half-duplex
HOST operation, not really for a particular terminal (although
admittedly the infamous 2741 was the most common at the time).  That
is, it was the overall IBM philosophy of half-duplex operation with
locked terminals that introduced the need to know when to allow/expect
input, which is all the GO-AHEAD was for.  It made no difference
whether the terminals involved were 2741's, 2740's, 3270's ("modern"
boob tubes), or even ASR33's -- they were ALL driven with the idea
that there was a time for waiting for output and there was a time for
typing input, and the HOST was the one who determined which was which.
The GO-AHEAD was introduced to try to give the host at least a hint as
to how to make this determination (although most implementations did
little actual good).

Of course, all this has become a moot point now that IBM has joined
the rest of the universe with AIX and such.  (Right ...  Try selling
THAT one to the thousands of TSO users sitting at their 3270's right
now with that maddening little "X" shining brightly at the bottom!)

  Wayne Hathaway            
  Ultra Network Technologies     domain: wayne@Ultra.COM
  101 Daggett Drive            Internet: ultra!wayne@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!wayne
  408-922-0100

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 15:45:55 GMT
From:      gerald@ge1cbx.UUCP (Gerald Aden)
To:        comp.protocols.tcp-ip
Subject:   NSFNET ?

I'm not sure that this is the right group to post this to.

I heard the other day about a network called NSFNET that is supposedly
replacing the ARPANET.  Can anyone tell me something about it and how
one goes about getting on this network?  Does one need to have some 
affiliation with a government agency?  Is there a better group to
post this question to?

Thanks in advance,
Gerald Aden
-- 
Quotron Systems Inc.	          | Phone: (213)302-4254 FAX: (213)302-4499
Dept. 36240                       | uucp: uunet!janus!ge1cbx!gerald
12731 West Jefferson Blvd.	      |       trwrb!hacgate!janus!ge1cbx!gerald
Los Angeles, CA 90066             |       gerald@ge1cbx.quotron.com

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 16:53:44 GMT
From:      clements@bbn.com (Bob Clements)
To:        comp.protocols.tcp-ip
Subject:   Re: MS-DOS TCP/IP

In article <MS-C.607804220.377401575.mrc@SUMEX-AIM.Stanford.EDU>
mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) writes:

>     I've heard n different stories about which TCP is "best".  Here are my
>preferences, and I'd appreciate some guidelines:
> . public domain w/ sources.  
 ...
>     The leading condenders seem to be KA9Q and NCSA.
 ...
>-- Mark --

At the risk of being tediously pedantic and repetitive, the KA9Q
package is NOT public domain.  It's copyrighted but freely
copyable for non-commercial use.  (Phil has made arrangements for
commercial use in some cases, which I point out because I'm sure
he wouldn't use the net himself to advertise.)

/Rcc

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 17:00:47 GMT
From:      fink@nucthy.physics.orst.edu (Paul Fink)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

In article <1989Apr4.000727.2759@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Was there some reason not to just use the Phil Karn ("KA9Q") TCP/IP
>for the PC/XT/AT/...?  I can't see any reason why Phil's stuff wouldn't
>make a perfectly good router; were you aware of its existence?
>-- 
>Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
>passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Ah, I'm not aware of it's existence. Could you tell me wher to get it?


____________________________________________________________________________
         Paul J. Fink Jr.                    Internet:
         Oregon State University                fink@PHYSICS.ORST.EDU       
         Department of Physics               Phone:
         Corvallis, Oregon 97331                (503) 754-4631

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 17:18:10 GMT
From:      gc@EWOK.AMD.BNL.GOV (Graham Campbell)
To:        comp.protocols.tcp-ip
Subject:   Slow start et al

A while back, Van Jacobson posted a description of the changes he made
to deal with network congestion (slow start etc.).  Now that I need it
I find that I have discarded it.  Could someone send me a copy if they
still have one around?

Graham (gc@bnl.gov or gc@bnl.bitnet or BNL::GC)

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 18:02:41 GMT
From:      donndeli@sunburn.aero.org (James Donndelinger)
To:        comp.protocols.tcp-ip
Subject:   cisco, secure gateways


I'm looking for a gateway that will provide subnet isolation.  Cisco
has been recommended as the way to go.  My question is does anyone out
there have any experience with cisco?  Are there any problems or
quirks with cisco that I should be aware of?  Would anyone recommend
a different gateway?  I'll be using either twisted pair or ethernet
for a medium.  Please e-mail responses and I'll summarize to the net.

Thanks,

~Jim

(213) 336-3048

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 21:45:51 GMT
From:      jim@tiamat.fsc.com (Jim O'Connor)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: Read Receipts & Return Receipts in E-mail

In article <11428@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
> Some people using MMDF are wanting to implement some sort of features
> for returning indicators for when mail is delivered and/or read.
> There are good reasons for wanting to do this, and I'm interested
> in implementing the "when mail is delivered" version at least.
>
It is probably true that any type of "tell me when/if they read it" feature
would have to be implemented in the MUA's (perhaps a new feature for Elm 2.3).
This feature is something I would also be interested in.

"Return notice on delivery" is/should be implemented in the MDA, but as you
said, not all systems support that, and even when they do support it, the
text of the message you get back is not consistent.

------------- 
James B. O'Connor			jim@tiamat.fsc.com
Filtration Sciences Corporation		615/821-4022 x. 651

*** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 22:27:19 GMT
From:      d.jba@harald.ruc.dk (Jan B. Andersen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Problems on a Data General MV/10000 (AOS/VS)

paj@gatech.edu (P. Allen Jensen) writes:

>I am not sure this is the correct place to post this so any suggestions of
>other appropriate news-groups would be appretiated.

How about comp.os.aos ?

>One note - The Data General TCP/IP software has very little in the way of
>configuration setup - I can set host ID's and gateway routes but have no
>control over broadcast packets, arp, or other "normal" things that
>can be controlled in most Unix systems.

So true - and the manuals doesn't say much either.

------------------
Jan Bruun Andersen
Computer Science Department, Roskilde University Center
e-mail: d.jba@meza.ruc.dk
-- 
Jan Bruun Andersen
Computer Science Department, Roskilde University Center
e-mail: d.jba@meza.ruc.dk

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 22:52:24 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   (none)

Good afternoon all,
		   I thought I'd take a moment or two to sumarize the
responses that I received when I sent a query about TN3270 function-
ality in a terminal server. In addition to all the "gee, that's a
good idea" mail, I did get a few informative notes, mostly from 
people at the companies that will (hopefully) make these beasts.
Here's what I received:

>From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
>Encore is very close to having that availible.  Next release I'm told...
					>Milo

*******************************************************************
>One of the problems here is mapping the 327X stream into a ascii/ansi terminal
>of some type (where some type is one of at least a hundred).  Carrying all
>this "curses" (forgive me) information around in memory is very wasteful.  A
>standard protocol might help vendors (and definitely users).  This protocol
>upon identification of terminal type to the terminal server would ask some
>server (who has disk storage) what is the curses defnition for this terminal
>to be mapped into.  Sounds like an IETF Working group.
 
>Another place to possibly look is how ISO VTP with forms mode does this, knowing
>them they probably have left it up to a vendor's agreement.
 
>Marty

***************************************************************
>From: William Westfield <BILLW@MATHOM.CISCO.COM>
 
>cisco plans to do tn3270 in our terminal server.  The main reason it hans't
>been done yet is that it is HARD.  Not technically hard, you understand -
>it is just that the models don't mesh well.  If you look at the berkeley
>tn3270, you find that the majority of the code deals with the user interface;
>reading the users config file and figuring out which function keys get mapped
>to which PF keys, and so on.  This is swell when each user can have a long
>".tn3270rc" or whatever file.  But terminal servers don't have file systems,
>or termcap databases, or users, or even (frequently) terminal types.
 
>This makes things difficult.
 
>Bill Westfield
>cisco Systems.
 ****************************************************************
>From swb@chumley.tn.cornell.edu Mon Feb 27 05:47:32 1989
>Xylogics bought Encore's "Annex" product, and the whole development
>staff, including Jack O'Neill, the manager, who's a pretty good guy.
>Jack had been planning on bringing out 3270 emulation very early this
>year.  It's been delayed, of course, by the move, but you should call
>Jack at Xylogics.
*****************************************************************


So, it would seem that folks are working on the product, people
agree there's a market, but nothing's running yet. Thanks for
all the replies, people really took some time to express opinions
and ideas on how to make it all work. If things have changed since
I sent this out please let me know. I've got a list of people
who are interested(:*)
			Thanks again,
				    Chris VandenBerg
				    ACC
				    chris@salt.acc.com
				    805-963-9431

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 89 23:20:29 GMT
From:      mlandau@bbn.com (Matt Landau)
To:        comp.protocols.tcp-ip
Subject:   SMTP and alternate message body types [Was Re: Secure SMTP & X.400]

In comp.protocols.tcp-ip (<286@brolga.cc.uq.oz>), ggm@brolga.cc.uq.oz 
(George Michaelson) writes:
>
>also, by positing a framework for transmitting encoded body-types in
>plain SMTP we can equally propose other complex body-types, and thus
>X.400 and OSI can be staved off for a few years yet by concentrating 
>on the UA's to de-munge the mail and forgetting all the transport stuff.

On a related topic, there is currently an Internet RFC (RFC 1049, by
Marvin Sirbu at CMU) that proposes extending RFC-822 headers to include 
a standard Content-Type: header in which the body-type and decoding
instructions can be transmitted.

We've gone ahead and implemented a front-end to /bin/mail (actually, to 
the local mail delivery agent of your choice) that interprets either
Content-Type or X-Content-Type headers, and allows for an external
configuration file with instructions for dispatching different mail 
content types to different decoders and delivery programs.

We use this facility quite effectively in the Slate multimedia document 
communications system to deliver encoded multimedia electronic mail over 
conventional mail transport channels.  I've seen it work with existing
mail systems including SMTP with sendmail or MMDF, uucp, BITNET, and at 
least one X.400 mailer (delivering our own private body type instead
of one of the "standard" ones).

I believe that CMU has done something similar with the Andrew system
to allow delivery of Andrew multimedia documents via sendmail.  I'm not
sure their version is configurable to handle arbitrary content types,
but the existence of these two different systems should serve as proof
that we can easily extend current SMTP (and other text-mail mail delivery
mechanisms) to deal with complex body types, without all the ancilliary
hair of X.400

In fact, there are tremendous advantages in doing so.  For one thing, you 
don't lose any of the current network connectivity that has made mail 
systems work so well up to this point.  By relying on existing transport 
systems, and using encoding/decoding schemes to package up different body 
types in a form acceptable to those transport systems, we have a 
pre-existing electronic community of tens (or more likely hundreds) of 
thousands of people, with the network communications infrastructure 
already in place to make complex/compound message types useful almost 
immediately.

Eventually, X.400 and related standards may become widespread, and may
even become the de facto way we all deal with mail.  (I'm not sure I'd
bet on it, but that's another story...)  But X.400 and company are no 
means necessary if one simply wants to extend the domain of things that 
can be communicated by electronic mail beyond simple text.
--
 Matt Landau			Waiting for a flash of enlightenment
 mlandau@bbn.com			  in all this blood and thunder

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 89 03:18:51 GMT
From:      ml@gandalf.UUCP (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

In article <2913@spdcc.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes:
> 
> Phil Karn's KA9Q TCP/IP implementation can run as a user process
> under most flavors of UNIX, although I wager that only those folks
> without a TCP/IP implementation on a machine would bother.  I got it
> running under XENIX 386 with SLIP last year, although I never really beat
> on it hard.  At the time it was a monolithic program and didn't provide
> a socket application library, so it was mainly of tutorial interest to me.
> I haven't examined it lately.
> 
> It is available for non-commercial use via anonymous FTP on bellcore.com
> in the pub/ka9q directory.

Indeed.  I spent some time tweaking the KA9Q TCP/IP code to provide a BSD
  socket interface to applications.  The general notion was that TCP/UDP/IP
  and the "device handlers" would run in a single process, with a socket
  library to provide an interface to applications via named pipes. There's a
  gotcha with sockets, however.  Sockets are objects upon which it is legal
  to do read () and write () calls (a socket looks like a file descriptor that
  is both readable and writeable).  Faking that up using (for example) named
  pipes turned out to be more-or-less impossible.  The BSD socket library also
  provides sock_send () and sock_recv () (the names may be wrong--this is
  from memory).  Sock_send () and Sock_recv () could certainly be made to
  work with a named-pipe/FIFO implementation--provided you don't want read()
  and write () functionality also.
My conclusion is that it is better to place at least some of the networking
  code in the kernel.  My next crack at the KA9Q code will involve burying
  much of it in a "socket" device driver.  The device driver approach lends
  to easier integration into binary-only systems.  Most binary-only
  distributions don't allow the addition of system calls (and many other
  things).

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 89 03:40:26 GMT
From:      pvo1478@OCE.ORST.EDU (Paul V. O'Neill)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson's improved TCP code

>>............................................ I do not have internet
>>access and was wondering if I could get it via uucp (or could someone send
>>it to me ??). Any assistance or information would be GREATLY appreciated.
 
>I would also like to have this UUCP information, or be emailed the
>source.  Thx MUCH!!!

The Van Jacobson stuff on ucbarpa.berkeley.edu has improvements for dealing
with congested networks.  (Slow-start, re-transmission timer, etc.) If you're 
not on the Internet, you probably don't have congested connections and 
don't need it.  If you are running SunOS 4.0, you already have it.
 
Paul O'Neill                 pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR  97331         503-754-3251

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 89 06:59:59 GMT
From:      earle@mahendo.Jpl.Nasa.Gov (Greg Earle)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   IP address per host vs. per interface (was: Re: Super Cheap IP router)

In article <15134@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:
>>Well, for one thing, Phil's code associates an IP address with the *host*,
>>not with each interface. (See? KA9Q isn't *perfect*... yet.)
>
>I consider that a feature, not a bug. :-)  Seriously, I have always
>considered the Internet approach of giving addresses to interfaces
>rather than to hosts to have been a bad move, and my approach of "one IP
>address per customer" was a deliberate design decision based on how I
>wanted the amateur packet radio TCP/IP network to evolve.

Until a few days ago, I had thought that any machine with more than one
network interface *had* to have a separate IP address for each interface.
Now it appears that this isn't necessarily so; I infer that both from Phil's
posting, and I also just discovered an Encore Annex terminal server that
gives the same IP address to it's Ethernet interface, and to a permanently-
attached SLIP interface (which connects the Encore here at JPL to a Sun
at a Rockwell site about 35 miles away).  When I first did the netstat -i
on the Encore and noticed that it spewed out the same IP address, my brain
started to hurt and I almost blew my cookies (^:  "Non sequitur!!" my brain
howled.  "How is this possible?  Doesn't it break things left and right?" it
asked.

Can someone quote chapter and verse on where this is allowed?  Is it not
recommended?  Does it break anything to do things this way?  I'm confused ...

As much as my brain dislikes the idea, in practice it has a highly
desirable side effect (for me): the Ethernet interface on the Annex has an
IP address which is directly on the JPL backbone network.  By having the
same IP address on it's SLIP link, the Sun at the other end can have an
IP address on that interface which is also on the backbone.  With a simple
net route to the backbone net through it's SLIP interface, and a default
route with the Encore as the gateway, the remote Sun has no routing problems
whatsoever.  On the other hand, I have a dialup SLIP link to a Sun which also
sits on the JPL backbone; we are doing the conventional allocate-a-new-subnet-
with-2-hosts-on-it method.  So, not only is my IP address on a subnet instead
of the backbone, but it appears that the gateway's `gated', seeing that the
SLIP link to me is a point-to-point link, declares a host route to my
machine and proceeds to propagate that to the world (instead of a net route
to the SLIP subnet).  From what we've seen, boxes like the Proteon p4200
don't seem to grok this advertised host route, so I cannot reach any machines
that are behind such a gateway.  The machine I'm typing this on is such a
machine, and reaching it was one of the main raison d'etres for hooking up
the SLIP link in the first place!   *sigh* ...

Thus, if I could have the remote SLIP gateway host declare it's SLIP interface
to be the same IP address as it's address on the JPL backbone, then I could
do the same thing as the Encore-Sun combo and gain a backbone IP address as
well, and make these routing problems vanish (that is, if I could only fool
`gated' ... or use a fixed static route to the backbone net address).

Further enlightenment would be appreciated ...
-- 
	Greg Earle			earle@Sun.COM
	Sun Microsystems		earle@mahendo.JPL.NASA.GOV
	JPL on-site Software Support	poseur!earle@elroy.JPL.NASA.GOV
...!{cit-vax,ames}!elroy!poseur!earle	...!sun!{poseur!}earle

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Apr 89 12:04:06 EDT
From:      Marshall Feldman <RLN101%URIACC.BITNET@mitvma.mit.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP/IP for OS/2 on PS/2-80-311
What operating system are you running?  The answer is "yes", but how
you run tcp-ip depends on your os.
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 89 16:04:06 GMT
From:      RLN101@URIACC.BITNET (Marshall Feldman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for OS/2 on PS/2-80-311

What operating system are you running?  The answer is "yes", but how
you run tcp-ip depends on your os.

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 89 20:57:22 GMT
From:      geraci@rex.cs.tulane.edu (Bart Geraci)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Protocols for Presentation/Application Layers?


Hello.

I am doing some research on the presentation & application layers.
 I am searching for references for proposed protocols (both
 formal and informal) for these two layers. I have Tanenbaum's
 "Computer Networks" (2nd ed.) and I have become familiar with ASN.

If anyone has any references or knows of papers available via ftp,
 please e-mail them to me.

Many thanks.

    -bj-                           You see things and say "Why?" But I dream
    bart j. geraci                 things that never were; and say "Why not?"
Usenet: [{ames,bionet}!]rex!geraci                    -G. B. Shaw-
Internet & Bitnet: geraci@rex.cs.tulane.edu
-- 
    -bj-                           You see things and say "Why?" But I dream
    bart j. geraci                 things that never were; and say "Why not?"
Usenet: [{ames,bionet}!]rex!geraci                    -G. B. Shaw-
Internet & Bitnet: geraci@rex.cs.tulane.edu

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 89 23:17:57 GMT
From:      renglish@hpirs.HP.COM (Robert English)
To:        comp.protocols.tcp-ip
Subject:   LAN multicasts and TCP/IP

I'm looking for a way to allow a network server to move between processors
connected by a LAN.  At the IP level, this can be done by using
unsolicited ARP messages to inform other processors that the server has
moved.  This approach, however, has some problems.

First, the unreliability of message delivery leaves the system open to
the "black hole" phenomenon, where remote sites keep the old station
address in their caches and continue to send messages to the wrong
processor.  Second, not all IP sites handle unsolicited ARP messages
correctly, so that even if the message were delivered to the remote
site, it might not change its routing table appropriately.  And third,
not all LAN protocols are based on IP, so that the approach simply
doesn't help with servers that use both IP-based traffic and
non-IP-based traffic.

A solution to this problem seemed obvious to me:  Use the programmable
multicast address capability on the card to allow a server's station
address to move with it.  Since the mapping between station address and
IP address does not change, black holes are not a problem.  Since the
station address itself moves with the server, servers that use non-IP
protocols can be supported as well.  Everything seemed to work fine.

But then I learn that the Host Requirements RFC explicitly forbids the
use of physical network multicast addresses for standard IP messages, to
the extent that hosts receiving standard IP packets from multicast
sources are required to drop them.  So long, obvious solution.

Apparently, the multi-cast IP spec doesn't allow for this possibility,
either.  Multicast IP addresses are legal as destinations, but not as
sources, so they wouldn't help solve my problem, either.

I can see many reasons to be careful about using multicast station
addresses in a LAN, but very few to forbid them.  Suppose, for example,
that multicast addresses were legal only if they were derivable from the
IP address they were associated with.  For example, a host with the IP
address x could only use the multicast address 0x800....0|x, and all
others would be illegal.  In that case, since IP addresses must be
unique on a single LAN, then the multicast station addresses for the
hosts would have to be unique as well.

Does anyone have a better solution to this problem?

--bob--						renglish%hpda@sde.hp.com

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 03:14:47 GMT
From:      rjh@cs.purdue.EDU (Bob Hathaway)
To:        comp.lang.ada,comp.software-eng,comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.nfs,comp.dcom.lans
Subject:   Subliminal


[This is a comment on RFC 1097, which provides a standard for sending 
and receiving subliminal messages across the internet.  Since newsgroups
are a potential victim of subliminal messages, I'm cross-posting this
article.]

I sincerely hope RFC 1097 is a joke, subliminal suggestion is a devious and
underhanded way to influence people into taking actions or adopt ideas
without their consent.  People should be afraid to look at terminals if
there is a possibility subliminal messages are being sent.  Why isn't this
practice illegal?  I vote for a complete banning of subliminal messages from
any electronic medium and propose for now a banning of subliminal messages
across the Internet.  Subliminal messages are a dangerous threat to our
security and the integrity of the Internet.

From rfc 1097:
>
>4.  Motivation for the option
>
>   Frequently the use of "Message of the day" banners and newsletters is
>   insufficient to convince stubborn users to upgrade to the latest
>   version of telnet.  Some users will use the same outdated version for
>   years.  I ran across this problem trying to convince people to use
>   the REMOTE-FLOW-CONTROL Telnet option.  These users need to be gently
>   "persuaded".
>

Persuading users without their consent?  Do we really want system 
administrators and programmers to secretly influence us to use their 
latest fad software or worse?  This is absurd.

>   1.  Server suggests and client agrees to use SUBLIMINAL-MESSAGE.
>
>      (Server sends) IAC DO SUBLIMINAL-MESSAGE
>      (Client sends) IAC WILL SUBLIMINAL-MESSAGE
>      (Server sends) IAC SB SUBLIMINAL-MESSAGE 0 5 0 20 "Use VMS" IAC SE
>
>         [The server is "suggesting that the user employ a stable
>         operating system, not an unreasonable request...]

VMS is a proprietary operating system, this tactic should not be used.  Any
software producer could subliminally suggest we use their software.  This 
is an unconscionable and underhanded means of influencing people and
selling products.

In my opinion, subliminal messages are a direct, unconscionable, and
flagrant violation of our civil rights and should be banned immediately.

So, 
	1. I am preparing another RFC to ban subliminal messages 
	   from passage across the Internet.  I wouldn't give 
	   subliminal messages the respectability of an RFC,
	   and think we should replace the existing RFC 1097 by
	   a new RFC banning the practice, not just obsolete RFC 1097.
	   I believe this is necessary to maintain the respectability of
	   the Internet.

	2. How did this RFC ever get adopted?  If this adoption practice 
	   is carried out in private, I vote RFC's should be posted for 
	   public discussion first, perhaps in comp.protocols.tcp-ip.

Bob Hathaway
rjh@purdue.edu

Seen in a .signature recently:

	The price of freedom is eternal digilence.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 03:28:54 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson's improved TCP code

pvo1478@OCE.ORST.EDU (Paul V. O'Neill) writes:
+---------------
| The Van Jacobson stuff on ucbarpa.berkeley.edu has improvements for dealing
| with congested networks.  (Slow-start, re-transmission timer, etc.) If you're 
| not on the Internet, you probably don't have congested connections and 
| don't need it....
+---------------

Well, the Internet isn't the only congested net in the world... ;-}
Anybody who has a 9600 or 56k link between two campuses/buildings of
Ethernets has probably seen congestion burps. And I've seen cases when
the new code would work with badly designed old Ethernet controllers
(need I name names? except to say they're for really small hosts) when
nothing else would. So it's good to have, regardless.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 05:14:55 GMT
From:      dpz@pilot.njin.net (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal

I think somebody missed the joke ... for anyone interested in submitting an
RFC titled "Requirements for Internet Users", please contact me :-)

						David
-- 
David Paul Zimmerman                                 Rutgers University
dpz@pilot.njin.net         rutgers!dpz        dpzimmerman@zodiac.bitnet

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 05:24:19 GMT
From:      Brian_C_McBee@cup.portal.com
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   CMU-TEK and VMS5.0

Has anyone succeeded in getting CMU-TEK TCP/IP to run under VMS 5.0-2?
We only had it running for a few weeks under 4.7 and had to upgrade to
5.0 to run some other software.  Is there hope, or should I just write
it off? :-)
				Brian

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 10:20:29 GMT
From:      mah@hpuviea.UUCP (Michael Haberler)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Super Cheap IP router (< $1000)

We're using KA9Q as a 'super cheap' IP router for about a year now at the
University of Economics at Vienna. It's an AT clone bridging a NetBIOS
IBM PC Network (broadband - the early works from IBM & Sytek) and the
campus ethernet. Also, it has a permanent SLIP connection to a remote
PC Network running with 19200 baud. We also experimented with two KA9Q's 
and dialup SLIP for bridging two distant Ethernets.

This worked flawless as long as traffic is low; given the average dumb
PC hardware it's easy to lose interrupts when traffic is coming in from
more than one side. Especially the Slip connection deteriorated badly
under high load. The Ethernet card we use (3c501 - yes I know) keeps
the CPU busy with interrupts disabled too long so the serial port just is
overrun. The Netbios/slip route actually works better, probably due
to less latency of the Netbios driver. 

I think that a bridge able to sustain higer traffic would need interface
cards with substantial on-board buffering. The one-interrupt-per-character
scheme for slip would need to be replaced with at least DMA, or better an
own CPU on the card. 

Remember: this all is due to the !@*&^% PC hardware having lousy
real-time performance. KA9Q never gave us a problem (Kudos, Phil!).

Michael Haberler & Gustaf Neumann (neumann@awiwuw11.bitnet)
-- 
Michael Haberler		mah@hpuviea.uucp 
Hewlett-Packard Austria GmbH, 	...mcvax!tuvie!hpuviea!mah
Lieblgasse 1 			...hplabs!hpfcla!hpbbn!hpuviea!mah
A-1220 Vienna, Austria		Tel: (0043) (222) 2500 x412 (9-18 CET) 	

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 21:50:07 GMT
From:      tim@hoptoad.uucp (Tim Maroney)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal

Jeez, we better not less this Hathaway guy read any Padlipsky.  He'd
probably blow a gasket.

Anyone interested in a SENSE-OF-HUMOR TELNET option?  Unfortunately, it
seems the usual response from some people to an IAC DO SENSE-OF-HUMOR
would be IAC WONT SENSE-OF-HUMOR.  Or perhaps we should add a CANT
opcode to option negotiation....
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Those who restrain desire, do so because theirs is weak enough to be
 restrained..." - Blake, "The Marriage of Heaven and Hell"

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 23:30:23 GMT
From:      skl@van-bc.UUCP (Samuel Lam)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)

In article <8904081252.AA03712@alanine.phri.nyu.edu>, roy@ALANINE.PHRI.NYU.EDU (Roy Smith) wrote:
>Uh, yeah Bob, I think it was a joke.  Did you notice the April 1st date
>on the RFC?  You are of course correct about the evils of subliminality
>but I wouldn't be surprised if some hackers out there have already worked
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>support for 1097 into their telnet clients and servers.  Perhaps it was
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>a joke taken too far, but rest assured that it was a joke.

Well, at least they wouldn't be able to implement RFC1097 "to-the-letter". :-)

RFC854 says the TELNET option code is one-byte long.  Now, someone would
have to be pretty creative to figure out how to jam the decimal value
257 into that poor byte. :-)  (Of course, "byte" means octect in this
context.)

(I admit that I wasn't totally convinced about it being a joke until the
257 came along. :-( )

-- 
Samuel Lam     {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 89 23:39:00 GMT
From:      skl@van-bc.UUCP (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   NNTP client or server for the new KA9Q

Has anyone written a NNTP client or server to run inside the new (NOS)
version of Phil Karn's KA9Q TCP/IP package yet?

Thanks in advance for any information.

...Sam
-- 
Samuel Lam     {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 00:16:12 GMT
From:      hughes@bnrmtv.UUCP (Kent Hughes)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Protocols for Presentation/Application Layers?

you might try the CCITT Blue Book Recomendations (1988) Series
X.200, in particular X.219 "Remote Operations: Model, Notation, and
Service Definitions," and X.229 "Remote Operations: Protocol Specifi-
cations."

The very same standards recommendations appear in the ISO documents,
(Draft?) International Standard ISO/IEC/DIS 9072-1.2 and ISO/IEC/DIS
9072-2.2.

There is probably much more available (I don't know where the current
ANSI T1S1 work is at the present time), but this might help you.

Kent Hughes
NT Mountain View

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 02:00:05 GMT
From:      schoff@REBEL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: cisco, secure gateways

Cisco's have been used by Corporate NYSERNet members succesfully who were
interested in security.  This concept of "security" through additional
network structure is old, however, I've explained it to so many
people lately that I got tired and just wrote an article with pictures
so even marketing types can understand it.  I liken it to the electric
fence, you can still see the "target" (usually through DNS) and your
SOL if the power goes away (I'm being obscure purposefully).

Maybe I can sell OLE the reprint rights for Connexions, he'll probably want
to add German Sheppards though...

Herr Marty
----------------------- 
    I'm looking for a gateway that will provide subnet isolation.  Cisco
    has been recommended as the way to go.  My question is does anyone out
    there have any experience with cisco?  Are there any problems or
    quirks with cisco that I should be aware of?  Would anyone recommend
    a different gateway?  I'll be using either twisted pair or ethernet
    for a medium.  Please e-mail responses and I'll summarize to the net.

    Thanks,

    ~Jim

    (213) 336-3048

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 03:09:53 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address per host vs. per interface (was: Re: Super Cheap IP router)

In article <424@mahendo.Jpl.Nasa.Gov> poseur!earle@Sun.COM writes:
> ... and I also just discovered an Encore Annex terminal server that
> gives the same IP address to it's Ethernet interface, and to a permanently-
> attached SLIP interface...

This isn't really something special about the Annex; the ability to give
multiple interfaces the same IP address is inherited from the 4.3BSD
networking code, and any BSD-based host should be able to do the same
thing.  The one special thing the Annex does is respond to ARP requests
for the SLIP destination address, if its network number is the same as
the one on the Annex's Ethernet interface.  This makes it convenient for
connecting isolated hosts, as no additional routing information is needed
(as you've discovered).

-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140
loverso%Xylogics@Encore.COM		Annex Terminal Server Development Group
encore!xylogics!loverso			[formerly of Encore Computer Corp]

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 12:33:41 GMT
From:      schoff@REBEL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET ?

Strictly speaking the ARPANet is being replaced by other DARPA
networks on the National Networking Testbed (NNT), and the ARPANet
is still chugging along as we speak.  The NSFNet is a national network
connecting regional networks (BARRNet in your area).  Indvidual organizations
don't join NSFNet they join a regional.

Of course one paragraph doesn't do any of this jstice.

Marty
-------------

    I'm not sure that this is the right group to post this to.

    I heard the other day about a network called NSFNET that is supposedly
    replacing the ARPANET.  Can anyone tell me something about it and how
    one goes about getting on this network?  Does one need to have some 
    affiliation with a government agency?  Is there a better group to
    post this question to?

    Thanks in advance,
    Gerald Aden
    -- 
    Quotron Systems Inc.	          | Phone: (213)302-4254 FAX: (213)302-
   4499
    Dept. 36240                       | uucp: uunet!janus!ge1cbx!gerald
    12731 West Jefferson Blvd.	      |       trwrb!hacgate!janus!ge1cbx!gerald
    Los Angeles, CA 90066             |       gerald@ge1cbx.quotron.com

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Apr 89 17:29:20 EDT
From:      Jim_Sweeton@um.cc.umich.edu
To:        tcp-ip@sri-nic.arpa, nsfnet-info@merit.edu, gerald@ge1cbx.quotron.com
Subject:   re: tcp-ip question about NSFNET
 
 
>I heard the other day about a network called NSFNET that is supposedly
>replacing the ARPANET.  Can anyone tell me something about it and how
>one goes about getting on this network?  Does one need to have some
>affiliation with a government agency?  Is there a better group to
>post this question to?
>
 NSFNET is the National Science Foundation Network, a transcontinental
 backbone network managed by the Merit Computer Network in Ann Arbor.
 If you would like information about NSFNET, please send a message to
 nis-info@merit.edu, or call 1-800-66-MERIT.  We would be happy to help
 you get the connectivity you need.
 
      --Jim Sweeton
        Merit Information Services
        jcs@merit.edu
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 20:24:00 GMT
From:      khan@iuvax.cs.indiana.edu
To:        comp.protocols.tcp-ip
Subject:   Bidirectional communication (HELP)



Can anyone tell me how to use bidirectional communication in UNIX tcp-ip,
using STREAM sockets.  I am trying to implement a CLIENT-SERVER model
application.  Here is what each of them successfully do:

CLIENT:
...
s = socket(AF_INT,SOCK_STREAM,0);
if (s < 0)
...

if (connect(s,(char *)&server, sizeof(server)) < 0)
...

if (write(s,msg,strlen(msg)) < 0)
...


SERVER:

f = socket(AF_INET, SOCK_STREAM, 0);
...
if (bind(f,(struct sockaddr *) &sin, sizeof(sin)) < 0) 
...

listen(f,5)
for (;;)
...
len = sizeof(from);
g = accept(f,(struct sockaddr *)&from,&len);
...
if ((rval = read(g,msg,1024)) < 0)
...


The CLIENT succeeds in establishing a connection with the SERVER and sends
it a message which the SERVER receives.  Now the problem is that the server
cannot send a message back to the CLIENT.  I tried writing on the socket
"g" on the SERVER side but it doesn't send the message.

Could somebody tell me what I am doing wrong or what I am not doing.

Thank you (you can send me mail if you like).


------------------
Iqbal Mustafa Khan
------------------
khan@iuvax.bacs.indiana.edu
Computer Science Department
Indiana University
Bloomington, Indiana

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 22:00:01 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

Is there any particular reason why we have to enumerate every piece of
computer hardware in the world?

For instance, the domain application wants host type and OS type for the
hosts on which the domain's nameservers run.  What on Earth for?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 89 22:34:35 GMT
From:      eric@ists.ists.ca (Eric M. Carroll)
To:        comp.protocols.tcp-ip
Subject:   IP based authentication of hosts

While pondering the vulnerabilities that we are about to expose
ourselves to when we connect up to the Internet, I have been left with
some questions about the believability of IP addresses.

Namely, most bsd/sunOs authentication is done on the basis of host name
(ie ip address) then (sometimes) uid. UID authentication is clearly 
meaningless. But given a packet coming in to my machine with a forged IP
source address, what are the chances of an attacker actually
establishing a real tcp connection? What UDP based services would *not*
require a response to work (ie what could he do blind)? What conditions 
would be required to allow the attacker to sucessfully represent themselves
as another host?

A first cut look at the problem suggests that in the world of routers,
forged IP address can be delivered to the target but responses don't
get returned to the attacker. A one-way connection. Looks useless at
first glance.

Any comments or paper references would be appreciated. Email to me, 
and I will summarize. Thanks.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 03:23:26 GMT
From:      mshiels@tmsoft.uucp (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

The best ideas for helping to support a PC as a gateway machine are
SMART ethernet cards and SMART serial cards. (Or us a 16550 UART which has
16 byte buffers for in/out bound data).  You can write packet drivers
which will talk to a smart serial card which has a custom process written
to run on it which talks SLIP.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 04:30:30 GMT
From:      birri@unigs.CH (Birri Peter)
To:        comp.protocols.tcp-ip
Subject:   SLIP needed

we are looking for a SLIP protocol. 
Can anybody tell me where to get public domain sw in europe ?

Peter Birri
Comtek AG
Switzerland
FAX ++41 1 844 28 18

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 05:18:36 GMT
From:      morrison@accuvax.nwu.edu (Vance Morrison)
To:        comp.protocols.tcp-ip
Subject:   PCroute IP router to be posted

Hello,

I have had several requests to post the PCroute software in a way that
people who are not directly on the Internet can gain access to it.

For those who came in late, the PCroute software is code that I have
written that will turn an XT into an IP router for about $450.  Since
you can buy a monitorless XT for $400 this means you can make an IP
router for < $900.  For those on the Internet you can pick it up from
accuvax.nwu.edu (129.105.49.1) in the directory pub/pcroute.  It is
called pcroute.tar or pcroute.tar.Z (compressed)

I am posting PCroute to the 'comp.binaries.ibm.pc' newsgroup in the
next day or two.  Anyone not on the Internet but who gets this
newsgroup can pick it up there.

I realize that this still may not cover everyone, but I know of no way
of doing that.  Any suggestions?  In the mean time I will mail the shar
to anyone who can not get it any other way (it is 77K).

ANSWERS TO COMMON QUESTIONS

	1) Will it support SNMP?	No.  SNMP is to complicated.

	2) Will it support RIP?		Yes I am working on that now

	3) Will it support SLIP?	It could if someone wrote the driver
					we have no use for this but if someone
					wants to write it I will point the 
					right direction.   

	4) What is the Atalk support?	I have written a driver that allows
					the router to send IP packets over
					Apple localtalk.  This is very nice
					for us because with Phonenet, this
					allows us a Cheap method to use twisted
					pair wiring to get IP in and between
					building (~5000 ft) in a star config, 
					at speeds (230Kbits/sec) better than 
					slip or X.25.

	5) What is it written in?	Assembler, my own interesting style
					which takes some disipline on the part
					of the programmer, but ultimately 
					make assembly code a tolerable 
					programming environment.

	6) What about source?		I have not distributed source at 
					because I am still working on major 
					additions to the code and I don't want
					to have to deal with supporting and
					explain and merging my code with others.
					In about 3 months I will release source.					Until then, people who what to just
					look at it or use it for other purposes
					(making a bridge for example) can ask
					me for it.
	
	7) Can I write a 3Com driver?	Well, Yes and No.  Yes you certainly
					can do it, but I am not sure of its 
					speed.  One big reason I used WD is 
					because it does on board queueing in
					dual port ram.  Thus I use no interupts
					or DMA.  This also means the most time
					critical part of the operation (input
					packet queueing) does not involve  
					(slow) CPU.  My recommendation is just
					to buy the WD8003 cards (after all they
					are only $225 a piece) and use your
					3Com cards somewhere else.


Vance Morrison <morrison@accuvax.nwu.edu>

[
The above software will be posted in comp.binaries.ibm.pc
on April 13, 1989.

Rahul Dhesi -- moderator, comp.binaries.ibm.pc.
]

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 08:52:16 GMT
From:      kls@tumuc.UUCP (Klaus Steinberger)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: CMU-TEK and VMS5.0

In article <16847@cup.portal.com> Brian_C_McBee@cup.portal.com writes:
>Has anyone succeeded in getting CMU-TEK TCP/IP to run under VMS 5.0-2?
>We only had it running for a few weeks under 4.7 and had to upgrade to
>5.0 to run some other software.  Is there hope, or should I just write
>it off? :-)
>				Brian

You need some new images (especially the IPACP). You can get
this images from:
Art Stine
Clarkson University
Educational Resources Center
Potsdam, NY 13676
BITNET: ABSTINE@CLVMS
INTERNET: ABStine@CLVMS.Clarkson.Edu

There is also an list for discussing CMU-TEK related things:
The list is CMU-TEK-TCP@cs.cmu.edu
send request to cmu-tek-tcp-request@cs.cmu.edu


Also there is currently a version for VMS5.x under work
at CMU, this version would be called 6.4, and it should be finished
in a few weeks

Sincerely 
Klaus STeinberger

BITNET: steinber@DGATUM5p

C
C

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 11:57:00 GMT
From:      Mly@AI.AI.MIT.EDU (Richard Mlynarik)
To:        comp.protocols.tcp-ip
Subject:   HINFO


    Date: 9 Apr 89 22:00:01 GMT
    From: mailrus!shadooby!accuvax.nwu.edu!nucsrl!gore@bbn.com  (Jacob Gore)

    Is there any particular reason why we have to enumerate every piece of
    computer hardware in the world?

    For instance, the domain application wants host type and OS type for the
    hosts on which the domain's nameservers run.  What on Earth for?

Re host type:

How else does my machine I determine what pathname syntax to use for the
host's filesystem?

How else can my machine determine how to interpret the idiosyncratic
results returned by such semi-standard things as FTP LIST?

How else can my machine attempt to try to compensate in advance for
well-known (but never repaired) bugs in implementations of
specific network protocols under specific operating systems?




TCP interconnectivity is increasingly a "least common denominator"
effort at the level of what various broken (usually unix)
implementations -implement-, rather than what the specifications
-specify-.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 13:03:29 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address per host vs. per interface, <424@mahendo.Jpl.Nasa.Gov>

[deleted]
>Further enlightenment would be appreciated ...
>-- 
>	Greg Earle			earle@Sun.COM
>	Sun Microsystems		earle@mahendo.JPL.NASA.GOV
>	JPL on-site Software Support	poseur!earle@elroy.JPL.NASA.GOV
>...!{cit-vax,ames}!elroy!poseur!earle	...!sun!{poseur!}earle

Charles - I agree with Greg; it's time for one of your tutorials.
Please - Craig

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 15:02:01 GMT
From:      abstine@sun.soe.clarkson.edu (Arthur Stine)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: CMU-TEK and VMS5.0

From article <16847@cup.portal.com>, by Brian_C_McBee@cup.portal.com:
> Has anyone succeeded in getting CMU-TEK TCP/IP to run under VMS 5.0-2?
> We only had it running for a few weeks under 4.7 and had to upgrade to
> 5.0 to run some other software.  Is there hope, or should I just write
> it off? :-)
> 				Brian

V6.4 of the software which supports V5.x VMS is supposed to start shipping
pretty soon (weeks, not months). The field test ended a couple weeks ago
and I guess all the current licensees will be getting a letter about
upgrading.

art

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 15:12:18 GMT
From:      lopez@JVNCA.CSC.ORG (Claudia Lopez)
To:        comp.protocols.tcp-ip
Subject:   information on X.500


Hi,

I am looking for some information on X.500 distributed Data Base.
I will appreciate any information or documentation you may have.

Thanks in advance.
Caludia Lopez
Net-Coordinator
Lopez@jvnca.csc.org

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 15:12:54 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal

Bob,

Better check RFC 748 for another bad idea.

Alex McKenzie
 

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 15:18:05 GMT
From:      lopez@JVNCA.CSC.ORG (Claudia Lopez)
To:        comp.protocols.tcp-ip
Subject:   information on X.500


Hi,

I am looking for some information on X.500 Distributed Data Base.
I will appreciate any information or documentation you may have.


Thanks in advanced
Claudia Lopez
Net-Coordinator
Lopez@jvnca.csc.org

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 16:03:29 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET ?


ARPANET is being gradually decommissioned.

DARPA is building the Defense Research Internet (DRI) for the conduct of
DARPA business.

NSFNET is assuming the role of providing general purpose networking in
support of scientific research and other scholarly activities.  In your
case, access would be obtained through the regional network CERFnet, whose
Chairperson is Susan Estrada <estradas@sds.sdsc.edu> 619-534-5067.

In the longer term, the research-support networking activities of Federal
agencies are being coordinated as recommended in the 1987 report "A
Research and Development Strategy for High Performance Computing" issued by
the White House Office of Science and Technology Policy.  Within this
strategic plan, networks of NSF, DARPA, NASA, DoE and other agencies will
be merged into a single National Research and Education Network, with
backbone speeds rising from the present 1.5 mb/s to 45 mb/s within three
years, and to 1-3 gb/s within ten years.

-s

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 16:21:45 GMT
From:      dsmith@oregon.uoregon.edu (Dale Smith)
To:        news.software.nntp,comp.protocols.tcp-ip,comp.os.vms
Subject:   Looking for NNTP client for Unix, VMS, and MS-DOS

I am looking for a NNTP client that provides rn-like functionality for
various operating system environments (Unix, VMS, and MS-DOS).  Yes, I
know about rrn, but I don't think it would run on a PC or on my VMS host. 
Yes, I know about ANU news (I run it), but I would like something that
uses BSD 4.3 network programming libraries (DECnet transport for the VMS
environment) and termcap or curses.  What I want is a common piece of
software that runs in multiple environments and is suitable for
providing news service to lots of small, sites that don't have many
resources or technical expertise (just install it and go).  I saw an
NNTP client in comp.os.vms some time ago that might be retrofitted for
my application, but lost the references. 

Any pointers or suggestions would be appreciated.

Thanks in advance,

Dale Smith			Internet: dsmith@oregon.uoregon.edu
University of Oregon		BITNET: dsmith@oregon.bitnet
Computing Center		UUCP: ...hp-pcd!uoregon!dsmith
Eugene, OR  97403-1212		Voice: (503)686-4394

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 16:22:06 GMT
From:      bob@oz.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.lang.ada,comp.software-eng,comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.nfs,comp.dcom.lans
Subject:   Re: Subliminal

(In the voice of Foghorn Leghorn:) "That's a joke, son!"

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Apr 89 16:24:02 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

In article <8904061537.AA00580@lear.ultra.com> wayne@ultra.UUCP (Wayne Hathaway) writes:
>... It made no difference
>whether the terminals involved were 2741's, 2740's, 3270's ("modern"
>boob tubes), or even ASR33's -- they were ALL driven with the idea
>that there was a time for waiting for output and there was a time for
>typing input, and the HOST was the one who determined which was which.

Um, the ASR33, for all its other flaws, at least was full-duplex.  It
didn't have IBM Terminal Disease.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 18:18:14 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

In article <7080013@eecs.nwu.edu>,ntgore@eecs.nwu.edu (Jacob Gore) writes:
   Is there any particular reason why we have to enumerate every piece of
   computer hardware in the world?

Well, I think the general principle goes something along the lines of:
Since, the world being as it is, it is often necessary or desirable for
two pieces of hardware to be able to use information about each other
in order to communicate.  For terminals this is particularly necessary
if any functinality greater than "glass teletype" is desired.  Making this
type of information available automatically (such as through a domain
name server, the telnet TERMINAL-TYPE negotiation, Hesiod, etc.) results
in decreased time and increased accuracy over the alternative of having
users supply this information whenever it is needed.  In fact, users
may well not have this information readily available, if at all.

   For instance, the domain application wants host type and OS type for the
   hosts on which the domain's nameservers run.  What on Earth for?

I can think of several reasons off-hand.  The most practical one is for
identifying special circumstances.  For example, the FTP client in our
Macintosh TCP/IP package uses this information to provide extended
functionality (such as directory browsing and file size estimation)
for hosts it "understands."  It can make do without it, but taking
advantage of it allows us to move the burden of system-specific
knowledge from the user to the software.  Network diagnostic programs
can use this information to improve the intelligibility of their output.
Programs such as mailers can use the well-known-socket information to
predetermine whether or not a given type of service is available on
a particular host.

We don't, of course, *need* to enumerate all of this stuff, but it is
often quite useful...


--
Amanda Walker <amanda@lts.UUCP>
InterCon Systems Corporation
--
"A keyboard ... how quaint!"  -- Scotty, Star Trek IV: The Voyage Home

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 18:40:46 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNET ?

In article <8904091233.AA00388@rebel.nyser.net> schoff@REBEL.NYSER.NET
 ("Marty Schoffstall") writes:
>Strictly speaking the ARPANet is being replaced by other DARPA
>networks on the National Networking Testbed (NNT), and the ARPANet
>is still chugging along as we speak.  The NSFNet is a national network
>connecting regional networks (BARRNet in your area).  Indvidual organizations
>don't join NSFNet they join a regional.
>
>Of course one paragraph doesn't do any of this jstice.
>
>Marty
>-------------

	You are right, one paragraph can't do the topic justice.  The
original poster gets Internet service from uunet.  This will not change
at all as the arpanet goes away and nsfnet develops.  That may allay
some fears about connectivity.

	Of course, in a way, the old arpanet operational service *is*
being transferred to the NSFnet.  The NNT will be research oriented
and not for production e-mail use.  (Back to the roots.)  So, most
people's idea of arpanet service is moving to the NSFnet.

	In southern CA, Quotron could join the San Diego Supercomputer
regional or perhaps one of the other quasi-independent networking
conspiracies in CA.  I know of four now (BARRnet in the Bay Area,
SDSCnet in San Diego, CERFnet, and Los Nettos in LA).  I think that is
a record of sorts.  (I forgot to mention Shorelinenet, (good luck
folks) :-).

	Be prepared to pay your way and to use the net only for
academic, educational, and research purposes.  It's a little looser
than the arpanet was.  Understand you get telnet, ftp, smtp as well as
mail gateways to usenet, csnet, bitnet, etc.

	So call your local regional network sales office and sign up!
:-) 

	Kent England, Boston University

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 20:34:46 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  HINFO

>How else does my machine I determine what pathname syntax to use for the
>host's filesystem?
>How else can my machine attempt to try to compensate in advance for
>well-known (but never repaired) bugs in implementations

I don't believe that very many existing implementations in fact use
HINFO for this (or any other) purpose.  In fact, I know of none; can
someone correct me (maybe LispMachines?)?  If what you care about is
implementation bugs, then HINFO is the wrong level of analysis -- you
don't care that a system is a MICROVAX-II running VMS, but that it is a
VAX running VMS with Wollongong version 5.0SMP or whatever.  The best
way to find out about version-specific bugs in a particular instance of
a service is to query the service on that host.  For example, the
herald when you connect to the SMTP socket on a host usually contains
version information about the particular SMTP implementation:
    220 hogg.cc.uoregon.edu Sendmail 4.0/SMI-4.0.1 ready at Mon, 10 Apr 89 12:59:35 PDT

HINFO seems to me to be a holdover from late-1970s perceived needs as
realized in HOSTS.TXT.  In the present era it makes very little sense,
and in fact many domain administrators are quite careless about keeping
it up to date or making sure that the values are chosen from the
(always out of date) legal list in assigned numbers (What value should
I choose for a Mac-IICX running NCSA Telnet?  No "Mac" value appears in
RFC1010, but Macs are rapidly becoming the most common IP-speaking
machine on our network).  The proposal to delete HINFO makes good sense
to me.

On the other hand, it is often useful to humans (particularly people
debugging the network) to be able to learn something about a foreign
machine.  I frequently find myself looking for the HINFO data about a
misbehaving remote machine, then (when I find that there is no HINFO
data, and perhaps not even a domain entry for the machine) I telnet to
the machine to see what the telnet herald reports.  If we really care
about this data, the place to put it is in a new IP self-description
service that a machine could offer; the machine, after all, is the most
likely place for up to date data to be available!  If it must be in the
domain database, then making it a longer descriptive string rather than
a forced-choice keyword would make it much more useful.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 23:01:05 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Cc:        budd@bu-it.bu.edu tower@bu-it.bu.edu
Subject:   Re: IP based authentication of hosts

In article <376@ists.ists.ca> eric@ists.ists.ca (Eric M. Carroll) writes:
>
>A first cut look at the problem suggests that in the world of routers,
>forged IP address can be delivered to the target but responses don't
>get returned to the attacker. A one-way connection. Looks useless at
>first glance.
>
	Seems to me that if the router follows source routing and the
host follows source routing (as required by the Gateway and Hosts
(draft) RFCs) that you can easily spoof IP source addresses.

	If this is true, why is source routing required and not
optional?  Shouldn't I be allowed to turn it off if I worry about the
veracity of source addresses, or I want to implement security levels
that vary by subnet?

	Kent England, Boston University

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 89 23:46:13 GMT
From:      gerald@ge1cbx.UUCP (Gerald Aden)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip multicasting

I am trying to obtain information on any current activities for providing 
multicasting/group-addressing services across interconnected LANs and/or 
WANs (particularly in X.25 arena).  I am interested both in standards 
development work and in existing proprietary implementations of such 
services.  Any level of information will be useful!

Please reply to:  Gerald Aden at uucp address below

Thank you for your cooperation in this matter.


Alex Kapelnikov 
Quotron Systems
-- 
Quotron Systems Inc.	          | Phone: (213)302-4254 FAX: (213)302-4499
Dept. 36240                       | uucp: uunet!janus!ge1cbx!gerald
12731 West Jefferson Blvd.	      |       trwrb!hacgate!janus!ge1cbx!gerald
Los Angeles, CA 90066             |       gerald@ge1cbx.quotron.com

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 01:33:15 GMT
From:      elliston@rob.UUCP ( Keith Elliston)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Getting on the Arpanet...


I'm not sure which groups this should go to... so I chose the ones I felt would
respond....

I need to find out how one gets his computer (Vax or Unix) onto the internet,
specifically onto Arpanet.  I have no idea how this is done, so I need to start
with the very basic basics.  Just to narrow down the problem, I will try to
clarify the situation.

We (figuratively) are a commercial outfit that need s access to electronic mail
and FTP over the internet.  We specifically want our scientists to interact withother scientist (mostly academic scientists) on the nets, and be able to exchange software, data, and manuscripts at will.  We currently have a usenet feed,
but that just doesnt have the capability that we need.

So... where do I start, what does it cost, what can/can't I do... help!?!?

I look forward to loads of info....

-Keith Elliston

uunet!rob!elliston

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 03:04:54 GMT
From:      bownesrm@beowulf.UUCP (Uncle Keptin Comrade Dr. Bobwrench)
To:        comp.protocols.tcp-ip
Subject:   VMS Ftp won't mkdir


	I'm trying to ftp from a Sun to a 8650 running Wollongong's FTP
	and it informs me 'I/O error' when I issue a mkdir command.

	Is this a feature or a bug? Or am I doing something wrong?

	thanks, bob

-- 
"Reading legal mush can turn your brain to guacamole"
Bob Bownes, aka iii, aka captain comrade doktor bobwrench
3 A Pinehurst Ave,	Albany, New York, 12203, (518)-482-8798 voice 
bownesrm@beowulf.uucp {uunet!crdgw1,rutgers!brspyr1}!beowulf!bownesrm

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Apr 89 10:08:51 -0400
From:      Debbie Deutsch <ddeutsch@BBN.COM>
To:        Claudia Lopez <lopez@jvnca.csc.org>
Cc:        tcp-ip@SRI-NIC.ARPA, ddeutsch@BBN.COM
Subject:   Re: information on X.500

X.500 is a distributed directory system.  Of course it has elements of
a distributed database, but it has a lot of other things, too.
Perhaps most important, it provides a framework for naming objects
(people, applications, etc.) with which one might communicate via a
large, multiply-administered network.  X.500 addresses topics such as
security (via use of certificates) but does not fully treat
traditional aspects of databases such as access control.

X.500 is described in a series of eight documents.  They are available
from:

Omnicom
115 Park St., SE
Vienna, Virginia 22180

703-281-1135

Regards,

Debbie Deutsch
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 03:46:47 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

Yes, with source routing you can fake IP addresses in such a way that
you get a two-way conversation going to the wrong place.  For that
reason, our gateways drop any packet that uses source routing.  I'm
looking into a more selective approach, but for the moment this seems
the safest.  However even the ability to fake source addresses leaves
the possibility of some damage.  Some servers (e.g. some options of
YP, maybe also named) may allow you to change a database with a single
packet.  The fact that you don't get an ACK doesn't necessarily
prevent the damage from being done.  This suggests that RPC servers
that make significant changes should require passwords or some other
validation.  Furthermore, I'll bet I could find a way to open a TCP
connection even if I don't get the ack's back.  Probably I couldn't
keep it open very long, but I might get enough data through to do an
rsh.  It would require some intelligent guessing of what sequence
numbers you're using, and probably a good deal of redundant traffic.
Eventually I'm probably going to make our external gateways check
source addresses of packets they forward.  The idea would be to refuse
to allow packets into Rutgers from the outside with Rutgers source
addresses.  However in the end we're probably going to want
encryption-based validation for everything.  I think even with kludges
in the gateways, the days are numbered for security based on source
addresses.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 10:50:56 GMT
From:      marcel@dx7.UUCP (Marcel Bernards)
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK TCP-IP 5.0 and Printer queue on a TCP terminal server ??

Hello there,

We currently own the 4.X version and it works fine for us.
The Question I have is about installing a possibility of
creating a VMS printer-symbiont to a (telnet)TCP terminal server
like a spider port or a Ungermann-Bass NIU-1X0.

Does someone on the net has managed something like this ??

Currently we use a DECSERVER-200 NIU-180 back to back Klude 
to print via LAT to a printer connected on a terminal server.

If we can manage to use TCP, we can get rid of the DECSERVERS
and use TCP/IP ( We are a fast growing TCP site , DECNET going Bogus ;-)

Please E-mail if you can.

-- 
Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN
P.O. Box 1, 1755 ZG Petten, PHONE: 09 312246 4342 EARN/BITNET:ESU0130@HPEENR51 
IP: marcel%ecn.uucp@nluug.nl UUCP: marcel@ecn.uucp,marcel%ecn.uucp@uunet.uu.net
SCREAMNet : AAAAAARGHH!HUH?? : Disclaimer: "The AntiChrist is the Computer !" 

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 11:03:50 GMT
From:      yeongw@LENNON.NYSER.NET
To:        comp.protocols.tcp-ip
Subject:   Re:  information on X.500

QUIPU, which is an implementation of X.500 from UCL, is distributed
with the ISODE 5.0 package. For more information, I suggest you send
a message to the 'isode' list.

Wengyik

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 12:30:04 GMT
From:      peter@aries5 (Peter Bumbulis)
To:        comp.protocols.tcp-ip
Subject:   Hitchhikers Guide to Internet, Intro to Internet Protocols

I'd like to locate the documents ``Hitchhiker's Guide to the Internet''
(Ed Kroll (sp?)) and ``Introduction to the Internet Protocols'' (Charles
Hedrick).  Are they available for ftp from somewhere?  Thanks in advance,

Peter

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 14:08:51 GMT
From:      ddeutsch@BBN.COM (Debbie Deutsch)
To:        comp.protocols.tcp-ip
Subject:   Re: information on X.500


X.500 is a distributed directory system.  Of course it has elements of
a distributed database, but it has a lot of other things, too.
Perhaps most important, it provides a framework for naming objects
(people, applications, etc.) with which one might communicate via a
large, multiply-administered network.  X.500 addresses topics such as
security (via use of certificates) but does not fully treat
traditional aspects of databases such as access control.

X.500 is described in a series of eight documents.  They are available
from:

Omnicom
115 Park St., SE
Vienna, Virginia 22180

703-281-1135

Regards,

Debbie Deutsch

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Apr 89 21:29:09 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!mnetor!tmsoft!mshiels@csd4.milw.wisc.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Super Cheap IP router (< $1000)
No doubt, I missed all of the important messages, earlier.  If so, please
forgive, but..

The ONLY function that you need in the i/o cards of a cheap (and even many
expensive) routers is to buffer data adequately, to avoid dropping
back-to-back packets (for a fast LAN) and to avoid excessive (e.g.,
per-character) interrupt rates.  In the PC world, especially, intelligent
LAN cards have a habit of being slower than the PC, adding $500 to the
cost, per network interface, and making routing quite difficult, since
you end up with IP inside multiple interfaces.  Putting the
link-level code into the interface usually makes sense, especially with
the number that now are in silicon; is that being called "intelligent"?

Dave
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 15:29:46 GMT
From:      mcneill@eplrx7.UUCP (mcneill)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Routers

Soon I am going to need some sort of router/gateway to route TCP/IP between 2
ethernets (about 10 miles apart).

What is out there in the way of Routers/gateways?  

Thanks,

Keith
-- 
    Keith D. McNeill              |    E.I. du Pont de Nemours & Co.
    eplrx7!mcneill@uunet.uu.net   |    Engineering Physics Laboratory
    (302) 695-7395                |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 16:15:25 GMT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

> In article <8904061537.AA00580@lear.ultra.com> wayne@ultra.UUCP (Wayne Hathaway) writes:
> >... It made no difference
> >whether the terminals involved were 2741's, 2740's, 3270's ("modern"
> >boob tubes), or even ASR33's -- they were ALL driven with the idea
> >that there was a time for waiting for output and there was a time for
> >typing input, and the HOST was the one who determined which was which.
 
> Um, the ASR33, for all its other flaws, at least was full-duplex.  It
> didn't have IBM Terminal Disease.
> -- 
> Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
> passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Well, the point I was trying to make was that it didn't MATTER on IBM
operating systems whether the terminal was capable of full duplex
operation or not, the system ran it as half-duplex with a "locked"
keyboard.  Since 2741's and the like could physically lock the
keyboard, there was no confusion.  One system I remember that
supported ASR33's simulated the "locked" mode by just treating
anything typed while "locked" as a BREAK character.  (I think this was
a requirement of the box -- 2703? -- used to connect the ASR33 to the
mainframe.)  Needless to say this was NOT a very nice user interface!

Anyway, the only reason I commented earlier was that this seems to me
to be another of those situations where a simplistic "their terminals
are broken" explanation hides the REAL problem of a completely
different user interface philosophy.  Now it's UNIX, but back then it
was TENEX, and you wouldn't believe the difficulties trying to get
otherwise very bright people to even consider the possibility of
alternative approaches.  Right or wrong, better or worse, that wasn't
the issue -- in general the TENEX crowd couldn't even COMPREHEND any
alternatives enough to evaluate them.  Blaming it on defective
hardware provided a very easy out.

If I felt that this problem died completely with the demise of TENEX
parochialism then I wouldn't have commented.  Unfortunately, the names
have changed but the tunnel vision remains the same.

  Wayne Hathaway            
  Ultra Network Technologies     domain: wayne@Ultra.COM
  101 Daggett Drive            Internet: ultra!wayne@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!wayne
  408-922-0100

PS: Love your quotes, Henry!

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 17:05:02 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <Apr.10.23.46.46.1989.12488@geneva.rutgers.edu> 
hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>Yes, with source routing you can fake IP addresses in such a way that
>you get a two-way conversation going to the wrong place.  
> [...]
> However in the end we're probably going to want
>encryption-based validation for everything.  I think even with kludges
>in the gateways, the days are numbered for security based on source
>addresses.


	I agree that encryption-based validation is important, but we
still want to be sure that the unencrypted data follows specific (in
some sense secure) routes.  I think TOS is the way to do this, but
until then I can structure my subnets in such a way that, with some
physical security, I have some assurance that unencrypted, sensitive
data cannot easily be snooped off the net.

	I would not want to allow someone with genuine
Kerberos-authenticated access to login from an "open" subnet.  I would
want some assurance that the data stream is following routes
controlled by the routers and not by the hosts.  (Another argument
against source routing :-)

	Is this reasonable?

	Kent England, BU

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 18:28:00 GMT
From:      7thSon@SLCS.SLB.COM (Chris Garrigues)
To:        comp.protocols.tcp-ip
Subject:   Re:  HINFO


    Date: Mon, 10 Apr 89 13:34:46 PDT
    From: jqj@hogg.cc.uoregon.edu

    >How else does my machine I determine what pathname syntax to use for the
    >host's filesystem?
    >How else can my machine attempt to try to compensate in advance for
    >well-known (but never repaired) bugs in implementations

    I don't believe that very many existing implementations in fact use
    HINFO for this (or any other) purpose.  In fact, I know of none; can
    someone correct me (maybe LispMachines?)?  
Yes, they do.
								 The best
    way to find out about version-specific bugs in a particular instance of
    a service is to query the service on that host.  For example, the
    herald when you connect to the SMTP socket on a host usually contains
    version information about the particular SMTP implementation:
	220 hogg.cc.uoregon.edu Sendmail 4.0/SMI-4.0.1 ready at Mon, 10 Apr 89 12:59:35 PDT

Basically true, but it isn't in a standardized machine readable form, so
my software can't automatically deal with it.

    HINFO seems to me to be a holdover from late-1970s perceived needs as
    realized in HOSTS.TXT.  
HINFO and WKS are both useful pieces of data for systems which are
willing to make use of them.  The Lisp Machine "Copy File" command uses
HINFO to figure out the pathname of the host it's dealing with and WKS
to figure out what file transfer protocol to use to get to the host.
This means that as a user I use the same command and don't have to care
if the system actually uses FTP, TFTP, NFS, NFILE, QFILE, PUP, or
whatever.
			    In the present era it makes very little sense,
    and in fact many domain administrators are quite careless about keeping
    it up to date 
This is true, but is it an argument against the idea? 
		  or making sure that the values are chosen from the
    (always out of date) legal list in assigned numbers (What value should
    I choose for a Mac-IICX running NCSA Telnet?  No "Mac" value appears in
    RFC1010, but Macs are rapidly becoming the most common IP-speaking
    machine on our network).  The proposal to delete HINFO makes good sense
    to me.
Is your argument that your software doesn't make use of this data, so
therefore it shouldn't be available for those systems which do?  What
ever happened to the philosophy of "Be liberal in what you accept and
conservative in what you generate"?  This implication is that everybody
*should* provide as much info as possible, but nobody should be required
to ask for the info.
    On the other hand, it is often useful to humans (particularly people
    debugging the network) to be able to learn something about a foreign
    machine.  I frequently find myself looking for the HINFO data about a
    misbehaving remote machine, then (when I find that there is no HINFO
    data, and perhaps not even a domain entry for the machine) I telnet to
    the machine to see what the telnet herald reports.  
Fine for human debugging, but as users get more naive, this becomes less
desirable.  Naive users shouldn't ever need to find out this
information.  As it is, they call me to say they have a problem.  I'd
prefer that their software handle it so I don't have to.
							If we really care
    about this data, the place to put it is in a new IP self-description
    service that a machine could offer; 
This idea, I like.
					the machine, after all, is the most
    likely place for up to date data to be available!  If it must be in the
    domain database, then making it a longer descriptive string rather than
    a forced-choice keyword would make it much more useful.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Apr 89 18:54:22 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

In article <1989Apr10.032326.12080@tmsoft.uucp> mshiels@tmsoft.UUCP (Michael A. Shiels) writes:
>The best ideas for helping to support a PC as a gateway machine are
>SMART ethernet cards and SMART serial cards. (Or us a 16550 UART which has
>16 byte buffers for in/out bound data).  You can write packet drivers
>which will talk to a smart serial card which has a custom process written
>to run on it which talks SLIP.

Alternatively, you can make the software do the right thing.  It's not that
hard to get real-time response to device interrupts.  Just because the
high-level software doesn't want to be bothered by interrupts at the moment
doesn't mean that low-level software can't be taking the interrupts and
stashing away the incoming characters.  This is a common tactic for dealing
with high-speed input on dumb serial ports.

Agreed that smartness is required, but it doesn't have to be in the hardware.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 19:36:57 GMT
From:      uucigj@sw1e.UUCP (3531])
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP needed

In article <126@unigs.CH> birri@unigs.CH (Birri Peter) writes:
>we are looking for a SLIP protocol. 
>Can anybody tell me where to get public domain sw in europe ?
>


How about in USA?
Gregg Jensen

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 19:47:28 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal

Alex -

     As the author of RFC 748, I take extreme offense at the suggestion that
RFC 748 was a bad idea.  It was, perhaps, an idea that was before its time
(the RFC was written 10 years ago), but with the advent of Internetworking,
TCP, and ISO the problem addressed by RFC 748 has become more serious.  RFC
748 provides a simple and elegant way of solving the problem.

     I expect that the authors of the forthcoming Host Requirements RFC will
make RFC 748 a mandatory part of all host implementations.

     With tongue firmly planted in cheek,

-- Mark --

-------

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 20:28:45 GMT
From:      jon@athena.mit.edu (Jon A. Rochlis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <29455@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:

>	I would not want to allow someone with genuine
>Kerberos-authenticated access to login from an "open" subnet.  I would
>want some assurance that the data stream is following routes
>controlled by the routers and not by the hosts.  (Another argument
>against source routing :-)
>
>	Is this reasonable?

I don't think so.  What does an "open" subnet mean?  

Remember the model we're working with here.  The path from client to
server may span several networks and pass through several (many)
routers each possibly under different (and potentially hostile)
administrative control.  You cannot say (now or for very long in the
future) that you only allow access to your campus resources from some
"secure" subnets which you in some fashion control.  If a professor
from BU wants to log into an MIT colleague's machine using Kerberos am
I supposed to disallow that because I don't control the BU subnet he's
coming from, the routers in the path on the BU backbone, or the
NEARNet backbone/routers?  What if he's coming in over the NSFnet?

It's the "principal" who's accessing the data, not the machine he's
currently using.  Where the ends of the converstation or the path the
packets take shouldn't matter.  [Some information may be too sensitive
for this, but that should be the exception for quite a while.  No
classified on the Internet, right!]

The only real solution is an end-to-end approach using something other
than addresses for authentication.

		-- Jon

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 20:55:40 GMT
From:      tinker@ultra.UUCP (Don Tinker)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal

I am heartened by the sensibility of the community that met
this proposal with silent disdain. After all, a User is a 
device for maintaining connectivity among devices (or
maintaining reconnectivity, in the case of those $%*&^#%
sliding-latch connectors), and thus more properly should
be specified by EIA.

Don Tinker						tinker@ultra.com
Systems Engineer				(703) 821-8393
Ultra Network Technologies

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 22:33:47 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <10526@bloom-beacon.MIT.EDU> jon@mit.edu (Jon A. Rochlis) writes:
>In article <29455@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>
>>	I would not want to allow someone with genuine
>>Kerberos-authenticated access to login from an "open" subnet.  I would
>>want some assurance that the data stream is following routes
>>controlled by the routers and not by the hosts.  (Another argument
>>against source routing :-)
>>
>>	Is this reasonable?
>
>I don't think so.  What does an "open" subnet mean?  

	I should have known better than to toss that off-the-cuff.
So, Jon takes me to task.  :-)
	How about we call a subnet "open" if it has no special
security features; no control over nodes, etc?  Ie, subject to packet
snooping by anyone on the subnet. 
>
>Remember the model we're working with here.  The path from client to
>server may span several networks and pass through several (many)
>routers each possibly under different (and potentially hostile)
>administrative control.  
>
	I was thinking of a much simpler case where I might be able to
secure a subset of subnets under my control and protect data in
transit from snooping.  I think this is a common case in many
institutions.  If some data paths could be "secured" to some degree
from snooping and all hosts on a "secure" subnet could be maintained
by administrators to some level of security, etc, we might be able to
achieve some measure of protection against snooping for communication
between "secure" hosts.

>
>The only real solution is an end-to-end approach using something other
>than addresses for authentication.
>
>		-- Jon

	True, but assuming that full data encryption is too expensive
in terms of performance and software, perhaps I could implement a
limited security model consisting of "secure" subnets and "secure"
routing that would provide enough protection against snooping that I
could get my administrative users on the network and get their
auditors off my back.  :-)

	So, if I set-up "secure" subnets with hosts that are
"sanitized" to some degree, and I have some level of physical security
on these subnets, and I use Kerberos to protect passwords, and I turn
off source routing in secure hosts and all routers, and secure hosts
do some address checking to keep sensitive data from transiting open
subnets, do I have something worth having, ie a modest level of
security sufficient to fulfill my obligations to protect data and yet
still allow these applications to use network technology?

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 22:48:33 GMT
From:      tdh@moriaMoria.Sp.Unisys.Com (Thomas Hintz)
To:        comp.protocols.tcp-ip
Subject:   Berkeley r-commands

I'm looking for the protocol definition of the Berkeley R commands
(ie. what is the protocol of the rsh/rcmd and rcp commands).

Will someone please point the way to the FM's?


-- 
Thomas D. Hintz				(612) 687-2684
UNISYS					tdh@moria.sp.unisys.com
Custom Networks				..bungia!com50!mscunx!moria!tdh

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 23:10:53 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip
Subject:   Re: Hitchhikers Guide to Internet, Intro to Internet Protocols

Check out topaz.rutgers.edu:~ftp/pub/tcp-ip-docs.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 23:12:46 GMT
From:      renglish@hpirs.HP.COM (Robert English)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN multicasts and TCP/IP

> / hpirs:comp.protocols.tcp-ip / renglish@hpirs.HP.COM (Robert English) /
 
> But then I learn that the Host Requirements RFC explicitly forbids the
> use of physical network multicast addresses for standard IP messages, to
> the extent that hosts receiving standard IP packets from multicast
> sources are required to drop them.  So long, obvious solution.

Hello, obvious solution.  It appears that I misread the Host
Requirements RFC.  It doesn't outlaw link-level multicast source
addresses for IP packets.  It only outlaws link-level broadcast source
addresses for standard (non-multicast or -broadcast) IP addresses.

My thanks to the individual who took the time to set me straight.

--bob--						renglish%hpda@sde.hp.com

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 89 23:23:19 GMT
From:      jeff@hpctdkz.HP.COM (Jeff Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Subliminal (RFC1097)


    I am confused. Is RFC1097 a joke or what? If so, no one is laughing.
I agree with Bob H. completely!

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 03:47:50 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  VMS Ftp won't mkdir

Bob:

You're probably doing something wrong.  Works from a VAX11/750 (4.3bsd) to a
VAX8250 (VMS 4.7) with TWG TCP/IP.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 04:29:09 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

No doubt, I missed all of the important messages, earlier.  If so, please
forgive, but..

The ONLY function that you need in the i/o cards of a cheap (and even many
expensive) routers is to buffer data adequately, to avoid dropping
back-to-back packets (for a fast LAN) and to avoid excessive (e.g.,
per-character) interrupt rates.  In the PC world, especially, intelligent
LAN cards have a habit of being slower than the PC, adding $500 to the
cost, per network interface, and making routing quite difficult, since
you end up with IP inside multiple interfaces.  Putting the
link-level code into the interface usually makes sense, especially with
the number that now are in silicon; is that being called "intelligent"?

Dave

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 10:17:37 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP terminal access to GEAC computers anyone?

GEACs are computers made in Canada and sold mainly (?) for library 
automation. They have an X.25 capability, but I'm not sure what 
protocol they speak over that to their terminal concentrator things 
called NIMs. They allow direct connection of async terminals so it
should be easy to get into them with a terminal server, right?
Wrong. They have their own funny terminals which talk some strange
multidrop polling protocol to the GEAC over the async line. This
lets you put up to 3 terminals on one async line. Each terminal
has to have a unique Polling Code. So you can set it up:

 up-to-3-GEAC-terminals---terminal-server----terminal-server---GEAC

I guess this will work if it is a fixed connection, but the GEAC will
keep polling the terminals across the network. If you try to bring
different (groups of) terminals in from different terminal servers
in to the same port on the GEAC then the polling won't work because
the Polling Codes will be wrong. You could set multiple terminals up
with the same codes, but then they wouldn't be able to use the GEAC
simultaneously (I think).

Well if I had the source for the terminal servers I guess I could
put in special code to fudge the polling and diddle the Polling
Codes. I hope somebody out there has a better idea: or knows more
about these beasts than me. I might say that we have a fair few
of these GEAC terminals, so we'd like a solution that allows them.
Then again they're expensive (understatement) so we would also be
interested in a solution that emulates them on VT100s or similar.

Bob Smart <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 10:24:58 GMT
From:      mark@psauly.UUCP (marco graziano)
To:        comp.protocols.tcp-ip
Subject:   Out-dial for Arpanet

Could anyone tell me if there is any special node on Arpanet that allows
terminals, via dial-up modems, to reach other hosts in Internet ?
Thanks in advance,
	- Marco.

======
Marco E. Graziano
Olivetti Systems & Networks
via Palestro,30
56100 Pisa, ITALY
EMail: oliveb!psauly!mark@sun.com
======

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 15:01:41 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re:  HINFO


Hmm.  You can look at a domain name server in two ways.  The first is
that it replaces the /etc/hosts file under UNIX, that is to say it
provides the mapping between ASCII host names and IP addresses.  This
is currently its primary use most of the time, I admit.  However, you
can also look at it as a way to determine the attributes of hosts and
domains, with the IP address being just one of the attributes.  This
is how I see it, and from my reading of the RFC, is how it was intended.

There are often good reasons for needing to know more than just the IP
address of another machine, and in some cases you need to know this
even if the machine in question is down (MX records, in particular).
A more general host information protocol (HIP? :-)) would be useful,
but I still think that it wouldn't replace HINFO and MX records.

Maybe we shouldn't need them (in some sense of ``should''), but the fact
is that we often do, DNS as it stands does a pretty good job of
solving the problem, and extensions such as Hesiod do the same thing
for users, mailboxes, and so on.

I don't mean to be flippant, but if you know a better way to do it,
by all means implement it and write up an RFC...

--
Amanda Walker <amanda@lts.UUCP>
InterCon Systems Corporation
--
"A keyboard ... how quaint!"  -- Scotty, Star Trek IV: The Voyage Home

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 16:03:12 GMT
From:      dla@athena.mit.edu (Don Alvarez)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <29475@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:

>	... assuming that full data encryption is too expensive
>in terms of performance and software, perhaps I could implement a
>limited security model consisting of "secure" subnets and "secure"
>routing that would provide enough protection against snooping that I
>could get my administrative users on the network and get their
>auditors off my back.  :-)
>
>	So, if I set-up "secure" subnets with hosts that are
>"sanitized" to some degree, and I have some level of physical security
>on these subnets, and I use Kerberos to protect passwords, and I turn
>off source routing in secure hosts and all routers, and secure hosts
>do some address checking to keep sensitive data from transiting open
>subnets, do I have something worth having, ie a modest level of
>security sufficient to fulfill my obligations to protect data and yet
>still allow these applications to use network technology?

No.  You don't have anything worth having.  All I need is an IBM-PC
($0.10/dozen), an ethernet card ($0.20/dozen), and a vampire tap ($0.50/
dozen), and I can listen to ANYTHING I want to on your "secure" subnet.
As you leave your office today, look at the yellow or orange cable running
all over your building/campus and tell me that you can secure every inch of it.
It may sound far-fetched for a student to be running around with an ethernet
card and a vampire tap today, but in five years the statement "nobody can
tap ethernet because they don't have the hardware" will sound like "9600 baud
lines are secure because no hackers can afford 9600 baud modems."  I can
already buy everything I need to tap your ethernet for just over $1000, and
prices are dropping fast.  Remember that any network you would want to secure,
someone else would want to tap.

Unless you can see every inch of your ethernet cable at the same time, and can
put it all behind the same locked door, you don't have a secure subnet.  If you
can secure it, and if enough of your traffic is internel to that subnet to
make your special internal protocol worthwhile, then your best bet is almost
certainly to do as the romans do and not allow any external connections 
to your subnet.  

						-Don
						 boomer@space.mit.edu
						 MIT Center for Space Research

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 18:55:21 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

Using IP source addresses for authentication doesn't work.  In fact, I
just finished a paper which has that as one of its major subthemes;
it will appear in the April 1989 issue of ``Computer Communication Review''.
There are many attacks possible on hosts which believe such address, and
Chuck Hedrick is absolutely correct that one need not hear responses to
a TCP connection request to do harm; details are in the paper.  (Note:
I didn't invent that attack, though I did generalize it a bit.)

In the very near future, we're going to have to use encryption-based
authentication; it's the *only* way.

		--Steve Bellovin
		smb@ulysses.att.com
		att!ulysses!smb

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 21:17:02 GMT
From:      pfrennin@altos86.UUCP (Peter Frenning)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP <-> X.25 Gateway

Expires: 
Sender: 
Reply-To: pfrennin@altos86.UUCP (Peter Frenning)
Followup-To: 
Distribution: usa
Organization: Altos Computer Systems, San Jose, CA
Keywords: 

Anyone out there in netland who has any experience with such boxes?
I would like to collect all info you have, good or bad, pricing,
vendors (ph#).
Pls. mail me, i'll summarize to this newsgroup.

Peter

+-----------------------------------------------------------------------+
|      Peter Frenning, Altos Computer Systems, San Jose                 |
 +--------------------+--------------------------------------------------+
| I don't need a dis-| JackNet:        mgr.prodmkt!pfrennin             |
| claimer, since all | USENET:         pfrennin@altos86.UUCP            |
| my statements are  | VOICE:          (408) 496-6700                   |
| borrowed, and pro- | SNAILMAIL:      2641 Orchard Parkway             |
| bably already dis- |                 San Jose, CA 95134               |
| claimed by someone |                                                  |
| else!              | FAX:            (408) 433-9335                   |
|                PF  |                                                  |
 +--------------------+--------------------------------------------------+

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 21:46:04 GMT
From:      jom@belltec.UUCP (Jerry Merlaine)
To:        comp.protocols.tcp-ip
Subject:   /etc/hosts to BIND

Hello!

In the BIND 4.8 distribution we find:
	1) :pwedit - convert /etc/passwd into user records for BIND
	2) atod.y -  convert /usr/lib/aliases into mail records for BIND

What we do not find is a somewhat more complex program to transform /etc/hosts
into records for the BIND database.  Has anyone done this?

Jerry O. Merlaine
pacbell.com!belltec!jom

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 21:52:17 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

>Indeed.  I spent some time tweaking the KA9Q TCP/IP code to provide a BSD
>  socket interface to applications.  [...]  There's a
>  gotcha with sockets, however.  Sockets are objects upon which it is legal
>  to do read () and write () calls (a socket looks like a file descriptor that
>  is both readable and writeable).

I recently rewrote my package to use a very simple non-pre-emptive
multitasking kernel. It provides what I believe are generally known as
"lightweight processes" -- tasks share external and static variables,
but they have private stacks and therefore private automatic variables.
Tasks are switched with the C-library setjmp/longjmp functions --
simple, effective and about as portable as such code can be. As before,
heavy use is made of the storage allocator to create per-process
data structures that must be maintained between calls to a function or
shared across multiple functions.

This made it possible to implement a socket layer as a "veneer" on top
of the older upcall mechanism, and to rewrite all of the applications in
terms of the new socket interface. (I was amazed at how much simpler the
FTP client became!)

Pretty much the whole set of Berkeley socket calls are provided with
similar semantics, albeit with the caveat that I didn't test Berkeley's
code to see exactly how it behaved in all sorts of strange exception
conditions. In doing this job (now the so-called "NOS" version) I ran
smack into the problem you report. I would have very much liked to use a
common file descriptor space for both sockets and regular file
descriptors, but this just didn't seem possible to do in a portable
manner. So the socket descriptor space is distinct, and you can't do
read, write or close calls on socket descriptors (a separate call,
close_s, is provided for closing sockets).

A snapshot of my current development work can be found on
flash.bellcore.com under /pub/ka9q/src.arc. An executable is in
/pub/ka9q/net.exe.  Please don't pepper me with a lot of questions, it's
still being polished and I haven't had time to write the documentation
yet.

Phil

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 22:54:07 GMT
From:      ml@gandalf.UUCP (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Promiscuous ARP


I have a couple of questions for this group.  They're largely independant
    but I'm packaging them together for economy :-)

I intend to build a network of Convergent MightyFrame machines running
  their TCP/IP software (Berkeley-style, with sockets).  I'd like to
  build a network that looks like this:

                     [---------ETHERNET-A----------]
                                    |
                                 MACHINE A
                                 /         \
                               /             \
                            SLIP              SLIP
                            /                   \
                           /                      \
                       MACHINE-B-----SLIP-------MACHINE-C
                          |                        |
                [----ETHERNET-B----]     [----ETHERNET-C----]


I'd like to configure each of the SLIP<--->ETHERNET gateway machines
    such that they'd respond to ARP requests for either of the two "other"
    networks ("Promiscuous ARP").  Is it possible to do this with the
    regular Berkeley networking code?  With the Convergent TCP/IP?
I could, of course, put default gateway information into each of the
    hosts on the local ETHERNETs, but I'd like to avoid having to do that.
    


Question 2 is this:  Can anyone point me in the direction of source code
    for BIND, or any other reasonable-good Domain Name Server implementation?
-- 
"This sentence not witty"               #include <std_disclaimer.h>
Marcus Leech                            E-mail:      ml@gandalf.UUCP
Gandalf Data Ltd                        PacketRadio: VE3MDL@VE3JF
Engineering Computer Facilities         Paper: 130 Colonnade Rd, Nepean, ON

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 89 23:11:50 GMT
From:      kline@tuna.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: Hitchhikers Guide to Internet, Intro to Internet Protocols

In article <116@maytag.waterloo.edu>, peter@aries5 (Peter Bumbulis) writes:
> I'd like to locate the documents ``Hitchhiker's Guide to the Internet''
> (Ed Kroll (sp?)) and ``Introduction to the Internet Protocols'' (Charles
> Hedrick).  Are they available for ftp from somewhere?  Thanks in advance,
 
Ed Krol's Hitchhiker's Guide to the Internet is available via anonymous FTP
from uxc.cso.uiuc.edu. It's in pub/hgi.me.

Hm, now that I look I see that the Hedrick paper is on uxc too, in
pub/tcp-ip-intro.me.

-----
Charley Kline, University of Illinois Computing Services
kline@tuna.cso.uiuc.edu
{uunet,seismo,pur-ee,convex}!uiucdcs!uiucuxc!kline

"Just another useless dead thing, I've been killed by love."

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Apr 89 06:53:08 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        tank!eecae!shadooby!sharkey!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!henry@handies.ucar.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Super Cheap IP router (< $1000)
Henry Spencer asserts that interrupts need not hurt performance, if software
is written properly, primarily through the use of low-level modules to do
the real-time servicing, deferring the rest of the processing for upper-level
software.

Well, five years ago, I would have agreed.  I used to deal almost exclusively
with application-layer protocols.  Working in the lower layers has been
sobering.

Interrupts kill.

The raw machine processing time -- i.e., hardware instruction cost -- for
interrupts is quite significant.  As with most features in this world,
interrupts are excellent for their intended purpose and questionable for
other situations.

An interrupt is very useful when you don't expect much activity and don't
want the overhead of polling.  On the other hand, if you DO expect heavy
activity, polling is quite nice.

Some folks I used to work with did a calculation of the interupt overhead
for 8 terminals running at 9600 baud, using an 80186 processor (I believe
at 6MHz) and discovered that they would have time left over for VERY few
instructions per character.  With a polling approach, they were able
to sustain a data rate of about 14Kbps per terminal.  (My memory is
fuzzy; it may have been around 17000 baud, but you get the idea.)  This
was with appropriate processing for an ethernet protocol stack and
per-character terminal-oriented instpection and modification.

Many, occasional sources of activity warrant interrupts.
A few, active sources warrant polling.

Dave
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 00:58:15 GMT
From:      scc@cl.cam.ac.uk (Stephen Crawley)
To:        comp.protocols.tcp-ip
Subject:   Re:  Re: IP based authentication of hosts

Kent England suggests that it is possible to prevent ether snooping
in many cases, and that this can be used to give ``a modest level of
security sufficient to fulfill [his] obligations to protect data and
yet still allow [] applications to use network technology'' 

Kent, how do you propose to stop J R User from unplugging his Sun and 
plugging in a PC to run an etherspy?

The only way to prevent etherspying is to:
  1) place all ethernet wire and any machine attached to it in a physically
     secured area and post a guard to keep out anyone who you can't trust 100%,
  2) make sure that all machines on the ethernet accessible from outside
     the secured area run a verified secure operating system.
These restrictions are just not practical in an academic environment, and in
most other environments too. 

I put it to you that your ``modest degree of security'' is actually
no security worth speaking of.  

-- Steve

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 01:02:16 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

By the way, dropping support for go-ahead may not be a disaster, even if
you have some of those "old" terminals. Back in 19-ought-74 (or so), at
Digital Communications Assoc., we made our network processors capable
of doing the reverse -- supporting 2741's as "full-duplex" terminals
on PDP-10's. [Why? Well, there were these customers who had 2741's...]

It may have been sluggish [and by modern sensibilities *ug-lee!*], but
it worked. You could even run character-at-a-time programs like TECO
and DDT on a 2741. [You know, type "1234/" and the contents of location
"1234" come out on the same line.] Yes, we required the 2741 to have the
"reverse break" option, wherein the host can lock your keyboard even if
you haven't typed "return" yet. Conversely, we unlocked the keyboard
whenever the host user process was in TTY input wait. [There was more
to it than that, of course.]

My point is that in a "full-duplex world" those older terminals can
still be supported to a great extent by providing appropriate filters.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 09:11:10 GMT
From:      huitema@mirsa.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

From article <15285@bellcore.bellcore.com>, by karn@jupiter (Phil R. Karn):
> ........... In doing this job (now the so-called "NOS" version) I ran
> smack into the problem you report. I would have very much liked to use a
> common file descriptor space for both sockets and regular file
> descriptors, but this just didn't seem possible to do in a portable
> manner....

The same problem was encountered with a lot of the early implementations of 
the OSI transport. A number of them were done outside the kernel, either 
because the programmers had not access to the kernel at all, or because they
wanted to minimize the development of kernel code, or because they barked at
increasing the kernel space by umpteen kbytes for just a seldom used
protocol. Most implementations came with a single process that would
interface the network (X.25 or Ether, in most cases), manage the protocol
engine and provide some form of interface with the user processes. Some used
named pipes, some others used their own form of ``communication drivers'',
whose design was not unlike that of pseudo ttys. All ran into a number of
problems:

1- Compatibility with the socket library is extremely hard to achieve. In
particular,  sockets can be dynamically created by the ``socket'' and
``accept'' call; this feature is embedded in most of the Berkeley
applications, and you have to devise work arounds. 

2- Performance is poor, as each packet will wake up the transport process
first, then the application process. Switching from one task to another is
by no way what Unix does best. Moreover, there could be nasty side effects,
like the transport process using a lot of CPU, thus getting lower and lower
priority in the Unix scheduler.

There is a way to circumvent the secund point, which is to provide a
subroutine implementation of the transport, for architectures where a single
user process serves multiple connexions. The key is that the application
must be the sole user of a particular network address, and that it should be
ready to multiplex its various connexion contexts, e.g. using some form of
light weight process. It should also call the transport manager at
reasonable intervals, so that the protocol machine would not break.

This architecture is commonly used for information servers, which need to
handle a very large number of connexions (several hundreds), and would be
penalized by the standard UNIX architecture: either the number of connexions
would be limited by the maximum number of file descriptor per task, or by
the maximum number of FD per system, or the number of tasks would become so
large that the system would be inefficient, and the interprocess
synchronisation a nightmare. Actually, it could be a very reasonable design
for an X-Window terminal.

Christian Huitema

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 13:53:08 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

Henry Spencer asserts that interrupts need not hurt performance, if software
is written properly, primarily through the use of low-level modules to do
the real-time servicing, deferring the rest of the processing for upper-level
software.

Well, five years ago, I would have agreed.  I used to deal almost exclusively
with application-layer protocols.  Working in the lower layers has been
sobering.

Interrupts kill.

The raw machine processing time -- i.e., hardware instruction cost -- for
interrupts is quite significant.  As with most features in this world,
interrupts are excellent for their intended purpose and questionable for
other situations.

An interrupt is very useful when you don't expect much activity and don't
want the overhead of polling.  On the other hand, if you DO expect heavy
activity, polling is quite nice.

Some folks I used to work with did a calculation of the interupt overhead
for 8 terminals running at 9600 baud, using an 80186 processor (I believe
at 6MHz) and discovered that they would have time left over for VERY few
instructions per character.  With a polling approach, they were able
to sustain a data rate of about 14Kbps per terminal.  (My memory is
fuzzy; it may have been around 17000 baud, but you get the idea.)  This
was with appropriate processing for an ethernet protocol stack and
per-character terminal-oriented instpection and modification.

Many, occasional sources of activity warrant interrupts.
A few, active sources warrant polling.

Dave

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Apr 89 19:59:23 EDT
From:      Mills@udel.edu
To:        Rob Warnock <amdcad!rpw3@ucbvax.berkeley.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  new terminal names
Bob,

Darn, don't kill the GA fossil just yet. I am still using GA to key
high-power HF radioteletype transmitters that just don't really allow
full-duplex at all.

Dave
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 16:05:34 GMT
From:      tonym@FLORA.WUSTL.EDU (Tony Mazraani)
To:        comp.protocols.tcp-ip
Subject:   CSMA/CD channel

Hi everybody,
 
     I am currently pursuing research in LANs that will soon require
running some simulations on top of a simulated CSMA/CD channel. I was 
wondering if there is anybody out there who has already simulated a 
CSMA/CD channel and has the source code available for the public domain. 
Any help is very much appreciated.


Tony Mazraani 	Computer and Communications Research Center
S-MAIL:         Washington University in St. Louis MO 63130
INTERNET:       tonym@flora.wustl.edu
PHONE:          314-726-4163

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 16:11:00 GMT
From:      watrous@porthos.rutgers.edu (Don Watrous)
To:        comp.protocols.tcp-ip, rjh@cs.purdue.EDU
Subject:   Re: Subliminal

In article <6462@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes:

> I sincerely hope RFC 1097 is a joke, subliminal suggestion is a devious and
> underhanded way to influence people into taking actions or adopt ideas
> without their consent.  People should be afraid to look at terminals if
> there is a possibility subliminal messages are being sent.  Why isn't this
> practice illegal?  I vote for a complete banning of subliminal messages from
> any electronic medium and propose for now a banning of subliminal messages
> across the Internet.  Subliminal messages are a dangerous threat to our
> security and the integrity of the Internet.

I would have agreed with you a while ago myself.  When our systems
group first considered implementing subliminals, I strongly opposed on
ethical grounds.  I gave in to a test period only after assurances
that it would be used only on our most difficult users by unanimous
decision of the systems staff, and *NEVER* on the staff themselves.

Well, I must say that after the test period was over, I was convinced.
Our users seem happier and decision making around here has never gone
easier.  In terms of user satisfaction, our performance has never been
better.  That's what we're here for, right?  Get down off your ethical
high horse and deal with problems pragmatically!

;^)

Don
-- 
{backbone}!aramis.rutgers.edu!watrous        watrous@aramis.rutgers.edu

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 18:43:29 GMT
From:      circuit@csd4.milw.wisc.edu (Christopher Steinke)
To:        comp.protocols.tcp-ip
Subject:   uk hosts


	I am not sure if this is the proper newsgroup, but I am in
need of a list of uk hosts, west german hosts would be appreciated
too. Or if there is another newsgroup that this belongs on let me
know. 

	Thanks. please reply via email



--
|circuit@csd4.milw.wisc.edu|

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 89 18:51:20 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <10540@bloom-beacon.MIT.EDU> boomer@space.mit.edu
 (Don Alvarez) writes:
>>
>>	So, if I set-up "secure" subnets with hosts that are
>>"sanitized" to some degree, and I have some level of physical security
>>on these subnets, and I use Kerberos to protect passwords, and I turn
>
>No.  You don't have anything worth having.  All I need is an IBM-PC
>($0.10/dozen), an ethernet card ($0.20/dozen), and a vampire tap ($0.50/
>dozen), and I can listen to ANYTHING I want to on your "secure" subnet.
>As you leave your office today, look at the yellow or orange cable running
>all over your building/campus and tell me that you can secure every inch of it.

	Of course I would not think of using that yellow or orange
cable for a secure subnet.  I don't like that cable for open subnets-
it's too hard to manage in an office environment.

	But I can think of several techniques to install relatively
secure Ethernet subnets.  My secure subnet might be a delni in a
locked equipment rack.  I could even say that my twisted pair Ethernet
subnets are sufficiently secure against snooping under certain extra
conditions.  And if that isn't good enough, fiber today is as easy to
install as thin coax (though not as cost effective), so I could spec
fiber. 

	I am not trying to secure my nets against the KGB, so don't
tell me you can crack any net I design and install.  I just want a
reasonable level of physical security, like I require of my backbone
nets.  I could spec conduits if I had to, but that is taking things
too far.  I would spec link level encryption first.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Apr 89 07:23:04 -0700
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa
Subject:   Re: IP based authentication of hosts
1700 psi reinforced concrete conduit seems to be favoured in some circles to
provide a modicum of protection from tampering with the ethernet.  You must
plan carefully when using this type of conduit--it is difficult to remove
without the aid of a nuclear device.
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1989 08:15-EDT
From:      CERF@A.ISI.EDU
To:        kwe@BU-CS.BU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP based authentication of hosts
All hosts on all subnets in the set of connected "secure" subnets
must comply with (meet the standard of) your security requirement.
an unruly host is as bad as an unruly (untrusted) gateway or network.

Vint
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Apr 89 09:26:15 EST
From:      kwe@bu-it.BU.EDU
To:        CERF@A.ISI.EDU, kwe@bu-cs.bu.edu
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP based authentication of hosts
	You are right (of course).  It is workable only so long as
the set of secure subnets and hosts on those subnets is small.  This
approach does not scale well.
	Encrypted authentication and encrypted data transfer are the
only way to go.

	--Kent
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 04:36:46 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]

dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
+---------------
| Interrupts kill...
| An interrupt is very useful when you don't expect much activity and don't
| want the overhead of polling.  On the other hand, if you DO expect heavy
| activity, polling is quite nice...
| Many, occasional sources of activity warrant interrupts.
| A few, active sources warrant polling.
+---------------

Which is why the two-level interrupt service structure I wrote a
"tutorial" about in comp.arch (circa 3/20/89?) does exactly this,
although that was not one of the points I stressed in that article.

In the absence of interrupt activity, you are "interrupt driven".
But once you get an interrupt, additional interrupts are queued on
a lightweight task queue, and [this is the part I left unstressed]
every second-level interrupt routine checks for more work of its
own type before exiting, and if there is any, requeues itself on
the tail of the task queue. [This promotes fairness. And of course,
you can have multiple 2nd-level interrupt queues/priorities if you
like.] Thus, once fired up by a 1st-level interrupt, the 2nd-level
interrupt service layer is *polled* -- exactly as you requested!

This has the nice behavior that a full interrupt context save/restore
only has to be done once for each "burst" of interrupts (and in
timesharing systems, interrupts *are* "bursty").

I once wrote a PDP-8/e communications kernel which, using this
approach, was able to handle 10,000 characters a second *through*
the node. Interrupt per character, on each side, or 20k ints/sec.

If you have a *large* number of sources of data to service (such as
*many* async terminal ports, say more than 100, as on that PDP-8/e),
and you have some very-light-weight 1st-level hardware interrupt
mechanism (such as the Am29000's "freeze mode"), then using interrupts
as "asynchronous polls" can save you some polling overhead while still
not requiring a full context save. That is, hardware interrupts remain
enabled even while the 2nd-level service routines work. This is a useful
tradeoff even on some CISCs [such as the MC68000 -- though not the '020],
where the 1st-level catch-the-data/queue-the-2nd-level-task function
can be done without very much save/restore overhead. Like Dave's
experience, I have seen this technique result in a factor of *12*
improvement in the TTY-handling capacity of a 68000-based Unix.

Note that this "interrupt/polling" switchoff has a direct analogy to
those link-level access protocols which attempt to provide low latency
under light load and good efficiency under heavy load. I'm talking about
things like the "Urn" protocol and some forms of "reservation/TDMA" or
"random-access/TDMA" which have a contention phase which degenerates
into round-robin under load. There are also some forms of "virtual token
bus" which deliberately drop the token under light load, reverting to
a contention mode. [Sorry I don't have access to formal references on
these handy, as I hear a flood of "Tell me more"s already. Anybody else?]

Anyway, the point is that any good design provides a smooth *dynamic*
tradeoff between latency and efficiency.

p.s.
I personally feel that the FDDI standard is oriented too far to the
"efficiency" side; on maximal configurations of FDDI, the "packet
exchange" time (say, an NFS disk block request/response) on a lightly
loaded net can be over 3 milliseconds -- that's worse than Ethernet!


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 05:33:45 GMT
From:      scc@cl.cam.ac.uk (Stephen Crawley)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

Kent England writes:
> My secure subnet might be a delni in a locked equipment rack.

Are the computers inside the locked equipment rack as well?  If not, 
what is to stop JR User from plugging a PC into a drop cable?  

Suppose that you do put the computers in the locked rack, how do your 
users access the machines?  Lots of 9600 baud async lines?  [You can't 
provide terminal over your LAN without sending network traffic off your 
physically secure subnet!]  What are you going to say to the users who 
want to use a PC or a workstation?  

Do the physically secure machines on the LAN run a secure OS?  If not, 
what is to stop JR Hacker from indulging in a bit of unauthorised spade 
work on the OS kernel to give himself access to ethernet packets?  
[Don't tell me that JR Hacker =/= JR User.  What if he is and you don't
know about it?  What if he is and you DO know about it?!]  

What are you going to say to your users who want to use ... say ... UNIX?

> I am not trying to secure my nets against the KGB, so don't tell me 
> you can crack any net I design and install.  

Just who are you trying to make the system secure against?  Cleaning
ladies?  An undergraduate CS hacker wouldn't have much trouble finding 
a way through your scheme ... given a big enough carrot.  Certainly 
the undergrads around here wouldn't!

I want security that is on the same level as me keeping sensitive 
materials in a locked filing cabinet inside a locked office with the 
nightwatchman walking the corridors.  At the same time I want to use a 
nice bitmapped workstation with several MIPs of local processing power
[In 5-10 years time I'll expect an integrated services workstation.]  
I do NOT want to be forced to use a klunky old 24 by 80 on a 9600 baud 
terminal line.  I do NOT want to have to go down the corridor to the
secure room every time I want to read my email.  

I claim that security without substantial inconvenience is achievable 
using encrypted protocols, but not with a physical security scheme.

-- Steve

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 05:35:32 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)


My experiences match those of Dave Crocker almost exactly. Per-character
interrupts on the IBM PC are deadly. Minimizing the number of host level
interrupts per byte transferred is the single most important optimization
you can make in almost any PC communications program.

The problem is that existing PC hardware has virtually no support for
anything else. Background polling is usually out of the question, as most
applications are complex enough to make it highly inconvenient to poll often
enough to avoid missing input. DMA is virtually unusable, given the limited
number of channels on the original PC plus a desire to be backward
compatible with that machine. This leaves interrupt-driven I/O and busy-wait
loops.

I recently did a driver for the PC that handles a HDLC controller connected
to a 56Kbps amateur packet radio modem. (Yes, we've made some progress since
the InterOp 88 and Ann Arbor IETF demos. :-)) At 142 microseconds between
characters, there was no way I could make it run in interrupt driven mode,
nor could I tolerate an interrupt from another source while the interface was
active. I therefore designed the driver to use only one interrupt:
demodulator carrier detect. The presence of carrier causes the host to enter
a polling loop on the receive status register with interrupts disabled.  It
stays there, receiving frames, until the carrier goes away.

The transmit routine is simpler: it just busy waits on the transmitter with
interrupts off, sending frames as long as it has frames to send.

The scheme works, but is much less than satisfactory. Whenever the channel
is active, all other activity on the system freezes. Keystrokes are not
echoed. Even the $#@!! time-of-day clock freezes (why computer designers
have this fetish for complex interrupt-driven software clocks instead of
simple read-only hardware binary counters driven by oscillators, I'll never
understand).

The irony of this situation is that it wouldn't be so bad if the modem were
faster; the PC would spend less time sending each packet. There is enough
real time, even on a 4.77 MHz PC, to spin around the wait loop on the device
a few times for each character that is actually sent or received. But the
inter-character time is not long enough to go off and do any other useful
work, so it goes to waste. It's sort of like making a cross-country airline
trip with several hour-long connections. They're long enough to become a
significant fraction of the total trip, but each one is too short to do
anything but sit around each terminal, waiting.

Just having lots of FIFO buffering on each I/O card would be an enormous
help.  It would be really nice to use the 80286 INS (block input)
instruction to slurp several kilobytes out of a FIFO that had been loaded by
the line controller without direct processor intervention. Considering the
speed of this instruction, the total bus overhead would actually be less
than DMA since you can avoid the bus arbitration that has to go on for each
DMA transfer. Better yet is enough FIFO buffering plus hardware smarts to
handle several packets without host intervention. Except for the newer
Ethernet controllers the slave I/O CPU seems to be the only way to do this.
But this is not to say that the link or higher protocols should be executed
on the controller -- its job should be strictly limited to buffering for
the purpose of alleviating the host processor's real-time constraints.

Right now, my "slave I/O CPU" is a dedicated PC/XT with an Ethernet interface
on one side and the packet radio interface on the other. It sits in the
corner, gatewaying packets between the local Ethernet and the radio
channel (the real Ether). Most people need a cheaper solution, so a friend
(Mike Chepponis, K3MC) is designing a slave I/O processor for the PC that
contains a V40 CPU, several hundred K of RAM and one or more 8530 HDLC chips.

As an additional aside, polling is the standard technique used in electronic
telephone switches. Imagine an interrupt-driven switch when all the phones
come off-hook simultaneously...

Phil

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Apr 89 09:44:39 EDT
From:      stev@vax.ftp.com
To:        tcp-ip@sri-nic.arpa
Subject:   secure subnets

*	But I can think of several techniques to install relatively
*secure Ethernet subnets.  My secure subnet might be a delni in a
*locked equipment rack.  I could even say that my twisted pair Ethernet
*subnets are sufficiently secure against snooping under certain extra
*conditions.  And if that isn't good enough, fiber today is as easy to
*install as thin coax (though not as cost effective), so I could spec
*fiber. 

*	I am not trying to secure my nets against the KGB, so don't
*tell me you can crack any net I design and install.  I just want a
*reasonable level of physical security, like I require of my backbone
*nets.  I could spec conduits if I had to, but that is taking things
*too far.  I would spec link level encryption first.


i think you are missing the point. do you have any pc's with students
on them attached to the ethernet? even teaching assistants? if so,
that is not a secure subnet. the PC/IP public domain package comes
with a tool called NETWATCH which will allow them to "snoop" on your
network. or how about SUNS? as i recall, suns have some snooping
tools on them under sunview also. basically, yea, you have to worry
about someone installing an unknown node on your ethernet, but you
also have to worry about someone misusing the equiptment you have.
one other thing to worry about is if you are using something like an
ANNEX box to provide "ethernet terminals". if you are going to start
playing with encryption, you have to make sure your terminal servers
will support it.

the people who sit and think about security as their jobs told me
that the *real* problem in security was the people using it. you can
secure the systems, but you *have* to be able to trust the users.


stev knowles
ftp software
stev@ftp.com

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 15:37:09 GMT
From:      amanda@lts.UUCP
To:        comp.protocols.tcp-ip
Subject:   interrupt-driven vs. polled I/O performance

Dave Crocker argues with Henry Spencer about interrupts:
>[...]
>Interrupts kill.
>
>The raw machine processing time -- i.e., hardware instruction cost -- for
>interrupts is quite significant.  As with most features in this world,
>interrupts are excellent for their intended purpose and questionable for
>other situations.
>
>An interrupt is very useful when you don't expect much activity and don't
>want the overhead of polling.  On the other hand, if you DO expect heavy
>activity, polling is quite nice.

Well, I wouldn't say it's quite so clear cut as all of that.  Granted,
the absolute best raw data rate through a given interface (of whatever
sort) can be achieved by polling, principally because there is then no
need to save and restore any state--the processor is only doing I/O.
This is one of the reasons that separate I/O processors are such a big
performance win: I/O state gets encapsulated in hardware rather than
software.

What I think Henry was getting at, though, is that given a processor
which is doing both I/O and other tasks (or, for that matter, which is
being subjected to an unpredictable I/O load), careful attention to
how interruptsa are handled can make an incredible difference in
real-time response and overall performance, for exactly some of the
same reasons that polling wins.  

The general idea is that you do as little processing as possible one
character at a time.  For example, a serial input interrupt service
routine should stuff the incoming character in a buffer *and that's it*.
This only takes a few microseconds on the kinds of processors being used
in most workstations and desktop computers.  In other words, interrupts
are used to approximate the behavior of a hardware FIFO.  No context
switches or wakeups, just "push a register or two, grab the input,
stuff it into a buffer, update the buffer head, and return."
This buffer is then polled by the upper-level code, which (especially
under high load) then has a chance of grabbing a whole block of data at
once, which it can then rip through all at once without having to switch
state.  Sound familiar :-)?  When I first saw the code to the UNIX tty
handler, my first question was "why are they doing all of this at
interrupt time?"  So far, I've never seen an answer to that besides
"historical reasons."

Now, if you do have the luxury of a dedicated I/O processor, polling and
hardware FIFOs are the way to go.  For an Ethernet terminal sever, for
example, a LANCE (or other chip that buffer bunches of back-to-back
packets all by its little lonesome self) plus FIFOs between the serial
chips and the processor will give you some impressive throughput even
with a relatively wimpy 6MHz 80186...

>Many, occasional sources of activity warrant interrupts.
>A few, active sources warrant polling.
>
>Dave

How 'bout we add "A non-I/O-dedicated processor warrants interrupts?"

I agree with you in general, I just don't see how it's too relevant to
the discussion, which (to me anyway) seemed to be "how can we keep
workstations from croaking under heavy input traffic?"

Of course, this approach is also useful in upper-level processing as well.
For example, it doesn't matter how well your network I/O code is if your
RPC input queue is only 8 items long, and 50 NFS clients try to mount one
of your filesystems...

Amanda Walker
InterCon Systems Corporation
amanda@lts.UUCP

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 16:36:55 GMT
From:      jim@tiamat.fsc.com (Jim O'Connor)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP software for Altos 2086

I know there are vendors reading this newsgroup, so I'll ask this question
here.  I don't really expect much of a response, but I have to at least
ask.

Is there anyone who has TCP/IP software that will run on an Altos 2086
running Altos Xenix 3.4?

(pause, to let the laughter die down :-)

Points to keep in mind:

1 - Altos Xenix != SCO Xenix, actually Altos Xenix <<<< SCO Xenix
2 - Putting SCO Xenix on the Altos is not possible.  If it were, I would have
    done it long ago. :-)
3 - There is supposed to be an Ethernet board available for the 2086 from
    Altos, but I have yet to hear of anyone actually using it.
    Otherwise, SLIP would be the only means of physical connection
    (No flames, please, in this case, slow TCP/IP is better than NO TCP/IP).

Please quote any and all exorbitant prices, since the cost might not be
a factor if something is actually available.

Thanks for your attention (you can stop laughing now :-).
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Filtration Sciences Corporation		615/821-4022 x. 651

*** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 17:45:49 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <710@scaup.cl.cam.ac.uk>, scc@cl.cam.ac.uk (Stephen Crawley) writes:
> Kent England writes:
> > My secure subnet might be a delni in a locked equipment rack.
> 
> Do the physically secure machines on the LAN run a secure OS?  If not, 
> what is to stop JR Hacker from indulging in a bit of unauthorised spade 
> work on the OS kernel to give himself access to ethernet packets?  

Why dig up the kernel?  More than one workstation vendor provides standard
tools to send and receive arbitrary ethernet packets.  Remember nit,
tcpdump, and etherfind from one of those vendors.  Others have what they
consider better.  Many paying customers think they require raw ether for
real applications (i.e. something they'll pay for).


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Apr 89 18:56:54 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

In article <8904140206.AA10084@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
>Henry Spencer asserts that interrupts need not hurt performance, if software
>is written properly, primarily through the use of low-level modules to do
>the real-time servicing, deferring the rest of the processing for upper-level
>software...

Well, that's the scheme I outlined, but the conclusion is overstated.  I
didn't say that interrupts were free, I said that they could be made a
good deal less expensive than people tend to think.  Obviously there is
always a point where the cost gets too high.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Apr 89 19:02:19 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

In article <15321@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
>As an additional aside, polling is the standard technique used in electronic
>telephone switches. Imagine an interrupt-driven switch when all the phones
>come off-hook simultaneously...

At least one terminal switch, built by otherwise very professional people,
did in fact collapse when presented with a large number of simultaneous
connection requests.  I shouldn't give names, since this may well have been
fixed by now -- it wasn't recent.  Normally it's very uncommon for lots of
people to hit BREAK simultaneously, but when you're talking about a military
school with a whole class of cadets being marched into the terminal room, 
sitting down, and then hitting BREAK en masse, it can happen...
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 21:06:21 GMT
From:      pcg@aber-cs.UUCP (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]

In article <25223@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
    dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
    +---------------
    | Interrupts kill...
    | An interrupt is very useful when you don't expect much activity and don't
    | want the overhead of polling.  On the other hand, if you DO expect heavy
    | activity, polling is quite nice...
    | Many, occasional sources of activity warrant interrupts.
    | A few, active sources warrant polling.
    +---------------
    
    Which is why the two-level interrupt service structure I wrote a
    "tutorial" about in comp.arch (circa 3/20/89?) does exactly this,
    although that was not one of the points I stressed in that article.
    
    In the absence of interrupt activity, you are "interrupt driven".
    But once you get an interrupt, additional interrupts are queued on
    a lightweight task queue, and [this is the part I left unstressed]
    every second-level interrupt routine checks for more work of its
    own type before exiting, and if there is any, requeues itself on
    the tail of the task queue.

While I agree that the technique is useful, it requires implementing
a lightweight process system in your kernel, which may be major
surgery. In a sense, you are using any interrupt as though it were
the clock interrupt to start polling.

The simple version, used e.g. in many UNIX kernels, is to have any
and every interrupt processing procedure always check at the end for
further pending interrupts for ITSELF, and then go into a loop. Even a
little busy waiting, if it is known that there will be a next interrupt
shortly, may be worthwhile, e.g. when reading packets/bursts from
line on which you are running a protocol.

I do not like much the idea of having an interrupt routine at the end
fire up polling in other drivers. (If I understood correctly what you
are thinking about).
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 21:07:49 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re:  Re: IP based authentication of hosts

In article <709@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>
>I put it to you that your ``modest degree of security'' is actually
>no security worth speaking of.  
>
	With no flame intended (since you are so polite in your
response):
I put it to you that this objection that "security" without total
"security" is no security is a way to do nothing, when something needs
to be done.  I must start somewhere and I don't intend to be put off
by this kind of argument.

	I should say that one of the things we don't mention often
enough is that any discussion of security needs to talk specifically
about the threat that is being countered.  I am as guilty as anyone in
not explicitly defining the threats I think need to be countered.  No
one knows exactly what threat they are faced with.  Perhaps they have
an idea, when presented with a threat scenario, whether they think
they must counter it.

	While I don't know exactly what threats I am faced with, I know
that applying reasonable measures will result in a winnowing of the
threat "pool".  Doing nothing results in nothing being done.

	Of course, doing something does not guarantee that anything
useful has been accomplished and for that reason I appreciate
everyone's comments, recommendations, and pointers.  Thanks.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 21:58:14 GMT
From:      Makey@LOGICON.ARPA (Jeff Makey)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <14-Apr-89.114221@192.41.214.2> amanda@lts.UUCP writes:
>When I first saw the code to the UNIX tty
>handler, my first question was "why are they doing all of this at
>interrupt time?"  So far, I've never seen an answer to that besides
>"historical reasons."

The reason "all of this" gets done at interrupt time is performance,
although not the kind that has been discussed so far.  In this case,
UNIX software is responsible for echoing characters, and to keep echo
delay to a minimum the character(s) actually echoed are put on the
output queue at interrupt time.  Anyone who has used TELNET (hah!
there's the relevance to TCP/IP) over a slow connection knows how
annoying delayed echo is.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@LOGICON.ARPA    UUCP: {nosc,ucsd}!logicon.arpa!Makey

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 89 23:51:02 GMT
From:      cyrus@pprg.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Re:  Re: IP based authentication of hosts

In article <709@scaup.cl.cam.ac.uk> Kent writes:
>Kent, how do you propose to stop J R User from unplugging his Sun and 
>plugging in a PC to run an etherspy?

Why go to that trouble.  I use a Sun ALL the time to do 'ether' snooping.
It is faster than a PC AND I can still get "real-work" done while it
is snooping.

Since it is unrealistic to assume you can keep every "J R User" from
gaining access to your net (either physical access where they can
attach a "device" or logical access via an already attached
machine (SUN/PC) ) the only way to make sure you have authentication 
of hosts is some kind of encryption.  The question is at what layer.

If, and that is a BIG IF, you put your cable in a "special" pressurized
conduit, AND you can trust EVERY user that has an account on ALL
machines connected to this "special" cable, THEN you have a secure
network.  As soon as ONE of those users does something they are not
supposed to (i.e. run a snooper on a Sun attached to this network),
THEN your net security is shot.

If you use encryption, you can do some good, but that encryption will
have to be below the network layer.  If you put it at the network
layer, a snooper still knows who is talking to whom and that, in a
lot of cases, is enough information to allow "someone" to cause
damage to your net or gain information they are not supposed to have
access to.  Even if you put it at the LLC layer, a snooper still
knows who is talking to whom and there is a lot of information in
just knowing that.

Now you can argue that encryption at the network layer, or above, is
sufficient because even if someone "steps into a conversation", they
still don't know what the data content is.  With the new 10-20 MIP
machines available, this would be a trivial task, depending on the
method of encryption of course, to break the crypt and gain access to
the data.

On the extreme case, what if "someone" dumps a conversation to disk
for later analysis.  If you want to to keep people from being able to
break your data, you will have to use such a high level of encryption
that just encrypting/decrypting the data will take so long that it
would make your network useless.  

The only way around it is to say that you will use a moderately 
complicated encryption algorithm (fairly fast for encrypting/decrypting).
Even though someone can break this crypt in a day or two, and assuming
they store the conversation to disk, the data will be so old that it
will not do them much good.  You will, of course, have to change keys
fairly often (once a day).

>-- Steve

---
W. Tait Cyrus   (505) 277-0806		e-mail: cyrus@pprg.unm.edu
University of New Mexico			
Dept. of Electrical and Computer Engineering
Parallel Processing Research Group
Albuquerque, New Mexico 87131

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Apr 89 07:27 ADT
From:      John Sherwood <SHERWOOD%AC.DAL.CA@CORNELLC.cit.cornell.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP access to GEAC
> They have their own funny terminals which talk some strange
>multidrop polling protocol to the GEAC over the async line.

Bob:

Our GEAC allows the asynch terminals to be configured as GLASS-TTY
instead of the multi-dropped polling type. This means you can connect
a single, dumb ASCII terminal to the GEAC port. Makes for an easy
connection to the terminal server, right?

Wrong. They neglect such frills as flow control and connection control.
We figured out (the hard way) that you can do the following:

) Flow control of data from the GEAC port can be controlled by toggling the
  DSR line (nobody can explain why this works; not even GEAC). Flow control in
  the other direction doesn't seem to be possible.

) GEAC will signal a disconnect by dropping DTR for about 2 seconds. After
  the 2 seconds it will assume it has a new session and start painting
  screens unless DSR is low.

) The server must signal disconnect to GEAC by sending the ASCII string "END".
  This has not proved to be bullet-proof and new users sometimes connect
  into the middle of someone else's session.

All this applies to the older 8000 series machines. Our 9000 is in and
running, but I haven't had a chance to see if things have improved. If
anyone has a better way of doing things, would we ever like to hear it!

Cheers

John Sherwood
Dalhousie University
Halifax, Nova Scotia
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 04:59:46 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <416@logicon.arpa> Makey@LOGICON.ARPA (Jeff Makey) writes:
+---------------
| In article <14-Apr-89.114221@192.41.214.2> amanda@lts.UUCP writes:
| >When I first saw the code to the UNIX tty handler, my first question was
| >"why are they doing all of this at interrupt time?"  So far, I've never
| >seen an answer to that besides "historical reasons."
| The reason "all of this" gets done at interrupt time is performance,
| although not the kind that has been discussed so far.  In this case,
| UNIX software is responsible for echoing characters, and to keep echo
| delay to a minimum the character(s) actually echoed are put on the
| output queue at interrupt time.  Anyone who has used TELNET (hah!
| there's the relevance to TCP/IP) over a slow connection knows how
| annoying delayed echo is.  :: Jeff Makey
+---------------

But the echo delay doesn't need to be kept to a *minimum*, but only
well below the objectionable level to the human user. And the difference
between those two scenarios can be a *large* fraction of your machine,
especially when you have a TTY driver that is used by both humans
and (say) UUCP at 19200 baud.

A *very small* delay in input processing -- the amount you get when
you use the two-level interrupt scheme Amanda referred to -- can save
enormously in overhead on your high-speed input lines, without ever
being noticed by your users. Likewise, a *small* delay in beginning
output (to give the upper levels time to copy more data into the output
queues) can result in large improvements in efficiency, again without
being noticed by users.

What numbers are we talking about here? Well, at Fortune Systems we
delayed input by 1/60 second (the queue built by the 1st-level handler
wasn't passed to "tty.c" until the next clock tick), and TTY input
capacity went up a factor of 12. In a certain release of TOPS-10
[6.04? I forget], DEC delayed beginning output until the next tick
[4 ticks?], and the output rate went up by a factor of 4 to 6.
Yet both of these systems had "crisp" echo.

I claim that 100ms for echo is not noticable to a user of a video
display (although it is mildly annoying if you are on an ASR-33 (!)
or any other terminal which causes an audible signal on output),
yet allowing the operating system that 100ms or so can result
in such performance gains that not to do so is gross negligence!

Interrupts are ugly, brutish things, to be sure. ("Nyekulturny!" as
the Russians might say.) But they have their uses, especially when
you'd like certain things (like echo) to happen reasonably on time.
But the key is "reasonably"...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 10:17:47 GMT
From:      mah@hpuviea.UUCP (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

From article <8904140206.AA10084@ucbvax.Berkeley.EDU>, by dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker):
> 
> Many, occasional sources of activity warrant interrupts.
> A few, active sources warrant polling.
> 

This is, by the way, what the hp-ux tty driver  on the 300 series does: if 
traffic is low, it works on a interrupt-per-character basis; if traffic 
exceeds some high-water mark, it switches to polled operation.

-michael
-- 
Michael Haberler		mah@hpuviea.uucp 
Hewlett-Packard Austria GmbH, 	...mcvax!tuvie!hpuviea!mah
Lieblgasse 1 					...hplabs!hpbbn!hpuviea!mah
A-1220 Vienna, Austria		Tel: (0043) (222) 2500 x412 (9-18 CET) 	

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 10:27:00 GMT
From:      SHERWOOD@AC.DAL.CA (John Sherwood)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP access to GEAC

> They have their own funny terminals which talk some strange
>multidrop polling protocol to the GEAC over the async line.

Bob:

Our GEAC allows the asynch terminals to be configured as GLASS-TTY
instead of the multi-dropped polling type. This means you can connect
a single, dumb ASCII terminal to the GEAC port. Makes for an easy
connection to the terminal server, right?

Wrong. They neglect such frills as flow control and connection control.
We figured out (the hard way) that you can do the following:

) Flow control of data from the GEAC port can be controlled by toggling the
  DSR line (nobody can explain why this works; not even GEAC). Flow control in
  the other direction doesn't seem to be possible.

) GEAC will signal a disconnect by dropping DTR for about 2 seconds. After
  the 2 seconds it will assume it has a new session and start painting
  screens unless DSR is low.

) The server must signal disconnect to GEAC by sending the ASCII string "END".
  This has not proved to be bullet-proof and new users sometimes connect
  into the middle of someone else's session.

All this applies to the older 8000 series machines. Our 9000 is in and
running, but I haven't had a chance to see if things have improved. If
anyone has a better way of doing things, would we ever like to hear it!

Cheers

John Sherwood
Dalhousie University
Halifax, Nova Scotia

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 13:01:05 GMT
From:      mshiels@tmsoft.uucp (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

Low level buffering is great but it is still a performance pig.  If you
can get one interrupt per packet then you can support more interfaces in one
machine.  I was thinking of a couple of SLIP lines a ethernet, token ring
and makybe an arcnet.  This thing becomes interrupt intensive unless you can get
rid of some of the serial interrupts.

It's really bad if your running 9600/19200.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 16:36:07 GMT
From:      pete@relay.nixctc.de (Pete Delaney)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat,comp.lang.postscript,comp.windows.news
Subject:   Re: TCP/IP versus OSI

Come on guys, where is the Followup to Joachim Carlo Santos Martillo's
paper " Round 2 in the great TCP/IP versus OSI Debate".  I expected
a bit more than everyone being quite.  Is Darth Vader watching or
something?  I've been working on OSI for a few years and it seems
that most of what Joachin is presenting is right.  I'm a little
disapointed in explanations about why this obsurdity has developed
the way it has.  I am sure a lot of developers love OSI over arpanet,
I'd like to here their story. Also, it might be nice to hear why 
arpnet is migrating to OSI; do the arpa developers really like ASN1
more than postscript?  I found programing in ASN1 with the NBS meta
compiler very time consuming.  What about using postscript instead of
ASN1 for network management and Manufactoring Messageing? Is it really
that important to check, cross-check, and then tripple-check as
is done in OSI and ASN1.  Can't we just assume like Joachim points out
that the connection above transport is reliable and then send programs
like postscript to due what we want?  


Pete Delaney - Nixdorf UCC	| pete@relay.NIXCTC.DE		Prefered Addr
Loffel Strasse 3		| pyramid!nixctc!pete		UUCP from Calf
7000 Stuttgart 70		
West Germany			| Phone: +49 (711) 7685-128

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 18:21:50 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <29624@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:
> I put it to you that this objection that "security" without total
> "security" is no security is a way to do nothing, when something needs
> to be done.
 ....
> 	I should say that one of the things we don't mention often
> enough is that any discussion of security needs to talk specifically
> about the threat that is being countered.  I am as guilty as anyone in
> not explicitly defining the threats I think need to be countered.

Kent refers to two crucial points:  that network security is just one
aspect, and that one must assess the threats before doing anything.
Let me add a few more points from a canned security lecture I give on
occasion:  levels of security should be consistent, and that security
is always a tradeoff with convenience.

In my environment -- a research-oriented department within AT&T Bell
Laboratories -- I'm primarily concerned with intrusions from the
outside.  More specifically, I'm concerned with preventing initial
break-ins, and with containing an intruder within a single compromised
machine, and preventing the infection from spreading.  Consequently,
physical security -- i.e., keeping curious fingers away from our
Ethernets -- is a rather minor concern.  Anyone inside who is intent on
doing damage could do far more, far more easily, than by adding yet
another tap.  But networks and password capture are great ways for an
intruder to take over more machines; consequently, I'm concerned about
IP security -- and as I've said, I feel it provides none -- and about
host-based security measures such as login-spoofers and easily-guessed
passwords.  A corollary to this is that I need to keep cleartext passwords
off of the Ethernet because of the existence of programs like etherfind.
(There are other, more subtle, ways to spy on network connections; they're
outlined in my paper.)

Other environments -- i.e., universities, or high-security military
places -- need to pay far more attention to physical security issues.
But that doesn't mean that they can neglect the others.

Kerberos is a very good start, though I have serious reservations about
some aspects of it.  (For example, I think too little consideration is
given to fake login programs building a collection of passwords.)  And
the (current) inability to forward a ticket is inconvenient at times
when one is rlogin'ed to a host and wishes to do a network operation.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 18:37:20 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI

Julian--
   Although I wouldn't think of violating the author's request not to
comment, I do feel a gloss for the cis-Atlantic audience is required:
   "Bean tin" (English) = "Tin can" (Amerenglish)

   And for your own interest and amusement, though I wouldn't think of
bothering the author with it, we might observe that there is a deep
sense in which the OSI protocols share in the advantage of not being
invented by ISO.  (They were, of course, reinvented--and badly, as
witness the fact that the ARPA protocols do indeed offer some "session"
and a lot of "presentation" FUNCTIONALITY, they just don't overcomplicate
life by instantiating them in rigidly hierarchical layers.  But, then,
I daresay you knew that, just as you knew who invented Layering
and Virtualizing ... and just as you knew that the FTP spec contains a
checkpoint-restart facility, even if nobody implements it--the real
advantage of ISO being, after all, that they presumably will be able to
enlist Interpol as the cadre of the International Protocol Police.)
   Oh, by the bye, is the University of the Outer Hebrides convenient to
Islay?  If so, I'd be glad to visit some time, since Islay is where
several important facilities in my real field of research interest are
(e.g., Lagavulin, Laphroaig, and Port Ellen Maltings), and the day and
a half I spent there in '86 wasn't at all an exhaustive research
expedition, merely a preliminary dig.

   cheers, map
-------

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 21:20:28 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on X.500


The June 1989 issue of ConneXions will have an article on X.500 by Steve
Benford of the University of Nottingham, England. The article is part of
a series entitled "Components of OSI". 

Ole
-------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 89 21:21:42 GMT
From:      CC_DFOO@VAXB.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   DEPCA & PC tcp/ip

Hi ;
    Anybody knows in the PC tcp/ip software market which one support DEPCA card
    (Digital Ethernet Personal Computer-Bus adapter) or any NETBIOS can
    support DEPCA goes into tcp/ip word.

--- David Foo     -- 210-420-5736
    Computer Center
    Stevens Institute of Technology
    ( Bitnet cc_dfoo@sitvxc
      Arpnet cc_dfoo@vaxc.stevens-tech.edu )
------------

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 02:22:08 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Secure access over TCP/IP networks.

There is interest in security of access over a TCP/IP network. Here
is a simple proposal for your criticism. The objective is
minimum change to existing code.

This addresses two related security issues: (1) people attempting
unauthorized access to your system; (2) the fact that the TCP data
stream is easy to snoop on as it passes through insecure parts of
a network.

The first thing a Secure-TELNET daemon does when it receives a 
connection is send a random number (say 4 bytes) to the client.
The client has to know the servers "magic number". It combines
that magic number with the random number to obtain two random
number sequences. The server does the same. From then on each
byte in the TCP stream is XORed with the low order byte of the 
appropriate random number sequence. This simultaneously encrypts
outgoing bytes and decrypts incoming ones. In fact the encryption/
decryption code should be in the TCP layer so that it is quite
easy to modify other applications like ftp to produce secure 
versions.

I think this would have a low overhead and be very hard for
someone watching the data stream to decrypt. Any encryption
experts like to comment?

The nice thing about this scheme is that it can be used in two
distinct ways. You can set it up so that machines you trust (on
your local subnet, etc) know the "magic number". The users of
those machines can log in to your machine via Secure Telnet without
having the "magic number". Indeed it is best if the number is held
securely so they can't find it out. For the much smaller number
of people who use your machine from remote hosts, perhaps while
travelling, you can tell those people the magic number and they
can tell the secure Telnet client the number when they invoke it.

Bob Smart, <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 05:04:24 GMT
From:      amdcad!rpw3@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]
[Excuse me if I edited previous comments to the bone, but it's getting deep...]

By the way, let me preface this by saying that I actually completely agree
with Dave Crocker [below] that polling is the way to go when you have a
few very active devices... *if* you don't need to do something else with
your "idle" time. Pure polling is often the best (and sometimes the only)
strategy in an embedded controller. My remarks in the past few postings
have been assuming that there is general-purpose timesharing going on
in the same CPU, and thus you are trying to balance those famous three --
latency, efficiency, and throughput -- *and* give useful time to the "user".

+--------------- In article <820@aber-cs.UUCP> (Piercarlo Grandi) writes:
| +--------------- In article <25223@amdcad.AMD.COM> (Rob Warnock) writes:
| | +--------------- dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
| | | Interrupts kill... Many, occasional sources of activity warrant
| | | interrupts. A few, active sources warrant polling.
| | Which is why the two-level interrupt service structure I wrote a
| | "tutorial" about in comp.arch (circa 3/20/89?) does exactly this,...
| | But once you get an interrupt, additional interrupts are queued...
| | every second-level interrupt routine checks for more work...
| | if there is any, requeues itself on the tail of the task queue.
| While I agree that the technique is useful, it requires implementing
| a lightweight process system in your kernel, which may be major surgery.
+---------------

The only real surgery, and I'll admit it's a mass of painful detail, is
to go through the kernel (especially the disk cache stuff) taking out all
the unneeded "spl7()" (a.k.a. "splhigh()") calls, and replacing them with
"splsched()". But in fact, for a quick hack, you can simply map *all* the
old calls to "splsched()", and then just put back the few you really need.
[You have to do this, because in any "standard" kernel, there are places
that hold "splhigh" for many *milliseconds*. Any needed mutual exclusion
can always be done in a few microseconds, if only by setting a lock.]

As far as "lightweight processes", I think you misunderstood me. There is
a "lightweight task queue", but the "processes" that are run are actually
all interrupt completion routines, all of which were already there. There
is no new "context"; you're still in "interrupt context".

+---------------
| In a sense, you are using any interrupt as though it were
| the clock interrupt to start polling.
+---------------

Precisely! In fact, one version of this actually just used the kernel's
callout queue (the one that "timeout()" uses), and queued interrupt
completions with a time-to-run of "zero ticks", then let the next tick
of the normal "softclock" handler (which runs at the *lowest* interrupt
priority) run the 2nd-level tasks *just as if* they were timeouts which
had expired. [This assumes you can get a fast enough "hardclock". You can
have "urgent" interrupts start the queue running directly, if you like,
but you lose a lot of the efficiency benefit.]

Any new interrupts that occur while one of those is running get queued
after all the "zero" callouts but before any that are really waiting for
time to elapse. (You should add one more pointer to be maintained, so
you don't have to scan the queue.) And of course, the "softclock" handler
always checks the queue again before dismissing, just to see if any new
interrupts have arrived. (*And* if the clock ticks, adjusts the time left
of the first non-zero task and if it goes to zero promotes the task into
the zero group. That way you your "real" timeouts stay accurate, too.
Also, the "hardclock" 1st-level handler should bump a count of "ticks
seen while softclock busy" that "softclock" can use to keep time straight.)

+---------------
| The simple version, used e.g. in many UNIX kernels, is to have any
| and every interrupt processing procedure always check at the end for
| further pending interrupts for ITSELF, and then go into a loop. Even a
| little busy waiting, if it is known that there will be a next interrupt
| shortly, may be worthwhile, e.g. when reading packets/bursts from
| line on which you are running a protocol.
+---------------

That's fine, and should be used when appropriate. It mixes well with
the two-level style... as long as you don't leave everybody else's
interrupts turned off during that loop. That's the fundamental problem
the two-level scheme is trying to solve: to decouple the fast-latency
needs of simple hardware (e.g., SIOs at 38400 baud) from the efficiency
concerns of not taking/dismissing a bunch of [heavyweight] interrupts
when you know there's still more work to do.

By keeping the 1st-level interrupts *very* lightweight (*don't* save any
context [except maybe a working reg or two], just grab the data, queue it,
then queue your 2nd-level handler), you can afford a *lot* of interrupts,
many more than you would think. And by leaving hardware interrupts *enabled*
during [almost] all 2nd-level processing, you don't lose data due to
latency problems.

And by doing as much 2nd-level work [normal C-language "interrupt handlers"]
as possible before dismissing -- that is, by letting 1st-level interrupts
continue to add to the 2nd-level work queue and not dismissing until the
work queue is empty -- you only do one full save/restore for the lot.

+---------------
| I do not like much the idea of having an interrupt routine at the end
| fire up polling in other drivers. (If I understood correctly what you
| are thinking about).
+---------------

Why not? Shouldn't they get the same benefits as "your" driver?  ;-}  ;-}

Or maybe you don't like the idea of every interrupt triggering a lot
of "polling". Well, that doesn't really happen. You only "poll" those
other handlers for which interrupts occurred (and thus got queued)
while you were in your "dally" loop... and that's why you don't shut
off system-wide interrupts in your dally loop, just the device you
are polling. And then when you decide nothing else is going to happen
[typically after about 1.5 to 3 times the expected next event], you
re-enable your interrupt, return to the common interrupt "scheduler"
[see above], and Lo & Behold!, if while somebody *else* is handling
a burst your device interrupts, you'll get control again before the
ultimate "dismiss" occurs.

This saves *lots* of context save/restore CPU time. Lots.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 07:01:27 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]

[Excuse me if I edited previous comments to the bone, but it's getting deep...]

By the way, let me preface this by saying that I actually completely agree
with Dave Crocker [below] that polling is the way to go when you have a
few very active devices... *if* you don't need to do something else with
your "idle" time. Pure polling is often the best (and sometimes the only)
strategy in an embedded controller. My remarks in the past few postings
have been assuming that there is general-purpose timesharing going on
in the same CPU, and thus you are trying to balance those famous three --
latency, efficiency, and throughput -- *and* give useful time to the "user".

+--------------- In article <820@aber-cs.UUCP> (Piercarlo Grandi) writes:
| +--------------- In article <25223@amdcad.AMD.COM> (Rob Warnock) writes:
| | +--------------- dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
| | | Interrupts kill... Many, occasional sources of activity warrant
| | | interrupts. A few, active sources warrant polling.
| | Which is why the two-level interrupt service structure I wrote a
| | "tutorial" about in comp.arch (circa 3/20/89?) does exactly this,...
| | But once you get an interrupt, additional interrupts are queued...
| | every second-level interrupt routine checks for more work...
| | if there is any, requeues itself on the tail of the task queue.
| While I agree that the technique is useful, it requires implementing
| a lightweight process system in your kernel, which may be major surgery.
+---------------

The only real surgery, and I'll admit it's a mass of painful detail, is
to go through the kernel (especially the disk cache stuff) taking out all
the unneeded "spl7()" (a.k.a. "splhigh()") calls, and replacing them with
"splsched()". But in fact, for a quick hack, you can simply map *all* the
old calls to "splsched()", and then just put back the few you really need.
[You have to do this, because in any "standard" kernel, there are places
that hold "splhigh" for many *milliseconds*. Any needed mutual exclusion
can always be done in a few microseconds, if only by setting a lock.]

As far as "lightweight processes", I think you misunderstood me. There is
a "lightweight task queue", but the "processes" that are run are actually
all interrupt completion routines, all of which were already there. There
is no new "context"; you're still in "interrupt context".

+---------------
| In a sense, you are using any interrupt as though it were
| the clock interrupt to start polling.
+---------------

Precisely! In fact, one version of this actually just used the kernel's
callout queue (the one that "timeout()" uses), and queued interrupt
completions with a time-to-run of "zero ticks", then let the next tick
of the normal "softclock" handler (which runs at the *lowest* interrupt
priority) run the 2nd-level tasks *just as if* they were timeouts which
had expired. [This assumes you can get a fast enough "hardclock". You can
have "urgent" interrupts start the queue running directly, if you like,
but you lose a lot of the efficiency benefit.]

Any new interrupts that occur while one of those is running get queued
after all the "zero" callouts but before any that are really waiting for
time to elapse. (You should add one more pointer to be maintained, so
you don't have to scan the queue.) And of course, the "softclock" handler
always checks the queue again before dismissing, just to see if any new
interrupts have arrived. (*And* if the clock ticks, adjusts the time left
of the first non-zero task and if it goes to zero promotes the task into
the zero group. That way you your "real" timeouts stay accurate, too.
Also, the "hardclock" 1st-level handler should bump a count of "ticks
seen while softclock busy" that "softclock" can use to keep time straight.)

+---------------
| The simple version, used e.g. in many UNIX kernels, is to have any
| and every interrupt processing procedure always check at the end for
| further pending interrupts for ITSELF, and then go into a loop. Even a
| little busy waiting, if it is known that there will be a next interrupt
| shortly, may be worthwhile, e.g. when reading packets/bursts from
| line on which you are running a protocol.
+---------------

That's fine, and should be used when appropriate. It mixes well with
the two-level style... as long as you don't leave everybody else's
interrupts turned off during that loop. That's the fundamental problem
the two-level scheme is trying to solve: to decouple the fast-latency
needs of simple hardware (e.g., SIOs at 38400 baud) from the efficiency
concerns of not taking/dismissing a bunch of [heavyweight] interrupts
when you know there's still more work to do.

By keeping the 1st-level interrupts *very* lightweight (*don't* save any
context [except maybe a working reg or two], just grab the data, queue it,
then queue your 2nd-level handler), you can afford a *lot* of interrupts,
many more than you would think. And by leaving hardware interrupts *enabled*
during [almost] all 2nd-level processing, you don't lose data due to
latency problems.

And by doing as much 2nd-level work [normal C-language "interrupt handlers"]
as possible before dismissing -- that is, by letting 1st-level interrupts
continue to add to the 2nd-level work queue and not dismissing until the
work queue is empty -- you only do one full save/restore for the lot.

+---------------
| I do not like much the idea of having an interrupt routine at the end
| fire up polling in other drivers. (If I understood correctly what you
| are thinking about).
+---------------

Why not? Shouldn't they get the same benefits as "your" driver?  ;-}  ;-}

Or maybe you don't like the idea of every interrupt triggering a lot
of "polling". Well, that doesn't really happen. You only "poll" those
other handlers for which interrupts occurred (and thus got queued)
while you were in your "dally" loop... and that's why you don't shut
off system-wide interrupts in your dally loop, just the device you
are polling. And then when you decide nothing else is going to happen
[typically after about 1.5 to 3 times the expected next event], you
re-enable your interrupt, return to the common interrupt "scheduler"
[see above], and Lo & Behold!, if while somebody *else* is handling
a burst your device interrupts, you'll get control again before the
ultimate "dismiss" occurs.

This saves *lots* of context save/restore CPU time. Lots.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 11:35:11 GMT
From:      pete@relay.nixctc.de (Pete Delaney)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat
Subject:   Re: TCP/IP versus OSI

In article <146@mirsa.UUCP>, huitema@mirsa.UUCP (Christian Huitema) writes:
> < 
> >                    Round 2 in the great TCP/IP versus OSI Debate
>> 
 I always thought that the date for April fools was April 1st,
>> not March 15th..
> 
> Christian Huitema  <huitema@mirsa.inria.fr>

Noop, it's the 15th :)

How about a serious comeback from one of Europes leading OSI guru's?

Pete Delaney - Nixdorf UCC	| pete@relay.NIXCTC.DE		Prefered Addr
Loffel Strasse 3		| pyramid!nixctc!pete		UUCP from Calf
7000 Stuttgart 70		
West Germany			| Phone: +49 (711) 7685-128

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 15:21:17 GMT
From:      vance@JVNCF.CSC.ORG (Vercell Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]

:q!

zz
ZZ



____________________________________________________________________________

Vercell Vance
Manager, User Services
John von Neumann National Supercomputer Center
Princeton, New Jersey, 08543
Bitnet = vance@jvncc			Internet = vance@jvnca.csc.org
Phone = 609-520-2000
____________________________________________________________________________

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 17:14:22 GMT
From:      Robert.Smart@ditmela.oz.au (Robert Smart)
To:        aus.comms,comp.protocols.tcp-ip
Subject:   Secure access over TCP/IP networks.

Posting #53 to aus.comms
------------------------------------------------------------------------

There is interest in security of access over a TCP/IP network. Here is a simple
proposal for your criticism. The objective is minimum change to existing code. 

This addresses two related security issues: (1) people attempting unauthorized
access to your system; (2) the fact that the TCP data stream is easy to snoop
on as it passes through insecure parts of a network. 

The first thing a Secure-TELNET daemon does when it receives a connection is
send a random number (say 4 bytes) to the client. The client has to know the
servers "magic number". It combines that magic number with the random number to
obtain two random number sequences. The server does the same. From then on each
byte in the TCP stream is XORed with the low order byte of the appropriate
random number sequence. This simultaneously encrypts outgoing bytes and
decrypts incoming ones. In fact the encryption/ decryption code should be in
the TCP layer so that it is quite easy to modify other applications like ftp to
produce secure versions. 

I think this would have a low overhead and be very hard for someone watching
the data stream to decrypt. Any encryption experts like to comment? 

The nice thing about this scheme is that it can be used in two distinct ways.
You can set it up so that machines you trust (on your local subnet, etc) know
the "magic number". The users of those machines can log in to your machine via
Secure Telnet without having the "magic number". Indeed it is best if the
number is held securely so they can't find it out. For the much smaller number
of people who use your machine from remote hosts, perhaps while travelling, you
can tell those people the magic number and they can tell the secure Telnet
client the number when they invoke it. 

-- 
Bob Smart, <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 89 20:16:52 GMT
From:      cpj@SUN.COM (Chuck Jerian)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure access over TCP/IP networks.

>Why not use a a four byte key, a magic number and the low byte to xor...

A four byte key is too short.  It invites a search of the key space.
Also xoring the data one byte at a time with the low byte is suspect.
A much sounder scheme would be to use cipher block chaining and des.

One problem with telnet is that data is sent out of band for commands,
and this causes trouble keeping a cbc synchronized on both ends.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 06:42:00 GMT
From:      whwb@cgch.UUCP (Hans W. Barz)
To:        comp.protocols.tcp-ip
Subject:   MTU with Wollongong

I am posting this question on behalf of Derek A. Stealenberg (DTB):

 This questions concerns Wollongong's TCP/IP with the VAX Pascal interface:

 1) Is it possible to manipulate any TCP/IP parameter (i.e. MTU or max segment
    size) to force our remote recv calls to read 2048 byte mesages with a single 
    read. Currently our client writes 2048 bytes messages and although our server
    expects to read 2048 messages, the read completes with 1024 messages. We then
    have to do a second read to get the rest of the message.

 2) Is there a limit to the size of a message that can be written to the datagram
    socket ? We see a limit of 2048 bytes per message. Can we change this ? We 
    already use setsockopt to increase the send and receive buffers.

 3) Why are our network sockets not deleted when the program that creates them
    goes away. We do a shutdown of the socket and deassign it before exiting. We
    only see this problem if we act as a server and use the primary socket for
    the connection request and the data transfer. If we assign a new channel to
    the client, the problem does not exist.

Hans W. Barz, R.1032.5.56, CIBA-GEIGY, 4002 Basel, Switzerland
mail: whwb@cgch.uucp
phone: +41/61/6974520
fax: +41/61/6973288

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 12:49:28 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   IP authentication


Speaking of encryption on a LAN: 

There's a group meeting for some time called: LAN Security Study Group
(802.10 I think) working toward a group  of encryption standards for LAN.
These are algorithm independent but, everyone likes DES for the traffic
and they've just gotten a proposal for RSA key distribution.
They're been laying a lot of ground work and of couse, 
certain vendors would like the standard to look like their product(s)
(nothing new in this). For more information you might send mail to
kek@mitre-bedford.arpa (mbunix.mitre.org), Kim acts as chairperson of
the group.

Before you trade in your trusty TCPDUMP and overhaul your old rotor
machines, what about all those keys that are going to be floating around 
the net. If everyone shares a common key you get no security. If everyones
got a different key, well, start thinking about key management. 

                           -hal@gateway.mitre.org
                                 

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 16:35:27 GMT
From:      jpeck@hpspdra.HP.COM (Joe Peck)
To:        comp.protocols.tcp-ip
Subject:   What is AT&T's vendor id?

I'm trying to verify what the Ethernet vendor id is for AT&T.
I have it as 08-00-10, but lately we've been seeing packets on
a network with the vendor id = 80-00-10.  I'd like to know if we've
got the right one for AT&T and if we do, then who is 80-00-10?

Thanks,

Joe Peck   jpeck@hpspdra.hp.com

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 19:11:35 GMT
From:      CC_DFOO@VAXB.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   VAX6220 network problem

Hi ;
	Someone who has VAX6220 may interest in this network problem !!!!
        *************************************************************
	*************************************************************

	Currently our campus network was designed to allow student use
	PC running DECnet/DOS v 1.2 through DEMPER direct connect to Ethernet 
        backbone. One of our VAXcluster 6220 (VMS 5.0-2 two processor) 
        suddently became network resource unavailable. I checked users at that 
	moment only 11 users on the system but when I checked NCP> show know 
	link, there were lots of unknown processors occupied the line.
	I call DEC Colorado for help.
        The unsatisfied answers are:
        ***************************

	" When you log in and log out of VAX6220 using DECnet-DOS v 1.2 through
	DEMPR and did not turn off P.C. right away. VAX will still reconize
	you still hanging there wear an unknown mask. That's why the unknown
	processors from."


	I am doing some test now including update the DECnet-DOS version and
	modify NCP parameters. But if someone has the same experience I had
	please let me know.


	David Foo        Tel: 201-420-5736
	Computer Center
	Stevens Institute of Technology
        Bitnet cc_dfoo@sitvxc
	Arpnet cc_dfoo@vaxc.stevens-tech.edu
       

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

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 20:45:36 GMT
From:      nsb+@ANDREW.CMU.EDU (Nathaniel Borenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: SMTP and alternate message body types [Was Re: Secure SMTP & X.400]

> *Excerpts from magazines.mail.cfe: 6-Apr-89 SMTP and alternate message ..*
> *Matt Landau@bbn.com (2843)*
> I believe that CMU has done something similar with the Andrew system
> to allow delivery of Andrew multimedia documents via sendmail.  I'm not
> sure their version is configurable to handle arbitrary content types,
> but the existence of these two different systems should serve as proof
> that we can easily extend current SMTP (and other text-mail mail delivery
> mechanisms) to deal with complex body types, without all the ancilliary
> hair of X.400
Yes, this is certainly the case.  For the record, the Andrew Message system can
handle other content types; for example, you can use the header

Content-type: troff; 0 ; /usr/lib/tmac/tmac.an,/usr/lib/tmac/tmac.recipe

to see on-screen the properly formatted versions of the recipes that Briane Reid
distributes via the newsgroup alt.gourmand (assuming, of course, that you've
installed his troff library in /usr/lib/tmac/tmac.recipe).  The mechanism is
indeed very general and flexible.

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Apr 89 21:16:59 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure access over TCP/IP networks.

In article <4814@ditmela.oz> smart@ditmela.oz.au (Robert Smart) writes:
>The first thing a Secure-TELNET daemon does when it receives a 
>connection is send a random number (say 4 bytes) to the client.

Why?  Since this number is sent over the network and is visible to any
snoopers, it adds nothing to security.

>The client has to know the servers "magic number". It combines
>that magic number with the random number to obtain two random
>number sequences. The server does the same. From then on each
>byte in the TCP stream is XORed with the low order byte of the 
>appropriate random number sequence...
>I think this would have a low overhead and be very hard for
>someone watching the data stream to decrypt...

It depends entirely on how good your random-number-sequence generator
is.  If it's, say, the one from your local C library, you have very
little security, because methods of breaking such things are widely
known.  If it's of crypto quality, okay -- but where are you going
to get one like that?  What you've invented is the supporting
substructure of a cryptosystem -- a secret key known to both ends
and XOR-based combination with the plaintext.  What you haven't done
is to specify the crucial part:  how a short key gets turned into a
very long sequence of very random-looking bits.  The standard sorts
of random-number generators used in computing are ridiculous toys
by cryptographic standards.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 21:28:22 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Link-layer I/O interface (was: IP based authentication of hosts)


    Why dig up the kernel?  More than one workstation vendor provides standard
    tools to send and receive arbitrary ethernet packets.  Remember nit,
    tcpdump, and etherfind from one of those vendors.  Others have what they
    consider better.  Many paying customers think they require raw ether for
    real applications (i.e. something they'll pay for).

This brings up a point that I've been thinking about for a while. Has anyone
proposed a standard UNIX socket interface for sending/receiving link-layer
packets? It would be a very useful thing to see in, say, 4.4BSD... Something
combining the I/O interface of sockets with the better features of both NIT
and the CMU/Stanford packet filter would be ideal.

	--Vince
-------

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Apr 89 21:37:12 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re:  Re: IP based authentication of hosts

In article <709@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>Kent England suggests that it is possible to prevent ether snooping
>in many cases, and that this can be used to give ``a modest level of
>security sufficient to fulfill [his] obligations to protect data and
>yet still allow [] applications to use network technology'' 
>
>Kent, how do you propose to stop J R User from unplugging his Sun and 
>plugging in a PC to run an etherspy?

If he's using Ethernet to connect Suns in offices and terminal rooms,
he can't.  If, on the other hand, it's simply the interconnect within a
central computing facility, then the situation is not so bad.  Yes, it
can always be done by someone with the right tools and knowledge -- but
in most places, such people are relatively rare.  The key question is,
what level of threat are you trying to defend against?  If all you want
is to stop casual nosiness by J R User, Kent's approach may be reasonable.

Even if JRU knows how to tap an Ethernet -- and if it's thick cable, the
chances are pretty good that he doesn't -- he is going to be reluctant
to walk into a facility where he is an unauthorized outsider and start
pulling up floor tiles and messing with cables underneath.  Likewise, he's
going to be reluctant to disconnect existing transceiver cables, for fear
that he'll disrupt ongoing activities badly enough for the Cable Police
to come charging in the door.

No, it's not going to stop a determined and knowledgeable intruder who
is willing to take some risks, but that's a different level of threat
and a rather less common one.  Switching to encryption-based schemes
will thwart him, but it is much more costly in several ways.  In a
relatively friendly environment, it may not be cost-effective.

>I put it to you that your ``modest degree of security'' is actually
>no security worth speaking of.  

It depends on what level of threat we are speaking of, and on details
of the environment (e.g. where existing taps are).  Don't dismiss it
as "no security worth speaking of" just because it wouldn't stop the NSA.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Apr 89 21:41:58 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <710@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>I want security that is on the same level as me keeping sensitive 
>materials in a locked filing cabinet inside a locked office with the 
>nightwatchman walking the corridors...

Gee, you mean one of those filing cabinets whose locks can be picked with
a paperclip?  Inside an office that opens to a master key that the janitor
has?  The nightwatchman is actually very useful, I can have him hold the
door for me as I walk out with an armload of papers.

Let us not kid ourselves.  An awful lot of non-computer security rests
primarily on the rarity of determined and sophisticated intruders.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 89 22:14:42 GMT
From:      rja%batcomfs@Sun.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   DDN X.25 question.


    I'm working on adding some 1984 X.25 features to a 1980 X.25 implementation
    and I have a question about the facilites required by DDN X.25, as
    specified in the DDN X.25 spec. in Vol. 1 of the DDN Protocol Handbook.

    In section 2.1.2, it is noted that two facilities, type-of-service and
    call precedence, should be included *after* all CCITT X.25 facilities and
    must be preceded by a two byte facility marker, where each byte is of
    zero value.

    The type and location of the facility marker is counter to what is 
    documented in DIS 8208 "Info. Processing Systems - X.25 packet level
    protocol for data terminal equipment", which states that:
    
	(1) all CCITT specified facilities must come *after* "non-X.25
	facilities supported by the network...of the calling DTE...",
	which is what the DDN facilities are based on the facilities marker
	used to denote them.

	(2) that the facilites marker for X.25 specific facilities (which
	happens to be two zero bytes) must come BEFORE the CCITT facilites
	marker,

    If, as the DDN X.25 spec states, the DDN X.25 facilities must come after
    the CCITT facilities, *and* must use two zero bytes as the facilities
    marker of two zero bytes, then the two protocols, DDN X.25 and 1984 X.25,
    seem to not be compatible.  Is this correct?  If not, what am I mis-
    understanding here?

    Thanks in advance,

Robert Allen		"I'm the NRA" (and soon the ACLU too.)
rallen@sun.com		"Just say NO to the loss all our civil liberties."
Disclaimer: The opinions expressed are mine [so keep your hands off :-) ]

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 01:58:25 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: new terminal names

/ comp.protocols.tcp-ip / amanda@lts.UUCP (Amanda Walker) / Apr 10, 1989 /

>    For instance, the domain application wants host type and OS type for the
>    hosts on which the domain's nameservers run.  What on Earth for?
> 
> I can think of several reasons off-hand.  The most practical one is for
> identifying special circumstances.  For example, the FTP client in our
> Macintosh TCP/IP package uses this information to provide extended
> functionality (such as directory browsing and file size estimation)
> for hosts it "understands."

If you are doing an FTP to foo.bar.edu, how does it help to know that the
two name servers for bar.edu are a Timex/Sinclair and an IBM Selectric?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Apr 89 08:59:42 -0400
From:      Andy Malis <malis@BBN.COM>
To:        Robert Allen <batcomfs!rja@sun.com>
Cc:        tcp-ip@sri-nic.arpa, malis@BBN.COM
Subject:   Re: DDN X.25 question.
Robert,

I'm not familiar with DIS 8208.  However, let me quote from the
CCITT Red Book (1984), Rec. X.25, section 7.1, p.209:

      Facility/registration markers, consisting of a single octet
      pair, are used to separate requests for X.25 facilities ...
      from other categories as defined above [non-X.25 facilities
      which may be provided by some networks] ...

      The first octet of the marker is a facility/registration
      code field and is set to zero.  The second octet is ... set
      to zero when the marker precedes requests for:

      - non-X.25 facilities provided by the network in case of
        intranetwork calls.

      ...

      Facility/registration codes for X.25 facilities and for
      the other categories of facilities may be simultaneously
      present.  However, requests for X.25 facilities must
      precede the other requests.


So, you must first have the CCITT-defined X.25 facilities, then
the marker, and then the non-X.25 facilities provided by the
network.

Cheers,
Andy Malis
BBNCC PSN Development
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Apr 1989 07:22:59 EDT
From:      JoAnn <TKSJMI@UBVM.CC.BUFFALO.EDU>
To:        tcpip mail list <TCP-IP@SRI-NIC.ARPA>
Subject:   ip routers and ethernet types

 In our campus network of brouters and ip routers we have Wellfleet
 boxes, Vaxes and Suns that act as ip gateways.

 I am not sure if a "real" rfc-defined ip router should only let packets
 of ethernet type 800 (dod ip) thru it's interfaces.  I couldn't find
 a statement to clearly define this point in the gateway rfc (rfc1009).
 But I may have missed it!

 We want to have requirements defined for terminal server downlineload
 hosts, and it is not clear if we should ask vendors to use ethernet
 type 800 as part of their bootstrap/ts management protocols.  If a
 vendor uses another ethernet type, should a "real" ip router block
 the packet?

 Can someone site the rfc this info is directly addressed?

 thanks,
 JoAnn
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 03:47:36 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   DRAFT RFC: Implementing TELNET Option Negotiation

DRAFT RFC: Implementing TELNET Option Negotiation
April 1989
Daniel J. Bernstein, brnstnd@stealth.acf.nyu.edu

Status of This Memo

  This is a draft RFC supplementing RFC 854, TELNET PROTOCOL
  SPECIFICATION. It is intended as a specification for the
  Internet community. Distribution of this memo is unlimited.


SECTION 1. Introduction

This RFC amplifies, supplements, and extends the RFC 854
option negotiation rules and guidelines, which are insufficient
to prevent all option negotiation loops. This RFC also presents
an example of correct implementation.

A TELNET implementation is not compliant with this RFC if
it fails to satisfy all rules marked MUST. It is compliant if
it satisfies all rules marked MUST. If it is compliant, it is
unconditionally compliant if it also satisfies all rules marked
SHOULD and conditionally compliant otherwise. Rules marked MAY
are optional.

Options are in almost all cases negotiated separately for each side
of the connection. We will consider the option on one side to be
separate from the option on the other side. Thus when we talk about
``the'' option referred to by a DONT/WONT or a DO/WILL, we are only
combining the cases for semantic convenience. Each sentence could be
split into two, one with the words before the slash and one with the
words after the slash.


SECTION 2. RFC 854 Option Negotiation Requirements

We require the following, as per RFC 854: A TELNET implementation
MUST obey a refusal to enable an option; i.e., if it receives a
DONT/WONT in response to a WILL/DO, it MUST NOT enable the option.
It MUST therefore remember that it is negotiating a WILL/DO, and
this negotiation state MUST be separate from the enabled state
and from the disabled state. During the negotiation state, any
effects of having the option enabled MUST NOT be used.

If it receives WONT/DONT and the option is enabled, it MUST respond
DONT/WONT repectively and disable the option. It MUST NOT initiate
a DO/WILL negotiation for an already enabled option or a DONT/WONT
negotiation for a disabled option. It MUST NOT respond to receipt
of such a negotiation. It MUST respond to receipt of a negotiation
that does propose to change the status quo.

The implementation MUST NOT automatically respond to the rejection
of a request by submitting a new request. As a rule of thumb, new
requests should be sent either at the beginning of a connection or
in response to an external stimulus, i.e., input from the human user or
from the process behind the server.

Though this is not stated as strongly in RFC 854, a TELNET
implementation MUST refuse (DONT/WONT) a request to enable an
option for which it does not comply with the appropriate protocol
specification. Any other action is counterproductive.


SECTION 3. Rule: Remember DONT/WONT requests

It is not clear from RFC 854 whether or not TELNET must remember
beginning a DONT/WONT negotiation. The argument for remembering
a DO/WILL negotiation does not apply, because WANTNO (negotiating
for disabling) does not differ from NO the way that WANTYES differs
from YES. (In state YES, the option is enabled; in state WANTYES,
the option is disabled. However, in both states NO and WANTNO,
the option is disabled.) There is no choice for the other side in
responding to a DONT/WONT; the option is going to end up disabled.
When we receive the WONT/DONT response, we will ignore it since the
option is disabled. It appears then that we might as well not
remember starting a DONT/WONT negotiation.

Unfortunately, that conclusion is wrong. Consider the following
TELNET conversation between two parties, ``me'' and ``him''. (The
reader of this RFC may want to sort the steps into chronological
order for a different view.)

  Both sides know that the option is on.

  On his side:
  1. He decides to disable. He sends DONT and disables the option.
  2. He decides to reenable. He sends DO and remembers he is negotiating.
  5. He receives WONT and gives up on negotiation.
  6. He decides to try once again to reenable. He sends DO and remembers
     he is negotiating.
  7. He receives WONT and gives up on negotiation.
  For whatever reason, he decides to agree with future requests.
  10. He receives WILL and agrees. He responds DO and enables the option.
  11. He receives WONT and sighs. He responds DONT and disables the option.
  (repeat 10 and then 11, forever)

  On our side:
  3. We receive DONT and sigh. We respond WONT and disable the option.
  4. We receive DO but disagree. We respond WONT.
  8. We receive DO and decide to agree. We respond WILL and enable the
     option.
  9. We decide to disable. We send WONT and disable the option.
  For whatever reason, we decide to agree with future requests.
  12. We receive DO and agree. We send WILL and enable the option.
  13. We receive DONT and sigh. We send WONT and disable the option.
  (repeat 12 and then 13, forever)

Both sides have followed RFC 854; but we end in an option negotiation
loop, as DONT DO DO and then DO DONT forever travel through the network
one way, and WONT WONT followed by WILL WONT forever travel through the
network the other way. The behavior in steps 1 and 9 is responsible for
this loop.

Therefore: A TELNET implementation MUST remember starting a DONT/WONT
negotiation.

We will consider later whether separate states are needed for WANTNO and
WANTYES or a single negotiation state will suffice.


SECTION 4. Rule: Prohibit new requests before completing old negotiation

It is also unclear from RFC 854 whether or not a TELNET implementation
may allow new requests about an option that is currently under
negotiation; it certainly seems limiting to prohibit ``option
typeahead.'' Unfortunately, it is necessary.

Suppose an option is disabled, and I decide in quick succession to
enable it, disable it, and reenable it. I send WILL WONT WILL and
at the end remember that I am negotiating. The other side agrees
with DO DONT DO. I receive the first DO, enable the option, and
forget I have negotiated. Now DONT DO are coming through the
network and both sides have forgotten they are negotiating; and
consequently we loop.

(All possible TELNET loops eventually degenerate into this same form,
where WILL WONT [or WONT WILL, or WILL WONT WILL WONT, etc.] go
through the network while both sides think negotiation is over;
the response is DO DONT and this loops forever. TELNET implementors
are encouraged to implement any option that can detect such a loop
and cut it off; e.g., a method of explicitly differentiating requests
from acknowledgments would be sufficient. No such option exists as
of April 1989.)

This particular case is of considerable practical importance,
since most combinations of existing user-server TELNET implementations
do enter an infinite loop when asked quickly a few times to enable and
then disable an option. It is clear that a new rule is needed.

One might try to prevent the several-alternating-requests problem by
maintaining a more elaborate state than YES/NO/WANTwhatever, e.g.,
a state that records all outstanding requests; but it is difficult
to specify such a scheme so that it won't blow up if both sides initiate
several requests at once. Another possible answer would be to wait
for a response before continuing at all; but this is very limiting
and impractical over slow networks, and it is more restrictive than
the solution we actually adopt, which is as follows:

A TELNET implementation MUST NOT initiate a new WILL/WONT/DO/DONT
request about an option that is under negotiation, i.e., for which
it has already made such a request and not yet received a response.


SECTION 5. How to reallow the request queue

The above rule prevents queueing of more than one request through
the network. We discuss here how to queue new requests within the
TELNET implementation, so that ``option typeahead'' is effectively
restored.

An obvious possibility is to maintain a list of requests that have been
made but not yet sent, and when one negotiation completes, the next can
be started immediately. So while negotiating for a WILL, TELNET could
buffer the user's requests for WONT, then WILL again, then WONT, then
WILL, then WONT, buffering as far as desired.

This requires a dynamic and potentially unmanageable buffer. However,
the restrictions upon possible requests guarantee that the list of
requests must simply alternate between WONT and WILL. It is wasteful
to enable an option and then disable it, just to enable it again;
we might as well just enable it in the first place. The few possible
exceptions to this rule do not outweigh the immense simplification
afforded by remembering only the last few entries on the queue.

To be more precise, during a WILL negotiation, the only sensible
queues are WONT and WONT WILL, and similarly during a WONT negotiation.
In the interest of simplicity, we eliminate the WONT WILL possibility,
though this is debatable.

We are now left with a queue consisting of either nothing or the
opposite of the current negotiation. When the TELNET implementation
receives a reply to the negotiation, if the queue indicates that the
option should be changed, it sends the opposite request immediately
and empties the queue. Note that this does not conflict with the
RFC 854 rule about automatic regeneration of requests, as these new
requests are simply the delayed effects of user or process commands.

Now the specific rules: An implementation SHOULD support the queue.
If it does support the queue, it MUST handle a new request from the
user or process before the option negotiation is complete as follows:
If the queue is EMPTY, then set it to OPPOSITE if the request is for
the opposite of the previous negotiation and otherwise indicate an
error or ignore the request. If the queue is OPPOSITE, then set it
to EMPTY if the request is for the same as the previous negotiation
and otherwise indicate an error or ignore the request.

If the queue is set to OPPOSITE and the negotiation completes in
the affirmative (DO-WILL/WILL-DO, DONT-WONT/WONT-DONT), the TELNET
implementation MUST immediately generate a new request for the
opposite effect, and set the queue to EMPTY.

The implementation MAY provide a method by which support for the
queue may be turned off and back on. In this case, it MUST default
to having the support turned on.


SECTION 6. Rule: Separate WANTNO and WANTYES

It is possible to maintain a working TELNET implementation if
the NO/YES/WANTNO/WANTYES states are simplified to NO/YES/WANT.
However, in a hostile environment this is a bad idea, as it
means that handling a DO/WILL response to a WONT/DONT cannot
be done correctly. It does not greatly simplify code; and the
simplicity gained is lost in the extra complexity needed to
maintain the queue.

Thus, implementations MUST separate the state of negotiating
WILL/DO from the state of negotiating WONT/DONT.


7. Example of Correct Implementation

To ease the task of writing TELNET implementations, we present
here a precise example of the response that a compliant TELNET
implementation could give in each possible situation. All
TELNET implementations SHOULD follow the procedures shown here,
and implementors are very strongly encouraged to follow them
unless they have an excellent reason otherwise.

  There are two sides, I (me) and he (him).

  I keep several variables.

    me: state of option on my side (NO/WANTNO/WANTYES/YES);
	also, if me is WANTNO or WANTYES, a ``queue bit''
	meq (EMPTY/OPPOSITE).
    him: state of option on his side; also, if him is WANTNO
	 or WANTYES, a ``queue bit'' himq.

  An option is enabled if and only if its state is YES. Note
  that me and meq could be combined into a NO/WANTNO/
  WANTNOOPPOSITE/WANTYES/WANTYESOPPOSITE/YES state.

  ``Error'' below means that producing diagnostic information
  may be a good idea, though it isn't required.

  Upon receipt of WILL, I choose based upon him and himq:
    NO            If we agree that he should enable, him=YES, send DO;
		  otherwise, send DONT.
    YES           Ignore.
    WANTNO EMPTY  Error: DONT answered by WILL. him=NO.
        OPPOSITE  Error: DONT answered by WILL. him=YES*, himq=EMPTY.
    WANTYES EMPTY him=YES.
	 OPPOSITE him=WANTNO, himq=EMPTY, send DONT.

* This behavior is debatable; DONT will never be answered by WILL
over a reliable connection between TELNETs compliant with this RFC,
so this was chosen (1) not to generate further messages, because
if we know we're dealing with a noncompliant TELNET we shouldn't
trust it to be sensible; (2) to empty the queue sensibly.

  Upon receipt of WONT, I choose based upon him and himq:
    NO            Ignore.
    YES           him=NO, send DONT.
    WANTNO EMPTY  him=NO.
	OPPOSITE  him=WANTYES, himq=NONE, send DO.
    WANTYES EMPTY him=NO.*
	 OPPOSITE him=NO, himq=NONE.**

* Here is the only spot a length-two queue could be useful; after a
WILL negotiation was refused, a queue of WONT WILL would mean to
request the option again. This seems of too little utility and too
much potential waste; there is little chance that the other side will
change its mind immediately.

** Here we don't have to generate another request because we've been
``refused into'' the correct state anyway.
    
  If we decide to ask him to enable:
    NO            him=WANTYES, send DO.
    YES           Error: Already enabled.
    WANTNO EMPTY  If we are queueing requests, himq=OPPOSITE;
		  otherwise, Error: Cannot initiate new request
		  in the middle of negotiation.
	OPPOSITE  Error: Already queued an enable request.
    WANTYES EMPTY Error: Already negotiating for enable.
	 OPPOSITE himq=EMPTY.

  If we decide to ask him to disable:
    NO            Error: Already disabled.
    YES           him=WANTNO, send DONT.
    WANTNO EMPTY  Error: Already negotiating for disable.
	OPPOSITE  himq=EMPTY.
    WANTYES EMPTY If we are queueing requests, himq=OPPOSITE;
		  otherwise, Error: Cannot initiate new request
		  in the middle of negotiation.
	 OPPOSITE Error: Already queued a disable request.


End of DRAFT RFC

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 04:04:56 GMT
From:      munnari!otc!softway!chris@uunet.uu.net  (Chris Maltby)
To:        tcp-ip@sri-nic.arpa
Subject:   RFC on Internet Data Encryption scheme
My apologies for boring you, but can anyone inform me of the
RFC number which refers to the proposed Internet encryption
scheme. I would be even happier if you could direct a copy of
the RFC in my direction. (compress/btoa or uuencode preferred).

Thanks in advance...
-- 
Chris Maltby - Softway Pty Ltd	(chris@softway.sw.oz)

PHONE:	+61-2-698-2322		UUCP:		uunet!softway.sw.oz.au!chris
FAX:	+61-2-699-9174		INTERNET:	chris@softway.sw.oz.au
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 1989 1450-EST
From:      hsw@TYCHO.NCSC.MIL  (Howard Weiss)
To:        tcp-ip at nic.ddn.mil
Subject:   SIGCOMM '89
Does anyone have any pre-information regarding SIGCOMM '89 - I've got the
dates and the place (Austin, 20-22 Sept) - does anyone have an idea what
the costs will be and what tutorials will be given.  I need this info
for planning purposes - the conference comes out near the end of the
govt fiscal year and money is many times in very short supply at that
time of the year.

Thanks,

Howard Weiss
-------

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 11:22:59 GMT
From:      TKSJMI@UBVM.CC.BUFFALO.EDU (JoAnn)
To:        comp.protocols.tcp-ip
Subject:   ip routers and ethernet types


 In our campus network of brouters and ip routers we have Wellfleet
 boxes, Vaxes and Suns that act as ip gateways.

 I am not sure if a "real" rfc-defined ip router should only let packets
 of ethernet type 800 (dod ip) thru it's interfaces.  I couldn't find
 a statement to clearly define this point in the gateway rfc (rfc1009).
 But I may have missed it!

 We want to have requirements defined for terminal server downlineload
 hosts, and it is not clear if we should ask vendors to use ethernet
 type 800 as part of their bootstrap/ts management protocols.  If a
 vendor uses another ethernet type, should a "real" ip router block
 the packet?

 Can someone site the rfc this info is directly addressed?

 thanks,
 JoAnn

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 12:59:42 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN X.25 question.

Robert,

I'm not familiar with DIS 8208.  However, let me quote from the
CCITT Red Book (1984), Rec. X.25, section 7.1, p.209:

      Facility/registration markers, consisting of a single octet
      pair, are used to separate requests for X.25 facilities ...
      from other categories as defined above [non-X.25 facilities
      which may be provided by some networks] ...

      The first octet of the marker is a facility/registration
      code field and is set to zero.  The second octet is ... set
      to zero when the marker precedes requests for:

      - non-X.25 facilities provided by the network in case of
        intranetwork calls.

      ...

      Facility/registration codes for X.25 facilities and for
      the other categories of facilities may be simultaneously
      present.  However, requests for X.25 facilities must
      precede the other requests.


So, you must first have the CCITT-defined X.25 facilities, then
the marker, and then the non-X.25 facilities provided by the
network.

Cheers,
Andy Malis
BBNCC PSN Development

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 13:54:51 GMT
From:      mcguffey@muvms1.bitnet (Michael McGuffey)
To:        comp.protocols.tcp-ip,u3b.misc
Subject:   TCP/IP requested for ATT 3B systems


Our Computer Science department recently received an ATT 3B15, and our
College of Science has had several 3B2/400's for a while.  They would 
like some "connectivity" to the outside world.

The University Computer Center has VAX computers running VMS with DECnet 
and TCP/IP (Internet) connections to other campuses.

Each could probably swing funding for an Ethernet card, but commercial
software is expensive.  Are any "free" TCP/IP implementations available
for the 3B series of  computers? 

What are other alternatives for connecting 3B's to a VMS/VAX system?

Thanks,

--michael

-----------------------------------------------------------------------
Michael McGuffey, Senior Software Applications Analyst
Phone:    304/696-3212			University Computer Center 
FAX:      304/696-3601			Marshall University
BITNET:   mcguffey@muvms1		Huntington, WV 25755-5320
Internet: mcguffey%muvms3@wvnvms.wvnet.edu

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 15:05:18 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   DEPCA & PC tcp/ip



we support tcp-ip and, on top of that, netbios on the depca, running some
software dec provides for it (pcsa or decnet dos). you can mail to 
info@vaxeline.ftp.com for more detailed sales type information.


stev knowles
ftp software

"Do you have any MAPS of POLAND?"

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 15:32:14 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  DDN X.25 question.

I think you have become lost in CCITT/ISOspeak.  This is no reflection
on your intelligence or diligence; their nomenclature is considerably
less than lucid.

I'm not sure where you got your #1 from in 8208, but I'm speculating
that you are looking near the end of clause 15.1.  The statement
actually made there is that "requests for X.25 facilities must precede
the other requests and requests for CCITT-Specified DTE facilities must
follow the other requests."  In both 8208 and 1984 X.25, X.25
facilities and CCITT-Specified DTE facilities are two disjoint subsets
of the facilities discussed in the documents.

By X.25 facilities, they mean those discussed in clauses 6 and 7 of
X.25(1984), which correspond to clause 13 of 8208.  By CCITT-Specified
DTE facilities, they mean those discussed in Annex G of X.25(1984),
which corresponds to clause 14 of 8208.  So the "non-X.25 facilities"
(which as you correctly deduced, is what the DDN Type of Service and
Precedence facilities are) are requested with "other requests".

Translation: The X.25 facilities come first, the non-X.25 facilities
(such as DDN's) come second, and the CCITT-Specified DTE facilities
come third.

Bear in mind that when the DDN X.25 spec in the Handbook was written,
X.25(1984) wasn't out yet.  Before X.25(1984), there was no such thing
as a "CCITT-Specified DTE facility" and thus no reason to clarify where
the DDN non-X.25 facilities belong in relation to them.  So, when the
DDN spec refers to "all CCITT X.25 facilities", it's unambiguous in
the author's frame of reference.  And strictly speaking, it isn't wrong
now, if you parse it as  (all (CCITT (X.25 facilities)))  rather than as
(all ((CCITT X.25) facilities))  since the CCITT-Specified DTE facilities
are not X.25 facilities even though CCITT specifies them in Annex G of
Rec X.25 and Annexes are considered an integral part of Recommendations.

Sigh.

(Fine print:  CCITT specifies the coding of the CCITT-Specified DTE
Facilities, but does not specify the procedures for using them, in the
CCITT sense of the word "procedures".  That issue is considered to be
in the realm of "international user organizations" by which they mean
ISO.  Likewise, they don't tell you how the two types of "other
requests" are positioned in relation to each other, only where they all
are in relation to the facilities which are in their domain to specify.
So the relative position of calling-DTE-specific-non-X.25-facility-requests
and called-<what I just said> is a local network matter.  You have to
ponder this for a bit to realize that an internetwork call between two
networks with conflicting rules doesn't make the conflict visible to
either network!)

The DDN doesn't specifically claim to support passing CCITT-Specified
DTE facilities at this time, and I have no idea what would happen if
you tried to do it.  If it doesn't work now, it will probably be added
on the next pass.

Does it all make sense now?  Hmm, let me rephrase that.  Does it all
seem consistent now?

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Apr 89 19:36:01 EDT
From:      Scotty <SCOTTY%UOGUELPH.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Some alternatives to OSI
I lived in Stornoway for 3 years, so I wouldn't really be too surprised to
see bonifres burning on the hill! :-)
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 16:24:54 GMT
From:      hoffman@pitt.UUCP (Bob Hoffman)
To:        comp.protocols.tcp-ip
Subject:   Re: What is AT&T's vendor id?

All of the lists I have seen show AT&T's vendor ID to be 08-00-10,
however all of the AT&T machines I have pinged on campus have
ethernet addresses beginning with 80-00-10.

-- 
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    hoffman@vax.cs.pittsburgh.edu

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 16:41:10 GMT
From:      J.Pearson@CS.UCL.AC.UK (James Pearson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for RT-11 and/or TSX+?

Does anyone know of a TCP/IP implementation for a MicroPDP 11/73
running RT-11 and/or TSX+?

I only require FTP client capability.

Thanks in advance

James Pearson
+------------------------------------------------------------------------+
Dept. Photogrammetry & Surveying	 ARPA: j.pearson@cs.ucl.ac.uk
University College London		 UUCP: ...!ukc!cs.ucl!j.pearson
Gower Street				JANET: j.pearson@uk.ac.ucl.cs
London	WC1E 6BT
England

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 17:39:00 GMT
From:      7thSon@SLCS.SLB.COM (Chris Garrigues)
To:        comp.protocols.tcp-ip
Subject:   Re:  Re: IP based authentication of hosts

It seems to me that Kent is working on the theory that:

	"Locks are to keep honest people honest; no amount of security
	which we can afford will keep out anybody who truely wants to
	cause trouble anyway." 

If he's going to take this approach, he needs to plug anything which is
easy to get into , but he also has to be careful not to put in enough
security to make it "an interesting challenge" for someone who would
otherwise not bother.


Chris

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 18:10:26 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Subliminal (RFC1097)

In article <3270014@hpctdkz.HP.COM> jeff@hpctdkz.HP.COM (Jeff Hughes) writes:
>    I am confused. Is RFC1097 a joke or what? If so, no one is laughing.

Maybe you aren't, but I chuckled when I read it.  It was dated April
1, so I recognized it immediately for what it was (I don't think a
serious RFC ever has or will be published on that date).  It was good
satire, as it was written in the precise style of normal Telnet option
RFC's.  It was funnier than the usual Usenet humor, which is mostly
made up of Star Trek: The Next Generation parodies, definitions of
"Real Programmers", and computer folklore discussions that degenerate
into lists of all the silly things naive users do to floppy disks.
But the proof of the pudding is that some people actually believed it,
despite repeated warnings in news.announce.important to be on the
lookout for April Fool's Day hacks.  The other funny thing is that
there are still people flaming about it nearly three weeks later.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 19:50:00 GMT
From:      hsw@TYCHO.NCSC.MIL (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '89

Does anyone have any pre-information regarding SIGCOMM '89 - I've got the
dates and the place (Austin, 20-22 Sept) - does anyone have an idea what
the costs will be and what tutorials will be given.  I need this info
for planning purposes - the conference comes out near the end of the
govt fiscal year and money is many times in very short supply at that
time of the year.

Thanks,

Howard Weiss
-------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 20:24:07 GMT
From:      pete@uotcsic..uofo.edu
To:        comp.protocols.tcp-ip
Subject:   Need help



Hi networld,
       Where can I get a copy of RFC1097?  I've been reading the discussions,
and I think that it would be very useful for me to read the entire thing
myself.  I am even thinking that the local press might like to look at
it, after all, they are *so* great at educating the public on the 
dangers/security problems/etc. of computer systems.
Pete Hickey                            | pete@UOTCSI2.BITNET
Dept. of Computer Science,             | pete@uotcsi2.UofO.EDU
University of Ottawa,                  |
Ottawa, Ont., Canada K1N 6N5           | (613) 564-5424

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 20:52:24 GMT
From:      oz@yunexus.UUCP (Ozan Yigit)
To:        comp.protocols.tcp-ip
Subject:   ps2/70 AIX + ether card (?)

[If this is the wrong newsgroup, my apologies]

In order to run TCP/IP under PS2/70 with AIX, IBM recommends
Ungermann Bass NICps/2 Adapter 1542. Does anyone know of other
interface cards (We prefer not to use UB, if we can help it)
supported by/or has driver for AIX PS/2, or compatible with UB
interface so that the AIX driver works ??

Please reply by mail.	Thnx...		oz
-- 
use the source, luke !!     		Usenet:    oz@nexus.yorku.ca
uh... we forgot to tell you...       	......!uunet!utai!yunexus!oz
it is unintelligible, but hey, you	Bitnet: oz@[yulibra|yuyetti]
got it, for free (!).		  	Phonet: +1 416 736-5257x3976

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 21:06:54 GMT
From:      dan@ccnysci.UUCP (Dan Schlitt)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal

It must be working like magic.  Haven't heard a noise out of Webber in
ages.


-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan@ccnysci                        City College of New York
dan@ccnysci.bitnet                 New York, NY 10031
                                   (212)690-6868

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 89 23:36:01 GMT
From:      SCOTTY@UOGUELPH.BITNET (Scotty)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI

I lived in Stornoway for 3 years, so I wouldn't really be too surprised to
see bonifres burning on the hill! :-)

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 03:05:10 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Information on X.500


Sorry about the re-posting, this never seems to have made it out to the
USENET, at least it never appeared back on this host:

>Date: Sat 15 Apr 89 14:20:28-PDT
>From: Ole J. Jacobsen <OLE@CSLI.Stanford.EDU>
>Subject: Re: Info on X.500
>To: tcp-ip@sri-nic.arpa
 
>The June 1989 issue of ConneXions will have an article on X.500 by Steve
>Benford of the University of Nottingham, England. The article is part of
>a series entitled "Components of OSI". 
 
>Ole

-------

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Apr 89 09:47:39 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        yunexus!lethe!dave@uunet.uu.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Unaligned Accesses & Comms.

David:

    This is a belated reply to your note.

    I think that for the near future processor speeds and communications
speeds will roughly keep pace.  Or better said, they won't be so out of
sync that we need to radically revise our current networking models
(both virtual circuit and datagram) even into the gigabit speed realm.
[Note that some folks are talking about supporting new communications
paradigms on very high speed networks -- those new paradigms may require
us to revise our networking models -- I'm simply saying that speed alone
won't].

    On the narrower question of alignment, I think some alignment is
always a win.  Note that I don't care if each field is aligned nicely
on a word boundary -- bit masks can grab out stuff from the middle.
What I do care about is not having fields straddle boundaries.  Having
the high-order byte of a two-byte field in one word and the low-order byte
in another word is a nuisance...

Craig
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Apr 89 09:23 EDT
From:      SMANTHANI@ccmail.sunysb.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: VAX6220 network problem
	We have a similar network problem. Our network consists of a
Vax-cluster with a 8350 (2 cpus) and a 8600.  We have over 200 DEC PRO
350s as end nodes distributed across the campus. Students access the
VAX 8350 using Remote terminal software ( similar to SET HOST) on PROs.
Even though, students logout we see multiple links with a zero pid
(00000000) when we give NCP> SHOW KNOWN LINKS command on the VAX.  We
explained the problem to DEC Colorado support center.  So far they have not 
come up with any explanation or solution.  To make the links disapper
we shut down the Decnet on the VAX and bring it up again from time to time.

  
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 13:23:00 GMT
From:      SMANTHANI@CCMAIL.SUNYSB.EDU
To:        comp.protocols.tcp-ip
Subject:   RE: VAX6220 network problem


	We have a similar network problem. Our network consists of a
Vax-cluster with a 8350 (2 cpus) and a 8600.  We have over 200 DEC PRO
350s as end nodes distributed across the campus. Students access the
VAX 8350 using Remote terminal software ( similar to SET HOST) on PROs.
Even though, students logout we see multiple links with a zero pid
(00000000) when we give NCP> SHOW KNOWN LINKS command on the VAX.  We
explained the problem to DEC Colorado support center.  So far they have not 
come up with any explanation or solution.  To make the links disapper
we shut down the Decnet on the VAX and bring it up again from time to time.

  

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 13:47:39 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Unaligned Accesses & Comms.


David:

    This is a belated reply to your note.

    I think that for the near future processor speeds and communications
speeds will roughly keep pace.  Or better said, they won't be so out of
sync that we need to radically revise our current networking models
(both virtual circuit and datagram) even into the gigabit speed realm.
[Note that some folks are talking about supporting new communications
paradigms on very high speed networks -- those new paradigms may require
us to revise our networking models -- I'm simply saying that speed alone
won't].

    On the narrower question of alignment, I think some alignment is
always a win.  Note that I don't care if each field is aligned nicely
on a word boundary -- bit masks can grab out stuff from the middle.
What I do care about is not having fields straddle boundaries.  Having
the high-order byte of a two-byte field in one word and the low-order byte
in another word is a nuisance...

Craig

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 14:40:58 GMT
From:      vance@JVNCF.CSC.ORG (Vercell Vance)
To:        comp.protocols.tcp-ip
Subject:   Please remove me from this mailer

Thanks...Please remove me from this mailing list...Vercell
____________________________________________________________________________

Vercell Vance
Manager, User Services
John von Neumann National Supercomputer Center
Princeton, New Jersey, 08543
Bitnet = vance@jvncc			Internet = vance@jvnca.csc.org
Phone = 609-520-2000
____________________________________________________________________________

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 15:33:33 GMT
From:      bpa!cbmvax!vu-vlsi!lehi3b15!lafcol!ciriello@rutgers.edu  (Patrick Ciriello II)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP requested for ATT 3B systems
In article <1924@muvms1.bitnet>, mcguffey@muvms1.bitnet (Michael McGuffey) writes:

> Each could probably swing funding for an Ethernet card, but commercial
> software is expensive.  Are any "free" TCP/IP implementations available
> for the 3B series of  computers? 

I could also use this info ... please post it to the net, as I am sure
others are in the same boat (it is like a $25,000 upgrade for us!)

Patrick Ciriello II
Supervisor of Networking and Tech. Services
Lafayette College

ciriello@lafayett
ciriello@lafayett.uucp
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 15:37:00 GMT
From:      7thSon@SLCS.SLB.COM (Chris Garrigues)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Subliminal (RFC1097)

We felt that this option would be useful here because we have a number
of users who appear to be unable to remember instructions from one day
to the next, so I was going to implement it.  I first decided that I
should implement WILL RANDOMLY-LOSE (RFC 748), however since it would be
useful to turn this flag on until I got SUBLIMINAL-MESSAGE debugged.

However, I've been having a hell of a time figuring out how to get
either 256 or 257 encoded into a single byte.  Should this be implmented
using the EXTENDED-OPTIONS-LIST of RFC 861?


Chris

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 1989 19:54-EDT
From:      CERF@A.ISI.EDU
To:        hsw@TYCHO.NCSC.MIL
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SIGCOMM '89
Howard,

I have some mailers - can I send you a few? What address?

Vint
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Apr 89 17:37:29 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

In article <15321@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
>As an additional aside, polling is the standard technique used in electronic
>telephone switches. Imagine an interrupt-driven switch when all the phones
>come off-hook simultaneously...

Little birds tell me, actually, that it is not unheard-of for some electronic
phone switches to misbehave badly in this situation...
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 18:52:37 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)

>From: hpfcdc!hpldola!hpctdlb!hpctdkz!jeff@hplabs.hp.com  (Jeff Hughes)
>
>    I am confused. Is RFC1097 a joke or what? If so, no one is laughing.
>I agree with Bob H. completely!

I believe the date of the RFC (91/1989 Julian) should influence 
our thinking on this matter.  Regards - Craig

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 20:17:33 GMT
From:      dtm@MBUNIX.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Use of Precedence in the IP Type of Service field

I'm interested in information regarding the use of Precedence in the IP 
Type of Service field.  The draft Host Requirements document (April 6 ver.)
states the following:

"The Precedence field is intended for Department of Defense applications of
the Internet Protocols, and is outside the scope of this document and the IP
standard specification.  Vendors should consult the Defense Communications
Agency (DCA) for guidance on the IP Precedence field and its implications
for other protocol layers."

I'm not aware of any implementations using Precedence.  Does anyone have
information regarding present or future use of the Precedence field?  Also,
if anyone knows of the appropriate people in DCA to contact, I would
appreciate the information.

Thanx in advance.

David Miller
MITRE Corporation
dtm@mbunix.mitre.org

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 23:24:19 GMT
From:      geoff@eve.oz (Geoff Cawte)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans,comp.sources.wanted
Subject:   Driver for 3Com 3C503 Etherlink II card

Fellow Underlings,
		  Recently I acquired the NCSA TCP/IP software for PCs from the
public domain on the net. However, in keeping with true Murphian law, it 
contained hardware drivers for almost every card except the 3Com 3C503 cards 
which we are using with our existing PC-NFS software. Since we are in the 
process of writng an applications system using a LAN, we are keen to use the 
pd software as a starting point for a customised system, and knowing diddly-
squat about the internals of the 3C503 we really need source for a driver for 
the said card. The alternative is spending mega-bucks on a proprietry product
with development kit... Can anybody in NETland help??

Thanks muchly,
		Geoff 

Geoff Cawte, 
Megadata (Could be worse...could be "Awesome-data") pty. ltd.
2/37 Waterloo Rd.
Nth Ryde
Sydney
NSW 2113
Australia

(02) 805-0899 x202

geoff@eve.mega.oz

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 89 23:54:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: SIGCOMM '89

Howard,

I have some mailers - can I send you a few? What address?

Vint

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 00:09:07 GMT
From:      munnari!uqcspe!bunyip!brolga!ggm@uunet.uu.net  (George Michaelson)
To:        tcp-ip@sri-nic.arpa
Subject:   PC router & security.
The stuff about IP security and PC routers lay one after the other
in my news list. -Thus posing in my mind a question:

	how do you tell the difference between a damn slow PC router
	and some homebrew box which sees *every packet* on the net
	and dumps grep "ogin:.*\nPassword:.*" matches to some file?

If you're paranoid about ether security you better not try and save
money on the hardware!

George

-- 
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 00:34:55 GMT
From:      sollins@DILL.LCS.MIT.EDU (Karen R. Sollins)
To:        comp.protocols.tcp-ip
Subject:   ECMA "Security in Open Systems..."

I have moved the files from England to a publicly accessible file
server here in the US.  They are available via anonymous ftp from
allspice.lcs.mit.edu and are in pub/ecma-desd.  They are, as before:

   5253120 Apr 12 18:04 desdlj.tar
   1816056 Apr 13 11:33 desdlj.tar.Z
   1505280 Apr 13 11:33 desdps.tar
    569425 Apr 13 11:36 desdps.tar.Z

For people without a4 printing capabilities, note tha you may lose
the page numbering when printing on 8 1/2 x 11" paper.
			Karen Sollins

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 01:49:58 GMT
From:      mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   draft TELNET Option RFC from Dan Bernstein

Although this RFC is well-intentioned, I am opposed to several of its
principles on the grounds that many (most?) implementors of TELNET clients or
servers will not go to the level of detail specified by this RFC to get
correct behavior.  This level of detail is perhaps necessary for the more
complex TELNET options, but for the most important ones - binary, echo, and
suppress-GA - a simpler implementation model will suffice.

This simpler model does violate several of the rules of the draft RFC.
However, the "violations", for the most part, take the form of timing races in
which the "correct" behavior often produces results that are not necessarily
superior.  The model does, however, prevent the endless protocol loop.

In this model, you send a negotiation *only* when the state of an option
changes at your end.  In other words, you send a negotiation to notify the
other end of your new state.  Your new state is set either by your own action
(the user gives a command to change binary mode, or an initial flurry of
DO/WILL negotiations you set when you open a connection, etc.) or because you
received a change of state from the other end.

You are permitted to reject a state change to ON (WILL/DO) by sending the
corresponding (DONT/WONT).  You are forbidden from rejecting a state change to
OFF (WONT/DONT) although at a later time, as the result of some human action,
you may try changing the state to ON again if you want.

The previous principle means that you can only inflict your "desired state" on
the other end when the connection starts up.  You must implement the state
where no TELNET options are enabled and not try to change out of it *except*
at initial startup.

Technically, this model violates TELNET and certainly violates the draft RFC.
However, there is no way the other end can determine this (except, of course,
for the more esoteric TELNET options which have subsequent subnegotiations),
and it is better to have a simple TELNET that doesn't loop than a possibly
broken complex TELNET.

-- Mark --

-------

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 05:23:51 GMT
From:      jom@belltec.UUCP (Jerry Merlaine)
To:        comp.protocols.tcp-ip
Subject:   RFC 822 mail format - yacc parser

Hello Friends,

Has there ever been composed and placed in the public domain an RFC 822
mail format yacc parser?  My idea is that instead of sendmail you would
just have an 822 yacc program that rewrites messages by consulting the
mail records supplied by your friendly local BIND server, and then hands
the result to the Honey/Collier/MIT SMTP stuff, thus giving you SMTP mail 
service with the fewest lines of code.  Is this totally wacko?

Thank you,

Jerry O. Merlaine
pacbell.com!belltec!jom

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 08:00:30 GMT
From:      sylvain@roxy.chorus.fr (Sylvain Langlois)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat,comp.lang.postscript,comp.windows.news
Subject:   Re: TCP/IP versus OSI

In "TCP/IP versus OSI" (<1042@nixctc.DE>), pete@relay.nixctc.de (Pete
Delaney) writes: 

>[..]. Also, it might be nice to hear why 
>arpnet is migrating to OSI;
Arpanet has to move to *real* international standards someday, even if
the protocol suite it uses today has shown it was far more superior to
the currently available implementations. Bringing OSI implementations
up to TCP/IP and known applications today's quality is, to my own
advice, a question of time. People working on the ISODE (Marshall
Rose, Steve Kille and co.) are doing a wonderful job in this way. Once
4.4BSD OSI support will be available, I guess people will be more
motivated than they are today. 

>[...] do the arpa developers really like ASN1
>more than postscript? 
PostScript has nothing to do here.

> Can't we just assume like Joachim points out
>that the connection above transport is reliable
The problem seems to me that reliability has different meannings,
depanding on the context the Transport Service is used.


Sylvain


----------------
Sylvain Langlois		  "Dogmatic attachement to the supposed merits
(sylvain@chorus.fr)		   of a particular structure hinders the search
(sylvain%chorus.fr%uunet.uu.net)   of an appropriate structure" (Robert Fripp)

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 08:09:39 GMT
From:      rhc%rcole@HPLABS.HP.COM (Robert Cole)
To:        comp.protocols.tcp-ip
Subject:   Draft Standard for Security

A new draft ECMA standard for Security in Open and Distributed systems
is available for FTP. This draft standard addresses the problems of 
security standardisation in applications intended for OSI or ODP
environments. Comments are requested on this draft for inclusion in
the final version.

Please forward this message to any other groups or individuals who
may be interested in this work.

The text may be obtained by anonymous FTP from rcole.hpl.hp.com
(15.255.61.89) which is in the UK, or from allspice.lcs.mit.edu in the
directory ~/pub/ecma-desd, as a tar file containing print files for
the individual chapters. Two print file formats are offered:
desdps - contains the PostScript version
desdlj - contains print files for the HP-Laserjet+ (or better).
Compressed versions are also available to ease the transfer problem.
So the file choices (and sizes) are:
5253120 Apr  5 13:50 desdlj.tar
1816056 Apr  5 15:34 desdlj.tar.Z
1505280 Apr  5 11:00 desdps.tar
 569425 Apr  5 11:12 desdps.tar.Z
Note that the document contains pictures as well as text so it is not
possible to send the text directly by e-mail.

Please note that the document was designed for, and will evenatually be
published on, A4 paper. If you must print it on AQ size then you may
lose the page numbers. 

Robert

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Apr 89 13:24:36 EDT
From:      Margaret Alexander <alexand@ccw.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        alexand@ccw.bbn.com
Subject:   please remove me from this mailing list

thank you.

margaret alexander
bbn

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      20 APR 89 11:40:02:00 GMT
From:      FUSION <FUSION@uhhepg.phys.hawaii.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Subnet routing using Fusion TCP/IP software
We have a problem with routing using Network Research Corp. Fusion
TCP/IP software for our VAX computer operating on VMS.
We are DEC local area cluster with a vaxstation 3600 and a vax 780.
The 3600 is our router/gateway to our campus ethernet network using
primarily TCP/IP protocol and almost all the computers are running
unix. The 3600 is also connected to our vax 780 to form a subnet.
We are class B network address.
The problem we have is the rest of the campus network do not know
about our subnet running Fusion TCP/IP software. Fusion does not
support RIP as yet. Fusion software allows designating a gateway/router
on our network to be our router (information like go to the 3600 to
get to our subnet) and also the capability for our 3600 to have
subnet proxy and proxy arb to let the network know that one can get
to our subnet through our 3600. However, when our network administrators
enter into the unix software routing table...
	"route add subnetaddrIP vax3600IP 1
This command will just sits there....is it doing RIP and our software
do not support RIP and therefore it keeps trying?
Anyhow, it will not accept this static routing entry....because it
does not get some reply I think. I tried pinging into the subnet with
subnet proxy arb on the 3600 turn on and cannot get through.
Fusion stated the set up for their software is okay. 
Is there any users our there that have Fusion software running on
VAX computers and routing out/in as subnet into the unix computers
software world. Please phone or electronic mail me if anyone has
some wisdom on this.
Phone: 808 948-8326 (Harry)
 




-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 12:33:49 GMT
From:      dtm@MBUNIX.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   (Commercial) IP Security Option

The following is an excerpt from the February IAB Report:
  
IAB REPORT -- February 1, 1989

D. IP Security Option

   A vendor requested an IP Option for commercial security, where the
   contents of this option would be unstandardized and vendor-specific.
   The IAB felt strongly that IP options must be publically defined and
   documented, while that proprietary or privately-structured options 
   are a bad idea.  The IAB will initiate a broad-based effort to
   define a (commercial) security option for IP.  Interested parties 
   may contact Steve Kent (Kent@BBN.COM  (617) 873 3988).   
   
How is this option related to the Revised IP Security Option defined in
RFC 1038?  Is this intended to be a completely new option with a different
option number or is the intent to define additional security classifications
to meet the needs of the commercial world within the RFC 1038 format?

David Miller
MITRE Corporation
dtm@mbunix.mitre.org

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 16:55:56 GMT
From:      spdcc!eli@bloom-beacon.mit.edu  (Steve Elias)
To:        tcp-ip@sri-nic.arpa
Subject:   smtp problem:  remote protocol error: bad file number
if anyone has any idea as to what i could do to fix the above error, 
i'd love to hear it...  our site, chipcom.com, is unable to originate
messages to certain internet nodes.  we communicate fine with all
the ".edu" and most ".com" sites, but some ".com" and most ".arpa" 
sites are unreachable.  all mail sent to them is returned with 
smtp error 554: remote protocol error: bad file number.

we are registered with uunet and seismo, our forwarder node
is spdcc.com.  i'm very confused by this problem.  the only thing
i can think of is to change the name of our mailserver from 'chipcom.com'
to 'chipcom.chipcom.com'.  i wonder if the problem is at our site, 
though.  it seems like some machine out there is causing the protocol
error because it is confused by 'chipcom.com'.  as you can tell, i'm
rather confused myself.  thanks in advance for any help...  

-- 
   Steve Elias (eli@spdcc.com);(6172399406)
     "Space is small.  The planets are big." -- Heinlein
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 17:19:13 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@sri-nic.arpa
Subject:   NIC-SERVICE
>       Where can I get a copy of RFC1097?  I've been reading the discussions,

	Maybe it's time to talk about RFCs by mail again.  I've seen
several postings like this lately.  Hope this saves some wear and
tear.

	You can get lots of information (and overload a poor computer)
by electronic mail from the SRI Network Information Center.  Send mail
addressed to:
	service@sri-nic.arpa

with keywords in the Subject: line to request files:

	RFC INDEX	to request the index list (save it and grep it)
	RFC nnnn	request a particular RFC
	HELP		to get info on how to use service@sri-nic.arpa

and many others.

	Now is probably not the best time to be posting this.  sri-nic
is reachable only via arpanet and milnet at this time and connectivity
between those nets and the rest of the Internet is "strained".  But
perhaps service will migrate somewhere else or show up somewhere else
and use the same syntax.  The concept is certainly excellent.

	So, don't flood sri-nic with too many requests all at once (is
it conceited of me to assume that anyone is paying attention to my
postings :-) and don't request everything at once.  Start with HELP or
RFC INDEX.

	What we have done at BU is get all the RFCs on-line in one
place for everybody.  That way, only one ftp or "service call" from one
site.  This is highly recommended to save sri-nic load.

	Enjoy.  (And say a silent thanks for all those who toil at
sri-nic for the benefit of everyone.)
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 17:24:36 GMT
From:      alexand@CCW.BBN.COM (Margaret Alexander)
To:        comp.protocols.tcp-ip
Subject:   please remove me from this mailing list


thank you.

margaret alexander
bbn

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 17:46:04 GMT
From:      ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal



To anyone who's still unsure about whether this is a joke:  just try to
implement it.  Upon careful reading of RFC 1097, you'll see the following:

        1.  Command name and code.

             SUBLIMINAL-MESSAGE 257



Good luck,

Walt Wimer

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 18:33:13 GMT
From:      SOL@SRI-NIC.ARPA (Sol Lederman)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help

Pete,

To get an RFC by electronic mail from the NIC send a message to 
SERVICE@SRI-NIC.ARPA with the words  RFC 1097   in the subject line.

Sol/NIC
-------

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 18:40:16 GMT
From:      allosaur.cis.ohio-state.edu!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: NIC-SERVICE
In article <29914@bu-cs.BU.EDU> kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:

   >Where can I get a copy of RFC1097?

   Maybe it's time to talk about RFCs by mail again.  I've seen
   several postings like this lately.  Hope this saves some wear and
   tear.

Maybe it's time to talk about RFCs by UUCP again.  Hope this saves
some wear and tear on the mail links between you and the NIC -
particularly the ones that someone else pays for.

You can get the RFCs (and lots of other stuff) via anonymous UUCP from
osu-cis, the only catch being that you pay for the call to Columbus,
Ohio.  Write me for directions if you need them.
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 89 19:15:00 GMT
From:      N39@applelink.apple.com
To:        comp.protocols.tcp-ip
Subject:   Help on Sun routing

Help!

I am sending this message on the advice of Chris Vandenberg from ACC
(chris@SALT.ACC.COM).  He says somewhere someone will have the answer.  I hope
so.  We (Deere) don't have our DDN connection yet.  Consequently I'm sending
this from my AppleLink mail address on Apple's 4381 through a mail gateway to
the Internet.  (Hey, what-ever works!)  Replies can be sent to Doug Foster,
Deere & Company (n39@applink.apple.com).  See below.

The problem:

We have an IBM 3090 running MVS and ACC's ACCES/MVS product (v2.1.1).  I am
building a Deere wide-area internet.  Because of design considerations, we are
implementing some short term solutions (they always start out short term don't
they?).  Anyway, the 3090 (192.43.1.1) is using a Sun 3/140 (192.43.1.3) disked
machine to gateway for him.  The Sun is running Sun OS 4.0.1, pretty much
generic kernal.  The Sun has routes to networks 192.43.3, 192.43.4, 192.43.13,
etc..  These routes were added with the "route" command & set at 0 hops, since
the different logical nets lay on the same physical net.  Problem is ACCES/MVS
arp request/replies are OK, forwards to the Sun gateway are OK, but the Sun
will not route!  The Sun has one interface (remember multiple logical nets on
the same physical net), has IPFORWARD on in /usr/sys/netinet/ip_var.h.  I even
tried the "adb -w /vmunix;ipforward? w 1; cntrl d" business, no diff.  If I
switch to a stock Sun 3/160 running Sun OS 3.4, it works!  What's the diff?  I
need to get this resolved pronto.  Managers & time schedules, you know. Any
help????

Thanks,

Doug Foster
Deere Tech Services
Deere & Company
John Deere Rd.
Moline, Ill.  61265
309-765-5180
return mail: n39@applink.apple.com





=END=

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Apr 89 14:13:42 EDT
From:      Steve Kent <kent@BBN.COM>
To:        tcp-ip@sri-nic.ARPA
Cc:        dtm@mbunix.mitre.org, braden@venera.isi.edu
Subject:   IP security option workshop
The April Internet Monthly Report reported plans for a workshop top
address "an IP option for commercial security."  The goal of the 
workshop is to explore issues associated with the creation of a new
IP option which would address security concerns that arise in the
commercial (vs. DoD) community. For example,the current RIPSO is not
designed to accommodate sensitivity labels for a variety of non-
government organizations, nor is there an infrastructure established
to register such labels and associated policies (ala' ISO/CCITT
resgitration).  We may not come away from the workshop with a new
option format and all the attendant documentation, but we do hope
to explore requirements,anticipated usage patterns,formats, etc.

	The workshop is being "sponsored" by the IAB and by NIST.
It is an invitation only gathering with a requirement that prospective
participants prepare and sumbit (in advance) material for presentation
during the workshop.  Thus there will be no attendees who are not also
presenters. 

	I hope this asnwers the questions raised by Dave Miller's message
earlier this week.

Steve Kent
Chair,
IAB Task Force on Privacy and Security
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1989 1700-EST
From:      hsw@TYCHO.NCSC.MIL  (Howard Weiss)
To:        tcp-ip at nic.ddn.mil
Subject:   sigcomm
Forwarded message comment:
----------
As per Larry Landweber's request, I am forwarding this back out onto
the tcp-ip list
----------

Return-Path: <lhl@cs.wisc.edu>
Received: FROM parmesan.cs.wisc.edu BY TYCHO.NCSC.MIL ; 21 APR 89 21:13:50 UT
Date: Fri, 21 Apr 89 15:12:11 -0500
From: lhl@cs.wisc.edu (L.H. Landweber)
Message-Id: <8904212012.AA21018@parmesan.cs.wisc.edu>
Received: by parmesan.cs.wisc.edu; Fri, 21 Apr 89 15:12:11 -0500
To: hsw@tycho.ncsc.mil
Subject: sigcomm
Cc: lhl@cs.wisc.edu

The SIGCOMM '89 program committee is currently 
evaluating papers. In about a month, we should 
know the program's contents. Similarly, the tutorials 
have not yet been completely determined. 

As far as costs are concerned, my understanding is that
the hotel will be very reasonable. It would be best
to write to Mohamed Gouda, local arrangements chair
for details (gouda@cs.utexas.edu).

I will send more info as soon as it is available.

Regards
Larry Landweber
PS: Please distribute on the mailing list to which
you sent your original request.
-------

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 23:15:00 PST
From:      lars@sage.acc.com
To:        "n39" <n39@applelink.apple.com>
Cc:        "tcp-ip" <tcp-ip@SRI-NIC.ARPA>, "chris" <chris@salt.ACC.COM>, "lars" <lars@salt.ACC.COM>
Subject:   Help on Sun routing
> Date: 20 Apr 89 12:15:00 PDT
> From: N39@applelink.apple.com
> 	(Doug Foster, John Deere & Co)
> Subject: Help on Sun routing
> 
> [Our IBM] 3090 (192.43.1.1) [running ACES/MVS] is using a Sun 3/140
> (192.43.1.3) disked machine to gateway for him.
> The Sun is running Sun OS 4.0.1, pretty much generic kernal.
> The Sun has routes to networks 192.43.3, 192.43.4, 192.43.13, etc..
> These routes were added with the "route" command & set at 0 hops, since
> the different logical nets lay on the same physical net.
> Problem is ACCES/MVS arp request/replies are OK, forwards to the Sun
> gateway are OK, but the Sun will not route!  
> The Sun has one interface (remember multiple logical nets on
> the same physical net), has IPFORWARD on in /usr/sys/netinet/ip_var.h.
> ... If I switch to a stock Sun 3/160 running Sun OS 3.4, it works!
> What's the diff?

When I read this, my first thought was: This should work, I've seen it
work, but then: So have you !! The difference is that SunOS 4 has newer
TCP/IP routing code, which (I think) refuses to send a packet out on
the same interface it came in on.

There are 3 ways out of this:
(1) Take the check out of the source code (no sources ? sorry!)
(2) Add a second ethercard connected to the same cable
(3) Use SunOS 3

Have fun !

/ Lars Poulsen
  ACC Customer Service

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 16:38:39 GMT
From:      FUSION@UHHEPG.PHYS.HAWAII.EDU (FUSION)
To:        comp.protocols.tcp-ip
Subject:   Subnet routing using Fusion TCP/IP software

We have a problem with routing using Network Research Corp. Fusion
TCP/IP software for our VAX computer operating on VMS.
We are DEC local area cluster with a vaxstation 3600 and a vax 780.
The 3600 is our router/gateway to our campus ethernet network using
primarily TCP/IP protocol and almost all the computers are running
unix. The 3600 is also connected to our vax 780 to form a subnet.
We are class B network address.
The problem we have is the rest of the campus network do not know
about our subnet running Fusion TCP/IP software. Fusion does not
support RIP as yet. Fusion software allows designating a gateway/router
on our network to be our router (information like go to the 3600 to
get to our subnet) and also the capability for our 3600 to have
subnet proxy and proxy arb to let the network know that one can get
to our subnet through our 3600. However, when our network administrators
enter into the unix software routing table...
	"route add subnetaddrIP vax3600IP 1
This command will just sits there....is it doing RIP and our software
do not support RIP and therefore it keeps trying?
Anyhow, it will not accept this static routing entry....because it
does not get some reply I think. I tried pinging into the subnet with
subnet proxy arb on the 3600 turn on and cannot get through.
Fusion stated the set up for their software is okay. 
Is there any users our there that have Fusion software running on
VAX computers and routing out/in as subnet into the unix computers
software world. Please phone or electronic mail me if anyone has
some wisdom on this.
Phone: 808 948-8326 (Harry)
 

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 16:38:57 GMT
From:      sadler@heurikon.UUCP (Jon Sadler)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP requested for ATT 3B systems

TCP/IP software is available for the 3B2 and 3B15 from AT&T.  This package
was developed by The Wollengong Group, and is an enhanced 4.2BSD style
implementation (eg. sockets, no subnets, TLI support).  It does include
the Berkeley utilities (rsh, rlogin, rcp, sendmail) and routed support.

This package is available through AT&T's University Grant program, and
University discounts are also possible.  Contact your local AT&T rep. for
more information on this package, educational discounts, and grant programs.

If you have any specific questions on the implementation, feel free to
contact me.

Jonathan Sadler

-- 
BANG PATH:      ...rutgers!uwvax!heurikon!sadler   SNAIL: Jonathan Sadler
                ...rutgers!nucsrl!laidbak!sadler          Heurikon Corp.
UUCP DOMAIN:    sadler@heurikon.UUCP                      3201 Latham Drive
                sadler@laidbak.UUCP                       Madison, WI 53713
ARPA:           sadler@csd4.milw.wisc.edu          PHONE: (608) 271-8700

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 16:50:57 GMT
From:      cfe+@andrew.cmu.edu (Craig F. Everhart)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: smtp problem: remote protocol error: bad file number

You're seeing a misleading error message.  ``bad file number'' is a
representation of what was left in errno (EBADF) after an SMTP connection went
south; the connection is closed, but sendmail doesn't know it, so it does a
``close()'' anyway, leaving bad stuff in the global variable ``errno''.  An
ostensible fix for this was posted to comp.mail.sendmail about a month ago,
involving saving and restoring the errno value across a pair of close()
operations.

Unfortunately, that errno-clobber is masking the original errno value, which is
doubtless something like ETIMEDOUT or ECONNREFUSED.  Too bad your error-handler
is interpreting the EBADF as a permanent/persistent error rather than a
transient one.

Once you find out what the network problem is, you'll have to deal with your
network/gateway support to find out why you can't get to some hosts.

                Craig

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 18:13:42 GMT
From:      kent@BBN.COM (Steve Kent)
To:        comp.protocols.tcp-ip
Subject:   IP security option workshop

The April Internet Monthly Report reported plans for a workshop top
address "an IP option for commercial security."  The goal of the 
workshop is to explore issues associated with the creation of a new
IP option which would address security concerns that arise in the
commercial (vs. DoD) community. For example,the current RIPSO is not
designed to accommodate sensitivity labels for a variety of non-
government organizations, nor is there an infrastructure established
to register such labels and associated policies (ala' ISO/CCITT
resgitration).  We may not come away from the workshop with a new
option format and all the attendant documentation, but we do hope
to explore requirements,anticipated usage patterns,formats, etc.

	The workshop is being "sponsored" by the IAB and by NIST.
It is an invitation only gathering with a requirement that prospective
participants prepare and sumbit (in advance) material for presentation
during the workshop.  Thus there will be no attendees who are not also
presenters. 

	I hope this asnwers the questions raised by Dave Miller's message
earlier this week.

Steve Kent
Chair,
IAB Task Force on Privacy and Security

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 22:00:00 GMT
From:      hsw@TYCHO.NCSC.MIL (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   sigcomm

Forwarded message comment:
----------
As per Larry Landweber's request, I am forwarding this back out onto
the tcp-ip list
----------

Return-Path: <lhl@cs.wisc.edu>
Received: FROM parmesan.cs.wisc.edu BY TYCHO.NCSC.MIL ; 21 APR 89 21:13:50 UT
Date: Fri, 21 Apr 89 15:12:11 -0500
From: lhl@cs.wisc.edu (L.H. Landweber)
Message-Id: <8904212012.AA21018@parmesan.cs.wisc.edu>
Received: by parmesan.cs.wisc.edu; Fri, 21 Apr 89 15:12:11 -0500
To: hsw@tycho.ncsc.mil
Subject: sigcomm
Cc: lhl@cs.wisc.edu

The SIGCOMM '89 program committee is currently 
evaluating papers. In about a month, we should 
know the program's contents. Similarly, the tutorials 
have not yet been completely determined. 

As far as costs are concerned, my understanding is that
the hotel will be very reasonable. It would be best
to write to Mohamed Gouda, local arrangements chair
for details (gouda@cs.utexas.edu).

I will send more info as soon as it is available.

Regards
Larry Landweber
PS: Please distribute on the mailing list to which
you sent your original request.
-------

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 22:31:17 GMT
From:      stevea@laidbak.UUCP (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for RT-11 and/or TSX+?

In article <13518.608920870@UK.AC.UCL.CS> J.Pearson@CS.UCL.AC.UK (James Pearson) writes:
>Does anyone know of a TCP/IP implementation for a MicroPDP 11/73
>running RT-11 and/or TSX+?
>

I believe that there is a company called Process Software that has
TELNET and FTP for RT-11 and TSX, as well as a product that allows users to
write TCP/IP applications.  Their address is:

	Process Software Corporation
	35 Montague Road
	PO Box 746
	Amherst, Massachusetts, 01004, USA
	+1 413 549 6994
	FAX +1 413 549 5273
	TELEX 517891

Hope this helps.

-- 
Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com
Lachman Associates, Inc.            | ...!sun!laidbak!stevea

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 89 22:41:32 GMT
From:      sean@geac.UUCP (Sean Phelan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP terminal access to GEAC computers anyone?

There have been a couple of messages about Geac's old-style polled,
async terminals, with some ( very valid ) criticism of their inability
to interroperate with TCP-IP lans. 
 
smart@ditmela.oz.au (Robert Smart) writes :
 
> GEACs are computers made in Canada and sold mainly (?) for library 
> automation. They have an X.25 capability, but I'm not sure what 
> protocol they speak over that to their terminal concentrator things 
> called NIMs. They allow direct connection of async terminals so it
> should be easy to get into them with a terminal server, right?
> Wrong.
> ......
> Then again they're expensive (understatement) so we would also be
> interested in a solution that emulates them on VT100s or similar.
>  
>  
 
SHERWOOD@AC.DAL.CA (John Sherwood) replies :
 
> Our GEAC allows the asynch terminals to be configured as GLASS-TTY
> instead of the multi-dropped polling type. This means you can connect
> a single, dumb ASCII terminal to the GEAC port. Makes for an easy
> connection to the terminal server, right?
>  
> Wrong. They neglect such frills as flow control and connection control.
>  ......
> All this applies to the older 8000 series machines. Our 9000 is in and
> running, but I haven't had a chance to see if things have improved. If
> anyone has a better way of doing things, would we ever like to hear it!
>  
 
Yes, there sure is a better way of doing things !!  Let me put things in
context by explaining a bit more about our old-style polling protocol,
and then I'll describe how we now support VT100/VT220 terminals.
 
The reason we used to build our own terminals was that libraries require
more than the standard 96 character ASCII character set.  North America
uses the ~160 character ALA ( American Libraries Association ) set, and
most of the rest of the world uses the 190 character ISO set.  We also
put bar-wand decoding hardware and software in the terminal, which meant
that a terminal just needed a $200 wand, and no $500 decoder box, in 
order to read bar-codes.
 
We used the ANSI X3.28 polling protocol because it allowed cheap, easy
cabling, and enabled several terminals in a library branch to share one
leased line back to the host. 
 
So, Geac terminals were a smart idea 5 or 6 years ago, even cheap by the
standards of the day.  However now their time has passed, for two main
reasons :
 
  - far too expensive ( for us to make, and hence for libraries to buy )
 
  - polling and lans don't mix !!
 
The first point needs little explanation - companies like Wyse have over
120 times the terminal manufacturing volume that Geac had.  Wyse has
factories in the far east, our factory is in Toronto.
 
Clearly, passing async polls across a LAN is horrendous.  Some people
do it, but we don't recommend it.  
 
So we've replaced the polled, Geac-built terminals with two alternatives :
Support of VT100/VT220 terminals, and a terminal emulation for a PC.
 
VT100/VT220 compatible terminals are supported through a small 8 port
cluster controller called the Geac 8212.  Either connect the terminals
directly or via a LAN and terminal servers.  Flow control ( X-on X-off)
and connection control are optimised for use over LANs, radio-modems
etc.
 
        up to 8                       .--------.
        terminals                     |  Geac  |
                    .--------.        |  host  |
          VT220 ----|        |        |        |
          VT220 ----|  8212  |--------|        |      
          VT100 ----|        |        |        | 
                    `--------'        `--------'
     
 
VT100/VT220 terminals won't display the full ALA or ISO character sets,
but we use the DEC Multinational Charcter Set to get many of the common
ones.  Bar wands are done with an add-on decoder box.
 
For the full ALA or ISO character sets, we offer a terminal emulation on
the PC.  There's also an optional PC board for doing the bar-wand decoding. 
 
I'm beginning to sound like a salesman now, so I'll stop here.  For more
information call your Geac account rep, who has no inhibitions about
sounding like a salesman.
 
If the terminals on your LAN are vt100/vt220 compatible, I would STRONGLY
recommend using the 8212 solution rather than the dumb async terminal
approach - you get a nice, user-friendly full-screen mode instead of
the scrolling dumb terminal, and the per-port cost is the same or lower
than buying port boards for the host ( at least, it was last time I
looked - I'm a programmer, not a salesman. )  If you find ANYTHING
unsatisfactory about the way this configuration works, bug your account
rep about it, or mail or call me.  Since LAN connectivity was one of
the main reasons for introducing this product, we'd like to see it 
work as well as possible.
 
Your reaction to this may be "but that's not REAL lan connectivity -
I want the Geac host to connect direct to the Ethernet, without going
through terminal servers !!"   We decided to start with the async
approach, because most of our sites only want a few simultaneous
connections - one 8212 with 8 ports is almost always sufficient - and
this approach is much cheaper for the library than a direct Ethernet
connection.  We are working on a direct connection for future sites that
will use Ethernet for all the terminals - perhaps 100 simultaneous
connections.  Sorry, I can't give a release date. 
 
 
If you are trying to connect a Geac library system to your LAN, or to
anything else, please feel free to mail me questions or comments.  It
would help me, though, if you tell me the name of your Geac account rep.
 
-- 
Sean Phelan                                   | "Education furnishes the mind,
Geac Computer, Markham, Ontario               |  making it a pleasant place to
sean@geac                                     |  spend the rest of one's life"
{uunet!mnetor,yunexus,unicus,utgpu}!geac!sean |

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 89 00:16:30 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Use of Precedence in the IP Type of Service field

David,

So far as I know, the only IP implementation to use the precedence
field in the forwarding function is the Fuzzzball, which led a brief
but flashy life as the switching engine in the NSFNET Phase-I backbone
network prior to July 1988. These gizmos used the precedence field
as a priority indicator in a conventional FB(n) queue service discipline.
However, and this has not been widely known, if the precedence field
was zero, which is what almost all implmentations (except the Fuzzball)
used, the priority indicator was taken as the type-of-service bits read
as a three-bit number. If even those bits were zero and either the
source or destination TCP port field was 23 (TELNET), then the priority
indicator was assumed as one. 

You will note that (a) if the precedence/TOS field was zero, TELNET
won; (b) if the delay or throughput bits were set, they won over (a);
(c) if a nonzero precedence was set, they won over (b); and (c)
Fuzzballs themselves used a precedence field of all ones, so they
always won. Oh yes, TELNET usually won, but FTP usually lost. All this
in the bad old days of horrendous congestion when desperate men were
driven to desparate measures. Surely these crimes of history will never
haunt us again, at least for the next month or two.

Further culpa of mea can be found in my papers in the SIGCOMM 87 and
SIGCOMM 88 proceedings. I surely would not admit that above nonsense
in a rag like that. And, oh yes, the Fuzzballs are still around. Have
you read your clock lately?

Dave

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 89 13:48:09 GMT
From:      merdian@kssun1.rus.uni-stuttgart.dbp.DE (Peter Merdian)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for VMS

Hello,

I am looking for information about TCP/IP for VMS.

We have VAX 8810, 8300, MVAX-II and use currently WIN TCP/IP from Wollongong.
What experiences do you have with TCP/IP for VMS, for example from Fusion or
CMU. I am particularely interested in your experiences with those products 
concering the use of nameserver and subnetting (we have a class B net with 
3 byte subnetting).

Thanks for any help,
--- Peter

Computing Center
University of Stuttgart
e-mail: merdian@rus.uni-stuttgart.de
        zrau at ds0rus1i.bitnet

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 89 19:07:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   How much ISDN is out there?


  I know this isn't 100% germaine to the TCP-IP group, but I figure there
ought to be enough network experts reading to get a reasonable answer:

	How many homes/offices could I walk into tomorrow and see ISDN
	equipment?

  I'm just curious -- since I read about broadband ISDN in IEEE Communications
magazine, but couldn't get Illinois Bell to put a T1-rate ISDN line into
my home for all the rice in China (or for any other sum of money/form of
remuneration). It seems like ISDN is a great idea that's on the way -- but
(as far as I can gather) _still_ on the way.


-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 89 19:25:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP vs. OSI facts wanted

I need some *facts and figures* (not perceptions) concerning the
current use of TCP/IP vs. OSI to either refute or support the claim
that OSI is *rapidly* replacing TCP/IP in the US and worldwide.

Mail your replies directly to me and I *will* summarize.

--Frank

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 02:18:21 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Traceroute....

Does anyone have ``traceroute" running on a Sun-4 running SunOS4.0? I can't
seem to get it to work even after having made the necessary kernel mods.

						Aloha, Torben

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 03:44:06 GMT
From:      ingoldsb@ctycal.COM (Terry Ingoldsby)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts




Other people have offered their ideas on how to secure a network (whether it
is TCP-IP, DECNet or XNS is unimportant).  Here is my idea.  Shoot it down if
you can think of a good way to break it:

  This is derived on something I read in BYTE some time ago.  I don
remember what issue.

  Each authorized node has a file of a reasonably large size, say 100K,
filled with random numbers.  Make them really unpredictable (they don't
necessarily have to satisfy any particular distribution).  Protect both
files, so only privileged processes can read them (if you can't
trust superusers, your security is shot anyway).  Each side of the
connection gets to ask the other side 3 questions.  The questions are
of the form:
   What number is at position 32156?
   The number at position 2154 is 3261.  True or False.
It is unpredictable what the indices of the questions will be, so just
listening to one session won't give you the answers you need for the
next session.  The second type of the question is particularly good,
since if the answer is false, the eavesdropper still doesn't know what
the value at position 2154 is.

Each side gets a chance to decide if the other side is authentic.  Once
authentication has been established, the initiator suggests that both
sides use the D.E.S. (Data Encryption Standard) key found at index ###.
From that point on, all communication is DES encrypted.  There are
cheap chips to do that for you, so the overhead needn't be high.

Periodically, change the file at all nodes.  If anyone is eavesdropping,
they won't have sufficient sessions to observe to deduce the contents
of the mystery file.

Is that secure enough?

                                   Terry Ingoldsby
                                   Land Related Information Systems
                                   The City of Calgary

                                   ctycal!ingoldsb@calgary.UUCP
                                            or
                       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 13:32:27 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   dialup SLIP (again)

It has been suggested (including on this forum) that one could use
dialup SLIP to create backup paths in leased-line wans.  If an
intermediate router in my regional network went down, I could just
automatically call past it and temporarily use a SLIP connection while
the primary was being restored.

Is anybody (besides me) actually experimenting with this use of dialup 
SLIP?  

Has anybody given any thought to how to handle routing in such an
environment?  There seem to be two possible models:
   (1)	The CSnet "dial on demand", in which the SLIP route is
	claimed to exist all the time, but is only active while traffic
	is present.  This has the disadvantage that you can't employ a
	routing protocol like RIP that depends on routinely sending
	reachability data across the link.  CSnet, I gather, uses
	only static routes.
   (2)	Create and advertise a route when needed.  This requires that
	network management software notice that the primary route is
	gone and initiate a connection.  Since network management has
	noticed the loss of connectivity, presumably user applications
	have too.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 14:51:43 GMT
From:      skl@van-bc.UUCP (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   talk(1)'s Protocol Description

Could someone please point me to the protocol description of talk(1) on
on the SUN?  About all I know about it is that there are two incompatible
versions (for different versions of SunOS) and they use UDP port 517/518
to establish a connection and then change over to use a TCP connection to
support the conversation.

Thanks in advance for your help.

...Sam
-- 
Samuel Lam     {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 16:26:00 GMT
From:      jeffery@jsheese.FIDONET.ORG (Jeff Sheese)
To:        comp.protocols.tcp-ip
Subject:   dialup SLIP (again)

In an article of <23 Apr 89 13:32:27 GMT>, jqj@HOGG.CC.UOREGON.EDU writes:

 >It has been suggested (including on this forum) that one could use
 >dialup SLIP to create backup paths in leased-line wans.  If an
 >intermediate router in my regional network went down, I could just
 >automatically call past it and temporarily use a SLIP connection while
 >the primary was being restored.
 >
 >Is anybody (besides me) actually experimenting with this use of dialup 
 >SLIP?  

Contact mju@m-net.UUCP.  He and several others have modified the source
for KA9Q software to use dialup SLIP with the Merit network in Ann
Arbor and Detroit Michigan.
--  
Jeff Sheese - via FidoNet node 1:109/116
UUCP: ...!netsys!jsheese!jeffery

(Send all replies to netsys!jsheese!jeffery)

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 17:40:09 GMT
From:      eckert@faui10.UUCP (Toerless Eckert,0.058I4,7908,04181-8353)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute....

From article <89Apr22.161824hst.4270@dorsai.ics.hawaii.edu>, by torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen"):
> Does anyone have ``traceroute" running on a Sun-4 running SunOS4.0? I can't
> seem to get it to work even after having made the necessary kernel mods.

By the way: Where can i get the patches for the NIT bug
in the SunOS kernel ? I would like to have diffs to the
sources and not binaries!!

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 89 23:52:43 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute....

>>From article <89Apr22.161824hst.4270@dorsai.ics.hawaii.edu>, by torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen"):
>> Does anyone have ``traceroute" running on a Sun-4 running SunOS4.0? I can't
>> seem to get it to work even after having made the necessary kernel mods.
>
>By the way: Where can i get the patches for the NIT bug
>in the SunOS kernel ? I would like to have diffs to the
>sources and not binaries!!

I have all of the patches necessary to the Sun kernel to fix the NIT bug. So
do a lot of other people I think.

How about bugging Sun to put them on UUNET along with the other patches there?

If you're looking to get something like ``statspy" running, I have the patches
for that to make it work on a Sun-4. But maybe Bob Braden and Annette DeSchon
have an ``official" version by now that'll work across both architectures.

						Aloha, Torben

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 89 00:42:44 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   dialup SLIP (again)

>Contact mju@m-net.UUCP.  He and several others have modified the source
>for KA9Q software to use dialup SLIP with the Merit network in Ann
>Arbor and Detroit Michigan.
 
Merit does not provide dial-up SLIP, but instead provides dial-up SLFP
(the MIT/PCIP serial protocol).  SLFP provides the dynamic IP address
assignment desirable for dialup lines.  We offer SLIP for hardwire
lines only.
 
Dave Katz
Merit Computer Network

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 89 11:34:56 GMT
From:      avq@goya.dit.upm.es (Alfredo Villalobos)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for 386 streams, problems ....


  
    We are trying to install WIN/TCP for 386 (Rel. 1.1) streams on 
    Olivetti M380 System (European version of ATT 6386 system) running
    UNIX SYSV/3.1u. but we have some problems:

    a) We don't have NETwork Service Extension (NSE) software package but 
       NETwork Support Utilities instead.

    b) There are not relation between the system configuration files of 
       the installation process and our system configuration files.

    c) Some commands of the installation process are not available
	with the same name.
 
  Any help would be appreciated.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 89 12:27:45 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  Use of Precedence in the IP Type of Service field

David,

The text to which you refer, and similar material in several other
places, amounts to HR WG hand-waving to disclaim responsibility for the
subject.  As for the DCA side, I could mention a few things, but it
might lead into topics best reserved to a less widely distributed
forum.  How about giving me a call sometime at (703) 883-6832 and we'll
talk about the whole area; or, send me email and tell me more about the
context of your interest and I'll try to come up with appropriate material.

Bill Barns / MITRE-Washington Networking Center / barns@gateway.mitre.org

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 89 15:48:40 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)

What sort of hardware is needed to implement this? The 1/60 second update
rate of standard CRTs is too slow for subliminal messages, even ignoring
considerations of phosphor decay rates. Do you need some sort of RS232-able
tachistoscope to get the required ~2ms display time?
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 89 21:45:33 GMT
From:      thorin!menges!menges@mcnc.org  (John Menges)
To:        tcp-ip@sri-nic.arpa
Subject:   Automated Voice Systems

I'm looking for a device or devices that will perform most or all of
the following functions, under the control of a UNIX host (via TCP/IP
or a serial line would be best).

    - Initiate a call to a number given by controlling host (CH).
    - Return call progress status information to CH
        (dialing, busy, answered, I hung up, they hung up, etc.).
    - Speak an arbitrary message given by CH, preferably as text, but 
      phonetically is ok.  Strongly prefer arbitrary messages, not
      pre-recorded.  Speech should be good enough for most adults to
      understand with a bit of effort.
    - Decode DTMF tones and report to CH what buttons were pushed.
    - Answer the phone & report to CH that phone was answered.
    - Start/Stop recording (digital is preferred), present message ID
      to controlling host.
    - Given message id, speak or delete recorded message.

  Ideally, it would interact with the controlling host *during* a
call, rather than just at the beginning and end of the call.  That is,
the box should be able to:

    - dial/answer
    - speak
    - record, file, retrieve, replay, delete messages
    - decode DTMF tones
    - interact with controlling host

but decision making & control would be done by the controlling host.
One call at a time is ok.

Immediate applications:
    Alerting appropriate personnel to abnormal network or computer events.
    Voice mail.
    System status queries initiated by users & operations staff.
    Primitive device control via voice lines.

Does anybody know of or have experience with such a device?
Any experience with DECtalk or Teleflex?

Is there a better newsgroup for this?
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 89 22:09:32 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

>>As an additional aside, polling is the standard technique used in electronic
>>telephone switches. Imagine an interrupt-driven switch when all the phones
>>come off-hook simultaneously...
>
>Little birds tell me, actually, that it is not unheard-of for some electronic
>phone switches to misbehave badly in this situation...

Yes, things do slow down -- BUT -- if you wait long enough you will
eventually get a dial tone.  An excellent test of this occurred back in
1980 during the Carter/Reagan debates, when 900 DIAL-IT service was
being trialed on a nationwide basis for the first time. AT&T had
carefully designed the service to avoid tying up long distance trunk
capacity (by limiting the number of 900 calls to a small fraction
of each trunk group) but they had not anticipated the extraordinary
level of interest that had half the homes in the US lifting their
receivers simultaneously. I measured dial tone delays of 2-3 minutes
on my local ESS in Illinois.

When polled systems get overloaded they do inded slow down, but they do
not collapse.

Phil

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 01:01:01 GMT
From:      Makey@LOGICON.ARPA (Jeff Makey)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <25231@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>But the echo delay doesn't need to be kept to a *minimum*, but only
>well below the objectionable level to the human user.
 [...]
>I claim that 100ms for echo is not noticable to a user of a video
>display

Your point about only needing to keep echo delay below the level of
perception is well taken.  However, 100ms is 1/10 second, which I am
sure I would find quite noticeable (my terminal runs at 19,200 baud).
Taking a cue from motion pictures, I would assume that 1/30 second is
the order of magnitude of the level of perception, but I would want to
perform some experiments with different delays and lots of people to
make sure.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@LOGICON.ARPA    UUCP: {nosc,ucsd}!logicon.arpa!Makey

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 02:27:15 GMT
From:      nick@spider.co.uk (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

In-Reply-To: Message from "David M. Balenson" of Mar 30, 89 at 9:31 am

> 
> 
> Is it possible to implement TCP/IP in a UNIX (Berkeley 4.{2,3}, SunOS{3,4})
> system OUTSIDE of the kernel?  I presume doing so would have a major impact
> on efficiency, but it might be much easier to program.  Does anyone know o
> any such TCP/IP implementations?  Thanks.
> 
> -David M. Balenson
>  Trusted Information Systems
>  (301) 854-5358
> 
> 


David,

At Spider we have written a "clean" version of the AT&T Streams package
(i.e no AT&T code but similar functionality), mainly as an aid to debugging
our streams software (TCP, X.25, ISO).  Using this, I run the whole "TCP"
stack (ip, arp, etc) in one process, and communicate from applications using
either UNIX IPC (msgget, msgsnd, etc), named pipes, or 'real' streams.

A standard raw ethernet driver is used to communicate with the outside world.

Performance is really not as bad as you might fear; measurements indicate
around 50% of the in-kernel system.

Makes portability really good, though!

Nick Felisiak				nick@spider.co.uk
Spider Systems, Edinburgh

+ 44 31 554 9424

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 02:39:33 GMT
From:      philipp@CLOUSO.CRIM.CA ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   IP options...

I remember hearing on this list several months ago a discussion
about the semantics of interpreting loose/strict source and
record route options, and a possible document that was to come
of this.  Does anyone have a pointer to said document?
(As I remember, it was precipitated because a few implementa-
tions didn't do The Right Thing.)

Also, I was wondering if certain IP options are implicitly
(ie. the RFC doesn't explicitly say) mutually-exclusive,
such as loose and strict source and record routing, or
timestamping and record routes...  Actually it would seem
silly to have more than one of these in a packet.  Is it
an error to have more than one of these?

Lastly (for now), if one has a timestamp area that isn't
a multiple of 4 (or 8) bytes long, and the overflow field
overflows, should the Parameter Error message point to the
length or overflow field?

Please reply directly.

Thanks,

-Philip

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 08:05:59 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <421@logicon.arpa> Makey@LOGICON.ARPA (Jeff Makey) writes:
+---------------
| In article <25231@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
| >But the echo delay doesn't need to be kept to a *minimum*, but only
| >well below the objectionable level to the human user.
| >I claim that 100ms for echo is not noticable to a user of a video display
| Your point about only needing to keep echo delay below the level of
| perception is well taken.  However, 100ms is 1/10 second, which I am
| sure I would find quite noticeable (my terminal runs at 19,200 baud).
+---------------

But you're only typing about 5 chars/sec. What I'm saying is that the
hand-eye echo delay can be a large fraction (even >1) of the inter-keystroke
time before it becomes noticeable. The fact that you are using 9600, 19200,
or 56k baud is irrelevant.  [O.k. you're a touch-typist, and are doing
10 c/s... but touch-typists depend even *less* on visual feedback.]

+---------------
| Taking a cue from motion pictures, I would assume that 1/30 second is
| the order of magnitude of the level of perception, but I would want to
| perform some experiments with different delays and lots of people to
| make sure.  :: Jeff Makey
+---------------

Well, the analogy doesn't really apply.

1. We're not talking about merging a succession of frames into a seamless
   whole here ["eye-eye coordination", if you will], but [in the worst case]
   about maintaining hand-eye coordination between cursor keys and cursor
   location.

2. There is actually very little feedback from visual input back to the
   keyboarding process; the major feedbacks are (a) auditory -- you *hear*
   the keys being struck, and (b) tactile -- you *feel* the keys hitting
   bottom (or clicking or whatever). Compared to these two, the visual
   feedback (for most people) is quite minor, and is almost ignored.

3. Most error detection while typing is unrelated to the visual perception;
   it has instead to do with typing the wrong thing, and then *realizing*
   it without having to see it. [You may not believe this at first, but
   watch someone else type for a while...]

Of course, it was quite true that when the echo from the computer *did*
have a large auditory component, as with the Teletype [*klunk* *klunk*],
then the 1/10 second delay [110 baud] between keyboard and typehead was
quite noticable [*ker*-*chunk* *ker-chunk*]. And when you used a Teletype in
full-duplex with host echo, that gave you 2/10 sec delay [*ker*-gap-*chunk*
*ker*-gap-*chunk*] that was initially annoying [the "rubber band" touch],
but users got used to it. [They had to.]

With a video display, the irritation begins when the delay is such that
there is a noticable mismatch in action and result. In my experience,
this starts about 0.2-0.3 sec, but gets *really* bad above about 1 second,
when it becomes difficult to match cursor key strikes to cursor location.
[Even worse is the sort of variation you get with program-"echo" on a loaded
system or with Telnet on a slow connection, where you think you're typing
ahead the right number, only to stop and see the cursor "coast" far beyond
where you wanted it.]

But you can try the experiments you want fairly easily by modifying
a copy of Telnet [doing it in the client's easiest] to delay sending
keystrokes in to the host by some amount of time.

I have no really hard data to hand, but based comment from users when I was
building async mux networks back at Dig. Comm. Assoc., I'd still say that a
hand-eye echo delay [with *no* auditory component of echo from the "display"!]
of 100ms is not noticable, and up to 200-300ms is quite acceptable.

[But note that that has to encompass *all* components of the echo path,
including possibly several layers of terminal servers and intermediate
Telnet hosts, if that's what a "typical" user does. Design goals of 20-50ms
each for terminal input and output dally/startup timers are probably o.k.]

This should probably go in comp.ergonomics, except that is *is* germane
to designing networking systems that balance efficiency and latency
considerations...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Apr 89 13:34 EDT
From:      Bob Stratton <BSTRATTO%NAS.BITNET@CORNELLC.cit.cornell.edu>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   TCP/IP under VM/CMS
*cc: Bob Stratton

          Hello all!

          I'm looking for a TCP/IP implementation, preferably
          non-commercial, that runs on an IBM 43XX under VM/CMS.

          The machine has a 3725 FEP and a Renex protocol converter,
          and currently speaks RSCS to BITNET.

          If anyone knows of such a beast, please respond directly to
          me. I've worked at several companies with commercial
          implementations for sale, but this is an experimental
          effort. (sort of the "If we show them it works, maybe we can
          do it right later...)

                                             Thanks in advance!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Robert J. Stratton, III   BITNET:   BSTRATTO@NAS
Stratton Systems Design   INTERNET: BSTRATTO%NAS.BITNET@UUNET.UU.NET
Alexandria, VA, USA       USENET:   uunet!NAS.BITNET!BSTRATTO
                          PSTNET:   1-202-334-3638
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"If builders built buildings the way most programmers write programs,
 then the first woodpecker to come along would destroy civilization."
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 10:15:52 GMT
From:      hollandm@prlhp1.prl.philips.co.uk (Martin Holland)
To:        comp.protocols.tcp-ip
Subject:   Micom NTS/TCP V3.0


I have just got hold of V3.0 of NTS/TCP to run on Micom NTS100, this
is supposed to cure a bug that crashes the server with NTS/TCP V2.0.	
When the terminal server is configured with the ports as Slave, (which we
use to connect to non-TCP/IP hosts), it becomes very fussy about what hosts
can connect to it properly.  It works with an HP 9000/350 and an Apollo DN570
and other Micom NTS100s.
It has stopped working with the IBM VM/CMS (5798-FAL) and PCs with various 
ethernet cards (Software PC/TCP from FTP Inc.)
I have connected a loopback connector and monitor to one port on the server
and connected to it from various hosts. I also had an ethernet monitor running. 
When I type I expect the characters to be echoed back.  From all hosts the 
correct characters arrive at the port and are echoed correctly, but on 
the PCs and IBM the packet sent from the server dosn't contain the character 
that was sent. 
Has anyone else had this problem?  Can anyone thing of anything to solve the
problem?

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Apr 89 17:18:19 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Joe Peck <hpl-opus!hpspdra!jpeck@hplabs.hp.com>, tcp-ip@sri-nic.arpa
Subject:   Re: What is AT&T's vendor id?
>I'm trying to verify what the Ethernet vendor id is for AT&T.
>I have it as 08-00-10, but lately we've been seeing packets on
>a network with the vendor id = 80-00-10.  I'd like to know if we've
>got the right one for AT&T and if we do, then who is 80-00-10?

Apparently 08-00-10 is assigned to AT&T, but they use 80-00-10.  I have
never seen packets from the former address range, and can verify that
the systems using 80-00-10 are all from AT&T.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Apr 89 17:22:02 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Jerry Merlaine <pacbell!belltec!jom@ames.arc.nasa.gov>, tcp-ip@sri-nic.arpa
Subject:   Re: /etc/hosts to BIND
>In the BIND 4.8 distribution we find:
>        1) :pwedit - convert /etc/passwd into user records for BIND
>        2) atod.y -  convert /usr/lib/aliases into mail records for BIND
>
>What we do not find is a somewhat more complex program to transform /etc/hosts
>into records for the BIND database.  Has anyone done this?

I have several "awk" scripts you might find useful.  See the files in
/src/hostmaint on serv1.cl.msu.edu (via anonymous ftp).  I maintain all
my records in the "hosts.txt" format, and convert the same file to both
the /etc/hosts format and named format.  Also there is a script to change
"hosts" format into "hosts.txt", which will get you started.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 13:24:10 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]

>By keeping the 1st-level interrupts *very* lightweight (*don't* save any
>context [except maybe a working reg or two], just grab the data, queue it,
>then queue your 2nd-level handler), you can afford a *lot* of interrupts,
>many more than you would think. And by leaving hardware interrupts *enabled*
>during [almost] all 2nd-level processing, you don't lose data due to
>latency problems.
>

	[]

	I've been following the "interrupts kill" discussion with interest.
	Its been a few years since I did SDLC/HDLC with the SIO but as I
	remember...

	The approach of capturing an interrupt, grabbing the appropriate
	SIO registers, and queuing them for later processing worked fine
	except for one nasty case.  That case was the situation where a
	large data framewithout the final bit was followed immediately by
	a Receive Ready (3 or 4 bytes).  The burst of interrupts that
	end of frame, CRC, start of frame, end of frame, CRC generated was
	too fast for 4.77 Mhz. PC's.  If I remeber correctly, the only
	approach that worked was a modified interrupt queue/handler.  The
	interrupt was scanned as it was processed, if it was "lightweight"
	i.e. a data interrupt, or one of the less critical start or end of
	frame ones it was queued for later processing.  If it was a
	"heavyweight" interrupt, i.e., the CRC for frame two in the
	situation mentioned above, it was processed immediately.  The
	catch of course was that before the "heavyweight" interrupt could
	be processed, the queue of "lightweight" interrupts had to be 
	completely serviced to keep things in their proper order. Now,
	here we are at interrupt time, and a very critical one, doing
	complete servicing of not one, but a whole string of interrupts.

	THis approach worked, but as has been previously mentioned, the rest
	of the system suffered.  As I recall, the SIO only had a 2 or 3 byte
	FIFO and did not latch interrupts.  Has a better serial chip come
	out since?


						Larry Backman
						Interlan

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 13:41:55 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)


	What sort of hardware is needed to implement this? The 1/60
	second update rate of standard CRTs is too slow for subliminal
	messages, even ignoring considerations of phosphor decay rates.
	Do you need some sort of RS232-able tachistoscope to get the
	required ~2ms display time?
A standard vector CRT with a reasonably flexible controller should do
the trick.  HP makes such a beast, for instance.  If you keep the
display list very short and tell the controller to scan once only,
you may be able to achieve 2ms display time.  In a perception lab
with which I am associated we routinely get ~10ms temporal accuracy,
more limited by the cpu clock than by the display.

Note, however, that since you must draw characters the text of your 
message must be kept short.  A reasonable upper bound would be 2 
characters.  Thus, the subliminal message "IP" is doable, but "OSI" 
probably is not.

More seriously, but not appropriate to this list:  if anyone knows
of any raster display hardware capable of < 10ms temporal resolution
please send me email.  We are interested in buying...  Our T-scope
controller is a networked PC (spry.psych.uoregon.edu), but the stimuli
still have to be inserted in the fields manually.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 14:29:53 GMT
From:      gkrishn@donald.uucp (Krishnan Gopalan)
To:        comp.protocols.tcp-ip
Subject:   Re: NIC-SERVICE


	Instead of loading sri-nic, one can ftp to sh.cs.net and get
	the RFC's you need. I have been doing this successfully.Else
	you can send mail to info-server@sh.cs.net with the following
	message:
	REQUEST:rfc
	TOPIC:rfc no of your choice
	The second method has not worked too successfully.

		gkrishn@eng.clemson.edu

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 14:51:45 GMT
From:      jeff@dante.nmsu.edu (Jeff Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: IP authentication


For those people really concerned about security on their LAN, you
might be interested in the DEC DESNC Ethernet Security Device.  This
box looks like a 4 port thinwire repeater, but performs real-time DES
encryption on packet bodies.  A VMS VAX provides key distribution, and
determines what e-net address can connect to what ports, and whether
or not sessions must be encrypted.  The devices that you connect to
the box think they are connecting to a standard thinwire ethernet, so
no mods are required to hardware or software.

We are currently evaluating this box for construction of a relatively
secure network for our administrative users.

Jeff Harris
Computer Center - Room 133E
Box 30001 / Dept 3AT
New Mexico State University
Las Cruces, New Mexico 88003-0001

Internet: jeff@NMSU.Edu				Voice	: (505) 646-5110
UUCP	: sun!sunpeaks!sunnmex!nmsu!jeff	FAX	: (505) 646-5278
Bitnet	: jeff@nmsu

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 15:03:00 GMT
From:      7thSon@SLCS.SLB.COM (Chris Garrigues)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)


    Date: 24 Apr 89 15:48:40 GMT
    From: peter%ficc%sugar%texbell@bellcore.com  (Peter da Silva)

    What sort of hardware is needed to implement this? The 1/60 second update
    rate of standard CRTs is too slow for subliminal messages, even ignoring
    considerations of phosphor decay rates. Do you need some sort of RS232-able
    tachistoscope to get the required ~2ms display time?

I was actually implementing it on a Lisp Machine and because this is an
AI machine, I can use various AI techniques to display the message very
quickly on a portion of the screen where I can be reasonably certain the
user isn't looking (by use of an expert system modeling the user's
visual system).

Admittedly, this solution isn't guaranteed to always keep the message at
a subliminal level, but we feel that our model is accurate enough (and
our users are sufficiently asleep), that the majority of them will never
know what hit their retina.

A second option I was considering was to simply display it as a
notification with the string "Don't read this:  " appended to the front,
but after some experimentation, I now feel that this might be too
obvious.

Two techniques which I haven't experimented with are (a) to dither the
message into the background pattern on my window system.  This would
make the message difficult to read, but isn't that the idea? and (b) to
use the audio system of the console to actually say the words very
quietly.  I suspect this would work on people like myself who work with
the radio on, but might be detectable by those who perfer to work in
silence.

I expect to have more success when I port to a color screen because I
can simply write the charaters with the color being almost, but not
quite, identical to the background color.  After all, can *you*
differentiate 16,777,216 different colors?  How to select the colors is
certainly a fascinating area for future research.

Chris

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 16:49:05 GMT
From:      huitema@mirsa.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

From article <421@logicon.arpa>, by Makey@LOGICON.ARPA (Jeff Makey):
> In article <25231@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>  [...]
>>I claim that 100ms for echo is not noticable to a user of a video
>>display
> 
> Your point about only needing to keep echo delay below the level of
> perception is well taken.  However, 100ms is 1/10 second, which I am
> sure I would find quite noticeable (my terminal runs at 19,200 baud).

Just analyse a few very popular pieces of software:

	ksh,
	emacs,
	X-Windows,
	...

An interesting point is that all of them are making the echoing from the
user level program! Moreover, X-Windows even send the data on a secundary
TCP connection and back before processing it. And the look at all ``virtual
terminals'' based on the ``pseudo-ttys'', which feature an extra hop inside
the user level before going to the network... Thus, I have some doubts that
one should aim at interrupt time echoing just for the sake of optimizing
``ed'' and ``bin/sh'' if user level echoing is felt acceptable otherwise...

Moreover, by using a conjunction of minimal real time interrupt handlers +
properly scheduled software interrupts, one maximises the system throughput
and thus reduces response times and echoing delays for all users, ``ed'' as
well as ``emacs''.

Christian Huitema

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 17:34:00 GMT
From:      BSTRATTO@NAS.BITNET (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP under VM/CMS

*cc: Bob Stratton

          Hello all!

          I'm looking for a TCP/IP implementation, preferably
          non-commercial, that runs on an IBM 43XX under VM/CMS.

          The machine has a 3725 FEP and a Renex protocol converter,
          and currently speaks RSCS to BITNET.

          If anyone knows of such a beast, please respond directly to
          me. I've worked at several companies with commercial
          implementations for sale, but this is an experimental
          effort. (sort of the "If we show them it works, maybe we can
          do it right later...)

                                             Thanks in advance!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Robert J. Stratton, III   BITNET:   BSTRATTO@NAS
Stratton Systems Design   INTERNET: BSTRATTO%NAS.BITNET@UUNET.UU.NET
Alexandria, VA, USA       USENET:   uunet!NAS.BITNET!BSTRATTO
                          PSTNET:   1-202-334-3638
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"If builders built buildings the way most programmers write programs,
 then the first woodpecker to come along would destroy civilization."

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 20:31:06 GMT
From:      DIXON-R@osu-20.ircc.ohio-state.edu (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   DEC Encryption Scheme

The information provided to me by the DEC product manager for this encryption
indicates it is not very generally useful. The problems are:
1. Too much of a packet is encrypted, such that it cannot pass thru a router.
2. You must have a VAX and the control software to use it at all.

                                  Bob Dixon
                                  Ohio State University

-------

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 21:18:19 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: What is AT&T's vendor id?

>I'm trying to verify what the Ethernet vendor id is for AT&T.
>I have it as 08-00-10, but lately we've been seeing packets on
>a network with the vendor id = 80-00-10.  I'd like to know if we've
>got the right one for AT&T and if we do, then who is 80-00-10?

Apparently 08-00-10 is assigned to AT&T, but they use 80-00-10.  I have
never seen packets from the former address range, and can verify that
the systems using 80-00-10 are all from AT&T.

Doug Nelson
Network Software Manager
Michigan State University

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 21:22:02 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts to BIND

>In the BIND 4.8 distribution we find:
>        1) :pwedit - convert /etc/passwd into user records for BIND
>        2) atod.y -  convert /usr/lib/aliases into mail records for BIND
>
>What we do not find is a somewhat more complex program to transform /etc/hosts
>into records for the BIND database.  Has anyone done this?

I have several "awk" scripts you might find useful.  See the files in
/src/hostmaint on serv1.cl.msu.edu (via anonymous ftp).  I maintain all
my records in the "hosts.txt" format, and convert the same file to both
the /etc/hosts format and named format.  Also there is a script to change
"hosts" format into "hosts.txt", which will get you started.

Doug Nelson
Network Software Manager
Michigan State University

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 21:27:42 GMT
From:      hubcap!ncrcae!wingo@gatech.edu  (Dave Wingo)
To:        tcp-ip@sri-nic.arpa
Subject:   tcp/ip terminal servers?

 am currently looking for a list of terminal servers which utilize tcp/ip
I know that one such vendor is Xylogics which has the Annex II product. Has 
anyone used it?? What are your comments?? Do you know of other products 
currently available? 

Please direct responses directly to me.
Thanks in advance..... regards David Wingo
                               wingo@Columbia.NCR.COM
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 89 21:51:44 GMT
From:      gws@Xylogics.COM (Geoff Steckel)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

There is some knowledge about human sensitivity to delays in
tactile/aural/visual feedback.  Some of the old experiments did things
like have people try to write while watching their hand in a delayed
video monitor.  Some of this was published in general science magazines
like Scientific American as much as 30 years ago.
There are three regimes of interest:

0 to about 50 milliseconds:
   Subject doesn't notice much.  At the upper end, performance slows slightly,
but error rate doesn't increase much.

50 to about 500 milliseconds:
   The **REALLY** annoying range.  Performance slows by x10 or more, even
to a complete stop.  Error rate climbs to virtually 100% at the high end.
Subjects become fatigued and irritable.

500 milliseconds and up:
   If people are forced to use feedback with this much delay, oscillations,
gross errors (like hitting yourself with a pen, etc.), and great annoyance
are the result.  Performing with any accuracy is very slow and very fatiguing.
Most subjects ignore everything except tactile and internal muscle/joint
feedback and `fly blind' -- and feel much better.  They then stop occasionally
and wait for the returned information to catch up with reality.

I worked on a cross-country proprietary network about 15 years ago.
We worked VERY hard to get user feedback time < 100 ms; we wanted 50 or less.
Users started complaining at about 80 ms or so.

Moral: ergonomics are important even (or especially) when designing comm
systems, if humans are in the loop.

	geoff steckel (steckel@alliant.COM, steckel@xenna.COM)

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 01:58:00 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   IP over ISDN and Satellite?

What is being done about IP connectivity using some of the new
communication capabilities.

Perhaps satellite isn't so new. Of course it isn't very suitable
for IP in its raw form. But I would thing it could be used 
in cooperation with low speed terestrial links. For example
instead of a T1 terestrial link (which is very expensive in
Australia) you could link two points with a 56Kb terestrial
link plus a T1 satellite link. The idea would be to use the
low speed link for all small packets (or big packets when the
link is free maybe) and use the satellite for big packets. This
would use the satellite for file transfers or bulk data from
computer to terminal, but allow interactive traffic to have
usable echo characteristics. Has anyone tried anything like this?

ISDN is also interesting. I presume you could link your ISDN to
many other ISDN sites simultaneously but at low speed using the
signalling channel (running something like IP over X.25). Then
when you get a significant amount of data going to some destination
you would start making connections using the 64Kb data channels.
The idea (preferably) would be to use as many data channels as
possible while still leaving some lines free at each end for
telephone users. Not trivial but not conceptually difficult. Is
anyone working in this area?

Bob Smart, <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Apr 89 09:52 CST
From:      Larry Owen <OWEN@ducvax.auburn.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   NCSA Telnet problem
This is probably pretty simple.  I have a Mac II with a Kinetics Etherport
II installed, and I'm trying to bring up NCSA Telnet.  I had this setup
working several months ago when I was on another (non-Internet-connected)
LAN, but never used it much. I subsequently had to replace my hard disk,
and rebuilt the new disk from software distribution diskettes rather than
from a backup.

When I try to launch Telnet, I get Ye Olde Bombe with ID = 01.  I re-installed
the Ethertalk software (V1.1) that came with the Etherport II, and replaced
NCSA Telnet with a "fresh" copy from the distribution diskette (V2.1e), but
I still get the bomb.  I have probably just forgotten part of the installation
procedure, but unfortunately my Kinetics documentation has not yet surfaced
after my recent move.  Any ideas?

Other (perhaps) relevant data: Finder 6.1, System 6.0.2.

Any help appreciated.

Larry Owen
Mgr. Minicomputer Support
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 07:38:09 GMT
From:      jgm@kokab.cc.deakin.OZ (John Moorfoot)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Telnet problems with Bridge CS/1's

We have Bridge CS/1's and CS/200's running s/w version 20000 into
Suns running SUNOS 4.0. The telnet client on the Bridge boxes
passes a <CR><NUL> string (which is produced by the Suns as per
the telnet protocol spec) to the terminal as is (i.e. without
stripping the <NUL>). This upsets terminals which may use \015 as
part of their cursor address sequence.

Has anyone else seen this problem? Is there a fix for it? The
Australian agents are mainly into XNS, and do not seem to
understand the problem.

John Moorfoot 		ARPA:	jgm%charlie.oz.au@uunet.uu.net
			UUCP:	...!uunet!munnari!charlie.oz!jgm

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 09:22:15 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Interrupts & Polling [was: Re: Super Cheap IP router (< $1000)]

In article <606@interlan.UUCP> backman@interlan.UUCP (Larry Backman) writes:
+---------------
| 	The approach of capturing an interrupt, grabbing the appropriate
| 	SIO registers, and queuing them for later processing worked fine
| 	except for one nasty case...  The burst of interrupts that
| 	end of frame, CRC, start of frame, end of frame, CRC generated was
| 	too fast for 4.77 Mhz. PC's...  [...then discusses fix/hack...]
| 	THis approach worked, but as has been previously mentioned, the rest
| 	of the system suffered.  As I recall, the SIO only had a 2 or 3 byte
| 	FIFO and did not latch interrupts.  Has a better serial chip come
| 	out since? | Larry Backman | Interlan
+---------------

No, but faster CPUs have... ;-}  ;-}

Sorry, that was too flip. What we did back at Dig.Comm.Assoc. to handle
similar issues with our poor little 4 MHz Z80's (DCA System-350, and the like)
was to build an interrupt state machine which fielded the hardware interrupts
from the serial chips and stuck the results of the interrupt into a linked
list (via DMA) in the Z-80's memory.

Why did we need all that, given that we had my fancy two-level interrupt
scheme in the first place? Well, yes, of course, there *are* limits to
the two-level scheme. All I've been trying to say was that the limits
are typically much higher than the common perception of interrupt handling
ability for a given CPU. So a 68000 *can* handle a dozen 19200-baud TTYs...

But the "DCA System 350" could have 128 idle ports all starting up from idle
at once, and one poor 4 MHz Z-80 having to deal with it. [Similar to the
problem mentioned by an earlier poster with dial tone in telephone systems.]

This system was an upgrade from an earlier PDP-8 based net node, for which
the PDP-8 was handling all the interrupts from a bus with the ports on it.
[Western Digital "ASTRO" chips, but might as well have been SIOs.] When
the PDP-8 finally ran out of steam, we wanted to use multiple Z-80's to
share the traffic, but without inventing a new bus. So we built a little
state machine to go where the PDP-8 used to go, to handle all the interrupts
from the serial ports. And the Z-80's went on boards that looked sort of
like another serial port to the bus. And there was a little RAM that
told the state machine which Z-80 should get the status for an interrupt
from a given serial port. The state machine wrote a 4-byte "packet" to the
correct Z-80, consisting of {intr-type, src-port, int-status, [int-data]}.
(That is, if the interrupt status on the port said "received data available",
the state machine went ahead and read the data for us.)

Now a Z-80 wasn't all that blindingly fast at handling interrupts, and a
*lot* of people could type <RETURN> at once, and all "idle" ports were
mapped to a common node controller Z-80 (which would assign a port to
the least busy Z-80 when the port went non-idle). So we needed to be able
to handle 128 interrupts at once, and without interfering with full-speed
traffic that might allready be going on on one of the ports (say).

The solution was to make the bus interface DMA the 4-byte interrupt
packet into Z-80 RAM, and to allocate enough space for those interrupts
that a given Z-80 could handle the worst-case peak interrupt load.
(It was really quite cute, just a couple of chips.)

When the first-level handler for "bus interrupts" saw that the incoming queue
was non-empty, it fired up the second-level handler, which trundled down the
DMA queue processing transmit & receive interrupts as fast as it could.

So I would say if your 4.77 MHz PC wasn't fast enough to handle the
SDLC inter-frame timing, you could either get a faster CPU, or make
the serial port "smarter". This may mean putting a small state machine
on the port card to handle the inter-frame state changes, and/or putting a
FIFO on board to queue the interrupt activity. There are many solutions.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 09:50:03 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <1410@xenna.Xylogics.COM> gws@Xylogics.COM (Geoff Steckel) writes:
+---------------
| There is some knowledge about human sensitivity to delays in
| tactile/aural/visual feedback...  | There are three regimes of interest:
| 0 to about 50 milliseconds: Subject doesn't notice much...
| 50 to about 500 milliseconds: The **REALLY** annoying range...
| 500 milliseconds and up:
+---------------

I completely agree with your numbers for tactile/aural [one of the
"torture tests" we applied before we'd let new announcers work at a
certain campus radio station (c.1965) was to delay the sound in their
monitor earphone from their voice by about 1/2 second -- *killer!*],
but I just can't agree in the case of visual echo to keyboarded data.
It's my experience that the second regime ("really annoying") begins
well above the 200ms range for the keyboard/display situation.

For example, I am typing this message into "vi" via a Telebit modem.
The Telebit, in "micropacket" mode, has a round-trip time of about
240ms for single-character echo (including response to cursor-motion
commands). [I just measured it.] Yet I experience no discomfort or
irritation when doing low-level editing over this modem. [Reading
news, yes, the ~1sec pause while it shifts into "long packet" mode
when displaying a new page is quite annoying. I often wish the Telebit
had something intermediate between its two modes!]

I just don't believe the thresholds are the same for all pairs of
action/perception modes, especially keyboard/display.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 13:08:17 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: IP authentication

>From: opus!dante!jeff@lanl.gov  (Jeff Harris)
>Organization: New Mexico State University
>
>For those people really concerned about security on their LAN, you
>might be interested in the DEC DESNC Ethernet Security Device.  

Wang, Motorola, and Xerox are also developing LAN encryption products.
I'm familiar the Xerox Encryption Unit: 802.3; it plugs into the drop 
cable between the processor and the transceiver connection; encryption 
is done using a chip developed by Ultron (703)827-9405; the first 14
octets remain in-the-clear; the  XEU costs about 5K; Xerox contact 
is Frank Presson (703)442-6777.

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 13:22:15 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <164@mirsa.inria.fr>, huitema@mirsa.inria.fr (Christian Huitema) writes:
[ vi, emacs, etc... do echoing at the user level ]

> Thus, I have some doubts that
> one should aim at interrupt time echoing just for the sake of optimizing
> ``ed'' and ``bin/sh'' if user level echoing is felt acceptable otherwise...

You have obviously been blessed with an abundance of CPU time. There have been
times I've dropped out of 'vi' to 'ex' because the echo delay for 'vi' was so
long I couldn't stand it.

Yes, a real-time kernel would be an improvement... but failing that interrupt-
time echoing has its place.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Apr 89 17:58:40 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        "TCP/IP list (plus more)" <tcp-ip@sri-nic.arpa>
Subject:   FAX over IP
Is anyone aware of FAX machines (or FAX/PC combinations) that can run
over an IP network?  If not, do you know who might be working on such
a product?

Doug Nelson
Network Software Manager
Michigan State University
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 14:06:27 GMT
From:      bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <291@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
   This is derived on something I read in BYTE some time ago.

(...surely a reputable authority on the management on large networks
of modern machines :-)

   Protect both files, so only privileged processes can read them (if
   you can't trust superusers, your security is shot anyway).

I trust superusers on consoles of hosts that are locked in our machine
room.  I don't trust superusers anywhere else.  MIT publishes their
workstations' root password in their lab guides.

"Shot" host security is different from "shot" network security, and
"shot" remote host security is different from "shot" local host
security.  I want to maintain some semblance of security on our
systems, and I do that by assuming (recognizing?) that the network and
all the other systems on it are insecure.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 15:08:29 GMT
From:      pritch@tut.cis.ohio-state.edu (Norm Pritchett)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Seeking advice on establishing a LARGE centralized mail system


I would like to hear from individuals experienced in establishing a
centralized electronic mail service for a large user base (4 figures
or greater). 

Here at the Ohio State University we have a campus-wide token ring
network interconnecting individually-administered departmental networks
whose sizes range from a handful to hundreds.  It is not very easy to
provide a total count of hosts but it should be pretty close to a thousand.

Some of our departments already implement one scheme or another for
providing uniform addressing of mail for its users such that a sender
need not be concerned with which particular machine to direct the
message to.  In these cases, the sender addresses the message to the
department's Internet domain name (e.g. user@eng.ohio-state.edu or
user@cis.ohio-state.edu) and the message is delivered to the recipient
on his "home" machine.

We would like to implement a similar scheme at the university-wide
level where a sender could address a message to
some-userid@ohio-state.edu and have the message delivered to the
recipient on his home system.  The major obstacle is with the
"some-userid" part: we wish it to be representative of the recipient's
real name (or actually be his real name) while at the same time have
it uniquely identify him/her among the 75,000+ faculty, staff and
students where there are numerous unresolvable name collisions.  A
format of Firstname.MI.Lastname which eliminates many collisions still
leaves many remaining.

If there is anyone who has experience in setting up a similar thing or
has constructive advise, please correspond with me via mail at one of the
following Internet addresses:

	pritch@cis.ohio-state.edu
	npritchett@osu-20.ircc.ohio-state.edu
	pritchett@eng.ohio-state.edu

-- 

Norm Pritchett, The Ohio State University College of Engineering Network
Internet: pritchett@eng.ohio-state.edu	BITNET: TS1703 at OHSTVMA
UUCP: pritch@sydney.columbus.oh.us	CCNET: ENG::PRITCHETT (6172::PRITCHETT)

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 15:38:00 GMT
From:      Andrew.S.Hooper@QueensU.CA
To:        comp.protocols.tcp-ip
Subject:   FTP incompatibility

Following is an FTP incompatibility we recently encountered. I'd
appreciate any comments on the correctness of the two implementations.

A user on host A makes an FTP control connection to host B at address
B1. B also has a second network connection with address B2. The user
requests a directory listing. The FTP server on host B then initiates
a data connection back to host A, but uses B2 as the source address.
Host A is prepared to accept a connection from B1, but refuses to
accept one from B2. Hence, no listings or transfers can be done. The
port number supplied by A is used correctly by B.

Host A runs IBM VM TCP/IP Release 1.2, host B runs Wollongong 3.2.

Nowhere in the FTP RFC (959) can I find a specifcation as to the source
address of the data connection, so I cannot point fingers. It does seem
appropriate to me to reject the mismatching address, as it could be
coming from who knows where, but there may be arguments for not doing so.
Two other TCP/IP packages do not check the source address.

Thanks in advance for any advice.

Andy Hooper         Queen's Univ. Computing Services       Bitnet: HOOPER@QUCDN
                    Kingston, Ontario, Canada        Telephone: +1 613 545 2019

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 15:52:00 GMT
From:      OWEN@DUCVAX.AUBURN.EDU (Larry Owen)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet problem

This is probably pretty simple.  I have a Mac II with a Kinetics Etherport
II installed, and I'm trying to bring up NCSA Telnet.  I had this setup
working several months ago when I was on another (non-Internet-connected)
LAN, but never used it much. I subsequently had to replace my hard disk,
and rebuilt the new disk from software distribution diskettes rather than
from a backup.

When I try to launch Telnet, I get Ye Olde Bombe with ID = 01.  I re-installed
the Ethertalk software (V1.1) that came with the Etherport II, and replaced
NCSA Telnet with a "fresh" copy from the distribution diskette (V2.1e), but
I still get the bomb.  I have probably just forgotten part of the installation
procedure, but unfortunately my Kinetics documentation has not yet surfaced
after my recent move.  Any ideas?

Other (perhaps) relevant data: Finder 6.1, System 6.0.2.

Any help appreciated.

Larry Owen
Mgr. Minicomputer Support
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 16:48:00 GMT
From:      m.cs.uiuc.edu!p.cs.uiuc.edu!zweig@uxc.cso.uiuc.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Re: interrupt-driven vs. polled I/O per

  A fascinating experiment (which has probably already been run somewhere)
about visual feedback and typing would be to have the computer *fix* errors
in typing before feeding back. That is, if I type "qiu" as the first part
of "quick", it'd be easy to repair it to "qui" before echoing the characters.
If you had users typing from dictation, it'd be almost trivial for the
computer to correct typos (since the correct text would already be known and
you'd just have to synchronize with the user's typing).
  What I wonder is this: would people make more/fewer typos, and how would
typos effect their speed? I, for one, always pause for about half a second
when I make a typo -- even if it only takes 2 keystrokes (~.25 sec) to
correct.

-Johnny Zweig
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      26 APR 89 17:06:38:00 GMT
From:      FUSION <FUSION@uhhepg.phys.hawaii.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP/IP USING FUSION SOFTWARE FOR ROUTING OUT OF SUBNET
THIS IS AN UPDATE TO OUR INQUERY ABOUT FUSION TCP/IP RUNNING ON VMS
OPERATING SYSTEM WITHIN PRIMARILY UNIX OPERATING SYSTEM ON A SUBNETTED
TCP/IP ETHERNET NETWORKS. AS WE STATED BEFORE, FUSION SOFTWARE DOESNOT
SUPPORT RIP AND THEREFORE WE NEEDED TO HAVE SOME ONE TELL THE OTHER
COMPUTERS ABOUT OUR SUBNET. THE PROBLEM IS NOT FUSION SOFTWARE...ASIDE
FROM THEM NOT SUPPORTING RIP OR SOME DYNAMIC ROUTING. WE TESTED STATIC
ROUTING USING OUR VAX8650 RUNNING ULTRIX AND HAD SOME PROBLEMS...WE
DID NOT ENTER THE STATIC ROUTING COMMANDS FOR ROUTING CORRECTLY  (PROBABLY).
WE DID A STATIC ROUTINE ON A SUN MACHINE AND WE WERE ABLE TO ROUTE INTO
AND OUT OF OUR SUBNET. DOES ANYBODY KNOW A WAY OF JUST ENTERING ONLY ONTO
ONE MACHINE RUNNING UNIX AND LET IT TELLS ALL THE OTHER ROUTERS/GATEWAYS
WITHIN OUR LOCAL NETWORKS WITHOUT ENTERING IT INTO ALL THE MACHINES?




-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Apr 89 18:11:56 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: talk(1)'s Protocol Description

In article <2382@van-bc.UUCP> skl@van-bc.UUCP (Samuel Lam) writes:
>Could someone please point me to the protocol description of talk(1) on
>on the SUN? ...

I believe the answer is the usual for Berkeley networking software:  you
get to read the source (if you have it!), as there is no documentation.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Apr 89 18:16:51 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Super Cheap IP router (< $1000)

In article <15577@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:
>>>As an additional aside, polling is the standard technique used in electronic
>>>telephone switches. Imagine an interrupt-driven switch when all the phones
>>>come off-hook simultaneously...
>>
>>Little birds tell me, actually, that it is not unheard-of for some electronic
>>phone switches to misbehave badly in this situation...
>
>Yes, things do slow down -- BUT -- if you wait long enough you will
>eventually get a dial tone...

Context implied that the little birds' phrase "misbehave badly" did not
mean just "respond slowly".  The implication was that not all phone switches
are always polled, or at least the polling isn't always done right.  Just
because it's the standard technique doesn't mean everybody is standard...
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 18:22:16 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: echo delays (was interrupt-driven vs. polled I/O)

The discussion of acceptable delays is rapidly moving away from topics
of interest to the majority of TCP-IP mailing list readers.  Perhaps
the discussion could be moved to another forum?

Three technical points:
1/ It is generally agreed that miminum variance in response time is as
   important to user comfort as mean response time.  Studies have
   been done varying the response time of commands in "line mode" i.e.
   from the time you press RETURN to the time the command completes.  I
   imagine that there is literature investigating variance in full
   duplex echo delay.  User expectations also make a big difference as
   to what is considered acceptable.
2/ DEC in their design of the LAT protocol invested substantial effort
   in literature review and some human factors testing.  I believed
   they concluded that it was acceptable to collect typeahead for 80ms
   from a terminal before packetizing and sending it to a host,
   resulting in echo delays to a lightly loaded VMS system with a
   typical range of (I'm guessing) 40 to 200ms.  The 80ms is a tunable
   parameter.  Maybe someone more familiar than I am with LAT could
   comment further.
3/ A request:  could those of you who refer to human factors literature
   please provide citations?  A good though now dated survey is Ben
   Schneiderman, "Response Time and Display Rate in Human Performance
   with Computers," ACM COMPUTING SURVEYS, v 16 n 3 (September 1984),
   pp. 265-286.

JQ Johnson			voice:     503-686-4394
Director of Network Services	Internet:  jqj@oregon.uoregon.edu
Computing Center		Bitnet:    jqj@oregon
University of Oregon		UUCP:	   ...!uoregon!jqj
Eugene, OR  97403		(Internet is preferred)

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 18:24:36 GMT
From:      geoff@USAFA.AF.MIL (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   sendmail.cf

Has anyone solved the problem with their sendmail configuration if a
host has two different domains.  We are presently receiving mail
addressed to usafa.af.mil and usafa.arpa.  I seem to have kludged
something to work by adding another rule in rule set zero, but I am
not sure if it is correct.

	Thanks,
		geoff

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Apr 89 18:30:06 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)

In article <8904251341.AA04991@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes:
>A standard vector CRT with a reasonably flexible controller should do
>the trick.  HP makes such a beast, for instance.  If you keep the
>display list very short and tell the controller to scan once only,
>you may be able to achieve 2ms display time...
>
>Note, however, that since you must draw characters the text of your 
>message must be kept short.  A reasonable upper bound would be 2 
>characters.  Thus, the subliminal message "IP" is doable, but "OSI" 
>probably is not...

Of course, if you've got a Three Rivers Graphic Wonder, you could probably
do a chapter or so out of Padlipsky's book... :-)

(For those not familiar with it, the GW was a CMU invention that Three
Rivers tried -- not very successfully -- to sell commercially.  The market
wanted vector displays to be smart; the GW was dumb but very very very fast.
It tended to fill its dual-ported memory before it ran out of refresh
speed, but Tom Duff once estimated it could refresh 100,000 short vectors
without serious flicker, if you could find somewhere to store them all.)
(U of T has Three Rivers GW serial number 001.)
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 19:32:38 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   human factors aspects of echo delay

Someone associated with NASA wrote a paper a few years ago in which he
claimed that the key parameter affecting annoyance level associated
with full-duplex typein echo delay was the variance and not the
mean/median.  (I think he was at JPL and I think his name was
Callender, but I don't remember the title or where it appeared.  Echo
delay was not the main subject of the paper but it came up in passing.)
I believe this was a qualitative/impressionistic evaluation, not a
controlled experiment.

His hypothesis would seem plausible given that there is already some
mental compensation for neurological timing skews.  I don't remember
specific numbers but have this impression of having heard that the
feedback loop time to the eye is on the order of a few milliseconds,
whereas to the toes it is somewhere in the 50+ milliseconds area.  This
is a distinguishable difference in the brain - if it weren't, auditory
direction discrimination wouldn't work.  It sounds plausible to me that
it would be easier to adapt to a high mean skew than to a high variance
of skew in echoing.  It might be amusing to speculate on whether the
echo-variance annoyance factor is due to the presence of a variance
estimator in a human user's brain processing, or to its absence.  Both
answers seem to have implicit epistemological ramifications in other
areas: the former in social sciences, the latter in physical sciences
(in which category I place protocol engineering).

Bill Barns / barns@gateway.mitre.org

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 21:58:40 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   FAX over IP

Is anyone aware of FAX machines (or FAX/PC combinations) that can run
over an IP network?  If not, do you know who might be working on such
a product?

Doug Nelson
Network Software Manager
Michigan State University

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 89 22:01:17 GMT
From:      mr-frog@fxgrp.UUCP (Dave Pare)
To:        comp.protocols.tcp-ip
Subject:   BSD IP broadcast datagram fragmentation

4.3 BSD, SunOS 4.0.1, and AIX 2.2.1 all arbitrarily disallow fragmented
broadcast IP datagrams.  Since they are all are apparently derived from
the same 4.2 code, this shouldn't be surprising.  However, the IP protocol
specification mentions nothing about such a limitation.

Line 141 of netinet/ip_output.c (4.3 BSD code) contains the offending
lines...

		/* don't allow broadcast messages to be fragmented */
		if (ip->ip_len > ifp->if_mtu) {
			error = EMSGSIZE;
			goto bad;
		}

So, the question is, why the limitation?  I no-op'ed the offending
lines of code and I was able to broadcast and receive larger datagrams
with no apparent difficulty.

Naturally I'm working on an ethernet, so my perspective will probably
be a little different.  But that brings up the question: how does
broadcast work in a non LAN environment?  Does anyone actually use it?

Dave

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 00:24:20 GMT
From:      yam@nttmhs.ntt.JP (Toshihiko YAMAKAMI)
To:        comp.protocols.tcp-ip
Subject:   Call for Information on XTP


I hear there is a public domain software to demonstrate
XTP protocol functions, which can be installed on TCP-IP based systems.

I would like to know information about such software, including
availability and how to get it.

	XTP: eXpress Transfer Protocol
	     It is proposed by G.Chesson( Protocol Engines Inc.)
	     It is under discussion in ANSI X3S3.3

Anyone who is kind enough to send information to me,
please mail to yam%nttmhs.ntt.jp@relay.cs.net.

(If this is a wrong place to ask, please let me know it.)

Thanks in advance.
------------------------------------------------------------
Toshihiko YAMAKAMI	NTT Telecommunication Networks Laboratories
* Interests include:	Office Systems, CHI, OSI
	Telephone:	+81-468-59-3781
	FAX:		+81-468-59-2546
	junet:		yam@nttmhs.ntt.jp
	CSNET:		yam%nttmhs.ntt.jp@relay.cs.net
	snail-mail:	Take 1-2356-523A, Yokosuka, Kanagawa 238-03 JAPAN

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Apr 89 8:49 EDT
From:      Bob Stratton <BSTRATTO%NAS.BITNET@CORNELLC.cit.cornell.edu>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Need info on U. of Wisconsin 3798-FAL Product.
*cc: Bob Stratton

          Hello All!

          Is there anyone out there from U. Wisconsin or Wiscnet who
          can point me toward information on the 3798-FAL TCP/IP
          implementation for VM/CMS? (That product number may not be
          right)

          Any information (availability, cost, accurate product name,
          etc.) would be greatly appreciated.

                                             TNX 1.0E+06!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Robert J. Stratton, III   BITNET:   BSTRATTO@NAS
Stratton Systems Design   INTERNET: BSTRATTO%NAS.BITNET@UUNET.UU.NET
Alexandria, VA, USA       USENET:   uunet!NAS.BITNET!BSTRATTO
                          PSTNET:   1-202-334-3638
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"If builders built buildings the way most programmers write programs,
 then the first woodpecker to come along would destroy civilization."
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Apr 89 10:36 CDT
From:      "Michael_Jacobson, Networks Manager, L.S.U." <JACOBSON%SNMRJ.LSU.EDU@CORNELLC.cit.cornell.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   FWD: Undeliverable Mail
I tried to get straight to you but could not get past cunyvm.cuny.edu. Hope you
read the list.

Subject: RE: tcp/ip terminal servers?
To: wingo@Columbia.NCR.COM
X-VMS-To: lsuvax::IN%"wingo@Columbia.NCR.COM"

Hi Dave,

I am the networks manager here at Louisiana State University. We have tried
2 different products that offer lat and tcp/ip telnet access simultaneously.
The first is the MAXserver from Xyplex and the other is the NTS200 from
Micom/Interlan. Both products seem to work really well. The Maxserver is
cheaper if you want more than 8 ports. Its has a chasis that you can hot swap
cards in. Each card handles 8 ports and has its own micro processor. The chasis
has either 5 or 17 slots. One slot is required for the ethernet interface.
One nice thing about the slots is that they also have other boards for doing
things like wide area networking that plug into the same chasis. You can also
plug in redundant ethernet boards if you want. The lat setups can be controled
wit DEC's Terminal Server Manager if you have it or they can be setup from any
terminal port that you put into privilege mode (same a s a decserver 200). The
tcp/ip configurations must be typed in from a terminal port put in privilidge
mode. There is a piece of special software that must be loaded on a VMS machine
called the parameter server that is used to initially load the box. This is the
big difference between the xyplex and the dec servers. The Interlan box has only
8 ports per box and the software is contain on a rom cartridge that must be
purchased seperately. There are different rom catridges for other protocols like
XNS I think. If you want some sales contacts let me know and I will try to dig
them up. I would like any information you have on the annex box and any opinions
you formed about them. Do they require a special load host? We have some here
and they boot from a Multimacs machine that we have here.


                                        Thanks in advance
                                        Mike Jacobson
                                        jacobson%lsuvax.bitnet@cunyvm.cuny.edu
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 08:25:34 GMT
From:      lco@tatooine.cs.duke.edu (Louis C. Olszyk)
To:        comp.protocols.tcp-ip
Subject:   Help with SOCK_RAW

I have been trying to take advantage of the SOCK_RAW
type of socket. Even though I've looked through the
manuals and sources, I'm still not clear on what data
format is needed or what system call to use (ie, do I need to
use an mbuf and do I just use "sendto"). My attempts
so far have failed. I would appreciate any help with this.

thanks in advance.

Louis C. Olszyk - Duke University Dept. of Computer Science
INET:  lco@cs.duke.edu		UUCP:  {decvax, ihnp4}!mcnc!duke!lco
PHONE: (919) 660-6578
U.S. MAIL: 07 North Bldg., Durham, NC 27706-2591  USA

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 10:04:33 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Traceroute....

I got a number of requests from other people who wanted to know if I
found a solution to a problem I thought I had with getting ``traceroute" to
work on a Sun-4 earlier.

Well, the reason was simple. I generated objects for the kernel mods 
required and then I generated a ``new" kernel using the old objects. Sad.
And pretty dumb :-( So the problem is solved. Mea culpa.

					Torben

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 12:49:00 GMT
From:      BSTRATTO@NAS.BITNET (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   Need info on U. of Wisconsin 3798-FAL Product.

*cc: Bob Stratton

          Hello All!

          Is there anyone out there from U. Wisconsin or Wiscnet who
          can point me toward information on the 3798-FAL TCP/IP
          implementation for VM/CMS? (That product number may not be
          right)

          Any information (availability, cost, accurate product name,
          etc.) would be greatly appreciated.

                                             TNX 1.0E+06!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Robert J. Stratton, III   BITNET:   BSTRATTO@NAS
Stratton Systems Design   INTERNET: BSTRATTO%NAS.BITNET@UUNET.UU.NET
Alexandria, VA, USA       USENET:   uunet!NAS.BITNET!BSTRATTO
                          PSTNET:   1-202-334-3638
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"If builders built buildings the way most programmers write programs,
 then the first woodpecker to come along would destroy civilization."

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 13:20:35 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Subliminal (RFC1097)

In article <19890425150305.1.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>, 7thSon@SLCS.SLB.COM (Chris Garrigues) writes:
> Two techniques which I haven't experimented with are (a) to dither the
> message into the background pattern on my window system.  This would
> make the message difficult to read, but isn't that the idea?

The problem is that the human visual system is cued to movement and to
certain kinds of borders. If you use differential dithering patterns you
may or may not be able to see the message at all, particularly if the
size of the message is on the order of magnitude of your background.

Consider the success of copy-protected checks, that use two areas of the same
luminance but a different sized mesh of dots to print a ghostly 'VOID' on the
check... one that can't be seen but will produce a visible interference
pattern with the screen in a copy machine.

Of course this might actually have a subliminal effect. Maybe the anxiety
you feel at payday is NOT just related to the size of your paycheck?
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 15:01:18 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP incompatibility

I had always thought it was specified that the server data port was to
be associated with the IP address of the control connection, except if
PASV came into play.  I made remarks in Host Requirements WG recently
which implicitly assumed this, and no one complained at the time.  It
looks like you're right, though, the RFC doesn't come out and say it in
so many words.  I would suggest that the second paragraph of section 5.2
when interpreted in the context of the first paragraph, takes on a rather
odd flavor if it is not assumed that the IP address is the same.  The
server is supposed to "initiate the data connection from his own default
data port (L-1)" and it seems rather tortured to interpret this as "L-1
at any address".  But yes, this should be clarified.  I'll mention it to
the WG (some have undoubtedly seen your message, too).  In my opinion,
machine B should be deemed broken and machine A is being reasonable, for
the reason you indicated.

In checking this, I noted an error in the last sentence of paragraph 2
of RFC 959 section 5.2.  The words "and the port used" should not
appear.  This is a mistaken holdover from NCP FTP, RFC 542, top of page
34, mechanically translated into TCP jargon.  The approximate
counterpart to a TCP port is a pair of NCP sockets, each of which is
unidirectional; so the socket used in NCP FTP depended on the direction
of transfer.  In TCP FTP the issue doesn't arise since TCP connections
are full-duplex.  The same correction is needed in MIL-STD-1780, last
sentence of section 5.9.2.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 15:01:19 GMT
From:      ciriello@lafcol.UUCP (Patrick Ciriello II)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Suite Available


Greetings:

I am looking for any TCP/IP software (Telnet, FTP, TFTP, PING, FINGER,
etc) that will run on the following machines:

IBM 9375, OS: VM & MUSIC
VAX 11/750, OS: VMS ver. 5.0
VAX 11/785, OS: VMS ver. 5.0
AT&T 3B15, OS: UNIX System V, ver. 2.1

PC Compatible Units, 8088, 80286, 80386

Preferable, I would like to find public domain software that has some
modicum of documentation, some tech support, and some goal of upgrading.

Optimally, the different versions would provide support for VT100, 3270,
and TTY.

I realize that I am probably asking for the moon, but I would appreciate
any information, whether it be public domain or not.  

We have some software at this point .. we have IBM PC/IP for the PC's,
and we have TWG for the VAXen.

I would suggest that the responses be sent to me directly:

BITNET: ciriello@lafayett
UUCP:   lafcol!ciriello

I will compile and summarize and make a posting of this in the future.

Thanks in advance for you support.

Pat Ciriello II
Supervisor of Networking and Tech. Services
Lafayette College

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 18:00:39 GMT
From:      wunder@HP-SDE.SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over ISDN and Satellite?


   For example instead of a T1 terestrial link (which is very expensive
   in Australia) you could link two points with a 56Kb terestrial link
   plus a T1 satellite link. The idea would be to use the low speed link
   for all small packets (or big packets when the link is free maybe) and
   use the satellite for big packets.

"The future is now" as someone used to say.  The routing algorithms in
cisco gateways have been able to do this for a while.  When Uniforum
was in DC, HP had a 56Kbit satellite link and a 9.6 terrestrial link
in parallel between two cisco gateways.  We could watch the CSU/DSUs
and see the small packets go over the terrestrial and the large
packets go over the satellite.

This trick does require the right balance of links.  The BW and delay
of the two links should work out so that the boundary between large
and small is in the mid-size for IP packets (200 bytes?).  If the
boundary is wrong (anything over 2000 bytes goes over the satellite),
then you'll end up with an idle link.

wunder

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 89 21:46:14 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip.ibmpc,rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   Next release of PC packet drivers soon.

Anyone who has any contributions, bugs or suggestions for the IBM-PC
packet driver collection should send them to me.  I'm going to put out
a new release of the packet drivers soon.  This release will include
globally unique handles[1], user documentation[2], Kelly McDonald's
Novell packet driver support, and Karl Auerbach's PCIP packet driver
support.  The last two will be distributed separately because not
everyone will want them.

[1] Required for Phil Karn's TCP/IP package to support multiple packet drivers.
[2] People seem unwilling to read the source when they can't grok the 
    parameters.  I don't understand why...  :-)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
S&Ls get bailouts and that's okay, but poor people get welfare and that's not.

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 01:45:35 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   SUN user telnet bug?

When sun client telnet is in single character, remote echo mode, and
you type return, it sends <cr><null>.  This is fine.

When in line-at-a-time, local echo mode, it sends lines terminated by
<cr><lf>.  This is fine too.

When in single character, local echo mode, and you type return, it
apparently send a plain <lf>.  This is wrong, and troublesome to
some applications who really want to see <cr> or <eol>.  Is there
a fix/patch/new version of SUN telnet?  This bugs seems to be in
the telnets shipped with both 3.5 and 4.0 SUNOS...

Thanks
Bill W
-------

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 07:29:11 GMT
From:      FUSION@UHHEPG.PHYS.HAWAII.EDU (FUSION)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP USING FUSION SOFTWARE FOR ROUTING OUT OF SUBNET

THIS IS AN UPDATE TO OUR INQUERY ABOUT FUSION TCP/IP RUNNING ON VMS
OPERATING SYSTEM WITHIN PRIMARILY UNIX OPERATING SYSTEM ON A SUBNETTED
TCP/IP ETHERNET NETWORKS. AS WE STATED BEFORE, FUSION SOFTWARE DOESNOT
SUPPORT RIP AND THEREFORE WE NEEDED TO HAVE SOME ONE TELL THE OTHER
COMPUTERS ABOUT OUR SUBNET. THE PROBLEM IS NOT FUSION SOFTWARE...ASIDE
FROM THEM NOT SUPPORTING RIP OR SOME DYNAMIC ROUTING. WE TESTED STATIC
ROUTING USING OUR VAX8650 RUNNING ULTRIX AND HAD SOME PROBLEMS...WE
DID NOT ENTER THE STATIC ROUTING COMMANDS FOR ROUTING CORRECTLY  (PROBABLY).
WE DID A STATIC ROUTINE ON A SUN MACHINE AND WE WERE ABLE TO ROUTE INTO
AND OUT OF OUR SUBNET. DOES ANYBODY KNOW A WAY OF JUST ENTERING ONLY ONTO
ONE MACHINE RUNNING UNIX AND LET IT TELLS ALL THE OTHER ROUTERS/GATEWAYS
WITHIN OUR LOCAL NETWORKS WITHOUT ENTERING IT INTO ALL THE MACHINES?

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 13:49:28 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking advice on establishing a LARGE centralized mail system

For what it is worth (two belgian cents = approx 0.0005 dollar..) :

We have established an unified address  scheme here. But we did not find
any way to  allow external correspondants to send mail  to an individual
when  only  knowing   his  name,  *and*  avoid   clashes...  This  seems
theoretically impossible. The sender must *know* and *specify* some more
information to  garantee uniqueness.  So the addresses  used are  of the
form   :  personal-identifier@unit.ucl.ac.be,   where   'unit'  is   the
standardized three or four letter sigle  of the laboratory or service in
which  the person  can  be found.  Of  course, it  is  difficult for  an
external correspondant trying to contact  somebody for the first time to
guess the 'unit' to  be used. On the other hand, clashes  are a very low
probability event, since units never count more than 50 persons.

Implementation : the DNS would be  a marvelous tool for this, since each
unit  could have  and manage  its  own name  server. Halas,  (one of  my
favorite gripes), the arbitrary division  of mail addresses into a local
and  a domain  part makes  it  impossible to  use  the DNS  down to  the
individual  level. So  the  current situation  is  that one  centralized
machine contains a centralized database of mail routing information, and
nearly all domain-addressed mail goes physically (uh, should we say that
about zeroes-and-ones on wires and disks and ...) through that machine.

Alain FONTAINE                       +--------------------------------+
Universite Catholique de Louvain     | If your mail software barks at |
Service d'Etudes Informatiques       | my address, you may try :      |
Batiment Pythagore                   |                                |
Place des Sciences, 4                |     FNTA80@BUCLLN11.BITNET     |
B-1348 Louvain-la-Neuve, BELGIUM     +--------------------------------+
phone +32 (10) 47-2625

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 15:14:26 GMT
From:      rsmith@vms.macc.wisc.edu (Rusty Smith, MACC)
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on U. of Wisconsin 3798-FAL Product.

In article <8904280952.AA12666@ucbvax.Berkeley.EDU>, BSTRATTO@NAS.BITNET (Bob Stratton) writes...

>          Is there anyone out there from U. Wisconsin or Wiscnet who
>          can point me toward information on the 3798-FAL TCP/IP
>          implementation for VM/CMS? (That product number may not be
>          right)

You can contact Mike Wollen at "wollen@vms.macc.wisc.edu or 
wollen@wiscmacc". He can also be reached at 800 543-3201.
Hope this helps.

Rusty Smith			Internet:  rsmith@vms.macc.wisc.edu
MACC Data Communications	Bitnet:    rsmith@wiscmacc
(608)  263-6307			Univ. of Wisconsin @ Madison

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 15:17:38 GMT
From:      rsmith@vms.macc.wisc.edu (Rusty Smith, MACC)
To:        comp.protocols.tcp-ip
Subject:   rewiring and twisted pair ethernet

We are currently starting a campus rewiring of all buildings. It
calls for phone and data jacks in every room wired to the USOC
standard. This was the standard telecommunications needed for 
the campus equipment and went into the proposal for data also. AT&T got
the contract and is just beginning some test buildings.
Now we are finding that Cabletron, Synoptics and possibly others
are using the AT&T standard for connections to twisted pair ethernet.
We would appreciate any replies about other manufacturers' twisted pair
ethernet wiring schemes. It would be nice not to use USOC to AT&T 
adapters later down the line. We are investigating the possiblity
of changing the data jack to the AT&T standard, but this looks even
more difficult since the contract is complete and started. Long range
compatibility seems more important than a short term easy solution.
Any ideas or information would be appreciated. Thanks...

Rusty Smith			Internet:  rsmith@vms.macc.wisc.edu
MACC Data Communications	Bitnet:    rsmith@wiscmacc
(608)  263-6307			Univ. of Wisconsin @ Madison

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 15:22:50 GMT
From:      howard@cos.com (Howard C. Berkowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI


Suddenly, I have insight... :-)

In article <12486384267.18.PADLIPSKY@A.ISI.EDU>, PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes:
> 
>    And for your own interest and amusement, though I wouldn't think of
> bothering the author with it, we might observe that there is a deep
> sense in which the OSI protocols share in the advantage of not being
> invented by ISO.  (They were, of course, reinvented--and badly, as
> witness the fact that the ARPA protocols do indeed offer some "session"
> and a lot of "presentation" FUNCTIONALITY, they just don't overcomplicate
> life by instantiating them in rigidly hierarchical layers. 


>    Oh, by the bye, is the University of the Outer Hebrides convenient to
> Islay?  If so, I'd be glad to visit some time, since Islay is where
> several important facilities in my real field of research interest are
> (e.g., Lagavulin, Laphroaig, and Port Ellen Maltings), and the day and
> a half I spent there in '86 wasn't at all an exhaustive research
> expedition, merely a preliminary dig.


Indeed, conformance testing is quite secondary to these fields; perhaps
we can agree on Laphroaig as a common presentation syntax.  I am continuing
studies into the role of the MacAllen...

Now, there may be a fundamental insight here.  I see an equivalence
relation here between scotch whiskies and network architecture...
I assume you feel that a blended scotch overcomplicates whiskey
by instantiating its components in arbitrarily hierarchical
solutions, which are then mixed without proper definition of the
service interface?

Is it Session or Presentation you consider the equivalent of 
grain neutral spirits?
-- 
howard@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [W] (703) 998-5017 [H]
DISCLAIMER:  Opinions expressed are not necessarily those of the Corporation
for Open Systems, its members, or any standards body.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 15:41:39 GMT
From:      rsmith@vms.macc.wisc.edu (Rusty Smith, MACC)
To:        comp.protocols.tcp-ip
Subject:   Re: Need info on U. of Wisconsin 3798-FAL Product.

CORRECTION     Mike Woollen was spelled wrong. It has 2 o's not 1.

Rusty Smith			Internet:  rsmith@vms.macc.wisc.edu
MACC Data Communications	Bitnet:    rsmith@wiscmacc
(608)  263-6307			Univ. of Wisconsin @ Madison

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 17:35:58 GMT
From:      mliu@polyslo.CalPoly.EDU (Mei-Ling L. Liu)
To:        comp.protocols.tcp-ip
Subject:   SURFNET (CERFNET) Infomation


<<Article 7158 (6 more) in comp.protocols.tcp-ip:
<<From: johnan@ism780c.isc.com (John Antypas)
<<Subject: Need address of Surfnet coordinator
<<Organization: Interactive Systems Corp., Santa Monica CA
<<
--MORE--(39%)Hello Surfers!
<<
<<Would anyone out there on Surfnet (I believe I'm spelling it correctly)

I responded earlier:
<
<SURFNET was the first choice, but the name was already taken, so the
<Southern Cal NSF regional network is now known as CERFNET, which stands
<for The California Education and Research Federation.  The chairperson
<for CERFNET is Susan Estrada, San Diego Supercomputer Center, P.O. Box
<85608, San Diego, CA 92138, estradas@sds.sdsc.edu.  The network publishes
<a newsletter that can be obtained by sending a request to
<armstrongk@sdsc.sds.edu.
 
A couple of updates:
The newsletter can be obtained by sending a request to 
armstrongk@sds.sdsc.edu, not armstrongk@sdsc.sds.edu.
Enquiries about CERFNET can be e-mailed to the same address
or to Susie Arnold (susie@sds.sdsc.edu).

Mei-Ling Liu, Cal Poly SLO

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 20:17:23 GMT
From:      cpj@SUN.COM (Chuck Jerian)
To:        comp.protocols.tcp-ip
Subject:   in re whoever complained about not fragmenting broadcasts

Its a host requirment that broadcasts not be fragmented!
		--cpj

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 89 23:24:25 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   vendor implementations

A good Friday afternoon to all,
			       I'm looking around for TCP/IP implementations
for the following system and was wondering if anyone would care to share
knowledge and/or experiences. The systems are H/P 1000, Prime 50 series(I 
think) and a rather "experienced" (I hesitate to say old) B-7900, which is,
I believe, a Burroughs system, now supported by UNISYS?? (Please note the
question marks, they are indicative of how sure I am of my facts here (:*).
			THanks in advance for any help you would care
	to offer,
		Chris VandenBerg
		ACC
		(chris@salt.acc.com)
		(805)963-9431

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 89 01:57:04 GMT
From:      budden@manta.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: IP based authentication of hosts

In article <291@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
>
>necessarily have to satisfy any particular distribution).  Protect both
>files, so only privileged processes can read them (if you can't
>trust superusers, your security is shot anyway).  Each side of the
>
 Jerry Whitworth was a superuser.

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 89 05:07:01 GMT
From:      rms@saturn.ACC.COM (Ron Stoughton acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN user telnet bug?


	When in single character, local echo mode, and you type return, it
	apparently send a plain <lf>.  This is wrong, and troublesome to
	some applications who really want to see <cr> or <eol>.  Is there
	a fix/patch/new version of SUN telnet?  This bugs seems to be in
	the telnets shipped with both 3.5 and 4.0 SUNOS...

I too am interested in the answer to this question.  We have changed our
RFC-compliant server Telnet to grok <lf> as Telnet <eol> and are about to
distribute this to our customers.  I am inclined to cave into the needs
of our customers rather than stand our ground and be technically right.
However, isn't this stretching the robustness principle beyond its intended
purpose.

Ron Stoughton
rms@saturn.acc.com

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 89 18:28:08 GMT
From:      slevy@POINCARE.GEOM.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  in re whoever complained about not fragmenting broadcasts

> Its a host requirment that broadcasts not be fragmented!

But what's the technical reason for requiring that?

	Stuart

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 89 00:57:39 GMT
From:      digennar@umbc3.UMBC.EDU (Mr. Jerry DiGennaro)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Help with a Wang 7300 VS


The company I work for has an extensive Ethernet that is getting larger
all the time.  At the moment, there are over 500 PC's 18 Novell file
servers, and a VAX 8810 on the network.  Several Tandem and Perkin Elmer
minis are about to joined to the network  along with an
IBM 4341.  TCP/IP is the protocol of choice for inter-machine
communication.  So far so good.

I have been tasked to add a Wang 7310 VS system to this network.  Wang
has been less than fully co-operative with the TCP/IP end of the deal.
We have the Wang on the Ethernet with WSN running.  Does anyone have any
Wang TCP/IP experience?

One of the main problem areas deals with the Ethernet card to go into
the PC to allow the PC to talk to the network.  If we put in the
Micom-Interlan NI-5210 card, the PC can talk to the Novell, and VAX
machines but not the Wang.  If we put in a WLOC card, the PC can talk to
the Wang but not Novell or the VAX.  Both cards can not co-exist in a
PC.  Any suggestions?

PLEASE:  No flames about our choice of Wang.  I didn't make it, many of
us do not like it but we need it.   


Thanks in advance for your help.
-- 
Jerry DiGennaro			digennar@umbc3.umbc.edu
						(301) 266-4150

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 89 18:57:45 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI

Clearly, "grain whisky" resembles Session most strongly,
since it, too, is in the wrong place.

   cheers, map

P.S.  Earnestly suggest you reconsider common presentation notions:
      Not only is Lagavulin the best of the Islays, it's even by some
      minor miracle (doubtless having to do with neglible adverti[z/s]ing
      expenditures) less expensive than Laphroaig--even the 10 y.o.,
      much less the 15 y.o. (which in turn is itself much, much better
      than the 10, albeit nearly half again as expensive, at least cis-
      Atlantically).  But for more detailed analysis, perhaps we'd
      better take it off to the side, since it's remotely possible
      that not everybody on the List wants to know what the second-
      best Islay is (even though "best" isn't actually merely my
      own considered opinion, but is, in fact, the finding of arduous
      research).
-------

END OF DOCUMENT