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 October 1984 (126 messages, 55426 bytes)
NOTICE: recognises the rights of all third-party works.


Date:      Mon, 1 Oct 84 08:35:06 pdt
From:      mtxinu!excelan!jay@Berkeley (jay israel)
To:        mtxinu!ucbvax!"aronson@nlm-mcs"@Berkeley, mtxinu!ucbvax!"dpk@BRL-TGR"@Berkeley, mtxinu!ucbvax!"lamas@brl"@Berkeley, mtxinu!ucbvax!"mo@seismo"@Berkeley, mtxinu!ucbvax!"postel@USC-ISIF"@Berkeley
Cc:        avnish@Berkeley, billn@Berkeley, george@Berkeley, jay@Berkeley
Subject:   Re: Excelan ip/tcp
There is an update imminent of both the software and the documentation.  Among
the changes is support for all classes of networks.  For details, please
contact George Powers or me at (408) 945-9526.

If you know of others who may need this information, or to whom you have 
mentioned this issue, please convey this reply.

Thanks for your interest,
Date:      Mon Oct  1 12:09:43 1984
From:      Martin Lee Schoffstall <cadtroy!schoff@seismo.ARPA>
To:        cadmus!seismo!tcp-ip@nic.ARPA
Subject:   excelan boards
The current version of the firmware available to OEM's (Cadmus,Masscomp,
Silicon Graphics...) only supports class A networks.  In November they
are going to release new firmware which will support arbitrary network


Date:      2 Oct 84 03:57:16 PDT
To:        Doug Kingston <dpk@BRL-TGR.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, mo@SEISMO.ARPA
Subject:   Re: [Jules P. Aronson:  excelan tcp/ip boards]
That's just the tip of the iceberg. Ethernets use 48 bit host numbers.
The number czar assigns a 23 bit number to each manfacturer. They get to
pick the other 24. (The last one is used for multicast.)

Consider what happens if another company uses the same approach, and you
are trying to run a mixture of boards on the same ethernet. If you are
unlucky, you end up with 2 machines using the same IP host number. You
might think that getting a collision when picking 2 24 bit numbers would
be quite rare, but both manfacturers are probably assigning them
sequentially, and remember the number of people at a party that it takes
to get two with the same birthday...

