The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for May 1986 (196 messages, 92855 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 May 1986 08:39-PDT
From:      Mike StJohns <StJohns@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   X.400 over TCP-IP?

Is  there  anyone  out  there  running  X.400  mail above TCP/IP?
Please resond direct to me, I'll summarize for the list.  Mike
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 May 86 10:25:55 pdt
From:      Andy Poggio <poggio@sri-tsc.ARPA>
To:        Mike StJohns <StJohns@SRI-NIC.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: X.400 over TCP-IP?

Mike,

I know that BBN is working on one and we at ISTC have toyed with the idea.
I am very interested in any other responses you receive. Please let me
know...

--Andy
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 May 86 16:58:10 -0800
From:      Marshall Rose <mrose@nrtc-gremlin>
To:        Andy Poggio <poggio@sri-tsc.ARPA>
Cc:        Mike StJohns <StJohns@sri-nic.ARPA>, tcp-ip@sri-nic.ARPA
Subject:   Re: X.400 over TCP-IP?
    The big problem though is what goes between TCP-IP and X.400.
    Where's the session and presentation stuff?  This is what partially
    motivated rfc983 - the iso/ccitt folks are spending the majority of
    their time arguing about addressing, etc. (in general, things that
    got solved fairly well 5 years ago!), and much less work is being
    done on the application stuff.  Since all our previous experience
    tells us that doing the higher-level stuff is at least as hard as
    the lower-level stuff, if you're doing iso/ccitt applications, the
    rfc983 approach is a big win.  

    (that bit of soap-boxing aside,) I know that the EAN system,
    originally from University of British Columbia, and now from Sydney
    Development Corporation has a TCP/IP interface.  John Demco
    (demco@ubc.csnet) is one of the principle gurus at UBC.  Looking at
    the NIC's HOST.TXT, I note that BBN-DIAMOND advertises TCP/X400 in
    addition to TCP/MPM.  I've been meaning to ask the Diamond wizards
    about that, but haven't gotten around to it.  If ISTC also has
    something, I'd like to hear more.  

/mtr
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 May 86 12:38:20 EDT
From:      Ross Patterson <PATTERSON@BLUE.RUTGERS.EDU>
To:        1017518%MCMASTER.BITNET@WISCVM.WISC.EDU
Cc:        PATTERSON@BLUE.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: DEC-IBM connection
Joanne,
   If you are running MVS on the IBM system, you may want to consider using
UCLA's Arpanet Control Program (ACP) software to drive an ACC IF/370E Ethernet
adapter. The IF/370E seems to work well, and the UCLA code required no changes
to support it (in fact, UCLA is considering buying an IF/370E also.) We have
had occasional problems with the hardware, but ACC has been quite responsive.
I would be glad to discuss this in more depth, if you're interested.
 
Ross Patterson
Rutgers University
Center for Computer and Information Services
PATTERSON@BLUE.RUTGERS.EDU
-------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 May 86 11:30:19 pdt
From:      John Demco <demco%ubc.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.ARPA
Cc:        mrose@nrtc-gremlin.ARPA, CLynn@diamond.bbn.com, Harry Forsdick <forsdick@diamond.bbn.com>
Subject:   X.400 Mail Transport

I know this isn't TCP related, but I should clarify a bit... The EAN
X.400 message system was developed here at the University of British
Columbia, and development is continuing. Sydney Development has the
commercial rights to EAN.

To get back closer to the topic of TCP... EAN implements class 0 of the
ISO transport protocol. Above is the X.225 session layer. Below are
interfaces to TCP, X.25, DECNET, and TTXP (a protocol based on MMDF for
use on asynchronous lines and ITI connections). I am interested in the
approach proposed by RFC983 too, although I haven't read the document
closely yet.

John Demco
UBC

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 May 86 09:17:33 EDT
From:      Harry Forsdick <forsdick@DIAMOND.BBN.COM>
To:        mrose@nrtc-gremlin.ARPA
Cc:        CLynn@DIAMOND.BBN.COM, tcp-ip@sri-nic
Subject:   Diamond X.400 Mail Transport
Hi.  I was forwarded your message in tcp-ip about X.400.

Yes, we have developed an X.400 based mail transport agent for use by the
Diamond Multimedia Communications System.  You should contact Charlie Lynn
(CLynn@BBN) for details.

I'm already aware of the Sydney Development Corp's X.400 on top of IP/TCP.
I'm not familiar with "ISTC".  Who are they and what are they offering in
the way of X.400 mail systems?

Regards,

	Harry

P.S., Please reply directly since I am not on the tcp-ip list.
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 May 86 08:45:17 pdt
From:      Jonathan Biggar <sdcrdcf!RDCF.SDC.UUCP!jonab@LOCUS.UCLA.EDU>
To:        ucla-cs!tcp-ip@sri-nic.arpa
Newsgroups: net.unix-wizards,net.lan,mod.protocols.tcp-ip
Subject: Problem with IP fragmentation under Sun 3.0 UNIX
Expires: 
References: 
Sender: 
Reply-To: jonab@sdcrdcf.UUCP (Jonathan Biggar)
Followup-To: 
Distribution: 
Organization: System Development Corporation R&D, Santa Monica
Keywords: 


We have a problem with IP fragmentation-reassembly causing bad tcp
checksums at the receiving end under Sun 3.0 UNIX.  Any pointers
to bug fixes related to this for SUN 3.0, SUN 2.0, or 4.2bsd would
be appreciated.

Jonathan Biggar
sdcrdcf!jonab
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      05-May-86 03:37:34-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Spurious TCP retransmissions from NIC
Folks,

I have noticed an alarmingly high incidence of TCP retransmissions from NIC on
FTP transfers over medium-delay, low-loss paths. On a typical transfer from
its ARPANET address via an ARPANET gateway and 4800-bps line for instance, an
average of 2.5 packet transissions occured for every packet stored. During this
transfer no packets were recorded as lost in either the gateway or destination
host - all spurious packets were duplicates. In transfers to an Ethernet host
connected via the same path an average of 2.0 packet transmissions occured for
every packet stored.

I supsect something is wrong in the retransmission-timeout algorithm of the NIC
TCP client, since other TOPS-20 hosts do not exhibit anything like this behavior;
however, other TOPS-20s seem on the hairy edge of eagerness, since ISI hosts,'f
for instance, seem to generate rather more duplicates that, say, Unix hosts over
the same paths. Fuzzball hosts (ahem) generate next to none over most paths. It
implementors read RFC-889.

It would be useful to learn if others can confirm or refute these observations,
since NIC is fast becoming a major fountain of data.

Dave
-------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 May 86 10:08:25 edt
From:      rhott@NSWC-OAS.ARPA
To:        tcp-ip@sri-nic.ARPA
Subject:   Looking for MacIP
Has anyone heard of a Macintosh TCP/IP software product called MacIP?
I believe it originated at Carnegie Mellon University.  Any pointers
to users, distributors would be appreciated.

Send responses to:  rhott@nswc-g.arpa

Thanks,
  bob hott    Naval Surface Weapons Center, Dahlgren, VA  22448
              Code K33 (Systems Integration and Networking)
              Milnet mail :  rhott@nswc-g.arpa
              (703) 663 - 7745
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 May 86 11:16:17 edt
From:      steve@aplvax (Steven Kahn)
To:        tcp-ip@sri-nic
Subject:   1822/X.25 interoperability question

First, a naive question about 1822/X.25 interoperability.
Is it a reality? We understand that all future PSN hook-ups
require X.25. Does this mean that we could establish TCP
connections via such an interface to another host that is
connected to its PSN via 1822?

Now for a totally unrelated question regarding IBM TCP/IP.
Do any of the software products for IBM (such as the UCLA
code) contain the application level functionality (such
as SMTP, Telnet and FTP) that I am used to in the UNIX
world? For example, is SMTP integrated into IBM's "mailer"?
(You can tell I'm not from the IBM world...)

		Steve Kahn
		Johns Hopkins Applied Physics Lab
		Laurel, MD

		steve@aplvax.arpa

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue  6 May 86 12:49:10-EDT
From:      Dennis G. Perry <PERRY@IPTO.ARPA>
To:        steve@APLVAX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, perry@IPTO.ARPA
Subject:   Re: 1822/X.25 interoperability question
Steve, my understanding is that with psn release 5, X.25 and 1822 should
be able to talk to each other.  Release 5 is almost ready, but required
that all C30s be upgraded to C30Es.  I believe that this release will
occur soon.

dennis
-------
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 May 86 13:21:35 EDT
From:      Robert Myhill <myhill@ccs.bbn.com>
To:        Dennis G. Perry <PERRY@ipto.arpa>
Cc:        steve@aplvax.arpa, tcp-ip@sri-nic.arpa, laube@bbncc2.arpa, seisner@bbnccs.arpa, myhill@bbnccs.arpa, malis@bbnccs.arpa
Subject:   Re: 1822/X.25 interoperability question

Here are some facts on X.25/1822 interoperability:

	o  In order for an X.25 host and an 1822 host to
	   communicate, the PSN connected to the X.25 host must be
	   running PSN Release 6.0 (note that the PSN at the 1822
	   end of the connection, or any PSN in between, need not 
	   be running PSN Release 6.0).

	o  In order for a PSN to be running Release 6.0, it must be
	   running on a C/30E.  

	o  PSN Release 6.0 has been officially released.

	o  The hosts at both ends of an X.25 to 1822 connection
	   must be running TCP/IP on top.


I've heard that there are at least a couple of MILNET PSNs running
Release 6.0, though I don't know this for a fact.

I hope this helps.

--Robert
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      7 May 1986 04:09-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        myhill@BBNCCS.ARPA
Cc:        PERRY@IPTO.ARPA, steve@APLVAX.ARPA tcp-ip@SRI-NIC.ARPA, laube@BBNCC2.ARPA seisner@BBNCCS.ARPA, malis@BBNCCS.ARPA
Subject:   Re: 1822/X.25 interoperability question
PSN  6.0 is in LIMITED release on the MILNET and is being fielded
to meet specific operational  needs.   As  of  the  last  time  I
looked,  there  are  no  nodes  on the ARPANET which have PSN 6.0
installed.  We have been waiting for the upgrade to C30Es on  the
ARPANET to be completed (which may have happened even as I type).

Mike
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      7 May 1986 09:06:00 EDT
From:      Glen Foster <GFoster@USC-ISI.ARPA>
To:        STJOHNS@SRI-NIC.ARPA
Cc:        myhill@BBNCCS.ARPA, PERRY@IPTO.ARPA, steve@APLVAX.ARPA, tcp-ip@SRI-NIC.ARPA, laube@BBNCC2.ARPA, seisner@BBNCCS.ARPA, malis@BBNCCS.ARPA
Subject:   Re: 1822/X.25 interoperability question

I think that the c/30 -> c/30e upgrade has been completed.  The PSN
ver. 5.0 software is currently being installed in all Arpanet IMPS
(oops, PSNS).  PSN 28 was just upgraded yesterday. and I don't think
it was one of the first.  Our Milnet PSN, on the other hand, was
upgraded last September.

Glen
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 May 86 17:04:42 EDT
From:      swb@devvax.tn.cornell.edu (Scott Brim)
To:        tcp-ip@sri-nic.arpa
Subject:   Cisco
I have an introductory blurb from Cisco, a company marketing an IP
gateway developed at Stanford.  Does anyone have a phone number for the
company?  Any detailed information on how the product behaves, what its
advantages and shortcomings are, what interfaces it supports, etc.?
						Thanks very much,
							Scott
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      8 May 1986 12:32:54 PDT
From:      BRADEN@USC-ISIB.ARPA
To:        steve@APLVAX.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        BRADEN@USC-ISIB.ARPA
Subject:   Re: 1822/X.25 interoperability question
In response to the message sent  Tue, 6 May 86 11:16:17 edt from steve@aplvax 

Steve,

The "UCLA code" for TCP/IP supports Telnet, FTP, and SMTP
under OS/MVS.  It interfaces not to the IBM "mailer" (because,
incredible as it may seem from our perspective, there is no such critter),
but to a mailer written at UCLA for both Bitnet and the Internet.
There is a fullscreen 3278 interface to this mailer that is comparable
in quality and ease with the mailtool on my Sun workstation, for example.

Bob Braden
-------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 May 86 11:48:45 EDT
From:      Louis A. Mamakos <louie@trantor.UMD.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   ULTRIX 1.2 brokeness
They did it again.  After all of the flaming about the proper thing for
a user telnet program to send for an end-of-line sequence, the ULTRIX 1.2
release is STILL broken.

It seems that too many vendors assume that the correct thing is what UNIX
does.  These protocols are not defined by their actions, but by the
specifications in the RFCs.  The Wollongong people have this same problem,
and are even more unresponsive to the user's needs then most vendors are.

It's only a 3 line fix to make TELNET work.  Oh well.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
  University of Maryland, Computer Science Center - Systems Programming

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      8 May 1986 16:14-PDT
From:      William "Chops" Westfield <BillW@SU-SCORE.ARPA>
To:        swb@DEVVAX.TN.CORNELL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Cisco
	cisco Systems, Inc
	PO Box 475
	Menlo Park, CA, 94026
	(415) 326-1941
	5106016967   (telex)

They sell the IP gateway, a terminal server (talks TCP), and the MEIS,
a massbus ethernet interface (eg for 20's).  The gateway supports
"Sun" 3Mb ethernet interfaces, 3com 10Mb interfaces, Interlan/micom
10Mb interfaces, ACC 1822 interfaces, and 56Kbps serial links, and
others (up to 4 at once).  The box is multibus based, so other
interface support is feasible.  Full support of IP, TCP, ICMP, EGP,
ARP, Subnets, etc, and "IGP" (Internal Gateway Protocol (supports
multipath routing, etc)).

Stanford has about 25 of the "non-production" version linking together
their 60 odd cable segments, along with about 60 of the "terminal
servers".  It all works quite well.

Disclaimer:  I dont for for cisco, but my boss does.  I DO work for Stanford.

BillW
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      08 May 86 14:36:54 EST (Thu)
From:      "Christopher A. Kent" <cak@Purdue.EDU>
To:        "Louis A. Mamakos" <louie@trantor.UMD.EDU>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: ULTRIX 1.2 brokeness
Well, the story I get from the folks that actually put Ultrix together
is that it takes 10 - 12 months to get changes out the door. So Ultrix
1.2 was probably frozen long before our flaming.

Sigh,
chris
----------
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 May 86 19:03:27 -0500
From:      Stan Ames <sra@mitre-bedford.ARPA>
To:        tcp-ip@sri-nic.ARPA, info-ibmpc@usc-isib.ARPA
Cc:        sra@mitre-bedford.ARPA
Subject:   Net Bios on top of TCP/IP

Recently several vendors (including Excelan, UB, and CMC) have anounced
products that support the IBM/Microsoft Net Bios on top of the TCP/IP/UDP
internet protocols for IEEE 802.3 LAN products.

Unfortuantly each has interfaced Net Bios to the internet protocols in a
somewhat different mannor.  MITRE under the direction of the ULANA program
office is attempting to bring the vendors together to agree on an interface
specification.  In order to be successful each of the vendors must participate
and users must make their desires for vendor interoperability known to the
vendors.

Anyone that is involved in an inpending implementation of Net Bios on the
internet protocols is encouraged to participate.

Stan Ames
sra@mitre-bedford.arpa
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 May 1986  20:13 EDT
From:      Jon Solomon <JSOL@BUCS20.BU.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   4.2/4.3 subnetting
I have received numerous replies to my subnetting queries and
here is a summary of the results.

1) Subnets aren't anywhere near fully implemented in the field.
With the growing number of networks out there and the finite
amount of network space it makes sense to utilize all the resources
as well as one can.

2) 4.2 has no subnetting support. 4.3 apparently does have full
subnetting support.

3) If you have ARP based networks then you can use a hack to implement
subnets. This is known as "the ARP hack". I now have a copy of 
this hack for 4.3, but are in need of it for 4.2. Does anyone have
a copy of it they'd be willing to give me?

Oh, incidentally the 4.3 ARP hack implementation can be gotten from
sally.utexas.edu using the anonymous FTP convention, if memory serves.
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 May 86 0:15:56 EDT
From:      Ron Natalie <ron@BRL.ARPA>
To:        Jon Solomon <JSOL@bucs20.bu.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  4.2/4.3 subnetting
By the way, if you plan to talk to 4.2 machines using the ARP
hack (i.e. you are going to treat the 4.2 machines as being
ignorant about subnets), you must fix the code that references
the "oldmap" variable as this will prevent ARP from working on
the entire 16 bit address.

-Ron
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri 9 May 86 00:30:31-EDT
From:      "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
To:        BillW@SU-SCORE.ARPA, swb@devvax.tn.cornell.edu
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@XX.LCS.MIT.EDU
Subject:   Re: Cisco
	Are there working examples of the EGP and ARPANet interface,
or is that merely an announced product?

	Noel
-------
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 May 86 08:21:07 edt
From:      martin%sabre@mouton.bellcore.com (Martin J Levy)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  ULTRIX 1.2 brokeness
can i also bring up the subject of UDP broadcast's (this is with
ULTRIX-32m).  i'm coming to the conclusion that there is a mix of 4.2
and 4.3 style code in there for allowing a user to do a broadcast. in
4.2 one only needs to be root to send a broadcast, but with ULTRIX 1.1
it seems you need so do the setsockopt() also, but the correct defines
are not in socket.h.

can anyone help?, is 1.2 fixed?

martin
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      09 May 86 01:54 +0200
From:      Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Specs for TCP/IP on Ethernet for t20
Maybe sending to a black hole....

I'm trying to find the specs, that describes what goes on the
ethernet cable, from a TCP/IP taking T20 6.1 arpa monitor.

(.trying to hook a t10 7.02 with homebuild ethernet hardware
  into such network.)



-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 May 1986  10:05 EDT
From:      Jon Solomon <JSOL@BUCS20.BU.EDU>
To:        Ron Natalie <ron@BRL.ARPA>
Cc:        tcp-ip@sri-nic.arpa
Subject:   4.2/4.3 subnetting
    Date: Friday, 9 May 1986  00:15-EDT
    From: Ron Natalie <ron at BRL.ARPA>
    To:   Jon Solomon <JSOL>
    cc:   tcp-ip at sri-nic.arpa
    Re:   4.2/4.3 subnetting

    By the way, if you plan to talk to 4.2 machines using the ARP
    hack (i.e. you are going to treat the 4.2 machines as being
    ignorant about subnets), you must fix the code that references
    the "oldmap" variable as this will prevent ARP from working on
    the entire 16 bit address.

    -Ron

Explain more.....Do you have such a fix?

--jsol
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 May 86 22:08:12 edt
From:      jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen)
To:        tcp-ip@sri-nic.arpa
Subject:   Ultrix 1.2
One of our customers has reported that TFTP clients which can talk
to Ultrix 1.1 just fine can't communicate with Ultrix 1.2.  Anyone
else experienced this?

jbvb@AI.AI.MIT.EDU
James B. VanBokkelen
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      10-May-86 04:47:32-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   TCP retransmissions from NIC
Folks,

Thanks to Alan Hill of BBN and Bob Knight and Mark Lottor at NIC for their
comments on my message about excessive TCP retransmissions. Measurements made
tonight (about 0400Z) show some improvement. Via the NIC MILNET address,
ARPANET/MILNET gateway complex, DCN-GATEWAY and 4800-bps line to DCN6.ARPA,
about one packet in 23 was dropped and one packet in seven was an old
duplicate. Via the NIC ARPANET address and the same path, about one packet in
212 was dropped and one packet in 14 was an old duplicate. These figures
represent a significant improvement over the figures I reported last week, but
still leave room for improvement. I have not measured the performance via
higher-speed paths, but suspect it is much better than before. I would like to
thank the folk both at NIC and BBN for their quick response and prompt action
on my message.

Dave
-------
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10-May-86 16:47:33 EDT
From:      mills@DCN6.ARPA
To:        mod.protocols.tcp-ip
Subject:   TCP retransmissions from NIC

Folks,

Thanks to Alan Hill of BBN and Bob Knight and Mark Lottor at NIC for their
comments on my message about excessive TCP retransmissions. Measurements made
tonight (about 0400Z) show some improvement. Via the NIC MILNET address,
ARPANET/MILNET gateway complex, DCN-GATEWAY and 4800-bps line to DCN6.ARPA,
about one packet in 23 was dropped and one packet in seven was an old
duplicate. Via the NIC ARPANET address and the same path, about one packet in
212 was dropped and one packet in 14 was an old duplicate. These figures
represent a significant improvement over the figures I reported last week, but
still leave room for improvement. I have not measured the performance via
higher-speed paths, but suspect it is much better than before. I would like to
thank the folk both at NIC and BBN for their quick response and prompt action
on my message.

Dave
-------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11-May-86 01:24:27 EDT
From:      faunt@spar.UUCP (Doug Faunt)
To:        mod.protocols.tcp-ip
Subject:   info on cisco


Phone number is 415-326-1941.  IP gateway is 1-4 way, currently supports
IP/TCP and V.35.  Coming soon is T1 and DECNET-IP.  Price is $7950 for
2-way IP.  Add or subtract $1K for less/more ethernets.  Each 2-line
v.35 (for muxing high-speed (usually 56Kb) phone lines onto ethernet)
interface is $2K.  Advantages:  has run onder 24 different implementations
of IP/TCP and has all boot loaders, servers, and net mgmt. stuff in ROM
in the box, so you don't need any other box to do diagnostics or traffic
management.  Also, the command lang. interface is very good, and nearly
everything is user-settable in the config. files.  Two levels of password
protection on idividual lines to net segments.  Fast: 1200 pps burst.

For more information, contact cisco or BOSACK@SU-SCORE.ARPA

I don't work for cisco, but my boss does.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-May-86 09:36:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Port Collisions

Folks,

This mail is a follow-up to a discussion I had with Jon some weeks ago.

We here at Symbolics are concerned with the process of assigning TCP/UDP
port numbers.  It is not always appropriate for us (and other vendors)
to apply for ports in the Czar-controlled first 256 ports.  Either
because of time constraints or issues of proprietary information, we
cannot always write and distribute an RFC for each of our protocols.

We have had complaints from customers that we are not the only vendor
using the `any private file proctocol' port.

We need a way to define new protocols without feat of collision with
other people.

We see two possibilities:

1) A registry of ports for private protocols.  Symbolics would be
willing to administer a simple registry for a group of ports outside the
first 256. We (or someone else, it matters not) would keep a list, and
anyone from an identifiable organization could ask for ports.  The
registrar's only function would be to hand out each such port only once.
It would be helpful, of course, if the official RFC's for TCP/UDP would
designate the group of ports involved as reserved for use through this
registry.

2) A new protocol that would vastly increase the effective namespace by
multiplexing ports.  For example, a port that the user side connects to
and sends an arbitrary (or at least a reasonably long) character string
specifying the service desired.  Some obvious use of prefixes or
suffices would suffice to avoid collisions.

--benson

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      13 May 1986 18:38-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        Margulies@SCRC-YUKON.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, postel%usc-isib.arpa@MC.LCS.MIT.EDU
Subject:   Re: Port Collisions
I  am not sure I see the problem here.  A "private file protocol"
is just that - PRIVATE.  It is run between machines that make the
assumption  that  they are all running the same private protocol.
Or is there the possibility that one machine is running  multiple
PRIVATE file protocols?

Either  a  protocol is a network wide standard - implying that is
is documented, and that it is designed for at least a minimum  of
interoperability  -  or  it  is private, with little or no public
documentation, and with no designed  interoperability.   In  this
context,  I  am  talking  about global interoperability, not just
interoperability between UNIX systems for example.

I can see  some  advantage  though  in  providing  some  sort  of
sentinal  as  part  of the PRIVATE protocols to say "I am running
FOO as my private protocol, go away if you don't talk FOO".   But
wouldn't  this  more  properly  be  part  of  the protocol?  Each
protocol should do some  confirmation  for  robustness  purposes,
right?

Mike
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-May-86 17:25:46 EDT
From:      tef@virginia.CSNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP-IP Mailing List


Please add me to the tcp-ip mailing list.

	Thanks,

	Todd Fuller

	tef@uvacs.UUCP



***************************************************************************

Todd E. Fuller		University of Virginia Dept. of Computer Science

   			Path:  ...cbosgd!uvacs!tef
			       ...whuxlm!uvacs!tef
			       ...mcnc!ncsu!uvacs!tef

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 May 86 17:25:46 edt
From:      Todd Eugene Fuller <tef%virginia.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        
Subject:   TCP-IP Mailing List

Please add me to the tcp-ip mailing list.

	Thanks,

	Todd Fuller

	tef@uvacs.UUCP



***************************************************************************

Todd E. Fuller		University of Virginia Dept. of Computer Science

   			Path:  ...cbosgd!uvacs!tef
			       ...whuxlm!uvacs!tef
			       ...mcnc!ncsu!uvacs!tef

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 May 86 21:22:49 -0400
From:      Craig Partridge <craig@loki.bbn.com>
To:        margulies@scrc-yukon.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   re: Port Collisions

> We here at Symbolics are concerned with the process of assigning TCP/UDP
> port numbers.  It is not always appropriate for us (and other vendors)
> to apply for ports in the Czar-controlled first 256 ports.  Either
> because of time constraints or issues of proprietary information, we
> cannot always write and distribute an RFC for each of our protocols.

Why not make the port numbers used user/site configurable?  Berkeley
actually did this quite nicely with a services list, which mapped
a service name/protocol pair with a port number.  Since programs
use this database (or are supposed to) to find out what port they
are supposed to us, one could run SMTP on TCP port 25 on the Internet
but port 243 on some private network if one so chose.

The advantage is the vendor need not necessarily worry about what
port you pick for your special application -- it can always be
changed among cooperating machines.

Craig Partridge
CSNET Technical Staff
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-May-86 21:38:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

I  am not sure I see the problem here.  A "private file protocol"
is just that - PRIVATE.  It is run between machines that make the
assumption  that  they are all running the same private protocol.
Or is there the possibility that one machine is running  multiple
PRIVATE file protocols?

Either  a  protocol is a network wide standard - implying that is
is documented, and that it is designed for at least a minimum  of
interoperability  -  or  it  is private, with little or no public
documentation, and with no designed  interoperability.   In  this
context,  I  am  talking  about global interoperability, not just
interoperability between UNIX systems for example.

I can see  some  advantage  though  in  providing  some  sort  of
sentinal  as  part  of the PRIVATE protocols to say "I am running
FOO as my private protocol, go away if you don't talk FOO".   But
wouldn't  this  more  properly  be  part  of  the protocol?  Each
protocol should do some  confirmation  for  robustness  purposes,
right?

Mike

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-May-86 22:13:00 EDT
From:      CERF@USC-ISI.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   C implementations of TCP/IP

Are there any public domain implementations of TCP/IP written in C
which are readily accessible? With documentation? 

Many thanks,

Vint Cerf

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      13 May 1986 22:13-EDT
From:      CERF@USC-ISI.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   C implementations of TCP/IP
Are there any public domain implementations of TCP/IP written in C
which are readily accessible? With documentation? 

Many thanks,

Vint Cerf
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-May-86 22:16:39 EDT
From:      craig@LOKI.BBN.COM (Craig Partridge)
To:        mod.protocols.tcp-ip
Subject:   re: Port Collisions


> We here at Symbolics are concerned with the process of assigning TCP/UDP
> port numbers.  It is not always appropriate for us (and other vendors)
> to apply for ports in the Czar-controlled first 256 ports.  Either
> because of time constraints or issues of proprietary information, we
> cannot always write and distribute an RFC for each of our protocols.

Why not make the port numbers used user/site configurable?  Berkeley
actually did this quite nicely with a services list, which mapped
a service name/protocol pair with a port number.  Since programs
use this database (or are supposed to) to find out what port they
are supposed to us, one could run SMTP on TCP port 25 on the Internet
but port 243 on some private network if one so chose.

The advantage is the vendor need not necessarily worry about what
port you pick for your special application -- it can always be
changed among cooperating machines.

Craig Partridge
CSNET Technical Staff

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 05:37:25 EDT
From:      Murray.pa@XEROX.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

One word of caution.... Xerox managed to get off on the wrong foot in
the Ethernet packet type assignment business.

If you administer a group of ports, I suggest that the ground rules
include publishing a who-to-contact as well as a simple (one line?)
description of its function. Otherwise people will flame at you when you
won't answer questions.

The proprietary aspect might complicate that attitude. I don't think
that objection really holds water. It's too easy to look at the bits on
an ethernet.

I like your second suggestion, but somebody is bound to ignore it
because it takes an extra packet to get started.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 07:45:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: 13 May 1986 18:38-PDT
    From: STJOHNS@SRI-NIC.ARPA

    I  am not sure I see the problem here.  A "private file protocol"
    is just that - PRIVATE.  It is run between machines that make the
    assumption  that  they are all running the same private protocol.

Wrong meaning of private.  Try the definition `A protocol not published
as an RFC, for any reason whatsoever.'

    Or is there the possibility that one machine is running  multiple
    PRIVATE file protocols?

Exactly. Symbolics has a 'private' file protocol.  One of our customers
wanted to teach their lisp machine to talk someone elses 'private' file
protocol.  Unfortunately, they were on the same port.  This situation is
typical, and likely to happen again and again.


    Either  a  protocol is a network wide standard - implying that is
    is documented, and that it is designed for at least a minimum  of
    interoperability  -  or  it  is private, with little or no public
    documentation, and with no designed  interoperability.   In  this
    context,  I  am  talking  about global interoperability, not just
    interoperability between UNIX systems for example.

