The 'Security Digest' Archives (TM)

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

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


Date:      3 Aug 84 1201 EDT (Friday)
From:      don.provan@CMU-CS-A.ARPA
To:        info-nets@MIT-MC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   OSI
I'm not sure info-nets is the proper forum for this, but does anyone
know how ISO and NBS are getting along with the OSI?  Is there any kind
of ground swell of support for using it?  I'm reading a lot of articles
about it, but they all date from '82.  My impression from these articles
is that it's being designed using political negotiations and compromise,
something that usually leads to something noone wants to use.
Date:      3 Aug 1984 1547 PDT
From:      Eric P. Scott <EPS@JPL-VLSI.ARPA>
Subject:   IP on Ungermann-Bass Net/One
Greetings, standards-lovers!  Recently a number of RFCs have been
issued specifying standards for implementing Internet protocols
on Ethernet(-like) networks.  I am in need of such a standard for
Net/One (registered trademark of Ungermann-Bass, Inc.).

Net/One Network Interface Units (NIUs) can provide two services
of interest to us, Ethernet Data Link Service (EDLS), and Net/One
Datagram Service (SDS).  EDLS is fully Ethernet compatible (i.e.
"this problem has already been solved").  SDS (an "ethernoid")
is capable of sending datagrams across Net/One Bridges.  Bridges
connect Net/One Networks (Ethernet segment, Broadband channel-
pair, etc.).  SDS provides the interface to Net/One protocols
that handle routing, etc. as well as actual delivery.  This
option is considered cost-effective (less IP networks, less IP

All NIUs have Ethernet-compatible 48-bit addresses.  SDP (Simple
Datagram Protocol) uses 80-bit addresses; 16 bits are reserved
(must be zero), 16 bits are used for the "Network ID" and the
remaining 48 are the original "Host ID."  Network numbers range
from 1-7FFF (hex) and are assigned by the customer.  Each Network
must have a unique Network ID.  "Network 0" is defined to be the
directly-connected network.  FFFF (hex) (=broadcast) indicates
that the datagram should be sent to all networks.  Note that to
send a datagram to all NIUs both the Network and Host addresses
must be set to broadcast values.

Instead of a single "Ethernet type" field, SDP has a source and
a destination type.  If you request (destination) type filtering
only the first byte is examined.  Legal values for SDP types are
0100-0DFF (hex); 0100-0BFF are reserved for Net/One protocols
leaving 0C00-0DFF available for use.
SDP (SDS/MDS) Frame Format

|				| \		 01 DD 00 multi FF
+-			       -+  | 00 00 ii ii 00 DD 00 nn nn pb
|				|  |		 \__ Ethernet ___/
+-			       -+  |	iiii = Network ID
|      DESTINATION ADDRESS	|  |	nnnn = NIU serial #
+-			       -+  |	   p = port (always 1 for
|				|  |		SDS, 1-6 for MDS)
+-			       -+  |	   b = board (0-3)
|				|  |	All bits on in any field
+-------------------------------+  |	matches any (broadcast)
|	DESTINATION TYPE	|  | 0C 00 through 0D FF
+-------------------------------+  |
|				|   > SDP HEADER
+-			       -+  |
|				|  |
+-			       -+  |
|	 SOURCE ADDRESS		|  | 00 00 ii ii 00 DD 00 nn nn pb
+-			       -+  |
|				|  |
+-			       -+  |
|				|  |
+-------------------------------+  |
|	   SOURCE TYPE		|  | 0C 00 through 0D FF
+-------------------------------+  |
|				|
:	      DATA		:
:	   0-600 BYTES		:
|				|
Issue 1: What to use for type values?
	Suggestion: set the
		destination type to 0D 00 + LSB\/of the RFC 900
		     source type to 0D 00 + MSB/\Ethernet type

Issue 2: How to do address resolution?
	Suggestion: The "Host IDs" are in 10 Meg Ethernet space;
	adapt existing ARP.  Consider embedding Network ID in
	32-bit IP address (a la Stanford PUP subnets).

Issue 3: Datagrams max out at 600 bytes.
	Suggestion: Use 576 as the MTU and hope for the best.

Issue 4: Trailer encapsulation
	See issue 3.

Feedback is encouraged; assistance drafting an RFC is welcome.

					Eric P. Scott
			      Networked Computer Systems Group
			  Computer Science and Applications Section
				  Jet Propulsion Laboratory
			     California Institute of Technology

P.S.  The "un" driver in BSD Unix is for an earlier, incompatible
incarnation of Net/One.  No one else to my knowledge has
attempted this.
Date:      Mon, 6 Aug 84 07:26:59 cdt
To:        don.provan@CMU-CS-A.ARPA
Cc:        info-nets@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  OSI
There's a Committee of the National Academy of Sciences and Engineering
which is advising the Department of Defense and the NBS (under their
sponsorship) what they should do about Transfer and Internet Protocols.
I'm a member of the committee.

There has been much OSI progress in the past two years -- much of it
resulting from efforts of NBS in collaboration with US industry.
There is a transport protocol which is functionally similar to but
not interoperable with TCP.  The DoD and OSI IP's are much more
similar with the Specs on OSI IP just about firmed up.

The OSI tranport -- TP4 -- is viewed as good as or slightly better than
TCP.  The quality of the specs and the validation facilities are
better for TP4 than for TCP but there has been much more experience
in implementing and operating TCP (though many feel that not all
of that experience was performed with high engineering standards).

This past month thirteen companies demonstrated interoperating TP4's
at the NCC.  All went smoothly andd there was much favorable
professional and popular press -- articles in the Wall Street Journal and
Business Week.  I believe that, at most, only two of the demonstrated
TP4's were vendor supported products.  The big question is how much
market demand exists for OSI concept and how soon will products be

All agree that ISO has made surprising progress, particularly in the
past several years.  There has been politics but it has had very
little detrimental effect on the evolving standards.  The question
is:  what next?

I've spent much time on this is the past year, coming in as a novice.
I would be glad to address more specific points.  I'd also
appreciate a sketch of the kind of response that you get.

Herb Benington at System Development Corporation.
Date:      6 Aug 84 11:20:01 EDT
From:      snively @ DDN1.ARPA
To:        tcp-ip @
Cc:        snively @ DDN1.ARPA, mlewis @ DDN1.ARPA, dcab645 @ DDN1.ARPA
Subject:   TCP-IP Distribution List
Please remove DCAB645 at DDN1 from subject distribution and add
Thanks much,
Jack Snively, DCA/B646  703-285-5230

Date:      6 Aug 84 1203 EDT (Monday)
From:      don.provan@CMU-CS-A.ARPA
To:        info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   re: OSI
first, let me clarify what i'm asking for.  i've gotten two
responses from my note so far.  one said "here are the people working
on OSI.  Ask them."  the other you all saw, and said "this is where we
are."  i appreciate the input and it's information i can use, but
what i really want to know is what do people think about it that
aren't personally involved?  is anyone planning to use this once it
does start to hit the streets?

one thing that's always worried me was exacerbated when Herb
Benington used the word "inoperable."  i assume if he meant "compatible,"
he would have said that, so it sounds to me like we're going
to have lots of ISO compatible, NBS approved products that
can't talk to each other.  i've always been told that the ISO
stuff is more of a guideline than a protocol specification, and
this seems to bear that out.  a protocol does me no good if i
can't plug in an IBM machine and network it to my DEC machine.
it doesn't help any that they both agree with ISO if they can talk.
Date:      Mon, 6 Aug 84 13:10:37 cdt
To:        don.provan@CMU-CS-A.ARPA
Cc:        info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   re: OSI
First let me start with an assertion or hypothesis.  To wit:

	TP4 is a very well specified protocol.  It is not only a
	guideline.  It is not an early or mid X.25 which has so
	many options that it's unlikely that two implementations
	will be able to talk to each other.  There are
	important options in implementing TP4 but they represent
	vertical features (assuming a model of heterogenous
	processors talking to each other horizontally). Two
	examples:  There is an option for a "graceful close"
	(which DoD would very like to have in its implementations)
	but it isn't essential for minimum operations.  Security
	is a well defined interface but design of security
	specifics is left up to the implementation (which is the
	way DoD would wan't it).

Next, two different implementations of TP4 should talk to each other
if they follow the specifications and understand which options are
being followed.  The best example of this is the development of
the implementations for the NCC demonstration just successfully
completed.  It took about an hour and a half for fifteen vendors
to agree on all details that would be implemented.  Once a vendor
had his (or her) implementation completed, they would subject it to
a battery of tests that have been prepared over the past two years.
These NBS tests have been described in Data Communications and
received very good professional reviews.

If they passed those tests, then it turned out that invariably they
could talk to the other vendors at the transport level.  (There were
some less well specified and testable functions at the File and
Applications level that had to be worked out but these ended up
causing no problems.)  Not all TP4 vertical functions were demonstrated
in Las Vegas; for example, graceful close was omitted.

In my previous message I had meant to say that TCP and TP4 are
functionally similar but won't interoperate with each other.  Some
people are looking at translating gateways but there's little optimism 
that these will be easy to achieve or will be functionally powerful.

The Committee which I referred to has just about completed its
report.  Academy protocols urge silence until the Academy issues the
report.  The intention is to issue the report as an RFC.
Several members compared TCP/IP and TP4/IP in some detail; this
comparison is in the report.  The conclusions are, I think,
consistent with the above thoughts.  Carl Sunshine at Sytek and Tony
Lauck at DEC did the most homework.

Almost completely independent of the above analysis but very much
related to the market is the work represented in General Motors'
Manufacturing Automation Program.  The MAP specifications call for
ISO as represented in NBS documents and there is a considerable
movement to have this become a standard for industrial automation.
Similar trends are developing in banking, domestically and
internationally.  GM has done alot of homework with six vendors
including IBM which, I believe, has indicated that it will have
ISO gateway products.

Pardon the mild pun: this subject is no longer academic.
Date:      6 Aug 84 14:21:13 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        don.provan@CMU-CS-A.ARPA
Cc:        info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   re: OSI
I am enclosing a reply that I originally sent only to Herb Benington.
But first, I can't keep from responding to your comment about
interoperability.  The term interoperable is viewed as being less
ambiguous that compatible.  We all know there are various types of
compatibility.  Interoperable says that the whatever level of
compatibility they may or may not have, they have to be able to talk to
each other.  I think that is what you were asking for. The comment that
I assume you are responding to said that the ISO equivalent of TCP would
not be interoperable with TCP.  I saw nothing in his message to suggest
that various ISO implementations would have any problem talking to each
other.  Indeed he indicated that facilities for validating
implementations would be better than on TCP.  As I understand it, the
people who did the ISO demonstration had to do some of their own
protocol-defining, but this was simply because not all the protocols are
finished, not because the ISO folks plan to leave holes in their

Now for my actual feelings on the subject.  Note that I am sending
this because both you and Herb indicated that you wanted to hear from
people who aren't involved in the efforts, not because I claim to
know anything in particular about networking.


My problem with the OSI effect is that I am in the process of trying to
build up networking locally.  I am concerned that the OSI effort is
going to detract from our ability to implement TCP.  As you probably
know, TCP is now available on a very wide variety of machines, and a
variety of commercial hardware is becoming available for it. However
there are still some serious omissions from the list.  Universities
are now beginning to press the vendors that are not on the list, and
are having some success.  However some critical vendors (e.g. IBM, DEC,
Apple) keep saying they are waiting for OSI.  Unless OSI is going to be
markedly superior to TCP, I would rather have the effort vanish.  As as
example of the effect, consider the trade press coverage of networking.
It is almost as if the trade press were in a conspiracy to ignore TCP.
All the articles on networking mention the OSI model, and there has been
lots of press for the demo that you described.  They always manage to
give the impression that TCP is used and usable only by a few Arpanet
sites.  If OSI were really here and available widely, it would be great.
I would also be able to understand the attention if OSI were really
going to have seriously superior facilities to TCP.  But neither of
these seems to be the case.  So why are we splitting the effort?  In my
opinion (again, unless something is going on that I don't know), those
people who are pushing OSI (e.g. GM) are doing a very serious disservice
to the industry.

By far the best approach would be to modify the OSI standards to be
close to TCP.  By close I mean that the changes would either be
upward-compatible, or at least of a nature that it would be plausible
to believe that all TCP implementations would follow them.  Then we
would view it as a second-generation TCP.
Date:      Mon 6 Aug 84 20:14:18-EDT
From:      J. Noel Chiappa <JNC@MIT-XX.ARPA>
Cc:        info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Ignorance (sic) of TCP/IP in trade press
		Hear, hear!
Date:      Tue, 7 Aug 84 11:44:56 pdt
From:      Janet M. Walker <walker%cod@Nosc>
To:        tcp-ip-request@sri-nic
Subject:   Request for info
I am trying to find if anyone has ever worked on, or implemented,
TCP/IP  for  a  PDP-11  with  an  IAS  operating system.  I would
appreciate any help you could give me in this matter.

Date:      Wed 8 Aug 84 11:49:10-PDT
From:      Anne Sauer <SAUER@SRI-NIC.ARPA>
To:        walker%cod@NOSC.ARPA
Cc:        SAUER@SRI-NIC.ARPA, perillo@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Request for info
     I am somewhat familiar with the tcp-ip-implementations.txt file where
we keep information about implementations of tcp-ip.  In that file, there
are vendors of various systems.  I did a search on the file and found no
IAS operating system there.  
     However, I suggest that you ftp the file to your system to look at it
because there are several implementations on pdp-11's.  The file name is
<netinfo>tcp-ip-implementations.txt and by connecting to nic@sri-nic, you
may ftp the file over to you.
     The new Vendor's Guide will be out in hard copy in the near future.  If
you wish, I could add your name to the distribution list.
     Also, if you find out more information, we would like to include it in
this collection.
     Thanks for contacting us and I will keep you updated if I learn anything


Anne for the NIC
Date:      Wed 8 Aug 84 13:55:10-PDT
From:      Harry Sameshima <HSS@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        postel@USC-ISI.ARPA, mike@BRL-TGR.ARPA, rogers@USC-ISI.ARPA, roode@SRI-NIC.ARPA, satz@SRI-NIC.ARPA
Subject:   Error messages
This is a test. If it works, TCP-IP list messages will now specify 
a return path of TCP-IP-RELAY@SRI-NIC so as to funnel downline error messages
to be processed at SRI-NIC rather than returning them to the
originator of the message. Continue to send contributions to TCP-IP@SRI-NIC
and list addition and deletion requests to TCP-IP-REQUEST@SRI-NIC.
Date:      Thu Aug  9 18:26:16 1984
From:      Martin Lee Schoffstall <cadmus!schoff@seismo.ARPA>
To:        seismo!tcp-ip@sri-nic.ARPA
Subject:   EXCELAN and class A networks
Is anyone trying to run an EXCELAN board in the DDN/ARPA
internet world.  Do you have a Class A network or are
you doing something in your gateway that you don't want
to talk about?


Date:      13 Aug 1984 07:13-EDT
To:        don.provan@CMU-CS-A.ARPA
Cc:        info-nets@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: OSI
My impression is that the OSI model and the protocols which are
developing around it are getting a fair amount of support from
the vendors but it is a slow process.  Demo's at NCC 84 of the
level 4 TP4 and File Transfer protocols on DEC, HPand other gear
seem to show serious intent on the part of vendors.

Vint Cerf
Date:      Mon Aug 13 22:17:56 1984
From:      Martin Lee Schoffstall <cadmus!schoff@seismo.ARPA>
To:        seismo!tcp-ip@sri-nic.ARPA
Subject:   OSI/NCC thoughts
I was at NCC specifically to get a feel for what the rest
world was going to commit to.  Of most interest to me in the
short term is that DEC stated that they were going to mold DECNET
to follow NBS and friends.  IBM Industrial Systems has committed
as has HP.  Note that IBM was there with Series1's, a 43xx/30xx
implementation would be incredibly significant.  It would be nice
if SNA was put to sleep but given the ECC's settlement, marketing
and politics will continue to defeat engineering and architecture.
Also rumored was that IBM Corp. was going to commit
to OSI through a fabled OSI/NBS <-> SNA bridge.  It would seem that
this is definitely the coupe de grace on XNS and from other DCA signals
an omen for TCP/IP.



Date:      14 Aug 84 08:26:19 EDT
From:      ddn-usaf @ DDN1.ARPA
To:        tcp-ip @
Cc:        ddn-usaf @ DDN1.ARPA
Subject:   tcp-ip newsletter mailing list
please add my name to the distribution list for your tcp-ip 
newsletter. also add jyoung@ddn1.
thank you.
major allen

Date:      15 Aug 84  2036 PDT
From:      Joe Weening <JJW@SU-AI.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Data General TCP implementation?
Does anyone know of any IP/TCP implementation for the Data General
Eclipse, running RDOS?

Date:      21 August 1984 08:55-EDT
From:      Charles Hornig <CAH @ MIT-MC>
To:        tcp-ip @ SRI-NIC, postmaster @ AIDS-UNIX, postmaster @ UW-VLSI
Subject:   bad TCP implementations
Over the last few months, I have noticed that there are many Internet hosts with defective TCP implementations.
The common problem with them is that they do not properly process an
incoming segment which contains both acknowledged and unqcknowledged data.
Instead of ignoring the acknowledged part and processing the unacknowledged part,
they ignore the whole segment.  Since the TCP for the Symbolics 3600 sends these
segments (for performance reasons), we are unable to communicate with such hosts.

The two hosts I have seen this in most recently are UW-VLSI and AIDS-UNIX.  These
are (I believe) both 4.1bsd Unix hosts.

It is really unacceptable that at this late date there are still TCP implementations with such fundamental flaws.

Date:      Thu, 23 Aug 84 17:41 EST
From:      Ed Fox <>
Subject:   AT&T IS ISN use with ULTRIX?
Does anyone know if it is possible, and if so how, to attach a VAX 11/780
running ULTRIX to the new AT&T Information Systems Network packet controller
through KMC front end via fiber?  They have hardware to do it into System V
and I believe AT&T Technologies has software to go along, but wonder if their
URP can work with our TCP/IP or come in through special driver.  I know that
they have not announced such a product but wonder if it might be possible for
us to develop here or get from elsewhere.  We eventually will have LAN with
several machines, including VAXen running VMS and ULTRIX and some machine
running System V, and if we can use KMC instead of DH on ULTRIX machine
would then be interested in using ISN for the LAN.  Does anyone have other
comments about the new ISN?  Thank you for your assistance!  Please
reply directly to
Date:      Thu, 23 Aug 84 17:38:02 EDT
From:      Ron Natalie <ron@BRL-TGR.ARPA>
To:        gurus@BRL-TGR.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   AMES-NAS-GW
These people send mail (and want to be on INFO-MICRO) but their host
is not listed as a HOST but only as a GATEWAY.  MMDF won't send to
things that aren't hosts.

Date:      27 Aug 1984 1738 PDT
From:      Ron Tencati <TENCATI@JPL-VLSI.ARPA>
To:        TCP-IP@SRI-NIC
Subject:   Arpanet User Needs Help...

	Our Arpanet Guru has left JPL.  I was given the dubious title
"Keeper of the Net".  I am not new to the ARPANET, but I am new to
maintaining a computer that is on the Net.  My first priority is
updating my host tables. Our Guru left no documentation whatsoever. I
desire to know how to update my host tables. We have a program called
ROUTE that the sytem executes during startup, but I don't know what it
does or why (is it documented anywhere?).  I don't know how to get the
host table at SRI to look like the host table we have here. Our Guru was
also able to add hosts not in SRI's table to our local table without
rebooting the system (Do I just add a line?).

	We have a "Field Test Site Agreement" with SRI which I am told
is equivalent to a "license" to run the software.  We do not have EUNICE
here, nor do we do we have The Wollongong Group's stuff.  We are
currently running (I was told) Kashtan's implementaion of TCP/IP on our
11/780 under VMS V3.6. Apparently, we just FTP the new stuff from SRI
when there is an update or such and run it here. We have little or no 
source (is this normal?). We have RSTAT, NETSTAT, ROUTE, and some other 
programs that we don't know what they do.  We never asked WHY or
HOW until now... 

	Outside of the RFCs, is there any documentation (written or
known about) that addresses these kinds of implimentations?  If anyone
out there could give me some advice, it would be appreciably recieved. 

	Thanks in advance, 
	         Ron Tencati 
Date:      Mon, 27 Aug 84 20:38:29 edt
From:      cu-arpa.bill@Cornell.ARPA (William A. Nesheim)
To:        tcp-ip@sri-nic.ARPA
Subject:   RDP implementation

Has anyone implemented the Reliable Data Protocol for 4.2 yet?  I am interested
in useing it as a basis for a reliable data path between our 4.2 VAX hosts
and our pdp11 front-end processors, useing the ethernet as a transport layer.

			Bill Nesheim
			Cornell U. Dept. of Computer Science
Date:      29 August 1984 1347-PDT (Wednesday)
From:      stanonik@nprdc
To:        tcp-ip@sri-nic
Cc:        info-unix@brl-tgr
Subject:   4.2bsd gatewaying
We're thinking about running rick@seismo's serial line ip code
to a machine, sdcsla, at a local university, ucsd.  Our aim is 
to communicate with sdcsla, but not to gateway between ucsd's 
relatively large local network and the milnet.  (sdcsla is on
ucsd's local network and we're on the milnet).  My reasoning,
or lack thereof, runs as follows.
1) 4.2bsd assumes packets should be forwarded between network 
   interfaces; ie, packets will be forwarded between ucsd's
   local network and the milnet, given the appropriate routing 
2) routed on our machine will inform sdcsla that we are a gateway 
   to the milnet, and routed on sdcsla will in turn inform every 
   machine on ucsd's local network.
3) egp (kirton@usc-isif's egp) on our machine will inform every
   machine on the milnet that we are a gateway to ucsd's local
4) Has anyone else had to deal with keeping networks disjoint, 
   both speaking IP?  Any ideas on controlling 4.2bsd packet 
   forwarding, or routed/egp routing information?