We have a similar problem when running Pups (8 bit host numbers) on our
Ethernets. We couldn't come up with any good way to do it. Our current
implementation uses a centrally maintained table and an NS based
protocol to talk to a server. We thought about fancier schemes that
would avoid the manual editing of the table, but that would require
several severs to keep cooridinated and there isn't any reasonable way
to determine that a machine is really dead (so you can recycle it's host
number) as compared to just quiet for some good reason (it's owner is on

Anybody have any good ideas?

Date:      2 Oct 84 03:05:38 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   packet size constraints
I seem to recall discussion on this point sometime in the dim past, but
I can't come up with it.  Can somebody refresh me on the situations in
which it is legal to use packets larger than 576 bytes?  We are using a
DEC-20 as a gateway.  It can handle packets of size 1004 on the Arpanet
side and 972 on the Ethernet side.  Apparently there is no way we are
going to get the 20 to accept packets above 1004 on the Ethernet side
without massive recoding.  This causes problems when two Unix systems
talk to each other through our gateway.  Unix likes to use 1500-byte
packets on the Ethernet.  A 4.2 system on my Ethernet is talking to one
at SRI on their Ethernet. Apparently the two TCP's determine that they
can both handle 1500-byte packets, and use that as their packet-size.
Unfortunately, packets do not make it through my gateway.  Somebody is
violating a rule someplace.  Is it
  - Unix, because before using 1500-byte packets they have to make sure
	that not only both hosts, but also all intervening gateways can
	handle them
  - Tops-20, because any gateway should be able to accept the largest
	size packet supported by its physical medium

Obviously this answer doesn't much matter to me.  Since I can't fix
Tops-20, I will have to patch Unix so it doesn't send large packets, no
matter what the answer is.  But if the conclusion is that Unix is wrong,
I will recommend to Pyramid that they modify the TCP code to use
576-byte packets.  If the conclusion is that Tops-20 is wrong, I will
simply keep this as a local hack.
Date:      2 Oct 1984 07:48:57 PDT
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: datagram size constraints

A gateway must be able to accept the maximum datagram that can be transmitted
on the physical networks it is attached to.

Date:      2 Oct 1984 08:05:33 PDT
Subject:   re: ARP is what you need

Well,  i think that the "ARP is what you need" comments miss the point.
The problem is how to assign a pair (Ethernet, IP) addresses to a host
in the first place.  I don't think there is any good answer for that.
At ISI, we keep a list.  We have a local number czar.  When some new
machine shows up the owner of the machine goes to the number czar and
gets a new IP address (within the ISI-NET), and the number czar makes
some notes about the new machine (including both the IP address and the
Ethernet address).  Once the assignment is made the new host can be taught
its IP address, and knows from the hardware its Ethernet address.  Only
after all this can it play ARP.  ARP is a great way to dynamically 
map IP addreses to Ethernet addresses using a distributed table lookup.
The table is so distributed that each host hold only one enrty of the
table -- its own.  But don't kid yourself - the table exists and
somebody has to make sure it is consistent.

Date:      Tue 2 Oct 84 07:44:36-EDT
From:      J. Noel Chiappa <JNC%MIT-XX@MIT-XX>
Subject:   Re: [Jules P. Aronson:  excelan tcp/ip boards]
	Use the ARP protocol (RFC 826) which does just the right thing.
It's the current standard for translation of hardware addresses to protocol
addresses for nets for which there is no simple mapping.
Date:      Tue 2 Oct 84 09:53:53-EDT
From:      Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
Cc:        dpk@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA, mo@SEISMO.ARPA
Subject:   Re: [Jules P. Aronson:  excelan tcp/ip boards]
ARP  is exactly what you want. One of the side effects using ARP for IP
was quite beneficial to TOPS-20 and you may all find it amusing.

DECNET had the same problem as as IP. The address mapping for DECNET is
much smaller than the address mapping for Ethernet. The "solution"  was
to  make  all  DEC  Ethernet  hardware  have  the ability to change its
address. When DECNET starts  up  it  changes  the  Ethernet  interfaces
address to be some magic number or or'ed with the decnet node number.

We  expected  this  to cause a pretty bad problem for the IP code which
was allready happilly talking on the Ethernet  and  allready  knew  its
address (as did all the hosts it was talking to).

There  are  several  solutions  to this problem. One solution is to not
start talking until DECNET sets the address to what it  wants.  Another
solution  is  to  broadcast an ARP packet with our new address when the
address changes. This actually does work.

We  do  not  have to determine what we are going to do for a few months
yet as DECNET and IP will not coexist on the same Ethernet in the  same
monitor  until  6.1  of TOPS-20 (because 5.4 does not support DECNET on
the Ethernet).  
Date:      2 October 1984 10:10-EDT
From:      David C. Plummer <DCP @ MIT-MC>
Cc:        mo @ SEISMO, tcp-ip @ SRI-NIC, @ XEROX, dpk @ BRL-TGR
Subject:   Re: [Jules P. Aronson:  excelan tcp/ip boards]
    Date: Tue 2 Oct 84 09:53:53-EDT
    From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>

    There  are  several  solutions  to this problem. One solution is to not
    start talking until DECNET sets the address to what it  wants.  Another
    solution  is  to  broadcast an ARP packet with our new address when the
    address changes. This actually does work.
Right, but this is just a bit non-deterministic.  You should also
flush your tranlation tables so you take translation faults
whenever the -20 tries to send packets again..
Date:      2 Oct 1984 1126-EST (Tuesday)
From:      Christopher A Kent <cak@Purdue.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   re: datagram size constraints
	Date:  2 Oct 1984 07:48:57 PDT
	Subject: re: datagram size constraints
	A gateway must be able to accept the maximum datagram that can be transmitted
	on the physical networks it is attached to.
Note that this maximum is not necessarily the maximum physical limit --
it can be an administrative limit. For example, in your case, it sounds
like the limit should be 904 on all machines, since your TOPS-20
machine can't handle anything bigger than that. We have a proNET ring,
with a physical maximum packet size of 2044 octets, but the largest
packet sent, by administrative decree, is 1600 octets. Everyone agrees
to this, including the gateway, and everything is happy. For a while,
the gateway ran a different MTU, and things broke a lot.

If the TCP clients that go through your gateway are doing the right
thing with maximum segment size options, and it sounds like they're at
least trying, your side should tell its peers not to send any TCP
segments that will push datagrams >904 octets at your gateway, so
everything should work.

Date:      2 Oct 1984 14:17-PDT
Subject:   Packet Size Constraints

RFC-879 discusses the TCP maximum segment option.

Date:      Tue 2 Oct 84 11:43:24-EDT
From:      Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
To:        DCP@MIT-MC.ARPA
Cc:        mo@SEISMO.ARPA, tcp-ip@SRI-NIC.ARPA,, dpk@BRL-TGR.ARPA
Subject:   Re: [Jules P. Aronson:  excelan tcp/ip boards]
we flush the table when the address changes.

Date:      Tue 2 Oct 84 11:52:01-EDT
From:      Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, hedrick@RUTGERS.ARPA
Subject:   re: datagram size constraints
After thinking about the tops20 tcp/ip code and the maximum datagram size
I have thought of a way I can get this to work.  However it will not happen
for a few months.  For now the maximum datagram size of 1004 is a restriction
in the TOPS-20 tcp.

Date:      Tue, 2 Oct 84 12:51:57 EDT
From:      Gary Delp  <delp@udel-ee>
To:        Charles Hedrick <>
Cc:        tcp-ip@sri-nic
Subject:   Re:  packet size constraints

	The option negotiation at the beginning of the tcp setup
lets each host adversise the maximum size packet that they are 
willing to except.  If no such advertisement takes place, 
the default is the minimum size
(circa 570 bytes).  Note that only the endpoints enter into
this negotiation.  IP, which handles the intermediate stuff never
negotiates end point to endpoint, it just knows what each network
it gateways to can handle.  The IP which does the gatewaying (the
DEC20 machine) is responsible for fragmenting the packets as needed to
transmit them on the networks it uses to forward the packets.
Each recieving host must then do IP packet reassembly.  
	If hosts chose not to do reassembly, they can throw packets away,
advertize small TCP windows, and set the dont't fragment flag on the
IP packets they send, but this is a work around possibly more
difficult that implementing fragment reassembly. And certainlly not
in the spirit of IP.  David Clark has
a very nicely worded rfc about reassembly which should be a help
if that is the problem.  (rfc 815).

-Gary Delp <>
Date:      2 Oct 1984 1646-EST (Tuesday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        Ron Natalie <ron@BRL-TGR.ARPA>
Subject:   Re:  datagram size constraints
	Date:     Tue, 2 Oct 84 16:09:36 EDT
	From: Ron Natalie <ron@BRL-TGR.ARPA>
	Subject:  Re:  datagram size constraints
	TCP?  IP!  Regardless of what the TCP does, the IP should not send
	packets larger than the network maximum transfer limit.  It is IP's
	job to fragment the packets to fit the network.
Yes, right, of course. But the TCPs should also try to pick Max Seg
sizes to avoid IP fragmentation of TCP segments (although that's a
different story).

Date:      2 Oct 1984 1705-EST (Tuesday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  datagram size constraints
	Yes, but how can IP know the maximum packet size for the network.

Everyone on the network must agree to a MTU (that is, the owners of the
machines!) and set it with whatever black magic is required for their
host. It's not intended that you figure it out on the fly. That means
hardcoding into the kernel on a Unix system (or patching with adb, but
that doesn't always work), or changing the Tops-20 configuration

If you have a box that doesn't let you change it, you're out of luck
unless you can get everyone else to use that box's idea of the MTU...

Date:      Tue, 2 Oct 84 16:09:36 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        Christopher A Kent <cak@PURDUE.ARPA>
Subject:   Re:  datagram size constraints
TCP?  IP!  Regardless of what the TCP does, the IP should not send
packets larger than the network maximum transfer limit.  It is IP's
job to fragment the packets to fit the network.

Date:      2 Oct 84 17:59:03 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        ron@BRL-TGR.ARPA
Subject:   Re:  datagram size constraints
Yes, but how can IP know the maximum packet size for the network.  As
far as I can see, either the OS lets you specify the packet size
for each interface as a configuration parameter (Tops-20) or they
hardcode it into the kernel (Unix).  I don't see any way that a machine
can detemine the MTU for a given network by asking somebody.
Date:      Tue, 2 Oct 84 19:33:56 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject:   Re:  datagram size constraints
You are right.  You have to know.

Date:      3 Oct 84 08:41:11 EDT
From:      dca-pgs @ DDN1.ARPA
To:        tcp-ip @
Cc:        info-unix @
Subject:   DDN Host Interface Contract Awards
Forwarded message(s):  
To: ddn-pmo @ DDN1
From: jmallory @ DDN1
Subject: Host Interface Contract Awards
Date: 2 Oct 84 13:10:19 EDT
cc: jmallory @ DDN1

The following contracts have been awarded for DDN host interfaces:

          COMPANY                      HOST FAMILY

    1. Network Solutions               IBM 370 MVS

    2. CDC                             CDC CYBER 170 NOS

    3. HIS                             HIS Level 6 GCOS 6 MOD 400

    4. Gould Software Division         DEC VAX 11 VAX/VMS

    5. Internet Systems Corp.          SPERRY 1100

Contracts are in process for the following host families:

    1. HIS DPS8 GCOS8

    2. IBM 370 VM

    3. DEC PDP 11 RSX-11M

Awards are expected shortly for the first two families.  The third one will
delayed until after Dec 15th due to the availability of funds.

The information in this message is not restricted and may be disseminated
to the world.


-------------END OF FORWARDED MESSAGE(S)-------------

Date:      3 Oct 1984 14:19-EDT
From:      CLYNN@BBNA
Cc:        tcp-ip@SRI-NIC, CLynn@BBNA
Subject:   Re: packet size constraints
	Don't engage in any massive recoding for packets larger than
1004 octets.  Such code is currently running at BBN, and was given to
DEC last May, but they haven't yet had a chance to put it in a system
release.  A more recent version has (at least half) of the code required
for option sub-negotiations, which MARANTZ@RUTGERS was inquiring about
a couple weeks ago.
	It is a bit discouraging to see people reporting problems which
were solved a long time ago but just haven't made it through the system.
ARPA's goal is to transfer the BBN code and TOPS20 TCP support to DEC.
We are concluding our work on TOPS20 TCP this October and expect that
DEC will include the BBN code in a future TOPS20 release.

Date:      4 Oct 1984 08:49-PDT
From:      Dan <LYNCH@ISIB>
Subject:   Re: packet size constraints
Charlie and Charles,  Let me be a bit more direct about what Charlie
said in his last message:  ARPA is going to depend on DEc for future
TCP/IP support in TOPS20.  The work has never been "trivial".
I am not intimately familiar with what is going on inside DEC with
regards to this matter, but I can suggest that each site independantly
apply pressure towards DEC to get the appropriate amount of
resources applied internally to get TCP/IP supported in
an accurate and timely manner.  How each site applies that
pressure is alocal matter (use the best pressure point you
know of), but it is imperative that you let DEC know how important
this matter is or they will attend to the louder squeeky wheel.
Date:      4 Oct 1984  9:21:13 EDT (Thursday)
From:      walt lazear <lazear@mitre>
To:        tcp-ip at nic
Cc:        lazear@mitre
Subject:   Add to list
Please add 'lazear at mitre' to the tcp-ip list.  Thanks in advance.

Date:      Thursday,  4 Oct 1984 13:23-PDT
From:      imagen!
To:        shasta!tcp-ip@SRI-NIC, shasta!HEDRICK@RUTGERS.ARPA
Subject:   Re: packet size constraints

I got a strange view of your question, since my mailer managed to
reverse the order of the question and the many responses that have been
pouring in.  I agree with what Jon Postel says (that a gateway is
required to accept the maximum sized packet on a network).  I don't
think that is the end of the story.

When you say that the tops-20 code handles 972-byte packets on your
ethernet, and that you can't practically fix it, what you are REALLY
saying (applying Jon's logic) is that YOUR Ethernet only supports
972-byte packets.  There are two constraints that limit the size of
internet datagrams that can be sent on a network:
	- the maximum length packet the hardware supports
	- the maximum length packet essential service machines can handle
In most cases the first constraint is the more significant; in yours the
second is.

The bug with this is that two hosts on your Ethernet can't figure out
that they can communicate with 1500-byte packets.  That is a better bug
(in my opinion) than randomly failing when using the gateway.  

Implementations of the Internet protocol should have an easily
reconfigurable maximum packet size for the network.  A source license
should not be necessary to change the maximum packet size, unless a
source license accompanies every copy of the binaries (as is not the
case, for example, with 4.2 unix).  Are you listening, fellow TCP

A hack that recognises when you are using the gateway and warned the
local TCP to do the ``right thing'' would probably work better than the
above.  On the other hand, that above is consistent within the
limitations of current TCP-IP specs (I hope).

- Geof Cooper
Date:      Thursday,  4 Oct 1984 15:00-PDT
From:      imagen!
To:        shasta!tcp-ip@sri-nic
Subject:   Crufty mailer behavior

We have been getting quite a few messages like this one:

  From: su-shas!tcp-ip-relay@sri-nic
  Received: from by with TCP; Tue Oct  2 14:49:34 1984
  Sender: tcp-ip-relay@sri-nic
  Date: Tuesday, 2 Oct 1984 14:52-???

  <925 lines containing DATA deleted due to lack of interest-ed>
  Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Tue 2 Oct 84 13:34:06-PDT
  Date:     Tue, 2 Oct 84 16:09:36 EDT
  < rest of message is normal >

It appears that something is amiss in the SMTP connection from the NIC.

Theory of a Bug:
	NIC sends DATA to shasta during SMTP
	Shasta sends response only after long delay.
	Meanwhile, NIC retransmits(??) the DATA statement many times,
		the extra data statements are correctly interpreted as
		part of the message.

If this is what is going on, then there is a bug in the NIC's code.  

Has anyone else been seeing similar problems?

- Geof Cooper
Date:      Thu 4 Oct 84 13:08:10-EDT
From:      Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
Subject:   Re: packet size constraints
Well, lets get the story straight.

We  (TOPS-20  Monitor group) met with BBN early this year (or late last
year) about the code in question from BBN. At that time we talked about
the schedules that TOPS-20 had at that point and informed BBN  that  we
needed  to  have  the  code  from  them by sometime in February to meet
release 6 schedules.

We did not get the code in time for release 6. It was at least 4 months
late for release 6. It will not be in release 6.

We  have  not  been  sitting  on  our  hands however. We went ahead and
implemented the DEC KLNI ethernet hardware, driver, and  IP  interface.
Also cleaned up lots of stuff in TCP/IP in general.

I  have not had a chance to even look at the BBN changes yet. I was not
aware that it even supported larger messages. 

It  is  not clear that I will get the chance to merge this stuff before
the release 6.1 schedule shuts me out. 

There is a little bit more to TOPS-20 than the TCP/IP code.
Date:      Thu 4 Oct 84 13:13:32-EDT
From:      Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
Subject:   Re: packet size constraints
Applying  pressure  is  a  two  way street. Unfortunately when we apply
pressure at this end it is ignored. The schedules that DEC has for this
product are even not considered when external organizations want to get
changes made to the product.
Date:      Thu 4 Oct 84 18:28:50-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        imagen!geof@SU-SHASTA.ARPA
Subject:   Re: Crufty mailer behavior
     What gives you the idea that the bug is necessarily at the NIC?
There is at least one other agent, SU-Shasta, which could be the cause
of the problem.  I don't know what modifications the NIC may have in
their copy of the TOPS-20 mailsystem but certainly the mailsystem as
distributed by me doesn't have that bug!
Date:      Thu, 4 Oct 84 19:42 EDT
From:      "David C. Plummer" <DCP@SCRC-STONY-BROOK.ARPA>
To:        "tcp-ip@SRI-NIC"@MIT-MC.ARPA
Subject:   information in RESET segments
Does anybody check to see if the length of a segment that has the RESET
bit is 0?  What are the consequences if I put textual data (a "reason")
in the RESET segment and had a non-zero length field.

I would like to add this to the spec.  I believe it is upward
(backward?, I can never get them straight) compatible.

Rationale: we have systems that will refuse connections for a variety of
reasons, and we have to guess what the reasons are when we use TCP.
Also, there are several places in the spec that say "Send a RESET."
Many are for different reasons, so if there is a protocol violation it
would be nice to know what it was.

Paranoid, secure, etc., systems need not fill it in; this is optional.

Date:      Fri, 5 Oct 84 00:17 EDT
From:      Mike StJohns <StJohns@MIT-MULTICS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: information in RESET segments
My copy of the mil-std version of tcp reveals that the length of the
segment never gets considered if the reset bit is on.  In most cases,
the only action taken is to throw away the reset.

Textual data?  Wouldn't a better way be to define a "standard" set of
RESET errors ids (one byte long) and just return the ID?  The system
receiving the RESET would have a better idea of what went wrong, and it
would be easier for non-interactive users to react to the RESET

Keep in mind though, a modification to TCP at this level will probably
require modifications in the TCP/upper level protocol interface to allow
the reset code to pass upwards.

Mike StJohns
Date:      5 October 1984 11:11-EDT
From:      David C. Plummer <DCP @ MIT-MC>
To:        StJohns @ MIT-MULTICS
Cc:        tcp-ip @ SRI-NIC, dcp @ SCRC-STONY-BROOK
Subject:   Re: information in RESET segments
    Date:  Fri, 5 Oct 84 00:17 EDT
    From:  Mike StJohns <StJohns@MIT-MULTICS.ARPA>

    My copy of the mil-std version of tcp reveals that the length of the
    segment never gets considered if the reset bit is on.  In most cases,
    the only action taken is to throw away the reset.


    Textual data?  Wouldn't a better way be to define a "standard" set of
    RESET errors ids (one byte long) and just return the ID?  The system
    receiving the RESET would have a better idea of what went wrong, and it
    would be easier for non-interactive users to react to the RESET

Yes, damnit, textual data.  Why can't we have some human readable
things?  Does everybody out there work for IBM and memorize error
codes.  Textual data allows arbitrary reasons to be presented to
USERS.  If you read what I proposed, I said "we have to guess."
I didn't say "the implementation has to guess."  Let this be a
warning to people out there that I consider bit packing for
things to be presented to users to be a completely assinine
concept and has no place in user interfaces.  It is not
extensible ("Gee, we need a new error code that means X"), it
doesn't allow superfluous USEFUL information ("RESET because you
sent data after sending a FIN"), etc.  It is also possible for
application programs to supply an infinite variety of abnormal
close reasons.  Those familiar with the LispM flavor system may
be familiar with the :CLOSE message to streams.  Well, there is
also a :CLOSE-WITH-REASON message, which in the case of TCP makes
the reason go into a black hole.

It pains me TCP didn't adopt a textual contact name (like the
Chaos protocol does) but instead stuck with NCP port numbers.  It
is so much simpler to prototype protocols
experimental number and then propose it as an RFC and then get a
bona fide port number from the PORT CZAR and then go in and
change all the code and then reboot every system.  Come off it,
get out of the dark ages!  <Flame off>

Summary: I will not accept anything but textual data as the
extension to RESET.

    Keep in mind though, a modification to TCP at this level will probably
    require modifications in the TCP/upper level protocol interface to allow
    the reset code to pass upwards.

This is COMPLETELY upward compatible.  Consider all four cases:
 * old ->RESET-> old
	Same as now
 * new ->RESET-> old
	Same as now (since old receiver throws it away)
 * old ->RESET-> new
	new receiver notices the RESET is empty and supplies its
	own reason of "No reason was given."
 * new ->RESET-> new
	new receiver retains reason and gives it to the user.

The (Lisp Machine) network environment I work on normally use the
Chaos protocol, which does convey reasons (there are probably 2
dozen reasons, and each (non-LispM included) operating system has
its own little (valid) variants).  When we implemented TCP for
the LispM, it was always a sore point that we couldn't get any
useful information out of the other end, and had to turn off TCP
(TCP is a bit more efficient because it can use thrice as large
packets (on the Ethernet) as the chaos protocol) in order to try
again and find out THE REAL REASON the connection was refused or

Executive summary: I think this is upward compatible, optional,
and useful.  I think it should be adopted.  If somebody doesn't
think it is upward compatible, give me a proof.

Date:      Fri, 5 Oct 84 12:13:25 EDT
From:      Gary Delp  <delp@udel-ee>
To:        Mike StJohns <>
Subject:   Re:  information in RESET segments
The idea of one byte codes for the RESET REASON in rejected tcp segments
sound like a good one, although it could be extended the way (for instance)
SMTP works.  Use clear text for the number of  the error followed by 
implementation dependent text giving more information. (if appropriate ).

I am about to start debuging a TCP writen in Ada, running on the intel
432/670/330 system.  Having some clues available for the debugging
may well be helpful.  Is someone going to pursue this idea?

-Gary Delp <delp@udel-ee>
Date:      5 Oct 84 1412 EDT (Friday)
From:      don.provan@CMU-CS-A.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   maximum packet size
I hate to be obvious, but has anyone ever thought of adding an IP
option like the timestamp option where each machine along the
route fills in the maximum IP packet size it can handle for that
route?  We've talked and argued about the TCP packet size problem,
but I don't remember anyone suggesting this.  It seems like a
straightforward solution to all of these problems.
Date:      Fri 5 Oct 84 14:38:35-EDT
From:      Mark K. Lottor <MKL@MIT-XX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   SFTP

I would like to hear from anyone that is interested in
working on experimental SFTP implementations and discussing
problems and modifications to the protocol.

I have an almost complete SFTP server running on TOPS-20
but no user process yet. 

Please reply to me if you are interested.

Date:      Fri, 5 Oct 84 16:12 EDT
From:      Mike StJohns <StJohns@MIT-MULTICS.ARPA>
To:        "David C. Plummer" <DCP@MIT-MC.ARPA>
Subject:   Re: information in RESET segments
I take back my last point.  The standard nowhere defines the format of
the error message returned to the Upper Level Protocol.

Gary Delps idea sounds like a reasonable compromise.  Have a set of
"standard" error messages with their own individual numbers, but also
have a number which says "see the text for further details".  This makes
for a human friendly, as well as computer friendly interface.
Date:      5 Oct 84 1725 EDT (Friday)
From:      don.provan@CMU-CS-A.ARPA
To:        Mark K. Lottor <MKL@MIT-XX.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA,
Subject:   Re: SFTP
I've got a few comments on RFC913.

I assume that the idea behind LIST F is to do a multiple retrieve.
As given, it's no good for that between dissimilar machines.  There
are two reasons for this.  First of all, it requires the user process
to know something about the format of file names on the remote host.
If the user tells the user process to retreive all the files in
directory <foo>, the user process sends "List F <foo>".  Great.  Now
the server returns the "file names", so let's say there's one file,
RFC913.txt.  OK.  Now what's the user process supposed to do.  I'm
sure, just like with FTP, all you twenty user processes will
instantly retrieve <foo>rfc913.txt, but the fact of the matter is
that there are any number of ways to put the [foo] and the rfc913.txt
together.  The solution is so simple I always assumed that FTP and
SFTP (until I got to the examples) intended it:  return the full file
spec to the file.  After all, that's what the file name really is to
an external host, not just what us big boys that use DEC machines
know to be the name and the extension.  I should be able to start a
whole new connection in an entirely different user area and still use
the string from the first connection to name the file.  It MUST be an
absolute name.

The second problem with "List F" is that it limits what the server
process is allowed to take as an argument.  It must be a directory
path.  You almost never want to retreive all of the files in a given
directory.  I sometimes want to get all of the most recent RFCs:
"RFC91*.txt", but I NEVER want to get ALL of the RFCs.  This argument
should allow such operations.

I don't understand why "Stor Old" and "Stor App" aren't allowed to
check for such things as illformed file-spec or no write access to
the given file and return a "-" message.

Sort of fanciful idea, but it would be interesting to see if the SFTP
dialog could be made symetric.  The example that made me think of
this is that the server says, "55" in response to a RETR, but STOR is
followed by "SIZE 55".  Would there be any advantage in making the
STOR command be a request for the receiver to do a RETR, and then the
rest of the dialog go like a RETR, but with the server and user roles
reversed?  Probably not worth doing, but an interesting idea that
crossed my mind.
Date:      Fri 5 Oct 84 23:07:33-PDT
From:      David Roode <ROODE@SRI-NIC.ARPA>
Subject:   ["Frank J. Wancho" <WANCHO@SIMTEL20>: HOSTS Table size]
This sounds like a plea for conversion to a resolver accessing
distributed name servers instead of a host table.  Has anyone
installed such a scheme in a production host utilizing the 3 currently
running redundant instances of the experimental domain server?

Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Fri 5 Oct 84 21:44:33-PDT
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Oct 84 21:36:24-PDT
Date: 5 Oct 1984  22:38 MDT (Fri)
Message-ID: <WANCHO.12053169588.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
Subject: HOSTS Table size

Isn't anyone getting fed up enough when the HOSTS.TXT no longer fits
and a new MONITR has to be built again every so often, to rattle some
cages?  Or, have you all found an obsurdly high prime value that
you've never been bit?  If so, just tell all of us that number and
I'll go away quietly.  Then, the next time the table overruns, we can
all scream together....

Date:      6 Oct 1984 14:17:03 PDT
Subject:   Domain Servers Available

Hi.  Yes, three instances of a Domain Server are up and running.  They
systems, the implementation is written in pascal.  We are most interested
in having people write resolvers and test against these servers.  If you
do plan to write some code please check in with Paul Mockapetris at ISI to
get the details of some small differences from the initial specifications
(RFCs 882 & 883).  Paul is MOCKAPETRIS@USC-ISIF.ARPA.  A revised spec is
planned soon.

Work is also under way on a new implementation schedule for putting the
full domain name system into use.   That schedule should also appear
in the next few weeks.

Date:      Sat, 6 Oct 84 12:27:51 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        don.provan@CMU-CS-A.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  maximum packet size
The falacy in this and the reason for some other non-optimizations
in IP is that the packet may not traverse the same path everytime
through the net.  If the two routes have dissimilar MTU's your information
gained by the proposed ICMP RECORD-MTU packet would be invalid.
Better to have all the things that are playing gateway to act like
real gateways and to know how to fragment.  One of the reasons gateways
don't try and optimize by reassembling fragments is this.

A more useful option is one to ask the gateway what the MTU for the
intervening net is.  That way only one host need to know the "decreed"
route on the net.


Date:      Sat 6 Oct 84 15:25:55-EDT
From:      Mark K. Lottor <MKL@MIT-XX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        don.provan@CMU-CS-A.ARPA
Subject:   Re: SFTP comments
Here's some comments on your comments on RFC913:

First, the problem of LIST F not returning full file names:
If you just do a LIST F and take the list returned to use with
multiple retrieves it should work fine.  This is because you
are connected to the directory that the LIST F came from.
If you gave an argument to LIST F then before doing the
retrieves you can CDIR (connect) to the directory.
Your argument might still be valid and we'll see what happens
when we get some working implementations.

LIST F should probably be made to take any legal argument
that could be sent to the remote machines directory command.
This could be changed, and actually, my implementation
allows this.

You're right, STOR OLD and APP should allow a '-' reply.
That will be changed.

As for the comments on sending the size of the file
as in '55' or 'SIZE 55', this might help:  There is actually
a number sign before the '55', the valid replies are +,-,#,!.
I guess a number sign isn't a valid character in an RFC?

Other comments on the RFC:

I was working on an easier way to do logins and connects that
eliminates the '!' reply.  This would consists of sending
USER, ACCT, and PASS commands and receiving only '+' or '-'.
When you think you have sent enough the you would send
a LGIN command which would then return only a '+' or '-'.

In RETR, after you tell the remote host to SEND, it should
not just return the file.  It should return either a
'-' reply with an error message (ex. Can't read file),
or a '+' reply followed by the file and a null (for consistency).

A new RFC will probably be published once some implmentations
are running and have been tested.  Keep sending comments.

Date:      6 Oct 1984 21:16:18 PDT
Subject:   re: information in RESET segments

To help me think about this can some one give an example list of the things
that would be reported as "reasons" and what the TCP receiving these might
be expected to do about them?

Date:      7 October 1984 00:00-EDT
From:      David C. Plummer <DCP @ MIT-MC>
To:        StJohns @ MIT-MULTICS
Cc:        DCP @ MIT-MC, tcp-ip @ SRI-NIC, dcp @ SCRC-STONY-BROOK
Subject:   Re: information in RESET segments
    Date:  Fri, 5 Oct 84 16:12 EDT
    From:  Mike StJohns <StJohns@MIT-MULTICS.ARPA>
    In-Reply-To:  Message of 5 Oct 84 11:11 EDT from "David C. Plummer"

    I take back my last point.  The standard nowhere defines the format of
    the error message returned to the Upper Level Protocol.

    Gary Delps idea sounds like a reasonable compromise.  Have a set of
    "standard" error messages with their own individual numbers, but also
    have a number which says "see the text for further details".  This makes
    for a human friendly, as well as computer friendly interface.

Grumble.  This is not a negotiation.  That is my understanding of
why SMPT uses numbers: to negotiate various options and
alternatives and provide a standard for doing to.  There isn't
any dialog going on with RESET segments; one side tells the other
its a loser and that's that.

Just for grins, I counted the number of calls to
RESET-INCOMING-SEGMENT in my implementation.  There are 8 of them
in the TCP network level.  There are 2 occurances of
SEND-RST-FOR-TCB, both as part of the user's stream interface,
and these 2 get reasons from a higher level.

Date:      7 Oct 84 11:22:04 PDT
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: information in RESET segments
It seems like a great idea to me. I vote for both a machine readable
code and a text string. Several of our protocols have used that
approach. It works pretty well. A code lets machines make reasonable
decisions, and text conveys the fine print to a human.

Date:      Sun, 7 Oct 84 14:39 EDT
From:      Mike StJohns <StJohns@MIT-MULTICS.ARPA>
Subject:   Re: information in RESET segments
Reasons huh?  OK, here's a couple:

 1) No connection.  (In reply to any packet to indicate that the
receiving system didn't have a TCB it could direct the packet to.)
 2) Bad or Missing Security option.  (The receiving system was expecting
security option with the packet.)  3) Ack received, connection was in
LISTEN state.  4) Unable to establish connection, no resources.  (For
example, TELNETing to an already innundated system.)

This is just a partial list while perusing the MIL STD document.

As for the what the TCP receiving the reset would do about them...
generally all it can do is report it to the ULP.
Date:      Sun,  7 Oct 84 19:56:28 CDT
From:      Mike Caplinger <mike@rice.ARPA>
Subject:   Unix 4.2 remote copy and execution
I am currently attempting to implement a subset of the 4.2 BSD
rsh/rcp/rexec facilities for TCP/IP under VM/CMS.  Has there been any
attempt, or is there any interest, in trying to define these things in
an RFC?  While they are not particularly "Internet-flavored" they are
much more convenient.

There are of course a number of security issues, over and above the
protocol itself, that deserve discussion.

	- Mike
Date:      08 Oct 84 07:30:40 PDT (Mon)
From:      Marshall Rose <mrose@uci-750a>
To:        Mike Caplinger <mike@rice>
Cc:        TCP-IP@sri-nic
Subject:   Re: Unix 4.2 remote copy and execution
I'd be interested in seeing what you get.  Sadly, I agree that rsh/rlogin/rcp
work real well (I use telnet/ftp only when talking to non-BSD sites).  I think
if you hook up the "authorization protocol" discussed earlier with programs
that use the telnet and ftp protocols in such a way that it looks like 
rsh/rlogin to the *user*, you'd save a lot of work.  Nothing's wrong with
either telnet or ftp, I just can't stand the user-interfaces...

Date:      8 Oct 1984 10:17:35 PDT
Subject:   re: information in RESET segments

I don't see any use for a machine oriented code, since no one has suggested
what a TCP could do that depends on the reason received.

Date:      8 Oct 1984 1351 PDT
From:      Tuan Truong <TUAN@JPL-VLSI.ARPA>
To:        tcp-ip@sri-nic
Subject:   DECnet document
Does anyone have a copy of 

	DECnet-VAX Datalink Driver Specification

Is this one of those confidential documents?

Date:      8 Oct 84 1418 EDT (Monday)
From:      don.provan@CMU-CS-A.ARPA
To:        Mark K. Lottor <MKL@MIT-XX.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SFTP comments
re: your comments re: my comments re: your request for comments

There are two problems with the idea of using CDir (well, three, now
that  I think of it):  first, this only works if CDir takes the same
argument as List F, which it does according to the spec but which you
say it shouldn't and your implementation doesn't.  second, the SFTP
server can't pull the same trick that the tops-20 FTP server used to
(and for all I know, still does): it can't request a password to
change the directory.  Third, this requires that the SFTP user process
knows what the directory was that the user started in if it wants to
aboid changing things behind the user's back.

The larger question here is whether we should consider "file.ext" a
file name for an external entity.  I contend that for any external
process, the only file name a 20 should give out is dev:<dir>file.ext;version.
(well, if it has decnet, node::, i suppose).  Anything less than that
is giving some tops-20 (yes, admittedly, many other systems, too) idea
of what part of a file specification is the file name.  As the previous
note pointed out, this piece of information is of some value, but it
still seems to violate some concept of "keep your file system to yourself."

I just remember that the biggest reason I hated this idea in FTP was that
some systems allow a wildcarded file spec to include wildcards in the
directory specs.  If I tell a 10 to give me a directory of
"foo.*[757,7312,*,*,*]", it might respond with "foo.mac<crlf>foo.mac<crlf>
foo.mac<crlf>", which really gives me no useful information except that
somewhere in those subfile directories, there are three copies of foo.mac.
Obviously, this is completely worthless for a multiple retrieve, even
if there only one copy, and I just couldn't remember which subfile directory
it was in.
Date:      8 Oct 84 1510 EDT
From:      Rudy.Nedved@CMU-CS-A.ARPA
Subject:   Re: information in RESET segments
Can't you just look at Xerox BSP/RTP protocol design and use the same

"System unavailable for users; try later at XX:XX" can be used for
when people are debugging a system and some people are trying to
betwork in.

"Service unavailable, too many connections". Resource problems.

"Protocol transition error; ...." Can be used when some TCP is
talking to another TCP and it is doing something wrong...

I don't know if I would advocate changing TCP given how many sites
use it and who knows how many sites are extremely conservative in
what they receive...non-zero reset segments could break things. All
I can say is "it is a good idea".

Date:      Monday,  8 Oct 1984 19:12-PDT
From:      imagen!
To:        shasta!POSTEL@USC-ISIF.ARPA
Cc:        shasta!TCP-IP@SRI-NIC.ARPA,
Subject:   re: information in RESET segments

You asked for examples of what messages might appear in reset
statements.  Our TCP implementation does generate these messages
internally, for logging on the printer's console when in debug mode.
Here is a list of the resets that an imagen printer can generate.

* Received packet directed to bad port no.
	= no listener on destination port (bad demultiplex)

* ack of non-existent data
	= Ack numbers received  exceed next sequence number sent
	(protocol violation)

* Packet with no SYN and no ACK
	= protocol violation

* Open packet arrives without a syn in it
	= connection is not open, but no syn in packet (usually because
	  packet is from an older connection that was aborted).

* not accepting connections
	= no resources for connection (no TCB's, packet buffers, etc.)

Also, no message is logged when a higher level of software calls
tcp_Abort.  If there were a place to put the messages, things like
	* connection aborted by operator at console
	* higher-level timeout
would also exist.

- Geof Cooper
Date:      Monday,  8 Oct 1984 19:22-PDT
From:      imagen!
To:        shasta!POSTEL@USC-ISIF.ARPA
Cc:        shasta!TCP-IP@SRI-NIC.ARPA,
Subject:   re: information in RESET segments

What can a host do after interpreting the code in a tcp reset packet?

	[1] try again with tcp later if the error indicates lack of
	    resources and not lack of service (e.g., SMTP)

	[2] try XNS or DECNET or TFTP or RS232 ...

	[3] try to get the same service another way (e.g., send to LPT instead
	    of DIABLO)

General issue:

	Reset statements are generated for (at least) two generic
		- lack of resources (temporarily)
		- no such service (permanent)

In the latter case, a retry would have to be based on a total
replacement of the higher-level service (e.g., [2] or [3]).  In the
former case, a retry is suitable after a short while.

My philosophy on error codes vs. error strings is that error codes
should be as generic as possible and error strings as specific as
possible.  Error codes suggest a class of recovery from an error, while
error strings try to pinpoint the error for later (human) debugging.

I haven't been able to think of more than two error codes for tcp reset
statements (the others that come to mind can be generated directly by
the higher level and can use TCP to communicate the error before
connection termination).

- Geof Cooper

Date:      8 Oct 84 1659 EDT (Monday)
From:      don.provan@CMU-CS-A.ARPA
To:        Rudy.Nedved@CMU-CS-A.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: information in RESET segments
Actually, I can't find anywhere in the RFC that says a packet with
RST set shouldn't have any data.  As far as I can see, we can declare
any implementation that chokes on a data bearing RST to be in violation
of the protocol.  But I suspect most implementations, like mine,
automatically discard any data that is not otherwise dealt with.  I don't
think many implementations would break.  I say let's do it.  I think it's
a great idea.  Then we can have a fight over whether a SYN to a port
that I don't have a service for should be answered with an ICMP no port
or a RST with a no port explaination.  Hey, while we're at it, how about
sending additional information for destination unreachable messages?
Does this destination unreachable mean I don't have a path to that host
or just that that host is currently down?
Date:      Mon, 8 Oct 84 20:12:27 EDT
From:      Doug Kingston <dpk@BRL-TGR.ARPA>
To:        Marshall Rose <mrose@UCI-750A.ARPA>
Cc:        Mike Caplinger <mike@RICE.ARPA>, TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Unix 4.2 remote copy and execution
There IS something wrong with FTP and TELNET.  They force you to
send your password in plaintext.  What is really needed is a public
key encryption technique for verifying the identity of a user or a
host.  This particularly true now with lots of user operated workstations
on Ethernets and other "open" systems where all you need to do is
put your system into promiscuous receive mode.  The R* protocols are
not much better on nets using ARP because you can make your workstation
pretend it is some other host if the other host is down, but at least we
are no longer sending plaintext passwords.

More discussion and ideas if people are interested.

Date:      9 October 1984 01:46-EDT
From:      David C. Plummer <DCP @ MIT-MC>
To:        POSTEL @ USC-ISIF
Cc:        TCP-IP @ SRI-NIC
Subject:   re: information in RESET segments
    Date:  6 Oct 1984 21:16:18 PDT

    To help me think about this can some one give an example list of the things
    that would be reported as "reasons" and what the TCP receiving these might
    be expected to do about them?

Others have sent several possibilities for things that would be
reported.  All of the examples are for pretty low level things,
but a couple were higher up (e.g., "System not really up, try
again at XX:XX").  Most of those examples were refusals or
protocol errors.  There is another class: the connection is open
and one side abort closes.  Suppose the abort close happens
because of a program error or asynchronous condition.  The system
may be able to say "Connection closed because >>Error: the
argument given to SQRT, -4, was not a non-negative number, while
more information than the user wanted, but it sure is a lot
better than having the receiver of the RESET say "Connection
closed -- TCP can't convey reasons".

As you pointed out in a later message, you don't see what the use
of a machine readable form is.  I already grumbled about that
because there isn't any need.  This information is for a human's
benefit only.  I think that's also why nobody took you up on your
request to say what the TCP receiving these should do.  I'll tell
you: pass the string to the user if the application program can
handle accepting it.

As I said before, I believe this is completely compatible.  Don
Provan's message really warmed my heart; he seems to be in the
right spirit.

Maybe we'll get a friendly protocol out of this yet....
Date:      09 Oct 84 08:04:40 PDT (Tue)
From:      Marshall Rose <mrose@uci-750a>
To:        Doug Kingston <dpk@brl-tgr>
Cc:        Mike Caplinger <mike@rice>, TCP-IP@sri-nic
Subject:   Re: Unix 4.2 remote copy and execution
Well, then they're all busted since TELNET/FTP/SMTP/R* don't encode any data
at all.  So we hack FTP to encrypt my password as it goes down the pipe.
Fine.  Somebody can still snoop the files that get sent down the pipe later.
I'm not arguing security here, and I didn't say that TELNET/FTP/SMTP/R* were
secure.  What I object to is having to continuously type my password for each
FTP/TELNET session.  If we could get around that, I'd be happy (for now).

Date:      Tue, 9 Oct 84 08:58 EDT
From:      "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA>
To:        Mike StJohns <StJohns@MIT-MULTICS.ARPA>
Subject:   Re: information in RESET segments
Re StJohns error reason #2, bad security option:  in some cases, it
would be invalid to return this message, because the information may not
be returned to the user on the originating system.

However, it would be useful to LOG such information somewhere.
Associating machine-interpretable error codes with the messages allows
logging and censorship decisions to be made by the TCP.  The network
maintainer for a host may find logged information of this type useful
even when no information is ever returned to applications.
Date:      9 Oct 84 1124 EDT
From:      Rudy.Nedved@CMU-CS-A.ARPA
To:        imagen!geof@SU-SHASTA.ARPA
Subject:   Re: information in RESET segments
I would normally agree to have error code,,error string in an
ABORT packat would be a good thing because alot of protocols
use such a format....but I have been burned too often by
protocols trying to "recover" in a wizzy way and blowing it.

For instance, I don't recomend that mailers try every 2 minutes
for a system that has an error code that indicates it is
"booting" or "will be available shortly". It helps saturate the
network and does not handle a system that failed half way
into the boot.

I can bring up other examples from my networking experience at
CMU and they all seem to say "let the humans figure out why
the system is screwed....don't try fancy code analysis". One of
the best ones is our Laser printer support which is from Xerox.
It uses aborts to indicate how often some network process should
"beat on" the server to send the request. It also has several
codes that say whether to abort completely or
occasionally sends out complete aborts to valid requests losing
people's print request (but we hacked around it and ignored the
specification) and it occasionaly sends out "please try again
much much later" when it is only a temporary problem. The killer
is that we can't modify the software...since it is owned by
Xerox and we don't have rights.

Date:      9 Oct 84 1423 EDT (Tuesday)
From:      don.provan@CMU-CS-A.ARPA
To:        imagen!geof@SU-SHASTA.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: information in RESET segments
another generic reason for a reset is "I think we're confused" which
tells the TCP receiving the reset that the sending TCP doesn't think
the other side did anything wrong, the connection just got out of
whack. If the receiver tries again immediately, he has as much chance
of succeeding as if he waits a while.

Geof's message convinced me that at least it's conceivable that some
machine entity may want to know the reason for the reset.  But I
don't see any problem with adding this idea after we have some firm
ideas, as long as we agree now that error messages shouldn't begin
with digits.  Another possibility is to send the reason code in the
unused window field of the RST message.  Perhaps we could even add
those codes right into the TCP specs.
Date:      Tue, 9 Oct 84 17:45:55 EDT
From:      Dave Mankins <dm@bbn-labs-b>
Subject:   re: Public keys and R*
Funny you should mention public key systems on LANs of
workstations...Jeff Schiller and I came to the same conclusion in
discussing remote access on Project Athena's LANs.  I've implemented a
set of subroutines emulating 4.2 filesystem system-calls, but using UDP
datagrams to deliver the system calls to remote hosts on the network
(like the Newcastle connection or Purdue's IBIS).

The problem Jeff & I were discussing was: how do you prove that this
datagram is from the person it claims to be?  [Almost as important: how
do you do this efficiently and quickly] We are dealing only with the
authenticity of data, not it's privacy, allowing us to use a slower
encryption algorithm (another win is you don't have to authenticate
every UNIX system call--things like STATs can be done by anyone,
descriptor based system calls can use a faster private-key system (the
key is exchanged when the file is opened).  People who want privacy can
keep their data encrypted whenever it isn't on their workstation (I
have a scheme for doing this transparently, too, but it won't fit into
the margin).

Right now I'm tenatively looking at using digital signatures generated
using the Rivest-Shamir-Adleman public key system.  [The Hellman-Diffie
scheme is known to be breakable, and besides, I can't figure out how to
use it for digital signatures.]

It is not necessary to use a public key system: you can use a scheme
based on DES (or your favorite private key system).  If you have a
sufficiently trustworthy host (where "trustworthy" is defined as a
combination of physical and software security) it can serve as an
authentication manager, from whom you obtain conversation keys.  Andrew
Birrell and Bruce Nelson used a scheme like this in the remote procedure
call protocol they did at PARC.

They described a scheme for distributing conversation keys securely
(even in a public forum like the Ethernet) in the following way:

    Let "Crypt(text, Sue)" represent "text" encrypted with Sue's key.

    User Joe's process J wants to talk to user Sue's process, S.  J
    sends a request for a conversation key to the Authentication
    manager.  The Authentication manager replies with:

	    (key, Crypt("key,Joe" Sue))

    Which is encrypted using Joe's key.  Joe decrypts this message, and
    knows that this message is really from the Authentication Manager,
    because it is encrypted with his key, which only he and the
    Authentication Manager know (we hope).  Thus, the dialogue between
    the Authentication Manager and Joe is authenticated using Joe's
    private key.

    J sends Crypt("key,Joe" Sue) in clear-text along with its
    datagram request to S.  The datagram may be encrypted using the
    conversation key, or may just contain some digital signature
    generated using the key.

    S decrypts Crypt("key,Joe" Sue), and can now decrypt the rest of the
    datagram which was encrypted with the conversation key.  S knows
    that this message is REALLY from Joe, because only Joe could have
    gotten the key from the authentication manager, and only the
    authentication manager could have encrypted the key with Sue's key.

Or something like that.

Well, this solution isn't really very good for Project Athena, because
we don't really have any machines which are sufficiently secure (or even
reliable) to leave plain-text user keys lying around.  We're worried
about some student operator printing out the list of user's keys and
taping it to his or her dorm-room door.  There are other problems with
this scheme: key distribution, and a related problem, getting that
56-bit key into a public workstation in the library while you're using

It is, however, the solution I would recommend for any company building
a LAN with workstations in people's offices: once you've typed the key
in, you never take it out, you depend on the trustworthiness of your
computer operations staff to protect the authentication manager and hand
out keys.  Also, you are freed from lawsuits if the RSA algorithm is
broken.  That is, you aren't any more vulnerable than you were.
Another reason for going with this scheme if you can is the fact that
specialized fast DES hardware is likely to be more widely available than
RSA hardware, sooner.

While a public key system solves the file of plain-text keys problem, it
doesn't solve the getting-the-private-key-into-the-public-workstation
problem (indeed, the RSA scheme aggravates it: instead of being 56-bits,
it's now 200-600 bits!) 

But, with the public-key system, the user's private key can be stored
anywhere.  The private key is protected by being stored encrypted using
some more traditional technique (using more traditional keys like the
first-name of the user's girlfriend), and may be shipped to the user's
workstation in encrypted form when the user logs in.  Once on the
workstation, the user types the key which decrypts the private key, and
the private key may be stored in clear text in the workstation's memory
while the user is logged in, and may be referred to and inherited by the
user's processes.  Logging out may look very much like rebooting and
clearing the workstation's memory.  Or, that may at least be an option
available to the paranoid user.

Or, that's what I've been thinking about lately.  The only problem is
the RSA scheme too pretty slow to be applied to every system call.  As I
said earlier, one can try to be clever and authenticate only those
things that REALLY need it, but this is slightly inelegant, in that it
scatters te knowledge of what needs what kind of protection all over the
place, rather than localizing it in the place where the object being
protected lives.

Date:      9 Oct 84 2129 EDT
From:      Rudy.Nedved@CMU-CS-A.ARPA
To:        Dave Mankins <dm@BBN-LABS-B.ARPA>
Subject:   Re: Public keys and R*

What about people putting trap doors in the library software? What
about people that just want to disrupt service to your workstation
by sending lying aborts or setting up fake gateways? What about
systems that are network booted that people occasionally use to
talk to and login to their trustworthy hosts or workstations?

A serious network hacker for fun can violate all your systems
with partial or incomplete authentication and no one has addressed
the issue of figuring out if a gateway is "ok" or how to figure
out how to limit the effect of having some hosts encrypted and
some hosts not and someone putting trap doors in the insecure

There used to a phrase around CMU that went "Don't type anything
personal into a computer system or network." I believe it and
given some systems page off the network...and about trapdoors
in C-compilers. All bets are off. The best analogy I can think
up is trying to get rid of roaches in someone's can't
leave anything alone or they will infest again...the same is
true with all points on a network including connected networks.

The only realistic philosphy for security is to cover the obvious
holes and put in monitoring to catch the few that go thru the
semi-obvious holes before trying the very very sublte holes.

Date:      10 Oct 84 03:18:16 PDT
Subject:   Reassembly
Any historians in the crowd? I have a data point (confession?) to
contribute. Until last weekend, the reassembly code at XEROX.ARPA didn't

XEROX.ARPA is used only for mail. It processes roughly 1000 messages a
day. There was some confusion several months ago when something at BRL
caused them to fragment most packets. We were one of the sites that
didn't work. They undid that change before I tracked down our problems.

Over the past several months, I've fixed several problems in that module
whenever a crash rubbed my nose in a bug. Making sure it worked
correctly just never made it to the top of my stack.

Last Friday, I got a phone call from UCI. Their mail wasn't getting
through to us. (Our mail was getting to them.) Fortunatley, they gave me
a big clue by mentioning that a recent change at their end made it very
likely that their packets were now getting fragmented.

If you are looking for a convient test case, brew up a program that
talks to yourself, and then direct it to GOONHILLY-ECHO.

In the last 24 hours, we have received 33000 packets. 47 of them took
two fragments.
Date:      Wednesday, 10 Oct 1984 10:33-PDT
From:      imagen!
To:        shasta!
Cc:        shasta!TCP-IP@SRI-NIC
Subject:   Re: Reassembly - getting fragments

To get fragments sent to you --

	- modify your TCP to offer a MAXSEGSIZE greater than the MTU of
the connected network

	- connect to a vanilla 4.2 (telnet is ok)

	- generate a clump of data

That's how we do it on our Ethernet.  Some 4.2's have been fixed to
not generate fragments over the locally connected net.

- Geof Cooper
Date:      10 October 1984 12:51-EDT
From:      David C. Plummer <DCP @ MIT-MC>
To:        TCP-IP @ SRI-NIC
Subject:   information in RESET segments
My opnions about the recent rounds of mail on this subject;

Geof Cooper is wrong; there are many more than 2 clases of RESET
segments.  In fact, the two that he gave are specifically in
response to SYNs and doesn't take into account anything anybody
else has said in the last several days.

Rudy Nedved's comments are well taken: give a heuristic program a
chance to blow it, and sure enough...

J. Spencer Love's reasons for having a machine readable error
code is the only coherent reason I have seen.  Unfortunately,
even in the security violation case I think the application
should always get the string.  E.g., suppose I try to TELNET to
moderately-secure-installation and I don't have access.  It can
tell me I don't have access.  The NSA, on the other hand, might
always generate the string "Go away".  Note that for tha
paranoids, error codes are themselves information!

Date:      10 Oct 1984 2031 PDT
From:      Ron Tencati <TENCATI@JPL-VLSI.ARPA>
To:        tcp-ip@sri-nic
Cc:        info-vax@sri-kl
Subject:   Pinging gateways
I seem to be having problems with my routing table entries. Does anyone
know of any software that I can get my hands on that will let me "ping"
gateways?  We run the Kashtan 4.1c IP kernel under VMS 3.6. 

It sure would be nice if we could get rid of these annoying "network 
unreachable" messages... I need a way to verify that packets are making 
it to their destination. We need existing software, we don't have the 
technology to write our own.

Thanks in advance for any help.
Date:      10 October 1984 20:23-EDT
From:      John R. Lekashman <JRLK @ MIT-MC>
To:        tcp-ip @ SRI-NIC
Subject:   TCP/IP under primitive conditions
So, does anyone on this list know about partial
TCP/IP implementations (ie at least user FTP, and maybe even TELNET)
running on a PDP-11 with Rt-11 or TSX as the operating system.

Of course a more full implementation would be much nicer, but 
I don't expect miracles.

Date:      Thu, 11 Oct 84 12:41:35 CDT
From:      Paul Milazzo <milazzo@rice.ARPA>
To:        Rudy.Nedved@CMU-CS-A.ARPA
Subject:   Re: Pinging gateways

What Ron meant was that he wants a program with which can manually send
out pings and look for responses.  He is interested in using such a
program as a manual diagnostic aid for connectivity analysis, not part
of his standard operating procedure.  I'm sure that by now we're all
aware that pinging in the TOPS-20 sense is a bad idea.

Incidentally, the particular problem Ron wishes to diagnose is why,
after correcting his routing information, we (Rice) can connect to
JPL-VLSI, but JPL-VLSI can't open connections to us at either our
CSNET-PDN or RICE-NET address.  I've never seen this sort of asymmetric
behavior in a TCP/IP.  Does anyone out there have any ideas?

				Paul G. Milazzo <milazzo@rice.ARPA>
				Dept. of Computer Science
				Rice University, Houston, TX
Date:      11 Oct 84 1210 EDT
From:      Rudy.Nedved@CMU-CS-A.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA
Subject:   Re: Pinging gateways
You don't want to ping anything...all you do is clogg up the network
if everyone uses your solution. The best bet is to wait for the BBN
core gateways to get the "last bug" fixed where they forget about
little networks like MILNET. They seem to do a pretty good job... it possible that you have te version of VMS software that
does not have a default gateway and you have to specify for each
network a gateway? Maybe this is the problem...we had this problem
and we got errors like "network unreachable" or something.

At the moment, TOPS-20/TENEX BBN code has pinging in it for PRIME
gateways...for one site this caused their connected IMP to "freeze"
every so many minutes because the PING code was sending a massive
number of PINGs to a large number of gateways (of course the problem
was also one of incorrect "channel" usage and can sort of be avoided).

All and all PINGs by non-gateway hosts is a bad idea...especially for
them poor 9600 and 1200 baud links some folks (like us) have.

Date:      11 Oct 1984 1629-PDT (Thursday)
From:      Martin Fouts <fouts@AMES-NAS-GW.ARPA>
To:        Paul Milazzo <milazzo@rice.ARPA>
Cc:        TENCATI@JPL-VLSI.ARPA, tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA, Rudy.Nedved@CMU-CS-A.ARPA
Subject:   Re: Pinging gateways
     I don't have an idea, but I've got related problems.  We have
three vaxes here using the same MILNET Imp.  The VMS host can get
through to SRI-UNIX without problems.  Both of the 4.2BSD vaxes are LAN
gateways and running Kirton's EGP implementation.  One of the 4.2BSD
nodes can get through to SRI-UNIX, but nodes on its LAN can't.  The
other one can't get through at all.

     The error message is "connection timed out" in either case.

     Anybody got any ideas?

Date:      11 Oct 84 16:36 PDT
From:      Tom Perrine <tom@LOGICON.ARPA>
To:        UNIX-WIZARDS@BRL.ARPA, TCP-IP@SRI-NIC, LCROSBY@ALMSA-1.ARPA, John O'Donnell <multiflow!odonnell%UUCP@YALE.ARPA>, Barry Shein <root%bostonu.csnet@csnet-relay>, olympus!sauron!bob@ucbvax, rjh@crdc
Cc:        Tom Perrine <tom@logicon>, John Codd <john@logicon>, Roger Tjarks <roger@logicon>
Subject:   HyperChannel Summary
Well, after many false starts and two conferences to attend, I have
finally gotten the HyperChannel summary together.

I had 25 responses, describing connections between just about every
kind of system you can imagine.  Everything from UNIX to Multics, Cray

BRL is running a 4.1a driver on their homebrew V6+v7+sysIII UNIX
system.  Reportedly this is currently talking between VAXes and PDP-11s
and will soon include a Cyber 170.
(Douglas Kingston <dpk@BRL-TGR.ARPA>, Ron Natilie <ron@BRL-TGR.ARPA>,
Richard D.  Romanelli <romanelli@BRL-AOS.ARPA>) and Mike Muss

JPL is running Univac 1100s and and a Fujitsu 3033 clone.  (Matthew
Weinstein <matt@UCLA-LOCUS.ARPA>)

UCLA-LOCUS has tested HyperChannel between IBM 4331 running VM/370 and
VAX-11/750 running VMS.  (Barry Gold <lcc.barry@UCLA-LOCUS.ARPA>)

Linda Crosby (lcrosby@ALMSA-1.ARPA) reports that a company called "Uniq
Digital Technologies" is marketing a package that reportedly allows SYS
VR2 UNIX systems to use HyperChannel.  It look like they try to support
remote login to IBM TSO from UNIX (Yech!!!  -tep) Uniq's address is:
	Uniq Digital Technologies
	28 S. Water St.
	Batavia, IL 60510
	(312) 879-1008

Daivd L.  Gehrt (dave@RIACS.ARPA) reports that the NAS project at NASA
Ames is running HyperChannel between VAXes and a Cray.  He suggested
talking to creon@ames-nas-gw, who also responded with details:
VAX-11/780 running 4.2 plus the driver from Steve Glaser at Tektronix.

Tektronix is using HyperChannel to link seven Ethernet local-area
networks.  Some of the nodes are VAX-11/780s.  (Reported by Dave
Stewart <daemon!davest@CSNET-RELAY.ARPA, who suggests contacting Tim
Fallon <tektronix!timf>)

Peter Gross (hao!pag@seismo.ARPA) reposrts that he is using a
HyperChannel at NCAR (National Center for Atmospheric Research) to
connect two Cray-1a's, two VAX 4.2's, two VAX/VMS's, two IBM 4341's and
three PDP-11/70 Unix's.  (Whew!)

Mike StJohns (StJohns@MIT_MULTICS.ARPA) reports that the Air Force has
a HyperChannel made up of four Multics systems.

In almost every case, the respondents mentioned poor performance and
suggested using Ethernet of some other LAN instead of HyperChannel.
Specifically, Peter Gross mentioned that his 10Mb Ethernet outperforms
the 50Mb HyperChannel. 

I personally would like to run Ethernet instead, but the Government has
a few HyperChannel machines that we will have to connect to. *sigh*

My thanks to all who responded, as my apologies to those who think
this message was too long.

Thanks again,
		Tom Perrine
		Logicon - OSD
		Network and Secure Systems Department
		San Diego CA
		(619)455-1330 x 201

HyperChannel (in all its various spellings and capitalizations) is a
trademark or service mark or something of Network Systems Corp.

VAX, PDP and VMS are trademarks, etc. of Digital Equipment Corp.

Multics is a trademark of Honeywell.

UNIVAC is some kind of something to Sperry-Univac.

UNIX is a trademrk of AT&T Bell Labs (or whatever they call themselves
this month)

Cray is the name of a computer company and a person.

IBM is a trademark of International Business Machines.

Who cares about Fujitsu?

CDC and Cyber have mystical meaning to Control Data Corporation.

Date:      11 Oct 84 1436 EDT
From:      Rudy.Nedved@CMU-CS-A.ARPA
To:        Paul Milazzo <milazzo@rice.ARPA>
Subject:   Re: Pinging gateways
Well. Yesterday CMU-Gateway stop getting routing updates for MILNET
from the core gateway that we get information from for about 4 hours.

The result was that CMU-CS-A (ARPANET) could not talk to CMU-CS-B
(MILNET) but CMU-CS-B could talk to CMU-CS-A. The subtle difference
(I believe) is that the TOPS-10 code will use the IMP/port
information it keeps on active connection when sending a
response....and uses its assigned gateway when it initiates a
connection. Given that if you give a packet to a one of your two
assigned ARPANET/MILNET tends to deliver it even though
the core gateways don't tell anyone else about its delivery ability.

I don't like the situation and wish there were "fixes" but one must
recognize that the "growth" of the Internet structure has been like
an explosion...kinda of unexpected....the core gateways and other
gateways are having a problem dealing with the information (that is
why I like the concept of hiding as much internal network structure
as possible from external gateways).

Date:      11 Oct 84 14:55:42 EDT
From:      dca-pgs @ DDN1.ARPA
To:        tcp-dig @ DDN1.ARPA, hawgs @, tcp-ip @
Subject:   3rd-Party TCP/IP LAN for IBM VM and IBM PC

From  MISWeek, 10 Oct 84, p. 34:

"Spartacus Computer (of Bedford, MA) ...
is now entering the LAN marketplace with
hardware and software offerings. 

Its first product line in the LAN market
includes an Ethernet controller, called the
'K-200', a new software pkg called 'KNet', (and one)
called 'KNet/PC', (so that) an IBM PC can operate
as a host on an Ethernet. ...

... [A typical config is priced at] $24500.


The article goes on to say that KNet and KNet/PC 
both include TCP/IP. KNet runs as an application
under VM/SP and supports FTP, TFTP, and Telnet.
KNet/PC supports TFTP and Telnet.

The KNet/PC is very likely the MIT PC package
that Proteon was also marketing with the ProNet.
I'm not too familiar with KNet/VM, except that
I'm pretty sure that it's not the WISCNET package.

Things conspicuously absent from the press release:
-SMTP. Wasn't mentioned.
-Any sort of operational history or testing
 in an Internet environment.
-Plans for a mainframe-to-IMP interface.
 (An immediatee thought would be running KNet+K-200
  into an Ara## Arpa gateway)

I mention these things because there's been a tendency
for some vendors to "  christen some things "TCP/IP"
with no operational evidence that they will work
on the Internet or in an Internet environment.

Still, I hope someone will explore this; it looks
interesting. I heard that Spartacus was OEMing this
package to ComputerVision and that they had shipped
a number of copies already.


Good hunting,
-Pat Sullivan

Date:      11 Oct 1984 17:17:24 EDT
To:        JRLK@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP under primitive conditions
In response to the message sent  10 October 1984 20:23-EDT from JRLK@MIT-MC


See the file DCNET.DOC in the FUZZBALL directory at ISID for a description
of the "fuzzballs," which mumble IP/TCP and a few other things in an
emulated RT-11 environment. See HELP.DOC in the same directory for details
on the commands and application protocols.

There are fuzzballs now all over the place - CMU, Wisconsin, Michigan and
Maryland U's, DARPA (IPTO), Ford (Motor and Aerospace), Linkabit, NTARE 
(Norway), DFVLR and USECOM (Germany) and soon at CNUCE (Italy), to name a few.
Notice the plague is creeping eastward...

Date:      Thu, 11 Oct 84 21:48:29 EDT
From:      Mike Muuss <mike@BRL-TGR.ARPA>
To:        Paul Milazzo <milazzo@RICE.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, info-vax@sri-kl.ARPA, unix-wizards@BRL-TGR.ARPA
Subject:   Re:  Pinging gateways
For 4.2 BSD, BRL has a program called "ping", which allows
you to measure connectivity, round trip time, and packet loss.

Source is availible on BRL-VGR and BRL-TGR via anonymous FTP.

We also have in development a program to make sure that the
"default route" is working, and to switch among a set of them
in event of failure.  We will probably put this program into
production in a week, and will distribute in November.

Date:      Fri, 12 Oct 84 10:05:59 PDT
From:      Barry Gold <lcc.barry@UCLA-LOCUS.ARPA>
To:        unix-wizards@brl, tcp-ip@sri-nic, LCROSBY@ALMSA-1, multiflow!odonnel%UUCP@YALE, root%bostonu.csnet@csnet-relay, olympus!sauron!bob@ucbvax, rjh@crdc
Cc:        tom@logicon, john@logicon, roger@logicon
Subject:   HyperChannel Summary--CORRECTION
The experimental hookup of VM/370 and VMS via a Hyperchannel was done at
SDC (System Development Corp.) in Santa Monica, NOT at UCLA-LOCUS as Tom
Perrine's summary suggested.

Date:      Fri, 12 Oct 84  8:25:47 EDT
From:      Michael Brescia <brescia@BBNCCM.ARPA>
To:        imagen!
Subject:   Re: Reassembly - getting fragments
To get IP fragmentation without modifying your system, you can telnet
(or ftp) connect to host 'etam-echo', 'satnet-echo', or 'goonhilly-echo'
or 'tanum-echo'.  The Maximum Transmission Unit (MTU) on satnet is 256
bytes, which is among the smallest of nets.

In each case, you will find yourself connected to your own host, then
log in and start up data.  With telnet, typing a page of text out is
usually sufficient to send many packets which get fragmented.  If
reassembly is not working in your host, you see the connection hang.

The differences in the 'xx-echo' hosts are the length (time delay) of
the paths.  'etam-' is near the arpanet, less than one second delay;
'satnet-' is one satellite hop, 'goonhilly-' and 'tanum-' are two
satellite hops.  Each hop adds about a second to the round trip.

I hope your best test monitor is your own implementation (of TCP/IP).

Date:      12 Oct 84 08:35:27 EDT (Fri)
From:      Dan Grim <grim@udel-ee>
To:        Paul Milazzo <>
Cc:,,,, grim@udel-ee
Subject:   Re: Pinging gateways
We saw exactly the same behavior here at Delaware when machines on
two separate local nets could not connect in one direction when they
could in the other.  Our problem turned out to be that one of our
multiply connected machines (arpa and local ethernet) was sending its
arpa internet address as the source address in the IP packets and the
machine on the other local net apparently had the wrong routes installed
to reply.  That machine could reach other arpa hosts however so it is
not as simple a problem as it may seem.  The outcome is that routing on
intermediate hosts seemed to be able to cause the assymetric behavior.

				Dan Grim <Grim@UDel>
				Dept of Electrical Engineering
				University of Delaware
Date:      Fri, 12 Oct 84 12:39:15 edt
From:      God <>
Subject:   Re:  3rd-Party TCP/IP LAN for IBM VM and IBM PC
	Boston University will begin beta-testing the
	SPARTACUS box on our 3081 (VM) later this month.
	Part of the beta testing will be pieces of the
	application environment (eg. FTP, TELNET.)

	No, it is not WISCNET (we will be running that also
	and doing comparative benchmarks across a DACU.)

	The ethernet these will be attached to will be running
	4.2bsd hosts and a TOPS-20/NI20. In addition two of
	our 4.2bsd hosts can (do) act as gateways to the
	UNGERMANN/BASS broadband running our driver out to/from
	both 4.2bsd and VMS/Wollongong.

	If there is an interest I will be happy to summarize
	our experiences from time to time to this audience.

	We have no current plans to use the IBM/PC interface.

		Barry Shein
		Distributed Systems Group
		Boston University

Date:      Friday, 12 Oct 1984 17:55-PDT
From:      imagen!
To:        shasta!TCP-IP@SRI-NIC
Subject:   Spartacus TCP/IP

Apparently, Spartacus is selling a real TCP/IP implementation for
VM/370 systems, but the software currently lacks ARP--you have to
hardwire ARP-equivalent information.  They've gotten it talking to SUN,
Apollo and Masscomp workstations, as well as the MIT PC/TCP software,
from what I've heard.

They designed, and now manufacture, their own channel-to-Ethernet
adapator board.

Isn't someone out there watching who knows more details?  (Doesn't
Symbolics have a K102, or whatever they called their now-defunct
mini-370 product?)

--Chris Ryland, IMAGEN
Date:      Sun, 14 Oct 84 19:57 EDT
From:      "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
To:        "David C. Plummer" <DCP@MIT-MC.ARPA>
Subject:   re: information in RESET segments
How about a code at the front of the RST packet telling something about the
text in the rest of the data.  If the code is zero, the RST is unexplained.
Otherwise the rest of the packet contains textual information to be passed to
the application (if that capability exists.)

The code would be some standardized number (machine-readable frob) telling
what software layer (Application, TCP, IP) "caused" the RST, and some very
general reason such as: System Not Up, Protocol Violation, Internal Bug
Detected, Operator Aborted Conn, Random.

The code is a gross discriminator for the otherwise unexplained Abort-close,
and I can imagine various different software layers examining it and taking
some alternate or additional action besides presenting the error text string
to the user.

Examples of actions which might be taken include: make a log entry of some
kind; inform the user that the foreign host thinks there is a bug somewhere
and that some maintainer should be notified; or even send bug reporting mail
automatically (many programs on our system do this sort of thing when internal
impossible-condition bugs are detected).


Date:      Mon, 15 Oct 84 10:21:03 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        dca-pgs@DDN1.ARPA
Cc:        tcp-dig@DDN1.ARPA, hawgs@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, navyusers@DDN2.ARPA, afusers@DDN2.ARPA
Subject:   Re:  3rd-Party TCP/IP LAN for IBM VM and IBM PC
Sounds like something you'd buy at K-Mart.

Date:      Thu, 18 Oct 84 17:01:39 edt
From:      glenn@LL-XN (Glenn Adams)
To:        tcp-ip@sri-nic.ARPA
Cc:        hostmasters@sri-nic.ARPA
Subject:   RFC811 and VERSION keyword
In an attempt to automate retrieval of the NIC host table, I attempted
to utilitze the VERSION keyword mentioned in each message received from
NIC indicating that a new host name had been installed.  However, upon
attempting to use this keyword, I find it is not implemented, nor is it
mentioned in RFC811.

Does it really exist?  Can it be added?  My purpose for using it would be
to maintain a local version number and query the hostname server on
a regular (daily?) basis for any changes in the version.  If, and only if,
the version was updated, would the entire table be retrieved.

Glenn A. Adams
MIT - Lincoln Laboratory

Date:      Thu, 18 Oct 84 20:10:05 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        little@DCN5.ARPA
Cc:        header-people@MIT-MC.ARPA, msggroup@BRL.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Virtual Terminal Protocol
Actually, the WISCNET software that allows you to use TCP/IP to IBM-370
series machines running VM/CMS does this.  They have an option negotiation
that says "do 3270 style stuff" and from then on send 3270 control messages.

I have been meaning to try to simulate the user end on UNIX with a termcap
driven user telnet, but haven't gotten around to it.

Date:      19 Oct 1984 01:11-PDT
To:        little@DCN5
Cc:        header-people@MIT-MC, msggroup@BRL, tcp-ip@SRI-NIC
Subject:   Re: Virtual Terminal Protocol
Msggroup and header-people are both the wrong lists for this topic.

Please, everyone (and especially those of you who we all know know better),
refrain from dumbly copying these two lists on replies, just because
the originator did not know better.

I can understand innocent new netmail users making such an error, but
I cannot understand why knowlegeable people blindly continue?

Thanks for your forebearance, and your consideration.  Stef
Date:      18 October 1984 23:12-EDT
From:      Christopher C. Stacy <CSTACY @ MIT-MC>
To:        glenn @ LL-XN
Cc:        hostmasters @ SRI-NIC, tcp-ip @ SRI-NIC
Subject:   RFC811 and VERSION keyword
My automated host retrieval program uses the VERSION command and works fine.

Date:      18-Oct-84 19:33:35-UT
From:      little@dcn5
To:, msggroup@brl,
Subject:   Virtual Terminal Protocol
I am attempting to create a virtual terminal protocol (VTP) with emphasis
on solving problems created by forms mode type terminals (eg-3270).  I
currently view the problem with the following breakdown -

		Graphical (Character) Representation
			code for information exchange (agreement)

		Control Domain and Exercising
			modal operation
			transfer requests
			function keys
			out-of-band signals

			cursor addressing
			end-of-line/screen condition
			presentation attributes

Does anyone have any interesting thoughts or know of problems they are having
in this area?? (or are header/TCPIP/msg people the right people for this sort
of thing?)

Specifically - what problems do you have with TELNET??

Are there deficiencies you would like to overcome with TELNET or RFC 731?

Also, does anyone have access to the new VTP spec put out recently by the
Terminal Repertoire Committee of ANSI (chaired by Henry Lowe -DEC)?

						Mike Little - LINKABIT@DCN5
Date:      19 Oct 1984 1020 PDT
From:      Ron Tencati <TENCATI@JPL-VLSI.ARPA>
To:        tcp-ip@sri-nic
Subject:   Nicname VERSION command

I have used this command by connecting to SRI-NIC port 101.  It works fine
for me..

Date:      19 Oct 1984 at 1009-EDT
From:      hsw at TYCHO.ARPA  (Howard Weiss)
To:        tcp-ip at nic
Subject:   TCP/IP for RSX
One of my associates expressed an interest in obtaining a TCP/IP implementation
for a PDP 11 running RSX-11M.  There appear to be several RSX systems listed
in the NIC host table.  Could one of the RSX TCP/IP gurus please advise
me as to the availability of the protocol suite.

Many thanks,

Howard Weiss

Date:      19 Oct 1984 1321-EDT (Friday)
From:      James O'Toole <james@gyre>
To:        glenn@LL-XN (Glenn Adams)
Cc:        hostmasters@sri-nic.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: RFC811 and VERSION keyword
The VERSION keyword is working just fine.  I have automated table
updating on all our 4.2bsd unix machines running now, if you want it.

Date:      20 Oct 84 18:16:42 PDT (Sat)
From:      Jim Guyton <guyton@rand-unix>
To:        tcp-ip@sri-nic
Cc:        guyton@rand-unix
Subject:   Wanted: Ethernet Terminal Servers
I'm aware of Interlan and Bridge terminal servers, but
I'm looking to buy (or build) one that talks real TCP/IP.

Anyone else trying to do this?

-- Jim Guyton
Date:      20 Oct 1984 17:39-EDT
To:        little@DCN5.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Virtual Terminal Protocol

There  are  currently three main virtual terminal standardization
activities internationally, all of which  are  currently  in  the
working draft stage.

ISO is working on a Basic Class Virtual Terminal, which is really
equivalent  to  Telnet,  hence  would  not  be  functionally  too
interesting to someone interested in Forms Class.  Mike, I have a
copy of the just-released Service Definition for the Basic Class,
and  I  can  send  you  a  copy  if you will send me your correct
mailing address.  Then other people could get a  copy  from  you.
This  is  the  latest  internal  committee  working  draft of the
service definition: in  ISO,  the  "service  definition"  is  the
specification of what service a functional entity provides to its
user, and the "protocol specification" is  the  specification  of
the  data  units  exchanged  between peer entities cooperating to
provide the service.  In this case, the service  is  provided  by
Virtual  Terminal  Application  Entities (VTAEs) operating in the
Application Layer, using the services of the  Presentation  Layer
to  communicate  with  each  other  (to allow for syntax matching
between  dissimilar  machines).   The  Service   Definition   and
Protocol  Specification  for  Basic  Class  are  aiming  at Draft
Proposal status in March 1985.

ECMA (European Computer Manufacturers Association) is working  on
Forms  Class.   Their work is intended to be compatible with that
of ISO.  I don't know what the status  is.   In  both  the  above
cases,  try  contacting  Henry Lowe at DEC in Maynard, Mass.  for
more info.

There is also a New Work Item called Computer Graphics  Interface
in  ISO,  aimed at providing the virtual device interface for the
GKS (Graphical Kernel System) standard for interactive  graphics.
Now that GKS is an ISO standard, the CGI work (which is logically
the carry-on of the Virtual Device Interface Project of ANSI into
the  international  arena) is expected to get a lot of attention.
Try contacting Peter Bono at Graphic Software  Systems  in  Gales
Ferry, Conn.  for more info.

I'm afraid that none of these standardization activities would be
stable enough for even trial implementations before  1986.   Hope
this info is helpful anyway.

--Dick dJ
Date:      Sun Oct 21 14:28:13 1984
From:      Martin Lee Schoffstall <cadmus!schoff@seismo.ARPA>
To:        cadmus!seismo!tcp-ip@nic.ARPA
Subject:   telnet/tcp/ip ethernet terminal servers
Both Bridge and Interlan are working on this, though Bridge is much
closer to a product.  It will be based initially on their big box
(GS/1???).  Back in May I had some very intense discussions with
Ed McHugh (Director of Software Engineering @ Interlan) about taking
the NTS10 and doing the above.  They thought XNS was so wonderful and
IBM's ring was so imminent that they didn't want to commit their
resources to this speculative protocol.  Ed McHugh is leaving Interlan
shortly to return to PR1ME and they are now working in that area.  To
bad they wasted 6 months.  One other company with a lot of IP experience
will announce a product shortly which I am not at liberty to divulge.


Date:      Mon 22 Oct 84 14:24:42-PDT
From:      Ken Harrenstien <KLH@SRI-NIC.ARPA>
To:        don.provan@CMU-CS-A.ARPA, ron@BRL-TGR.ARPA
Subject:   Re: Host Table - Version #393
	Don.Provan is correct.  The string returned by VERSION is not
defined at this time.  It need not even be a numerical string.  If it
is in any way different from the previous string you recorded, you
should get a new copy of the host-table information.
	It's easy to see, though, how someone can make the empirical
assumption that the string is always a number which always increases.
The VERSION keyword was a feature added after the RFC came out.
I'll ask that the "new-table-available" message broadcast from HOSTMASTER
be modified to both avoid this implication and to mention that HELP is
available as a keyword.
Date:      22 Oct 1984 14:37 PDT
From:      Lars Poulsen <LARS@ACC>
To:        TCP-IP@SRI-NIC
Subject:   Telnet/tcp/ip/ethernet servers
What functionality is it that we are talking about here.
Do you really mean SERVER as in something that will accept
TELNET connections and pass them on to a host on async 
terminal lines plugged in to the hosts async distribution
panel ?
Or do you mean terminal concentrator, a device that has
async terminals wired to it and lets those terminals access
hosts that somehow have telnet server software on them.

I can see a market for a terminal concentrator; but not
really for a server.
			/ Lars Poulsen
Date:      Monday, 22 Oct 1984 15:03-PDT
From:      imagen!
To:        shasta!tcp-ip@sri-nic
Subject:   TCP/IP terminal servers
I hear that Bridge has such a beast.  415-969-4400.
--Chris Ryland, IMAGEN
Date:      Mon, 22 Oct 84 13:53:19 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
Cc:        TCP-IP@sri-nic.ARPA
Subject:   Re:  Host Table - Version #393
When it becomes necessary to revert to an older host table due to errors
in a newly released one, it would be better to supercede the defective
one with the old one (with a higher version number).  Our host table
retrieval is entirely automatic.  If you back up to a previous table,
we will never use it, because we will not use a host table with a version
number less than the one we already have.

This is the reason the VERSION number was put in to begin with and it
was stated then that the numbers would always be increasing.


Date:      22 Oct 84 1500 EDT (Monday)
From:      don.provan@CMU-CS-A.ARPA
To:        Ron Natalie <ron@BRL-TGR.ARPA>
Subject:   Re: Host Table - Version #393
i seem to remember seeing several times that the value returned by
the version command is undefined and should only be checked for
a change.  if ANYTHING changes, you must assume that it's a new
version and grab it.  presumably the current practise is designed
to avoid having a site that never noticed the bogus version from retrieving
a new copy of the version it currently has.  (no doubt, it's also easier
to keep track of versions back at NIC, too.)  i think this is perfectly
acceptable behavior and see no reason for it to change.  i don't see
why you would ignore old version, anyway.  if the current version is
older than the version you have, that's no reason to think your version
is better.  in fact, there's every reason to believe the opposite, since
YOUR version is not the CURRENT version.
Date:      Mon, 22 Oct 84 16:09:27 edt
From:      Alan Parker <parker@nrl-css>
To:        guyton@rand-unix
Cc:        tcp-ip@sri-nic
Subject:   ethernet terminal servers
A dealer is bringing a Bridge terminal server out here next week for a
demo.  He claims it talks TCP/IP.   I intend to plug it into my
ethernet and try it out.   I'll report what I learn.

[He sent me a document dated Sept. 1984 from Bridge, called TCP/IP
Compatible Terminal Server, CS/1-A with TCP/IP software.  It looks like
the same terminal server hardware they have been selling with new

Date:      22 Oct 1984 1959-EDT (Monday)
From:      James O'Toole <james@gyre>
To:        tcp-ip@sri-nic
Subject:   Automated table updating
If you want my automated table updating as is, ftp the tar file
from Gyre; anonymous ftp, and the file is in pub/netmap.dist.
Just extract the tar file into /etc/netmap on your machine and read
the README files.

Date:      22 Oct 1984 2137-EDT (Monday)
From:      James O'Toole <james@gyre>
To:        don.provan@CMU-CS-A.ARPA
Cc:        HOSTMASTER@SRI-NIC.ARPA, TCP-IP@sri-nic.ARPA, Ron Natalie <ron@BRL-TGR.ARPA>
Subject:   Re: Host Table - Version #393
I too have seen somewhere that the string returned by the version command
to the hostnames services was only guaranteed to be unique.  Does anyone
remember where this is stated?  I just checked RFC811 and didn't see it.

Still, since the NIC is still (right now) returning 393 as the version
string, we should not be told to use version 392.  Whether the NIC chooses
to re-issue 392 as 394, or just change the version string (and the table)
back to 394 doesn't matter.  But don't just leave the wrong table out there,

Date:      Mon, 22 Oct 84 22:32:52 EDT
From:      Doug Kingston <dpk@BRL-TGR.ARPA>
To:        Alan Parker <parker@NRL-CSS.ARPA>
Cc:        guyton@RAND-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  ethernet terminal servers
Neat!  Keep us informed...

Date:      Tue Oct 23 23:26:50 1984
From:      Martin Lee Schoffstall <cadmus!schoff@seismo.ARPA>
To:        cadmus!seismo!tcp-ip@nic.ARPA
Subject:   terminal concentrators or terminal servers
What we are talking about is a terminal concentrator, the
equivalent of a BBN TAC for an ethernet.  I'm not so sure that you
are correct about the market for servers though.  You would be amazed
how many networks are connected via a RS232 line.  Most people have
these; standard buses, operating systems, understandable manuals are
scarce and hence hinder (at least for a time) rational network
connections.  In fact BBN has modified the C/30 TAC to ACCEPT telnet
connections and use an "available" rs232 connections port.  I know at least
one site who has waited for so long for ATT to deliver a SysV ip/tcp
for their 11/70 running SysV that their TAC is configured that way.
Another has it going to their develcon??? switch.



Date:      Wed 24 Oct 84 02:54:40-EDT
From:      Mark K. Lottor <MKL@MIT-XX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   SFTP mailing list

There is now a mailing list for discussion of
anything related to SFTP/RFC913.

The list is: SFTP@MIT-XX
All requests to be added or deleted to: SFTP-REQUEST@MIT-XX

Date:      Thu, 25 Oct 84 16:56 PDT
From:      Provan@LLL-MFE.ARPA
Subject:   RFC810 table parsing
we're considering using the RFC810 format for our non-IP/TCP network.
i'd like to hear comments on that if anyone has any, but i have more
specific questions that cause me to write this note.

first off, since our network is not in the Internet, it doesn't have
a network number.  i don't think we'll be able to convince NIC to give
us a number without having a network, and i was scared off by the big
long form they wanted me to fill out to get a number.  what should we
use in the 810 tables for our network numbers?  right now we plan to
use 255.x, thereby making it completely illegal (for now) in the
internet world so no one could ever get confused by it.  any comments?

more importantly, since we're using this format, we'll need to parse it.
is there any chance someone out there has a Bliss parser already written?
barring that, are there any available C parsers for it we can get a hold
Date:      25 Oct 1984 17:37:48 PDT
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: TCP MSS Option

see also RFC 879.

Date:      25 Oct 1984 1926-EDT (Thursday)
From:      jnc@MIT-CSR
To:        tcp-ip@nic
Cc:        jnc
Subject:   TCP MSS Option
	We have recently apparently been seeing problems due to
certain cross-purposes in the IP and TCP specifications about
the maximum segement size. (This is NOT about what size packets
hosts or gateways have to accept from the local net, about which
there has been much discussion; this has to do with end to end
	According to the IP spec, nobody is supposed to send anyone
an IP packet of larger than 576 bytes without approval; see page 13
of that spec. In the case of TCP this is done via a MAX-SEG-SIZE
negotiation; the wording in the TCP spec is fairly plain, and what
it says is that unless you do this negotiation any segment size is
acceptable. Now, taken literally, this would mean that I can
send everyone 65K byte packets, unless they say otherwise. This,
while perfectly acceptable under a strict interpretation of the
spec, contravenes in spirit a guiding principle of TCP, enunciated
on page 13: "be conserative in what you do, and be liberal in what
you accept from others." My interpretation of this would be to
not send TCP segments of larger than 576 bytes unless I had received
from the other end a MSS option which positively told me that the
destination could accept packets larger than that.
	The problem that happens is that the disease that happens
to, e.g. mailers, when they try to send a message using 1000 bytes
segments to a host that only accepts 576 byte packets, is truly
awful. The connection opens OK, some data is sent, the packet is
dropped at the destination host with a hardware error, is retransmitted
several times, and then eventually the connection times out. The
mailer marks this as a temporary error, and tries again, and again,
and again, and again, etc. Some mailers (e.g. the TOPS-20 one) recognize
this symptom and try the 'individually PUSHed 40 byte segments', for
those of you who have seen that delightful error message, but others
just keep on mindlessly trying and eventually drop the mail.
	I wish they had written the spec to default to 576 rather than
anything, but it's a bit late now. However, can we agree to apply the
Robustness Principle and chose not to excercise that option in the
hopes of assuring operation?

Date:      25 Oct 1984 2235-EST (Thursday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        JNC@MIT-XX.ARPA
Cc:        tcp-ip@nic.ARPA
Subject:   Re: TCP MSS Option
Didn't Postel write something up about this very point? I have
reference of <INC-PROJECT, MAX-SEG-SIZ.NLS.14>. I think it said that
the deafult maximum segment size, if no negotiations are done, is 536.

Date:      Fri, 26 Oct 84 08:54 PDT
Subject:   Re: Virtual Terminal Protocol

Your original message said you are "attempting to create a virtual
terminal protocol (VTP) with emphasis on solving problems created
by forms mode type terminals (eg-3270)."   I wonder who will be the
market for this VTP?  The DET (Data Entry Terminal) option of
TELNET was designed millenia ago to solve this problem; it seemed
like a good idea, and is (as far as I know) adequate to the problem.
It has never been implemented, due to the ASCII orientation of the
ARPANET research community.  Now that the Internet is moving into
the REAL WORLD of MILNET, of course, there is a new interest in
providing communication services for IBM systems.  In fact, there is
an implementation of DET in progress; INCO is doing it for some
government agency.

Meanwhile, the sites with IBM hosts in the research community are
taking an end run around the problem.  As pointed out in a message
from Ron Natalie, the Wisconsin VM software encapsulates 3278 orders
within a binary-mode TELNET stream.  At UCLA, our OS/MVS version of
the Internet protocols has now been extended to support this same
encapsulation mode (both this effort and the Wisconsin development
were sponsored by IBM).  We have demonstrated interoperation between
VM and MVS across the Internet, using 3278's in full-screen mode.
We and Wisconsin have not yet reached complete agreement on some
details of the protocol (e.g., VM and MVS differ in what they
consider to be valid 3278 order codes).  I expect that we will
resolve these issues in the next few months, and publish an RFC
defining the encapsulationof 3278's within TELNET.

Undoubtedly this message will ignite a flame from some hothead on
a UNIX system, to the effect that we are supporting IBM 3278's
rather than interoperability of different 3278-like devices. Yes,
this is a pragmatic way to support a single community of users on
MILNET.  It recognizes reality without endorsing it.
Since the transparent 3278 operation is based upon TELNET,  we are
never far from an NVT.  In fact, the MVS User and Server Telnet
happily negotiate back and forth between normal NVT and transparent
3278 operation (one of the incompatibilities is that the VM code
cannot negotiate back out, yet).  I would argue that DET is just
too complex, and the encapsulation mode solves what is pragmatically
the real problem, in a straightforward and efficient manner.

The advantage of a common protocol like DET is that is solves the
"n-squared" problem of different terminals communicating with different
hosts.  This is a nice theoretical argument which I generally accept,
but in the case of IBM 3278 support the situation is really simpler.
An IBM server host is going to be accessed from a 3278 (of whatever
brand name), from an ASCII CRT, or from an ASCII line terminal.
Encapsulation handles the first case. For the second, there is a
software conversion package (SIM/3278) which an IBM host can run
to emulate a 3278 on an ASCII CRT. Finally, all IBM hosts support
normal NVT access.

Sometime in the future, the emergence of standards and the ability
of the production side of DoD to fund large and complex sofware
development efforts may make a common DET (-like) protocol
implementation attractive.  In the meantime, I believe the problem
is under control in DDN.

Bob Braden

Date:      26 Oct 1984 10:04 PDT
From:      Art Berggreen <ART@ACC>
To:        tcp-ip@sri-nic
Cc:        unix-wizards@brl
Subject:   4.2 RFNM count problem
Recently several people have remarked on the bug/feature in
the 4.2 IMP driver code that only resets per host RFNM counts
when a BADLEADER msg from the IMP is seen.

Has anyone implemented and TESTED a fix for this?  I'd like
not to reinvent the wheel if possible.  Please send me a
note or post to TCP-IP or UNIX_WIZARDS if you have such a

Also, did anyone get a definite reading on when the IMP resets
its RFNM counters?

    					Art Berggreen

"Too illiterate to have any cute quotes."

Date:      26 October 1984 1155-PDT (Friday)
From:      stanonik@nprdc
To:        tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA
Subject:   Re: 4.2 RFNM count problem
In response to our query about rfnm's, Bill Nesheim
(cu-arpa.bill@Cornell) provided the following fix which 
we've installed.
	RCS file: RCS/if_imp.c,v
	retrieving revision 1.1
	diff -c -r1.1 if_imp.c
	*** /tmp/,RCSt1017941	Fri Oct 26 11:26:49 1984
	--- if_imp.c	Fri Sep 21 14:16:42 1984
	*** 293,298
			impmsg(sc, "interface reset");
			goto drop;

	--- 293,299 -----
			impmsg(sc, "interface reset");
	+ 		hostreset(sc->imp_if.if_net);
			goto drop;
He said their rfnm problems disappeared, and now apparently 
so have ours.  Of course, disappearance of the problems isn't
quite the same as testing.  Hitting the ecu reset button would
probably be a good test, if I could think of a way of bumping 
up the rfnm counts (short of adb'ing /dev/kmem).  I never did
get a response about when the imp's clear their counts, and I
couldn't find that information in bbn's 1822 report.

Ron Stanonik
Date:      26 Oct 84 1255 EDT (Friday)
From:      don.provan@CMU-CS-A.ARPA
To:        JNC@MIT-XX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP MSS Option
On the other hand, the "Be conservative" maxum cuts both ways, so you
should be sending out the segment size option on each SYN packet.  When
this came up a while back, I blushed into my TCP code to add it, and it
turned out to be much simpler than I thought it would be.  Even though,
as the other two notes pointed out, you're in the right, add it or have it
Date:      Sat, 27 Oct 84 10:49:50 EDT
From:      Andrew Malis <malis@BBNCCS.ARPA>
Cc:,, malis@BBNCCS.ARPA
Subject:   Re: 4.2 RFNM count problem
Art and Ron,

The IMP always resets its RFNM counters under any of the
following circumstances:

1. The IMP was restarted by the NOC.

2. The host flapped or dropped its ready line to the IMP.

3. The host went tardy to the IMP, and then recovered.

All of these conditions cause the IMP to send NOPs and an
Interface Reset to the host, which the host can use as a signal
that RFNM counters have been reset.  So, the code in Ron's
message should do the trick, given that "hostreset()" does the
right thing.

Section 3.2 of BBN Report 1822 accurately discusses the second
and third cases that I list above, but does neglect to mention
that the RFNM counters are reset.

Date:      Sat, 27 Oct 84 12:25:28 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        Provan@LLL-MFE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  RFC810 table parsing
I'm sure theres a C parser, do to all the UNIX machines on the net.
I've got one that is straight C, while BSD uses YACC (YECH).  Turns
out it isn't too much of a problem since UNIX already has a file
whose fields are seperated by colons (/etc/passwd).

Date:      27 October 1984 14:25-EDT
From:      "Marvin A. Sirbu, Jr." <SIRBU @ MIT-MC>
To:        tcp-ip @ SRI-NIC
Subject:   TCP vs TP Class 4
About a year ago the DoD asked the National Academy of Sciences to form
a panel to examine whether TCP should be abandoned in favor of the
International Standards Organization's Transport Protocol-Class 4.  The
thought was that TP4 was more likely to get wide commercial support and
thus save the DoD money in the long run by not being out of step with
the commercial world.  Also, all of the European NATO countries have
indicated that they intend to use TP4.

On the other hand, after the traumas of the switch from NCP to TCP, I'm
sure no one is anxious to go through it again.

The National Academy report has yet to be released, but a blurb in the
Omnicom Newsletter says that the report will come out in favor of making
the switch.

Anybody know anything more or have any comments?

Marvin Sirbu
Date:      28 Oct 84 19:51:38 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   questions about authentication server
I have just done a test implementation of RFC912 (authentication server)
to allow FTP on Tops-20 to avoid the need for passwords.  I have some
questions and suggestions:

1) The document talks about a line of text.  However it does not
specifically say that the query and response end in CRLF.  I have
made my programs send CRLF, but accept lines terminated in CRLF or
not (i.e. connection is closed after sending the last byte of
data in the line).  However if another implementor took the
opposite interpreation, he might think I had returned a user name
that included a CRLF in it.  The spec should say whether the lines
end in CRLF.  I think they should.

2) The syntax is
  nnn, nnn : code : name
I think the spaces are a bad idea.  The document doesn't really say
that the spaces are there.  For all I know they could have been
added by the text processor used for the manual.  But whereever
there is a space, we have to ask:  should we accept a tab?  should
we accept more than one space?  How about a space before the comma?
I produce exactly the syntax given in the RFC, but allow for any
whitespace (including none) whereever one space shows.  I do not
allow for a space before the comma.  But I would prefer to have no
spaces at all.  I think that would make the syntax more likely to
be uniform.

Originally I suggested that this service should be done via UDP
instead of TCP.  I now think I was wrong, and agree with the RCP
in using a TCP connection:
  - It turns out that Tops-20 does not support UDP, although
	apparently it can be faked using some low-level
	primitives and somebody's I/O library
  - TCP is probably harder to fake.  Suppose somebody out there
	want to access my files.  It wouldn't be that hard to
	set his interface to promiscuous mode, catch my
	requests to some other host, and stick in his own reply.
	If it got to me first, I would probably believe it.
	In order to do TCP, he has to handle the whole byte-
	stream protocol, including ACK's, in the presence of
	another host that is trying to do so also.

The original posting sparked a brief flurry of conversation
about security on Ethernet.  I hate to speak about security, since
I am not an expert on either that subject or on protocols.  But it
does seem that it is somewhat better to use a protocol like this
one to verify who a user is rather than to use passwords.  Obviously
either can be broken.  But if you use passwords, all someone has
to do is monitor the net traffic, and he can pick your password
out of the Ether.  Once he has it, he can use it anywhere.  With
an authentication server, he has to produce a TCP implementation
that will detect attempts to connect to another host, and then
mimick that host.  This is certainly a more difficult enterprise.
Also, it still doesn't give him the password.  He still has to use
his hack whenever he wants to log in.  This is more likely to be
detectable.  However I do agree that some sort of public-key
encryption would be better yet.  Probably the best idea would be
for the query to have the form:
  port, port, random-key
The random-key is there to make sure that the user can't just
store up responses to commonly-used port pairs.  The response would
 port, port, random-key: USERID: username
encrypted with that host's signature encryption (i.e. one that anyone
can decrypt but no one else can produce).  In our enviornment,
this one piece of encryption would greatly increase security.  Almost
the only thing sensitive that would be on our network is people's
passwords.  If we can eliminate sending passwords on the Ether, and
have a fairly secure alternative to indentifying people, the rest of
what we do could be in the clear.  I am again assuming that our
average student might be able to look at what is going over the
Ether, but that he would have a hard time modifying it, e.g. replacing
the real copy of the authentication server with one that he has
modified, as I install it on other systems.  For cases where we
have to use passwords (e.g. when a user is coming in via a terminal
server where we cannot trust it to identify the user itself), we
could have a small amount of code in the terminal server to handle
passwords.  The system would send a challenge of the form:
and the terminal server would send back
  random-key password
encypted in a one-way encyption algorithm that mixes the random
key with the password.  Obviously that could be broken (e.g. by
modifying the terminal server software to store away the password
somewhere), but this seems like a worthwhile level of security for
some environments.
Date:      28 Oct 1984 21:36-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  TCP vs TP Class 4

I would imagine that DoD would find the switch attractive only
insofar as the machine vendors provided software as part of their
standard, supported protocol suite(s).  I believe there has been
some experimental work done by a number of vendors to try out TP4
and a file transfer protocol.  I am not sure they incorporated an
IP layer or not.

Vint Cerf
Date:      Sun, 28 Oct 84 22:56:44 est
From:      Alan Parker <parker@nrl-css>
To:        tcp-ip@nic
Subject:   tcp-ip mail list archive?
Does anyone archive these messages?  I would like to review the messages
from some time back concerning the issue of passwords on an ethernet. Thanks.

Date:      29 Oct 84 08:18:21 EST
From:      ddn-navy @ DDN1.ARPA
To:        SIRBU @
Cc:        tcp-ip @
Subject:   Re:   TCP vs TP Class 4
The following is my own opinion and not necessarily that of the decision
makers loosely referred to as DoD.


It amazes me that people feel that all they have to do is implement a policy,
throw the equivalent of the national debt at it, and everything will sudd-
enly be beautiful.  This is not the case and those who meander through life
thinking it is will also tell you that there really is a Santa Claus, they
believe in the Easter Bunny and at an advanced age still put their teeth
under the pillow believing the tooth fairy will leave them a dime or quarter
in exchange.  Such is the case with the DoD and their attempt to standardize on n
a level 4 transport protocol.

I sell DDN, DoD's long haul datacomm net nee ARPANet.  I am one of four who
do and we've done such a good job that the DDN Program Mgt Office has been
flooded with so many requests for service we currently have a backlog of
some 800 requests for connection to the network with no end in sight.  The
number of requests and sizes of the subscriber systems planning to access
the net is growing exponentially.  There is no end in sight cause DoD mandated
DDN as the only (underlined) means for services/agencies to communicate. We
sold the services...we sold the subscribers...and we sold the commercial

The latter is the important consideration because since 1978, when TCP became
the DoD standard, we have been telling the NAVDAC's and the CSC's that their
new systems must be procurred with TCP already hooked into the OS.  A few
got by the reviewers but more and more, the system RFP's are hitting the
streets for systems with full DDN capability and the pivotal protocols
continue to be IP and TCP.  Most of the majors and quite a few of the minor
vendors have now developed or OEM'd someone who has developed these and
the upper layers and they are ready to support DDN and requests from their
customer base.  Cases in point -- Sperry Corp sunk $4 Million in developing
their DDN X.25 interface and OEM'd Protocom for another $1 Million to do
every thing from level 3U through 7.  SDC-Burroughs sunk around $6 Million
in their MIL/INT DDN interface and plans to support IP/TCP for another
decade at least.

The DDN PMO recently awarded between $3.5 and 4.5 million in developmental
contracts for 8 vendors to produce full service, "generic" DDN interfaces.
Again IP/TCP/FTP/TELNET/SMTP operating above X.25.  It has taken 6 years
but we finally have everyone looking at, if not yet singing from, the same sheet
of music.

The many departments of government.  I will not bore you with quotes from
Thomas Jefferson or Andrew Jackson that warned about government becoming
so large it loses site of its purpose and serves its own interests rather
than those for which it is funded.  But suffice it to say that the National
Academy Report will probably be published without a rejoinder from this
program office telling those who read it the many problems of changing from
one standard to another, even if the follow-on is better or more efficient.
You mentioned the switch from NCP to TCP.  This is not finished even as I
write.  NCP is still the transport protocol for WIN.  And it is still
supported in the MILNET IMP's unless the release they are testing now has
finally removed it from that backbone.  

But don't be fooled for a minute into thinking this is the only example of
government "shooting itself in the foot" by failing to look at the impact
of implementing a decision.  I sat in the gallery when the past Director of
DCA, LTG Wm Hilsman testified that the divestiture of ATT would cause untold
havoc on expanding and managing the DCS...that the lack of a competent end-
to-end carrier would damage our national security and he could not guarantee
to the Congress that the DCS would be reconstitutable once the Bell System
was broken up.  I don't think I'll get many arguments from my readers 
the sum of the parts are anything nearly equal to the original whole of the
old Bell System.  And so it goes with standards.

Once we had none and different computer architectures found it difficult
to communicate among themselves.  Now we have them, but we have so many
because we really only have recommendations instead of standards, that the
same thing still holds true.  We commented on the National Academy's report
when it was still a draft.  Our concerns centered around what it would do
to this program to introduce still another "standard."  At that time we
were going through the exercise of choosing X.25/HDLC over 1822/HDH or DH
as the recommended connection protocol.  X.25 won because there were so
many X.25 interfaces available "off the shelf."  Our current hardware/software/
network monitoring base has all it can do to support the many level 3 connect       ct-
ions we ask it to support -- X.25/HDLC; 1822/HDH; or 1822 DH w/ECU's.  To
impose an additional level 4 protocol across, but not necesarily on, the
net, we feel, would add an untold amount of additional overhead to a system
already saturated with "non data bearing" packets.  There is also the problem
of monitoring center, MILDEP and industry support for a protocol billed as
the new "standard" but with no track record save for the experiments at
University College London and the U of Germany.

Let's hope that we all learned something from the NCP --> TCP and 1822 -->X25
exercises.  My biggest fear is that someone at DoD who writes policy letters
will take the Ntl Academy Report and sign out policy directing us to support
TP in DDN by 4th quarter FY86 or something absurd like that.  We should look
at adopting it only after it's left academia and has the support of industry.
After all, it's commercial, not academic, systems that we are connecting to
the net these days.


If you'd like to look at the Transport Protocol, you can FTP it from SRI-NIC
by calling for <RFC> 904.  The current TCP is filed under <RFC> 793.  I'd
like to close by saying that those of us who reviewed TP 12 or 14 months
ago all agreed that it's a better end-to-end protocol than the current TCP.
Our only real concerns were how we would support it on the net (minor); how
we'd sell it to the subscriber community (intermediate); and whether or not
it would gain widespread industry support (major).  We could support it on
the net in 2 years if the word came down to do so.  It would take a lot 
longer to sell it to our users or to IBM, Sperry, DEC, Honeywell, Burroughs
et al, I'm afraid.

Rod Richardson sends
Navy Systems Implementor
DDN Program Mgt Office

Date:      29 Oct 1984 10:52 PDT
From:      Art Berggreen <ART@ACC>
To:        jeff@aids-unix
Cc:        tcp-ip@sri-nic,unix-wizards@brl
Subject:   4.2 IF-11/HDH Driver
To any interested parties,

A Beta release of a 4.2BSD device driver for ACC's IF-11/HDH is
available from ACC.  The IF-11/HDH is the UNIBUS frontend which
implements the HDLC-Host (1822 appendix J) IMP Interface for
modem connected hosts.

Since we don't normally run our FTP daemon, anyone interested
should contact me directly at ACC for a copy.  I'll either
FTP it to your site, mail it to your site, or if needed send
a magtape.

    Phone:	(805) 963-9431 (Hard to catch this way)

    					Art Berggreen
    					Advanced Computer Communications

Date:      Mon 29 Oct 84 12:27:26-PST
From:      David Roode <ROODE@SRI-NIC.ARPA>
Subject:   TCP-IP list archives
These files are available for FTP from any Internet site.  FTP them
from SRI-NIC.ARPA logging in as ANONYMOUS with password GUEST.  The
MAIL.TXT file contains the most recent messages.

filename		  disk   char.      date last written
			 pages   count

PS:<TCP-IP>TCP-IP.1982.1     30 76060(7)   10-May-84 17:43:31 HSS       
PS:<TCP-IP>TCP-IP.1983.3    192 491285(7)  11-May-84 14:28:10 HSS       
PS:<TCP-IP>TCP-IP.1984A.1   158 404296(7)  27-Oct-84 13:07:56 ROODE     
PS:<TCP-IP>MAIL.TXT.1       139 353894(7)  29-Oct-84 11:05:46 tcp-ip-RELAY 

 Total of 519 pages in 4 files
Date:      29 Oct 1984 10:34-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  TCP vs TP Class 4

I  think  Vint  Cerf's  comment  is right on the mark.  The whole
point  of   the   ISO   protocol   suite   is   to   provide   an
"electropolitically"    acceptable    specification   which   the
manufacturers  will  build   into   their   standard,   supported
communications  offerings.  It will not save the DoD any money to
have to pay vendors specially to implement ISO protocols and then
have  to  pay  again and again to support them.  That is what the
vendors  should  be  doing;  they're  the  ones  that  gain  from
universally  "open"  interconnection, by the radical expansion of
the  communications  market  and  the  radical  facilitation   of
information services markets.

At the NCC in July, the NBS and GM cosponsored a demonstration of
ISO TP4 and an FTP subset  over  two  types  of  local  networks,
CSMA/CD  (IEEE  802.3)  and  token bus (IEEE 802.4).  More than a
dozen manufacturers, including IBM and DEC, participated, and  by
all  accounts, the demonstration was very successful.  NBS is now
planning to sponsor an  Internet  based  demonstration  in  1985,
using  ISO  Draft International Standard 8473, the ISO equivalent
of IP.

Obviously, the issue here is not a technical one, since  the  ISO
protocols  are  technically  similar  to the DoD protocols (after
all, ISO Transport Protocol Class 4, now  part  of  International
Standard  8073,  was  based  on  TCP,  and  the  ISO Protocol for
Providing the Connectionless-mode Network Service (DIS 8473)  was
based  on  IP).   The issue is to specify a protocol that all the
manufacturers  will  agree  to  support.   Since  all  the  major
manufacturers  are  now multinational manufacturers, they want to
develop globalized products which they can  sell  in  Europe  and
Asia  as well as in North America.  IBM is said to have announced
that they will offer the ISO Transport  Protocol  operating  over
X.25  in  Europe, just as they offered X.25 support in Europe two
years ago.  And of course, the European  manufacturers,  such  as
Siemens,  Bull,  and  ICL, want to be able to compete in the U.S.
market, and they are going to pressure their governments to  lock
out  the American companies if the Americans lock them out.  (IBM
just settled a major lawsuit with the European Economic Community
involving in part this issue.)

The bottom line is that Vint Cerf is exactly right: ISO protocols
will only be attractive when they are offered as a standard  part
of every manufacturer's product line.

--Dick desJardins
Date:      29 Oct 1984 17:19:10 PST
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: TP4 vs. TCP

Well, i for one, do not believe that ISO TP4 is as good as TCP.

Date:      29 Oct 84 1915 EST (Monday)
From:      don.provan@CMU-CS-A.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   TP4 vs. TCP
So now it's generally agreed that the ISO protocols will be at least
as good as IP/TCP?  What happened to all the apartment
building/parking structure and created by commitee arguments?  What
about the problems with not being able to have two protocols on the
same level a la TCP/UDP?  Have all of these shortcomings been solved
or are we just listening to the people already convinced that ISO is
good?  I've heard that DoD will inevitably go to ISO, but this is
the first time I've heard that the only issue is the conversion.
Date:      29 Oct 1984 21:47-EST
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   re: TP4 vs. TCP
In the end, it often turns out to be the case that the principal
issue in selecting a protocol is not its absolute "goodness" but
by whom it has been implemented and what it supports in the way
of applications or other protocols.

Consider 1822 vs X.25 - 1822 has served DoD well since 1968.  It
is only recently that enough widespread X.25 implementations have
made it worthwhile to consider its use as well.  There will be
some applications which X.25 supports less well than 1822, owing
to the latter's datagram-like interface, but for a large number
of cases, X.25 will probably work out quite acceptably.

A more serious concern may be system security - since the
CCITT/ISO TP4/IP protocols have not been developed with system
security in mind, so far as I know.  It may be quite a while
before DoD will even know if they work, let alone be able to
apply these protocols in an end/end secure application.

Like 1822, TCP/IP and the other Internet protocols will probably
be with us, serving DoD well, for a good long time.  In the
meantime, it is fair for us to recognize that international
standards are important - even to the U.S.  Defense Department.
We cannot ignore things, but on purely economic and management
grounds, one would expect motion towards the adoption of
international standards to be paced by feasibility and cost
constraints and possibly technical/functional constraints.

Vint Cerf
Date:      30 Oct 1984 18:06-EST
To:        don.provan@CMU-CS-A.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TP4 vs. TCP
You have to be careful about the "created by committee" argument.
Generally it's valid, because it's applied to cases where  design
integrity  is the issue.  And for design integrity, nothing beats
a single design team (unless it's a single mind).  And there  are
going  to  be  many  ISO  (or  any  other)  protocols, just to be
specific, which suffer from being "created  by  committee".   But
the  protocols  being  discussed, TP4 and Connectionless Network,
are just "improved" (a legitimate issue, to be sure) versions  of
TCP  and  IP, created by the NBS and BBN (ask John Heafner at NBS
what their heritage is and  what  technical  "improvements"  were
made)  in a single design team.  Other "improvements" were in the
more formal  specification  style  used,  and  in  the  political
compromises  which  made  it acceptable worldwide, which is a not
inconsiderable improvement if that's a goal.

Regarding conversion, you can keep your own protocols and  do  it
with  gateways  (which is the approach to be taken by IBM SNA) or
you can change out your protocols (which is the  approach  to  be
taken by DEC), but somehow DOD networks will have to interoperate
with other networks -- the DOD situation is no different from the
SNA  situation in this respect.  I believe this is the essence of
the conversion discussion, that it will  have  to  be  done  some
time,  some  how,  whether with gateways or by changeout, and the
discussion is about when and how.

And please -- just because someone believes that "ISO is  a  good
thing" doesn't make her (or him) unthoughtful!

--Dick dJ

(P.S.   A  camel  will  beat  a horse if the sand on the track is
loose enough and deep enough.)
Date:      Thu, 1 Nov 84 00:12:48 -0200
From:      barkan%wisdom.BITNET@Berkeley (Yirmiyahu Barkan)
To:        tcpip-list%wisdom.BITNET@Berkeley, vax-list%wisdom.BITNET@Berkeley
Subject:   vt220
does anyone have a termcap for a VT220, or any of the
VT200 series ?
does anyone know when dec will give full support for the
vt200 series on VMS ( ie - not until release 4.0 )

thanks - yb

Yirmiyahu Barkan