The problem is with the phrase `network-wide standard'.   The number
czar only designates protocols as `network-wide standards' as part of
the activity of the internet research community (I'm paraphrasing Jon
Postel, and I hope that I'm getting it right). That is not to say that
vendors cannot offer protcols for inclusion in the global set. However,
it is often not practical for us to do so.  We can't always afford the
time to document the protocol for the community, which is a pretty-near
necessart for inclusion in the global protocol set.

Anyway, I don't think that your simple division of the world into Public
and Private is good enough.  I think that things are more complex.

First, there is an extensive gray area between officially blessed
protocols (global interoperability) and protocols that are private hacks
amongst a small number of cooperative machines (no interoperability).
As a commercial vendor, we are concerned with orderly partial
inter-operability.  If Berkley has established a 'private' Unix TCP
protocol, it is very likely that sooner or later someone with a lisp
machine (or something else non-Unix) will want to talk that protocol to
a Unix.  That dosen't necessarily qualify the protocol as a network-wide
standard, but gives a good reason for us to avoid port collisions.

Second, even if I were implementing a protocol that would only be used
at one site amongst three machines,  I would like some assurance that I
won't find out next week that some vendor is using the port that I chose
for some protocol that I am interested in using.

    I can see  some  advantage  though  in  providing  some  sort  of
    sentinal  as  part  of the PRIVATE protocols to say "I am running
    FOO as my private protocol, go away if you don't talk FOO".   But
    wouldn't  this  more  properly  be  part  of  the protocol?  Each
    protocol should do some  confirmation  for  robustness  purposes,
    right?

Indeed, its not hard to say `sorry, you can't talk to him, because he's
doing something else over that port.'  Cold comfort if your goal is to
talk to him.

    Mike

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 07:49:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: Wed, 14 May 86 02:37:25 PDT
    From: Murray.pa@Xerox.COM

    One word of caution.... Xerox managed to get off on the wrong foot in
    the Ethernet packet type assignment business.

    If you administer a group of ports, I suggest that the ground rules
    include publishing a who-to-contact as well as a simple (one line?)
    description of its function. Otherwise people will flame at you when you
    won't answer questions.

Fine with me.  

    The proprietary aspect might complicate that attitude. I don't think
    that objection really holds water. It's too easy to look at the bits on
    an ethernet.

I expect that proprietary protocols will be fairly rare.  Mostly, I
expect that people just won't have the time or inclination to document.
I really cannot see why someone would insist on a listing of `Foobar
Company proprietary protocol 1'.


    I like your second suggestion, but somebody is bound to ignore it
    because it takes an extra packet to get started.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 11:07:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: Wed, 14 May 86 02:37:25 PDT
    From: Murray.pa@Xerox.COM

    I like your second suggestion, but somebody is bound to ignore it
    because it takes an extra packet to get started.


For reference, I suggest people read the documentation for the CHAOSNET
protocol, MIT A.I. Memo 628.  Basically, CHAOSNET wins in the connection
initiation methodology and the IP-class of protocols lose.  Small fields
(read: numbers) that require a number czar make ease of extension very
difficult.  In chaos it is easy to say "I want to invent a protocol
called RESET-TIME-SERVER" because the name of the protocol can also be
the contact name used in the RFC (SYN, for TCP folks).

I have a feeling TP4 loses in this respect as well.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      14 May 1986 15:05:06 PDT
From:      POSTEL@USC-ISIB.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   re: port collisions


Hi.

The number czar is primarily interested in having the protocols
assigned ports from the reserved space (numbers 0 through 255) be
documented and public.  It does not really matter much if the protocol
is developed for academic internet research or practical commercial
use.  It does matter that there be some good reason for the protocol
and that there be some evidience that some work was actually done on
the protocol.  The number czar dislikes assigning numbers on
speculation (that is, tends to turn down requests of the form "I might
write some protocols, give me a bunch of port numbers").  There are
already a few assignments for essentially private protocols (some that
would not be made today), but in most of these recent cases the
developer was able to send the czar some description of the protocol.

One of the great things about the Internet is that is an "open
system", and what that means is that the protocols are public.  Over
and over the czar has seen people develop some little hack protocol
for their own private use that turns out to be a neat thing and other
people want to use it too but it is not documented.

If there really is a need for a set of port numbers to be assigned to
individuals or companies for private use, the number czar is perfectly
happy to do the work of keeping track of who owns which numbers and
giving the next available number to the next requestor.  If this is a
thing we want to do what part of the port number space should be
allocated to this?  How many numbers should be set aside for this type
of assignment?  What is the impact on existing programs and systems?
Is anyone using the numbers that will suddenly be off limits by this
this reservation of part of the port number space?

Or if the other suggestion is followed (to have a port assigned for a
multiplexing service based on a character string argument), the number
czar is happy to keep the list of unique (initial) strings and who is
the contact person.

--jon.
-------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 13:01:46 EDT
From:      PATTERSON@BLUE.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

Yes, but then you have collision problems with protocol names. Most people
would use acronyms, not word-by-word forms. You still need a Socket Czar,
only now sockets have a (reasonably) human-understandable format (i.e TELNET
instead of 23.)
 
Ross Patterson
Center for Computer and Information Services
Rutgers University
-------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 13:47:27 EDT
From:      braden@ISI-BRADEN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

It sounds like another version of the SNA/DECNET free-enterprise protocol
wars.

Do you think we should encourage the proliferation of private protocols,
many of them doing the same things?  It is clearly in the national 
interest (that's us, friends) to promote maximal interconnection of
heterogeneous systems.  That is what standards are for.

Until recently, in England there were several different standards for
electric plugs, because each of the 19th century power barons designed
their own.  So you bought an appliance with a cord but no plug on the
end, and added the plug necessary for your outlet. Rather like a
configuration file, isn't it?

As a customer, do you think I should buy a software system from a vendor
that did not have the resources to properly document its internal function?
I wonder what kind of maintenance and support I will get with that product.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      14 May 1986 14:56:02 CDT
From:      AFDDN.BEACH@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   [domiller@lognet2.ARPA (Donald G. Miller): HP 3000]
Anybody know where one of these monsters is?
Darrel
                ---------------

Return-Path: <domiller@lognet2.ARPA>
Received: FROM LOGNET2.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 13 May 86 10:15:45 CDT
Return-Path: <domiller@lognet2.ARPA>
Received: by lognet2.ARPA
	id AA11563; Tue, 13 May 86 11:15:36 edt
Message-Id: <8605131515.AA11563@lognet2.ARPA>
Date: Tue May 13 11:15:33 1986
From: domiller@lognet2.ARPA (Donald G. Miller)
Subject: HP 3000
To: afddn.beach@gunter-adam
Status:  N 

Is there anyone on the DDN with full suite or working a full
suite on an HP 3000???? If so can you give me a POC?? tks don m
-------
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 14:36:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: 14 May 86 13:01:46 EDT
    From: Ross Patterson <PATTERSON@BLUE.RUTGERS.EDU>

    Yes, but then you have collision problems with protocol names. Most people
    would use acronyms, not word-by-word forms. You still need a Socket Czar,
    only now sockets have a (reasonably) human-understandable format (i.e TELNET
    instead of 23.)
 
Go read Benson's message again.  He said that private protocols would be
rather long contact names, possibly including the vendor/entity that
implemented it as part of the name.  People who use short names or
acronyms are anti-social.  Standard contact-names that correspond to
RFCs could still be administered by a Czar, e.g., TELNET, SUPDUP, ECHO,
but private protocols would have names like SYMBOLICS-NFILE.

Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE
SAME BUILDING OF THE SAME COMPANY.  Since numbers don't mean anything,
we both happened to pick 666 for our private port number.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      14 May 1986 at 1437-EDT
From:      hsw at TYCHO.ARPA  (Howard Weiss)
To:        cerf at isi
Cc:        tcp-ip at nic
Subject:   re: C implementations of TCP/IP

Vint,

I have a version of TCP/IP that was written by BBN under
DCA sponsorship.  This version was written in C and runs
on V6 UNIX.  There is some documentation and it currently
runs on the internet at both our site and at DCEC.  Also,
this is the version that Honeywell converted to run on
the SCOMP.

Howard Weiss
National Computer Security Center
(301) 859-4491
-------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 14:45:00 EDT
From:      Margulies@SCRC-YUKON.ARPA (Benson I. Margulies)
To:        mod.protocols.tcp-ip
Subject:   re: Port Collisions


    Date: Tue, 13 May 86 21:22:49 -0400
    From: Craig Partridge <craig@loki.bbn.COM>


    > We here at Symbolics are concerned with the process of assigning TCP/UDP
    > port numbers.  It is not always appropriate for us (and other vendors)
    > to apply for ports in the Czar-controlled first 256 ports.  Either
    > because of time constraints or issues of proprietary information, we
    > cannot always write and distribute an RFC for each of our protocols.

    Why not make the port numbers used user/site configurable?  Berkeley
    actually did this quite nicely with a services list, which mapped
    a service name/protocol pair with a port number.  Since programs
    use this database (or are supposed to) to find out what port they
    are supposed to us, one could run SMTP on TCP port 25 on the Internet
    but port 243 on some private network if one so chose.

We believe in 'plug-in-and-play' software.  Expecting not-very-savy
users to figure out the port usage of all the various programs they are
using is a big expectation.

What if two sites disagree on the port for a protocol? They will never
be able to inter-operate!

We have logical services and protocols that are mapped to ports. The
only way to make that do what you want is to use a different protocol
name for each port assignment in use anyplace, so that the database of
hosts can indicate which hosts are going to talk over which ports.  This
is an unreasonable burden.

    The advantage is the vendor need not necessarily worry about what
    port you pick for your special application -- it can always be
    changed among cooperating machines.

Its the vendor's job to worry so the user dosen't have to.

    Craig Partridge
    CSNET Technical Staff

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 14:52:00 EDT
From:      Margulies@SCRC-YUKON.ARPA (Benson I. Margulies)
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: Wed, 14 May 86 10:47:27 PDT
    From: braden@isi-braden.arpa (Bob Braden)

    It sounds like another version of the SNA/DECNET free-enterprise protocol
    wars.

    Do you think we should encourage the proliferation of private protocols,
    many of them doing the same things?  It is clearly in the national 
    interest (that's us, friends) to promote maximal interconnection of
    heterogeneous systems.  That is what standards are for.

Not all protocols are suitable for standardization.  Sometimes, there
isn't enough knowledge in the industry to settle on a standard.  We
can't be expected to wait around.

Some protocols perform very specific functions that are pointless to
standardize.  Heavily networked products are very likely to involve
network protocols that are not useful outside a particular application.
Yet these have to have ports, and those ports can't conflict with other,
interoperating protocols.

    Until recently, in England there were several different standards for
    electric plugs, because each of the 19th century power barons designed
    their own.  So you bought an appliance with a cord but no plug on the
    end, and added the plug necessary for your outlet. Rather like a
    configuration file, isn't it?

This is why I'm opposed to the configuration file solution.


    As a customer, do you think I should buy a software system from a vendor
    that did not have the resources to properly document its internal function?
    I wonder what kind of maintenance and support I will get with that product.

The statement `did not have the resources' is not a realistic view. As a
customer, I'd rather my vendor spent their (my) money on supporting me,
not informing the internet community about the network protocols in
their product.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 15:30:04 EDT
From:      MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   private/proprietary protocols

Personally, I think that proprietary protocols have no place in the Internet
research/military community.  They are absolutely not in the best interest
of US national defense.  Quite enough problems exist because the UUCP protocol
is AT&T proprietary.  As a software vendor, I sympathize with the need for
trade secret and other forms of software protection.  However, a deliberate
attempt to lock out interoperability with other vendors' products is bad for
the customer and ultimately bad for the vendor.

Private protocols should be discouraged as much as possible.  If a protocol is
useful enough to consume part of the Internet namespace, it is useful enough
to be documented for the rest of the Internet community.  My feeling is that
if there MUST be a private protocol assignment it should be "one port per
organization", and that organization should make some arrangement to identify
which of their private protocols they way (e.g. the first octet from the user
agent identifies "MIT protocol #n", or "Symbolics protocol #n", etc.)

I have occasionally been frustrated with the delays and paperwork involved
in getting numbers assigned by Postel, but at the same time I feel these
procedures are necessary.  If anything, Jon has erred on the side of giving
out a number in questionable circumstances.  I vote to keep the current
procedure; if it ain't broke don't fix it.

-- Mark --
-------

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 15:56:02 EDT
From:      AFDDN.BEACH@GUNTER-ADAM.ARPA
To:        mod.protocols.tcp-ip
Subject:   [domiller@lognet2.ARPA (Donald G. Miller): HP 3000]

Anybody know where one of these monsters is?
Darrel
                ---------------

Return-Path: <domiller@lognet2.ARPA>
Received: FROM LOGNET2.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 13 May 86 10:15:45 CDT
Return-Path: <domiller@lognet2.ARPA>
Received: by lognet2.ARPA
	id AA11563; Tue, 13 May 86 11:15:36 edt
Message-Id: <8605131515.AA11563@lognet2.ARPA>
Date: Tue May 13 11:15:33 1986
From: domiller@lognet2.ARPA (Donald G. Miller)
Subject: HP 3000
To: afddn.beach@gunter-adam
Status:  N 

Is there anyone on the DDN with full suite or working a full
suite on an HP 3000???? If so can you give me a POC?? tks don m
-------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 18:05:06 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: port collisions



Hi.

The number czar is primarily interested in having the protocols
assigned ports from the reserved space (numbers 0 through 255) be
documented and public.  It does not really matter much if the protocol
is developed for academic internet research or practical commercial
use.  It does matter that there be some good reason for the protocol
and that there be some evidience that some work was actually done on
the protocol.  The number czar dislikes assigning numbers on
speculation (that is, tends to turn down requests of the form "I might
write some protocols, give me a bunch of port numbers").  There are
already a few assignments for essentially private protocols (some that
would not be made today), but in most of these recent cases the
developer was able to send the czar some description of the protocol.

One of the great things about the Internet is that is an "open
system", and what that means is that the protocols are public.  Over
and over the czar has seen people develop some little hack protocol
for their own private use that turns out to be a neat thing and other
people want to use it too but it is not documented.

If there really is a need for a set of port numbers to be assigned to
individuals or companies for private use, the number czar is perfectly
happy to do the work of keeping track of who owns which numbers and
giving the next available number to the next requestor.  If this is a
thing we want to do what part of the port number space should be
allocated to this?  How many numbers should be set aside for this type
of assignment?  What is the impact on existing programs and systems?
Is anyone using the numbers that will suddenly be off limits by this
this reservation of part of the port number space?

Or if the other suggestion is followed (to have a port assigned for a
multiplexing service based on a character string argument), the number
czar is happy to keep the list of unique (initial) strings and who is
the contact person.

--jon.
-------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 18:23:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        mod.protocols.tcp-ip
Subject:   Port Collisions

The collision problem with protocol names is not as severe as the with
(small) protocol numbers.  People implementing private applications
tend to use ports in the low 500s (or working down from 1024), so
there is a fair chance that there will eventually be conflicts.
Whereas I doubt that Symbolics would have much trouble testing a new
service named "SYMBOLICS-PRIVATE-PROTOCOL-XYZ-PRIME".  When a protocol
becomes well enough known and widely enough used that it needs a short
snappy name, -then- you go talk to the Socket Czar.

--Rob

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 19:43:02 EDT
From:      karels@MONET.BERKELEY.EDU (Mike Karels)
To:        mod.protocols.tcp-ip
Subject:   Re: C implementations of TCP/IP

The Berkeley 4.2/4.3BSD TCP/IP code is written in C.  It's not quite
public domain (it is copyright by the university), but the only
restriction on its use is that the University of California be
credited.

		Mike

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 19:54:03 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


	Right. What happens if you pick a name for your private
protocol that happens to be exactly the same as the name someone else
picked for their private protocol? You are merely using strings
instead of numbers; the same problems can happen. The set of possible
identifiers is still pretty small, if people use descriptive english
words for services.
	Now, if you preface all your private services with some
personal string, e.g. 'SYMBOLICS-', as in 'SYMBOLICS-NEW-FILE' then
maybe you have a valid point.

	Noel
-------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 21:15:44 EDT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        mod.protocols.tcp-ip
Subject:   re: C implementations of TCP/IP


Vint,

I have a version of TCP/IP that was written by BBN under
DCA sponsorship.  This version was written in C and runs
on V6 UNIX.  There is some documentation and it currently
runs on the internet at both our site and at DCEC.  Also,
this is the version that Honeywell converted to run on
the SCOMP.

Howard Weiss
National Computer Security Center
(301) 859-4491
-------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 22:09:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: Wed, 14 May 86 10:47:27 PDT
    From: braden@isi-braden.arpa (Bob Braden)

    It sounds like another version of the SNA/DECNET free-enterprise protocol
    wars.

    Do you think we should encourage the proliferation of private protocols,
    many of them doing the same things?  It is clearly in the national 
    interest (that's us, friends) to promote maximal interconnection of
    heterogeneous systems.  That is what standards are for.

    Until recently, in England there were several different standards for
    electric plugs, because each of the 19th century power barons designed
    their own.  So you bought an appliance with a cord but no plug on the
    end, and added the plug necessary for your outlet. Rather like a
    configuration file, isn't it?

    As a customer, do you think I should buy a software system from a vendor
    that did not have the resources to properly document its internal function?
    I wonder what kind of maintenance and support I will get with that product.

Example.  Symbolics calls its current "private file protocol" NFILE.  It
is currently documented in the Release 6.1 Release Notes.  We know it to
be far superior to TCP/FTP and pervious file protocols on Lisp Machines.
NFILE is a true file ACCESS protocol as oposed to FTP which is a
transfer protocol.  Back then we weren't ready to tout it to the rest of
the world.  I'm still not sure we are.  The reasons are many.  We aren't
sure it is really sufficient.  We do know that there are some very
complex operations in it because of the need to handle aborting out of
operations correctly.  The generic-file-system model it assumes may not
fit in well with all known system.  We also fear that many people will
not understand the need for some of the complexity and will either want
it thrown out because they can't figure out how to implement it, or
won't implement the parts without telling people.  (Need I remind people
that Unix TCP/FTP still sends the wrong code for the DELETE operation, I
believe it is.)  Companies may be willing to document their protocols to
let others experiment with them.  They may not be prepared to solidify
on it or to change it to the whims of the masses.  If NFILE replaced
TCP/FTP as the Internet standard, and if we discovered some other
feature that is rather crucial to our system, we would be in the same
ballpark as we are now: a private protocol.

There are sometimes some good reasons not to push private protocols as
standards until all the conditions are right, even though those private
protocols are documented and provide superior functionality.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-May-86 22:28:00 EDT
From:      JSOL@BUCS20.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Documenting locally defined protocols

I want to point out that there's a difference between internally
(to a company) documenting protocols and reporting those protocols
back to the Internet via a RFC.

			--jsol

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 May 1986  22:28 EDT
From:      Jon Solomon <JSOL@BUCS20.BU.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Documenting locally defined protocols
I want to point out that there's a difference between internally
(to a company) documenting protocols and reporting those protocols
back to the Internet via a RFC.

			--jsol
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 01:29:57 EDT
From:      mrose@NRTC-GREMLIN.ARPA (Marshall Rose)
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    If your argument is:  

	 "having a port space of 512 distinct addresses is too small" 

    then I doubt anyone dis-agrees in principle.  On the other hand, if
    your argument is:  

	 "Benson and I, working on the floor for the same company,
	  collided, so the port space is too small"

    Then your argument points more to a possible (mis)management problem
    in your company than a port scarcity problem!  

    Let's face it, 512 distinct addresses for ports probably is too
    small for the totality of applications that can/could use TCP.  I
    don't think it's too small any given group of co-operating sites
    using TCP, though I could be convinced otherwise.  

    Personally, I like the Berkeley method since you can just define
    some numbers to meet your needs.  I'm not so keen on using strings
    or datastructures as port identifiers, though I'm sure, when ISO
    gets around to defining the port space for TS-users, they'll be sure
    to add an option for regular expressions, mandelbrots, etc.  (-:

/mtr

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 03:19:37 EDT
From:      dpk@mcvax.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Port Collisions

I like the idea of the "multiplexing port".  Consider this one
vote for it.

-Doug-

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 07:49:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: Wed 14 May 86 19:54:03-EDT
    From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>

	    Right. What happens if you pick a name for your private
    protocol that happens to be exactly the same as the name someone else
    picked for their private protocol? You are merely using strings
    instead of numbers; the same problems can happen. The set of possible
    identifiers is still pretty small, if people use descriptive english
    words for services.
	    Now, if you preface all your private services with some
    personal string, e.g. 'SYMBOLICS-', as in 'SYMBOLICS-NEW-FILE' then
    maybe you have a valid point.

That is exactly my plan.


	    Noel
    -------

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 08:03:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Port Collisions


    From: Doug Kingston <mcvax!dpk@seismo.CSS.GOV>

    I like the idea of the "multiplexing port".  Consider this one
    vote for it.

    -Doug-

well, so do I.  However, for it to be a workable solution, there has to
be some commitment that it won't be a member of the large `ignored RFC'
collection.  I think that we need a registry to tide us over in the
interim.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 May 1986 12:22 EST
From:      Gary D. Twiraga  <GARY%HARVARDA.BITNET@WISCVM.WISC.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
please take my name off your mailing list....


              thank
              gary at harvarda.bitnet
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      15 May 86 14:28 PDT
From:      Jeff Makey <Makey@LOGICON.ARPA>, Tom Perrine <tom@LOGICON.ARPA>
To:        tcp-ip@sri-nic
Cc:        Tom Perrine <tom@logicon.arpa>, Jeff Makey <Makey@logicon.arpa>
Subject:   Redirect wars and Buterfly gateways
This month's issue (May) of "Mini-Micro Systems" has a blurb in the
"Breakpoints" section (page 20) about a system called "Monarch", from
BBN Laboratories which will have 8,192 parallel processors of an
undisclosed type.  In the paragraph they mention that, for those who
can't wait for Monarch, BBN is shipping something called the "Butterfly"
system consisting of 256 Motorola MC68020 processors working in
parallel.  Is this any relation to the much-alluded-to "Butterfly
gateway" which is supposed to save us from the ravages of brain-dead
gateways?

Speaking of brain-dead gateways, we have had some more instances of the
ICMP "redirect wars".  This morning SRI-MILNET-GW redirected us to
BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened
11 times in 29 seconds while trying to establish a connection.
A reponse came in 23 seconds, but after we had timed out.

Obviously this is sub-optimal...

Tom Perrine & Jeff Makey

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 11:58:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    Date: Wed, 14 May 86 17:46:32 -0700
    From: Marshall Rose <mrose@nrtc-gremlin>

	If your argument is:  

	     "having a port space of 512 distinct addresses is too small" 

	then I doubt anyone dis-agrees in principle.  On the other hand, if
	your argument is:  

	     "Benson and I, working on the floor for the same company,
	      collided, so the port space is too small"

	Then your argument points more to a possible (mis)management problem
	in your company than a port scarcity problem!  

We were both doing independent, exploratory research of completley
unrelated problem domains.  Maybe we should have a number czar that is
on call 24 hours a day in case somebody has a hack attack at 9:30pm (or
3am) and needs a protocol number in 5 minutes.  Because my application
was stream oriented it works over TCP and CHAOS.  I didn't have any
problem with Chaos because my protocol was called MANDELBROT and
Benson's was completely different.

	Let's face it, 512 distinct addresses for ports probably is too
	small for the totality of applications that can/could use TCP.  I
	don't think it's too small any given group of co-operating sites
	using TCP, though I could be convinced otherwise.  

Here is a list of protocols that we use at Symbolics.  Some are trivial.
Some work over TCP and have RFCs.  All are (or were at one time or
another) useful, but not critical.  Sorry to bother everybody with this
list, but it shows that one company has several protocols that are not
all RFCs.  I don't think any of the ones below are considered
proprietary.  That's 32+ protocols we have use for.  If 16 companies or
groups or implementations each have 32 different protocols, we would (a)
have a tower of Babel, and (b) run out of the 512 port numbers.  The
tower of Babel might be needed.  For example, what machines other than
Suns can use the Sun net-paging protocol?

 "MANDELBROT"		My network mandelbrot protocol and is Lisp only
			(it actually sends Lisp forms)
 "SEND"			Interactive messages (ancient)
 "CONVERSE"		Interactive messages, done much better
 "SMTP"			(It's a byte stream protocol)
 "EXPAND-MAILING-LIST"	(ditto)

 "ECHO"			I think these have TCP equivalents
 "BABEL"
 "TIME"
 "NAME"

 "MAIL"			Chaos version
 "UPTIME"		Similar to TIME
 "QFILE"		(old) LispM file protocol
 "NFILE"		new one
 "FINGER"		Similar to NAME, but simpler in ways

 "DOMAIN"		The internet domain resolver stuff

 "NAMESPACE"		Our own namespace stuff, written before the RFC
 "NAMESPACE-TIMESTAMP"	for domains came out, and in some of our
 "WHO-AM-I"		opinions, superior 

 "TELNET"		Specified in an RFC
 "SUPDUP"		Specified in an RFC
 "TELSUP"		A mixture of the two
 "TTYLINK"		"raw" linking; no protocol.  useful for connecting to Unix
 "3600-LOGIN"		Better than all the above for talking to 3600s

 "PRINTER-QUEUE"	Various printer queue operations
 "LGP-STATUS"
 "LGP"
 "LGP-QUEUE"
 "DOVER"
 "DOVER-STATUS"

 "CONFIGURATION"	Various other useful protocols
 "RESET-TIME-SERVER"	For machines whose clocks are off
 "TCP"			To connect to TCP streams through a protocol gateway
 "NOTIFY"		Information dispersal
 "STATUS"		Network status
 "DUMP-ROUTING-TABLE"	Topology debugging
 "RTAPE"		Remote Tape facility

	Personally, I like the Berkeley method since you can just define
	some numbers to meet your needs.  I'm not so keen on using strings
	or datastructures as port identifiers, though I'm sure, when ISO
	gets around to defining the port space for TS-users, they'll be sure
	to add an option for regular expressions, mandelbrots, etc.  (-:

    /mtr

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 12:04:14 EDT
From:      root@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: port collisions


I think there is a problem here. Due to obvious security reasons
many of these protocols will need a low socket number and there are
only 255 of those guaranteed to be available (UNIX extends that to
1023 but I don't think everyone can honor that.) Some small portion
of that is already in use and if commercial trends continue I suspect
many, many vendors will need a *secure* port for their products.

The only solution I can think of is a super-server protocol which
would listen on a single secure port and map strings to available non-secure
ports indirectly (I believe the TOPS-20 IPC works something like this.)
I've thought about it a few hours and it's not easy, especially when
you start to take different TCP implementations into account (how exactly
do I reserve and "hand-off" a port number between two unrelated processes?
that's an O/S issue but I fear not generally easy.)

Doesn't SUN's RPC (which I believe is in the public domain) address this
issue (no pun intended)? If you say "do you seriously expect me to implement
RPC and XDR just to get a port number?", I sympathize, I was only trying
to find analogues for enlightenment.

	-Barry Shein, Boston University

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 13:22:00 EDT
From:      GARY@HARVARDA.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

please take my name off your mailing list....


              thank
              gary at harvarda.bitnet

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu 15 May 86 17:31:54-PDT
From:      MULHERN@SRI-KL.ARPA
To:        braden@ISI-BRADEN.ARPA
Cc:        Margulies@SCRC-YUKON.ARPA, Murray.pa@XEROX.COM, postel@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Port Collisions
I did work for Jon Brommeland at NAVELEX Vallejo which was sponsored
by PDW-120.  He did not let us contact 120 directly, and the Vallejo
involvement did not turn out well, but I (and several others here)
learned much about 120's systems -- NWSS, FHLT,HLT,OBS, OBU, IID, 
STT/TDCS and ISE.  Our task was to design a local network for
the 120 testbed at Patuxent River.  We also reviewed the initial
specifications for OBU  (non-black world).  This work was completed
in 82/83.
-------
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 16:16:44 EDT
From:      dab@BORAX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   port collisions


   Date: Thu, 15 May 86 12:04:14 EDT
   From: Ra <root@BU-CS.BU.EDU>

   I think there is a problem here. Due to obvious security reasons
   many of these protocols will need a low socket number and there are
   only 255 of those guaranteed to be available (UNIX extends that to
   1023 but I don't think everyone can honor that.) Some small portion
   of that is already in use and if commercial trends continue I suspect
   many, many vendors will need a *secure* port for their products.

	   -Barry Shein, Boston University

As far as I've found, this belief that some ports are secure while
others aren't is only implemented by Berkekley Unix.  Since other IP
implementations do not necessarily honor this belief, there is no
security in using *secure* ports unless your network consists
exclusively of machines running Berkelely Unix.
					David Bridgham

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 17:28:00 EDT
From:      tom@LOGICON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Redirect wars and Buterfly gateways

This month's issue (May) of "Mini-Micro Systems" has a blurb in the
"Breakpoints" section (page 20) about a system called "Monarch", from
BBN Laboratories which will have 8,192 parallel processors of an
undisclosed type.  In the paragraph they mention that, for those who
can't wait for Monarch, BBN is shipping something called the "Butterfly"
system consisting of 256 Motorola MC68020 processors working in
parallel.  Is this any relation to the much-alluded-to "Butterfly
gateway" which is supposed to save us from the ravages of brain-dead
gateways?

Speaking of brain-dead gateways, we have had some more instances of the
ICMP "redirect wars".  This morning SRI-MILNET-GW redirected us to
BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened
11 times in 29 seconds while trying to establish a connection.
A reponse came in 23 seconds, but after we had timed out.

Obviously this is sub-optimal...

Tom Perrine & Jeff Makey

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 19:29:35 EDT
From:      mrose@nrtc-gremlin.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    The obviously problem with a "multiplexing port" is that you can no
    longer tell by looking at the TCB what protocol is being spoken.
    This renders programs like netstat on BSD UNIX, et. al., pretty
    much worthless.  If we're going to expand the port space somehow, I
    vote we do it explicitly in the TCP headers, so it's part of the
    information in the TCB, rather than expand the port space covertly
    by exchanging the information in the TCP data.  

/mtr

    ps:  of course, this is the exact opposite of what we did in rfc973
    (iso transport on top of the tcp), primarily because I thought 1)
    keeping track of the numbers, if there ever were numbers, should be
    separate from the tcp port space, since the protocols probably
    weren't going to look anything like our good old ARM-style protocols
    ; and, 2), there's a good chance that we'd need more than 512 port
    numbers in the next three-five years.  To postpone that problem, 4K
    port numbers were reserved; presumably, though I didn't think about
    it, 2K of those are for "private" use.  

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 19:58:31 EDT
From:      geof@imagen.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: C implementations of TCP/IP

Two from MIT that I know of:
    - The MIT PC/IP software for the IBM-PC.
    - The V6 Unix TCP/IP software written by Liza Martin at MIT.
The alto implementation (BCPL) is also available; pieces of each of
the unix packages are direct translations to C of the alto code.

Both the MIT packages should be available from someone at the systems
group at MIT.  The only appropriate person I know of who is still
(sort of) in the systems group is Jerry Saltzer.

In the meantime, here is an implementation of TCP that I wrote and
am willing to put in the public domain.  I call it "tinytcp" after
"tinybasic" and "tiny-c" -- it's a very simple TCP that accomodates
a busywaiting style of coding.  We use it here at Imagen to allow
us to boot our image processors using arpa-ftp.  There are one or
two nasty hacks in the code.  The worst hack is that big-endian
byte ordering is assumed.  Please send flames about such hacks to
/dev/null.  But report any bugs to me.

- Geof

---------------CUT HERE------------------------------------------------
#!/bin/sh
: "This is a shell archive, meaning:                              "
: "1. Remove everything above the #! /bin/sh line.                "
: "2. Save the resulting test in a file.                          "
: "3. Execute the file with /bin/sh (not csh) to create the files:"
: "	README"
: "	arp.c"
: "	sed.c"
: "	sed.h"
: "	tinyftp.c"
: "	tinytcp.c"
: "	tinytcp.h"
: "This archive created:  Thu May 15 16:43:07 PDT 1986 "
echo file: README
sed 's/^X//' >README << 'END-of-README'
X
X    TinyTcp Public Domain Release
X
XThe files in this release contain a simple implementation of
XTCP & FTP, suitable for burning into ROM.  It is, in effect,
Xa big hack put together in two or three days.  It works for
Xus, though, and you might like it, too.  Warning: the code
Xwas intended for a 68000, and doesn't have any byte swapping
Xsupport in it.  Shouldn't be too hard to add, though.
X
X    - Geof Cooper
X      Imagen Corporation
X      [imagen!geof@decwrl.dec.com]
X      April 16, 1986
X
XThe package requires some system support:
X
X    clock_ValueRough() - should be a procedure that returns the current
X        value of a millisecond clock.  The procedure is called frequently,
X        so that interrupts are not needed to service the clock.  Our
X        implementation polls the real time timer and assumes that it is
X        called frequently enough so that it doesn't miss clock ticks (Since
X        the timer is only used for network timeouts, it doesn't really matter
X        if it does miss clock ticks, of course).  Systems without a clock
X        could probably get by with a procedure that increments a static
X        variable and returns it, by adjusting the timeout constants in the
X        program.
X
X    Network driver - some network interface  driver is needed.  A driver for a
X        3Com multibus (ethernet) board is included; this board isn't made anymore
X        (at least not by 3Com), so you'll probably need to write a driver for the
X        board in your system.
X
X
XGuide to source files:
X
X    sed.c - Simple Ethernet Driver - Driver for 3Com multibus card.  If you
X            have another type of Ethernet board, you can use this driver as
X            a template.
X
X    sed.h - header file for the above.
X
X    arp.c - Implementation of Address Resolution Protocol.  Note that there
X            is no arp "mapping" per se.  The higher level code (tcp, in this case)
X            is required to keep track of internet and ethernet addresses.
X
X    tinytcp.c - Implementation of TCP.
X
X    tinytcp.h - Header file for above, and for everything else.
X
X    tinyftp.c - Implementation of FTP, only allows files to be retrieved, not sent.
END-of-README
echo file: arp.c
sed 's/^X//' >arp.c << 'END-of-arp.c'
X/* 
X * SAR: Simple Address Resolution Protocol Implementation
X * Written by Geoffrey Cooper, September 27, 1983
X * 
X * This package implements a very simple version of the Plummer Address
X * Resolution Protocol (RFC 826).  It allows clients to resolve Internet
X * addresses into Ethernet addresses, and knows how to respond to an
X * address resolution request (when the transmit buffer is free).
X * 
X * Routines:
X * 
X *  sar_CheckPacket( pb ) => 1, if ARP packet and processed, 0 otherwise
X *  sar_MapIn2Eth( ina, ethap ) => 1 if did it, 0 if couldn't.
X *
X * Copyright (C) 1983, 1986 IMAGEN Corporation
X *  "This code may be duplicated in whole or in part provided that [1] there
X *   is no commercial gain involved in the duplication, and [2] that this
X *   copyright notice is preserved on all copies.  Any other duplication
X *   requires written notice of the author."
X * 
X */
X#include "tinytcp.h"
X
Xsar_CheckPacket(ap)
X    register arp_Header *ap;
X{
X    register arp_Header *op;
X
X    if ( ap->hwType != arp_TypeEther || /* have ethernet hardware, */
X         ap->protType != 0x800 ||       /* and internet software, */
X         ap->opcode != ARP_REQUEST ||   /* and be a resolution req. */
X         ap->dstIPAddr != sin_lclINAddr /* for my addr. */
X       ) return ( 0 );                  /* .... or we ignore it. */
X
X    /* format response. */
X    op = (arp_Header *)sed_FormatPacket(ap->srcEthAddr, 0x806);
X    op->hwType = arp_TypeEther;
X    op->protType = 0x800;
X    op->hwProtAddrLen = (sizeof(eth_HwAddress) << 8) + sizeof(in_HwAddress);
X    op->opcode = ARP_REPLY;
X    op->srcIPAddr = sin_lclINAddr;
X    MoveW(sed_lclEthAddr, op->srcEthAddr, sizeof(eth_HwAddress));
X    ap->dstIPAddr = op->srcIPAddr;
X    MoveW(ap->srcEthAddr, op->dstEthAddr, sizeof(eth_HwAddress));
X
X    sed_Send(sizeof(arp_Header));
X    
X    return ( 1 );
X}
X
X/* 
X * Do an address resolution bit.
X */
Xsar_MapIn2Eth(ina, ethap)
X    longword ina;
X    eth_HwAddress *ethap;
X{
X    register arp_Header *op;
X    extern in_HwAddress sin_lclINAddr;
X    register i;
X    longword endTime;
X    longword rxMitTime;
X
X    sed_Receive( 0 );
X    endTime = clock_ValueRough() + 2000;
X    while ( endTime > clock_ValueRough() ) {
X        op = (arp_Header *)sed_FormatPacket(&sed_ethBcastAddr[0], 0x806);
X        op->hwType = arp_TypeEther;
X        op->protType = 0x800;
X        op->hwProtAddrLen = (sizeof(eth_HwAddress) << 8) + sizeof(in_HwAddress);
X        op->opcode = ARP_REQUEST;
X        op->srcIPAddr = sin_lclINAddr;
X        MoveW(sed_lclEthAddr, op->srcEthAddr, sizeof(eth_HwAddress));
X        op->dstIPAddr = ina;
X
X        /* ...and send the packet */
X        sed_Send( sizeof(arp_Header) );
X
X        rxMitTime = clock_ValueRough() + 250;
X        while ( rxMitTime > clock_ValueRough() ) {
X            op = (arp_Header *)sed_IsPacket();
X            if ( op ) {
X                if ( sed_CheckPacket(op, 0x806) == 1 &&
X                    op->protType == 0x800 &&
X                    op->srcIPAddr == ina &&
X                    op->opcode == ARP_REPLY ) {
X                    MoveW(op->srcEthAddr, ethap, sizeof(eth_HwAddress));
X                    return ( 1 );
X                }
X                sed_Receive(op);
X            }
X        }
X    }
X    return ( 0 );
X}
END-of-arp.c
echo file: sed.c
sed 's/^X//' >sed.c << 'END-of-sed.c'
X/* 
X * Ethernet Driver.
X * A Very Simple set of ethernet driver primitives.  The ethernet (3com Mbus)
X * interface is controlled by busy-waiting, the application is handed the
X * location of on-board packet buffers, and allowed to fill in the
X * transmit buffer directly.  The interface is entirely blocking.
X * 
X * Written March, 1986 by Geoffrey Cooper
X *
X * Copyright (C) 1986, IMAGEN Corporation
X *  "This code may be duplicated in whole or in part provided that [1] there
X *   is no commercial gain involved in the duplication, and [2] that this
X *   copyright notice is preserved on all copies.  Any other duplication
X *   requires written notice of the author."
X * 
X * Primitives:
X *  sed_Init()  -- Initialize the package
X *  sed_FormatPacket( destEAddr ) => location of transmit buffer
X *  sed_Send( pkLength ) -- send the packet that is in the transmit buffer
X *  sed_Receive( recBufLocation ) -- enable receiving packets.
X *  sed_IsPacket() => location of packet in receive buffer
X *  sed_CheckPacket( recBufLocation, expectedType )
X *
X * Global Variables:
X *  sed_lclEthAddr -- Ethernet address of this host.
X *  sed_ethBcastAddr -- Ethernet broadcast address.
X */
X
X#include "tinytcp.h"
X#include "sed.h"
X
X#define en10pages        ((en10size) >> pageshift)
X
Xoctet *sed_va;                          /* virtual address of ethernet card */
Xeth_HwAddress sed_lclEthAddr;           /* local ethernet address */
Xeth_HwAddress sed_ethBcastAddr;         /* Ethernet broadcast address */
XBOOL sed_respondARPreq;                 /* controls responses to ARP req's */
Xchar bufAinUse, bufBinUse;              /* tell whether bufs are in use */
X
X/* 
X *  Initialize the Ethernet Interface, and this package.  Enable input on
X * both buffers.
X */
Xsed_Init()
X{
X    int recState;
X    register i, j;
X
X    recState = 7;                       /* == mine + broad - errors */
X
X    /* Map the Ethernet Interface in, and initialize sed_va */
X    sed_va = (octet *)SED3CVA;        /* our virtual addr */
X
X    /* Map memory for 3Com board (must be 8k boundary) */
X    /* INSERT CODE HERE */
X    map_ethernet_board();
X
X    /* Reset the Ethernet controller */
X    MECSR(sed_va) = RESET;
X    for (i=0; i<10; i++);           /* delay a bit... */
X
X    /* just copy on-board ROM to on-board RAM, to use std. address */
X    Move(MEAROM(sed_va), sed_lclEthAddr, 6);
X    Move(sed_lclEthAddr, MEARAM(sed_va), 6);
X    
X    MECSR(sed_va) |= AMSW;        /* and tell board we did it */
X
X    /*
X     * and initialize the exported variable which gives the Eth broadcast
X     * address, for everyone else to use. 
X     */
X    for (i=0; i<3; i++) sed_ethBcastAddr[i] = 0xFFFF;
X    
X    /* accept packets addressed for us and broadcast packets */
X
X    MECSR(sed_va) = (MECSR(sed_va)&~PA) | recState;
X
X    /* declare both buffers in use... */
X    bufAinUse = bufBinUse = TRUE;
X
X}
X
X/* 
X * Format an ethernet header in the transmit buffer, and say where it is.
X * Note that because of the way the 3Com interface works, we need to know
X * how long the packet is before we know where to put it.  The solution is
X * that we format the packet at the BEGINNING of the transmit buffer, and
X * later copy it (carefully) to where it belongs.  Another hack would be
X * to be inefficient about the size of the packet to be sent (always send
X * a larger ethernet packet than you need to, but copying should be ok for
X * now.
X */
Xoctet *
Xsed_FormatPacket( destEAddr, ethType )
X        register octet *destEAddr;
X{
X    register octet *xMitBuf;
X    
X    xMitBuf = &((octet *)MEXBUF(sed_va))[-0x800];
X    Move( destEAddr, xMitBuf, 6 );
X    Move( sed_lclEthAddr, xMitBuf + 6, 6 );
X    *((short *)(xMitBuf+12)) = ethType;
X    return ( xMitBuf+14 );
X}
X
X/*
X *  Send a packet out over the ethernet.  The packet is sitting at the
X * beginning of the transmit buffer.  The routine returns when the
X * packet has been successfully sent.
X */
Xsed_Send( pkLengthInOctets )
X    register int pkLengthInOctets;
X{
X    register octet *fromO, *toO;
X    register pkLength;
X    register csr;
X
X    pkLengthInOctets += 14;             /* account for Ethernet header */
X    pkLengthInOctets = (pkLengthInOctets + 1) & (~1);
X
X    if (pkLengthInOctets < E10P_MIN) 
X        pkLengthInOctets = E10P_MIN; /* and min. ethernet len */
X
X    /*  and copy the packet where it belongs */
X    pkLength = pkLengthInOctets;
X    fromO = &((octet *)MEXBUF(sed_va))[-0x800] + pkLength;
X    toO = ((octet *)MEXBUF(sed_va));
X
X    while ( pkLength-- ) *--toO = *--fromO;
X    
X    /* send the packet */
X    
X    MEXHDR(sed_va) = 2048 - pkLengthInOctets;
X    MECSR(sed_va) |= TBSW;
X
X    /* and wait until it has really been sent. */
X
X    for (pkLength=0; pkLength < 15; pkLength++) {
X        while ( (! ((csr = MECSR(sed_va)) & JAM)) && (csr & TBSW) )
X            ;
X        if (csr & JAM ) {
X            /* Ethernet Collision detected... */
X#ifdef DEBUG
X            printf("sed: JAM: MECSR=%x\n", csr);
X#endif
X            MEBACK(sed_va) = clock_ValueRough();
X            MECSR(sed_va) |= JAM;
X        } else break;
X    }
X    if ( pkLength == 15 ) SysBug("Go and Buy a New Ethernet Interface.");
X
X    /*  else we sent the packet ok. */
X}
X
X/* 
X *  Enable the Ethernet interface to receive packets from the network.  If
X * the argument is zero, enable both buffers.  If the argument is nonzero,
X * take it as the address of the buffer to be enabled.
X */
Xsed_Receive( recBufLocation )
X    octet *recBufLocation;
X{
X    word enables = 0;
X
X    if (recBufLocation == 0) {
X        bufAinUse = FALSE;
X        bufBinUse = FALSE;
X        enables = (ABSW | BBSW);
X    }
X    recBufLocation -= 16;
X    if (recBufLocation == ((octet *)MEAHDR(sed_va))) {
X        bufAinUse = FALSE;
X        enables = ABSW;
X        }
X    if (recBufLocation == ((octet *)MEBHDR(sed_va))) {
X        bufBinUse = FALSE;
X        enables = BBSW;
X    }
X
X    MECSR (sed_va) |= enables;
X}
X
X/* 
X * Test for the arrival of a packet on the Ethernet interface.  The packet may
X * arrive in either buffer A or buffer B; the location of the packet is
X * returned.  If no packet is returned withing 'timeout' milliseconds,
X * then the routine returns zero.
X * 
X * Note: ignores ethernet errors.  may occasionally return something
X * which was received in error.
X */
X
Xoctet *
Xsed_IsPacket()
X{
X    register oldStatus;
X    register octet *pb;
X    
X    pb = 0;
X    if ( ! bufAinUse && (MECSR(sed_va)&ABSW) == 0 ) 
X        pb = (octet *)MEAHDR(sed_va);
X    if ( ! pb && ! bufBinUse && (MECSR(sed_va)&BBSW) == 0 )
X        pb = (octet *)MEBHDR(sed_va);
X
X    if ( pb ) {
X        if ( ((octet *)pb) == ((octet *)MEAHDR(sed_va)) ) bufAinUse = 1;
X        else bufBinUse = 1;
X        pb += 16;                       /* get past the ethernet header */
X    }
X
X    return ( pb );
X}
X
X/* 
X *  Check to make sure that the packet that you received was the one that
X * you expected to get.
X */
Xsed_CheckPacket( recBufLocation, expectedType )
X    word *recBufLocation;
X    word expectedType;
X{
X    register recHeader = recBufLocation[-8];
X    if ( (recHeader&R_ERROR) != 0 ||
X         (recHeader&R_OFFSET) < E10P_MIN ) {
X         return ( -1 );
X    }
X    if ( recBufLocation[-1] != expectedType ) {
X        return ( 0 );
X    }
X    return (1);
X}
END-of-sed.c
echo file: sed.h
sed 's/^X//' >sed.h << 'END-of-sed.h'
X/* 
X *  Header file for very simple ethernet driver, based on 3Com Multibus
X *  board.
X *
X * Copyright (C) 1986, IMAGEN Corporation
X *  "This code may be duplicated in whole or in part provided that [1] there
X *   is no commercial gain involved in the duplication, and [2] that this
X *   copyright notice is preserved on all copies.  Any other duplication
X *   requires written notice of the author."
X */
X
X#define	en10size        (8*1024)	/* size of interface memory */
X#define	en10pages	((en10size) >> pageshift)
X#define E10P_MIN	60              /* Minimum Ethernet packet size */
X
X/* 
X * The position of the 3Com interface in virtual memory.  If we're
X * Running the bootloader function, then it must be in the last 8k
X * of virtual addresses.
X */
X#ifdef BOOTLOADER
X#define SED3CVA vm_3ComAdr /* hack, only need pb68.h if bootloader */
X#endif
X#ifndef SED3CVA
X#define SED3CVA 0x1c000
X#endif
X
X/* 10Mb Ethernet interface addresses */
X
X#define	MECSR(eth_va)	*(word*)(((octet *) eth_va) + 0x0)
X#define	MEBACK(eth_va)	*(word*)(((octet *) eth_va) + 0x2)
X#define	MEAROM(eth_va)	(word*)(((octet *) eth_va) + 0x400)
X#define	MEARAM(eth_va)	(word*)(((octet *) eth_va) + 0x600)
X#define	MEXHDR(eth_va)	*(word*)(((octet *) eth_va) + 0x800)
X#define	MEXBUF(eth_va)	(word*)(((octet *) eth_va) + 0x1000)
X#define	MEAHDR(eth_va)	(word*)(((octet *) eth_va) + 0x1000)
X#define	MEBHDR(eth_va)	(word*)(((octet *) eth_va) + 0x1800)
X
X/* control/status register fields */
X
X#define	BBSW		0x8000	/* Buffer B belongs to Network */
X#define	ABSW		0x4000	/* Buffer A belongs to Network */
X#define	TBSW		0x2000	/* Transmit buffer belongs to Network */
X#define	JAM		0x1000	/* Set when transmit collision */
X#define	AMSW		0x0800	/* 
X#define	RBBA		0x0400	/* Oldest received packet is in B */
X/*#define	UNUSED		0x0200 */
X#define	RESET		0x0100	/* Reset the controller */
X#define	BINT		0x0080	/* Interrupt when BBSW=>0 (packet in B) */
X#define	AINT		0x0040	/* Interrupt when ABSW=>0 (packet in A) */
X#define	TINT		0x0020	/* Interrupt when TBSW=>0 (transmit done) */
X#define	JINT		0x0010	/* Enable interrupts when JAM=>1 */
X#define	PA		0x000F	/* Which packets should be received? */
X#define INTENABLS	0x00F0
X
X/*
X * Receiver Header Fields: 
X * The receiver header is the first (short) word of the receive buffer.  It
X * includes such information as how big the packet is, whether it was a
X * broadcast, whether there was an error in receiving it, etc.
X */
X
X#define	R_FCS		0x8000	/* fcs error */
X#define	R_BCAST		0x4000	/* packet was NOT a broadcast */
X#define	R_RANGE		0x2000	/* range error (size of pkt?) */
X#define	R_MATCH		0x1000	/* packet is multicast (i.e., address
X				   received is not that of the interface) */
X#define	R_FRAME		0x0800	/* framing error */
X#define	R_ERROR		0x8800	/* was there any error */
X#define	R_OFFSET	0x07FF	/* packet length + 1 word */
X
Xextern octet *sed_FormatPacket(), *sed_WaitPacket();
X
X#ifdef BOOTLOADER
X#define ConsPrintf printf
X#endif
END-of-sed.h
echo file: tinyftp.c
sed 's/^X//' >tinyftp.c << 'END-of-tinyftp.c'
X/*
X * tinyftp.c - user ftp built on tinytcp.c
X *
X * Written March 31, 1986 by Geoffrey Cooper
X *
X * Copyright (C) 1986, IMAGEN Corporation
X *  "This code may be duplicated in whole or in part provided that [1] there
X *   is no commercial gain involved in the duplication, and [2] that this
X *   copyright notice is preserved on all copies.  Any other duplication
X *   requires written notice of the author."
X */
X#include "tinytcp.h"
X
Xtcp_Socket ftp_ctl, ftp_data, ftp_data2;
Xbyte ftp_cmdbuf[120];
Xint ftp_cmdbufi;
X
Xbyte ftp_outbuf[80];
Xint ftp_outbufix, ftp_outbuflen;
X    
Xshort ftp_rcvState;
X#define ftp_StateGETCMD     0       /* get a command from the user */
X#define ftp_StateIDLE       1       /* idle connection */
X#define ftp_StateINCOMMAND  2       /* command sent, awaiting response */
X#define ftp_StateRCVRESP    3       /* received response, need more data */
X
Xchar *ftp_script[7];
Xint ftp_scriptline;
Xchar ftp_retrfile[80];
XBOOL ftp_echoMode;
X
Xftp_ctlHandler(s, dp, len)
X    tcp_Socket *s;
X    byte *dp;
X    int len;
X{
X    byte c, *bp, data[80];
X    int i;
X
X    if ( dp == 0 ) {
X        tcp_Abort(&ftp_data);
X        return;
X    }
X
X    do {
X        i = len;
X        if ( i > sizeof data ) i = sizeof data;
X        MoveW(dp, data, i);
X        len -= i;
X        bp = data;
X        while ( i-- > 0 ) {
X            c = *bp++;
X            if ( c != '\r' ) {
X                if ( c == '\n' ) {
X                    ftp_cmdbuf[ftp_cmdbufi] = 0;
X                    ftp_commandLine();
X                    ftp_cmdbufi = 0;
X                } else if ( ftp_cmdbufi < (sizeof ftp_cmdbuf)-1 ) {
X                    ftp_cmdbuf[ftp_cmdbufi++] = c;
X                }
X            }
X        }
X    } while ( len > 0 );
X}
X
Xftp_commandLine()
X{
X    printf("> %s\n", ftp_cmdbuf);
X    switch(ftp_rcvState) {
X     case ftp_StateIDLE:
X        if ( ftp_cmdbuf[3] == '-' )
X            ftp_rcvState = ftp_StateRCVRESP;
X        break;
X
X     case ftp_StateINCOMMAND:
X        if ( ftp_cmdbuf[3] == '-' )
X            ftp_rcvState = ftp_StateRCVRESP;
X     case ftp_StateRCVRESP:
X        if ( ftp_cmdbuf[3] == ' ' )
X            ftp_rcvState = ftp_StateIDLE;
X        break;
X    }
X}
X
Xftp_Abort()
X{
X    tcp_Abort(&ftp_ctl);
X    tcp_Abort(&ftp_data);
X}
X
X
Xftp_application()
X{
X    char *s;
X    char *dp;
X    int i;
X
X    i = -1;
X    if ( isina() ) {
X        i = busyina() & 0177;
X#ifdef DEBUG
X        if ( i == ('D' & 037) ) SysBug("Pause to DDT");
X#endif
X        if ( i == ('C' & 037) ) {
X            printf("Closing...\n");
X            tcp_Close(&ftp_ctl);
X        }
X    }
X
X    switch (ftp_rcvState) {
X      case ftp_StateGETCMD:
X getcmd:if ( i != -1 ) {
X            ftp_outbuf[ftp_outbuflen] = 0;
X            switch (i) {
X                case 'H' & 037:
X                case 0177:
X                    if ( ftp_outbuflen > 0 ) {
X                        ftp_outbuflen--;
X                        printf("\010 \010");
X                    }
X                    break;
X
X                case 'R' & 037:
X                    if ( ftp_echoMode )
X                        printf("\nFtpCmd> %s", ftp_outbuf);
X                    break;
X
X                case 033:
X                    ftp_echoMode = ! ftp_echoMode;
X                    break;
X
X                case '\r':
X                case '\n':
X                    busyouta('\n');
X                    dp = &ftp_outbuf[ftp_outbuflen];
X                    goto docmd;
X
X                default:
X                    if ( i >= ' ' && ftp_outbuflen < sizeof ftp_outbuf ) {
X                        ftp_outbuf[ftp_outbuflen++] = i;
X                        if ( ftp_echoMode ) busyouta(i);
X                    }
X            }
X        }
X        break;
X
X      case ftp_StateIDLE:
X        if ( ftp_scriptline < 0 ) {
X            ftp_rcvState = ftp_StateGETCMD;
X            ftp_echoMode = true;
X            ftp_outbuflen = 0;
X            printf("FtpCmd> ");
X            goto getcmd;
X        }
X        s = ftp_script[ftp_scriptline];
X        if ( s == NIL )
X            break;
X        ftp_scriptline++;
X        printf("%s\n", s);
X        dp = ftp_outbuf;
X        while ( *dp++ = *s++ ) ;
X        dp--;
X docmd: *dp++ = '\r';
X        *dp++ = '\n';
X        ftp_outbuflen = dp - ftp_outbuf;
X        ftp_outbufix = 0;
X        ftp_rcvState = ftp_StateINCOMMAND;
X        /* fall through */
X    case ftp_StateINCOMMAND:
X        i = ftp_outbuflen - ftp_outbufix;
X        if ( i > 0 ) {
X            i = tcp_Write(&ftp_ctl, &ftp_outbuf[ftp_outbufix], i);
X            ftp_outbufix += i;
X            tcp_Flush(&ftp_ctl);
X        }
X        /* fall through */
X    case ftp_StateRCVRESP:
X        break;
X    }
X
X}
X
Xftp(host, fn, dataHandler)
X    in_HwAddress host;
X    char *fn;
X    procref dataHandler;
X{
X    word port;
X    char filecmd[80];
X
X    port = (sed_lclEthAddr[2] + clock_ValueRough()) | 0x8000;
X
X    if ( fn ) {
X        /* set up the script for this session */
X        ftp_script[0] = "user foo";
X        ftp_script[1] = "pass foo";
X        ftp_script[2] = "type i";
X        sprintf(filecmd, "retr %s", fn);
X        ftp_script[3] = filecmd;
X        ftp_script[4] = "quit";
X        ftp_script[5] = 0;
X        ftp_scriptline = 0;
X    } else {
X        ftp_scriptline = -1;        /* interactive mode */
X        ftp_echoMode = true;
X    }
X
X    /* set up state variables */
X    ftp_rcvState = ftp_StateRCVRESP;
X    ftp_cmdbufi = 0;
X    tcp_Listen(&ftp_data, port, dataHandler, 0);
X    tcp_Open(&ftp_ctl, port, host, 21, ftp_ctlHandler);
X    tcp(ftp_application);
X}
END-of-tinyftp.c
echo file: tinytcp.c
sed 's/^X//' >tinytcp.c << 'END-of-tinytcp.c'
X/*
X * tinytcp.c - Tiny Implementation of the Transmission Control Protocol
X *
X * Written March 28, 1986 by Geoffrey Cooper, IMAGEN Corporation.
X *
X * This code is a small implementation of the TCP and IP protocols, suitable
X * for burning into ROM.  The implementation is bare-bones and represents
X * two days' coding efforts.  A timer and an ethernet board are assumed.  The
X * implementation is based on busy-waiting, but the tcp_handler procedure
X * could easily be integrated into an interrupt driven scheme.
X *
X * IP routing is accomplished on active opens by broadcasting the tcp SYN
X * packet when ARP mapping fails.  If anyone answers, the ethernet address
X * used is saved for future use.  This also allows IP routing on incoming
X * connections.
X * 
X * The TCP does not implement urgent pointers (easy to add), and discards
X * segments that are received out of order.  It ignores the received window
X * and always offers a fixed window size on input (i.e., it is not flow
X * controlled).
X *
X * Special care is taken to access the ethernet buffers only in word
X * mode.  This is to support boards that only allow word accesses.
X *
X * Copyright (C) 1986, IMAGEN Corporation
X *  "This code may be duplicated in whole or in part provided that [1] there
X *   is no commercial gain involved in the duplication, and [2] that this
X *   copyright notice is preserved on all copies.  Any other duplication
X *   requires written notice of the author."
X */
X
X#include "tinytcp.h"
X
X/*
X * Local IP address
X */
Xin_HwAddress sin_lclINAddr;
X
X/*
X * IP identification numbers
X */
Xint tcp_id;
X
Xtcp_Socket *tcp_allsocs;
X
X/* Timer definitions */
X#define tcp_RETRANSMITTIME 1000     /* interval at which retransmitter is called */
X#define tcp_LONGTIMEOUT 31000       /* timeout for opens */
X#define tcp_TIMEOUT 10000           /* timeout during a connection */
X
X#ifdef DEBUG
X/* 
X * Primitive logging facility
X */
X#define tcp_LOGPACKETS 1        /* log packet headers */
Xword tcp_logState;
X#endif
X
X/*
X * Initialize the tcp implementation
X */
Xtcp_Init()
X{
X    extern eth_HwAddress sed_lclEthAddr;
X
X    /* initialize ethernet interface */
X    sed_Init();
X
X    tcp_allsocs = NIL;
X#ifdef DEBUG
X    tcp_logState = 0;
X#endif
X    tcp_id = 0;
X
X    /* hack - assume the network number */
X    sin_lclINAddr = 0x7d000000 + (*((longword *)&sed_lclEthAddr[1]) & 0xFFFFFF);
X}
X
X/*
X * Actively open a TCP connection to a particular destination.
X */
Xtcp_Open(s, lport, ina, port, datahandler)
X    tcp_Socket *s;
X    in_HwAddress ina;
X    word lport, port;
X    procref datahandler;
X{
X    extern eth_HwAddress sed_ethBcastAddr;
X
X    s->state = tcp_StateSYNSENT;
X    s->timeout = tcp_LONGTIMEOUT;
X    if ( lport == 0 ) lport = clock_ValueRough();
X    s->myport = lport;
X    if ( ! sar_MapIn2Eth(ina, &s->hisethaddr[0]) ) {
X        printf("tcp_Open of 0x%x: defaulting ethernet address to broadcast\n", ina);
X        Move(&sed_ethBcastAddr[0], &s->hisethaddr[0], sizeof(eth_HwAddress));
X    }
X    s->hisaddr = ina;
X    s->hisport = port;
X    s->seqnum = 0;
X    s->dataSize = 0;
X    s->flags = tcp_FlagSYN;
X    s->unhappy = true;
X    s->dataHandler = datahandler;
X    s->next = tcp_allsocs;
X    tcp_allsocs = s;
X    tcp_Send(s);
X}
X
X/*
X * Passive open: listen for a connection on a particular port
X */
Xtcp_Listen(s, port, datahandler, timeout)
X    tcp_Socket *s;
X    word port;
X    procref datahandler;
X{
X    s->state = tcp_StateLISTEN;
X    if ( timeout == 0 ) s->timeout = 0x7ffffff; /* forever... */
X    else s->timeout = timeout;
X    s->myport = port;
X    s->hisport = 0;
X    s->seqnum = 0;
X    s->dataSize = 0;
X    s->flags = 0;
X    s->unhappy = 0;
X    s->dataHandler = datahandler;
X    s->next = tcp_allsocs;
X    tcp_allsocs = s;
X}
X
X/*
X * Send a FIN on a particular port -- only works if it is open
X */
Xtcp_Close(s)
X    tcp_Socket *s;
X{
X    if ( s->state == tcp_StateESTAB || s->state == tcp_StateSYNREC ) {
X        s->flags = tcp_FlagACK | tcp_FlagFIN;
X        s->state = tcp_StateFINWT1;
X        s->unhappy = true;
X    }
X}
X
X/*
X * Abort a tcp connection
X */
Xtcp_Abort(s)
X    tcp_Socket *s;
X{
X    if ( s->state != tcp_StateLISTEN && s->state != tcp_StateCLOSED ) {
X        s->flags = tcp_FlagRST | tcp_FlagACK;
X        tcp_Send(s);
X    }
X    s->unhappy = 0;
X    s->dataSize = 0;
X    s->state = tcp_StateCLOSED;
X    s->dataHandler(s, 0, -1);
X    tcp_Unthread(s);
X}
X
X/*
X * Retransmitter - called periodically to perform tcp retransmissions
X */
Xtcp_Retransmitter()
X{
X    tcp_Socket *s;
X    BOOL x;
X
X    for ( s = tcp_allsocs; s; s = s->next ) {
X        x = false;
X        if ( s->dataSize > 0 || s->unhappy ) {
X            tcp_Send(s);
X            x = true;
X        }
X        if ( x || s->state != tcp_StateESTAB )
X            s->timeout -= tcp_RETRANSMITTIME;
X        if ( s->timeout <= 0 ) {
X            if ( s->state == tcp_StateTIMEWT ) {
X                printf("Closed.    \n");
X                s->state = tcp_StateCLOSED;
X                s->dataHandler(s, 0, 0);
X                tcp_Unthread(s);
X            } else {
X                printf("Timeout, aborting\n");
X                tcp_Abort(s);
X            }
X        }
X    }
X}
X
X/*
X * Unthread a socket from the socket list, if it's there 
X */
Xtcp_Unthread(ds)
X    tcp_Socket *ds;
X{
X    tcp_Socket *s, **sp;
X
X    sp = &tcp_allsocs;
X    for (;;) {
X        s = *sp;
X        if ( s == ds ) {
X            *sp = s->next;
X            break;
X        }
X        if ( s == NIL ) break;
X        sp = &s->next;
X    }
X}
X
X/*
X * busy-wait loop for tcp.  Also calls an "application proc"
X */
Xtcp(application)
X    procref application;
X{
X    in_Header *ip;
X    longword timeout, start;
X    int x;
X
X    sed_Receive(0);
X
X    timeout = 0;
X    while ( tcp_allsocs ) {
X        start = clock_ValueRough();
X        ip = sed_IsPacket();
X        if ( ip == NIL ) {
X            if ( clock_ValueRough() > timeout ) {
X                tcp_Retransmitter();
X                timeout = clock_ValueRough() + tcp_RETRANSMITTIME;
X            }
X
X            application();
X
X            continue;
X        }
X
X        if ( sed_CheckPacket(ip, 0x806) == 1 ) {
X            /* do arp */
X            sar_CheckPacket(ip);
X
X        } else if ( sed_CheckPacket(ip, 0x800) == 1 ) {
X            /* do IP */
X            if ( ip->destination == sin_lclINAddr &&
X                 in_GetProtocol(ip) == 6 &&
X                 checksum(ip, in_GetHdrlenBytes(ip)) == 0xFFFF ) {
X                tcp_Handler(ip);
X            }
X        }
X        /* recycle buffer */
X        sed_Receive(ip);
X
X        x = clock_ValueRough() - start;
X        timeout -= x;
X    }
X
X    return ( 1 );
X}
X
X/*
X * Write data to a connection.
X * Returns number of bytes written, == 0 when connection is not in
X * established state.
X */
Xtcp_Write(s, dp, len)
X    tcp_Socket *s;
X    byte *dp;
X    int len;
X{
X    int x;
X
X    if ( s->state != tcp_StateESTAB ) len = 0;
X    if ( len > (x = tcp_MaxData - s->dataSize) ) len = x;
X    if ( len > 0 ) {
X        Move(dp, &s->data[s->dataSize], len);
X        s->dataSize += len;
X        tcp_Flush(s);
X    }
X
X    return ( len );
X}
X
X/*
X * Send pending data
X */
Xtcp_Flush(s)
X    tcp_Socket *s;
X{
X    if ( s->dataSize > 0 ) {
X        s->flags |= tcp_FlagPUSH;
X        tcp_Send(s);
X    }
X}
X
X/*
X * Handler for incoming packets.
X */
Xtcp_Handler(ip)
X    in_Header *ip;
X{
X    tcp_Header *tp;
X    tcp_PseudoHeader ph;
X    int len;
X    byte *dp;
X    int x, diff;
X    tcp_Socket *s;
X    word flags;
X
X    len = in_GetHdrlenBytes(ip);
X    tp = (tcp_Header *)((byte *)ip + len);
X    len = ip->length - len;
X
X    /* demux to active sockets */
X    for ( s = tcp_allsocs; s; s = s->next )
X        if ( s->hisport != 0 &&
X             tp->dstPort == s->myport &&
X             tp->srcPort == s->hisport &&
X             ip->source == s->hisaddr ) break;
X    if ( s == NIL ) {
X        /* demux to passive sockets */
X        for ( s = tcp_allsocs; s; s = s->next )
X            if ( s->hisport == 0 && tp->dstPort == s->myport ) break;
X    }
X    if ( s == NIL ) {
X#ifdef DEBUG
X        if ( tcp_logState & tcp_LOGPACKETS ) tcp_DumpHeader(ip, tp, "Discarding");
X#endif
X        return;
X    }
X
X#ifdef DEBUG
X    if ( tcp_logState & tcp_LOGPACKETS )
X        tcp_DumpHeader(ip, tp, "Received");
X#endif
X
X    /* save his ethernet address */
X    MoveW(&((((eth_Header *)ip) - 1)->source[0]), &s->hisethaddr[0], sizeof(eth_HwAddress));
X
X    ph.src = ip->source;
X    ph.dst = ip->destination;
X    ph.mbz = 0;
X    ph.protocol = 6;
X    ph.length = len;
X    ph.checksum = checksum(tp, len);
X    if ( checksum(&ph, sizeof ph) != 0xffff )
X         printf("bad tcp checksum, received anyway\n");
X
X    flags = tp->flags;
X    if ( flags & tcp_FlagRST ) {
X        printf("connection reset\n");
X        s->state = tcp_StateCLOSED;
X        s->dataHandler(s, 0, -1);
X        tcp_Unthread(s);
X        return;
X    }
X
X    switch ( s->state ) {
X
X    case tcp_StateLISTEN:
X        if ( flags & tcp_FlagSYN ) {
X            s->acknum = tp->seqnum + 1;
X            s->hisport = tp->srcPort;
X            s->hisaddr = ip->source;
X            s->flags = tcp_FlagSYN | tcp_FlagACK;
X            tcp_Send(s);
X            s->state = tcp_StateSYNREC;
X            s->unhappy = true;
X            s->timeout = tcp_TIMEOUT;
X            printf("Syn from 0x%x#%d (seq 0x%x)\n", s->hisaddr, s->hisport, tp->seqnum);
X        }
X        break;
X
X    case tcp_StateSYNSENT:
X        if ( flags & tcp_FlagSYN ) {
X            s->acknum++;
X            s->flags = tcp_FlagACK;
X            s->timeout = tcp_TIMEOUT;
X            if ( (flags & tcp_FlagACK) && tp->acknum == (s->seqnum + 1) ) {
X                printf("Open\n");
X                s->state = tcp_StateESTAB;
X                s->seqnum++;
X                s->acknum = tp->seqnum + 1;
X                s->unhappy = false;
X            } else {
X                s->state = tcp_StateSYNREC;
X            }
X        }
X        break;
X
X    case tcp_StateSYNREC:
X        if ( flags & tcp_FlagSYN ) {
X            s->flags = tcp_FlagSYN | tcp_FlagACK;
X            tcp_Send(s);
X            s->timeout = tcp_TIMEOUT;
X            printf(" retransmit of original syn\n");
X        }
X        if ( (flags & tcp_FlagACK) && tp->acknum == (s->seqnum + 1) ) {
X            s->flags = tcp_FlagACK;
X            tcp_Send(s);
X            s->seqnum++;
X            s->unhappy = false;
X            s->state = tcp_StateESTAB;
X            s->timeout = tcp_TIMEOUT;
X            printf("Synack received - connection established\n");
X        }
X        break;
X
X    case tcp_StateESTAB:
X        if ( (flags & tcp_FlagACK) == 0 ) return;
X        /* process ack value in packet */
X        diff = tp->acknum - s->seqnum;
X        if ( diff > 0 ) {
X            Move(&s->data[diff], &s->data[0], diff);
X            s->dataSize -= diff;
X            s->seqnum += diff;
X        }
X        s->flags = tcp_FlagACK;
X        tcp_ProcessData(s, tp, len);
X        break;
X
X    case tcp_StateFINWT1:
X        if ( (flags & tcp_FlagACK) == 0 ) return;
X        diff = tp->acknum - s->seqnum - 1;
X        s->flags = tcp_FlagACK | tcp_FlagFIN;
X        if ( diff == 0 ) {
X            s->state = tcp_StateFINWT2;
X            s->flags = tcp_FlagACK;
X            printf("finack received.\n");
X        }
X        tcp_ProcessData(s, tp, len);
X        break;
X
X    case tcp_StateFINWT2:
X        s->flags = tcp_FlagACK;
X        tcp_ProcessData(s, tp, len);
X        break;
X
X    case tcp_StateCLOSING:
X        if ( tp->acknum == (s->seqnum + 1) ) {
X            s->state = tcp_StateTIMEWT;
X            s->timeout = tcp_TIMEOUT;
X        }
X        break;
X
X    case tcp_StateLASTACK:
X        if ( tp->acknum == (s->seqnum + 1) ) {
X            s->state = tcp_StateCLOSED;
X            s->unhappy = false;
X            s->dataSize = 0;
X            s->dataHandler(s, 0, 0);
X            tcp_Unthread(s);
X            printf("Closed.    \n");
X        } else {
X            s->flags = tcp_FlagACK | tcp_FlagFIN;
X            tcp_Send(s);
X            s->timeout = tcp_TIMEOUT;
X            printf("retransmitting FIN\n");
X        }
X        break;
X
X    case tcp_StateTIMEWT:
X        s->flags = tcp_FlagACK;
X        tcp_Send(s);
X    }
X}
X
X/*
X * Process the data in an incoming packet.
X * Called from all states where incoming data can be received: established,
X * fin-wait-1, fin-wait-2
X */
Xtcp_ProcessData(s, tp, len)
X    tcp_Socket *s;
X    tcp_Header *tp;
X    int len;
X{
X    int diff, x;
X    word flags;
X    byte *dp;
X
X    flags = tp->flags;
X    diff = s->acknum - tp->seqnum;
X    if ( flags & tcp_FlagSYN ) diff--;
X    x = tcp_GetDataOffset(tp) << 2;
X    dp = (byte *)tp + x;
X    len -= x;
X    if ( diff >= 0 ) {
X        dp += diff;
X        len -= diff;
X        s->acknum += len;
X        s->dataHandler(s, dp, len);
X        if ( flags & tcp_FlagFIN ) {
X            s->acknum++;
X#ifdef DEBUG
X            printf("consumed fin.\n");
X#endif
X            switch(s->state) {
X              case tcp_StateESTAB:
X                /* note: skip state CLOSEWT by automatically closing conn */
X                x = tcp_StateLASTACK;
X                s->flags |= tcp_FlagFIN;
X                s->unhappy = true;
X#ifdef DEBUG
X                printf("sending fin.\n");
X#endif
X                break;
X              case tcp_StateFINWT1:
X                x = tcp_StateCLOSING;
X                break;
X              case tcp_StateFINWT2:
X                x = tcp_StateTIMEWT;
X                break;
X            }
X            s->state = x;
X        }
X    }
X    s->timeout = tcp_TIMEOUT;
X    tcp_Send(s);
X}
X
X/*
X * Format and send an outgoing segment
X */
Xtcp_Send(s)
X    tcp_Socket *s;
X{
X    tcp_PseudoHeader ph;
X    struct _pkt {
X        in_Header in;
X        tcp_Header tcp;
X        longword maxsegopt;
X    } *pkt;
X    byte *dp;
X
X    pkt = (struct _pkt *)sed_FormatPacket(&s->hisethaddr[0], 0x800);
X    dp = &pkt->maxsegopt;
X
X    pkt->in.length = sizeof(in_Header) + sizeof(tcp_Header) + s->dataSize;
X
X    /* tcp header */
X    pkt->tcp.srcPort = s->myport;
X    pkt->tcp.dstPort = s->hisport;
X    pkt->tcp.seqnum = s->seqnum;
X    pkt->tcp.acknum = s->acknum;
X    pkt->tcp.window = 1024;
X    pkt->tcp.flags = s->flags | 0x5000;
X    pkt->tcp.checksum = 0;
X    pkt->tcp.urgentPointer = 0;
X    if ( s->flags & tcp_FlagSYN ) {
X        pkt->tcp.flags += 0x1000;
X        pkt->in.length += 4;
X        pkt->maxsegopt = 0x02040578; /* 1400 bytes */
X        dp += 4;
X    }
X    MoveW(s->data, dp, s->dataSize);
X
X    /* internet header */
X    pkt->in.vht = 0x4500;   /* version 4, hdrlen 5, tos 0 */
X    pkt->in.identification = tcp_id++;
X    pkt->in.frag = 0;
X    pkt->in.ttlProtocol = (250<<8) + 6;
X    pkt->in.checksum = 0;
X    pkt->in.source = sin_lclINAddr;
X    pkt->in.destination = s->hisaddr;
X    pkt->in.checksum = ~checksum(&pkt->in, sizeof(in_Header));
X
X    /* compute tcp checksum */
X    ph.src = pkt->in.source;
X    ph.dst = pkt->in.destination;
X    ph.mbz = 0;
X    ph.protocol = 6;
X    ph.length = pkt->in.length - sizeof(in_Header);
X    ph.checksum = checksum(&pkt->tcp, ph.length);
X    pkt->tcp.checksum = ~checksum(&ph, sizeof ph);
X
X#ifdef DEBUG
X    if ( tcp_logState & tcp_LOGPACKETS )
X        tcp_DumpHeader(&pkt->in, &pkt->tcp, "Sending");
X#endif
X
X    sed_Send(pkt->in.length);
X}
X
X/*
X * Do a one's complement checksum
X */
Xchecksum(dp, length)
X    word *dp;
X    int length;
X{
X    int len;
X    longword sum;
X
X    len = length >> 1;
X    sum = 0;
X    while ( len-- > 0 ) sum += *dp++;
X    if ( length & 1 ) sum += (*dp & 0xFF00);
X    sum = (sum & 0xFFFF) + ((sum >> 16) & 0xFFFF);
X    sum = (sum & 0xFFFF) + ((sum >> 16) & 0xFFFF);
X
X    return ( sum );
X}
X
X/*
X * Dump the tcp protocol header of a packet
X */
Xtcp_DumpHeader( ip, tp, mesg )
X    in_Header *ip;
X    char *mesg;
X{
X    register tcp_Header *tp = (tcp_Header *)((byte *)ip + in_GetHdrlenBytes(ip));
X    static char *flags[] = { "FIN", "SYN", "RST", "PUSH", "ACK", "URG" };
X    int len;
X    word f;
X
X    len =  ip->length - ((tcp_GetDataOffset(tp) + in_GetHdrlen(ip)) << 2);
X    printf("TCP: %s packet:\nS: %x; D: %x; SN=%x ACK=%x W=%d DLen=%d\n",
X           mesg, tp->srcPort, tp->dstPort, tp->seqnum, tp->acknum,
X           tp->window, len);
X    printf("DO=%d, C=%x U=%d",
X           tcp_GetDataOffset(tp), tp->checksum, tp->urgentPointer);
X    /* output flags */
X    f = tp->flags;
X    for ( len = 0; len < 6; len++ )
X        if ( f & (1 << len) ) printf(" %s", flags[len]);
X    printf("\n");
X}
X
X/*
X * Move bytes from hither to yon
X */
XMove( src, dest, numbytes )
X    register byte *src, *dest;
X    register numbytes;
X{
X    if ( numbytes <= 0 ) return;
X    if ( src < dest ) {
X        src += numbytes;
X        dest += numbytes;
X        do {
X            *--dest = *--src;
X        } while ( --numbytes > 0 );
X    } else
X        do {
X             *dest++ = *src++;
X        } while ( --numbytes > 0 );
X}
END-of-tinytcp.c
echo file: tinytcp.h
sed 's/^X//' >tinytcp.h << 'END-of-tinytcp.h'
X/*
X * tinytcp.h - header file for tinytcp.c
X *
X * Copyright (C) 1986, IMAGEN Corporation
X *  "This code may be duplicated in whole or in part provided that [1] there
X *   is no commercial gain involved in the duplication, and [2] that this
X *   copyright notice is preserved on all copies.  Any other duplication
X *   requires written notice of the author."
X *
X * Note: the structures herein must guarantee that the
X *       code only performs word fetches, since the
X *       imagenether card doesn't accept byte accesses.
X */
X
X#define TRUE        1
X#define true        1
X#define FALSE       0
X#define false       0
X#define NULL        0               /* An empty value */
X#define NIL         0               /* The distinguished empty pointer */
X
X/* Useful type definitions */
Xtypedef int (*procref)();
Xtypedef short BOOL;                  /* boolean type */
X
X/* Canonically-sized data */
Xtypedef unsigned long longword;     /* 32 bits */
Xtypedef unsigned short word;        /* 16 bits */
Xtypedef unsigned char byte;         /*  8 bits */
Xtypedef byte octet;                 /*  8 bits, for TCP */
X
X#ifdef DDT
Xextern longword MsecClock();
X#define clock_ValueRough() MsecClock()
X#else
Xextern longword clock_MS;
X#define clock_ValueRough() clock_MS
X#endif
X
X/* protocol address definitions */
Xtypedef longword in_HwAddress;
Xtypedef word eth_HwAddress[3];
X
X/* The Ethernet header */
Xtypedef struct {
X    eth_HwAddress   destination;
X    eth_HwAddress   source;
X    word            type;
X} eth_Header;
X
X/* The Internet Header: */
Xtypedef struct {
X    word            vht;    /* version, hdrlen, tos */
X    word            length;
X    word            identification;
X    word            frag;
X    word            ttlProtocol;
X    word            checksum;
X    in_HwAddress    source;
X    in_HwAddress    destination;
X} in_Header;
X#define in_GetVersion(ip) (((ip)->vht >> 12) & 0xf)
X#define in_GetHdrlen(ip)  (((ip)->vht >> 8) & 0xf)
X#define in_GetHdrlenBytes(ip)  (((ip)->vht >> 6) & 0x3c)
X#define in_GetTos(ip)      ((ip)->vht & 0xff)
X
X#define in_GetTTL(ip)      ((ip)->ttlProtocol >> 8)
X#define in_GetProtocol(ip) ((ip)->ttlProtocol & 0xff)
X
X
Xtypedef struct {
X    word            srcPort;
X    word            dstPort;
X    longword        seqnum;
X    longword        acknum;
X    word            flags;
X    word            window;
X    word            checksum;
X    word            urgentPointer;
X} tcp_Header;
X
X
X#define tcp_FlagFIN     0x0001
X#define tcp_FlagSYN     0x0002
X#define tcp_FlagRST     0x0004
X#define tcp_FlagPUSH    0x0008
X#define tcp_FlagACK     0x0010
X#define tcp_FlagURG     0x0020
X#define tcp_FlagDO      0xF000
X#define tcp_GetDataOffset(tp) ((tp)->flags >> 12)
X
X/* The TCP/UDP Pseudo Header */
Xtypedef struct {
X    in_HwAddress    src;
X    in_HwAddress    dst;
X    octet           mbz;
X    octet           protocol;
X    word            length;
X    word            checksum;
X} tcp_PseudoHeader;
X
X/*
X * TCP states, from tcp manual.
X * Note: close-wait state is bypassed by automatically closing a connection
X *       when a FIN is received.  This is easy to undo.
X */
X#define tcp_StateLISTEN  0      /* listening for connection */
X#define tcp_StateSYNSENT 1      /* syn sent, active open */
X#define tcp_StateSYNREC  2      /* syn received, synack+syn sent. */
X#define tcp_StateESTAB   3      /* established */
X#define tcp_StateFINWT1  4      /* sent FIN */
X#define tcp_StateFINWT2  5      /* sent FIN, received FINACK */
X/*#define tcp_StateCLOSEWT 6    /* received FIN waiting for close */
X#define tcp_StateCLOSING 6      /* sent FIN, received FIN (waiting for FINACK) */
X#define tcp_StateLASTACK 7      /* fin received, finack+fin sent */
X#define tcp_StateTIMEWT  8      /* dally after sending final FINACK */
X#define tcp_StateCLOSED  9      /* finack received */
X
X/*
X * TCP Socket definition
X */
X#define tcp_MaxData 32              /* maximum bytes to buffer on output */
X
Xtypedef struct _tcp_socket {
X    struct _tcp_socket *next;
X    short           state;          /* connection state */
X    procref         dataHandler;    /* called with incoming data */
X    eth_HwAddress   hisethaddr;     /* ethernet address of peer */
X    in_HwAddress    hisaddr;        /* internet address of peer */
X    word            myport, hisport;/* tcp ports for this connection */
X    longword        acknum, seqnum; /* data ack'd and sequence num */
X    int             timeout;        /* timeout, in milliseconds */
X    BOOL            unhappy;        /* flag, indicates retransmitting segt's */
X    word            flags;          /* tcp flags word for last packet sent */
X    short           dataSize;       /* number of bytes of data to send */
X    byte            data[tcp_MaxData]; /* data to send */
X} tcp_Socket;
X
Xextern eth_HwAddress sed_lclEthAddr;
Xextern eth_HwAddress sed_ethBcastAddr;
Xextern in_HwAddress  sin_lclINAddr;
X
X/*
X * ARP definitions
X */
X#define arp_TypeEther  1        /* ARP type of Ethernet address *
X
X/* harp op codes */
X#define ARP_REQUEST 1
X#define ARP_REPLY   2
X
X/*
X * Arp header
X */
Xtypedef struct {
X    word            hwType;
X    word            protType;
X    word            hwProtAddrLen;  /* hw and prot addr len */
X    word            opcode;
X    eth_HwAddress   srcEthAddr;
X    in_HwAddress    srcIPAddr;
X    eth_HwAddress   dstEthAddr;
X    in_HwAddress    dstIPAddr;
X} arp_Header;
X
X/*
X * Ethernet interface:
X *   sed_WaitPacket(0) => ptr to packet (beyond eth header)
X *                          or NIL if no packet ready.
X *   sed_Receive(ptr) - reenables receive on input buffer
X *   sed_FormatPacket(&ethdest, ethtype) => ptr to packet buffer
X *   sed_Send(packet_length) - send the buffer last formatted.
X */
Xbyte *sed_IsPacket(), *sed_FormatPacket();
END-of-tinytcp.h
exit

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 20:31:54 EDT
From:      MULHERN@SRI-KL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

I did work for Jon Brommeland at NAVELEX Vallejo which was sponsored
by PDW-120.  He did not let us contact 120 directly, and the Vallejo
involvement did not turn out well, but I (and several others here)
learned much about 120's systems -- NWSS, FHLT,HLT,OBS, OBU, IID, 
STT/TDCS and ISE.  Our task was to design a local network for
the 120 testbed at Patuxent River.  We also reviewed the initial
specifications for OBU  (non-black world).  This work was completed
in 82/83.
-------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 21:40:22 EDT
From:      MILLS@USC-ISID.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: C implementations of TCP/IP

In response to the message sent  Wed, 14 May 86 16:43:02 PDT from karels@monet.berkeley.edu 

Mike,

Will you distribute the 4.2/4.3bsd TCP/IP code without a Unix source license?

Dave
-------

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      15 May 1986 21:40:22 EDT
From:      MILLS@USC-ISID.ARPA
To:        karels@MONET.BERKELEY.EDU, CERF@USC-ISI.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA
Subject:   Re: C implementations of TCP/IP
In response to the message sent  Wed, 14 May 86 16:43:02 PDT from karels@monet.berkeley.edu 

Mike,

Will you distribute the 4.2/4.3bsd TCP/IP code without a Unix source license?

Dave
-------
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-May-86 22:18:00 EDT
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

I think symbolic port names are a great idea.  There are several
approaches which could be taken.  Possibly implementations of some of
these already exist, but I don't know about them.

A service multiplexing protocol:  this applies to TCP but not to UDP
because it relies on connections.  First, reserve one low numbered TCP
port for this protocol.  When a user establish a connection to this
server, the user sends the contact name, and optional contact arguments,
in ASCII, terminated by a network newline (CRLF).  The contact name is
always required, and should either be registered, or long and self
explanatory.  CHAOS protocol allows arguments to follow the contact
name, and I think we should allow this also, but they depend on the
contact name and the only specification here is that they be delimited
from the contact name by a space.  The protocol server which listens on
this TCP port should parse the contact line, look it up in the available
service list, and pass off that connection as if it had just been
established to the service on a reserved port.  If the service is
unavailable, the connection should be aborted.

Note that "multiplexing" in this case is not used in the sense that is
it used in IEN 90, the MUX protocol.

TCBs on such systems should contain a comment field which is filled in
with the service name.  Then listing the TCBs can show the comment, and
it won't matter that all the multiplexed services are to the multiplexed
port.  (Multics already does this; it makes the TCB list much easier to
read.)

There should be no significant performance impact in using this
mechanism for TELNET, SUPDUP, SMTP, FINGER, or FTP control connections.
While services used for metering, like TIME, ECHO, DISCARD, etc., can be
expected to require dedicated port numbers, there should be no need to
dedicate port numbers for private services thereafter.  Even DOMAIN TCP
connections could use multiplexing.

There should be a reserved contact name which lists the available
contact names.  The WKS domain RR would be useful only in showing that
multiplexed service is available.  Perhaps this list operation should
include port numbers for contacting the services, when available.  A
standard format should be used, so that the list is machine-readable as
well as human-readable.

A fly in the ointment is that some services reserve port numbers in ways
that can't be multiplexed.  For example, the FTP data port is port 20.
A replacement for the FTP "PORT" command would be needed to eliminate
this assumption.  This could be addressed by modifying the FTP
specification and all similar protocols if it is ever needed.  But since
we are doing this primarily for new protocols, they can be devised with
some mechanism for negotiating additional connections, as needed, which
does not require reserving ports.

There are other advantages within operating systems.  Services other
than TCP which support streams could hand off, for example, SMTP
connections in a similar manner.  If an X.25 network like TYMNET is
connected two sites, the operating system might permit an X.25 level 3
connection to be passed off to the SMTP server.  The contact name
arguments in that case might include a host name and associated password
since you couldn't verify the host in the same way that you might using
the Internet.

An alternative or additional protocol could use a UDP service to map
contact names to ports.  You would send the contact name to the port as
a datagram, and receive back a datagram which would indicate that 1) the
service is available on port P, 2) the service is available on the
multiplexed port M, or 3) that the service is unavailable.  Choice #2
only applies to connection based services, but #1 and #3 could apply to
either TCP or UDP, and perhaps other lower level services as well.  If
the query packet also contained a transport ID (e.g., 6 for TCP) or name
(e.g., "TCP") then the service could be more generally applicable.

This permits the equivalent of multiplexed service on UDP, a minimum
cost of an extra datagram per host per service per bootload to find out
what the port number is assigned to a service.  It wouldn't matter that
one Symbolics 3600 was running NFILE on port 57, and another on port
666, as long as they both call the service "NFILE".

The UDP service could not be expected to be able to construct packets
large enough to contain the names of all the available services.  While
in many cases they would fit, it would be unreasonable to expect that
this always be the case.  Rather than add complexity to this protocol it
would be better to require contacting the TCP port to get the service
list.

The number czar (tsar?)  would still be needed to hand out contact names
like "TELNET" and "FINGER", and prefixes like "SYMBOLICS-".  Once Benson
has the "SYMBOLICS-" prefix he can hand out SYMBOLICS-PRIVATE-1,
SYMBOLICS-NFILE, and so on without having to bother the czar or fear of
conflict with the rest of the world.

The server port number returned by UDP can have any value.  The number
needn't be less than 256 or 1024 to provide security.  The 255 well
known ports are just that:  well known.  If a host implements security
based on port number, then it is only necessary to ensure that the port
number given out by the UDP multiplexing port is secured, even if it is
port FFFF (hex).  The UNIX port scheme depends on the user-side port
being less than 1024 to ensure that the connection is valid, not the
server side port number.

It is unnecessary to encode contact names in every packet, especially
for TCP.  A port number is sufficient to keep track of packets, and only
the two parties to a conversation need know how the numbers map to
services.  This may not be strictly true for gateways that restrict
services.  Schemes that I have heard of restrict the SYN-bearing TCP
packets.  I'm afraid that they would have to prohibit the multiplex
port.  However, the UDP port translation could be used to avoid using
the multiplex port for all contact names which don't require arguments.

It would be nice to see an alternative to UDP that was in most ways
identical to it, but which had a contact name in the packet instead of
one of the port numbers.  For simple transactions this would avoid the
complexity of exchanging packets to get the port number before anything
could be accomplished.  The format of the packet would be as follows:
The length would be in the pseudo header.  The source port would be
replaced by a transaction ID (15 bit number) and a query/response flag
(one bit).  The destination port would be replaced by an ASCII character
string, terminated by one or two nulls to take an even number of
characters.  Two bytes would be reserved for an optional checksum.  The
rest would be data octets.  If the contact name is long, the number of
available data octets would be fewer than for UDP, but if the response
flag were set, perhaps the contact name could be omitted from the
response packet, permitting longer responses.  Otherwise, the
query/response flag would indicate which of the ID and the contact name
is the local "port".

If there already exist RFCs describing protocols which implement any of
these schemes, please point them out.  Otherwise, someone with immediate
need for these services could write an RFC or two.

All that is necessary for the Internet to generally convert to this mode
of operation is that a version of Berkeley Unix get into the field which
supports multiplexed service and which has user programs which attempt
multiplexed operation if it is available.  I think the advantages of
this mode of operation will become so apparent that the rest of the
network will be converted within a year or two.

The time will come when both TCP and TP4 are considered hopelessly
outmoded antiques.  By making TCP services more flexible in this way,
perhaps that can be postponed.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 05:16:06 EDT
From:      MKL@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   port multiplexing

Adding a port multiplexer can present some other problems:
You then have to support both the reserved well-known-sockets
and the multiplexed port in order to maintain compatability
with what is already in use.  Then you would have to try
one first and if it fails try the other.  This would be silly.
For example, to send mail you might first try connecting to a hosts 
multiplexed port.  If this failed then you would have to try a
direct connection to port 25.  So by adding multiplexed ports
you would now have to program two different ways to try and
make a connection.  If you try connecting to port 25 
first, you either get the connection or don't, so there is no
real reason to have the multiplexer support the well-known-sockets.

I think a multiplexed port protocol should ONLY support
"unknown-sockets" and not the "well-known-sockets".
A protocol of general use would still get a reserved
port number.  Any private or less useful protocols
that were rejected a port number would have to use
the port multiplexor.
-------

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      16 May 86 11:11 PDT
From:      Tom Perrine <tom@LOGICON.ARPA>
To:        tcp-ip@sri-nic
Cc:        perrine@logicon.arpa
Subject:   Re: port collisions
On the subject of picking port numbers:

>Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE
>SAME BUILDING OF THE SAME COMPANY.  Since numbers don't mean anything,
>we both happened to pick 666 for our private port number.

I wonder if that's because they both knew that the protocols they were
working on would be "devilishly difficult" to debug :-) 

(Sorry, I just couldn't resist...)

Tom


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 May 86 12:48:59 -0400
From:      Craig Partridge <craig@loki.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   re: port collisions

    Just a side note to these discussions.  Some IP protocols have 
only 8 bit port numbers (for example, RDP and HMP).  Any general
solution might think a bit about how to handle these beasties
(RDP was spec'd after TCP and UDP, so there is no guarantee that
new protocols will abide with the 16 bit port size unless Jon
has decided to be more demanding on protocol designers).

    You can't casually give away many ports in a 256 port space
for private use.

Craig Partridge
CSNET Technical Staff
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 10:20:22 EDT
From:      nolan@MIMSY.UMD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Redirect wars and Buterfly gateways

To set the record straight on Butterflies:

The Butterfly processor from BBN has nothing to do with gateways. It
is a general purpose parallel processor, configurable with boards
to have 16 to 256 processors. It is hosted by a Sun or Vaxen via either
an Ethernet or an RS232 TIP connection. Present versions have only MC68000
chips; the MC68020 version is coming shortly. The Butterfly is programmed
in C; the operating system is known as Chrysalis.


nolan@maryland

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 13:28:43 EDT
From:      Acuff@SUMEX-AIM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


   I like the idea of having a "port assignment service" that would
map a very large space of names into port numbers for a particular
host, but I would like to see "mature" protocols that have gotten to
the stage of being documented in RFCs be assigned ports, thus freeing
them from the extra connection overhead.  Then it would be easy for
protocol developers to experiment, and to make quick hacks, but the
most used protocols would not be affected.

	-- Rich
-------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 14:11:00 EDT
From:      tom@LOGICON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: port collisions

On the subject of picking port numbers:

>Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE
>SAME BUILDING OF THE SAME COMPANY.  Since numbers don't mean anything,
>we both happened to pick 666 for our private port number.

I wonder if that's because they both knew that the protocols they were
working on would be "devilishly difficult" to debug :-) 

(Sorry, I just couldn't resist...)

Tom

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 17:05:32 EDT
From:      chris@GYRE.UMD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  port collisions

Just to avert any confusion before it turns into a flame war:

	From: dab@mit-borax.arpa (David A. Bridgham)

	As far as I've found, this belief that some ports are secure
	while others aren't is only implemented by Berkekley [sic]
	Unix.  Since other IP implementations do not necessarily honor
	this belief, there is no security in using *secure* ports
	unless your network consists exclusively of machines running
	Berkelely Unix.

This is true, but not important.  The `proper' authorisation protocol,
as implemented by rcmd(), is to look for the host name in a list
of `trusted' hosts first.  Only after the host has been declared
`trusted' is the user name considered.  As long as one declares
only trust*worthy* hosts (specifically those that restrict access
to said ports) as trust*ed*, the protocol works.

For anything more complex, of course, a public-key cryptosystem or
other `better' authentication scheme is required.

Chris

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 17:09:05 EDT
From:      nowicki%rose@SUN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   More on Port numbers


	Doesn't SUN's RPC (which I believe is in the public domain)
	address this issue (no pun intended)? If you say "do you
	seriously expect me to implement RPC and XDR just to get a port
	number?", I sympathize, I was only trying to find analogues for
	enlightenment.

Yes, Sun RPC (which was posted to mod.sources and is on the 4.3BSD
tape) has a service called the "Port mapper" that listens on one well
known port (number 111, officially registered as SUNRPC).  Other Sun
RPC services register with the port mapper, and send to this port to
get other services.  RPC "program numbers" are 32-bit integers, which
will take a while to use up. There is a map in the Yellow Pages lookup
service that maps from string name to RPC program number, so you can
add new protocols without compiling their numbers in programs.  There
also is a Yellow Pages map for finding port numbers given a string name
(like the /etc/services file in 4.x BSD).

	-- Bill Nowicki
	   Sun Microsystems

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 17:38:00 EDT
From:      leiner@RIACS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Redirect wars and Buterfly gateways



A little history.

The butterfly processor (named because of the interconnection strategy
between the multiple processors which is similar to the butterfly of
the FFT) was first developed as a voice multiplexer/packetizer for the
Wideband Satellite Network project and was called the voice funnel.

It was then decided that it would be a good processor for the next
generation of gateway and high speed packet switch for the Wideband
network.

When the strategic computing program started, it was then considered
and pursued as a possible architecture for parallel processing in
general (as opposed to dedicated use such as a packet switch).

The monarch is the next generation of butterfly machine, using more
extensive VLSI particularly in the interconnection switching.

All of this was done by BBN under the sponsorship of DARPA.

Hope this helps.

Barry

----------

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 17:56:12 EDT
From:      hinden@BBNCCV.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Redirect wars and Buterfly gateways


The Butterfly Gateway is real and is very related to the Butterfly
Multiprocessor.  As can be guessed from its name, it runs on the
Butterfly Multiprocessor hardware.  It was developed by BBN for DARPA
and there are currently eleven installed.  It is a full function
routing Internet gateway with support for 1000 networks.  If you
would like more information, let me know and I would be happy to
supply it.

Regards,
Bob

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      16 May 86 17:56:12 EDT (Fri)
From:      Robert Hinden <hinden@BBNCCV.ARPA>
To:        Jeff Makey <Makey@logicon.ARPA>, Tom Perrine <tom@logicon.ARPA>
Cc:        tcp-ip@sri-nic.ARPA, hinden@BBNCCV.ARPA, nolan@maryland.ARPA
Subject:   Re: Redirect wars and Buterfly gateways

The Butterfly Gateway is real and is very related to the Butterfly
Multiprocessor.  As can be guessed from its name, it runs on the
Butterfly Multiprocessor hardware.  It was developed by BBN for DARPA
and there are currently eleven installed.  It is a full function
routing Internet gateway with support for 1000 networks.  If you
would like more information, let me know and I would be happy to
supply it.

Regards,
Bob

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-May-86 21:08:00 EDT
From:      CERF@USC-ISI.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Redirect wars and Buterfly gateways

butterfly multiprocessor and butterfly gateway use the same hardware -
based on multiple MC68K machines. Monarch is new technology - well over
12 months away, I would guess.

Vint

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      16 May 1986 21:08-EDT
From:      CERF@USC-ISI.ARPA
To:        Makey@LOGICON.ARPA, tom@LOGICON.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Redirect wars and Buterfly gateways
butterfly multiprocessor and butterfly gateway use the same hardware -
based on multiple MC68K machines. Monarch is new technology - well over
12 months away, I would guess.

Vint
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 May 86 02:33:48 PDT
From:      ihnp4!utzoo!henry@ucbvax.Berkeley.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Port Collisions
> 	Right. What happens if you pick a name for your private
> protocol that happens to be exactly the same as the name someone else
> picked for their private protocol? ...
> 	Now, if you preface all your private services with some
> personal string, e.g. 'SYMBOLICS-'...

Speaking from personal experience, this can work pretty well.  Take a look
at Usenet (I know, many of you would rather not!):  we're limited to roughly
a seven-character name space, but we have few collisions.  By and large,
people follow prefix-based naming conventions simply because it makes sense.
Most of the collisions we do have are cases where somebody was being "clever"
and naming sites after, say, Tolkien characters, and somebody else had the
same cutesy idea.  I find it striking, actually, that prefix-based naming
has worked out so well in such a cramped name space on such an anarchic
network.  It should do nicely for port numbering, if the technical problems
can be sorted out.

One suggestion:  pick a specific convention for separating prefix and the
rest of the name.  One way in which our tight name space is a real pain
is that it discourages spending a character position on a delimiter.
We're bound to have trouble with that some day.  (Some would say we do
already.)

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      17 May 86  1012 PDT
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Port collisions: use domains!
Why not add service-name to port-number mapping to the information stored
in domain nameserver databases?  For example, if we decide to implement
the Whizbang protocol on port 1234, then our nameserver would contain a
resource record of the form

    Whizbang.SAIL.Stanford.EDU  IN  TCP-PORT  1234

Applications would refer to the protocol by name, and find the port number
using a domain resolver, which will cache the information for next time.
The "well-known" protocols would bypass this mechanism since their port
numbers are known.

						Joe

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-May-86 13:12:00 EDT
From:      JJW@SU-AI.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Port collisions: use domains!

Why not add service-name to port-number mapping to the information stored
in domain nameserver databases?  For example, if we decide to implement
the Whizbang protocol on port 1234, then our nameserver would contain a
resource record of the form

    Whizbang.SAIL.Stanford.EDU  IN  TCP-PORT  1234

Applications would refer to the protocol by name, and find the port number
using a domain resolver, which will cache the information for next time.
The "well-known" protocols would bypass this mechanism since their port
numbers are known.

						Joe

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-May-86 17:19:00 EDT
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

Apparently the most controversial thing that I said in my last message
was that I thought all the TCP services should be supported by the
service multiplexor.  The service side of the multiplexor could offer
two types of service:  service associated with a port number and service
not associated with a port number.

If no multiplexor service is associated with a port number, then the
services are divided into two groups:  those available by contact name,
and those available by local port.  It would probably be simpler to
implement the service side of the multiplexor this way.  However, from
my point of view, if ANY service is available by both mechanisms, then
the simplest way to implement it is to have the multiplexor able to
access ALL well known TCP services which are available by port number.
By "well known" services, I mean services where one or more server
processes will accept any number of connections for the service.

This has several advantages.  First, I can easily imagine circumstances
where for some service, access by both methods is desired, perhaps
temporarily during cutover.  Second, the multiplexor service list can
easily list all the TCP services offered, not just those offered through
the multiplexor.  I would like to be able to obtain complete symbolic
service lists.

The biggest and most controversial advantage is that I think the
Internet made a big mistake in not using contact names in general in
this way.  There is a simple way of proving me wrong:  implement the
service multiplexor and see if, once they become fairly widespread,
there does not appear a definite preference for using the multiplexor
for new applications indefinitely.

I am not suggestion that existing user programs like TELNET be
converted.  I am noting my belief that this will seem like a good idea
later.  If this belief is mistaken, the multiplexor will still be useful
for addressing the needs of stream protocol developers.

Rather than implement TCBs which have no local port number associated
with them, I expect that the service port multiplexor would be simplest
to implement by having the server scan a list of listening TCBs.  This
means that every service would be available by both a port number and a
multiplexor name.  The services like TELNET would have "well known" port
numbers from 1 to 255, while private services could be available on more
obscure or even randomly chosen higher numbered ports.

If all services are available both ways, it is true that there is some
duplication of effort.  However, the user sides need not change.  In the
near term, we can't expect every host to run the multiplexor, so user
programs should still contact services with assigned numbers by the port
numbers.  Changing user programs may be considered only if the
multiplxor servers of this type become nearly universal.

Special operations like the service list might be implemented by passing
off the connection to a service which lists the services, or by handing
them in the multiplexor server.  I would prefer to implement certain
standard reserved operations like the service list as part of the
multiplexor protocol specification, so this choice may be covered by an
eventual specification.

I'd rather see symbolic names than a service which maps 32 bit service
numbers onto 16 bit service numbers, with the mappings from symbolic
names to 32 bit numbers done at the user host, and the mapping from 32
bit to 16 bit service identifiers done at the server host.  Perhaps this
description of the Sun protocol is defective, but if not, why have the
32 bit numbers at all?

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-May-86 23:52:47 EDT
From:      mark@cbosgd.ATT.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: private/proprietary protocols

>Personally, I think that proprietary protocols have no place in the Internet
>research/military community.

Please remember that TCP/IP is used throughout the world as an industry
standard, it isn't just the friendly folks on the ARPANET anymore.  Some
of us have to deal with managers who view our every remark as intellectual
property.

>They are absolutely not in the best interest
>of US national defense.  Quite enough problems exist because the UUCP protocol
>is AT&T proprietary.  As a software vendor, I sympathize with the need for
>trade secret and other forms of software protection.  However, a deliberate
>attempt to lock out interoperability with other vendors' products is bad for
>the customer and ultimately bad for the vendor.

I think Mark misunderstands the situation with UUCP.  I am sure that AT&T
has not made a deliberate effort to keep the protocol a trade secret.  I
don't believe they've given it any thought.  I think the reason you can't
just sit down and write a UUCP is that nobody at AT&T has bothered to sit
down and document the protocol.  (That would be a lot of work, especially
to get it really right, and there's no incentive to do it.)  I know of one
implementation of UUCP done outside AT&T which was done by watching the line
and testing against AT&T implementations, and it's in a commercial product.
I don't think AT&T has any objection (but of course, if you asked them, they
would have their lawyers take two years to decide.)

On the other hand, the CODE implementing UUCP is certainly considered to
be AT&T proprietary, as is the rest of UNIX.  But how many thousands of
students have seen it?

>Private protocols should be discouraged as much as possible.  If a protocol is
>useful enough to consume part of the Internet namespace, it is useful enough
>to be documented for the rest of the Internet community.  My feeling is that
>if there MUST be a private protocol assignment it should be "one port per
>organization", and that organization should make some arrangement to identify
>which of their private protocols they way (e.g. the first octet from the user
>agent identifies "MIT protocol #n", or "Symbolics protocol #n", etc.)

I can assure you that if AT&T were to be assigned a single TCP socket
to multiplex on, things would immediately become totally unworkable.
After all, there are 16 bits worth of sockets out there!  That's a lot
of room.

By definition, any new experimental protocol invented by a commercial
organization is going to be proprietary, at least initially.  Getting
it published as an RFC requires a fairly major management decision.
Management has a lot of things to take into account in making such a
decision, and the open nature of the ARPANET community is only one
factor in that decision.  They are concerned about things like sales,
competition, and lead time on development.  Good arguments can be made
for the use of an industry standard protocol as a selling point, but in
a new area, there probably aren't any industry standards.  Depending on
lots of factors, the protocol might be published quickly and pushed as
an XXX standard (fill in your favoriate standards org for XXX) such as
Starlan or Ethernet; it might be published later, after developers have
had a chance to implement it and evaluate it (and gain lead time on
competitors - IBM did this with their PC and it still created an
industry standard); it might be sold under license to other vendors; or
it might be kept a trade secret.

	Mark

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18-May-86 00:16:45 EDT
From:      mark@cbosgd.ATT.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: port collisions

>As far as I've found, this belief that some ports are secure while
>others aren't is only implemented by Berkekley Unix.  Since other IP
>implementations do not necessarily honor this belief, there is no
>security in using *secure* ports unless your network consists
>exclusively of machines running Berkelely Unix.

I wouldn't even go that far.  Even if your network is all based on
the UNIX conventions (the System V product is the same at Berkeley)
you still don't really have much security.  You have to trust the
super users of all the systems on your network, and keep the cable
physically secure.  There are enough cheap PCs running UNIX these
days that any user with a PC can break in with a little cleverness.

Many protocols depend on higher levels of security, e.g. FTP uses
a password on every connection.  I won't claim that there aren't
security problems here, either, but the point is that for many
applications, magic numbers like 255 or 1024 don't mean much.
As far as I'm concerned, I can choose any 16 bit number.  In fact,
our current protocol being developed uses port 1624 and we're
quite happy.  Nonetheless, I hope to reserve the port number
to avoid a possible random future collision.  Of course, we will
have some sort of management decision about publishing our protocol
before we can publish it.

	Mark

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18-May-86 05:48:00 EDT
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re:  Redirect wars and Buterfly gateways

John,

you leave the impression that the Butterfly Gateway has nothing to
do with butterfly multiprocessor! The multiprocessor is indeed a general
purpose machine. It has been used by BBN to build a more powerful
internet gateway. Clearly, it can be used for other things. Lincoln Labs
did a very fast FFT implementation using a 16 processor version, I believe.

Vint

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 00:50:03 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   surprising property of ICMP redirect on Unix

I have discovered, much to my surprise, that on 4.2 (at least on the
Pyramid and Sun) the system will accept an ICMP redirect from anybody
and act on it.  We have used this feature to good effect a few times,
when the core gateways lose track of us.  We have a program redirect
that will send an arbitrary ICMP redirect to an arbitrary host.  We can
often use this to put an entry for our gateway into a foreign host's
routing table, and then establish connections with them.  More
usefully, I intend to use this in our local Ethernet gateways to set up
default routing entries pointing to that gateway.  We are getting so
many Unix systems, managed by so many turk... er... inexperienced system
managers, that we want it to be possible for us to get routing going
without any action on the part of the system manager.  We believe that
we can broadcast an ICMP redirect establishing a routing for host 0
(default) to our gateway.  I have verified that this works when it is
not a broadcast, but have not yet had a chance to try the broadcast
form.  I think that if we do this often enough to prevent the entry from
being purged by routed, we will get the effect we want.  (Actually,
routed should not be running on any of our hosts, but there are enough
... er ... inexperienced system managers around that I am sure it is
being run on many of our hosts.)  If someone sets up a different
default gateway for themselves, our broadcast will cause no trouble,
since a second default entry has no effect.  (Actually, it is probably
a bug that 4.2 creates a second entry rather than changing the
information in the first one.)

This is all very convenient for us, but it does seem to be a bug.
I hope that by the time the bug is fixed, the gateway committee will
have come up with a better way to accomplish this, and it will have
been implemented by all of our Unix vendors.  (say about 1996.)

-------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 06:13:36 EDT
From:      craig@LOKI.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: port collisions


    Just a side note to these discussions.  Some IP protocols have 
only 8 bit port numbers (for example, RDP and HMP).  Any general
solution might think a bit about how to handle these beasties
(RDP was spec'd after TCP and UDP, so there is no guarantee that
new protocols will abide with the 16 bit port size unless Jon
has decided to be more demanding on protocol designers).

    You can't casually give away many ports in a 256 port space
for private use.

Craig Partridge
CSNET Technical Staff

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 07:26:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: port collisions


    Date: Thu, 15 May 86 22:23 PDT
    From: Provan@LLL-MFE.ARPA


    just out of curiousity, why is it so important that you not publish your
    protocol as an RFC?  is it just secret and yo udon't want it to be copied
    or is there soem other reason?

    just so my cards are on the table, i do work for a private, for profit,
    TCP protocol development firm, so be sure not to give me any secrets.

At this time, we have no protocols that we with to treat as proprietary.

We do have protocols that are complex and not seperately documented.
Commented Lisp code is clear to those who have to maintain the works.

To go back and write an RFC just to get a port number is a lot of work,
since we don't need it and I imagine that no one else will ever use
these protocols.

The importance of avioding RFC's is that as a vendor it makes us
uncomfortable to have to interact with something like a number czar to
extend our product.  It introduces unpredictable timing and adds
work-load.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 07:31:59 EDT
From:      mrose@nrtc-gremlin.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions


    I'm not going to get into an argument about how people doing
    "independent, exploratory research of completely unrelated problem
    domains" should interact with a numbers czar on call 24-hours a day.
    That's silly, right?  But wouldn't it be okay to have a tacit
    agreement between people doing development work about the port space
    being used for "independent, exploratory research of completely
    unrelated problem domains" is divided up?  (i.e., Benson's group
    gets 600-699, David's group gets 700-799, etc., etc.).

    No matter how complex you make the port space (e.g., go from 16-bit
    integers to null-terminated strings of arbitrary length), you will
    still run into collisions.  There has to be some authority somewhere
    which maintains a registry, binding on all parties, which assigns
    protocols to the port space.

/mtr

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 07:44:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Port Multiplexing Details

I have been thinking about how the port multiplexing protocol might
work. Part of it seems simple enough, but part does not.

For TCP, the following sketch seems easy enough:

Given a TCP port for a NAMED-TCP-SERVICE service, you connect to that
port, and send the name of the service you want followed by a CRLF.

If the service exists, your connection is handed off to it.  If not, the
connecting is closed.

Server implementions are welcome to mark the TCB with the service name.

Conceptually, note that there need not be any numeric port number
associated with the protocol at all.

Some implementations may choose to implement this as a mapping from
names to ports.  It is particularly useful for the port used to vary, so
that no explicit configuration is needed to avoid collisions between
protocols.

For UDP, the problem is harder.

In the CHAOS protocol, the datagram equivalent carries a protocol name.
However, it dosen't carry any data.

Having UDP packets include a protocol name would none the less be the
most elegant.  I fear that it won't be practical.  It would probably be
necessary to invent UDP-2 as a full-fledged protocol that stored the
name-length in the header.

The weaker alternative is a UDP service that converts a protocol name
into a port number.  The problem here is the lifetime of the resulting
information.  If the mapping from names to numbers has to be permanent,
then each server implementation has to have a way to maintain a
permanent data base of the assignments, which would be a shame.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon 19 May 86 17:07:52-PDT
From:      MULHERN@SRI-KL.ARPA
To:        braden@ISI-BRADEN.ARPA, Margulies@SCRC-YUKON.ARPA, Murray.pa@XEROX.COM, postel@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Port Collisions
sorry for my previous message -- please ignor it
-------
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 May 86 20:24:26 -0500
From:      /Steve Dyer <dyer@harvard.HARVARD.EDU>
To:        JDELSIGNORE@F.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IF-11Q/1822 Device Driver
I might mention that the combination of a Unibus LH-DH/11 and
an Able Qniverter for your MicroVAX would do quite nicely,
and will run 'out of the box' with the standard 4.2/Ultrix if_acc.c
driver.  This is especially attractive because no UNIBUS backplane
is needed, just a UNIBUS cable from the Qniverter into the LH/DH-11.
Perhaps it's not cost-effective for wholly new systems, but it's
a great way to avoid trashing newly obsoleted LH/DH-11's when your
VAX750's and VAX780's are upgraded to MicroVAX-II's.
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 16:09:00 EDT
From:      JDELSIGNORE@F.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   IF-11Q/1822 Device Driver

Does any out there have a device driver for an IF-11Q/1822?  The
IF-11Q/1822 sold by ACC is composed of an XQ/1822 board and an MDMA
board.  I'm planning on installing the boards in the QBUS of a
MicroVAX II running Ultrix.  The boards are setup to do Distant Host
to an ARPANET IMP.

Thanks, John DelSignore
	JDELSIGNORE@F.BBN.COM

P.S. Please respond to me directly as I am not on this mailing list.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      19 May 1986 16:09-EDT
From:      JDELSIGNORE@F.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        JDELSIGNORE@F.BBN.COM
Subject:   IF-11Q/1822 Device Driver
Does any out there have a device driver for an IF-11Q/1822?  The
IF-11Q/1822 sold by ACC is composed of an XQ/1822 board and an MDMA
board.  I'm planning on installing the boards in the QBUS of a
MicroVAX II running Ultrix.  The boards are setup to do Distant Host
to an ARPANET IMP.

Thanks, John DelSignore
	JDELSIGNORE@F.BBN.COM

P.S. Please respond to me directly as I am not on this mailing list.
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 16:24:00 EDT
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Multiplexing Details

Concerning Benson Margulies' comments on NAMED-TCP-SERVICE:

You can't just close the connection if the service is not implemented,
because the TCP close is a half-channel close.  I really think you must
abort the connection, sending an RST packet, to indicate totally
unambiguously that the service is unavailable.

Consider the timing windows if you use a closing strategy:  the user
side sends the protocol name to NAMED-TCP-SERVICE, and then passes the
connection to the protocol user program.  Perhaps it waits for the
server's TCP to acknowledge the name bytes.  The server receives the
name, and the service is unavailable.  It closes the connection.  The
user side gets the close but is already in the protocol user code.  This
could be surprising; it might even have some other interpretation if the
service multiplexor is used for some existing service.

When an abort is used instead, this more closely resembles the response
of a system which doesn't implement the service.  If you try to contact
a TCP which has nothing listening on a port, the connection is
effectively aborted.  Granted, it was never established, but a RST
packet is a RST packet.

A cleaner alternative is to have some positive acknowledgement.  For
example, the server could send OK, DOWN, or UNKNOWN back, followed by a
CRLF.  The disadvantage of this is the extra overhead of the reply.  If
you are lucky, the reply data gets piggybacked on the name
acknowledgement, and the reply acknowledgement gets piggybacked on the
first packet of the user program.

Long live UDP-2.  My proposal for this used a null-terminated string on
the theory that it constitutes encouragement to use the UDP-2 protocol
only for one shot single-query single-response datagram exchanges.  This
was probably not clever of me.  By having a single length byte, you can
hash very nicely on length and first character.  I don't believe that
more than one length byte is needed, but perhaps one or two high bits
could be swiped as flags if 127 or 63 is acceptable as the maximum
length of a protocol name.  I still think that the name field should be
an even number of bytes long because a number of machines like their 16
bit fields aligned.  The spec should thus include a pad byte for odd
length names.

There is still the problem of designating the other end of the
transaction.  When you send a query the service name is equivalent to
the foreign port; when sending a reply, the service name is the local
port.  Either both ports must be named, or there will have to be some
other way of distinguishing queries from replies.  I really don't like
using two names, but perhaps that is best.  I would prefer service name,
transaction ID, and a query/reply flag.  The transaction ID would be
assigned by the querying host, and for many protocols ignored by the
server except to send it back in the reply.  Uniqueness might be
required in some cases, but is only needed for a given host pair and
service name, just as the port number would be.

The extra space taken by the name combined with the packet size limits
restricts the amount of data in the datagram.  For UDP, I have heard
suggested maximum packet sizes of 512 bytes, although you can send real
jumbograms between some implementations using fragmentation.  By
requiring that transaction IDs be unique over host pairs (during some
TTL (time to live)), the service name could be omitted from reply
packets.  If this seems ugly, how about a flag in the request packet
indicating whether it is permissible to omit the service name from the
reply.  If the flag is still set in the reply, there is no service name.

If the UDP port lookup service is written, a TTL field could be included
in the reply.  Some user sides might ignore the TTL and look up every
time they had a transaction.  For simple exchanges this doubles the
overhead.  Hosts with a permanent database could return very long times
to live; and long TTLs would be the rule when servers permitted looking
up permanently assigned values like TELNET => 23.  When the port numbers
are assigned on a per-bootload basis, or even more often, TTL values
like one minute could be used to allow for system crashes or service
restarts.

The UDP service might be useful for protocols other than TCP.  A request
packet could include the protocol ID and the name of the service.  The
reply could begin with the request and add the port number and TTL.
Perhaps the port number could be at the end so that protocols could have
port numbers more than 16 bits long.

I think it is reasonable to refine all three proposals.  I fear that
there will be few takers for UDP-2.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 17:12:00 EDT
From:      gds@SRI-SPAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Redirect wars and Buterfly gateways

> From: tom@LOGICON.ARPA (Jeff Makey , Tom Perrine)
 
> Speaking of brain-dead gateways, we have had some more instances of the
> ICMP "redirect wars".  This morning SRI-MILNET-GW redirected us to
> BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened
> 11 times in 29 seconds while trying to establish a connection.
> A reponse came in 23 seconds, but after we had timed out.

This happens to me also.  Here's a sample netstat -r from sri-spam.arpa
(10.2.0.107/192.5.38.3).  It seems that our default gateway does not
always know how to get cross-net ...

Routing tables
Destination     Gateway         Flags    Refcnt        Use SWS pm Interface
default         10.1.0.107      UG            0         25  75  0 imp0
su-net-temp     sri-milnet-gw.a UG            0       1030  75  0 imp0
su-net-temp     isi-gateway.arp UG            0       1027  75  0 imp0
su-net-temp     stanford-gatewa UG            0       6071  75  0 imp0
su-net-temp     hazeltine-gw.ar UG            0          3  75  0 imp0
su-net-temp     sac-milnet-gw.a UG            0          3  75  0 imp0
su-net-temp     sri-gw.arpa     UG            0          4  75  0 imp0
su-net-temp     lbl-milnet-gw.a UG            0          2  75  0 imp0
su-net-temp     bbn-milnet-gw.a UG            0          4  75  0 imp0
su-net-temp     bbnnet2-arpanet UG            0          4  75  0 imp0
su-net-temp     bbn-van-gw.arpa UG            0          2  75  0 imp0
su-net-temp     crc-gw.arpa     UG            0          1  75  0 imp0
su-net-temp     bbn-cronus-gw.a UG            0          2  75  0 imp0
su-net-temp     isi-milnet-gw.a UG            0          1  75  0 imp0
su-net-temp     sri-csl-gw.arpa UG            0          2  75  0 imp0
su-net-temp     bbn-net-gateway UG            0          2  75  0 imp0
su-net-temp     dcec-milnet-gw. UG            0          1  75  0 imp0

Note the highest use count for the su-net-temp net is for
stanford-gateway, which is as it should be.  Some of the other gateways
mentioned are a little skeptical -- why would multiple gateways at BBN
be involved in what should be a decision strictly made in California?

One question is how your host handles redirects.  In 4.2, if there are
multiple gateways to the same destination, it attempts to share the load
between the two, by taking the lowest use count.  I have discovered
situations in which this may not be ideal.  4.3 attempts to be more
flexible by taking the route from the last redirect, and notifying any
connections of the route change (this is done in 4.2 BBN also).  There
is a short time in between the issuance of the redirect and the route
change for the connection in which the old route might be used, which
could cause a flurry of redirects.  I'd like to know how yours (and
others) IP routing implementations handle these sort of situations.
(I'd especially like to hear from the "hosts should be dumb, gateways
should be smart" folks.)

Back to the original topic, though, I have noticed similar behavior
going between sri-milnet-gw.arpa and bbn-milnet-gw.arpa for a lot of
connections I make (aside from the above, this happens for the rutgers
and mit-temp networks).

--gregbo

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      19 May 1986 20:18-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        JSLove@MIT-MULTICS.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Port Multiplexing Details
Let's  try  and make this as simple as possible, at least for the
TCP side.  I haven't taken a look at the UDP stuff yet, but there
may be a totally seperate solution.

Having  yielded to the original point that a multiplexing port is
necessary, I went back and took a look at the spec  and  came  up
with the following:

1) Assign a standard TCP port for a Contact by Name server.