Ron Stanonik
Date:      29 Aug 1984 1631-EST (Wednesday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        stanonik@NPRDC.ARPA
Cc:        info-unix@brl-tgr.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: 4.2bsd gatewaying
The straightforward way to avoid this is to make sure that sdcsla does
not have a route to milnet; then people might send to them, but the
reply packets will not be able to get out. If both ends run routed,
this might be a problem -- I'm not familiar enough with routed to
judge. We axed it a long time ago because it causes more trouble than
it's worth. You might be able to do without running routed on the two
endpoint machines.

Date:      29 Aug 1984 2107-EST (Wednesday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        tcp-ip@sri-nic.ARPA
Cc:        dbg@Purdue.ARPA
Subject:   TCP/IP on HP 9836?
We have just taken delivery of several HP 9836 workstations running
HP-UX, and would like to connect them to our local network. I have 
received several reports of Ethernet cards that connect to the HP-IB
bus, and one report of a TCP offering from HP, but "it may not talk to
*your* TCP" (why do they call it TCP, then?). Does anyone have positive
experience in this arena?

Date:      Thursday, 30 Aug 1984 09:18-PDT
From:      imagen!
To:        shasta!CERF@USC-ISI.ARPA
Cc:        shasta!cak@PURDUE.ARPA, shasta!tcp-ip@SRI-NIC.ARPA, shasta!dbg@PURDUE.ARPA,
Subject:   Re: TCP/IP on HP 9836?

When I was at NCC I spoke to the engineer who had brought up the TP4
demonstration.  I asked whether HP had a networking product based on it.
He replied that HP had no immediate plans to use the ISO protocols in
a product, but did have a network offering based on TCP-IP.

As to whether they believe in general systems interconnection with their
TCP and whether they have made this work, I have no idea.

- Geof Cooper
Date:      30 Aug 1984 07:01-EDT
To:        stanonik@NPRDC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, info-unix@BRL-TGR.ARPA
Subject:   Re: 4.2bsd gatewaying

Along time ago, BBN had to introduce similar fire walls between their
commercial Telenet system and the ARPANET (you may recall that BBN started
Telenet and sold it to GTE later). They were concerned at that time with
TOPS-20 or Tenex systems which were on both Telenet and ARPANET.

At that time there was no IP and no host gateway, so they only had to
block user access from one net via the host to the other.

What happens if you use two hardware interfaces (one to the local net and
one to the Milnet) and two copies of IP. The two copies of IP need not
know about each other's existence. Users of the IP layer would need to
know to route (select) IP services based on destination network.

Sounds awful, but it looks to me as if you need to bifurcate the
view of the world at about the gateway level if you are to maintain
the fiction that your machine is a host on two system which is
not, accidently, a gateway between them as well.

As to actual code availability to achieve this - I dunno.

Date:      30 Aug 1984 07:08-EDT
To:        cak@PURDUE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, dbg@PURDUE.ARPA
Subject:   Re: TCP/IP on HP 9836?

My understanding is that the HP9836's were used to demonstrate
something called TP4/IP at the NCC 84. TP4 is the level 4 protocol
from ISO. the IP is very similar to the DOD version, considering
it was based on the DOD spec.  I rather doubt the HP TP4 will work
with the DOD TCP. 

Vint Cerf
Date:      30 Aug 1984 09:33-CDT
To:        tcp-ip@SRI-NIC.ARPA
Subject:   New Addition to Mailing List

Please add SAC.Long@USC-ISIE to your distribution list.

Thank you.

  --  Steve

Date:      Thu, 30 Aug 84  9:26:34 EDT
From:      dca-pgs <dca-pgs@DDN1.ARPA>
Subject:   TCP/IP for HP 9836?
I have heard that HP's adaptation of Unix,
"HP-UX", is based upon Berkeley 4.2 and does
include TCP/IP + Arpanet applications. Does
anyone know anything more?

-Pat Sullivan

Date:      30 Aug 1984 10:25:40 EDT
Subject:   HDH

Date:      Thu, 30 Aug 84 13:58:23 EDT
From:      Dennis Rockwell <>
Subject:   Re: 4.2bsd gatewaying
	From: stanonik@nprdc
	Subject: 4.2bsd gatewaying
	Date: 29 August 1984 1347-PDT (Wednesday)

	We're thinking about running rick@seismo's serial line ip code
	to a machine, sdcsla, at a local university, ucsd.  Our aim is 
	to communicate with sdcsla, but not to gateway between ucsd's 
	relatively large local network and the milnet.  (sdcsla is on
	ucsd's local network and we're on the milnet).  My reasoning,
	or lack thereof, runs as follows.
	1) 4.2bsd assumes packets should be forwarded between network 
	   interfaces; ie, packets will be forwarded between ucsd's
	   local network and the milnet, given the appropriate routing 

There is a flag (ipforwarding) that you can set to 0 to prevent packet
forwarding.  You can either change it in your source, or run an adb script
from rc.local to turn off the forwarding.  Packets which would have been
forwarded are then answered with an ICMP UNREACHABLE message.

	2) routed on our machine will inform sdcsla that we are a gateway 
	   to the milnet, and routed on sdcsla will in turn inform every 
	   machine on ucsd's local network.

