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 February 1989 (348 messages, 167074 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/02.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 Feb 89 00:12:29 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP et al

Agreed; there is no way to transfer an arbitrary "Vendor" file which
has attributes stuffed in other parts of the file system (like UNIX
inodes) with the current FTP standard with out falling back on an
administrative hack using pre and post-processor's.

Would it be useful to consider a new standard which would allow for a
eXternal File Representation XFR "on-the-wire"?

We have a Central File Store (CFS) at LANL which allows for "user
maintained" control information (file attributes).  This is not XFR by
any means, but it allows VMS, CTSS, etc. systems to save files on CFS
and get them back with the correct attributes.  However, the file is
not transportable between different operating systems.  An XFR would allow
for this.

A "standard" representation of a text file has been defined.  A user
can pre-process the file and store it on CFS in "stext" (standard text)
format.  However, it is up to the user of the file, after he gets it,
to "ntext" (native text) it.  I'm not suggesting this as a mechanism!
Just throwing out some ideas.

Phil

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 00:47:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Loose and Strict source routing

Phil,

Unless I'm badly mistaken, there isn't any guarantee that
a non-source-routed internet packet has a valid source
address. Of course, responses to such a spoofed packet may
not make it back to the origin unless a cooperating gateway
helps out, or the source is on an Ethernet and is operating
in promiscuous mode. I suggest that, if source authentication
is an issue, you will need stronger tools/mechanisms than
avoiding the use of source routing of either type.

The general problem of authentication in the Internet is
very important, applies to many areas including, for example,
various control methods (e.g. network management subsystems)
and will probably require some form of cryptographic protection
to solve. The cryptography need not be used to conceal
information - merely to provide an unforgeable authentication
of the source.

Vint Cerf

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 01:43:52 GMT
From:      mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   first release of IMAP software

The IMAP software is now ready for distribution from SUMEX-AIM.STANFORD.EDU
(internet address [36.44.0.6]).  The IMAP distribution is available by
anonymous FTP from SUMEX as imap/imap.tar.Z .  So, the following commands on
your favorite Unix should snarf things:
	% ftp sumex-aim.stanford.edu
	Name: anonymous
	Password: foo
	ftp> binary
	ftp> cd imap
	ftp> get imap.tar.Z
	ftp> quit
	% uncompress imap.tar.Z
	% tar -xf imap.tar

You should take a look at imap/README before doing anything.  If you connect
to imap and do a "make" it should build all the software.  The two most
important binaries built by "make" will be imap/clients/ms/ms and
imap/servers/imapd/imapd.

Please report any problems to Mark Crispin at mrc@Blake.ACS.Washington.EDU and
to Bill Yeager at yeager@SUMEX-AIM.STANFORD.EDU.

-------

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Feb 89 09:47:02 PST
From:      adelman@TGV.COM (Kenneth Adelman)
To:        jam@radc-lonex.Arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  FTP "STRU VMS" extension
>	  [ text deleted ]

	  [ text deleted ]

>	  The deleted text is not pertinent to what I want to say.
>	  I don't want to swing towards either side of the fence
>	  here. I do raise my eyebrow, ie: Spock ;-), when there is
>	  a discussion going on about adding "machine specific"
>	  things to INTERNET protocols.  For so long so many have
>	  worked so hard to keep things "machine independent".

>	  We do tend, yes even us in the UNIX community ;-), to
>	  forget that we aren't designing things for just our operating
>	  system.  I'm not really sure what all is involved in "STRU-VMS",
>	  but I am wondering if the idea is generic enough that more
>	  than one system could be involved?

    Nope. STRU VMS is designed for one operating system. There is no
way to do it in a transportable way without sacrificing speed, and
there is a need for high-speed transparent VMS-to-VMS transfers. Unix
people might have trouble understanding this problem because the Unix
concept of a file exactly matches the FTP concept of a file and you
can use TYPE I to do high-speed transfers.

>>    I'm not sure this is appropriate to involve the entire TCP-IP list
> >in this discussion.	Anyone interested receiving copies of future
> >correspondance, please send mail to stru-vms-request@tgv.com.

>	  Why not?  This is exactly what this forum is for!  We
>	  are concerned with what is going on in tcp/ip land ;-).
>	  I don't see why discussions of pertenint items should
>	  start splitting off to new places.

    Because I won't want to discuss the merits or disadvantages of
such a protocol. I believe I can get enough VMS TCP vendors to come to
a consensus, and I do not believe that the TCP-IP list is a good place
to discuss the particulars of the protocol extension (i.e. the
encoding of VMS file attributes on the wire).

							Ken
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 01:55:12 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

Once upon a time, there was an operating system called Tenex (and its greater
child, TOPS-20) which lots of sites ran.  In fact, it was the Standard ARPANET
Operating System.  To accomodate its internal format of files, STRU P was
defined especially for that purpose.  To this day, this is the format that
TOPS-20 systems prefer to exchange files.

I see nothing wrong with the STRU VMS proposal, although it would be nice if
they could use the existing STRU P mechanism if at all possible.

I'm a little surprised there isn't a STRU TAR for better Unix file transfers
yet...

-- Mark --

-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 02:53:14 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension


Hey!  What about the STRU PAGE suggestion copied below?  Can someone
explain why it is not an adaquate soultion to the problem?

--jon.

  Date: 30 Jan 89 16:13:33 GMT
  From: sun.soe.clarkson.edu!abstine@tcgould.tn.cornell.edu  (Arthur Stine)
  Subject: Re: FTP "STRU VMS" extension
  To: tcp-ip@sri-nic.arpa

  ....

  Dale Moore & Co at CMU have done this with CMU/TEK FTP. They use 
  STRU PAGE to accomplish the same thing between two machines using 
  CMU FTP. You might want to talk to him about it and find out the 
  internals of it.  (Dale.Moore@moore.fac.cs.cmu.edu)

  art stine
  sr network engineer
  clarkson u

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 04:05:20 GMT
From:      tonym@FLORA.WUSTL.EDU (Tony Mazraani)
To:        comp.protocols.tcp-ip
Subject:   TOS, priority

I was informed that there are people suggesting the use of TOS and
some kind of a priority scheme to provide variable grade service with
some statistical guarantee on top of datagram networks. Could you please
let me know how I can have access to the work being done in this area.
Also, are there any published papers yet?

Thank you for your assistance.

-Tony Mazraani

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 05:49:09 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   While we are debating extensions to the FTP spec...

While we are fighting about STRU VMS, I would like to propose another FTP
extension (and this one I WOULD like to make interoperable with other vendor
FTPs).  We have implemented in our FTP for VMS a non-standard mode
"LZ-COMPRESS" which places an adaptive L-Z data compression module between
FTP (both client and server) and the network.  Why do this you ask??  Well,
there are some sites that are connected to the internet by VERY slow
communication paths (my particular concern was a machine that had effectively
a 4800 baud communication path).  Now L-Z compression usually gets between
50% and 80% data compression (depending on the how structured the data is).
So by turning on MODE LZ we typically see 8Kbaud to 32Kbaud transfer rates
on this pitiful line (which actually makes the line quite usable).

So, I am proposing a new transfer mode LZ in which the data on the data
connection is in L-Z form.  Now if you want to have a specific "MODE LZ"
or want a sub-mode of the already specified FTP compress mode is fine with
me -- but I WOULD very much like to be able take advantage of this most
useful transfer mode when communicating with machines that don't have
our software.

David
-------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Feb 89 13:02:58 MST
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        4bsd-bugs@berkeley.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   IP Timestamp option structure needs work
Description:
	If you pass an IP Timestamp with record route option through
	a Sun mc68000 or sparc machine the route is not recorded.
	
Repeat-By:
	Send an icmp echo with time stamp option and flag == 1 to
	some thing that returns it (cisco router will do, or A.ISI.EDU)
	
Fix:
	------- ip.h -------
*** /tmp/da0293	Wed Feb  1 12:55:19 1989
--- ip.h	Wed Feb  1 12:46:18 1989
***************
*** 77,84 ****
--- 77,90 ----
  	u_char	ipt_code;		/* IPOPT_TS */
  	u_char	ipt_len;		/* size of structure (variable) */
  	u_char	ipt_ptr;		/* index of current entry */
+ #if defined(vax) || defined(i386)
  	u_char	ipt_flg:4,		/* flags, see below */
  		ipt_oflw:4;		/* overflow counter */
+ #endif
+ #if defined(mc68000) || defined(sparc)
+ 	u_char	ipt_oflw:4,		/* overflow counter */
+ 		ipt_flg:4;		/* flags, see below */
+ #endif
  	union {
  		n_long	ipt_time[1];
  		struct	ipt_ta {

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Feb 89 11:22:03 EST
From:      jas@proteon.com (John A. Shriver)
To:        mrc@tomobiki-cho.cac.washington.edu
Cc:        TCP-IP@sri-nic.arpa
Subject:   first release of IMAP software
What's an IMAP?  (It might help to put a copy of README outside the .Z
file, since I don't want to get all that just to find out what it is.)
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Feb 89 12:32:00 EST
From:      jam@radc-lonex.arpa
To:        adelman@tgv.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  FTP "STRU VMS" extension
>From: adelman@TGV.COM (Kenneth Adelman)
>To: braden@venera.isi.Edu
>
>    I was hoping that I wouldn't have to defend the need for a "STRU VMS"
>but here goes...
>
>> The aproach you suggest works against interoperability and therefore must
>> be approached with suspicion.  If STRU VMS, then also STRU MVS?  What if
>> you want to FTP an ISAM file from a VMS to an MVS system? Is this
>> infeasible?
>
>    The idea is to provide a 'standard' way of transfering an arbitrary
>VMS file UNINTERPRETED through the network. There are two reasons for this:
>
	[ text deleted ]

>    2) The need for such an extension to FTP is already recognized by
>       many VMS TCP vendors. What I want is a 'standard' which will
>       allow each of these different *VMS* FTP implementations to
>       speak the same language.

	[ text delete ]

>    This is *NOT* an attempt to solve a very difference problem such
>as FTPing beasts like ISAM files between VMS and MVS. Even if FTP
>contained a specification to allow any of today's VMS file types to be
>FTPed, we're back in the same boat when DEC adds a NEW file type.
>
>> Rather than extend the STRU command of ftp to add "STRU VMS", how
>> about doing it through the SITE command instead?  From RFC959, pg 33:
>
>    I'm aware of the SITE command, but my understanding was that
>the SITE command was reserved for `non-standards', whereas this
>proposal would only be useful as an extension to the protocol. As I
>said above, I'm looking for more than just us to implement this.
>
>    Perhaps what we need to add to FTP is a "STRU O VMS", where O is
>short for operating system, and the resulting structure is the
>VMS-specific one defined...

	The deleted text is not pertinent to what I want to say.
	I don't want to swing towards either side of the fence
	here. I do raise my eyebrow, ie: Spock ;-), when there is
	a discussion going on about adding "machine specific"
	things to INTERNET protocols.  For so long so many have
	worked so hard to keep things "machine independent".

	We do tend, yes even us in the UNIX community ;-), to
	forget that we aren't designing things for just our operating
	system.  I'm not really sure what all is involved in "STRU-VMS",
	but I am wondering if the idea is generic enough that more
	than one system could be involved?

>    I'm not sure this is appropriate to involve the entire TCP-IP list
>in this discussion.  Anyone interested receiving copies of future
>correspondance, please send mail to stru-vms-request@tgv.com.

	Why not?  This is exactly what this forum is for!  We
	are concerned with what is going on in tcp/ip land ;-).
	I don't see why discussions of pertenint items should
	start splitting off to new places.

Joel A. Mussman
jam@radc-lonex.arpa, jam@etn-wlv.eaton.com
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Feb 89 15:32:54 PST
From:      lm@Sun.COM (Larry McVoy)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension
In article <8901312003.AA13471@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes:
>One alternative to the STRU VMS suggestion is to bury a set of
>permitted filters in the remote filename space supported by a
>particular implementation, e.g. something suitably gross like:
>	FTP> bin
>	FTP> put "|encode foo.bar;3" "|decode foo.bar" 

Yuck.  It's stuff like this that security holes are made of.  What about
FTP> put "|/bin/rm -rf /"

You get the idea.  And don't tell me that you would be very careful.  The only
way I'd believe it is if encode,decode,etc are all builtins.  Any additions
that require a popen() or a fork/exec are security problems and highly suspect.
-- 

Larry McVoy, Lachman Associates.			  My opinions are that.
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 08:00:51 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

> > ... (In UNIX terms, encoding == dump, decoding == restore).
>
> In theory, I agree with Phil.  Any type of compression/encryption/encoding
> program that includes O/S-specific file information can have as its output a
> file.  The contents of the file may be transferred via FTP to another machine
> which runs a program to reverse the algorithm to decompress/decrypt/format the
> result into a file.
 
> This approach treats FTP as a bulk-transport mechanism, NOT as an intelligent
> file-transfer mechanism that converts between file representations, but is
> handy for several applications, such as distributing software among like-minded
> O/S (the compressed .z files under UNIX come to mind.)

    The problem is that the market recognizes a need to an intelligent
file-transfer mechanism which isn't any harder to use than FTP.

> The first purpose of the SITE VMS or STRU VMS command is to allow a
> pre-specified two-step process to be performed automatically within the FTP
> command to each file AS IT IS TRANSFERRED, where this process is so common that
> it might be applied to every file in a directory.  This eliminates the two-step
> process, the problems of storing or naming an intermediate file, and the
> problems of applying this process in automated scripts or to entire directory
> trees.

    Understand that 'building' the 'filter' program into FTP isn't enough.
We need a way of determining if the receiving FTP will decode the file before
we encode it. Yes, the "SITE" command could be used for this.

> Second, if you are implementing an O/S-specific command, I applaud the attempt
> to have it be the same across multiple TCP/IP implementations, to improve
> interoperability.  Since you are trying to specify a useful VMS "protocol
> extension" as an ad-hoc standard, you might consider including not only the RMS
> headers, but flags to indicate compression and/or encryption that might be
> optionally implemented.  Or a field to specify a procedure, command file, or
> program to be executed upon completion of each individual file transfer to
> perform these and/or other conversions.

    Actualy ENCRYPTION and COMPRESSION should probably be a MODE command.
There is already defined a standard for run-length data compression
(MODE C) which the server on IU.AI.SRI.COM implements for those would
would like to test it against their implementations. Our FTP also has
the Unix 'comress' LZ-compression built in as a non-standard extension
called "MODE LZ" (try picking up a file in MODE LZ from IU.AI.SRI.COM
and uncompressing it on your Unix machine; actually, this will only work
in TYPE I, because otherwise the transfermation LF->CRLF->compressed(CFLF)->
network->decompress(CRLF)->CRLF->LF won't work).

    Note MODE LZ does not conflict with STRU VMS, and they can be used together
to increase performance over most slower-than-ethernet speed lines.

    No flames, I'm not arguing for a standard for this. But, we
implemented it because our customers asked for it.

								Ken

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 18:10:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  FTP "STRU VMS" extension
Joel Mussman raises a very good point.  Historically, open systems
protocol standards, such as the TCP stack, are careful to be universal.
To that end, standardizing the VMS-specific facility constitutes a
philosophical deviation.

It is, I believe, warranted; however, we may want to include a concern
for any other such deviations.  Should the new standard attempt also to
solve MVS-specific, or Unix System V.3 or Unix BSD-specific issues?

Probably.

Dave

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Feb 89 16:46:44 EST
From:      jam@radc-lonex.arpa
To:        tcp-ip@sri-nic.arpa
The following are comments to a private reply I made to Ken after
my posting of this morning.  I feel the subject bears discussion
by the tcp-ip community.

>From: adelman@TGV.COM (Kenneth Adelman)

>>	  My statement still stands about adding machine specific
>>	  protocols to INTERNET definitions.  I would say the same
>>	  thing about UNIX here.  If the need is that specific,
>>	  perhaps the VMS people should look at creating their own tool,
>>	  such as some UNIX vendors built NFS.
>
>    "some UNIX vendors" is SUN, and NFS is presumable Rev 2 of the NFS
>spec (what most people call NFS). Note that Rev 3 of the specification
>includes extensions such as arbitrary attributes attached to files,
>which SUN added at our request. I.e. NFS isn't tied to Unix either.
>
>    Look at what happened with other "UNIX-specific" tools, like the
>'R' services. Yep, we implement them for VMS because the market
>requires it. I doubt the market will require Unix machine understand
>VMS file...

	Yes, I realize NFS is not limited to UNIX.  And you won't find
	any disagreement from me on the necessity to implement the
	defacto standards on other machines due to market insistence.
	That wasn't quite my point.

>    Anyway --- exactly what I'm proposing is that the VMS people
>create their 'own' tools, STRU VMS, for transfering files in a
>standard way between VMS machines, just like the "UNIX" people
>invented R-services, NFS, etc, for performing those functions between
>Unix machine.

	Ah, that is much closer to my point.  But you see, when
	implementing vendor specific protocols, it may not be in
	our best interest to attach them to the supposedly independent
	INTERNET protocols.  It sort of goes against the grain.
	And that is what needs to be hashed out by the community:
	do we add them directly to our "generic" protocols?  or do
	we make people write vendor specific packages to do the
	job along side of the INTERNET tool (ie: ftp, telnet) specifications?

	You see, if you want a fast file transfer protocol to go
	just between VMS machines, perhaps the judgement will be
	that you have to create your own version of a file transfer
	protocol, not attach additions to the generic one the
	rest of the world is using.

	I'm not saying one way or the other; I'm just saying let
	the world decide if this type of addition to INTERNET
	protocols (VMS or other vendor dependent) is a justifiable
	policy.  Or at least let the committee decide...

	You may want to let that battle rage before you start
	deciding what the protocol specifications will be.

Joel A. Mussman
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 11:48:23 GMT
From:      jv@mhres.mh.nl (Johan Vromans)
To:        comp.protocols.tcp-ip
Subject:   Question on Telnet and CR/LF handling

Sorry if this has been asked before, but ...

I'm using several Unix systems, and access them via TCP/IP. I use
both a Macintosh with NCSA Telnet and a terminal connected to a
Bridge CS200 terminal server.

My problem is as follows.
When I run an application on the Unix machines which
switches off CR to LF mapping on input (e.g. stty -icrnl), some
of the systems behave correct, but others don't.

The Telnet protocol, as defined in RFC854, specifies that the
sequence CR-LF is to be treated as a single newline, and that
CR-NUL must be used where a CR alone is desired. NCSA Telnet lets
you specify this, but the CS200 does not.

I did a simple experiment. In the columns, CR-NUL means: NCSA Telnet
sends CR-NUL when the CR key is hit, CR-LF means: NCSA Telnet
sending CR-LF, and CS200 indicates access via the Bridge CS200
terminal server.
"ok" means the application can tell which key (CR or LF) was hit,
"-" means: it can not (it only sees a LF).

   System	CR-NUL	CR-LF	CS200
-------------------------------------
1. Ultrix 3.0	ok	ok	ok
2. UTX 2.0	ok	-	ok
3. HPUX 5.3	ok	ok	ok
4. HPUX 6.2	ok	-	-
-------------------------------------

I can understand that CR-NUL works ok for all systems. I can
understand that systems 2 and 4 adhere to RFC854 and that an
application cannot switch off CR to LF mapping because the
telnet protocol has already translated it.
I don't understand why systems 1 and 3 allow the application to
do so, in spite of RFC854.
And I cannot understand why systems 1, 2 and 3 can be used via
the CS200, but not system 4.

Can anyone shed some light into this darkness?

Please reply by E-mail, I'll summarize if relevant.

Thanks,

	Johan
-- 
Johan Vromans			 jv@mh.nl via european backbone (mcvax)
Multihouse [A-Za-z ]* [NB]V			uucp: ..!mcvax!mh.nl!jv
Gouda - The Netherlands				  phone: +31 1820 62944

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 13:36:39 GMT
From:      rcb@cccvs1.ncsu.edu (Randy Buckland)
To:        comp.protocols.tcp-ip
Subject:   Proxy arp

Does anybody know where I can get a copy of proxy arp code for either
an IBM PC/RT V2.2.1 or an Ultrix system V3.0?

Randy Buckland
rcb@ncsuvx.ncsu.edu

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 14:20:24 GMT
From:      kchon@secola.Columbia.NCR.COM (Kun Sop Chon)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Remote Peripheral Access

We(our group) try to build an End-to-End solution for TCP/IP Local Area
Network.  The hardware configuration for this system will include Unix
mini computers(as server or client), Unix PCs(client), and DOS PCs(client).

One of thing, We like to include in this system is a remote printer access.
In other words, any clients can submit printing jobs on server computer via the TCP/IP network, moniter the printer, and cancel the job if he/she wants.

If any of you know TCP/IP software package (perhaps NFS) allows me to do
these functions please let me know.  If you prefer to call I can be reached
at (803) 739-7708 during 8 to 5 in Eastern Standard Time.

There is the Novell package that allows one to print from DOS client
machines to a Unix server machine but not from other Unix machine.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 16:42:45 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: terminating connections

TCP and ISO TP handle the closing of a connection differently because of
different assumptions about the environment in which they will be
embedded.

TCP assumes that it (alone) is responsible for the reliability of the
data transport; a user application which doesn't want to be concerned
with transport reliability may be built directly on top of it.  This
might even be an application which has only a one-way data flow.  The
application can just hand a lot of data to the TCP module and the give
the module a command like "when you are done sending the data, close the
connection".  So TCP better be sure that all the data has been correctly
received by the receiver befor the connection is closed and the TCP
resources are deallocated.

ISO TP assumes that it is in the middle of a protocol stack.  It is
responsible for ensuring reliable transmission (let's not argue about
this phrase - I know it is not literally correct) but that higher layers
of protocol will be doing their own handshaking to be sure their
resources are not prematurely deallocated.  In particular, since the
Transport layer "knows" that the Session layer will perform a handshake
which must be completed before either Session entity asks the Transport
layer to close the connection, no value is added by having the Transport
entities also shake hands; the pipe is truely empty when the "Close
Transport" command comes down from Session.

Hope this helps,
Alex McKenzie

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 17:20:37 GMT
From:      booloo@lll-lcc.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Obtaining internet addresses

---

	Is it possible (under Ultrix 2.0) for a server to obtain the internet
address that the client used to contact the server?  My need to know this is
based on the following situation:  I have written an ftp gateway server which
we would like to gateway to two machines.  User should be able to specify
either machine using the normal ftp client syntax:
	
		ftp mach1 
		    or
		ftp mach2

The host table on the client machine will contain distinct internet addresses
for mach1 and mach2; however, they will have to resolve to the same physical
address since there is only a single ethernet interface on the gateway machine.
So, if the ftp server had some way of determining the internet address that was
used to contact it, the server could gateway to the appropriate machine.
	My guess is that, even if this information did exist, there is no way
to get at it.  In either case, if anyone has any suggestions as to how I might
solve this problem, I will heap praise upon thou.
	Thanks for reading this.
mb

-- 
uucp:  {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo
arpa:  booloo@lll-lcc.arpa

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 18:45:36 GMT
From:      sbradley@mipos3.intel.com (Seth Bradley ~)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Testing NFS performance

I am looking for bechmark programs that test the relative performance
of NFS fileservers.  I am particularly interested in simulating requests
from several clients simultaneously.  Any help would be appreciated.


-- 
UUCP:  {dalek|decwrl|hplabs|oliveb|pur-ee|amdcad}!intelca!mipos3!sbradley
Phone: (408) 765-4147

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Feb 89 4:41:04 EST
From:      Phil Dykstra <phil@BRL.MIL>
To:        tcp-ip@sri-nic.arpa
Subject:   Instability in the Core
Tonight I was trying to talk to some machines on XEROX-NET (net 13), and
once again was hit with oscillating Net-Up/Net-Unreachable.  This has been
happening to me for the past several days for net 13 as well as several
other nets (FYI, I'm 26.2.0.29).

We have been getting EGP info from the RESTON-DCEC Butterfly (26.21.0.104).
I started watching tonight to see why these routes kept appearing and
disappearing and found major unrest in the routing information we were
getting.  Here are nine consecutive EGP routing updates (taken at three
minute intervals).  They span 0400 EST.

	Int  Ext Routes (~A   B   C)
	 5   95   479
	 6   85   536
	 5   95   401
	 6   86   598    17  333  263
	 6   84   507    15  266  241
	 5   94   456     8  270  193
	 6   91   599    16  335  263
	 4   93   453     8  266  194
	 6   87   580    17  321  257

The fields are number of internal and external EGP gateways, total number
of routes, and the approximate number of class A, B, and C (approx because
this includes a few of our fixed routes).  I have complete EGP dumps for
the last six updates if anyone wishes to study the changes.

It really bothers me that the number of class A networks could double/half
every three minutes!  There is also a 10% to 50% change in the total number
of routes every three minutes.  One wouldn't expect the number of internal
EGP gateways to change so fast either [thought the LSI-11's used to flop
like that too].

It is nearly impossible to get data through when the routes come and go
this fast.  I realize that the Butterfly folks are probably working on
this, but I wasn't sure everyone was aware how bad things are right now
(I recall one other TCP-IP note about it).  Is there anything we can do
to help diagnose this?

- Phil
<phil@brl.mil>
uunet!brl!phil
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 89 23:54:00 GMT
From:      martillo@cpoint.UUCP (Joacim Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnets on an unsubnetted network

I am not sure I understand the problem.  Perhaps, I am wrong but
I would consider subnetting a useful administrative kludge when
I have several physical networks but one network number.

With such understanding gateways between two subnets of one
network number should not behave much differently than gateways
between two networks with two different network numbers.  I would
not want my gateway to forward IP broadcast packets from one
network or subnet to the other network or subnet.  That just allows
little sins to turn into big sins.

Now if I have hosts that understand subnets and hosts that do not
understand subnets on the same physical network.  I would expect
the hosts that understand subnets to use the subnet IP broadcast
and hosts that do not understand subnets to use the standard
network IP broadcast.  I would expect the subnet understanding
hosts to understand all IP broadcasts while the hosts which do
not subnet would not understand subnet IP broadcasts.  Such is
life and may be acceptable, otherwise you have to run subnetting
software on all machines.

Now if I understand the case presented, you have gateways which
understand subnetting and on one side of each gateway you have hosts
which understand subnets while on the other side of each gateway you
have hosts which do not understand subnets and there is but one network
for all the hosts which do not understand subnets. 

On the subnetted side, life is simple.  A given host either arps IP 
address on the subnet or sends IP packets to the gateway when the 
destination IP address is not on the same subnet.  

On the unsubnetted side, life is rotten.  Suppose a host which does not
understand subnets wants to send IP packets to a subnetted host.  This
host will assume that the subnetted host is on the same physical network
and will arp it.  Unless the gateway on the subnet host can do proxy
arp, there will be no response to the original arp request and the IP
address will not be resolved.  If the non-subnetted hosts can be
pursuaded to send IP packets with unresolved IP addresses to a gateway,
it would be possible to establish communication but there would be no
obvious basis on which to choose to which gateway to send the packet.  I
suppose you could depend on ICMP redirect to fix this but it seems
rather gross and lots of hosts ignore ICMP redirect so that an IP packet
might always be sent to the wrong gateway first which would then send
the packet to the right gateway.  The bottom line really is that in your
network hosts which do not have a subnet address should still be doing
subnet routing, and until you get the appropriate software you will have
problems. 

As for the gateways, as long as they understand subnet routing properly,
it should be possible for one interface to be attached to a subnetted
physical network with appropriate subnet mask while the other interface
is attached to an unsubnetted physical network. 

By the way, subnetting should be just as possible on a class C network
as on a class B network.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 00:18:43 GMT
From:      ncs@srhqla.UUCP (Sekar)
To:        comp.databases,comp.dcom.lans,comp.lsi,comp.protocols.tcp-ip,comp.software-eng,comp.std.internat,comp.std.misc
Subject:   Re: Network Definition Language

In article <153@qusunb.queensu.CA> fokas@qucis.queensu.CA (Elias Fokas) writes:
>
>                                  Abstract
>
>                         Network Definition Language (NDL)
>

Unisys (Detroit,MI) has had this language ( called NDL ! - same expansion )
on all its (Burroughs) mainframes with proprietary OS ( MCP - master control
program) for many,many years.
I know it handles some ( not all ) of your conceptual requirements.

Hope this helps.

- sekar

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 00:32:52 GMT
From:      martillo@cpoint.UUCP (Joacim Martillo)
To:        comp.protocols.iso,comp.std.internat,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Layer Encapsulation in OSI

In article <2016@cpoint.UUCP> martillo@cpoint.UUCP (Joacim Martillo) writes:
>Anyone know of any references to layer encapsulation in official
>OSI or CCITT documents.  The problem is as follows:
 
>LLC type II is reliable and one might want to provide security
>on a per logical link basis,  Unless you want to provide reliability
>in the security layer itself, to make sure that applications which
>run in a secure environment, you want to put the security layer
>between LLC and the MAC layer, but at that point in the stack
>the protocol software should only be looking at the MAC addresses
>and security cannot be provided on a per logical link basis.
>And if the security layers lives at the top of LLC, then the
>security layer has to provide reliability.  
 
>I vaguely remember having this problem at Bell Labs when working
>on Data Teleconferencing and the solution was layer encapsulation
>where the security procedures would encapsulate the protocol
>layer, but I simply don't remember where this was described in
>the CCITT or OSI documents.  If someone could give a pointer,
>I would be grateful.

I am following the current deliberations of the 802.10 committee on this
issue.  Tony Bono had what I consider a good original proposal for an
architecture to deal with the issue.  Apparently, the committee could
not shoot down the proposal, but because he did not give a detailed
functional specification (which was not what I understood to have been
originally requested), the committee decided that they would only
provide security procedures at the boundary between LLC and the MAC
(based on pairwise MAC addresses) and not at the boundary between the
Network Layer and LLC based on LSAP/DSAP pairs for a given MAC layer
connection.  Personally, I can think of many reasons why one might want
to provide pairwise LSAP/DSAP security rather than simply point-to-point
MAC address based security.  It seems to me perfectly reasonable that
Network Management communications streams, OSI communications streams or
TCP/IP communications streams might all require different security
procedures at the boundary between LLC and the network layer. 

Personally, I would think distributed multi-level security would be a
nice thing.  Providing security procedures on a per LSAP/DSAP basis
would give the possibility of multi-level security at the link-layer, so
that a given host might be able to realize that a given data stream from
a host was trusted at a secret level because the user had logged into
the console in a room guarded by guys with machine guns while another
data stream from the same host was not trusted at all because the user
had dialed in from outside. 

I see this situation all the time.  Everytime someone wants to
incorporate some new idea into OSI which actually give some reason to
switch from TCP/IP to OSI, it gets shot down at the committee level. 
Now I understand why the best standards are those which were ad hoc
standards first, and only much later standardized by the international
committees.  Any comments?

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 01:31:58 GMT
From:      mhampson@wpi.edu (Mark A. Hampson)
To:        comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   ATT 3b2/400 and TCP/IP

We have recently implimented a campus-wide TCP-IP network and have
several AT&T 3B2/400 machines running S5.  These machines each have
a transever port.  Currently we have software to impliment '3BNET'.
(Yes, the inventors of UNIX did not include any TCP-IP support).

I am wondering if anyone has heard of any TCP-IP software for this
machine.  

Please respond via E-Mail to:
				mhampson@wpi.wpi.edu (internet)

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Feb 89 12:07:38 EST
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        Mark Crispin <mrc@Tomobiki-Cho.cac.WASHINGTON.EDU>
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Unix TCP connectivity problems

Mark et al,

The CMU version of the pseudo terminal (pty) driver for 4.3BSD based Unix (or
for Mach Unix) has the concept of detached jobs. For this reason, it is not a
big deal to lose a network connection for Mach systems (assuming you are
running the CMU modified telnet daemon which uses the CMU pty driver).

For programs that use the network, you can detect a problem with an aborted
connection by checking errno which is documented in intro(2).  You will
get an errno of ENETUNREACH, ENETRESET, ECONNABORTED or ECONNRESET
(most likely).

But for general transparent network support of terminal sessions, the concept
of a detached terminal is needed. We have had this concept since 4.0BSD Unix
before the days of TCP (we used it for Xerox BSP/PUP 'Chat' connections).

-Rudy
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 14:27:38 GMT
From:      mhampson@wpi.edu (Mark A. Hampson)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   TCP-IP for AT&T 3B2's


 would like to take this oportunity to thank the folks at
Bell Labs for taking such good care of me on the TCP for
3B2 problem.

To summarize:
There is a package (Enhanced TCP/WIN 3B) from the Wollongong Group
that is sold through AT&T that uses the 3BNET hardware and gives
TCP/IP support.  The package is refered to as 1040-TE1 for S5R2 and
1040-TE2 for S5R3.

Thanks again.
Mark A. Hampson
(internet) mhampson@wpi.wpi.edu

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 15:41:12 GMT
From:      danno@onm3b2.UUCP (dan notov)
To:        comp.protocols.tcp-ip
Subject:   r* Command Incompatibilities?

I am running the following on a TCP/IP network:
	An AT&T 3B2/310 SVR3.1 with WIN/3B
	An AT&T 6386E WGS SVR3.1 with Micom/Interlan NP622A

I have found that rlogin from the 3B2 to the 386 always prompts me for a
password.  Is this normal?  I do have both hosts defined in
/etc/hosts.equiv and ~/.rhosts,  so I'm wondering if there is a problem
elsewhere.  However, the remote shell commands work properly.

On another network with a VAX/VMS & 3B2/UNIX (both WIN s/w),  rlogin works as
advertised.

Is there some incompatibility between the MICOM & WIN versions of these
commands?  Inquiring minds want to know...

--
danno

Daniel S. Notov
Ogilvy & Mather, Inc.
New York, NY				uunet!onm3b2!danno

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 16:28:01 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

I think we should either

	attempt to solve the interoperablity problem using:
	
		an eXternal File Representation?
		Pre and post-processing options? (tar; compress/uncompress;
		    tar for example)
		.
		.
		.
		with FTP.

	or, else realize that it is an os specific problem, and
	interoperablity is not the goal. Maybe "we" want a 'vcp' for
	VMS copy, etc.  The vendor and it's third parties could come up
	with the standard for that.  They probably already have one, it
	just needs to operate on top of TCP/IP instead of DECNET.
	
Phil Wood,  cpw@lanl.gov

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 16:58:06 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

One more thing and I'll leave it to the experts.

Rather than STRU VMS, make it STRU {LOCAL|EXOTIC}.  If two VMS hosts
were "inter-operating" than either option would work correctly.

	STRU LOCAL means that files transfered from the local host
	to the "exotic" host (I could not use Foreign or Remote because
	of File and Record) would be in a standard-for-local-operating-system
	format (SFLOS) ('tar;compressed' for UNIX, 'cpio;???' for ATT, ...).
	Conversely, files transfered to the local host would be in this
	"standard" format.  The "Exotic" host would have to understand
	this "standard".

	STRU EXOTIC means that the structure for a "file" transfer
	would be in standard-for-remote-operating-system  (SFROS) format.
	
That way we don't run out of single character mneumonics for all the
"Open" operating systems coming down the line.

Phil Wood,  cpw@lanl.gov

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 17:07:38 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Unix TCP connectivity problems


Mark et al,

The CMU version of the pseudo terminal (pty) driver for 4.3BSD based Unix (or
for Mach Unix) has the concept of detached jobs. For this reason, it is not a
big deal to lose a network connection for Mach systems (assuming you are
running the CMU modified telnet daemon which uses the CMU pty driver).

For programs that use the network, you can detect a problem with an aborted
connection by checking errno which is documented in intro(2).  You will
get an errno of ENETUNREACH, ENETRESET, ECONNABORTED or ECONNRESET
(most likely).

But for general transparent network support of terminal sessions, the concept
of a detached terminal is needed. We have had this concept since 4.0BSD Unix
before the days of TCP (we used it for Xerox BSP/PUP 'Chat' connections).

-Rudy

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 17:50:47 GMT
From:      chm@nbires.nbi.com (Paul Chmielewski)
To:        comp.protocols.tcp-ip
Subject:   IP over X.25 (request for info)


We're in the process of putting together an IP-over-X.25 package for our
4.3 derivative UNIX systems.  We currently have an intelligent communications
card (VME bus) on which we run X.25.  The UNIX kernel and networking subsystem
are pretty much straight from BSD4.3.  We plan to write a network interface
driver to interface with the X.25 code.  I'm interested in hearing from people
who have already done this or something similiar.  I'd like to hear about 
problems you ran into, what type of performance to expect, or what documentation
you found useful.  I've read RFC 877, but it doesn't seem to address all of the
issues.

I do have one specific question concerning the internet address to virtual
circuit pairings.  Is there a standard mechanism for telling the called end
of a virtual circuit what the internet address of the calling host is?  I'm
thinking that each X.25 VC or PVC will be configured as a point-to-point link.
The machine initiating the call can fairly easily map the pt-to-pt IP addresses
to the virtual circuit.  But I'm not sure how the machine accepting the call
would do this.  One possibility would be to include the initiating machines
IP address in the Call User Data Field after the protocol demultiplexing octet.
Any comments??


Paul Chmielewski		
NBI Inc., Boulder, CO		chm@nbires.UUCP or chm@nbires.NBI.COM
(303) 938-2926

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 19:15:26 GMT
From:      zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: Dial up SLIP

In article <32958@tut.cis.ohio-state.edu> Bill Wisner <wisner@cis.ohio-state.edu> writes:
>A protocol called SLFP, developed at MIT, has been added to the Atari ST port
>of KA9Q TCP/IP by a University of Michigan person, and has been implemented
>on Michigan's MERIT network. It allows dial-up Internet access like SLIP,
>but with an interesting twist. When an ST with KA9Q dials into MERIT, both
>ends automatically begin talking SLFP. But MERIT dynamically allocates
>the ST an IP address. The address assigned is different every time a
>connection is made.

Howard Chu (umix!hyc), myself, and Bill Doster 
(Bill_Doster@um.cc.umich.edu) have worked on slfp with ka9q.  The net 
result is that MERIT users possessing a modem and a PC can ftp files 
and use telnet.  

The files were available for anonymous ftp from umix.cc.umich.edu.  
Non internet people might try a public access unix system available at 
(313) 994-6333.  



-- 
  Jon Zeeff			zeeff@b-tech.ann-arbor.mi.us
  Ann Arbor, MI			mailrus!b-tech!zeeff

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu,  3 Feb 89 00:33:42
From:      Tod.Shannon@DRAGON.CIMDS.RI.CMU.EDU
To:        tcp-ip@sri-nic.arpa
Cc:        stru-vms@tgv.com
Subject:   Re: Using Page structure

We used the page structure for the CMU-TEK FTP because we wanted to stay
nominally within the FTP spec.  I don't think the page structure is really
the way that we should go, since it really is a TOPS-20/Tenex-ism.  The
255 (if I remember correctly) byte limit per page isn't really suited to
VMS; if we are going to make some VMS specific changes to the spec, they
should be oriented towards efficiency as well as functionality.

On the matter of having filters, I think the real world demands a better
solution.  A two step process for special file transfers would be awkward and
confusing; I think if filters became a "standard" that it would be a standard
soon retired to the dusty shelves of disuse.

It would be nice if everything could be designed and implemented in a vacuum,
and if everyone used the same "standards," and if all the "standards" were
of excellent quality.  Unfortunately, we don't live in a vacuum, standards
are often ignored (for good and bad reasons), and they are often of poor
quality.

I think it is pointless to discuss whether or not the addition of VMS specific
changes to the FTP spec. is appropriate.  The need for the functionality exists
and it is unreasonable to believe that vendors and other institutions will
discontinue efforts in support of such a need.  It is our job to try to meet
the functionality requirements in the best way that we can.

							-Tod Shannon
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 20:25:55 GMT
From:      ted@blia.BLI.COM (Ted Marshall)
To:        comp.protocols.tcp-ip
Subject:   IP Encapsulation on HP 3000/9000 computers


I have heard that HP's TCP/IP implementation, when sending over Ethernet,
uses IEEE802.3 data link format (i.e. packet length, SSAP and DSAP)
instead of Ethernet V2 format (i.e. protocol type) like most Unixes.
Can anyone confirm or deny this? Specifically, I need to know if one
can put an HP machine and one of our own boxes (which will only speak
Ethernet V2 format) on an Ethernet and have them communicate.

If the answer is that the HP box will only talk 802.3 format, can
someone suggest an inexpensive bridge/router/etc box that could translate
between the two?

Thank you in advance.

-- 
Ted Marshall       ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU
Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 89 20:36:15 GMT
From:      booloo@lll-lcc.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Re: Obtaining internet addresses

In article <2266@lll-lcc.llnl.gov> booloo@lll-lcc.llnl.gov.UUCP I write:
>
>The host table on the client machine will contain distinct internet addresses
>for mach1 and mach2; however, they will have to resolve to the same physical
>address since there is only a single ethernet interface on the gateway machine.

After looking through some source code, I have determined that it isn't 
actually possible to have two ip addresses resolve to a single physical
address (at least in the case of a vax running Ultrix).  So my question 
can't be answered (at least to my liking).
mb



-- 
uucp:  {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo
arpa:  booloo@lll-lcc.arpa

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 02:24:32 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: STRU VMS

> Rather than STRU VMS, make it STRU {LOCAL|EXOTIC}.  If two VMS hosts
> were "inter-operating" than either option would work correctly.
 
> That way we don't run out of single character mneumonics for all the
> "Open" operating systems coming down the line.

    Just a STRU EXOTIC isn't enough, because we'd like to be able to
send a STRU VMS on client startup. If it is accepted, then we use that
mode by default. The problem with STRU EXOTIC is that something else
might accept it.

    I think that "STRU O VMS" is a good idea, where "O" stands for Operating
System dependent. There are two reasons for this:

    1) It would be a big help to Wollongong not to call the result STRU VMS
       since they already have software in the field which uses this with
       a non-standard encapsulation. Calling it something else would give
       them compatibility between releases.

    2) We don't run into the 26 character limit (for those people who only
       look at the first character).

    Any objections to this????

							    Ken

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 03:18:01 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Interactive game playing over an internet network

I am amazed that there don't seem to be protocols and programs for 
supporting game playing over an internet network. The sort of thing I 
envisage would allow a client program to connect to a game control 
server. They could then start a game, or join an existing game. The 
protocol would include the ability to send move information to the 
control server, receive state-of-game information from the control
server, send text information to opponents, opponents and partners, 
just partners [this last not allowed in some games, e.g. Bridge!].
Given the appropriate control server it should then be easy to modify 
programs like the Sun gammontool and chesstool to provide nice human 
interfaces to various games.

I really feel that something like this would be extremely worthwhile 
in demonstating the sort of things that you can do with networks. I 
try to convince people that interactive computer networking doesn't 
have to mean that you use the network to log into an interactive 
account on a remote machine. In fact logging in over a network tends 
to be both a horrible security problem and a very inefficient use of 
network resources. But when you try to describe other ways that a 
network could be used interactively, there aren't a lot of examples: 
remote disk and file access and the talk/phone system (which isn't 
used a lot). I am sure a system such as I propose would inspire people 
with interests in worthwhile activities like remote education,
learning through serious role playing and computer conferencing.

Anybody else interested? Any existing work? Should we write an RFC?

Bob Smart, CSIRO Division of Information Technology, Australia
           smart@ditmelb.oz.au (or smart%ditmelb.oz.au@uunet.uu.net)

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 05:59:49 GMT
From:      jdm@starfish.Convergent.COM (John McLean)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers

From article <6402@blia.BLI.COM>, by ted@blia.BLI.COM (Ted Marshall):
> 
> I have heard that HP's TCP/IP implementation, when sending over Ethernet,
> uses IEEE802.3 data link format (i.e. packet length, SSAP and DSAP)
> instead of Ethernet V2 format (i.e. protocol type) like most Unixes.

This is correct; the encapsulation used by the HP's is IEEE802.3.
They also use PROBE for address resolution (instead of ARP).  In
addition, HP has their own set of user-level programs (instead of
TELNET and FTP).  I guess HP really did want to have it *their* own
way!

We have been able to get our UNIX hosts to communicate with a
HP3000/CLASSIC by doing the following:

	1. Purchasing a gateway server box from cisco.  This box
	   does the conversion from Ethernet 2.0 to IEEE802.3
	   encapsulation.  (The gateway server understands both
	   PROBE and ARP, however, we are currently operating
	   from manually-created IP-to-Ethernet address entries.)
	
	2. Purchasing the WIN/HP product from Wollongong.  This
	   package includes TELNET and FTP.  It runs on the
	   HP3000/CLASSIC model only.  (We also have two
	   HP3000/SPECTRUM systems; the WIN/HP product does not
	   run on these systems.)

All of our HP systems are on the same physical ethernet as the
UNIX hosts.  Of course, this means that all data from the UNIX
systems to the HP systems goes thru the net twice; the additional
overhead has not caused a problem yet.


John McLean			jdm@starfish.Convergent.COM
Systems Engineer
Convergent Technologies

---

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Feb 89 12:53 EST
From:      EWOLF@rcca.bbn.com
To:        tcp-ip@sri-nic.arpa
Cc:        ewolf@rcca.bbn.com
Subject:   Remove from list
Please remove my name from the tcp-ip distribution list.

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 07:53:40 GMT
From:      JOHN@MATHOM.CISCO.COM (John Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers

Yes, it is my understanding that they need some sort of translator. The
company I work for makes a router device which also can act as a
802.3/V2 converter it supports both Probe & ARP. If you would like
more information we can send you something in the mail. Make a request
to 'customer-service@cisco.com', as I am about to leave town for a while.

John Wright
Customer Engineer
cisco Systems, Inc.
1350 Willow Rd
Menlo Park, CA 94205
(415) 326-1941
-------

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 08:33:42 GMT
From:      Tod.Shannon@DRAGON.CIMDS.RI.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Using Page structure


We used the page structure for the CMU-TEK FTP because we wanted to stay
nominally within the FTP spec.  I don't think the page structure is really
the way that we should go, since it really is a TOPS-20/Tenex-ism.  The
255 (if I remember correctly) byte limit per page isn't really suited to
VMS; if we are going to make some VMS specific changes to the spec, they
should be oriented towards efficiency as well as functionality.

On the matter of having filters, I think the real world demands a better
solution.  A two step process for special file transfers would be awkward and
confusing; I think if filters became a "standard" that it would be a standard
soon retired to the dusty shelves of disuse.

It would be nice if everything could be designed and implemented in a vacuum,
and if everyone used the same "standards," and if all the "standards" were
of excellent quality.  Unfortunately, we don't live in a vacuum, standards
are often ignored (for good and bad reasons), and they are often of poor
quality.

I think it is pointless to discuss whether or not the addition of VMS specific
changes to the FTP spec. is appropriate.  The need for the functionality exists
and it is unreasonable to believe that vendors and other institutions will
discontinue efforts in support of such a need.  It is our job to try to meet
the functionality requirements in the best way that we can.

							-Tod Shannon

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 13:10:39 GMT
From:      mleonard@secola.Columbia.NCR.COM (Michael Leonard)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Network Security

In article <9424@pasteur.Berkeley.EDU> vincent@zubenelgenubi.uucp () writes:
>I am working on a network security project and am looking for pointers
>to papers, books .... etc or your own comments and views. 
>More specifically, I'm looking at 
>security measures at both hardware and network layer level. 
> 
>Thanks.
>Vincent.

The April 1987  issue of IEEE Network Magazine has a number of articles on network security. The references in those articles will lead you to many more.

mike

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 1989 19:01-EST
From:      CERF@A.ISI.EDU
To:        nbires!chm@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IP over X.25 (request for info)
Paul,
After the VC is established, the first packet over the link is an IP
packet containing source/destination IP addresses and, probably, a TCP
SYN packet or a UDP packet. Won't the Source/Dest address in the
first IP packet be sufficient or have I missed some initialization
problem on the receiving end?

Vint Cerf
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Feb 89 20:32:50 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        pcip@twg.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Packet Driver version of NCSA Telnet 2.2 is now Available
(sorry for the cross-post)
1/31/89
A Beta Test version of NCSA telnet V2.2C is now available via anonymous FTP
from omnigate.clarkson.edu (128.153.4.2) from the directory  pub/ncsa2.2c
This is the readme file from that directory.

A uuencoded compressed tar file of the binaries is also available by mail:
	% mail  archive-server@sun.soe.clarkson.edu
	Subject:  send  ncsabin.tar.Z.uu
        (206Kbytes long)

Version 2.2C is a highly modified copy of NCSA Telnet version 2.2
It has been recompiled under Turbo C 2.0, supports the Packet Driver
interface, 43 Line mode EGA, domain name search paths, BOOTP, connecting
to a specified destination port, internal random FTP password, enhanced
directory listing under FTP, display clock and a host of other enhancements.

*** This is a Beta release, no warranties are expressed or implied ***
*** Use at your OWN risk.  Neither Clarkson University nor the National
*** Center for Supercomputing Applications implies any warrenty or
*** fitness for use, etc.

This version was developed independently of NCSA, please do not bother them
with bug reports or questions (NCSA support of this version may be
a future possibility)


Plase Send bug reports and/or questions to:

	bkc@omnigate.clarkson.edu

The following files are available:


/pub/ncsa2.2c

-rw-r--r--  1 bkc        109755 Feb  3 18:12 PCtelnet2.2c.ascii
-rw-r--r--  1 bkc         47812 Feb  3 18:08 PCtelnet2.2c.ascii.Z
-rw-r--r--  1 bkc          9452 Jan 31 18:56 config.tel
-rw-r--r--  1 bkc        208896 Feb  3 18:13 ncsabin.tar
-rw-r--r--  1 bkc        150264 Feb  3 18:11 ncsabin.tar.Z
-rw-r--r--  1 bkc        988160 Feb  3 19:22 ncsasrc.tar
-rw-r--r--  1 bkc        374373 Feb  3 19:29 ncsasrc.tar.Z
-rw-r--r--  1 bkc          3126 Feb  3 20:04 readme

PCtelnet2.2c.ascii.Z   You should read this first for a detailed
		description of changes. This is version 2.2 documentation
		with margin comments describing the new features.

ncsabin.tar.Z   contains the binaries for telbin.exe, telpass.exe 
		(ftpbin.exe is not included due to a serious bug)

ncsasrc.tar.Z	contains all the source (for Turbo C 2.0)

config.tel	a sample config.tel file (is included in both tar files)

readme		This file.

NOTE!: Both tar files are binary images of the PC source. Thats good
for ncsabin.tar, but bad for ncsasrc.tar. If you untar the source
on a unix system you'll have to strip off trailing CR's and a ^Z at the
end of each file, unless you do a binary copy to your PC.


Known bugs:
	currently  ftpbin.exe can not upload to a host w/o crashing.

The best new feature in this version is support for the Packet Driver
interface (from FTP Software). Some packet drivers are available from
grape.ecs.clarkson.edu  in the file  comm/drivers.arc
This version has been tested with the following packet drivers:
	ni5210
	ni5010
	3c501

The second best feature is support for BOOTP. This is a method
whereby the client PC can get information from a server about its
IP address, gateway, nameservers and netmask. You should read
RFC1048 for detailed information.  

I would appreciate comments and bug reports. This version is currently
in use at Clarkson University in our public terminal areas (hence Bootp).


Brad Clements
Network Engineer
Educational Resources Center
Clarkson University
Potsdam, NY  		/* the land that time forgot */

(315)268-2292

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 16:25:02 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   FTP implemetation issues (was Re: FTP "STRU VMS" extension)


In our Macintosh TCP/IP product, we face the same issue of exchanging
non-vanilla files between like systems, and so far my preference is to
use "SITE" commands to modify the interpretation of Image mode.  I don't
want to leap into the fray here, that's just how I read the RFC.

Something else that we do with our FTP client is to make it as intelligent
as possible if it can figure out what it's talking to.  Theoretically,
this is pretty easy: just use the SYST command.  Unfortunately, very
few FTP servers seem to implement it, even though it's dead simple to
do.  We get along pretty well by looking at the HINFO fields in DNS
replies, but that doesn't help us differentiate from, say, half a
dozen different VMS FTP servers.

I encourage anyone working on an FTP server to add the SYST command.  I'd
also be interested to know what the responses are from any servers out
there that aleady do implement it.  Just to get things started, here's
what our products return:

	200 MAC-OS TCP/Connect for the Macintosh Version x.x
	200 MS/DOS TCP/Connect for the PC Version x.x

Even if you don't think anyone else cares :-), please at least mail it
to me...

-- 
Amanda Walker			...!uunet!lts!amanda / lts!amanda@uunet.uu.net
			  InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
"NO one expects the Spanish Inquisition!"

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 16:29:16 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   INTERNET.vendor_specific

>I think it is pointless to discuss whether or not the addition of VMS specific
>changes to the FTP spec. is appropriate.  The need for the functionality exists
>and it is unreasonable to believe that vendors and other institutions will
>discontinue efforts in support of such a need.  It is our job to try to meet
>the functionality requirements in the best way that we can.
 
>From some of the comments I've seen, I think that some people are still
misinterpreting what I said.  I didn't request that we kill the discussion
of a protocol under ftp for vms.  Let that go on... and on... whatever.

I realize that nobody is going to stop trying to do specific work to
transfer files between VMS, or TOPS-20, or UNIX, or MS-DOS, and whatever
other systems are out there.  Thats great!  There is NOTHING wrong with
that!  All I asked was should we add it as secondary protocols layers under
existing tool protocols (ie: telnet, ftp, etc.) or should new tool protocols
be developed.  If the goal is to keep the basic tools (ftp...) "open",
then new standards for "specific" tools need to be developed.  In either
case, somebody (the committee) has to make a statement on how us chickens,
in "nobody here but us chickens" ;-), in the world of software development
are supposed to approach this.

I thought there would be enough interest concerning the goals of the
network to warrent such a discussion.  I'm not going to flame out one
way or the other.  It's just that this is the first time in recent
memory (in this group) where someone has swung near that question again.

Perhaps I am wrong.  In that case I see myself going down in flames.
Wouldn't be the first time. ;-)

Joel A. Mussman

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 16:37:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP encapsulation on HP3000

I don't normally phrase things as commercial hype, but today is
Friday and Ted Marshall asked the right question...

While you are stopping at Wollongong to buy the applications for
Telnet, FTP, and mail (SMTP), you might also consider getting WIN/ROUTE2
for DOS.  This allows you to turn any DOS machine into an IP router that
translates the HP 802.3 IP frames into ethernet frames.  You will like
the price.

Dave Crocker
VP, Engineering
The Wollongong Group, Inc.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 16:52:15 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP over X.25 (request for info)

Paul,

If you have not made the acquaintance of the Defense Data Network (DDN)
X.25 Standard Service, it would probably be a good idea to do so.  It
will NOT answer your immediate question, but considering the type of
product you are developing, it seems to me that it would be rather
silly not to support the DDN Standard Service as a configuration
option.  That may be the largest single market for IP over X.25.  I
will not describe it in detail as there are documents for that, but
very briefly, it uses an algorithmic transformation between IP
addresses and X.121 addresses.  This transformation has some
limitations which make it undesirable or unusable in many other
situations, but it seems like it would be worth implementing, or at
least leaving hooks for.

DDN Standard X.25 has a couple of other twists which involve
network-specific X.25 facilities at SVC initiation, as well as the CUD
which is essentially as described in the RFC.  Also, it imposes some
implicit restrictions on the assignment of IP datagrams to X.25 VCs, so
that Precedence will work.  If you code it right to start with, the
extra work is minimal; retrofitting may or may not be easy, "depending."

The common method of address handling (that I know of) involves keeping
static address mapping tables in all the X.25 endpoints involved.  These
tables associate IP addresses with X.121 DTE addresses.  This method has
the advantage of providing the basis for some security checking.  Since
the static configuration table lists all the DTE's that are expected to
call and talk IP with you, you can clear calls from impostors.  You would
also have the IP layer do its routing based on this information, which
prevents a legitimate DTE address from acquiring packets destined to an
IP address properly belonging to some other DTE.  The utility of this
depends on the validity of the DTE address, but there is some validation
of this in most public data networks, I believe.  I would certainly want
such a feature to be available in any box that I used on a public data
network in this way.

Send mail if you would like to chat about this further...  this seems
like enough for the public wire.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 16:56:53 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers

For HP 9000's at least, you're not stuck with IEEE encapsulation --
it's a configurable option whether to use 802.3 or standard Ethernet
IP encapsulation.  We're using one right on our Ethernet, it interoperates
just fine.  I don't know about the HP 3000 series, though.

	Stuart Levy, Minnesota Supecomputer Center
	slevy@uc.msc.umn.edu

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 17:53:00 GMT
From:      EWOLF@RCCA.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Remove from list

Please remove my name from the tcp-ip distribution list.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 18:11:29 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers


*Yes, it is my understanding that they need some sort of translator. The
*company I work for makes a router device which also can act as a
*802.3/V2 converter it supports both Probe & ARP. If you would like
*more information we can send you something in the mail. Make a request
*to 'customer-service@cisco.com', as I am about to leave town for a while.

*John Wright
*cisco Systems, Inc.

i believe that only the 3000 is like this. i thought that the 9000
could speak this "special IP" to act as a gateway. i was also under the
impression that it wasnt even "real" ehternet based IP they were using,
they didnt use ARP or something. 

i am sure someone from HP will set us all straight, though . . . .

stev knowles
ftp software

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 19:03:26 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers


An even better solution is to throw away HP-UX, and run 4.3 BSD on your
9000 series.  Then you get full 4.3 networking code, and all the other things
4.3 gives you that HP-UX doesn't.  It works quite well, and you
can get from the folks at Utah.  Maybe one of them would like to send
out information on how to get the distribution.

Some people STILL don't understand that people buy Unix systems for
compatibility and portability.  Sigh...

					Thanks,
					   Milo

PS Standard disclaimers apply re: US Government, NASA, etc...  IE, this
should not be construed as an official position, but the you probably
realized that already.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 19:32:26 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   IP over AppleTalk

I am hoping to put together/edit an RFC defining how IP is sent over AppleTalk
(ala KIP gateways, K-STAR gateways, etc.).  There is an existing "way" of
doing this (though its never been set down as an RFC).

There are a few things in the current scheme I think need to be dropped (ie:
using NBP to do proxy ARP), and at least one important thing I think needs
to be added (a "cross protocol" redirect message).  [Sorry to the non-
AppleTalkers for the crypt here...]

At any rate, I'd love to gather a group to review the RFC before it is
issued.  If you are interested, please send your name, e-mail address,
and USPS address.  I hope to have a first draft for review by next week.

Greg Minshall				Kinetics
1-415-947-0998				...!ucbvax!unisoft!kinetics!minshall

2540 Camino Diablo	Walnut Creek	California	94596

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 20:30:20 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   IAB Ethics Statement


Network Working Group                          Internet Activities Board
Request for Comments: 1087                                  January 1989


                        Ethics and the Internet

Status of this Memo

   This memo is a statement of policy by the Internet Activities Board
   (IAB) concerning the proper use of the resources of the Internet.
   Distribution of this memo is unlimited.

Introduction

   At great human and economic cost, resources drawn from the U.S.
   Government, industry and the academic community have been assembled
   into a collection of interconnected networks called the Internet.
   Begun as a vehicle for experimental network research in the mid-
   1970's, the Internet has become an important national infrastructure
   supporting an increasingly widespread, multi-disciplinary community
   of researchers ranging, inter alia, from computer scientists and
   electrical engineers to mathematicians, physicists, medical
   researchers, chemists, astronomers and space scientists.

   As is true of other common infrastructures (e.g., roads, water
   reservoirs and delivery systems, and the power generation and
   distribution network), there is widespread dependence on the Internet
   by its users for the support of day-to-day research activities.

   The reliable operation of the Internet and the responsible use of its
   resources is of common interest and concern for its users, operators
   and sponsors.  Recent events involving the hosts on the Internet and
   in similar network infrastructures underscore the need to reiterate
   the professional responsibility every Internet user bears to
   colleagues and to the sponsors of the system.  Many of the Internet
   resources are provided by the U.S. Government.  Abuse of the system
   thus becomes a Federal matter above and beyond simple professional
   ethics.

IAB Statement of Policy

   The Internet is a national facility whose utility is largely a
   consequence of its wide availability and accessibility.
   Irresponsible use of this critical resource poses an enormous threat
   to its continued availability to the technical community.

   The U.S. Government sponsors of this system have a fiduciary
   responsibility to the public to allocate government resources wisely



Internet Activities Board                                       [Page 1]
 
RFC 1087                Ethics and the Internet             January 1989


   and effectively.  Justification for the support of this system
   suffers when highly disruptive abuses occur.  Access to and use of
   the Internet is a privilege and should be treated as such by all
   users of this system.

   The IAB strongly endorses the view of the Division Advisory Panel of
   the National Science Foundation Division of Network, Communications
   Research and Infrastructure which, in paraphrase, characterized as
   unethical and unacceptable any activity which purposely:

      (a) seeks to gain unauthorized access to the resources of the
          Internet,

      (b) disrupts the intended use of the Internet,

      (c) wastes resources (people, capacity, computer) through such
          actions,

      (d) destroys the integrity of computer-based information,

   and/or

      (e) compromises the privacy of users.

   The Internet exists in the general research milieu.  Portions of it
   continue to be used to support research and experimentation on
   networking.  Because experimentation on the Internet has the
   potential to affect all of its components and users, researchers have
   the responsibility to exercise great caution in the conduct of their
   work.  Negligence in the conduct of Internet-wide experiments is both
   irresponsible and unacceptable.

   The IAB plans to take whatever actions it can, in concert with
   Federal agencies and other interested parties, to identify and to set
   up technical and procedural mechanisms to make the Internet more
   resistant to disruption.  Such security, however, may be extremely
   expensive and may be counterproductive if it inhibits the free flow
   of information which makes the Internet so valuable.  In the final
   analysis, the health and well-being of the Internet is the
   responsibility of its users who must, uniformly, guard against abuses
   which disrupt the system and threaten its long-term viability.










Internet Activities Board                                       [Page 2]

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 21:07:54 GMT
From:      dlt@csuna.UUCP (Dave Thompson)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip on vms

I have just installed cmu's tcp/ip tackage.  Not having RFC952, which describes
the format of the known hosts file, I need to know the format of this file and
which will reside in SYS$LIBRARY:HOSTS.TXT.   I ported over /etc/hosts from one
of our unix boxes, but evidently the format is different for I get an invalid
keyword message for each line in the file when NAMSRV comes up.

Can anyone help????

Thanks,

	Dave

-- 
Dave Thompson		     		uucp:   dlt@csuna.csun.edu
Computer Center
Cal State University, Northridge	phone:  (818) 885-2790
18111 Nordhoff Street, Northridge, CA 91330

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 21:15:17 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Internet commercial uses policy?

Could someone refresh my memory about this? Several recent messages to this
mailing list seem to have, in my opinion, exceded the bounds of what might
be termed "non-commercial usage". I was under the impression that Internet
mailing lists were not to be used for commercial advertising.

	Vince Fuller, Stanford University
-------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 89 21:16:48 GMT
From:      kincl@KITZBUHL.IAG.HP.COM (Norman Kincl)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers



HP9000 (UNIX systems) speak both 802.2 and Ethernet V2 encapsulation.  They can
communicate transparently with either protocol.  Nothing special is required to
make this work.

HP3000 (MPE systems) currently only speak 802.2 encapsulation.  A cisco box can
translate from this to Ethernet encapsulation.

-Norm Kincl
 Information Architecture Group
 Hewlett-Packard

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 89 00:01:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

Paul,
After the VC is established, the first packet over the link is an IP
packet containing source/destination IP addresses and, probably, a TCP
SYN packet or a UDP packet. Won't the Source/Dest address in the
first IP packet be sufficient or have I missed some initialization
problem on the receiving end?

Vint Cerf

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 89 01:32:50 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver version of NCSA Telnet 2.2 is now Available

(sorry for the cross-post)
1/31/89
A Beta Test version of NCSA telnet V2.2C is now available via anonymous FTP
from omnigate.clarkson.edu (128.153.4.2) from the directory  pub/ncsa2.2c
This is the readme file from that directory.

A uuencoded compressed tar file of the binaries is also available by mail:
	% mail  archive-server@sun.soe.clarkson.edu
	Subject:  send  ncsabin.tar.Z.uu
        (206Kbytes long)

Version 2.2C is a highly modified copy of NCSA Telnet version 2.2
It has been recompiled under Turbo C 2.0, supports the Packet Driver
interface, 43 Line mode EGA, domain name search paths, BOOTP, connecting
to a specified destination port, internal random FTP password, enhanced
directory listing under FTP, display clock and a host of other enhancements.

*** This is a Beta release, no warranties are expressed or implied ***
*** Use at your OWN risk.  Neither Clarkson University nor the National
*** Center for Supercomputing Applications implies any warrenty or
*** fitness for use, etc.

This version was developed independently of NCSA, please do not bother them
with bug reports or questions (NCSA support of this version may be
a future possibility)


Plase Send bug reports and/or questions to:

	bkc@omnigate.clarkson.edu

The following files are available:


/pub/ncsa2.2c

-rw-r--r--  1 bkc        109755 Feb  3 18:12 PCtelnet2.2c.ascii
-rw-r--r--  1 bkc         47812 Feb  3 18:08 PCtelnet2.2c.ascii.Z
-rw-r--r--  1 bkc          9452 Jan 31 18:56 config.tel
-rw-r--r--  1 bkc        208896 Feb  3 18:13 ncsabin.tar
-rw-r--r--  1 bkc        150264 Feb  3 18:11 ncsabin.tar.Z
-rw-r--r--  1 bkc        988160 Feb  3 19:22 ncsasrc.tar
-rw-r--r--  1 bkc        374373 Feb  3 19:29 ncsasrc.tar.Z
-rw-r--r--  1 bkc          3126 Feb  3 20:04 readme

PCtelnet2.2c.ascii.Z   You should read this first for a detailed
		description of changes. This is version 2.2 documentation
		with margin comments describing the new features.

ncsabin.tar.Z   contains the binaries for telbin.exe, telpass.exe 
		(ftpbin.exe is not included due to a serious bug)

ncsasrc.tar.Z	contains all the source (for Turbo C 2.0)

config.tel	a sample config.tel file (is included in both tar files)

readme		This file.

NOTE!: Both tar files are binary images of the PC source. Thats good
for ncsabin.tar, but bad for ncsasrc.tar. If you untar the source
on a unix system you'll have to strip off trailing CR's and a ^Z at the
end of each file, unless you do a binary copy to your PC.


Known bugs:
	currently  ftpbin.exe can not upload to a host w/o crashing.

The best new feature in this version is support for the Packet Driver
interface (from FTP Software). Some packet drivers are available from
grape.ecs.clarkson.edu  in the file  comm/drivers.arc
This version has been tested with the following packet drivers:
	ni5210
	ni5010
	3c501

The second best feature is support for BOOTP. This is a method
whereby the client PC can get information from a server about its
IP address, gateway, nameservers and netmask. You should read
RFC1048 for detailed information.  

I would appreciate comments and bug reports. This version is currently
in use at Clarkson University in our public terminal areas (hence Bootp).


Brad Clements
Network Engineer
Educational Resources Center
Clarkson University
Potsdam, NY  		/* the land that time forgot */

(315)268-2292

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Feb 89 11:11:09 PST
From:      braden@venera.isi.edu
To:        sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu, tcp-ip@sri-nic.arpa
Subject:   Re: FTP implemetation issues (was Re: FTP "STRU VMS" extension)
	
	Speaking of FTP, has anyone implemented RESTart?  Restart requires MODE C
	(compressed), which is a simple repeated-byte-packing algorithm.  I
	checked radc-tops20's FTP server as well as several flavors of Unix FTP
	servers, and none of them support Compressed mode... :-(

Russ,

I am happy to say that this is WRONG!!  All that is required to send
Restart Markers is Block Mode, which is a trivial byte count header shlunked
into the stream whenever the sender feels like it ... eg when it wants to
send a Restart Marker.

Bob Braden
	
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 89 04:36:05 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP implemetation issues (was Re: FTP "STRU VMS" extension)

Speaking of FTP, has anyone implemented RESTart?  Restart requires MODE C
(compressed), which is a simple repeated-byte-packing algorithm.  I
checked radc-tops20's FTP server as well as several flavors of Unix FTP
servers, and none of them support Compressed mode... :-(

Several times I have gotten part of a .5 Megabyte file, and REST would have
been a *real* big help.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
"I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her
Christmas present of a whale "adoption" certificate.  Bless her liberal heart.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 89 20:56:00 PST
From:      art@sage.acc.com
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Re: IP over X.25 (request for info)
>Paul,
>After the VC is established, the first packet over the link is an IP
>packet containing source/destination IP addresses and, probably, a TCP
>SYN packet or a UDP packet. Won't the Source/Dest address in the
>first IP packet be sufficient or have I missed some initialization
>problem on the receiving end?
>
>Vint Cerf

Vint,

Unfortunately, the Source address in the IP packet may have little
relation to the X.121 address at the other end of the VC. If there
is at least one gateway between the local machine and the remote 
machine, the virtual circuit really exists as a logical level 2
connection between the local machine and gateway.  It's probably
better to translate from the X.121 calling address to an associated
IP address.

The IETF Performance Working Group has been working on a paper that
covers, amoung other things, issues around SVC management for IP over
X.25.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+


-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 89 23:07:36 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   Extended internet model


Recently, I completed a "revision" of a tech report called "Towards a  
Framework for High Speed Communication in a Heterogenous Networking
Environment." I think it may be of interest to people on this list. If
you want a copy, please send me a note, and I'll try to send it out
asap.
 
BTW, it is going to be published in the proceedings of IEEE
INFOCOM'89. So you can wait until then. 

DISCLAIMER: One of the reviewers thought it is too early to be writing
a paper based on these ideas, whereas other reviewers thought it has
good ideas about the functionality expected of future internet. 

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899 
(314) 889-4621


Here is an intro to the paper.
------------------------------------------------------------------------------
				   
	Towards to a Framework for High Speed Communication in
		 Heterogeneous Networking Environment
				   
			    Guru Parulkar
			      Jon Turner

		    Department of Computer Science
		  Washington University in St. Louis


In this paper we attempt to formulate a framework for high speed
communication in an environment comprising a mix of subnetworks with
widely varying characteristics.  Recent work on high speed wide area
packet switching systems is expected to lead to the development of
large public networks capable of supporting applications ranging from
low speed data to voice, high speed data and video.  If such networks
are to realize their full potential, they must be designed to operate
in an environment that includes networks with widely varying
characteristics.  Since the early seventies, much of the work on
computer communication has been directed toward the development of
protocols that allow interworking among computers, operating systems
and communication subnetworks of different types.  These efforts have
culminated in the \Arpa\ Internet Protocol Suite which has introduced
a number of ideas of fundamental importance.

Since the development of the internet protocols, the technological
context in which we find ourselves has changed dramatically.  The
development of high speed \Lan s and workstations, and the growing
role of supercomputers in scientific computing have led to new and
largely unfulfilled requirements for high speed computer
communication.  These needs have been difficult to satisfy for a
combination of reasons.  First, existing wide-area computer networks
have been unable to support the data rates required and second, the
existing end-to-end protocols and host computers are unable to deliver
the data to the application at those rates.

On the other hand, fiber optic transmission systems are being
introduced rapidly into the national communications infrastructure
offering vast amounts of bandwidth at fairly modest costs.  Several
research groups at industrial and academic laboratories around the
world have demonstrated that new high speed packet switching
techniques can make these resources available in a flexible fashion,
but up to now these groups have failed to consider the need to operate
in a complex networking environment consisting of autonomous and/or
technologically dissimilar subnetworks.  We feel that it is important
to recognize that this kind of heterogeneous environment is here to
stay and if we are to make the best possible use of new developments
in networking, we need to establish a framework that supports such
diversity.

In this paper we attempt to address these issues.  We first provide
some background on both the current internet model and high speed
packet switching.  We then outline the major elements of an extended
internet model that allows interworking of new high speed packet
networks with a wide range of other networks, including current data
networks and national telephone networks.  Finally, we discuss some
end-to-end and host interface issues.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 89 23:42:00 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   ICC'90 - Session on High Speed Internetworking and Gateway Arch


I am considering organizing a technical session for SUPERCOMM ICC'90
on "High Speed Internetworking and Gateway Architectures". The
conference will be held in in Atlanta Georgia during April 16-19 1990.
I would like to invite you to submit a paper to this session. Please
let me know if you would like to. Of course, I can send you more
information if you haven't seen the announcement yet. I am enclosing
the note that I sent to conference organizers about this session.   

Thanks.

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899 
(314) 889-4621

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


				   
		      High Speed Internetworking
		      and Gateway Architectures
				   
			  Dr. Guru Parulkar
		       Dept of Computer Science
		  Washington University in St. Louis

This session will serve as an excellent platform for presenting
research on the issues related to the next generation internetworking
and gateway architectures. A new model for internetworking has been
motivated in part by recent work on high speed packet switching and in
part by the limitations of ARPA Internet model in supporting
guaranteed levels of performance to a number of applications.

The work on high speed packet switching is expected to lead to the
development of large public networks capable of supporting
applications ranging from low speed data to voice, high speed data and
video.  If such networks are to realize their full potential, they
must be designed to operate in an environment that includes networks
with widely varying characteristics. The internet model based on the
ARPA Internet has worked well for internetworking of the first
generation networks, but is not appropriate for the internetworking of
newer high speed networks for a variety of reasons.  Thus, there is a
need to address the issues related to the interplay of component
networks' diversity and our ability to support a variety of
applications with guaranteed levels of performance in the next
generation internet.

Some of the topics that will be covered by papers in this session
include: 

- model for the next generation internet: connectionless and
 connection-oriented transport facility, addressing model, diversity
 of component networks, functionality expected of component networks,
 routing model, etc.

- design and specification of a connection-oriented internet protocol
  which can work well with the emerging high speed networks as well as
  with the existing neworks.

- design of gateway architectures for high speed networks based on the
  lessons of high speed packet switches  

- resource management in an internet of diverse networks to provide
  variable grade performance with guarantees

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 02:45:36 GMT
From:      nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   FTP implemetation issues (was Re: FTP "STRU VMS" extension)

I went back to the hosts that I looked at for MODE C to see if MODE B
would work.  They all say "We only support stream mode, sorry".
However, Bob *is* right, I misread the RFC, Compressed or Block mode
will do.

Let me ask the more experienced people on the net: Which do we need first?
Chickens (clients that implement MODE and REST) or Eggs (servers that ...)
I suspect that modifying the freely copyable Berkeley ftp and ftpd would
go a long way to making REST implementation universal.  Is anyone volunteering
or am I volunteering by bringing the issue up?  :-)
-russ

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 03:17:27 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Packet Driver version of NCSA Telnet 2.2 is now Available

In article <8902041218.AA06180@ucbvax.Berkeley.EDU> bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) writes:

   The best new feature in this version is support for the Packet Driver
   interface (from FTP Software). Some packet drivers are available from
   grape.ecs.clarkson.edu  in the file  comm/drivers.arc

Actually, the packet drivers are in /c/files/uploads, but since grape has not
been providing the best service lately, I'll convince Brad to put the latest
and greatest packet drivers on omnigate.clarkson.edu.  We have freely copyable
packet drivers for the ni5210, ni5010, 3c501, wd8003e, and SLIP8250.  .ASM
source is included, and all the functions that are common to all the drivers
has been split out.

I encourage anyone who writes a packet driver to send a copy to me so
that I can distribute it with the rest of the packet drivers.  I am
also offering to write a packet driver for any Ethernet card(s)
donated to Clarkson University.  We have PCs, ATs, and PS/2s.  This
driver(s) will be freely copyable, of course.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
"I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her
Christmas present of a whale "adoption" certificate.  Bless her liberal heart.

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 04:56:00 GMT
From:      art@SAGE.ACC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

>Paul,
>After the VC is established, the first packet over the link is an IP
>packet containing source/destination IP addresses and, probably, a TCP
>SYN packet or a UDP packet. Won't the Source/Dest address in the
>first IP packet be sufficient or have I missed some initialization
>problem on the receiving end?
>
>Vint Cerf

Vint,

Unfortunately, the Source address in the IP packet may have little
relation to the X.121 address at the other end of the VC. If there
is at least one gateway between the local machine and the remote 
machine, the virtual circuit really exists as a logical level 2
connection between the local machine and gateway.  It's probably
better to translate from the X.121 calling address to an associated
IP address.

The IETF Performance Working Group has been working on a paper that
covers, amoung other things, issues around SVC management for IP over
X.25.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
 +-----------------------------------------------------------------------+

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1989 12:22-EST
From:      CERF@A.ISI.EDU
To:        VAF@SCORE.STANFORD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Internet commercial uses policy?
Vince,

The "bounds of usage" question is being reviewed by the
government sponsors of the Internet - We should be getting
some guidance soon.

Vint
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1989 12:53-EST
From:      CERF@A.ISI.EDU
To:        munnari!murtoa.cs.mu.oz.au!wcc!latcs1!ditmela!smart@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interactive game playing over an internet network
There have been some interesting dynamic games run on low-delay
nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember
the names - one involved a chase though a maze of corridors
and you got zapped if a big, CBS-like EYE was caught staring at
you - your opponent).

What might be interesting is a delayed/deferred kind of game
which you could essentially join or leave at any time, catch
up on, as in computer-based teleconferencing, etc. Maybe
some sort of group adventure? 

I suppose some board games would work if the delays were
reasonably short. Chess obviously works fine in delayed mode.

Vint
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 1989 15:37-EST
From:      CERF@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   X.25 and IP
Art,

Now I am confused. Two cases: 

1. no gateways intervene
2. one or more gateways intervene between source and destination.

In the first case, the source needs to initiate an X.25 VC to
the destination. Given the IP destination address, known to
the source, the source must translate from IP destination
to comparable X.121 address. This is going to have to be
either straight table look-up or algorithmic (mapping of
a 32 IP address into an X.121 address - non-trivial in most
cases). The receiving host will get a call set-up packet
at the X.25 level which contains at least the source X.121
address. For this special case, one might be able to map
from the source X.121 address in the X.25 call set-up packet
to the source IP address, but this seems unnecessary since
the arriving IP packet coming on the set-up link will contain
source and destination IP addresses. Are you trying to bind
the call set-up to a particular service process before finding
out the originating IP source address?

In the second case, as you point out, the calling address of the
final X.25 call set-up may bear no relationship to the source
IP address of the caller since the last VC is between a gateway
andthe target host, not between the source host and thetarget
host. That being the case, it doesn't seem possible to try to map
the calling X.121 address into a source IP address at all.

I have the continuing feeling that I have not understood the
problem originally posed since I'm not able to make sense of your
most recent answer.

Vint
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 16:57:57 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

In article <220@cutter.nbi.com>, chm@nbires.nbi.com (Paul Chmielewski) writes:
> Is there a standard mechanism for telling the called end
> of a virtual circuit what the internet address of the calling host is?

I doubt that looking at the address on the first datagram is the right
way, that may have come from anywhere, and just happens to be being routed
through this X.25 connection (the calling site may have restrictions on
for whom it will forward datagrams over x.25, but then again, it also
might not).

A useful question might be "Do you care?"

I think not, datagrams arrive over the link, they carry source addresses,
the address of the particular site at the other end of the link shouldn't
matter much.

When you come to sending out a datagram, you need (somehow) to translate
the IP address to a DTE address - you have to be able to do this to
cope with the case where your end initiates the connection anyway.

Its likely that this translation will produce the same DTE address as
was in the "calling address" x.25 field in the initial call packet.
In that case, you can send your datagram(s) back out over this same
call (if its still active).

kre

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 17:22:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Internet commercial uses policy?

Vince,

The "bounds of usage" question is being reviewed by the
government sponsors of the Internet - We should be getting
some guidance soon.

Vint

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 17:52:22 GMT
From:      cheriton@PESCADERO.STANFORD.EDU (David Cheriton)
To:        comp.protocols.tcp-ip
Subject:   Re:  Interactive game playing over an internet network

VMTP (RFC 1045) is intended support the type of communication required for
distributed games (as well as other uses).  We are in the middle of
modifying mazewars to use VMTP and IP multicast, and will announce it
when available.  We are not planning to solve all the directory issues
raised by needing to register games, locate a particular game, etc.
I think a network directory service that could record this information
is the major missing piece. X.500?
David Cheriton

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 17:53:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

There have been some interesting dynamic games run on low-delay
nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember
the names - one involved a chase though a maze of corridors
and you got zapped if a big, CBS-like EYE was caught staring at
you - your opponent).

What might be interesting is a delayed/deferred kind of game
which you could essentially join or leave at any time, catch
up on, as in computer-based teleconferencing, etc. Maybe
some sort of group adventure? 

I suppose some board games would work if the delays were
reasonably short. Chess obviously works fine in delayed mode.

Vint

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 18:10:58 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

Ah, but there are some such games.  For instance, empire.

In any case, my impression is that not much noise is made lest management
take a dim view of this sort of use of the network.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<--          Stop!  Wait!  I didn't mean to!

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 18:32:34 GMT
From:      dwaitzma@bbn.com (David Waitzman)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

In article <4051@ditmela.oz> smart@ditmela.UUCP (Robert Smart) writes:
>I am amazed that there don't seem to be protocols and programs for 
>supporting game playing over an internet network. The sort of thing I 
>envisage would allow a client program to connect to a game control 
>server. They could then start a game, or join an existing game. The 
>protocol would include the ability to send move information to the 
>control server, receive state-of-game information from the control
>...
>Anybody else interested? Any existing work? Should we write an RFC?
>...

May I suggest that new work in this area exploit IP Multicasting?
Many-player games (and conferences) certainly could use multicasting,
and multicasting certainly could use games to become more widely valued.

Please see RFC-1054 and RFC-1075 for more information.

thank you,
-david (dwaitzman@bbn.com)

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 20:37:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   X.25 and IP

Art,

Now I am confused. Two cases: 

1. no gateways intervene
2. one or more gateways intervene between source and destination.

In the first case, the source needs to initiate an X.25 VC to
the destination. Given the IP destination address, known to
the source, the source must translate from IP destination
to comparable X.121 address. This is going to have to be
either straight table look-up or algorithmic (mapping of
a 32 IP address into an X.121 address - non-trivial in most
cases). The receiving host will get a call set-up packet
at the X.25 level which contains at least the source X.121
address. For this special case, one might be able to map
from the source X.121 address in the X.25 call set-up packet
to the source IP address, but this seems unnecessary since
the arriving IP packet coming on the set-up link will contain
source and destination IP addresses. Are you trying to bind
the call set-up to a particular service process before finding
out the originating IP source address?

In the second case, as you point out, the calling address of the
final X.25 call set-up may bear no relationship to the source
IP address of the caller since the last VC is between a gateway
andthe target host, not between the source host and thetarget
host. That being the case, it doesn't seem possible to try to map
the calling X.121 address into a source IP address at all.

I have the continuing feeling that I have not understood the
problem originally posed since I'm not able to make sense of your
most recent answer.

Vint

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 21:38:33 GMT
From:      jg@jumbo.dec.com (Jim Gettys)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

In article <[A.ISI.EDU].5-Feb-89.12:53:46.CERF> CERF@A.ISI.EDU writes:
>There have been some interesting dynamic games run on low-delay
>nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember
>the names - one involved a chase though a maze of corridors
>and you got zapped if a big, CBS-like EYE was caught staring at
>you - your opponent).

There are quite a few such games for X these days, including a
re-implementation of MAZEWAR (which actually precedes XEROX PARC; I played
it in 1972 or 1973 at MIT on IMLAC displays).  The possibly dubious claim
was made to me that it had been banned from the Internet because of
excessive use between MIT and Stanford, which was skewing network use
statistics.  (Maybe someone out there actually knows....).  There
is also xtrek, and at least one other empire like game, which are network
based.  Only mazewar is really distributed; the others involve invoking
a single server which then use multiple machines for display, which
X facilitates.

I guess I know X has succeeded by the proliferation of games for it... :-)
				Jim Gettys

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 23:07:24 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

The two most memorable games from the Xerox PUP days were MazeWar (which Vint
Cerf described) and AltoTrek, in which you controlled a ship on one of three
teams and went around blasting members of the other teams and planting your
bases around various planets (which could later be used for purposes such as
spying and self-distruction, if other players approached). Xtrek is a game
similar to AltoTrek which is implemented using the X protocol (which is layered
over TCP/IP) and I believe an almost identical copy of MazeWar has also been
implemented using X. I believe there are also others of this sort: Xtank and
Xconq (multi-player Empire), though I haven't seen them myself.

	--Vince
-------

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 23:38:22 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

In article <4051@ditmela.oz>, smart@ditmela.oz (Robert Smart) writes:
> I am amazed that there don't seem to be protocols and programs for 
> supporting game playing over an internet network....
> Anybody else interested? Any existing work? Should we write an RFC?
> 
> Bob Smart, CSIRO Division of Information Technology, Australia
>            smart@ditmelb.oz.au (or smart%ditmelb.oz.au@uunet.uu.net)


A standard would be nice.  It should support not only "low-speed" games
such as chess or bridge, but also those which require at least a couple
dozen updates/second, such as Silicon Graphics' "arena" and "dogfight."

"Dogfight" has been a very useful tool for these past several years.  It
has sold lots of systems, and, since it was converted from XNS-multicast to
UDP-broadcast, killed a number of obsolete machines which happened to be on
the same networks.  (We're working on IP-multicast so "dog" can get across
gateways as well as be friendlier to old stuff.)

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 89 23:38:37 GMT
From:      philipp@physicsa.mcgill.ca (Philip Prindeville Comp Ctr)
To:        comp.protocols.tcp-ip
Subject:   Re:  Interactive game playing over an internet network

I would be more inclined to think of something like Project Athena's
Zephyr notification system, but that could be out of lack of respect
for X.500.  See the Winter 1988 Usenet proceedings for a description
or ftp it from athena-dist.mit.edu, in pub/usenet (I think)...

-Philip

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 08:17:00 PST
From:      art@sage.acc.com
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   More on IP over X.25
Vint,

Remember that level 2 does not really care about the ultimate destination,
only the "next-hop" IP address (which could also be the destination).
In most cases what X.25 needs to do is to translate the the IP address
OF THE GATEWAY into an X.121 address.  If an X.25 Call is received from
a gateway (or host), one can translate from the Calling X.121 address to
an IP address, so that the next time a packet needs to make that hop,
it can use the same SVC.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Feb 89 10:04:31 PST
From:      satz@cisco.com
To:        CERF@A.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: X.25 and IP
Vint,

>> Now I am confused. Two cases: 
>> 
>> 1. no gateways intervene
>> 2. one or more gateways intervene between source and destination.

I would relabel these two cases as

1. packet sourced by host on connected subnet
2. packet sourced by host behind connected subnet (behind a router)
3. packet destined for host on connected subnet
4. packet destined for host behind connected subnet (behind a router).

And, I am not sure the distinction is necessary.

Since the X.25 virtual circuit source may not be from the originator but
from the previous hop, you can't necessarily believe the IP source address.
Also security and configuration reasons may require you to enumerate the
complete list of connected hosts you will speak with. For example if you
want to verify that an X.25 VC can Reverse Charge, some neighbor
information will need to be preconfigured. This information is needed
before the first X.25 DATA packet arrives to determine whether the VC can
be accepted.

The cisco implementation requires preconfigured table entries about other
entities sharing the same connected subnet unless a mapping function exists
(DDN or BFE). Preconfigured entries can always be used to provide
additional information (such as subnet multicast).

Greg
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 07:23:15 GMT
From:      mah@hpuviea.UUCP (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers

From article <6402@blia.BLI.COM>, by ted@blia.BLI.COM (Ted Marshall):
> 
> I have heard that HP's TCP/IP implementation, when sending over Ethernet,
> uses IEEE802.3 data link format (i.e. packet length, SSAP and DSAP)
> instead of Ethernet V2 format (i.e. protocol type) like most Unixes.
  ^^^^^^^^^^ replace by 'and'.

All HP 9000 series 300 and 800 talk both. The HP 3000 series currently only
speak IEEE802.3.

> Can anyone confirm or deny this? Specifically, I need to know if one
> can put an HP machine and one of our own boxes (which will only speak
> Ethernet V2 format) on an Ethernet and have them communicate.

You wont have any problems with the default setup, which is to talk both
protocols concurrently.


-michael
-- 
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) 	

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 16:17:00 GMT
From:      art@SAGE.ACC.COM
To:        comp.protocols.tcp-ip
Subject:   More on IP over X.25

Vint,

Remember that level 2 does not really care about the ultimate destination,
only the "next-hop" IP address (which could also be the destination).
In most cases what X.25 needs to do is to translate the the IP address
OF THE GATEWAY into an X.121 address.  If an X.25 Call is received from
a gateway (or host), one can translate from the Calling X.121 address to
an IP address, so that the next time a packet needs to make that hop,
it can use the same SVC.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
 +-----------------------------------------------------------------------+

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 16:36:02 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS" extension


What I don't understand is why this isn't taken care of extra-FTP by
some sort of archiving utility like tar.

How does one transfer ISAM (eg.) files by tape between VMS systems?
Why can't a similar mechanism be used?  The obvious advantage is that
such representations should even work when one wants to push such
files through third-party, non-VMS systems since all the info to
re-create the file gets bundled into the transferred file itself
rather than relying on wire transmission as server/client commands.

It wouldn't really occur to me to ask for an extension to FTP to
transfer an arbitrary file tree between Unix's (for example), I'd just
bundle it up with tar and send *that* (possibly compressing and/or
uuencoding if need be.) In fact, that's SOP.

At best I could imagine some sugar in the VMS server/clients which
might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
send the result of that, and if the other side is a VMS site he'll
recognize the header and automatically do the opposite", but none of
that needs a change in the protocol spec since it only affects the OS
interface, not the network interface (the file would just be xferred
binary I'd guess.) Personally I hate that kind of magic.

No FTP extensions should be needed (eg. something like embedding UNIX
magic numbers should do it.) And again, if the other side wasn't a VMS
site it would work also (that is, would store the file image but make
no attempt to unpack it.) A good example of the utility of this
approach is putting VMS files for Anonymous FTP onto a non-VMS system.

Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
have been using for years?

	-Barry Shein, ||Encore||

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 17:00:58 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: ATT 3b2/400 and TCP/IP

The Wollongong Group does TCP/IP products for 3B2s running SysV.
We're running it under SysVRel3.[02].

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 18:04:31 GMT
From:      satz@CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 and IP

Vint,

>> Now I am confused. Two cases: 
>> 
>> 1. no gateways intervene
>> 2. one or more gateways intervene between source and destination.

I would relabel these two cases as

1. packet sourced by host on connected subnet
2. packet sourced by host behind connected subnet (behind a router)
3. packet destined for host on connected subnet
4. packet destined for host behind connected subnet (behind a router).

And, I am not sure the distinction is necessary.

Since the X.25 virtual circuit source may not be from the originator but
from the previous hop, you can't necessarily believe the IP source address.
Also security and configuration reasons may require you to enumerate the
complete list of connected hosts you will speak with. For example if you
want to verify that an X.25 VC can Reverse Charge, some neighbor
information will need to be preconfigured. This information is needed
before the first X.25 DATA packet arrives to determine whether the VC can
be accepted.

The cisco implementation requires preconfigured table entries about other
entities sharing the same connected subnet unless a mapping function exists
(DDN or BFE). Preconfigured entries can always be used to provide
additional information (such as subnet multicast).

Greg

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 19:15:00 GMT
From:      jpederse@encad.Wichita.NCR.COM (John Pedersen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: netbios over tcp-ip

In article <23313@beta.lanl.gov> ddk@beta.lanl.gov (David D Kaas) writes:
|>Are there any hardware/software
|>systems available to allow connections between these protocols? 
|>Any boards to insert in a UNIX workstation or IBM PC/AT/2 that
|>will run both protocols?

I have a 3C505 with NRC's dual protocol software here but haven't loaded
it up to try it. It supposedly allows both protocols to exist on the same
board at the same time.

-- 
John Pedersen, Project Leader       N5DKQ     NCR Engineering & Manufacturing
Engineering Computer Support Services         3718 N. Rock Road
John.Pedersen@wichita.NCR.Com                 Wichita KS 67226
316-636-8837    FAX 316-636-8889

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 19:39:43 GMT
From:      wunder@HP-SDE.SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: IP Encapsulation on HP 3000/9000 computers

OK, here is the real story.  I work for HP, and this information is
from recent printed information announcing new products.

Up to now, the HP3000 has only used 802.3 encapsulation with the old
IP-over-802.3 standard.  This was done in the naive expectation that
an official standard was the right way to go.

Anyway, with the V-Delta-5 release of MPE for the "classic" HP3000,
Ethernet and ARP are supported.  It has TCP/IP of course, and there
are two sets of services available: the NS services, which are HP
proprietary and tweaked for the 3000 (sort of like STRU VMS, but not
based on FTP), avalable from HP; and regular ARPA services (Telnet,
FTP, and SMTP), available from The Wollongong Group.  The HP3000 can
also talk IP over X.25 links, but I'm not sure of the exact
encapsulation for that.  The HP3000 does not have UDP.

The Precsion Architecture HP3000 (OS is MPE/XL, machines are
HP3000/935, HP3000/950, etc.) has TCP/IP and the NS services, but does
not have ARPA services or Ethernet/ARP.  Ethernet/ARP is promised,
though I don't know which release, and I don't know whether we have
promised ARPA services.

The HP9000 (Unix) systems, both Motorola and Precision Architecture
(aka "Spectrum") have ARPA, Berkeley, and NS services; TCP/IP;
Ethernet and 802.3 (old); IP-over-X.25 (DDN, I think, s800 only?); and
soon, Jacobson/Karels TCP, BIND (supported), and probably other stuff.

The HP1000 has TCP/IP, NS services, and 802.3 (old).

We resell FTP Software, Inc.'s PC/FTP for the HP Vectra PC's as PC/ARPA.

I don't know whether 802.3/SNAP is planned for any of our systems.

Clear?

Walter Underwood
HP Software Engineering Systems

PS:  I think that the Wollongong product for the HP3000 is called
WIN/H3000 (is that right, Dave?).  Also, the HP3000 *always* talks
half-duplex to its terminals, so client Telnet can be aggravating if
you are talking to a full-duplex application.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 20:26:00 GMT
From:      berger@clio.las.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Internet commercial uses policy?


Isn't there a better place to discuss this?  I have the opposite
concern - that some users are trying to force all others to conform
to the lowest common denominator of service ("since I have to pay
per byte, YOU should limit what you write").

			Mike Berger
			Department of Statistics 
			University of Illinois 

			berger@clio.las.uiuc.edu
			{convex | pur-ee}!uiucuxc!clio!berger

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 22:12:33 GMT
From:      kent@WSL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network


	There have been some interesting dynamic games run on low-delay
	nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember
	the names - one involved a chase though a maze of corridors
	and you got zapped if a big, CBS-like EYE was caught staring at
	you - your opponent).

I ported Mazewar to X and UDP a while back. Other people have built
distributed games on top of IP (xtrek and xconq come to mind). I'm not
sure that a centralized server/protocol would have done me a lot of
good -- there's a lot of traffic and the extra hops can become
significant. In Mazewar, one of the games acts as a central server for
people who join the game and does "rebroadcast" of some of the packets,
but there are also some short circuits for efficiency. I only use
broadcasts to try to find an existing game.

Of course, if there had been an existing protocol implementation, I
might have built on top of it, and not noticed any loss in game responsiveness.

	What might be interesting is a delayed/deferred kind of game
	which you could essentially join or leave at any time, catch
	up on, as in computer-based teleconferencing, etc. Maybe
	some sort of group adventure? 

This sort of game has been built, too. Peter Langston's empire for
Unix, built starting in the late 70s, has contributed to more than one
academic suicide. (it's a highly detailed world conquest game, based on
a board game played at Reed College.) I've lost track of the game in
recent years, but he developed it actively for quite some time. As many
as 20 players could play in a single game, playing moves when they
wished. Games sometimes lasted weeks on end...

chris

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 89 23:43:17 GMT
From:      lance@hermix.UUCP (Lance Ellinghouse)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Printing over LAN

I have a LAN set up with a Xenix server running TCP/IP with ~ 14 PC's
running DOS. We do a lot of graphic developement on the DOS machines
and we would like to print them out on the laser printer on the Xenix
server. What we would like to do is do it either by a batch script or
by direct command. We have only telnet and ftp available for use.

If anyone out in net land knows how we can do this with minimal cost
please email me!!

Lance Ellinghouse
Mark V Systems

-- 
Lance Ellinghouse
Mark V Systems, Ltd.
UUCP: ...!hermix!lance
ARPA: ucla-an!hermix!lance@ee.UCLA.EDU

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 00:33:39 GMT
From:      klaas@hpindda.HP.COM (Darin J Klaas)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers

/ hpindda:comp.protocols.tcp-ip / stev@VAX.FTP.COM / 10:11 am  Feb  3, 1989 /

> i believe that only the 3000 is like this. i thought that the 9000
> could speak this "special IP" to act as a gateway. i was also under the
> impression that it wasnt even "real" ehternet based IP they were using,
> they didnt use ARP or something. 
 
> i am sure someone from HP will set us all straight, though . . . .
 
> stev knowles
> ftp software
> ----------

To rescue HP's reputation ... (:-)

The Series 9000's can talk either ethernet or 803.3; its a configurable
on a per interface basis.  The ethernet is standard ethernet, nothing
special.  You can even configure it to talk both on the same interface.
Beware that currently HP-UX will prefer to talk 802.3 over ethernet if 
given the choice.

The series 3000's are a different story; they talk 802.3 exclusively,
although I've heard that straight ARP and ethernet are coming to
a MPE system near you soon.

In either case, if you wish to talk 802.3 to an HP machine, you must use
HP's proprietary address resolution protocol, Probe ; ethernet uses ARP.

/ hpindda:comp.protocols.tcp-ip / medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) / 11:03 am  Feb  3, 1989 /

> An even better solution is to throw away HP-UX, and run 4.3 BSD on your
> 9000 series.  Then you get full 4.3 networking code, and all the other things
> 4.3 gives you that HP-UX doesn't.  It works quite well, and you
> can get from the folks at Utah.  Maybe one of them would like to send
> out information on how to get the distribution.
> 
> Some people STILL don't understand that people buy Unix systems for
> compatibility and portability.  Sigh...
> 
>					Thanks,
>					  Milo

We've heard this over and over again, and we are working toward a resolution.
Many people at HP DO realize that compatability is of utmost importance.
Stay tuned ...

-- darin klaas
   klaas@hpda

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 07:02:00 EST
From:      "BURKE D.N." <burke@nusc-npt.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   TCP-IP IMPLEMENTATION UNDER XENIX
does anyone know of a tcp-ip implementation that runs under xenix, and supports
a 3COM ethernet card? (preferably public domain)

Dave Burke
Aquidneck Data Corporation
(Sub. of Kodak)

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 05:09:42 GMT
From:      minshall@VIOLET.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270

There is a new "bug fix" version of tn3270 - 4.1.1.  This supercedes
version 4.1 (released December, 1988).

The files are on ucbarpa.berkeley.edu in the directory pub/tn3270.

The file 4.1TO4.1.1diffs.Z contains a set of diff's which will bring
a 4.1 release up to a 4.1.1 system (at least in all important aspects).
This includes three new versions of the man pages and a newer version
of /etc/map3270.

The file tn3270.4.1.1.tar.Z is the new release.

The main fix is to telnet.c - to notice that we have negotiated
out of a mode (for UCLA-based MVS systems mostly - but also for
protocol correctness).

Other changes include some more byte ordering considerations, eliminating
some unused macros from screen.h, checking the parameters to the 3270
orders RA and EUA (and bailing out if the parameters are bad - 3270
programmers beware!), tolerating the Gould C compiler, and making sure
that debugging information actually gets out (even if the programs dumps
core or goes into a loop).

A note to "by mail" customers:  I apologize to those who have ordered
their system in the last month and a half from the Campus Software Office.
I have not supplied the SW office with a new master and they have thus
been unable to satisfy your order.  I hope to provide a new master (of
4.1.1) within the next two weeks.

Thanks to all those providing such early bug reporting to my 4.1 release
(and for bearing with it all).

Greg Minshall

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 06:55:40 GMT
From:      hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

> From:	DECWRL::"encore!pinocchio!bzs@talcott.harvard.edu" "Barry Shein  6-Feb-89 1136 EST"  7-FEB-1989 08:50
> To:	KASHTAN@IU.AI.SRI.COM
> Subj:	 FTP "STRU VMS" extension
> 
> Cc: braden@venera.isi.edu, tcp-ip@sri-nic.arpa
>  
>  
> What I don't understand is why this isn't taken care of extra-FTP by
> some sort of archiving utility like tar.
>  
	There certainly is. Its known as BACKUP.

> How does one transfer ISAM (eg.) files by tape between VMS systems?
> Why can't a similar mechanism be used?  The obvious advantage is that
> such representations should even work when one wants to push such
> files through third-party, non-VMS systems since all the info to
> re-create the file gets bundled into the transferred file itself
> rather than relying on wire transmission as server/client commands.
>  
	It does work.

> It wouldn't really occur to me to ask for an extension to FTP to
> transfer an arbitrary file tree between Unix's (for example), I'd just
> bundle it up with tar and send *that* (possibly compressing and/or
> uuencoding if need be.) In fact, that's SOP.
>  
	The reason is UNIX (I'm sorry) has a very simple file system and
structure. Correct me if I'm wrong but a UNIX file can be safely treated 
as a binary byte stream, isn't that so?

> At best I could imagine some sugar in the VMS server/clients which
> might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
> send the result of that, and if the other side is a VMS site he'll
> recognize the header and automatically do the opposite", but none of
> that needs a change in the protocol spec since it only affects the OS
> interface, not the network interface (the file would just be xferred
> binary I'd guess.) Personally I hate that kind of magic.
>  
> No FTP extensions should be needed (eg. something like embedding UNIX
> magic numbers should do it.) And again, if the other side wasn't a VMS
> site it would work also (that is, would store the file image but make
> no attempt to unpack it.) A good example of the utility of this
> approach is putting VMS files for Anonymous FTP onto a non-VMS system.
>  
> Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
> have been using for years?
>  
> 	-Barry Shein, ||Encore||

	What Kenneth was asking for is an intelligent option where a VMS 
implementation of FTP will attempt to establish that fact to its 
counterpart. And if both parties are VAX/VMS then hey we can do things a 
lot faster and cheaper since we have some "mutual understanding". If 
not, then too bad, its back to the "standard FTP". Ken is trying to 
establish a standard for this "mutual understanding" among VMS/FTP ONLY. 

Your suggestion regarding the use of archival facility (ie BACKUP) as a 
pre-post processor is of course valid. But as some one else has 
mentioned, that pre-post processor takes time (cpu) and resources (read 
disk space). On VMS systems, disk quota are tightly controlled and if 
you don't have enough, its No Can Do. Eg if you retrieve a 1000 blocks 
archive file (in VMS its called a backup saveset), you need to have 2500 
blocks (1000 to keep the saveset, at least temporarily, and another 
1000+ for the files that will be extracted from the save set). 

For a long time, I was using Kermit to transfer files between 2 VAXes 
that weren't on the same DECnet. Now to transfer an indexed (read ISAM) 
file or a directory tree, I had to back it up then send it through 
Kermit in binary, and then restore it on my end. As I said, diskquota 
control can be a real restriction. (Most of the place wouldn't simply 
give you more disk space you know, you have to ask and justify for it). 
Besides there's the hassle of backing up the files and then restoring 
it. Not only that, efficiency on the wire suffers because BACKUP 
(unlike TAR) impose substantial overhead as it will keep lots of extra 
information about the files. This is to allow the recovery of data even 
when the saveset has some corruptions. Although I don't use much of 
UNIX, I know TAR's internal very well. It is nowhere compared to BACKUP, 
sort of comparing a Toyota to a Jaguar.

Ken, I am in favour of your STRU O VMS option. In which case, all OS can 
have such an option .. STRU O MVS, STRU O U43, STRU O EMBOS...

It does nothing to harm interoperability, as far as I can see. Its what 
the real world needed, if there's no standard then it'll just be 
non-standard features, so why not standardize it and make everybody 
happy?

Rgds,

Choy Heng Wah
Software Specialist

._._._._._._._.
|d|i|g|i|t|a|l|   Digital Equipment Singapore
._._._._._._._.

Disclaimer : What I express here is purely my own opinion and does not
             represent any policy of Digital Equipment Corp and its
             subsidiaries ... blah blah blah ...

EASYnet  : {zposws|zpovc|zpoact}::hwchoy
InterNET : hwchoy%zpovc.dec@decwrl.dec.com
	   <@decwrl.dec.com:hwchoy@zpovc.dec.com>  <-- source route addressing
	   hwchoy@zpovc.dec.com

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Feb 89 14:43:21 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        pcip@twg.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   How to get NCSA Telnet version 2.2C via E-mail
Previous directions on how to retrieve version 2.2C of NCSA Telnet
via the mail archiver were incorrect. 

To get a uuencoded compressed tar file of the binaries,
do the following:


	% mail archive-server@sun.soe.clarkson.edu
	  Subject:

	  path  <your return address goes here>
	  send  ncsa2.2c ncsabin.tar.Z.uuaa

	  ^D

Then send a second mail message that is identical, except substitute
	  send  ncsa2.2c ncsabin.tar.Z.uubb

(each file is approximately 100K long)
The path statement should be whatever address you want the
file sent to (presumably your own E-mail address)

You can get the modified ascii documentation by sending the following
command to the archive-server:

	send ncsa2.2c PCtelnet2.2c.ascii


As mentioned previously, the binaries, source and documentation is available
via anonymous ftp from omnigate.clarkson.edu from the directory
pub/ncsa2.2c

Some packet drivers have also been added to the ncsa2.2c directory on
omnigate, or
You can get packet drivers (and source) via mail by using the following
command:

	% mail archive-server@sun.soe.clarkson.edu
	Subject:

	path <your return address goes here>
	send  ka9q drivers01 drivers02 drivers03

(You can also send seperate messages to the archive server, requesting
one driver file at a time, otherwise all three files will be sent as
one message, which may be too long for your mailer to handle)

The binaries on sun.soe.clarkson.edu, and omnigate.clarkson.edu have
been changed as of 14:30 EST 2/7/89. These new binaries fix a bug in
the NLST command of the ftp server, which would cause mget's to fail.

A fixed source module (bkgr.c) is also available via ftp from omnigate.
The old source tar file has not been updated.

bugs, comments to
bkc@omnigate.clarkson.edu
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 10:13:13 GMT
From:      prinz@gmdzi.UUCP (Wolfgang Prinz)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Network Security

From article <9424@pasteur.Berkeley.EDU>, by vincent@zubenelgenubi.uucp:
> I am working on a network security project and am looking for pointers
> to papers, books .... etc or your own comments and views. 
> More specifically, I'm looking at 
> security measures at both hardware and network layer level. 
>  
> Thanks.
> Vincent.

You might find some interesting articels in:

Computer and Network Security, M.D. Abrams and H.J. Podell
IEEE Computer Society Press

regards 
Wolfgang

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 12:02:00 GMT
From:      burke@NUSC.ARPA ("BURKE D.N.")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP IMPLEMENTATION UNDER XENIX

does anyone know of a tcp-ip implementation that runs under xenix, and supports
a 3COM ethernet card? (preferably public domain)

Dave Burke
Aquidneck Data Corporation
(Sub. of Kodak)

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 14:59:55 GMT
From:      keith@SPIDER.CO.UK (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP over X.25 (request for info)



I am nearing completion of a Unix V.3 STREAMS-based implementation of
IP over X.25, which is part of our SpiderTCP and SpiderX.25 protocol
software products. We call it IXE (IP/X.25 Encapsulation).

It fits into the STREAMS protocol stack as a multiplexing driver
underneath IP and above our X.25 stack. It conforms fully to the
rather skimpy RFC 877 spec, and although at present it will only
work with CCITT-flavour X.25 PDNs, DDN support is on the way. (CCITT
is a lot more in demand in Europe than DDN, obviously). On the other
hand, it *does* work with both the 1980 and 1984 flavours of X.25.
Clearing down of idle X.25 calls and pre-emption of these when
resources are scarce are implemented.

Address mapping for this stuff is something of an issue. At present
we use a lookup table, which is the only way of really doing the
job, but if you have a lot of WAN destinations to talk to then there
is a danger of guzzling up lots of kernel memory.  Some kind of
address resolution protocol would be nice, but another way to look
at it is from a security point of view.

If you are connected to a public network, then anyone could call you
up and claim to be some host with a remote IP address that higher-
level software trusts.  This leaves you wide open to spoofing by
Public Data Network hackers. On the other hand, PDNs are usually set
up so you can trust the X.25 calling address, so we use this to look
back into the table and check that the remote IP host is who it
claims to be.

Using the CUDF field for address resolution does not seem like a
good idea to me.  I would prefer the use of X.25 facilities for
this, most specifically the extended addressing one of X.25(1984).
When used for the ISO CONS, this carries an NSAP. It is interesting
to note that a scheme for encoding IP addresses into NSAPs already
exists (RFC 986), at least for the connection-less world.  Some
scheme along these lines would thus bypass the need for table
lookup, and I think is probably the right approach. (Again you have
to trust the address you get from the PDN).

It strikes me that generally RFC 877 leaves a lot of issues
unanswered, and the introduction of the 1984 (and now 1988)
standards for X.25 have aggravated this. Is is perhaps time for a
new standard in this area ?  Any such work probably ought to take
into account using ISO IP (or CLNP) over X.25 circuits as well. Does
anyone have any thoughts on this ?

Keith Mitchell

Spider Systems Ltd.        Spider Systems Inc.
65 Bonnington Road        12 New England Executive Park
Edinburgh, Scotland        Burlington, MA 01803
+44 31-554 9424            +1 (617) 270-3510

keith@spider.co.uk        keith%spider.co.uk@uunet.uu.net
keith@uk.co.spider        ...!uunet!ukc!spider!keith

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 17:24:41 GMT
From:      dbercel@twg-ap.UUCP (Danielle S. Bercel)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers

In article <8902061939.AA26324@hp-ses.sde.hp.com>, wunder@HP-SDE.SDE.HP.COM (Walter Underwood) writes:
> 
> Walter Underwood
> HP Software Engineering Systems
> 
> PS:  I think that the Wollongong product for the HP3000 is called
> WIN/H3000 (is that right, Dave?).  Also, the HP3000 *always* talks
> half-duplex to its terminals, so client Telnet can be aggravating if
> you are talking to a full-duplex application.

The product is called WIN/TCP for MPE/V. Release 1.1 is available and
this includes block mode support through our telnet server.

The half-duplex communication in character mode is certainly not the best
of circumstances and it is for this reason that the 3000 telnet client
comes up in line mode.

danielle bercel
Project leader, WIN/TCP for MPE/V


-- 
Danielle Bercel - Senior Software Engineer - The Wollongong Group
Email:   dbercel@twg-ap.com or dbercel@twg.com
US Mail: 1129 San Antonio Rd. * Palo Alto, CA. 94303 * (415)962-7160

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 17:30:55 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

bzs@pinocchio.UUCP (Barry Shein) writes:

    What I don't understand is why this isn't taken care of extra-FTP by
    some sort of archiving utility like tar.

    [...]

    It wouldn't really occur to me to ask for an extension to FTP to
    transfer an arbitrary file tree between Unix's (for example), I'd just
    bundle it up with tar and send *that* (possibly compressing and/or
    uuencoding if need be.) In fact, that's SOP.

    [...]

    Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
    have been using for years?
    
    	-Barry Shein, ||Encore||

I agree with Barry's philospophy.  What our FTP does is to bundle up
Macintosh files into MacBinary format and send them in Image mode.  If the
other machine is anything but another Macintosh, they just get stored as-is.
If the other side is a Macintosh, it says, "gee, this is a MacBinary file;
I'll unpack it."  This lets you FTP applications and so on between two
Macs without any hassle.  The only problem is that MacBinary is a brain-
damaged format (no magic numbers), so we add SITE commands to turn the
automatic unpacking on and off.  This prevents tar files from being
falsely recognized as MacBinary and resulting in several-megabyte
invisible files full of garbage :-).  Using Apple's AppleSingle &
AppleDouble formats will solve this problem in future releases.

Nopw, I must admit that this approach works best on systems where
files are basically "Streams o' Bytes" like UNIX, but I can't imagine
it would be too hard to use a variant of ANSI tape format D or something
under VMS/TOPS-20/whatever.

-- 
Amanda Walker			...!uunet!lts!amanda / lts!amanda@uunet.uu.net
			  InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
I humans were meant to fly, the airlines wouldn't keep losing our luggage...

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 17:59:20 GMT
From:      kincl@hpiag2.iag.hp.com (Norman Kincl)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Encapsulation on HP 3000/9000 computers



> HP3000 (MPE systems) currently only speak 802.2 encapsulation.  A cisco box can
                    ^^^^^^^^^
> translate from this to Ethernet encapsulation.

A correction---as of version V-Delta-5, MPE-V supports BOTH 802.3 and standard
Ethernet encapsulation.  This includes ARP.  As with the HP 9000, it is
transparent to botht he user and the system administrator which protocol is
being used.  For MPE-XL, Ethernet compatability is a stated direction, the
schedule is under investigation.

-Norm Kincl
 Information Architecture Group
 Hewlett-Packard

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 18:54:53 GMT
From:      shaver@atanasoff.cs.iastate.edu (Dave Shaver)
To:        comp.protocols.tcp-ip
Subject:   Internet "time servers" and UNIX timed

I know that "network time servers" exist on the Internet.  Here's the
list I have:

		192.5.8.1            time
		128.9.2.129          time1 isi
		128.8.10.1           umd1 time2
		128.5.0.1            ford1 time3
		128.116.64.2         ncar time4

Now my question is how to use them.  How does one ask any of these
machines for the correct time?  On which IP port number and using what
protocol can I get the correct time?  Port numbers I know of: 13, 37,
and 525 (UNIX timed).  I know that you can just connet to port 13 and
read the time.  What is the best way of doing this?  Any help would be
appreciated.

My second problem is UNIX timed.  My goal is to get the "correct" time
from a time server and then pass it out on our LAN via timed.  We have
an HP 350 running HP-UX (System V/BSD "mix").  Has anyone ported
the 4.3 BSD timed to HP-UX or SYSV?  (This could be hard without
the adjtime(2) system call.)

Another option would be to use something other than timed.  Any other
comments or ideas are welcomed.

/\  Dave Shaver  -=*=-  CS Systems Support Group, Iowa State University
\\  UUCP:  {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver
\/  Internet: shaver@atanasoff.cs.iastate.edu

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 19:43:21 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   How to get NCSA Telnet version 2.2C via E-mail

Previous directions on how to retrieve version 2.2C of NCSA Telnet
via the mail archiver were incorrect. 

To get a uuencoded compressed tar file of the binaries,
do the following:


	% mail archive-server@sun.soe.clarkson.edu
	  Subject:

	  path  <your return address goes here>
	  send  ncsa2.2c ncsabin.tar.Z.uuaa

	  ^D

Then send a second mail message that is identical, except substitute
	  send  ncsa2.2c ncsabin.tar.Z.uubb

(each file is approximately 100K long)
The path statement should be whatever address you want the
file sent to (presumably your own E-mail address)

You can get the modified ascii documentation by sending the following
command to the archive-server:

	send ncsa2.2c PCtelnet2.2c.ascii


As mentioned previously, the binaries, source and documentation is available
via anonymous ftp from omnigate.clarkson.edu from the directory
pub/ncsa2.2c

Some packet drivers have also been added to the ncsa2.2c directory on
omnigate, or
You can get packet drivers (and source) via mail by using the following
command:

	% mail archive-server@sun.soe.clarkson.edu
	Subject:

	path <your return address goes here>
	send  ka9q drivers01 drivers02 drivers03

(You can also send seperate messages to the archive server, requesting
one driver file at a time, otherwise all three files will be sent as
one message, which may be too long for your mailer to handle)

The binaries on sun.soe.clarkson.edu, and omnigate.clarkson.edu have
been changed as of 14:30 EST 2/7/89. These new binaries fix a bug in
the NLST command of the ftp server, which would cause mget's to fail.

A fixed source module (bkgr.c) is also available via ftp from omnigate.
The old source tar file has not been updated.

bugs, comments to
bkc@omnigate.clarkson.edu

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 22:01:38 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

>What I don't understand is why this isn't taken care of extra-FTP by
>some sort of archiving utility like tar.

That has, in fact, been the solution for a LONG time.  Make a program that
can PACK/UNPACK VMS Backup Savesets using files that can be transferred in
FTP IMAGE mode.  Aside from various the system administration problems that
have already been enumerated there is also a psychological implication.  The
fewer steps you have to go through to get a file transfered the happier you
are (witness the preference of "rcp" over FTP when available).  There have
been many times that I have used slower file transfer methods just because
it was less work for me (the difference in transfer times has to be pretty
significant for me to prefer the more laborious method).  There is also the
issue of ensuring that EVERYBODY you might want to exchange VMS files with
has all the appropriate tools (isn't this what standards are for?).  As a
TCP vendor we are very concerned about providing MAXIMUM functionality to our
customers -- and this issue is of pretty serious concern to us.  So, rather
than just DO something so that machines running our software can communicate
in this fashion we have asked the TCP community to discuss the best way to set
a standard so that we can interoperate with other VMS TCPs for this "extended"
service yet still interoperate with the rest of the TCPs in the world.  I
feel that Ken's suggestions are a good solution to the problem (but I am
obviously biased).

>It wouldn't really occur to me to ask for an extension to FTP to
>transfer an arbitrary file tree between Unix's (for example), I'd just
>bundle it up with tar and send *that* (possibly compressing and/or
>uuencoding if need be.) In fact, that's SOP.

But that is just the point -- UNIX files and FTP IMAGE transfer are a good
match (i.e. they give you the functionality that you need).  We are looking
to do something equivalent for VMS, where IMAGE transfers are not sufficient.

>At best I could imagine some sugar in the VMS server/clients which
>might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
>send the result of that, and if the other side is a VMS site he'll
>recognize the header and automatically do the opposite", but none of
>that needs a change in the protocol spec since it only affects the OS
>interface, not the network interface (the file would just be xferred
>binary I'd guess.) Personally I hate that kind of magic.

AHA - but now you have implied some "standard" in the FTP protocol that
would allow both sides to recognize that they can do this.  In fact, this
is really what Ken's suggestion amounts to.

>No FTP extensions should be needed (eg. something like embedding UNIX
>magic numbers should do it.) And again, if the other side wasn't a VMS
>site it would work also (that is, would store the file image but make
>no attempt to unpack it.) A good example of the utility of this
>approach is putting VMS files for Anonymous FTP onto a non-VMS system.

But you would still need to know what "mode" the other side is in to
correctly interoperate with it.  What if you assumed that you were in
"include-the-magic-number-and-transfer-the-file-transparently" mode and
were talking to a "standard" FTP on the other side.  What if you were
transferring an ASCII file.  In this case, the correct thing to do is
to use the standard ASCII transfer mode.  How do you recognize automagically
that you should do this.  Once again -- we need some sort of "standard"
specified to allow the recognition that the other side can do what you
want it to.

David
-------

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 22:06:05 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Need help testing FTP's REST cmd.

Well, I had some work that I wanted to avoid doing, so I hacked REST
and MODE B into a version of Phil Karn's NET's FTP server.  However, I
haven't yet added the capability of *using* REST into the FTP client.
Interoperability is also desirable.  So, somewhere out there is
someone who has an FTP client that understands REST, MODE B, and
marks.  Whoever you are, will you please test the REST capability of
grape.ecs.clarkson.edu [128.153.13.196]?  Grape is a MS-DOS software
repository, as well as the semi-official comp.binaries.ibm.pc archive.

Also, my anonymous friend, how did you implement the mark storage?
The only clean way I can think of to do it is to create a temporary
file whose name is derived from the 'get' filename.  This temporary
file is used to contain the marks sent out by the sending process.  If
the transfer is completed, then the temporary file gets deleted.  The
ftp client, when asked to 'get' a file whose mark file exists, will
output the latest mark using REST, and will continue the transfer.

The marks *could* be written into the user's file, but I would rather
ensure that the partial file is usable.  The user may choose to use
only what they have instead of retrying.

The marks *could* be kept inside the user's ftp process, but I would rather
make the mark storage independent of the ftp process.  After all, one of the
reasons for an interrupted transfer is because the user's machine crashed.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lama

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 89 22:46:22 GMT
From:      kolb@NISC.NYSER.NET
To:        comp.protocols.tcp-ip
Subject:   Re: Request to be added to mailing list


	you are added.

	chris

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 00:17:47 GMT
From:      pat@SM.UNISYS.COM (Pat Ward)
To:        comp.protocols.tcp-ip
Subject:   TELNET NVDET questions

I am new to posting news articles...so I will appreciate all the help I
can get.

I need to implement TELNET (client & host) based on DIA's
DODIIS TELNET Network Virtual Data Entry Terminal (NVDET) Option
Specifications or RFC1043 TELNET Data Entry Terminal Option DODIIS
Implementation.

Questions:  Is DIA's DRS-2600-4841-85 5/85 the updated version of
DODIIS TELNET NVDET Option Specs, Apr 83?

Is there a real quick way I can get the DRS-2600...document?

Is there C source code for TELNET with the DET option available
on the news net such that I don't have to reinvent the wheel?

Has TELNET NVDET already been talked about or am I breaking new
ground?

Thanks in advance,   pat@sm.unisys.com

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 03:49:05 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

In article <8902071459.AA22881@redrump.spider.co.uk>, keith@SPIDER.CO.UK (Keith Mitchell) writes:
> Address mapping for this stuff is something of an issue. At present
> we use a lookup table, which is the only way of really doing the
> job, but if you have a lot of WAN destinations to talk to then there
> is a danger of guzzling up lots of kernel memory.

I have an implementation of IP over Datakit(r) VCS circuits that I did
for 4.3bsd; I had the same problems.  One thing I did was to do call
setup from user-level.  If a circuit to a destination is needed, but none
is available, the IP address is passed to a daemon process; this process
looks up the dialstring, makes the call, and hands the circuit back to
the dkip driver.  Because I'm using a user-level process, the mappings
can reside in a file.

The problem, though, is that *lots* of IP drivers need this sort of lookup,
especially for wide-area non-broadcast nets.  Dkip has one version, assorted
X.25 implementations have their own, dial-up SLIP needs analogous data,
etc.  Perhaps we can find some way to store the information via the
Domain Name System.  What we'd need, more or less, is a new record type
PHYSADDR in class IN; its data field would contain a type code (Datakit VCS,
X.25, etc., and a type-dependent set of dialing instructions.  The inverse
mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would
be useful as well, for validation of incoming calls.

I'm not entirely happy with this idea, though; the format of the dialing
instructions is rather too variable for a single record type.  But the
PHYSADDR record needs to be tied to the IN class, since IP is the primary
client for the information.  Suggestions, anyone?

		--Steve Bellovin
		smb@ulysses.att.com

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 05:38:57 GMT
From:      griefer@ibmarc.uucp (Allan D. Griefer)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

You might look at DREGS, a distributed games package from the University of
Wisconsin.

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Feb 89 14:15:31 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Jan '89 SIGCOMM Bibliography

Is available via anonymous FTP from sh.cs.net:sigcomm/jan89.refer

The bibliography is in UNIX refer format.  A LaTeX version is available,
if people are interested in it, please contact me.

The bibliography attempts to list every paper or book published on computer
networking and distributed systems in the preceding 3 months (note that
some things slop over -- publication dates and mailing dates aren't
always in sync).

The bibliography is printed quarterly in SIGCOMM Computer Communication
Review.  A postscript copy of the application to join SIGCOMM is appended.

Anyone who wants to submit a listing should e-mail it to me (craig@bbn.com).

Thanks,

Craig Partridge


--- cut here ----

/box-6 { % x y box-6
    newpath
    moveto
    0 6 rlineto
    6 0 rlineto
    0 -6 rlineto
    closepath
    stroke
} def

/Helvetica-Bold findfont 16 scalefont setfont

306 (APPLICATION FOR SIGCOMM MEMBERSHIP*) stringwidth pop 2 div sub 720 moveto
(APPLICATION FOR SIGCOMM MEMBERSHIP*) show

306 (ASSOCIATION FOR COMPUTING MACHINERY) stringwidth pop 2 div sub 660 moveto
(ASSOCIATION FOR COMPUTING MACHINERY) show
/Helvetica-Bold findfont 12 scalefont setfont
306 (11 WEST 42nd STREET, NEW YORK, N.Y. 10036) stringwidth pop 2 div sub 640 moveto
(11 WEST 42nd STREET, NEW YORK, N.Y. 10036) show

/Helvetica findfont 12 scalefont setfont
306 (Please enroll me as a member of the SPECIAL INTEREST GROUP) stringwidth pop 2 div sub 600 moveto
(Please enroll me as a member of the SPECIAL INTEREST GROUP) show
306 (ON DATA COMMUNICATION) stringwidth pop 2 div sub 585 moveto
(ON DATA COMMUNICATION) show

/Helvetica findfont 10 scalefont setfont
306 (Membership includes CCR Subscription.  Please make checks payable to) stringwidth pop 2 div sub 560 moveto
(Membership includes CCR Subscription.  Please make checks payable to) show
/Helvetica-Bold findfont 10 scalefont setfont
306 (ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) stringwidth pop 2 div sub 548 moveto
(ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) show

% left side text

/Helvetica findfont 10 scalefont setfont
72 468 moveto
288 0 rlineto stroke
72 458 moveto
(Name -- please print or type) show
72 424 moveto
288 0 rlineto stroke
72 414 moveto
(Mailing Address) show
72 380 moveto
288 0 rlineto stroke
72 334 moveto
288 0 rlineto stroke
72 324 moveto
(City) show
180 324 moveto
(State) show
324 324 moveto
(Zip) show

72 268 moveto
(Signature) show
124 268 moveto
240 0 rlineto stroke

72 220 box-6
82 220 moveto
(Please send information on ACM membership.) show

72 200 box-6
82 200 moveto
(New address. Please change my ACM record.) show

72 150 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(*NOTE: ) show
/Helvetica findfont 10 scalefont setfont
(ACM members renewing within the next three months do not need to use this application.) show
72 138 moveto
(Simply add SIGCOMM to your renewal invoice.) show

72 100 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(BACK ISSUES: ) show
/Helvetica findfont 10 scalefont setfont
(Back issues of SIGCOMM Computer Communication Review are available) show
72 88 moveto
(at the single copy price of $10.  ACM members receive a 25% discount.) show

% right side text

390 480 moveto
(Annual Membership Dues are:) show
394 468 moveto
($15 for ACM Members) show
394 456 moveto
($10 for ACM Student Members) show
394 444 moveto
($37 for Non-ACM Members) show

380 420 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 420 moveto
(ACM MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 400 moveto
(Member #) show
436 400 moveto
108 0 rlineto stroke
390 390 moveto
(Send no money now.  Dues are payable) show
390 380 moveto
(when ACM membership is renewed.) show


380 350 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 350 moveto
(ACM STUDENT MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 330 moveto
(Member #) show
436 330 moveto
108 0 rlineto stroke
390 320 moveto
(Send no money now.  Dues are payable) show
390 310 moveto
(when ACM membership is renewed.) show

380 280 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 280 moveto
(NON-ACM MEMBER) show
390 260 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is annual dues of $37.) show

380 230 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 230 moveto
(SUBSCRIPTION TO CCR ONLY) show
390 210 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is $25 annual subscription fee.) show
390 200 moveto
(NOTE: SIGCOMM Membership includes) show
390 190 moveto
(subscription to CCR.) show

showpage
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 06:23:31 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

In article <11194@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>Perhaps we can find some way to store the information via the
>Domain Name System.  What we'd need, more or less, is a new record type
>PHYSADDR in class IN; its data field would contain a type code (Datakit VCS,
>X.25, etc., and a type-dependent set of dialing instructions.  The inverse
>mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would
>be useful as well, for validation of incoming calls.
>
>I'm not entirely happy with this idea, though; the format of the dialing
>instructions is rather too variable for a single record type.  But the
>PHYSADDR record needs to be tied to the IN class, since IP is the primary
>client for the information.  Suggestions, anyone?

If you can live without the IN class, the Hesiod nameserver mods to
BIND we made at MIT would seem to be just what you want.  It essentially
uses class HS, type TXT for its resource records.  The TXT type
is just free-form ASCII text, and further qualification ("typing") is
done with a second string, the HesiodNameType, which when concatenated
with the name of the object to be resolved, is passed by the Hesiod
calls to the DNS.  Since there was no way to predict what data Hesiod
would be carrying in the future, we decided against defining new RR types,
preferring to encode this in the domain names of the RRs.

	char **cp;
e.g.,
	cp = hes_resolve(hostname-or-ip-addr-as-octet-string, "physaddr");
	/* Now cp == NULL */
	/* or cp[0], cp[1], cp[N-1] contain strings and cp[N] == NULL */
	cp[0] == "x25 some-long-ISO-addr", etc.
You get the idea.

In our use of Hesiod within Athena, we quite commonly return strings
of the form
	TYPE strings-meaningful-for-said-TYPE
and application which use Hesiod know about the structure of the
strings for a particular HesiodNameType.

If you want to examine Hesiod, it can be retrieved as pub/hesiod.tar.Z
from athena-dist.mit.edu.
-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 06:38:25 GMT
From:      hutton@scubed.arpa (Thomas Hutton)
To:        comp.protocols.tcp-ip
Subject:   Request of info/recomendations on bridges or gateways

We are soon going to need to connect our three San Diego sites ethernets
via T1 lines.  I am interseted in hearing recomendations on various
hardware for doing this.  

Since we need to transfer not only IP traffic but DECNET as well Im assuming
I need to use a bridge vrs a gateway product.  One of the things we would
like to do is have a redundent set of circuits:

                  Site A
                  /    \
                 /      \
             T1 /        \ T1
               /          \
              /            \
           SiteB----------Site C
                    T1

I am concerned with the problem of routing loops.  I would really like something
that could while avoiding loop problems, split the traffic over the links
to optimize the bandwidth of the links.

Help/Info is appreciated.

Thanks,
	Thomas Hutton
	hutton@scubed.com

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1989 14:56 EST
From:      tmac@sol.engin.umich.edu
To:        VAF@Score.Stanford.EDU, CERF@A.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, smart%ditmela%latcs1%wcc@murtoa.cs.mu.oz.au
Subject:   Re: Interactive game playing over an internet network
I haven't actually played xtrek (though we have it) but xconq
I have played over the network and it does provide an intersting
effect to the game. I wouldn't mind seeing more like this.  Plus,
building it using the X toolkit provides (though xconq could use
a little improvement) a good user interface.

	_Tom
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 11:27:52 GMT
From:      heimir@rhi.hi.is (Heimir Thor Sverrisson)
To:        comp.protocols.tcp-ip,comp.unix.microport,comp.unix.xenix
Subject:   SLIP for 386/ix

Is there an implementation of SLIP (Serial Line Internet Protocol ?) for
machines running under Interactive 386/ix. This is System V.3.2 and I
think the TCP/IP-Ethernet implementations use STREAMS. Please respond
via email, I'll summarize to the net if anything comes up.
--
Heimir Sverrisson
NeuroSoft Inc.

heimir@rhi.hi.is

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 14:52:42 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   DoDIIS TELNET NVDET Option

RFC 1043 by Thompson and Yatsuda (sp?) is the best definition of DoDIIS
TELNET Network Virtual Data Entry Terminal (NVDET) Option.  The earlier
DIA publications are not terribly clear on what is required.  Most of the
implementations that I have seen are embedded in systems that are not
publicly available and have a tendency to be application specific.  I
have not seen or heard of anyone touting that they have a publicly or
commercially available TELNET product with support for the NVDET option.

Merton Campbell Crockett                                 Contel Federal Systems
System Software Manager                 Information Management Systems Division
Production Systems                              31717 La Tienda Drive, Box 5027
01(818)706-5573                               Westlake Village, CA   91359-5027

Internet:  mcc@etn-wlv.EATON.COM     Easynet:   DECWRL::"mcc@etn-wlv.EATON.COM"

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 16:02:08 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   mail filtering

Some time ago there was a discussion of mail filtering.  The thrust was
to filter real mail (!) from things masquerading as mail.  Seems hard to
do, maybe impossible. But does anyone remember how this discussion ended up
or of any work being done in this area?

                    -Hal 

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 1989 22:02-EST
From:      CERF@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: More on IP over X.25
Art,

Why struggle to translate from X.121 to IP if the arriving
internet packet has a source IP address in it...oh,
the source IP address isn't the address of the gateway,
if there was a gateway, but the IP address of the source.
Sorry, that's what I forgot. So you want a way to relay
return traffic by way of the VC on which it was delivered.
Seems to me that return traffic is going to get routed
by the gateway based on the ultimate IP destination address
of the returning traffic. If the IP address of the intermediate
gateway can be mapped to an X.121 address, you could look for
an existing X.25 VC with that destination X.121 address and
put the packet on that - without having to map from X.121 to
IP at any time, yes?

Vint
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 17:11:06 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP over X.25 (request for info)

From offline sources I gather that some people were confused about what
the X.121/IP address mapping discussion really meant.  Here is an
attempt at an explanation.  After that, I have some remarks on the NSAP
vs. IP issue.

The point of an X.121/IP address mapping table is to enable mapping in
the IP -> X.121 direction, not the other way around.  This is needed to
identify or create an appropriate X.25 virtual circuit to carry an IP
datagram through an X.25 subnet to its destination or an appropriate
gateway.  The reverse mapping turns out not to be a very useful thing,
and thus is not really an issue.

It also happens that the list of X.121 addresses appearing in the
mapping table can be used for a rough validation of the legitimacy of
an incoming X.25 call.  In general, however, it is not possible to use
the reverse mapping X.121 -> IP to validate the IP addresses contained
in datagrams arriving over an X.25 VC whose other end is an X.121
address in the table.  Although the entity on the other end of the X.25
VC has an IP address, it does not necessarily follow that datagrams
received from the other end will have that particular IP address as the
IP source address.

There are three main reasons why the address might be different.
     (1) The other end of the X.25 VC is an IP gateway (router).  In
this situation there will be many IP source addresses appearing in the
datagrams arriving on that VC, and the IP address of the gateway itself
will not usually appear in those datagrams.
     (2) Source routing is being used.  In this case, the IP source
address might be anything, and the address of the gateway at the far
end of the VC will generally appear in the option, but this is not
assured.
     (3) The device at the other end is claiming an inappropriate IP
address.

The idea of checking each datagram's IP source address and the X.121
address of the other end of the X.25 VC on which it arrived against the
static table to detect spoofing is meant to deal with (3) above, but it
causes legitimate actions (1) and (2) to fail.  The functions (1) and
(2) are part of the normal IP definition and one ought not to break
these things unless there are particularly strong reasons to do so in a
specific limited usage environment.

One might try to cope with (1) by maintaining some knowledge of
legitimate backside network numbers for such gateways, but this
requires a more elaborate static table and tends to be impractical if
the backside has backdoors into other parts of the Internet.

If you distinguish between non-gateways and gateways in the static
table, it would be possible to use logic to cope with case (2) for
the non-gateways.  This would require checking for source routing
options.  This can work because the non-gateway is either the source
or has to have been named explicitly in the source route, in order
for a properly functioning gateway to have sent it the packet in the
first place.  (This logic doesn't hold for gateways because gateways
may have been routed to because of extrinsically derived information at
the prior hop.)

For the gateway case, security protection against unauthorized use of a
network (remember that the X.25 VC is a network/subnet in the IP sense)
can be implemented separately from VC management and X.121 address
mapping, and this is a nice feature to have.  It does not make sense to
shut down an X.25 VC to a gateway because an unauthorized party (or
someone impersonating one) has sent a datagram through it.  If you do
this, you make it easy for troublemakers to induce denial of service to
legitimate users.  Instead, filtering should be done at appropriate
gateways, and the undesirable datagrams should be dropped, with
appropriate ICMP messages to their source if feasible.  This feature
exists in several commercial gateway boxes.  The same thing can be done
in end systems, but the utility there is less clear.

Now then, about IP and ISO and so on.  The RFC that discusses IP-flavored
NSAPs is not 100% up with the latest thinking there.  As far as I know,
the current thought is IDEA003.  This scheme talks explicitly about the
case of isolated end systems on PDNs but the NSAP treatment essentially
ignores the question of IP address association.  The object of these
documents was to support ISO stacks, not IP.  The reason for the hybrid
NSAP format was to provide hooks for using IP routing mechanisms to
support NSAP interpretation, rather than the other way around.

There is official ISO work on the usage of CLNP over X.25, and this is
the mode of operation envisioned (most of the time) by US GOSIP.  But
it is not clear that all of the questions one might ask have really been
answered - or they may have been answered in ways you won't like.  The
first octet of CUD is now officially supposed to contain the protocol
identifier when you plan to use OSI protocols.  There is a designated
value, hex 81, identifying CLNP.  Distinct values are assigned (I don't
recall them) for ES-IS and IS-IS, which apparently means that it is
necessary to have two X.25 VC's to support one user's traffic between
two network entities.  I'm surprised that we aren't hearing howls from
gateway vendors already.  ES-IS should handle the problem of converting
the NSAP to an X.121 address, but of course you need a preconfigured
X.121 address for the IS so you can talk to it to ask the question, and
the IS (or another IS) still needs to be told what the mapping and
topology are.  These matters are outside the scope of the ISO specs.

Bill Barns

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 17:44:27 GMT
From:      Mills@udel.edu
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet "time servers" and UNIX timed

Dave,

First, please note your list of truechimers is out of date. Fetch the
file pub/ntp/clock.txt from louie.udel.edu as the latest list of servers
that chime the Network TIme Protocol (NTP). See RFC-1059 for a description
of NTP and either Louie Mamakos (louie@trantor.umd.edu) or Mike Petry
(petry@trantor.umd.edu) for the ntpd Unix daemon.

The list of NTP servers cited includes only the Fuzzball NTP servers,
both primary (i.e. directly connected to a radio clock) or secondary
(derives time from a primary clock via the network). There are many
more NTP servers, a few primary and a lot secondary, using ntpd. A
message to the ntp@trantor.edu list should smoke out a few near you.
As suggested in RFC-1059, you may find your needs well met by peering
with a couple of the primary servers on the NSFNET Bluebone (e.g. NCAR,
SDSC or UIUC) and a couple of nearby secondary servers.

NTP is not the only clock in town, even on the Fuzzballs. I found a
couple of thousand responded to either UDP/TIME (37), UDP/NTP (113)
or ICMP/Timestamp in a survey a year ago. While TCP-based time protocols
such as TCP/DAYTIME (13) are available on many machines, I for one
have strongly discouraged using TCP for that, as system resources can
quickly become congested if large numbers of connections are clanking
open and close. Both TIME and NTP can operate over UDP without any
state storage in the server and with only minimal state storage in the
client.

While most organizations I know of that use NTP distribute time within
their system with NTP as well, there is no reason in principle why timed
could not be used within the LAN, other than a small change to the
master-election algorithm. A query to the ntp@trantor.umd list will probably
smoke somebody that has already done that. While not strictly part of NTP
itself, the full accuracy of the service requires that the local-clock
adjustment mechanism by engineered. Both the Fuzzballs and ntpd do a very
careful job of that using phase-lock loop technology. In principle, timed
could do that as well. Maybe somebody will even make that happen.

Dave

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 19:01:49 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: first release of IMAP software

mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin) writes:
> The IMAP software is now ready for distribution from SUMEX-AIM.STANFORD.EDU
> (internet address [36.44.0.6]).

	Several problems.  First, when I did "ftp sumex-aim.stanford.edu" I
got connected to sumex-2060.stanford.edu.  I can't seem to reproduce it, so
maybe it was some transient nameserver problem?  But, the real point of
this message is to remind people that when they announce the availability
of software, it would be a good idea to give some idea of what it was.  I
havn't the foggiest idea what IMAP is and there isn't even a READ-ME file
that I can ftp; to figure out if I want it I have to pull the whole 365
kbyte compressed tar file from one coast to the other.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 19:15:31 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Jan '89 SIGCOMM Bibliography


Is available via anonymous FTP from sh.cs.net:sigcomm/jan89.refer

The bibliography is in UNIX refer format.  A LaTeX version is available,
if people are interested in it, please contact me.

The bibliography attempts to list every paper or book published on computer
networking and distributed systems in the preceding 3 months (note that
some things slop over -- publication dates and mailing dates aren't
always in sync).

The bibliography is printed quarterly in SIGCOMM Computer Communication
Review.  A postscript copy of the application to join SIGCOMM is appended.

Anyone who wants to submit a listing should e-mail it to me (craig@bbn.com).

Thanks,

Craig Partridge


--- cut here ----

/box-6 { % x y box-6
    newpath
    moveto
    0 6 rlineto
    6 0 rlineto
    0 -6 rlineto
    closepath
    stroke
} def

/Helvetica-Bold findfont 16 scalefont setfont

306 (APPLICATION FOR SIGCOMM MEMBERSHIP*) stringwidth pop 2 div sub 720 moveto
(APPLICATION FOR SIGCOMM MEMBERSHIP*) show

306 (ASSOCIATION FOR COMPUTING MACHINERY) stringwidth pop 2 div sub 660 moveto
(ASSOCIATION FOR COMPUTING MACHINERY) show
/Helvetica-Bold findfont 12 scalefont setfont
306 (11 WEST 42nd STREET, NEW YORK, N.Y. 10036) stringwidth pop 2 div sub 640 moveto
(11 WEST 42nd STREET, NEW YORK, N.Y. 10036) show

/Helvetica findfont 12 scalefont setfont
306 (Please enroll me as a member of the SPECIAL INTEREST GROUP) stringwidth pop 2 div sub 600 moveto
(Please enroll me as a member of the SPECIAL INTEREST GROUP) show
306 (ON DATA COMMUNICATION) stringwidth pop 2 div sub 585 moveto
(ON DATA COMMUNICATION) show

/Helvetica findfont 10 scalefont setfont
306 (Membership includes CCR Subscription.  Please make checks payable to) stringwidth pop 2 div sub 560 moveto
(Membership includes CCR Subscription.  Please make checks payable to) show
/Helvetica-Bold findfont 10 scalefont setfont
306 (ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) stringwidth pop 2 div sub 548 moveto
(ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) show

% left side text

/Helvetica findfont 10 scalefont setfont
72 468 moveto
288 0 rlineto stroke
72 458 moveto
(Name -- please print or type) show
72 424 moveto
288 0 rlineto stroke
72 414 moveto
(Mailing Address) show
72 380 moveto
288 0 rlineto stroke
72 334 moveto
288 0 rlineto stroke
72 324 moveto
(City) show
180 324 moveto
(State) show
324 324 moveto
(Zip) show

72 268 moveto
(Signature) show
124 268 moveto
240 0 rlineto stroke

72 220 box-6
82 220 moveto
(Please send information on ACM membership.) show

72 200 box-6
82 200 moveto
(New address. Please change my ACM record.) show

72 150 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(*NOTE: ) show
/Helvetica findfont 10 scalefont setfont
(ACM members renewing within the next three months do not need to use this application.) show
72 138 moveto
(Simply add SIGCOMM to your renewal invoice.) show

72 100 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(BACK ISSUES: ) show
/Helvetica findfont 10 scalefont setfont
(Back issues of SIGCOMM Computer Communication Review are available) show
72 88 moveto
(at the single copy price of $10.  ACM members receive a 25% discount.) show

% right side text

390 480 moveto
(Annual Membership Dues are:) show
394 468 moveto
($15 for ACM Members) show
394 456 moveto
($10 for ACM Student Members) show
394 444 moveto
($37 for Non-ACM Members) show

380 420 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 420 moveto
(ACM MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 400 moveto
(Member #) show
436 400 moveto
108 0 rlineto stroke
390 390 moveto
(Send no money now.  Dues are payable) show
390 380 moveto
(when ACM membership is renewed.) show


380 350 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 350 moveto
(ACM STUDENT MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 330 moveto
(Member #) show
436 330 moveto
108 0 rlineto stroke
390 320 moveto
(Send no money now.  Dues are payable) show
390 310 moveto
(when ACM membership is renewed.) show

380 280 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 280 moveto
(NON-ACM MEMBER) show
390 260 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is annual dues of $37.) show

380 230 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 230 moveto
(SUBSCRIPTION TO CCR ONLY) show
390 210 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is $25 annual subscription fee.) show
390 200 moveto
(NOTE: SIGCOMM Membership includes) show
390 190 moveto
(subscription to CCR.) show

showpage

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 19:56:00 GMT
From:      tmac@SOL.ENGIN.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

I haven't actually played xtrek (though we have it) but xconq
I have played over the network and it does provide an intersting
effect to the game. I wouldn't mind seeing more like this.  Plus,
building it using the X toolkit provides (though xconq could use
a little improvement) a good user interface.

	_Tom

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 20:18:28 GMT
From:      tai%hpdstma@HP-SDE.SDE.HP.COM (Tai Jin)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet "time servers" and UNIX timed

I'm not sure if anyone has ported timed to HP-UX, but we have ported
ntp.  Since HP-UX doesn't have an adjtime(2) system call I had to write
an emulator (as a user process) which works on 6.0/2.0 or later
releases.

We don't have the latest ntp ported yet (I'm not sure if the latest
code is stable yet), but if you need something now I can give you what
we have that works.

...tai

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 21:05:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  ATT 3b2/400 and TCP/IP

To clarify the note from Karl Kleinpaste (of Ohio State?):

1.  WIN/TCP for 3b is produced by Wollongong, but is marketed and supported
by AT+T.

2.  A new release of the software, for SVR3.2, was just delivered to AT+T.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 89 22:17:30 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS" extension


From: David L. Kashtan <IU.AI.SRI.COM!KASHTAN@talcott.harvard.edu>
>That has, in fact, been the solution for a LONG time.  Make a program that
>can PACK/UNPACK VMS Backup Savesets using files that can be transferred in
>FTP IMAGE mode.  Aside from various the system administration problems that
>have already been enumerated there is also a psychological implication.  The
>fewer steps you have to go through to get a file transfered the happier you
>are (witness the preference of "rcp" over FTP when available).  There have
>been many times that I have used slower file transfer methods just because
>it was less work for me (the difference in transfer times has to be pretty
>significant for me to prefer the more laborious method).  There is also the
>issue of ensuring that EVERYBODY you might want to exchange VMS files with
>has all the appropriate tools (isn't this what standards are for?).  As a
>TCP vendor we are very concerned about providing MAXIMUM functionality to our
>customers -- and this issue is of pretty serious concern to us.  So, rather
>than just DO something so that machines running our software can communicate
>in this fashion we have asked the TCP community to discuss the best way to set
>a standard so that we can interoperate with other VMS TCPs for this "extended"
>service yet still interoperate with the rest of the TCPs in the world.  I
>feel that Ken's suggestions are a good solution to the problem (but I am
>obviously biased).

(what's wrong with biased :-)

If it's a matter of saving steps why not just build a DCL wrapper
which does the job? Heck, Interlisp-D had what amounted to a very good
NFS based on vanilla FTP, required no changes to the server (eg. UNIX
or VMS) system as I remember.

>>It wouldn't really occur to me to ask for an extension to FTP to
>>transfer an arbitrary file tree between Unix's (for example), I'd just
>>bundle it up with tar and send *that* (possibly compressing and/or
>>uuencoding if need be.) In fact, that's SOP.
>
>But that is just the point -- UNIX files and FTP IMAGE transfer are a good
>match (i.e. they give you the functionality that you need).  We are looking
>to do something equivalent for VMS, where IMAGE transfers are not sufficient.

You missed my point. Unix directory trees and FTP IMAGE are *not* a
good match. You have to bundle it up with tar (or equivalent) first.

And saving/restoring file modes requires this even for a single file.

Maybe this gets closer to the heart of the matter, perhaps what VMS
really needs is an analog of Unix's RCP which can transfer directory
trees and preserve file modes. Why not a separate VMSCP utility for
VMS? At least that idea extrapolates cleanly to any number of OS's and
we can leave FTP alone to do what it was designed to, zap the bytes
from point A to point B with a minimum of interpretation (I'd be more
in favor of dropping TENEX mode from FTP.)

Just out of curiosity, how does DECNET handle all this (and, to go one
step further, is FTAM powerful enough to satisfy this requirement?)?

	-Barry Shein, ||Encore||

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 89 03:02:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: More on IP over X.25

Art,

Why struggle to translate from X.121 to IP if the arriving
internet packet has a source IP address in it...oh,
the source IP address isn't the address of the gateway,
if there was a gateway, but the IP address of the source.
Sorry, that's what I forgot. So you want a way to relay
return traffic by way of the VC on which it was delivered.
Seems to me that return traffic is going to get routed
by the gateway based on the ultimate IP destination address
of the returning traffic. If the IP address of the intermediate
gateway can be mapped to an X.121 address, you could look for
an existing X.25 VC with that destination X.121 address and
put the packet on that - without having to map from X.121 to
IP at any time, yes?

Vint

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Feb 89 09:14:53 EST
From:      Douglas Greenwald <R1DAG%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP/IP Readers <tcp-ip@sri-nic.arpa>
Subject:   Need info
Hello gentle readers.

We at the University of Akron's College of Engineering are in the
process of converting to a supermini to a system of workstations.  They
will be connected using 802.3, TCP/IP, thin lan.  We are looking for
recommendations for routers to connect us to the campus enet.  The
campus net is located in a different building to which we have fiber
optic connections.  We will eventually be the main engineering network
so we do need a router as opposed to a bridge.

Please respond to me directly as I don't think my subscribe command
ever made it to the listserv yet.

                             Thanx.

                             Doug Greenwald,
                             Engineering Computer Graphics Facility,
                             College of Engineering,
                             University of Akron.
                             (R1DAG@AKRONVM)
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 1989 18:36-EST
From:      CERF@A.ISI.EDU
To:        kent@WSL.DEC.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interactive game playing over an internet network
Chris,

By academic suicide, I take it you mean failing to pay attention
to studies, etc.

Is Langston reachable? The distributed game sounds worth writing
a paper or at least a column.

Vint
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 89 14:14:53 GMT
From:      R1DAG@AKRONVM.BITNET (Douglas Greenwald)
To:        comp.protocols.tcp-ip
Subject:   Need info

Hello gentle readers.

We at the University of Akron's College of Engineering are in the
process of converting to a supermini to a system of workstations.  They
will be connected using 802.3, TCP/IP, thin lan.  We are looking for
recommendations for routers to connect us to the campus enet.  The
campus net is located in a different building to which we have fiber
optic connections.  We will eventually be the main engineering network
so we do need a router as opposed to a bridge.

Please respond to me directly as I don't think my subscribe command
ever made it to the listserv yet.

                             Thanx.

                             Doug Greenwald,
                             Engineering Computer Graphics Facility,
                             College of Engineering,
                             University of Akron.
                             (R1DAG@AKRONVM)

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 89 16:20:05 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Request of info on bridges or gateways

In article <8902080638.AA14652@SCUBED.ARPA> 
>hutton@scubed.arpa (Thomas Hutton) writes:
>We are soon going to need to connect our three San Diego sites ethernets
>via T1 lines.  I am interseted in hearing recomendations on various
>hardware for doing this.  
>
>Since we need to transfer not only IP traffic but DECNET as well Im assuming
>I need to use a bridge vrs a gateway product.  One of the things we would
>like to do is have a redundent set of circuits:
>
	If you install three bridges, you will need spanning tree or
packet loops will result.  You will not be able to use any part of the
bandwidth of the redundant link.

	If you install routers, you can use all three links for
throughput and for redundancy.  If you need IP and DECnet, you can
find routers that will route both.  If you want bridging too (like
LAT, ugh) you can buy a cisco HyBridge which will route IP and DECnet
and bridge whatever other protocols you want.  I have not yet
personally set up a HyBridge, but I read the Rel 7.0 addendum and it
looks like a reasonable hybrid.

	The new cisco hardware is full-ethernet bandwidth, so the old
argument about packet switching slowness of routers is now moot.
>
>I am concerned with the problem of routing loops.  I would really
> like something
>that could while avoiding loop problems, 
>split the traffic over the links
>to optimize the bandwidth of the links.
>
	All modern routing implementations should have no trouble with
three links in your configuration.  Spanning tree will stop bridge
loops, but lose bandwidth, idling one link completely.

	BTW, are your sites within 4-5 miles line of sight of each
other?  You could save a lot of money with microwave and you could run
full Ethernet bandwidth, too.  There are, at last count, three vendors
selling such products.

	Kent England, Boston University

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 89 18:36:23 GMT
From:      emv@a.cc.umich.edu (Ed Vielmetti)
To:        comp.sources.d,comp.protocols.tcp-ip
Subject:   multiparty, real-time, lightweight sequenced communications

What's the state of the art in real-time chat programs connected
across an internet?  The goal is something like 'party' only over
multiple systems.  I've heard of 'phone' but don't have any more
pointers than that, & there must be others.

I'm sure it would be a good testbed for multicast protocols or some
sort of lightweight transaction scheme.

[cross-posted to comp.protocols.tcp-ip, cause I'm not interested in
single system solutions.]

--
Edward Vielmetti, U of Michigan Computing Center mail group

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 89 22:41:35 GMT
From:      wiltzius@lll-lcc.llnl.gov (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   SNMP client software.


Anyone know where I can get or purchase an SNMP client that
runs on (in order of preference) SUN 3/50's running 3.4,
Ultrix 2.0 or IBM PC (I suspect we are a bit behind the
times on OS releases)?

BTW I just received a Wellfleet LAN-LAN IP router that acts
as an SNMP agent.

Thank you, thank you.
  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 89 23:36:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

Chris,

By academic suicide, I take it you mean failing to pay attention
to studies, etc.

Is Langston reachable? The distributed game sounds worth writing
a paper or at least a column.

Vint

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 00:00:13 GMT
From:      gfb@wsc-sun.UUCP (Gareth Beale)
To:        comp.protocols.tcp-ip
Subject:   email/PROFS


Does anyone on this list know of a product that allows messages to flow
between IBM PROFS and email?

Please respond directly as well as to the net.  Lately I have only been 
getting my mailing list stuff for the last few days of the week (I assume 
messages have still been going out Monday through Wednesday).
Thank you,

Gareth Beale (206)865-5375             #  e-mail:
Boeing Computer Services, M/S 7A-35    #  gfb@wsc-sun.boeing.com
P.O. Box 24346                         #  or:
Seattle, Wa. 98124-0346                #  bcsaic.boeing.com!wsc-sun!gfb

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 00:11:21 GMT
From:      kent@WSL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

Vint,

	By academic suicide, I take it you mean failing to pay attention
	to studies, etc.

Yup, exactly. Someone wrote to me and said that a modern version of the
game is available on ucbvax.berkeley.edu. 

chris

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 00:16:24 GMT
From:      brock@brock.cs.unc.edu (J. Dean Brock)
To:        comp.protocols.tcp-ip
Subject:   FTPable list of *.edu, *.com, *.org, etc.

Is there anyone out there who maintains an FTP-able list of
the variously allocated 2nd-level domain names?

The root name servers must exchange this information ---

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 00:40:01 GMT
From:      gfb@wsc-sun.UUCP (Gareth Beale)
To:        comp.protocols.tcp-ip
Subject:   RJE over TCP/IP?


Migration to newer technology is often gradual, and you can't always get rid 
of your favourite millstones.  Assuming a batch processing machine with a 
UNIX operating system, and remote hosts capable of running TCP/IP protocols,
does there exist an implementation of any kind of RJE support?  I recently 
noticed port #5 is reserved for RJE, and from that dug up RFC's 407 and 740.
However, these are very old (1972 and 1977 respectively), and it's not clear to
me what protocol was used.  Telnet and FTP are mentioned, but there is talk of
ICP sockets (was ICP some predecessor of TCP?).

Any information will be gratefully received, but I was hoping to avoid any 
discussion of the merits or otherwise of RJE type service.  By the way, I
view RJE as the ability to send a job stream to a remote system and get the
output back, not any particular IBM-type definition of precisely what the
term means.

Since I am having some hiccoughs in my receipt of mail from this list, I would 
appreciate direct responses as well as anything posted.

Thank you,

Gareth Beale (206)865-5375             #  e-mail:
Boeing Computer Services, M/S 7A-35    #  gfb@wsc-sun.boeing.com
P.O. Box 24346                         #  or:
Seattle, Wa. 98124-0346                #  bcsaic.boeing.com!wsc-sun!gfb

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 02:18:44 GMT
From:      cmf@cisunx.UUCP (Carl M. Fongheiser)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

In article <8902061636.AA13703@pinocchio.UUCP> bzs@pinocchio.UUCP (Barry Shein) writes:
>How does one transfer ISAM (eg.) files by tape between VMS systems?
>Why can't a similar mechanism be used?  The obvious advantage is that
>such representations should even work when one wants to push such
>files through third-party, non-VMS systems since all the info to
>re-create the file gets bundled into the transferred file itself
>rather than relying on wire transmission as server/client commands.

Not a terrific example.  Normally this is done using BACKUP, but
BACKUP adds all kinds of extra gunk (like CRC's and ECC blocks) that
shouldn't be necessary for FTP.  Also, BACKUP savesets happen to
be some of the hardest things to transfer using FTP, since BACKUP likes
to create giant records (32,258 bytes by default for disk savesets),
and unlike tar, can't deal with the file if it shows up with a smaller
record size on the other end.

Naturally, VMS users have ways of dealing with this, but they're ugly
(probably uglier than the code required to deal with STRU VMS!)

>It wouldn't really occur to me to ask for an extension to FTP to
>transfer an arbitrary file tree between Unix's (for example), I'd just
>bundle it up with tar and send *that* (possibly compressing and/or
>uuencoding if need be.) In fact, that's SOP.

Sure, and it works fine and dandy.  But tar came with your system,
and you didn't need any extra gunk to make that all work, did you?
It just happens that Unix files are nice, simple, easy beasts to deal
with.  VMS files aren't.  BACKUP makes it a little easier, but it really
is a big hassle to do something like that, since you can't directly
FTP a BACKUP saveset either.

>At best I could imagine some sugar in the VMS server/clients which
>might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
>send the result of that, and if the other side is a VMS site he'll
>recognize the header and automatically do the opposite", but none of
>that needs a change in the protocol spec since it only affects the OS
>interface, not the network interface (the file would just be xferred
>binary I'd guess.) Personally I hate that kind of magic.

OK, I'll bite here.  What if the file I'm transferring contains that
magic string or number which tells the FTP server/client to go into
the magic mode, but doesn't need the interpretation.  How do I turn
that off?

>No FTP extensions should be needed (eg. something like embedding UNIX
>magic numbers should do it.) And again, if the other side wasn't a VMS
>site it would work also (that is, would store the file image but make
>no attempt to unpack it.) A good example of the utility of this
>approach is putting VMS files for Anonymous FTP onto a non-VMS system.

Sure, but as I said above, you'd need some out-of-band way to turn it
off.

>Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
>have been using for years?

Sure it is, but all of those operating systems have comparatively
simple file formats, and all of those programs write nice, simply
formatted files themselves.  VMS is blessed with neither, and unless
someone's volunteering to write a program to do something like that,
I'd rather let the VMS FTP's have a little private magic to themselves.

				Carl Fongheiser
				University of Pittsburgh
				cmf@unix.cis.pittsburgh.edu
				...!pitt!cisunx!cmf
				CMF@PITTVMS.BITNET

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 03:32:00 GMT
From:      keyles@rubbs.FIDONET.ORG (Michael Keyles)
To:        comp.protocols.tcp-ip
Subject:   Network Management

Hi, 

Does anyone have a pointer to a SNMP package for a Sun and/or 
an RT?  My firm is starting to have several machines that 
produce snmp stats, but we have no way of looking at it.  

Thanks.  

Mike 

--  
Michael Keyles - via FidoNet node 1:107/520
UUCP: ...!rutgers!rubbs!keyles
ARPA: keyles@rubbs.FIDONET.ORG

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 04:03:50 GMT
From:      hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS)
To:        comp.protocols.tcp-ip
Subject:   Whereabouts of NCD

Hi,

NCD (Network Computing Devices) recently announced an X Windows Terminal, the 
NCD16. Can anyone give me the address/fax/phone to the company?

Thanx
Heng-Wah

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 04:52:01 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

>If it's a matter of saving steps why not just build a DCL wrapper
>which does the job? Heck, Interlisp-D had what amounted to a very good
>NFS based on vanilla FTP, required no changes to the server (eg. UNIX
>or VMS) system as I remember.
  This is a solution -- though not a pretty one.  It loses on several
  fronts:
	1) It doesn't address the issues of system management and disk
	   quotas.   It is definitely not a selling point for the software
	   if you are required to have 2 times the disk space available
	   in order to transparently transfer the files

	2) It is considerably slower than just transferring the files

	3) Even with the wrapping (though I guess we could make the FTP
	   client do it behind your back) it is not as convenient to use
	   as directly using FTP.

	4) What about the destination site where you don't have login
	   access to invoke the wrapping.

>>>It wouldn't really occur to me to ask for an extension to FTP to
>>>transfer an arbitrary file tree between Unix's
>>>	.
>>>	.
>>
>>But that is just the point -- UNIX files and FTP IMAGE transfer are a good
>>match (i.e. they give you the functionality that you need).  We are looking
>>to do something equivalent for VMS, where IMAGE transfers are not sufficient.
>
>You missed my point. Unix directory trees and FTP IMAGE are *not* a
>good match. You have to bundle it up with tar (or equivalent) first.

IMAGE mode exactly matches the transfer characterstics you need for the UNIX
file data.  The LIST/NLST FTP commands provide "almost" everything you need
to implement directory tree copying (in fact -- you just need an extension to
the UNIX wildcard syntax to make that possible).  And the current FTP spec.
is most definitely well suited to copying whole UNIX directories (MGET/MPUT).
So in many cases "tar" is not needed -- and the facilities are already there
for a vendor to implement a full UNIX directory tree copy without having to
resort to an FTP protocol extension.  We are just trying to arrange for the
same situation for VAX/VMS.

>Maybe this gets closer to the heart of the matter, perhaps what VMS
>really needs is an analog of Unix's RCP which can transfer directory
>trees and preserve file modes. Why not a separate VMSCP utility for
>VMS? At least that idea extrapolates cleanly to any number of OS's and
>we can leave FTP alone to do what it was designed to, zap the bytes
>from point A to point B with a minimum of interpretation (I'd be more
>in favor of dropping TENEX mode from FTP.)

I wouldn't argue of this one much -- a VMS equivalent to UNIX's RCP is
a good idea (and we will probably by supplying one sometime in the future)
but it will be even more difficult to get all the VMS TCP vendors to agree
on a whole NEW application protocol than for them to agree to an extension
to an existing protocol (an extension which, by the way, requires very little
effort for VMS TCP vendors to implement -- this goes a LONG way towards
ensuring that all VMS TCP's can interoperate).

>Just out of curiosity, how does DECNET handle all this

DECNET uses a file data transfer protocol called DAP -- which was designed
to address exactly these issues of sharing different "format" files between
heterogeneous DEC systems (and, although the implementations are a bit slow
for my taste, DAP managed to do a pretty decent job of allowing transparent
file transfers between not just VAX/VMS systems but also to/from most other
systems sold by DEC over the years -- like TOPS-20, RSX ...etc).  I would
point out that DAP is complicated enough that few people would WANT to adopt
it as any kind of standard.

Still battling for a "STRU O xxx" standard,
David
-------

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 05:13:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   TENEX mode


    (I'd be more in favor of dropping TENEX mode from FTP.)

Barry,

I hope you were just being flippant, but I saw no smiley there...  So,
lest someone might take that comment seriously, let's make it clear
that TENEX is just an alias for TYPE L 8 (not TYPE L 32, please!).
But, if you really are seriously suggesting to drop TYPE L 8, then we
have a problem.  How else can you send bytes from one machine
architecture to another?  Certainly TYPE I (image) isn't a universal
solution, even between machines of the same word size and operating
system!

--Frank

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 05:40:57 GMT
From:      melvin@jacobs.CS.ORST.EDU (Todd Ferguson)
To:        comp.sources.d,comp.protocols.tcp-ip
Subject:   Re: multiparty, real-time, lightweight sequenced communications

In article <8879@mailgw.cc.umich.edu> emv@mailgw.cc.umich.edu (Ed Vielmetti) writes:
>What's the state of the art in real-time chat programs connected
>across an internet?  The goal is something like 'party' only over
>multiple systems.  I've heard of 'phone' but don't have any more
>pointers than that, & there must be others.

I have recently got ahold of a program called irc (Internet Relay Chat)
Each machine runs its own server and the servers are link in a tree fashion
to a master server.  I've only messed with it a little, but it appears
to be a good program.  I got it through anonymous ftp to 128.214.5.6
(tolsun.oulu.fi) and have asked the author about release to the USENET.
We currently have a small network of 5 machines, 2 at OSU and 3 at DU,
with orion.cair.du.edu as the master server.  If you get this program,
you should try connecting to this network.

Hope this helps.
---------------------------------------------------------------------------
Todd Ferguson
UUCP: {tektronix,hp-pcd}!orstcs!jacobs.cs.orst.edu!melvin
INTERNET:  melvin@jacobs.CS.ORST.EDU

Disclaimer:  Uh??  What???

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 08:13:14 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   Re: FTPable list of *.edu, *.com, *.org, etc.

A list of top and second level domains is available on SRI-NIC.ARPA
as file NETINFO:DOMAIN-INFO.TXT.
-------

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 18:13:08 GMT
From:      keith@SPIDER.CO.UK (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   IP, X.25 and OSI


It appears I may have contributed to the confusion on this topic
myself, for which I can only apologise, and attempt to clarify what
I meant when I mentioned using checking X.25 calling addresses for
security purposes. Following on from Bill Barns <barns@GATEWAY.MITRE.ORG>:

>In general, however, it is not possible to use
>the reverse mapping X.121 -> IP to validate the IP addresses contained
>in datagrams arriving over an X.25 VC whose other end is an X.121
>address in the table.

When I advocated using the calling X.121 address as a validity check,
I had *not* meant that it should be used to check the source IP
addresses in the incoming datagrams, rather merely that the X.121
address belongs to someone with whom you are prepared to exchange IP
datagrams with. The check is not to see that there is a valid
relationship between a caller's X.121 address and a datagram's source
IP address, but simply to see that the X.121 address is itself one of
a known set of possible such addresses.

>Although the entity on the other end of the X.25
>VC has an IP address, it does not necessarily follow that datagrams
>received from the other end will have that particular IP address as the
>IP source address.

I accept that the IP address of the caller need not be the same as a
datagram's IP source address. Nor do I believe that trying to deduce
what the source IP address should be from the X.25 calling address
is worth attempting.  However, I think it *is* worth checking to
determine whether this call is coming from someone who is part of
the Internet. It is not a very rigourous check, but the assumption
is that the Internet is a safer place than the PDN. My software
works on the basis that if they're not in your IP <-> X.121 mapping
table, then you don't know who they are and hence don't want
datagrams from them.

Once you have verified that someone is a legitimate source of
datagrams, you can then perform higher-level scrutiny of these,
filtering on network number as desired, which I agree is a nice
facility.


On to OSI and NSAPs. I must admit I do not have IDEA-0003 and so am
not fully up to date with current thinking on this. Certainly we
want to carry OSI services over both existing IP and X.25(80)
networks, this is a sensible approach for transition to OSI.

The question is, do we regard existing IP as a dead end, or is it
still worth developing subnetwork services for it which can exploit
the extra features being added to existing networks to make them OSI
compatible ?  I guess what I mean is, are the PTTs going to upgrade
their PDNs to the 1984 CONS flavour of X.25 before the Internet
starts using ISO CLNP, or will it be the other way round ?

If it's the former, then we need some new standards. It would be
nice if I could take the (NSAP + X.121) <-> IP address mapping table
out of SpiderX.25 IXE, and just replace it with an algorithmic
mapping. Too bad you can't use ES-IS for this sort of thing.  This
of course is why OSI will be the long-term solution to all this, and
I appreciate that the CLNP over X.25 stuff is being addressed in
GOSIP, even if I'm not terribly familiar with it.

Of course, even in an OSI world, a lot of this stuff would be less
of an issue if PTTs did not insist on providing Connection-Oriented
service only. Roll-on public datagram networks.


Keith Mitchell

Spider Systems Ltd.        Spider Systems Inc.
65 Bonnington Road        12 New England Executive Park
Edinburgh, Scotland        Burlington, MA 01803
+44 31-554 9424            +1 (617) 270-3510

keith@spider.co.uk        keith%spider.co.uk@uunet.uu.net
keith@uk.co.spider        ...!uunet!ukc!spider!keith

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 18:17:35 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   TTL

Why do the "Mail bridges" not decrement the TTL?  Or, do they?

(on 26.0.0.90)

#./traceroute ucbarpa.berkeley.edu
traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets
 1  UCBARPA.Berkeley.EDU (10.0.0.78)  633 ms  769 ms  595 ms
#

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 19:36:17 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

The point of doing a X.121->IP address map is to economize on virtual
circuits.  That is, routes are often symmetric; if a packet from A to B
goes through gateways G1 and G2, replies from B to A will often go through
G2 and G1.  If G1 and G2 communicate via X.25, G1 will call G2 to send
the first packet; if the reply is going to traverse the same path, it
makes sense to reuse the X.25 VC.  If G2 has to open its own circuit back
to G1, it will incur a delay, and -- probably more important -- it will
waste a channel.  Some boards only support a limited number of channels;
requiring two circuits for each call will, more or less, halve the number
of connections a gateway can handle.  (I'm assuming we don't want it
thrashing on connection setup/teardown.)

The flip side is the security issue:  can one trust the calling X.25 address
supplied?  That depends on how much trust one has in the underlying network,
or, more precisely, in the underlying X.25 *internetwork*.  If the network
provider is corrupt, making a new outgoing call won't help, as it will
be diverted as well.  But if the X.25 network relays calls from other
X.25 data networks, and doesn't check the source address properly, it is
possible that some spoofing will occur.

I note that the two X.25 drivers lying around my 4.3bsd system here (for
the ACC 5256/6250 and the 625 board) both behave as I describe:  they
attempt to determine the IP address to associate with incoming calls.


		--Steve Bellovin

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 20:12:10 GMT
From:      emv@a.cc.umich.edu (Ed Vielmetti)
To:        comp.unix.questions,comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Re: uucp via IP ?

In article <522@cvman.UUCP> gdelong@cvman.UUCP (Gary Delong) writes:
>How does one establish a uucp connection via an existing network
>connection such as TCP/IP where rlogin is available.

Two reasonably easy ways.

1.  If your uucp supports 't' protocol (4.3, recent HoneyDanber)
    then you're all set.  L.sys lines look like this for 4.3:

2.  If you have an Annex terminal server it can be configured to
    pass all 8 bits with the magic string 'stty parity none bchar 8'.
    Then run 'g' protocol over the line and use 'rlogin' to sign on.
    Similar magic for ciscos is probably available.

One gotcha is embedding the space character into the expect-send string
for the 'rlogin foo.umich.edu' command, check your documentation on that one.
--
Edward Vielmetti, U of Michigan Computing Center mail group
Support dial-up tcp/ip -- help wipe out uucp.

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 20:35:42 GMT
From:      jburruss@osterville.UUCP (John Burruss)
To:        comp.protocols.tcp-ip
Subject:   SNMP client software


Wellfleet Communications Inc. will be releasing its SNMP
client software in a couple of months.  This package runs
on Sun 3/50s, OS 3.5, X11R2 or 3.  Of course a large component
of the package is command oriented and doesn't require X at all.

John Burruss
Wellfleet Communications Inc.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 21:47:33 GMT
From:      glenn@dlcdev.UUCP (Glenn Meader)
To:        comp.protocols.tcp-ip
Subject:   Mac NCSA Telnet 2.2 on Apple Ethernet card?

I tried to get NCSA Telnet 2.2 running on my MAC II with
Apple ethernet card. I get an error: Network initialization failed!
Couldnt open driver [E]
then it goes back to the finder.
The card and network work fine under AU/X.
I have the hardware=Ether set in the config.tel file.
Any suggestions?

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 89 22:47:40 GMT
From:      karn@jupiter..bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

>The point of doing a X.121->IP address map is to economize on virtual
>circuits.  That is, routes are often symmetric; if a packet from A to B
>goes through gateways G1 and G2, replies from B to A will often go through
>G2 and G1....

On the other hand, CSNET's experience with real commercial X.25 networks
like Telenet has shown that multiple parallel virtual circuits are often
necessary anyway to even approach acceptable performance. The problem is the
small X.25 packet size limit and the tiny packet-layer flow control window.
In the absence of a mechanism for increasing this window you are forced to
open up additional circuits and distribute your traffic among them. Face it,
X.25 was designed for remote slow-speed terminal networking, not serious
computer networking.

I can also say from experience that such a path is an excellent stress test
for your TCP segment reordering code...

Phil

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 03:46:53 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: TENEX mode


        (I'd be more in favor of dropping TENEX mode from FTP.)

    I hope you were just being flippant, but I saw no smiley there...  So,
    lest someone might take that comment seriously, let's make it clear
    that TENEX is just an alias for TYPE L 8 (not TYPE L 32, please!).
    But, if you really are seriously suggesting to drop TYPE L 8, then we
    have a problem.  How else can you send bytes from one machine
    architecture to another?  Certainly TYPE I (image) isn't a universal
    solution, even between machines of the same word size and operating
    system!

There's some confusion here as to what "TENEX mode" in FTP means. Back in the
old days, when the majority of ARPANET (pre-Internet) systems were TENEX's and
TOPS-20's, a means was devised for doing transparent file copying between such
systems. This became known as "TENEX mode", and is a actually a combination of:

    TYPE L 36	(36-bit packing of the bytestream)
    STRU P	("Paged" structure)
    MODE S	("Stream" mode - actually this doesn't really matter)

In more recent times, the UNIX FTP client started calling TYPE L 8 "TENEX
mode", probably because it's the type of transfer used to retrieve a class of
shareware that is kept on a certain, popular TOPS-20 host.

In any case, I believe Barry is proposing the drop the original "TENEX mode"
from the FTP spec, not to drop TYPE L 8. I suppose this would consistant with
the philosophy that FTP should only implement the least-common-denominator of
pushing bits around and is sort of moot anyway, since the only machines that
implement this are not likely to hang around for more than a few more years.

Why not just make all non-interoperable FTP operations subject to the "SITE"
command? That's what it's there for. Why not "SITE VMS MODE RMSFILE", or
something like that? This will make implementation of "intermediary" machines
to store system-specific filetype difficult, but it will solve the immediate
problem of how to get systems running a common OS to transfer files that are
native to that OS.

	--Vince

(P.S. The only reason I know about the two definitions of "TENEX mode" is
 through experiencing similar confusion when someone asked me, onece the
 de facto TOPS-20 FTP maintainer, about "TENEX mode" on UNIX systems -
 "TENEX mode on UNIX systems??" I was a little surprised to hear about such
 a thing until it was explained to me what the speaker meant by "TENEX mode")
-------

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 06:12:36 GMT
From:      sean@ms.uky.edu (Sean Casey)
To:        comp.sources.d,comp.protocols.tcp-ip
Subject:   Re: multiparty, real-time, lightweight sequenced communications

In article <8879@mailgw.cc.umich.edu> emv@mailgw.cc.umich.edu (Ed Vielmetti) writes:
>What's the state of the art in real-time chat programs connected
>across an internet?  The goal is something like 'party' only over
>multiple systems.  I've heard of 'phone' but don't have any more
>pointers than that, & there must be others.
>
>I'm sure it would be a good testbed for multicast protocols or some
>sort of lightweight transaction scheme.

I'm designing one of these. It actually works but it's not in alpha test
yet. State of the art? Hope so...

Can someone point me at what a multicast protocol is? If it's in an RFC,
can you tell me a site where I can grab it with FTP?

Sean
-- 
***  Sean Casey                        sean@ms.uky.edu,  sean@ukma.bitnet
***  Who sometimes never learns.       {backbone site|rutgers|uunet}!ukma!sean
***  U of K, Lexington Kentucky, USA  ..where Christian movies are banned.
***  ``Fate? I thought you said Freight.''

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 06:15:05 GMT
From:      sean@ms.uky.edu (Sean Casey)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

In article <[A.ISI.EDU].9-Feb-89.18:36:57.CERF> CERF@A.ISI.EDU writes:
>Is Langston reachable? The distributed game sounds worth writing
>a paper or at least a column.

Langston is not really reachable, but UCSD empire is only based on
Langston empire. It is growing into another creature altogether. You
can find it on ucbvax.berkeley.edu in /empire.

There are scads of multiplayer games using Berkeley INET sockets, you
just have to look hard.

Sean
-- 
***  Sean Casey                        sean@ms.uky.edu,  sean@ukma.bitnet
***  Who sometimes never learns.       {backbone site|rutgers|uunet}!ukma!sean
***  U of K, Lexington Kentucky, USA  ..where Christian movies are banned.
***  ``Fate? I thought you said Freight.''

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 07:18:02 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

Those who are arguing over the proper predefined standard for VMS
transmission might do well to observe that most of the successful
parts of Unix that are considered `standard' got that way by being
written first instead of defined first.  Moreover, most of those
evolved, so that if they had been standardised without first being
tested, we would have something less useful.

In other words, if you want it done, do it yourself, then hack away
at it until you really like it.  *Then* cry out for standards, if
you still need them---likely most people will have installed your
code already anyway.

(I realise that some of you are doing this already.  Make that,
`I hope that some of you....'  The approach is not perfect, but it
is much more fruitful than sending mail to tcp-ip.)

Chris

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Feb 89 20:26:45 PST
From:      hwchoy%zpovc.DEC@decwrl.dec.com (Heng-Wah Choy DEC Singapore SWS)
To:        TCP-IP%zpovc.DEC@decwrl.dec.com, DECWRL""::"kashtan@iu.ai.sri.com"%zpovc.DEC@decwrl.dec.com, DECWRL""::"adelman@tgv.com"%zpovc.DEC@decwrl.dec.com
Subject:   Flames too strong for me...
Hi,

I got the following flames over the STRU VMS affair. I cc: it to tcp-ip and to
both of you at TGV.

One of you may care to reply?

Rgds,
Heng-Wah

> From:	DECWRL::"unisoft!sparker@uunet.UU.NET" "Steve Parker  8-Feb-89 1202 PST" 11-FEB-1989 07:26
> To:	uunet!zpovc.DEC.COM!hwchoy@uunet.UU.NET
> Subj:	Re: FTP "STRU VMS" extension
> 
> You've successfully argued that pre/post-processing with BACKUP has drawbacks.
> However, you still haven't presented an argument in favor of mucking up FTP's
> protocol specification.
>  
> Operating system dependencies have no business in FTP.  Period.  If one has
> to know about file types on VMS (as one does in order to use VMS), then one
> has to deal with them.  It is clear to me that what you need is a good
> utility for *this* purpose that hangs off the back end like backup.
>  
> Backup wasn't intended for this purpose, and so is wasteful.  So get a better
> utility.  It isn't a valid argument to bitch about VMS lacking a good, media
> independent method for transporting files, and claim FTP should be changed
> because of it!
>  
> And disk quotas on VMS systems have nothing to do with it either.  If you haven't
> got enough space, go buy another disk.  We have quotas on UNIX too you know...
>  
> Steve Parker
> {ucbvax,uunet,sun}!unisoft!sparker
> sparker@unisoft.com
 
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 12:53:48 GMT
From:      meissner@tiktok.dg.com (Michael Meissner)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP implemetation issues (was Re: FTP "STRU VMS" extension)

In article <NELSON.89Feb3233605@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
| Speaking of FTP, has anyone implemented RESTart?  Restart requires MODE C
| (compressed), which is a simple repeated-byte-packing algorithm.  I
| checked radc-tops20's FTP server as well as several flavors of Unix FTP
| servers, and none of them support Compressed mode... :-(

I beleive that Data General's native UNIX (DG/UX) 4.00 FTP does support
RESTart and MODE C operations.  Though of course you probably need
both sides of the connection to support it. :-).
--
Michael Meissner, Data General.
Uucp:	...!mcnc!rti!xyzzy!meissner
Arpa:	meissner@dg-rtp.DG.COM   (or) meissner%dg-rtp.DG.COM@relay.cs.net

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 16:58:48 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   NSFNET Fuzzbone statistics

Folks,

Intrepid archeologist Mike Davis sifted through his many megarocks of data
collected on the old NSFNET Fuzzbone and came up with the enclosed PostScript
graph, which shows the net gazinta and net gazouta traffic by week from the
birth to the death of that network. We are most fascinated by the discontinuity
near October 1987 for which no data seems to exist. In that month I made
many changes designed to improve the congestion management and routing
robustness. At the time some of you and including me wondered whether the
results justified the effort and intrusion on paying customers. From the graph
one might conclude (a) the changes worked and the peak prior to the changes
represented congestive retransmissions, (b) customers got disgusted and simply
walked away or (c) an artifact in the measurement and collection process messed
up the data. One might also conclude there is insufficient data to justify
any conclusion, so you can understand why the missing data are driving us
absolutely nuts. If anybody can come up with the missing data sloshing around
the various archives, we would truly love you a lot.

Dave

----- Forwarded message # 1:

Received: from nemo.udel.edu by Huey.UDEL.EDU id aa04757; 9 Feb 89 15:50 EST
Date:     Thu, 9 Feb 89 15:52:30 EST
From:     davis@UDEL.EDU
To:       mills@UDEL.EDU
Message-ID:  <8902091552.aa28133@Nemo.UDEL.EDU>

0 setgray 1 setlinecap
90 rotate 0 -576 translate .12 .12 scale
4 setlinewidth
/hfnt /Helvetica-Bold findfont 100 scalefont def 
/vfnt hfnt [0 1 -1 0 0 0] makefont def
/setfnt { dup /curfnt exch def setfont } def
hfnt setfnt
/txt {show} def
/ctxt {dup stringwidth 2 div neg exch 2 div neg exch rmoveto show} def
/rtxt {dup stringwidth neg exch neg exch rmoveto show} def
/setlinetype { 
     dup 1 eq { [] 0 setdash } if 
     dup 2 eq { [150] 0 setdash } if 
     dup 3 eq { [75] 0 setdash } if 
     dup 4 eq { [150 75] 0 setdash } if 
     dup 5 eq { [100 75 25 75] 0 setdash } if 
     pop } def 
/stxt {dup 0 get 42 eq {0 -30 rmoveto} if ctxt} def
/txtrotate {
  dup 0 eq
    {pop hfnt}
    {dup 90 eq
      {pop vfnt}
      {matrix identmatrix rotate hfnt exch makefont}
    ifelse}
  ifelse setfnt } def
/txtscale {curfnt exch scalefont setfont} def

688 495 moveto
740 487 lineto
792 580 lineto
844 539 lineto
896 580 lineto
948 471 lineto
1000 469 lineto
stroke 1103 464 moveto
1155 479 lineto
1207 577 lineto
1259 666 lineto
1311 774 lineto
1363 872 lineto
1415 590 lineto
1467 644 lineto
1519 765 lineto
1571 772 lineto
1623 803 lineto
1675 836 lineto
1726 571 lineto
1778 858 lineto
1830 999 lineto
1882 931 lineto
1934 1014 lineto
1986 942 lineto
2038 807 lineto
2090 1092 lineto
2142 1233 lineto
stroke 2246 1396 moveto
2298 1298 lineto
2349 1339 lineto
2401 1327 lineto
2453 1494 lineto
2505 1603 lineto
stroke 2609 1719 moveto
2661 1703 lineto
2713 1921 lineto
2765 2452 lineto
2817 2359 lineto
2869 2036 lineto
2921 2018 lineto
2972 1993 lineto
3024 1946 lineto
3076 2217 lineto
3128 2103 lineto
3180 2538 lineto
3232 2113 lineto
3284 2134 lineto
3336 2490 lineto
3388 2594 lineto
stroke 3543 1923 moveto
3595 1986 lineto
3647 2252 lineto
3699 2377 lineto
3751 2308 lineto
3803 2189 lineto
3855 2098 lineto
3907 1936 lineto
3959 2007 lineto
4011 2271 lineto
4063 2316 lineto
4115 2035 lineto
4166 2078 lineto
4218 2363 lineto
4270 2786 lineto
4322 2549 lineto
4374 2559 lineto
4426 2624 lineto
4478 2917 lineto
4530 3064 lineto
4582 3091 lineto
4634 3137 lineto
4686 3242 lineto
4738 3235 lineto
4789 3288 lineto
4841 3380 lineto
4893 3462 lineto
4945 3807 lineto
4997 3661 lineto
5049 3612 lineto
5101 3614 lineto
5153 3751 lineto
5205 3261 lineto
5257 3534 lineto
5309 3203 lineto
5361 3135 lineto
5412 2941 lineto
5464 2863 lineto
5516 2642 lineto
5568 1459 lineto
5620 907 lineto
currentpoint stroke moveto
1.5 txtscale 3232 4389 moveto (Ethernet In/Out) ctxt
1 txtscale 3232 49 moveto (Comparison of Input/Ouput packets summed over all nodes) ctxt
3232 131 moveto (Julian Weeks \(2447420 -> 2448085\)) ctxt
90 txtrotate 349 2291 moveto (# Packets) ctxt
636 418 moveto
636 493 lineto
stroke 1155 418 moveto
1155 493 lineto
stroke 1675 418 moveto
1675 493 lineto
stroke 2194 418 moveto
2194 493 lineto
stroke 2713 418 moveto
2713 493 lineto
stroke 3232 418 moveto
3232 493 lineto
stroke 3751 418 moveto
3751 493 lineto
stroke 4270 418 moveto
4270 493 lineto
stroke 4789 418 moveto
4789 493 lineto
stroke 5309 418 moveto
5309 493 lineto
stroke 5828 418 moveto
5828 493 lineto
stroke 636 418 moveto
5828 418 lineto
currentpoint stroke moveto
0 txtrotate 636 295 moveto (0) ctxt
1155 295 moveto (10) ctxt
1675 295 moveto (20) ctxt
2194 295 moveto (30) ctxt
2713 295 moveto (40) ctxt
3232 295 moveto (50) ctxt
3751 295 moveto (60) ctxt
4270 295 moveto (70) ctxt
4789 295 moveto (80) ctxt
5309 295 moveto (90) ctxt
5828 295 moveto (100) ctxt
636 418 moveto
711 418 lineto
stroke 636 1042 moveto
711 1042 lineto
stroke 636 1667 moveto
711 1667 lineto
stroke 636 2291 moveto
711 2291 lineto
stroke 636 2915 moveto
711 2915 lineto
stroke 636 3540 moveto
711 3540 lineto
stroke 636 4164 moveto
711 4164 lineto
stroke 636 418 moveto
636 4164 lineto
currentpoint stroke moveto
90 txtrotate 513 418 moveto (0) ctxt
595 418 moveto (e0) ctxt
513 1042 moveto (5.0) ctxt
595 1042 moveto (e6) ctxt
513 1667 moveto (1.0) ctxt
595 1667 moveto (e7) ctxt
513 2291 moveto (1.5) ctxt
595 2291 moveto (e7) ctxt
513 2915 moveto (2.0) ctxt
595 2915 moveto (e7) ctxt
513 3540 moveto (2.5) ctxt
595 3540 moveto (e7) ctxt
513 4164 moveto (3.0) ctxt
595 4164 moveto (e7) ctxt
636 4164 moveto
636 418 lineto
5828 418 lineto
5828 4164 lineto
636 4164 lineto
stroke 688 487 moveto
740 465 lineto
792 509 lineto
844 494 lineto
896 531 lineto
948 451 lineto
1000 464 lineto
stroke 1103 475 moveto
1155 459 lineto
1207 533 lineto
1259 600 lineto
1311 683 lineto
1363 687 lineto
1415 610 lineto
1467 587 lineto
1519 683 lineto
1571 685 lineto
1623 729 lineto
1675 803 lineto
1726 548 lineto
1778 815 lineto
1830 882 lineto
1882 818 lineto
1934 1014 lineto
1986 942 lineto
2038 807 lineto
2090 1092 lineto
2142 1233 lineto
stroke 2246 1396 moveto
2298 1298 lineto
2349 1339 lineto
2401 1327 lineto
2453 1494 lineto
2505 1603 lineto
stroke 2609 1719 moveto
2661 1762 lineto
2713 1936 lineto
2765 2676 lineto
2817 2443 lineto
2869 2122 lineto
2921 2111 lineto
2972 2014 lineto
3024 1942 lineto
3076 2233 lineto
3128 2170 lineto
3180 2498 lineto
3232 2371 lineto
3284 2304 lineto
3336 2505 lineto
3388 2583 lineto
stroke 3543 1808 moveto
3595 1926 lineto
3647 2144 lineto
3699 2133 lineto
3751 2157 lineto
3803 2057 lineto
3855 1927 lineto
3907 1747 lineto
3959 1903 lineto
4011 2245 lineto
4063 2054 lineto
4115 1888 lineto
4166 1994 lineto
4218 2111 lineto
4270 2525 lineto
4322 2367 lineto
4374 2352 lineto
4426 2600 lineto
4478 2859 lineto
4530 2924 lineto
4582 2998 lineto
4634 3052 lineto
4686 3185 lineto
4738 3227 lineto
4789 3425 lineto
4841 3361 lineto
4893 3475 lineto
4945 3560 lineto
4997 3620 lineto
5049 3530 lineto
5101 3500 lineto
5153 3773 lineto
5205 3326 lineto
5257 3477 lineto
5309 3506 lineto
5361 3343 lineto
5412 3099 lineto
5464 2731 lineto
5516 2652 lineto
5568 1484 lineto
5620 751 lineto
currentpoint stroke moveto
gsave showpage grestore newpath 0 0 moveto

----- End of forwarded messages

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 17:43:09 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: TENEX mode

In article <WANCHO.12469460754.BABYL@WSMR-SIMTEL20.ARMY.MIL> WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") writes:
>
>    (I'd be more in favor of dropping TENEX mode from FTP.)
>
       We used to call this ("TYPE L 8") "byte" mode in an implementation of
FTP that I controlled.  Unfortunately, "Tenex" has been enshrined in too
much software.  But I would suggest that "byte" be implemented as an alternate
name for the mode.

       Incidentally, remember, FTP client implementors, when doing directory 
operations, always switch back to ASCII mode for the directory transfer if 
you're in some other mode.

					John Nagle

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 17:48:23 GMT
From:      SOL@SRI-NIC.ARPA (Sol Lederman)
To:        comp.protocols.tcp-ip
Subject:   Re: multiparty, real-time, lightweight sequenced communications

Sean,

I belive RFC 1054 is the document you want. You can ftp it from SRI-NIC.ARPA
(login: anonymous, password: guest, filename: RFC:RFC1054.TXT). If it's
more convenient you can get the RFC via electronic mail by sending a message
to SERVICE@SRI-NIC.ARPA with the words   RFC 1054   in the subject line.

-Sol
                              ----------
1054  Deering, S.E.  Host extensions for IP multicasting.  1988 May; 19 p. 
      (45465 bytes)  (Obsoletes RFC 988)
-------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 20:36:15 GMT
From:      abstine@sun.soe.clarkson.edu (Arthur Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

How about if we take a quick vote on the various solutions to this
problem and then someone can author an RFC describing how it would be
done. I think the Un*x types are being somewhat prejudiced in this case
by refusing to recognize that there is a need for this type of facility.
Just because it doesn't apply to them in this case, they con't want to see
it added to the overall FTP protocol. The whole point of this is
interoperability. I don't see what is so wrong in adding something like
this to the protocol to further that end. Lets face it: Unix is NOT the
only OS in the world, nor will it probably ever be. Lets stop quibbling about
this and get something moving here. Otherwise, the various vendors are
going to just going to have to make something non-standard in their particular
implementations to provide this very necessary service and we would not
benefit from that.

Art Stine
Sr Network Engineer
Clarkson U

ABStine@CLVMS.Clarkson.Edu

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 22:38:25 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   TENEX mode


Vince is correct, I was referring to the 36-bit mode used between two
PDP10 systems when I made the comment about TENEX mode. And no, I
don't honestly think anyone should bother to drop it, what I meant was
that it shouldn't be used as a precedent.

	-Barry Shein, ||Encore||

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 23:24:11 GMT
From:      werme@Alliant.COM (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Re: Interactive game playing over an internet network

With the proliferation of X, I imagine a feature of interactive games would
be a common user interface throughout the net.  Keep in mind the possibilities
of allowing individual sites or users to develop their own interface.

Once upon a time, on an ARPAnet long, long ago (1973?) the Friday hackers
forum at MIT start a discussion on a network-wide Star Trek game.  I was
C-MU, I think we had input from Perdue and Stanford.  The idea was to inspire
work on network graphics, a task that was languishing because everyone's
system was different.  We toyed around with the idea of developing Star Trek
Protocol (STP) and servers on each machine that were identical.  Each server
would be responsible for some of the postional calculations, communicating
with the other servers, and with local game clients.

This would allow each site to write custom clients and encourage people
to come up with really good, efficient, and informative interfaces for the
game players.  (And to develop automated players if there weren't enough
real people around or if you wanted some extra help.)

It had a lot of possibilities, but none of us had the time to devote to it
and nothing came of it, as far as I know.  Someone at PARC in a more
authoritative position put forth a very similar proposal, but one aimed more
at network graphic protocols than my interest in specialized clients.

In 1974 I started fading from the ARPAnet.  First to DEC, then to a dot
matrix printer companies, then to starting a company to write a music teaching
program for Apples.  Now to Alliant and the Usenet.  Maybe I'll make it back
to the Internet someday.

But I still won't have any time for STP!
-- 

| A pride of lions              | Eric J Werme                |
| A gaggle of geese             | uucp: decvax!linus!alliant  |
| An odd lot of programmers     | Phone: 603-673-3993         |

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 89 23:35:39 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Whereabouts of NCD

Network Computing Devices, Inc.
350 N. Bernardo Ave.
Mountain View, CA. 94043
415-694-0650

Model NCD16 16" dialgonal X-windows terminal. Ethernet and RS-232.
1024x1024 pixel MC68000 based. Starts at US$2550. All from trade rag
announcement.

For tomorrow's trivia question: Competitors are given as Visual Technology,
Inc. of Lowell, Mass., and Acer Counterpoint of San Jose, CA. Does anyone
have THEIR addresses?

Has anyone seen any of these beasties to comment on their suitability as
multiwindow terminals?

Gene

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 89 04:04:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   TENEX mode

Vince,

At the risk of belaboring the point, but only to avoid rewriting
history, I must defer to you as the former maintainer of the FTP
server we use here as the more knowledgeable on FTP matters (I'm just
a late comer).  However, I don't ever recall seeing the "tenex"
command (not mode) (on Unix and bsd-derived systems only) as an alias
for PAGED mode file transfers.  It has always sent TYPE L 8 to the
remote host and conditioned the local host to receive a binary file.

PAGED mode was originally called XTP (eXperimental TENEX PAGED) mode
by Bob Clements in RFC 683.  The tenex command first appeared in some
early version of user ftp in bsd4.1 or so.  As far as I can tell, the
tenex command was never documented in any RFC related to FTP, although
it should have been because of a certain broken implementation which
sent TYPE L 32 and still causes us no end of complaints and
misunderstandings.

On the other hand, let's not confuse TENEX with PAGED mode either.
PAGED mode was originally devised for possibly holey TENEX/TOPS20 file
transfers, and as long as we have another TENEX/TOPS20 machine to talk
to, let's keep PAGED mode around.

In spite of the fact that Barry says we shouldn't use it as a
precedent, I propose that PAGED mode be considered a generic mode to
transfer an exact copy of a file, including FDB and other information
between two machines with the same operating system.  Note that in the
specification for PAGED mode, the exact format of the attribute and
descriptor blocks is not given.  It could easily be adapted by mutual
agreement between user and server ftp implementors to the VMS problem
currently under discussion.  When it is used between VMS systems, it
is understood to mean TYPE L wordsize instead of TYPE L 36 (all else
being left the same).

--Frank

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 89 14:05:06 GMT
From:      mcvax!unido!fauern!faui44!eckert@uunet.uu.net  (Toerless Eckert)
To:        tcp-ip@sri-nic.arpa
Subject:   Utilities for nameserver wanted
I am looking for utilities that can help me with the internet nameserver.
I would like to have a program that queries the nameserver of different
zones and generates a /etc/hosts compatible file from the resource
records, for those hosts in our LAN that can not use the nameserver.
I am also interested in programs that help creating nameserver
database files, especially for the PTR records.

-- 
				Toerless Eckert
				(eckert@immd4.informatik.uni-erlangen.de)
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 89 17:33:35 GMT
From:      trn@warper.jhuapl.edu (Tony Nardo)
To:        comp.protocols.tcp-ip
Subject:   MILNET<->ARPANET woes (again)

Does anyone know if the latest DDN essage (regarding conversion to standard
packet formats) is a roundabout explaination for why MILNET<->ARPANET
connectivity has been rather erratic over the past two weeks?

For that matter, has anyone else noticed any connectivity problems?  I seem
to be able to reach *West Coast* sites fairly reliably.  Sites closer to
home, however, have been another matter entirely.

								Tony

P.S.	To whom it concerns: warper routes thru 26.1.0.102 (aplvax.jhuapl.edu).
-------				----------------			-------
ARPA,	trn@aplcomm.jhuapl.edu,		UUCP:	{backbone!}mimsy!aplcomm!trn
BITNET:	trn@warper.jhuapl.edu

leading edge (adj.): used to describe technology that is five years out of date
and therefore mature enough to be used in a product.

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 89 23:30:57 GMT
From:      arul@sdsu.UUCP (Arul Ananthanarayanan)
To:        comp.protocols.tcp-ip
Subject:   Need phone number for Cisco


Hello,
	Could someone please mail me the address and phone number for
Cisco?

Thanks,

Arul
-- 
   San Diego State University Math Sciences Dept. Celerity 1230 BSD 4.3

   UUCP:    ....!ucsd!sdsu!arul              work:(619) 594-7208
   ARPA:    arul%sdsu.uucp@ucsd.edu          home:(619) 583-0439

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 89 23:44:32 GMT
From:      arul@sdsu.UUCP (Arul Ananthanarayanan)
To:        comp.protocols.tcp-ip
Subject:   interested in dialin SLIP


I am interested in any work that has been done or is in progress with
regard to dialin slip.  We have the SLIP code builtin to our 4.3 machine
so I would be interested if anyone has done anywork along the lines of
having personal computers dial up and request an address dynamically on
connection.

Could anyone point me in the proper direction?

Thanks,

Arul
-- 
   San Diego State University Math Sciences Dept. Celerity 1230 BSD 4.3

   UUCP:    ....!ucsd!sdsu!arul              work:(619) 594-7208
   ARPA:    arul%sdsu.uucp@ucsd.edu          home:(619) 583-0439

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Feb 89 08:24:19 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        ucsdhub!sdsu!arul@ucsd.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: interested in dialin SLIP

Arul:

This seems to be the hot topic of the moment.

For a reference, see 

    L. Lanzillo, C. Partridge, "Implementation of Dial-up IP for UNIX Systems,"
    Proc. 1989 Winter USENIX Technical Conf., San Diego, California,
    January 30 - February 3, 1989.

    ABSTRACT: CSNET has developed a software package to support the sending
    of Internet Protocol (IP) datagrams over dial-up phone lines. This driver
    can automatically establish and disconnect phone calls as IP traffic
    dictates. This code works in binary-only BSD systems.

People who don't have easy access to a USENIX proceedings can drop me a
note and I'll e-mail you a postscript copy. (By the way, this conference was
a good one -- see, for example, Tom Duff's paper on the virus he let loose
at AT&T).

The software described in this paper is available only to CSNET members.
Conversations I had with folks in the hall led me to believe that several
prominent people were also working on dial-up packages and we might see
more offerings in the near future.

By the way, there's apparent concensus among all involved that we'd like
our dial-up systems to interoperate. The key problem may be using
a standard serial line protocol.  Implementors are getting ahead of
the Point-To-Point Working Group (not what was intended when the P2P
group was established) and once software is distributed it is hard to
upgrade.

Craig
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Feb 89 09:44:11 PST
From:      braden@venera.isi.edu
To:        sean@g.ms.uky.edu, tcp-ip@sri-nic.arpa
Subject:   Re: multiparty, real-time, lightweight sequenced communications
	
	I'm designing one of these. It actually works but it's not in alpha test
	yet. State of the art? Hope so...
	
	Can someone point me at what a multicast protocol is? If it's in an RFC,
	can you tell me a site where I can grab it with FTP?
	
	Sean

Contact Steve Deering, deering@pescadero.stanford.edu, and read 
RFC-1054.

Bob Braden
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Feb 89 12:24:41 -0500
From:      Andy Malis <malis@BBN.COM>
To:        "Tony\, Nardo" <haven!aplcen!aplcomm!trn%warper.jhuapl.edu@ames.arc.nasa.gov>
Cc:        tcp-ip@sri-nic.arpa, malis@BBN.COM
Subject:   Re: MILNET<->ARPANET woes (again)
Tony,

The DDN bulletin has nothing to do with Arpanet-MILNET
connectivity, but rather with X.25 hosts requiring non-standard
default flow control parameters and the intra-MILNET
interroperability (and MILNET management) problems that result.

The connectivity problems are the result of a problem in the
Butterfly mailbridge software that was fixed late last week.  New
disks were being sent out on Friday.

Regards,
Andy Malis <malis@bbn.com>    UUCP: {harvard,rutgers,uunet}!bbn!malis
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Feb 89 12:38:58 -0500
From:      Mike Brescia <brescia@BBN.COM>
To:        "C. Philip Wood" <cpw%sneezy@lanl.gov>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: QUERY: TTL field in IP header
     Why do the "Mail bridges" not decrement the TTL?  Or, do they?

     (on 26.0.0.90)
     #./traceroute ucbarpa.berkeley.edu
     traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets
      1  UCBARPA.Berkeley.EDU (10.0.0.78)  633 ms  769 ms  595 ms
     #

Phil,

I am not sure whether you are claiming to find the "failure to decrement" bug
or the "failure to discard when TTL is 1" bug.  We see the gateways
decrementing the TTL field in packets which they pass.  They should also be
careful to pass a packet only if the TTL is still non-zero when they send it
on, but this may not have been rigorously tested.  Think of it as a fencepost
problem.

Mike
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 08:11:24 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: While we are debating extensions to the FTP spec...

| I would like to propose a ``MODE LZ'' extension to FTP.

  Don't forget that some hosts can't decode 16 bit LZ compressed
streams.  Maybe your mode had better be ``MODE LZ [BITS]'' with the
default BITS = 16.

Casey

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 08:24:59 GMT
From:      JOHN@MATHOM.CISCO.COM (John Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: Need phone number for Cisco

cisco's address is:

1350 Willow Rd.
Menlo Park, CA 94025
(415) 326-1941
-------

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 13:24:19 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: interested in dialin SLIP


Arul:

This seems to be the hot topic of the moment.

For a reference, see 

    L. Lanzillo, C. Partridge, "Implementation of Dial-up IP for UNIX Systems,"
    Proc. 1989 Winter USENIX Technical Conf., San Diego, California,
    January 30 - February 3, 1989.

    ABSTRACT: CSNET has developed a software package to support the sending
    of Internet Protocol (IP) datagrams over dial-up phone lines. This driver
    can automatically establish and disconnect phone calls as IP traffic
    dictates. This code works in binary-only BSD systems.

People who don't have easy access to a USENIX proceedings can drop me a
note and I'll e-mail you a postscript copy. (By the way, this conference was
a good one -- see, for example, Tom Duff's paper on the virus he let loose
at AT&T).

The software described in this paper is available only to CSNET members.
Conversations I had with folks in the hall led me to believe that several
prominent people were also working on dial-up packages and we might see
more offerings in the near future.

By the way, there's apparent concensus among all involved that we'd like
our dial-up systems to interoperate. The key problem may be using
a standard serial line protocol.  Implementors are getting ahead of
the Point-To-Point Working Group (not what was intended when the P2P
group was established) and once software is distributed it is hard to
upgrade.

Craig

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 14:53:41 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

I vote for something that provides "interoperability".  But,
interoperability is not the ability of one VMS system to talk to
another.  The mechanism I would vote for would create an eXternal File
Representation (XFR), which would allow for REAL "interoperability"
between HETEROGENEOUS hosts.  It would take care of mapping file
attributes to and from the file attribute scheme of all time.  And, if
a mapping was impossible, it would give the phone number of the nearest
XYZ vendor sales office, so the user could switch to an OS that was
flexible enough to handle the problem.

Phil Wood,  cpw@lanl.gov

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 16:48:21 GMT
From:      sdo@PHOEBE.LARC.NASA.GOV (Sharon O. Beskenis)
To:        comp.protocols.tcp-ip
Subject:   Re:  Whereabouts of NCD

The following address was listed on their brochure handed out at the Usenix
conference in San Diego, CA.

	Network Computing Devices, Inc.
	350 North Bernardo Ave.
	Mountain View, CA 94043
	Tel. (415)694-0650
	FAX  (415)961-7711

Sharon Beskenis
Emhart/PRC
NASA Langley Research Center
MS 478
Hampton, VA 23665
(804)864-1703

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 17:24:41 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: MILNET<->ARPANET woes (again)

Tony,

The DDN bulletin has nothing to do with Arpanet-MILNET
connectivity, but rather with X.25 hosts requiring non-standard
default flow control parameters and the intra-MILNET
interroperability (and MILNET management) problems that result.

The connectivity problems are the result of a problem in the
Butterfly mailbridge software that was fixed late last week.  New
disks were being sent out on Friday.

Regards,
Andy Malis <malis@bbn.com>    UUCP: {harvard,rutgers,uunet}!bbn!malis

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 17:38:58 GMT
From:      brescia@BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: QUERY: TTL field in IP header


     Why do the "Mail bridges" not decrement the TTL?  Or, do they?

     (on 26.0.0.90)
     #./traceroute ucbarpa.berkeley.edu
     traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets
      1  UCBARPA.Berkeley.EDU (10.0.0.78)  633 ms  769 ms  595 ms
     #

Phil,

I am not sure whether you are claiming to find the "failure to decrement" bug
or the "failure to discard when TTL is 1" bug.  We see the gateways
decrementing the TTL field in packets which they pass.  They should also be
careful to pass a packet only if the TTL is still non-zero when they send it
on, but this may not have been rigorously tested.  Think of it as a fencepost
problem.

Mike

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 17:40:29 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TENEX mode


Why are people talking about "Tenex mode in FTP", when that is just a
user command in one particular implementation of a User FTP?  There
is no "Tenex mode" in the FTP protocol, RFC-959.  If you don't like the
command, complain to the people who wrote and maintain the
operating system in which is appears.  I'm sure you know the address.

Bob Braden

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 18:48:33 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   SLIP for SUN-3/SUN-2

Can anyone tell me where I can get SLIP for the SUN-3 running SUN OS 3.5,
and for a SUN-2 running SUN OS 3.2.

I need a source for the binaries/sources and installation instructions.

Also, does anyone know if SLIP under Ultrix 3.0 in compatible with
SUN OS 3.5 SLIP.
------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
Disclaimer:		Standard disclaimers apply!
------------------------------------------------------------------------

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 19:08:44 GMT
From:      quentin@umb.umb.edu (Quentin Fennessy)
To:        comp.protocols.tcp-ip
Subject:   Unhelpful error message

I have two machines on an Ethernet. I got NFS up and running between them,
but a few days later it stopped for no apparent reason. The two machines
are a uVAX 3500 and an Olivetti 3020. When I try to ping from the oliv to
the VAX it is successful. When I try to ping the OLIV from the VAX I am 
successful. However I can not ping the VAX from the VAX. I get the 
following message:

VAX : ping olivetti
olivetti is alive
VAX : ping VAX
sendto: Can't assign requested address
ping: wrote localhost 64 chars, ret=-1
ping: sendto: Can't assign requested address
VAX :

I will appreciate any hints at all.

Quentin Fennessy
617-499-4291

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 19:43:17 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   DDN MGT Bulletin 54

So, not only are we the World's number one debtor nation, with other countries
setting our interest rates, now, we are under the thumb of the CCITT.

I guess it's back to two cans and a string.

Phil Wood, cpw@lanl.gov

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 20:12:24 GMT
From:      mac@proteon.com (Michael A. Curtis)
To:        comp.protocols.tcp-ip
Subject:   Availability of Cataia software ported to Unix Workstation


Gentlemen,

     Has anyone had any luck porting or obtaining a port of the Cataia
software??  I'm interested in any type of workstation anyone may have
this running on.  Many thanks in advance.


Mike Curtis

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 20:29:27 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: email/PROFS

Call IBM, the product is called PROFS Extended Mail and the Magic
number is 5798-FBJ.

-Ron

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 21:00:42 GMT
From:      ssb@picuxa.UUCP (Scott Strool 3D2 X1069)
To:        comp.protocols.tcp-ip
Subject:   libsocket.a

I have just installed Micom Interlan TCP/IP on a AT&T 6386. I am using the
Interlan 6200 Ethernet board. In an appllication that uses the tcp driver, it
is looking for a file called libsocket.a. I can't find this file anywhere.
Does anybody know where this file gets put and how does it get there.
I am using AT&T UNIX System V release 3.2


Scott Strool
AT&T att!picuxa!Tinman!ss

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 21:27:00 GMT
From:      VANCE@JVNCC.CSC.ORG
To:        comp.protocols.tcp-ip
Subject:   Commercial use of the Internet

Hello,

Could someone please send me any information that claifies what the
policy is on commercial use of the internet? I have asked and have 
not received any info on this.

Thanks in advance,

Vercell Vance
Manager of User Services
John von Neumann National Supercomputer Center
POB 3717
Princeton, NJ 98543

	or

Vance@jvnca.csc.org

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 21:34:13 GMT
From:      kzm@TWG.COM (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Management

Mike & Dave,

You both asked about the availability of a Network Management station
supporting SNMP on a Sun workstation.  We have such a product.  We also
have SNMP agent software to go with our TCP/IP products for VMS and 
386/Streams.  If you would like more information, let me know.

Keith McCloghrie
The Wollongong Group.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 89 22:15:03 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

| From: cpw%sneezy@LANL.GOV (C. Philip Wood)
| 
| I vote for something that provides "interoperability".  But,
| interoperability is not the ability of one VMS system to talk to
| another.  The mechanism I would vote for would create an eXternal File
| Representation (XFR), which would allow for REAL "interoperability"
| between HETEROGENEOUS hosts.  It would take care of mapping file
| attributes to and from the file attribute scheme of all time.  And, if a
| mapping was impossible, it would give the phone number of the nearest XYZ
| vendor sales office, so the user could switch to an OS that was flexible
| enough to handle the problem.

  Yech.  Just what we need.  Ftp written by AI people ... :-) Will I have
to have 32Mb of swap space to run ftp now?  Not flaming; just asking that
we don't go over board on this one.

Casey

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 02:25:44 GMT
From:      pha@cs.rit.edu (Paul H. Allen)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Users of Wollongong's WIN/3B Release 2.1

Last summer, I upgraded four 3B2/400s and one 3B2/600 to Wollongong's
"Enhanced" TCP/IP WIN/3B, Release 2.1 (WIN is a Trademark of The Wollongong
Group, Inc).  These computers belong to the graduate computer science
department which is highly dependent on their network.  The faculty and
students soon found out that the software had some serious problems and
looked to me for some answers.  I couldn't believe how much functionality
we lost.

Specific problems that we experienced:

1. The remote rn, "rrn", failed due to the system functions, "read" and "write"
not working properly.  I finally gave up and rewrote the networking code
using the TLI library.

2. All printing is done on a Citoh and Epson printer via remote shell to
the 3B2/600 from 3b1s.  Unfortunately, large files failed to print completely
due to truncation by the remote shell.  One grad. student told me he considered
a large file to be at least 5 pages. :-<

3. Screendumps from the 3b1 to the laser printer via remote shell to one
of the 3B2/400s completely failed.  Well, sometimes you would get a
partial printing.

4. I use to backup my 40 meg. hard disk to the 3B2/600's 60 meg SCSI tape
drive by executing,

 find pha -depth -print | cpio -oBc | remsh ma "dd of=/dev/rSA/qtape1 bs=10b"

But for some reason or other, the command failed complaining about
"too many processes".  Huh? it use to work before the upgrade!

5. Now the undergrads fill their labs with suns that currently operate
SunOS4.0 (SunOS is a trademark of Sun Microsystems, Incorporated).  Since
I am one of the maintainers of the CS Departments equipment, I occasionally
have a need to transfer files between the Suns and 3B2s.  I could transfer
a file by ftp if the sun was doing the "getting" and "putting" but the 3B2
failed, usually producing a zero byte file.

We made all types of noise and finally got the attention of the right people in
that massive AT&T bureaucracy.  Most of our problems have been solved by the
efforts of an individual belonging to the AT&T's Tier 4 support group in
Illinois.

What is this article about?  You won't believe this, BUT, that same AT&T
bureaucracy claims WE are the only ones that have these problems with this
sofeware, at least that is what they tell our salesman.  So, our salesman
asked me to query the readers of this net regarding their experience with
Wollongong's TCP/IP.  At least I know better, I've been reading this group
for quite a while now.  AND, if you are still having problems, I've been
told, that if you respond, someone from AT&T will contact you.  No kidding!

Paul Allen
...!rutgers!rochester!rit!pha               Rochester Institute of Technology
pha@cs.rit.edu                              Computer Science Dept.
pha1775@ritvax                              One Lomb Memorial Drive
                                            Post Office Box 9887
                                            Rochester, New York 14623-0877

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1989 0909-EST
From:      deseafo@TYCHO.ARPA  (David E. Seafolk)
To:        tcp-ip at sri-nic.arpa
Subject:   CMIP/CMIS info
	Can someone tell me where to get information about the CMIP/CMIS?
I understand that they are available as draft standards now, and we are
interested in seeing what is being proposed for network management standards?

Thanks
deseafo@tycho.arpa
-------

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 1989 11:27-EST
From:      CERF@A.ISI.EDU
To:        bcsaic!wsc-sun!gfb@JUNE.CS.WASHINGTON.EDU
Cc:        uw-june!sri-nic.arpa!tcp-ip@JUNE.CS.WASHINGTON.EDU
Subject:   Re: email/PROFS
Gareth,

MCI Mail has a link to PROFS via SOFTSWITCH Corp. software.

SOFTSWITCH is in or near King of Prussia, PA.

Vint Cerf
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 08:24:17 GMT
From:      fbraab@leuze.UUCP (Fritz B. Raab)
To:        comp.sources.wanted,comp.protocols.tcp-ip,eunet.sources
Subject:   Does anyone have a rdate for PC-NFS ?

Does anyone have a rdate (setclock) program, written for PC-NFS, which
remotely reads the date of a time server and sets the clock of the PC ?

Please mail to:


==============================================================================
Fritz B. Raab                     email: fbraab@leuze.UUCP
Leuze electronic, Abt. TDV               ..uunet!unido!leuze!fbraab
In der Braike 1
D7311 Owen / Teck                 voice: +49 7021 573185
West - Germany
==============================================================================
Thanks, Fritz

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 11:55:35 GMT
From:      rajaei@ttds.UUCP (Hassan Rajaei)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

In article <13962@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:

>On the other hand, CSNET's experience with real commercial X.25 networks
>like Telenet has shown that multiple parallel virtual circuits are often
>necessary anyway to even approach acceptable performance. The problem is the
>small X.25 packet size limit and the tiny packet-layer flow control window.
>In the absence of a mechanism for increasing this window you are forced to
>open up additional circuits and distribute your traffic among them. Face it,
>X.25 was designed for remote slow-speed terminal networking, not serious
>computer networking.

I quite agree with Phil. X.25 can not satisfy the high performance needed
for high-speed communication and certainly not for internetworking. Isn't
it really funny to have VC over a large network while it is not necessary?
I believe the PTTs have done some mistake and now it is hard for them to 
admit and backup. The investment is so enormous that nobody dare to backup
just like FORTRAN. I don't care which protocol the commercial world want to
use, but I do care what scientists and researchers use or will use. These
people have already started the alternative solutions. If other people listen
enough we can hope for a newer and better standard than X.25.

Hassan Rajaei

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 14:09:00 GMT
From:      deseafo@TYCHO.ARPA (David E. Seafolk)
To:        comp.protocols.tcp-ip
Subject:   CMIP/CMIS info


	Can someone tell me where to get information about the CMIP/CMIS?
I understand that they are available as draft standards now, and we are
interested in seeing what is being proposed for network management standards?

Thanks
deseafo@tycho.arpa
-------

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 14:13:07 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial use of the Internet


>  Could someone please send me any information that claifies what the
>  policy is on commercial use of the internet?

Unhappily, there is as yet no SINGLE policy, because the Internet is
administered by a number of different Federal agencies whose usage policies
differ.  The situation is complicated in the NSFNET case because the
mid-level networks (e.g., JVNCNET) are autonomous business entities with
their own policies.

Until a formal policy is issued by NSF (we ARE working on it!), you should
assume that traffic passed over the NSFNET Backbone must be "in support of
scientific research and other scholarly activities."

That does not rule out commercial use, obviously.

If your traffic is going to remain on JVNCNET, ask the von Neumann Center
folks for their policy.

The Federal Research Internet Coordinating Committee (FRICC), comprised of
folks who own bits of the Internet, has a draft joint usage policy under
discussion.

-s

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 16:27:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: email/PROFS

Gareth,

MCI Mail has a link to PROFS via SOFTSWITCH Corp. software.

SOFTSWITCH is in or near King of Prussia, PA.

Vint Cerf

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 18:28:00 GMT
From:      aprm@HAWAII-EMH.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: terminating connections

In this discussion TCP is being compared to ISO TP.  The
network we run at Ft. Shafter, OpenNET by Intel, uses TP4 in the
transport layer.  Is TP the same as TP4?

Gary Dunn
WESTCOM DCSRM IMO
Ft. Shafter, HI

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 18:28 GMT
From:      aprm @ Hawaii-EMH.arpa
To:        tcp-ip @ sri-nic.arpa
Subject:   Re: terminating connections
In this discussion TCP is being compared to ISO TP.  The
network we run at Ft. Shafter, OpenNET by Intel, uses TP4 in the
transport layer.  Is TP the same as TP4?

Gary Dunn
WESTCOM DCSRM IMO
Ft. Shafter, HI

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 19:39:54 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension


  I don't mind the idea of per vendor extensions to ftp just as long as
they're not part of the official FTP RFC standard.  And I don't mind the
idea of the InterNet community serving as a host for vendor
standardization efforts.  I think that a separate RFC for each separate
vendor extension (using a standard FTP escape mechanism) is the way to go.

  I think that more than enough evidence has been presented to justify
such extensions and their standardization.  But, that evidence also
suggests that, barring AI extensions to FTP, these facilities are totally
vendor specific with no known bound on the number of such.  Therefore in
order to promote standardization within vendor communities but also avoid
rewriting the FTP RFC every time a vendor extension is thought up, it's
fairly clear that each such extension should be described in a separate
RFC.

  Given the InterNet's traditional desire to achieve and enhance
interoperability, I think we should be receptive to hosting vendor
standardization efforts in this manner.  Part of the InterNet's role is
as a standards body after all.

  But, aside from these thoughts, I think Chris is right: you VMS TCP/IP
suppliers ought to get together on your own in a private meeting and
agree on a standard between yourselves.  I think you've received more
than enough commentary about usage of both "SITE" and "STRU".  My
personal choice is "SITE" because it was explicitly put in for such
non-standard extensions, but that's just me.

Casey

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 21:59:23 GMT
From:      lance@hermix.UUCP (Sir Ellinghouse)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP and printer daemons

I have a TCP/IP network running over ~ 14 PC's and one 386. We have two
printers hooked up to the 386 and would like to use them over the net.
I noticed that there was a socket address for printerd already. 
Does anyone have SCO Xenix 386 source and PC-DOS source for a host-server
print program? Anyone have any ideas on where to get a program like that?
PD not really necessary, but Nice.

Thanks,
Lance Ellinghouse

-- 
Lance Ellinghouse
Mark V Systems, Ltd.
UUCP: ...!hermix!lance
ARPA: ucla-an!hermix!lance@ee.UCLA.EDU

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 22:16:21 GMT
From:      eberard@ajpo.sei.cmu.edu (Edward Berard)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   The Relationship Between TCP/IP and B-Net?

I am looking for information regarding TCP/IP and B-Net. Specifically,
I would like either an explanation of their relationship, or a pointer
to where such an explanation could be found. Also useful would be an
explanation of the relationship between B-Net and NFS (Network File
System), and RPC (Remote Procedure Call).

As I understand it... Pipes, socketpairs and sockets are part of
B-Net. Sockets with Internet Domain map to TCP (stream) or UDP
(datagram). A/UX (and Sun) have NFS that is built on TCP/UDP/IP to
avoid using lower-level socket abstractions. Is NFS (and related
layers) part of B-Net or a separate product (protocol)?

Are there any good self-contained references on B-Net? (I am not
even sure if "B-Net" is a generic name, or a vendor-specific term.)

				-- Greg M. Bowen
				   (301) 695-6960
				   Toll Free: (800) 877-1815

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 89 23:12:21 GMT
From:      jon@ATHENA.MIT.EDU (Jon Rochlis)
To:        comp.protocols.tcp-ip
Subject:   MIT virus paper available for anonymous ftp


The MIT paper on the Internet virus of last Novemember, "With
Microscope and Tweezers: An Analysis of the Internet Virus of November
1988", is now available via anonymous ftp from either bitsy.mit.edu
(18.72.0.3) or athena-dist.mit.edu (18.71.0.38) in the pub/virus
directory as mit.PS (and mit.PS.Z). A version of this paper will be
presented at the 1989 IEEE Symposium on Research in Security and
Privacy.

		-- Jon

Abstract:

In early November 1988 the Internet, a collection of networks
consisting of 60,000 host computers implementing the TCP/IP protocol
suite, was attacked by a virus, a program which broke into computers
on the network and which spread from one machine to another.  This
paper is a detailed analysis of the virus program itself, as well as
the reactions of the besieged Internet community.  We discuss the
structure of the actual program, as well as the strategies the virus
used to reproduce itself. We present the chronology of events as seen
by our team at MIT, one of a handful of groups around the country
working to take apart the virus, in an attempt to discover its secrets
and to learn the network's vulnerabilities.

We describe the lessons that this incident has taught the Internet
community and topics for future consideration and resolution.  A
detailed routine by routine description of the virus program including
the contents of its built in dictionary is provided.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 09:48:00 PST
From:      art@sage.acc.com
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   RE: Users of Wollongong's WIN/3B Release 2.1
>Last summer, I upgraded four 3B2/400s and one 3B2/600 to Wollongong's
>"Enhanced" TCP/IP WIN/3B, Release 2.1 (WIN is a Trademark of The Wollongong
>Group, Inc).  These computers belong to the graduate computer science
>department which is highly dependent on their network.  The faculty and
>students soon found out that the software had some serious problems and
>looked to me for some answers.  I couldn't believe how much functionality
>we lost.
>	.
>	.
>	.
>What is this article about?  You won't believe this, BUT, that same AT&T
>bureaucracy claims WE are the only ones that have these problems with this
>sofeware, at least that is what they tell our salesman.  So, our salesman
>asked me to query the readers of this net regarding their experience with
>Wollongong's TCP/IP.  At least I know better, I've been reading this group
>for quite a while now.  AND, if you are still having problems, I've been
>told, that if you respond, someone from AT&T will contact you.  No kidding!
>
>Paul Allen
>...!rutgers!rochester!rit!pha               Rochester Institute of Technology
>pha@cs.rit.edu                              Computer Science Dept.
>pha1775@ritvax                              One Lomb Memorial Drive
>                                            Post Office Box 9887
>                                            Rochester, New York 14623-0877

I would suggest anyone with WIN/3B problems to push on ATT to get Release 3.0
(or later) into release.  This version has most of the current functionallity
equivalent to BSD 4.3 (Van's TCP mods, bind 4.8, etc.).  Release 3.0 seems
to be a large step above 2.1.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1989 07:32-EST
From:      CERF@A.ISI.EDU
To:        hastings@MORGUL.PSC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Whereabouts of NCD
Visual Technology
1703 Middlesex St.
Lowell, MA 01851
(617) 459-4903

I saw a Visual Technology 640 XDS being installed yesterday
and have seen/touched an NCD X-display. Both are quite nice.
the NCD is 1024 X 1024 while the VT is 1024 X 800. The VT
appears to be somewhat less expensive ($1995?) versus ($2550).
When comparing, make sure you price with keyboards and mice!
The VT runs out of PROM memory. I think the NCD downloads
into RAM, but I'm not certain of that.

Vint
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Feb 89 13:00:28 EST
From:      Cathy_Aronson@um.cc.umich.edu
To:        tcp-ip-RELAY@SRI-NIC.ARPA
Subject:   Packet Driver version of NCSA Telnet 2.2 is now Available
The land that time forgot!!!!
 
My aunt and uncle live there and I didn't forget it.
They live on the Raket ( I have never seen it spelled)
River.  It is really pretty there.
---Cathy
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 12:32:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Whereabouts of NCD

Visual Technology
1703 Middlesex St.
Lowell, MA 01851
(617) 459-4903

I saw a Visual Technology 640 XDS being installed yesterday
and have seen/touched an NCD X-display. Both are quite nice.
the NCD is 1024 X 1024 while the VT is 1024 X 800. The VT
appears to be somewhat less expensive ($1995?) versus ($2550).
When comparing, make sure you price with keyboards and mice!
The VT runs out of PROM memory. I think the NCD downloads
into RAM, but I'm not certain of that.

Vint

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 16:07:57 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: The Relationship Between TCP/IP and B-Net?

eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
    I am looking for information regarding TCP/IP and B-Net. Specifically,
    I would like either an explanation of their relationship, or a pointer
    to where such an explanation could be found.

As far as I know, "B-Net" is a term used by Apple and/or Unisoft to refer
to "Berkeley Networking," i.e., something compatible with 4.[23]BSD
networking.  In the case of A/UX this consists of a socket interface which
can be used with UNIX domain sockets, TCP/IP sockets, and so on.

-- 
Amanda Walker			...!uunet!lts!amanda / lts!amanda@uunet.uu.net
			  InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
Calm down; it's only ones and zeros...

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 16:59:54 GMT
From:      schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: CMIP/CMIS info


    	Can someone tell me where to get information about the CMIP/CMIS?
    I understand that they are available as draft standards now, and we are
    interested in seeing what is being proposed for network management standard

Actually I understand it is still out for ballot so its still a DP.

Marty

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 17:36:27 GMT
From:      phil@Apple.COM (Phil Ronzone)
To:        comp.unix.aux,comp.protocols.tcp-ip
Subject:   Re: The Relationship Between TCP/IP and B-Net?

In article <468@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
>I am looking for information regarding TCP/IP and B-Net. Specifically,
>I would like either an explanation of their relationship, ...
>Are there any good self-contained references on B-Net? (I am not
>even sure if "B-Net" is a generic name, or a vendor-specific term.)

B-NET stands for Berkeley NETworking. It is the name supplied to the BSD 4.x
networking code ported over to A/UX (which is System V based). A reasonable
reference is the A/UX manual "A/UX Communications User's Guide".

B-NET (or BNET) the term was coined by UniSoft. UniSoft has spelled it both
ways for a number of years.

+------------------------+-----------------------+----------------------------+
| Philip K. Ronzone      | A/UX System Architect | APPLELINK: RONZONE1        |
| Apple Computer MS 27AJ +-----------------------+----------------------------+
| 10500 N. DeAnza Blvd.  | Computer viruses don't cause security problems,    |
| Cupertino CA 95014     | computer programmers do ...                        |
 +------------------------+----------------------------------------------------+
|{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil                 |
+-----------------------------------------------------------------------------+

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 18:30:52 GMT
From:      haas@wasatch.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

In article <13962@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes:
> On the other hand, CSNET's experience with real commercial X.25 networks
> like Telenet has shown that multiple parallel virtual circuits are often
> necessary anyway to even approach acceptable performance. The problem is the
> small X.25 packet size limit and the tiny packet-layer flow control window.

I was waiting for somebody else to point out the obvious, but it didn't
happen... the small packet size limit and flow control window are *NOT X.25*
problems, they are problems with the Telenet implementation!

Please read the literature before you post...


Walt Haas    haas@cs.utah.edu    utah-cs!haas

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 20:08:25 GMT
From:      system@asuvax.asu.edu (Marc Lesure)
To:        comp.protocols.tcp-ip,misc.wanted
Subject:   Need IEN's

I'm trying to locate ftp'able copies if IEN-19,24,25, and 30.  Does
anyone know where I can get them?  SRI-NIC doesn't seem to have them
on-line.

-----------------------------------------------------------------------
Marc Lesure / Arizona State University / Tempe, AZ
"Between the world of men and make-believe, I can be found..."
"False faces and meaningless chases, I travel alone..."
"And where do you go when you come to the end of your dream?"

UUCP:                ...!ncar!noao!asuvax!lesure  
Internet/CSNET/ARPA: lesure@asuvax.asu.edu

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 20:09:11 GMT
From:      pat@hfsi.UUCP (Pat)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over 802.3.



    I am conducting research on implementing TCP/IP on top of 802.3
protocols.  I was wondering if anyone has any good source articles
or experience in making this work.  Specifically if anyone has
experience in the 802.2 LLC implementation problems I would really 
appreciate any input.  I think E-mail may be most appropriate unless
it is really relevant to the net.

Thanks
Pat

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 21:44:00 GMT
From:      phil@uxg.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   TELNET incompatibility questions


I have the following situation:

-   A host that REQUIRES use of the TELNET IP (Interrupt Process) and
    TELNET AO (Abort Output) commands (prefixed by IAC) in order to
    properly conduct a terminal session.  Without the ability to send
    these commands to that host's TELNET server, it is impossible to
    escape for runaway execution or runaway output.

-   A terminal server that provides no configurable way to transmit
    either the TELNET IP or TELNET AO commands.

Clearly, these two are not going to work well together.  Conceivably,
a modification to either of these could correct the problem.

Are the TELNET IP and AO commands a requirement?  Is it valid TELNET to
require use of them?  Which of the above two would it be more appropriate
to make modifications to?

A change to the host increases the level of compatibility and workability
whereas a change to the terminal server increases the flexibility and
functionality.  I am asking the above questions to get a better insight
on what the TELNET protocol expects of its implementations.

--phil

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 21:57:38 GMT
From:      abair@oakhill.UUCP (Alan Bair)
To:        comp.protocols.tcp-ip
Subject:   Source for FTP c callable functions

The group I work for would like to be able to pipe data to FTP
instead of writting an intermediate file and then invoking FTP to
transfer the file.  As far as I know you cannot directly pipe to
FTP or get it to read STDIN for the file to transfer.

Therefore, I would like to know if there are any c callable functions
that know the FTP protocol.  Then the program that genreates the
data file could open the connection and feed the data directly
across the connection to the FTP server at the other end.

If these types of rotuines do not already exist, how hard would it
be to write a set of functions to do this.  We only need a limited
set of the capabilites of FTP, like only one direction, fixed record
format, minimal error correction, etc.

Please email, since I normally do not read this group.

Thanks,
Alan Bair
SPS CAD  Austin, Texas
Motorola, Inc.
UUCP cs.utexas.edu!oakhill!turbinia!abair

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 89 22:57:41 GMT
From:      karn@jupiter..bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over X.25 (request for info)

>I was waiting for somebody else to point out the obvious, but it didn't
>happen... the small packet size limit and flow control window are *NOT X.25*
>problems, they are problems with the Telenet implementation!
>
>Please read the literature before you post...

I did. Unfortunately nobody seemed particularly interested in implementing
all those wonderful features like modulo-128 packet numbering and packet
window negotiation.  Nor did Telenet seem interested in fixing their
switches to not act as though the D bit were always set.

Paper specs by themselves don't do much for me.

The more gratuitously complicated a protocol is, the greater the
opportunity for the vender to screw it up.

Phil

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 89 02:18:20 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Time Synchronization Protocol (Tempo) spec

We're running the 4.3bsd Time Synchronization Protocol (aka Tempo?) on
our Unix boxes here, and I'd like to implement servers on our
Symbolics machines.  The man page for timed refers to a document,
"TSP: The Time Synchronization Protocol for UNIX 4.3BSD", by Gusella
and Zatti.  Is this document available anywhere for anonymous FTP?

Please respond by mail.

Barry Margolin
Thinking Machines Corp.

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

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 89 10:07:32 GMT
From:      grn@stl.stc.co.UK (Gary Nebbett)
To:        comp.protocols.tcp-ip
Subject:   TELNET and 8-bit ascii codes

Should a computer and terminal communicating via TELNET and capable of
exchanging 8 bit ascii codes (say a VT220 and a VMS system) negotiate BINARY
TRANSMISSION mode?

The Draft Host Requirements RFC states that the high order bit should not be
set in NVT mode.

Regards,
        Gary Nebbett           STL, London Road, Harlow, Essex  CM17 9NA, UK
        Voice +44-279-29531  Email grn@stl.stc.co.uk | PSI%234237100122::GRN

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 89 16:23:22 GMT
From:      dgolber@SM.UNISYS.COM (David Lawrence Golber)
To:        comp.protocols.tcp-ip
Subject:   X.25 service (was Re: IP over X.25)

In article <14077@bellcore.bellcore.com> karn@jupiter.bellcore.com
(Phil R. Karn) writes:
>Nor did Telenet seem interested in fixing their
>switches to not act as though the D bit were always set.

The obvious thing to try: go to other vendors!  That IS one of the
advantages of a standard; there are lots of vendors - at least in
the US.  (When the only vendor is the government PTT, you may have a
problem.)

Nothing gets the attention of a vendor more than loosing business.

I don't think it's the 7-bit sequence numbers you want; it's the
act-as-though-no-D-bit is set.

I'd be real interested in what you find out about different vendors
... and I'm sure lots of other people would to.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 89 17:48:22 GMT
From:      gryphon!cadovax!ucla-an!hermix!lance@elroy.jpl.nasa.gov  (Lance Ellinghouse)
To:        tcp-ip@sri-nic.arpa
Subject:   printerd for TCP/IP
Does anyone know where I can get a program that will allow me to print
files over TCP/IP using the printerd socket? I'm sure SOMEONE out there
has put something together or knows of someone that has.

Please email me at the address below.

Thanks,
Lance Ellinghouse

-- 
Lance Ellinghouse
Mark V Systems, Ltd.
UUCP: ...!hermix!lance
ARPA: ucla-an!hermix!lance@ee.UCLA.EDU
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 89 17:54:34 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Need IEN's

Marc,

A couple of those are on dcn6.udel.edu (anonymous/guest), but I
suspect they are pointers to hardcopies, which may no longer exist.
Poor Fuzzball dcn6.udel.edu is at the end of a 9600-bps line, so
please don't try to mget everything at once.

Dave

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 89 19:40:31 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET incompatibility questions

I would demand that *both* vendors change.  IP and AO are part of the
standard.  They're not a part I am enthusiastic about, but they should
be implemented.  On the other hand, something should also be done by
the host implementation to let it work with telnet's that don't
implement IP and AO.  TELNET BREAK should both stop the process and
abort output.  Either that, or you should emulate the multiple types
of break by saying that the first break stops output, and if you do a
second break witin 1/2 sec of the first, it aborts output, or some
hack like that. An IBM implementation that ignores break is crazy.
However I believe they should even try to coexist with systems that
can't do any of the telnet special commands, and thus they should pick
two control characters to do IP and AO on the host end.

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 00:21:41 GMT
From:      karn@jupiter..bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 service (was Re: IP over X.25)

>>Nor did Telenet seem interested in fixing their
>>switches to not act as though the D bit were always set.
>
>The obvious thing to try: go to other vendors!
>[...]
>Nothing gets the attention of a vendor more than loosing business.

We did! We junked the 9600 bps Telenet X.25 interface several years ago and
went with a 56kbps leased line direct to a port on the ARPANET. Costs far
less and works much better, although I did have to insist I wanted an 1822J
(HDH) port, NOT an X.25 port. It's still amusing to see all that HDLC link
layer overhead on the protocol monitor, but since the data frames are large
and the delays small, it doesn't create any real problem. And, of course,
our gateway is immune to "virtual cirkosis".

>I don't think it's the 7-bit sequence numbers you want; it's the
>act-as-though-no-D-bit is set.

Actually, either one would have been a help, since "local significance" in
the packet layer RRs would reduce the delays and therefore increase the
protocol-imposed throughput limit just as a larger packet layer window
would.

Please don't take any of my criticisms of Telenet and X.25 as criticisms of
the CSNET team at BBN. They did the best job possible given brain-damaged
network facilities, and the fact they could make it work at all can be best
described as heroic.

Phil

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 01:12:44 GMT
From:      sara@SPAM.ISTC.SRI.COM (Sara Tietz, see Ed Kozel)
To:        comp.protocols.tcp-ip
Subject:   Lan Manager MIB meeting and agenda

The MIB Working Group meeting on Wednesday of next week is in fact the
first meeting of a new IETF working group to define MIB for Lan Manager.

This message includes a meeting agenda and
a    *** CHANGE OF LOCATION ***    for the meeting

Date/Location:
   Wednesday, 22 February 
   9am-5pm, Coffee/Pastries at 8:30am

   Sunnyvale Hilton Hotel
   1250 Lakeside Drive
   Sunnyvale, CA    408-738-4888

Directions to Hotel:
   From Highway 101 
   South on Lawrence Expressway
   Left at Oakmead Parkway (the first light)
   Left on Lakeside Drive (one block)

Please RSVP to me if you plan to attend this meeting or send
someone.  I have to order lunches and need an accurate count.
Also, if you plan to stay at the hotel, let me know and I will
try to get discounted rooms for meeting attendees.
RSVP to:  sara@spam.istc.sri.com / 415-941-3399 at ACE

AGENDA:

*Short introduction to Lan Manager
*Objectives of the group
*Relationship to the MIB working group
*Process:  meetings, mailing list, etc.
*Lan Manager management objectives (initial discussion)


Sara Tietz, Advanced Computing Environments

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 01:28:30 GMT
From:      nemo@altger.UUCP (Paolo Bevilacqua)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   LOCUS PC Interface problem

We have installed on our Bell-Tech Unix 3.0 Sys V/386 the 
tcp-ip support by Excelan with 205 Tboard and the PC Interface
by Locus.
Our DOS Workstation must use the wd 8003 S Ethernet board 
running the aposite module by Locus.
We can't establish any connection between the pc and the host.
Using a protocol analyzer the host send broadcast OK, but the PC
send only incoherent packets missing also Ethernet physical addresses
Locus have sent us an additional disk for the support of the 
wd 8003 S with two files :
-wd8003.sys
-wd8003.eth
We have tried these in the config.sys file in conjunction with 
bridge.sys or bridge.ip
and nothing seems to work.
The documentation about use of these files is not of help
because as usual miss important points.
I can exclude any hardware and/or hardware setting problems
and i hope someone with experience on this can help me.
Any suggest will be greatly appreciated, thx in advance.

Reply by news or by mail to : ...mcvax!unido!altger!nemo

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 01:29:49 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Network Management information


	The March 1989 issue of ConneXions--The Interoperability
Report (Vol.3, No. 3) is a special 40 page report on Network
Management. It contains descriptions of both the CMOT and SNMP
architectures, as well as articles on tools that are common to both
systems (Case Diagrams, The SMI & MIB, etc.). An overview of Unisys'
Network Management Language (presented at ACM SIGCOMM 88) and an
article on UCL's Project INCA on Network Management are also included.


(If you are not a subscriber, drop me a note.)


Ole J. Jacobsen, Editor.

-------

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 02:10:24 GMT
From:      swartz@amethyst.bucknell.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)

REQUEST: INFO
TOPIC: HELP

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 03:29:51 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET incompatibility questions

> ...  TELNET BREAK should both stop the process and abort output.  Either
> that, or you should emulate the multiple types of break by  saying  that
> the first break stops output, and if you do a second break witin 1/2 sec
> of the first, it aborts output, or some hack like that. ...

Charles:

When was the new RFC published that changed the TELNET definition for BRK?
RFC 854 indicates that the TELNET BRK  has  no  meaning  except  to  those
systems that implement support for a BREAK key.   In  those  systems,  its
function is to perform the same function that it would  perform  when  the
BREAK key is pressed at a local terminal.  The RFC explicitly states  that
BRK is not a substitute for IP and/or AO.

Merton

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 04:03:49 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET incompatibility questions

Phil:

RFC 854 which defines the TELNET  Protocol  defines  both  IP  and  AO  as
required commands.  A User TELNET which does not provide the capability to
generate an IP or AO command has not been implemented correctly.  In  your
case, the User TELNET is the one that needs to be fixed.  To fully support
the AO command, the TELNET "synch" function needs to be implemented.   The
"synch" function is required to indicate to the User TELNET  when  it  can
stop discarding data received from the Server TELNET.

Merton

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 06:18:57 GMT
From:      john@amc.UUCP (John Sambrook)
To:        comp.protocols.tcp-ip
Subject:   Commercial use of the Internet

I read with interest Stephen Wolff's article (8902140913.aa11462@note.nsf.gov) 
on "Commercial use of the Internet."  As someone who has recently lost his
access to the Internet (due to changing jobs) this topic is (now!) near and
dear to my heart.  I'd appreciate comments on the following suggestion:

I would like to suggest that the rules for obtaining "connected status"
be ammended to permit commerical use of the Internet.  For the sake of
discussion I will refer to this as "Commerical Connected Status (CCS)."
Applying for, and receiving, this status would authorize a commerical
organization to connect to the Internet.

Of course, some means for cost recovery must be provided.  I would
suggest that this would be the domain (no pun intended) of the commerical
communications companies.  In particular, they could provide gateways
to the Internet, that would perform a cost-accounting function.  They 
would bill their customers, and in turn would be responsible for
reimbursing the federal government for their use of the Internet.  

Comments?

John Sambrook                        Internet: amc!john@uunet.uu.net
Applied Microsystems Corporation	 UUCP: amc!john
Redmond, Washington  98073               Dial: (206) 882-2000 ext. 630


-- 
John Sambrook                        Internet: amc!john@uunet.uu.net
Applied Microsystems Corporation	 UUCP: amc!john
Redmond, Washington  98073               Dial: (206) 882-2000 ext. 326

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 09:08:19 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for FTP c callable functions

In article <1856@turbinia.oakhill.UUCP> abair@oakhill.UUCP (Alan Bair) writes:
+---------------
| The group I work for would like to be able to pipe data to FTP
| instead of writting an intermediate file and then invoking FTP to
| transfer the file.  As far as I know you cannot directly pipe to
| FTP or get it to read STDIN for the file to transfer.
+---------------

Well, as a matter of fact, with Berkeley FTP you can, as least for plain
ASCII files, though it's really a kludge. On a "put" command, the special
filename "-" in the position of the input file says to use stdin, and on
a "get" command, "-" in the position of the output file says to use stdout.
Try this (setting $HOST, $USER, $PASS, and $DESTFILE as needed):

	$ cmd... | (echo $USER; echo $PASS; echo put - $DESTFILE) | ftp $HOST

and the output of "cmd..." should end up in $DESTFILE on $HOST. Same thing
works to retrieve output from a remote site:

	$ (echo $USER; echo $PASS; echo get $DESTFILE - ) | ftp $HOST | cmd...

with the remote file showing up as the standard input of "cmd...".

In fact, with some care, binary files usually work, too, but you may run into
problems with error messages ending up in the stream sometimes, etc. As you
say, what you really want is:

+---------------
| Therefore, I would like to know if there are any c callable functions
| that know the FTP protocol.
+---------------

One might think about trying to take the 4.3bsd FTP client and molding it into
a set of "library routines" for use inside random applications programs...
but it's not really that cleanly structured inside, though some of the routines
("command()", "getreply()") are at about the right level. You could do it, but
it would be a lot harder than the simple command-line client outlined below.

+---------------
| If these types of rotuines do not already exist, how hard would it
| be to write a set of functions to do this.  We only need a limited
| set of the capabilites of FTP, like only one direction, fixed record
| format, minimal error correction, etc.
+---------------

DISCLAIMER: The "netcp" mentioned below is an internal tool within AMD, and
            is not itself available (that I know of), though the general
	    idea (an FTP client with an "rcp"-like command line) is easily
	    duplicated. However, should you want to ask them about it, mail
	    to "postmaster@amdcad.amd.com" directly (not to me).

Several years ago, some folks here at AMD [where I am a consultant] wrote a
program called "netcp" which is an FTP client, but which uses an "rcp"-like
command line (you know, the "host:file" syntax). It also reads the "~/.netrc"
file (if present), which makes shell-script and pipeline use extremely easy
(if you are comfortable with the security implications of ".netrc"). Examples:

	$ netcp srchost:srcfile -    # sort of an "rcat", but using FTP

	$ (cd gorp; tar cvf - . ) | compress | netcp -b - desthost:gorp.tar.Z

	$ netcp -b srchost:~ftp/pub/foo.tar.Z - | uncompress | tar xvf -

Since it is merely an FTP client, it works with any standard FTP server.
Thus, there are a bunch of options for doing things you would do interactively
if you were running the usual FTP client, such as "-b" above for "binary"
(a.k.a. "MODE IMAGE").

They started with the source to the standard Berkeley 4.3bsd FTP client,
which is now freely available as one of the "liberated" files on the
4.3-Tahoe release, and you could do the same. Just doing the basics
above is pretty straightforward: Whenever the original code would read
an interactive command from the user, fake up the right command based
on the arguments given on the command line. And watch out that you don't
start proliferating options...  ;-}

Note that -- at least in a Unix environment -- even though "netcp" is a
program rather than a set of library routines, it is still a useful tool
for faking a "remote file open". Just use the Unix "popen()" function.
For example, to open a file remotely and count form-feeds (minus any
error-checking):
	
	FILE *remote_input;
	char buf[BUFSIZ], *host = "somehost"; *filename = "somefile";
	int c, n = 0;

	sprintf(buf, "netcp -b %s:%s -", host, filename);
	remote_input = popen(buf, "r");
	while ((c = getc(remote_input)) != EOF) {
		if (c == '\f')
			++n;
	}
	fclose(remote_input);		/* remember to gather zombie */
	printf("File %s on host %s has %d form-feeds\n", filename, host, n);

You can even do this with the standard FTP client (modulo the caveats above
about getting error messages mixed in the stream), as many Unix implmentations
allow pipelines in "popen()" arguments:

	remote_input = popen("echo get somefile - | ftp somehost", "r");

or, if you don't use "~/.netrc":

	sprintf(buf,
		"(echo %s; echo %s; echo get %s - ) | ftp %s",
		username,
		password,
		filename
		host);
	remote_input = popen(buf, "r");
	while ((c = getc(remote_input)) != EOF) {
	...and so on...

If even that fails, you can write your own version of popen() which hands two
pipes (or stdio FILEs might be better) back to you for both stdin and stdout
(and stderr, for that matter), and then pump the commands "interactively" to
your system's normal FTP client:

	FILE *fdi, *fdo, *fde;

	sprintf(buf, "ftp %s", host);
	my3popen(buf, "r", &fdi, &fdo, &fde);
	fprintf(fdo, "%s\n%s\nget %s -\n", username, password, filename);
	fclose(fdo);				/* push it out to child */
	while ((c = getc(fdi)) != EOF) {
		if (c == '\f')
			++n;
	}
	fclose(fdi);
	...and so on...

Just a few of the many ways to hack out a solution...


Rob Warnock
Systems Architecture Consultant

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

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 09:14:18 GMT
From:      pasteur!sham.berkeley.edu!kiernan@ucbvax.Berkeley.EDU  (Mike Kiernan)
To:        tcp-ip@sri-nic.arpa
Subject:   Pseudo headers in TCP/UDP checksum -- Why?
What is the historical reasoning behind including a pseudo header
(IP src/dst addr, proto #, TCP/UDP len) in the TCP/UDP checksums?

The RFCs state:
	This gives the TCP/UDP protection against misrouted segments.

Misrouted segments from the IP level???  I can't buy this...

People have suggested that it is because TCP might be layered on top
of something else (that doesn't checksum its header), but that doesn't
seem likely (adding a header checksum layer makes more sense).

What is the real reason behind the pseudo header?
Do misrouted packets really get through the IP level to the TCP/UDP level?

Mike Kiernan
kiernan@xcf.berkeley.edu
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 1989 19:03-EST
From:      CERF@A.ISI.EDU
To:        pasteur!sham.berkeley.edu!kiernan@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Pseudo headers in TCP/UDP checksum -- Why?
Mike,

We wanted to make sure that we had true end/end (at TCP level)
checking since the IP level passed through gateways as was potentially
modified en route. We didn't want to literally duplicate information
in the TCP header which was carried in the IP header, so we formed
a pseudo header for efficiency (taking some of the IP fields which
were not supposed to change and making them play a part in the
TCP level checking).

Vint Cerf

p.s. This may sound like a "layer crossing violation" but was
just a way of not duplicating header information.
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 16:56:11 GMT
From:      sow@ulmo1.mt.luth.se (Sven-Ove Westberg)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL

In article <8902101817.AA03292@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes:
|Why do the "Mail bridges" not decrement the TTL?  Or, do they?
|
|(on 26.0.0.90)
|
|#./traceroute ucbarpa.berkeley.edu
|traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets
| 1  UCBARPA.Berkeley.EDU (10.0.0.78)  633 ms  769 ms  595 ms
|#

Where can I find the traceroute program?

Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Internet: sow@cad.luth.se

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 18:12:43 GMT
From:      tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti)
To:        comp.protocols.tcp-ip
Subject:   route tracing through gateways

Hi!
I recently found source for Van J's traceroute program.  It is a really
neat program for finding out what gateways your packets are travelling
through, and for seeing how long it takes to get there.  Unfortunately,
I can't get it to work on my Sun 3/260 running Sun OS 3.5.  I went and
installed all the new TCP/IP from Berkeley, which includes new "slow
start" algorithms, and also made the patch to raw_output that was in
the README for traceroute.  I reconfigured my kernel with all this
new tcp/ip stuff.  The kernel works fine.  All existing networking
functions still function.  Traceroute compiled without serious errors.
But, when I run it, it dumps core.  Has anyone out there gotten this
program to work on a Sun running OS 3.5 ?, or for that matter, Sun OS 3.x?
I would appreciate hearing from you!  Thanks in advance!
                                       - Tom Corsetti
 
-- 
  Tom Corsetti                 * * * *   internet - tomc@dftsrv.gsfc.nasa.gov
  NASA/Goddard Space Flt Ctr    * * *    decnet   - dftnic::tomc
  Greenbelt Maryland           * * * *   bitnet   - tomc at dftbit

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 21:14:05 GMT
From:      pete@NCSC.ARPA (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and DECNET


Fellow SIG Members,
                      I don't know exactly what would satisfy the following,
but I,m looking for a thing which can smooth the  turbulent waters between
TCP/IPers and DECNETters; something that uses the tcp/ip in the appropriate
levels and uses the plusses of decnet in the higher levels.  I know it's
a tall order, particularly since decnet is predicated upon DDCMP.  


                      Thanx in advance
                      Pete Fernandez, pete@ncsc.arpa

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 23:01:31 GMT
From:      romkey@asylum.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo headers in TCP/UDP checksum -- Why?

In article <10010@pasteur.Berkeley.EDU> kiernan@sham.berkeley.edu
(Mike Kiernan) doesn't believe that the historical reason for the TCP
pseudoheader is to detect misrouted IP datagrams.

The keyword is "historical". It doesn't matter much now, but when the
first IP implementations were being written, people knew a lot less
about networking and layered protocols, and this was probably an
important consistency check for the first TCP/IP implementations.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@xx.lcs.mit.edu
"Can you find me soft asylum..." - The Doors

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 89 23:57:36 GMT
From:      brazil@pawl.rpi.edu (Timothy E. Onders)
To:        comp.protocols.tcp-ip
Subject:   SysV SLIP

Does anyone know of a version of SLIP for SysV? I have seen lots of them
for BSD, but we want to run it on a 3B2. Thanks

Timothy Onders

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 00:03:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Pseudo headers in TCP/UDP checksum -- Why?

Mike,

We wanted to make sure that we had true end/end (at TCP level)
checking since the IP level passed through gateways as was potentially
modified en route. We didn't want to literally duplicate information
in the TCP header which was carried in the IP header, so we formed
a pseudo header for efficiency (taking some of the IP fields which
were not supposed to change and making them play a part in the
TCP level checking).

Vint Cerf

p.s. This may sound like a "layer crossing violation" but was
just a way of not duplicating header information.

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1989 18:42-EST
From:      CERF@A.ISI.EDU
To:        tikal!amc!john@BEAVER.CS.WASHINGTON.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Commercial use of the Internet
John,

There are several efforts to make links available from
public email carriers into the Internet. DASNET based
in San Fracisco area (I think) has one such link. UUNET 
has UUCP to Internet facility. My company is working on a
link between Internet and MCI Mail. We hope to pursue
other such links or to encourage them, as appropriate.

This does NOT mean that the Internet should be used for
commercial purposes - I distinguish between links between
commercial organizations and the Internet for purposes of
research support, exchanges with the academic and research
community and commercial use (i.e. using the facilities
of the Internet to support a profit-making enterprise).
It should be legitimate for a commercial enterprise to
provide for-profit services linking their users to users
of the Internet, but the general purpose of such links
should be to further exchanges among the R&D community members.

A final statement of use and interconnect policy is still the
subject of consideration by the members of the FRICC.

Vint
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 1989 18:49-EST
From:      CERF@A.ISI.EDU
To:        pete@NCSC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP and DECNET
Pete,

how about running higher level DECNET stuff above TCP so we
can use ordinary IP gateways to tie everything together? Rather
like Marshal Rose's ISODE suggestion in which higher level
OSI protocols are supported above the TCP layer.

Vint Cerf
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 15:59:44 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECNET


      I don't know exactly what would satisfy the following, but I,m
> looking for a thing which can smooth the turbulent waters between
> TCP/IPers and DECNETters; something that uses the tcp/ip in the
> appropriate levels and uses the plusses of decnet in the higher
> levels.  I know it's a tall order, particularly since decnet is
> predicated upon DDCMP.

    Ah, DECnet isn't stuck on DDCMP. As part of our VMS TCP product,
MultiNet, we provide the ability to run DECnet lines and circuits over
an arbitrary IP network (and the inverse). You can make a
point-to-point DECnet circuit across the Internet, or any other place
where you have IP connectivity. One copy of MultiNet would be required
on each site of the link, and of course any other DECnet-only machines
could route through the link.

    We attach DECnet at the lowest level of the protocol stack and
encapsulate the DECnet datagrams into UDP datagrams for transmission.
When they arrive at the other site, we pass them up to DECnet.

    For more information about MultiNet, please contact me offline...

						Kenneth Adelman
						TGV, Incorporated

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Feb 89 22:14:12 CST
From:      german@uxh.cso.uiuc.edu (Gregory German)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP and DECNET

We are running a DECNET to TCP/IP gateway on a DECserver 3500.
This is a DEC software product running under Ultrix.  TCP/IP users
can login on DECNET machines and DECNET users can login to TCP/IP
machines.  Filetransfer is possible as well.

On a different level our campus backbone routes both TCP/IP and DECNET
traffic.  We are using Proteon gateways between building networks and
the backbone is a collection of 10 and 80 megabit/sec Proteon Token 
Rings.  The two protocols do not interact, but they do co-exist.

         Greg German (german@sonne.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
Office:  129 Digital Computer Lab., Network Design Office
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 19:23:25 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   re: TELNET and 8-bit ascii codes

In a word, the answer is yes, if you want to transmit 8-bit ASCII
codes then you should use network binary mode.  Note that network
binary mode also turns off the special handling of CR; the concept of
the "Telnet newline" only exists if binary mode is off.  Also,
remember that binary mode is unidirectional and if you want a
bidirectional binary stream (e.g. for using the international
character set on a VT220) you must negotiate binary mode in both
directions (IAC DO BINARY + IAC WILL BINARY).

An example of operating systems which support this are WAITS (the
system at SAIL.STANFORD.EDU), ITS, and TOPS-20.  The most important
use is to support 8-bit keyboard controls (the so-called "EDIT" key)
or to turn off local controls for people coming in from a TAC.  The
PANDA version of TOPS-20 also supports VT220 characters as one of
its extensions.

Beware!!  Many Unix Telnet servers tie network binary mode to the
internal Unix concept of "raw" vs. "cooked" terminal modes.  Arguably,
this is a bug or at least a misfeature, but it's much too late to hope
for a fix.  At least some Unix Telnet servers will process 8-bit
characters even if the stream is not in binary mode.  Also, many
terminals send parity in the high order bit.  For this reason, it is
not safe for a Telnet client to enter binary mode on its own without
explicit direction from the human user or from the Telnet server,
since there is no "right" setting that is guaranteed to work on all systems.

-------

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 20:16:08 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET incompatibility questions

The design intent of Telnet IP and AO (about which it happens I can speak
with complete confidence) was certainly that USER Telnets must have the
ability to convey the user's desire to invoke the respective functions
to Server Telnets.  (Explicit note was taken that not all Servers offer
AO, and that we weren't demanding more of them than they would offer in
their native states.  This also applied to not expecting the output to
stop immediately, since some systems would have no way of getting at
data already in the "lowest" output buffers.  For that matter, I expect
the same principle ought to apply to the issue of whether User Telnets
need to get into the act at all on stanching the flow, but let that
ride.)  Therefore, the onus in the case you cite should be on the User
Telnet to give the user a way to cause the Generic Function Codes
in question to be sent to the Server.  Nor should the corresponding
onus on ALL Servers to recognize the GFCs be overlooked, by the way--
for, at any rate, each of the Generic Functions they have specific
native versions of (i.e., let's not forget Erase, Kill, and Are You
There either).

Of course, User Telnets are traditionally deficient; that it's traditional
doesn't make it right, however:  As it says in The Book, the first time
I (and Multics) ever was approached by a User Telnet, it couldn't even
send lower-case--which Multics needed (and I wanted)--and nearly 18 years
(by now) haven't dimmed the indignation (much, anyway).

   cheers, map
-------

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 23:42:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial use of the Internet

John,

There are several efforts to make links available from
public email carriers into the Internet. DASNET based
in San Fracisco area (I think) has one such link. UUNET 
has UUCP to Internet facility. My company is working on a
link between Internet and MCI Mail. We hope to pursue
other such links or to encourage them, as appropriate.

This does NOT mean that the Internet should be used for
commercial purposes - I distinguish between links between
commercial organizations and the Internet for purposes of
research support, exchanges with the academic and research
community and commercial use (i.e. using the facilities
of the Internet to support a profit-making enterprise).
It should be legitimate for a commercial enterprise to
provide for-profit services linking their users to users
of the Internet, but the general purpose of such links
should be to further exchanges among the R&D community members.

A final statement of use and interconnect policy is still the
subject of consideration by the members of the FRICC.

Vint

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 23:46:01 GMT
From:      dtmiller@heart-of-gold
To:        comp.protocols.tcp-ip
Subject:   Whereabouts of "Comments on the IP Source Route Option"


     Does anyone know where I can get a copy (anonymous FTP, preferrably)
of the RFC to be published by J. Postel and J. Reynolds "Comments on the IP
Source Route Option".  This RFC to be was referenced in the Draft Host
Requirements Document in the IP Section.

Post to the Internet or send response to:

dtm@mbunix.mitre.org

Thanks in advance!!

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 89 23:49:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECNET

Pete,

how about running higher level DECNET stuff above TCP so we
can use ordinary IP gateways to tie everything together? Rather
like Marshal Rose's ISODE suggestion in which higher level
OSI protocols are supported above the TCP layer.

Vint Cerf

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 89 06:39:07 GMT
From:      dpz@pilot.njin.net (David Zimmerman)
To:        comp.protocols.tcp-ip, tomc@dftsrv.gsfc.nasa.gov
Subject:   Re: route tracing through gateways

Tom, I've gotten route recording working at Rutgers.  You need four conditions
to exist to get back the information you want:

1- you have to be able to set up IP options to go out in an IP packet

2- your gateways have to do "the right thing"; that is, each has to look at
the IP options, note the IPOPT_RR field, and append its Internet address to
that field (if there is room)

3- if your destination machine has to turn the packet around, it must do so
correctly (see below)

4- you have to be able to read the IP options out of a packet

4.3BSD-derived systems do the right thing for #1 and #4.  cisco gateways do
the right thing with #2.  I'm not sure whether 4.2BSD-derived systems do the
right thing with #1, #2, or #4, since our single link to the outside world is
a 4.3BSD VAX here -> 4.2BSD VAX at JVNC, and we're more or less out of that
manner of beast around here.  However, my experience has been rather negative
with 4.2BSD-derived systems in that respect.

I wanted to set the IP options for route recording in a ICMP echo packet, so
that the echo reply back to me would have the path, or as much of the path as
possible, that the packet took.  Due to the maximum length of the IP option
area, you get a maximum of 9 Internet addresses.

My problem was that a target Unix box using 4.xBSD-derived networking would do
the wrong thing.  4.3BSD-derived systems (including SunOS 4.x) would send me
back an echo reply without any IP options, so I would see that the machine is
up, but not be able to tell what path the packet took to get there and back.
4.2BSD-derived systems (including SunOS 3.x) would get confused and not send
me back anything, so not only would I not get the route back, I couldn't even
tell if the machine was up.

I'm not sure if your problem is related to any of this, but...

I have fixes to sys/netinet/ip_input.c and sys/netinet/ip_icmp.c to take care
of that.  I also have a modified ping to send out and parse back these route
recording creatures (although the code is a one night hack, and looks it).
All our SunOS 4.x Suns and 4.3BSD VAX 11/750 now reflect the ICMP echo back
correctly, and we get to see how our routing isn't working.

Drop me a line if you are interested.

						David
-- 
David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc
dpz@dorm.rutgers.edu          rutgers!dpz          dpzimmerman@zodiac.bitnet

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 89 19:49:49 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   SysV SLIP

*From: leah!rpi!pawl16.pawl.rpi.edu!brazil@csd4.milw.wisc.edu  (Timothy E. Onders)
*Subject: SysV SLIP

*Does anyone know of a version of SLIP for SysV? I have seen lots of them
*for BSD, but we want to run it on a 3B2. Thanks

*Timothy Onders


i believe that spyder systems (in Burlington mass) has slip for the 3B
class of machines. i believe a 3B2 was then machine they used at the 
other end of the slip line we had at the InterOP(1) show.



(1) InterOP is a trademark, i would imagine, of dan lynch's people (ACE).

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 89 23:37:46 GMT
From:      emv@starbarlounge.cc.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip,comp.sources.d
Subject:   ftp'able software (as posted to tcp-ip list)

Here's a summary of software that people have annouced as being
available on the tcp-ip list in the past month or so.  This is
a very brief list without a lot of accompanying details.

zaphod.ncsa.uiuc.edu	NCSA Telnet
sphere.mast.ohio-state.edu	'phone'
athena-dist.mit.edu	Kerberos, Zephyr, MIT worm paper
bitsy.mit.edu		MIT worm paper
sumex-aim.stanford.edu	imap
him1.cc.umich.edu	KA9Q for Atari ST w/SLFP support (cd PC7:)
sun.soe.clarkson.edu	Packet drivers for various PC network devices
omnigate.clarkson.edu	NCSA Telnet w/packet driver support
tolsun.oulu.fi		IRC (Internet Relay Chat)
???			IEN 19,24,25,30

--
Edward Vielmetti, U of Michigan Computing Center

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 89 07:09:01 GMT
From:      gfengstad@laconn.FIDONET.ORG (Grant Fengstad)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP <-> LAN Gateways

Can anyone who has had first hand experience clue me in on what are 
good choices to look at to gateway a LAN into the TCP-IP protocol. 
Specifically, Sun workstations to a Novell LAN.
 
I am aware of a few products out there such as:
 
Micom-InterLan, Wollongong, etc.
 
Which are the best and what are the key differences?
 


--  
Grant Fengstad - via FidoNet node 1:134/104
UUCP: ...!calgary!xenlink!laconn!gfengstad
ARPA: gfengstad@laconn.FIDONET.ORG

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 89 16:06:11 GMT
From:      greggt@VAX1.CC.UAKRON.EDU (Gregg Thompson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.att,comp.sys.ibm.pc,comp.unix.questions,comp.unix.wizards
Subject:   NEED Network for AT&T and IBM computers running Unix and DOS


PLEASE REPLY VIA MAIL, PLEASE DO NOT WASTE "BANDWITH" ON DISCUSSING THIS MESSAGE

I have been asked by a government organization to do some consulting for
them.  They need to set up a network so I thought I would ask here (Usenet)
first to start.

PLEASE reply to me AS SOON AS POSSIBLE.  They need the information and prices
for the network soon so they can bring it up in the next "network committee"
meeting next month.

EMAIL:		greggt@vax1.cc.uakron.edu or greggt@[130.101.2.2]
USMAIL		Gregg F. Thompson
		426 Janes Lane
		Macedonia, Ohio 44056-1820


I need to network the following type of configuration:


AT&T 6386
3B2
IBM PC/XT
(Maybe a Macintosh or Sun 386i need something for Desktop Publishing that will
network easily with TCP/IP.  Any DP WYSIWYG (as you are typing) for the Sun
386i??? Will NeXT sell to local, state, and federal gonvernment agencies?)
All of the machines have at least a 20 megs.

I need to have a network that will support TCP/IP AND NFS so that ALL the
hard disks in the above list will be shared on both DOS and Unix levels.  There
will also be a need of allowing DOS and Unix to "access each other" in the
sense of Unix must be allowed to access DOS data files and DOS must access
data files on Unix.

The 386 will be running both Unix and DOS if possible (preferred) and we need
the ability for the PC to telnet to the Unix "server" (the 386 or 3B2).

The network will start off with at least one or 2 of each of the above list
and will eventually be networked with several other "offices" of the same
configuration and then eventually networked to Internet.

The Unix operating system is from AT&T SYSV.
NEED NETWORK! Cards and software for Unix and DOS!

			Thank You!!
			GRegg
P.S. They will eventually need the desktop publishing soon too.

-- 
To live is to die, to die is to live forever;			GRegg Thompson
Where will you spend eternity?			     greggt@vax1.cc.uakron.edu

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 89 16:32:20 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET and 8-bit ascii codes

One important thing to note about this discussion is its impact on user
transparency. Ideally, a user wants to not know what underlying 
mechanism is used to connect him to his host. It should appear to be
a direct cable link while in data transfer. Telnet, as implemented under
many Un*x systems, causes problems in this respect. For instance,
take a user who is using his PC as an ASCII terminal (YECH) and connecting
to a number of hosts using a multiplexer that uses a number of protocols.
This user is going to expect to be able to do file transfers over 
his async connection. If this user gets a real async hookup
to his UN*X box, this works fine. If, however he happens to be sent to a 
Telnet session, this doesn't work. 

In the days when a user knew that his connection was going to be via
Telnet, this may have been acceptable. But, in these days of 
heterogeneous networks, a non-technical user doesn't want to hear
about the details of implementations. This is a call to end the days
of "Well, UN*X is supposed to have these quirks. It is a programmers'
environment." I think we need to re-think our attitudes and implement 
our systems with the non-technical end user in mind. The days of 
saying that UN*X bugs are part of the deal should be over.

Lets face it, UN*X should not say that it will send 8 bit data when asked
to do so, and then send 7 bit data. (NOTE- this is what SUN 3.5 does).


Wishfully speaking
Bill VerSteeg

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 89 18:20:12 GMT
From:      melpar!toppin@uunet.uu.net  (Doug Toppin)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP Examples?
Can anyone suggest where I can find some good examples
on using TCP/IP? We are using PC/ATs running IBM Xenix
with the Network Research Corporation version of TCP
called 'Fusion'. We are new to the Ethernet world and
would like to see some good public domain examples of
software using it. I have the Comer book 'Internetworking
with TCP' but it contains little in the way of actual
software examples. I'd appreciate any references to books
or software available in the archives that anyone can send me.
thanks
Doug Toppin
uunet!melpar!toppin
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 89 19:42:20 GMT
From:      sra@MBUNIX.MITRE.ORG (Stan Ames)
To:        comp.protocols.tcp-ip
Subject:   IBM MVS TCP-IP

Does any one know of the performance characteristics of IBMs new TCP/IP
product for MVS?  Of particular interest is TCP performance, FTP performance
and NFS performance.  Information regarding how faithfully this implementation
follows the standards is also of interest.

Thanks

Stan Ames

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 89 23:33:01 GMT
From:      abair@oakhill.UUCP (Alan Bair)
To:        comp.protocols.tcp-ip
Subject:   Summary- FTP c callable functions


I would like to thank everyone that responded to my request for help with
FTP.  Sorry I was not able to respond directly to everyone that sent me
suggestions.  And for those that wanted to know what I learned, here is a
summary of the suggestions.

First off, always read ALL of the man page. It turned out that toward the
end, in the section 'FILE NAMING CONVENTIONS', most of what other people
had to say was described.  However, the examples made it a lot easier to
understand.

1. Using the filename '-' for the local file in a put or get will cause
	FTP to read from stdin or write to stdout.  Here is an example
	from rpw3@amdcad.UUCP (Rob Warnock):
-----------------------------------------------------------------------------
Try this (setting $HOST, $USER, $PASS, and $DESTFILE as needed):

        $ cmd... | (echo $USER; echo $PASS; echo put - $DESTFILE) | ftp $HOST

and the output of "cmd..." should end up in $DESTFILE on $HOST. Same thing
works to retrieve output from a remote site:

        $ (echo $USER; echo $PASS; echo get $DESTFILE - ) | ftp $HOST | cmd...

with the remote file showing up as the standard input of "cmd...".

In fact, with some care, binary files usually work, too, but you may run into
problems with error messages ending up in the stream sometimes, etc.
----------------------------------------------------------------------------
	This example also demonstrates the piping of commands to FTP, so you
	could run it in a shell or in C with system("...") without user
	input.

2. The local filename can also be '|program ..." which will cause FTP to either
	read stdout of the program in a put or write to stdin of the program
	in a get.  Here is an example from "Stuart Levy" 
	<uc.msc.umn.edu!slevy@cs.utexas.edu>:
----------------------------------------------------------------------------
ftp>  put "|shellcommand  args ..."  remote-file

and

ftp>  get  remote-file  "|shellcommand  args ..."

so if you can stand to call the pipeline from inside FTP, you can
have it read/write on pipelines rather than disk files.
----------------------------------------------------------------------------
	This also gets around the problem of messages possibly ending up in
	the data stream, as Rob mentioned above.  He also mentioned, that
	due to security reasons, this generally is not allowed for the
	remote filename.

3. I also had an offer for source code that was C callable and acted like
	one end of the FTP connection.  However, it turned out that there
	were some legal requirements(paperwork) to allow for the transfer.
	If your interested, contact:
	hermes.chpc.utexas.edu!xxss533@cs.utexas.edu (Kenneth J. Montgomery)

I think a combination of options 1 and 2 should do what I was looking for.
One final point that I failed to make in my first request, the machine at
the other end of the FTP connection is an IBM mainframe running the
Fibronnics KNET software.  So some of the suggetions I received would not
have worked, along with some of the above options for the remote filename.

Again, Thanks for all the help.
It makes you wonder what the world would be like without a net.

Alan Bair
UUCP cs.utexas.edu!oakhill!turbinia!abair

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 01:54:18 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   dumping LANbridge 100 info

Sometime recently I remember someone posting (Phil Karn maybe?) a note about some software
they'd written which did stuff to/from LANbridge 100's.  Is my memory right?  I looked
through all the 3+ weeks of news we save in these two newsgroups and couldn't find anything.

-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<--          Stop!  Wait!  I didn't mean to!

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 03:14:29 GMT
From:      sale@ed.uucp (Ed Sale)
To:        comp.protocols.tcp-ip
Subject:   Re-fragmenting IP Datagrams

I have just spent the large part of the day trying to determine if it is
legal for an IP gateway to re-fragment an already fragmented datagram
when it attempts to route the datagram from a network with a large MTU
(Max Transmission Unit) to one with a smaller MTU.  I have perused all
*current* RFC's containing the word "fragment" and Douglas Comer's book
to no avail.

A simplified example of the problem arises when an 8 Kbyte UDP datagram 
originates on a network whose MTU is 2K bytes.  The source must fragment
the datagram before sending it and so makes 4 2K byte fragments.  The
destination of the datagram resides on another network whose MTU is 1
Kbyte.  The fragments will be sent from the original source through 1 or
more gateways to a gateway directly connected to the 1 Kbyte MTU network.
This gateway will encounter fragments too large to send on the destination
network.  Is it legal for the gateway to make smaller fragments from the
larger ones?  The problem would also arise if any of the intermediate
physical networks along the route had a smaller MTU than the original net.

If the gateways can't re-fragment datagrams, the solution that immediately
comes to mind is that when the datagram is originally fragmented that it
be divided into some *small* fragment size that all gateways and physical
nets supporting IP are required to handle.  All IP implementations are
required to have MTU's of at least 68 bytes one maximum sized (60 byte) IP
header with one minimum-sized fragment (8 bytes).  I sure hope that this
isn't the case.

Using this "make minimum-sized-fragments" scheme would reduce the
throughput on large MTU nets, however, when sending large datagrams
between two endpoints on the same network with an MTU smaller than the
datagram size but much larger than the minimum size - unless a test was
made before fragmenting to determine what the optimal fragment size should
be.

What do current implementations do?  If there is an RFC addressing this
please let me know so that I can read it.  I apologize if this topic has
been addressed in this newsgroup previously.  Thanks for reading this far
and (hopefully) responding.

Ed Sale

..!uunet!ingr!b11!sale  or  b11!ed!sale@ingr.com

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 08:49:12 GMT
From:      trw@hrc63.co.uk (Trevor Wright "Marconi Baddow")
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   TRW Terminal Servers (ACU 2000's) v Bridge/3Com...


The TRW range of Access Control Units (Terminal Servers) are now being
distributed in the UK. They appear to either run Bridge/3Com 'CS200'
binary or their own TRW code. You can boot from a TRW loader or a
Bridge NCS/AT. 

Does anyone have experience of these units, particularly in a mixed
Bridge/TRW site - also is there any info on whatever the link between
TRW and Bridge is/was...

Trevor Wright
GEC-Marconi Research Centre
Chelmsford
UK
yc23%uk.co.gec-mrc@uk.ac.ucl.cs.nss

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 13:44:56 GMT
From:      ken@ingr.com (Ken Cox)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams

in article <4014@ingr.com>, sale@ed.uucp (Ed Sale) says:
> 
> I have just spent the large part of the day trying to determine if it is
> legal for an IP gateway to re-fragment an already fragmented datagram
> when it attempts to route the datagram from a network with a large MTU
> (Max Transmission Unit) to one with a smaller MTU.  I have perused all
> *current* RFC's containing the word "fragment" and Douglas Comer's book
> to no avail.
> 

RFC 791 addresses this problem, but you have to read carefully to
find it.  To summarize, you can fragment as long as the don't fragment
bit is not set.  The receiving end does not know or care how many times
the original datagram has been fragmented.

If you look at the fragmentation example in the RFC, it will clearly
outline the algorithm for fragmentation (or re-fragmentation.)

--Ken Cox

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 13:57:16 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams

It is perfectly legal and sometimes necessary to further fragment
already fragmented datagrams.  One item to watch out for is being sure
that the MORE_FRAGMENTS bit is cleared only in the last fragment of
the original datagram.  That is, if a gateway fragments datagram A
into AF1 and AF2, AF1 will have the MORE_FRAGMENTS bit set, while AF2
will have it cleared.  If another gateway finds that it must fragment
AF1, all of AF1's fragments (including the last one) would have the
MORE_FRAGMENTS bit set.  Similar considerations apply to the
FRAGMENT_OFFSET field.

4.2 BSD got that case wrong the first time around, but it's been fixed
for a long time.

Thomas

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 14:17:20 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Re-fragmenting IP Datagrams

Fragmentation is addressed in RFC 791 section 2.4.  All Internet hosts must be
able to accept, at a minimum, a 576 octet packet.  Re-fragmentation of an IP
datagram is permitted as long as the "don't fragment" flag is not set.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 18:54:08 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECNET

In article <8902172114.AA06098@ncsc.ARPA> pete@NCSC.ARPA (Fernandez) writes:
>
>Fellow SIG Members,
>                      I don't know exactly what would satisfy the following,
>but I,m looking for a thing which can smooth the  turbulent waters between
>TCP/IPers and DECNETters; something that uses the tcp/ip in the appropriate
>levels and uses the plusses of decnet in the higher levels.  

	Oh, what you want is "DECNet-over-TCP/IP", better known as
DECNOT.  This is similar to the concept of plugging ISO application
layer protocols on top of TCP/IP, like CMOT, which is
CMIP-over-TCP/IP. 

	I was thinking of publishing the specs for DECNOT around the
first of April.  [note date]  I was thinking this might take some of
the wind out of DEC's sails when they come out with "ISO-compliant"
DECNet Phase V.

	I like the acronym, DECNOT.  Practically speaking, we should
call it DECNEVER.

	The converse stack, "TCP/IP-over-DECNet", known as TIPDEC, is
not nearly as feasible as DECNOT.  IF all you want is
"TCP/IP-over-DDCMP", that's no problem, just order TCPoMP, from
Wollamagung software.


	Kent England, Boston University


Disclaimer: None of the above should be taken seriously.  It's all a
personal whimsy of the author's.  

	Seriously, the desired mongrel stack you seek is unfeasible
and you should look for an application layer gateway, like
DECNet-on-Ultrix, or run dual stacks on your DEC nodes, like you can
with the Wollengong software.  You aren't going to see anyone gluing
lower layer TCP and DECNet together in any fashion.

	If you really want to see some fun with application gateways,
look for the "transport-gateways" for gluing TCP/IP applications onto
ISO applications.  That should be fun to watch.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 18:57:10 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Question about route vs. routed


	I'm sure this is a naive question, but could somebody give me a
quick rundown on what /etc/route and /etc/routed do on BSD unix?  We're on
an ethernet with only one connection to the Internet.  People have told me
that instead of running routed on each of my diskless workstations, all I
really have to do is run route from /etc/rc to set up a default route to a
gateway host.  Will I see any difference in performance?  What happens when
that default gateway host goes down?  How will the machines know to switch
to another gateway.

	I'm sure you can tell, from the level of the questions, that I'm
sort of new to this internetworking game.  Maybe somebody could point me at
the appropriate reading material (RFCs, etc) to fill me in on all this
routing magic?
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 89 23:37:23 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams


Ed Sale:

It is "obviously" correct for a gateway to re-fragment a datagram fragment
if it must be sent over a network with a still smaller MTU.

--jon.

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 06:57:23 GMT
From:      hutton@s3sun (Thomas Hutton)
To:        comp.protocols.tcp-ip
Subject:   Re:  Question about route vs. routed

Routed is the routing daemon which speaks RIP.  This is used to pass routing
information between hosts in a domain (eg company, campus, etc).  This is 
called an "interior protocol" as it only is used within your domain.  
The information is used to route between systems and ethernets under
your control.

Since you state that you only have one connection to the internet, that is 
your gateway (and default route).  In your rc file comment out the /etc/routed 
lines and add a line of the form

/etc/route add 0 gatewayhost 2   

where gateway host is your system that talks to the internet.  Since this is
your only path out,  and you only have one ethernet, all your packets for off
site destinations should go to that gateway.

There is really no reason to want to run any interior routing in your case.

Thomas Hutton
hutton@scubed.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 07:40:51 GMT
From:      chedley@psu-cs.UUCP (Chedley A. Aouriri)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   TCP-IP conformance testing

Seeking TCP-IP conformance test software 
----------------------------------------
I am looking for test software from commercial vendors or in the public
domain to validate an implementation of TCP-IP : ie. make sure it is conform
to the official DoD recommendations.
It seems that, starting June 1, 89,  the DCA (Defense Communications Agency) 
will require any machine running TCP-IP to pass a not-yet specified battery of 
TCP-IP validation tests before its vendor can sell it to the DoD and/or its 
related agencies.

Please E-mail and I'll summarize to the usenet.
Thanks,..

...CHEDLEY..
Tel. 503-696-4705
....psueea!psu-cs!chedley

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 11:52:00 EDT
From:      <ddnmgr@adel01.army.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Need some help on info

	I am interested in getting some information concerning
TCP/IP capability for the IBM when the IBM has MVS for the 
operating system.  The two products out there that I have looked
into are ACCESS/MVS and IBM's TCP/IP (due to come out in June).
The major difference that I can find between these products is
that ACCESS gives the capability to use Berkeley sockets while
IBM's product gives you the capability to use Wisconsin sockets.

As a non-Unix person, this does not tell me anything.  Is this an
important difference?

	Any opinions on either of these two products?  Our environment
is an Ethernet environment going out to DDN through a gateway.  We are
mainly a Dec environment here with Suns, Convex, and a few Apollos.

Thanks for any help!

Catherine McDonald
DDNMGR@ADEL01.ARMY.MIL
301-394-2659

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Feb 89 19:21:59 -0600
From:      Gurudatta Parulkar <guru@flora.wustl.edu>
To:        mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Re-fragmenting IP Datagrams

    Fragmentation is addressed in RFC 791 section 2.4.  All Internet
    hosts must be able to accept, at a minimum, a 576 octet packet.
    Re-fragmentation of an IP datagram is permitted as long as the
    "don't fragment" flag is not set. 

I believe the specifications also require all networks to be able to
forward a 576 octet datagram without fragmentation. I can understand
logic behing this requirement as part of IP specifications. But I
wonder what would happen when the first ATM network joins the internet
with packet size of about 64 bytes. Most of the high speed packet
switches being desinged plan to conform to the ATM standards. In such
a mixed environment, does it make sense for an internet layer to
require a minimum packet size of all component networks. Is the packet
size an attribute to be specified by an internet layer or left to
the underlying networks to decide. What are the performance
implications of doing it one way or the other ? 
(Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
in the existing environment, but I am looking beyond.)

I would like to see some discussion on  this issue. Note that I am
talking about an internet layer in a generic sense and not challenging 
IP specifications.

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899 
(314) 889-4621

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Feb 89 15:55:32 EST
From:      "Barry Appelman" <BEAPPEL%YKTVMX.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Sockets on IBM's MVS TCP/IP
Both the VM and MVS TCP/IP from IBM have a Berkeley socket programming
interface.
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 1989 19:37-EST
From:      CERF@A.ISI.EDU
To:        ingr!ed!sale@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Re-fragmenting IP Datagrams
Unless I have completely misunderstood the situation, it is always
technically permissible to re-fragment an already fragmented IP DG.
That is how fragmentation was designed to work.

Vint Cerf
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 15:52:00 GMT
From:      ddnmgr@ADEL01.ARMY.MIL
To:        comp.protocols.tcp-ip
Subject:   Need some help on info


	I am interested in getting some information concerning
TCP/IP capability for the IBM when the IBM has MVS for the 
operating system.  The two products out there that I have looked
into are ACCESS/MVS and IBM's TCP/IP (due to come out in June).
The major difference that I can find between these products is
that ACCESS gives the capability to use Berkeley sockets while
IBM's product gives you the capability to use Wisconsin sockets.

As a non-Unix person, this does not tell me anything.  Is this an
important difference?

	Any opinions on either of these two products?  Our environment
is an Ethernet environment going out to DDN through a gateway.  We are
mainly a Dec environment here with Suns, Convex, and a few Apollos.

Thanks for any help!

Catherine McDonald
DDNMGR@ADEL01.ARMY.MIL
301-394-2659

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 16:28:36 GMT
From:      sale@ed.uucp (Ed Sale)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-Fragmenting IP Datagrams

Thank you all for responding to my query regarding re-fragmentaion of IP
datagrams.  It is legal.



Ed Sale

..!uunet!ingr!b11!sale  or  b11!ed!sale@ingr.com

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 19:24:24 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   SOCK_SEQPACKET vs SOCK_STREAM

For TCP/IP:
In our environment we have to pass a large number of small
messages from a number of processors to a single processor.
Due to max open socket limitations on the server the connections
cannot be kept open for more than a single message.
We are using IBM Xenix V on the AT with NRC Fusion TCP/IP.
I am interested in using data grams but the unreliability problems
in lost or duplicated messages are a concern.
My Questions:
* Is there a performance benefit in using the SOCK_SEQPACKET 
  over the SOCK_STREAM options in the socket call (given known
  data sizes to be sent)?
* How unreliable are data grams in a system without a gateway in
  the real world? (percentage of error)
* What is the best approach in sending a large number of
  small messages where no losses or duplicates getting to the
  applications software can tolerated?
* Is there software in the public domain that will provide a reliable
  data gram system and fit between applications software and the
  protocol software?
Thanks in advance, reply via mail, useful replies will be posted.
Doug Toppin     uunet!melpar!toppin

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 19:36:35 GMT
From:      netcoor@NCS.DND.CA (DRENET Coordinator)
To:        comp.protocols.tcp-ip
Subject:   Odd FTP Problem


Has anyone seen, or can anyone explain this problem?

We have users on network 128.43 who has reported trouble retreiving
files from several hosts in the Internet. The FTP connection is opened
and the user and password are exchanged and the login completed message
is received. After this, problems occur for any command for which a
data connection is to be opened. Other commands not needing the data
connection (eg cd, ascii, binary) work as expected, but commands like
get and dir fail. The usual message received is:

	< 425 Can't build data connection: Connection timed out

although the message:

	< 425 Can't build data connection: Network is unreachable.

is also common. After this, cd and other commands not needing data
connections still work.

This problem is variable in that sometimes it strikes and sometimes it
doesn't. Sometimes it will interrupt an already started data transfer
(the above messages don't apply in this case).

Network 128.43 is gatewayed onto the ARPANET through a Butterfly gateway
(10.1.0.15). I am on network 192.12.98, which is also gatewayed through
the same Butterfly. I have yet to see the problem affect my host (Ultrix).
The host affected on net 128.43 is a DEC 2065 running TOPS-20. 

What confuses me is that packets are being transferred between the two systems
over the command connection throughout, yet any attempt to establish a
new connection for data fails.

Can anyone explain this? I would sure like to understand what is going on
to create this situation, then I can try to do something about it.

Thanks.

Bob Bradford				netcoor@ncs.dnd.ca
DREnet Coordinator			(613) 998-2520

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 20:01:59 GMT
From:      matthews@udel.EDU (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Anyone used SLIP with 19.2kbaud modems?



Has anyone out there used SLIP reliably with 19.2kbaud modems?
Are you happy with the results?  We're thinking about buying a
couple of these fast modems to use here at Bell Labs as backup
network links.  We are not as concerned with the lower throughput
as we are of being unreachable.  If you have had reasonable
success could you please let me know what kind of modem you are using
and possibly what your best TCP/IP configuration was?  By this I mean
did you play with the window size or the mss to get higher throughput?
Could you please respond to me at "matthews@udel.edu" or 
"matthews@research.att.com" just in case I don't get a chance to read
this newsgroup again before the responses expire?
					Thanks in advance,
						John Matthews

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 20:55:32 GMT
From:      BEAPPEL@YKTVMX.BITNET ("Barry Appelman")
To:        comp.protocols.tcp-ip
Subject:   Sockets on IBM's MVS TCP/IP

Both the VM and MVS TCP/IP from IBM have a Berkeley socket programming
interface.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 89 21:42:11 GMT
From:      desnoyer@Apple.COM (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Archives?

Is this newsgroup/mailing list archived on any Internet site
accessible by anonymous FTP?

				Thanks
				Peter Desnoyers

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Feb 89 08:27:52 -0500
From:      Craig Partridge <craig@SH.CS.NET>
To:        guru@flora.wustl.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   re: Re-fragmenting IP Datagrams

> I believe the specifications also require all networks to be able to
> forward a 576 octet datagram without fragmentation. I can understand
> logic behing this requirement as part of IP specifications. But I
> wonder what would happen when the first ATM network joins the internet
> with packet size of about 64 bytes. Most of the high speed packet
> switches being desinged plan to conform to the ATM standards. In such
> a mixed environment, does it make sense for an internet layer to
> require a minimum packet size of all component networks. Is the packet
> size an attribute to be specified by an internet layer or left to
> the underlying networks to decide. What are the performance
> implications of doing it one way or the other ? 
> (Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
> in the existing environment, but I am looking beyond.)

Guru:

    My most recent reading of discussions of ATM (which if memory serves
were in the latest issue of IEEE Network) suggested that the ATM folks
had concluded that they needed some fragmentation/reassembly mechanism
layered on ATM if they were going to support large datagrams.  That's
certainly consistent with the idea that ATM is simply a fancy way to
multiplex a gigabit speed line.

    More generally, I think something is going to have to do this sort of
fragmentation and re-assembly before data on an ATM network reaches an
end-system (or maybe even an intermediate system).  64 octets implies
a capacity to deliver as many as 2 ** 21 datagrams per second to the
end system at one gigabit/second.  That's about one datagram every 3
instructions right now (Using a 6 MIP SUN 4).  If you naively
follow the rule of thumb that processors double in speed every two years,
that's still only 12 instructions in 1993!  So even if the machine could
interrupt that fast, you haven't a hope of processing the data coming in
(parallel processors *might* help -- depends on how you design your
system).  So I suspect someone will have to fragment and aggregate
somewhere in the ATM pipe.

    So yes, I think it is perfectly fair to choose a minimum datagram
size (probably based on your minimum expectations of buffering in end-systems).
In a gigabit realm, I'd suggest that size might well be several kilobytes.

Craig

PS: Some people may wonder why I picked the SUN as a candidate end-system.
Many gigabit applications involve viewing graphics or data on graphics
workstations -- I figure SUNs are *a* reasonable prototype of the type
of machine (in cost/horsepower) that people will want to do these things
on in the early 1990s.  If you disagree with me, that's fine, choose
your favorite machine architecture and berate me if your numbers are better.
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 00:37:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams

Unless I have completely misunderstood the situation, it is always
technically permissible to re-fragment an already fragmented IP DG.
That is how fragmentation was designed to work.

Vint Cerf

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 00:59:21 GMT
From:      jerry@olivey.olivetti.com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

In article <603089521.0.KASHTAN@IU.AI.SRI.COM> KASHTAN@IU.AI.SRI.COM (David L. Kashtan) writes:
>>If it's a matter of saving steps why not just build a DCL wrapper
>>which does the job? Heck, Interlisp-D had what amounted to a very good
>>NFS based on vanilla FTP, required no changes to the server (eg. UNIX
>>or VMS) system as I remember.
>  This is a solution -- though not a pretty one.  It loses on several
>  fronts:
>	1) It doesn't address the issues of system management and disk
>	   quotas.   It is definitely not a selling point for the software
>	   if you are required to have 2 times the disk space available
>	   in order to transparently transfer the files

I think there is a basic misunderstanding here brought about by the
different philosophy of Unix and VMS users.  The VMS users are assuming
that they "backup" or whatever into a file, transfer the file, extract
the files, and then cleanup the temporary files used to store the backup
image.  Thus the requirement for the extra space for the backup.  (Don't
they have the equivelent of a /tmp directory?)

A Unix user implementing the same facility would assume that the data
was being "piped" directly from the output of "tar" to the ftp transfer.
No temporary file names or disk space would be needed and also no long
delay creating the backup before the transfer can start.  And of course
the ftp output can also be piped into tar on the receiving end to
achieve the same benifits.

The common usage of pipes in Unix and the ability of tar and dump to use
them make this an unspoken assumption.

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 01:19:39 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams


    Fragmentation is addressed in RFC 791 section 2.4.  All Internet
    hosts must be able to accept, at a minimum, a 576 octet packet.
    Re-fragmentation of an IP datagram is permitted as long as the
    "don't fragment" flag is not set. 

I believe the specifications also require all networks to be able to
forward a 576 octet datagram without fragmentation. I can understand
logic behing this requirement as part of IP specifications. But I
wonder what would happen when the first ATM network joins the internet
with packet size of about 64 bytes. Most of the high speed packet
switches being desinged plan to conform to the ATM standards. In such
a mixed environment, does it make sense for an internet layer to
require a minimum packet size of all component networks. Is the packet
size an attribute to be specified by an internet layer or left to
the underlying networks to decide. What are the performance
implications of doing it one way or the other ? 
(Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
in the existing environment, but I am looking beyond.)

I would like to see some discussion on  this issue. Note that I am
talking about an internet layer in a generic sense and not challenging 
IP specifications.

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899 
(314) 889-4621

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Feb 89 09:57:49 PST
From:      braden@venera.isi.edu
To:        guru@flora.wustl.edu, mcc@etn-wlv.eaton.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Re-fragmenting IP Datagrams
	
	I believe the specifications also require all networks to be able to
	forward a 576 octet datagram without fragmentation.
	
No, I don't think the specs say that.  We certainly advise AGAINST 
networks with MTU's < 576 for performance reasons, but historically 
there have been several... Packet Radio Net and SATNET, if I remember 
correctly.   If people implement the protocols correctly, communication
should still function across a network with small MTU.

Bob Braden
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 04:11:43 GMT
From:      philipp@PHYSICSA.MCGILL.CA (Philip Prindeville Comp Ctr)
To:        comp.protocols.tcp-ip
Subject:   Re:  Archives?


	Date: 22 Feb 89 21:42:11 GMT
	From: desnoyer@apple.com  (Peter Desnoyers)
	Subject: Archives?
	To: tcp-ip@sri-nic.arpa
	
	Is this newsgroup/mailing list archived on any Internet site
	accessible by anonymous FTP?
	
					Thanks
					Peter Desnoyers
	
Yes it is: sri-nic.arpa in the TCP-IP: directory.  Or you
can send mail to action@sri-nic.arpa for more help if
you don't have FTP access.

In any case, questions like this should *always* go to
the list maintainer, not the readership.  Next time, try:
<tcp-ip-request@sri-nic.arpa>.  This applies to most
Internet mailing lists.

-Philip

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 1989 14:32-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        guru@flora.wustl.edu
Cc:        tcp-ip@sri-nic.arpa, Craig Partridge <craig@SH.CS.NET>
Subject:   Re: Re-fragmenting IP Datagrams
> I believe the specifications also require all networks to be able to
> forward a 576 octet datagram without fragmentation.

That's incorrect, Guru.  From page 25 of the IP spec (RFC 791):

	Every internet module must be able to forward a datagram of
	68 octets without further fragmentation.  This is because an
	internet header may be up to 60 octets, and the minimum
	fragment is 8 octets.

	Every internet destination must be able to receive a datagram
	of 576 octets either in one piece or in fragments to be
	reassembled.

Therefore, every network must be able to deliver 68 bytes of IP in one
piece.  This is still too long for the silly ATM stuff, but as Craig
pointed out, transparent fragmentation and reassembly below the IP
level is allowed by the IP architecture (and recommended for networks
with ridiculously small MTUs).

Steve
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 13:27:52 GMT
From:      craig@SH.CS.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Re-fragmenting IP Datagrams


> I believe the specifications also require all networks to be able to
> forward a 576 octet datagram without fragmentation. I can understand
> logic behing this requirement as part of IP specifications. But I
> wonder what would happen when the first ATM network joins the internet
> with packet size of about 64 bytes. Most of the high speed packet
> switches being desinged plan to conform to the ATM standards. In such
> a mixed environment, does it make sense for an internet layer to
> require a minimum packet size of all component networks. Is the packet
> size an attribute to be specified by an internet layer or left to
> the underlying networks to decide. What are the performance
> implications of doing it one way or the other ? 
> (Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
> in the existing environment, but I am looking beyond.)

Guru:

    My most recent reading of discussions of ATM (which if memory serves
were in the latest issue of IEEE Network) suggested that the ATM folks
had concluded that they needed some fragmentation/reassembly mechanism
layered on ATM if they were going to support large datagrams.  That's
certainly consistent with the idea that ATM is simply a fancy way to
multiplex a gigabit speed line.

    More generally, I think something is going to have to do this sort of
fragmentation and re-assembly before data on an ATM network reaches an
end-system (or maybe even an intermediate system).  64 octets implies
a capacity to deliver as many as 2 ** 21 datagrams per second to the
end system at one gigabit/second.  That's about one datagram every 3
instructions right now (Using a 6 MIP SUN 4).  If you naively
follow the rule of thumb that processors double in speed every two years,
that's still only 12 instructions in 1993!  So even if the machine could
interrupt that fast, you haven't a hope of processing the data coming in
(parallel processors *might* help -- depends on how you design your
system).  So I suspect someone will have to fragment and aggregate
somewhere in the ATM pipe.

    So yes, I think it is perfectly fair to choose a minimum datagram
size (probably based on your minimum expectations of buffering in end-systems).
In a gigabit realm, I'd suggest that size might well be several kilobytes.

Craig

PS: Some people may wonder why I picked the SUN as a candidate end-system.
Many gigabit applications involve viewing graphics or data on graphics
workstations -- I figure SUNs are *a* reasonable prototype of the type
of machine (in cost/horsepower) that people will want to do these things
on in the early 1990s.  If you disagree with me, that's fine, choose
your favorite machine architecture and berate me if your numbers are better.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 14:55:41 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams


>I believe the specifications also require all networks to be able to
>forward a 576 octet datagram without fragmentation.

576 is not a lower limit on the size of a datagram fragment, but an
upper limit on what a destination is *required* to accept.  The
sender/destination might agree to exchange larger datagrams, but any
such agreements are private to the communicating end points.

From RFC-791:

    Every internet module must be able to forward a datagram of 68
    octets without further fragmentation.  This is because an internet
    header may be up to 60 octets, and the minimum fragment is 8 octets.

    Every internet destination must be able to receive a datagram of 576
    octets either in one piece or in fragments to be reassembled.

Thomas

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 15:55:02 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS" extension

First, there is no /tmp in VMS.  Face it, /tmp is an arcane leftover
from when UNIX ran on machines that did not have virtual memory.

There is nothing really like pipes in VMS, especially at the command
level.  The syntax of the BACKUP command is also very awkward and
restrictive. 

ALso, a pipe would fail to solve the same basic VMS problem.  Files
are not just a sequence of bytes in VMS.  They have a lot of
attributes, attributes that must be preserved or the file is useless.
(It is better than OS/360, since the system always keeps track of the
attributes for you.)  Thus, the output of BACKUP, when sent throught a
pipe (or transferred via FTP) loses a key attribute: it's
extraordinary block size.

Also, as noted before, the output of the BACKUP program is not an
efficient format.  It has a very high degree of redundnacy.  You can
punch a 1/4" hole in a BACKUP tape and still restore from it.
Overkill for what will be transferred over FTP, which we trust more
than a tape drive.

The VMS folks have a real problem.  The binary abstraction of FTP just
does not hack it for their files.  You will find that they are not the
only OS that has addresses this, I think the UCLA MVS TCP/IP FTP
allows you to specify a bit of (moral) JCL before writing a file.

Let's let them agree on something to solve this problem.  Anything to
make the VMS users less anti-TCP.

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 17:30:20 GMT
From:      frg@jfcl.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams

In article <8902230119.AA22877@flora.wustl.edu> guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) writes:
>
>    Fragmentation is addressed in RFC 791 section 2.4.  All Internet
>    hosts must be able to accept, at a minimum, a 576 octet packet.
>    Re-fragmentation of an IP datagram is permitted as long as the
>    "don't fragment" flag is not set. 
>
>I believe the specifications also require all networks to be able to
>forward a 576 octet datagram without fragmentation. I can understand
>logic behing this requirement as part of IP specifications. But I
>wonder what would happen when the first ATM network joins the internet
>with packet size of about 64 bytes. Most of the high speed packet
>switches being desinged plan to conform to the ATM standards.

There is a simple answer to that question.  ATM operates within
the (OSIRM) Physical layer, while IP operates within the SNICP role
of the Network layer.  As nonadjacent layers, they do not have to
get along.

ATM cells (not "packets") carry fragments of data link layer packets
((or "frames", but not really frames in this case).  A segmentation
and reassembly function takes place atop ATM to allow large packets
to be carried.  One such technique is proposed in the current 802.6
letter ballot.  ANother, called the ATM Adaptation Layer (AAL), has
been bandied about the Broadband ISDN group.  It is fatally flawed, 
as currently proposed, but it does support long packets.  Any number
of workable mechanisms (which would take the Data Link layer into
account) can be created for this purpose.

Or to look at it differently, T1 carrier with D4 channel banks
uses 1-byte fragments, position-interleaved.  ATM uses 64-byte
fragments, labeled.  But they're both down in mux-land, not in
the subnetwork role that IP has to contend with.
     fred (T1S1 member)

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 18:47:52 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SOCK_SEQPACKET vs SOCK_STREAM

Doug,

WHAT YOU NEED IS...  a tranaction transport protocol.

I suggest you look into Dave Cheriton's VMTP, described in RFC-1045 (see also
RFC-955).

Bob Braden

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 19:58:20 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   re: Odd FTP Problem


     I've seen this problem in other forms.  Apparently there are a lot of
"ICMP Destination Network Unreachable" messages getting sent in instances
where network connectivity is broken for only a brief duration (perhaps due
merely to congestion at a gateway).

     Some versions of BSD Unix nuke the connection when this or "host
unreachable" occur; it is reputed that patching location _inetctlerrmap+8 in
the kernel from 0x3341 to 0x0 remedies this problem but I haven't been able to
verify it.

     Since the "425 Can't build data connection" message is coming from the
remote server, it suggests that the problem is occuring when the remote server
tries to open a connection to the FTP client on the 128.43 TOPS-20 host.
Because of this, I'm inclined to absolve the TOSP-20 host of guilt
(particularly in the "Network is unreachable" case), and more likely to blame
network routing.

     Question: could an ICMP Destination Network Unreachable happen when
something like an X.25 virtual circuit limitation is reached?

-------

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 21:18:47 GMT
From:      martinea@CRC.SKL.DND.CA (Mike Martineau)
To:        comp.protocols.tcp-ip
Subject:   Dial up slip


I remember seeing a number of messages regarding dial up slip
in the past month.  I suddenly have an urgent need to get more
info re: dial up slip but, unfortunately,  did not save any of
the previous mail messages.  Can someone point me in the right
direction?

Thanks,

Michael Martineau
Software Kinetics Ltd.
martinea@crc.skl.dnd.ca (192.5.204.1)

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 22:32:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: Re-fragmenting IP Datagrams

> I believe the specifications also require all networks to be able to
> forward a 576 octet datagram without fragmentation.

That's incorrect, Guru.  From page 25 of the IP spec (RFC 791):

	Every internet module must be able to forward a datagram of
	68 octets without further fragmentation.  This is because an
	internet header may be up to 60 octets, and the minimum
	fragment is 8 octets.

	Every internet destination must be able to receive a datagram
	of 576 octets either in one piece or in fragments to be
	reassembled.

Therefore, every network must be able to deliver 68 bytes of IP in one
piece.  This is still too long for the silly ATM stuff, but as Craig
pointed out, transparent fragmentation and reassembly below the IP
level is allowed by the IP architecture (and recommended for networks
with ridiculously small MTUs).

Steve

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 89 23:17:48 GMT
From:      davy@RIACS.EDU
To:        comp.protocols.tcp-ip
Subject:   Header Processing Times


One of the researchers here is looking for information about how long it
takes to process a "network packet".  For the type of stuff she needs,
it really doesn't matter what "network packet" is, it could be TCP/IP,
DECNET, XNS, whatever.  TCP/IP or OSI would probably be best, though.

Anyway, what she's looking for is stuff which answers questions like,
"given a bunch of data to send, how long does it take to stick the
headers on, increment the sequence number, compute the ckecksums, etc.
before sticking the packet on the wire?"  The timings can be for any
arbitrary processor, although something "well known" like a Vax, Sun,
or PC would be preferred.

Hopefully the above is clear.  If anyone has any data like this they'd
be willing to let us have, or any pointers to published work on the
above, please reply to me (not the list) via mail.  If there's enough
interest, I'll summarize my findings back to the list.

Thanks,

Dave Curry
Research Institute for
Advanced Computer Science
davy@riacs.edu

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 00:40:47 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension


	does not hack it for their files.  You will find that they are not the
	only OS that has addresses this, I think the UCLA MVS TCP/IP FTP
	allows you to specify a bit of (moral) JCL before writing a file.
	
Yes, the UCLA MVS ACP implements the FTP SITE command with keyword
parameters calculated to warm the heart of a JCL-lover -- BLKSIZE(),
RECFM(), LRECL()... all that wonderful stuff! (yukh)

Bob Braden

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 01:34:52 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   What seems to be a glitch in the TCP spec.

Consider the following situation:  A TCP connection is carrying
intermittent, bidirectional traffic.  Host A has just sent a burst
which filled host B's window.  B has enough data for a small segment,
piggybacking the Ack and indicating a window of 0.  A replies with an
Ack, just as B's application consumes the data and B sends a segment
to re-open the window.  B's implementor has chosen to retransmit the
first segment of un-acked data (if any) with window updates and Acks
(B's cost/packet is much larger than the cost/byte).  A's implementor
has exactly followed pg. 69 of RFC 793, which says to discard segments
with obsolete data before checking the Ack or Window values.

     Host A						    Host B
1.	    <-	Seq 100, Ack 200, Data 20, Window 0

2.	     	Seq 200, Ack 120, Data 0, Window 4076	-> (crosses w/3)

3.	    <-	Seq 100, Ack 200, Data 20, Window 4096	(Dropped per pg. 69)

4.		Seq 200, Ack 120, Data 0, Window 4076   -> (ignored, pg. 72)

Segments 2 and 3 cross in transit, A drops 3 before checking either the
Ack or the window and sends 4, which B drops as a duplicate Ack.  At
this point, A has more data to send, but B doesn't.  Everyone has followed
the spec, but A didn't see B's window re-open, and the connection will
sit idle until A sends a window-probe segment.  The user is unhappy,
because a TCP-based window system glitches.

I see four possible solutions:

1. Tell the user that he has found a glitch in the spec, and he should
be glad that heterogenous networking works at all.  See Figure 1.

2. Amend the spec to warn that "window updates and acks may be ignored
if they accompany retransmitted data; therefore this should be avoided".

3. Amend the spec to require that the first window-probe segment be sent
when the window stays zero for two round-trip times.  If the probe is
rejected, try again in a couple of minutes.

4. Amend the spec to require that, when a segment is about to be dropped
per pg. 69, if the segment is immediately to the left of the window (e.g.
(SEG.SEQ + SEG.LEN) == RCV.NXT), SEG.ACK should be checked, and if it
is valid (SEG.ACK >= SND.UNA), both the Ack and the Window should be
processed before the segment is discarded and the obligatory Ack sent.
Note that pg. 72 of the RFC has an error.  As corrected in the upcoming
"Requirements for Internet Hosts" RFC, the send window should be updated
even when SEG.ACK == SND.UNA (otherwise TCP could not continue without
a window probe once the send window went to 0).

I don't like solution 1 (after all, I want the customer's money).  I have
discussed this matter with some other TCP implementors, who don't like
solution 2, particularly when applied to Telnet connections.  Solution
3 is partially implemented in some TCPs (the first probe occurs after
about 4 sec.), but there is still a glitch.  I've fully implemented
solution 4, and have two years of experience with it (in a commercial
product).  It seems to work, and the only objection I can think of is
a miniscule increase in the probability of the connection being reset
due to an old duplicate segment (the mechanism is "ack of unsent data",
not accepting bad data, and the odds of this are still way below those
of damaged data escaping detection by the TCP checksum).

Comments?  In particular, have I missed something relevant in RFC 793?
Has someone else already addressed this issue in some publication other
than an RFC?

One TCP implementor I discussed this with asked:  "Is there any particular
reason why we couldn't amend the spec to say 'check all acks, regardless
of the sequence field?'?"  Any comments on this?

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 06:20:27 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: Odd FTP Problem


      Mark,

   A couple of weeks ago BRL noted severe difficulties with
connectivity. We were able to trace this to ICMP Network Unreachables
(we're a BSD shop), which appeared to be the result of core route
"flopping".  At the end of this message, I'll tack on the message I sent
to BBN on the subject.  The raw data file mentioned in that message
is still available if anyone is masochisitic enough to want to look at
it.

   When we spoke to BBN the afternoon before sending that message, they
told us they had identified a problem with routing, and a message
received the next afternoon confirmed that a fix to the problem alluded
to in the phone conversation would be fielded in the next few days.  By
mid-week the following week, connectivity did indeed appear to be better
than previously.

   Since this last change, we still see more routing variability than we
feel should be present though it does look better than before the
change.  One curious thing, has anyone else noticed the EGP peers
bouncing in and out?  We peer with BMILDCEC, BMILBBN, and BMILMTR in
that order (though we only exchange updates with one at any given time),
and we are continually having to re-acquire one or more of these
beasties (as I write this, the gateway is trying to acquire BMILMTR).
Have these gateways been bouncing up and down a lot?   We have also
started looking at the EGP information we are getting a little more
closely, and have seen hopcounts as high as 62(!).

   In the last few days, our PSN insufficient resource (type 4)
messages are haunting us again.  We had earlier reported these and BBN
reconfigured our PSN with more space allocated to buffers to lessen the
severity of that problem.  I suppose we'll have to complain about this
again.

   Has anyone else noted any interesting behavior since the change?

				Later,
				    Bob 
   --------
Phone:  (301)278-6678   AV: 298-6678    FTS: 939-6678
Arpa:   reschly@BRL.MIL (or BRL.ARPA)   UUCP: ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
        U.S. Army Ballistic Research Laboratory
        Systems Engineering and Concepts Analysis Division
        Advanced Computer Systems Team
        ATTN: SLCBR-SE  (Reschly)
        APG, MD  21005-5066             (Hey, *I* don't make 'em up!)

****  For a good time, call: (303) 499-7111.   Seriously!  ****

================
Date:     Thu, 9 Feb 89 5:51:55 EST
From:     "Robert J. Reschly Jr." <reschly@brl.mil>
To:       meason@wash.bbn.com, amalis@bbn.com
cc:       jcst@BRL.MIL
Subject:  More Node 29 troubles.


      Mike,

   Here is a summary of our recent experience and a copy of Phil's message.

   First, the incompletes are still with us though they appear to be at
the reduced level we noted after the PSN buffer configuration changes.
The only note here is that these messages are still coming in at a much
greater rate than before our switching to EGP peering with the
Buttergates.  We are currently seeing these 5 to 10 (on average) times
an hour, rather than 5 to 10 times a day.

   Second, as Phil notes in the enclosed message, we have been suffering
from what looks like significant routing instability since switching to
EGP peering with the Buttergates.  The variability in numbers of reported
routes was noted as soon as we switched, but we did not notice any actual
reachability problems until a while later.  A typical sequence would be:

	Establish a connection (e.g. FTP, TELNET, rlogin); everything
	appears fine, connectivity is good and round trip times are
	reasonable.

	After a few minutes of operation, suddenly the the connection
	freezes.  The connection usually closes at this time.

	Attempt to restart the connection -- this usually fails

	Wait a few minutes, then attempt to restart the connection.
	This usually succeeds as if there was never any problem.  At
	this point the cycle repeats.

   Running an experiment with ping shows that the loss of communication
coincides with the receipt of ICMP Network Unreachable messages.  I ran
a ping experiment against louie.udel.edu to see if I could  duplicate
and record the symptoms today.  I'll include a summary from the first
part of that at the end of this message, and will put the raw data,
(roughly 1.3MB collected over 4 hours between 1800 EST and 2200 EST 8
Feb 1989) in the public FTP area of vgr.brl.mil.  Note that since this
is a script of a terminal session, there are a few control characters
and escape sequences buried in this file.  We currently EGP peer with
the buttergates at DCEC and CAMBRIDGE as our primary and fallback.

   I have also made some changes to the gateway software to extract a
bit more information but have nothing to present at this time.

   The raw data is the composite of a 15 second timestamp loop, the
ping, and the gateway console all smashed together and intertwingled.
The ping generates the "xx bytes" messages as well as the verbose dumps
of most other ICMP messages.  Much of the gateway console output is
prepended by "<process_name>: ", though there are a few messages which
are different (e.g. "ICMP redirect" and "UPTIME" messages.  The gateway
software is of local origin.  If you have any questions about any of it,
get in touch with us and we will clarify.

   Finally, you will find a number of "milr:  msg with link 27 from
4/48" followed by an equal number of "milr: pack len <value1>, format 15,
illen <value2>" messages.  The values range over a small set for each.
We only started noticing these today, but had not been closely watching
the gateway for the few days prior to today.  The "link" parameter is
the link type from the IMP leader -- we are 1822 connected.

   I hope this stuff helps.
				Later,
				    Bob 
   --------
Phone:  (301)278-6678   AV: 298-6678    FTS: 939-6678
Arpa:   reschly@BRL.MIL (or BRL.ARPA)   UUCP: ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
        U.S. Army Ballistic Research Laboratory
        Systems Engineering and Concepts Analysis Division
        Advanced Computer Systems Team
        ATTN: SLCBR-SE  (Reschly)
        APG, MD  21005-5066             (Hey, *I* don't make 'em up!)

****  For a good time, call: (303) 499-7111.   Seriously!  ****

----- Forwarded message # 1:

Received: from smoke.brl.mil by SEM.BRL.MIL id aa07207; 2 Feb 89 7:56 EST
Received: from SMOKE.BRL.MIL by SMOKE.BRL.MIL id aa12789; 2 Feb 89 7:52 EST
Received: from SRI-NIC.ARPA by SMOKE.BRL.MIL id aa12653; 2 Feb 89 7:45 EST
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Thu, 2 Feb 89 01:47:18 PST
Date:     Thu, 2 Feb 89 4:41:04 EST
From:     Phil Dykstra <phil@BRL.MIL>
To:       tcp-ip@sri-nic.arpa
Subject:  Instability in the Core
Message-ID:  <8902020441.aa16937@VGR.BRL.MIL>

Tonight I was trying to talk to some machines on XEROX-NET (net 13), and
once again was hit with oscillating Net-Up/Net-Unreachable.  This has been
happening to me for the past several days for net 13 as well as several
other nets (FYI, I'm 26.2.0.29).

We have been getting EGP info from the RESTON-DCEC Butterfly (26.21.0.104).
I started watching tonight to see why these routes kept appearing and
disappearing and found major unrest in the routing information we were
getting.  Here are nine consecutive EGP routing updates (taken at three
minute intervals).  They span 0400 EST.

	Int  Ext Routes (~A   B   C)
	 5   95   479
	 6   85   536
	 5   95   401
	 6   86   598    17  333  263
	 6   84   507    15  266  241
	 5   94   456     8  270  193
	 6   91   599    16  335  263
	 4   93   453     8  266  194
	 6   87   580    17  321  257

The fields are number of internal and external EGP gateways, total number
of routes, and the approximate number of class A, B, and C (approx because
this includes a few of our fixed routes).  I have complete EGP dumps for
the last six updates if anyone wishes to study the changes.

It really bothers me that the number of class A networks could double/half
every three minutes!  There is also a 10% to 50% change in the total number
of routes every three minutes.  One wouldn't expect the number of internal
EGP gateways to change so fast either [thought the LSI-11's used to flop
like that too].

It is nearly impossible to get data through when the routes come and go
this fast.  I realize that the Butterfly folks are probably working on
this, but I wasn't sure everyone was aware how bad things are right now
(I recall one other TCP-IP note about it).  Is there anything we can do
to help diagnose this?

- Phil
<phil@brl.mil>
uunet!brl!phil

----- End of forwarded messages

================
Script started on Wed Feb  8 18:11:57 1989
PING louie.udel.edu (128.175.1.3): 56 data bytes
64 bytes from 128.175.1.3: icmp_seq=0 time=466 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=95 time=433 ms
64 bytes from 128.175.1.3: icmp_seq=96 time=981 ms
Wed Feb  8 18:14:15 EST 1989
64 bytes from 128.175.1.3: icmp_seq=96 time=1948 ms	<<<DUPLICATE!
64 bytes from 128.175.1.3: icmp_seq=97 time=1084 ms
64 bytes from 128.175.1.3: icmp_seq=98 time=451 ms
64 bytes from 128.175.1.3: icmp_seq=99 time=514 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=175 time=566 ms
Wed Feb  8 18:15:36 EST 1989
64 bytes from 128.175.1.3: icmp_seq=176 time=414 ms
64 bytes from 128.175.1.3: icmp_seq=177 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=178 time=414 ms
64 bytes from 128.175.1.3: icmp_seq=179 time=499 ms
64 bytes from 128.175.1.3: icmp_seq=180 time=481 ms
64 bytes from 128.175.1.3: icmp_seq=181 time=481 ms
64 bytes from 128.175.1.3: icmp_seq=182 time=499 ms
64 bytes from 128.175.1.3: icmp_seq=183 time=599 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a304   0 0000  fb  01 c3e4 c0051708 80af0103 
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a30f   0 0000  fb  01 c3d9 c0051708 80af0103 
 ... 21 more net unreachables deleted ...
egp: default of 26.1.0.49 with 293 routes		<<<GATEWAY EGP UPDATE
egp: 87 gwys, 6 int, 81 ext (565 routes).
ip: 587 routes, 15 A, 306 B, 259 C, 7 S, 0 O.
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a3a4   0 0000  fb  01 c344 c0051708 80af0103 
Wed Feb  8 18:16:09 EST 1989
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a3aa   0 0000  fb  01 c33e c0051708 80af0103 
 ... 45 more net unreachables deleted ...
milr:  msg with link 27 from 4/48			<<<FUNNY AFWL MESSAGES
milr: pack len 2352, format 15, illen 28681		<<<"4/48" IS PORT/NODE
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a4c1   0 0000  fb  01 c227 c0051708 80af0103 
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a4c6   0 0000  fb  01 c222 c0051708 80af0103 
Wed Feb  8 18:16:58 EST 1989
 ... 42 more net unreachables deleted ...
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a5f3   0 0000  fb  01 c0f5 c0051708 80af0103 
64 bytes from 128.175.1.3: icmp_seq=300 time=633 ms	<<< ONLY DROPPED 3PKTS
64 bytes from 128.175.1.3: icmp_seq=301 time=733 ms
Wed Feb  8 18:17:47 EST 1989
64 bytes from 128.175.1.3: icmp_seq=302 time=666 ms
64 bytes from 128.175.1.3: icmp_seq=303 time=881 ms
92 bytes from BRL.ARPA (26.2.0.29): Source Quench
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a605   0 0000  fc  01 bfe3 c0051708 80af0103 
64 bytes from 128.175.1.3: icmp_seq=304 time=1248 ms
64 bytes from 128.175.1.3: icmp_seq=306 time=633 ms
64 bytes from 128.175.1.3: icmp_seq=307 time=748 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=331 time=1381 ms

Wed Feb  8 18:18:19 EST 1989
64 bytes from 128.175.1.3: icmp_seq=333 time=933 ms
milr:  msg with link 27 from 4/48
milr: pack len 2352, format 15, illen 28681
64 bytes from 128.175.1.3: icmp_seq=334 time=1281 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=384 time=784 ms
64 bytes from 128.175.1.3: icmp_seq=386 time=566 ms
64 bytes from 128.175.1.3: icmp_seq=387 time=651 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=410 time=766 ms
Wed Feb  8 18:19:40 EST 1989
64 bytes from 128.175.1.3: icmp_seq=411 time=833 ms
64 bytes from 128.175.1.3: icmp_seq=412 time=633 ms
64 bytes from 128.175.1.3: icmp_seq=413 time=548 ms
64 bytes from 128.175.1.3: icmp_seq=414 time=766 ms
64 bytes from 128.175.1.3: icmp_seq=415 time=848 ms
64 bytes from 128.175.1.3: icmp_seq=416 time=633 ms
egp: default of 26.1.0.49 with 232 routes		<<< GATEWAY EGP UPDATE
egp: 86 gwys, 6 int, 80 ext (434 routes).
ip: 456 routes, 14 A, 243 B, 192 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=417 time=848 ms	<<< 1 MORE PACKET THEN
Wed Feb  8 18:19:56 EST 1989				<<< NOTHING UNTIL
Wed Feb  8 18:20:12 EST 1989
Wed Feb  8 18:20:28 EST 1989
milr:  msg with link 27 from 4/48
milr: pack len 2352, format 15, illen 28681
Wed Feb  8 18:20:44 EST 1989
Wed Feb  8 18:21:00 EST 1989
milr: incomplete 15/115 3
Wed Feb  8 18:21:16 EST 1989
64 bytes from 128.175.1.3: icmp_seq=514 time=418 ms	<<< HERE
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=534 time=499 ms
92 bytes from BRL.ARPA (26.2.0.29): Source Quench
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a836   0 0000  fc  01 bdb2 c0051708 80af0103 
64 bytes from 128.175.1.3: icmp_seq=536 time=514 ms
Wed Feb  8 18:21:49 EST 1989
64 bytes from 128.175.1.3: icmp_seq=537 time=533 ms
36 bytes from localhost (127.0.0.1): Destination Port Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 003d a842   0 0000  1e  11 0000 7f000001 7f000001 
UDP: from port 53, to port 3500 (decimal)
64 bytes from 128.175.1.3: icmp_seq=538 time=433 ms
64 bytes from 128.175.1.3: icmp_seq=539 time=448 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=546 time=448 ms
92 bytes from BRL.ARPA (26.2.0.29): Source Quench
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 a882   0 0000  fc  01 bd66 c0051708 80af0103 
64 bytes from 128.175.1.3: icmp_seq=547 time=5048 ms	<<< UNUSUAL DELAY
64 bytes from 128.175.1.3: icmp_seq=548 time=4181 ms
Wed Feb  8 18:22:05 EST 1989
64 bytes from 128.175.1.3: icmp_seq=552 time=2381 ms
64 bytes from 128.175.1.3: icmp_seq=553 time=2266 ms
64 bytes from 128.175.1.3: icmp_seq=554 time=2099 ms
64 bytes from 128.175.1.3: icmp_seq=555 time=1866 ms
64 bytes from 128.175.1.3: icmp_seq=556 time=1448 ms
64 bytes from 128.175.1.3: icmp_seq=557 time=999 ms
64 bytes from 128.175.1.3: icmp_seq=558 time=433 ms
64 bytes from 128.175.1.3: icmp_seq=559 time=533 ms
 ... through ...
Wed Feb  8 18:23:58 EST 1989
64 bytes from 128.175.1.3: icmp_seq=662 time=518 ms
64 bytes from 128.175.1.3: icmp_seq=663 time=518 ms
64 bytes from 128.175.1.3: icmp_seq=664 time=499 ms
64 bytes from 128.175.1.3: icmp_seq=665 time=551 ms
64 bytes from 128.175.1.3: icmp_seq=666 time=451 ms
64 bytes from 128.175.1.3: icmp_seq=667 time=418 ms
64 bytes from 128.175.1.3: icmp_seq=668 time=599 ms
64 bytes from 128.175.1.3: icmp_seq=669 time=466 ms
64 bytes from 128.175.1.3: icmp_seq=670 time=566 ms
64 bytes from 128.175.1.3: icmp_seq=671 time=633 ms
64 bytes from 128.175.1.3: icmp_seq=672 time=433 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 aa58   0 0000  fb  01 bc90 c0051708 80af0103 
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 aa64   0 0000  fb  01 bc84 c0051708 80af0103 
 ... 174 more net unreachables deleted ...
64 bytes from 128.175.1.3: icmp_seq=848 time=666 ms
64 bytes from 128.175.1.3: icmp_seq=849 time=833 ms
Wed Feb  8 18:27:14 EST 1989
64 bytes from 128.175.1.3: icmp_seq=850 time=751 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=878 time=833 ms
egp: default of 26.1.0.49 with 318 routes
egp: 83 gwys, 6 int, 77 ext (569 routes).
ip: 591 routes, 15 A, 311 B, 258 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=879 time=918 ms
64 bytes from 128.175.1.3: icmp_seq=880 time=1051 ms
Wed Feb  8 18:27:46 EST 1989
64 bytes from 128.175.1.3: icmp_seq=881 time=818 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=895 time=551 ms
64 bytes from 128.175.1.3: icmp_seq=896 time=851 ms
Wed Feb  8 18:28:02 EST 1989
64 bytes from 128.175.1.3: icmp_seq=897 time=1151 ms
64 bytes from 128.175.1.3: icmp_seq=895 time=3833 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=898 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=899 time=933 ms
64 bytes from 128.175.1.3: icmp_seq=900 time=584 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=1039 time=566 ms
64 bytes from 128.175.1.3: icmp_seq=1039 time=766 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1040 time=748 ms
 ... though ...
64 bytes from 128.175.1.3: icmp_seq=1115 time=748 ms
64 bytes from 128.175.1.3: icmp_seq=1116 time=499 ms
Wed Feb  8 18:31:49 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1117 time=599 ms
64 bytes from 128.175.1.3: icmp_seq=1118 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1119 time=533 ms
64 bytes from 128.175.1.3: icmp_seq=1120 time=699 ms
64 bytes from 128.175.1.3: icmp_seq=1121 time=533 ms
64 bytes from 128.175.1.3: icmp_seq=1121 time=781 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1122 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1124 time=981 ms	<<< MISSING 1123
64 bytes from 128.175.1.3: icmp_seq=1125 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1126 time=548 ms
64 bytes from 128.175.1.3: icmp_seq=1127 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1128 time=614 ms
64 bytes from 128.175.1.3: icmp_seq=1129 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=1130 time=666 ms
64 bytes from 128.175.1.3: icmp_seq=1131 time=681 ms
64 bytes from 128.175.1.3: icmp_seq=1132 time=681 ms
Wed Feb  8 18:32:06 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1133 time=614 ms
64 bytes from 128.175.1.3: icmp_seq=1134 time=514 ms
egp: default of 26.1.0.49 with 276 routes		<<< GATEWAY EGP UPDATE
egp: 88 gwys, 6 int, 82 ext (492 routes).
ip: 514 routes, 16 A, 267 B, 224 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=1135 time=814 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 b1ae   0 0000  fb  01 b53a c0051708 80af0103 
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 b1b3   0 0000  fb  01 b535 c0051708 80af0103 
 ... 73 more net unreachables deleted ...
milr:  msg with link 27 from 4/48		<<< ANOTHER LINK MESSAGE
milr: pack len 2370, format 15, illen 10
Wed Feb  8 18:33:29 EST 1989
milr: incomplete 3/13 4				<<< THESE SEEM MORE COMMON
milr: incomplete 3/13 4				<<< WHEN RESTON IS COMPLAINING
milr: incomplete 3/13 3
milr:  msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
Wed Feb  8 18:33:45 EST 1989			<<< A BUNCH MORE MISSING
Wed Feb  8 18:34:01 EST 1989
milr:  msg with link 27 from 4/48
milr: pack len 2352, format 15, illen 28681
milr:  msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr:  msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr:  msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
milr:  msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr:  msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
milr:  msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr:  msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
Wed Feb  8 18:34:17 EST 1989
milr:  msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
milr:  msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
Wed Feb  8 18:34:34 EST 1989
Wed Feb  8 18:34:50 EST 1989
Wed Feb  8 18:35:06 EST 1989
Wed Feb  8 18:35:22 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1330 time=581 ms
64 bytes from 128.175.1.3: icmp_seq=1331 time=699 ms
64 bytes from 128.175.1.3: icmp_seq=1332 time=614 ms
64 bytes from 128.175.1.3: icmp_seq=1333 time=481 ms
64 bytes from 128.175.1.3: icmp_seq=1334 time=748 ms
64 bytes from 128.175.1.3: icmp_seq=1335 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=1336 time=599 ms
64 bytes from 128.175.1.3: icmp_seq=1337 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=1338 time=499 ms
Wed Feb  8 18:35:38 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1339 time=566 ms
 ... through ...
64 bytes from 128.175.1.3: icmp_seq=1401 time=818 ms
Wed Feb  8 18:36:44 EST 1989
egp: default of 26.1.0.49 with 228 routes
egp: 88 gwys, 6 int, 82 ext (529 routes).
ip: 551 routes, 14 A, 299 B, 231 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=1402 time=848 ms
64 bytes from 128.175.1.3: icmp_seq=1403 time=1199 ms
64 bytes from 128.175.1.3: icmp_seq=1404 time=681 ms
64 bytes from 128.175.1.3: icmp_seq=1404 time=699 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1404 time=1166 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1405 time=514 ms
64 bytes from 128.175.1.3: icmp_seq=1406 time=699 ms
64 bytes from 128.175.1.3: icmp_seq=1407 time=766 ms
64 bytes from 128.175.1.3: icmp_seq=1408 time=881 ms
64 bytes from 128.175.1.3: icmp_seq=1409 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1410 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1410 time=714 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1411 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1412 time=1248 ms
64 bytes from 128.175.1.3: icmp_seq=1413 time=1148 ms
64 bytes from 128.175.1.3: icmp_seq=1414 time=814 ms
64 bytes from 128.175.1.3: icmp_seq=1415 time=933 ms
   ... through ...
64 bytes from 128.175.1.3: icmp_seq=1493 time=884 ms
64 bytes from 128.175.1.3: icmp_seq=1494 time=866 ms
64 bytes from 128.175.1.3: icmp_seq=1494 time=1833 ms	<<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1495 time=1051 ms
64 bytes from 128.175.1.3: icmp_seq=1496 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1497 time=866 ms
Wed Feb  8 18:38:23 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1498 time=618 ms
   ... through ...
64 bytes from 128.175.1.3: icmp_seq=1749 time=718 ms
Wed Feb  8 18:42:44 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1750 time=818 ms
64 bytes from 128.175.1.3: icmp_seq=1751 time=1133 ms
64 bytes from 128.175.1.3: icmp_seq=1752 time=818 ms
64 bytes from 128.175.1.3: icmp_seq=1753 time=1318 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 bba1   0 0000  fb  01 ab47 c0051708 80af0103 
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 0054 bba6   0 0000  fb  01 ab42 c0051708 80af0103 

 ...and the data goes on for roughly three more hours ....

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Feb 89 14:20:19 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Toerless Eckert <mcvax!unido!fauern!faui44!eckert@uunet.uu.net>, tcp-ip@sri-nic.arpa
Subject:   Re: Utilities for nameserver wanted
>I am looking for utilities that can help me with the internet nameserver.
>I would like to have a program that queries the nameserver of different
>zones and generates a /etc/hosts compatible file from the resource
>records, for those hosts in our LAN that can not use the nameserver.
>I am also interested in programs that help creating nameserver
>database files, especially for the PTR records.

I don't worry about the former - I just fetch the "hosts" format lists
from several different domains I'm interested in, plus the NIC hosts list.
I'm anxiously awaiting the day when all our systems will call domain
service instead, though.

I have a number of awk scripts and a small program that you might be
interested in.  I maintain data for my local domain in "hosts.txt"
format, almost identical to that used by SRI-NIC.  A couple of the
awk scripts convert this format to the "/etc/hosts" and "named" formats.
The program, "ndrev", takes the "named" format records and generates "PTR"
entries for hosts in a given (sub-)network.

If you are interested in any of these, take a look at the files in
"src/hostmaint" on serv1.cl.msu.edu.

Doug Nelson
Michigan State University
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 15:49:06 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS" extension


From: jas@proteon.com (John A. Shriver)
>The VMS folks have a real problem.  The binary abstraction of FTP just
>does not hack it for their files.  You will find that they are not the
>only OS that has addresses this, I think the UCLA MVS TCP/IP FTP
>allows you to specify a bit of (moral) JCL before writing a file.
>
>Let's let them agree on something to solve this problem.  Anything to
>make the VMS users less anti-TCP.

Ok, I can live with this but...VMS is a proprietary operating system
managed by exactly one corporation. I hear DEC is supporting or soon
to support TCP on VMS, do they have any proposals in this realm?

If DECNET solves this problem then DECNET over IP might be a better
way to deal with this issue as it simply provides a lower layer for
transport and any changes in the file attributes etc by DEC can be
punted to DECNET support, it can be the only layer aware of such
things and as long as the DECNET packets flow all should be well.

We *are* talking VMS<->VMS communications here, right? And at least
one vendor already offers DECNET over IP, so the only real question is
whether this combination already or could in the near future solve the
problem. I could see an encapsulation standard (RFC) for DECNET/IP as
a way to acheive this in a uniform manner among vendors.

At least that model could lead to dealing with other proprietary
systems and network protocols, as it has in the past (eg. RSCS over
IP, CHAOS over IP, XNS over IP, etc.)

	-Barry Shein, ||Encore||

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 16:00:12 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   IP access control

Who knows if  anything was/is/will be done to permit what DoD people
call "discretionary" access control at the IP level. Forms include
"filtering" based on host identity (address), host membership in a 
discretionary access control group, member of a subnet (perhaps via 
the IPSO and an RSA-like certificate).

I'm told that the new thing for all sorts of access control  problems is 
RSA-like certificates. Hope we can stand the overhead.

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 16:24:17 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Odd FTP Problem

Well Mark, that indeed sounds like a great way to improve the
antisocial behaviour of 4.[23]bsd in the face of ICMP host and net
unreachables.  I looked at the source (ip_input.c, tcp_subr.c,
protosw.h), and it certainly seems that will have the deisred result.

The u_char array inetctlerrmap (in ip_input.c) maps the generic error
types from protosw.h to error numbers from errno.h.  Offsets 8 and 9
are (protosw.h):

#define	PRC_UNREACH_NET		8	/* no route to network */
#define	PRC_UNREACH_HOST	9	/* no route to host */

which are mapped repsectively to (errno.h):

#define	ENETUNREACH	51		/* Network is unreachable */
#define	EHOSTUNREACH	65		/* No route to host */

Entries in that array which are 0 do not cause user errors.  Patching
8 & 9 to zero should do this.

Here's an example.  Be careful to use lower case `w'.

# adb -w /vmunix /dev/kmem
inetctlerrmap?w0				patches disk
inetctlerrmap/w0				patches memory

I have not tried this, no guaruntees.  It looks like this works in
4.3bsd, Ultrix 2.2, and SunOS 3.5.

It still is not the optimal solution, which would be to pass a warning
to the user layer, so they could decide what to do.  I suspect that is
why there is a /* XXX */ at the end of tcp_ctlinput() in tcp_subr.c.
(/* XXX */ is Berkeley shorthand for kludge, should be fixed.)  There
are no comments on the entire subroutine.

Any 4.3bsd gurus out there like to verify this?

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 16:39:06 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   updated sendmail on ucbarpa


We've found a few problems in some of the tcp mailer rulesets that were
included in the recent sendmail distribution on ucbarpa.  They have been
fixed and the distribution updated.  We've also included some additional
documentation on the configuration files as well as some support routines
and include files to make it easier to install under Sun OS and Ultrix.

--keith

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 17:36:45 GMT
From:      campbell@hpbsla.HP.COM (gary campbell)
To:        comp.protocols.tcp-ip
Subject:   Need help with NCSA V2.2 problem

I am having some trouble with NCSA Telnet V2.2.  I have a HP Vectra ES12
(AT compatible) with a 3COM 3C505B (EtherLink Plus) card and a 3C501
card.  The 3C505B is used to talk to a 3 server 386, but I don't have
the 3COM software loaded when I use the NCSA package.  I had the same
problem when the same cards were in a PC/XT.

The problem: I can log in to a HP9000/S320 (hpbsla) on our LAN via
Telnet once just fine.  When I log off and try to log in again, Telnet
says "Reading configuration file...", and then "Console messages",

Trying to open TCP connection to: hpbsla
Local host or gateway not responding

Could not open new connection to: hpbsla

and then ends up saying "entering server mode".  When I press ESC, it
exits to DOS normally.

The hardware configuration of the Thinlan card is:

IO Addr 310
IRQ 7
Shared Memory EC00 (card has bits 19-17,15,14 set, I shifted this value
4 bits to the right to derive the segment address.)

I have a serial/parallel card on COM1 and LPT1  (don't know what IRQs).
The 3C505B is set for shared memory the same except for bit 17 not set
(segment adr CC00), IO addr 300, IRQ 3.

...But it gets worse!!!
I removed the 505B to see if there was some kind of interaction.  There
must be, because now it says "Networked jammed, probable break in wire".
Other computers on my LAN are working, and the cable looks like it's
connected properly.

Any ideas as to what is going on?  What other info would be helpful?  Is
it likely that v2.2c would help?

I would prefer to use only the 3C505B card for both systems.  (They are
both on the same cable.)  Is there any way to make the NCSA package work
with the 3C505B?

Thank you.

Gary Campbell
Internet: campbell%hpbsla@hplabs.HP.COM
UUCP: ....!hplabs!hpbsla!campbell

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 19:20:19 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Utilities for nameserver wanted

>I am looking for utilities that can help me with the internet nameserver.
>I would like to have a program that queries the nameserver of different
>zones and generates a /etc/hosts compatible file from the resource
>records, for those hosts in our LAN that can not use the nameserver.
>I am also interested in programs that help creating nameserver
>database files, especially for the PTR records.

I don't worry about the former - I just fetch the "hosts" format lists
from several different domains I'm interested in, plus the NIC hosts list.
I'm anxiously awaiting the day when all our systems will call domain
service instead, though.

I have a number of awk scripts and a small program that you might be
interested in.  I maintain data for my local domain in "hosts.txt"
format, almost identical to that used by SRI-NIC.  A couple of the
awk scripts convert this format to the "/etc/hosts" and "named" formats.
The program, "ndrev", takes the "named" format records and generates "PTR"
entries for hosts in a given (sub-)network.

If you are interested in any of these, take a look at the files in
"src/hostmaint" on serv1.cl.msu.edu.

Doug Nelson
Michigan State University

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 20:15:40 GMT
From:      woody@SAIC.COM (Robert Allen Woodburn)
To:        comp.protocols.tcp-ip
Subject:   Public domain CMIS/CMIP/CMOT


I have heard that several groups are working on implementations
of CMIS, CMIT, and/or CMOT.  I am working for SAIC teamed with
SPARTA to evaluate network management needs of DDN users and
perhaps compile or even develop a toolbox of network management
tools.  I would be interested in public domain implementations
of any ISO management protocols.

Thanks Much....


wood y

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 21:13:15 GMT
From:      chas@sfc.Wichita.NCR.COM (Charles Binford)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Help using SUN as nameserver

I am trying to use a sun 3/160 for a nameserver on my local net.
I created an /etc/named.boot and /etc/named.db as the man page for
named(8) says, and edited /etc/rc to start /usr/etc/in.named.  All
workes fine for my pc's and other unix boxes I configured to use
the name server.  The problem is I can't get the sun to use itself!
I do not want to have to maintain the nameserver data base PLUS
/etc/hosts on the sun.  The reason I want to use the nameserver is
so I don't have to maintain /etc/hosts.

The sun manuals all seem to assume you are in a network of suns and
are using yellow pages to maintain /etc/hosts.  Of the 30 plus nodes
on our local net, only two are suns.  However, only the suns have
the ability to be a nameserver, all of the other nodes just know how
to use one if it exists. 

I tried creating the file /etc/resolv.conf, but it didn't help.
I would appreciate any information on setting up the sun as a
nameserver, and specifically how to tell it to use itself for
resolving host names.

Charles Binford, Automation Engineering, NCR E&M Wichita
<C.Binford@Wichita.NCR.COM>
<{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!c.binford>
<{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ncrwic!c.binford>

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 89 21:20:42 GMT
From:      bill@VLSI1.CS.CONCORDIA.CA (Bill Atwood)
To:        comp.protocols.tcp-ip
Subject:   4.3 networking in SUNOS 3.5

I would like to rip out the networking software that comes with SUNOS 3.5
(for which I do not have source), and replace it with the networking
software from 4.3 BSD (for which I do have source).  Does anyone have
experience with doing this?  Are you willing to share with me how tough
it was, and what problems you ran into, if any?
Please reply directly to me; I will summarize if enough people express
interest in seeing the result of this enquiry.

Bill Atwood
Concordia University, Montreal
bill@vlsi1.cs.concordia.ca
uunet!sunkisd!vlsi1.cs.concordia.ca!bill

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 00:05:45 GMT
From:      edb@fai.UUCP (Edward Bunch)
To:        comp.protocols.tcp-ip
Subject:   Re: Odd FTP Problem

In article <8902221936.AA10826@ncs.dnd.ca> netcoor@NCS.DND.CA (DRENET) writes:
>We have users on network 128.43 who has reported trouble retrieving
>files from several hosts in the Internet.
>	< 425 Can't build data connection: Connection timed out
>Can anyone explain this? I would sure like to understand what is going on
>to create this situation, then I can try to do something about it.
>
>Bob Bradford				netcoor@ncs.dnd.ca


I saw this same problem here on our WAN. The problem was this. We were trying
to talk to a ethernet interface that was on the other end of the machine.

This is a little difficult to explain. Picture a machine with two interfaces
that we wish to contact to ftp something off. When we start the FTP we 
specify a host address of the interface on the far side. That is packets must
pass through the first interface and then through loop-back before arriving
at ftpd. When FTP trys to build the data connection the reverse way it fails.
ie. Loop-Back --> Other Interface -->  Me.
I suppose FTPD wasn't smart enough to avoid the loop-back network on the return
trip.
Solution: Use the interface address on the near side.

--------------------------------------------------------------------------------
Edward A. Bunch                       UUCP: {uunet,amdahl,sun}!fai!edb
Fujitsu America, Inc.                 DOMAIN: edb@fai.com
Computer Support and Administation.
--------------------------------------------------------------------------------

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 02:06:10 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

> If DECNET solves this problem then DECNET over IP might be a better
> way to deal with this issue as it simply provides a lower layer for
> transport and any changes in the file attributes etc by DEC can be
> punted to DECNET support, it can be the only layer aware of such
> things and as long as the DECNET packets flow all should be well.

    DECnet over IP isn't a replacement for STRU VMS in the Internet
environment. Phase IV DECnet is routing-braindead, limiting the size
of DECnet networks, and requiring great administrative pains to get
large networks to work.

> We *are* talking VMS<->VMS communications here, right? And at least
> one vendor already offers DECNET over IP, so the only real question is
> whether this combination already or could in the near future solve the
> problem. I could see an encapsulation standard (RFC) for DECNET/IP as
> a way to acheive this in a uniform manner among vendors.

    After all the flames I've received about the proposed STRU VMS
extension to FTP, I'm not going to propose our DECnet over IP
encapsulation as a standard. However, I would be more than happy to
share the encapsulation specification with anyone interested in
developing complementary or competing products to MultiNet.

    TGV does not believe that protocols of this nature are
trade-secrets, only the code and associated technology used to
implement them.  This applies to STRU VMS, IP over DECnet, DECnet over
IP, and potentially others.

					      Kenneth Adelman
					      TGV, Incorporated

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 02:11:20 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "STRU VMS" extension

>Ok, I can live with this but...VMS is a proprietary operating system
>managed by exactly one corporation. I hear DEC is supporting or soon
>to support TCP on VMS, do they have any proposals in this realm?

  My impression of things is that TCP is very low priority within DEC
  and that they have a long long way to go before they start worrying
  about this kind of problem.

>If DECNET solves this problem then DECNET over IP might be a better
>way to deal with this issue as it simply provides a lower layer for
>transport and any changes in the file attributes etc by DEC can be
>punted to DECNET support, it can be the only layer aware of such
>things and as long as the DECNET packets flow all should be well.

  Yuck!  Now to solve a very straightforward problem you need to ensure
  that all VMS TCP sites:
	1) Buy DECNET (it is NOT cheap!)
	2) Arrange to be connected (DECNET-wise) into a single accessable
	   DECNET network (even if it IS using IP as the transport).
  Not to mention that the users (who might be transferring some files from
  UNIX workstations and some files from other VMS machines) will have to do
  2 completely different things when they want to transfer VAX/VMS files
  with attributes intact vs moving files to/from hosts running any other
  O/S.

>We *are* talking VMS<->VMS communications here, right? And at least
>one vendor already offers DECNET over IP, so the only real question is
>whether this combination already or could in the near future solve the
>problem. I could see an encapsulation standard (RFC) for DECNET/IP as
>a way to acheive this in a uniform manner among vendors.

  I think that an RFC for DECNET over IP (actually UDP) is a good idea, and
  since we are (as far as I can tell) the only ones who have implemented this
  I guess we should get an RFC out right away.  Note that this DOES NOT
  solve the original problem -- extending FTP to transfer O/S-dependent
  files between cooperating systems in a way that still interoperates
  correctly with OTHER systems.  To this end I think that extending the
  proposed STRU VMS to STRU OS xxx (i.e. STRU OS VMS is a particular
  instantiation) is a valuable contribution to the FTP spec.  The SITE command
  might be more appropriate for this extension -- but the semantics entailed
  in this transfer mode most closely mesh with the semantics of the STRU
  command.

>At least that model could lead to dealing with other proprietary
>systems and network protocols, as it has in the past (eg. RSCS over
>IP, CHAOS over IP, XNS over IP, etc.)
  Again -- tunneling through IP is a most worthwhile thing (and we do this
  quite a bit with our software) but it does NOT address the issue we are
  currently arguing.

					David Kashtan
					TGV Inc.
-------

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 04:38:41 GMT
From:      rjh@cs.purdue.EDU (Bob Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary- FTP c callable functions

Does anyone know of a way to pipe command output?  I'd like to do
something simple like "ls | more", but nothing seems to work.

Thanks,
Bob Hathaway
rjh@purdue.edu

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 1989 12:14-EST
From:      CERF@A.ISI.EDU
To:        jbvb@VAX.FTP.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: What seems to be a glitch in the TCP spec.
James,

thanks for taking time to describe the "glitch" scenario carefully.
The reasoning behind the advice to ignore the "old" packet is
that it isn't clear how old the ACK and WINDOW information is.
We were concerned about disorderly arrivals in which window information
is delivered in reverse of the order sent (e.g. opening the window
and then closing it again). If we follow your rule 4, is there a
scenario in which disorderly arrival leaves A believing the window
is closed when it isn't? Of course, in that case, the probe mechanism
should provide more up to date information. 

In general, the probe is needed - I don;t think there is any debate
on that point. The question is whether your slightly relaxed rules
for processing ACKs and WINDOWs is a net gain or opens the door to
new glitches. Intuition suggests that your "hack" [I don't mean
this in any pejorative sense] probably does more good than harm,
though I confess it feels slightly more pragmatic than my
puritanical attitudes allow me to enjoy.

Let's see what the reactions are from other practitioners.

Vint Cerf
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 16:10:46 GMT
From:      Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695)
To:        comp.protocols.tcp-ip
Subject:   ARP for IP over X.25


Is there any dynamic way of learning the address resolution
for IP over X.25?

I would appreciate it if anyone could give me pointers for
papers or information.

Yuko Murayama
Dept of Computer Science
UCL

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Feb 89 16:10:46 +0000
From:      Yuko Murayama (+44-1-387-7050 ext.3695) <Y.Murayama@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Cc:        murayama@Cs.Ucl.AC.UK
Subject:   ARP for IP over X.25

Is there any dynamic way of learning the address resolution
for IP over X.25?

I would appreciate it if anyone could give me pointers for
papers or information.

Yuko Murayama
Dept of Computer Science
UCL
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 16:35:33 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Terminal servers and 3270 emulation

Morning all...
	Having just read Excelan's announcement for their new terminal server
the thought once again crossed my mind that no one seems to see the need
for these things to try and do TN3270. I get requests from customers every
day for a product like this but it seems that no one has the bugs worked out
yet. I threw this query out on the net almost a year ago, fully expecting a
commercial product long before now. Does anyone know of a box that will do
TN3270 for the dumb terminal user? PLease let me know if anyone has the
inside scoop and I'll try and sumarize the responses to the net.
	THis might be some start-up's road to fame and fortune (:*)
			Chris VandenBerg
			ACC(chris@salt.acc.com)
Standard disclaimer - My employer knows I can't do any REAL damage so they humorme.

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 17:14:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: What seems to be a glitch in the TCP spec.

James,

thanks for taking time to describe the "glitch" scenario carefully.
The reasoning behind the advice to ignore the "old" packet is
that it isn't clear how old the ACK and WINDOW information is.
We were concerned about disorderly arrivals in which window information
is delivered in reverse of the order sent (e.g. opening the window
and then closing it again). If we follow your rule 4, is there a
scenario in which disorderly arrival leaves A believing the window
is closed when it isn't? Of course, in that case, the probe mechanism
should provide more up to date information. 

In general, the probe is needed - I don;t think there is any debate
on that point. The question is whether your slightly relaxed rules
for processing ACKs and WINDOWs is a net gain or opens the door to
new glitches. Intuition suggests that your "hack" [I don't mean
this in any pejorative sense] probably does more good than harm,
though I confess it feels slightly more pragmatic than my
puritanical attitudes allow me to enjoy.

Let's see what the reactions are from other practitioners.

Vint Cerf

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 18:55:57 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Odd FTP Problem (4.3 BSD kernel patches)

[ Stuff about using adb to xero out errors in inetctlerrmap ]

The suggested fix causes 4.3 to ignore ICMP unreachable errors in all
cases, something that one probably does not want to do.  For instance,
I *much* prefer to have telnet attempts abort quickly with a "network
unreachable" than with a "connection timed out" some 60 seconds later.
On the other hand, once a connection has been established, I'd prefer
stray ICMP errors not break a connection.  Moreover, nuking ICMP
unreachable errors weakens utilities like ping that understand such
messages.  One of ping's useful features is the printing of ICMP
errors it receives.

The following patch (perhaps not pretty, but precise) treats ICMP
unreachable errors as before, except that they won't break established
connections.

Thomas

*** /tmp/,RCSt1025442	Sat Feb 25 13:46:58 1989
--- /tmp/,RCSt2025442	Sat Feb 25 13:46:59 1989
***************
*** 258,264 ****
  tcp_notify(inp)
  	register struct inpcb *inp;
  {
! 
  	wakeup((caddr_t) &inp->inp_socket->so_timeo);
  	sorwakeup(inp->inp_socket);
  	sowwakeup(inp->inp_socket);
--- 258,271 ----
  tcp_notify(inp)
  	register struct inpcb *inp;
  {
! 	if (inp->inp_socket->so_state != SS_ISCONNECTING) {
! 	        register int error = inp->inp_socket->so_error;
! 	        if ((error == EHOSTUNREACH) || (error == ENETUNREACH)
! 		     || (error == EHOSTDOWN)) {
! 		        inp->inp_socket->so_error = 0; /* clear error */
! 			return;
! 		}
! 	} 
  	wakeup((caddr_t) &inp->inp_socket->so_timeo);
  	sorwakeup(inp->inp_socket);
  	sowwakeup(inp->inp_socket);

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 89 21:08:51 GMT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: What seems to be a glitch in the TCP spec.

>Consider the following situation:  A TCP connection is carrying
>intermittent, bidirectional traffic.  Host A has just sent a burst
>which filled host B's window.  B has enough data for a small segment,
>piggybacking the Ack and indicating a window of 0.  A replies with an
>Ack, just as B's application consumes the data and B sends a segment
>to re-open the window.  B's implementor has chosen to retransmit the
>first segment of un-acked data (if any) with window updates and Acks
>(B's cost/packet is much larger than the cost/byte).  A's implementor
>has exactly followed pg. 69 of RFC 793, which says to discard segments
>with obsolete data before checking the Ack or Window values.

James:

Did you stumble across this example in an actual case?  It strikes me
that it should not happen under "normal" conditions.  The keyword is
"retransmit".  The above scenario has B piggybacking the window update
on a retransmission.  But this implies 1)  B's retransmit timer has
fired before the ACK for the first transmission has returned, or 2) B,
aware that the cost per packet is higher than the cost per character,
thinks it can get ahead by including some of the already transmitted data.

Case 1 implies the retransmit timer is broken (in which case said
scenario is the least of your worries) or that the transmission path
is lossy (again, probably more serious than the described problem).

Rather than a glitch in the spec, wouldn't this qualify as feature of
case 2?  Which RFCs suggest retransmitting the first segment of
un-acked data (if present) when sending window updates and ACKs?

Thomas

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 89 05:24:44 GMT
From:      rdp@pbseps.UUCP (Richard Perlman)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip 327x controller

I am looking for a 3270 terminal controller that can use a tcp/ip
ethernet as the local (controller to terminal) channel.  I wish to
use IBM PCs and perhaps Macs (FastPath is in place) for the "3270"
terminals.  Access to the VM host is Bisync.

Since I may not be completely correct on my IBM terminology I'll
restate my need another way.  I would like to be able to access our 
VM system from a PC or Mac on our local network and look like a 3270.  
Tcp/ip on the VM is NOT a possibility (wish it were).  A 9.6 bisync 
line is the only option I have.

I have seen Tri-Data's Appletalk based controller, NET-1000 I think,
but it requires TOPS' Appletalk drivers for the PC and TOPS does not
(yet) support the WD8003E ethernet board, which we are using.

Responses by E-mail please.

-- 
Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602,  San Francisco, CA  94105  |*| 1(415) 545-0233

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 89 13:12:00 GMT
From:      jensen%hsr.uninett@NORUNIX.BITNET ("Tarjei T. Jensen")
To:        comp.protocols.tcp-ip
Subject:   FTP "STRU VMS"


        If I were to solve something like this I would create something called
a fil description language. This would enable somebody at the other end to
reconstruct the original file or make a representation of it. It would be human
readable so that people without the facility would be able to find out what to
do. I don't care whether somebody would have to invent a cludge or something to
get this to work gracefully. All I want is for it to work. That means that ftp
probably should know about it (FTP "STRU FDL"?) through some sort of extended
hand-shake sequence. A language like this could probably be used to export and
import data into databases. Below I'll give an example of what I mean. I
suppose one would send the description first and then the file itself. In
certain cases there would have to be a facility to build a binary file from an
ascii representation. E.g. ISAM files. This would be appended to the
description file and fed to someting that would build the right file. I know
this could be a difficult task, but if the description is human readable we can
work something out. The point is to make the description logical, so when the
time is right somebody can make a program that will handle this in a reasonable
manner.

Examples (they do not show everything I would want in a description):

DESCRITPTION
QUOTE="
SEPARATOR=" "
REALNAME="A_NICE_FILE.BCK"
FILETYPE=VMSBACKUP ASCII8 NOPARITY ENCODED COMPACTED CRC=FILE
OPERATINGSYSTEM=VMS_4.7
CPU=VAX
COMPACTID=COMPRESS_6.4
ENCODEID=UUENCODE_1.4
CRC=4AC384D5
SPECIAL BCK
BCK_BACKUPTYPE=IMAGE
BCK_RECORDLENGTH=32768
ENDSPECIAL
REPRESENTATION=EXTERNAL
ENDDESCRIPTION

DESCRIPTION
QUOTE="
SEPARATOR=" "
REALNAME="A.FILE.ISAM"
FILETYPE=ISAM ASCII7 NOPARITY ENCODED COMPACTED CRC=FILE
OPERATINGSYSTEM=SINTRAN_III
CPU=ND110CX
COMPACTID=CPRS_92.4c
ENCODEID=BIGSECRET_MCLXIIV
CRC=32F798FD
SPECIAL ISAM
ISAM_DEFINERECORD_1 "clients"
ISAM_DEFINEFIELD_1 "client name" STRING 80 ASCII8
ISAM_DEFINEFIELD_1 "address" NESTED
ISAM_DEFINEFIELD_2 "address 1" STRING 60 ASCII8
ISAM_DEFINEFIELD_2 "address 2" STRING 60 ASCII8
ISAM_DEFINERECORD_END
ENDSPECIAL
REPRESENTATION=INLINE ATTENTION="ISAM_" ESCAPE="@"
ISAM_RECORD1 NO=1
ISAM_RECORD1 NO=SEQUENCE
ISAM_ENDREPRESENTATION
ENDDESCRITPTION

If you don't like it I understand, but try to find something more portable.
With a description like this it would be easy to import the file into a
database that know about FDL. We would have tools that would generate code to
access the file.

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 89 14:09:52 GMT
From:      schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal servers and 3270 emulation


Chris,

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

PS:  I'm not suggesting you use curses it is only something generally known
--------------------------your message----------------------
    	Having just read Excelan's announcement for their new terminal server
    the thought once again crossed my mind that no one seems to see the need
    for these things to try and do TN3270. I get requests from customers every
    day for a product like this but it seems that no one has the bugs worked ou
    yet. I threw this query out on the net almost a year ago, fully expecting a
    commercial product long before now. Does anyone know of a box that will do
    TN3270 for the dumb terminal user? PLease let me know if anyone has the
    inside scoop and I'll try and sumarize the responses to the net.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 89 15:00:42 GMT
From:      hal@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   IP access control


>   Who knows if  anything was/is/will be done to permit what DoD people
>    call "discretionary" access control at the IP level. Forms include
>   "filtering" based on host identity (address), host membership in a 
>   discretionary access control group, member of a subnet.

I should have added "discretionary access control performed by the
host IP server."  A few well designed gateways have such filtering, 
some quite  elaborate; however, what about host based software.

The IP security option carries "labels", some of which can be used for
access control and others which are  "advisory."  Does anyone know if 
any product will have a clean mechanism for passing these advisory labels
up to an application which can make use of them?

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 89 16:49:29 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: What seems to be a glitch in the TCP spec.


   Solution (4), honoring the ACK and window of a pkt rcvd just to the
   left of the receive window, seems to be the defacto standard.  As I'm
   sure you know, BSD TCP does this.  So do the TCPs developed locally.

   Philip Koch
   (Philip.Koch@Dartmouth.EDU)

If this is the case, I wish that the Sun and HP TCP mungers hadn't chosen to
change their bsd-derived code to exact conformance with pg. 69 of RFC 793.

   From: Thomas Narten <narten@purdue.edu>

   Did you stumble across this example in an actual case?  It strikes me
   that it should not happen under "normal" conditions.  The keyword is
   "retransmit".  The above scenario has B piggybacking the window update
   on a retransmission.  But this implies 1)  B's retransmit timer has
   fired before the ACK for the first transmission has returned, or 2) B,
   aware that the cost per packet is higher than the cost per character,
   thinks it can get ahead by including some of the already transmitted data.

My problem is indeed a real-world one, observable with an X-windows server
running on the PC and communicating with HP-UX 9000/350 and Sun 3/50
X clients.  The Sun is running 3.5, I don't know the HP release, I can
obtain it if anyone (are support people listening?) is interested.

   Rather than a glitch in the spec, wouldn't this qualify as feature of
   case 2?  Which RFCs suggest retransmitting the first segment of
   un-acked data (if present) when sending window updates and ACKs?

Yes, it is a feature of case 2 (I am retransmitting the data before the
timer fires).  There are complicated reasons (most historical, relating
to the PCIP ancestry of the TCP implementation) why it is much easier
to do this, so we always have.  I freely admit to doing something that
wasn't proven (right or wrong) by anyone else, but 793 doesn't tell me
not to, either.

I am willing to accept "don't include window updates or acks with retransmits",
(my solution (2)) if this is the consensus, but I have seen some significant
support for checking the window and ack if the segment is only slightly
obsolete, or even regardless of SEG.SEQ.  Many implementers have faced this
issue, but the answers they chose haven't been published.  I want to air the
issue because we have unhappy users, and the fact that 793 allows the glitch
means that they won't be the last people bitten by it.  We may well have to
implement separate window update segments anyway, just because of relative
company sizes...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 89 17:09:00 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   What seems to be a glitch in the TCP spec.


   From: CERF@A.ISI.EDU

   ....
   We were concerned about disorderly arrivals in which window information
   is delivered in reverse of the order sent (e.g. opening the window
   and then closing it again). If we follow your rule 4, is there a
   scenario in which disorderly arrival leaves A believing the window
   is closed when it isn't? Of course, in that case, the probe mechanism
   should provide more up to date information. 

As I see it, there have always been cases where disorderly arrival of window
updates can leave one host believing the window is closed when it should't.
Consider the unidirectional case:

1.		Seq 100, Ack 200, Data 50, Window 4096 ->

2.	    <-	Seq 200, Ack 150, Data 0, Window 0

3.	    <-	Seq 200, Ack 150, Data 0, Window 50

If 3 arrives before 2, and the sender doesn't have more data ready to go
before 2 shows up, the window looks closed.  Of course, it shrank to get
there, but there are enough TCPs that shrink the window that the sender
will probably manage to deal with it.  Probes will restart the data flow
just fine, but with a glitch.

Part of the problem is that X may be the first widely-used application to
provide a fast, intermittent bi-directional load to TCP.  The remainder is
because PC interfaces have to offer 1-segment windows to survive when talking
to faster hosts.  When the window is 2*MSS or more, this is much less likely
to happen.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 04:03:51 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Odd FTP Problem

Robert,

The Fuzzball logs on net 128.4 and various other places near the NSFNET
Bluebone are also showing unstable routes, sometimes intermittent
ICMP unretchables and other times ICMP time exceededs. The problem has
been growing slowly worse over the last few weeks. Seen from here
one or more of the Fuzzball time servers drops off the Earth only to
replanet a few minutes or hours later. Also, there is a rising tide
of ICMP unmentionables coming from distant gateways, rather than
nearby EGP gateways on ARPANET, so things are certainly unstable somewhere
in space. Finally, the rate of ARPANET error messages, especially to
a few gateways, is growing steadily worse. I conclude PSNs for those
gateways may be sinking slowly in the muck.

This report is certainly much less specific than yours; however, you may
find whatever corroboration useful.

Dave

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 09:48:28 GMT
From:      mcvax!hp4nl!targon!nixvia!mink@uunet.uu.net  (Mink van der Zwan)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP-IP zero checksum

On our Targon31 we use the Pyramid networking code.

In tcp_output the following code is included :

	ti->th_sum = 0;
	if ((so->so_options&SO_NOCHKSUM) == 0)
		if((ti->th_sum = in_cksum(m, sizeof (struct tcphdr) +
					 sizeof(struct ipovly) +
					 (int)optlen + len)) == 0)
			ti->th_sum = -1;

Can anyone tell me why the checksum in the TCP header isn't allowed to
be zero ? I can't find it documented in any RFC. Also I can't find this
conversion back in the tcp_input routine


--------------------------------------------------------------------------------
Mink van der Zwan              UUCP    : mcvax!unido!nixpbe!mink.via 
Nixdorf Computer B.V.  EG4     NERV    : mink.via
Mijlweg 9,  4124 PJ VIANEN     voice   : 31 3473 75154
Netherlands.                   telefax : 31 3473 76504
--------------------------------------------------------------------------------
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 12:32:00 GMT
From:      Hampton@DOCKMASTER.ARPA ("David R. Hampton")
To:        comp.protocols.tcp-ip
Subject:   Re: Odd FTP Problem


    Are the hosts that you are having problems with Berkeley 4.2
systems?  There is a problem with the Berkeley 4.2 FTP server code.
When the 4.2 server opens a data connection, it should performs several
internal steps to get the data connection set up, and then announce the
port number to the client.  In the distributed kernel, it actually
announces the data port before it performs the final step of setup.  If
this final step fails, a 425 error is returned.

David Hampton
Hampton @ Dockmaster.ARPA

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 12:55:07 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  IP access control

I haven't been particularly following this, but I know that Deborah
Estrins Autonets Task Force has been thinking about this stuff.
In particular, she has done some work on what she calls VISAs
which are used to authenticate IP-level packets.

PT

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 14:46:22 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  ARP for IP over X.25

The prior discussion on IP and X.25 left me with the impression that
there is not any scheme now in use anywhere, for *dynamically* learning
an X.121 address corresponding to an IP address given that the source
and destination are both connected to some particular X.25 network.  If
such a scheme does exist, I would be interested in learning about it.

Keith Mitchell suggested a scheme involving passing IP addresses in
the Call User Data field of the call request.  I think he had a
rather different purpose in mind - for the originator to declare
its own IP address.  However, I can imagine a variation of this which
uses an address server whose X.121 address is preconfigured in other
systems.  You would connect to such a server and include the IP address
you want to resolve in the CUD, probably with some protocol identifier
prefix which signals that you are requesting this address resolution
service.  There are probably three ways that could be used to pass back
the answer:

   1) accept the call, send back the X.121 address as data, then clear.

   2) perform the whole operation as a 'fast select' and use a clear with
      data to send back the X.121 address.

   3) use the new 1988 Call Deflection facility to route the call through
      automatically to the right destination, and return a called line
      address modification notification facility to the source for its
      future reference.  This allows the same VC to be used for address
      resolution and for actually communicating.  [According to the best
      locally available rumor, Call Deflection seems to be like call
      redirection, except that it works on a per-call basis.]

It can be argued that if servers are to be built, they should use ES-IS
protocol instead of an ad hoc approach like those above.  This does not
entirely eliminate the need for preconfiguration of at least one
address, since the ES and IS can only communicate on an X.25 network
when one of them has called the other one, which it cannot do without
first having the appropriate X.121 address.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 15:25:50 GMT
From:      VAX1!greggt@tut.cis.ohio-state.edu  (Gregg Thompson)
To:        tcp-ip@sri-nic.arpa
Subject:   TN3270 needed for Unisys running SYSV
Subject says it all. (tried to compile/hack tn3270 to compile, but once
we got it to compile the final compilation and the compiler gave up)



-- 
To live is to die, to die is to live forever;			GRegg Thompson
Where will you spend eternity?			     greggt@vax1.cc.uakron.edu
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 15:41:21 GMT
From:      abe@mace.cc.purdue.edu (Vic Abell)
To:        comp.protocols.tcp-ip
Subject:   Re: Odd FTP Problem

There is another BSD ftpd problem in the very latest post-worm release that
can cause data connection failure.  The connection failure occurs when there
are two, incoming ftpd calls from the same remote peer.  If the two, receiving
ftpd processes both try to open a data connection at the same time, one can
fail with an EADDRINUSE error.  We have fixed this problem locally by adding
a retry loop in ftpd.c's getdatasock() function.

The released ftpd lacks this loop.  It also may be reporting the cause of
data connection failures improperly when they result from an error in the
bind() call within getdatasock().  There are several function calls between
the bind() and the reply() call that can change the value of errno.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 18:34:45 GMT
From:      rick@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal servers and 3270 emulation

This is off the original subject of availability of forms-oriented
terminal servers, but I thought I'd agree with Marty about a
terminal description server...

You are correct about the exchange of curses-type information
not being covered in the ISO VT standard.  It's generally considered
that this is only useful for the mapping of VT updates to a specific
terminal type, and is therefor a "local" rather than a "peer to peer"
protocol matter. The VT standard only defines communications between
2 peer VTs and doesn't have an idea of a terminal description server.

I suppose in the ISO world the proper way to look at this may be to
register the terminal information in the directory. (could a name
domain record type be devised for this?)  This may take
care of the need for a protocol to distribute the info, but it definitely
still requires standards for the format of the information. Maybe there
needs to be more than one format for different terminal classes
(possibly screen-oriented ala curses, forms-oriented, and graphics).

This kind of information might be used by a variety of clients:

1. terminal servers, as you suggested

2. TELNET or ISO VT client programs.  This would be to help them
map either generic VT updates to a physical terminal, or one type
of data stream (ie. 3270) to another (ie. async dumb terminal).

3. applications that want to control terminals directly.
This, of course,contradicts the VT idea that anything being sent across
a network to a terminal should be in a standard (device-independent) format.
On the other hand it is exactly what happens when someone telnets
to a remote unix box and fires up "vi".  A well designed, standard
representation (or set of representations)
for the terminal capability data may just expand this
approach beyond curses/termcap/terminfo.  Wasn't there a project some
years ago at Berkeley to define a termcap-like description for
graphics terminals? Anybody know about it?

By the way, it's not yet clear what method of supporting 
forms-oriented applications will be popular using ISO VTP.  
There is a FORMS VT profile defined by the NIST OSI workshop,
but some favor the idea of sending 3270 data streams through
a "transparent" VT (ala tn3270). Here at MITRE we have a prototype of a 
VT FORMS implementation and are looking for someone to test
interoperability with. This implementation uses curses to map
VT FORMS updates to async. terminals.

-Rick Wilder (rick@gateway.mitre.org)
 

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 19:53:39 GMT
From:      david@uhccux.uhcc.hawaii.edu (David Lassner)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Novell Net with Telnet & FTP

We're interested in putting together one or more Novell
networks with PC and PS/2 type machines.  And we want each
machine to also be able to telnet and ftp out to our campus
network (ProNet-80).  We know that at least Excelan and U-B
offer hardware/software solutions for this.  Any other
vendors we should be checking with?  Any opinions or horror
stories will be appreciated.  We're a public university and
are especially interested in site license deals that don't
nickel and dime us on each workstation.  Are there any
cards that are supported for simultaneous use of the Novell
network OS and NCSA Telnet or other free TCP/IP software?
-- 
David Lassner, University of Hawaii Computing Center, 808/948-7351
INTERNET: david@uhccux.uhcc.hawaii.edu      BITNET: david@uhccux

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 89 20:00:51 GMT
From:      haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@ames.arc.nasa.gov  (Tony Nardo)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Odd FTP Problem
In article <MS-C.604267100.377401575.mrc@SUMEX-AIM.Stanford.EDU> mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) writes:
>
>     I've seen this problem in other forms.  Apparently there are a lot of
>"ICMP Destination Network Unreachable" messages getting sent in instances
>where network connectivity is broken for only a brief duration (perhaps due
>merely to congestion at a gateway).

Considering that I've seen this one crop up at 6:40am EST on a Monday, and at
other times even more unlikely to have high traffic (02:00 am EST on a Friday
night/Saturday morning), I'd doubt if gateway conjestion is the sole culprit.

>     Some versions of BSD Unix nuke the connection when this or "host
>unreachable" occur; it is reputed that patching location _inetctlerrmap+8 in
>the kernel from 0x3341 to 0x0 remedies this problem but I haven't been able to
>verify it.

This might help cover up the problem, but it doesn't really solve it.  What
can you do when the "host unreachable" condition persists for several minutes?
Several hours?
-------				----------------			-------
ARPA,	trn@aplcomm.jhuapl.edu,		UUCP:	{backbone!}mimsy!aplcomm!trn
BITNET:	trn@warper.jhuapl.edu

	    "Thank God I'm only watching the game, controlling it."
				"One Night In Bangkok" (_Chess_)
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 1989 04:56-EST
From:      CERF@A.ISI.EDU
To:        jbvb@VAX.FTP.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: What seems to be a glitch in the TCP spec.
James,

thanks for the example - indeed, it is that sort of situation which
led us to introduce probing behavior, among other things.

What's your view of the proposed special case check?

Vint
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 89 10:57:55 GMT
From:      mcvax!kth!enea!maxim!prc@uunet.uu.net  (Robert Claeson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Terminal servers and 3270 emulation
In article <8902271834.AA01285@mars.mitre.org>, rick@GATEWAY.MITRE.ORG writes:

> A well designed, standard representation (or set of representations)
> for the terminal capability data may just expand this
> approach beyond curses/termcap/terminfo.  Wasn't there a project some
> years ago at Berkeley to define a termcap-like description for
> graphics terminals? Anybody know about it?

Is it really possible to handle all kinds and types of terminals via
table descriptions? I suspect that an implementation based on drivers
for different terminal types would be able to make better use of the
terminal's capabilities.

-- 
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
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 89 11:46:56 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   HP3000 Enet MAU Choices and pinouts

For connecting HP3000s, (MPE V) to ethernet, has anyone found ANY DEC, TCL
or other MAUs which perform properly for getting to thich or thin lan ?

Can anyone tell us what the cable signals are?  Appear NOT to JUST be RETN,
COLL, TXD, RXD, PWR for nine pins.  Are signal condition to no signal 
conditions different than for those of us used to common ethernet 802.3 as
offered by DEC, TCP, etc. ?


-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
    efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Feb 89 21:45:54 PST
From:      Van Jacobson <van@helios.ee.lbl.gov>
To:        tcp-ip@sri-nic.arpa
Subject:   4BSD routing diagnostic tool available for ftp
Traceroute, a Berkeley Unix (4.xBSD) tool that can help debug
some network routing problems is available for anonymous ftp
from host ftp.ee.lbl.gov (128.3.254.68), file traceroute.tar.Z
(a compressed Unix tar file -- ftp it in binary mode).
Unfortunately, you will have to hack your kernel slightly to use
it (there's a README that gives a modified
/sys/netinet/raw_ip.c:rip_output that's known to work on
4.[23]bsd and Sun OS [34].x.)

If this sounds useful and you feel comfortable with the kernel
hacking, help yourself.  

 - Van
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 89 15:16:42 GMT
From:      mailrus!sharkey!atanasoff!deimos.cis.ksu.edu!eecea!terry@tut.cis.ohio-state.edu  (Terry Hull)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Novell Net with Telnet & FTP
In article <3343@uhccux.uhcc.hawaii.edu> david@uhccux.uhcc.hawaii.edu (David Lassner) writes:
>We're interested in putting together one or more Novell
>networks with PC and PS/2 type machines.  And we want each
>machine to also be able to telnet and ftp out to our campus
>network (ProNet-80).  
Micom has a gateway product based on their NP600 Ethernet board.  I have
one connected to a Convergent Technologies S/640.  The telnet feature works - 
mostly.  The only problem is the gateway occasionally hangs and the board must 
be reset.  While logged in on the Novell, you can ftp files from the
Convergent, but you cannot send files over 4K to the Convergent.  All
of the "r-commands" rwho, rsh, ruptime do not work.  The gateway has
SMTP capability, but I have not had the opportunity to test that yet.
(The Convergent came without a mailer capable of SMTP.)  The last
problem is the board is very expensive at $4000.  

I have the gateway installed and working in the net now, but I am
certainly not thrilled with the product.  

-- 
Terry Hull                    Department of Electrical and Computer Engineering
                                           Kansas State University
INTERNET: terry@eecea.eece.ksu.edu          Manhattan, KS  66502 
UUCP: rutgers!ksuvax1!eecea!terry
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 89 18:58:00 GMT
From:      mentor.cc.purdue.edu!mace.cc.purdue.edu!abe@purdue.edu  (Vic Abell)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Odd FTP Problem

There is another BSD ftpd problem in the very latest post-worm release that
can cause data connection failure.  It occurs when there are two, incoming
ftpd calls from the same remote peer at nearly the same time.  When the two
receiving ftpd processes both try to open a data connection, one may fail
with an EADDRINUSE error.  I have fixed this problem locally by adding a
retry loop in ftpd.c's getdatasock() and have reported it to Berkeley.

The released ftpd may also report the cause of data connection failures
improperly when they result from an error in the bind() call within
getdatasock().  There are several function calls between the bind() and the
reply() calls that can change the value of errno.
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 89 23:22:18 GMT
From:      leonard@cod.nosc.mil  (Norman Leonard)
To:        tcp-ip@sri-nic.arpa
Subject:   ping info

	I am a technician at NOSC SD and have recently become involved with
ethernet installation and maintenance which I am learning as I go.  I have
a HP 4792A lan analyzer which I would like to use to ping various hosts on
the net and monitor their response using the analyzer as the source.  To this
end I have captured a ping package between two unix hosts on the net and mod-
ified the the source ethernet address to reflect the analyzer's address and
at the same time have modified the source IP address to one given me by the
unix administrator for the lan analyzer.  At this point I have assumed I have
made the necessary changes for the analyzer to act as the source for the ping
package and that the unmodified destination host would respond to the analyzers
ping package, but it has not.  Am I incorrect in my modification of the ping
package or is there some other area that I am overlooking?  Any help or suggest-
ions would be appreciated.  I also would like any suggestions regarding sources
for basic tcp/ip concepts and structure. 

END OF DOCUMENT