The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for December 1984 (52 messages, 23064 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      Tue 4 Dec 84 11:42:33-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        louie@UMD5.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SMTP Max recpients reply code
In my admittedly biased opinion, the mention of 552 in the SMTP
specification is a bug in the specification.  It should be 452.
I would interpret 552 as meaning "too many people on this site
have gotten this message, do not send it to any more people" as
opposed to 442 which would mean "too many addressees in this
SMTP transaction, please send this message to this addressee in
another transaction."

I'm pretty down on SMTP servers which place limits on the number
of recipients.  Many of them actually deliver the message to each
recipient at the end of the transaction, forcing the SMTP sender
to wait (and wait) for the acknowledgement to come back that the
DATA command completed.  I feel a superior approach is to queue
the list of recipients and the message to some mailer process and
get the SMTP connection out of the way as soon as possible.  This
has the side effect of maximizing SMTP throughput.
Date:      4 Dec 1984 12:04:53 PST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   SMTP max recipients reply code


It has been suggested before that the reply code for "too many recipients"
should be 452 (i.e., a temporary instead of permenant error). This would
mean changing the second to last line on page 43 and the example on page
63 of RFC 821.  I suggest that you go ahead an change the UMD2 system to
return the 452 code.  Let us know if that results in any further problems.

Date:      Tue, 4 Dec 84 13:45:24 EST
From:      louie@umd5 (Louis Mamakos)
To:        tcp-ip@sri-nic
Subject:   SMTP Max recpients reply code
I'm so confused..  I observed a strangeness in the interaction between
UMD5.ARPA (PDP 11/44 2.9BSD UNIX, running sendmail) and UMD2.ARPA (Sperry
1100/82, with our own IP/TCP networking code).  UMD5's sendmail was attempting
to deliver mail to multiple recpients on UMD2.  When the local recpient 
storage space filled up, UMD2 returned a '552 Max recpients' reply to
UMD5's sendmail for each of the remaining recpients, which marked each of
the remaining recpients as perm failures.  This caused an  advisory message
to be generated for those recpients rather than another SMTP transaction to
be attempted.

When I implemented the SMTP server on the Sperry (UMD2) system, I decided to
return the 552 reply in this case, rather than the 452 reply since that
agreed with the example scenario in RFC 821 on page 63.  Sendmail looks
like it might work if this reply is changed to a 452, but I haven't gone
too deep in the code to make sure (and I'm not sure I want to if I can
avoid it).

So the questions are: Is sendmail on UMD5 broken?  Is the SMTP server on
UMD2 broken?  Are they both broken?  Should I use Federal Express instead?

Louis A. Mamakos
Computer Science Center - Systems Programming
University of Maryland, College Park

UUCP: ..!seismo!cvl!umd5!louie
Date:      Wed, 5 Dec 84 12:09 PST
From:      Provan@LLL-MFE.ARPA
Subject:   bug in UNIX telnet
I've run into a bug in UNIX telnet several times, and I'm wondering if
there's any awareness of it in the TCP-IP club.  I won't go into great
detail, but the problem is that UNIX sends <LF> when the user types the
return key.  With most systems in the ARPAnet, this causes no problem,
but we have a particular application where it is unacceptable (<LF>
means something different than <CR><LF>).

There's a fix to UNIX Telnet that solves this problem around.  It's
apparently a trivial one, but I can't remember just now who has it.  The
site we're currently having trouble with is ORNL-MSR.  Could someone get
the fix to them?  Is there any chance of this being fixed more
universally?  I get tired of hearing about the same bugs over and over.
Date:      Thu, 06 Dec 84 08:38:58 EST
From:      Dennis Rockwell <drockwel@CSNET-SH.ARPA>
To:        Tom Daniel <tom@UCL-CS.ARPA>
Cc:        Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: bug in UNIX telnet
Gee, I was hoping to stay out of this...

I do indeed have a version of user telnet for 4.2 that behaves correctly
when talking to the UCL TG (which switches back & forth between local and
remote echo), which requires all the right things to happen at end-of-line.
This version works *much* better when you're using telnet to talk to an SMTP
server (or other local-echo netascii server) because it stays in cooked mode
when doing local echo (thus, local line-editing works).

It also implements word mode (transmit on non-alphanumeric or timeout); I
put this in for use over low-bandwidth, high-delay, or charged nets (like
X.25, which is all of the above).  It cuts the packet count considerably,
and perceived performance is better.  This helps when using lossy gateways
as well.

If there's enough demand, I can probably make it available.  I'll soak up
requests for a while and see.

Distribution will probably have to be in the form of a diff listing due to
license hassles.

Dennis Rockwell
CSNET Technical Staff
Date:      Thu, 6 Dec 84 14:36 EST
From:      Henry Nussbacher <HJNCU%CUNYVM.BITNET@Berkeley>
To:        <tcp-ip@sri-nic.ARPA>
Can you please register the following user in your list:

Thank you,
Henry Nussbacher
BITNET Network Information Center
Date:      Thu, 6 Dec 84 10:44:51 GMT
From:      Tom Daniel <>
Subject:   Re:  bug in UNIX telnet
Yes I have come across this bug on a couple of hosts when
people were trying to acess the Terminal gateway at UCL. The
TELNET in the TG works line at a time and is very particular
about end of line being CRLF or CRNULL thus these
implementations wont work. One of the hosts was CSNET-SH and I
believe the person who fixed ithe problem there was Denis
Rockwell - drockwel@csnet-sh

                Tom Daniel

Date:      Thu, 6 Dec 84 21:32:06 EST
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        Provan@LLL-MFE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  bug in UNIX telnet
UNIX telnet (I assume you mean the BSD one since there really isn't
any others) has a number of bugs.  First there is buffer boundry
condition in the server that causes characters to be thrown away
when dealing with large quantities of output.  Second the server
handles "Are you There" by sticking a bell in the input stream.
Third, the user program sends out not linefeed when you type return
but CR-NUL rather than CR-LF.  This causes problem with some sites
and makes it difficult to use telnet to debug other things like the
mail system.  If you still need the new versions, I could send you
our locally enhanced version that also includes an option for local
flow mode.

Date:      7 Dec 1984 1708 PST
From:      Ron Tencati <TENCATI@JPL-VLSI.ARPA>
To:        tcp-ip@sri-nic
Subject:   Implementing GATEWAYS
Hello again,

As Christmastime approaches, I find it that it is time for my monthly
network inquiry. This month's topic is GATEWAYS. 

I am trying to come up with some kind of scheme whereby I could network
together some computers here at JPL via some kind of Local Area Net, and
then gateway those computers to the ARPANET. 

Currently, there is a broadband Ungermann/Bass LAN installed at the Lab.
One method would be to net some machines together on this LAN, and put one
of them onto the ARPANET to act as the gateway.  Another idea is to
implement some other kind of network for the LAN, and then do the gateway.

I am seeking information (general and technical) from persons who have
implemented LANs with ARPA gateways at their facilities.  In general, I'm
interested in types of configurations that are being used, and your
experiences with them. I would also appreciate getting a feel for how
traffic affects the gateways, as well as a feel for an implementation
estimate with respect to manpower, software, time, and resources that were
needed to implement your particular configuration. 

Our initial configuration will probably be all VAXes, but we would like to
plan a LAN/GATEWAY that is flexible enough to support many different CPUs
on the same LAN.

If you'd rather not clog up the mailing list with replies, feel free to 
send them directly to me.

Thank you for any help/info/assistance anyone can send my way.

Ron Tencati
Tech. Liaison
Date:      Sat 8 Dec 84 04:14:26-PST
From:      Ken Harrenstien <KLH@SRI-NIC.ARPA>
To:        ron@BRL-TGR.ARPA, Provan@LLL-MFE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA
Subject:   Re:  bug in UNIX telnet
There is definitely another bug in UNIX telnet, at the other end -- the server.
If you connect to a 2.9 or 4.2 BSD system, and do something that generates
a lot of terminal output, you will see short glitches every so many lines
where a string of characters is output twice.  It looks something like
thiut twice. It looks something like this.  Output doesn't seem to be
lost, but it iseem to be lost, but it is definitely annoying, especially if you are trying to look at
an otherwise nicely formatted table (or paragraph!)

I doubt it is a problem with TCP retransmitting (and resequencing!)
output, because I have done massive FTPs without problems.  The
culprit is probably either in the Telnet server buffering code, or the
UNIX pseudo-TTY kernel code.  This may be the same thing that Ron Natalie
mentioned, although he says output is dropped, whereas this bug
manages to repeat a chunk of text.  Granted, unless you look carefully
you will immediately assume subtraction instead of addition.

I am sure this has been fixed somewhere, but it seems to be the nature
of things that such fixes are rarely distributed where they should be.
This is one service that lists such as TCP-IP can perform.
Houch as TCP-IP can perform.  How about it?
Date:      8 Dec 84 1:18:13 EST
From:      DonWinter.pasa@XEROX.ARPA
To:        Postel@USC-ISIF.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, DonWinter.pasa@XEROX.ARPA
Subject:   IEEE 802.3 vs. IP Datagram on Ethernet

IEEE 802.3 redefines the "Type" field of an Ethernet packet as "length"
for values from 0000H to 05FFH. Values of 0600H and greater are
available for other uses. This clears Xerox NS packets, since they have
a "Type" value of 0600H. However, IP Datagrams have "Type" value 0400H,
and thus cannot co-exist with IEEE 802.3 packets on the same Ethernet.
(The same is true of the earlier Xerox PUPs.)

What impact does this have on the burgeoning number of Ethernet-based
LANs out there in TCP/IP land, and what would be the reaction to an
attempt to change the legal "Type" value of IP Datagrams to a value
greater than 0600H?

Date:      8 Dec 1984 0757-PST (Saturday)
From:      lou@aero3 (Lou Nelson (ISRO))
Cc:        tcp-ip@sri-nic, sills@aero1, crocker@aero1, gal@aero1, lou@aero3
Subject:   Re: Implementing GATEWAYS
>Date: 7 Dec 1984 1708 PST
>From: Ron Tencati <TENCATI@JPL-VLSI.ARPA>
>Subject: Implementing GATEWAYS
>To: tcp-ip@sri-nic
>I am trying to come up with some kind of scheme whereby I could network
>together some computers here at JPL via some kind of Local Area Net, and
>then gateway those computers to the ARPANET. 
>Currently, there is a broadband Ungermann/Bass LAN installed at the Lab.
>One method would be to net some machines together on this LAN, and put one
>of them onto the ARPANET to act as the gateway.  Another idea is to
>implement some other kind of network for the LAN, and then do the gateway.
>I am seeking information (general and technical) from persons who have
>implemented LANs with ARPA gateways at their facilities.  In general, I'm
>interested in types of configurations that are being used, and your
>experiences with them. I would also appreciate getting a feel for how
>traffic affects the gateways, as well as a feel for an implementation
>estimate with respect to manpower, software, time, and resources that were
>needed to implement your particular configuration. 
>Our initial configuration will probably be all VAXes, but we would like to
>plan a LAN/GATEWAY that is flexible enough to support many different CPUs
>on the same LAN.
Here at Aerospace in El Segundo, we have been running three
LANs connecting VAXes, Apollos, Dolphins, an Alto, PDP11
gateways, and IBM PCs for a while now.  Our backbone net is
a Proteon proNET that serves as the inter-building medium
and all 4 VAXes and the 2 PDP11/23 gateways are connected to
it.  The primary gateway is the AERONET-GW host in the NIC
host table and it connects the Aeronet, 192.5.9, to the
MILNET, 26.  The gateways run the standard BBN Internet
gateway code, GGP I think.  I haven't really kept track so
we may be running EGP by now. We also have two
intra-building Ethernets; one is connected to the backbone
net via another gateway and the other is not officially
connected at all, but in practice is connected via a VAX.  I
won't go on at length about this but would rather encourage
you to call and/or visit for a tour.
Lou Nelson
(213) 615-4424
Date:      Sat, 8 Dec 84 7:38:37 EST
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject:   Re:  bug in UNIX telnet
I believe I mentioned that bug.
The problem is with when the buffer totally fills, i.e. you are catting                 a big file, every 1024th char gets dropped.  If you repetatively cat
/usr/pub/ascii (all the lines are the same length) you'll see that every
20 lines or so is missing a character.  Actually, I've got a telnet for
4.2 that has these fixed, and a much nicer telnet for 4.1 that includes
transcript mode, the ability to send things like AYT, AO, IP, etc...,
flow mode and the ability to set these from the command line.  If anybody
wants these for 4.1 or they want to convert them to use the 4.2 network
calls and give them out, they are welcome to them (I don't have time right
now to do this).

Date:      Monday, 10 Dec 1984 10:00-PST
From:      imagen!
To:        shasta!DonWinter.pasa@XEROX.ARPA
Cc:        shasta!TCP-IP@SRI-NIC.ARPA
Subject:   Re: IEEE 802.3 vs. IP Datagram on Ethernet

I beg to differ, the type of Internet datagrams is 0x800 (800 hex),
and fits in with the IEEE 802.3 loophole nicely.

In the recent ``XNS Implementors Group'' meeting, one of the Xerox
people discussed this problem.  The discrimination algorithm is:

	if ( ieeeheader.length > ethMaxLength ) then
		interpret as Ethernet type field
		interpret as IEEE packet

This does not solve the problem of the IEEE 802.3 header not having a
type field, that is, of how to figure out what protocol header is next
in the packet.  The Xerox people at the XNS group said that xerox will
continue to manage type numbers for the immediate future, and will
allocate them to make this algorithm work.  However, they acknowledged
that this was useful only during the transition to IEEE 802.3, and was
not an ultimate solution to the problem.

There are two non-xerox-internal type fields that have been assigned
that don't work with this algorithm.  One is PUP (sorry to Stanford),
which is 0x200, [I think], and the other was assigned to some
unmentioned private organization.  Both of these will be reassigned in
the future.

The xerox people also indicated that they consider IEEE 802.3 to be
the `next release' of the Ethernet spec, and intend to switch to it. 

- Geof
Date:      Mon 10 Dec 84 15:31:23-EST
From:      J. Noel Chiappa <JNC@MIT-XX.ARPA>
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: Implementing GATEWAYS
	To add to what someone else just said, Proteon (mfrs of
Pronet, with whom I am associated) are also going to be offering a
gateway product based on the MIT CGW (which has been in service for
several years at MIT and Stanford); this code can handle up to 280
packets/second running on an 11/23; a considerably faster MC68000
version is under way. People who want more details should contact
Proteon at (617)-655-3340 (or me if they want real technical details).

Date:      Mon 10 Dec 84 15:58:40-EST
From:      J. Noel Chiappa <JNC@MIT-XX.ARPA>
To:        DonWinter.pasa@XEROX.ARPA, Postel@USC-ISIF.ARPA
Subject:   Re: IEEE 802.3 vs. IP Datagram on Ethernet
	It is technically possible to switch to a different field,
albeit quite painful due to the extremely large number of machines
deplayed in the field (probably way over several thousand by now).
For easiest implementation there would be three stages: a) in which
all existing software has to be taught that the new number exists
to recognize it on input, b) in which this number is generated by
default on output, and c) recognition of the old number as an IP
packet is deleted to allow it to be used as a length.

	The questions I have so far heard no commentary on involve how
this new length field is supposed to fit in. For instances of the new
style header, will multiple protocols on a single wire be supported?
Did the people writing the spec even consider this?  Will it be done
by a new 'type field' after the existing header? Will the the format
of this field and the numbers in it be a standard? What mechanism will
a host use to decide whether to send, say, an IP packet in the 'type'
format or the 'length' one? Will people build hardware that recognizes
and uses the length field? What will it do when given a header without
a length field? Since the hardware has to work without a length field
anyway, what use is adding hardware to use it? Why couldn't people put
a length field in the protocol header if they needed one? If people
build hardware that generates a length field, will it be possible to
supress this insertion to use type codes instead?
	I could go on but you get the idea. I try not to flame much
any more, but I have got to say that this 'Length' bit is one of the
stupidest ideas I have heard in 8 years of building network hardware
and software. With any luck the marketplace will laugh it off;
however, the IEEE's extremely foolish action in promulgating this
drivel may well stick. God help us all.
Date:      Mon, 10 Dec 84 17:34:10 CST
From:      Mike Caplinger <mike@rice.ARPA>
To:        tcp-ip@nic.ARPA
Subject:   "all messages" data in RFC 918
Is there any standard way of separating messages transmitted in a big
blob, as in response to a RCEV command?  Perhaps it would be better to
use a Grapevine-like primitive to read a single message, rather than
receiving all available messages at one go.

A (possibly crude) user interface based on the single-message per
transaction would be easier to write, too.

	- Mike
Date:      10 Dec 1984 2317 PST
From:      Ron Tencati <TENCATI@JPL-VLSI.ARPA>
To:        tcp-ip@sri-nic
Cc:        info-vax@sri-kl
Subject:   Gateway Information

I want to thank all the people who are responding to my inquiry into gateways.
The information I am getting is quite informative.  This week, I will be
at DECUS and will be unavailable.  Next week, I will follow up on the msgs
I am recieving.  Keep those cards and letters coming!

Thanks again,

Date:      Tue, 11 Dec 84 17:20 EST
From:      Mike StJohns <StJohns@MIT-MULTICS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   expansions to FTP spec

Is there any interest in expanding FTP to handle LINE and RECORD
oriented file transfers?  What I mean by this is the ability to open a
remote file and transfer only specific portions of the file, rather than
the entire file.  I see at LEAST the following commands being added to
handle this.

 OPMD - Open Mode, read, write, or read/write (append?)
 OPEN - Actually open the file and connect to the currently
        specified data port.
 POSN - Depends on type of file, could be a key seek, relative or
        absolute position.  Depends on TYPE of transfer.
 READ - Read one line (or record) from the file and throw it at the
        data port.
 WRIT - Grab a line (or record) of data from the data port and write
        it at the current position in the file.
 CLFL - Close file. Housekeeping.

This would be the beginnings of a standardized distributed database
system (well, at least some of the primitives needed to implement one)

Mike .
Date:      Tue, 11 Dec 84 19:24:00 EST
From:      Doug Kingston <dpk@BRL-TGR.ARPA>
To:        Mike StJohns <StJohns@MIT-MULTICS.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  expansions to FTP spec
	Your ideas for an expanded file access service have merit,
but DO NOT add it to FTP.  The range of file access services required
should be completely thought out and a NEW service defined and
implemented. I suggest that a virtual file system interface be defined,
and a set of remote procedure calls be defined upon it.  Include
locking and whatever other facilities you might want.  FTP is not the
place to start adding things. You might even call this new service
"CFTP", for ...

		"Complex File Transfer Protocal"!

					FTP Preservation Committee

PS. There is a great deal of active work on remote procedure call (RPC)
    interfaces, particularly for communications between UNIX systems
    across TCP connections, but not limited to such connections.
    The basic RPC mechanism for most of these would easily adapt to
    that addition of other RPC types, mapping to expanded services,
    such as keyed file access.
Date:      Tue 11 Dec 84 19:39:24-EST
From:      J. Noel Chiappa <JNC@MIT-XX.ARPA>
To:        StJohns@MIT-MULTICS.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: expansions to FTP spec
	What you really want is a file access protocol, not a file
transfer protocol. Several have been proposed and at least one
Date:      12 December 1984 05:36-EST
From:      Christopher C. Stacy <CSTACY @ MIT-MC>
To:        TCP-IP @ SRI-NIC
Subject:   Unix host table software query
Could anyone please send me information on C programs to compile an
RFC810-style host table for 4.2 Unix systems?

Date:      12 Dec 84 10:29:12 PST (Wednesday)
From:      Lansford.PASA@XEROX.ARPA
To:        Mike StJohns <StJohns@MIT-MULTICS.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: expansions to FTP spec
"This would be the beginnings of a standardized distributed database
system (well, at least some of the primitives needed to implement one)"

While random access to a remote file is a very useful thing to have, FTP
is an inappropriate protocol to use to achieve this.

Date:      13 Dec 1984 15:47-PST
From:      Postel@isif
Subject:   "all messages" data in RFC 918

Mike Caplinger:

We are working on a revised PoP specification that includes a
detailed description of the message separator.

Date:      Fri 14 Dec 84 05:40:31-PST
From:      Ken Harrenstien <KLH@SRI-NIC.ARPA>
To:        ron@BRL-TGR.ARPA
Subject:   Re:  bug in UNIX telnet
Sorry, but it's clear that the bug you mentioned is not the one I am
talking about.  I have not seen the char-drop bug.  What I see is
short segments of text that are REPEATED.  This happens on a 4.2BSD
system (SRI-TSCA).  Someone mentioned that this was a 4.1 and 2.8
problem with TCP that was supposedly fixed by 4.2 and 2.9.  That
obviously is not the case either.  Isn't there anyone out there who has
also seen this happen when telnetting to such a system?
Date:      Fri 14 Dec 84 06:38:23-PST
From:      Witold Paluszynski <Witold@WASHINGTON.ARPA>
Cc:        ron@BRL-TGR.ARPA, Provan@LLL-MFE.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  bug in UNIX telnet
The bug you are talking about must be really common as I used
to see it quite often (like once in 4 telnet sessions).
Just as you said, some portion of output is repeated.
It is 4.1 telnet server that must be at fault.  I can't
be sure if I saw it with 4.2.  I seem to recall other people
here confirmed having seen it too when I reported this.

Date:      Friday, 14 Dec 1984 09:34-PST
From:      imagen!
To:        shasta!KLH@SRI-NIC.ARPA
Cc:        shasta!tcp-ip@SRI-NIC.ARP
Subject:   Re:  bug in UNIX telnet


Yes, I too have seen the bug that you mentioned, where characters are
replicated in the telnet input stream.  I get it telnetting to our 4.1a
system.  It appears to happen when a packet is lost, from the delays on
the typeout.  I seem to remember the old BBN 4.1 code doing the same
thing about two years ago.  I seem to remember a new release from BBN
that fixed the problem, about two years ago; the Berkeley code had
diverged by then.

Anyone out there on TCP-IP remember the bug fix?

- Geof
Date:      Fri, 14 Dec 84 14:27:26 EST
From:      Dennis Rockwell <drockwel@CSNET-SH.ARPA>
To:        imagen!geof@SU-SHASTA.ARPA
Cc:        KLH@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: bug in UNIX telnet
	From: imagen!geof@SU-SHASTA.ARPA
	Subject: Re:  bug in UNIX telnet
	Date: Friday, 14 Dec 1984 09:34-PST

	Anyone out there on TCP-IP remember the bug fix?

	- Geof

Sure, I remember it; I wrote it.  The bug was an off-by-one in the TCP
resequencing code; if a multi-data-byte segment arrived that was a
retransmission of some single-data-byte segments, the last byte that was
retransmitted would be doubled.

This doesn't sound like the bug under discussionh (which invloved segments
of text being repeated, not single characters).

Date:      14 Dec 1984 1457-EST (Friday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        imagen!geof@shasta.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA
Subject:   Re:  bug in UNIX telnet
I think I have it here somewhere .... it got fixed before 4.2, as I
recall, but maybe not before 4.1c.


It looks like there were at least two tries. Good luck.


From: daemon
Subject: Fix to Stuttering Bug
To: ucbtcp11@Sri-Tsc
Date: 25 May 1983 1059-PDT (Wednesday)
Date: 25 May 1983 at 0932-PDT
Reply-To: dan @ Sri-Tsc
From: Shasta!dan%SRI-TSC@SCORE

Bill Croft sent me this fix to the (telnet) stuttering bug.  Apparently
Bill Joy went through some back versions of tcp_usrreq.c looking for the
bug, and found that it was caused when fixing a different bug.  Anyway,
here is a diff listing, followed by the change in context.  Thanks, Bill's,
for the fix!

---------- diff tcp_usrreq.c tcp_usrreq.c- ----------
< 		(void) tcp_output(tp);	/* stutter bug fix */
> 		error = tcp_output(tp);

	 * Do a send by putting data in output queue and updating urgent
	 * marker if URG set.  Possibly send more data.
	case PRU_SEND:
		sbappend(&so->so_snd, m);
#ifdef notdef
		if (tp->t_flags & TF_PUSH)
			tp->snd_end = tp->snd_una + so->so_snd.sb_cc;
		(void) tcp_output(tp);	/* stutter bug fix */

	 * Abort the TCP.
	case PRU_ABORT:
		tcp_drop(tp, ECONNABORTED);
		tp = 0;

From: uucp
Subject: Fix to Stuttering Bug fix!
To: ucbtcp11@Sri-Tsc
Date: 27 May 1983 1004-PDT (Friday)
Date: 27 May 1983 at 0922-PDT
Reply-To: dan @ Sri-Tsc
From: Shasta!dan%SRI-TSC@SCORE

------- Forwarded Message
Date: 25 May 1983 1346-PDT (Wednesday)
From: sam%UCBARPA@Berkeley (Sam Leffler)
Subject: Re: Fix to Stuttering Bug
Message-Id: <8305252046.AA00860@UCBARPA.ARPA>
Received: by UCBARPA.ARPA (3.342/3.29)	id AA00860; 25 May 83 13:46:37 PDT (Wed)
Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.341/3.29)	id AA03678; 25 May 83 13:46:57 PDT (Wed)
To: dan@Sri-Tsc
In-Reply-To: Your message of 25 May 1983 at 0932-PDT.             <8305251658.AA03270@UCBARPA.ARPA>
Received: from by with TCP; 25 May 83 13:48-PDT

This is actually not the proper way to fix the bug.  By ignoring
all errors, callers never see errors returned from the routing and
interface layers (as well as some important ones from the ip layer).
I found long ago that the reason for stuttering was ENOBUFS being
returned to the telnet daemon (which would then resend the data).
Consequently I added something of the form

	if (error == ENOBUFS)
		error = 0;

in the PRU_SEND case of tcp_usrreq (the delta was subsequently lost).
Understand however this forces errors such as "net unreachable" to be
considered fatal errors (often not the case).  The general problem is
difficult due to the "mushy" way that errors are defined in the Internet,
but it's safe to say returning errors directly back through subroutine
calls was a mistake (I'm responsible).  The proper way is probably
to place only fatal errors in so_error and then never have tcp_output
return a value.
------- End of Forwarded Message


Date:      Fri, 14 Dec 84 15:16:27 EST
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        Witold Paluszynski <Witold@WASHINGTON.ARPA>
Subject:   Re:  bug in UNIX telnet
Is this differnet than the stuttering bug, where the contents of a small
(usually single character) packet are repeat 10 or so times.  If it is,
it was a problem with TCP and has been fixed.

Date:      Fri 14 Dec 84 22:16:27-PST
From:      Witold Paluszynski <Witold@WASHINGTON.ARPA>
To:        ron@BRL-TGR.ARPA
Subject:   Re:  bug in UNIX telnet
Yes, it is a different bug.  I never counted how long string gets
errouneously retransmitted but it should be order of 50-100.
I also doubt if it is in the TCP code since it only shows up
in telnet.  But I am not sure.  What I am sure about is that
it is on the Unix side.  I usually telnet from TOPS-20.

Date:      Fri, 14 Dec 84 23:31 EST
From:      Mike StJohns <StJohns@MIT-MULTICS.ARPA>
To:        Lansford.PASA@XEROX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: expansions to FTP spec
    Date:  12 December 1984 13:29 est
    From:  Lansford.PASA at XEROX
    Subject:  Re: expansions to FTP spec

    "This would be the beginnings of a standardized distributed database
    system (well, at least some of the primitives needed to implement one)"

    While random access to a remote file is a very useful thing to have, FTP
    is an inappropriate protocol to use to achieve this.


_______________________________________ I got another response which
said the same thing...  i.e.  don't add it to FTP.  I really don't
understand why.  Why go through the fuss and bother of totally designing
another protocol when FTP has most of the hooks in it already?  Granted
FTP is an established protocol, but why consign it to a static life?
Also, it bothers me to proliferate protocols when others exist that can
do the job.

As a system developer given the choice between programming a totally new
system or adding commands to an already working, modularly designed
system, I would take the latter.  (Dust off that soapbox.....)

Date:      15-Dec-84 17:07:54-UT
From:      mills@dcn6
To:        tcp-ip@nic
Subject:   Reflections on a segment trace

While trying to find the source of a bug recently I observed an interesting
TCP segment trace from ECLB. That host was sending a message to the DCN6
fuzzball, which apparently received it with no problem. During the transfer,
however, ECLB sent at least one jumbogram clearly violating the DCN6 window
constraint. While this, by itself, does not violate current specifications -
the excess was neatly trimmed off and ECLB eventually retransmitted it - it
may be symptomatic of previously known TOPS-20 bugs in which this happened and
did cause connections to hang in bizarre ways.

Following is an extract from the segment trace showing how the segment
sequence received at DCN6 covers the sequence space. In the following "Time"
is the time of arrival (16-bit field, in milliseconds), "Seq" is the IP
sequence number, "LWE" is relative position in sequence space of the first
octet of the segment, "Size" is the number of octets in the segment and
"Window" is the remaining receive window size after the segment is stored and
which is returned in the subsequent ACK. A negative number in the "LWE" column
indicates a retransmission, while a positive number greater than zero
indicates a hole, which ordinarily is due to a dropped datagram.

The first part of the trace shows normal operation, with no retransmitted or
lost datagrams. The maximum receiver window size is 450. Note that the sum of
the "Size" and "Window" quantities in each row sum to 450, indicating the
SMTP server client of the TCP layer is gobbling up the data as fast as

(disregard)			Time	Seq	LWE	Size	Window
15:48:38 002 ?TRAP-I-TCP rcv	33207	49104	0	400	50
15:48:41 002 ?TRAP-I-TCP rcv	35741	49107	0	130	320
15:48:41 002 ?TRAP-I-TCP rcv	36124	49108	0	80	370
15:48:42 002 ?TRAP-I-TCP rcv	37024	49109	0	430	20
15:48:44 002 ?TRAP-I-TCP rcv	38808	49112	0	100	350
15:48:45 002 ?TRAP-I-TCP rcv	39791	49113	0	410	40
15:48:46 002 ?TRAP-I-TCP rcv	41524	49119	0	170	280
15:48:47 002 ?TRAP-I-TCP rcv	42025	49120	0	190	260
15:48:48 002 ?TRAP-I-TCP rcv	43475	49123	0	260	190
15:48:49 002 ?TRAP-I-TCP rcv	43991	49124	0	190	260
15:48:50 002 ?TRAP-I-TCP rcv	44958	49125	0	120	330
15:48:50 002 ?TRAP-I-TCP rcv	45441	49126	0	140	310
15:48:51 002 ?TRAP-I-TCP rcv	46441	49127	0	370	80

Now something wicked happens. Out of the blue ECLB sends a 536-octet
jumbogram, clearly overflowing the receive window. The first 450 octets of it
are stored and an ACK returned specifying a zero window. Shortly after that
the SMTP server client empties the buffer and returns an ACK specifying 450
octets. Meanwhile, ECLB trots along with a 74-octet segment followed by a
160-octet segment, which are saved in the reassembly buffer, leaving a
536 - 450 = 86 octet hole at the beginning. Finally, ECLB retranmsits the
536-octet segment, the last 86 octets of which fill in the missing hole, and
everything returns to normal.

15:48:54 002 ?TRAP-I-TCP rcv	49658	49132	0	536	0
15:48:56 002 ?TRAP-I-TCP rcv	50909	49137	86	74	450
15:48:57 002 ?TRAP-I-TCP rcv	52225	49138	160	290	450
15:49:01 002 ?TRAP-I-TCP rcv	56609	49132	-450	536	0
15:49:02 002 ?TRAP-I-TCP rcv	57643	49140	0	80	370
15:49:03 002 ?TRAP-I-TCP rcv	58243	49141	0	110	340
15:49:03 002 ?TRAP-I-TCP rcv	58443	49142	0	-3	447

I have no explanation why ECLB suddenly decided to send a 536-octet segment;
however, it is nice to see that both ECLB and DCN6 do the Right Thing and data
continue to flow anyway. Several months ago this problem was observed at other
TOPS-20 sites, but in these cases something drastic went wrong in the TOPS-20
and the connection broke. Bugfixes were subsequently distributed by BBN and
ISI; however, the data recorded here may indicate that not all of them have
been installed at ECLB.

Date:      Mon 17 Dec 84 11:13:32-EST
From:      J. Noel Chiappa <JNC@MIT-XX.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: expansions to FTP spec
	It might be the case that server FTP contains large pieces that
can be reused, but the user end will certainly be useless, since a File
Access Protocol would have to be integrated with the application, unless
you are going to run it in a separate process, in which case the
performance will be terrible.
	In general, it is better to build new small things to do exactly
what you want, rather than modifying the bits at hand, for several
reasons. To begin with, you are not limited by the preexisting
structure: when SMTP was done as a new mail transfer protocol, the
designers had a free hand. Secondly, performance can be optimized to the
application at hand: many FAP's use UDP rather than TCP for data
transfer since UDP is better suited to applications where the round trip
delay limits performance; FTP can use the ability of TCP to 'keep the
pipe full'. Finally, it is much easier to maintain and find bugs in
small systems than larger; FTP is a large jumble already (the spec is
longer than any other one in the book except TCP), and it doesn't need
to get worse.
Date:      17 Dec 1984 16:41:05 PST
Subject:   re: IEEE 802.3  and  Ethernet Types

Geof Cooper:

Thanks for straightening out that problem.  

By the way, do you know how the Service Access Point or SAP fits into
this situation?  There is a SAP assigned for IP (RFC-923 pg. 20).

Date:      Tuesday, 18 Dec 1984 09:24-PST
From:      imagen!
To:        shasta!POSTEL@USC-ISIF.ARPA
Cc:        shasta!TCP-IP@SRI-NIC.ARPA
Subject:   re: IEEE 802.3  and  Ethernet Types


I must confess general ignorance about the SAP issue.  There was some
off-handed mention of it at the XNS conference, from which I gathered
that SAP's were proposed as a solution to the lack-of-type-field
problem.  I believe that a SAP is a small (16-bit?) header that goes
above the IEEE 802.3 header.

There were two gripes expressed about SAP's:

	[1] The portion of the header used as a type field is
	    apparently 6 bits.  Not much foresight in that.

	[2] There is both a `source' type field and a `destination' type
	    field for each packet.  The concept was that one represented
	    what the sender of the packet put in the packet, and the
	    other how the sender wanted the receiver to interpret the
	    packet.  No one could think of any useful situation where
	    these would be different.

Again, I don't really know what this is all about.  Maybe someone else
on the net can fill in more details.

- Geof
Date:      Wed 19 Dec 84 07:10:58-PST
From:      Ken Harrenstien <KLH@SRI-NIC.ARPA>
To:        mike@BRL-TGR.ARPA, Action@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA
Subject:   Re: NIC TABLE FAILURE!!!
There turned out to be 5 nulls in the host-table file just at that
exact point.  This is rather suspicious.  I have written out a new
version so that things will work for you while I start tracking down
the original problem.  It may turn out to be a disk error at some
stage (ugh).
Date:      19 Dec 84 09:20:04 PST (Wednesday)
From:      Lansford.PASA@XEROX.ARPA
To:        Mike StJohns <StJohns@MIT-MULTICS.ARPA>
Cc:        Lansford.PASA@XEROX.ARPA, J. Noel Chiappa <JNC@MIT-XX.ARPA>, tcp-ip@SRI-NIC.ARPA
Subject:   Re: expansions to FTP spec

"....Why go through the fuss and bother of totally designing
another protocol when FTP has most of the hooks in it already?  Granted
FTP is an established protocol, but why consign it to a static life?
Also, it bothers me to proliferate protocols when others exist that can
do the job."

FTP is an end-to-end protocol which is assumed to be (fairly) transient
- and can thus have a large amount of baggage associated with it for
reliability, etc. However, "remote files" are quite another matter. In
this case, you want to keep the connection open for considerable lengths
of time, and allow many such simultaneous connections. thus any such
protocol must be "light weight" (little "state", etc.) so as to minimize
the resources expanded at the server end.

For instance, restricting a server to say, 8 simultaneous FTP
connections might result in quite adequate service to the user community
because of the short duration of the connections; but you would find
that you must allow perhaps an order of magnitude more "remote file "
connections to satisfy user demands.


Date:      Wed, 19 Dec 84 9:46:30 EST
From:      Mike Muuss <mike@brl-tgr>
To:        Action@sri-nic.ARPA, KLH@sri-nic.ARPA
Cc:        tcp-ip@sri-nic.ARPA
This morning, all the hosts at BRL were crippled, because the
copy of the NIC table that we downloaded at 0400 was defective.
At 0930, the probelm still existed at the NIC, and I notified
the NIC operator.

Very simply, the NIC table service on port 101 would return
1069 lines, and then break off and print "END:".
No BRL hosts apear in the abbreviated table.

This has destroyed connectivity at BRL, and interrupted the flow
of mail between our hosts.  This service is vital, please try
to get the difficulty fixed quickly.

-Mike Muuss
 Host Administrator for BRL-*

Here is an excerpt from a TELNET session with the NIC on port 101:

Script started on Wed Dec 19 09:37:36 1984
1 brl-tgr> telnet nic 101


Connected to

Escape character is '^]'.



; DoD Internet Host Table

;  18-Dec-84

;  Version number 410


; Changes, corrections, comments or questions to (HOSTMASTER@SRI-NIC)


; The format of this file is documented in RFC 810, "DoD Internet

; Host Table Specification", which is available online at SRI-NIC

; as the file

;              [SRI-NIC]<RFC>RFC810.TXT

; It may be retrieved via FTP using username ANONYMOUS with

; any password.


; NOTE CAREFULLY: RFC 810 has been slightly revised since the original

; version was written.  In particular, the version printed in the

; "Internet Protocol Transition Workbook" does not document the

; added "machine type" field (between the host-name and system-name

; fields).


; The format for entries is:







; Where:

;;  ADDR = internet address in decimal, e.g.,

;;  CPUTYPE = machine type (PDP-11/70, VAX-11/780, FOONLY-F3, C/30, etc.)

;;  OPSYS = operating system (UNIX, TOPS20, TENEX, ITS, etc.)

;;  PROTOCOLS = transport/service (TCP/TELNET,TCP/FTP, etc.)

;;  : (colon) = field delimiter

;;  :: (2 colons) = null field







NET : : ATT :

...... lots of text removed here, for brevity ......
























Connection closed by foreign host.

NOTE how it aborts in the middle of RICE-ASTRAEA, yet gives
the END: indication.
Date:      19 Dec 84 10:35:19 EST
From:      ddn-navy @ DDN1.ARPA
To:        tcp-ip @
Cc:        fnoc-mry @, ddn-navy @ DDN1.ARPA
Subject:   Query on Data Gen AOS/VS <--> ARPANet Capability
A few weeks ago there was an extensive dialogue on the net concerning
Data Gen AOS systems.  I have a user at Fleet Numerical Oceanography Center
who is procurring a Data Gen running VS.  Has Data Gen announced a full
Internet interface and if so does anyone have a POC so I can get them into
the certification cycle here at DDN.  Many thanks.

Rod Richardson
Navy Systems Implementor
DDN Prog Mgt Office

Date:      Thu, 20 Dec 84 14:03:23 est
From:      Alan Parker <parker@nrl-css>
To:        tcp-ip@nic
Subject:   Internet Gateways
We are in the market for an IP gateway to sit between our TCP/IP ethernet
and a C/30 IMP.   Where should we look?  Any sellers welcome to call
at (202) 767-3477 or send mail.   Any other pointers appreciated.  Thanks.

Date:      20 Dec 1984 1418-EST (Thursday)
From:      jnc@proteon
To:        parker@nrl-css
Cc:        tcp-ip at nic,jnc, hs,acm,jas
Subject:   Internet Gateways
	This question seems to be getting asked a lot lately. Among
others, Proteon, makers of the Pronet ring network, will be
selling gateways based on the MIT C gateway. The code currently
runs on PDP11's, with several years of service at MIT and
Stanford; it is in the process of beig transported to the
MC68000. People wanting more information should contact Proteon
at (617)-655-3340 for marketing information, or me if they want
technical details.

Date:      Thu, 20 Dec 84 14:59:21 EST
From:      Doug Kingston <dpk@BRL-TGR.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   TCP/IP for IBM MVS
	Does an implementation exist that does not require
the existence of VM (I know about WISCVM and Spartacus)

Date:      Fri, 21 Dec 84 06:40:38 cst
From: (L.H. Landweber)
To:        dpk@BRL-TGR.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  TCP/IP for IBM MVS
Bob Braden at UCLA has a TCP/IP for MVS.
Date:      21 Dec 1984 15:43 PST
From:      Gary Krall <GARY@ACC>
To:        TCP-IP@SRI-NIC
Subject:   IBM MVS support

In addition to Network Solutions supplying the software, ACC jointly
with NS was awarded a contract to provide host interfaces for
attaching IBM 4300, IBM 3300, IBM 370 and other IBM compatible
mainframes to the Defense Data Network.

ACC's IF-370/DDN hardware interface attaches directlty to the block
multiplexor channel of IBM-type mainframes and offers both X.25 and
HDH connection.  The IF-370/DDN is capable of transferring data at
rates in excess of 1.5M bits per second.

The DDN/MVS package proposed to the DCA by Network Solutions and ACC
includes on-site surveys, on-site customized installation of software,

operational testing, ongoing support and maintenance and access to a toll-
free service number.

Gary Krall
Date:      21 Dec 1984 15:44 PST
From:      Gary Krall <GARY@ACC>
To:        TCP-IP@SRI-NIC
Subject:   XNS on 4.2

Does anyone know of any work and the status of that work of implementing
Xerox XNS under the 4.2 networking kernal?  Also any info about any
work on having Courier run on top of TCP/IP?

Thanks for the help,

Gary Krall
Date:      21 Dec 1984 17:04:54 EST
To:        dpk@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP for IBM MVS
In response to the message sent      Thu, 20 Dec 84 14:59:21 EST from dpk@BRL-TGR.ARPA

As noted in a recent DDN Newsletter, Network Solutions, Inc is under contract
to provide support oninstallation and operation of the UCLA TCP/Ip code for
OS/MVS.  Call Will McDuffie at (703) 356 1411, or send mail to him at

Bob Braden
Date:      Sat, 22 Dec 84 14:57:28 est
From:      James O'Toole <james@gyre>
To:        gary@acc
Cc:        tcp-ip@sri-nic
Subject:   Re: XNS on 4.2
	Does anyone know of any work and the status of that work of
	implementing Xerox XNS under the 4.2 networking kernal?

I know of mine.  Chris Torek and I have made many changes to the 4.2
kernel so that we could try to implement the two lowest layers of XNS
inside the kernel (IDP and SPP).  We have implemented IDP and SPP, except
for two things:
    1) We haven't had time to test our implementations with our Xerox