2)  Define  a  TCP option - Contact Name, give is some reasonable
maximum.  (32 chars?

3) The Contact Name option is only valid in a packet containing a
SYN.  (Just like the max seg size option).

4)  Multiplexing  is  still done at the TCP level, based on ports
and host addresses.  In fact, once the connection is open,  there
is no difference in the way it is handled.

Looking  at  the  implementations  I  am  familiar with (Multics,
UNIX), this shouldn't be difficult to implement at all.

Mike
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 17:44:50 EDT
From:      MILLS@USC-ISID.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: surprising property of ICMP redirect on Unix

In response to the message sent  19 May 86 00:50:03 EDT from HEDRICK@RED.RUTGERS.EDU

Charles,

While I have ample sympathy with your routing problems in the local
environment, I sure would like to discourage use of ICMP redirects in lieu
of something more robust. The danger of accidental and/or malicious abuse,
not to mention what happens when the bug is "fixed," would seem to argue against
the scheme in the first place. Several of us have been scratching on some
sort of gateway requirements model which, if it were adopted, might preclude
your scheme in the interests of robustness. Your comments on Appendix A of
RFC-981 would be much appreciated.

Dave
-------

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      19 May 1986 17:44:50 EDT
From:      MILLS@USC-ISID.ARPA
To:        HEDRICK@RED.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA
Cc:        MILLS@USC-ISID.ARPA
Subject:   Re: surprising property of ICMP redirect on Unix
In response to the message sent  19 May 86 00:50:03 EDT from HEDRICK@RED.RUTGERS.EDU