Don't run routed unless you have to (for a local net, perhaps).  In any
case, turning off forwarding will stop the traffic.

	3) egp (kirton@usc-isif's egp) on our machine will inform every
	   machine on the milnet that we are a gateway to ucsd's local

Why are you running EGP if you don't want to be a gateway?  If you run it
because you want to keep your routes up to date, then you should use the
"egpnetsreachable" config command (in the file etc-egp) to restrict the nets
that are advertised by EGP.  If you are a gateway between MILNET and some
local net you don't mention in your message, then you will have to hack
ip_forward in netinet/ip_input.c to exclude the point-to-point net plus all
the nets behind sdcsla.

	4) Has anyone else had to deal with keeping networks disjoint, 
	   both speaking IP?  Any ideas on controlling 4.2bsd packet 
	   forwarding, or routed/egp routing information?

In addition to the above, we (CSNET) have to restrict our non-domestic X.25
sites from sending or receiving packets from the Internet.  The solution in
this case is (unfortunately) to hack ip_forward as mentioned above.


	Ron Stanonik

Good luck!  Let me know what you finally do.

Dennis Rockwell
CSNET Technical Staff
Date:      Thu, 30 Aug 84 17:20:20 cdt
To:        cak@Purdue.ARPA
Cc:        dbg@Purdue.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re:  TCP/IP on HP 9836?
The National Academy panel that has been looking into potential use
of ISO's TP4/IP by DoD has unanimously concluded that TP4 can't talk
to TCP and that a translating gateway may or may not turn out to
be  cost-effective.