workstations yet, so we almost certainly have small changes to make involving
packet formats.
    2) The SPP implementation is not complete; we haven't done out of band
data, for example.

	Also any info about any work on having Courier run on top of TCP/IP?

4.2 as distributed contains someone's experimental versions of courier
under TCP...see code in /usr/src/new/courier (Eric C. Cooper <cooper@berkeley>
is the name that comes to mind).
jqj@cornell and cu-arpa.bill@cornell are two people at (guess where?) cornell
who have been improving the courier-tcp code in /usr/new, intending to
implement courier on top of our SPP.

If you want more details about our implementation, contact me.

Date:      Thursday, 27 Dec 1984 09:27-PST
From:      imagen!
To:        shasta!TCP-IP@SRI-NIC
Subject:   "TCP/IP for VM Systems Available Commercially"

FYI, the following article appeared in the latest CSNET News, Fall,
1984, No.  6, and is reprinted without permission in its entirety
(please, someone at the CIC let me know if this is Bad Practice):

"IBM has formally announced that it will market the software known as
''The VM Interface Program for TCP/IP,'' developed jointly by IBM and
the University of Wisconsin.  With this software, IBM VM hosts can
connect to CSNET X25Net and use the ARPANET/DoD protocols for mail,
file transfer, and remote login.  Previously, the software was
available to universities and colleges only, as the ''WISCNET''
package.  (See CSNET News, No.  5.)