Charles,

While I have ample sympathy with your routing problems in the local
environment, I sure would like to discourage use of ICMP redirects in lieu
of something more robust. The danger of accidental and/or malicious abuse,
not to mention what happens when the bug is "fixed," would seem to argue against
the scheme in the first place. Several of us have been scratching on some
sort of gateway requirements model which, if it were adopted, might preclude
your scheme in the interests of robustness. Your comments on Appendix A of
RFC-981 would be much appreciated.

Dave
-------
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 20:07:52 EDT
From:      MULHERN@SRI-KL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Collisions

sorry for my previous message -- please ignor it
-------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 20:32:32 EDT
From:      GROSSMAN@SU-SIERRA.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Port collisions continued/Service naming

DECnet solved this problem a long time ago.  Here is what it does:

In DECnet, the SYN message (called a CI in DECnet) can contain one of the
following for both the destination and source ports:

	1) A numeric service id (ala the FTP, TELNET, etc known ports).
	2) A string service id (usually called a process name).
	3) A PPN and a string service ID.

This data is actually carried inside the CI message just as though it was
user data.  The point is that the desired service is specified by a string
of bytes of (almost) arbitrary length and format in the normal data bucket
within the message.  By contrast, TCP describes the desired service by
using some bytes from the port number of the packet, which is very small
and inflexible compared to the aforementioned scheme.