Herb Benington
Date:      30-Aug-84 15:21:12-UT
From:      mills@dcn6
To:        stanonic@nprdc
Cc:        tcp-ip@nic
Subject:   Backdoor address filters

It took me a while to cross-check your presumed connectivity with the NIC
tables, from which it is apparent that there are no advertised gateways now
between UCSD (128.54), NPRDC-ETHER (192.5.65) and any other net in the
Internet system, nor any advertised hosts on these local nets. Thus, it would
seem you can protect the UCSD - MILNET path by the simple mechanism of
dropping packets (a) with destination address UCSD and source address other
than NPRDC-ETHER and (b) with source address UCSD and destination address
other than NPRDC-ETHER. This is similar to the mechanism now used on the
MARYLAND (University of Maryland) 4.2bsd, which is a gateway between MILNET
and UMDNET, which in turn includes a gateway to DCNET, itself gatewayed to
ARPANET (!). For further information, I suggest you contact Mark Weiser

This mechanism protects only the raw-datagram flow, of course, leaving the IP
source-route and Telnet double-login paths open. So far as I know, 4.2bsd does
NOT support source-route and Telnet double-login can be prevented by the usual
password mechanism. Maryland has not yet brought up the Kirton EGP code, so
some fine-tuning may be necessary to prevent UCSD being broadcast in EGP