"The VM Interface Program for TCP/IP provides the following functions:
 - An implementation of the standard DoD protocols TCP and IP under
   VM/SP Release 2 or 3.
 - File transfer to and from remote sites using file transfer protocol
 - Electronic mail to remote sites using the VM NOTE facility as an
   interface to simple mail transfer protocol (SMTP)
 - Remote terminal login using the TELNET protocol

"Sample programs are also provided for the Series/1 EDX system,
Series/1 RPS system, or Device Access Control Unit to support
interfaces to local area and packet-switched networks, including
ProNet, Ethernet, and X.25.

"There is a one-time chare of $17,000 for the software.

"If you would like more specific information about the net TCP/IP
interface software, please contact your local IBM sales representative
and refer to Availability Notice G320-9219."
Date:      30 Dec 84 15:43:56 EST (Sun)
From:      Marshall Rose <mrose@udel-dewey>
Subject:   The Netweaver's Sourcebook
[ This probably belongs to info-micro, but ... ]

    I picked up a copy of "The Netweaver's Sourcebook" by Dean Gengle.
    It's got lots of interesting information on micros and networks
    along with a long treatise on the information society.  This book
    is a lot like the hitchhikers's guide to the galaxy: parts of it
    are really great, other parts are woefully untrue.  Here's the
    description about TCP/IP (which is why I sent this message to this

	 "This is the Internet Protocol/Transmission Control Protocol,
	 set and used by the U.S. Department of Defense since 1980.  It
	 is oriented towards peer-to-peer communications.  It is only
	 important to the military, and those wishing to interface to
	 the military."

    The back of the book has a "Netweaver's Feedback Form", so I'm
    going to drop him a quick note politely stating my discuss.

    My question to the group is: have you seen other descriptions of
    TCP/IP outside of "our community", and if so, are they as misguided
    as this?  Or, if this is on the mark, how did I get so misguided?


Date:      31 Dec 1984 07:30-EST
To:        mrose@UDEL-DEWEY.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: The Netweaver's Sourcebook

Perhaps the reason the author is misguided is the strong emphasis placed,
during design and internal standardization, on meeting military needs for
high reliability under extremely hostile (in the communications sense)

Also, it is only in the last year or so that commercial versions of
TCP/IP and related higher-level protocols have attracted some of the
mainframe vendors - and I imagine much of this attraction stemmed
from the need to link up with local area nets.

From my present perspective, anything which stimulates commercial
interest in marketing and supporting these protocols can only help
since the ISO standards are still a long way from being complete
or even available.

Vint Cerf
Date:      Mon 31 Dec 84 13:03:40-PST
From:      David Roode <ROODE@SRI-NIC.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: The Netweaver's Sourcebook
Perhaps it would interest the people on this list to hear of
two recent examples of support by DEC for TCP/IP.  At the
December DECUS Symposium, DEC relied on TCP/IP as the network
link between VAXes running Ultrix (Unix) and the rest of their
product line (VMS particularly).  They thereby endorsed use of
the Wollongong Group's supported TCP/IP (essentially the Unix
version running under the Eunice emulator) for VMS.

Furthermore, DEC has extended availability of TOPS-20 TCP/IP
supported configurations to include its new Ethernet device,
with non-ARPANET/MILNET customers in mind.