This means that the port numbers used in DECnet have no intrinsic meaning
(other than to uniquely identify this logical link).  Once DECnet has made
a connection, there is no way to tell what type of service is being used
over a logical link.

With respect to secure services, DECnet implementations are supposed to only
allow privileged people to offer services for service types 1-128.  In
addition, only privileged people are allowed to use a different PPN from
their own in the source descriptor type.  I don't beleive that any DECnet
implementations currently impose any restrictions on the string service ID
text.  But it would be easy to add.

Note that the format type is carried along in the CI message prefixed to the
data that it is describing.  Currently, only 3 format types are defined.  It
would be trivial to add more if they were deemed necessary.

I think that adding this to TCP could be done fairly easily.  One way to
do it would be to create a new option:

	Kind	Length		Meaning
	----	------		-------
	 3	  --		Service ID

	If this option is present, then it communicates the name of the
	service that the user desires.  The format of the service name
	is TBD...  This option must only be sent in the initial connection
	request (i.e., in segments with the SYN control bit set).

The only important thing about the Service ID is that it should be of
arbitrary length, and allow for multiple (but well specified) formats
by using a format type byte in the beginning of the data.

Another way to put this into TCP would be to create a new control bit:

	SID:	Service ID

	If this flag is on, then the data segment of the datagram contains
	a service name string.