Date:      30 Aug 84 21:44:22 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        dca-pgs@DDN1.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, cerf@USC-ISI.ARPA
Subject:   Re: TCP/IP for HP 9836?
The HP/UX that we have is System III with few Berkeley enhancements.
The documentation acknowleges Berkeley, but we haven't noticed very
many Berkeley features.  We have heard rumors that there will be TCP
over Ethernet "Real Soon Now", but it does not seem to be available to
us yet.  They have put a lot of work into documentation, and into
graphics support.  However System III is a primitive system by
today's standards.
Date:      30 Aug 84 22:33:07 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   need for a protocol
We are about to start using TCP for our local networking.  We need to
add a feature that we have been using in PUP.  We have a number of batch
control files that transfer files among our systems.  We prefer to avoid
having passwords to privileged user id's in control files.  Thus we have
implemented a  "same name same user" bit on our DEC-20's.  If I have
that bit set, it asserts that Hedrick is the same on the systems. PUPFTP
is able to use this to avoid asking for passwords.  I need to do
something similar in TCP FTP.  I didn't do the PUP implementation, but I
think what happens is that the remote FTP server sends the equivalent of
a UDP packet to the miscellaneous server asking who the user is on the
local machine.  As we use "job-relative" socket numbers for FTP
connections, the server knows the job number.  So it just asks "who is
the user for this job number?"