The format and restrictions on this would be the same as for the option
described above.

Now for the question of backwards compatibility.  Lets say that old TCPs were
allowed to just ignore this option/SID bit.  Then senders would be able to
ensure connections by making SYNs that used BOTH a known port AND the Service
ID option/SID bit.  The one bugaboo that this has is that TCPs that support
the Service ID option/bit would have to be careful about avoiding
"known ports" unless they really mean to use them for their intended purpose.
A way around this would be to create another flag called the KP (Known Port
(Kitchen Patrol :-)) flag.  If this is set, you are using a known port,
otherwise the port is just a random number.  I would desperately urge people
to come up with a better way than this flag.

			Just another point 'o view,
				Stu Grossman
-------

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 22:32:55 EDT
From:      mike@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  [domiller@lognet2.ARPA (Donald G. Miller): HP 3000]

Contact Skeet Steffey <CSteffey@WSMR>.  WSMR has been doing some
neat stuff with TCP for HP machines.
	Best,
	 -Mike

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 May 86 22:32:55 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        AFDDN.BEACH@gunter-adam.arpa, domiller@lognet2.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  [domiller@lognet2.ARPA (Donald G. Miller): HP 3000]
Contact Skeet Steffey <CSteffey@WSMR>.  WSMR has been doing some
neat stuff with TCP for HP machines.
	Best,
	 -Mike
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 23:18:00 EDT
From:      STJOHNS@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Multiplexing Details

Let's  try  and make this as simple as possible, at least for the
TCP side.  I haven't taken a look at the UDP stuff yet, but there
may be a totally seperate solution.

Having  yielded to the original point that a multiplexing port is
necessary, I went back and took a look at the spec  and  came  up
with the following:

1) Assign a standard TCP port for a Contact by Name server.

2)  Define  a  TCP option - Contact Name, give is some reasonable
maximum.  (32 chars?

3) The Contact Name option is only valid in a packet containing a
SYN.  (Just like the max seg size option).

4)  Multiplexing  is  still done at the TCP level, based on ports
and host addresses.  In fact, once the connection is open,  there
is no difference in the way it is handled.

Looking  at  the  implementations  I  am  familiar with (Multics,
UNIX), this shouldn't be difficult to implement at all.

Mike

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-May-86 23:50:29 EDT
From:      dyer@HARVARD.HARVARD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: IF-11Q/1822 Device Driver

I might mention that the combination of a Unibus LH-DH/11 and
an Able Qniverter for your MicroVAX would do quite nicely,
and will run 'out of the box' with the standard 4.2/Ultrix if_acc.c
driver.  This is especially attractive because no UNIBUS backplane
is needed, just a UNIBUS cable from the Qniverter into the LH/DH-11.
Perhaps it's not cost-effective for wholly new systems, but it's
a great way to avoid trashing newly obsoleted LH/DH-11's when your
VAX750's and VAX780's are upgraded to MicroVAX-II's.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-May-86 15:33:51 EDT
From:      bruce@THINK.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   4.2bsd gateways

I have heard many things about deficiencies of 4.2bsd as internet gateways.  I
know some of these involve old bugs which I have fixed in our kernel, and some
are just unimplemented (like sending ICMP redirects), and some just result in
poor efficiency.  However, I would really like to hear the whole scoop on what
needs to be done to get it right; up until know I haven't been too concerned
becuase our ``gateway'' is the primary machine here, so it doesn't do too much
forwarding.  It seems to work fine to other unix machines, but the throughput
that Symbolics lispmachines see is horrible.  Also, how different is the 4.3
implementation?

--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
--bruce@think.com, ihnp4!think!bruce; +1 617 876 1111

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-May-86 17:33:00 EDT
From:      DCP@SCRC-QUABBIN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Port Multiplexing Details

It shouldn't end in CRLF.  For that matter, you might as well do what
CHAOS did: add arguments to the 'contact name'.  You could even use the
urgent pointer to delimit the end of the contact/name arguments!

In the CHAOS protocol, there is only one type of connection: you connect
with a packet that has contact name and arguments.  There is no
'datagram equivalent'.

I guess I'm not sure what the UDP problem is, possibly because I don't
know how UDP connections get started.  Isn't there a 'first' packet that
can include the contact name?

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-May-86 17:53:23 EDT
From:      geof@imagen.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Fiber-optic Ethernet Extender

Sorry that this is a little off the topic, but someone on this list
probably knows the answer to this question.

We are in need of a way to extend our network across a conduit to an
adjacent building.  To simplify matters, we'd like to use an "ethernet
extender" device that hooks two halves of an ethernet together
with a fiber optic cable and looks like a repeater (?).  I seem to
remember that something like this exists, but I don't remember much
about it.  Does anyone know about such a product?

Does anyone have clever ideas of how to connect two ethernets in
different but adjacent buildings (don't bother to tell me about
gateways, I know about them).
 
- Geof Cooper
  Imagen

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 01:57:05 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   more oddities from the swamp

I have come up with a somewhat better kludge for notifying my hosts
about the gateway than using broadcast ICMP redirects. The machines I am
worried about are normally configured to run routed as they come out of
the box.  It turns out that it is  possible for a gateway to advertise
via routed that network 0 is one of the destinations it can forward to.
This will set up the gateway as a default gateway on the routed clients.
This seems a more controlled way of doing what I want then unsolicited
ICMP redirects, since routed is the protocol that gateways are supposed
to use to announce themselves.

However there is another interesting problem with either approach. They
both require broadcasts, but it is not clear whether it is safe to do
broadcasts on our networks.  Our problem is that half of our hosts know
about subnetting and the other half don't.  We have to make our Pyramid
and Sun kernels  know about subnetting, because we have machines of both
kinds with more than one interface.  But we have lots of machines from
other vendors that do not support subnets and do not supply source.
Generally this is not a big deal. They can talk to each other.  Routing
entries have to be a bit different for the two classes of machines,
since one thinks all of 128.6 is one network, whereas the other knows
about 128.6.n.  But our gateway can handle the ARP hack, so if a
non-subnet machine ARPs a machine on a different subnet, the gateway
handles it.  The problem comes in when we send a broadcast.  the only
broadcast address that Unix will understand is network.0   (I think this
is probably a bug.  But it doesn't do me any good to send a broadcast
which meets all the RFC's but nobody will receive.  So I'm stuck.)  The
question is, what network number should I use.  If I send to 128.6.0.0,
the non-subnet machines accept it just fine.  But the subnet machines
all think I am trying to send a broadcast on subnet 0.  Since that is
not their subnet, they do not process the broadcast.  For some reason
that I don't quite understand, we get back a bunch of  ICMP ttl exceeded
messages.  As far as I can tell, some of the machines try to forward the
message to subnet zero, and get into a routing loop. If I send to
128.6.4.0, the subnet machines accept it just fine.  But the non-subnet
machines think I am trying to send to host 4.0 on network 128.6.  They
helpfullly attempt to forward it.  Thus I suddenly get an ARP request
from every non-subnet machine, asking for the address of 128.6.4.0.  Our
Arpanet gateway, which also does not know we have subnets, also thinks
we are trying to get it to forward packets to 128.6.4.0.  But it notices
that this is on the same network, pronouces it an utterly bogus request,
and sends back an ICMP redirect to the original sender, saying "do it
yourself, idiot" [by the way, is this a standard use of ICMP redirect?
What is a gateway supposed to do when a host asks it to forward a packet
back onto the same network that it came in from?  Intuitively, it seems
reasonable that an ICMP redirect should occur, but it is not clear what
gateway address one should use.  Our Arpanet gateway uses the
originator's address.  This is somehow morally correct and esthetically
satisfying, but no implementation that I know of knows what to do when
given an ICMP redirect pointing back at itself.]

The net effect of all of this is the any broadcast results in a  flurry
of other network traffic.  This makes it seem unreasonable to use any
protocol that requires a broadcast every 30 sec. 

By the way, this is not the worst symptom of networks containing a mix
of subnet and nonsubnet machines.  Now and then somebody brings up a Sun
kernel that does not have the subnet patches.  If you try to boot a
diskless Sun on a network containing a mix of  subnet and nonsubnet
machines, the entire network comes to a halt for a period of a minute or
so.  (Actually to be fair, the only machines that come to a halt are
other Suns and Celerities.  Our Pyramids and DEC-20s seem unaffected.)


-------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 03:22:47 EDT
From:      JNC@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: more oddities from the swamp


	Sorry, my bogometer just tripped when I got to the phrase
'routed is the protocol that gateways are supposed to use to announce
themselves'. First, this protocol is not documented anywhere. Second,
it's not an official Internet protocol. Third, it is a gross violation
of IP design philosophy to have hosts know about a gateway routing
protocol for any reason, let alone just to find out where gateways
are.
	The Internet Engineering committee has talked about a new ICMP
message for hosts to find gateways; I'll try to get this written up
soon.

	I sympathize with your problems with Unix and broadcast
addresses.  We get shafted by the same thing; the upward compatability
with all the nonstandard stuff and gratuitous functionality (such as
non-subnet hosts fowarding packets to 128.6.4.0) in 4.2 is an
incredible drag.
	It is to prevent confusion about exactly who is being
broadcast to that I maintain that the 'default' broadcast address to
use is all 1's, rather than use net.1's or subnet.1's, etc. It's much
harder to lose using all 1's; the only possible meaning is 'local
wire'.
	Unfortunately, it's way to late to put the 4.2 genie back in
the bottle. Maybe we should all quit and become wood carvers?

	Noel
-------

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 05:05:00 EDT
From:      FTD%MIT-OZ@MC.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Fiber-optic Ethernet Extender



Dec makes one but I don't have the part number.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      21 May 86  0915 PDT
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ICMP redirects
What do the ICMP redirects that are used to fool Unix contain in the
field that is supposed to be the Internet header of the original
datagram causing a redirect?  Can you just make up some values to
cause the action that you desire?

It would seem that hosts should do some validity checking on redirects
before believing them.  This should include checking the Internet
header field to see if it corresponds to a packet that was sent out.
It would also be useful to see if the gateway sending a redirect is in
fact the one to which the original message was sent, and ignore it if
not.  But this is complicated by the fact that it is apparently legal
for a gateway to use any of its addresses as the IP source address of
the redirect.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 09:20:00 EDT
From:      SRV.MDC@OFFICE-1.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber-optic Ethernet Extender

Digital Equipment Company sells two ethernet repeaters.  Their local ethernet 
repeater (DEREP-AA) can connect two 500 meter segments of Baseband Ethernet 
coax.  Their Remote Ethernet Repeater (DEREP-RA) uses a fiber optic cable to 
connect two  segments that are up to 1000 meters apart.  I got these out of 
DEC's Networks and Communications Buyer's Guide.  Your local DEC rep should be 
able to get this for you.

I am not affiliated with DEC in any way other than using their products.

Stephen Veit (Veit@Office-1)

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 09:43:22 EDT
From:      hoffman%pitt@CSNET-RELAY.ARPA (Bob Hoffman)
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber-optic Ethernet Extender

Fiber optic Ethernet extenders are made by American Photonics, Inc.;
71 Commerce Drive; Brookfield Center, CT  06805; 800-626-5745 or
203-775-8950/8955.

Their RL6000 series of Ethernet repeaters will connect two segments
of a V2.0 or IEEE 802.3 Ethernet LAN by way of duplex optical fiber
cable up to 1000 meters in length.  Price is around $4K/pair.

I have not used these units, but we are considering their purchase to
link up two Ethernets on campus.  Another department at Pitt has
purchased T1 multiplexers from API and they are satisfied.

-- 
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    hoffman%pitt@csnet-relay

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 May 86 09:43:22 edt
From:      Bob Hoffman <hoffman%pitt@CSNET-RELAY.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Fiber-optic Ethernet Extender
Fiber optic Ethernet extenders are made by American Photonics, Inc.;
71 Commerce Drive; Brookfield Center, CT  06805; 800-626-5745 or
203-775-8950/8955.

Their RL6000 series of Ethernet repeaters will connect two segments
of a V2.0 or IEEE 802.3 Ethernet LAN by way of duplex optical fiber
cable up to 1000 meters in length.  Price is around $4K/pair.

I have not used these units, but we are considering their purchase to
link up two Ethernets on campus.  Another department at Pitt has
purchased T1 multiplexers from API and they are satisfied.

-- 
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    hoffman%pitt@csnet-relay

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 11:16:00 EDT
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Port Multiplexing Details

Are the general readership really interested in seeing this design
discussion continue on the TCP-IP list?  I haven't received any
complaints about my long messages, but perhaps the interested parties
have already identified themselves.  If this goes on much longer, should
we create a new list or something?

Putting the contact name in a TCP option in the header of the SYN packet
is cute:  it solves the problem of gateways finding out what service
owns the connection.  It is ugly to have to use a reserved port number
as well, but it would clearly be necessary so that hosts which didn't
implement the protocol would properly reject such packets.

However, putting the contact name in the header imposes length
limitations much more stringent than placing it in the data stream.  It
also requires significant changes to all TCPs that participate in this
game.  Perhaps that seems desirable to others, but I view both as
disasterous.

A 32 character name length may seem adequate, but it really isn't.
First, the number czar may give out long suffixes, like SYMBOLICS-,
THINKING-MACHINES-, HONEYWELL-INFORMATION-SYSTEMS-, and so on.  Within
an organization, there may be further delegation, like OFFICE-SYSTEMS-,
ULTRIX-, SCRC-, and so on.  It would be better to spell out names like
MANDELBROT, rather than having them compressed into MNDLBRT or given
less clear names like DCP3.

In the connection model we are currently using, there is no use for
contact arguments.  There is no pressing need to implement them, since
we are using a stream protocol.  The contact arguments can effectively
just appear in the TCP data stream.  I believe that FINGER is a good
example.  For TCP, the FINGER server arguments appear at the beginning
of the data stream.  In fact, they are the whole data stream in one
direction.  In CHAOS, the first packet contains the FINGER contact name
and the arguments.  The only other packets to go in that direction are
the acknowledgements of the reply.  TCPs generally assume a zero window
until the connection is established, so TCP requires at least two
packets to do what CHAOS does in one.

However, contact arguments can server as protocol specific options, and
it is easy to envision services that might be offered for more than one
stream protocol.  For example, a system might support TCP, DECNET
(whatever their stream protocol is), CHAOS, TP4, X.25, and so on.
Defining an out-of-band mechanism for later use preserves flexibility.

Even though it makes life harder for security-minded gateways, I think
that the advantages of putting the contact information at the front of
the stream outweigh it.  Protocols which must cross the secure gateways
can be assigned numbers.  The gateways can reject multiplexor port SYN
packets.

Sending the contact information urgently is less disruptive since many
TCPs wouldn't have to be modified to permit this.  The advantage of a
protocol that sends the contact information in the stream is that no
underlying mechanisms need be modified on either side of the connection.
The user side just sends the contact information at the beginning of the
stream, suitably delimited, and the server side reads it and acts on it.
The server TCP doesn't need to be modified; the server could make a new
connection to a numbered port and transfer bytes between the two
connections transparently.

Still, there may be TCPs that don't handle urgent data well.  The
rationale for using a network newline (CRLF) to delimit the connection
name is that this is a standard delimiter sequence which is widely
understood across the network.  Any ASCII character may be sent without
triggering recognition of this delimiter since a CRLF can be quoted as
CR NUL LF.  (That is asking for trouble since there are implementations
which are defective in this department.)  Certainly any printing
character can be sent with any implementation.  Sending the contact
name, an optional space followed by contact arguments, and ending the
whole thing with a newline makes it very easy for both user and server.
The server can read one line from the TCP, which is often available as a
primitive.  (If it isn't, there are other ways of ensuring that too much
data is not read from the TCP, like reading one character at a time.)

On Multics, either urgent or newline-delimited contact names would be
easy to implement.  Interoperability would be possible in a very short
time, although improvements could be made later.  A new option would
require significant changes to the underlying TCP for every system that
used it, a much bigger job.

UDP is a connectionless protocol.  It has no options, and no memory from
one packet to the next.  Requests are sent out to a well known port from
a local port which is used to identify the reply, if any.

There are two common scenarios which UDP is used for:  a simple
announcement or query where each participating host sends at most one
packet, and as an underlying base for implementing some complex
protocol.  To ask the time, for example, one host sends a UDP packet to
the time port; there may be no data in the packet (except the port
number to return the time to, which is part of the UDP header).  The
reply contains only the time, perhaps as a 32 bit number.  When it
arrives, the transaction is finished.  This might be a good candidate
for a UDP-2 protocol which carried the name
"TIME-IN-SECONDS-SINCE-1970/01/01-00:00:00-GMT" rather than a well known
port number.  At least one such protocol would get the short name
"TIME", I suppose, since the desire for precise names doesn't seem to be
widespread.

Other examples include TFTP and the remote virtual disk protocol.  Both
of these applications maintain considerable state information about a
session and exchange many packets during the session.  Using UDP-2 would
increase the overhead of the protocols, and might decrease the amount of
useful data sent in a datagram.  For these sorts of services, some other
service to translate service names into port numbers would be much more
efficient.

The UDP lookup server, like Benson's version of the multiplexor server,
is easy to implement.  UDP-2 might be nice, but is an even bigger job
than adding a new TCP option, and I never expect to see it in general
use.

Concerning contact names:  how about reserving some TCP options as
"higher-level protocol specific"?  The options could vary in meaning and
even length depending on which protocol (well known port) was used.
They would be valid only for the SYN packet.  TCPs which play this game
could indicate in the LISTEN or OPEN call that they would accept such
options, and define a way for the application server to read them when
the connection is established.  TCPs which don't implement the options,
or TCBs which don't accept the options would cause the connection to be
aborted rather than established.  This precursor would make it possible
to implement St.  Johns' version of the Named-Service server, and would
provide a mechanism like contact arguments.

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 12:15:00 EDT
From:      JJW@SU-AI.ARPA (Joe Weening)
To:        mod.protocols.tcp-ip
Subject:   ICMP redirects

What do the ICMP redirects that are used to fool Unix contain in the
field that is supposed to be the Internet header of the original
datagram causing a redirect?  Can you just make up some values to
cause the action that you desire?

It would seem that hosts should do some validity checking on redirects
before believing them.  This should include checking the Internet
header field to see if it corresponds to a packet that was sent out.
It would also be useful to see if the gateway sending a redirect is in
fact the one to which the original message was sent, and ignore it if
not.  But this is complicated by the fact that it is apparently legal
for a gateway to use any of its addresses as the IP source address of
the redirect.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 13:59:36 EDT
From:      geof@imagen.UUCP (Geof Cooper)
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber-optic Ethernet Extender

Much thanks for the 15 or so immediate responses.  To summarize, people have
mentioned that repeaters and half-repeaters (sometimes called "remote
repeaters) are available as products from DEC, Xerox, Ungerman Bass,
American Photonics (actually, this last one is a fiber extension of the
Ethernet transceiver cable (between the tap and the host)).  One idea
suggested was to run low-cost ethernet coax between buildings, with a
half repeater on each side of it.

DEC's products were by far the most frequently mentioned.  Several people
said they have one or the other product installed and working.  There were two
products mentioned.  One was the DEREP repeater, which is "intended for
exactly the type of use you describe (to link buildings where there may
be a ground potential difference, perhaps a small conduit, and a moderate
distance (I forget the max, but it is something like 1000M I think))"
[JSPEAR@AI.AI.MIT.EDU].  The other was the Lanbridge-100, which seems to
be something more like a "transparent gateway" -- it peeks at network
traffic and selectively relays information.  It apparently has a fiber
optical extension available as an option.

The DEREP-RA Remote Ethernet Repeater cost $4,400 (for both halves) in
September '85.  However, "it seems to be slightly divergent from the
Ethernet specs in that it only seems to work properly when connected
to the coax with a DEC transceiver (H-4000).  Aside from that problem,
we've had one in use...without troubles [mckenzie@j.bbn.com].

Thanks again,

- Geof Cooper
  Imagen

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 15:01:02 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: more oddities from the swamp

I have been through this with Mills also.  Everything that you say
is right.  But it is also nearly irrelevant for those of us out
in the swamp surrounded by binary-only alligators.  I would be
quite happy with an ICMP who is my gateway or ICMP I am the default
gateway.  But until such a thing shows up, I use what I have, and
that is routed.  I think this list needs to discuss both what the
standards should be and what we should do until it becomes practical
to use the standards.  My best estimate is that it will take about
3 years between the time you define something and when we can
depend upon using it.  At the moment it is likely to take longer
than 3 years, since anything that is done now will have just missed
a new release of Berkeley Unix.  A number of vendors don't do anything
until a features shows up in BSD.  So any new ICMP things are likely
to have to wait for 4.4, then another year or so until all the vendors
incorporate the 4.4 features.  Lest you think I am being overly
pessimistic, look at the slow spead of subnets.  A change in broadcast
address is going to be particularly messy, since unless everybody does
it at the same time (a manifest impossibility), we could be in for
some incompatibility.  I would recommend that implementations should be
prepared to accept any of 
  net.0
  net.subnet.0
  -1
for the moment.  Once everyone recognizes -1, all senders would start
using it, and the 0's could be phased out.  Alternatively, your
subnet RFC could have specified that the correct broadcast address
for implementations that use 0's is net.0, not net.subnet.0.  then
we would have one less incompatibility to deal with.

By the way, a month or so ago we got this shiny new collection of
Internet protocol documents.  I assume this is what most vendors
use to do their implementations.  I didn't see subnetting it in.
I didn't see any signs of -1 being specified as the broadcast address.
How many vendors do you think know that they are supposed to be
changing the broadcast address?
-------

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 May 86 17:41:36 EST
From:      John Leong <leong@ANDREW.CMU.EDU>
To:        imagen!geof@decwrl.DEC.COM (Geof Cooper)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Fiber-optic Ethernet Extender

DEC, Ungermann-Bass (UB) and American Photonics (API) make both local
and remote repeaters. 

All the remote repeaters use fibre optic cables. DEC and UB requires
100 micron cable while API is engineered for 50 micron. (Phone companies
had been busy putting in 50 micron cables. They are now changing to
62.5). One thing you should know is that when you connect a 100 micron
light source into a 50 micron cable, you lose 75% of your light !!!  

API has an Ethernet extender which is really a long fibre drop cable
transceiver and is quite cute.

If you want to join two nets together but do not want to sum up the
traffic, you can investigate into the LANbridge from DEC. They sell
both a local as well as a remote version (or you can use a local version
with the API Ethernet extender). I really like the LANbridge better
than plain repeater since they will relay only applicable packets to
the other side. However, they do cost $$$$. (roughly $8,000 list)

John Leong


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 18:36:56 EDT
From:      mar@MONK.PROTEON.COM (Mark A. Rosenstein)
To:        mod.protocols.tcp-ip
Subject:   more oddities from the swamp

There is something that can be done to cut down on the flurry of
packets in response to a broadcast.  On all of the 4.2 Unix machines
which are not serving as gateways, turn off IP forwarding in the
kernel.  This will cause them to no longer send ICMP messages or
forward packets that were not specifically addressed to them in the
first place.  Forwarding is controlled by the variable _ipforwarding.
If this is set to zero, these extra packets will not be generated.  On
binary-only systems, you still can turn it off using adb on /vmunix.
					-Mark

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 18:41:36 EDT
From:      leong@PO1.ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber-optic Ethernet Extender


DEC, Ungermann-Bass (UB) and American Photonics (API) make both local
and remote repeaters. 

All the remote repeaters use fibre optic cables. DEC and UB requires
100 micron cable while API is engineered for 50 micron. (Phone companies
had been busy putting in 50 micron cables. They are now changing to
62.5). One thing you should know is that when you connect a 100 micron
light source into a 50 micron cable, you lose 75% of your light !!!  

API has an Ethernet extender which is really a long fibre drop cable
transceiver and is quite cute.

If you want to join two nets together but do not want to sum up the
traffic, you can investigate into the LANbridge from DEC. They sell
both a local as well as a remote version (or you can use a local version
with the API Ethernet extender). I really like the LANbridge better
than plain repeater since they will relay only applicable packets to
the other side. However, they do cost $$$$. (roughly $8,000 list)

John Leong

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-May-86 21:14:04 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: more oddities from the swamp


	The reason the subnet RFC didn't speak about net.0 versus
net.subnet.0 is a) we wanted net.broadcast to mean something different
from net.subnet.broadcast, and b) that spec was written, although
unfortunately not released, before 4.2 came out.
	I have already complained fairly strongly to Jon Postel about
the lack of subnet stuff in the IP protocol documents. I didn't
realize that broadcast was also missing.

	The whole problem of out of date implementations attached to
the network system is one of the key organizational (as opposed to
technical) problems the system faces right now. You are correct that
currently the time around the loop is several years. The problem is
that this kind of delay is not acceptable if the system is going to
continue to grow successfully at the rate that it has been growing.
Things are going to break and need to be replaced, and we can't wait
around for years until vendors feel like fixing things.
	I think we need two things: a certification process, and
pressure from buyers. The need for the first is clear; right now there
is no comprehensive test of whether or not something correctly obeys
all the protocols. It's hard to beat up vendors when you don't have a
definite measuring stick for them. Second, people have to get militant
about timely support. Don't buy something if you don't get either a)
source, or b) a written commitment to pass the testing suite within N
months of changes.
	Such products may cost more, but look at the other side: you
will waste countelss skilled people hours pasting things together if
you buy whatever's cheapest. But people *have* to exercise discipline
and say to vendors "No, your stuff does not meet the spec, *go away*".

	Noel
-------

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-May-86 04:13:43 EDT
From:      chris@BRILLIG.UMD.EDU (Chris Torek)
To:        mod.protocols.tcp-ip
Subject:   4.3(beta) subnets & routed

This is perhaps obvious in retrospect, but it is a bad idea to run
routed between two machines with different subnet masks.  Boy do
they get confused.  Sorry about all those UMDNET packets that sprayed
out into the MILNET (though that may have been due to an unrelated
mistake).  (We just turned on subnets, and I did it in phases.  That
was a mistake.  Do it all at once!)

Other than that, hey!, it works very well indeed.  You will need
to use `route -n add <subnet> <gateway> <metric>' (note the `-n')
if your subnet gateways do not run routed.  I am not sure what
happens if they do:  ours are not under my control (for which many
are no doubt grateful :-) ).

Chris

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-May-86 07:46:46 EDT
From:      mo@SEISMO.CSS.GOV (Mike O'Dell)
To:        mod.protocols.tcp-ip
Subject:   multiplexing

I don't know which is funnier: seeing this august community very nearly
advocating the need for what is almost the ISO session protocol, or seeing it
retrench and reinvent the "USER DATA" part of the X.25L3
"Call Request" packet as an alternative.  (Even the X.25 boys now
believe in the folly of the latter.)

Jeez! Could the the ISOOSI Tribe bit mongers have been right?????

	Ducking under the table for a while until
	everyone settles down,

	-Mike O'Dell

--------
"Little Packets,
 Little Packets,
 Little Packets made of Ticky Tacky,
 .....
 Little Packets just the same."

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-May-86 08:14:26 EDT
From:      louden@MITRE-GATEWAY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: more oddities from the swamp

The "shiny new collection of Internet protocol documents" does have
the "-1" address. See volume 3 page 177 last paragraph.
It does not say "-1" because that makes assumptions about your hardware
it is described as 'addresses of all ones are to be interpreted as meaning
"all"'.  The word broadcast is also not used because it makes assumptions
about your hardware.

Subnets are mentioned in volume 3 page 244 but I did not see any detailed
discussion.

The documents make an excelent starting point but may not be complete for
all applications.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      22 May 1986  8:14:26 EDT (Thursday)
From:      T. Michael Louden (MS W422) <louden@mitre-gateway.arpa>
To:        hedrick@rutgers
Cc:        tcp-ip@sri-nic, louden@mitre-gateway.arpa
Subject:   Re: more oddities from the swamp
The "shiny new collection of Internet protocol documents" does have
the "-1" address. See volume 3 page 177 last paragraph.
It does not say "-1" because that makes assumptions about your hardware
it is described as 'addresses of all ones are to be interpreted as meaning
"all"'.  The word broadcast is also not used because it makes assumptions
about your hardware.

Subnets are mentioned in volume 3 page 244 but I did not see any detailed
discussion.

The documents make an excelent starting point but may not be complete for
all applications.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-May-86 10:27:42 EDT
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: 4.2bsd gateways

In response to the message sent  Tue, 20 May 86 15:33:51 edt from bruce@Think.Com 

Bruce,

Rather than trying to figure out what needs to be done to upgrade 4.2bsd
to an honest gateway, why not start with the requirements for such a beast
and work backwards? See RFC-985 for a first step in such a process.

Dave
-------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      22 May 86 16:16 PDT
From:      Tom Perrine <Perrine@LOGICON.ARPA>
To:        tcp-ip@sri-nic
Cc:        Perrine@logicon
Subject:   The Big Bug?
This is really a dumb question, prompted by the recent
comment about using ICMP redirects to tell local hosts
where to send things...

I get the impression that most (or at least, some) TCP/IP implementations
will accept a redirect from anyone. Is this true? If so...

What is to stop me (or Kevensky Gregory Breznhev) from sending a
redirect to every host on my net, i.e. MILNET, indicating (for example)
that they should send all of their ARPA traffic to me?

My host could then copy all of the packets and forward them to the
proper gateway. Talk about Big Brother, not to mention the performance
impact!

I am sure that I am missing something, this couldn't be true!

Tom

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 May 86 19:31 PDT
From:      Provan@LLL-MFE.ARPA
To:        Tcp-ip@nic.arpa
Subject:   re: the big bug?

what a happy coincident: i was just about to ask tcp-ip about this very
point when the subject suddenly popped up for me!

some implementations, the one i'm sending this from in fact, only
apply redirects to the particular connection they apply to.  for
example, a redirect for a host with multiple connections from here
will not cause any of the connections to change their route except
the one that actually sent the redirect packet.

on the other hand, i suspect there are sites that you could restrict
arpanet access for by sending a redirect and then not even bothering
to forward the packets.  it would probably take human intervention
in soem cases to get the routing entry out of the tables.
CC:     Perrine@LOGICON.ARPA,
	Tcp-ip@nic.arpa
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-May-86 19:16:00 EDT
From:      Perrine@LOGICON.ARPA (Tom Perrine)
To:        mod.protocols.tcp-ip
Subject:   The Big Bug?

This is really a dumb question, prompted by the recent
comment about using ICMP redirects to tell local hosts
where to send things...

I get the impression that most (or at least, some) TCP/IP implementations
will accept a redirect from anyone. Is this true? If so...

What is to stop me (or Kevensky Gregory Breznhev) from sending a
redirect to every host on my net, i.e. MILNET, indicating (for example)
that they should send all of their ARPA traffic to me?

My host could then copy all of the packets and forward them to the
proper gateway. Talk about Big Brother, not to mention the performance
impact!

I am sure that I am missing something, this couldn't be true!

Tom

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-May-86 22:31:00 EDT
From:      Provan@LLL-MFE.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: the big bug?


what a happy coincident: i was just about to ask tcp-ip about this very
point when the subject suddenly popped up for me!

some implementations, the one i'm sending this from in fact, only
apply redirects to the particular connection they apply to.  for
example, a redirect for a host with multiple connections from here
will not cause any of the connections to change their route except
the one that actually sent the redirect packet.

on the other hand, i suspect there are sites that you could restrict
arpanet access for by sending a redirect and then not even bothering
to forward the packets.  it would probably take human intervention
in soem cases to get the routing entry out of the tables.
CC:     Perrine@LOGICON.ARPA,
	Tcp-ip@nic.arpa

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-May-86 00:15:00 EDT
From:      dardy@NRL-CSS.ARPA (Hank Dardy)
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber-optic Ethernet Extender

We have been using the Digital DEREP fiber repeaters for close to two years
without problem.  The fiber has withstood both nature and man made electrical
surge (we have a plasma physics group next door).  Our installation has over
120 machines connected thru a "virtual" ethernet composed of broadband,
baseband and fiber.

Hank

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-May-86 00:37:43 EDT
From:      jdreyer@BBNCCV.ARPA (Jonathan Dreyer)
To:        mod.protocols.tcp-ip
Subject:   Re: The Big Bug?

I got good news or bad news, depending on the answer to this question:

What do hosts do when they are redirected via a "gateway" that is not
on their directly-connected net?

If hosts do the right thing, then most redirect pranksters won't get
very far.  In fact, it is hard to imagine what hosts could reasonably
do besides to ignore these bogograms (and maybe complain).

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      23 May 86 00:37:43 EDT (Fri)
From:      Jonathan Dreyer <jdreyer@BBNCCV.ARPA>
To:        tcp-ip@sri-nic.ARPA
Cc:        jdreyer@BBNCCV.ARPA
Subject:   Re: The Big Bug?
I got good news or bad news, depending on the answer to this question:

What do hosts do when they are redirected via a "gateway" that is not
on their directly-connected net?

If hosts do the right thing, then most redirect pranksters won't get
very far.  In fact, it is hard to imagine what hosts could reasonably
do besides to ignore these bogograms (and maybe complain).
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      23 May 86 09:08:00 PST
From:      <gary@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   IF-11Q/1822 for uVAXen
Those of you who have a need for supporting the 1822 protocol for
the uVAX, and have access to a LH-DH driver, can modify that
driver to work with the IF-11Q/1822.  The differences between the
two require driver changes in the way the system communicates with the
Control Status Registers. Those changes have been documented by Test
personnel here at ACC and are available.  For reference the interface
requires two dual slots in the backplane and will support either
a Distant Host or Local Host connection to the PSN.

Gary Krall

------
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-May-86 11:00:05 EDT
From:      MILLS@USC-ISID.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: The Big Bug?

In response to the message sent  22 May 86 16:16 PDT from Perrine@LOGICON.ARPA

Tom,

The ICMP redirect includes a copy of the IP header (plus a few bits) of the
IPgram that was received and forwarded at the gateway. Presumably, the host
receiving such a thing has the opportunity to determine its authenticity using
this information. Granted  this doesn't nab all the bogs, especially with
raw-datagram protocols, but it is much better than nothing at all. What this means
is that it's hard to send gratuitous redirects to reasonable implementations
that remember, at least for a little while, the address/route bindings recently
used.

Dave
-------

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      23 May 1986 11:00:05 EDT
From:      MILLS@USC-ISID.ARPA
To:        Perrine@LOGICON.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        MILLS@USC-ISID.ARPA
Subject:   Re: The Big Bug?
In response to the message sent  22 May 86 16:16 PDT from Perrine@LOGICON.ARPA

Tom,

The ICMP redirect includes a copy of the IP header (plus a few bits) of the
IPgram that was received and forwarded at the gateway. Presumably, the host
receiving such a thing has the opportunity to determine its authenticity using
this information. Granted  this doesn't nab all the bogs, especially with
raw-datagram protocols, but it is much better than nothing at all. What this means
is that it's hard to send gratuitous redirects to reasonable implementations
that remember, at least for a little while, the address/route bindings recently
used.

Dave
-------
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-May-86 13:08:00 EDT
From:      gary@ACC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   IF-11Q/1822 for uVAXen

Those of you who have a need for supporting the 1822 protocol for
the uVAX, and have access to a LH-DH driver, can modify that
driver to work with the IF-11Q/1822.  The differences between the
two require driver changes in the way the system communicates with the
Control Status Registers. Those changes have been documented by Test
personnel here at ACC and are available.  For reference the interface
requires two dual slots in the backplane and will support either
a Distant Host or Local Host connection to the PSN.

Gary Krall

------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-May-86 13:10:34 EDT
From:      gds@SRI-SPAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: The Big Bug?

> What do hosts do when they are redirected via a "gateway" that is not
> on their directly-connected net?

4.2 hosts running BBN TCP/IP ignore redirects from gateways which are
not on their directly attached net.  In addition, there is a notion of
the "connected set of gateways" which are allowed to send redirects to
the host.  It starts with the "default" gateway, installed by the system
manager.  The default gateway may redirect the host to another gateway
if there is a better route, and any other gateways put in the routing
tables from similar redirects may do likewise.  A gateway which has not
been "installed" from previous redirects cannot redirect the host -- in
fact the code is commented "Who are you, and why are you talking to us,
and how do we know the IP source is not a lie?"

--gregbo

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-May-86 15:41:00 EDT
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Postmaster Alert -- CISL-SERVICE-MULTICS.ARPA => MIT-MULTICS.ARPA

Yesterday, 22 May 1986, CISL-SERVICE-MULTICS.ARPA (10.3.0.31) went off
the air.  The Cambridge Information Systems Lab closed its doors today.

At some future time, probably in about 2 months, a new Multics will come
on the ARPAnet at a different Honeywell location in Billerica, MA.  The
name and address are not definitely known at this time.

For the moment, all mail intended for recipients at
CISL-SEREVICE-MULTICS.ARPA should be sent to MIT-MULTICS.ARPA (10.0.0.6)
instead.  This includes mail destined for other non-Internet sites which
uses CISL-DEVELOPMENT-MULTICS.ARPA as a gateway.  For example, Multics
users in Phoenix, AZ, receive mail as
User%PCO-MULTICS@CISL-DEVELOPMENT-MULTICS.ARPA.

To the best of our ability, all mail will be delivered by MIT-Multics to
the same parties as CISL-Service-Multics would have.  It is possible
that for the first few days some mail might be rejected, but it will not
be delivered to the wrong person.

The host table from SRI-NIC and the ARPA domain servers will be updated
soon to show all the names of CISL-SERVICE-MULTICS.ARPA as addnames on
MIT-MULTICS.ARPA.  However, this may not be accomplished until next week
some time, and that host table may take several days to be picked up by
the various hosts, so mail addressed to CISL-SERVICE-MULTICS will be
returned by mailers as undeliverable.

We apologize for the inconvenience.  If your host is known by you to
handle significant volume mail to CISL, please consider manually
updating your host table or patching your mailer queues.  Otherwise,
when asked what to do about returned mail, either advise your users of
the change or ask them to resend it after the domain server or local
host table have been updated.

We are concerned that subscribers not be dropped from digests because of
an essentially temporary outage.  Please feel free to forward this
message to any other mailing lists or parties who might be affected.

                    -- Spencer Love for Liaison@MIT-MULTICS.ARPA

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 May 86 07:47:30 EDT
From:      swb@tcgould.tn.cornell.edu (Scott Brim)
To:        leong@andrew.cmu.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Fiber-optic Ethernet Extender
John: American Photonics told me they could handle 50, 62.5 or 100
micron fiber -- and indeed sold me some RL5002s for 62.5 micron.
							Scott
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24-May-86 14:38:38 EDT
From:      tcp-ip-RELAY@SRI-NIC.ARPA,
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber-optic Ethernet Extender, Re: Fiber-optic Ethernet Extender

John: American Photonics told me they could handle 50, 62.5 or 100
micron fiber -- and indeed sold me some RL5002s for 62.5 micron.
							Scott

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      26 MAY 86 13:44-EDT
From:      1017263%MCMASTER.BITNET@WISCVM.WISC.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   A non-routing problem.
Here is a problem from the world of TCP/IP. Why does the Vax retransmit a
packet which has been acknowledged ? Also if the PC does window shrinking and
the window size becomes zero at the point of transmitting the character, the
retry time can be about 30 seconds.

The following is a true log of packets between the Vax and the PC. Only the
names have been changed to protect my innocence.

              From PC                           From Unix/Vax
           (Using BWTEL)

                                                Characters = 82
                                                Seq # = 207
                                                Ack # = 32
Characters = 0
Seq # = 32
Ack # = 289
                                                Characters = 82
                                                Seq # = 289
                                                Ack # = 32

*** Character transmitted before last packet processed

Characters = 1
Seq # = 32
Ack # = 289

                                                Characters = 0
                                                Seq # = 371
                                                Ack # = 33

This packet is in response to second to last packet, last packet not yet
processed.

Characters = 1 same character as above
Seq # = 32
Ack # = 371
                                                Characters = 0
                                                Seq # = 371
                                                Ack # = 33

                                                Characters = 82
        ***                                     Seq # = 289
                                                Ack # = 33

*** Why Does the Vax retransmit ???? ***

Characters = 0
Seq # = 33
Ack # = 371

                                                Characters = 82
                                                Seq # = 371
                                                Ack # = 33
Characters = 0
Seq # = 33
Ack # = 453


                - Carl Beame 1017263@MCMASTER.BITNET or
                             BEAME@MCMASTER.BITNET

P.S> Any comments or explanations are very welcome.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26-May-86 16:18:04 EDT
From:      1017263@MCMASTER.BITNET
To:        mod.protocols.tcp-ip
Subject:   A non-routing problem.

Here is a problem from the world of TCP/IP. Why does the Vax retransmit a
packet which has been acknowledged ? Also if the PC does window shrinking and
the window size becomes zero at the point of transmitting the character, the
retry time can be about 30 seconds.

The following is a true log of packets between the Vax and the PC. Only the
names have been changed to protect my innocence.

              From PC                           From Unix/Vax
           (Using BWTEL)

                                                Characters = 82
                                                Seq # = 207
                                                Ack # = 32
Characters = 0
Seq # = 32
Ack # = 289
                                                Characters = 82
                                                Seq # = 289
                                                Ack # = 32

*** Character transmitted before last packet processed

Characters = 1
Seq # = 32
Ack # = 289

                                                Characters = 0
                                                Seq # = 371
                                                Ack # = 33

This packet is in response to second to last packet, last packet not yet
processed.

Characters = 1 same character as above
Seq # = 32
Ack # = 371
                                                Characters = 0
                                                Seq # = 371
                                                Ack # = 33

                                                Characters = 82
        ***                                     Seq # = 289
                                                Ack # = 33

*** Why Does the Vax retransmit ???? ***

Characters = 0
Seq # = 33
Ack # = 371

                                                Characters = 82
                                                Seq # = 371
                                                Ack # = 33
Characters = 0
Seq # = 33
Ack # = 453


                - Carl Beame 1017263@MCMASTER.BITNET or
                             BEAME@MCMASTER.BITNET

P.S> Any comments or explanations are very welcome.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-May-86 05:37:00 EDT
From:      CERF@USC-ISI.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: A non-routing problem.


Aside from bugs, there are a couple of reasons for retransmissions (this
is a generic comment, not specific to the VAX code):




1.  timeout awaiting ACK leads to retransmissions

2. ACK fails to arrive at all (then see 1 above).


Do you know what the path was between the source/sink of this
TCP connection? Were there any long delay nets (e.g. SATNET)?
Network congestion? Overloaded gateways?

Vint Cerf

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      27 May 1986 05:37-EDT
From:      CERF@USC-ISI.ARPA
To:        1017263%MCMASTER.BITNET@WISCVM.WISC.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: A non-routing problem.

Aside from bugs, there are a couple of reasons for retransmissions (this
is a generic comment, not specific to the VAX code):




1.  timeout awaiting ACK leads to retransmissions

2. ACK fails to arrive at all (then see 1 above).


Do you know what the path was between the source/sink of this
TCP connection? Were there any long delay nets (e.g. SATNET)?
Network congestion? Overloaded gateways?

Vint Cerf
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      27 May 1986 09:18:27 PDT
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP/IP Vendors Workshop
The Internet Activities Board (IAB), in cooperation with DARPA, will
hold a TCP/IP Vendors Workshop from 25-27 August, 1986 in
Monterey, California.  The purpose of the workshop is to bring
together the designers of the TCP/IP protocol suite with the
implementors of those protocols in the commercial marketplace to go
over the meaning of the current protocols and planned future
extensions.  The workshop will begin with presentations by experts
from the research community on the current status of ARPANET and DDN's
MILNET, future directions of research, gateway issues, and on
migration to ISO standards.  Then the workshop will shift into a
series of sessions on specific topics (as listed below) that will
begin with a statement of known open issues on each topic followed by
questions from the implementors for each other or for the the experts.
Some sessions topics will undoubtedly need more time than others and
topics that have been left out will be accomodated as they arise.

Session Topics::

Specifications and Testing:  ULANA, Testing/Certification, Assigned
     Numbers, Official Protocols

Files:  FTP, TFTP

Mail:   SMTP, User Mail Agents, MMM, X.400.

Telnet:  Telnet, Telnet Options

Transactions:  Domain Names,  Remote Procedure Calls

Transport:  TCP, Retransmission, UDP

Network:  IP, ICMP, Fragmentation, Security, Precedence (TOS), Gateways
          (EGP, GGP, IGP), Routing, Subnetting

Data Link:   ARP, RARP, Address Mapping 

Physical: 1822, X.25, Ethernet, Token Ring, Token Bus, Satellite,
          Packet Radio

One of the results of the workshop will be an indication of the need
for further such workshops or perhaps some other format for exchanging
information amongst the multitude of participants in the TCP/IP arena.



The list that follows is comprised of companies that are believed to
be heavily involved with commercial products in the TCP/IP
marketplace.

To obtain an invitation to this workshop please contact the Workshop
Chair, Dan Lynch.  I may be reached at Lynch@USC-ISIB.ARPA or at
408-996-2042.  We plan on having two attendees from each company (or
separate divisions in some cases) and want to have attendees who are
prepared to discuss in detail their implementation problems and
suggestions for solutions.  If you know of companies that are missing from
this list please let me know of them.  If you are a customer of commercial
TCP/IP products and would like to make sure that your Vendor(s)
participate in this workshop please let them know how much you care.


ACC, Alliant, Amdahl, Apple, Applitek, Apollo, AT&T, BBN, BDM, Bridge,
Burroughs, CDC, Cisco, Computer Network Technology, CMC, Convergent,
Convex, Cray, CSC, Data General, Datapoint, DEC, Encore, Elxsi,
Excelan, Ford Aerospace, Fortune, Frontier Technologies, FTP Inc.,
Gould, Honeywell, HP, IBM, Imagen, Intel, Interlan (Micom), Internet
Systems Corp., Kinetics, LMI, Locus, Mitre, NCR, Network Research
(Oxnard), Network Research (Salt Lake), Network Solutions, NSC,
Panda Programming, Perkin-Elmer (now called Concurrent Computing),
Plexus, Prime, Process Software, Proteon, Pyramid, QMI, Ridge, SAI,
Scope, SDC, Softsel, Spartacus, Sperry, SRI, Sun, Symbolics, Sytek,
Tandem, Tektronix, TI, 3Com, Ungermann-Bass, Uniq, Unisoft, Vitalink,
Wollongong, Xerox.

-------
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-May-86 12:18:27 EDT
From:      LYNCH@USC-ISIB.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP Vendors Workshop

The Internet Activities Board (IAB), in cooperation with DARPA, will
hold a TCP/IP Vendors Workshop from 25-27 August, 1986 in
Monterey, California.  The purpose of the workshop is to bring
together the designers of the TCP/IP protocol suite with the
implementors of those protocols in the commercial marketplace to go
over the meaning of the current protocols and planned future
extensions.  The workshop will begin with presentations by experts
from the research community on the current status of ARPANET and DDN's
MILNET, future directions of research, gateway issues, and on
migration to ISO standards.  Then the workshop will shift into a
series of sessions on specific topics (as listed below) that will
begin with a statement of known open issues on each topic followed by
questions from the implementors for each other or for the the experts.
Some sessions topics will undoubtedly need more time than others and
topics that have been left out will be accomodated as they arise.

Session Topics::

Specifications and Testing:  ULANA, Testing/Certification, Assigned
     Numbers, Official Protocols

Files:  FTP, TFTP

Mail:   SMTP, User Mail Agents, MMM, X.400.

Telnet:  Telnet, Telnet Options

Transactions:  Domain Names,  Remote Procedure Calls

Transport:  TCP, Retransmission, UDP

Network:  IP, ICMP, Fragmentation, Security, Precedence (TOS), Gateways
          (EGP, GGP, IGP), Routing, Subnetting

Data Link:   ARP, RARP, Address Mapping 

Physical: 1822, X.25, Ethernet, Token Ring, Token Bus, Satellite,
          Packet Radio

One of the results of the workshop will be an indication of the need
for further such workshops or perhaps some other format for exchanging
information amongst the multitude of participants in the TCP/IP arena.



The list that follows is comprised of companies that are believed to
be heavily involved with commercial products in the TCP/IP
marketplace.

To obtain an invitation to this workshop please contact the Workshop
Chair, Dan Lynch.  I may be reached at Lynch@USC-ISIB.ARPA or at
408-996-2042.  We plan on having two attendees from each company (or
separate divisions in some cases) and want to have attendees who are
prepared to discuss in detail their implementation problems and
suggestions for solutions.  If you know of companies that are missing from
this list please let me know of them.  If you are a customer of commercial
TCP/IP products and would like to make sure that your Vendor(s)
participate in this workshop please let them know how much you care.


ACC, Alliant, Amdahl, Apple, Applitek, Apollo, AT&T, BBN, BDM, Bridge,
Burroughs, CDC, Cisco, Computer Network Technology, CMC, Convergent,
Convex, Cray, CSC, Data General, Datapoint, DEC, Encore, Elxsi,
Excelan, Ford Aerospace, Fortune, Frontier Technologies, FTP Inc.,
Gould, Honeywell, HP, IBM, Imagen, Intel, Interlan (Micom), Internet
Systems Corp., Kinetics, LMI, Locus, Mitre, NCR, Network Research
(Oxnard), Network Research (Salt Lake), Network Solutions, NSC,
Panda Programming, Perkin-Elmer (now called Concurrent Computing),
Plexus, Prime, Process Software, Proteon, Pyramid, QMI, Ridge, SAI,
Scope, SDC, Softsel, Spartacus, Sperry, SRI, Sun, Symbolics, Sytek,
Tandem, Tektronix, TI, 3Com, Ungermann-Bass, Uniq, Unisoft, Vitalink,
Wollongong, Xerox.

-------

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-May-86 13:31:20 EDT
From:      braden@ISI-BRADEN.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  TCP/IP Vendors Workshop

Dan,

I don't understand the inclusion of a generic topic "Transactions" or
a specific topic "Remote Procedure Call".  There is no current or proposed
Internet standard in that area... it is being treated as a (quasi-)
research topic, which will hopefully lead to a proposed standard at some
future time.  

The domain system deserves to have a major topic all to itself.

Bob Braden

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Tue 27 May 86 16:53:11-PDT
From:      "Joel Goldberger" <JOEL@isi-venera.arpa>
To:        Margulies@scrc-yukon.arpa
Cc:        JOEL%isi-venera.arpa@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa, Joseph@scrc-yukon.arpa, ALNeches%isi-venera.arpa@mc.lcs.mit.edu, Action%USC-ISID.ARPA@mc.lcs.mit.edu, Joel@isi-venera.arpa
Subject:   Re: {8605.0428} oh mr. postman ...
The rejection you are getting is from our SMTP receiver, which (like most
mailers) does not parse either the headers or the text of the message.  It
responds only to the SMTP control lines to form both the return-path line
and the received: line.  It doesn't like the host specification in the
MAIL FROM:<...> SMTP control line.  It doesn't care what is sent after
the DATA SMTP control line (which is where the "Reply-To: " line is).
There are no hard rules on this and our implementation chooses to reject
mail where the only host specified is unknown.  UNIX is not so rigorous,
it will accept mail from (or for) any host whether it exists or not, and
will then have no way of informing anyone but the mail system maintainer
that there is a problem.  We like the TOPS-20 system better where the
originator has to resolve the problem.

- Joel -
-------
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-May-86 18:37:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   {8605.0428} oh mr. postman ...


    Date: Tue 27 May 86 14:59:42-PDT
    From: "Joel Goldberger" <JOEL@isi-venera.arpa>

    Benson,

    I have been asked to help with your question about our mailers rejection
    of messages from you.  The message you sent to Postmaster claimed a from
    address of Margulies@SCRC-YUKON.ARPA, but this host didn't appear
    anywhere in the Received lines.  The only hosts in that line are:

    REDWING.SCRC.Symbolics.com
    SAPSUCKER.SCRC.Symbolics.com
    MC.LCS.MIT.EDU

    Our domain resolvers are unable to find any record for the first two of
    these hosts.  SCRC-YUKON.ARPA is in both the domain and NIC databases.
    Our TOPS-20 mailers will not accept mail from hosts they cannot resolve.
    Currently our TOPS-20 systems use the NIC table for all lookups, but in
    this case a domain based system would not have helped either.

    You should try to get your mailer to supply at least some honest data
    concerning the route of outgoing mail.

I think that this is reasonable information.  The message says on its
face: Reply to me by sending to SCRC-YUKON.ARPA. YUKON is a legitimate,
visible host. 

Using the delivery history is flawed.  Just because a given chain of
machines participated in getting a message out, dosen't mean that it is
an appropriate return route.

I can sympathize with wanting to toss mail that can't be replied to.
However, the restriction should be that mail is returned if none of the
return-path, the sender, the reply-to or the from address could be
resolved, not if any of them failed to resolve.

Furthermore, just because you cannot parse it now, dosen't mean you
won't be able to later. Surely you have noticed the rather low
availability of most of the domain servers.

(as an aside: as a user, I often know more about mail topology than
 computers, because of the incredibly poor behavior of the domain system
[no zone transfers, etc.]  Thus, I would prefer to receive this kind of
mail rather than haveing the SMTP server do me the favor of dropping it
on the ground].

REDWING is my personal machine, which does not offer SMTP, because it
has no file system.  SAPSUCKER is an internal mail transfer node, used
to share outgoing mail load.  Yukon is the one and only appropriate
place to send me mail, and that's why its in the from line.

I have no control over the delivery history.  I can't `put something
reasonable in it', because it is accumulated as the message goes along.
I believe that the protocol states that its purpose is informational,
not prescriptive.

Even if SAPSUCKER and REDWING were in the host databases, using the
return path to return the mail would fail.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-May-86 19:53:11 EDT
From:      JOEL@ISI-VENERA.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: {8605.0428} oh mr. postman ...

The rejection you are getting is from our SMTP receiver, which (like most
mailers) does not parse either the headers or the text of the message.  It
responds only to the SMTP control lines to form both the return-path line
and the received: line.  It doesn't like the host specification in the
MAIL FROM:<...> SMTP control line.  It doesn't care what is sent after
the DATA SMTP control line (which is where the "Reply-To: " line is).
There are no hard rules on this and our implementation chooses to reject
mail where the only host specified is unknown.  UNIX is not so rigorous,
it will accept mail from (or for) any host whether it exists or not, and
will then have no way of informing anyone but the mail system maintainer
that there is a problem.  We like the TOPS-20 system better where the
originator has to resolve the problem.

- Joel -
-------

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-May-86 22:03:12 EDT
From:      MRC@SIMTEL20.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: {8605.0428} oh mr. postman ...

Joel -

     ISI's SMTP receiver is, as far as I can tell, unique to ISI.  The
standard TOPS-20 SMTP receiver is my MAISER, which does not validate
the host names in MAIL FROM:<...> SMTP commands.  The reason it does
not validate the host names in the MAIL FROM is that if it did my
friends at the NIC would not be able to receive HOSTMASTER mail of
the form "Hi, this is FOOBAR, we just got on the net, please add us to
the host table"!!!!

     Since the MAIL FROM host names are only used by the mailer to
return failed mail, this isn't a big deal.  Failed messages that can't
be returned end up in the dead letter mailbox (typically POSTMASTER but
not necessarily), where a human can decide whether to keep or toss it
out.

     I ask you not to confuse the two SMTP servers, and I urge the ISI
system management to give serious consideration towards adopting the
standard SMTP server or at least to implement its willingness to accept
mail in spite of possibly bogus return paths.

-- Mark --
-------

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      28 May 1986 01:04-PDT
From:      Dale Chase <Chase@USC-ISIB>
To:        MRC@SIMTEL20.ARPA
Cc:        JOEL@ISI-VENERA.ARPA, Margulies@SCRC-YUKON.ARPA TCP-IP@SRI-NIC.ARPA, Joseph@SCRC-YUKON.ARPA Action@USC-ISID.ARPA
Subject:   Re: {8605.0428} oh mr. postman ...
I think the NIC (and probably domain registries) has a unique need to accept
mail from unknown hosts, which doesn't apply to hosts in general.  The problem
with blithely accepting mail with unknown hostnames in the MAIL FROM:<...>
control line is that the server is accepting responsibility to either deliver
the mail or return a negative acknowledgement.  If such a piece of mail turns
out to be undeliverable, it does indeed go to the dead letter mailbox.

At this point, if the postmaster is good and the phase of the moon is right,
the mail will either be forwarded to the intended recipient or returned to the
originator.  But if the adresses are sufficiently esoteric, the mail just gets
dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task
was flushing the dead letter mailbox to keep it from overflowing.  I wouldn't
be surprised if this still happens in some places).  And the sender is left
wondering why he didn't get an answer to his urgent request.