We would like to do something similar for TCP.  We also need a way for
our mail servers to know when they are talking to another server and
when to a normal user.  We have to prevent a user from convincing one
of our servers to forward his message onto the Arpanet when he does not
have the right to do so.

Both of these problems share something in common:  Our server needs to
know who it is talking to on the other end.  Does anyone know whether
there is something in the protocols that will allow this?  If not, can
anyone suggest a way to add it that will be consistent with the overall
philosophies of TCP/IP?  The cleanest way is probably to have a server
to whom we can send a query: "what is the user name of the job that has
the following socket number open?"  PUP's method of encoding things in
the socket number involves less coding, but is probably not a good idea
in the long run.  Obviously we will combine this protocol with a list of
"trusted hosts".  Users on hosts that are not trusted will always have
to type a password, and will never be able to get mail forwarded to the
Date:      31 Aug 1984 0937-EST (Friday)
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        tcp-ip@nic.ARPA
Subject:   More info about HP's "TCP"
Simply unbelievable. How can they call it TCP?

Is there, by some chance, a mechanism for preventing them from using
the name TCP, since it really isn't?


------- Forwarded Message

From: djb@cbosgd.UUCP (David J. Bryant)
Subject: Re: HP's TCP/IP implementation
Message-ID: <260@cbosgd.UUCP>
Date: Wed, 29-Aug-84 08:53:25 EST
Date-Received: Thu, 30-Aug-84 01:12:10 EST
Organization: AT&T Bell Laboratories, Columbus

We have had several meetings with a variety of HP people about this issue
recently.  You are quite right - the HP implementation of TCP/IP is different
from the standard TCP/IP, and it's intentional on HP's part.  As far as I
understand the situation the differences are that HP's version does not
provide/support the following:

 	1) Urgent Data
        2) Graceful Release
        3) Option Fields
        4) Segmentation and Reassembly of IP packets.
        5) Checksumming. (HP figures that this is done adequately in layer 2,
	   so they left it out to improve performance)
        6) Address-Resolution Protocol.  HP uses a custom-designed "probe"

The bottom line is that an HP TCP/IP system can ONLY talk to another HP
TCP/IP product!  We found this to be an incredible design decision, and
one that is totally incompatible with our requirements.

Further, HP supports only file transfer and remote file access.  Virtual
terminal and IPC applications are planned for the future. Yet another
problem area we're having to work out...

According to HP, they have had "several people" question their lack of
support for standard TCP/IP.  They are clearly aware of the problem, and 
are considering fixing things up, but we have not had any detailed
committment from them.  For some reason they are determined to support
their "version" of TCP/IP, but they are talking about some mechanism
that will make it possible to talk both their version and the standard
version with the same software.  Regardless, I expect that things will
get fixed eventually - the HP folks have been amazingly receptive to
our requests so far - but it will take time.

Still, we see this as a silly situation, and have yet to understand HP's
reasoning on this one.  I'd like to personally encourage every HP owner/user 
(and anyone else that can get HP's ear) to strongly "suggest" to their HP 
contact that HP get their TCP/IP version in line with the standard, for
innumerable obvious reasons.

As our discussions with HP progress and new things happen, I'll keep you 

	David Bryant   AT&T Bell Laboratories   Columbus, OH   (614) 860-4516

------- End of Forwarded Message