As Joel said, we prefer the originator be notified of the potential problem
immediately so it can be straightened out.  In this manner, problem resolution
is pushed to the most local point possible relative to problem's source.  In
other words, the user or administrator at site XX is more likely to know that a
piece of mail from mumble@frob should really be mumble%frob@XX.

<>Dale
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-May-86 01:10:11 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        mod.protocols.tcp-ip
Subject:   Re: {8605.0428} oh mr. postman ...

I would like to second Mark's request to ISI to consider checking out their
SMTP mailer software.  I don't remember what the exact problem was offhand
right now, but I remember we had trouble talking to their mailer, and vice
versa.  I *think* it had something to do with what I believe was some
nonstandard SMTP dialog.  /Ken
-------

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-May-86 04:04:00 EDT
From:      Chase@USC-ISIB (Dale Chase)
To:        mod.protocols.tcp-ip
Subject:   Re: {8605.0428} oh mr. postman ...

I think the NIC (and probably domain registries) has a unique need to accept
mail from unknown hosts, which doesn't apply to hosts in general.  The problem
with blithely accepting mail with unknown hostnames in the MAIL FROM:<...>
control line is that the server is accepting responsibility to either deliver
the mail or return a negative acknowledgement.  If such a piece of mail turns
out to be undeliverable, it does indeed go to the dead letter mailbox.

At this point, if the postmaster is good and the phase of the moon is right,
the mail will either be forwarded to the intended recipient or returned to the
originator.  But if the adresses are sufficiently esoteric, the mail just gets
dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task
was flushing the dead letter mailbox to keep it from overflowing.  I wouldn't
be surprised if this still happens in some places).  And the sender is left
wondering why he didn't get an answer to his urgent request.

As Joel said, we prefer the originator be notified of the potential problem
immediately so it can be straightened out.  In this manner, problem resolution
is pushed to the most local point possible relative to problem's source.  In
other words, the user or administrator at site XX is more likely to know that a
piece of mail from mumble@frob should really be mumble%frob@XX.

<>Dale

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 May 86 09:33:00 -0400
From:      Craig Partridge <craig@loki.bbn.com>
To:        joel@isi-venera.arpa
Cc:        tcp-ip@sri-nic.arpa, margulies@scrc-yukon.arpa
Subject:   SMTP receiver rejections

> There are no hard rules on this and our implementation chooses to reject
> mail where the only host specified is unknown.  UNIX is not so rigorous,
> it will accept mail from (or for) any host whether it exists or not, and
> will then have no way of informing anyone but the mail system maintainer
> that there is a problem.  We like the TOPS-20 system better where the
> originator has to resolve the problem.

Joel,

    I generally agree with the goal but do want to point out that our
experience at CSNET is that, more often than not, the problem is not the
originator's but that of the receiving mail system, which either has
out of date host tables (presumably under domains this problem will become
one of having a defective or ill-informed nameserver) or some configurational
error which causes it to reject the message.

Craig Partridge
CSNET Technical Staff
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-May-86 07:42:00 EDT
From:      Margulies@SCRC-YUKON.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: {8605.0428} oh mr. postman ...


    Date: 28 May 1986 01:04-PDT
    From: Dale Chase <Chase@USC-ISIB>

    I think the NIC (and probably domain registries) has a unique need to accept
    mail from unknown hosts, which doesn't apply to hosts in general.  The problem
    with blithely accepting mail with unknown hostnames in the MAIL FROM:<...>
    control line is that the server is accepting responsibility to either deliver
    the mail or return a negative acknowledgement.  If such a piece of mail turns
    out to be undeliverable, it does indeed go to the dead letter mailbox.

    At this point, if the postmaster is good and the phase of the moon is right,
    the mail will either be forwarded to the intended recipient or returned to the
    originator.  But if the adresses are sufficiently esoteric, the mail just gets
    dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task
    was flushing the dead letter mailbox to keep it from overflowing.  I wouldn't
    be surprised if this still happens in some places).  And the sender is left
    wondering why he didn't get an answer to his urgent request.

    As Joel said, we prefer the originator be notified of the potential problem
    immediately so it can be straightened out.  In this manner, problem resolution
    is pushed to the most local point possible relative to problem's source.  In
    other words, the user or administrator at site XX is more likely to know that a
    piece of mail from mumble@frob should really be mumble%frob@XX.

    <>Dale

1)

As I have pointed out before, the resolvability of an address varies
with time and the domain system.  It is never appropriate to ask the
question: is this a valid address? and reject because it cannot be
domain resolved right now.

2)

In-Reply-To and From are in that SMTP spec for a reason, so that mail
sending agents can tell mail reading agents how to reply.  Mail
transmission agents should just follow orders and stay out of the way.

Having the SMTP server 'validate' MAIL FROM is a confusion in protocol
levels.  Personally, I think that MAIL FROM was a bad idea altogether,
for this reason.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 May 86 07:43 EDT
From:      Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>
To:        Dale Chase <Chase%USC-ISIB.ARPA@MIT-MC.ARPA>, MRC@SIMTEL20.ARPA
Cc:        JOEL%ISI-VENERA.ARPA@MIT-MC.ARPA, TCP-IP@SRI-NIC.ARPA, Joseph@SCRC-YUKON.ARPA, Action%USC-ISID.ARPA@MIT-MC.ARPA
Subject:   Re: {8605.0428} oh mr. postman ...
    Date: 28 May 1986 01:04-PDT
    From: Dale Chase <Chase@USC-ISIB>

    I think the NIC (and probably domain registries) has a unique need to accept
    mail from unknown hosts, which doesn't apply to hosts in general.  The problem
    with blithely accepting mail with unknown hostnames in the MAIL FROM:<...>
    control line is that the server is accepting responsibility to either deliver
    the mail or return a negative acknowledgement.  If such a piece of mail turns
    out to be undeliverable, it does indeed go to the dead letter mailbox.

    At this point, if the postmaster is good and the phase of the moon is right,
    the mail will either be forwarded to the intended recipient or returned to the
    originator.  But if the adresses are sufficiently esoteric, the mail just gets
    dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task
    was flushing the dead letter mailbox to keep it from overflowing.  I wouldn't
    be surprised if this still happens in some places).  And the sender is left
    wondering why he didn't get an answer to his urgent request.

    As Joel said, we prefer the originator be notified of the potential problem
    immediately so it can be straightened out.  In this manner, problem resolution
    is pushed to the most local point possible relative to problem's source.  In
    other words, the user or administrator at site XX is more likely to know that a
    piece of mail from mumble@frob should really be mumble%frob@XX.

    <>Dale

1)

As I have pointed out before, the resolvability of an address varies
with time and the domain system.  It is never appropriate to ask the
question: is this a valid address? and reject because it cannot be
domain resolved right now.

2)

In-Reply-To and From are in that SMTP spec for a reason, so that mail
sending agents can tell mail reading agents how to reply.  Mail
transmission agents should just follow orders and stay out of the way.

Having the SMTP server 'validate' MAIL FROM is a confusion in protocol
levels.  Personally, I think that MAIL FROM was a bad idea altogether,
for this reason.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-May-86 10:47:55 EDT
From:      oconnor@TRANTOR.UMD.EDU (Mike O'Connor)
To:        mod.protocols.tcp-ip
Subject:   Symbolics TCP/IP

Does anyone have any comments or caveats concerning the TCP/IP package
marketed by Symbolics?

			Thanks,
				Mike

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 May 86 15:54:49 -0500
From:      Craig Partridge <craig@SH.CS.NET>
To:        mmdf2@relay.CS.NET, tcp-ip@sri-nic.ARPA
Subject:   Adaptive SMTP Timeouts

    I've noticed that a lot of mailers use timeouts on some or
all SMTP commands, to make sure that a defective remote mailer doesn't
cause the other mailer to hang permanently waiting for a reply.  All the
code I have seen uses a fixed timeout period.  For example, you always
have 30 seconds to reply to a HELO, or some such.

    It has occurred to me that it might make more sense for such mailers
to adapt their timeouts to perceived performance at the remote end.
For example, I've seen 10-15 second packet round trip times on parts
of the Internet.  In such a situation, a 30 second timeout is actually
a 15 second timeout for the other mailer.

    One idea for adapting timeouts is to "ping" the other end of the
SMTP link with a NOOP command every so often to find out the round
trip time, and also get some vague sense of the remote machine's
load (since it must actually recognize the NOOP and compose a reply).
Another is to simply do one test at the start of the interaction,
using the HELO command as the benchmark.

    What do other people think of this idea?.  Anyone got other
interesting ways to adjust the timeouts?  We're serioiusly considering
putting this feature into MMDF2b.

Craig Partridge
CSNET Technical Staff
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-May-86 15:02:04 EDT
From:      craig@LOKI.BBN.COM (Craig Partridge)
To:        mod.protocols.tcp-ip
Subject:   SMTP receiver rejections


> There are no hard rules on this and our implementation chooses to reject
> mail where the only host specified is unknown.  UNIX is not so rigorous,
> it will accept mail from (or for) any host whether it exists or not, and
> will then have no way of informing anyone but the mail system maintainer
> that there is a problem.  We like the TOPS-20 system better where the
> originator has to resolve the problem.

Joel,

    I generally agree with the goal but do want to point out that our
experience at CSNET is that, more often than not, the problem is not the
originator's but that of the receiving mail system, which either has
out of date host tables (presumably under domains this problem will become
one of having a defective or ill-informed nameserver) or some configurational
error which causes it to reject the message.

Craig Partridge
CSNET Technical Staff

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-May-86 17:23:07 EDT
From:      craig@SH.CS.NET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Adaptive SMTP Timeouts


    I've noticed that a lot of mailers use timeouts on some or
all SMTP commands, to make sure that a defective remote mailer doesn't
cause the other mailer to hang permanently waiting for a reply.  All the
code I have seen uses a fixed timeout period.  For example, you always
have 30 seconds to reply to a HELO, or some such.

    It has occurred to me that it might make more sense for such mailers
to adapt their timeouts to perceived performance at the remote end.
For example, I've seen 10-15 second packet round trip times on parts
of the Internet.  In such a situation, a 30 second timeout is actually
a 15 second timeout for the other mailer.

    One idea for adapting timeouts is to "ping" the other end of the
SMTP link with a NOOP command every so often to find out the round
trip time, and also get some vague sense of the remote machine's
load (since it must actually recognize the NOOP and compose a reply).
Another is to simply do one test at the start of the interaction,
using the HELO command as the benchmark.

    What do other people think of this idea?.  Anyone got other
interesting ways to adjust the timeouts?  We're serioiusly considering
putting this feature into MMDF2b.

Craig Partridge
CSNET Technical Staff

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      29 May 1986 2:48-PDT
From:      Steve Deering <deering@su-pescadero.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   time-to-live
Please excuse me if this has all been discussed to death in the past,
but I'm seeking the answers to the following two questions:

  (1) Do any existing host or gateway implementations of IP ever decrement
      the time-to-live field of a IP datagram by more than 1?  I.e., does
      anyone actually check for datagram holding times of more than one
      second and adjust TTL accordingly?

  (2) The IP spec (RFC791) says "...every module that processes a
      datagram must decrease the TTL by at least one...".  Is this
      normally interpreted as including the originating host IP
      module and/or the final destination host IP module?

							-- Steve Deering
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 05:48:00 EDT
From:      deering@SU-PESCADERO.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   time-to-live

Please excuse me if this has all been discussed to death in the past,
but I'm seeking the answers to the following two questions:

  (1) Do any existing host or gateway implementations of IP ever decrement
      the time-to-live field of a IP datagram by more than 1?  I.e., does
      anyone actually check for datagram holding times of more than one
      second and adjust TTL accordingly?

  (2) The IP spec (RFC791) says "...every module that processes a
      datagram must decrease the TTL by at least one...".  Is this
      normally interpreted as including the originating host IP
      module and/or the final destination host IP module?

							-- Steve Deering

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 08:52:00 EDT
From:      dpk@mcvax.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts

Sounds cute, but is it really necessary.  In all cases there should be
a reasonable MAXIMUM hardcoded in.  I thought the times I put in were
reasonable.  If not we have to ask should be really be talking to
a host whose round trip time is 15 seconds.  My suspicion is that the
answer might be no.  For example, no reply to a HELO after one minute
is ridiculous.  Sounds like a lot of work to get right and not necessarily
foolproof.  If you get a really fast HELO response, ar you going to reduce
the time on RCPT replies too much (if it needs mucho expansion)?  Its very
hard to get right in all cases.  It may be easier to be able to state
difinitively what the values are for all cases.  Consider them specs for
performance.  You need hardcoded minimums and maximums in any case.

-Doug-

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 09:56:00 EDT
From:      CLYNN@A.BBN.COM
To:        mod.protocols.tcp-ip
Subject:   Re: time-to-live

Steve,
	The TOPS-20 IP implementation does decrement the Time-to-live
field by more than one if the packet has been queued for more than a
second.  Note however, that this doesn't really apply to the major
source of output-queue delay which is in the layer(s) below IP.  The
timeout for received fragments is set from the time-to-live field, but
any additional fragment which is received will reset the timeout to
allow fragments from different retransmissions to be combined.

	The TOPS20 always decrements the Time-to-live, even when it is
the originating or receiving host (since the systems support multiple
network interfaces and will typically forward packets, route loops could
theoretically occur).  When a packet is received with a Time-to-live
of 1, the packet will be delivered to the higher layers, but not forwarded.

Charles Lynn

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 14:02:15 EDT
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts

In response to the message sent  Thu, 29 May 86 12:15:38 +0100 from mcvax!dpk@seismo.CSS.GOV

Doug,

I commonly see delays of up to a minute for replies to SMTP commands
with MIT-MULTICS and up to two minutes for certain FORD-WDL hosts. This,
however, bogs the question, since delays of this magnitude would be considered
prima facie evidence of brain lesions by almost everybody except their
maintainers. On the other hand, premature abandonment of an SMTP connection
may be hazardous to the mental health of the recipients. In a recent case
when our local 4.2bsd prematurely abandoned an SMTP connection and repeatedly
tried it again hour after hour, the recipient got a (truncated) copy of the
message every time. After three days he became quite violent.

I think SMTP adaptive timeouts, while cute and possibly even useful in some
cases, should not be used to "tune" connections, but to ensure system
resources are returned to service when something hangs. They should be set
quite long - in the order of several minutes. The present situation clearly
indicates some implementations are broken and should be fixed. Having
said that, it also is clear that the error-recovery characteristics of
many mailers and femailers could be much improved.

Dave
-------

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 17:13:22 EDT
From:      garry@TCGOULD.TN.CORNELL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: {8605.0428} oh mr. postman ...

Why not send a rejection (actually a warning) AND forward the message?

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 21:28:00 EDT
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts


Doug,

In the complex internet environment, round-trip variations can be significant,
depending on the paths taken, the satellite hops, congestion, various failures,
and so on. Under jamming conditions, bandwidths drop to increase S/N and also
increase delays (unfortunately). At least with respect to DoD objectives,
the system has to work even if its parameters exceed the nominally desired
limits. Consequently, many of us have been reluctant to rely on any fixed
maxima if we can find ways to measure and adapt instead.

I don't disagree that it would be easier to declare some maximum and in some
instances (e.g. the 576 octet IP packet size which all subsystems must carry
without fragmentation) we have done so. But with respect to dynamic parameters
such as round-trip time, we have tried hard not to allow ourselves to be
bequiled by the apparent simplicity of declared limits.

There may well be some other dissenting opinions on this point out there in
the diverse world which makes up this interest group, but I believe I am
stating the principal view of those of us concerned for DoD requirements.

Vint

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-May-86 23:39:28 EDT
From:      dcf@COMET.LCS.MIT.EDU (David C. Feldmeier)
To:        mod.protocols.tcp-ip
Subject:   Avalanche

I am doing measurements of the interpacket arrival times for the gateways on
a 10 Mbit token ring at MIT, especially our gateway to the ARPANET because
it carries the most traffic.  While doing these measurements, I noticed that
about 35% of the packets arriving at the gateway were only 300 microseconds
after the previous packet.  Since this is faster than the gateway receives
or a single host transmits, I was curious about what was causing it.

The problem turned out to be with the 30 VAXs on the ring that run Berkeley
4.2 Unix.  A gateway would send a routing packet to the broadcast address
and all of the VAXs would not recognize the destination address and forward
the packet to the default gateway, which is the gateway to the ARPANET.  As
soon as the broadcast packet was transmitted, all of the VAXs would
simultaneously begin forwarding packets to the gateway as quickly as
possible until they got through.  The token ring has a data link layer
packet acknowledgment, so the VAXs would simply continue in order around the
ring with successful host dropping out.  Eventually, all would succeed
(about 0.13 seconds) and the net would return to normal.  The interarrival
time of 300 microseconds is because the transmission time of the routing
packet is 300 microseconds.  The ring was 100% loaded with back-to-back
packets for the entire 0.13 seconds.  I suspect that on an Ethernet, this
would be a bigger mess because of the multiple collisions.

					-Dave Feldmeier

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-May-86 04:52:38 EDT
From:      MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP Vendors Workshop

Hi -

     You can include Panda Programming as being interested in
attending this workshop.  Our stuff is mostly applications (esp.
mail), and we're *very* interested in the X.400 issues, etc.
We're also interested in gateway issues and the threatened
migration from TCP to TP4.

-- Mark --
-------

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      30 May 1986 10:21:33 PDT
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        Mark Crispin <MRC%PANDA@SUMEX-AIM.ARPA>
Cc:        LYNCH@USC-ISIB.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP/IP Vendors Workshop

Great, Mark.  You'll get a packet in about a month.

Thanks,
Dan
-------
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-May-86 13:21:33 EDT
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP Vendors Workshop


Great, Mark.  You'll get a packet in about a month.

Thanks,
Dan
-------

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 00:27:23 EDT
From:      dpk@mcvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts

For systems that don't have large quantities of mail I have no complaint
with large timeouts, but one systems like CSNET-RELAY and BRL which have
to
process hundreds or thousands of messages a day, waiting minutes can
quite a delay if the number of "slow hosts" becomes more than a few.
We already have to run 3-4 channels at BRL just to get them mail we
have sent.  Thinks a 'bout it.  It's not an issue I feel strongly
enough about to push further, but I want people to think about it.

-Doug-

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 00:36:00 EDT
From:      james@CLS.LCS.MIT.EDU (James W. O'Toole Jr.)
To:        mod.protocols.tcp-ip
Subject:   Re: Avalanche


	From: dcf@comet.lcs.mit.edu (David C. Feldmeier)
	Subject: Avalanche

	I suspect that on an Ethernet, this would be a bigger mess
	because of the multiple collisions.

I wouldn't expect multiple collisions, just one: then the ``randomness''
in the backoff times ought to break the symmetry.  This is an interesting
way to get collisions though.  Usually the biggest cause of Ethernet
collisions is the transmission of a long packet.  If two other hosts
become ready to transmit during that time, they will both begin
transmitting shortly after the long packet's end.

Curious, the gateway's broadcast acts as a synchronizing event, so that
the independent transmission times assumption fails.

  --Jim

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 01:29:33 EDT
From:      dpk@mcvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts

I am aware of DOD operational requirements, as you know.

I also have been responsible for real service at a large mail
host that essentially talked to every Internet host at the time.

My opinions come from this background.  While arbitrary limits
are to be avoided, there are certain cases when a decision which
may help you in a few cases (say a 5 minute response time) can
tie up significant resources at other times when a more reasonable
timeout would be say 30 seconds.  If you can classify hosts or
users in one group or the other fine, you can have different
classes of response times.  But if preclassification is not
possible, you have to be careful you don't create more problem
that solution.  We have had times at BRL when we could not
get rid of the mail as fast as it was coming in until we ran
seven outbound mail processes simultaneously (with what are now
believed to be too short time intervals).  Think about it.  Novel
solutions welcome, but waiting forever is not practical.

-Doug-

PS.  We didn't start out with timeouts, they were added for a reason.

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 05:20:08 EDT
From:      BILLW@SU-SCORE.ARPA (William "Chops" Westfield)
To:        mod.protocols.tcp-ip
Subject:   Avalanche

Im pretty sure that I've seen thi problem discussed before -
I think as a way to trash microvaxes (somebody sends out
an rwhod broadcast packet to the correct (all 1's) address.
N Sun workstations think that the broadcast address address
ought to be 0, and that the -1 address packet needs to be
forwarded (which they all do).  the resulting massive and
lengthy collision seems to break the DEQNA...)

This is the major reason why it is suggested that ip forwarding
be turned off on all unixes that aren't actually gateways...

BillW
-------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 08:52:00 EDT
From:      CERF@USC-ISI.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Adaptive SMTP Timeouts

Doug,

these are good points. The line of reasoning which says that timeouts that
are too long result in poor resource utilization is on good grounds - the
problem I had with an arbitrary maximum is that under some extreme conditions,
no service might be provided at all - the usual effect of timeouts that
are too short.

Vint

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 15:11:55 EDT
From:      MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   Don't throw out your "Internet Mail Protocols"!


     The NIC has confirmed that RFC 822 was inadvertantly left out
of the glossy three-volume DDN Protocol Handbook set.  I haven't
checked to make sure that the other volumes of the old protocol
books are in fact really obsoleted, but considering how important
RFC 822 is I would be very careful in throwing out any old documents.

     Sigh.  It's a shame that happened, because otherwise the glossy
set is quite a good idea.  Is the NIC planning upon more frequent
revisions?

-- Mark --
-------

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-May-86 18:11:40 EDT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        mod.protocols.tcp-ip
Subject:   Re:  Avalanche

Indeed, it seems to me that IP forwarding should default to `off'
on most Unix machines.  It also makes sense to disable it if the
machine has only one IP interface; this is what 4.3 does.

For anyone who has not already done it, IP forwarding may be
turned off as follows:

	1) binary-only:
	   The first write turns it off in the running kernel; the
	   second turns it off in the boot image.
		% su
		[password]
		# adb -w /vmunix /dev/kmem
		ipforwarding/W 0
		ipforwarding:	1 =	0
		ipforwarding?W 0
		ipforwarding:	1 =	0
		[type ^D here]

	2) source:
	   Find the declaration of `ipforwarding' in
	   /sys/netinet/ip_input.c; change it to be initialised to zero.

Chris

END OF DOCUMENT