The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for March 1989 (290 messages, 216767 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/03.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 Mar 89 00:51:36 GMT
From:      greg@muddy.cs.unlv.edu (Greg Wohletz)
To:        comp.protocols.tcp-ip,comp.sources.d
Subject:   Re: ftp'able software (as posted to tcp-ip list)

In article <946@mailrus.cc.umich.edu> emv@starbarlounge.cc.umich.edu (Edward Vielmetti) writes:

[list of available software, including the following]

>athena-dist.mit.edu	Kerberos, Zephyr, MIT worm paper
                                  ^^^^^^
Is zephyr being distributed?  Last time I looked on athena-dist I could
not find it.  If you know where it lives please let me know!

					--Greg

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 89 08:33:00 EST
From:      "AFSC02::MCDANIEL" <mcdaniel%afsc02.decnet@hqafsc-vax.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   DEC-VAX ALL-IN-ONE
Andrews AFB

                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      1-Mar-1989 08:32am EST
                                        From:      Mr Rodney A McDaniel 
                                                   MCDANIEL 
                                        Dept:      HQ AFSC/SCXP
                                        Tel No:    981-7909
                                        Owner:     Mr Rodney A McDaniel  *

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: DEC-VAX "ALL-IN-ONE"



REQUEST FOR HELP:  DEC-VAX "ALL-IN-ONE"

PLEASE REPLY TO EMAIL ADDRESS: MCDANIEL@HQAFSC-VAX.ARPA

PRESENTLY, I AM A USER ON A DEC-VAX SYSTEM USING THE "ALL-IN-ONE"
OPERATING SYSTEM.  THE RECENT PROBLEM I HAVE EXPERIENCED IS WITH
THE "ALL-IN-ONE" SYSTEM CONVERTING ALL "MAILBOX USER NAMES" TO
UPPER CASE AND CANNOT SUPPORT "lower-case" SENSITVE MAILBOX 
NAMES, THE ONLY SOLUTION THAT HAS BEEN PROVIDED IS TO GET "DCL" 
ACCESS FOR USING THE VMS MAILER, HOWEVER THIS SEEMS UNREALISITIC 
FOR LOGICALLY EVERY EMAIL USER SHOULD BE ABLE TO SEND TO ANY 
OTHER EMAIL USER, WHETHER HIS EMAIL ADDRESS IS "lowercase" 
SENSITIVE OR NOT.

HAVE ANY OTHER USERS OF THE "ALL-IN-ONE" SOFTWARE HAD THIS 
PROBLEM??  IF SO, WHAT DID YOU DO TO RESOLVE THE PROBLEM??
DOES ANYONE HAVE A POINT OF CONTACT ON GETTING THIS PROBLEM 
CORRECTED.  I WAS TOLD BY OUR SYSTEMS MANAGER FOLKS THIS WOULD 
REQUIRE A SOFTWARE CHANGE TO THE "ALL-IN-ONE" AND COULD BE VERY 
EXPENSIVE.  ALSO, THIS VERTUALLY STOPS ANY EMAIL TRAFFIC WITH THE 
WANG SYSTEMS, PLUS ANY OTHER SYSTEMS WITH "lowercase" mailboxes.

I REALIZE THIS IS NOT A TCP-IP ISSUE, BUT I NEED TO REACH THE 
TCP-IP MAILING LIST SO POSSIBLY SOMEONE CAN PROVIDE A SOLUTION TO 
THIS DILEMMA.

ANY ASSISTANCE WOULD BE APPRECIATED, SO I COULD PASS THE 
INFORMATION TO THE SYSTEMS MANAGER AND HOST ADMINISTRATOR.

RODNEY A. MCDANIEL
AIR FORCE SYSTEMS COMMAND
DDN PROGRAM MANAGER


------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 89 05:40:34 GMT
From:      njin!dpz@rutgers.edu  (David Paul Zimmerman)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ping info

	... I have captured a ping package between two unix hosts on
	the net and modified the the source ethernet address to
	reflect the analyzer's address and at the same time have
	modified the source IP address to one given me by the unix
	administrator for the lan analyzer.  ...

I see a basic problem in that the IP header checksum will then be
wrong.  Given your application, though, you can compute it manually.
It is "the 16 bit one's complement of the one's complement sum of all
16 bit words in the header.  For purposes of computing the checksum,
the value of the checksum field is zero". (RFC960) As long as you are
grabbing any packets destined for the IP address you sent it out with,
you should see the ICMP echo-reply come back correctly.

A thought - you said that you captured a ping package.  I'm not sure
what that means.  During interrogation, did you notice whether it was
the ICMP echo or the ICMP echo-reply?  If you're sending out a packet
with echo-reply, you got the wrong guy, because you won't get an
answer to it.

						David
-- 
David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc
dpz@pilot.njin.net            rutgers!dpz          dpzimmerman@zodiac.bitnet
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Mar 89 12:14:36 CST
From:      "Craig Finseth" <fin@uf.msc.umn.edu>
To:        leonard@cod.nosc.mil
Cc:        tcp-ip@sri-nic.ARPA
Subject:   ping info
You have selected a novel way of generating packets.  You may (or may
not) find it easier to write a program to generate the packets, as a
ping packet is simply an ICMP Echo Request.

In any event, you must also update the IP Header Checksum field, since
you have changed part of the header (the source address).

Actually, with a LAN analyzer, you don't have to change the packet as
long as the destination is correct and the destination's route to the
source is over the network that you are monitoring.  Simply re-send
the original packet and pick up the return Echo Reply packet on the
analyzer...  It shouldn't cause any harm to the machine that appears
in the source address, but I would recommend at least letting the
manager of the machine know what you're doing.

Craig A. Finseth			fin@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 89 11:14:45 GMT
From:      mcvax!hp4nl!uva!smitf@uunet.uu.net
To:        tcp-ip@sri-nic.arpa
Subject:   info
Hi guys,

I'm looking for an introducing paper or book about the tcp-ip stuff.
I would be very happy if anyone who is reading this newsgroup could
help me with it.
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 89 14:11:49 GMT
From:      mssoft@pbinfo.UUCP (Software r/o)
To:        comp.protocols.nfs,comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   PCNFS Problems

Hi out there !

I have some problems with PCNFS 3.0 !
All works fine except RCP direction SUN to PC. 
Example : rcp host:mbox .
The other direction is all right and fast.
The problem concerns big files only ( >200k ).
In some rare cases it seems to work, but I get times over 2 minutes
for 500k and a factor of four in the number of handled IP packets versa
the PC to SUN direction. 

I use the following configuration :
AT-02 with 640kb
3COM 3C501 Interface
or 
3COM 3C500b Interface
Both thick and thin Ethernet give same results.



                                     Thanx
                                         Tilt

-----------------------------------------------------------------------------
UUCP:  ...!uunet!unido!pbinfo!tilt       |  Bertil Munde
       or tilt@pbinfo.UUCP               |  Universitaet-GH Paderborn, FB 17
CSNET: tilt%pbinfo.uucp@Germany.CSNET    |  Warburger Str. 100
ARPA:  tilt%pbinfo.uucp@uunet.uu.net     |  D-4790 Paderborn, West Germany
-----------------------------------------------------------------------------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 89 15:36:57 GMT
From:      hfsi!pat@uunet.uu.net  (Pat)
To:        tcp-ip@sri-nic.arpa
Subject:   802.2 implementations.
Netfolks

	I read rfc1042 as i was directed by several of your helpful selves
I found it most enlightening, I was left with some questions which I was
hoping I could get cleared up.  Is it mandatory to implement the 
XID/TEST commands ?  The rfc says it is not required to support tcp/ip
but we have to as part of the standard. Has anyone actually done this
or is practice to merely stuff the 802.2 headers and set MTU to 1492?

Thanks for any help
Pat
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 89 18:38:26 GMT
From:      oliveb!intelca!mipos3!omepd!psu-cs!profeta@apple.com  (Sandy@Oresoft)
To:        tcp-ip@sri-nic.arpa
Subject:   Looking for an Ethernet driver for Intel 82586 chip
Rumor has it that Rice University has an ethernet driver for the Intel
82586 chip.  Does anyone know how I could obtain this driver or who
I could call who might know more about it?

Please e-mail me at:

tektronix!reed!psu-cs!profeta

--Sandy Profeta
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 89 03:52:28 GMT
From:      hubcap!ncrcae!wingo@gatech.edu  (Dave Wingo)
To:        tcp-ip@sri-nic.arpa
Subject:   tcp/ip over x.25
can anyone tell me who supports tcp/ip over x.25 connections??? What is considered to be acceptable or non-acceptable performance with this type of connection??I here HP has such a connection. Your help in identifying vendors who have this type connection and more importantly performance criteria is most appreciated in advance.
Replies can be sent directly to wingo@ncrcae.com
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 89 08:11:30 GMT
From:      mcvax!unido!ecrcvax!paul@uunet.uu.net  (Paul Martin)
To:        tcp-ip@sri-nic.arpa
Subject:   CSNET PAD driver - help requested
I am looking for information on installing a working CSNET PAD driver for
an Interactive Systems X25 card on a VAX 785 running 4.3 BSD. The problem
that we have is one of flow control. 

Currently when I connect to a remote site the PAD driver works fine
until I hit ^S / ^Q in which case the line hangs. The problem does not occur
with rlogin over TCP/IP => this is probably due to the fact that TCP/IP provides
its own flow control protocol. 

Examining the code in xn_pad.c the pad profile table sets the X3 parameters 5 
& 12 but these appear to be no-ops ?. Furthermore the code in xn_nty.c has
parameter 12 set but no parameter 5 (is this a clue that the card does not
handle flow control correctly ?) 

The other puzzling thing is that the X25 protocol defines several types of
level 3 packet: call request packets, data and interrupt packets, flow control 
packets (RR & RNR) , reset and restart packets and yet I can only find code to 
handle CRP and CACC (call accept) packets ? The X25 card appears to have
a hardware flow control mechanism for handling buffer overflow - however
details of how software may instigate such a mechanism is not given.

I wonder whether someone in netland can possibly provide some light on my 
confusion - 
the situation at the moment is that the x25 card cannot be used by users
due to these flow control problems. 

Thanks in advance for any assistance.

Paul Martin  			
European Computer-Industry Research Centre        ECRC, Arabellastr. 17/II 
US:     paul%ecrcvax.uucp@pyramid.pyramid.com     8000 Muenchen 81, West Germany
        ..!pyramid!ecrcvax!paul		          Tel. +49 89 / 92699-124
Europe: paul@ecrcvax.uucp
	..!unido!ecrcvax!paul
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Mar 89 23:56:32 EST
From:      Mills@udel.edu
To:        Jeff Wabik <tank!shamash!jwabik@handies.ucar.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Internet Timeservers?
Jeff,

Copy the file pub/ntp/clock.txt on louie.udel.edu to a timezone near you.

Dave
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Mar 89 08:42:29 -0800
From:      davy@riacs.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Header Processing Times

As I promised last week, this is a summary of the responses to my query
about information on header processing times.  I received several
valuable pointers to information, as well as several requests for the
info I received.  (Those of you who requested a copy of the responses
will be receiving a non-summarized version.)

Thanks, everyone!

---------------
Clark, Romkey, Salwen; "An Analysis of TCP Processing Overhead", Proc.
13th Conf. on Local Computer Networks, IEEE Computer Society, Oct, 88.

	Several people referred to this.  It does have some very good
	information in it on instruction counts for TCP.
---------------
Van Jacobson's talk in IETF in Ann Arbor Michigan covers some of
this.

	I'm not sure if the researcher I got this info for has gotten any
	more information on this yet.
---------------
From: Mills@udel.edu

Dave,

Using current technology packet switches typically max at 400-2000
packets per second, to first order independent of packet length. The
max is typically CPU-limited, whith most of the processing time due
to resource management (scheduling, memory allocation, etc.) and
next-hop routing. Sticking headers on and calculating header checksums
are in the noise relative to these other factors. 

Dave
---------------
Several people sent me various letters to TCP-IP from Van Jacobson.
The dates/message ids are below; you can dig them up out of the
TCP-IP archives if you want them.

  From: Van Jacobson <van@helios.ee.lbl.gov>
  Subject: Re: TCP Ethernet Throughput 
  Date: Thu, 15 Dec 88 10:01:42 PST
  Message-Id: <8812151801.AA07386@helios.ee.lbl.gov>

	Interesting numbers on CPU memory requirements to provide required
	speed, etc.

  From: van@LBL-CSAM.ARPA (Van Jacobson)
  Subject: Re: maximum Ethernet throughput
  Message-ID: <8803100345.AA09833@lbl-csam.arpa>
  Date: 10 Mar 88 03:45:47 GMT

	This is the one about the LANCE and Intel chips in the Sun.

  From: van@HELIOS.EE.LBL.GOV (Van Jacobson)
  Subject: some interim notes on the bsd network speedups
  Message-ID: <8807200426.AA01221@helios.ee.lbl.gov>
  Date: 20 Jul 88 04:26:17 GMT

	This has some real interesting data on how long it takes the BSD
	code to process a packet, etc.
---------------

Thanks again to all who responded,
--Dave Curry
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 89 19:38:01 GMT
From:      aero!trwind!robert@oberon.usc.edu  (Robert W. Snyder)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TRW Terminal Servers (ACU 2000's) v Bridge/3Com...
Robert Snyder
>
>The TRW range of Access Control Units (Terminal Servers) are now being
>distributed in the UK. They appear to either run Bridge/3Com 'CS200'
>binary or their own TRW code. You can boot from a TRW loader or a
>Bridge NCS/AT. 
>
>Does anyone have experience of these units, particularly in a mixed
>Bridge/TRW site - also is there any info on whatever the link between
>TRW and Bridge is/was...
>
>Trevor Wright

Sorry I tried to send this direct, but my mail bounced.
Let me just identify myself and leave it at that so as not to be
too commercial.

I am the Product Marketing Manager for the ACU (Advanced Connector Unit).
Please feel free to ask me any questions about the product.


-- 
Robert Snyder       Disclaimer  --  nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
ARPA: robert@trwind.TRW.COM                               Ph 213-373-9161
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 89 23:21:53 GMT
From:      tank!shamash!jwabik@handies.ucar.edu  (Jeff Wabik)
To:        tcp-ip@sri-nic.arpa
Subject:   Internet Timeservers?
Please pardon my filing system, but ..  A few weeks ago there was a 
discussion here regarding accurate timeservers on the Internet, and,
as usual, I've lost track of the names of those servers.  I'd appreciate
it if someone could e/mail them to me ... 

Thanks much ..

	-Jeff

--
Jeff A. Wabik       E/Mail: jwabik@shamash.cdc.com   AT&T: +1 612 853 6811
  ____  ____                                         FAX:  +1 612 853 4789
 / ___||___ \
| |___  ___| |  Control Data Corporation - Don't worry, be grounded.
 \____||____/

      " .. You went out, nearly froze, earned a quarter, 
		     then the women took it..  Today you're a man."
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 89 01:52:19 GMT
From:      hpda!hpcuhb!hpindda!raj@ucbvax.Berkeley.EDU  (Richard Jones)
To:        tcp-ip@sri-nic.arpa
Subject:   wither slow-start?
Here's a toss-up to the net:

  Is it 'OK' to not 'slow-start' in the case where you know that the remote
is directly connected to 'your' lan on the assumption that you cannot
congest a lan?

Also, is it realisticly possible to flood things like bridges and repeters?

thanks for your input

rick jones

standard disclaimers - btw, who standardized the disclaimers - was it OSI,
CCITT, NIST ;-?
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Mar 89 09:40:32 CST
From:      pete@ncsc.ARPA (Fernandez)
To:        tcp-ip@sri-nic.arpa
Subject:   NetBIOS

 Fellow SIG members,

          I am looking for a good technical reference manual on NetBIOS;
       I already have the RFCs, so don't mention those.  It's my under-
       standing that IBM has such a manual, but it's next to impossible
       to ascertain.  Any help would be appreciated.  Thanx in advance.

        Pete Fernandez, pete@ncsc.arpa
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri,  3 Mar 89 15:44:16 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa, hfsi!pat@uunet.uu.net (Pat)
Subject:   Re: 802.2 implementations.
> *Excerpts from ext.in.tcp-ip: 1-Mar-89 802.2 implementations.*
> *Pat@uunet.uu.net (453)*
>       I read rfc1042 as i was directed by several of your helpful selves
> I found it most enlightening, I was left with some questions which I was
> hoping I could get cleared up.  Is it mandatory to implement the
> XID/TEST commands ?  The rfc says it is not required to support tcp/ip
> but we have to as part of the standard. Has anyone actually done this
> or is practice to merely stuff the 802.2 headers and set MTU to 1492?
All of the implementations that I have seen have supported XID/TEST.  However, I
have never seen it used for anything either.

Implementations on the IBM PC ASI typically give you this support for free.  I
suspect that recent versions of microcode for the TMS380 also do this behind
your back for free, atleast when it is enabled.

My feeling is that XID/TEST implementation should be encouraged, simply because
it may be useful/necessary for some network management applications, especially
of the non-TCP/IP variety.

Drew
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 89 15:45:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  TCP-IP zero checksum
This is soapbox time.  M. van der Zwan asks why checksum is REQUIRED for
TCP.  The answer is very simple.

If you don't have an end-to-end checksum, there will come a time when
your data will be corrupted.  Of the cases that I am aware, these events
involved file (rather than interactive) data and went undetected for
a long-enough period of time to do considerable damage to their users.

Link-level reliability mechanisms are still essential.  The TCP
mechanism is INTENTIONALLY weak.  But, then, it is intended to cover
the cracks.  In particular, a TCP path usually has some portions, such
as the internals of the relay hosts, which are not covered by the
link-level checksum.  Hardware and software in these portions DO,
sometimes, misbehave.  The TCP checksum is quite reasonable at
catching these.

Dave Crocker


-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Mar 89 15:28:46 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet NAWS Option
Is there any telnet server implementation that currently supports the
telnet NAWS option? (RFC1073)

I have a PC client that supports various window sizes, and I need to test 
it with some server.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 89 14:48:24 GMT
From:      inco!mack@uunet.uu.net  (Dave Mack)
To:        tcp-ip@sri-nic.arpa
Subject:   Need Info on VMS TCP/IP

I am looking for information on TCP/IP packages for VAX/VMS 5.0.
I have heard a few rumors about Wollongong's package, not all
of them good, and I've been told that CMU has a package.

I would appreciate it if anyone who has had experience with
these packages could give me your assessment of them, and
if there are other systems in addition to these two, I'd like
to know about them as well.

Also, could anyone tell me how to get the CMU system?

I'll summarize responses in a week or so.

Thanks,
Dave Mack
McDonnell Douglas Electronic Systems Co.
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 89 19:09:08 GMT
From:      spdcc!ftp!jbvb@husc6.harvard.edu  (James Van Bokkelen)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Novell Net with Telnet & FTP
In article <3343@uhccux.uhcc.hawaii.edu>, david@uhccux.uhcc.hawaii.edu (David Lassner) writes:
> ......  Are there any
> cards that are supported for simultaneous use of the Novell
> network OS and NCSA Telnet or other free TCP/IP software?
> -- 
The following vendors support our Packet Driver spec, which allows this
kind of co-existence:

InterLAN		NI5010, NI5210 (built into Netware)
Univation		NC-516 (bare driver, usable w/Netware, Lifenet)
Schneider & Koch	PC-bus and MCA cards (no details, usable w/Netware)
Spider Systems		SpiderMonitor (for add-on TCP/IP sold with it)
Sytek			both Ether and Broadband (no details, usable w/Netware)
TCL			Ethernet board (no details, usable w/Netware)
TRW			PC-2000 (bare driver, tested (but not sold) w/PC/NFS)

In addition, the following should hit the streets soon:

10-Net Communications	200-series, 300-series (bare driver, usable w/10-Net)
FTP Software		Microsoft NDIS/MAC-to-Packet-Driver adapter
Gateway Communications	PC, AT & MCA cards (no details, may not be shipping)
IMC Networks		PC-NIC, PC-NIC II (both bare & built into Netware)

Most of the above are sold bundled with hardware, and sometimes with Netware
and/or TCP/IP.  There will be a few more later this year.

See Russ Nelson's reply for his non-commercial drivers for the WD8003, NI5010,
NI5210 and SLIP over COMn.  They're working on NCSA support at Clarkson, too.

Karl Auerbach added the TRW PC-2000 driver to the Harvard version of PC-IP.

Phil Karn added support for it to KA9Q last Fall.

Kelly Macdonald's people did a version of Netware that calls the P-D.  It has
been given to Novell, for inclusion in the distributed source code, but I don't
know if it is shipping yet.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901





-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 89 21:25:39 GMT
From:      hubcap!ncrcae!wingo@gatech.edu  (Dave Wingo)
To:        tcp-ip@sri-nic.arpa
Subject:   Information needed on Kerberos
can anyone tell me where I might obtain information concerning the Kerberos
authentication model? I understand that MIT has done some research in the area
of secure communications over non-secure networks. Thanks in advance....
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 89 21:53:29 GMT
From:      bzs@Encore.COM (Barry Shein)
To:        comp.software-eng,comp.lang.c,comp.unix.wizards,comp.protocols.tcp-ip,comp.windows.x
Subject:   WORKSHOP ON SOFTWARE MANAGEMENT -- FINAL PROGRAM




		   WORKSHOP ON SOFTWARE MANAGEMENT
				   
		 Sponsored by the USENIX Association
				   
		 David Tilbrook, Barry Shein, Chairs


When:	April 3 & 4 1989
Where:	The New Orleans Hilton, Riverside & Towers Hotel (504-561-0500)
	New Orleans, LA (call for reservations now!)
How:	Registration fee $200, Deadline 3/27/89, peter@usenix.org for more
	details.

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

			    FINAL PROGRAM


Monday	April 3rd

9:00-10:30	Introduction and Keynote Address	Chair: David Tilbrook

		Vic Stenning
		"Project Hygiene"

10:30-11:00	BREAK

11:00-12:30	Version Management I			Chair: Deborah Scherrer

		Steven R. Bourne, Sun Microsystems
		"What a Source Code Control System Should Do"

		Masahiro Honda and Terence Miller, Sun Microsystems
		"Software Management using a CASE Environment"

		Andy Glew, Motorola MCD
		"Boxes, Links, and Parallel Trees"

12:30-2:00	LUNCH

2:00-3:30	Version Management II			Chair: Kirk McKusick

		Peter Costantinidis, Jr. and Hamish Reid, Unisoft Corp.
		"The DV System of Source File Management"

		Dale Miller, Sterling IMD
		"Controlling Software for Multiple Projects"

		Mel Pleasant and Eliot Lear, Rutgers University
		"Transcending Administrative Domains by Automating
		System Management Tasks in a Large Heterogeneous
		Environment"

3:30-4:00	BREAK

4:00-5:30	Testing					Chair: Barry Shein

		Barton P. Miller, Lars Fredriksen and Bryan So
		Computer Sciences Dept, University of Wisconsin, Madison
		"An Empirical Study of the Reliability of Operating
		System Utilities"

		Evi Nemeth, University of Colorado, Boulder
		Panel Discussion

Tuesday	April 4th

9:00-10:30	Installation & Configuration Management	Chair: David Tilbrook

		Russel Brand and D. Brent Chapman,
		Lawrence Livermore National Laboratories
		"RAPID: Remote Automated Patch Installation Data Base"

		Susan A. Dart and Peter Feiler
		Software Engineering Institute
		"Configuration Management of an Environment"

		Tan Bronson, Microvation
		"The CCSLAND Configuration Control System"

10:30-11:00	BREAK

11:00-12:30	Release Engineering			Chair: Deborah Scherrer

		Kirk McKusick, CSRG, University of California, Berkeley
		"The Release Engineering of 4.3BSD" (?)

		Don Davis, MIT Project Athena
		"Project Athena's Release Engineering Tricks"

		Jim Fulton, X Consortium, MIT LCS
		"Configuration Management in the X Window System"

12:30-2:00	LUNCH

2:00-3:30	Miscellaneous Topics			Chair: Kirk McKusick

		Paul R. Eggert,	Unisys Corporation
		"Automating the Importation of Software"

		Andrew Hume, AT&T Bell Laboratories
		"The Use of a Time Machine to Control Software"

		Peter Nicklin, Hewlett-Packard
		"Experiences Using a Hypertext Framework to Manage Software"

3:30-4:00	BREAK

4:00-5:30	The Grand View				Chair: Barry Shein

		David Tilbrook, Nixdorf Corp.
		"Under Ten Flags: Software Management on Many Different
		Unix Systems"
		
		Panel Discussion and Wrap-up

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Mar 89 12:34:24 -0500
From:      dardy@itd.nrl.navy.mil (Hank Dardy)
To:        tcp-ip@sri-nic.itd.nrl.navy.mil
Cc:        dardy@cmf.nrl.navy.mil
Subject:   Re: Information needed on Kerberos
Documentation and source are available via anonymous ftp from
athena-dist.mit.edu. The package contains several postscript
printable articles that explain the architecture and design
philosophy.

Hank
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sun, 05 Mar 89 08:59:42 EST
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        Dave Crocker <dcrocker@TWG.COM>
Cc:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re: TCP-IP zero checksum

Dave,

Sometimes the converts have to get burned or someone else has to get burned
and then burn the non-converts...

We had a problem with someone using a terminal line...he was getting garbage
displayed on his computer screen but things seem to work. The terminal line
was checked out and the computer terminal was checked out.

It turned out the terminal was connected to a terminal box which connected to
our ethernet. It used the old protocol of Xerox BSP/PUP which had the 
required checksum (which could be overridden by using zero). Well, the builder
of the system didn't believe in checksums (wasted cpu time he said) and did
not check them on input.

We effectively had a three part failure when we determined what the cause of
the garbage display data was...
	- checksums were not checked
	- the error bit indicating a problem with the incoming packet was
	  not checked in the device driver and therefore a bad packet was
	  processed.
	- there was a minor hardware problem with the ethernet device for
	  a certain computer pair.

Overall, I have seen only one bad experience with the TCP checksum. Certain
bit failures are not detected and guess what? we had about 100 or so
computers that use ethernet boards that would cause this certain bit
failure.

You can't win them all.

-Rudy






-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Sun,  5 Mar 89 16:39:43 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa, Brad Clements <bkc@omnigate.clarkson.edu>
Subject:   Re: Telnet NAWS Option
> *Excerpts from ext.in.tcp-ip: 3-Mar-89 Telnet NAWS Option Brad*
> *Clements@omnigate.c (346)*
> Is there any telnet server implementation that currently supports the
> telnet NAWS option? (RFC1073)
> I have a PC client that supports various window sizes, and I need to test
> it with some server.
lancaster.andrew.cmu.edu (128.2.13.21) sports such as server.  Anyone who has a
telnet client with such support can test it by telnet'ing to lancaster and
logging in with user "stty".  Hit CR/NL/Enter at the password prompt and ignore
the two lines of garbage.  It should then run "stty all" showing you your
terminal speed, rows, columns, etc.

You can pick up your own telnetd using anonymous ftp to lancaster.  Get
pub/telnetd.tar (in binary mode).  This telnetd source includes support for
Terminal Speed, Remote Flow Control and Window Size.  Credit goes to Chuck
Hedrick (Rutgers) for the first two and Greg Satz (Cisco) for the third.

Drew
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 89 18:16:35 GMT
From:      leah!rpi!sun.soe.clarkson.edu!valdis@csd4.milw.wisc.edu  (& Kletnieks)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
I dunno, I might be missing something, but I think the original query was
NOT why tcp/ip requires checksums, but why said checksum is not allowed
to evaluate to zero (looks like if it checksums to zero, it jams in an
all-ones pattern)...

				Valdis Kletnieks
				Sr. Systems Programmer
				Clarkson University
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Mar 89 23:44:32 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Slip support for Sun 386 Sun OS 4.01
Has anyone gotten slip to work with Sun OS 4.01 (object only) on a 386i
machine (or any other Sun machine under OS 4.01)?

I'm all set to add the slip package that was posted to USENET at the end
of last year, only there is no  tty_conf.c file on my system.
(Nor tty_conf.o) so I don't know where to place the entry points
for if_sl.c (when the IOCTL calls are made into the tty driver, the SLIPDISC
has to be vectored somewhere...)

Does anyone know how to go about adding the slip discipline into the tty
driver without having source?  Or do I have to make slip a real pseudo
device (with its own major and minor) and change slattach to access
the device directly?  Can that even be done?

Any help would be appreciated.  I'm also currently trying to patch in support
for traceroute.. This requires a new raw_ip.c (output) function, but I don't
have the raw_ip.c source... so I'm using raw_ip.c from the Van Jacobson mods
package from berkeley... Has anyone else tried this and gotten it to
work?


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 89 23:49:21 GMT
From:      mah@hpuviea.UUCP (Michael Haberler)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   BOOTPD (rfc1048) source needed

Could some kind soul send me the source for a rfc1048 style bootp 
server for BSD style Unix? 

thanks in advance,
-michael
-- 
Michael Haberler		mah@hpuviea.uucp 
Hewlett-Packard Austria GmbH, 	...mcvax!tuvie!hpuviea!mah
Lieblgasse 1 			...hplabs!hpfcla!hpbbn!hpuviea!mah
A-1220 Vienna, Austria		Tel: (0043) (222) 2500 x412 (9-18 CET) 	

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Mar 89 08:36:08 -0500
From:      Andy Malis <malis@BBN.COM>
To:        Mink van der Zwan <mcvax!hp4nl!targon!nixvia!mink@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa, malis@BBN.COM
Subject:   Re: TCP-IP zero checksum
Mink,

Because the TCP checksum uses ones-complement arithmetic, the
binary values 0 and all ones (-1 in twos-complement) both equal
the value "zero".  Thanks to the end-around carry, either version
of "zero", added to any number, gives you that number back (try
it!).

Given this property, if TCP checksums are in use, only the all
ones version of "zero" is allowed in the checksum field.  A 0 in
the TCP checksum field signifies that a checksum was not computed
on the sending side and should not be checked on the receiving
side.

This isn't mentioned in the RFCs (at least that I could find in a
quick glance) but is a "well-known" procedure.

Andy
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Mon,  6 Mar 89 10:09:27 -0500 (EST)
From:      "Bruce R. Miller" <bm17+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Telnet NAWS Option
> *Excerpts from ext.in.tcp-ip: 5-Mar-89 Re: Telnet NAWS Option Drew Daniel*
> *Perkins@andr (947)*
> > *Excerpts from ext.in.tcp-ip: 3-Mar-89 Telnet NAWS Option Brad*
> > *Clements@omnigate.c (346)*
> > Is there any telnet server implementation that currently supports the
> > telnet NAWS option? (RFC1073)
> > I have a PC client that supports various window sizes, and I need to test
> > it with some server.
> lancaster.andrew.cmu.edu (128.2.13.21) sports such as server.  Anyone who has a
> telnet client with such support can test it by telnet'ing to lancaster and
> logging in with user "stty".  Hit CR/NL/Enter at the password prompt and ignore
> the two lines of garbage.  It should then run "stty all" showing you your
> terminal speed, rows, columns, etc.
There is another machine right down the hallway from lancaster
which also supports the NAWS option.  The machine's name is
spiff.andrew.cmu.edu (128.2.232.18) and it's a Vaxstation II running
VMS 5.02 and Unipress EMACS (which works with the resize).
The Telnet server is willing to do window size negotiation in both
directions but will only explicitly ask for the client to turn his side on.
Anyone who want to test a client with NAWS capability can
Telnet into the GUEST account which has no password.

I've also implemented support for the Remote_Flow_Control
option on this server.

Bruce R. Miller
(bm17@andrew.cmu.edu)
CMU Network Development

P.S.  I can not insure the stability of the Telnet server on Spiff.
It's still under development and may not be in top form when
you try it out.  For that matter, I may not even have TCP/IP
running on Spiff when you try to connect.  If this is the case,
try again later.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 03:11:40 GMT
From:      dave@galaxia.Newport.RI.US (David H. Brierley)
To:        comp.protocols.nfs,comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   Re: PCNFS Problems

In article <499@corona.pb> mssoft@pbinfo.UUCP (Software r/o) writes:
>
>I have some problems with PCNFS 3.0 !
>All works fine except RCP direction SUN to PC. 

I seem to recall a problem like this when I upgraded from 2.0 to 3.0.  I
reported the problem to SUN and they basically told me "fixed in the next
release", or to be more precise "un-broken in the next release".  The
reason that I say "un-broken" is that everything worked fine under 2.0 and
as a stop-gap solution your can retrieve the rcp/rsh binaries from a 2.0
distribution.  The person I was dealing with at SUN was almost in shock (or
was that almost in stitches) when I told him I had gotten everything
working by reloading the 2.0 programs on top of the 3.0 system (we wanted
to upgrade to 3.0 for some of the other features).  If you want more info
on exactly what problems we encountered and how we fixed them, send mail to
me at the "work" address listed below and I will attempt to dig up the
files.
-- 
David H. Brierley
Home: dave@galaxia.Newport.RI.US   {rayssd,xanth,lazlo,jclyde}!galaxia!dave
Work: dhb@rayssd.ray.com           {sun,decuac,gatech,necntc,ukma}!rayssd!dhb

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 04:29:00 GMT
From:      mailrus!caen.engin.umich.edu!conliffe@tut.cis.ohio-state.edu  (Darryl C. Conliffe)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: DEC-VAX ALL-IN-ONE
In article <8903011831.AA00709@ucbvax.Berkeley.EDU>, mcdaniel%afsc02.decnet@HQAFSC-VAX.ARPA ("AFSC02::MCDANIEL") writes:
> 
> REQUEST FOR HELP:  DEC-VAX "ALL-IN-ONE"
> 
> PRESENTLY, I AM A USER ON A DEC-VAX SYSTEM USING THE "ALL-IN-ONE"
> OPERATING SYSTEM.  THE RECENT PROBLEM I HAVE EXPERIENCED IS WITH
> THE "ALL-IN-ONE" SYSTEM CONVERTING ALL "MAILBOX USER NAMES" TO
> UPPER CASE AND CANNOT SUPPORT "lower-case" SENSITVE MAILBOX 
> NAMES.

 [ stuff deleted ]
> 
> RODNEY A. MCDANIEL

Have encountered same problem and same answer, Rodney.  It is true
also with file names; A1 forces lower to upper there, too.  My
interface to other systems is via an Ultrix uVax, with DECNET on
one side, "UNIX" on the other.  File transfer is effected by
defining a logical device (the UNIX target host connected on
the other side of the Ultrix node) and pushing quoted filenames
to the logicial device.

The modification seems
trivial if DEC would make the fix, 
and expensive if each local site must.

That, of course, presumes DEC wants you to be able to do it.

However, calling ALL-IN-ONE an operating system is a little extreme;
it looks more like an office automation product - editor, mailer,
calendar, etc.

While I don't think this should be discussed here, is there a better
place?

-- 
___________________

 Darryl C. Conliffe  conliffe@caen.engin.umich.edu  (313) 721-6069
-------------------
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Mar 89 12:44:28 PST
From:      braden@venera.isi.edu
To:        malis@bbn.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
	
	Given this property, if TCP checksums are in use, only the all
	ones version of "zero" is allowed in the checksum field.  A 0 in
	the TCP checksum field signifies that a checksum was not computed
	on the sending side and should not be checked on the receiving
	side.
	
Andy,

The TCP checksum is NOT optional, although the UDP checksum is.

   Bob Braden
   	
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1989 14:30-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Andy Malis <malis@BBN.COM>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
	A 0 in the TCP checksum field signifies that a checksum was not
	computed on the sending side and should not be checked on the
	receiving side.

I believe that a zero checksum means "no checksum computed" in the case of
UDP only.  The checksum is not optional for TCP; the zero value and all-ones
value should be treated as equivalent by a TCP receiver.  A TCP sender should
send only the all-ones version, because some TCP receivers mistakenly
interpret a zero value as "no checksum computed".

Steve Deering
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 06:50:56 GMT
From:      cos!howard@uunet.uu.net  (Howard C. Berkowitz)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: 802.2 implementations.
In article <gY3jYUy00UoJ4C7p0Y@andrew.cmu.edu>, ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes:
> >       I read rfc1042 as i was directed by several of your helpful selves
> > I found it most enlightening, I was left with some questions which I was
> > hoping I could get cleared up.  Is it mandatory to implement the
> > XID/TEST commands ?  The rfc says it is not required to support tcp/ip
> > but we have to as part of the standard. Has anyone actually done this
> > or is practice to merely stuff the 802.2 headers and set MTU to 1492?
> All of the implementations that I have seen have supported XID/TEST.  However, I
> have never seen it used for anything either.
> 
> My feeling is that XID/TEST implementation should be encouraged, simply because
> it may be useful/necessary for some network management applications, especially
> of the non-TCP/IP variety.


While not strictly a network management application, there is use of
XID/TEST in OSI work, specifically conformance testing.  (Personal
opinion here -- conformance testing is a special case of the fault
management functional area of fault management)

XID and TEST are used in current COS conformance testers for 
MAC sublayer protocols (i.e., 802.3 and 802.4).  
We use LLC as a "reflector" upper tester above MAC, 
which avoids requirements for modifying products by putting
"test hooks" above the MAC implementation.

Experience with this use of XID and TEST is being submitted to 
IEEE and other appropriate organizations.


-- 
howard@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [W] (703) 998-5017 [H]
DISCLAIMER:  Opinions expressed are not necessarily those of the Corporation
for Open Systems, its members, or any standards body.
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Mar 89 15:53:56 -0500
From:      Andy Malis <malis@BBN.COM>
To:        braden@venera.isi.edu
Cc:        malis@BBN.COM, tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
Bob,

Thanks for jogging my memory.  THAT'S where I read about forcing
a zero checksum to all ones in the checksum field - RFC 768, p. 2.

Andy
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 08:06:47 GMT
From:      mcvax!kth!draken!umecs!roland@uunet.uu.net  (Roland Hedberg)
To:        tcp-ip@sri-nic.arpa
Subject:   I want some information about NQS
Hi!

As I said on the subject line, I would like to get some information 
about the Network Queue System ( if I have got it right ).
NQS is supposed to be a remote jobentry system ontop of tcp/ip.
Pointers to documents describing NQS or even better pointers to PD 
software implementing it, is very wellcome.

Please answer by mail .

-- Roland
_______________________________________________________________________
Roland Hedberg, UMDAC, University of Ume, Sweden.
Internet : roland@umu.se
Bitnet/Earn : rhg@seumdc51
-- 
===========================================================================
Roland Hedberg, Department of Info. Proc., University of Umea, Sweden
UUCP:  ...mcvax!enea!luth!umecs!roland
BITNET/EARN: RHG@SEUMDC51
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 13:30:54 GMT
From:      amdcad!rpw3@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: wither slow-start?
In article <6200017@hpindda.HP.COM> raj@hpindda.HP.COM (Richard Jones) writes:
+---------------
|   Is it 'OK' to not 'slow-start' in the case where you know that the remote
| is directly connected to 'your' lan on the assumption that you cannot
| congest a lan?
+---------------

This is not safe in the general case. There are many older Ethernet controllers
that simply cannot accept a "window"-sized burst of packets without dropping
some.  Slow-start is a big win if you have any of these on your local net.

+---------------
| Also, is it realisticly possible to flood things like bridges and repeters?
+---------------

It is not possible to overrun a true repeater. It *is* possible to overrun
some bridges, especially if there is a slower point-to-point link between them.
It is also possible (in the worst case) to overrun even a fast bridge between
two equal-speed LANs, if the destination LAN is very busy with local (to it)
traffic.

Use slow-start. It wins. And the "start" is not all that "slow"...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 16:32:22 GMT
From:      hpfcdc!hpldola!hpctdlb!jpeck@hplabs.hp.com  (Joe Peck)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ping info


> I have
> a HP 4792A lan analyzer which I would like to use to ping various hosts on
> the net and monitor their response using the analyzer as the source.  

The latest revision to the HP 4972 LAN analyzer added a TCP/IP decode
package.  Included in this package are many canned program setups, including
one to send ICMP echo request packets and capture the response.  The response
time is measured, the packets can be logged to disc, and counters for
requests and responses are maintained.  There is also documentation to
help you modify the ICMP echo message.  (ping uses ICMP echo messages) 

What you need to do is fill in the IP address and the ethernet address
fields of the message.  After doing this you need to make sure the checksum
fields are correct.  The Ethernet checksum is computed automatically by
the HP4972.  To determine the correct IP checksum, send out the packet
and have the HP4972 capture it.  The IP decode will show that the packet has
a bad checksum and will show what the correct ckecksum is.  This will be
much easier than computing the IP checksum manually.  To make it easier
to set up the message, you can use an IP filter template to format it.

Many of you may not be aware of the TCP/IP protocol decodes available 
for the HP4972 LAN analyzer.  Someone mentioned it here last month, at
which time another person denied its existence.  I just want to say
the decodes are avaliable, and really increase the power of the analyzer.
I just got back from Uniforum, where we used it to debug the show network.
We were able to find all sorts of strange protocol problems and track them
to specific hosts.  There were ICMP redirects of the broadcast address 
to the broadcast address, continuous ARPs from one host, and even a traffic 
generator that added 50% load to the net.  It was a lot of fun and very 
interesting.


Joe Peck
Colorado Telecommunications Division
Hewlett Packard

Disclaimer - I worked on the HP 4972 LAN analyzer and after using it
             at Uniforum, I'm convinced it's the best analyzer on the
             market.  Protocol interpreters alone aren't enough, you
             need flexible debugging tools to go with them.
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 89 18:48:48 GMT
From:      emv@a.cc.umich.edu (Ed Vielmetti)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: BOOTPD (rfc1048) source needed

In article <863@hpuviea.UUCP> mah@hpuviea.UUCP (Michael Haberler) writes:
>Could some kind soul send me the source for a rfc1048 style bootp 
>server for BSD style Unix? 

Such a beast is ftp'able from lancaster.andrew.cmu.edu in the bootp directory.
The credits go to Bill Croft, Walter Wimer, and Drew Perkins.

--Ed

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 89 02:31:27 GMT
From:      encore!cloud9!cme@bu-cs.bu.edu  (Carl Ellison)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
In article <VALDIS.89Mar5131635@alchemy.mcs.clarkson.edu>, valdis@alchemy.mcs.clarkson.edu (& Kletnieks) writes:
> I dunno, I might be missing something, but I think the original query was
> NOT why tcp/ip requires checksums, but why said checksum is not allowed
> to evaluate to zero (looks like if it checksums to zero, it jams in an
> all-ones pattern)...


Could this be a hold-over from the days of 1's complement arithmetic?

(I know --

 I'm admitting my age)


--Carl Ellison                      UUCP::  cme@cloud9.Stratus.COM
SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752
Disclaimer::  (of course)
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Mar 89 16:16:18 -0800
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        tcp-ip@sri-nic.arpa
Cc:        postmaster@twg.com
Subject:   TWG SMTP Configuration
Could someone help me with what is probably an operator error--mine.  There may
be several problems.  Mail is being generated on a VAX11/750 running 4.3BSD and
be transmitted to a VAX8250 running VMS 4.7 with WIN/TCP 3.2.  Mail sent to a
user that is not logged in is bounced back to the sending system.  There is no
node name in the From line causing the message to be appended to the previous
message in the sender's mailbox on the 4.3BSD system.  What is needed to cause
the node name to be inserted into the From line for returned mail?

The second question is why is the mail being bounced when sent to a valid user?
Do user names have to be in SMTP.CONF?  What record type (MA, MB) do they have
to be if required?

Merton
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Mar 89 16:44:02 -0800
From:      James M Galvin <galvin@TWG.COM>
To:        Merton Campbell Crockett <mcc@etn-wlv.eaton.com>
Cc:        tcp-ip@sri-nic.arpa, postmaster@TWG.COM
Subject:   Re: TWG SMTP Configuration
> Mail is being generated on a VAX11/750 running 4.3BSD and
> be transmitted to a VAX8250 running VMS 4.7 with WIN/TCP 3.2.  Mail sent to a
> user that is not logged in is bounced back to the sending system.  There is
> no node name in the From line causing the message to be appended to the
> previous message in the sender's mailbox on the 4.3BSD system.  What is
> needed to cause the node name to be inserted into the From line for returned
> mail?

I assume from your message that when the user is logged in they do receive
their mail.

When you say there is no node name in the From line, which From line?  The one
in the returned message or the one in the original message?

> The second question is why is the mail being bounced when sent to a valid
> user?  Do user names have to be in SMTP.CONF?  What record type (MA, MB) do
> they have to be if required?

Can you send a copy of a failed message?  There should be some indication in
the message as to why it failed.

User names do not have to be in the SMTP.CONF file.

This conversation need not continue on the tcp-ip mailing list.  If you would
respond to this message directly to "postmaster@twg.com" and to
"support@twg.com", I will see that your problem is resolved.

Jim
Postmaster at TWG
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 89 06:01:28 GMT
From:      fernwood!asylum!romkey@decwrl.dec.com  (John Romkey)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
In article <8903062207.AA06130@ucbvax.Berkeley.EDU> malis@BBN.COM
(Andy Malis) writes about how TCP checksums are optional and a 0 means
to not check the checksum.

NO. TCP checksums are MANDATORY. This is not a well-known feature. The
UDP checksum is indeed optional; UDP is a datagram oriented service,
and an application using it might want to use a different error
checking algorithgm better suited to that application, so UDP
checksums may be disabled.

You MUST compute the TCP checksum for every TCP packet, and verify
it. The reason you didn't find the part about it being optional in an
RFC is because it's not.

But given this, I'm at a loss to answer the original question.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@xx.lcs.mit.edu
"Can you find me soft asylum..." - The Doors
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Mar 89 13:52:36 EST
From:      "Timothy G. Smith (Systems Staff)" <tsmith@USNA.MIL>
To:        tcp-ip@sri-nic.arpa
Subject:   bind woes
I need some help with bind.

The situation is this:

"gateway.usna.navy.mil" is the primary server for "usna.navy.mil".
"gateway" has been set up to have another hosts be a primary for a
subdomain of "usna.navy.mil". We will want to do this with a couple of
our subdomains as time goes on. For the current example "gateway" has
NS and A records for the subdomain "nadn" which points to
"nadn2.nadn.usna.navy.mil". "nadn2.nadn.usna.navy.mil" has an SOA
record for "nadn.usna.navy.mil" and all of the appropriate local data.
[ as an aside I have "gateway" acting as a secondary for
"nadn.usna.navy.mil"- is this a good or bad thing? Might this be
breaking something? ]

The problem is that when "nadn2" is given a hostname like "cad" or
"cad.usna.navy.mil." it eventualy determines that it has to ask some
other host for the data and times out trying.

For quite some time this setup was working fine. It seems to have
broken during the latest milnet/arpanet meltdown. As it stands right
now all hosts at usna that are not directly connected to milnet cannot
reach milnet (this will be the subject of a future message). I
theorized that maybe "nadn2" was trying to contact a root server to
determine who is responsoble for the domain "usna.navy.mil" and dies
when it can't. 

It is my opinion that "nadn2" should now that "usna.navy.mil" is a
local domain and is handled by a local host. I have recently tried
sticking an entry for "usna.navy.mil" into the root cache on "nadn2"
which does show up in the dumps of the database but "nadn2" still
times out on requests to "*.usna.navy.mil". 

Any ideas on what is wrong and how to fix it?

thanks,
	Tim Smith		
US mail:ECSD/CADIG mailstop: 11G	E-mail:
	US Naval Academy		internet:tsmith@USNA.MIL
	Annapolis, MD 21402		uucp	:...!uunet!usna!tsmith
MaBell :(301)267-4413
					

PS: attached are some relavent files from "gateway" and "nand2".
; --------------------
; /etc/named.boot from gateway.usna.navy.mil
;
directory /usr/usna/etc/named
domain		USNA.NAVY.MIL
cache		.			root
primary		USNA.NAVY.MIL		usna/usna.mil
primary		31.12.192.in-addr.arpa	usna/enet.rev
primary		56.128.in-addr.arpa	usna/usnanet.rev
primary		0.0.127.in-addr.arpa	usna/local
;
;
; These lines are for us to be a secondary for NADN.USNA.MIL 
secondary	NADN.USNA.NAVY.MIL	131.121.1.2 nadn/nadn.usna.mil
secondary	121.131.in-addr.arpa	131.121.1.2 nadn/nadn.rev
;--------------------
; /usr/usna/etc/named/usna/local from gateway.usna.navy.mil
;
@		IN	SOA	usna.navy.mil. hostmaster.CAD.USNA.MIL. (
			890109  ; Serial
			3600    ; Refresh
			300     ; Retry
			3600000 ; Expire
			3600 )  ; Minimum
		IN	NS	gateway.usna.navy.mil.
1		IN	PTR	localhost.usna.navy.mil.
nadn		IN	NS	nadn2.nadn
nadn2.nadn	IN	A	131.121.1.2
; --------------------
; /etc/named.boot from nadn2.nadn.usna.navy.mil
;
;	4.7.3 Named boot file 03/30/88 GB
;
directory	/etc
primary		0.0.127.IN-ADDR.ARPA	/etc/named.local 
primary		nadn.usna.navy.mil.	/etc/nadn2.hosts
primary		121.131.IN-ADDR.ARPA	/etc/nadn2.hosts.rev
cache		.			/etc/root.cache
; --------------------
; /etc/named.local from nadn2.nadn.usna.navy.mil
;
@	IN	SOA	nadn.usna.navy.mil.	nadn2.nadn.usna.navy.mil.  (
			880606      ;Serial
			3600   ;Refresh
			300    ;Retry
			3600000;Expire
			3600 )  ;Minimum
	IN	NS	nadn2.nadn.usna.navy.mil.
1	IN	PTR	localhost.
; --------------------
; /etc/root.cache from nadn2.nadn.usna.navy.mil
;
; Initial cache data for root domain servers.
;
.		99999999	IN	NS	BRL-AOS.ARPA.
		99999999	IN	NS	SRI-NIC.ARPA.
		99999999	IN	NS	NS.NASA.GOV.
		99999999	IN	NS	A.ISI.EDU.
		99999999	IN	NS	GUNTER-ADAM.ARPA.
		99999999	IN	NS	C.NYSER.NET.
		99999999	IN	NS	TERP.UMD.EDU.

;  The LAST root server (previous line) is consulted FIRST.

;  Prep the cache (hotwire the addresses).  FIRST addr used FIRST.
SRI-NIC.ARPA.		99999999	IN	A	26.0.0.73
SRI-NIC.ARPA.		99999999	IN	A	10.0.0.51
A.ISI.EDU.		99999999	IN	A	26.3.0.103
BRL-AOS.ARPA.		99999999	IN	A	192.5.25.82
BRL-AOS.ARPA.		99999999	IN	A	128.20.1.2
GUNTER-ADAM.ARPA.	99999999	IN	A	26.1.0.13
C.NYSER.NET.		99999999	IN	A	192.33.4.12
TERP.UMD.EDU.		99999999	IN	A	10.1.0.17
TERP.UMD.EDU.		99999999	IN	A	128.8.10.90
NS.NASA.GOV.		99999999	IN	A	128.102.16.10
LOCALHOST.		99999999	IN	A	127.0.0.1
;
; Initial cache data for usna domain servers.
;
usna.navy.mil.	99999999	IN	NS	gateway.usna.navy.mil.

gateway.usna.navy.mil.	99999999	IN	A	128.56.1.1
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 89 16:06:53 GMT
From:      suned1!efb@elroy.jpl.nasa.gov  (Everett F. Batey II)
To:        tcp-ip@sri-nic.arpa
Subject:   TWG 3.2 chokes on my named.hosts
Using TWG WIN/TPC 3.2 on MV_2, VMS 4.6. PROBLEM: Trying to run named Gags
on named.hosts lines and refers to line numbers.

Do numbers include comment lines ?

What ( besides spare trailing spaces ) make good problems ??

We followed the examples .. Is ther a way beyond boot time to get the diagnostic
messages from reading named.hosts.  NETADMIN NAMED RELOAD doesn't do it.

Thank you for any help .. /Ev/
-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
    efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
      Statements, Opinions ... MINE ... NOT those of my US Employer  
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 89 17:11:14 GMT
From:      holmes@WDL1.FAC.FORD.COM  (Randy D Holmes)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ping info

      A problem i see is, the remote machine does not know the ethernet
      address of your analyzer. You send a ping, the remote machine sends an
      ARP and your machine does not reply, so the echo response never gets sent.
      Look for an ethernet broadcast with your IP address (i dont know the
      exact format) but this should be the ARP packet, now just build a response
      to that and send it, then your echo response should return.

      Randy
      holmes@wdl1.fac.ford.com
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Mar 89 18:06:53 +0000
From:      Yuko Murayama (+44-1-387-7050 ext.3695) <Y.Murayama@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Cc:        murayama@Cs.Ucl.AC.UK
Subject:   the Chaosnet

Could anyone tell me what the Chaosnet is and where I can
find the information about it, please?

Yuko Murayama
Dept of Computer Science
UCL
e mail: murayama@cs.ucl.ac.uk
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 89 18:30:39 GMT
From:      ingr!jones@uunet.uu.net  (Mark Jones)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
In article <8903031752.aa11088@Obelix.TWG.COM>, dcrocker@TWG.COM (Dave Crocker) writes:
> This is soapbox time.  M. van der Zwan asks why checksum is REQUIRED for
> TCP.  The answer is very simple.

> Dave Crocker

Wait a minute BOZO!  He asks why can't the checksum be zero.  He
does not ask why the checksum is REQUIRED.  Learn to read or learn to BURN.

Mark Jones
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Mar 89 02:02:48 EST
From:      wneugent@mwunix.mitre.org
To:        tcp-ip@sri-nic.arpa
Subject:   Kerberos
I am in need of references or phone numbers by which I can find out
something about Kerberos from MIT.  I'm especially interested in
capabilities it provides for central security authentication and
audit management.  Please send replies to WNeugent@MITRE.ARPA.
Thanks,
Bill
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 89 21:36:52 GMT
From:      spdcc!eli@bbn.com  (Steve Elias)
To:        tcp-ip@sri-nic.arpa
Subject:   Ethernet type fields which conflict with 802.3 length fields
can anyone give me any news regarding the ethernet type fields which
were apparently assigned before anyone thought of 802.3?

the Urbaniak ethernet type list only shows two such types, 
both of them assigned to Xerox PUPs.  each of these two "dog" types
have been reassigned to types in the legal ethernet range.  

the real essence of my query is whether there are any networks
out there which use these PUP (woof) type assignments or any other
type assignments which are less than 1500 decimal.

feel free to reply to me any way you like... 
or send dog biscuits to Xerox :)


-- 
   Steve Elias (chipcom!eli@spdcc.com);((6172399406)%(6178906844)) (smile^3) 
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 00:23:42 GMT
From:      rennet.cs.wisc.edu!stuart@speedy.wisc.edu  (Stuart Friedberg)
To:        tcp-ip@sri-nic.arpa
Subject:   Pointer to ARPAnet NOC data?
I'm planning some WAN simulations.  I'd like use the 60+ IMP Arpanet
topology (prior to its de-construction) but I don't know who to contact
in the NOC.  Where should I send a request for "real" Arpanet topology,
link bandwidths, and link latencies?  (Transmission, not congestion, delays.)

Stu Friedberg  (stuart@cs.wisc.edu)
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 00:42:42 GMT
From:      bbn.com!cdh@bbn.com  (Carl D. Howe)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum
I think the rational about always using the FFFF version of 0 in the
ones-complement checksum of TCP was that it prevented an all-zeros
packet from being legal.  Therefore, if some interface or memory
fed you a packet containing all zeros, you knew it was illegal, since
a correct all-zeros packet would have checksum FFFF.

Of course, I could be wrong.

Carl
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 08:46:00 CST
From:      <hacke@mdc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Network Analysis/Simulation

We are doing some formal network analysis on an Ethernet design.  We need
a work load characterization of TCP/IP.

Do you know of any references (written or people) on TCP/IP analysis/simulation.
We need information to characterize TCP, such as TCP performance studies, how it
does flow control, where the delays in transmission are, etc.  It seems there
must be lots of material on this from TCP conferences.

We also want the analysis based on the user TELNET traffic comming off the
MILNET.  There will be occasional large file transfers through to other
MILNET sites.  

Do you know of any similar studies?  Any information will help!

Thanks
Keith Hacke
hacke@mdc.com
314-895-5343


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 02:51:26 GMT
From:      vsi1!wyse!rc@apple.com  (Ran-Chi Huang x1537 dept302)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: the Chaosnet
In article <8903072030.AA14877@ucbvax.Berkeley.EDU> Y.Murayama@CS.UCL.AC.UK writes:
>
>Could anyone tell me what the Chaosnet is and where I can
>find the information about it, please?

As far as I know, Chaosnet is used principally at MIT and on Symbolic
workstations. This may not be accurate, but for a start, you might want to
send mail to postmaster@bitsy.mit.edu for further information.

Regards

-rc

Ran-Chi
Ran-Chi Huang
Wyse Technology                 VOICE: (408) 433-1000 x1537
3571, N. First Street           ARPA:  rc@wyse.com  OR  rc@caf.mit.edu
San Jose, CA 95134              UUCP:  ...!{uunet}!wyse!rc
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 02:54:42 GMT
From:      sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu  (Russ Nelson)
To:        tcp-ip@sri-nic.arpa
Subject:   MTU question
Some people at brl.mil, amsaa-seer.brl.mil, and
notecnirp.princeton.edu have had trouble FTPing from
grape.ecs.clarkson.edu, which was using an MTU of 1500.  I asked our
local network guru, and he said that the MTU for the Internet should
be less than 1024.  As expected, reducing the MTU to 1000 eliminated
those problems.

In an unrelated matter, I was told by Phil Karn that there is no maximum
MTU for the Internet, and that someone's gateway or host software is broken.

Now, I'm happy enough using 1000 as the MTU, but does this problem have any
other ramifications for other hosts?  Maybe people just need to be aware
that some gateways and/or hosts cannot deal with MTUs larger than 1000?

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lama
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Mar 89 12:26:03 -0500
From:      Ed Frankenberry <ezf@BBN.COM>
To:        wneugent@mitre.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Kerberos
This message appeared on the TCP-IP list recently.
	Ed Frankenberry

================================================================

Date:    Thu, 26 Jan 89 22:17:11 EST
To:      tcp-ip@SRI-NIC.ARPA
From:    Jon Rochlis <jon@BITSY.MIT.EDU>
Subject: MIT Athena Kerberos Authentication System available for FTP



What is Kerberos and why is it needed?

In an open network computing environment a workstation cannot be
trusted to identify its users correctly to network services.  Software
on the workstations may not be trustworthly, so being a privileged
user on a workstation is not a meaningful test of authenticity.
Source network addresses are so easily forged that they are are
meaningful either.  Passwords sent uncrypted on the network are
vulnerable to wiretappers.  Kerberos provides an alternative approach
whereby a trusted third-party encryption-based authentication service
is used to verify users' identities.  Much more information is
available with the documentation (see below).

How to get it:

The first public release of the Kerberos Authentication System is ready
for retrieval.  Initial distribution will be by anonymous
FTP; eventually 9-track tapes will be available.

To retrieve the distribution, ftp to ATHENA-DIST.MIT.EDU (18.71.0.38),
login as anonymous (password whatever you like, usually your
username@host), then cd to pub/kerberos.

Retrieve README.ftp, it has directions on how to get to the rest of the
software.

Distribution is split compressed tar files (xxx.Z.aa, xxx.Z.ab, ...).

If you would like to retrieve documents separately, you can get them
from pub/kerberos/doc (documents) or pub/kerberos/man (manual pages).
If you prefer hardcopy of the documentation, send your address and request
to "info-kerberos@athena.mit.edu".

If you would like to be put on the Kerberos e-mail list
("kerberos@athena.mit.edu"), send your request to
"kerberos-request@athena.mit.edu".

I would like to thank the following people for their assistance in
getting Kerberos in shape for release:

Andrew Borthwick-Leslie
Bill Bryant
Doug Church
Rob French
Dan Geer
Andrew Greene
Ken Raeburn
Jon Rochlis
Mike Shanzer
Bill Sommerfeld
Jennifer Steiner
Win Treese
Stan Zanarotti

FYI, the copyright notice:

  Copyright (C) 1989 by the Massachusetts Institute of Technology

   Export of this software from the United States of America is assumed
   to require a specific license from the United States Government.
   It is the responsibility of any person or organization contemplating
   export to obtain such a license before exporting.


WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
distribute this software and its documentation for any purpose and
without fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright notice and
this permission notice appear in supporting documentation, and that
the name of M.I.T. not be used in advertising or publicity pertaining
to distribution of the software without specific, written prior
permission.  M.I.T. makes no representations about the suitability of
this software for any purpose.  It is provided "as is" without express
or implied warranty.

--------
John Kohl
MIT Project Athena/Kerberos Development Team
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Mar 89 14:09:37 -0600
From:      dan@emx.utexas.edu (Dan Reynolds)
To:        mcvax!kth!draken!umecs!roland@uunet.uu.net
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: I want some information about NQS
NQS (Network Queuing System) was developed for NASA-Ames by a company in
California under government contract. It is a networked batching system
for UNIX-based supercomputers. Vendors like Cray and Convex
have picked up this software and are (will be) including it in future releases
of their systems. For a description of NQS and its protocols, I suggest you
acquire the following paper:

"The Network Queuing System" by Brent Kingsbury of Sterling Software, Palo
Alto, California.

from COSMIC (that's NASA-Ames' corporation for software distribution).

Cheers,

Dan Reynolds <dan@hermes.chpc.utexas.edu>
UT System Center for High Performance Computing
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Mar 89 10:01:27 EST
From:      boesch@vax.darpa.mil
To:        tcp-ip@sri-nic.arpa
Cc:        pullen@vax.darpa.mil
Subject:   [Mark Pullen: [munnari!vaxa.dsto.oz.au!jwb@uunet.UU.NET (John Bennett - Head, Networks Group (HN)): help on subnetting Apollo's pleas]]

I am forwarding this question. Please send replies to:
  munnari!vaxa.dsto.oz.au!jwb@uunet.UU.NET 
	(John Bennett - Head, Networks Group (HN)) 

  -------------------------------------------------------------
DSTO is running an Ethernet backbone to which are connected a number of VAX's, 
Sun's, etc, and an Apollo workstation acting as a gateway to an Apollo Domain 
token ring.  The general picture looks like this... 


      [A]---[A]
     /         \    Apollo
    /           \   Domain
  [A]           [A] token ring                     ___ to Internet (future)
    \           /   network        MicroVAX II    /
     \         /                     ULTRIX  -> [V]
      [A]---[A]                      gateway     | \___ to ACSnet
             |                                   |
             |  Fibre Optic Ethernet             |
   ====================================================================
                |       |        |       |     |       |
      misc VAX's, Sun's, PC's, Appletalk gateways, SNA gateway (proposed)

We have been allocated a class B network number, and are now planning towards 
an Internet connection, hopefully some time this year.  We are setting up a 
subnet numbering scheme (basically "transparent subnetting") on the Ethernet, 
but we are having trouble implementing it on the Apollo gateway.  Apollo claim 
it cannot be done until we get a new release of the OS, but we would like a 
quicker solution.

I would appreciate hearing from anyone who has subnetting an Apollo ring off 
Ethernet working now.

Thanks in advance,

John Bennett					jwb@vaxa.dsto.oz.au
Electronics Research Laboratory		     OR	jwb%vaxa.dsto.oz@uunet.uu.net
Defence Science & Technology Organisation	FAX +61 8 2811292
Salisbury
South AUSTRALIA
------- End of Forwarded Message

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 08:07:01 GMT
From:      pitstop!sundc!rlgvax!dennis@sun.com  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   IEEE 802.3 co-exist on 4.2 BSD TCP/IP/Ethernet?
Can IEEE 802.3 packets be sent on an ethernet which implements
TCP/IP/ethernet?  My understanding of the difference is is as
follows (packet layout below):

Bytes	802.3			Ethernet
1-6	Dest Ether Address	Dest Ether Address
7-12	Source Ethernet Addr	Source Ethernet Address
13-14	Packet Length		Type field (0x800 = IP, 0x806=ARP,
				0x10XX = Trailer Encapsulation).
15-x	802.2 portion		IP header or ARP header

[I ommited the premble part.  Also the 802.3 had some sync char
before byte 1, and I do not have the Xerox Blue book spec
handy to find out if the Ethernet also has such a byte.]


The reason I ask is that I saw output from an ethernet line
monitor that said some packets were "IEEE 802.3" while some
where labelled as ethernet (ARP: ICMP: IP:) etc.  How did
it know that?  Is there something else different about the
packet format that I do not know?

And also, what if an IEEE 802.3 packet is sent on an
ethernet? Will it cause disruption? I suppose the length
field in the 802.3 header would not be one of the valid type
fields for Ethernet, and even if it were, the 802.2 data
after the 802.3 header would not be a good IP/ARP/Trailer
packet to the Ethernet machine.

Comments?
-dennis
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 10:11:30 GMT
From:      mcvax!hp4nl!uva!smitf@uunet.uu.net
To:        tcp-ip@sri-nic.arpa
Subject:   Destination ARPA
Hello over there,

I have a question about the shell script at page 301 of the book
"Internetworking wiht TCP-IP" by D. Comer. In this script the ftp command
is used to retreive several RFCs from SRI-NIC.ARPA. Now this is the 
domain name of the computer at the Internet Network Information Center, but
used on the system I work at it says "Unknown host". 
What name do I have to use with ftp to establish a connection, if that is
possible anyway ?

Greetings from a beginner.
Tims Knarf
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 17:26:45 GMT
From:      orion.cf.uci.edu!iglesias@ucsd.edu  (Mike Iglesias)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TWG 3.2 chokes on my named.hosts
In article <1287@suned1.UUCP> efb@suned1.UUCP (Everett F. Batey II) writes:
>Using TWG WIN/TPC 3.2 on MV_2, VMS 4.6. PROBLEM: Trying to run named Gags
>on named.hosts lines and refers to line numbers.
>
>Do numbers include comment lines ?

Yes.  You should be able to zero in on the offending line from the message.

>What ( besides spare trailing spaces ) make good problems ??

Typos, incorrect spelling, etc.

>We followed the examples .. Is ther a way beyond boot time to get the diagnostic
>messages from reading named.hosts.  NETADMIN NAMED RELOAD doesn't do it.

You'll have to STOP/ID the NAMED process and restart it completely
(@TWG$TCP:[NETDIST.MISC]NAMED) to get the messages again if forcing
a reload doesn't do it.


Mike Iglesias
University of California, Irvine
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 17:48:36 GMT
From:      bbn.com!san@bbn.com  (Stephen H. An)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: MTU question
There is no max MTU for the internet, the gateway/host is supposed to do IP
fragmentation, someone's software is definitely broken along the way.

In reality, this does not surprise me at all, I have seen more brain-dead,
outdated TCP/IP implementations than I care to remember. There are alot of 
people who still don't support address masking, subnet, 4.3 etc... or disagree
on broadcast addr. format.

- Steve.
  (san@bbn.com)
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 89 23:32:47 GMT
From:      oliveb!intelca!mipos3!cadsqa!akay@apple.com  (Allen Kay)
To:        tcp-ip@sri-nic.arpa
Subject:   Requesting SLIP Set Up Info
I am trying to set up a SLIP connection with two Intel 301 systems
(Unix V.3.2) running Lachman's TCP/IP software and two Telebit 9600 baud
modems.  The following are the steps I have already taken:

     1)  Used "ct" command to make modem-to-modem connection.

     2)  Issued "slattach /dev/tty00 local_host remote_hosts 9600" command
         to set up IP point to point connection over tty00 which is connected
	 to COM1 serial port.
     
So far I am able to do ping from one system to the other and seeing the ICMP
packets being received by the remote modem.  The problem is that I'm not
getting any response back from the remote system.  Can somebody on the net
give me some pointers on this or refer me to any manual that contains SLIP
installation?  The TCP/IP manual that came software doesn't have anything
on SLIP other than "slattach" and "sldetach" command descriptions.
--------

US mail      :  Allen Kay
		2625 Walsh Ave. 
                Santa Clara, CA 95051
	        MS SC3-17
Internet mail:  akay@cadev4.intel.com
Phone Number :  (408) 765-5061

All standard disclaimers apply.
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Mar 89 07:11 PDT
From:      CURT.ELLMANN <CURT.ELLMANN%MAIL.ADMIN.WISC.EDU.CP6%LADC@BCO-MULTICS.ARPA>
To:        tcp-ip@sri-nic.ARPA
Subject:   ftp software Devel Kit

I am looking for someone who has purchased the TCP/IP development kit
from ftp Software and is using it with Turbo C.  The documentation
states that it is meant to be used with the Microsoft compiler.
Presently, I'm having a good bit of trouble with library file format
incompatabilities.



Any hints or suggestions are welcome.  You can email me directly and
and I'll post a summary, if necessary.

Curt Ellmann
University of Wisconsin
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Mar 89 10:57:48 EST
From:      swb@chumley.tn.cornell.edu
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: TCP/IP and DECNET
    Date: 9 Mar 89 12:07:15 GMT
    From: mcgill-vision!mouse@BLOOM-BEACON.MIT.EDU  (der Mouse)
    Subject: Re: TCP/IP and DECNET
    To: tcp-ip@sri-nic.ARPA
       
    It's not clear to me exactly what is desired here.  If all he wants
    is to use IP as a transport medium for DECnet packets, that
    shouldn't be difficult: I might even be able to write it myself,
    though not soon (I don't know enough DECnet).

I understand TGV.COM already has this code working and part of their
MultiNet product.
							Scott
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 06:28:31 GMT
From:      romkey@asylum.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: the Chaosnet

In article <8903072030.AA14877@ucbvax.Berkeley.EDU>
Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695) asks
what Chaosnet is, and where to find more information

Chaosnet was two things: a type of network hardware (~4Mbps virtual
token bus), and a protocol stack that first ran on top of the
hardware. It provided similar functionality to TCP/IP and I think was
first developed and implemented at the time the TCP/IP suite was first
being designed (mid to late 70's). You'd have reliable streams and
unreliable datagrams. The host address space was smaller, 16 bits.
There were minor but notable differences between the way it did
reliable streams and the way TCP does (a Chaos open could include
arguments, data block boundaries were preserved and the close worked
slightly differently from the way TCP's does).

Internally, it didn't differentiate between the transport and network
layers as much as TCP/IP does (smush TCP, UDP and IP together into one
protocol and you get something similar to the layering of Chaosnet).
It didn't have end-to-end error checks on individual frames, which
gave many people a good source of experience leading to the belief
that end-to-end checks are necessary. Also, for reliable streams,
Chaosnet sequence numbers were for packets rather than bytes.

The hardware and the protocol stack were developed by the MIT
Artificial Intelligence lab, to provide a high speed local network for
the lisp machines they were building. Lisp machines would access files
from their fileservers (often PDP 10's running ITS, the Incompatible
Timesharing System) using the FILE application protocol. The lisp
machines had full page bitmapped displays with mice. This was ten to
fifteen years ago, remember.

A number of other groups around the MIT campus adopted both the
hardware and the protocols, and for a long time there was a sort-of
religious war between the TCP/IP and Chaosnet factions at MIT. I was
on the TCP side, but I liked a lot of things that the Chaosnet
protocol did (finally writing an implementation of it opened my eyes a
little), and I have a lot of respect for its design. Also, the
hardware was pretty neat.

Eventually, the AI Lab didn't want to have to support the hardware
anymore, and it moved to using the Chaosnet protocols over ethernet,
which became widely available in the early-to-mid 80's. Symbolics and
LMI both supported Chaosnet on their commercially available lisp
machines; I think TI might have on the Explorer, but I don't remember
for sure. Eventually LMI went boom and Symbolics brought up TCP. As
TCP became more and more available, more parts of MIT switched over to
using it. That's why I've been refering to Chaosnet in the past tense
throughout this note. I believe there are still a few systems around
MIT runing it, and probably some at Symbolics, but by and large, it's
faded away.

There's a document called "Chaosnet" by David Moon (if I remember
correctly) available from the AI Lab, it's good reading and it will
introduce people to some slightly different ideas about how to do a
reliable stream protocol. It also has a description of some pretty
interesting network hardware in it. There's a number attached to it,
and if I were on the east coast, I'd go find out what it is, but my
copy is in a box in the garage somewhere, and the east to west coast
connectivity isn't doing so well these days, so you'll have to dig it
out of the AI lab yourself. The main information number for MIT is
(617) 253-1000, see if they can give you the number of documentation
in the AI Lab.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@xx.lcs.mit.edu
"Can you find me soft asylum..." - The Doors

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Mar 89 12:38:59 EST
From:      "Dennis G. Rears (FSAC)" <drears@ARDEC.ARPA>
To:        mcvax!hp4nl!uva!smitf@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Destination ARPA
>
>
>"Internetworking wiht TCP-IP" by D. Comer. In this script the ftp command
>is used to retreive several RFCs from SRI-NIC.ARPA. Now this is the 
>domain name of the computer at the Internet Network Information Center, but
>used on the system I work at it says "Unknown host". 
>What name do I have to use with ftp to establish a connection, if that is
>possible anyway ?

   Try any of these:

sri-nic.arpa sri-nic nic.ddn.mil

  Or try  ftp 26.0.0.73 or ftp 10.0.0.51

Dennis
--------------------------------------------------------------------------
			Dennis G. Rears
ARPA: drears@ac4.pica.army.mil   UUCP:  ...!uunet!ac4.pica.army.mil!drears
AT&T: 201-724-6639		 USPS:	Box 210, Wharton, NJ 07885
Work: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806
--------------------------------------------------------------------------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Mar 89 21:38:03 -0600
From:      dan@emx.utexas.edu (Dan Reynolds)
To:        Mark Jones <ingr!jones@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Not hardly
In article <4267@ingr.com>, Mark Jones <ingr!jones@uunet.uu.net> writes:

> Wait a minute BOZO!  He asks why can't the checksum be zero.  He
> does not ask why the checksum is REQUIRED.  Learn to read or learn to BURN.
>
> Mark Jones

Dave Crocker may be lots of things but BOZO ain't one of them.

Dan Reynolds <dan@hermes.chpc.utexas.edu>
UT System Center for High Performance Computing
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 12:07:15 GMT
From:      mcgill-vision!mouse@BLOOM-BEACON.MIT.EDU  (der Mouse)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP and DECNET
In article <28180@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:
> In article <8902172114.AA06098@ncsc.ARPA> pete@NCSC.ARPA (Fernandez) writes:
>> I don't know exactly what would satisfy the following, but I,m
>> looking for a thing which can smooth the turbulent waters between
>> TCP/IPers and DECNETters; something that uses the tcp/ip in the
>> appropriate levels and uses the plusses of decnet in the higher
>> levels.
(You mean DECnet has plusses? :-)
> [rather nice humor piece by Mr. England]
> Seriously, the desired mongrel stack you seek is unfeasible and you
> should look for an application layer gateway [...].  You aren't going
> to see anyone gluing lower layer TCP and DECNet together in any
> fashion.

It's not clear to me exactly what is desired here.  If all he wants is
to use IP as a transport medium for DECnet packets, that shouldn't be
difficult: I might even be able to write it myself, though not soon (I
don't know enough DECnet).  The converse, DECnet as a transport medium
for IP packets, is working now here in Montreal and has been for
months.  Is this what you mean by "gluing lower layer TCP and DECnet
together", Kent%?  (The IP-over-DECnet version is easier because IP
makes fewer assumptions about the low layers of the network.)

Is this what you meant, Fernandez?  To have two DECnet-capable machines
speaking over IP-based links?  Or do you want, say, a DECnet-only
machine and an IP-only machine to be able to speak somehow?  The latter
*will* require application-level gateways.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

[%] It's not clear what you'd prefer: Kent, Mr. England, kwe, or
    something else....
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 15:23:13 GMT
From:      dogie!dorl%vms.macc.wisc.edu@csd4.milw.wisc.edu  (Michael Dorl - MACC)
To:        tcp-ip@sri-nic.arpa
Subject:   RFC 1042 (IP on 802.2 nets) to non 802.2 Ethernet router wanted
I'm looking for a router which will connect a IP 802.3 network using 
RFC 1042 (IP on 802.2) to a ordinary IP on Ethernet network.
The two nets are likey to be the same physical network so
a product that has only one interface would be best.

Michael Dorl (608) 262-0466
dorl@vms.macc.wisc.edu
dorl@wiscmacc.bitnet
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 16:50:17 GMT
From:      mcvax!ukc!etive!adam@uunet.uu.net  (A Hamilton)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: 802.2 implementations.
In article <15834@cos.com> howard@cos.com (Howard C. Berkowitz) writes:
>In article <gY3jYUy00UoJ4C7p0Y@andrew.cmu.edu>, ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes:
>> > Is it mandatory to implement the
>> > XID/TEST commands ?  The rfc says it is not required to support tcp/ip
>> > but we have to as part of the standard. Has anyone actually done this

>> All of the implementations that I have seen have supported XID/TEST. 
>> However, I have never seen it used for anything either.
>> 
>> My feeling is that XID/TEST implementation should be encouraged, simply
>> because it may be useful/necessary for some network management applications
>
	We use XID for 2 purposes, both blessed by the standard. 
Firstly, we implement "duplicate address check" at startup.  You send an XID
addressed to LSAP 0 at your own MAC address and within time x you must receive
exactly 1 reply (from yourself).  (Note that this requires frames addressed
to yourself to be looped back AND transmitted on the cable).
Secondly, XID is used within LLC2 procedures (connection based) to exchange
window sizes.

	Implementation of TEST is simple and worthwhile.  The Spider Systems
Ethermonitor will send TEST frames to its list of hosts when the test sequence
is run.
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 17:34:08 GMT
From:      mailrus!ulowell!masscomp!bob@tut.cis.ohio-state.edu  (Bob Daniels)
To:        tcp-ip@sri-nic.arpa
Subject:   CISCO <--> VITALINK
Is their any reason to believe why a Cisco MGS-II (MAC bridging function) 
wouldn't bridge IP traffic to a Vitalink bridge?  Does anyone have experience
with mixing these bridges within their topology?

Thanks in advance...

-----------------------------------------------------------------------------
Bob Daniels				
Concurrent Computer (Formerly MASSCOMP)  
1 Technology Way			
Westford, MA			
			
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 19:08:35 GMT
From:      wiltzius@lll-lcc.llnl.gov  (Dave P. Wiltzius)
To:        tcp-ip@sri-nic.arpa
Subject:   Wither PCIP?

My current version of PCIP is dated 1984.  Can anyone direct
me to the latest (public domain) PCIP, preferably where I can
anonymous FTP it?

Thanks!
  Dave (wiltzius@lll-lcc.llnl.gov)
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 20:06:46 GMT
From:      vsi1!wyse!rc@apple.com  (Ran-Chi Huang x1537 dept302)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Destination ARPA
In article <661@uva.UUCP> smitf@uva.UUCP () writes:
>I have a question about the shell script at page 301 of the book
>"Internetworking wiht TCP-IP" by D. Comer. In this script the ftp command
>is used to retreive several RFCs from SRI-NIC.ARPA. Now this is the 
>domain name of the computer at the Internet Network Information Center, but
>used on the system I work at it says "Unknown host". 

Alternately, RFCs may be requested through electronic mail from the
automated NIC mail server by sending a message to SERVICE@SRI-NIC.ARPA
with a subject line of "RFC ####" where #### is the number of the RFC you
are interested in. 

-rc
Ran-Chi Huang
Wyse Technology                 VOICE: (408) 433-1000 x1537
3571, N. First Street           ARPA:  rc@wyse.com  OR  rc@caf.mit.edu
San Jose, CA 95134              UUCP:  ...!{uunet}!wyse!rc
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 1989 01:53-EST
From:      CERF@A.ISI.EDU
To:        ingr!jones@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP-IP zero checksum

My recollection of the zero checksum matter is that, taking into
account the 1's complement nature of the checksum, we want to
make sure that there was no ambiguity in the value produced when
the checksum evaluated to "zero" [which could be 0 or -1].

In the earliest days of TCP experimentation, I seem to recall
that, taking the forcing to -1 into account, some implementations
treated the "illegal" value zero [000..00] to mean the checksum
had not been calculated at the source so should be ignored at
the receiver - just to allow other problems with TCP functionality
to be debugged without worrying about getting the 1's complement
algorithm right. 

This "hack" was never intended to be doctrine, which is why the
TCP RFC requires that checksums always be computed. It should
also have said that the correct value for "zero" is all 1's,
to avoid any ambiguity in presentation of a zero checksum packet.

Does anyone have a different recollection of the history?

Vint Cerf
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 22:10:15 GMT
From:      jpl-devvax!mike@elroy.jpl.nasa.gov  (Mike Tankenson)
To:        tcp-ip@sri-nic.arpa
Subject:   more IP (was Re: Re-fragmenting IP Datagrams)
A group at JPL's Deep Space Network is currently drafting a new design
based around IP as the transport protocol.  They are not using one of the
standard transport protocols due to the long line delay and throughput
requirements.  The DSN spans continents, and travels over cable,
token-ring, and X.25 leased lines.  They've come up with their own method
of sequencing, error detection, etc.

Anyway, one concept they have come up with is to 'trick' IP into thinking
that a bunch of datagrams are actually datagram fragments (by forcing the
appropriate fields in the IP header).  They expect that IP on the receiving
end will simply recognize the things as fragments, reconstruct, and hand
the fully formed datagram off to the application.

In particular, what are the consequences for the receiver running standard
"off the shelf" IP?

Any ideas if this will work?  Flames are welcome, but if this idea seems
too ridiculous, then please e-mail me so as not to clutter this newsgroup.

Thanks in advance.

--mike
-- 
Mike Tankenson                      Telos/Jet Propulsion Laboratory/NASA
4800 Oak Grove Drive, Pasadena, CA.  91109    Mail Stop: 301-260a
Phone: (818) 354-1439
ARPA: mike@jpl-devvax.JPL.NASA.GOV  UUCP: seismo!cit-vax!jpl-devvax!mike
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 23:12:57 GMT
From:      aramis.rutgers.edu!geneva.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEEE 802.3 co-exist on 4.2 BSD TCP/IP/Ethernet?
Yes, it is possible to use both 802.3-style (length code) and
Ethernet-style (type code) packets on the same network.  We do it, and
I think many other large networks do as well.  In fact there is an
official encapsulation for TCP/IP for 802.x networks.  It uses the
length code, NSAP's, and all that 802 stuff.  It is mostly intended
for use with 802.5, etc., but can also be used on 802.3.  Mostly if
you have Ethernet/802.3 hardware you should use the Ethernet
encapsulation, since that's what most other TCP/IP implementations
expect.  But if you have a network that is mostly Token Ring, or some
other 802.x, and you want to be able to use a low-level bridge between
that and your 802.3 network, it might make sense to use the 802.x
format on 802.3 hardware.  Of course a host that is set up to use the
802.x encapsulation may not be able to talk to a host that is set up
to use the Ethernet encapsulation.  They won't interfere with each
other.  They may just not communicate.  It is quite possible to have a
host that can handle both at the same time.  cisco terminal servers
and routers do this.  They have a field in the ARP table indicating
which encapsulation was used in the most recent ARP request (or its
IEEE equivalent) from that host.  They'll use that encapsulation when
talking with that host.  I don't think cisco invented this strategy,
though I don't know who else uses it.

In general implementations that expect Ethernet-style encapsulations
will ignore packets with length codes.  The length codes will look
like undefined packet types.  Implementations that expect length codes
will ignore packets with Ethernet packet types, since the Ethernet
packet types are longer than the longest legal length code.
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 89 23:14:19 GMT
From:      stat!curci@pyr.gatech.edu  (Ray Curci (scri))
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Destination ARPA
In article <661@uva.UUCP> smitf@uva.UUCP () writes:
>used on the system I work at it says "Unknown host". 
>Tims Knarf

Perhaps the problem is that your host is unable to translate the name
"sri-nic.arpa" into an IP address.  Try either (1) adding the following
lines to your /etc/hosts file, or (2) substitute the IP address where the
name "sri-nic.arpa" occurs in the script.

26.0.0.73   sri-nic.arpa
10.0.0.51	sri-nic.arpa

ray curci
curci@nu.cs.fsu.edu
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 00:55:51 GMT
From:      mailrus!ulowell!interlan!solensky@tut.cis.ohio-state.edu  (Frank Solensky)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum (with segue question)
In article <VALDIS.89Mar5131635@alchemy.mcs.clarkson.edu>,
		valdis@alchemy.mcs.clarkson.edu (& Kletnieks) writes:
> I dunno, I might be missing something, but I think the original query was
> NOT why tcp/ip requires checksums, but why said checksum is not allowed
> to evaluate to zero (looks like if it checksums to zero, it jams in an
> all-ones pattern)...

The reason for jamming in 0xFFFF into the checksum field when the computed sum
is zero is to allow the receiving machine to be able to distinguish between
an incoming TCP packet that has a checksum to verify against a packet that had
not computed the checksum before putting it out on the net.

Of course, no one would EVER send a TCP packet out without calculating
a checksum.. :-)

Actually, that brings to mind one of those vague recollections that I've been
meaning to pursue.  In some specification, I thought I remembered reading
some statement that it may not be necessary to duplicate functionality that is
already supplied by a lower level (eg: calculating a TCP checksum when the
connection is over a local Ethernet that already supplies CRCs).  Can anyone
confirm this?
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 08:34:07 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP-IP zero checksum (with segue question)
In article <588@interlan.UUCP> solensky@interlan.UUCP (Frank Solensky) writes:
>Actually, that brings to mind one of those vague recollections that I've been
>meaning to pursue.  In some specification, I thought I remembered reading
>some statement that it may not be necessary to duplicate functionality that is
>already supplied by a lower level (eg: calculating a TCP checksum when the
>connection is over a local Ethernet that already supplies CRCs).  Can anyone
>confirm this?

I can't confirm it, I'll deny it.  TCP needs to calculate a checksum
because it has no way of knowing how IP will transmit the datagram,
nor whether that mechanism provides reliable tranmission.  If the
packet has to traverse multiple networks, link-level CRCs aren't
enough; you need an end-to-end reliability check to detect gateway
errors.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 09:32:00 GMT
From:      freiss@nixpbe.uucp
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP zero checksum



Mink writes:
>Can anyone tell me why the checksum in the TCP header isn't allowed to
>be zero ? I can't find it documented in any RFC. Also I can't find this
>conversion back in the tcp_input routine

Hmmm... RFC 793 says (page 16):

...While computing the checksum, the checksum field itself is replaced
with zeros.

Maybe a checksum of zero therefore is regarded as 'something broke while
the checksum was computed' and replaced by the one's complement of zero.
This doesn't sound like a very intelligent way of errorchecking though.
  Anybody have a better idea?

-Martin

--
 Martin Freiss
 Nixdorf Computer AG, Dept. ET2
 Pontanusstr. 55                    USA: ..!uunet!linus!nixbur!freiss.pad
 D-4792 Paderborn, FRG             !USA: ..!mcvax!unido!nixpbe!freiss.pad

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 10:55:23 GMT
From:      vixie@decwrl.dec.com (Paul A Vixie)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Re: how good is SLIP on a Telebit? (not very)

(Moving this discussion from comp.mail.uucp to comp.protocols.tcp-ip.)

[Rob Warnock]
# Consider the following configuration:
# 1. One end: PC/AT ... "KA9Q" TCP/IP ... SLIP over COM1 at 9600 baud.
# 2. Other end: VAX 780 ... 4.3bsd ... SLIP driver ... 9600-baud DH-11
# 3. Telebit Trailblazer+ on both ends.
# 4. KA9Q's "TCP Max Seg Size" set to 512, "TCP Window Size" set to 4096.
#
# ... measured large FTP file transfers (100K+) at 880 bytes/sec of user data
# (that is, FileSize/ElapsedTime = 880). The best I have ever seen between Unix
# systems, even using the TB+'s UUCP mode, was a little over 800 bytes/sec at
# 9600 baud.

Using two MicroVax II's, MTU 296, 19200, TB+ w/ S120=12, header compression
that averages 11 bytes per ACK (including framing), I *also* get 880 B/sec.
But in my case I have less time to wait for an echo if I'm trying to do
interactive work at the same time I have a large file transfer -- with a
296-byte MTU, there is less data between my new packet and whatever is on
its way into the modem when my new packet is ready.

Van Jacobson does it better -- his compression averages 5 bytes per ACK, plus
one or two for framing, so he runs S120=0.  He also does TOS queuing, so if
some FTP or RCP data packets have already been IF_ENQUEUE'd, the next slstart
will get the interactive data and the big data packets will just have to wait.
(This required some changes to the interactive-style TCP clients and servers
since nobody ever set TOS to anything).

A few additional notes:

* you can't get Van's code yet; he's waiting on the PPP spec which is sort
  of dragging on forever.  Bugging Van would not be productive for you or
  for him -- trust me, I know :-).

* you can't get my code either, since it's a gross, bogus hack that I wrote
  in desperation since Van wouldn't give me his.  If I ever get my 4.3bsd
  machine back up, I'll make my compression code work there and then let it
  out into the world.  Right now it's full of Ultrix KM_ALLOC stuff.

* S120=12 seems to disable microshort PEP packets in the Telebit.  This means
  that my 11-byte ACKs are sent out in a frame capable of handling 25 or so
  bytes, and the next PEP frame coming the other way will have ~250 bytes in
  it.  With S120=0, the telebit seems to send a full ~250-byte-capable frame
  just to handle my little 11-byte ACK; either that or it's sending the first
  9 bytes in a microshort, waiting for ~250 bytes to come in the other direct-
  ion, then sending the last 2 bytes in another microshort.  I'm still unclear
  about shorts, microshorts, and so on.  I know that S120=12 works a lot
  better than S120=0 for my compression scheme.  If I could find another
  two bytes to smash out, I'd use S120=0 and wouldn't life be grand...
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 14:09:18 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   TCP-IP zero checksum (with segue question)

> The reason for jamming in 0xFFFF into the checksum field when the computed sum
> is zero is to allow the receiving machine to be able to distinguish between
> an incoming TCP packet that has a checksum to verify against a packet that had
> not computed the checksum before putting it out on the net.
 
The spec calls for the "ones complement of the ones complement sum."  Ones
complement arithmetic never results in -0 (0xFFFF) as a result, so the
ones complement of that never results in 0.  If you can really do ones
complement arithmetic (don't throw away those PDP 11s!), there's no
"jamming" involved;  it just comes out that way.  This is handy for
detecting a zero checksum (if the semantics of that are meaningful),
but it's also handy because you can verify the checksum of a received
packet by running the algorithm with the received checksum in place;
a result of zero means that the checksum was valid.

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 14:58:36 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)

> ones complement of that never results in 0.  If you can really do ones
> complement arithmetic (don't throw away those PDP 11s!), there's no
 
It quickly occurred to me after posting this that the PDP 11 ADD/ADC
combination fails to be true one's complement in the one case that
we're referring to.  Oh, well.  Make that, "don't throw away those
CDC 6000s!"

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Mar 89 23:17:32 PST
From:      hjs@lindy.Stanford.EDU
To:        hpfcdc!hpldola!hpctdlb!jpeck@hplabs.hp.com (Joe Peck)
Cc:        tcp-ip@sri-nic.ARPA, hjs@lindy.Stanford.EDU
Subject:   Re: ping info --not Analyzer commercials please!
Gee wiz! Joe Peck of HP Telecommunications goes to Uniforum and discovers that
his own product is useful in debugging a network. How thrilling!  Finally a
TCP/IP decoder is available and it amazes the very designers of the product.
James Van B. of FTP spends valuable net time touting his own product, admitting
its limited 254 packet buffer but stand by-- he's already working on another 
release.

This sort of crass self promotion should stop. If Mr. Peck wants to respond
to a query about how PING works and can be used, great. His blatant ad for
the "born again" HP4972A should be banned from the net.

Respectfully yrs.... Harry Saal (from NGC, manufacturer of the Sniffer)

Claimer: the above are entirely the opinions of my employer Network General.
         I'm the president after all!
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 17:08:04 GMT
From:      dragon@CS.UTEXAS.EDU
To:        comp.protocols.tcp-ip
Subject:   Reminder of SIGCOMM 89 Call for Papers


-------------------------------------------------------------------------
CALL FOR PAPERS
ACM SIGCOMM '89 SYMPOSIUM
------------------------------------------
COMMUNICATIONS ARCHITECTURES AND PROTOCOLS
------------------------------------------
September 20-22, 1989 (Tutorials September 19th)	Austin, Texas
-------------------------------------------------------------------------

The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.  Authors are invited to
submit full papers concerned with both theory and practice.

The areas of interest for the symposium include, but are not limited
to the following:

  * analysis and design of computer network architectures and algorithms,
  * innovative results in local area networks,
  * computer-supported collaborative work,
  * network interconnection and mixed-media networks,
  * high-speed networks,
  * resource sharing in distributed systems,
  * distributed operating systems and databases,
  * protocol specification, verification, and analysis.

Papers should be about 20 double-spaced pages long and should have an
abstract of 100-150 words.  All submitted papers will be reviewed and
will be judged with respect to their quality and relevance.   Authors
of accepted papers will be expected to sign an ACM copyright release
form.  The Proceedings will be distributed at the symposium and
published as a special issue of SIGCOMM Computer Communication Review.
A few of the submitted papers will be selected for publication in the
ACM Transactions on Computer Systems.

Submit 5 copies of each paper to the program chairman:

			  Dr. Mohamed Gouda
		     Computer Sciences Department
		    University of Texas at Austin
			 Austin TX 78712, USA
		      Telephone: (512) 471-9532
		      Email: gouda@cs.utexas.edu

For more information about the symposium, contact:

		  Dr. L. H. Landweber, General Chair
		     Computer Sciences Department
		       University of Wisconsin
			1210 W.  Dayton Street
			  Madison, WI 53706
		      Telephone: (608) 262-1204
		    EMAIL: landweber@cs.wisc.edu.

_______________________
STUDENT PAPER AWARD

Papers submitted by students will enter a student-paper award contest.
Among the accepted papers, a maximum of four outstanding papers will
be awarded (1) full conference registration and (2) a travel grant of
$500 US dollars.

_____________________
PROGRAM COMMITTEE

	Geoffrey Brown		Cornell University
	Vinton Cerf		Corp. for National Research Initiative
	Douglas Comer		Purdue University
	David Farber		University of Pennsylvania
	Paul Green		IBM Corporation
	Leonard Kleinrock	University of California, Los Angeles
	Simon Lam		University of Texas at Austin
	Nick Maxemchuk		AT&T Bell Laboratories
	Craig Partridge		BBN Systems & Technologies Corp.
	Radia Perlman		Digital Equipment Corporation
	Larry Peterson		University of Arizona
	Harry Rudin		IBM Corporation
	Krishan Sabnani		AT&T Bell Laboratories
	Udaya Shankar		University of Maryland
	Fouad Tobagi		Stanford University

_____________________
IMPORTANT DATES

	Deadline for paper submission	March 20, 1989
	Notification of acceptance	May 19, 1989
	Camera-ready manuscript due	June 19, 1989

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 21:41:41 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip support for Sun 386 Sun OS 4.01

In article <8903060609.AA21488@ucbvax.Berkeley.EDU> bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) writes:
>Has anyone gotten slip to work with Sun OS 4.01 (object only) on a 386i
>machine (or any other Sun machine under OS 4.01)?
>
>I'm all set to add the slip package that was posted to USENET at the end
>of last year, only there is no  tty_conf.c file on my system.
>
>Does anyone know how to go about adding the slip discipline into the tty
>driver without having source?  Or do I have to make slip a real pseudo
>device (with its own major and minor) and change slattach to access
>the device directly?  Can that even be done?

In SunOS 4.0 et seq, the TTY driver is Streams-based. (I think I'm
supposed to capitalize that "Streams", or maybe it should be "streams" 
or "STREAMS". Oh, well...) This means that SLIP has to be rewritten as
a Streams module, and "slattach" has to push (and eventually pop)
it. It's planned for the next release of PC-NFS (no date yet). Note
that Sun only officially endorses SLIP for PC-to-Sun (or whatever)
connectivity.

Roll on PPP....


-- 
Geoff Arnold,                              Internet: garnold@sun.com
Manager, PC-NFS Engineering                UUCP: ....!sun!garnold
PCDS Group, Sun Microsystems Inc.
*** I SPEAK ONLY FOR MYSELF *** (MY CHILDREN INSISTED THAT I SAY THAT) ***

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 22:57:56 GMT
From:      pete@NCSC.ARPA (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Netware and TCP


Fellow SIG Members,

    We have a situation where we're migrating an application/system built
    around the Novell Netware NOS (+ a token ring) over to our TCP/IP
    Ethernet.  Does anyone have an familiarity with a product from MICOM
    called the Netware TCP Gateway?  What are the plusses and minuses?
    Thanx in advance.

    Pete Fernandez
    Naval Coastal Systems Center
    (904) 234-4120
    pete@ncsc.arpa

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 89 22:59:55 GMT
From:      rick@ssbell.UUCP (Richard Ohnemus)
To:        comp.protocols.tcp-ip
Subject:   How can I get the Berkeley networking code?

A few months ago a message was posted giving the instructions for
ordering a tape containing all of the Berkeley networking code.
Unfortunately I lost the copy I made of it. Would some one please send
me instructions on how I can get this tape from Berkeley?

		Thanks in advance,

Rick Ohnemus                 UUCP:     rick@ssbell
Sterling Software FSG/IMD    INTERNET: rick%ssbell.uucp@uunet.uu.net
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 89 07:17:32 GMT
From:      hjs@LINDY.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ping info --not Analyzer commercials please!

Gee wiz! Joe Peck of HP Telecommunications goes to Uniforum and discovers that
his own product is useful in debugging a network. How thrilling!  Finally a
TCP/IP decoder is available and it amazes the very designers of the product.
James Van B. of FTP spends valuable net time touting his own product, admitting
its limited 254 packet buffer but stand by-- he's already working on another 
release.

This sort of crass self promotion should stop. If Mr. Peck wants to respond
to a query about how PING works and can be used, great. His blatant ad for
the "born again" HP4972A should be banned from the net.

Respectfully yrs.... Harry Saal (from NGC, manufacturer of the Sniffer)

Claimer: the above are entirely the opinions of my employer Network General.
         I'm the president after all!

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Mar 89 12:44:05 EST
From:      Boots Cassel <cassel%villanova.edu@RELAY.CS.NET>
To:        tcp-ip%sri-nic.arpa@RELAY.CS.NET, cassel@RELAY.CS.NET
Subject:   Address Change
Please change my address for tcp-ip to
boots%villanova.edu@relay.cs.net
(from cassel%villanova.edu@relay.cs.net)

Thank you.

Boots Cassel

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 89 17:44:05 GMT
From:      cassel@villanova.EDU (Boots Cassel)
To:        comp.protocols.tcp-ip
Subject:   Address Change

Please change my address for tcp-ip to
boots%villanova.edu@relay.cs.net
(from cassel%villanova.edu@relay.cs.net)

Thank you.

Boots Cassel

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 89 19:33:00 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   new ICMP types and codes

Is there a comprehensive list of the new types and codes that have
been added to ICMP since RFC 793?  I know about subnet mask query and
reply, and the Blacker Front End document lists code 10 (Administratively
Prohibited) as a new code for Destination Unreachable.  What should
an implementation do with new codes?  4.3bsd, for example, rejects
ICMP messages with unknown codes, rather than passing some error
indication up to the application.

		--Steve Bellovin
		smb@ulysses.att.com

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 89 20:26:35 GMT
From:      deanr@lakesys.UUCP (Dean Roth)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Primer Needed

I am looking for a intertask communications primer using
TCP/IP for my programming staff.  I am not looking for
a book that covers the internals of TCP/IP: skip Comer's
book for this purpose. (However, I do recommend Comer's
book for the internals and such of TCP/IP.)

Besides covering client-server concepts, with examples,
the book should also cover UNIX daemon concepts.

Does such a book exist? Is it better than the man pages?

Pleas email me as my node has been receiving news unreliably.
If I receive good responses, I will summarize for the net.
Thank you.

Dean A. Roth
deanr@lakesys.lakesys.com
deanr@lakesys.UUCP
{rutgers, uwvax} uwmcsd1!lakesys!deanr

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Mar 89 23:48:27 EST
From:      Bruce Crabill <BRUCE@UMDD.UMD.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   PUSH bit
I've noticed a quirk with a TCP/IP implementation that I'm working with.  It
has to do with how it handles the PUSH bit on TCP segments that it receives.
What is happening is that when a segment is received with the PUSH bit set,
it is placed in the client buffer and the client is notified as he should be.
However, if another segment comes in before the client picks up the data,
the new segment is also appended to the buffer.  When the client picks up
the buffer, it is marked as having been PUSHed.

The problems are that in some cases the second packet won't completely fit
in the buffer and will have to be split (or the second packet didn't have
the PUSH bit on it).  The client is seeing data that is marked as being
PUSHed, but in fact it was data earlier in the buffer.  I see three
possible solutions, do it as RFC 793 implied and don't allow anymore data
to be placed in the buffer.  This has the drawbacks of wasting buffer
space and causes more overhead in that the client needs to be notified
more times.  Second, don't set the PUSH flag for the buffer if the buffer
ends up with the final byte not being the last byte of a PUSHed segment
(but still give the buffer to the client ASAP).  Third, only allow data
to be appended to the buffer if they are also PUSHed and will fit within
the buffer.

What I guess I'm really asking is what is the exact purpose of the PUSH
bit.  You could interpret the PUSH bit as a end of logical record marker.
Or you could interpret is as simply a mechanism to make sure all the data
that is currently in the pipe is pushed out to the client.  Since TCP is
a stream oriented protocol, it would appear that the latter is the correct
interpretation.  In which case, any of the above 3 solutions will work.
However, the thing that is throwing me is the fact that PUSH data indications
are to be given to the client.  Why was this done?  Does this imply that
for every PUSH done on the sending side, their must be a corresponding
PUSH indication on the receiver's side?  If not, why bother with PUSH
indications at all?

                                       Bruce
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 04:48:27 GMT
From:      BRUCE@UMDD.UMD.EDU (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   PUSH bit

I've noticed a quirk with a TCP/IP implementation that I'm working with.  It
has to do with how it handles the PUSH bit on TCP segments that it receives.
What is happening is that when a segment is received with the PUSH bit set,
it is placed in the client buffer and the client is notified as he should be.
However, if another segment comes in before the client picks up the data,
the new segment is also appended to the buffer.  When the client picks up
the buffer, it is marked as having been PUSHed.

The problems are that in some cases the second packet won't completely fit
in the buffer and will have to be split (or the second packet didn't have
the PUSH bit on it).  The client is seeing data that is marked as being
PUSHed, but in fact it was data earlier in the buffer.  I see three
possible solutions, do it as RFC 793 implied and don't allow anymore data
to be placed in the buffer.  This has the drawbacks of wasting buffer
space and causes more overhead in that the client needs to be notified
more times.  Second, don't set the PUSH flag for the buffer if the buffer
ends up with the final byte not being the last byte of a PUSHed segment
(but still give the buffer to the client ASAP).  Third, only allow data
to be appended to the buffer if they are also PUSHed and will fit within
the buffer.

What I guess I'm really asking is what is the exact purpose of the PUSH
bit.  You could interpret the PUSH bit as a end of logical record marker.
Or you could interpret is as simply a mechanism to make sure all the data
that is currently in the pipe is pushed out to the client.  Since TCP is
a stream oriented protocol, it would appear that the latter is the correct
interpretation.  In which case, any of the above 3 solutions will work.
However, the thing that is throwing me is the fact that PUSH data indications
are to be given to the client.  Why was this done?  Does this imply that
for every PUSH done on the sending side, their must be a corresponding
PUSH indication on the receiver's side?  If not, why bother with PUSH
indications at all?

                                       Bruce

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Mar 89 10:03:13 EST
From:      Boots Cassel <cassel%villanova.edu@RELAY.CS.NET>
To:        tcp-ip%sri-nic.arpa@RELAY.CS.NET, cassel@RELAY.CS.NET
Subject:   Address Change
Please change my address from cassel%villanova.edu@relay.cs.net
                           to boots%villanova.edu@relay.cs.net

Thank you.

Boots Cassel

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 14:53 EST
From:      FCOHEN%LUKE.decnet@ge-crd.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Request For Info On TCP/IP Performance Problems






        We need information on TCP/IP performance problems.



        As a preliminary design step we are trying to investigate some

        of  the  specific problems with protocol processing, operating

        system interface processing, flow control and  other  specific

        performance  problems  that  you  members  of  the TCP/IP user

        community have recently encountered, and also to learn of what

        was done about these problems.



        Your timely responses,  including  any  comments  and  advice,

        would be a big help to us and will be much appreciated.



        Thanks in advance.









                                                 Fred Cohen

                                                 GE/RCA Camden, N.J.

                                     TACNET NO:  794-2085

                                   INTERNET NO:  fcohen%luke.decnet@ge-crd.arpa

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 13:38:02 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: ping info --not Analyzer commercials please!


>This sort of crass self promotion should stop. If Mr. Peck wants to respond
>to a query about how PING works and can be used, great. His blatant ad for
>the "born again" HP4972A should be banned from the net.

My goodness Harry, lighten up; I thought Joe Peck's note was brief
and informative.  Regards - Craig

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 14:22:18 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  PUSH bit

OK, I'll bite, since I babbled about this in the Host Requirements WG.

The PSH bit is definitely NOT a record marker.  It is the sending
application's means of demanding that the data not be allowed to linger
in buffers somewhere between the sending and receiving application.

It is fine to deliver some 'non-PSHed' data in the same buffer as the
PUSHed data, if there is some of both kinds available for delivery.  It
is always permitted to deliver any (in-sequence) data that is on hand,
regardless of Push.  The ABSENCE of Push gives all the intermediate
processes permission to buffer the data until there is a Push (or until
some other event implying a Push occurs, such as a FIN arriving).

It is not required that PSH be transferred one-to-one.  Either the
sending or receiving TCP may 'collapse' them.  The HR RFC (coming
soon...) will clarify that providing notification of a Push to a
receiving application is optional rather than required.  Kindly note,
tiny minority of careless readers, that sending a PSH bit at
appropriate times is still mandatory.  This is important!!  Anyhow, the
service definition in RFC 793 is somewhat exemplary and contains a few
optional features.  It is hoped that the text in the HR RFC will
clarify all this.  (Draft available from venera.isi.edu by anonymous
ftp using filename /pub/ietf-hosts.rfc.txt)

All of your three solutions are legal, but somewhat distasteful to me,
especially #2, which probably "ought" to be illegal.  For the case you
describe, I think the preferred solution is to fill the buffer as full
as possible with any available data, and set the Push indication.

Why should a Push indication be passed from the destination TCP to the
client application?  True, it is often not very useful, and it should
never be NECESSARY (if it seems to be necessary to the application, the
application/TCP service mapping is flawed, given the facts described
above).  However, it has a little value once in a while.  Here is an
example.  A few years ago I was working with some timesharing host
software which used windows on a 24x80 display terminal and could have
connections to various other hosts whose output might be sent to
various windows.  This was originally designed for a different protocol
stack and I added support for TCP connections driving windows.  Since
bandwidth to the terminal and CPU usage (context switches..) were of
some concern, I contrived code such that window repaints were only
scheduled when a Push came in for that window.  This resulted in fewer
process wakeups, better efficiency on the terminal-host interface, and
yet allowed a window to be updated pretty promptly when a remote host
felt the need to do that.  Also, it saved me the nuisance of
timer-driven connection polling or some other algorithm which would
have taken more effort to code.  I thought it worked out pretty well.

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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 15:03:13 GMT
From:      cassel@villanova.EDU (Boots Cassel)
To:        comp.protocols.tcp-ip
Subject:   Address Change

Please change my address from cassel%villanova.edu@relay.cs.net
                           to boots%villanova.edu@relay.cs.net

Thank you.

Boots Cassel

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 15:10:43 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re: more IP (was Re: Re-fragmenting IP Datagrams)

>Anyway, one concept they have come up with is to 'trick' IP into thinking
>that a bunch of datagrams are actually datagram fragments (by forcing the
>appropriate fields in the IP header).  They expect that IP on the receiving
>end will simply recognize the things as fragments, reconstruct, and hand
>the fully formed datagram off to the application.

I suppose you've already considered the fact that one of these 
"super-datagrams" might have several sets of TCP or UDP headers in them, due
to the conglomeration of "fragments" that the receiving IP will perform? I 
expect that will cause most TCP/IP implementations to become deathly ill. 

Ross Patterson
Rutgers University
Center for Computer and Information Services

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 15:12:28 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: PUSH bit

In article <8903130939.AA05138@ucbvax.Berkeley.EDU>, BRUCE@UMDD.UMD.EDU (Bruce Crabill) writes:
> You could interpret the PUSH bit as a end of logical record marker.

That is definitely the wrong interpretation.  The spec says, many
times in many places, that the PUSH bit is *not* a record marker.
See, for example, the bottom of page 7 of RFC 1011:

         Push:  There are still some phrases in the document that give a
         "record mark" flavor to the push.  These should be further
         clarified.  The push is not a record mark.

> Or you could interpret is as simply a mechanism to make sure all the data
> that is currently in the pipe is pushed out to the client.

The proper interpretation is that at least all data up to the PUSH point
must be delivered promptly.  Whether or not more data is delivered is
entirely up to the implementation; any interpretation is in conformance
with the spec.  Applications that assume that the PUSH bit is an end-of-
record mark are non-conforming.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 16:22:43 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: "...not Analyzer commercials please!"

Mr. Saal:

Your own employees have also been known to answer posted questions with
information about your product.  I don't have any of them to hand, but I
recall them as 1) informative and useful re: Sniffers, 2) not mentioning
your competition, 3) not discussing any negative aspects of your product.

In my public answers to questions, I attempt to be balanced, and either
provide a summary of the whole market (or as much of it as I am aware of),
or give details and trade-offs about our contribution to it.  I don't promise
perfection, but the feedback I have gotten has been almost entirely positive
(you are the exception, to date).

Mr. Peck's message had three classes of content:  First, a demonstration
of how useful network monitoring equipment can be (many users are amazed at
the actual content of their cables).  Second, information about HP's having
remedied a widely-discussed deficiency (perhaps a dozen postings in 1988,
across the lists/groups I read) in their product.  Third, an enthusiastic
recommendation for it.  The first is indirectly a commercial for the whole
concept of network monitors.  The last you criticize as "commercial", but I
didn't find it significantly worse than what I consider average for vendor
employees.

Myself, I am pleased each time another vendor-connected net-person is heard
from, because it means the net has gotten bigger, and represents a better
resource to its users.  If you and Mr. Peck can be relied on to post current
information in replies to relevant questions, I will be happy.  Globally,
it means the network community will be better informed, and personally, I
won't feel compelled to type so much.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 17:44:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP zero checksum


> /* Written  6:42 pm  Mar  7, 1989 by cdh@bbn.com 
> I think the rational about always using the FFFF version of 0 in the
> ones-complement checksum of TCP was that it prevented an all-zeros
> packet from being legal.  Therefore, if some interface or memory
> fed you a packet containing all zeros, you knew it was illegal, since
> a correct all-zeros packet would have checksum FFFF.
> 
> Of course, I could be wrong.
> 
> Carl

That's why the definition is the complement of the sum of all the 16-bit
words in the datagram. All 0's add to 0000 which then gets complemented
to FFFF. A packet that contained 0000FFFF0000FFFF0000FFFF... might be
the result of some hardware messup (half the data lines jammed on a memory
board) but seems unlikely. Still only has a 50/50 chance of getting 0000
as a checksum.

Ignoring checksums in TCP/IP is like giving a bucket o' pork ribs to
someone to celebrate a barmitzvah -- it runs counter to the principle
of reliable stream transport.


Johnny Zweig
University of Illinois at Urbana-Champaign
Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 19:53:00 GMT
From:      FCOHEN%LUKE.decnet@GE-CRD.ARPA
To:        comp.protocols.tcp-ip
Subject:   Request For Info On TCP/IP Performance Problems







        We need information on TCP/IP performance problems.



        As a preliminary design step we are trying to investigate some

        of  the  specific problems with protocol processing, operating

        system interface processing, flow control and  other  specific

        performance  problems  that  you  members  of  the TCP/IP user

        community have recently encountered, and also to learn of what

        was done about these problems.



        Your timely responses,  including  any  comments  and  advice,

        would be a big help to us and will be much appreciated.



        Thanks in advance.









                                                 Fred Cohen

                                                 GE/RCA Camden, N.J.

                                     TACNET NO:  794-2085

                                   INTERNET NO:  fcohen%luke.decnet@ge-crd.arpa

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 19:56:08 GMT
From:      DEDOUREK@UNB.CA
To:        comp.protocols.tcp-ip
Subject:   SLIP

A couple of years ago there was some activity to add capabilities
to the SLIP (Serial Line IP) protocol for TCP/IP.  Was this
pursued?  Could someone give me a reference?  Is there any current
activity in this area?

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

John DeDourek
dedourek@unb.ca      -- Registered Domain Name
DEDOUREK@UNB         -- BITNET / NETNORTH (Canada)
dedourek@unb.bitnet  -- For mailers which only know how to get to
                        bitnet this way.

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 20:56:01 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   INARC workshop announcement


   WORKSHOP ON THE FUTURE OF THE INTERNET ARCHITECTURE AND PROTOCOLS

                 1-2 June 1989, University of Delaware

           Sponsored by the Internet Architecture Task Force
                   and the Internet Activities Board

The Internet Activities Board (IAB) has been guiding and coordinating
the research and development activities of the DARPA/NSF Internet System
for several years. The Internet Architecture Task Force (INARC) of the
IAB has been asked to explore the inherent limitations in the existing
Internet architecture and supporting IP/TCP protocol suite and how the
lessons learned can be applied to future systems. The INARC will hold a
two-day workshop on 1-2 June 1989 at the University of Delaware to
explore these and related issues. While the emphasis of the workshop
will be on the past and future evolution of the Internet system,
specific issues relevant to other architectures, protocol suites and
migration strategies may be discussed as well.

Interested persons from all walks of network life are invited to attend.
Participants will be encouraged to present short briefings on specific
technical issues, including those suggested below, but this is not a
requirement for admission. While some participants may be invited on the
basis of their known expertise, biases and past vocalizations on these
issues, participants outside the IAB, INARC and their dependencies are
actively encouraged. In order to manage the local arrangements it is
necessary that participants register their intent to attend by
contacting the INARC chair:

David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
(302) 451-8247
mills@udel.edu

Areas of interest include, but are not limited to, the following:

1.   Are the Internet architecture and protocols suitable for use on
     very high-speed networks operating in the 1000 Mbps range and up?
     If the network-level or transport-level protocols are not usable
     directly, can they be modified or new ones developed to operate
     effectively at these speeds?

2.   Are the Internet addressing and gateway-routing algorithms adequate
     for very large networks with millions of subscribers? If not, is it
     possible to extend the addressing scope and/or develop new routing
     paradigms without starting over from scratch?

3.   Can the Internet model of stateless networks and stateful hosts be
     evolved to include sophisticated algorithms for flow management,
     congestion control and effective use of multiple, prioritized
     paths? Can this be done without abandoning the estimated 60,000
     hosts and 700 networks now gatewayed in the system?

4.   Can the existing Internet of about 300 routing domains be evolved
     to support the policy and engineering mechanisms for many thousands
     of domains including education, research, commercial and government
     interests? Can this be done with existing decentralized management
     styles and funding sources? If not, what changes are needed and how
     can they be supported, given practical limits on infrastructure
     funding?

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 21:33:27 GMT
From:      jim@tiamat.fsc.com (Jim O'Connor)
To:        comp.protocols.tcp-ip,comp.unix.xenix
Subject:   TCP/IP using the KAQ9 package

I have seen several articles lately about SLIP and the KAQ9 TCP/IP software
package and would like to ask a few questions:

1) will this software run on SCO Xenix 386 version 2.3.1?

2) has anyone been able to compile and use it under any 80286 based *nix
   (particularly Xenix) ?

3) where do I get the sources?

4) is there someone who has compiled and is using TCP/IP and SLIP in a
   Xenix environment who would be willing to work with me on getting
   thnigs set up here?

Thanks.
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Filtration Sciences Corporation		615/821-4022 x. 651

*** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 21:52:34 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Broken SMTP daemon @ WPAFB-FDL.ARPA

Someone call the protocol police!


	Script started on Mon Mar 13 16:45:18 1989
	You have mail.
	| 1 - s:david --> telnet wpafb-fdl.arpa smtp
	Trying...
	Connected to wpafb-fdl.arpa.
	Escape character is '^]'.
	220 HYPER-LINK VAX/VMS Simple Mail Transfer Service ready.
	helo e.ms.uky.edu
----->	501 Syntax error in parameters or arguments.
	mail from:<david@ms.uky.edu>
	250 Requested mail action okay, completed.
	rcpt to:<edwardsrl@wpafb-fdl.arpa>
	250 Requested mail action okay, completed.
	data
	354 Start mail input; end with <CRLF>.<CRLF>.
	From: david@ms.uky.edu
	To: edwardsrl@wpafl-fdl.arpa
	Subject: test 

	I'm demonstrating to comp.protocols.tcp-ip that your mailer is broken.
	.
	250 Requested mail action okay, completed.
	quit
	221 HYPER-LINK VAX/VMS Service closing transmission channel.
	Connection closed by foreign host.
	| 2 - s:david --> 
	script done on Mon Mar 13 16:47:07 1989

The marked line is in error.  I just checked in RFC-821 to make certain
and it says in section 4.1.1 that the HELO command and an affirmative
reply are necessary to ensure that both mailers are in sync.

Further in section 4.3 in the COMMAND-REPLY SEQUENCES, the only
allowable "Success" reply is a "250", "501" is an "Error" reply.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- 
<-- For a good time send mail to somebody@ms.uky.edu

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 89 22:46:04 GMT
From:      deanr@lakesys.UUCP (Dean Roth)
To:        comp.protocols.tcp-ip
Subject:   Port Number


My company will be producing commercial TCP/IP
server  and client software. Question:
how do we pick a port number that will not collide
with another software package's port number?
I have already tentatively selected a "large"
and hopefully improbable number, but I'd like
to do better than "toss darts in the dark" looking
for a "good" number to use.

Please email me. My node's news delivery has not
been 100% reliable recently. Thank you.

deanr@lakesys.lakesys.com
deanr@lakesys.UUCP
{rutgers, uwvax} uwmcsd1!lakesys!deanr

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 07:36:51 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Do Butterflies Live Forever?

If you run traceroute through the Buttergates in the core, you will
notice that they do not decrement the IP TTL.  This is not a very
good idea.  We would be in deep trouble if a routing loop was ever
set up between them (not that this would ever happen of course :-).

- Phil

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 09:45:24 GMT
From:      sundar@WHEATIES.AI.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   the Chaosnet AIMemo

>There's a document called "Chaosnet" by David Moon (if I remember
>correctly) available from the AI Lab, it's good reading and it will
>introduce people to some slightly different ideas about how to do a
>reliable stream protocol. It also has a description of some pretty

	David Moon, "ChaosNet", AI Memo 628.

You can send a note to publications@wheaties.ai.mit.edu or mail to
	Ms. Blythe Heepe,
	Publications Dept.,
	MIT AILab, 545 Technology Square,
	Cambridge, MA 02139

and see if copies are still available.

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 15:36:00 GMT
From:      Mly@AI.AI.MIT.EDU (Richard Mlynarik)
To:        comp.protocols.tcp-ip
Subject:   Port Number


    Date: 13 Mar 89 22:46:04 GMT
    From: marque!lakesys!deanr@csd4.milw.wisc.edu  (Dean Roth)


    My company will be producing commercial TCP/IP
    server  and client software. Question:
    how do we pick a port number that will not collide
    with another software package's port number?
    I have already tentatively selected a "large"
    and hopefully improbable number, but I'd like
    to do better than "toss darts in the dark" looking
    for a "good" number to use.

Use TCPMUX, RFC1078.

Choose a contact name like "VERSION-1.MY-PROTOCOL.MY-COMANY-NAME.COM"
(Assuming that "MY-COMPANY-NAME.COM" is a registered domain name,
and hence guaranteed unique.)

Down with meaningless numbers!

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 16:44:19 GMT
From:      sra@MBUNIX.MITRE.ORG (Stan Ames)
To:        comp.protocols.tcp-ip
Subject:   ULANA Network Management Proposal


The Air Force ULANA program is considering an upgrade in the 
network management area to bring the program in line with 
emerging standards and to foster commercial availability of 
network management products.

The ULANA components that will be managed include host 
attachments, asychronous and synchronous attachments (i.e. 
terminal servers), bridges and the DDN gateway.  Host attachments 
and the DDN gateway will be required to implement SNMP or CMOT to 
exchange the required MIB information with the Network Management 
Station.  Asychronous attachments, synchronous attachments and 
bridges may use SNMP, CMOT, or a proxy to exchange the required 
MIB information with the network management station.

The ULANA management information base (MIB) is planned to 
include the elements from RFC 1066 together with a subset of IEEE 
802.3h.

The network management station will be required to implement both 
SNMP and CMOT in order to exchange standard management 
information with the various agents and will use windows with 
telnet using VT100 emulation to manage device specific functions 
and MIB information not currently covered by the 1066 MIB (e.g. 
the RS232 side of terminal servers.)

It will be required that all network management products be part 
of the vendors commercial product line so that the costs of 
producing network management can be shared by both commercial and 
government users.

In deciding on whether to proceed with this approach we are 
soliciting input from both vendors and major users as to the 
merits of proceeding with a dual protocol network management 
approach at this time.

Stan Ames
sra@mitre-bedford.arpa

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 17:11:30 GMT
From:      brunner@CACFS.ARMY.MIL (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Broken SMTP daemon @ WPAFB-FDL.ARPA

David,
	Don't take this too seriously, the nic's smtp service, which
advises that one not worry and be happy views an unargumentative "helo"
similarly:
	220-SRI-NIC.ARPA SMTP Service 6.1 at Tue, 14 Mar 89 08:52:36 PST
	220 Don't Worry.
	helo
	500 Missing required argument: helo
as does, of course, a.isi.edu... For all I know this is a feature of TOPS-20,
as both of these two hosts are DEC-20s running TOPS-20, and version 6.1 of
their SMTP implementation, emulated on VMS hosts :-).

Eric
P.S.	Ignore bogus return address, fixing mailer,
	use brunner@spam.istc.sri.com for best results

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 19:39:25 GMT
From:      matthews@alux2.ATT.COM (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Addresses?


Can someone tell me if there is some sort of list that says what
manufacturer uses what ethernet addresses?  I have noticed that
for the most part all suns have a leading 8:0:20:?:?:? and that
other machines do the same.  What I am looking for is a list that
will give some indication as to what type of machine it might be
by just looking at the ethernet address.
				Thanks,
					John Matthews
					matthews@research.att.com

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 21:35:52 GMT
From:      tom@tut.cis.ohio-state.edu (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   bisync terminal server


Does anyone know of a terminal server that will allow access to an
IBM-like mainframe through a bisync connection?  We have a Bridge Com.
Inc. server that does SNA but need one that talks bisync.

						 Tom

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 89 23:40:47 GMT
From:      MAP@LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   the Chaosnet

John, that was a very nice and fairly complete reply on the ChaosNet.
I have a few minor clarifications of historical (or hysterical :-)
fact.  I had already been in communication with Mr. Murayama in answer
to his original query so these comments are mostly intended as a
follow up to you and the wider distribution to which your message was
addressed.  As you know, but others may not, I was involved in the
early days of the ChaosNet (in 1979 I worked on one of the first
implementations).  Later I worked with Dave Clark (and you, when you
showed up :-) on early TCP/IP development (1981-1982).  As you noted,
a comparison of the two architectures is very interesting indeed.

>>	[...]  The host address space was smaller, 16 bits.
This was in fact a conscious decision.  The design of the protocols
was known to be biased towards campus sized networks and was
explicitly intended to be internetworked with gateways above the
network layer, rather than routers as the IP protocols are.  Several
of these gateways exist, it's possible to transparently telnet from a
ChaosNet host to a host on the Internet, the reverse was never
implemented because TCP opens don't have arguments, someone later
proposed a way to do it with address mapping, but this was never
implemented to my knowledge.

>>  Internally, it didn't differentiate between the transport and network
>>  layers as much as TCP/IP does (smush TCP, UDP and IP together into one
>>  protocol and you get something similar to the layering of Chaosnet).
One of the features that I liked about the protocol stack was the
ability to have one "connection" with a fully error-checked and
sequenced byte stream, with out-of-band packets.  This allowed
terminal applications to send interrupt characters that would succeed
in interrupting type-ahead.

>>	[...] Symbolics and LMI both supported Chaosnet [...] I think
>>  TI might have on the Explorer.
 Right, TI did have it, on both the Explorer and the Nu.
>>  Eventually LMI went boom and Symbolics brought up TCP.
Actually all varieties of LispMachine I know of speak both Chaos and
TCP/IP.  The code frequently is arranged to try one and then fall back
to the other for various services.
>>  [...] I believe there are still a few systems around MIT running it,
>>  and probably some at Symbolics, but by and large, it's faded away.
At this instant 28 Chaos subnets are reachable at MIT (vs 47 IP
subnets), with 441 hosts registered and over 300 on-line now.  It
hasn't quite faded away yet it's just that TCP/IP has been growing so
much faster around here.

>>  There's a document called "Chaosnet" by David Moon (if I remember
>>  correctly) available from the AI Lab, [...]
Yes, I believe the latest version is AI Lab Memo #628, June 1981, it
is sometimes referred to as the "Amber" document (from "9 Princes in
Amber", also where the name Chaos comes from).  I also recommend it
for people looking for a different perspective on how to do local area
networking.  The AI Lab Publications office is at +1-(617)-253-6773
and by E-Mail at pub@Wheaties.AI.MIT.Edu (I think).

	    __
  /|  /|  /|  \		Mike Patton, Network Hacker
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 04:33:06 GMT
From:      glen@aecom.YU.EDU (Glen M. Marianko)
To:        comp.protocols.tcp-ip
Subject:   Children disguised as vendors

You know what, I think crybaby vendors should be banned from the net!

As a user listening to vendors go at eachother's throats I find myself
rather turned off to those companies.  Maybe if you have a problem
you should air it privately rather than spattering venom all over
my disk drives.

I for one couldn't care less if a vendor on the net OCCASIONALLY as an aside
spouts a little MEASURED enthusiasm for his own product.  It obviously
shows a little in-house excitement and may even indicate a good product.
As long as the guy CLEARLY states his affiliation with the company
and doesn't masquerade as a user, FINE!  I think the intelligent users
out there will make the connection and take the comments with a
bag of salt.

This bickering is CONSTANTLY coming up on the nets - ENOUGH!  Hear
me now and understand me later, IT ONLY MAKES YOU LOOK BAD IN THE END.

I DON'T WANT THE VENDORS ON THE NET TO BE AFRAID TO RESPOND JUST
BECAUSE THERE IS SOMEONE OUT THERE READY TO CHEW THEIR HEADS OFF!
Your availability and resource to the net is too valuable.  After all,
if we called you would you really answer the phone? 8-)

Now, make friends publicly and short eachother's stock privately.

-- Glen Marianko
   glen@aecom.yu.edu

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 10:38:26 GMT
From:      pvo1478@neptune.uucp (Paul O'Neill)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Addresses?

In article <234@alux2.ATT.COM> Matthews@Research.ATT.COM (John Matthews) writes:
>
>Can someone tell me if there is some sort of list that says what
>manufacturer uses what ethernet addresses? ................
>

    ftp pprg.unm.edu
    get pub/rfc/ethernet_vendor_addrs

It's dated 6/18/88 and has 45 entries.

Paul O'Neill                 pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR  97331         503-754-3251

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 12:37:56 GMT
From:      martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat
Subject:   TCP/IP versus OSI

The following is an article which I am going to submit to Data
Communications in reply to a column which William Stallings
did on me a few months ago.  I think people in this forum might
be interested, and I would not mind some comments.


                   Round 2 in the great TCP/IP versus OSI Debate

            I. INTRODUCTION

            When ISO  published the first proposal for the ISO reference
            model in  1978, DARPA-sponsored research in packet switching
            for data  communications had  already been  progressing  for
            over 10  years.  The NCP protocol suite, from which the X.25
            packet-switching protocol suite originated, had already been
            rejected as unsuitable for genuine resource-sharing computer
            networks.   The major architectural and protocol development
            for internetting  over the  ARPANET was completed during the
            1978-79 period.  The complete  conversion of DARPA-sponsored
            networks to  internetting occurred  in January,  1983,  when
            DARPA required  all ARPANET  computers to  use TCP/IP. Since
            then, with an effective architecture, with working protocols
            on real networks, researchers and developers within the ARPA
            Internet community  have been  refining computer  networking
            and providing  continually more  resource sharing  at  lower
            costs.  At the same time, with no obvious architecture, with
            theoretical  or   idealized  networks   and  while  actively
            ignoring the  work being  done in the ARPA Internet context,
            the ISO  OSI  standards  committees  were  developing  basic
            remote terminal  and file  transfer protocols.   The ISO OSI
            protocol suite  generally provides  potentially much less at
            much  more   cost  than  the  ARPA  Internet  suite  already
            provides.   No one  should be  surprised that  many computer
            networking system  architects wish  to debate  the merits of
            the OSI  reference model  and that  many relatively  pleased
            business, technical  and academic users of the ARPA Internet
            protocol suite  would like  such a  debate  to  be  actively
            pursued in the media.

           ______________________________________________________________
           |                                                            |
           |                         Background				|
           |								|
           |Since June,  1988 William Stallings and I have been engaging|
           |in a  guerilla debate  in the  reader's forum  and  the  EOT|
           |feature on  the technical  and economic merits of OSI versus|
           |ARPANET-style networking.  Enough issues have been raised to|
           |require a  complete article  to continue the discussion. The|
           |debate is  of major interest because managers are now making|
           |strategic decisions  which will affect the development, cost|
           |and functionality  of  corporate  networks  over  the  whole|
           |world.   A valid  approach to  the  debate  deals  with  the|
           |technical,  economic  and  logistic  issues  but  avoids  ad|
           |hominem attacks.  I apologize for those comments in my forum|
           |letter which  might be  construed  as  personal  attacks  on|
           |William Stallings.           				|
	   |								|
           |Since I  have not  yet published  many papers and my book is|
           |only 3/4s  finished, I  should  introduce  myself  before  I|
           |refute the  ideas which Stallings presented in the September|
           |EOT feature.   I am a system designer and implementer who is|
           |a founder and Project Director at Constellation Technologies|
           |which   is    a   Boston-based   start-up   consulting   and|
           |manufacturing  company   specializing  in   increasing   the|
           |performance, reliability  and security of standard low-level|
           |communications technologies   for  any of  the  plethora  of|
           |computer networking environments currently available.       |
           |                                                            |
           |I  am   not  an  "Arpanet  Old  Network  Boy."  My  original|
           |experience is   in  telephony.  I have implemented Signaling|
           |System 6, X.25, Q.921 and Q.931.  During a one-year research|
           |position at  MIT, I  worked on TFTP and helped develop the X|
           |network transparent  windowing protocol.   Later I developed|
           |PC/NTS which  uses IEEE  802.2 Type  2 to  provide  PC-Prime|
           |Series 50  connectivity over IEEE 802.3 (Ethernet) networks.|
           |My partner  Tony Bono  and I  have attended various IEEE and|
           |CCITT  standards-related   committees  in  various  official|
           |capacities. 				         	|
           _____________________________________________________________|

            II. THE DEBATE        

            Part of  the problem with debating is the lack of a mutually
            agreeable and  understood set  of concepts in which to frame
            the debate.   I  have yet  to meet a communications engineer
            who had  a sense  of what  a process might be. Having taught
            working  software   and  hardware   engineers   at   Harvard
            University and  AT&T and  having attended  the international
            standards  committees   with  many  hardware,  software  and
            communications  engineers,  I  have  observed  that  overall
            system design  concepts in  computer networking  need a  lot
            more  attention   and  understanding  than  they  have  been
            getting.  Normally in the standardization process, this lack
            of attention would not be serious because official standards
            bodies usually  simply make  official  already  existing  de
            facto standards  like Ethernet  2.0 which had already proven
            themselves.   In the  case of OSI, the ISO committee, for no
            obvious reasons, chose to ignore the proven ARPA Internet de
            facto standard.
            
           ______________________________________________________________
           |                                                            |
           |                       Architecture,           		| 
           |                 Functional Specification,           	|
           |                    Design Specification           		|
           |                                         |                  |
           |Nowadays, we  read a lot of hype about CASE, object-oriented|
           |program techniques  and languages  designed to facilitate or|
           |to ease  the development  of large software projects.  These|
           |tools generally duck the hardest and most interesting system|
           |design and  development problem  which is  the design  under|
           |constraint of  major systems  which somebody  might actually|
           |want to  buy.   The hype  avoids the real issue that student|
           |engineers are  either simply  not taught  or  do  not  learn|
           |system  design  in  university  engineering  programs.    If|
           |software engineers  generally knew how to produce acceptable|
           |architectures,   functional    specifications   and   design|
           |specifications, the  push for  automatic tools would be much|
           |less. In  fact, the  development of CASE tools for automatic|
           |creation of systems architectures, functional specifications|
           |and design specifications requires understanding exactly how|
           |to produce  proper architectures and specifications.  But if|
           |engineers  knew   how  to  produce  good  architectures  and|
           |specifications for  software, presumably  student  engineers|
           |would   receive    reasonable   instruction   in   producing|
           |architectures and  specifications, and  then there  would be|
           |much less  need for  automatic CASE  tools to produce system|
           |architectures,   functional    specifications   or    design|
           |specifications.						|
           |           							|
           |Just as  an architectural  description of  a building  would|
           |point  out  that  a  building  is  Gothic  or  Georgian,  an|
           |operating system  architecture  might  point  out  that  the|
           |operating system  is multitasking, pre-emptively time-sliced|
           |with kernel  privileged routines running at interrupt level.|
           |A  system   architecture  would   describe  statically   and|
           |abstractly the  fundamental operating  system entities.   In|
           |Unix, the  fundamental operating system entities on the user|
           |side would  be the  process and  the file.   The  functional|
           |specification  would   describe  the   functionality  to  be|
           |provided  to   the  user   within  the  constraints  of  the|
           |architecture. A functional specification should not list the|
           |function calls used in the system.  The design specification|
           |should specify  the model by which the architecture is to be|
           |implemented to  provide the desired functionality.  A little|
           |pseudocode can  be useful depending on the particular design|
           |specification detail  level.   Data  structures,  which  are|
           |likely to  change many  times during implementations, should|
           |not appear in the design specification.			|
           |								|
           |Ancillary  documents   which  treat  financial  and  project|
           |management issues  should be  available to  the  development|
           |team.   In all  cases documents  must be  short.  Otherwise,|
           |there is  no assurance the all members of the development or|
           |product management  teams will  read  and  fully  comprehend|
           |their documents.   Detail  and verbiage  can be the enemy of|
           |clarity.   Good architectures  and functional specifications|
           |for moderately  large systems  like Unix  generally  require|
           |about 10-20  pages.   A good high-level design specification|
           |for such  a system  would take  about  25  pages.    If  the|
           |documents are  longer, something  may be  wrong.  The key is|
           |understanding what should not be included in such documents.|
           |The  ISO   OSI  documents   generally  violate   all   these|
           |principles.							|
           _____________________________________________________________|

            As a  consequence, the  ISO OSI  committee and  OSI boosters
            have an  obligation to justify their viewpoint in debate and
            technical discussion  with computer  networking experts  and
            system designers.  Unfortunately, the debate over the use of
            OSI versus TCP/IP has so far suffered from three problems:
                 
                 o    a lack of systems level viewpoint,
                 
                 o    a lack of developer insight and
                 
                 o    an hostility toward critical appraisal either
                      technically or economically of the proposed ISO
                      OSI standards.

            The following material is an attempt to engage in a critical
            analysis  of  OSI  on  the  basis  of  system  architecture,
            development principles and business economics.  Note that in
            the following article unattributed quotations are taken from
            the itemized  list which Stallings used in EOT to attempt to
            summarize my position.

            III. INTERNETWORKING:  THE KEY SYSTEM LEVEL START POINT

            The most  powerful system level architectural design concept
            in   modern    computer   networking   is   internetworking.
            Internetworking is practically absent from the OSI reference
            model  which   concentrates  on   layering,  which   is   an
            implementation technique,  and on  the  virtual  connection,
            which  would   be  a   feature  of  a  proper  architecture.
            Internetworking   is good  for the same reason Unix is good.
            The Unix  architects and the ARPA Internet architects, after
            several missteps, concluded that the most useful designs are
            achieved by  first choosing  an effective  computational  or
            application model  for the user and then figuring out how to
            implement this  model  on  a  particular  set  of  hardware.
            Without taking  a position on success or failure, I have the
            impression that  the  SNA  and  VMS  architects  by  way  of
            contrast set  out to  make the  most effective  use of their
            hardware.   As a  consequence both  SNA and  VMS are  rather
            inflexible systems  which are  often rather inconvenient for
            users even  though the  hardware is  often quite effectively
            used.   Of course,  starting from  the user computational or
            application model  does not  preclude eventually  making the
            most  effective   use  of  the  hardware  once  the  desired
            computational or application model has been implemented.

           ______________________________________________________________
           |                                                            |
           |                      Internetworking           		|
           |           							|
           |The internetworking  approach enables  system designers  and|
           |implementers to  provide network users with a single, highly|
           |available,  highly   reliable,   easily   enlarged,   easily|
           |modifiable, virtual network.  The user does not need to know|
           |that this single virtual network is  composed of a multitude|
           |of technologically  heterogeneous wide  area and  local area|
           |networks    with     multiple    domains    of    authority.|
           |Internetworking is  achieved by  means of  a coherent system|
           |level  view  through  the  use  of  an  obligatory  internet|
           |protocol  with   ancillary  monitoring  protocol,  gateways,|
           |exterior/internal gateway  protocols and hierarchical domain|
           |name service.                                               |
           |                                                            |
           |In the  internetworking (not  interworking) approach, if two|
           |hosts are  attached to  the same  physical subnetwork  of an|
           |internetwork,  the  hosts  communicate  directly  with  each|
           |other.   If the  hosts are  attached to  different  physical|
           |subnetworks, the  hosts communicate  via gateways  local  to|
           |each host.   Gateways  understand and learn the internetwork|
           |topology dynamically  at a  subnetwork (not  host level) and|
           |route  data   from  the  source  subnetwork  to  destination|
           |subnetwork on a subnetwork hop by subnetwork hop basis.  The|
           |detail of information required for routing and configuration|
           |is reduced  by orders  of magnitude.   In the ARPA Internet,|
           |gateways  learn   topological  information  dynamically  and|
           |provide reliability  as well  as availability  by performing|
           |alternate routing  of  IP  datagrams  in  cases  of  network|
           |congestion or network failures.                             |
           |                                                            |
           |An authoritative  domain,  Within  the  ARPA  Internet,  can|
           |conceal from  the rest of the internetwork a lot of internal|
           |structural detail  because gateways  in other  domains  need|
           |only  know  about  gateways  within  their  own  domain  and|
           |gateways  between  authoritative  domains.    Thus,  logical|
           |subnetworks  of  an  internetwork  may  also  themselves  be|
           |catenets  (concatenated  networks)  with  internal  gateways|
           |connecting  different   physical  subnetworks   within  each|
           |catenet.   For example, to send traffic to MIT, a gateway at|
           |U.C. Berkeley  only need know about gateways between MIT and|
           |other domains  and need  know  nothing  about  the  internal|
           |structure of the MIT domain's catenet.                      |
           _____________________________________________________________|

            
	    The ARPA  Internet is one realization of the internetworking
            model.   While I am not particularly enamored of some of the
            ARPA protocol  features (nor  of Unix features by the way),1
            the ARPA  Internet works  well with  capacity for expansion.
            SINet  (described   in  "How  to  grow  a  world-class  X.25
            network," Data  Communications, May  1988) is  based on  the
            CSNet subnetwork within the ARPA Internet.
            ____________________

            1 The  use of  local-IP-address, local-TCP-port,  remote-IP-
            address, remote-TCP-port  quadruples to  uniquely identify a
            given TCP  virtual circuit  is an  impediment  to  providing
            greater  reliability  and  availability  for  a  non-gateway
            multihomed host.   A  even larger  problem with TCP/IP could
            lie   in    the   possibly   non-optimal   partitioning   of
            functionality between TCP, IP and ICMP.
            ____________________
            
           ______________________________________________________________
           |                                                    	|
           |                        WANs and LANs			|
           |                                     			|
           |OSI actually  has an  architecture.   Like the  ARPANET, OSI|
           |predicates  the   existence  of   a  communications   subnet|
           |consisting  communications   subnet  processors  (or  subnet|
           |switches) and  communications subnet  access processors  (or|
           |access switches).   Access  switches are  also known as IMPs|
           |(Interface Message Processors) or PSNs (Packet Switch Nodes)|
           |in the  ARPANET context.  PSPDN (Packet-Switched Public Data|
           |Network)  terminology  usually  designates  access  switches|
           |simply as  packet switches.  The communication subnet may be|
           |hierarchical and  may contain  adjunct processors other than|
           |subnet and  access switches.   The  internal architecture of|
           |the  communications   subnet  is  quite  distinct  from  the|
           |architecture   presented    to   end-point   hosts.      The|
           |communications subnet may use protocols completely different|
           |from the  protocols used  for communication between two end-|
           |point hosts.   An end-point host receives and transmits data|
           |to its  attached access switch via a subnet access protocol.|
           |The communications subnet is responsible for taking a packet|
           |received at  an access switch and transporting the packet to|
           |the access  switch attached  to  the  destination  end-point|
           |host.   The existence  of such a well-defined communications|
           |subnet is the hall mark of a Wide-Area Network (WAN).       |
	   								|
           |Unfortunately,  from   the  standpoint  of  making  computer|
           |networking generally and inexpensively available, access and|
           |subnet switches  are expensive  devices to  build which need|
           |fairly complicated  control software.   DECNET  gets  around|
           |some of  these problems  by incorporating the communications|
           |subnet logic  into  end-point  hosts.    As  a  consequence,|
           |customers who  wish to run DECNET typically have to purchase|
           |much more  powerful machines  than they might otherwise use.|
           |For the  situation of  a communications  subnet  which  need|
           |support connectivity  for only  a small number of hosts, LAN|
           |developers  found   a  more   cost  effective   solution  by|
           |developing a  degenerate form  of packet  switches based  on|
           |hardware-logic  packet   filtering  rather   than   software|
           |controlled  packet   switching.    These  degenerate  packet|
           |switches are  installed in the end-point hosts, are accessed|
           |often via  DMA2 as  LAN  controllers  and  are  attached  to|
           |extremely simplified  communications  subnets  like  coaxial|
           |cables.     Direct   host-to-switch   (controller)   access,|
           |degenerate    packet-switching     (packet-filtering)    and|
           |simplified communications  subnets  are  the  distinguishing|
           |features of LANs.           				|
           |           							|
           |While ISO  was ignoring  the whole  internetworking issue of|
           |providing universal  connectivity  between  end-point  hosts|
           |attached to different physical networks within internetworks|
           |composed of  many  WANs  and  even  more  LANs  concatenated|
           |together, and while the IEEE was confusing all the issues by|
           |presenting as an end-to-end protocol a communications subnet|
           |protocol (IEEE  802.2)  based  on  a  communications  subnet|
           |access protocol  (X.25 level 2), the ARPA Internet community|
           |developed an  internet architecture capable of providing the|
           |universal connectivity  and resource sharing which business,|
           |technical and academic users really want and need.         	|
           ______________________________________________________________

            ____________________
            
            2 Some  machines like the Prime 50 Series do not use genuine
            DMA  but  instead  use  inefficient  microcoded  I/O.    IBM
            machines generally  use more  efficient  and  somewhat  more
            expensive internal switching.
            ____________________


            The backbone  of the  ARPA Internet  is the  ARPANET.    The
            ARPANET is  a packet  switched subnetwork  within  the  ARPA
            Internet.  The ARPANET communications subnet access protocol
            is 1822.   CSNet  was set up as an experiment to demonstrate
            that the  ARPA Internet  architecture and suite of protocols
            would function  on a  packet  network  whose  communications
            subnet access  protocol is  X.25.   Using  an  X.25-accessed
            packet network  instead of  an 1822-accessed  packet network
            makes sense  despite  the  glaring  deficiencies  of  X.25,3
            because X.25 controllers are available for many more systems
            than  1822   controllers  and   because   many   proprietary
            networking schemes like SNA and DECNET can use X.25-accessed
            packet networks  but cannot use a packet network accessed by
            1822.

            Yet,  calling  SINet  a  world  class  X.25  network  is  as
            reasonable  as  calling  the  ARPANET  a  world  class  1822
            network.4   Schlumberger has  produced a  world class TCP/IP
            network whose wires can be shared with SNA and DECNET hosts.
            Schlumberger  has   shown  enthusiasm   for  the   flexible,
            effective ARPANET  suite  of  protocols  but  has  given  no
            support in  the  development  of  SINet  to  the  idea  that
            business should prepare to migrate to OSI based networks.

            I  would   be  an   OSI-enthusiast  if  ISO  had  reinvented
            internetworking  correctly.    Unfortunately,  the  ISO  OSI
            reference model which first appeared in 1978 clearly ignored
            all the  ARPA community work on intercomputer networking and
            resource  sharing   which  was   easily  accessible  in  the
            literature of the time.  Instead of building the OSI network
            on an  internetworking foundation,  ISO standardized  on the
            older less  effective  host-to-packet-switch-to-packet-data-
            subnet-to-packet-switch-to-host (NCP)  model which the DARPA


            ____________________
            
            3 For  example, X.25 does flow control on the host to packet
            switch connection on the basis of packets transmitted rather
            than on  the  basis  of  consumption  of  advertised  memory
            window.   The exchange  of lots of little packets on an X.25
            connection can  cause continual transmission throttling even
            though the receiver has lots of space for incoming data.
            
            4 Or  as much  sense  as  calling  Ethernet  LANs  DMA-based
            networks because the packet switches (an Ethernet controller
            is a  degenerate case  of a  packet switch)  on the  LAN are
            typically accessed by DMA.
            ____________________


            had abandoned 5 years earlier because of lack of flexibility
            and other problems.

           ______________________________________________________________
           |                                                            |
           |           Pieces of the ARPA Internet Conceptually         | 
           |                                                		|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |			(No Graphics)			 	|
           |							 	|
           |							 	|
           ______________________________________________________________



            Nowadays, mostly in response to US vendors and DARPA, pieces
            of the ARPA Internet architecture have resurfaced in the OSI
            reference  model   quite  incoherently   rather  than  as  a
            consequence   of   an   integrated   correct   architectural
            viewpoint.  Connectionless-mode transmission is described in
            ISO/7498/DAD1 which  is an  addendum to  ISO 7498  and not a
            core document.   Because connectionless-mode transmission is
            defined in an addendum, the procedure apparently need not be
            implemented, and  UK GOSIP,  for example, explicitly rejects
            the use  of the  connectionless transmission  mode.      The
            introduction to the 1986 ISO 7498/DAD1 explicitly states, as
            follows, that  ISO was  extremely reluctant to incorporate a
            genuine datagram  based protocol  which could  be  used  for
            internetworking.

                ISO 7498 describes the Reference Model of Open
                Systems Interconnection.  It is the intention of
                that International standard that the Reference
                model should establish a framework for coordinating
                the development of existing and future standards
                for the interconnection of systems.  The assumption
                that connection is a fundamental prerequisite for
                communication in the OSI environment permeates the
                Reference Model and is one of the most useful and
                important unifying concepts of the architecture
                which it describes.  However, since the
                International Standard was produced it has been
                realized that this deeply-rooted connection
                orientation unnecessarily limits the power and
                scope of the Reference Model, since it excludes
                important classes of applications and important
                classes of communication network technology which
                have a fundamentally connectionless nature.

            An  OSI  connectionless-mode  protocol  packet  may  undergo
            something like  fragmentation, but from the literature, this
            form of  segmentation as  used in  OSI  networks  is  hardly
            equivalent to ARPA Internet fragmentation.  Stallings states
            the  following   in  Handbook   of   Computer-Communications
            Standards, the  Open Systems Interconnection (OSI) Model and
            OSI-Related Standards,  on p.  18  (the  only  reference  to
            anything resembling fragmentation in the book).

                Whether the application entity sends data in
                messages or in a continuous stream, lower level
                protocols may need to break up the data into blocks
                of some smaller bounded size.  This process is
                called segmentation.

            Such  a   process  is   not  equivalent   to  ARPA  Internet
            fragmentation.   In the  ARPA Internet  fragmentation is the
            process whereby  the gateway  software operating  at the  IP
            layer converts  a single  IP packet into several separate IP
            packets and  then routes the packets.  Each ARPA IP fragment
            has a  full IP  header.   It is  not obvious  that each  OSI
            segment has a complete packet header. The ARPA fragmentation
            procedure is not carried out by lower protocol layers.  A N-
            layer packet  in OSI  is segmented  at layer  N-1 while  the
            packet is routed (relayed) at layer N+1.

            This partitioning of basic internetworking procedures across
            layer 2  (N-1), layer  3 (N)  and layer 4 (N+1) violates the
            following principles described in ISO/DIS 7498:  Information
            Processing Systems  -- Open Systems Interconnection -- Basic
            Reference Model.
                         
                 P1:  do not create so many layers as to make the system
                      engineering task of describing and integrating the
                      layers more difficult than necessary [ISO uses
                      three layers where one could be used];
                      
                 
                 P2:  create a boundary at a point where the description
                      of services can be small and the number or
                      interactions across the boundary are minimized [by
                      putting per-packet relaying in layer 4 at least
                      two interactions across the boundary are required
                      per packet];
                 
                 P5:  select boundaries at a point which past experience
                      has demonstrated to be successful [the ARPA
                      Internet layering boundaries which combine the
                      addressing, fragmentation and routing in one layer
                      has proven successful];
                 
                 P6:  create a layer where there is a need for a
                      different level of abstraction in the handling of
                      data, e.g. morphology, syntax, semantics
                      [fragmentation, routing, and network addressing
                      are all seem quit naturally to be part of network
                      layer semantics as the ARPA Internet example
                      shows];
                 
                 P9:  allow changes of functions or protocols to be made
                      within a layer without affecting other layers [I
                      would think changing the manner of addressing at
                      layer 3 would affect relaying at layer 4].

            Even if  OSI N-1 segmentation and N+1 relaying could be used
            in the  same way  as fragmentation  and routing  in the ARPA
            Internet,  it   takes  a  lot  more  apparatus  than  simply
            permitting the  use of  the  ISO  connectionless  "internet"
            protocol to achieve internetworking.

            The OSI  documents almost  concede this  point  because  ISO
            7498/DAD 1,  ISO/DIS 8473 (Information Processing Systems --
            Data    Communications    --    Protocol    for    Providing
            Connectionless-Mode Network Service) actually provide for N-
            layer  segmentation  (actually  fragmentation)  and  N-layer
            routing right  in the  network layer  in addition to the OSI
            standard N-1  segmentation and N+1 relaying.  Providing such
            functionality directly  in the  network layer actually seems
            in greater accordance with OSI design principles, but if ISO
            is really  conceding this  point, ISO  should  go  back  and
            redesign the system rather than leaving this mishmash of N-1
            segmentation, N  segmentation, N  routing and  N+1 relaying.
            The current  connectionless-mode network  service  is  still
            insufficient  for   internetworking  because   the   gateway
            protocols are  not present and the connectionless-mode error
            PDUs (Protocol Data Units) do not provide the necessary ICMP
            functionality.     The  documents   also  indicate  a  major
            confusion between  an internetwork  gateway, which  connects
            different subnetworks of one catenet (concatenated network),
            and  a   simple  bridge,  which  connects  several  separate
            physical networks  into a  single network at the link layer,
            or an interworking unit, which is a subnet switch connecting
            two different  communications subnets either under different
            administrative  authorities   or  using  different  internal
            protocols.5    Tanenbaum  writes  the  following  about  the

            ____________________
            
            5  This  confusion  is  most  distressing  from  a  security
            standpoint.   The November  2 ARPA  Internet (Cornell) virus
            attack shows  that one  of  the  major  threats  to  network
            security is  insider attack which is a problem with even the
            most isolated corporate network.  Because many ARPA Internet
            network authorities  were assuming  insider  good  behavior,
            ARPA Internet  network administrators  often did  not  erect
            security  barriers   or  close   trapdoors.    Nevertheless,
            gateways  have   far  more   potential   than   bridges   or
            interworking units to provide reasonable firewalls to hinder
            and frustrate  insider attack.    MIT/Project  Athena  which
            makes judicious  use of  gateways and  which does not assume
            insider good  behavior  was  relatively  unaffected  by  the
            virus. Any  document which  confuses gateways,  bridges  and
            interworking units is encouraging security laxity.
            ____________________


            connectionless-mode network service in Computer Networks, p.
            321.

                In the OSI model, internetworking is done in the
                network layer.  In all honesty, this is not one of
                the areas in which ISO has devised a model that has
                met with universal acclaim (network security is
                another one).6  From looking at the documents, one
                gets the feeling that internetworking was hastily
                grafted onto the main structure at the last minute.
                In particular, the objections from the ARPA
                Internet community did not carry as much weight as
                they perhaps should have, inasmuch as DARPA had 10
                years experience running an internet with hundreds
                of interconnected networks, and had a good idea of
                what worked in practice and what did not.

            Internetworking,  the   key  concept   of  modern   computer
            networking, exists  within the  OSI  reference  model  as  a
            conceptual wart  which violates even the OSI principles.  If
            ISO had  not tacked  internetworking onto the OSI model, ISO
            was afraid  that DARPA  and that  part of  the  US  computer
            industry with  experience with  modern  computer  networking
            would have  absolutely rejected  the OSI  reference model as
            unusable.
            ____________________            

            6 Actually,  I find ISO 7498/2 (Security Architecture) to be
            one of  the more  reasonable ISO documents. I would disagree
            that simple  encryption is  the only  form of security which
            should be  performed at  the link  layer  because  it  seems
            sensible that  if a  multilevel secure mini is replaced by a
            cluster of  PCs on  a  LAN,  multilevel  security  might  be
            desirable at  the link layer.  Providing multilevel security
            at the link layer would require more than simple encryption.
            Still, ISO  7498/2 has the virtue of not pretending to solve
            completely the network security problem.  The document gives
            instead a  framework indentifying  fundamental concepts  and
            building blocks  for  developing  a  security  system  in  a
            networked environment.
            ____________________            

                                                           
            IV. "GREATER RICHNESS" VERSUS DEVELOPER INSIGHT

            In view  of this  major conceptual  flaw which  OSI has with
            respect to  internetworking,  no  one  should  therefore  be
            surprised that  instead of  tight technical  discussion  and
            reasoning,  implementers   and   designers   like   me   are
            continually  subjected   to  vague  assertions  of  "greater
            richness" of  the  OSI  protocols  over  the  ARPA  Internet
            protocols.   In ARPA  Internet  RFCs,  real-world  practical
            discussion is  common.   I  would not mind similar developer
            insight or  even hints  about the  integration of  these OSI
            protocol  interpreters   into  genuine   operating   systems
            participating in an OSI interoperable environment.

            The customers  should realize "greater richness" costs a lot
            of extra  money even  if a  lot of  the added  features  are
            useless  to   the   customer.   "Greater   richness"   might
            necessitate the  use of  a much  more powerful  processor if
            "greater  richness"   forced  much   more   obligatory   but
            purposeless protocol processing overhead. "Greater richness"
            might also represent a bad or less than optimal partitioning
            of the problem.

                       A. OSI NETWORK MANAGEMENT AND NETVIEW

            Netview has  so much  "greater richness"  than  the  network
            management protocols  and systems  under development  in the
            ARPA Internet  context that  I have  real problems  with the
            standardization of  Netview into  OSI network  management as
            the obligatory  user interface  and  data  analysis  system.
            Netview is  big, costly,  hard to  implement, and  extremely
            demanding on  the rest of the network management system.  As
            OSI network  management  apparently  subsumes  most  of  the
            capabilities of  Arpanet ICMP  (Internet Control  Monitoring
            Protocol) which  is a sine qua non for internetworking, I am
            as a developer rather distressed that full blown OSI network
            management (possibly  including  a  full  implementation  of
            FTAM)  might have to run on a poor little laser printer with
            a dumb  ethernet interface  card  and  not  much  processing
            power.

                                B. FTAM IS DANGEROUS

            The "greater  richness" of  FTAM seems to lie in the ability
            to transmit  single records  and in  the ability  to restart
            aborted file  transfer sessions.    Transmission  of  single
            records seems  fairly useless  in  the  general  case  since
            operating systems  like Unix  and DOS do not base their file
            systems on  records while  the records  of file systems like
            those of  Primos and VMS  have no relationship whatsoever to
            one another.    Including  single  record  or  partial  file
            transfer in  the remote  transfer utility  seems is  a  good
            example of bad partitioning of the problem.  This capability
            really belongs in a separate network file system.  A network
            file system should be separate from the remote file transfer
            system because  the major  issues in  security, performance,
            data  encoding   translation  and  locating  objects  to  be
            transferred are different in major ways for the two systems.

            The ability  to  restart  aborted  file  transfers  is  more
            dangerous than  helpful.  If the transfer were aborted in an
            OSI network,  it could have been aborted because one or both
            of the  end hosts  died or because some piece of the network
            died.  If the network died, a checkpointed file transfer can
            probably be restarted.  If a host died on the other hand, it
            may have  gradually gone  insane and  the checkpoints may be
            useless.   The checkpoints  could only  be guaranteed if end
            hosts  have   special  self-diagnosing  hardware  (which  is
            expensive).   In the absence of special hardware and ways of
            determining exactly  why a  file transfer  aborted, the file
            transfer must  be restarted from the beginning.  By the way,
            even with  the greater  richness of FTAM, it is not clear to
            me that a file could be transferred by FTAM from IBM PC A to
            a Prime Series 50 to IBM PC B in such a way that the file on
            PC A and on PC B could be guaranteed to be identical.

                  C. X.400:  E-MAIL AS GOOD AS THE POSTAL SERVICE

            As currently  used and  envisioned, the X.400 family message
            handling also  has  "greater  richness."    X.400  seems  to
            include   binary-encoded   arbitrary   message-transmission,
            simple  mail   exchange  and   notification  provided  by  a
            Submission and  Delivery Entity  (SDE).   In comparison with
            ARPA SMTP  (Simple Mail  Transfer Protocol), X.400 is overly
            complicated with  hordes  of  User  Agent  Entities  (UAEs),
            Message Transfer  Agent Entities  (MTAEs) and SDEs scurrying
            around potentially eating up -- especially during periods of
            high traffic  -- lots  of  computer  cycles  on  originator,
            target and  intermediate host systems because the source UAE
            has to transfer mail through the local MTAE and intermediate
            MTAEs on  a hop-by-hop  basis to get to the target machine.7

            ____________________
            
            7 I have to admit that if I were implementing X.400, I would
            probably implement  the local  UAE and  MTAE in one process.
            The  CCITT  specification  does  not  strictly  forbid  this
            design,  but  the  specification  does  seem  to  discourage
            strongly such  a design.   I consider it a major flaw with a
            protocol  specification  when  the  simplest  design  is  so
            strongly counterindicated.   It  does seem  to be obligatory
            that mail  traffic  which  passes  through  an  Intermediate
            System (IS) must pass through an MTAE running on that IS.
            ____________________


            The design is particularly obnoxious because X.400 increases
            the number  of ways  of getting mail transmission failure by
            using so  many intermediate  entities  above  the  transport
            layer. The  SMTP architecture  is, by  contrast, simple  and
            direct.  The user mail program connects to the target system
            SMTP daemon  by a  reliable byte  stream (like a TCP virtual
            circuit) and  transfers  the  mail.    Hop-by-hop  transfers
            through intermediate  systems are possible when needed.  One
            SMTP daemon  simply connects  to another the same way a user
            mail program connects to an SMTP daemon.

            The relatively  greater complexity  and obscurity  of  X.400
            arises because  a major  purpose of  X.400 seems  to  be  to
            intermingle  intercomputer   mail  service   and   telephony
            services  like   telex  or   teletex  to  fit  the  computer
            networking  into   the  PTT  (Post,  Telegraph  &  Telephone
            administration)  model   of  data   communications  (not  an
            unreasonable goal  for a  CCITT protocol  specification  but
            probably not the best technical or cost-effective design for
            the  typical   customer).    Mail  gateways  are  apparently
            supposed to  handle  document  interchange  and  conversion.
            Document interchange and conversion is a really hard problem
            requiring detailed knowledge at least of word processor file
            formats, operating  system architecture,  data encoding, and
            machine architecture.

            It may  be impossible  to   develop a  satisfactory  network
            representation  which   can  handle  all  possible  document
            content, language and source/target hardware combinations as
            well as  provide interconversion  with tradition  telephonic
            data transmission encodings. The cost of development of such
            a system might be hard to justify, and a customer might have
            a hard time justifying paying the price a manufacturer would
            probably have  to charge  for this  product. A  network file
            system  or   remote  file  transfer  provides  a  much  more
            reasonable means  of document  sharing or  interchange  than
            tacking an  e-mail address  into a  file with  a complicated
            internal structure,  sending  this  file  through  the  mail
            system and  then removing  the addressing information before
            putting the  document through  the appropriate  document  or
            graphics handler.

            A NETASCII-based  e-mail system  corresponds exactly  to the
            obvious mapping  of the  typical physical letter, which does
            not usually  contain complicated  pictorial or tabular data,
            to an  electronic letter  and is  sufficient for practically
            all electronic  mail traffic.  Special hybrid systems can be

            developed for  that extremely  tiny fraction  of traffic for
            which NETASCII  representations may  be insufficient and for
            which a network file system or FTP may be insufficient.    A
            correct partitioning  of the  electronic mail should be kept
            completely  separate   from  telephony   services,  document
            interchange and document conversion.

            
           ______________________________________________________________
	   |								|
           |                    X.400 Mail Connections			|
           |                                                            |
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |			(No Graphics)			 	|
           |							 	|
           |							 	|
           ______________________________________________________________


                 D. ARPA SMTP:  DESIGNING MAIL AND MESSAGING RIGHT

            The MIT environment at Project Athena, where IBM and DEC are
            conducting a  major  experiment  in  the  productization  of
            academic software,  provides an  instructive example  of the
            differences between e-mail, messaging and notification.  The
            mail system  used at  MIT is  an implementation of the basic
            SMTP-based ARPA  Internet mail  system. More than four years
            ago the  ARPA Internet  mail system  was  extremely powerful
            and world-spanning.   It  enabled  then  and  still  enables
            electronic mail  to reach  users on any of well over 100,000
            hosts in  N. America,  Europe, large portions of E. Asia and
            Israel.   The Citicorp  network (described  in "How one firm
            created  its  own  global  electronic  mail  network,"  Data
            Communications,  June   1988,  p.   167),   while   probably
            sufficient  for   Citicorp's  current   needs,  connects  an
            insignificant number of CPUs (47), provides no potential for
            connectivity outside  the Citicorp  domain of authority  and
            will probably  not scale  well with  respect to  routing  or
            configuration as it grows.

            The MIT  environment is complex and purposely (apparently in
            the strategies  of DEC  and IBM)  anticipates  the  sort  of
            environment which  should become typical within the business
            world within  the next  few years.   MIT is an authoritative
            domain within  the ARPA  Internet.   The gateways out of the
            MIT domain  communicate with  gateways in  other domains via
            the Exterior  Gateway Protocol (EGP).  Internally, currently
            used internal gateway protocols are GGP, RIP and HELLO.  The
            MIT domain  is composed of a multitude of Ethernet and other
            types of  local area  networks connected  by  a  fiber-optic
            backbone physically  and by gateway machines logically. This
            use of  gateways provides  firewalls between  the  different
            physical networks  so that  little sins  (temporary  network
            meltdowns caused  by Chernobyl  packets) do  not become  big
            sins propagating  themselves throughout  the network.    The
            gatewayed architecture  of the  MIT network  also permits  a
            necessary traffic engineering by putting file system, paging
            and boot  servers on  the same  physical network  with their
            most likely clients so that this sort of traffic need not be
            propagate throughout the complete MIT domain.

            Difficult to  reach locations  achieve connectivity by means
            of non-switched  telephone links.   Since  MIT has  its  own
            5ESS, these  links may  be converted  to ISDN at some point.
            While there  are some  minis and  mainframes in the network,
            the vast  majority of  hosts  within  the  MIT  network  are
            personal workstations with high resolution graphics displays
            of the  Vaxstation and  RT/PC type and personal computers of
            the IBM  PC, PC/XT  and PC/AT  type.   A few  Apollos, Suns,
            Sonys and  various workstations of the 80386 type as well as
            Lisp Machines  and PCs  from other  manufacturers like Apple
            are also  on the  air.  Most of the workstations are public.
            When a user logs in to such a workstation, after appropriate
            Kerberos (MIT  security system)  authentication, he has full
            access to  his own  network files  and directory  as well as
            access to  those resources  within the  network which he has
            the right to use.

            To assist  the administration  of the  MIT domain within the
            ARPA  Internet,   several   network   processes   might   be
            continually sending (possibly non-ASCII) event messages to a
            network  management  server  which  might  every  few  hours
            perform some  data analysis  on received  messages and  then
            format  a   summary  mail  message  to  send  to  a  network
            administrator.   This mail  message would  be placed in that
            network administrator's  mailbox by  his  mail  home's  SMTP
            daemon  which   then  might   check  whether   this  network
            administrator is reachable somewhere within the local domain
            (maybe on  a PC  with a network interface which was recently
            turned on and then was dynamically assigned an IP address by
            a  local  authoritative  dynamic  IP  address  server  after
            appropriate  authentication).    If  this  administrator  is
            available,  the   SMTP  daemon  might  notify  him  via  the
            notification service  (maybe by  popping up  a window on the
            administrator's display)  that he has received mail which he
            could read  from his  remote  location  via  a  post  office
            protocol.

            I have  seen the  above system being developed on top of the
            basic "static"  TCP/IP protocol suite by researchers at MIT,
            DEC and  IBM over  the last  4 years.   X.400 contains a lot
            this MIT  network functionality mishmashed together but I as
            a customer or designer prefer the much more modular MIT mail
            system.   It is  an   extensible,  dynamically  configurable
            TCP/IP-based architecture  from which a customer could chose
            those pieces  of the  system which he needs.  The MIT system
            requires relatively  little static  configuration.   Yet  by
            properly choosing  the system  pieces, coding an appropriate
            filter program  and setting  up a tiny amount of appropriate
            configuration data, a customer could even set up a portal to
            send e-mail  to a fax machine. In comparison, X.400 requires
            complicated directory  services and  an  immense  amount  of
            static configuration about the end user and end user machine
            to   compensate   for   the   internetworking-deficient   or
            internetworking-incompatible addressing scheme. The need for
            such a  level of  static configuration  is  unfortunate  for
            system users  because in  the real world a PC or workstation
            might easily  be moved  from one  LAN to another or might be
            easily replaced by a workstation or PC of another type.

            An MIT-style  mail system  could also  be  much  cheaper  to
            develop and  consequently  could  be  much  less  costly  to
            purchase  than  an  X.400  mail  system  simply  because  it
            represents a  much better  partitioning of the problem.  One
            or two engineers produced each module of the MIT mail system
            in approximately  6  months.    Because  of  complexity  and
            obscurity, the  development of  X.400  products  (I  saw  an
            example at Prime) is measured in staff years.  The executive
            who chooses  X.400 will  cost his  firm an immense amount of
            money which  will look  utterly wasted  when his  firm joins
            with another  firm in some venture and the top executives of
            both firms  try  to  exchange  mail  via  their  X.400  mail
            systems.   Simple mail  exchange between  such systems would
            likely be  very hard  to impossible  because  the  different
            corporations  could   easily  have   made  permissible   but
            incompatible choices in their initial system set-up.  At the
            very last  complete reconfiguration of both systems could be
            necessary.   Had the  firms chosen  an  ARPA  Internet  mail
            system like  the  MIT  system,  once  both  firms  had  ARPA
            Internet connectivity  or set up a domain-to-domain gateway,
            mail would simply work.

            
           ______________________________________________________________
           |                                                        	|    
	   |			SMTP Mail Connections			|
           |                                                            |
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |			(No Graphics)			 	|
           |							 	|
           |							 	|
           ______________________________________________________________


            V. IS THE TCP/IP PROTOCOL SUITE "STATIC?"

            Because of  the mail  system development in progress at MIT,
            DEC and  IBM, the X development which I and others have done
            and which is still continuing, SUN NFS (Network File System)
            development,  IBM  AFS  (Andrew  File  System)  development,
            Xenix-Net development,  Kerberos development,  and the other
            plethora of protocol systems being developed within the ARPA
            Internet context  (including the VMTP transaction processing
            system and  commercial  distributed  database  systems  like
            network Ingress),  I am  at the  very least  puzzled by  Mr.
            Stallings' assertion   that  "[it] is the military standards
            that appear  on procurement  specifications  and  that  have
            driven  the   development  of   interoperable   commercially
            available TCP/IP products."
           ______________________________________________________________
           |                                                            |
           |                  Partitioning the Problem           	|
           |           							|
           |The X  window system  is an  example of  a clearly  and well|
           |partitioned system.   In  windowing, the  first piece of the|
           |problem is  virtualizing the high-resolution raster graphics|
           |device.  Individual applications do not want or need to know|
           |about the  details  of  the  hardware.    Thus,  to  provide|
           |hardware independence,  applications should  only deal  with|
           |virtual high-resolution  raster-graphics devices  and should|
           |only know  about its  own virtual  high  resolution  raster-|
           |graphics devices  (windows).   The next piece of the problem|
           |is  to  translate  between  virtual  high-resolution  raster|
           |graphics devices  and the  physical  high-resolution  raster|
           |graphics device  (display).   The final  part of the problem|
           |lies in  managing the windows on the display.  This problem,|
           |with a  little consideration  clearly differentiates  itself|
           |from  translating   between  virtual   and  physical   high-|
           |resolution raster-graphics devices.                         |
           |           |                                                |
           |In  the   X  window   system,  communication   between   the|
           |application and  its windows is handled by the X library and|
           |those libraries  built  on  top  of  the  basic  X  library.|
           |Virtual to  physical and  physical to virtual translation is|
           |handled by the X server.  X display management is handled by|
           |the X window manager.           |                           |
           |           |                                                |
           |After partitioning  the problem,  careful  consideration  of|
           |display management  leads to  the  conclusion  that  if  all|
           |windows on  a display  are treated as "children" of a single|
           |"root" window,  all of  which "belong"  in some sense to the|
           |window manager,  then the X window manager itself becomes an|
           |ordinary application  which talks  to the X server via the X|
           |library.   As a consequence, developers can easily implement|
           |different  display   management   strategies   as   ordinary|
           |applications without  having to "hack" the operating system.|
           |The  server  itself  may  be  partitioned  (under  operating|
           |systems which support the concept) into a privileged portion|
           |which directly  accesses the  display hardware  and  a  non-|
           |privileged  portion   which  requests   services  from   the|
           |privileged part  of the  server.  Under Unix, the privileged|
           |part of the server goes into the display, mouse and keyboard|
           |drivers while  the non-privileged  part becomes  an ordinary|
           |application.  In common parlance, X server usually refers to|
           |the non-privileged part of the X server which is implemented|
           |as an ordinary application.                                 |
           |                                                            |
           |The last  step in  realizing the X window system is choosing|
           |the  communications  mechanism  between  the  X  server  and|
           |ordinary applications  or the  display manager.  Because the|
           |problem was  nicely partitioned,  the communications problem|
           |is completely extrinsic to the windowing problem as lives as|
           |an easily  replaceable interface module.  The initial choice|
           |at MIT  was to  use TCP/IP  virtual circuits, which provided|
           |immediate network  transparency, but  in fact because X only|
           |requires sequenced  reliable byte-streams so that DECNET VCs|
           |or  shared-memory   communications  mechanisms   can  easily|
           |replace   TCP/IP   virtual   circuits   according   to   the|
           |requirements of  the target  environment.   Systems built on|
           |well-partitioned approaches  to solving  problems often show|
           |such flexibility  because of  modularity of the approach and|
           |because a  successful partitioning of the problem will often|
           |in its  solution increase  the understanding of the original|
           |problem that  developers can  perceive greater  tractability|
           |and simplicity  in the  original and  related problems  than|
           |they might have originally seen.                            |
           _____________________________________________________________|

            It seems  somewhat  propagandistic    to  label  the  TCP/IP
            protocol  suite   static  and   military.     New  RFCs  are
            continually being  generated as Paul Strauss has pointed out
            in his  September article.  Such new  protocols only  become
            military   standards    slowly    because    the    military
            standardization of  new protocols  and  systems  is  a  long
            tedious political  process which  once completed may require
            expensive conformance  and verification  procedures.   After
            all, neither  the   obligatory ICMP nor the immensely useful
            UDP  (User   Datagram  Protocol)  have  associated  military
            standards. Often,  after reviewing  those products generated
            by market  forces, the  US military  specifies and  acquires
            products which go beyond existing military standards. By the
            way, hierarchical  domain name  servers and  X are  used  on
            MILNET.

            VI. ENTERPRISE NETWORKING AND SOPHISTICATED APPLICATIONS:   
            SELLING INTERCOMPUTER NETWORKING            

            The military  are not  the only  users "more  interested  in
            sophisticated  applications  than  in  a  slightly  enhanced
            version of  Kermit."   The whole  DEC enterprise  networking
            strategy  is   postulated  on  this  observation.  Stallings
            ignored  my   reference  to   network  file   systems  as  a
            sophisticated  networking   application.  Yet,   in  several
            consulting jobs,  I have seen brokers and investment bankers
            make extensive  use of network file systems.  I also believe
            network transparent graphics will be popular in the business
            world.     At  Saloman   Brothers  both   IBM  PCs  and  SUN
            workstations are  extensively used.   With X, it is possible
            for a  PC user  to run a SUN application remotely which uses
            the PC  as the  output device.  This capability seems highly
            desirable in the Saloman Brothers environment.

            Unfortunately "OSI  is unlikely  ever to  provide for [such]
            resource sharing because it is industry-driven."  Wayne Rash
            Jr.,  a   member  of  the  professional  staff  of  American
            Management Systems,  Inc.  (Arlington, Virginia) who acts as
            a US federal government microcomputer consultant, writes the
            following in  "Is More Always Better," Byte, September 1988,
            p. 131.

                You've probably seen the AT&T television ads about
                this trend [toward downsizing and the development
                of LAN-based resource-sharing systems].  They
                feature two executives, one of whom is equipping
                his office with stand-alone microcomputers.  He's
                being intimidated by another executive, who tells
                him in a very nasty scene, "Stop blowing your
                budget" on personal computers and hook all your
                users to a central system.  This is one view of
                workgroup computing, although AT&T has the perverse
                idea that the intimidator is the forward thinker in
                the scene.

            AT&T and  to an  even greater  extent the similarly inclined
            European PTTs have major input into OSI specification.

            VII. BIG AND SMALL PLAYERS CONSTRAIN OSI            

            The inclinations  of AT&T  and the  PTTs are  not  the  only
            constraints  under   which  the   OSI  reference  model  was
            developed.   A proprietary  computer networking system, sold
            to a customer, becomes a cow which the manufacturer can milk
            for years. Complete and effective official standards make it
            difficult  for   a  company   to  lock  a  customer  into  a
            proprietary system.   A customer could shop for the cheapest
            standard  system,   or  could  chose  the  offering  of  the
            manufacturer considered  most reliable.   It  is  proverbial
            that no  MIS executive  gets fired  for choosing IBM.  Small
            players have  genuine reason  to fear that a big player like
            Unisys, which  no longer  has a  major proprietary  computer
            networking installed base8, or AT&T, which never had a major
            proprietary computer  networking installed  base9, might try
            to establish  themselves in  the minds  of customers  as the
            ultimate authority  for the supply of true OSI connectivity.
            Thus, small  players fear  that  a  complete  and  effective
            official  standard  might  only  benefit  the  big  players.
            Players like  AT&T or  Unisys fear  IBM  might  hi-jack  the
            standard.   IBM would prefer to preserve its own proprietary
            base  and   avoid  competing  with  the  little  guys  on  a
            cost/performance basis  in what  could turn into a commodity
            marker.

            No such  considerations were operative in the development of
            the ARPA  Internet suite of protocols.  DARPA had a specific
            need for  intercomputer networking,  was willing  to pay top
            dollar  to   get  the   top  experts  in  the  intercomputer
            networking field  to design  the system  right and  was less
            concerned by  issues of competition (except perhaps for turf
            battles within  the U.S.  government).   By contrast, almost
            all players  who have  input into  the  ISO  standardization
            process have  had reasons and have apparently worked hard to
            limit the effectiveness of OSI systems.

            With all  the limitations, which have been incorporated into
            the OSI  design and  suite of  protocols, the  small players
            have no reason to fear being overwhelmed by big players like
            Unisys or  AT&T.  The big players have the dilemma of either
            being  non-standard   or  of   providing   an   ineffective,
            incomplete  but  genuine  international  standards.    Small
            vendors have lots of room to offer enhanced versions perhaps
            drawing from more sophisticated internetworking concepts. In
            any case,  most small  vendors, as  well as DEC and IBM, are
            hedging their  bets by  offering both  OSI and  TCP/IP based
            products.   IBM seems well positioned with on-going projects
            at the  University of Michigan, CMU, MIT, Brown and Stanford
            and with  IBM's creditability  in the  business world to set
            the  standard   for  the   business  use   of  TCP/IP  style

            ____________________
            
            8 BNA  and DCA  seem hardly  to count  even  to  the  Unisys
            management.
            
            9 Connecting  computer systems  to the  telephone network is
            not computer networking in any real sense.
            ____________________


            networking. By  contrast, no major manufacturer really seems
            to want to build OSI products, and with the current state of
            OSI, there is really no reason to buy OSI products.

            VIII. MAP:  FOLLOWING THE OSI MODEL

            MAP shows perfectly the result of following the OSI model to
            produce a computer networking  system.  GM analysts sold MAP
            to GM's  top management  on the  basis of the predicted cost
            savings.   Since GM  engineers designed,  sponsored and gave
            birth to  MAP, I  am not surprised that an internal GM study
            has found MAP products less expensive than non-MAP compliant
            products.   If the internal study found anything else, heads
            would have  to roll.  Yet, as far as I know, neither IBM nor
            DEC have  bought into  the concept  although both  companies
            would probably  supply MAP  products for  sufficient profit.
            Ungermann-Bass and other similar vendors have also announced
            a disinclination  to  produce  IEEE  802.4  based  products.
            Allen-Bradley has chosen DECNET in preference to a MAP-based
            manufacturing and  materials handling system. This defection
            of major  manufacturers, vendors  and customers from the MAP
            market has to limit the amount of MAP products available for
            customers to purchase.

            Nowadays, GM  can purchase  equipment for  its manufacturing
            floor from  a limited  selection of  products, which are the
            computer networking  equivalent of  bows and arrows, whereas
            in the  past GM  was stuck  with rocks and knives.  Bows and
            arrows might  be sufficient for the current GM applications;
            however, if  my firm  had designed  MAP, GM  would have  the
            networking equivalent  of nuclear  weapons,  for    the  MAP
            network would  have been  built around  an internet  with  a
            genuine multimedium  gatewayed easily modifiable environment
            so that  in those locations where token-bus noise resistance
            is insufficient and where higher bandwidths might be needed,
            fiber media  could be  used.   With the  imminent deluge  of
            fiber-based  products,   MAP  looks   excessively   limited.
            (Actually, the  MAP standards  committees  have  shown  some
            belated awareness that fiber might be useful in factories.)

            IX. EXTENDING OSI VIA PROTOCOL CONVERTERS:  QUO VADIT?

            Interestingly enough,  even when OSI systems try to overcome
            OSI limitations via protocol conversion to provide access to
            some of  the sophisticated  resource sharing  to which  ARPA
            Internet users  have long  been accustomed,  the service  is
            specified in  such a  way as  to place  major limitations on
            performance of  more sophisticated  applications. Just  like
            IBM and  other system manufacturers, I have no problems with
            providing to  the customer  at sufficient  profit    exactly
            those products  which  the  customer  specifies.    Yet,  if
            contracted for advice on a system like the NBS TCP/IP-to-OSI
            protocol converter  IS (Intermediate  System), described  in
            "Getting there from here," Data Communications, August 1988,
            I might  point out  that such  a system  could easily double
            packet  traffic   on  a   single   LAN,   decrease   network
            availability and reliability, prevent alternate routing, and
            harm throughput  by creating  a bottleneck  at the  IS which
            must perform both TCP/IP and OSI protocol termination.

            X. CONCLUSION

            Official standardization  simply by  itself does  not make a
            proposal good.   Good  standards generally were already good
            before they  became official  standards. The  IEEE and other
            standards bodies  generate lots  of  standards  for  systems
            which quickly  pass into  oblivion.   OSI was  generated  de
            novo, apparently  with a  conscious decision  to ignore  the
            already functioning  ARPA Internet  example. Unless  a major
            rethinking  of  OSI  (like  redesigning  OSI  on  the  solid
            foundation of  the internetworking  concept) takes  place in
            the near  future, I  must conclude  that the  ARPA  Internet
            suite of  protocols will  be around for a long time and that
            users of  OSI will  be immensely  disappointed by  the cost,
            performance,  flexibility   and   manageability   of   their
            networks.

            I. Introduction                                            1
            II. The Debate                                             2
            III. Internetworking:  The Key System Level Start Point    4
            IV. "Greater Richness" Versus Developer Insight           14
                A. OSI Network Management and Netview                 14
                B. FTAM is Dangerous                                  14
                C. X.400:  E-Mail as Good as the Postal Service       15
                D. ARPA SMTP:  Designing Mail and Messaging Right     18
            V. Is the TCP/IP Protocol Suite "Static?"                 22
            VI. Enterprise Networking and Sophisticated Applications:
                    Selling Intercomputer Networking                  24
            VII. Big and Small Players Constrain OSI                  24
            VIII. MAP:  Following the OSI Model                       26
            IX. Extending OSI Via Protocol Converters:  Quo vadit?    26
            X. Conclusion                                             27

            







































Newsgroups: comp.protocols.iso
Subject: TCP/IP versus OSI
Summary: 
Expires: 
Sender: 
Reply-To: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
Followup-To: 
Distribution: world
Organization: Clearpoint Research Corp., Hopkinton Mass.
Keywords: 

Newsgroups: soc.culture.indian
Subject: Re: Evil Westerners
Summary: 
Expires: 
References: <5386@whuts.ATT.COM> <2126@cpoint.UUCP> <715@gould.doc.ic.ac.uk> <8765@aw.sei.cmu.edu> <4742@hubcap.UUCP> <VCHAUDHA.89Mar11025908@calcutta.oracle>
Sender: 
Reply-To: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
Followup-To: 
Distribution: 
Organization: Clearpoint Research Corp., Hopkinton Mass.
Keywords: 

In article <VCHAUDHA.89Mar11025908@calcutta.oracle> vchaudha@calcutta.oracle (Vikram Aaditya Chaudhary) writes:
>
>In article <4742@hubcap.UUCP> spingal@hubcap.UUCP (sridhar pingali) writes,
>in response to firth@sei.cmu.edu (Robert Firth):
>
>	[   Which leading writer of Goa?
>	[
>	[   Sridhar
>
>I think Firth is talking about VS Naipaul.  Firth is implying that
>a "leading" "Indian" "writer" is criticizing India, and therefore there
>must be some truth to it.
>
>Just because Naipual is ethnically Goan doesn't mean a damn thing.
>I don't think he was even born in India; he certainly grew up in 
>Trinidad.  He has no first hand knowledge of the Indian political
>or social system.  So he is certainly not a leading "Indian" writer.
>That would be like saying William Faulkner is a leading English writer.
>(Pardon the unfair analogy of the two-bit writer Naipaul to Faulkner)
>
>Naipaul is another product of colonial educational systems, trying desperately
>to prove that he is the de facto sovereign of all that is anti-Indian.
>Apologists for colonialism *love* his writing.
>
>No wonder Robert Firth quotes Naipaul.
>
>					Vikram Aaditya
>
> *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
> *     INTERNET:	vchaudha%oracle.com@apple.com                *
> *     UUCP    :	apple!oracle!vchaudha                        *
> *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*


Newsgroups: comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat,comp.protocols.iso.x400
Subject: TCP/IP versus OSI
Summary: 
Expires: 
Sender: 
Reply-To: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
Followup-To: 
Distribution: world
Organization: Clearpoint Research Corp., Hopkinton Mass.
Keywords: 

The following is an article which I am going to submit to Data
Communications in reply to a column which William Stallings
did on me a few months ago.  I think people in this forum might
be interested, and I would not mind some comments.


                   Round 2 in the great TCP/IP versus OSI Debate

            I. INTRODUCTION

            When ISO  published the first proposal for the ISO reference
            model in  1978, DARPA-sponsored research in packet switching
            for data  communications had  already been  progressing  for
            over 10  years.  The NCP protocol suite, from which the X.25
            packet-switching protocol suite originated, had already been
            rejected as unsuitable for genuine resource-sharing computer
            networks.   The major architectural and protocol development
            for internetting  over the  ARPANET was completed during the
            1978-79 period.  The complete  conversion of DARPA-sponsored
            networks to  internetting occurred  in January,  1983,  when
            DARPA required  all ARPANET  computers to  use TCP/IP. Since
            then, with an effective architecture, with working protocols
            on real networks, researchers and developers within the ARPA
            Internet community  have been  refining computer  networking
            and providing  continually more  resource sharing  at  lower
            costs.  At the same time, with no obvious architecture, with
            theoretical  or   idealized  networks   and  while  actively
            ignoring the  work being  done in the ARPA Internet context,
            the ISO  OSI  standards  committees  were  developing  basic
            remote terminal  and file  transfer protocols.   The ISO OSI
            protocol suite  generally provides  potentially much less at
            much  more   cost  than  the  ARPA  Internet  suite  already
            provides.   No one  should be  surprised that  many computer
            networking system  architects wish  to debate  the merits of
            the OSI  reference model  and that  many relatively  pleased
            business, technical  and academic users of the ARPA Internet
            protocol suite  would like  such a  debate  to  be  actively
            pursued in the media.

           ______________________________________________________________
           |                                                            |
           |                         Background				|
           |								|
           |Since June,  1988 William Stallings and I have been engaging|
           |in a  guerilla debate  in the  reader's forum  and  the  EOT|
           |feature on  the technical  and economic merits of OSI versus|
           |ARPANET-style networking.  Enough issues have been raised to|
           |require a  complete article  to continue the discussion. The|
           |debate is  of major interest because managers are now making|
           |strategic decisions  which will affect the development, cost|
           |and functionality  of  corporate  networks  over  the  whole|
           |world.   A valid  approach to  the  debate  deals  with  the|
           |technical,  economic  and  logistic  issues  but  avoids  ad|
           |hominem attacks.  I apologize for those comments in my forum|
           |letter which  might be  construed  as  personal  attacks  on|
           |William Stallings.           				|
	   |								|
           |Since I  have not  yet published  many papers and my book is|
           |only 3/4s  finished, I  should  introduce  myself  before  I|
           |refute the  ideas which Stallings presented in the September|
           |EOT feature.   I am a system designer and implementer who is|
           |a founder and Project Director at Constellation Technologies|
           |which   is    a   Boston-based   start-up   consulting   and|
           |manufacturing  company   specializing  in   increasing   the|
           |performance, reliability  and security of standard low-level|
           |communications technologies   for  any of  the  plethora  of|
           |computer networking environments currently available.       |
           |                                                            |
           |I  am   not  an  "Arpanet  Old  Network  Boy."  My  original|
           |experience is   in  telephony.  I have implemented Signaling|
           |System 6, X.25, Q.921 and Q.931.  During a one-year research|
           |position at  MIT, I  worked on TFTP and helped develop the X|
           |network transparent  windowing protocol.   Later I developed|
           |PC/NTS which  uses IEEE  802.2 Type  2 to  provide  PC-Prime|
           |Series 50  connectivity over IEEE 802.3 (Ethernet) networks.|
           |My partner  Tony Bono  and I  have attended various IEEE and|
           |CCITT  standards-related   committees  in  various  official|
           |capacities. 				         	|
           _____________________________________________________________|

            II. THE DEBATE        

            Part of  the problem with debating is the lack of a mutually
            agreeable and  understood set  of concepts in which to frame
            the debate.   I  have yet  to meet a communications engineer
            who had  a sense  of what  a process might be. Having taught
            working  software   and  hardware   engineers   at   Harvard
            University and  AT&T and  having attended  the international
            standards  committees   with  many  hardware,  software  and
            communications  engineers,  I  have  observed  that  overall
            system design  concepts in  computer networking  need a  lot
            more  attention   and  understanding  than  they  have  been
            getting.  Normally in the standardization process, this lack
            of attention would not be serious because official standards
            bodies usually  simply make  official  already  existing  de
            facto standards  like Ethernet  2.0 which had already proven
            themselves.   In the  case of OSI, the ISO committee, for no
            obvious reasons, chose to ignore the proven ARPA Internet de
            facto standard.
            
           ______________________________________________________________
           |                                                            |
           |                       Architecture,           		| 
           |                 Functional Specification,           	|
           |                    Design Specification           		|
           |                                         |                  |
           |Nowadays, we  read a lot of hype about CASE, object-oriented|
           |program techniques  and languages  designed to facilitate or|
           |to ease  the development  of large software projects.  These|
           |tools generally duck the hardest and most interesting system|
           |design and  development problem  which is  the design  under|
           |constraint of  major systems  which somebody  might actually|
           |want to  buy.   The hype  avoids the real issue that student|
           |engineers are  either simply  not taught  or  do  not  learn|
           |system  design  in  university  engineering  programs.    If|
           |software engineers  generally knew how to produce acceptable|
           |architectures,   functional    specifications   and   design|
           |specifications, the  push for  automatic tools would be much|
           |less. In  fact, the  development of CASE tools for automatic|
           |creation of systems architectures, functional specifications|
           |and design specifications requires understanding exactly how|
           |to produce  proper architectures and specifications.  But if|
           |engineers  knew   how  to  produce  good  architectures  and|
           |specifications for  software, presumably  student  engineers|
           |would   receive    reasonable   instruction   in   producing|
           |architectures and  specifications, and  then there  would be|
           |much less  need for  automatic CASE  tools to produce system|
           |architectures,   functional    specifications   or    design|
           |specifications.						|
           |           							|
           |Just as  an architectural  description of  a building  would|
           |point  out  that  a  building  is  Gothic  or  Georgian,  an|
           |operating system  architecture  might  point  out  that  the|
           |operating system  is multitasking, pre-emptively time-sliced|
           |with kernel  privileged routines running at interrupt level.|
           |A  system   architecture  would   describe  statically   and|
           |abstractly the  fundamental operating  system entities.   In|
           |Unix, the  fundamental operating system entities on the user|
           |side would  be the  process and  the file.   The  functional|
           |specification  would   describe  the   functionality  to  be|
           |provided  to   the  user   within  the  constraints  of  the|
           |architecture. A functional specification should not list the|
           |function calls used in the system.  The design specification|
           |should specify  the model by which the architecture is to be|
           |implemented to  provide the desired functionality.  A little|
           |pseudocode can  be useful depending on the particular design|
           |specification detail  level.   Data  structures,  which  are|
           |likely to  change many  times during implementations, should|
           |not appear in the design specification.			|
           |								|
           |Ancillary  documents   which  treat  financial  and  project|
           |management issues  should be  available to  the  development|
           |team.   In all  cases documents  must be  short.  Otherwise,|
           |there is  no assurance the all members of the development or|
           |product management  teams will  read  and  fully  comprehend|
           |their documents.   Detail  and verbiage  can be the enemy of|
           |clarity.   Good architectures  and functional specifications|
           |for moderately  large systems  like Unix  generally  require|
           |about 10-20  pages.   A good high-level design specification|
           |for such  a system  would take  about  25  pages.    If  the|
           |documents are  longer, something  may be  wrong.  The key is|
           |understanding what should not be included in such documents.|
           |The  ISO   OSI  documents   generally  violate   all   these|
           |principles.							|
           _____________________________________________________________|

            As a  consequence, the  ISO OSI  committee and  OSI boosters
            have an  obligation to justify their viewpoint in debate and
            technical discussion  with computer  networking experts  and
            system designers.  Unfortunately, the debate over the use of
            OSI versus TCP/IP has so far suffered from three problems:
                 
                 o    a lack of systems level viewpoint,
                 
                 o    a lack of developer insight and
                 
                 o    an hostility toward critical appraisal either
                      technically or economically of the proposed ISO
                      OSI standards.

            The following material is an attempt to engage in a critical
            analysis  of  OSI  on  the  basis  of  system  architecture,
            development principles and business economics.  Note that in
            the following article unattributed quotations are taken from
            the itemized  list which Stallings used in EOT to attempt to
            summarize my position.

            III. INTERNETWORKING:  THE KEY SYSTEM LEVEL START POINT

            The most  powerful system level architectural design concept
            in   modern    computer   networking   is   internetworking.
            Internetworking is practically absent from the OSI reference
            model  which   concentrates  on   layering,  which   is   an
            implementation technique,  and on  the  virtual  connection,
            which  would   be  a   feature  of  a  proper  architecture.
            Internetworking   is good  for the same reason Unix is good.
            The Unix  architects and the ARPA Internet architects, after
            several missteps, concluded that the most useful designs are
            achieved by  first choosing  an effective  computational  or
            application model  for the user and then figuring out how to
            implement this  model  on  a  particular  set  of  hardware.
            Without taking  a position on success or failure, I have the
            impression that  the  SNA  and  VMS  architects  by  way  of
            contrast set  out to  make the  most effective  use of their
            hardware.   As a  consequence both  SNA and  VMS are  rather
            inflexible systems  which are  often rather inconvenient for
            users even  though the  hardware is  often quite effectively
            used.   Of course,  starting from  the user computational or
            application model  does not  preclude eventually  making the
            most  effective   use  of  the  hardware  once  the  desired
            computational or application model has been implemented.

           ______________________________________________________________
           |                                                            |
           |                      Internetworking           		|
           |           							|
           |The internetworking  approach enables  system designers  and|
           |implementers to  provide network users with a single, highly|
           |available,  highly   reliable,   easily   enlarged,   easily|
           |modifiable, virtual network.  The user does not need to know|
           |that this single virtual network is  composed of a multitude|
           |of technologically  heterogeneous wide  area and  local area|
           |networks    with     multiple    domains    of    authority.|
           |Internetworking is  achieved by  means of  a coherent system|
           |level  view  through  the  use  of  an  obligatory  internet|
           |protocol  with   ancillary  monitoring  protocol,  gateways,|
           |exterior/internal gateway  protocols and hierarchical domain|
           |name service.                                               |
           |                                                            |
           |In the  internetworking (not  interworking) approach, if two|
           |hosts are  attached to  the same  physical subnetwork  of an|
           |internetwork,  the  hosts  communicate  directly  with  each|
           |other.   If the  hosts are  attached to  different  physical|
           |subnetworks, the  hosts communicate  via gateways  local  to|
           |each host.   Gateways  understand and learn the internetwork|
           |topology dynamically  at a  subnetwork (not  host level) and|
           |route  data   from  the  source  subnetwork  to  destination|
           |subnetwork on a subnetwork hop by subnetwork hop basis.  The|
           |detail of information required for routing and configuration|
           |is reduced  by orders  of magnitude.   In the ARPA Internet,|
           |gateways  learn   topological  information  dynamically  and|
           |provide reliability  as well  as availability  by performing|
           |alternate routing  of  IP  datagrams  in  cases  of  network|
           |congestion or network failures.                             |
           |                                                            |
           |An authoritative  domain,  Within  the  ARPA  Internet,  can|
           |conceal from  the rest of the internetwork a lot of internal|
           |structural detail  because gateways  in other  domains  need|
           |only  know  about  gateways  within  their  own  domain  and|
           |gateways  between  authoritative  domains.    Thus,  logical|
           |subnetworks  of  an  internetwork  may  also  themselves  be|
           |catenets  (concatenated  networks)  with  internal  gateways|
           |connecting  different   physical  subnetworks   within  each|
           |catenet.   For example, to send traffic to MIT, a gateway at|
           |U.C. Berkeley  only need know about gateways between MIT and|
           |other domains  and need  know  nothing  about  the  internal|
           |structure of the MIT domain's catenet.                      |
           _____________________________________________________________|

            
	    The ARPA  Internet is one realization of the internetworking
            model.   While I am not particularly enamored of some of the
            ARPA protocol  features (nor  of Unix features by the way),1
            the ARPA  Internet works  well with  capacity for expansion.
            SINet  (described   in  "How  to  grow  a  world-class  X.25
            network," Data  Communications, May  1988) is  based on  the
            CSNet subnetwork within the ARPA Internet.
            ____________________

            1 The  use of  local-IP-address, local-TCP-port,  remote-IP-
            address, remote-TCP-port  quadruples to  uniquely identify a
            given TCP  virtual circuit  is an  impediment  to  providing
            greater  reliability  and  availability  for  a  non-gateway
            multihomed host.   A  even larger  problem with TCP/IP could
            lie   in    the   possibly   non-optimal   partitioning   of
            functionality between TCP, IP and ICMP.
            ____________________
            
           ______________________________________________________________
           |                                                    	|
           |                        WANs and LANs			|
           |                                     			|
           |OSI actually  has an  architecture.   Like the  ARPANET, OSI|
           |predicates  the   existence  of   a  communications   subnet|
           |consisting  communications   subnet  processors  (or  subnet|
           |switches) and  communications subnet  access processors  (or|
           |access switches).   Access  switches are  also known as IMPs|
           |(Interface Message Processors) or PSNs (Packet Switch Nodes)|
           |in the  ARPANET context.  PSPDN (Packet-Switched Public Data|
           |Network)  terminology  usually  designates  access  switches|
           |simply as  packet switches.  The communication subnet may be|
           |hierarchical and  may contain  adjunct processors other than|
           |subnet and  access switches.   The  internal architecture of|
           |the  communications   subnet  is  quite  distinct  from  the|
           |architecture   presented    to   end-point   hosts.      The|
           |communications subnet may use protocols completely different|
           |from the  protocols used  for communication between two end-|
           |point hosts.   An end-point host receives and transmits data|
           |to its  attached access switch via a subnet access protocol.|
           |The communications subnet is responsible for taking a packet|
           |received at  an access switch and transporting the packet to|
           |the access  switch attached  to  the  destination  end-point|
           |host.   The existence  of such a well-defined communications|
           |subnet is the hall mark of a Wide-Area Network (WAN).       |
	   								|
           |Unfortunately,  from   the  standpoint  of  making  computer|
           |networking generally and inexpensively available, access and|
           |subnet switches  are expensive  devices to  build which need|
           |fairly complicated  control software.   DECNET  gets  around|
           |some of  these problems  by incorporating the communications|
           |subnet logic  into  end-point  hosts.    As  a  consequence,|
           |customers who  wish to run DECNET typically have to purchase|
           |much more  powerful machines  than they might otherwise use.|
           |For the  situation of  a communications  subnet  which  need|
           |support connectivity  for only  a small number of hosts, LAN|
           |developers  found   a  more   cost  effective   solution  by|
           |developing a  degenerate form  of packet  switches based  on|
           |hardware-logic  packet   filtering  rather   than   software|
           |controlled  packet   switching.    These  degenerate  packet|
           |switches are  installed in the end-point hosts, are accessed|
           |often via  DMA2 as  LAN  controllers  and  are  attached  to|
           |extremely simplified  communications  subnets  like  coaxial|
           |cables.     Direct   host-to-switch   (controller)   access,|
           |degenerate    packet-switching     (packet-filtering)    and|
           |simplified communications  subnets  are  the  distinguishing|
           |features of LANs.           				|
           |           							|
           |While ISO  was ignoring  the whole  internetworking issue of|
           |providing universal  connectivity  between  end-point  hosts|
           |attached to different physical networks within internetworks|
           |composed of  many  WANs  and  even  more  LANs  concatenated|
           |together, and while the IEEE was confusing all the issues by|
           |presenting as an end-to-end protocol a communications subnet|
           |protocol (IEEE  802.2)  based  on  a  communications  subnet|
           |access protocol  (X.25 level 2), the ARPA Internet community|
           |developed an  internet architecture capable of providing the|
           |universal connectivity  and resource sharing which business,|
           |technical and academic users really want and need.         	|
           ______________________________________________________________

            ____________________
            
            2 Some  machines like the Prime 50 Series do not use genuine
            DMA  but  instead  use  inefficient  microcoded  I/O.    IBM
            machines generally  use more  efficient  and  somewhat  more
            expensive internal switching.
            ____________________


            The backbone  of the  ARPA Internet  is the  ARPANET.    The
            ARPANET is  a packet  switched subnetwork  within  the  ARPA
            Internet.  The ARPANET communications subnet access protocol
            is 1822.   CSNet  was set up as an experiment to demonstrate
            that the  ARPA Internet  architecture and suite of protocols
            would function  on a  packet  network  whose  communications
            subnet access  protocol is  X.25.   Using  an  X.25-accessed
            packet network  instead of  an 1822-accessed  packet network
            makes sense  despite  the  glaring  deficiencies  of  X.25,3
            because X.25 controllers are available for many more systems
            than  1822   controllers  and   because   many   proprietary
            networking schemes like SNA and DECNET can use X.25-accessed
            packet networks  but cannot use a packet network accessed by
            1822.

            Yet,  calling  SINet  a  world  class  X.25  network  is  as
            reasonable  as  calling  the  ARPANET  a  world  class  1822
            network.4   Schlumberger has  produced a  world class TCP/IP
            network whose wires can be shared with SNA and DECNET hosts.
            Schlumberger  has   shown  enthusiasm   for  the   flexible,
            effective ARPANET  suite  of  protocols  but  has  given  no
            support in  the  development  of  SINet  to  the  idea  that
            business should prepare to migrate to OSI based networks.

            I  would   be  an   OSI-enthusiast  if  ISO  had  reinvented
            internetworking  correctly.    Unfortunately,  the  ISO  OSI
            reference model which first appeared in 1978 clearly ignored
            all the  ARPA community work on intercomputer networking and
            resource  sharing   which  was   easily  accessible  in  the
            literature of the time.  Instead of building the OSI network
            on an  internetworking foundation,  ISO standardized  on the
            older less  effective  host-to-packet-switch-to-packet-data-
            subnet-to-packet-switch-to-host (NCP)  model which the DARPA


            ____________________
            
            3 For  example, X.25 does flow control on the host to packet
            switch connection on the basis of packets transmitted rather
            than on  the  basis  of  consumption  of  advertised  memory
            window.   The exchange  of lots of little packets on an X.25
            connection can  cause continual transmission throttling even
            though the receiver has lots of space for incoming data.
            
            4 Or  as much  sense  as  calling  Ethernet  LANs  DMA-based
            networks because the packet switches (an Ethernet controller
            is a  degenerate case  of a  packet switch)  on the  LAN are
            typically accessed by DMA.
            ____________________


            had abandoned 5 years earlier because of lack of flexibility
            and other problems.

           ______________________________________________________________
           |                                                            |
           |           Pieces of the ARPA Internet Conceptually         | 
           |                                                		|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |			(No Graphics)			 	|
           |							 	|
           |							 	|
           ______________________________________________________________



            Nowadays, mostly in response to US vendors and DARPA, pieces
            of the ARPA Internet architecture have resurfaced in the OSI
            reference  model   quite  incoherently   rather  than  as  a
            consequence   of   an   integrated   correct   architectural
            viewpoint.  Connectionless-mode transmission is described in
            ISO/7498/DAD1 which  is an  addendum to  ISO 7498  and not a
            core document.   Because connectionless-mode transmission is
            defined in an addendum, the procedure apparently need not be
            implemented, and  UK GOSIP,  for example, explicitly rejects
            the use  of the  connectionless transmission  mode.      The
            introduction to the 1986 ISO 7498/DAD1 explicitly states, as
            follows, that  ISO was  extremely reluctant to incorporate a
            genuine datagram  based protocol  which could  be  used  for
            internetworking.

                ISO 7498 describes the Reference Model of Open
                Systems Interconnection.  It is the intention of
                that International standard that the Reference
                model should establish a framework for coordinating
                the development of existing and future standards
                for the interconnection of systems.  The assumption
                that connection is a fundamental prerequisite for
                communication in the OSI environment permeates the
                Reference Model and is one of the most useful and
                important unifying concepts of the architecture
                which it describes.  However, since the
                International Standard was produced it has been
                realized that this deeply-rooted connection
                orientation unnecessarily limits the power and
                scope of the Reference Model, since it excludes
                important classes of applications and important
                classes of communication network technology which
                have a fundamentally connectionless nature.

            An  OSI  connectionless-mode  protocol  packet  may  undergo
            something like  fragmentation, but from the literature, this
            form of  segmentation as  used in  OSI  networks  is  hardly
            equivalent to ARPA Internet fragmentation.  Stallings states
            the  following   in  Handbook   of   Computer-Communications
            Standards, the  Open Systems Interconnection (OSI) Model and
            OSI-Related Standards,  on p.  18  (the  only  reference  to
            anything resembling fragmentation in the book).

                Whether the application entity sends data in
                messages or in a continuous stream, lower level
                protocols may need to break up the data into blocks
                of some smaller bounded size.  This process is
                called segmentation.

            Such  a   process  is   not  equivalent   to  ARPA  Internet
            fragmentation.   In the  ARPA Internet  fragmentation is the
            process whereby  the gateway  software operating  at the  IP
            layer converts  a single  IP packet into several separate IP
            packets and  then routes the packets.  Each ARPA IP fragment
            has a  full IP  header.   It is  not obvious  that each  OSI
            segment has a complete packet header. The ARPA fragmentation
            procedure is not carried out by lower protocol layers.  A N-
            layer packet  in OSI  is segmented  at layer  N-1 while  the
            packet is routed (relayed) at layer N+1.

            This partitioning of basic internetworking procedures across
            layer 2  (N-1), layer  3 (N)  and layer 4 (N+1) violates the
            following principles described in ISO/DIS 7498:  Information
            Processing Systems  -- Open Systems Interconnection -- Basic
            Reference Model.
                         
                 P1:  do not create so many layers as to make the system
                      engineering task of describing and integrating the
                      layers more difficult than necessary [ISO uses
                      three layers where one could be used];
                      
                 
                 P2:  create a boundary at a point where the description
                      of services can be small and the number or
                      interactions across the boundary are minimized [by
                      putting per-packet relaying in layer 4 at least
                      two interactions across the boundary are required
                      per packet];
                 
                 P5:  select boundaries at a point which past experience
                      has demonstrated to be successful [the ARPA
                      Internet layering boundaries which combine the
                      addressing, fragmentation and routing in one layer
                      has proven successful];
                 
                 P6:  create a layer where there is a need for a
                      different level of abstraction in the handling of
                      data, e.g. morphology, syntax, semantics
                      [fragmentation, routing, and network addressing
                      are all seem quit naturally to be part of network
                      layer semantics as the ARPA Internet example
                      shows];
                 
                 P9:  allow changes of functions or protocols to be made
                      within a layer without affecting other layers [I
                      would think changing the manner of addressing at
                      layer 3 would affect relaying at layer 4].

            Even if  OSI N-1 segmentation and N+1 relaying could be used
            in the  same way  as fragmentation  and routing  in the ARPA
            Internet,  it   takes  a  lot  more  apparatus  than  simply
            permitting the  use of  the  ISO  connectionless  "internet"
            protocol to achieve internetworking.

            The OSI  documents almost  concede this  point  because  ISO
            7498/DAD 1,  ISO/DIS 8473 (Information Processing Systems --
            Data    Communications    --    Protocol    for    Providing
            Connectionless-Mode Network Service) actually provide for N-
            layer  segmentation  (actually  fragmentation)  and  N-layer
            routing right  in the  network layer  in addition to the OSI
            standard N-1  segmentation and N+1 relaying.  Providing such
            functionality directly  in the  network layer actually seems
            in greater accordance with OSI design principles, but if ISO
            is really  conceding this  point, ISO  should  go  back  and
            redesign the system rather than leaving this mishmash of N-1
            segmentation, N  segmentation, N  routing and  N+1 relaying.
            The current  connectionless-mode network  service  is  still
            insufficient  for   internetworking  because   the   gateway
            protocols are  not present and the connectionless-mode error
            PDUs (Protocol Data Units) do not provide the necessary ICMP
            functionality.     The  documents   also  indicate  a  major
            confusion between  an internetwork  gateway, which  connects
            different subnetworks of one catenet (concatenated network),
            and  a   simple  bridge,  which  connects  several  separate
            physical networks  into a  single network at the link layer,
            or an interworking unit, which is a subnet switch connecting
            two different  communications subnets either under different
            administrative  authorities   or  using  different  internal
            protocols.5    Tanenbaum  writes  the  following  about  the

            ____________________
            
            5  This  confusion  is  most  distressing  from  a  security
            standpoint.   The November  2 ARPA  Internet (Cornell) virus
            attack shows  that one  of  the  major  threats  to  network
            security is  insider attack which is a problem with even the
            most isolated corporate network.  Because many ARPA Internet
            network authorities  were assuming  insider  good  behavior,
            ARPA Internet  network administrators  often did  not  erect
            security  barriers   or  close   trapdoors.    Nevertheless,
            gateways  have   far  more   potential   than   bridges   or
            interworking units to provide reasonable firewalls to hinder
            and frustrate  insider attack.    MIT/Project  Athena  which
            makes judicious  use of  gateways and  which does not assume
            insider good  behavior  was  relatively  unaffected  by  the
            virus. Any  document which  confuses gateways,  bridges  and
            interworking units is encouraging security laxity.
            ____________________


            connectionless-mode network service in Computer Networks, p.
            321.

                In the OSI model, internetworking is done in the
                network layer.  In all honesty, this is not one of
                the areas in which ISO has devised a model that has
                met with universal acclaim (network security is
                another one).6  From looking at the documents, one
                gets the feeling that internetworking was hastily
                grafted onto the main structure at the last minute.
                In particular, the objections from the ARPA
                Internet community did not carry as much weight as
                they perhaps should have, inasmuch as DARPA had 10
                years experience running an internet with hundreds
                of interconnected networks, and had a good idea of
                what worked in practice and what did not.

            Internetworking,  the   key  concept   of  modern   computer
            networking, exists  within the  OSI  reference  model  as  a
            conceptual wart  which violates even the OSI principles.  If
            ISO had  not tacked  internetworking onto the OSI model, ISO
            was afraid  that DARPA  and that  part of  the  US  computer
            industry with  experience with  modern  computer  networking
            would have  absolutely rejected  the OSI  reference model as
            unusable.
            ____________________            

            6 Actually,  I find ISO 7498/2 (Security Architecture) to be
            one of  the more  reasonable ISO documents. I would disagree
            that simple  encryption is  the only  form of security which
            should be  performed at  the link  layer  because  it  seems
            sensible that  if a  multilevel secure mini is replaced by a
            cluster of  PCs on  a  LAN,  multilevel  security  might  be
            desirable at  the link layer.  Providing multilevel security
            at the link layer would require more than simple encryption.
            Still, ISO  7498/2 has the virtue of not pretending to solve
            completely the network security problem.  The document gives
            instead a  framework indentifying  fundamental concepts  and
            building blocks  for  developing  a  security  system  in  a
            networked environment.
            ____________________            

                                                           
            IV. "GREATER RICHNESS" VERSUS DEVELOPER INSIGHT

            In view  of this  major conceptual  flaw which  OSI has with
            respect to  internetworking,  no  one  should  therefore  be
            surprised that  instead of  tight technical  discussion  and
            reasoning,  implementers   and   designers   like   me   are
            continually  subjected   to  vague  assertions  of  "greater
            richness" of  the  OSI  protocols  over  the  ARPA  Internet
            protocols.   In ARPA  Internet  RFCs,  real-world  practical
            discussion is  common.   I  would not mind similar developer
            insight or  even hints  about the  integration of  these OSI
            protocol  interpreters   into  genuine   operating   systems
            participating in an OSI interoperable environment.

            The customers  should realize "greater richness" costs a lot
            of extra  money even  if a  lot of  the added  features  are
            useless  to   the   customer.   "Greater   richness"   might
            necessitate the  use of  a much  more powerful  processor if
            "greater  richness"   forced  much   more   obligatory   but
            purposeless protocol processing overhead. "Greater richness"
            might also represent a bad or less than optimal partitioning
            of the problem.

                       A. OSI NETWORK MANAGEMENT AND NETVIEW

            Netview has  so much  "greater richness"  than  the  network
            management protocols  and systems  under development  in the
            ARPA Internet  context that  I have  real problems  with the
            standardization of  Netview into  OSI network  management as
            the obligatory  user interface  and  data  analysis  system.
            Netview is  big, costly,  hard to  implement, and  extremely
            demanding on  the rest of the network management system.  As
            OSI network  management  apparently  subsumes  most  of  the
            capabilities of  Arpanet ICMP  (Internet Control  Monitoring
            Protocol) which  is a sine qua non for internetworking, I am
            as a developer rather distressed that full blown OSI network
            management (possibly  including  a  full  implementation  of
            FTAM)  might have to run on a poor little laser printer with
            a dumb  ethernet interface  card  and  not  much  processing
            power.

                                B. FTAM IS DANGEROUS

            The "greater  richness" of  FTAM seems to lie in the ability
            to transmit  single records  and in  the ability  to restart
            aborted file  transfer sessions.    Transmission  of  single
            records seems  fairly useless  in  the  general  case  since
            operating systems  like Unix  and DOS do not base their file
            systems on  records while  the records  of file systems like
            those of  Primos and VMS  have no relationship whatsoever to
            one another.    Including  single  record  or  partial  file
            transfer in  the remote  transfer utility  seems is  a  good
            example of bad partitioning of the problem.  This capability
            really belongs in a separate network file system.  A network
            file system should be separate from the remote file transfer
            system because  the major  issues in  security, performance,
            data  encoding   translation  and  locating  objects  to  be
            transferred are different in major ways for the two systems.

            The ability  to  restart  aborted  file  transfers  is  more
            dangerous than  helpful.  If the transfer were aborted in an
            OSI network,  it could have been aborted because one or both
            of the  end hosts  died or because some piece of the network
            died.  If the network died, a checkpointed file transfer can
            probably be restarted.  If a host died on the other hand, it
            may have  gradually gone  insane and  the checkpoints may be
            useless.   The checkpoints  could only  be guaranteed if end
            hosts  have   special  self-diagnosing  hardware  (which  is
            expensive).   In the absence of special hardware and ways of
            determining exactly  why a  file transfer  aborted, the file
            transfer must  be restarted from the beginning.  By the way,
            even with  the greater  richness of FTAM, it is not clear to
            me that a file could be transferred by FTAM from IBM PC A to
            a Prime Series 50 to IBM PC B in such a way that the file on
            PC A and on PC B could be guaranteed to be identical.

                  C. X.400:  E-MAIL AS GOOD AS THE POSTAL SERVICE

            As currently  used and  envisioned, the X.400 family message
            handling also  has  "greater  richness."    X.400  seems  to
            include   binary-encoded   arbitrary   message-transmission,
            simple  mail   exchange  and   notification  provided  by  a
            Submission and  Delivery Entity  (SDE).   In comparison with
            ARPA SMTP  (Simple Mail  Transfer Protocol), X.400 is overly
            complicated with  hordes  of  User  Agent  Entities  (UAEs),
            Message Transfer  Agent Entities  (MTAEs) and SDEs scurrying
            around potentially eating up -- especially during periods of
            high traffic  -- lots  of  computer  cycles  on  originator,
            target and  intermediate host systems because the source UAE
            has to transfer mail through the local MTAE and intermediate
            MTAEs on  a hop-by-hop  basis to get to the target machine.7

            ____________________
            
            7 I have to admit that if I were implementing X.400, I would
            probably implement  the local  UAE and  MTAE in one process.
            The  CCITT  specification  does  not  strictly  forbid  this
            design,  but  the  specification  does  seem  to  discourage
            strongly such  a design.   I consider it a major flaw with a
            protocol  specification  when  the  simplest  design  is  so
            strongly counterindicated.   It  does seem  to be obligatory
            that mail  traffic  which  passes  through  an  Intermediate
            System (IS) must pass through an MTAE running on that IS.
            ____________________


            The design is particularly obnoxious because X.400 increases
            the number  of ways  of getting mail transmission failure by
            using so  many intermediate  entities  above  the  transport
            layer. The  SMTP architecture  is, by  contrast, simple  and
            direct.  The user mail program connects to the target system
            SMTP daemon  by a  reliable byte  stream (like a TCP virtual
            circuit) and  transfers  the  mail.    Hop-by-hop  transfers
            through intermediate  systems are possible when needed.  One
            SMTP daemon  simply connects  to another the same way a user
            mail program connects to an SMTP daemon.

            The relatively  greater complexity  and obscurity  of  X.400
            arises because  a major  purpose of  X.400 seems  to  be  to
            intermingle  intercomputer   mail  service   and   telephony
            services  like   telex  or   teletex  to  fit  the  computer
            networking  into   the  PTT  (Post,  Telegraph  &  Telephone
            administration)  model   of  data   communications  (not  an
            unreasonable goal  for a  CCITT protocol  specification  but
            probably not the best technical or cost-effective design for
            the  typical   customer).    Mail  gateways  are  apparently
            supposed to  handle  document  interchange  and  conversion.
            Document interchange and conversion is a really hard problem
            requiring detailed knowledge at least of word processor file
            formats, operating  system architecture,  data encoding, and
            machine architecture.

            It may  be impossible  to   develop a  satisfactory  network
            representation  which   can  handle  all  possible  document
            content, language and source/target hardware combinations as
            well as  provide interconversion  with tradition  telephonic
            data transmission encodings. The cost of development of such
            a system might be hard to justify, and a customer might have
            a hard time justifying paying the price a manufacturer would
            probably have  to charge  for this  product. A  network file
            system  or   remote  file  transfer  provides  a  much  more
            reasonable means  of document  sharing or  interchange  than
            tacking an  e-mail address  into a  file with  a complicated
            internal structure,  sending  this  file  through  the  mail
            system and  then removing  the addressing information before
            putting the  document through  the appropriate  document  or
            graphics handler.

            A NETASCII-based  e-mail system  corresponds exactly  to the
            obvious mapping  of the  typical physical letter, which does
            not usually  contain complicated  pictorial or tabular data,
            to an  electronic letter  and is  sufficient for practically
            all electronic  mail traffic.  Special hybrid systems can be

            developed for  that extremely  tiny fraction  of traffic for
            which NETASCII  representations may  be insufficient and for
            which a network file system or FTP may be insufficient.    A
            correct partitioning  of the  electronic mail should be kept
            completely  separate   from  telephony   services,  document
            interchange and document conversion.

            
           ______________________________________________________________
	   |								|
           |                    X.400 Mail Connections			|
           |                                                            |
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |			(No Graphics)			 	|
           |							 	|
           |							 	|
           ______________________________________________________________


                 D. ARPA SMTP:  DESIGNING MAIL AND MESSAGING RIGHT

            The MIT environment at Project Athena, where IBM and DEC are
            conducting a  major  experiment  in  the  productization  of
            academic software,  provides an  instructive example  of the
            differences between e-mail, messaging and notification.  The
            mail system  used at  MIT is  an implementation of the basic
            SMTP-based ARPA  Internet mail  system. More than four years
            ago the  ARPA Internet  mail system  was  extremely powerful
            and world-spanning.   It  enabled  then  and  still  enables
            electronic mail  to reach  users on any of well over 100,000
            hosts in  N. America,  Europe, large portions of E. Asia and
            Israel.   The Citicorp  network (described  in "How one firm
            created  its  own  global  electronic  mail  network,"  Data
            Communications,  June   1988,  p.   167),   while   probably
            sufficient  for   Citicorp's  current   needs,  connects  an
            insignificant number of CPUs (47), provides no potential for
            connectivity outside  the Citicorp  domain of authority  and
            will probably  not scale  well with  respect to  routing  or
            configuration as it grows.

            The MIT  environment is complex and purposely (apparently in
            the strategies  of DEC  and IBM)  anticipates  the  sort  of
            environment which  should become typical within the business
            world within  the next  few years.   MIT is an authoritative
            domain within  the ARPA  Internet.   The gateways out of the
            MIT domain  communicate with  gateways in  other domains via
            the Exterior  Gateway Protocol (EGP).  Internally, currently
            used internal gateway protocols are GGP, RIP and HELLO.  The
            MIT domain  is composed of a multitude of Ethernet and other
            types of  local area  networks connected  by  a  fiber-optic
            backbone physically  and by gateway machines logically. This
            use of  gateways provides  firewalls between  the  different
            physical networks  so that  little sins  (temporary  network
            meltdowns caused  by Chernobyl  packets) do  not become  big
            sins propagating  themselves throughout  the network.    The
            gatewayed architecture  of the  MIT network  also permits  a
            necessary traffic engineering by putting file system, paging
            and boot  servers on  the same  physical network  with their
            most likely clients so that this sort of traffic need not be
            propagate throughout the complete MIT domain.

            Difficult to  reach locations  achieve connectivity by means
            of non-switched  telephone links.   Since  MIT has  its  own
            5ESS, these  links may  be converted  to ISDN at some point.
            While there  are some  minis and  mainframes in the network,
            the vast  majority of  hosts  within  the  MIT  network  are
            personal workstations with high resolution graphics displays
            of the  Vaxstation and  RT/PC type and personal computers of
            the IBM  PC, PC/XT  and PC/AT  type.   A few  Apollos, Suns,
            Sonys and  various workstations of the 80386 type as well as
            Lisp Machines  and PCs  from other  manufacturers like Apple
            are also  on the  air.  Most of the workstations are public.
            When a user logs in to such a workstation, after appropriate
            Kerberos (MIT  security system)  authentication, he has full
            access to  his own  network files  and directory  as well as
            access to  those resources  within the  network which he has
            the right to use.

            To assist  the administration  of the  MIT domain within the
            ARPA  Internet,   several   network   processes   might   be
            continually sending (possibly non-ASCII) event messages to a
            network  management  server  which  might  every  few  hours
            perform some  data analysis  on received  messages and  then
            format  a   summary  mail  message  to  send  to  a  network
            administrator.   This mail  message would  be placed in that
            network administrator's  mailbox by  his  mail  home's  SMTP
            daemon  which   then  might   check  whether   this  network
            administrator is reachable somewhere within the local domain
            (maybe on  a PC  with a network interface which was recently
            turned on and then was dynamically assigned an IP address by
            a  local  authoritative  dynamic  IP  address  server  after
            appropriate  authentication).    If  this  administrator  is
            available,  the   SMTP  daemon  might  notify  him  via  the
            notification service  (maybe by  popping up  a window on the
            administrator's display)  that he has received mail which he
            could read  from his  remote  location  via  a  post  office
            protocol.

            I have  seen the  above system being developed on top of the
            basic "static"  TCP/IP protocol suite by researchers at MIT,
            DEC and  IBM over  the last  4 years.   X.400 contains a lot
            this MIT  network functionality mishmashed together but I as
            a customer or designer prefer the much more modular MIT mail
            system.   It is  an   extensible,  dynamically  configurable
            TCP/IP-based architecture  from which a customer could chose
            those pieces  of the  system which he needs.  The MIT system
            requires relatively  little static  configuration.   Yet  by
            properly choosing  the system  pieces, coding an appropriate
            filter program  and setting  up a tiny amount of appropriate
            configuration data, a customer could even set up a portal to
            send e-mail  to a fax machine. In comparison, X.400 requires
            complicated directory  services and  an  immense  amount  of
            static configuration about the end user and end user machine
            to   compensate   for   the   internetworking-deficient   or
            internetworking-incompatible addressing scheme. The need for
            such a  level of  static configuration  is  unfortunate  for
            system users  because in  the real world a PC or workstation
            might easily  be moved  from one  LAN to another or might be
            easily replaced by a workstation or PC of another type.

            An MIT-style  mail system  could also  be  much  cheaper  to
            develop and  consequently  could  be  much  less  costly  to
            purchase  than  an  X.400  mail  system  simply  because  it
            represents a  much better  partitioning of the problem.  One
            or two engineers produced each module of the MIT mail system
            in approximately  6  months.    Because  of  complexity  and
            obscurity, the  development of  X.400  products  (I  saw  an
            example at Prime) is measured in staff years.  The executive
            who chooses  X.400 will  cost his  firm an immense amount of
            money which  will look  utterly wasted  when his  firm joins
            with another  firm in some venture and the top executives of
            both firms  try  to  exchange  mail  via  their  X.400  mail
            systems.   Simple mail  exchange between  such systems would
            likely be  very hard  to impossible  because  the  different
            corporations  could   easily  have   made  permissible   but
            incompatible choices in their initial system set-up.  At the
            very last  complete reconfiguration of both systems could be
            necessary.   Had the  firms chosen  an  ARPA  Internet  mail
            system like  the  MIT  system,  once  both  firms  had  ARPA
            Internet connectivity  or set up a domain-to-domain gateway,
            mail would simply work.

            
           ______________________________________________________________
           |                                                        	|    
	   |			SMTP Mail Connections			|
           |                                                            |
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |							 	|
           |			(No Graphics)			 	|
           |							 	|
           |							 	|
           ______________________________________________________________


            V. IS THE TCP/IP PROTOCOL SUITE "STATIC?"

            Because of  the mail  system development in progress at MIT,
            DEC and  IBM, the X development which I and others have done
            and which is still continuing, SUN NFS (Network File System)
            development,  IBM  AFS  (Andrew  File  System)  development,
            Xenix-Net development,  Kerberos development,  and the other
            plethora of protocol systems being developed within the ARPA
            Internet context  (including the VMTP transaction processing
            system and  commercial  distributed  database  systems  like
            network Ingress),  I am  at the  very least  puzzled by  Mr.
            Stallings' assertion   that  "[it] is the military standards
            that appear  on procurement  specifications  and  that  have
            driven  the   development  of   interoperable   commercially
            available TCP/IP products."
           ______________________________________________________________
           |                                                            |
           |                  Partitioning the Problem           	|
           |           							|
           |The X  window system  is an  example of  a clearly  and well|
           |partitioned system.   In  windowing, the  first piece of the|
           |problem is  virtualizing the high-resolution raster graphics|
           |device.  Individual applications do not want or need to know|
           |about the  details  of  the  hardware.    Thus,  to  provide|
           |hardware independence,  applications should  only deal  with|
           |virtual high-resolution  raster-graphics devices  and should|
           |only know  about its  own virtual  high  resolution  raster-|
           |graphics devices  (windows).   The next piece of the problem|
           |is  to  translate  between  virtual  high-resolution  raster|
           |graphics devices  and the  physical  high-resolution  raster|
           |graphics device  (display).   The final  part of the problem|
           |lies in  managing the windows on the display.  This problem,|
           |with a  little consideration  clearly differentiates  itself|
           |from  translating   between  virtual   and  physical   high-|
           |resolution raster-graphics devices.                         |
           |           |                                                |
           |In  the   X  window   system,  communication   between   the|
           |application and  its windows is handled by the X library and|
           |those libraries  built  on  top  of  the  basic  X  library.|
           |Virtual to  physical and  physical to virtual translation is|
           |handled by the X server.  X display management is handled by|
           |the X window manager.           |                           |
           |           |                                                |
           |After partitioning  the problem,  careful  consideration  of|
           |display management  leads to  the  conclusion  that  if  all|
           |windows on  a display  are treated as "children" of a single|
           |"root" window,  all of  which "belong"  in some sense to the|
           |window manager,  then the X window manager itself becomes an|
           |ordinary application  which talks  to the X server via the X|
           |library.   As a consequence, developers can easily implement|
           |different  display   management   strategies   as   ordinary|
           |applications without  having to "hack" the operating system.|
           |The  server  itself  may  be  partitioned  (under  operating|
           |systems which support the concept) into a privileged portion|
           |which directly  accesses the  display hardware  and  a  non-|
           |privileged  portion   which  requests   services  from   the|
           |privileged part  of the  server.  Under Unix, the privileged|
           |part of the server goes into the display, mouse and keyboard|
           |drivers while  the non-privileged  part becomes  an ordinary|
           |application.  In common parlance, X server usually refers to|
           |the non-privileged part of the X server which is implemented|
           |as an ordinary application.                                 |
           |                                                            |
           |The last  step in  realizing the X window system is choosing|
           |the  communications  mechanism  between  the  X  server  and|
           |ordinary applications  or the  display manager.  Because the|
           |problem was  nicely partitioned,  the communications problem|
           |is completely extrinsic to the windowing problem as lives as|
           |an easily  replaceable interface module.  The initial choice|
           |at MIT  was to  use TCP/IP  virtual circuits, which provided|
           |immediate network  transparency, but  in fact because X only|
           |requires sequenced  reliable byte-streams so that DECNET VCs|
           |or  shared-memory   communications  mechanisms   can  easily|
           |replace   TCP/IP   virtual   circuits   according   to   the|
           |requirements of  the target  environment.   Systems built on|
           |well-partitioned approaches  to solving  problems often show|
           |such flexibility  because of  modularity of the approach and|
           |because a  successful partitioning of the problem will often|
           |in its  solution increase  the understanding of the original|
           |problem that  developers can  perceive greater  tractability|
           |and simplicity  in the  original and  related problems  than|
           |they might have originally seen.                            |
           _____________________________________________________________|

            It seems  somewhat  propagandistic    to  label  the  TCP/IP
            protocol  suite   static  and   military.     New  RFCs  are
            continually being  generated as Paul Strauss has pointed out
            in his  September article.  Such new  protocols only  become
            military   standards    slowly    because    the    military
            standardization of  new protocols  and  systems  is  a  long
            tedious political  process which  once completed may require
            expensive conformance  and verification  procedures.   After
            all, neither  the   obligatory ICMP nor the immensely useful
            UDP  (User   Datagram  Protocol)  have  associated  military
            standards. Often,  after reviewing  those products generated
            by market  forces, the  US military  specifies and  acquires
            products which go beyond existing military standards. By the
            way, hierarchical  domain name  servers and  X are  used  on
            MILNET.

            VI. ENTERPRISE NETWORKING AND SOPHISTICATED APPLICATIONS:   
            SELLING INTERCOMPUTER NETWORKING            

            The military  are not  the only  users "more  interested  in
            sophisticated  applications  than  in  a  slightly  enhanced
            version of  Kermit."   The whole  DEC enterprise  networking
            strategy  is   postulated  on  this  observation.  Stallings
            ignored  my   reference  to   network  file   systems  as  a
            sophisticated  networking   application.  Yet,   in  several
            consulting jobs,  I have seen brokers and investment bankers
            make extensive  use of network file systems.  I also believe
            network transparent graphics will be popular in the business
            world.     At  Saloman   Brothers  both   IBM  PCs  and  SUN
            workstations are  extensively used.   With X, it is possible
            for a  PC user  to run a SUN application remotely which uses
            the PC  as the  output device.  This capability seems highly
            desirable in the Saloman Brothers environment.

            Unfortunately "OSI  is unlikely  ever to  provide for [such]
            resource sharing because it is industry-driven."  Wayne Rash
            Jr.,  a   member  of  the  professional  staff  of  American
            Management Systems,  Inc.  (Arlington, Virginia) who acts as
            a US federal government microcomputer consultant, writes the
            following in  "Is More Always Better," Byte, September 1988,
            p. 131.

                You've probably seen the AT&T television ads about
                this trend [toward downsizing and the development
                of LAN-based resource-sharing systems].  They
                feature two executives, one of whom is equipping
                his office with stand-alone microcomputers.  He's
                being intimidated by another executive, who tells
                him in a very nasty scene, "Stop blowing your
                budget" on personal computers and hook all your
                users to a central system.  This is one view of
                workgroup computing, although AT&T has the perverse
                idea that the intimidator is the forward thinker in
                the scene.

            AT&T and  to an  even greater  extent the similarly inclined
            European PTTs have major input into OSI specification.

            VII. BIG AND SMALL PLAYERS CONSTRAIN OSI            

            The inclinations  of AT&T  and the  PTTs are  not  the  only
            constraints  under   which  the   OSI  reference  model  was
            developed.   A proprietary  computer networking system, sold
            to a customer, becomes a cow which the manufacturer can milk
            for years. Complete and effective official standards make it
            difficult  for   a  company   to  lock  a  customer  into  a
            proprietary system.   A customer could shop for the cheapest
            standard  system,   or  could  chose  the  offering  of  the
            manufacturer considered  most reliable.   It  is  proverbial
            that no  MIS executive  gets fired  for choosing IBM.  Small
            players have  genuine reason  to fear that a big player like
            Unisys, which  no longer  has a  major proprietary  computer
            networking installed base8, or AT&T, which never had a major
            proprietary computer  networking installed  base9, might try
            to establish  themselves in  the minds  of customers  as the
            ultimate authority  for the supply of true OSI connectivity.
            Thus, small  players fear  that  a  complete  and  effective
            official  standard  might  only  benefit  the  big  players.
            Players like  AT&T or  Unisys fear  IBM  might  hi-jack  the
            standard.   IBM would prefer to preserve its own proprietary
            base  and   avoid  competing  with  the  little  guys  on  a
            cost/performance basis  in what  could turn into a commodity
            marker.

            No such  considerations were operative in the development of
            the ARPA  Internet suite of protocols.  DARPA had a specific
            need for  intercomputer networking,  was willing  to pay top
            dollar  to   get  the   top  experts  in  the  intercomputer
            networking field  to design  the system  right and  was less
            concerned by  issues of competition (except perhaps for turf
            battles within  the U.S.  government).   By contrast, almost
            all players  who have  input into  the  ISO  standardization
            process have  had reasons and have apparently worked hard to
            limit the effectiveness of OSI systems.

            With all  the limitations, which have been incorporated into
            the OSI  design and  suite of  protocols, the  small players
            have no reason to fear being overwhelmed by big players like
            Unisys or  AT&T.  The big players have the dilemma of either
            being  non-standard   or  of   providing   an   ineffective,
            incomplete  but  genuine  international  standards.    Small
            vendors have lots of room to offer enhanced versions perhaps
            drawing from more sophisticated internetworking concepts. In
            any case,  most small  vendors, as  well as DEC and IBM, are
            hedging their  bets by  offering both  OSI and  TCP/IP based
            products.   IBM seems well positioned with on-going projects
            at the  University of Michigan, CMU, MIT, Brown and Stanford
            and with  IBM's creditability  in the  business world to set
            the  standard   for  the   business  use   of  TCP/IP  style

            ____________________
            
            8 BNA  and DCA  seem hardly  to count  even  to  the  Unisys
            management.
            
            9 Connecting  computer systems  to the  telephone network is
            not computer networking in any real sense.
            ____________________


            networking. By  contrast, no major manufacturer really seems
            to want to build OSI products, and with the current state of
            OSI, there is really no reason to buy OSI products.

            VIII. MAP:  FOLLOWING THE OSI MODEL

            MAP shows perfectly the result of following the OSI model to
            produce a computer networking  system.  GM analysts sold MAP
            to GM's  top management  on the  basis of the predicted cost
            savings.   Since GM  engineers designed,  sponsored and gave
            birth to  MAP, I  am not surprised that an internal GM study
            has found MAP products less expensive than non-MAP compliant
            products.   If the internal study found anything else, heads
            would have  to roll.  Yet, as far as I know, neither IBM nor
            DEC have  bought into  the concept  although both  companies
            would probably  supply MAP  products for  sufficient profit.
            Ungermann-Bass and other similar vendors have also announced
            a disinclination  to  produce  IEEE  802.4  based  products.
            Allen-Bradley has chosen DECNET in preference to a MAP-based
            manufacturing and  materials handling system. This defection
            of major  manufacturers, vendors  and customers from the MAP
            market has to limit the amount of MAP products available for
            customers to purchase.

            Nowadays, GM  can purchase  equipment for  its manufacturing
            floor from  a limited  selection of  products, which are the
            computer networking  equivalent of  bows and arrows, whereas
            in the  past GM  was stuck  with rocks and knives.  Bows and
            arrows might  be sufficient for the current GM applications;
            however, if  my firm  had designed  MAP, GM  would have  the
            networking equivalent  of nuclear  weapons,  for    the  MAP
            network would  have been  built around  an internet  with  a
            genuine multimedium  gatewayed easily modifiable environment
            so that  in those locations where token-bus noise resistance
            is insufficient and where higher bandwidths might be needed,
            fiber media  could be  used.   With the  imminent deluge  of
            fiber-based  products,   MAP  looks   excessively   limited.
            (Actually, the  MAP standards  committees  have  shown  some
            belated awareness that fiber might be useful in factories.)

            IX. EXTENDING OSI VIA PROTOCOL CONVERTERS:  QUO VADIT?

            Interestingly enough,  even when OSI systems try to overcome
            OSI limitations via protocol conversion to provide access to
            some of  the sophisticated  resource sharing  to which  ARPA
            Internet users  have long  been accustomed,  the service  is
            specified in  such a  way as  to place  major limitations on
            performance of  more sophisticated  applications. Just  like
            IBM and  other system manufacturers, I have no problems with
            providing to  the customer  at sufficient  profit    exactly
            those products  which  the  customer  specifies.    Yet,  if
            contracted for advice on a system like the NBS TCP/IP-to-OSI
            protocol converter  IS (Intermediate  System), described  in
            "Getting there from here," Data Communications, August 1988,
            I might  point out  that such  a system  could easily double
            packet  traffic   on  a   single   LAN,   decrease   network
            availability and reliability, prevent alternate routing, and
            harm throughput  by creating  a bottleneck  at the  IS which
            must perform both TCP/IP and OSI protocol termination.

            X. CONCLUSION

            Official standardization  simply by  itself does  not make a
            proposal good.   Good  standards generally were already good
            before they  became official  standards. The  IEEE and other
            standards bodies  generate lots  of  standards  for  systems
            which quickly  pass into  oblivion.   OSI was  generated  de
            novo, apparently  with a  conscious decision  to ignore  the
            already functioning  ARPA Internet  example. Unless  a major
            rethinking  of  OSI  (like  redesigning  OSI  on  the  solid
            foundation of  the internetworking  concept) takes  place in
            the near  future, I  must conclude  that the  ARPA  Internet
            suite of  protocols will  be around for a long time and that
            users of  OSI will  be immensely  disappointed by  the cost,
            performance,  flexibility   and   manageability   of   their
            networks.

            I. Introduction                                            1
            II. The Debate                                             2
            III. Internetworking:  The Key System Level Start Point    4
            IV. "Greater Richness" Versus Developer Insight           14
                A. OSI Network Management and Netview                 14
                B. FTAM is Dangerous                                  14
                C. X.400:  E-Mail as Good as the Postal Service       15
                D. ARPA SMTP:  Designing Mail and Messaging Right     18
            V. Is the TCP/IP Protocol Suite "Static?"                 22
            VI. Enterprise Networking and Sophisticated Applications:
                    Selling Intercomputer Networking                  24
            VII. Big and Small Players Constrain OSI                  24
            VIII. MAP:  Following the OSI Model                       26
            IX. Extending OSI Via Protocol Converters:  Quo vadit?    26
            X. Conclusion                                             27

            

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 16:16:27 GMT
From:      SOL@SRI-NIC.ARPA (Sol Lederman)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Addresses?

John,

The IEEE Standards Office, the folks who sell the Ethernet vendor codes
(leading 24 bits of address) won't distribute any list of codes. What they
are willing to do is if you give them a number they'll tell you if the
number is registered (it's supposed to be in all cases) and they will
contact the manufacturer and only if the manufacturer agrees to be identified
will IEEE let the two of you communicate. Apparently enough manufacturers
value their privacy. 

Some folks on this list have their own lists of numbers they've been able to
identify without IEEE help. Hopefully somebody will email you a copy.

Let me know if you want a contact at IEEE Standards.

Sol
-------

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 21:31:10 GMT
From:      beau@ultra.UUCP (Beau James {Manager-SW Development-Ultra Network Tech.})
To:        comp.protocols.tcp-ip
Subject:   Re:  Ethernet Addresses?


	Can someone tell me if there is some sort of list that says what
	manufacturer uses what ethernet addresses?  I have noticed that
	for the most part all suns have a leading 8:0:20:?:?:? and that
	other machines do the same.  What I am looking for is a list that
	will give some indication as to what type of machine it might be
	by just looking at the ethernet address.

The official list is maintained by Xerox.  Every vendor who makes
Ethernet interfaces is supposed to apply to Xerox for a range of
Ethernet numbers, which the vendor then assigns uniquely to each
new controller built.  If everyone follows the rules, then all
Ethernet addresses will be unique.

Unfortunately, some systems assign the Ethernet address in software,
or allow you to override the Ethernet address assigned to the
controller.  So global uniqueness is not guaranteed in practice,
even when the vendors followed the rules.

I don't know the contact address at Xerox, but the information
is included in the DEC-Intel-Xerox Ethernet spec documents, if
you can locate one of those.

Beau James					beau@ultra.COM
Ultra Network Technologies

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 22:09:18 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Broken SMTP daemon @ WPAFB-FDL.ARPA

I wrote the TOPS-20 SMTP server.  I think that ISI and GUNTER-ADAM run their
own homebrew server, but all other 20's run mine.  Some, such as the NIC, have
hacked their servers; the "Don't Worry." was originally "Please report any
problems to Bug-MAISER@WSMR-SIMTEL20.ARMY.MIL." ...

At the time I wrote it (1982) I endeavored to make it conform to the standards
as published in RFC-821.  I also believed in thorough syntax checking.  I was
already warned that some Unix systems used a bogus form of A-D-L:
	<@foo:@bar:rag@zap>
instead of the correct
	<@foo,@bar:rag@zap>
and that many omitted the "@zap" part as well if "zap" .eq. server-host.  I
made allowances for these external bugs.  However, I believed that this did
not imply license for new SMTP clients to violate SMTP in other ways.  So, I
require a HELO before a MAIL, a MAIL before a RCPT, and a RCPT before a DATA.
I also check the argument for the HELO, but no HELO is ever rejected unless
the argument is missing (a client bug), syntactically bad (a client bug), or
it the argument equals the local name and the connection isn't coming from the
local host (a client and/or network "mirroring" bug, the latter being quite
common in NCP days).

My worst "crime" in all of this was my firm insistance that a NEWLINE that
ended an SMTP command was a CR followed immediately by a LF.  No bare CR's,
bare LF's, LFCR's, CR NUL's, etc. etc. need apply.  About once a month, I get
a message from some guy *insisting* that my server is broken, and it turns out
he's sending bare LF's for newlines because his sendmail.cf is broken.

How do I feel today?  I don't care.  Nobody seems to care whether or not the
protocols conform to specifications as long as they interoperate (which, I
guess, is the bottom line) so everybody just makes allowances for the zillions
of new bugs except for stubborn twerps like me who don't want to be bothered
to remove all my own syntax checking code and just tell the guys "it's your
bug, fix your client!!"  Then, when things like an Internet Worm hit, we're
unaffected and happily networking until they take down the net on us......

:-)

-- Mark --

-------

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 22:09:47 GMT
From:      galvin@TWG.COM (James M Galvin)
To:        comp.protocols.tcp-ip
Subject:   Re: TWG 3.2 chokes on my named.hosts

Questions or problems with TWG products should be directed to
"support@twg.com".  I have forwarded your message there.

Jim

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 22:10:20 GMT
From:      vanden@brubeck.SRC.Honeywell.COM (Kurt Vandenberg)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Reliable Datagram Sockets


The bsd 4.3 and Sun OS 4.0 manuals refer to reliable datagram sockets but say
they are not implemented yet.  Does anyone know of an implementation
(available or in the works) for reliable datagram sockets?


Kurt Vandenberg   (612) 782-7341                 Honeywell
UUCP : {ihnp4,philabs,umn-cs,mmm}!srcsip!vanden  Systems and Research Center  
INET : srcsip!vanden@umn-cs.cs.umn.edu           3660 Technology Drive
ARPA : vanden@src.honeywell.com                  Minneapolis, MN 55418

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 23:38:55 GMT
From:      sale@ed.uucp (Ed Sale)
To:        comp.protocols.tcp-ip
Subject:   ICMP Information Request Message format

RFC 792 when describing the Information Request message, states:

	This message may be sent with the source network in the IP header
	source and destination address fields zero (which means "this"
	network).  The replying IP module should send the reply with the
	address fully specified.  This message is a way for a host to 
	find out the number of the network it is on.

Douglas Comer in "Internetworking with TCP/IP", states:

	Machines use the ICMP information request message to obtain an
	Internet address for a network to which they attach; it is an
	alternative to RARP.

I'm confused.  Which does it do - get the network part of the internet
address (in which case how does it know what class network address it
is to determine how many bytes are host address?) - or get the entire
internet address translated from the hardware address in the physical
header - or both?


Ed Sale

...!uunet!ingr!b11!sale  or  b11!ed!sale@ingr.com

Ed Sale

..!uunet!ingr!b11!sale  or  b11!ed!sale@ingr.com

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 89 23:53:54 GMT
From:      hans@duttnph.UUCP (Hans Buurman)
To:        comp.protocols.tcp-ip
Subject:   unsubnetted B-net



My university has recently been appointed a B-class network, and is now
moving towards an unsubnetted B-net. The reason to do things unsubnetted,
I am told, is the fact that there are other protocols than tcp-ip on the
net. I am not sure, but from a unix point if view this looks like an
unpleasant solution. We will have bridges separating busy branches of the
net, but these will be transparent to broadcasts so that these will be seen
everywhere.

I am not a networking wizard, I just use unix machines (suns, mostly)
and like to do NFS mounts between different faculties. I really like
our network as it is now. I'm afraid it will not improve.

Would the net like to comment on our solution or other solutions ?
Please email, I'll summarise to the net.

	Hans

Disclaimer: any opinions expressed above are my own.

-----------------Stop acid rain. Don't burn books.---------------------------
Hans Buurman                   | hans@duttnph.UUCP
Pattern Recognition Group      | mcvax!hp4nl!dutrun!duttnph!hans
Faculty of Applied Physics     | tel. 31 - (0) 15 - 78 46 94
Delft University of Technology |

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 01:40:41 GMT
From:      penneyj@servio.UUCP (D. Jason Penney)
To:        comp.protocols.tcp-ip
Subject:   Interaction of wildcard bind() with services database

I want some opinions whether or not what I have been seeing should
be regarded as a TCP/IP bug or a feature.

We have some entries in our services database that are above 1024 and
refer to services that are usually not in use.  When we call bind()
with the requested port INADDR_ANY, bind() *can*, upon occasion, actually
return a port that is listed in the services database.

I think it is bug.  Suppose a booting system invokes two different
services, both of which allocate both a predeclared port (from the
services database) and a wildcard port.  In theory, it might never
be possible for the system to boot properly because the wildcard
bind allocates the second service's predeclared port.

I have seen this problem on SunOS, VAX/VMS Wollongong (WIN) TCP/IP,
and an unnamed System V Unix derivative.

Is there any reason I shouldn't call up these vendors and tell them
it's a bug?

-- 
D. Jason Penney                  Ph: (503) 629-8383
Servio Logic Corporation       uucp: ...ogccse!servio!penneyj
15220 NW Greenbrier Parkway #100
Beaverton, OR 97006

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 05:16:27 GMT
From:      MAP@LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   list of Ethernet addresses (&c.)


   Date: 15 Mar 89 10:38:26 GMT
   From: neptune!pvo1478@cs.orst.edu  (Paul O'Neill)

       ftp pprg.unm.edu
       get pub/rfc/ethernet_vendor_addrs

   It's dated 6/18/88 and has 45 entries.

A more extensive one (I went to merge your's in and found it was a
subset) dated 12/5/88 is available for anonymous ftp from my work-
station [Gaak.LCS.MIT.Edu] as the file pub/map/ethernet-codes which
also lists Multi-cast addresses and type codes.  This is a merge of an
October 1988 version of the BBN list (that's what you have) and
another list posted in late November.

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 1989 19:25-EST
From:      URBANIAK@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA, bytecounters@VENERA.ISI.EDU
Cc:        urbaniak@BBN.COM
Subject:   Ethernet Type Fields, etc.
Attached is the most recent list of Ethernet Type Fields, Vendor Addresses,
and known Multicast Addresses. please send comments or additions directly
to Urbaniak@BBN.COM.

Future publications of this information will probably be as a TCP/IP
Internet RFC, rather than email to this mailing list. If you wish
to comment on the format in which this data should be presented,
or if you wish to be placed on a private mailing list for these
updates, please send me mail at Urbaniak@BBN.COM, or US Mail at

	Bolt, Beranek & Newman, Inc.
	10 Fawcett Street
	Cambridge, MA 02138
	attn: Walter Urbaniak, MS021
Some Known Ethernet and IEEE802.3 "Type" Fields		3/16/89

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These values are managed by XEROX.
Some assignments are public, others private. Current information includes:
Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960;
contributions from network managers and vendors.

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888-088A	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation for IP
1600	VALID system protocol *
5208	BBN Simnet Private %
6000	DEC unassigned, experimental
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV, DNA Routing
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC), System Communication Architecture (SCA)
6008	DEC unassigned (AMBER?)
6009	DEC unassigned (MUMPS?)
6010-6014	3Com
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
7020-7029	LRT
7030	Proteon
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8008	AT&T
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
802E	Tymshare
802F	Tigan
8035	Reverse Address Resolution Protocol (RARP)
8036	Aeonic Systems
8038	DEC LanBridge Management
8039	DEC unassigned (DSM/DTP?)
803A	DEC unassigned (Argonaut Console?)
803B	DEC unassigned (VAXELN?)
803C	DEC unassigned (NMSV? DNA Naming Service?)
803D	DEC Ethernet CSMA/CD Encryption Protocol
803E	DEC unassigned (DNA Time Service?)
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned (NetBios Emulator?)
8041	DEC unassigned (MS/DOS?, Local Area System Transport?)
8042	DEC unassigned
8044	Planning Research Co.
8046	AT&T
8047	AT&T
8049	ExperData
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
805D	Evans & Sutherland
8060	Little Machines
8062	Counterpoint Computers
8065	University of Massachusetts, Amherst
8066	University of Massachusetts, Amherst
8067	Veeco Integrated Automation
8068	General Dynamics
8069	AT&T
806A	Autophon
806C	ComDesign
806D	Compugraphic
806E-8077	Landmark Graphics
807A	Matra
807B	Dansk Data Elektronik
807C	Merit Internodal (or Univ of Michigan?)
807D-807F	Vitalink
8080	Vitalink TransLAN III Management
8081-8083	Counterpoint Computers
809B	EtherTalk (AppleTalk over Ethernet)
809C-809E	Datability
809F	Spider Systems
80A3	Nixdorf Computers
80A4-80B3	Siemens Gammasonics
80C0-80C3	DCA (Digital Comm. Assoc.) Data Exchange Cluster
80C6	Pacer Software
80C7	Applitek
80C8-80CC	Intergraph
80CD-80CE	Harris
80CF-80D2	Taylor Instrument
80D3-80D4	Rosemount
80DD	Varian
80DE-80DF	Integrated Solutions Transparent Remote File System (TRFS)
80E0-80E3	Allen-Bradley
80E4-80F0	Datability
80F2	Retix
80F3	AppleTalk Address Resolution Protocol (AARP)
80F4-80F5	Kinetics
80F7	Apollo
80FF-8103	Wellfleet
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8130	Waterloo Microsystems
8131	VG Laboratory Systems
8137	Novell (old)
8138	Novell
8139-813D	KTI
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
9003	Bridge Communications
FF00	BBN VITAL-LanBridge cache wakeups %

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
Some Known Ethernet Vendor Addresses		3/16/89

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme (e.g AA0003; 02xxxx).

00000C	Cisco
000020	DIAB (Data Intdustrier AB)
000022	Visual Technology
00002A	TRW
00005A	S & Koch
000065	Network General
000089	Cayman Systems	Gatorbox
000093	Proteon
00009F	Ameristar Technology
0000A9	Network Systems
0000AA	Xerox		Xerox machines
0000B3	CIMLinc
0000C0	Western Digital
0000DD	Gould
0000E2	Acer Counterpoint
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00AA00	Intel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	MICOM/Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080003	ACC (Advanced Computer Communications)
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
08000A	Nestar Systems
08000B	Unisys
080010	AT&T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080022	NBI
080025	CDC
080028	TI		Explorer
08002B	DIGITAL
080036	Intergraph	CAE stations
080039	Spider Systems
080045	Xylogics???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
08005A	IBM
080067	Comdesign
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
080075	DDE (Danish Data Elektronik A/S)
08007C	Vitalink	TransLAN III
080080	XIOS
080086	Imagen/QMS
080087	????
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0000	DIGITAL		obsolete~
AA0001	DIGITAL		obsolete~
AA0002	DIGITAL		obsolete~
AA0003	DIGITAL		Global physical address for some older DEC interfaces
AA0004	DIGITAL		Local logical address for systems running DECNET
Some Known Ethernet Multicast Addresses		3/16/89

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-02-04-00-01?	8080?	Vitalink printer
09-00-02-04-00-02?	8080?	Vitalink management
09-00-09-00-00-01	8005	HP Probe
09-00-09-00-00-01	802.2LLC	HP Probe
09-00-09-00-00-04	8005?	HP DTC
09-00-1E-00-00-00	8019?	Apollo DOMAIN
09-00-2B-00-00-00	6009?	DEC MUMPS?
09-00-2B-00-00-01	8039?	DEC DSM/DTP?
09-00-2B-00-00-02	803B?	DEC VAXELN?
09-00-2B-00-00-03	8038	DEC Lanbridge Traffic Monitor (LTM)
09-00-2B-00-00-04	????	DEC MAP End System Hello?
09-00-2B-00-00-05	????	DEC MAP Intermediate System Hello?
09-00-2B-00-00-06	803D?	DEC CSMA/CD Encryption?
09-00-2B-00-00-07	8040?	DEC NetBios Emulator?
09-00-2B-00-00-0F	6004	DEC Local Area Transport (LAT)
09-00-2B-00-00-1x	????	DEC Experimental
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets (All bridges)
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets (All local bridges)
				1 packet per second, sent by the
				designated LanBridge
09-00-2B-02-00-00	????	DEC DNA Level 2 Routing Layer routers?
09-00-2B-02-01-00	803C?	DEC DNA Naming Service Advertisement?
09-00-2B-02-01-01	803C?	DEC DNA Naming Service Solicitation?
09-00-2B-02-01-02	803E?	DEC DNA Time Service?
09-00-2B-03-xx-xx	????	DEC default filtering by bridges?
09-00-2B-04-00-00	8041?	DEC Local Area System Transport (LAST)?
09-00-2B-23-00-00	803A?	DEC Argonaut Console?
09-00-4E-00-00-02?	8137?	Novell IPX
09-00-7C-02-00-05	8080?	Vitalink diagnostics
09-00-7C-05-00-01	8080?	Vitalink gateway?
0D-1E-15-BA-DD-06	????	HP
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				DNA Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				DNA Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-03-00-00-00	6004	DEC Local Area Transport (LAT) - old
AB-00-04-00-xx-xx	????	Reserved DEC customer private use
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
				System Communication Architecture (SCA)
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0804	CHAOS
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	0BAD	Banyan
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
FF-FF-FF-FF-FF-FF	8035	Reverse ARP
FF-FF-FF-FF-FF-FF	807C	Merit Internodal (INP)
FF-FF-FF-FF-FF-FF	809B	EtherTalk
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 16:32:02 GMT
From:      mckee@CORWIN.CCS.NORTHEASTERN.EDU (George McKee)
To:        comp.protocols.tcp-ip
Subject:   syntax of remote pathnames?

Is there any standard notation for file on some remote host where
the filename includes the host's domain name?  People seem to
talk around the issue when the problem comes up in writing 
and use expressions like:
	ftp somehost.someUniv.EDU
	get pub/goodstuff/goodthing
when it would make the writing flow much more smoothly if you
could say things like "you can find a program that might do what
you want in @SUMEX-AIM.STANFORD.EDU:info-mac/app/contour81.hqx".
	If there's no standard for this, I'll propose that a
pathname beginning with @ be interpreted as an Internet File Path
and that the string between the @ and the following : conform to
the normal domain syntax and denote the host filesystem that the
IFP refers to.  Anything following the : will use whatever syntax
is native to the host filesystem.
	An obvious alternative is pathname@domain.name like in
mailboxes, but people don't use this either.  I don't know why.

	- George McKee
	  NU Computer Science

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 17:21:18 GMT
From:      smir@pbhya.PacBell.COM (Sonu Mirchandani)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.proteon,comp.dcom.modems,pb.general
Subject:   Direct T1 interface



  The following is a request from a colleague, and I am posting this
  on behalf of him. In responding to your questions, if any, I will
  try to answer as soon as I can. If you wish to send replies directly
  to me, feel free to do so. Either way, I will summarize, if there's
  enough interest.  Appreciate your time and thanks for the input.
  Sorry if this has already been discussed.


          Are there routers available that provide a T-1 rate serial
          interface that meets the DSX-1 standards?  The DSX-1 is a
          signal that is T-1 framed 1.544mbps and connects directly to
          T-1 equipment, such as a microwave link or T-1 switch
          located close to the router (i.e. within 600 feet).  This
          would elminate the need to use the V.35 interface at the
          router along with an external T-1 DSU/CSU (which costs about
          $3k).  Some of the functions provided by the DSU/CSU to
          drive the long T-1 line are not needed for these short
          connections.  If this DSX-1 serial interface is available on
          a particular box, how would the price of this interface
          board compare with the straight V.35 interface?


 Sonu Mirchandani
 smir@pacbell.com
 (415) 823-8908

 pacific bell, 2600 camino ramon, 2 south 300, san ramon, ca. 94583

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 17:28:34 GMT
From:      huitema@mirsa.UUCP (Christian Huitema)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat
Subject:   Re: TCP/IP versus OSI

From article <2145@cpoint.UUCP>, by martillo@cpoint.UUCP (Joachim Carlo Santos Martillo):
> The following is an article which I am going to submit to Data
 < Communications in reply to a column which William Stallings
> did on me a few months ago.  I think people in this forum might
 < be interested, and I would not mind some comments.
> 
 < 
>                    Round 2 in the great TCP/IP versus OSI Debate
< .... 

I always thought that the date for April fools was April 1st, not March 15th..

Christian Huitema  <huitema@mirsa.inria.fr>

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 20:39:00 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Reliable Datagram Sockets

Kurt Vandenberg:

Please note, "reliable datagram" is an oxymoron (like Military Intelligence).

--jon.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 21:54:46 GMT
From:      brentb@BOULDER.COLORADO.EDU (Brent Browning)
To:        comp.protocols.tcp-ip
Subject:   Hardware Ethernet addresses


   Does someone have a list of the IEEE assigned 3 byte hardware
ethernet address prefixes and the vendors that they have been
assigned to?  I seem to remember someone posting a list like
this a while ago.

08:00:20:XX:XX:XX		Sun Microsystems, Inc.
(etc...)

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Brent Browning                Internet: brentb@boulder.Colorado.EDU  |
| Dept. of Computer Science     UUCP: ...!{ncar,nbires}!boulder!brentb |
| University of Colorado                                               |
| Boulder, Colorado 80309-0430  Phone: (303) 492-0264                  |
 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 21:59:26 GMT
From:      john@stiatl.UUCP (John DeArmond)
To:        comp.protocols.tcp-ip
Subject:   Question regarding print spooling

I have a question regarding print spooling and tcp/ip for the net.  We have
written a print spooling server designed to allow tcp/ip users on PCs 
transfer files directly to the spooler on our SYSV unix system (convergent 640).  
We have used port 515 which is reserved by Sun in the /etc/services file for an 
experimental spooler server.  The server as it currently exists is 
interactive in that after the user telnets to port 515, the server prompts the 
user for an ID to print on the burst page, asks which service he wants (and 
will present a list of services on request), and then opens a pipe to lp.  
The user then dumps the file down the pipe and closes the connnection.

We would like to add a keyword "print" or something similiar to the PC
programs (modified ka9q and/or ncsa) to automate the process.  The user
should be able to type something to the effect:

print -dhplaser stiatl:filename

in order to print a file.  I started to design a protocol using FTP 
result codes but before I proceed down this path too far, I want to 
find out what, if anything, have others done in this area.  I can 
find no references to printing in my body of reference materials (RFCs,
Tannenbaum, Sun manuals, and so on).  Comments and advice welcome.

Thanks,
John


PS:  I have no internet access so I'd appreciate if you reference a 
document, emailing it to me if possible.

-- 
John De Armond, WD4OQC                     | Manual? ... What manual ?!? 
Sales Technologies, Inc.    Atlanta, GA    | This is Unix, My son, You 
...!gatech!stiatl!john                     | just GOTTA Know!!! 

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 23:00:07 GMT
From:      tdh@moriaMoria.Sp.Unisys.Com (Thomas Hintz)
To:        comp.protocols.tcp-ip
Subject:   IETF RFC Draft


I'm looking for a copy of the forthcomming IETF RFC document.  If you have it,
please to be so kind as to mail it my way... Thanks much!

Thomas D. Hintz				(612) 687-2684
UNISYS					tdh@moria.sp.unisys.com
Network Engineering			..bungia!com50!mscunx!moria!tdh
-- 
Thomas D. Hintz				(612) 687-2684
UNISYS					tdh@moria.sp.unisys.com
Network Engineering			..bungia!com50!mscunx!moria!tdh

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 23:07:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   TCP checksum shortcuts


  I am not the world's best mathematician, and 1's complement arithmetic
is sometimes scary, so I'll post this here, since probably many of you out
in netland have come up against this.
  A TCP checksum is the complement of the sum of all the words in a file
(everything done in 1's complement instead of 2's complement, as any fool
can see). Suppose I have a checksum for a packet that I'm brewing up, and
I change 1 word that has the value 0xNNNN to 0xMMMM. Could I just set
the checksum to complement(complement(old-chksum) - 0xNNNN + 0xMMMM)??
  That is, is 1's complement addition associative in real life?
  A similar trick is to stash the checksum of the data-portion while
twiddling the bits in the header.
  The reason I was thinking of this is that it would be possible to
stash checksums of various pieces of messages and header-templates and
whatnot, then when a packet it put together before going out, it might
be possible to save time recalculating the checksum (esp. if the data
portion is big). Recalculating checksums on retransmissions might be
easier, too, though the overall performance impact should be negligible.

  In short, what shortcuts do folks know to make checksumming in
software (apologies to anyone at AT&T who cringes at the thought) less
expensive????

Johnny Zweig
University of Illinois at Urbana-Champaign
Department of Computer Science

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 89 23:19:40 GMT
From:      doug@csd4.milw.wisc.edu (Doug Tiarks)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NCSA Telnet and SLIP ??

Hi,

Has out there anyone added SLIP support to NCSA Telnet (IBM PC version)? 
If not does anyone have any suggestions/pointers to adding
it? Any help would be appreciated.



	Doug Tiarks
	UW-Milwaukee Computing Services Div.

	Internet: doug@csd4.milw.wisc.edu
	UUCP: {uwvax, uwmacc}!uwmcsd1!doug
--

	Doug Tiarks
	UW-Milwaukee Computing Services Div.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 00:25:00 GMT
From:      URBANIAK@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Ethernet Type Fields, etc.

Attached is the most recent list of Ethernet Type Fields, Vendor Addresses,
and known Multicast Addresses. please send comments or additions directly
to Urbaniak@BBN.COM.

Future publications of this information will probably be as a TCP/IP
Internet RFC, rather than email to this mailing list. If you wish
to comment on the format in which this data should be presented,
or if you wish to be placed on a private mailing list for these
updates, please send me mail at Urbaniak@BBN.COM, or US Mail at

	Bolt, Beranek & Newman, Inc.
	10 Fawcett Street
	Cambridge, MA 02138
	attn: Walter Urbaniak, MS021
 Some Known Ethernet and IEEE802.3 "Type" Fields		3/16/89

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These values are managed by XEROX.
Some assignments are public, others private. Current information includes:
Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960;
contributions from network managers and vendors.

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888-088A	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation for IP
1600	VALID system protocol *
5208	BBN Simnet Private %
6000	DEC unassigned, experimental
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV, DNA Routing
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC), System Communication Architecture (SCA)
6008	DEC unassigned (AMBER?)
6009	DEC unassigned (MUMPS?)
6010-6014	3Com
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
7020-7029	LRT
7030	Proteon
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8008	AT&T
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
802E	Tymshare
802F	Tigan
8035	Reverse Address Resolution Protocol (RARP)
8036	Aeonic Systems
8038	DEC LanBridge Management
8039	DEC unassigned (DSM/DTP?)
803A	DEC unassigned (Argonaut Console?)
803B	DEC unassigned (VAXELN?)
803C	DEC unassigned (NMSV? DNA Naming Service?)
803D	DEC Ethernet CSMA/CD Encryption Protocol
803E	DEC unassigned (DNA Time Service?)
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned (NetBios Emulator?)
8041	DEC unassigned (MS/DOS?, Local Area System Transport?)
8042	DEC unassigned
8044	Planning Research Co.
8046	AT&T
8047	AT&T
8049	ExperData
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
805D	Evans & Sutherland
8060	Little Machines
8062	Counterpoint Computers
8065	University of Massachusetts, Amherst
8066	University of Massachusetts, Amherst
8067	Veeco Integrated Automation
8068	General Dynamics
8069	AT&T
806A	Autophon
806C	ComDesign
806D	Compugraphic
806E-8077	Landmark Graphics
807A	Matra
807B	Dansk Data Elektronik
807C	Merit Internodal (or Univ of Michigan?)
807D-807F	Vitalink
8080	Vitalink TransLAN III Management
8081-8083	Counterpoint Computers
809B	EtherTalk (AppleTalk over Ethernet)
809C-809E	Datability
809F	Spider Systems
80A3	Nixdorf Computers
80A4-80B3	Siemens Gammasonics
80C0-80C3	DCA (Digital Comm. Assoc.) Data Exchange Cluster
80C6	Pacer Software
80C7	Applitek
80C8-80CC	Intergraph
80CD-80CE	Harris
80CF-80D2	Taylor Instrument
80D3-80D4	Rosemount
80DD	Varian
80DE-80DF	Integrated Solutions Transparent Remote File System (TRFS)
80E0-80E3	Allen-Bradley
80E4-80F0	Datability
80F2	Retix
80F3	AppleTalk Address Resolution Protocol (AARP)
80F4-80F5	Kinetics
80F7	Apollo
80FF-8103	Wellfleet
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8130	Waterloo Microsystems
8131	VG Laboratory Systems
8137	Novell (old)
8138	Novell
8139-813D	KTI
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
9003	Bridge Communications
FF00	BBN VITAL-LanBridge cache wakeups %

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
 Some Known Ethernet Vendor Addresses		3/16/89

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme (e.g AA0003; 02xxxx).

00000C	Cisco
000020	DIAB (Data Intdustrier AB)
000022	Visual Technology
00002A	TRW
00005A	S & Koch
000065	Network General
000089	Cayman Systems	Gatorbox
000093	Proteon
00009F	Ameristar Technology
0000A9	Network Systems
0000AA	Xerox		Xerox machines
0000B3	CIMLinc
0000C0	Western Digital
0000DD	Gould
0000E2	Acer Counterpoint
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00AA00	Intel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	MICOM/Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080003	ACC (Advanced Computer Communications)
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
08000A	Nestar Systems
08000B	Unisys
080010	AT&T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080022	NBI
080025	CDC
080028	TI		Explorer
08002B	DIGITAL
080036	Intergraph	CAE stations
080039	Spider Systems
080045	Xylogics???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
08005A	IBM
080067	Comdesign
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
080075	DDE (Danish Data Elektronik A/S)
08007C	Vitalink	TransLAN III
080080	XIOS
080086	Imagen/QMS
080087	????
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0000	DIGITAL		obsolete~
AA0001	DIGITAL		obsolete~
AA0002	DIGITAL		obsolete~
AA0003	DIGITAL		Global physical address for some older DEC interfaces
AA0004	DIGITAL		Local logical address for systems running DECNET
 Some Known Ethernet Multicast Addresses		3/16/89

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-02-04-00-01?	8080?	Vitalink printer
09-00-02-04-00-02?	8080?	Vitalink management
09-00-09-00-00-01	8005	HP Probe
09-00-09-00-00-01	802.2LLC	HP Probe
09-00-09-00-00-04	8005?	HP DTC
09-00-1E-00-00-00	8019?	Apollo DOMAIN
09-00-2B-00-00-00	6009?	DEC MUMPS?
09-00-2B-00-00-01	8039?	DEC DSM/DTP?
09-00-2B-00-00-02	803B?	DEC VAXELN?
09-00-2B-00-00-03	8038	DEC Lanbridge Traffic Monitor (LTM)
09-00-2B-00-00-04	????	DEC MAP End System Hello?
09-00-2B-00-00-05	????	DEC MAP Intermediate System Hello?
09-00-2B-00-00-06	803D?	DEC CSMA/CD Encryption?
09-00-2B-00-00-07	8040?	DEC NetBios Emulator?
09-00-2B-00-00-0F	6004	DEC Local Area Transport (LAT)
09-00-2B-00-00-1x	????	DEC Experimental
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets (All bridges)
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets (All local bridges)
				1 packet per second, sent by the
				designated LanBridge
09-00-2B-02-00-00	????	DEC DNA Level 2 Routing Layer routers?
09-00-2B-02-01-00	803C?	DEC DNA Naming Service Advertisement?
09-00-2B-02-01-01	803C?	DEC DNA Naming Service Solicitation?
09-00-2B-02-01-02	803E?	DEC DNA Time Service?
09-00-2B-03-xx-xx	????	DEC default filtering by bridges?
09-00-2B-04-00-00	8041?	DEC Local Area System Transport (LAST)?
09-00-2B-23-00-00	803A?	DEC Argonaut Console?
09-00-4E-00-00-02?	8137?	Novell IPX
09-00-7C-02-00-05	8080?	Vitalink diagnostics
09-00-7C-05-00-01	8080?	Vitalink gateway?
0D-1E-15-BA-DD-06	????	HP
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				DNA Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				DNA Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-03-00-00-00	6004	DEC Local Area Transport (LAT) - old
AB-00-04-00-xx-xx	????	Reserved DEC customer private use
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
				System Communication Architecture (SCA)
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0804	CHAOS
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	0BAD	Banyan
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
FF-FF-FF-FF-FF-FF	8035	Reverse ARP
FF-FF-FF-FF-FF-FF	807C	Merit Internodal (INP)
FF-FF-FF-FF-FF-FF	809B	EtherTalk

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 01:52:24 GMT
From:      cyrus@pprg.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Re: Hardware Ethernet addresses

Since many people are talking/requesting this information, I will
post the information I have.  I would like to thank Michael Patton
from Laboratory for Computer Science MIT for his updated versions.
These versions, as a previous posting mentioned, are available
via anonymous ftp from pprg.unm.edu (129.24.13.10) in /pub/rfc/*


Some Known Ethernet and IEEE802.3 "Type" Fields		3/16/89

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after
the preamble) consist of the "Ethernet Type" or "IEEE802.3 Length"
field. The "Ethernet Type" values are managed by XEROX.  Some
assignments are public (see + below), others private.  Current
information includes:  Xerox Public Ethernet Packet Type
documentation(Xerox Courier Vol. 3 Issue 4 October 1988); IEEE802.3
Std; NIC RFC1010; contributions from network managers and vendors.

Hex
@   0000-05FF   IEEE802.3 Length Field
+   0101-01FF   Experimental
    0200        Xerox PUP (conflicts with IEEE802.3 Length Field
			range) (see 0A00)
    0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
+*  0600	Xerox NS IDP
+*# 0800	Dod Internet Protocol (IP) (RFC791)
+   0801	X.75 Internet
+   0802	NBS Internet
+   0803	ECMA Internet
+   0804	CHAOSnet (proposed by Symbolic)
+   0805	X.25 Level 3
+*  0806	Address Resolution Protocol (ARP) (RFC826) (for IP and
			for CHAOS) (proposed by Symbolic)
    0807	XNS Compatibility
    081C	Symbolics Private
+   0888-088A   Xyplex
    0900	Ungermann-Bass network debugger
    0A00	Xerox IEEE802.3 PUP (was 0200, see above)
    0A01	Xerox IEEE802.3 PUP Address Translation (was 0201, see above)
    0BAD	Banyan Systems
    1000	Berkeley Trailer negotiation
    1001-100F   Berkeley Trailer encapsulation for IP
*   1600	VALID system protocol
%   5208	BBN Simnet Private
    6000	DEC unassigned
    6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
    6002	DEC Maintenance Operation Protocol (MOP) Remote Console
    6003	DECNET Phase IV
    6004	DEC Local Area Transport (LAT)
    6005	DEC diagnostic protocol (at interface initialization?)
    6006	DEC customer protocol
    6007	DEC Local Area VAX Cluster (LAVC)
    6008	DEC unassigned
    6009	DEC unassigned
+   6010-6014   3Com Corporation
    7000	Ungermann-Bass download
    7002	Ungermann-Bass diagnostic/loopback
+   7020-7029   LRT
    8003	Cronus VLN
    8004	Cronus Direct
    8005	HP Probe protocol
+   8006	Nestar
+   8008	AT&T
    8010	Excelan
+   8013	Silicon Graphics diagnostic
+   8014	Silicon Graphics network games
+   8015	Silicon Graphics reserved
+   8016	Silicon Graphics XNS NameServer, bounce server
+   8019	Apollo DOMAIN
+   802E	Tymshare
+   802F	Tigan, Inc.
+   8035	Reverse Address Resolution Protocol (RARP) (RFC903)
			(by Stanford University)
+   8036	Aeonic Systems
    8038	DEC LanBridge Management
    8039	DEC unassigned
    803A	DEC unassigned
    803B	DEC unassigned
    803C	DEC unassigned
    803D	DEC Ethernet Encryption Protocol
    803E	DEC unassigned
    803F	DEC LAN Traffic Monitor Protocol
    8040	DEC unassigned
    8041	DEC unassigned
    8042	DEC unassigned
+   8044	Planning Research Corp.
+   8046-8047   AT&T
+   8049	ExperData
+   805B	Stanford V Kernel, experimental
+   805C	Stanford V Kernel, production
+   805D	Evans & Sutherland
+   8060	Little Machines
+   8062	Counterpoint Computers
+   8065-8066   University Of Mass. at Amherst
+   8067	Veeco Integrated Automation
+   8068	General Dynamics
+   806A	Autophon
+   806C	ComDesign
+   806D	Compugraphic Corporation
+   806E-8077   Landmark Graphics Corporation
+   807A	Matra
+   807C	Merit Internodal (University of Michigan)
+   807D-807F   Vitalink Communications
+   8080	Vitalink TransLAN III Management
+   8081-8083   Counterpoint Computers
+   809B	EtherTalk (AppleTalk over Ethernet) (Kinetics)
+   809C-809E   Datability
+   809F	Spider Systems Ltd.
+   80A3	Nixdorf Computers
+   80A4-80B3   Siemens Gammasonics Inc.
+   80C0-80C3   Digital Comm. Assoc. Inc.
    80C1	DCA Data Exchange Cluster
+   80C6	Pacer Software
+   80C7	Applitek Corporation
+   80C8-80CC   Intergraph Corporation
+   80CD-80CE   Harris Corporation
+   80CF-80D2   Taylor Instrument
+   80D3-80D4   Rosemount Corporation
+   80DD	Varian Associates
+   80DE	TRFS (Integrated Solutions Transparent Remote File System)
+   80DF	Integrated Solutions
+   80E0-80E3   Allen-Bradley
+   80E4-80F0   Datability
+   80F2	Retix
+   80F3	AppleTalk Address Resolution Protocol (AARP) (Kinetics)
+   80F4-80F5   Kinetics
+   80F7	Apollo Computer
+   80FF-8103   Wellfleet Communications
+   8069	AT&T
+   807B	Dansk Data Elektronik A/S
    8107	Symbolics Private
    8108	Symbolics Private
    8109	Symbolics Private
+   8130	Waterloo Microsystems Inc.
+   8131	VG Laboratory Systems
+   8137-8138   Novell, Inc.
+   8139-813D   KTI
+   9000	Loopback (Configuration Test Protocol)
    9001	Bridge Communications XNS Systems Management
    9002	Bridge Communications TCP/IP Systems Management
%   FF00	BBN VITAL-LanBridge cache wakeups

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
+ These protocols are mentioned by Xerox in their October 1988 issue of
  COURIER (page 8-9) as the publicly assigned numbers.  Only vendors are
  listed by Xerox, not what protocols.  For more information about type field
  assignments, contact: Pam DuPuy, Xerox Systems Instuture, (408)737-4652.
@ According to the October 1988 issue of COURIER (page 8), "if it is less
  than 600H, the packet is assumed to be an 802.3 packet; if it is greater
  than 600H, the packet is flagged as an Ethernet packet."
 Some Known Ethernet Vendor Addresses		12/5/88

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme.

00000C	Cisco
000020	DIAB (Data Intdustrier AB)
000022	Visual Technology
00002A	TRW
00005A	S & Koch
000065	Network General
000093	Proteon
00009F	Ameristar Technology
0000A9	Network Systems
0000AA	Xerox		Xerox machines
0000B3	CIMLinc
0000C0	Western Digital
0000DD	Gould
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid; Cisco
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080003	ACC (Advanced Computer Communications)
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
08000A	Nestar Systems
08000B	Unisys
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080022	NBI
080025	CDC
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080036	Intergraph	CAE stations
080039	Spider Systems
080045	Xylogics???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
08005A	IBM
080067	Comdesign
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
080075	DDE (Danish Data Elektronik A/S)
08007C	Vitalink	TransLAN III
080080	XIOS
080087	????
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Global physical address for some DEC machines
AA0004	DEC		Local logical address for systems running DECNET
 Some Known Ethernet Multicast Addresses		12/5/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-02-04-00-01?	8080?	Vitalink printer
09-00-02-04-00-02?	8080?	Vitalink management
09-00-09-00-00-01	8005	HP Probe
09-00-09-00-00-01	802.2LLC	HP Probe
09-00-09-00-00-04	8005?	HP DTC
09-00-1E-00-00-00	8019?	Apollo DOMAIN
09-00-2B-00-00-03	8038	DEC Lanbridge Traffic Monitor (LTM)
09-00-2B-00-00-0F	6004	DEC Local Area Transport (LAT)
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
09-00-4E-00-00-02?	8137?	Novell IPX
09-00-7C-02-00-05	8080?	Vitalink diagnostics
09-00-7C-05-00-01	8080?	Vitalink gateway?
0D-1E-15-BA-DD-06	????	HP
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-03-00-00-00	6004	DEC Local Area Transport (LAT) - old
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-00-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0804	CHAOS
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	0BAD	Banyan
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
FF-FF-FF-FF-FF-FF	8035	Reverse ARP
FF-FF-FF-FF-FF-FF	807C	Merit Internodal (INP)
FF-FF-FF-FF-FF-FF	809B	EtherTalk

---
W. Tait Cyrus   (505) 277-0806		e-mail: cyrus@pprg.unm.edu
University of New Mexico			
Dept of ECE - Parallel Processing Research Group
Albuquerque, New Mexico 87131

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 04:36:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   syntax of remote pathnames?

One syntax that's often used is

    hostname:pathname

eg, "Bigboote.LCS.MIT.EDU:/etc/passwd",
    "Reagan.AI.MIT.EDU:>File-Server>FOO.Lisp",
    "XX.LCS.MIT.EDU:XX:<SRA>LOGIN.CMD".

This syntax has been used by the the generic filesystem code in the
Lisp Machine family of systems (MIT CADR, LMI, TI, Symbolics) for a
long time, and was used by some commands (rcp et al) in BSD 4.2.

Of course, there will always be filesystem syntaxes that will confuse
the simpleminded program, eg "MC.LCS.MIT.EDU:PK0:SRA;SRA LOGIN" (the
space is a required part of the filename syntax, and the local portion
could equally well have been written as "PK0: SRA; SRA LOGIN").

Perhaps just stating the hostname and a string to ask that host for in
plain English wasn't such a bad idea after all!

--Rob

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 04:49:38 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Information Request Message format

I do not think you are confused.  If Comer says ICMP Information
Request can be used as a complete replacement for RARP, then he is
confused.  However it could be used in some cases.  According to
RFC792, ICMP Information Request can be used in the case where a host
knows its own host number, but not its network number.  The source
address would be thus be something like 0.0.0.123.  The host
generating the reply fills in the address by supplying the local
network number.  In the early days, there were some schemes that
mapped the host number into the low-order byte of the Ethernet
address, derived it from the machine serial number, etc.  In such a
situation the local software might reasonably be able to deterine the
local host number but not the network number.  In practice I don't
think anybody uses such schemes these days.  So this technique for
finding your own address isn't much use.  I suppose one could extend
ICMP information request by allowing a source address of 0.0.0.0 where
a host didn't know anything about its address at all.  If the system
generating the reply can see the Ethernet address from which the
request came, and if it has a table of Ethernet address vs IP address
(i.e. the data needed to use RARP), it would then be in a position to
fill in the full address.  While one could imagine using such a
technique, I've never heard of it being done.  4.3 BSD will work if
you supply 0.0.0.123, but not 0.0.0.0.  (If you did that, it would
return an address like 128.6.0.0, i.e. the network number with the
zero still in the low-order end.)  In my view, that is technically
what RFC 792 says to do.  I suggest using BOOTP to find your IP
address.  Its advantage over RARP is that it will work even if you are
separated from the bootp server by a router.  It is also possible to
us bootp to give configuration information other than just the IP 
address.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Mar 89 15:56:20 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   April '89 CCR

Hi folks:

    Just wanted to let you know that the April issue of CCR may be of
interest to many of you.  The articles in it include:

    an article by Dave Borman of 500+ mbit/sec Cray TCP implementation

    an article by Bill Nowicki on making NFS run over complex Internet
	paths

    an article by Steve Bellovin on security problems with the TCP/IP
	protocol suite

    an article by Larry Peterson describing an general naming protocol
	(UNP)

Craig

PS: To get CCR, you should join ACM SIGCOMM.  You can FTP a postscript
copy of the application from sh.cs.net:CCR/appl.ps or drop me a note
with your US mail address and I'll send you a hardcopy.
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1989 12:47-EST
From:      CERF@A.ISI.EDU
To:        mckee@CORWIN.CCS.NORTHEASTERN.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: syntax of remote pathnames?
There was once a convention used for the form:
[domain name of host]<directory name> file name.extension

Vint Cerf
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 15:04:58 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.dcom.lans,comp.edu,comp.protocols.misc,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Campus Networking Philosophy and Planning


I'd like to tap into the collective wisdom of the net regarding
long-term network planning. I'm looking for examples of instruments
(polls, surveys, literature searches, etc.) that indicate what services
users in the near future (5 years from now) will expect from their
networked computing environment. This is mainly targeted at a campus
local area network, but such a LAN would also be integrated into wide
area networks (e.g. NSFnet or whatever replaces it).

I'm interested in...

o	What are the possible new network services that the networking
	community foresees coming in the next five to ten years?

o	What are the implications of those services for campus
	networking, in regards to bandwidth, topology, design, etc.?

o	What surveys, polls, etc. have been used at organizations in
	the past to determine what the user community's perceived,
	real, and foreseeable needs are?

Please email responses to the addresses below. I will be more than
happy to summerize for the net.

	jsloan%spots.wright.edu@relay.cs.net

	...!uunet!ncrlnk!wright!jsloan

	...!osu-cis!wright!jsloan

Thanks in advance, on behalf of the Network Planning Task Force.

Now, here's some background...

Wright State University is currently going through a planning process
to determine user needs, both known and potential, for a future local
area network. We already have a baseband Ethernet-TCP/IP based campus
LAN in place, with perhaps 175 or so nodes, ranging from VAXen, Suns,
terminal servers, PCs, etc. Growth in the past two years has been
high, but we expect growth over the next five years to be even
more steep.

We're interested in deploying a larger scale network, with a broader
scope then the usual IPC/telnet/ftp/email/NFS/X11 functionality (but not
at the expense of supporting these traditional services well). We're
interested in looking at (but are not committed to) integrating video,
telephone, voice, etc. along with data.

Some of the technical decisions are pretty straightforward, at least at
the administrative level. For example, fiber currently has no
competition for high bandwidth. You can argue for broadband, or perhaps
for future high-temperature superconductors. But in the near term,
fiber optic cable is it.

Mostly what we are interested in right now is establishing a networking
philosophy, and a vision of the future of networking to support it. To
do that, we need, in part, to know what services the users may expect to
have available in the future, and what the implications are for the
network.

To get the ball rolling, I can recommend the following resources as a
starting point to anyone interested in this topic.

_Campus_Networking_Strategies_, Caroline Arms, ed., Digital Press, 1988
	(an EDUCOM book containing case histories of campus LAN
	deployments at ten universities ranging from small liberal
	arts schools to very large multicampus institutions)

_Network_Requirements_for_Scientific_Research_, Barry M. Leiner,
	RFC1017, August 1987

_Critical_Issues_in_High_Bandwidth_Networking_, B. Leiner, ed.,
	RFC1077, November 1988

John Sloan  +1 513 259 1384         jsloan%spots.wright.edu@relay.cs.net
Wright State University Research Center   ...!uunet!ncrlnk!wright!jsloan
3171 Research Blvd., Kettering, OH 45420       ...!osu-cis!wright!jsloan
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-- 
John Sloan  +1 513 259 1384         jsloan%spots.wright.edu@relay.cs.net
Wright State University Research Center   ...!uunet!ncrlnk!wright!jsloan
3171 Research Blvd., Kettering, OH 45420       ...!osu-cis!wright!jsloan
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 17:47:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: syntax of remote pathnames?

There was once a convention used for the form:
[domain name of host]<directory name> file name.extension

Vint Cerf

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 20:34:53 GMT
From:      ted@ultra.UUCP (Ted Schroeder)
To:        comp.protocols.tcp-ip
Subject:   Re:  Interaction of wildcard bind() with services database

D. Jason Penney writes:
> We have some entries in our services database that are above 1024 and
> refer to services that are usually not in use.  When we call bind()
> with the requested port INADDR_ANY, bind() *can*, upon occasion, actually
> return a port that is listed in the services database.
 
> I think it is bug.  Suppose a booting system invokes two different
> services, both of which allocate both a predeclared port (from the
> services database) and a wildcard port.  In theory, it might never
> be possible for the system to boot properly because the wildcard
> bind allocates the second service's predeclared port.
 
> I have seen this problem on SunOS, VAX/VMS Wollongong (WIN) TCP/IP,
> and an unnamed System V Unix derivative.
 
> Is there any reason I shouldn't call up these vendors and tell them
> it's a bug?

This is perfectly reasonable behavior.  All you've told TCP/IP is to get
an unused port number.  Having a well-defined port in your services
table does not make the port "in use".  It only means that you've now
got a name to use "getservbyname" with.

If you really want to keep these ports reserved, then you'll have to have 
a listen hung on them or something.

      Ted Schroeder                   ted@Ultra.com
      Ultra Network Technologies      ...!ames!ultra!ted
      101 Daggett Drive           
      San Jose, CA 95134          
      408-922-0100

Disclaimer:  I don't even believe what I say, why should my company?

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 20:52:10 GMT
From:      jam@RADC-LONEX.ARPA (Joel A. Mussman)
To:        comp.protocols.tcp-ip
Subject:   Re:  Interaction of wildcard bind() with services database

>From: killer!rpp386!ditka!bucket!servio!penneyj@ames.arc.nasa.gov
>
>I want some opinions whether or not what I have been seeing should
>be regarded as a TCP/IP bug or a feature.
>
>We have some entries in our services database that are above 1024 and
>refer to services that are usually not in use.  When we call bind()
>with the requested port INADDR_ANY, bind() *can*, upon occasion, actually
>return a port that is listed in the services database.
>
>I think it is bug.  Suppose a booting system invokes two different
>services, both of which allocate both a predeclared port (from the
>services database) and a wildcard port.  In theory, it might never
>be possible for the system to boot properly because the wildcard
>bind allocates the second service's predeclared port.
>
>I have seen this problem on SunOS, VAX/VMS Wollongong (WIN) TCP/IP,
>and an unnamed System V Unix derivative.
>
>Is there any reason I shouldn't call up these vendors and tell them
>it's a bug?

	The only definition I have ever seen puts services below 1024.
	Bind() doesn't actually know what ports services reside at,
	and there probably isn't any simple way for it to find out.
	On UNIX applications automagically get a port above 1024 based
	on the idea that services are below 1024.  But that is a UNIX
	convention, not universal.  4.3BSD UNIX declares that supposedly
	non-privileged services should have port numbers above 5000,
	which of course would prevent bind() from getting to them on
	any normal machine (if you can support that many open sockets,
	and still maintain performance, can I come work for you?)

	You have no contest on your argument that this is a bug, and on
	two counts.

	First, TCP/IP as a protocol doesn't provide for service allocation.
	It just allows connections to be established.  Services are a
	soft flexible construct above the network protocol level.

	Second, the network by convention has placed all service port
	assignments below 1024.  If your's are above, they are non-standard
	network services, and therefore conflicts fall outside of the
	rules.  You can't have a bug if there aren't any rules to follow. 

Joel A. Mussman

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 20:56:20 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   April '89 CCR


Hi folks:

    Just wanted to let you know that the April issue of CCR may be of
interest to many of you.  The articles in it include:

    an article by Dave Borman of 500+ mbit/sec Cray TCP implementation

    an article by Bill Nowicki on making NFS run over complex Internet
	paths

    an article by Steve Bellovin on security problems with the TCP/IP
	protocol suite

    an article by Larry Peterson describing an general naming protocol
	(UNP)

Craig

PS: To get CCR, you should join ACM SIGCOMM.  You can FTP a postscript
copy of the application from sh.cs.net:CCR/appl.ps or drop me a note
with your US mail address and I'll send you a hardcopy.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 20:57:25 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip
Subject:   Whither TCP header prediction code?

I was under the impression that Van Jacobson finished the TCP header
prediction code some time after the tahoe release of 4.3 BSD.  Since I can't
find the code on ucbarpa, I'm beginning to wonder if it has been released at
all or not.

Could someone please clue me in to the current status of the TCP header
prediction code and perhaps give me a pointer to it, if it is sitting
somewhere on the Internet.

Thanks.

-bc
-- 
Bill Crews                        bc@halley.UUCP
(512) 244-8350                    ..!rutgers!cs.utexas.edu!halley!bc

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 89 22:08:34 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   re: Reliable Datagram Sockets

One might, however, achieve oxydullnormalcy by using the checksums which
are, after all, available in UDP's spec.  Granted, not _truly_ reliable since
lacking retransmission discipline; but possibly what's meant/wanted in
context--provided, of course, that anybody implements it....

(There's also the quibble that if you define by Form rather than by
Content, TCP/IP "is" a reliable datagram protocol, since it/they satisfy
the formal criterion for datagrammaticality of containing source and
destination addresses in each transmission unit, but I'm not really in
the mood for that one, so let it go.)

   cheers, map
-------

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Mar 89 12:35:45 -0500
From:      Mike Brescia <brescia@BBN.COM>
To:        Phil Dykstra <phil@brl.mil>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Do Butterflies Live Forever?

     If you run traceroute through the Buttergates in the core, you will
     notice that they do not decrement the IP TTL.  This is not a very
     good idea.

Phil Wood raised this in a msg dated 2/10, which appears not to have gotten a
(broadcast) answer.  The short of it is that the Butterfly gateways claim to
decrement the TTL, and claim to discard packets received with TTL=0, but do
not claim to avoid sending packets with TTL=0.  While they do not yet conform
to RFC1009 in this detail, the Butterflies will not cause a packet to live
forever.

If you want TTL to be a measure of 'how many gateways may touch this packet',
then one with TTL=1 will pass through one gateway.  I don't view this as
refusing to comply with RFC1009, but attempting to explain the thinking behind
the current implementation.  We made our design decisions before 1009 was
being discussed.  In the interests of uniformity, this is the sort of detail
that should be included in protocol definitions.

I hope this explains your traceroute results.

Mike Brescia
Gateway Development Group, BBNCC

------- Forwarded Message

Date: Fri, 10 Feb 89 11:17:35 MST
From: "C. Philip Wood" <cpw%sneezy@lanl.gov>
Message-Id: <8902101817.AA03292@sneezy.lanl.gov>
To: tcp-ip@sri-nic.arpa
Subject: TTL

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

(on 26.0.0.90)

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

------- End of Forwarded Message
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 89 10:27:43 GMT
From:      pete@sun360.Online.Nixdorf.De (pete delany)
To:        comp.protocols.iso,comp.std.internat,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Layer Encapsulation in OSI


In article <2028@cpoint.UUCP>, martillo@cpoint.UUCP (Joacim Martillo) writes:
> Path: nixctc!unido!mcvax!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!cloud9!jjmhome!cpoint!martillo
> From: martillo@cpoint.U> > 
> I see this situation all the time.  Everytime someone wants to
> incorporate some new idea into OSI which actually give some reason to
> switch from TCP/IP to OSI, it gets shot down at the committee level. 
> Now I understand why the best standards are those which were ad hoc
> standards first, and only much later standardized by the international
> committees.  Any comments?

I've been hacking on OSI code for the past few years, and I also doubt
the value of spending a lot of money trying to get people to accept these
standards dictated by the central committees.  Clearly, the problem is 
with the 'authorities' participating in the market.

Pete Delaney - Nixdorf UCC	| pete@NIXCTC.DE		Prefered Addr
Loffel Strasse 3		| pyramid!nixctc!pete		UUCP from Calf
7000 Stuttgart 70		| pete@RELAY.HUJI.AC.IL		Backup Address
West Germany			| Phone: +49 (711) 7685-128

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 89 16:31:24 GMT
From:      Jim_Sweeton@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Internetworking Seminar


 
 
 INTERNETWORKING SEMINAR--APRIL 17-18,1989
 Sponsored by the National Science Foundation
 and the Merit Computer Network
 --------------------------------------
 OVERVIEW
 
 This seminar will provide a thorough introduction to the networking
 environment. This day and a half seminar will give you solid answers
 to questions you have about connecting to the National Science
 Foundation's national network, NSFNET.  NSFNET is part of the general
 Internet and provides excellent connection to the nation's government
 and academic computing resources.
 
 In the opening session on Monday, April 17, you will get an overview
 of the potential benefits for your campus. you will also have an
 opportunity to meet directly with mid-level representatives from
 institutions already connected to the NSFNET and to attend informal
 question and answer sessions.
 
 In Monday's afternoon session, practical day-to-day issues will be
 addressed by experienced computer network professionals. These
 issues include mail and campus postmastering and domain management.
 
 A vital part of network operations is the information services
 component. In Tuesday's morning session, experts in the area of
 documentation and on-line databases will survey these services
 and highlight the key issues.
 
 The Network Operation Center (NOC) is another important aspect
 of NSFNET. In the final session of the seminar, you will get an
 overview of the solutions to problems which arose in setting up a
 NOC for this national network. Scheduling and network management
 issues will also be addressed in this session.
 
 WHO SHOULD ATTEND?
 
 This seminar is ideal for campus liaisons and for those who help
 end users. Anyone interested in learning more about the NSFNET and
 about the potential benefits for campuses connected to this
 national network will be interested in attending.
 
 SEMINAR LOCATION
 
 We will meet at the Radisson Suite Resort on Hilton Head Island.
 The island is located on the world-famous South Carolina coast.
 Activities available include tennis,golf,sailing,sightseeing,
 shopping, and wonderful restaurants.
 
 Hilton Head is located 95 miles south of Charleston, SC and 35
 miles north of Savannah, GA. Traveling south on i-95, you should
 take exit 28 (SC 462) to Hilton Head Island. Traveling north on
 i-95, you should take exit 5 (Hardeeville, SC,17 North). Highways
 to Hilton Head are well marked from these exits.
 
 TRAVEL ARRANGEMENTS
 
 Piedmont Airlines is offering substantial discounts when tickets
 are purchased from Travel Diplomat, 800-445-0022 (outside of
 Michigan) or 616-329-0080 (collect within Michigan). The Radisson
 Suite Resort has reserved a block of rooms for the seminar at
 a special rate. Make your own room reservations and payment
 arrangements directly with the hotel by calling 803-686-5700.
 
 To be eligible for these discounts, you must indicate that you
 will be attending the National Science Foundation Network seminar.
 
 REGISTRATION
 
 To enroll in the Internetworking Seminar, send an electronic
 message to: nsfnet-info@merit.edu
 
 You can also call 800-66-MERIT. Mail payments to: Merit/NSFNET,
 1075 Beal, Ann Arbor, MI 48109-2112.
 
 The registration fee is $100 and must be postmarked by April 1.
 If there is room to accommodate late registrations, an additional
 $25 fee will be assessed. The registration fee includes coffee
 breaks, lunch on April 17, and seminar materials.
 
 Cancellations received after April 12 and no-shows will be charged
 the full fee.
 
 Please make check or money order payable to the University of
 Michigan Merit Computer Network. We cannot accept university
 purchase orders.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 89 17:35:45 GMT
From:      brescia@BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Do Butterflies Live Forever?


     If you run traceroute through the Buttergates in the core, you will
     notice that they do not decrement the IP TTL.  This is not a very
     good idea.

Phil Wood raised this in a msg dated 2/10, which appears not to have gotten a
(broadcast) answer.  The short of it is that the Butterfly gateways claim to
decrement the TTL, and claim to discard packets received with TTL=0, but do
not claim to avoid sending packets with TTL=0.  While they do not yet conform
to RFC1009 in this detail, the Butterflies will not cause a packet to live
forever.

If you want TTL to be a measure of 'how many gateways may touch this packet',
then one with TTL=1 will pass through one gateway.  I don't view this as
refusing to comply with RFC1009, but attempting to explain the thinking behind
the current implementation.  We made our design decisions before 1009 was
being discussed.  In the interests of uniformity, this is the sort of detail
that should be included in protocol definitions.

I hope this explains your traceroute results.

Mike Brescia
Gateway Development Group, BBNCC

------- Forwarded Message

Date: Fri, 10 Feb 89 11:17:35 MST
From: "C. Philip Wood" <cpw%sneezy@lanl.gov>
Message-Id: <8902101817.AA03292@sneezy.lanl.gov>
To: tcp-ip@sri-nic.arpa
Subject: TTL

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

(on 26.0.0.90)

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

------- End of Forwarded Message

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 89 21:30:56 GMT
From:      matthews@alux2.ATT.COM (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   NFS Performance through Routers

Last week we replaced a DEC Lan Bridge with a new Proteon P4200 router
to create a local subnet for our building.  Ever since, things have
been running extremely slow for the people that get their CAD software
through our gateway.  They do rely heavily on huge CAD executables that
get sent through the gateway.  I have been looking into this for quite
some time and I am finally posting a message here to see what other
people have done in similar situations.  What I have found is that
default mounts in NFS make reads and writes that are 8192 bytes long.
The kernel gets these and then in turn fragments these requests into up
to 9 UDP packets.  If the proteon discards even one of these packets,
all 9 of them have to get retransmitted.  I went around and changed all
of the NFS mounts to do 1024 byte reads and writes.  This seemed to
improve things a little.  Another thing that I have noticed is that we
are getting extremely high collision rates on the SUNS.  They add up to
about a million and a half for the past week.  Someone told me that the
SUNS don't abide by a standard that says they should wait 10
milliseconds between each packet they send to give others a chance to
transmit.  They told me they only wait 1 millisecond, if that.   Could
this be causing alot of collisions?  There are only around 15 Sun
clients and one server sitting on each of two bridged ethernets in the
building where they are having all of the problems.  In the main
building we have things set up the same way with collisions adding up
to around 40,000.  There does seem to be alot of broadcasting going on
that ethernet that could cause this.  There is a problem stemming from
the fact that older versions of UNIX are trying to forward IP broadcast
packets.  When these hosts receive a broadcasted RIP packet addressed
to 128.94.255.255, they think it's a packet destined to a specific
machine and they then try and forward it.  For every such packet, an
ARP request is broadcasted on the ethernet.  There are about 16
machines running the old network software and 5 routers generating up
to 5 rip packets every 30 seconds.  I believe that added up to around
28,000 broadcasts per hour.  Temporarily, I answered these ARP requests
and pointed them to a device that would ignore them, but the network is
still slow.  Is there anything wrong with responding to these ARP
requests with an ethernet address that doesn't really exist on that
network.  Then the machines running the old network software would just
forward it into a black hole.  Am I thinking right or would this cause
problems?  What will the DEC Lan Bridges do with an ethernet packet
when it has no idea which side that ethernet device is really on.  Will
every bridge throughout the network pass this packet everytime it's
sent?

Last night we tried to configure an extra ethernet board on the
fileserver that houses all of the CAD software and connect it to the
other ethernet cable to give them back some speed.  All we did was
uncomment the ie1 interface in the kernel config file, recompile the
kernel and reboot.  We didn't change any of the /etc/*rc* files at
all.  When the sun came back up, all of the old NFS mounts on the
clients just timed out.  The NFS deamons wouldn't service any NFS
requests.  I was able to use telnet and rlogin to connect to hosts on
either side after manually ifconfig'ing the new ie1 interface.  I gave
up and tried it on another fileserver.  It did the exact same thing.
The thing that doesn't make sense is that the only thing we did was add
one ethernet device to the kernel and then nothing worked the way it
used to.  We rebooted on the old kernels and everything was back to
normal. We called SUN but they didn't seem to know what the problem
was.  Has anyone else ever encountered such problems?

We are eventually going to move some of that software to servers in
that building so that they aren't pounding on the gateway.  I wasn't
aware that the proteon had such little bandwidth compared to a LAN
bridge.  How on earth can they go from Pronet-80 to ethernet when they
can't come close to handling ethernet's full 10 megabits/s?  What
percent of 10 mbits/s can a proteon really route from one ethernet to
another?  Has anyone done some real life performance testing?

What other things could I do to optimize NFS traffic?

If there are things that I am wrong about, please let me know.  This
has been a frustrating week to say the least.  If anyone could spare a
few minutes on the phone, please e-mail me your phone number.  I'd
really appreciate it.
				John Matthews
				ulysses!aloft!matthews@princeton.edu
				matthews@aloft.att.com
				matthews@research.att.com

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 89 04:05:06 GMT
From:      kline@tuna.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Performance through Routers

> There is a problem stemming from
> the fact that older versions of UNIX are trying to forward IP broadcast
> packets.  When these hosts receive a broadcasted RIP packet addressed
> to 128.94.255.255, they think it's a packet destined to a specific
> machine and they then try and forward it.  For every such packet, an
> ARP request is broadcasted on the ethernet.  There are about 16
> machines running the old network software and 5 routers generating up
> to 5 rip packets every 30 seconds.  I believe that added up to around
> 28,000 broadcasts per hour.  Temporarily, I answered these ARP requests
> and pointed them to a device that would ignore them, but the network is
> still slow.  Is there anything wrong with responding to these ARP
> requests with an ethernet address that doesn't really exist on that
> network.

Yow! Be careful with your broadcast address! If you have old Suns, they'll
be using a zero's broadcast (128.94.0.0). The p4200 by default will use
ones broadcast. I'm not surprised you're getting 28000 broadcasts an hour
and all those collisions. Mixing broadcast addresses is a good way to get
an ethernet meltdown, because exactly the behavior you describe happens.

Go to the same broadcast address everywhere on your net and I bet a lot
of your problem will go away. Since you're running old Suns, which don't
give you a choice, I suspect you'll have to change everything to zero's
broadcast.

Hope this helps.

-----
Charley Kline, University of Illinois Computing Services
kline@tuna.cso.uiuc.edu
{uunet,seismo,pur-ee,convex}!uiucdcs!uiucuxc!kline

"Flaring high or flaring early makes the little prop tips curly."

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Mar 89 12:46:56 PST
From:      satz@cisco.com
To:        Mike Brescia <brescia@BBN.COM>
Cc:        Phil Dykstra <phil@brl.mil>, tcp-ip@sri-nic.arpa
Subject:   Re: Do Butterflies Live Forever?
Mike,

If the Butterfly Gateways support LSR or SSR and if I accidently screw up
my source routing, will the packet ever die? In other words, I am asking if
I can construct a source routed packet within the DDN which could live
forever.

Greg Satz
cisco

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 89 08:14:40 GMT
From:      dlr@daver.UUCP (Dave Rand)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Performance through Routers

In article <633@garcon.cso.uiuc.edu> kline@tuna.cso.uiuc.edu (Charley Kline) writes:
>> the fact that older versions of UNIX are trying to forward IP broadcast
>> packets.  When these hosts receive a broadcasted RIP packet addressed
>> to 128.94.255.255, they think it's a packet destined to a specific
>Yow! Be careful with your broadcast address! If you have old Suns, they'll
>be using a zero's broadcast (128.94.0.0). The p4200 by default will use
Please forgive my ignorance, but I have noticed this as well. Why do
machines ARP for broadcast IP addresses?


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 89 18:25:28 GMT
From:      MAP@LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   ARP for the broadcast address


   Date: 19 Mar 89 08:14:40 GMT
   From: vsi1!daver!dlr@ames.arc.nasa.gov  (Dave Rand)

   [Dave asks:]  Why do machines ARP for broadcast IP addresses?

Because they have two bugs!  First, they think they should be
forwarding packets (as if they were a gateway, even though they
aren't).  Second, they have a mistaken impression of the broadcast
address and so don't recognize it and think it's just another host.
This is because one of the more popular bases for networking code came
out during a time when the spec on broadcast addresses was in flux.

The way the problem manifests itself is that when one host broadcasts
a packet using the right address, any hosts with these two bugs will
believe it's for a specific host and attempt to forward there.  They
will ALL send out an ARP request for this address AT THE SAME TIME!
This gives lots of collisions on these hosts.  Lots of older systems
work this way.

The best way to keep this traffic down is to find these systems and
upgrade them (provided the vendor supports up-to-date code).  The
second best (and often more practical) approach is to use a non-spec
broadcast address that all your hosts will at least recognize.  The
spec address for broadcast is ones, what you'll probably find is that
the deficient hosts only take zeros but that the "correct" hosts can
be configured to use this as well.

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 89 18:54:38 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: Do Butterflies Live Forever?


      Mike,

   I am not convinced that hanging your hat on rfc1009 provides an out
(see page 2 of rfc791, expanded upon on page 14 and repeated on page
30). The key point is (as stated on page 2) "If the time to live reaches
zero before the internet datagram reaches its destination, the internet
datagram is destroyed."  Since this field must be decremented as a part
of the packet processing (also stated in rfc791), you need to check
whether the outgoing TTL has reached zero.

				Later,
				    Bob

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 89 20:46:56 GMT
From:      satz@CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Do Butterflies Live Forever?

Mike,

If the Butterfly Gateways support LSR or SSR and if I accidently screw up
my source routing, will the packet ever die? In other words, I am asking if
I can construct a source routed packet within the DDN which could live
forever.

Greg Satz
cisco

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 89 22:32:39 GMT
From:      gross@SCCGATE.SCC.COM (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  IETF RFC Draft

> I'm looking for a copy of the forthcomming IETF RFC document.  If you have 
> please to be so kind as to mail it my way... Thanks much!

Thomas,

The Internet Engineering Task Force has been the spawning ground for
quite a few RFCs, so it is not clear what you mean by the `IETF RFC
document'.  However, I suspect what you want is the Host Requirements
document, currently in final editing stages by the IETF HR Working Group.

Bob Braden at ISI (braden@isi.edu) is the chair of that group and the editor 
of this important document.  The latest draft is close to 180 pages, so the
preferred method of retrieval is FTP.  If this is the document you are 
looking for, drop a note to Bob directly for the host and file names for
anonymous FTP.

Phill Gross
Corporation for Natioanl Research Initiatives

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 00:02:50 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TN3270 for HP3000

Morning all,
		Does anyone have knowledge of TN3270 being currently available
for those H/P 3000's running the Wollongong code? I know that TWG came out
with their TN3270 for version 5.0 of VMS but I'm curious if they have plans
to port it to some of the older platforms that they have been supporting. Any
inside knowledge that anyone could share would be greatly appreciated.
			Thanks in advance,
					  Chris VandenBerg
					  ACC
					  (chris@salt.acc.com) or 805-967-3964

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 02:47:46 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Performance through Routers

Sun NFS does not violate any standard.  Now and again when problems
like this come up somebody floats this rumor that they somehow
transmit "too fast".  It just isn't true.  It is true that NFS pushes
networking technology very hard, but if it doesn't work something on
your network is broken.  In particular, there is no standard that says
something should wait 10 milliseconds between transmissions.  If two
systems try to transmit at the same time, there is a pattern of random
exponential backoff.  But if only one host is sending, you may see as
little as 9.6 microsecond (I think -- this is from memory) between
packets.  This stuff is done by the Ethernet controller chip, and Sun
uses the same chips as everybody else.

I agree with the other response: you've got to find a way for all
machines that do broadcasts to use an address that all machines on the
network can cope with.  In my opinion the safest is 128.92.0.0.
Presumably there will be a way to set all machines to use this as
their broadcast address.  Responding to ARP's with a bogus Ethernet
address is a standard technique, and I don't know of anything wrong
with it, but it's better to set things up so that you don't need to do
that.  You should also try setting ipforwarding to 0 in all of your
unix kernels:
   adb -w /vmunix
   ipforwarding?W 0
   ^D
This will cause the systems not to attempt to forward stray packets.
They may however still send ICMP unreachables back to the source.
However this is far better than an ARP, because it isn't a broadcast.
If you're willing to do a bit more work in adb on your Sun's, you
can make them accept the correct broadcast address.  Unfortunately
I don't have the exact offset, but if you do  
   adb /vmunix
   ipintr?i
and keep hitting CR, you will eventually find a section of code
that calls if_ifwithaddr, compares an address with -1 (or it might
show as 0xffffffff), and then calls ip_forward.  You want to change
the comparison with -1 to compare with the actual broadcast 
address used on your network.  This advice is Sun-specific.

Now, as to the rsize and wsize settings.  Certainly if a gateway or
bridge is dropping packets, you may do better off by using values
smaller than the original 8192 default.  However 1024 may be going a
bit too far.  Most Ethernet interfaces can handle two packets in a
row, so 2048 would make sense.  It does help performance to use as
large a number as your hardware can handle reliably.  We are able to
use 2048 through all of the bridges and routers that we've tried.
From what I know of Proteon's hardware, I'd be very surprised if they
couldn't handle at least that much.  What is critical is how much
buffering there is on the Ethernet interface.  Newer interfaces often
have enough that you can use the full 8192.  We have no problem with
8192 with cisco routers that use their new MCI Ethernet interfaces.
It's fairly easy to test.  Try changing the value and then doing some
operation that generates a lot of NFS traffic.  Do "nfsstat" before
and after the test.  Look at "retrans" and "timeout" compared to the
total.  A couple of percent is OK.  My normal test is 
"cp /server/usr/lib/* /dev/null" Be sure you specify "intr" as one of
the mount options, so you can abort the test if something goes wrong.
(In fact, I would always specify "intr".  I don't know why it isn't the
default.)

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 09:59:44 GMT
From:      4006_232@uwovax.uwo.ca (Mike Bennett)
To:        comp.protocols.tcp-ip
Subject:   Damage Estimates of the Worm Attack


To the Net:
	We are doing a paper on the econimic       nomic effect
of last November's worm attack on the Internet.
Rumour has it that the cost of the attack was about
a hundred million dollars. Can anyone verify that figure?
	Also, if anyone has oersoonal           personal examples of 
real hjard    ars dship caused by non-availability of the     a computer
disabled by the worm, could you please forward the stories to me?
Also, examples of losa t data, financila    al costs incrued by the            curred by
the      attack would be welcome. We will be happy to post the
final results to the community.

The purpose of our research is to attempt to place a dololar    lar  
and personal cost to such attacks that could eventually be
factored into risk analysis of viruses. These is no other
purpose for this request; please change names etc if you wish.
			Thanx in advance
			Mike Bennett, PhD                   Prof. M Michael Bennett

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 13:10:27 GMT
From:      paone@aramis.rutgers.edu (Phil Paone)
To:        comp.protocols.tcp-ip
Subject:   IP Qustion


I have a question (which based on my limited knowledge might be
misstated) regarding the use of the Internet Protocal portion of
TCP/IP.  Is a special version needed to run IP over standard serial
devices such as modems or direct connects?  

			Thanks,
			Phil Paone
-- 
Phil Paone
attmail!ppaone
!rutgers.edu!topaz.edu!ppaone
paone@topaz.rutgers.edu

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 14:25:11 GMT
From:      jos@idca.tds.PHILIPS.nl (Jos Vos)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat
Subject:   Re: TCP/IP versus OSI

In article <146@mirsa.UUCP> huitema@mirsa.UUCP (Christian Huitema) writes:
:From article <2145@cpoint.UUCP>, by martillo@cpoint.UUCP (Joachim Carlo Santos Martillo):
:>                    Round 2 in the great TCP/IP versus OSI Debate
:< .... 
:
:I always thought that the date for April fools was April 1st, not March 15th..

I think you're wrong: it's obviously March 16th... :-(

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 15:31:19 GMT
From:      ken@GVAX.CS.CORNELL.EDU (Ken Birman)
To:        comp.protocols.tcp-ip
Subject:   FINGERLAKES 89 (LIFE BEYOND TCP/IP...)

I am taking the liberty of posting this to protocols.tcp-ip
because the group is such an active one and seems to include
a wide range of distributed computing "consumers".  

 FINGERLAKES `89: AN ADVANCED COURSE ON DISTRIBUTED SYSTEMS
             ITHACA, NEW YORK, JULY 10-20 1989


     This is to announce a short course on distributed  sys-
tems that will be held next summer, at Cornell University.

     The field of distributed computing is undergoing  rapid
changes with the introduction of new programming  methodolo-
gies and the migration of next-generation communication tools
and protocols from the laboratory into practice.  The course
is aimed at  graduate students  and industrial practitioners
with an interest in tracking these important developments.

     The course will consist of 10 days of lectures  on  the
topics  shown below.  It is based on The Arctic `88 Advanced
Course on Distributed Systems, which  was  held  in  Tromso,
Norway.   Attendees   are   assumed  to  have  a  background
equivalent to  that  of  a  second  year  graduate  student,
including familiarity with basic issues in operating systems
and networking.  Advance readings and a copy of a  forthcom-
ing textbook, coauthored by the lecturers, will be provided.
The tuition of $1250 ($750 for full-time students)  includes
course  materials,  breakfast and lunch, and fees for social
events.   Some  student  scholarships  will  be  awarded  to
deserving applicants.  Attendance is limited to 200.

                      COURSE OUTLINE
    Introduction
        Survey of issues in distributed computing.
    Communication
        Interprocess communication
        Remote procedure call
    Naming and security
        Naming, authentication and cryptography
        Protection
    Data Storage
        File Systems
    Transactions
        Transactional mechanisms and applications
        Transactional theory in object-oriented systems
    Replication
        Transactional data replication
        Reliable broadcast protocols
        Exploiting virtual synchrony
    Real-time systems
        Abstractions for simplifying distributed algorithms
        Realtime databases and concurrency control
        Distributed control mechanisms
    Methodology
        Derivation of distributed programs
        High-level specifications of distributed programs
    Distributed Systems Architecture
        The Advanced Networked Systems Architecture
    Panel discussion and conclusions

     For each area, the lecturers will discuss  the  current
state of the art, review relevant systems work, and point to
directions for future research.

     The course will be structured as a series of daily lec-
tures  with several afternoon discussion sections.  The dis-
cussions will permit smaller groups of attendees to interact
directly  with the lecturers, either to focus on issues that
arise out of the lectures  or  to  pursue  other  topics  of
interest  to  the  group.   The course closely parallels the
textbook.

                      THE LECTURERS

     The Fingerlakes 89 lecturers are internationally  known
researchers  whose  interests span the full range of distri-
buted computing.

     Kenneth P. Birman  is an Associate  Professor  of  Com-
puter Science at Cornell University, where he heads the ISIS
Project.  His research focuses on methods  for  constructing
fault-tolerant distributed software that exploits replicated
data, distributed execution and concurrency.  He is also  an
Associate  Editor  of  the ACM Transactions on Computer Sys-
tems.

     Susan Davidson is an Assistant Professor in the Depart-
ment  of  Computer and Information Science at the University
of  Pennsylvania.  Her  research  interests  include  fault-
tolerance,  distributed  systems, database systems and real-
time systems.

     Andrew  J.  Herbert   heads   the   ANSA   Project,   a
Cambridge-based  industry  consortium developing an Advanced
Networked Systems Architecture.  Prior to joining  ANSA,  he
headed the Mayflower project and was a developer of the Cam-
bridge Ring system in the Computer Laboratory  at  Cambridge
University, where he is a Fellow of Wolfson College.

     Keith Marzullo is an Assistant  Professor  of  Computer
Science  at Cornell University.  His research focuses on the
development of large scale fault-tolerant  distributed  com-
puting  applications and on realtime applications.  Prior to
joining Cornell in 1986, he developed the  JASMINE  software
control  system  at  XEROX  SDD  and a clock synchronization
facility for the XEROX research internet.

     Sape J. Mullender is head  of  the  Amoeba  distributed
systems  project  at  the Centre of Mathematics and Computer
Science in Amsterdam.   He  is  particularly  interested  in
high-performance  distributed  computing  and  the design of
scalable fault-tolerant  services.   He  is  also  concerned
about  organization  and  protection  in distributed systems
that can span a continent.

     Roger M. Needham is Professor and  Department  Head  of
the Computer Laboratory at Cambridge University and a Fellow
of the Royal Society.  He  has  contributed  extensively  to
every  aspect of distributed computing and has most recently
been interested in computer protection and security.

     Mahadev Satyanarayanan is  an  Assistant  Professor  of
Computer   Science   at   Carnegie  Mellon  University.   He
currently leads an effort to build a distributed  file  sys-
tem,  Coda, that is scalable, secure and highly resilient to
failures.  He has contributed in the past to the design  and
implementation of the Andrew file system, a large-scale dis-
tributed file system  now in use at CMU and other sites.

     Michael D. Schroeder is a member of the research  staff
at  Digital's Systems Research Center in Palo Alto, Califor-
nia.   His  particular  interest  is  discovering  practical
structures  for  distributed systems.  Over the years he has
worked on computer protection and security, encryption-based
authentication  protocols,  computer message systems, naming
in large networks, remote procedure  call  performance,  and
various distributed file systems.

     Fred B. Schneider is an Associate Professor of Computer
Science  at  Cornell  University.  His research is primarily
concerned with methodologies  for  designing  and  reasoning
about  concurrent  programs.  He is an editor of Distributed
Computing, Information  Processing  Letters,  and  Springer-
Verlag Texts and Monographs in Computer Science.

     Sam Toueg is an Associate Professor of Computer Science
at  Cornell  University.   His  research  interests  include
fault-tolerance, distributed systems, realtime  systems  and
and distributed databases.

     William E. Weihl is an Associate Professor of  Computer
Science  at  the Massachusetts Institute of Technology.  His
research interests include concurrency  control  and  fault-
tolerance,    programming   methodology,   and   programming
languages.  He is one of  the  principal  designers  of  the
Argus and Mercury systems developed at MIT.

			THE LOCATION

    The course will be held on the Cornell University campus,
situated in the beautiful Fingerlakes District of Upstate New
York.  Cornell  is located  on a 40-mile long lake in an area
known for  a  wide range of  summer sporting and recreational
possibilities.  Participants will have an opportunity to swim
in local gorges beneath waterfalls and in the lake, sample the
local wines, and visit Corning Glass, which maintains a world
renowned glass museum and offers tours of the Steuben Crystal
manufacturing center.  Weather in mid-July is typically  warm
and dry.  Inexpensive on-campus  accomodations are available.

    The  Fingerlakes area  is a  well known and popular summer
resort region for New York State.  Additional  information  is
available  for  particpants who will be accompanied  by  other
family members.

			  SCHOLARSHIPS

    The course will offer partial or full tuition scholarships
to a small number of full time students.  Selection   will  be
based on the number of applicants and the financial  status of
the course (the number of paying attendees).  More information
is available from the address given below.

			  DEADLINES

    Although registrations will be accepted until the course
reaches its enrollment limit, a $50 late fee will be charged
after April 1.  Early registration is encouraged.

FOR MORE INFORMATION
        Fingerlakes `89
        Department of Computer Science
        4130 Upson Hall
        Cornell University
        Ithaca, New York 14853

E-mail: fingerlakes89@cs.cornell.edu

Phone:  Margaret Schimizzi
        (607)-255-9198

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 17:50:01 GMT
From:      larry@hcr.UUCP (Larry Philps)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip support for Sun 386 Sun OS 4.01

In article <469@eagle_snax.UUCP> geoff@eagle_snax.UUCP (Geoff Arnold @ Sun ECD - R.H. coast near the top) writes:
>In article <8903060609.AA21488@ucbvax.Berkeley.EDU> bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) writes:
>>Has anyone gotten slip to work with Sun OS 4.01 (object only) on a 386i
>>machine (or any other Sun machine under OS 4.01)?
>> ...
 
>In SunOS 4.0 et seq, the TTY driver is Streams-based. (I think I'm
>supposed to capitalize that "Streams", or maybe it should be "streams" 
>or "STREAMS". Oh, well...) This means that SLIP has to be rewritten as
>a Streams module, and "slattach" has to push (and eventually pop)
>it. It's planned for the next release of PC-NFS (no date yet). Note
>that Sun only officially endorses SLIP for PC-to-Sun (or whatever)
>connectivity.

This has already been done by Rayan Zachariassen at the U of Toronto for
SunOS 4.0.  It is available for anonymous ftp from neat.ai.toronto.edu
(128.100.1.65).  I don't remember what the name of the file(s) are.  There is
lots of stuff in that pub directory.  Its availability was announced in the
comp.archives group.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 19:09:05 GMT
From:      bob@tinman.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Performance through Routers

In article <Mar.19.21.47.45.1989.5916@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
   ...You should also try setting ipforwarding to 0 in all of your
   unix kernels:
      adb -w /vmunix
      ipforwarding?W 0
      ^D
   This will cause the systems not to attempt to forward stray
   packets...

...in fact, none at all!  Note that Rutgers uses lots of dedicated
little boxes, not UNIX beasties, as IP routers.  The original
question, which included a description of an attempt to install a
second Ethernet interface in a Sun backplane, sounded as if they
planned to use the Sun as an IP router between two Ethernets.  In this
case, you'd want to leave ipforwarding turned on, at least in the
kernel of the Sun to be used as a router.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 20:51:23 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Performance through Routers

You're quite right.  I meant you should set ipforwarding to 0 on
machines that aren't gateways.  If you do it on a machine that is a
gateway, it will stop gatewaying.  You get broadcast storms when every
machine on your network tries to ARP the broadcast address.  If you
turn ipforwarding off on the machines that aren't actually gateways,
then at least you cut down the number of machines participating in the
storm to just the gateways.  On most networks this is a very
worthwhile gain.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 21:38:07 GMT
From:      kumar@hpindwa.HP.COM (Krishna Kumar)
To:        comp.protocols.tcp-ip
Subject:   Source Quench & Jacobson's Alg.

Hello,

With more and more implementations adopting Van Jacobson's source-based
congestion avoidance and control mechanisms, is it likely that in the near
future gateways will stop sending ICMP source quench messages when they
discard packets? 

There seem to be conflicting documentation on sending ICMP source quench
messages in the first place.

RFC 792 [Postel: Internet Control Message Protocol, Sep '81] states: "If a 
gateway discards a datagram, it *may* send a source quench message to the
internet source host of the datagram."

RFC 896 [Nagle: Congestion Control in TCP/IP Internetworks, Jan '84] states:
"The present ICMP standard specifies that an ICMP Source Quench message
*should* be sent whenever a packet is dropped, and additionally may be sent
when a gateway finds itself becoming short of resources. There is some
ambiguity here but clearly it is a violation of the standard to drop a
packet without sending an ICMP message."

RFC 1016 [Prue and Postel: The Source Quench Introduced Delay (SQUID),
July '87] states: If a gateway discards a datagram, it *may* send a source 
quench message to the Internet source host of the datagram." (referring
to RFC 792). It goes on to suggest, "We propose gateway IP nodes start
SQing before the node is flooded at a level we call SQ Keep but forward
the datagram.... Once the gateway starts sending SQs it *should* continue
to do so until the queue level goes below a low water mark level..."

Can anyone shed some light on these issues? Any comments or suggestions?

Thanks,

Krishna Kumar,
Business Networks Division, HP.
(kumar@hpindwa.HP.COM)

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

(Disclaimer: All opinions are my own and not my employer's.)

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 89 22:14:08 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   new Vendors Guide available from the NIC

The February 1989 edition of the DDN Protocol Implementation and Vendors
Guide is now available from the DDN Network Information Center (NIC).

The Vendors Guide is a guide to implementations and products associated with
the DoD Defense Data Network (DDN) suite of data communication protocols,
notably TCP/IP and OSI implementations.  It is published for informational
purposes only by the DDN Network Information Center at SRI International on
behalf of the Defense Communications System Data Systems (DCS DS) Office to
assist those who wish identify existing implementations or products
incorporating the DoD protocols.

You may obtain an ASCII text version of the Vendors Guide by FTP or in
hardcopy form from the NIC. Using FTP, connect to the SRI-NIC.ARPA host, login
as "anonymous" with a password of "guest" and retrieve the file
"netinfo:vendors-guide.doc". For hardcopy information contact the NIC by
electronic mail (nic@sri-nic.arpa) or by telephone (800-235-3155 or
415-859-3695).  
-------

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 00:47:00 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Internet Requirements Seminar


ACE will host an Internet Requirements Seminar, May 1-2 in Monterey,
California. The speaker is Bob Braden of USC-ISI. Bob will discuss
RFC 1009 entitled "Requirements for Internet Gateways" and a (soon
to be published) RFC called "Requirements for Internet Hosts". Drop
me your postal address or call ACE at 415-941-3399 for more info.

Ole
-------

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Mar 89 11:08:18 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        pcip@udel.edu, tcp-ip@sri-nic.arpa
Subject:   NCSA Telnet with TN3270 support now Available.
3/20/89
A new version of NCSA Telnet with TN3270 support is now
available via anonymous ftp from omnigate.clarkson.edu (128.153.4.2)
from the directory   /pub/ncsa2.2tn

This is the readme file from that directory.

Version 2.2TN is an upgraded copy of version 2.2C with support
for a single Tn3270 session concurrent with simultanous
non-3270 telnet sessions. A full description of new features
and bug fixes are included at the end of this notice.
A similar version without the 3270 support is also included.
It has all the bug fixes and other enhancements as version 2.2TN
but without the 3270 support, its called version 2.2D.

The following files are available:
/pub/ncsa2.2tn

-rw-r--r--  1 bkc        613888 Mar 20 17:57 ncsabin.tar
-rw-r--r--  1 bkc        435892 Mar 20 18:00 ncsabin.tar.Z
-rw-r--r--  1 bkc       1850880 Mar 20 17:56 ncsasrc.tar
-rw-r--r--  1 bkc        703841 Mar 20 18:03 ncsasrc.tar.Z
-rw-r--r--  1 bkc           633 Mar 20 18:17 readme
-rw-r--r--  1 bkc        125824 Mar 20 17:58 telnet.doc
-rw-r--r--  1 bkc         54153 Mar 20 17:59 telnet.doc.Z

ncsabin.tar.Z	contains the binaries for tn3270.exe, telbin.exe
		telpass.exe, ftpbin.exe, tncpp.exe, a sample
		config.tel and various 3270 support files.
		tn3270.exe is identical to telbin.exe except that
		it has 3270 datastream support.

ncsasrc.tar.Z	contains the source for all programs, requires
		turbo C 2.0.

readme		this file

telnet.doc.Z	contains updated documentation. This is version 2.2C
		documentation with additional margin comments
		describing new features.

Note!: Both tar files are binary copies of PC source. If you untar
the source on a unix system, you will have to strip off trailing
CR's and a ^Z at the end of each file. Also, the commonly available
tarread.exe can not extract binary images, it will extract the
source correctly, but should not be used to extract the executables.

Omnigate is no longer providing packet drivers, you can get them
from sun.soe.clarkson.edu:/ka9q/drivers.exe Be advised that
the old SLIP8250 driver has a bug and will not work with this 
version of telnet.

This software is available via E-Mail. For information on how
to obtain a copy via email, send mail as follows:

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

	path  <your return address in internet form goes here>
	send ncsa2.2tn Index
	^D
The archive server has 8 uuencoded files that can be reassembled
into ncsabin.tar.Z and 13 uuencoded files that can be reassembled
into ncsasrc.tar.Z.  The documentation is also available via
the archive server. In this distribution no uuencoded file
is larger than 75K bytes. Be sure to use the path command in
your request to the archive server to ensure proper reply addressing.

Comments, bugs and suggestions to
	Brad Clements
	Network Engineer
	Educational Resources Center
	Clarkson University
	Potsdam, NY 13676
	(315)268-2292  
	bkc@omnigate.clarkson.edu

The following is updatetn.doc - describes updates and bug fixes to this
version.
-----------------------------------------------------------------------

NCSA Version 2.2D and Version 2.2TN bug fixes and enhancements

This file describes bug fixes from version 2.2C and enhancements
added to make version 2.2TN/D. Enhancements added apply to both
2.2D and 2.2TN except where noted. Bug fixes apply to both equally.

Enhancements:
        1. Version 2.2TN (only) now supports a single 3270 connection
           to VM hosts concurrent with simultanous regular telnet sessions.
           The 3270 code is based on version 4.1.1 of Unix tn3270
           developed by Greg Minshall of Berkeley and is Copyright
           (C) 1988 by the Regents of California.
           (this is the only portion of NCSA Telnet 2.2TN that is not
            public domain)
           TN3270 emulation supports 25, 32 and 43 line 3270 screens
           as well as 7171 datastreams to the TEK screen, VTscreen or
           capture file.

        2. Telnet negotiation options are now expanded, the console
           provides detailed indications of the negotions. New options
           supported:
                Terminal Type (will send VT102, or IBM-3278)
                NAWS (Notify About Window Size) to automatically inform
                    the host about your window size (43 lines, 35 lines etc).
                EOR  (for 3270)
                Binary  (only in 3270 mode, normal telnet connections refuse
                         binary mode (due to limitations in CMU-TEK-TCP for VMS)

        3. Program Status, reports on stack depth used and remaining
           free memory.

        4. Ansi set color escape sequences are now supported, as well as
           Ansi print through and screen dump escape sequences.
           (Thanks to David Camp of Washington University Medical School).

        5. Screen Dump (ALT-D) to capture file.

        6. The Packet Driver interface now supports SLIP mode,
           but requires packet drivers compatible with FTP specification
           version 1.08 or above.

        7. A built in screen saver is provided, with variable delay from
           0 to 60 minutes (0 disables the screen saver).

        8. Escape to dos (ALT-E) works from server mode.

        9. Telnet now automatically switches into 43 or 35 line mode
           if run on an EGA and the -l option was specified. 50 line mode
           works under MSwindows, but is not automatically supported
           under telnet.

        10. The parameters menu can now set BOLD and BLINK for foreground
            and background colors.

Bug Fixes - This section describes bugs fixed since version 2.2C

        1. A change was made in the lowwater/receive window code to
           cause an updated rwindow packet to be sent to hosts when the
           water mark passed the halfway point. Previously an update
           packet was sent after passing the 600 byte mark. This improves
           performance when cat'ing large files to the screen, and 
           removes long pauses that had occured previously.

        2. The FTPBIN client now works. There is a limitation in the
           ni5210 driver which causes it to crash if maxseg is larger than
           1098 bytes. The maxseg now has an upper limit of 1024 for all
           cards. (this should be made more robust in the future, pending
           decisions by FTP software on how the Packet Driver is to handle
           maxseg)

        3. The domain name lookup routines, when using a domainslist, would
           skip to the next search entry if a lookup timeout occured.
           It has been fixed to skip to the next entry only if a 'host not found'
           error is returned.

        4. The parameters menu used to save the parameters even if <ESC>
           was pressed (where normally F1 is used to save the params).
           Also, there was a bug that would keep the terminal type from
           being reset to VT102 if it was set to DUMB. Both problems
           have been fixed.

        5. There was a problem in the FTP server when performing an
           mget fred/*. The files returned to the host would have a \
           rather than a /. This has been fixed. Also, the server would
           attempt to upload the directories . and .. during an mget.

        6. When exiting telnet in 43 line mode, often telnet would not
           correctly reset the video configuration. This has been fixed,
           and now works correctly for both 43 and 35 line operation.
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue 21 Mar 89 13:37:20-EST
From:      "Rich DeJordy, x295" <RAD@VAX02.AMS.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   VMS/SMTP Mailer Information

     We are interested in hearing from VMS sites which are running the
     MultiNet version of TCP/IP for VMS.  We are running MultiNet TCP/IP
     software with Pony Express as the mail delivery system and are using
     MM-32 as the mail interface.  We have been having some problems with
     the mail system.  We are working on these problems with the author of
     each component.  However, in the event that we cannot resolve the
     problems we are having, we are considering two alternatives.  First,
     as we would like to keep using MM-32, we are considering switching
     from Pony Express to Software Tools.  If there is another mail
     delivery system which can deliver to MM-style mail files, that would
     be fine as well.  If we still cannot resolve the problems, we will be
     forced to revert to VAX Mail.  Should that be the case, we would need
     a good mail system to send and receive Internet mail into VAX Mail
     files.

     So, my questions are:

          Is anyone else using the MultiNet/Pony Express/MM-32 combination
          for mail at their site?  If so, I would like to speak with you.

          Is there anyone using MultiNet and MM-32 and not using Pony Express
          for the mail delivery system?  If so, what is it?  How does it
          work?  Where did you get it?

          If we need to abandon MM-32, what is a good, reliable interface
          for VAX Mail to SMTP on the Internet.
-------
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 14:00:59 GMT
From:      mac@proteon.com (Michael A. Curtis)
To:        comp.protocols.tcp-ip
Subject:   Internet Requirements Seminar

Ole,

     Please be kind enough to send me some additional information on
Bob Braden's upcoming discussion of RFC-1009 and the "Requirements for
Internet Hosts" RFC.  Thank you.

Mike Curtis

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 16:08:18 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet with TN3270 support now Available.

3/20/89
A new version of NCSA Telnet with TN3270 support is now
available via anonymous ftp from omnigate.clarkson.edu (128.153.4.2)
from the directory   /pub/ncsa2.2tn

This is the readme file from that directory.

Version 2.2TN is an upgraded copy of version 2.2C with support
for a single Tn3270 session concurrent with simultanous
non-3270 telnet sessions. A full description of new features
and bug fixes are included at the end of this notice.
A similar version without the 3270 support is also included.
It has all the bug fixes and other enhancements as version 2.2TN
but without the 3270 support, its called version 2.2D.

The following files are available:
/pub/ncsa2.2tn

-rw-r--r--  1 bkc        613888 Mar 20 17:57 ncsabin.tar
-rw-r--r--  1 bkc        435892 Mar 20 18:00 ncsabin.tar.Z
-rw-r--r--  1 bkc       1850880 Mar 20 17:56 ncsasrc.tar
-rw-r--r--  1 bkc        703841 Mar 20 18:03 ncsasrc.tar.Z
-rw-r--r--  1 bkc           633 Mar 20 18:17 readme
-rw-r--r--  1 bkc        125824 Mar 20 17:58 telnet.doc
-rw-r--r--  1 bkc         54153 Mar 20 17:59 telnet.doc.Z

ncsabin.tar.Z	contains the binaries for tn3270.exe, telbin.exe
		telpass.exe, ftpbin.exe, tncpp.exe, a sample
		config.tel and various 3270 support files.
		tn3270.exe is identical to telbin.exe except that
		it has 3270 datastream support.

ncsasrc.tar.Z	contains the source for all programs, requires
		turbo C 2.0.

readme		this file

telnet.doc.Z	contains updated documentation. This is version 2.2C
		documentation with additional margin comments
		describing new features.

Note!: Both tar files are binary copies of PC source. If you untar
the source on a unix system, you will have to strip off trailing
CR's and a ^Z at the end of each file. Also, the commonly available
tarread.exe can not extract binary images, it will extract the
source correctly, but should not be used to extract the executables.

Omnigate is no longer providing packet drivers, you can get them
from sun.soe.clarkson.edu:/ka9q/drivers.exe Be advised that
the old SLIP8250 driver has a bug and will not work with this 
version of telnet.

This software is available via E-Mail. For information on how
to obtain a copy via email, send mail as follows:

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

	path  <your return address in internet form goes here>
	send ncsa2.2tn Index
	^D
The archive server has 8 uuencoded files that can be reassembled
into ncsabin.tar.Z and 13 uuencoded files that can be reassembled
into ncsasrc.tar.Z.  The documentation is also available via
the archive server. In this distribution no uuencoded file
is larger than 75K bytes. Be sure to use the path command in
your request to the archive server to ensure proper reply addressing.

Comments, bugs and suggestions to
	Brad Clements
	Network Engineer
	Educational Resources Center
	Clarkson University
	Potsdam, NY 13676
	(315)268-2292  
	bkc@omnigate.clarkson.edu

The following is updatetn.doc - describes updates and bug fixes to this
version.
-----------------------------------------------------------------------

NCSA Version 2.2D and Version 2.2TN bug fixes and enhancements

This file describes bug fixes from version 2.2C and enhancements
added to make version 2.2TN/D. Enhancements added apply to both
2.2D and 2.2TN except where noted. Bug fixes apply to both equally.

Enhancements:
        1. Version 2.2TN (only) now supports a single 3270 connection
           to VM hosts concurrent with simultanous regular telnet sessions.
           The 3270 code is based on version 4.1.1 of Unix tn3270
           developed by Greg Minshall of Berkeley and is Copyright
           (C) 1988 by the Regents of California.
           (this is the only portion of NCSA Telnet 2.2TN that is not
            public domain)
           TN3270 emulation supports 25, 32 and 43 line 3270 screens
           as well as 7171 datastreams to the TEK screen, VTscreen or
           capture file.

        2. Telnet negotiation options are now expanded, the console
           provides detailed indications of the negotions. New options
           supported:
                Terminal Type (will send VT102, or IBM-3278)
                NAWS (Notify About Window Size) to automatically inform
                    the host about your window size (43 lines, 35 lines etc).
                EOR  (for 3270)
                Binary  (only in 3270 mode, normal telnet connections refuse
                         binary mode (due to limitations in CMU-TEK-TCP for VMS)

        3. Program Status, reports on stack depth used and remaining
           free memory.

        4. Ansi set color escape sequences are now supported, as well as
           Ansi print through and screen dump escape sequences.
           (Thanks to David Camp of Washington University Medical School).

        5. Screen Dump (ALT-D) to capture file.

        6. The Packet Driver interface now supports SLIP mode,
           but requires packet drivers compatible with FTP specification
           version 1.08 or above.

        7. A built in screen saver is provided, with variable delay from
           0 to 60 minutes (0 disables the screen saver).

        8. Escape to dos (ALT-E) works from server mode.

        9. Telnet now automatically switches into 43 or 35 line mode
           if run on an EGA and the -l option was specified. 50 line mode
           works under MSwindows, but is not automatically supported
           under telnet.

        10. The parameters menu can now set BOLD and BLINK for foreground
            and background colors.

Bug Fixes - This section describes bugs fixed since version 2.2C

        1. A change was made in the lowwater/receive window code to
           cause an updated rwindow packet to be sent to hosts when the
           water mark passed the halfway point. Previously an update
           packet was sent after passing the 600 byte mark. This improves
           performance when cat'ing large files to the screen, and 
           removes long pauses that had occured previously.

        2. The FTPBIN client now works. There is a limitation in the
           ni5210 driver which causes it to crash if maxseg is larger than
           1098 bytes. The maxseg now has an upper limit of 1024 for all
           cards. (this should be made more robust in the future, pending
           decisions by FTP software on how the Packet Driver is to handle
           maxseg)

        3. The domain name lookup routines, when using a domainslist, would
           skip to the next search entry if a lookup timeout occured.
           It has been fixed to skip to the next entry only if a 'host not found'
           error is returned.

        4. The parameters menu used to save the parameters even if <ESC>
           was pressed (where normally F1 is used to save the params).
           Also, there was a bug that would keep the terminal type from
           being reset to VT102 if it was set to DUMB. Both problems
           have been fixed.

        5. There was a problem in the FTP server when performing an
           mget fred/*. The files returned to the host would have a \
           rather than a /. This has been fixed. Also, the server would
           attempt to upload the directories . and .. during an mget.

        6. When exiting telnet in 43 line mode, often telnet would not
           correctly reset the video configuration. This has been fixed,
           and now works correctly for both 43 and 35 line operation.

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 17:06:00 GMT
From:      mac@proteon.com (Michael A. Curtis)
To:        comp.protocols.tcp-ip
Subject:   NFS Performance through Routers

John,

	Here are a couple of things to try to help with the throughput
problem with your SUN's running NFS.  Some of this is a rehash of what
you have already seen, hopefully with a better explanation.  Number 1)
deals with configuring the P4200's to quiet down the ARP storms that
the SUN's are causing.  It is also recommended that you also go into
each SUN which is not acting as a gateway and turn off IP forwarding.
By turning off the IP forwarding, you will be able to limit the size
of the ARP storm.  However, you must realize that you will still see a
series of ICMP host unreachable messages for each RIP packet.  The
real fix for this situation is to have all machines configured with
the same broadcast address, ie 0's or 1's.  Again, the future
implications must be considered as you may be able (in fact, required
if you are using systems which are running 4.2 BSD) to set the
broadcast to 0's on all machines; however, you will eventually have to
change all machines to a 1's broadcast as BSD Unix cleans this issue
up.  Number 2) deals with setting window size for NFS in an effort to
improve performance.

1) - Broadcasts

     By default, the Sun machines will try and forward any packet they
receive that:

A. Is not for them, but is on the same (sub)network (depending on what
rev SW they are running).

B. Is on a different network.

     This behaviour occurs irregardless of the method of packet
reception (addressed, multicast, or broadcast).  (This is a generic
problem with all hosts using networking software derived from the 4.2
BSD distribution.)

     The broadcast storm comes from the fact that they are not
recognizing the IP destination as the broadcast address for that
(sub)network.  The older Sun's only recongnize 0.0.0.0 or net.0.  When
they see net.255, they just think that's another host on the
(sub)network (no different from net.254), and forward it.  This is why
we let you set the broadcast so many different ways, and why the
default fill is still 0.

     To change the broadcast fill you need to go into the CONFIG
process (T 6) and to process 0 ("IP Config>" prompt).  Type "set
broadcast".  You might try a LOCAL WIRE broadcast, but first just set
the fill pattern to 0 with a NETWORK broadcast.

     The problem with NFS is that it sends large UDP packets (default
8192 bytes), which are then fragmented at the IP level.  The problem
with this is that a large number of packets (6) are sent in a row.  If
you send a burst of 6 packets, we will probably miss one or more,
especially on a heavily loaded ethernet.  Even though the host will
retransmit, the retransmitted burst has a different IP unique ID, so
the IP fragments from the two transmissions cannot be combined.  This
results in having to retransmit until all 6 get through at once.

2) - NFS window size

     The solution is to shrink the size of the UDP writes.  Sun also
has to do with when running through a Sun as a router, or when using a
Sun-2 as a file server for a fast machine like a Sun-3 or Sun-4.

     Here is an old message on the subject:

     How to slow down NFS is something we've known you could do, but
not known how for some time.  It appears to be important when running
NFS through our p4200, which is why I'm posting it here.  Someone
might also want to post it to the p4200 mailing list, if it is still
an outstanding issue in the field.

>From Sun Software Technical Bulletin, February 1987, in the customer
buglist section:
-------
135. Synopsis: fstab entry for sun-3 mounting from a 3com sys not documented
     Release: 3.2

     Description:
	When a Sun-3 system with a Sun Ethernet board NFS mounts a
	filesystem from a system (sun-2 only? I don't know) that has a
	3com ethernet board, extra entries are required on the
	/etc/fstab line to make it work successfully. The Sun-3/ie
	machine pumps out packets so fast that the 3com system can't
	keep up. The rsize and wsize of packets has to be limited, or
	else you get lots and lots of retransmissions and "server not
	responding" msgs. This was documented in the 2.0 to 3.0 Change
	notes (or release notes), but is not noted in the 3.2 manual
	set. It needs to be in the System Administration manual in the
	section covering entworking and NFS.

     Work Around:
	The line in /etc/fstab needs to be of this form:
	3com_machine:/usr /usr nfs rw,noquota,soft,rsize=2048,wsize=2048 0 0
	(the rsize and wsize entries are what is relevant)

     Additionally, we have no record of you ever calling in to Proteon
for support or assistance.  You should be aware that you can request
help directly from Proteon either via telephone (508-898-3100) or
electronic mail (to bug-cgw@proteon.com) as detailed in the support
pamphlet.  Additionally, there is a P4200 users group which you can
address mail to.  To become a member, send a request stating so to
p4200-request@devvax.tn.cornell.edu.  To send mail to this list, send
it to p4200@devvax.tn.cornell.edu.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 17:51:06 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip,sci.crypt
Subject:   RSA Encryption on the Internet

The New York Times reported today that the Internet has decided to
adopt RSA as the basis for an authentication scheme.  This was done
after appropriate negotiations with RSA, Inc., concerning licensing.
Can someone post the details, both technical and administrative?
(It's odd to learn something significant about the Internet from the
mundane media...)

		--Steve Bellovin
	att!ulysses!smb, smb@ulysses.att.com

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 18:36:53 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Damage Estimates of the Worm Attack

Rutgers has a rather large internet network between it's campuses.
It took us about a man-day (two of us spent Thursday morning) fixing
up the various machines on campus to twart the bug.

The next day we spent about 5 man-days answering calls from the media.

Note, that the virus wasn't what caused us to spend the first man-day.
It was the security hole in the UNIX software that left the virus in.
We would have had to fix it anyway even if the bug was reported to us
in a more innocuous way than having a virus unleashed on us.  The media
hype was directly related to the scare though.

Thus you would probably be correct in attributing $1920 (in very generous
salary and overhead money) to answering media inquiries directly associated
to the virus.

We've spent a lot of time checking over our security in the intervening
time, as have a lot of people, but the amount of money they spend beefing
up their security should not be attributed to the virus.  It was a latent
problem that they should have been doing anyhow.

-Ron

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 18:44:00 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Source Quench & Jacobson's Alg.

RFC 1009 requires that source quench be sent; this statement should be
taken as authoritative:

	      2.2.3.  Source Quench

	 All gateways must contain code for sending ICMP Source Quench
	 messages when they are forced to drop IP datagrams due to
	 congestion.  Although the Source Quench mechanism is known to
	 be an imperfect means for Internet congestion control, and
	 research towards more effective means is in progress, Source
	 Quench is considered to be too valuable to omit from production
	 gateways.

	 There is some argument that the Source Quench should be sent
	 before the gateway is forced to drop datagrams [62].  For
	 example, a parameter X could be established and set to have
	 Source Quench sent when only X buffers remain.	 Or, a parameter
	 Y could be established and set to have Source Quench sent when
	 only Y per cent of the buffers remain.

	 Two problems for a gateway sending Source Quench are: (1) the
	 consumption of bandwidth on the reverse path, and (2) the use
	 of gateway CPU time.  To ameliorate these problems, a gateway
	 must be prepared to limit the frequency with which it sends
	 Source Quench messages.  This may be on the basis of a count
	 (e.g., only send a Source Quench for every N dropped datagrams
	 overall or per given source host), or on the basis of a time
	 (e.g., send a Source Quench to a given source host or overall
	 at most once per T millseconds).  The parameters (e.g., N or T)
	 must be settable as part of the configuration of the gateway;
	 furthermore, there should be some configuration setting which
	 disables sending Source Quenches.  These configuration
	 parameters, including disabling, should ideally be specifiable
	 separately for each network interface.

	 Note that a gateway itself may receive a Source Quench as the
	 result of sending a datagram targeted to another gateway.  Such
	 datagrams might be an EGP update, for example.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 19:18:51 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  IETF RFC Draft

Host Requirements RFC draft: anonymous FTP from host venera.isi.edu,
with pathname pub/ietf-hosts.rfc.txt


Bob Braden

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 19:32:01 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   BS in InfoWorld

Sigh.  On page 12 of the March 20 InfoWorld, there is Yet Another report of
the Imminent Death of TCP/IP by Mark Stephens.  Some of the more laughable
gaffes:
  o TCP is required to check for errors, which makes the protocol "not
    especially fast".
  o "TCP/IP that lacks Telnet, FTP and SMTP is not TCP/IP."
  o "Don't fault the architects of TCP/IP, who couldn't know there would be
    millions of IP addresses in use today, but their choice of a 32-bit
    address means that we are running out of addresses."
-russ
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lama

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 19:47:35 GMT
From:      pjb@MBUNIX.MITRE.ORG (Brusil)
To:        comp.protocols.tcp-ip
Subject:   IFIP NET MGMT SYMPOSIUM


	ADVANCE PROGRAM SUMMARY & REGISTRATION INFO

********************************************************************
** FIRST INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK MANAGEMENT **
********************************************************************

Improving Global Communication Through Network Management
May 14-17, 1989
The Westin Hotel, Boston, Massachusetts

Sponsored by the International Federation for Information Processing
(IFIP)
Hosted by The MITRE Corporation and the National Institute of
Standards and Technology


			******************
			*    OVERVIEW    *
			******************

This symposium, a unique combination of high-level technical sessions
and presentations by industry-leading vendors, will:

	o  familiarize professionals from diverse network management
	   backgrounds with the goals, current priorities, and plans of the 
	   many worldwide activities focusing on network management

	o  promote detailed technological interchanges

	o  create a forum for discussion and coordination of the complex
	   advanced research and development needed to define the network
	   management standards of the future

	o  provide a framework to feed back insight about current
	   implementations to standards developers

	o  stimulate cooperative international efforts in various areas of
	   network management


	*********************************************************
	* TECHNICAL TRACKS (two parallel tracks on May 15 & 17; *
	* three parallel tracks on May 16)                      *
	*********************************************************

1.Heterogeneous Network Management -- Invited Speaker: Carl Sunshine (UNISYS)
	Session 1A: Enterprise Management
	Panel 1B: Experience with Network Management

2.Integration Through Standards -- Invited Speaker: Yoshikazu Kobayashi (IBM)
	Session 2A: Business Requirements
	Session 2B: Technical Requirements 

3. Management Information and Functions -- Inivted Speaker: Jeremy
   Tucker (Logica)
	Session 3A: Management Information
	Session 3B: Performance Management and Modeling
	Session 3C: Security and Dialogue Management

4. Design and Modeling -- Invited Speaker: Lev Feldkuhn (Bell Atlantic)
	Session 4A: Design Approaches
	Session 4B: Fault Management
	Panel 4C: Network Management: Which Model to Choose?

5. Management Architectures -- Invited Speaker: Phillip Enslow
   (Georgia Inst Technology)
	Session 5A: Telecommunication Architectures
	Session 5B: Multimedia Integration
	Session 5C: LAN Management

6. Distributed Systems Management -- Invited Speaker: Morris Sloman
   (Imperial College)
	Session 6A: International Cooperation
	Session 6B: Implementation and Language Issues

7. Artificial Intelligence in Network Management -- Invited Speaker:
   Rodney Goodman (Cal Tech)
	Session 7A: Expert Tools for Network Management
	Panel 7B: Intelligent Network Management


	************************************************
	* TUTORIALS (five parallel sessions on May 14) *
	************************************************

 Management Standards - Current Status of Work in ISO -- Chris Sluman,
 Jeremy Tucker, and Tony Jeffree

 Tools for the Performance and Fault Management of Local and Wide Area
 Networks -- Belinda Yung-Rubke

 Recent Developments in Integrated Network Security -- Harold Podell
 and Marshall Abrams

 Comparative Analysis of Existing Network Management Systems -- James
 Herman

 Management of Manufacturing Networks -- Juan Pimentel


		**********************
		* FEATURED SPEAKERS  *
		**********************

Vinton Cerf, Vice President, Corporation for National Research
Initiatives

John Gibbons, Director, Office of Technology Assessment, U.S.
Congress

Lt. Gen. John Myers, Director, Defense Communications Agency

John Crecine, President, Georgia Institute of Technology


	********************************************
	* VENDOR PRESENTATIONS - CORPORATE PATRONS *
	* (4 vendors/day; 30 min plenary 	   *
	* presentations each; single day suite for *
	* each)					   *
	********************************************	

Atlantic Research Corporation
Avant-Garde Computing, Inc.
Boeing Computer Services, Inc.
Codex Corporation
Data General Corporation
Digital Communications Associates, Inc.
Digital Equipment Corporation
International Business Machines Corporation
MCI Telecommunications, Inc.
NYNEX Information Systems Group
OSI/NM Forum
Wang Laboratories, Inc.


	******************************
	*     REGISTRATION FEES      *
	******************************

TECHNICAL PROGRAM: 

Full registration (received before April 14, 1989):  $595
	(includes technical and vendor sessions, three breakfasts, 
	 two luncheons, three receptions, one banquet, the Omni Theater 
	 social event, and one copy of the proceedings)
Full registration (received after April 14, 1989): $695

TUTORIAL PROGRAM:

Tutorial registration (received before April 14, 1989): $200
	(includes admission to one tutorial, plus that tutorial's
	 handouts)
Tutorial registration (received after April 14, 1989): $300

Copies of Tutorial Materials: $25 for each tutorial; $100 for all tutorials


		************************
		* FURTHER INFORMATION  *
		************************

For a copy of the advance program, contact:  Hershey Young, IFIP
Symposium, c/o National Institute of Standards and Technology, Bldg.
225, Room B217, Gaithersburg, MD 20899; (301) 975-5267

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 20:11:36 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Information Request Message format

The Host Requirements RFC draft says ICMP Information Request/Response is
a SHOULD NOT.  The discussion notes that RARP and BOOTP are better
approaches to booting a diskless host.

Bob Braden

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 20:58:04 GMT
From:      droms@sol.bucknell.EDU ("Ralph E. Droms")
To:        comp.protocols.tcp-ip
Subject:   Configuring ntpd



I'm looking for hints in configuring ntpd for a system without
Internet access.  I recently copied the source from louie.udel.edu;
the RCS info is "Revision 3.1, 89/01/30".  I'd like to designate one
of my local systems as the "master" clock, and synchronize the other
clocks to that master.  I've tried a couple of different
configurations, and am able to get several systems to exchange data,
but can't get any of the clocks to converge on the master clock.  The
problem seems to be related to setting the master clock to have a
non-zero stratum.

Any help would be greatly appreciated...

- Ralph Droms                 Computer Science Department
  droms@sol.bucknell.edu      323 Dana Engineering
  droms@bknlvms.bitnet        Bucknell University
  (717) 524-1145              Lewisburg, PA 17837

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 20:59:11 GMT
From:      droms@sol.bucknell.EDU ("Ralph E. Droms")
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix-32


Can anyone give me a pointer to SLIP for "Ultrix-32 V3.0 (Rev 64)"?

- Ralph Droms                 Computer Science Department
  droms@sol.bucknell.edu      323 Dana Engineering
  droms@bknlvms.bitnet        Bucknell University
  (717) 524-1145              Lewisburg, PA 17837

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 89 22:40:37 GMT
From:      sean@ms.uky.edu (Sean Casey)
To:        comp.protocols.tcp-ip,sci.crypt
Subject:   Re: RSA Encryption on the Internet


Jim Bidzos of RSA Data Security told me that there should be an RFC out
by early April describing the implementation of the standard.

He outlined it to me, but I don't remember it that well. It mostly
concerns the transmission of DES keys for encrypted email by using the
RSA scheme.

As far as using the RSA scheme, they are pretty liberal about granting
no-cost licenses for noncommercial use. The trick is that anyone who
uses RSA must first register their personal key with them. It costs $25
for two years.  They then encode their key in yours, and send it back.
Anyone who is granted a license for an RSA application program then has
to check any user's public key and verify that they are registered and
up to date. This is easily done by encrypting with RSA Corp's public
key. Out pops a string (I guess - he didn't say explicitly) and a date
code.

Thus it's likely that once you've registered a personal key, you can
use Internet RSA facilities at no additional cost for two years.

Hopefully, once the RFC is out, we'll have some heavy math types
writing a a really fast freely redistributable implementation.

Sean

-- 
***  Sean Casey                        sean@ms.uky.edu,  sean@ukma.bitnet
***  Who sometimes never learns.       {backbone site|rutgers|uunet}!ukma!sean
***  U of K, Lexington Kentucky, USA  ..where Christian movies are banned.
***  ``You talk the talk. Do you walk the walk?''

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      WED, 22 Mar 1989 12:53:21 EST
From:      Jeffery K. Bacon <BACON%MTUS5.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Re: Sun ARP storms and such
Could the person who posted that information about the Sun ARP storms and
nonesuch please resend it to me (provate email)? I punched the 'discard'
key too quick for my own good...thanks.
-jb
<bacon%mtus5.bitnet@cunyvm.cuny.edu>

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 08:39:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   NFS Performance through Routers

Something we've occasionally done when experiencing ARP storms is to
set up a PC or similar expendable machine ANSWERING the ARP requests
for the incorrect broadcast address (and throwing the resultant
forwarded packets on the floor).  Besides providing a sink for the
traffic and thus calming the storm, this provides us with a good way
to monitor exactly which hosts are using the wrong address, so that we
can go in with the debuggers and service calls and icepicks with some
assurance that we know who the culprits are.

Tasteless, but it works....

--Rob

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 15:27:32 GMT
From:      paul@kuhub.cc.ukans.edu (Craig Paul)
To:        comp.protocols.tcp-ip,sci.crypt
Subject:   Re: RSA Encryption on the Internet

> The New York Times reported today that the Internet has decided to
> adopt RSA as the basis for an authentication scheme.  This was done
> after appropriate negotiations with RSA, Inc., concerning licensing.
> Can someone post the details, both technical and administrative?
> (It's odd to learn something significant about the Internet from the
> mundane media...)

Look up this reference....

From:	KUHUB::PAUL         "Craig Paul" 14-FEB-1989 15:06:04.87
To:	PAUL,PAUL        
CC:	
Subj:	Internet Endorses RSA E-mail.

PC Week, 2/13/89, p. c/6

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 17:53:21 GMT
From:      BACON@MTUS5.BITNET (Jeffery K. Bacon)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun ARP storms and such

Could the person who posted that information about the Sun ARP storms and
nonesuch please resend it to me (provate email)? I punched the 'discard'
key too quick for my own good...thanks.
-jb
<bacon%mtus5.bitnet@cunyvm.cuny.edu>

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 18:14:43 GMT
From:      larry@rnms1.uucp (0000-Larry Swift(0000))
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip,comp.std.internat
Subject:   Re: TCP/IP versus OSI

In article <2145@cpoint.UUCP> martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) writes:
>be interested, and I would not mind some comments.

OK, here goes.

Some of your remarks seem to be deliberately baiting entire groups of
people, to wit:

>            costs.  At the same time, with no obvious architecture, with
                                         ^^^^^^^^^^^^^^^^^^^^^^^
>            theoretical  or   idealized  networks   and  while  actively
>            ignoring the  work being  done in the ARPA Internet context,
>            the ISO  OSI  standards  committees  were  developing  basic
>            remote terminal  and file  transfer protocols.   The ISO OSI

I won't argue the merit of this statement one way or the other.  But
the fact is that there have been lots and lots of people working on
architectural issues in the ISO context since the very early days who
could easily get offended by the off-hand nature of this remark.

>           |Since June,  1988 William Stallings and I have been engaging|
>           |in a  guerilla debate  in the  reader's forum  and  the  EOT|
                   ^^^^^^^^
I would offer that a lot of people who might otherwise be interested in
this subject will not bother with this debate because of the "guerilla"
nature of your discourse.  I'm certainly less interested than I otherwise
would be.

>           |hominem attacks.  I apologize for those comments in my forum|
>           |letter which  might be  construed  as  personal  attacks  on|
>           |William Stallings.           				|

'nuff said.

>            the debate.   I  have yet  to meet a communications engineer
>            who had  a sense  of what  a process might be. Having taught

In other words, you are the only exception?  Give us a break, here.

Maybe I'll read the rest later.


Larry Swift                     email: larry@pdn.paradyne.com
AT&T Paradyne, LG-129           Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981           She's old and she's creaky, but she holds!

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 18:20:00 GMT
From:      w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   Domain resolver resets needed

On Monday March 20 a large number of Milnet hosts changed their
network addresses.  Simtel20 was one of those.  I've been getting a
lot of complaints from users on other hosts who cannot connect to
Simtel20 with FTP.  We are also not receiving mail from a number of
hosts which are reporting "connection refused".

The problem can be solved by restarting your domain resolver so it
will pick up the new address for Simtel20 and the many other hosts
whose addresses changed.

This points out the need for some mechanism to update domain resolver
caches before their expiration so that when address changes occur they
do not result in loss of connectivity.  In our case it will be five
days before hosts with domain servers know that we have made the
address change.  Meantime they are all trying to connect to
whitesands-mil-tac which now has our old address.

--Keith Petersen

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 19:32:27 GMT
From:      stoltz@ida.org (Bill Stoltz)
To:        comp.sys.misc,comp.protocols.misc,comp.protocols.tcp-ip,comp.sys.proteon
Subject:   Wanted: real life product reviews


OH NO, not again.  Somebody trying to get free advice on some products.
Sorry! :-(  But you have to admit, for real life stories this is a great 
source of information.  How often to you get to praise or condem a
product to a complete stranger.

I have been talking to various vendors for the last 3 months on different
physical media equipment, Like SynOptics, ODS, Du Pont, and Proteon.
Now, I would like the truth, or at least your interpretation of it.

We have settled on a star topology for the horizontal wiring.  We installed
some unshieled twisted pair about 3 years ago, for RS 232, that we may
reuse, although that is not definite.  We will be using Fiber for the
Riser connections.

I would appreciate any real life information (good, bad, etc) 
about SynOptics, ODS, Du Pont Fiber Optics for AppleTalk,
ProNET-4, ProNET-10, and ProNET-80, or any other comperable products. Sorry
NO coax! :-) I have all the product information on all of these, I would like 
comments like "it works ok, except...." or "I had problems installing ...".
Don't feel like you have to give me a technical comparision, Stop right now
and tell me how the products you are using are working today, last week, last
month.

Oh yes, I almost forgot, Please send replies directly to me, and yes I will
summarize to anyone interested.

Thanks in advance for all the replies.



--------------------------------------------------------------------------
Bill  Stoltz					    Internet:  stoltz@ida.org
Institute for Defense Analyses
1801 N. Beauregard St.
Alexandria, Va 22311				Voice:  (703) 845-2119

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 19:43:47 GMT
From:      msd@trwind.UUCP (Marc S. Dye )
To:        comp.protocols.tcp-ip
Subject:   Re: syntax of remote pathnames?

In article <8903161632.AA16971@corwin.CCS.Northeastern.EDU> mckee@CORWIN.CCS.NORTHEASTERN.EDU (George McKee) writes:
> ...
>when it would make the writing flow much more smoothly if you
>could say things like "you can find a program that might do what
>you want in @SUMEX-AIM.STANFORD.EDU:info-mac/app/contour81.hqx".

It would be *WONDERFUL* to have a canonical format for file pathnames.
I suggest you don't imbed naked colons ':' anytime soon though.  VMS
and probably TOPS-20 will get sick.  Also note that Unix allows ':',
'@', or almost anything except '/' in a pathname.

Maybe some quoting is in order?  For example:

	@SRI-NIC.ARPA:`PS:<RFC>RFC1087.TXT'

is almost(?) as readable, and possible interpretable by a non-human
(just need to strip matching `', while feeling free to interpret the
naked ':' and '@' as syntactic operators).  Note that one obvious
alternative (escaping) gets *ugly* in a hurry:

	@SRI-NIC.ARPA:PS\:\<RFC\>RFC1087\.TXT

If you wanted to go further, you could talk about other 'operators' in
Unified File Speak.  Seriously, you could presumably adopt any regular
expression syntax for 'wildcarding', extended with a useful alternation,
and add in some sensible directory recursion, distinguishable from normal
(non-recursive) wildcarding.

The BSD Unix csh-style pathname syntax is fairly nice, but doesn't do
recursive directory descent.  VMS has some of these notions, but I'm
not personally wild about the [] pairs.  I.e. I like:

	/foo/.../bar

better than:

	[foo....]bar.

User names (or in more global sense, named access restriction classes)
would also be nifty:

	ANONYMOUS@SRI-NIC.ARPA:`PS:<RFC>RFC106'[5-7]`.TXT.0'

Note that the non-quoted parts behave according to canon; quoted stuff
can be as grotesque as any vendor likes.

Just suggestions ...

For fun, how about:

	@woof.Poundmasters.Com:`D:\HOSED'/.../{SHARE,SHAREALIKE}`.EXE'
	KO@VirulentlyMalignantSoftware.Com:`DQB666:[MANUALS]InThere.SOMEWHERE;0'

Enough fun -- back to the salt!

++msd

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 20:40:31 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet


	
	The New York Times reported today that the Internet has decided to
	adopt RSA as the basis for an authentication scheme.  This was done
	after appropriate negotiations with RSA, Inc., concerning licensing.
	Can someone post the details, both technical and administrative?
	(It's odd to learn something significant about the Internet from the
	mundane media...)
	
			--Steve Bellovin
		att!ulysses!smb, smb@ulysses.att.com
	
Steve,

Yes, it certainly is odd.  We (the IAB) are trying to improve the info
flow, but we obviously have a distance to go.  The general info was
published in the Internet Monthly Report recently, but that is pretty
much limited to the research community.  I appending that announcement.
The details will be covered in future (we hope not too distant future!)
RFC's being prepared by the Privace and Security Task Force, Steve Kent,
proprietor.

     Bob Braden (for the IAB).

____________________________________________________
____________________________________________________
  
IAB REPORT -- February 1, 1989

This is the first of a series of reports on those decisions and actions taken
by the Internet Activities Board that should be of general interest to the
Internet community.

The following items are decisions made at the January 1989 meeting of the
IAB.

A. Private Mail

   For several years, the Privacy&Security Task Force chaired by Steve
   Kent of BBN has been developing a scheme to add privacy to SMTP-based
   electronic mail.  RFC's to be published soon will contain the final
   details of the plan for encapsulating encrypted text within SMTP
   messages (see RFC-1040 for an earlier draft) and the plan for key
   distribution.  This scheme will (optionally) provide data
   confidentiality, origin authentication, per-message integrity, and
   non-repudiation by the originator, and is based upon public-key
   encryption using the RSA algorithm.  Public keys will be bound to
   individuals by means of "user certificates", which will be issued
   by a private company, RSA Data Security Inc.  The expected cost will
   be $25 for a user certificate valid for two years.

   The IAB reviewed this plan and gave the go-ahead to proceed with
   implementation in the Internet.  Not everyone needs private mail, of
   course, but for those that do, this feature should allow Internet
   email to take on a new importance.
   
B. The Worm Incident

   The IAB joined others in the community in expressing its deep concern
   about the recent Internet worm incident and the resulting public
   reaction.  The IAB released a policy statement that has been published
   in RFC-1087, entitled "Ethics and the Internet."

   The IAB plans to take future steps to make the gateway protocols more
   secure against subversion and to improve the facilities for network
   managers to selectively isolate pieces of the Internet should such
   problems recur.

C. Draft Documents

   The IAB believes that the Internet community is best served if there
   continues to be only one archival series of documents, the RFC's.  To
   help prevent the erosion of this singularity, the IAB has decided that
   the IDEA series of draft documents maintained by the IETF will be
   replaced by a series of "Internet drafts".  The new series is crafted
   to minimize inappropriate citations and to ensure that these drafts
   move forward into RFC's as quickly as possible.  Details were
   announced by Phill Gross, chair of the Internet Engineering Task
   Force, at its January 1989 meeting.
   
D. IP Security Option

   A vendor requested an IP Option for commercial security, where the
   contents of this option would be unstandardized and vendor-specific.
   The IAB felt strongly that IP options must be publically defined and
   documented, while that proprietary or privately-structured options 
   are a bad idea.  The IAB will initiate a broad-based effort to
   define a (commercial) security option for IP.  Interested parties 
   may contact Steve Kent (Kent@BBN.COM  (617) 873 3988).   
   

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 21:28:45 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Version 2.0 of the "PD" packet drivers.

Version 2.0 of the freely copyable packet drivers is now available.  Included
in this mail message are the changes from the previous version and instructions
on obtaining the drivers.
-russ


Changes from version 3 to 2.0 of the drivers:

Version numbering now changed.  If the skeleton changes, the major version is
     incremented and all the minor versions are reset to zero.

**** As a result of the changes to support version 1.08 of the packet driver
**** spec, minor changes had to be made to every driver.
**** As of this writing, the following drivers are untested:
****      ni5010.
**** Please mail to (Russ) nelson@clutx.clarkson.edu if you can verify that
**** these drivers work.

Support for version 1.08 of the packet driver spec included.
Bob Clements' 3c503 driver added.  See README.503.
Some comments improved.
BAD_COMMAND checking code fixed.
cld instructions added to ensure that DF=0.
NI5210 sped up slightly -- look at movemem in ni5210.asm for an especially
     fast routine to move memory around.
Spurious error condition that caused NCSA Telnet to fail in send_pkt
     function removed.


These drivers are available from the Clarkson archive-server as well
as by FTP.  If you don't know how to use the archive server, send a
mail message consisting of the word "help" to one of the addresses
given below.  For those who can FTP, a self-extracting ZOO archive can
be found on sun.soe.clarkson.edu in pub/ka9q as drivers.exe.

Clarkson Archive Server // commands = help, index, send, path
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lama

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 22:45:05 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  NFS Performance through Routers

We did a similar hack here at BRL.  Our gateways answer broadcast ARP
requests with the ethernet address (hex)

	0:0:D:E:A:D

The buggers still keep forwarding of course but at least they quit ARPing.
This address makes the culprits easy to spot with tcpdump.

- Phil

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1989 07:17-PST
From:      Steve Sidner <SAC.PRC@E.ISI.EDU>
To:        braden@VENERA.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  RSA Encryption on the Internet
Bob, I found the IAB Monthly report informative, particular
regarding mail security and the status of IDEAs.  Is it possible
to get on the distribution list for this report?
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 89 23:59:16 GMT
From:      mogul@WSL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS Performance through Routers


Rob Austein writes:
    Something we've occasionally done when experiencing ARP storms is to
    set up a PC or similar expendable machine ANSWERING the ARP requests
    for the incorrect broadcast address (and throwing the resultant
    forwarded packets on the floor).  Besides providing a sink for the
    traffic and thus calming the storm, this provides us with a good way
    to monitor exactly which hosts are using the wrong address, so that we
    can go in with the debuggers and service calls and icepicks with some
    assurance that we know who the culprits are.
    
    Tasteless, but it works....

NOVICES, BEWARE: under no circumstances should the answer to an
ARP for a broadcast IP address return the broadcast Ethernet address.
This is clearly not what Rob is doing, and of course "nobody would
ever do this" ... but I have heard of people doing it.  Chernobyl
was nothing compared to this.

If I were supporting an ARP implementation, I would have it check
to make sure it wasn't inserting a broadcast/multicast address in
any of the hardware address fields of an ARP message ... and if it
detects such an attempt, it should start the "host self-destruct"
sequence to make sure that a person who makes this mistake is
properly chastised.

-Jeff

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 00:43:03 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Damage Estimates of the Worm Attack

Thank you, Ron, for the sanest statement I've seen posted on the
worm/virus attack!  At last, a note of sanity.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Mar 89 08:31:38 MST
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        w8sdz@wsmr-simtel20.army.mil
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Domain resolver resets needed
Keith,

One suggestion:

Next time, before the change, set the TTL for the domain or the
particular addresses down to 1 day, sometime around 'old ttl' days before
the switch.

The only thing that can be done for users with static tables is place
warnings in various news and mailing lists, and as messages of the day
on the hosts that will be changing.


Phil
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 01:48:38 GMT
From:      mjoshi@hpldsla.HP.COM
To:        comp.protocols.tcp-ip
Subject:   LAN performance


I am reviewing the performance of 802.3/Ethernet LANs, and the 
following questions arose:

Is there a UNIX based tool to measure the Load (in say, bits/sec) 
on the network at any given time. Although, I am able to compute the 
traffic factor for the artificial load generated by my applications, 
I am not able to assess the load factor or percentage of LAN bandwidth 
that is already being consumed by other systems on the LAN.           

Also does anyone have a performance curve for the distribution of 
throughput at the ethernet as well as TCP/IP level as the load varies, 
for a fixed message size? I found Cabrera (et al)'s article on 
User Process Communication Performance (IEEE Transactions on s/w Engg,
Vol. 14, No1, Jan 1988 very informative although the illustrated
curves give throughput v/s message size for fixed loads.

Has anyone evaluated Ethernet/802.3  cards (for Intel/Motorola 
architectures in the Dos/Unix/Xenix environments) like 3-COM, Interlan, 
Excelan or Western Digital in terms of data buffering, speed, memory
requirements, cost-effectiveness and so on. I would very much 
appreciate if someone has data to spare on this.

Manoj Joshi.

manoj@hpldas5

Telnet: 857-7099

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Mar 89 08:51:09 MST
From:      prisma!mo@uunet.UU.NET (Mike O'Dell)
To:        tcp-ip@sri-nic.ARPA
Subject:   the UT SunOS 4.0 streams stuff
Well, it works, mostly.  I certainly have crashes on my machine
where I'm trying to debug it.  The mbuf management in 4.0
is rather more sophisticated than in previous versions and
there are some cases the open-coded macros don't seem to cope with.

	-Mike O'Dell
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Mar 89 09:57:44 PST
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        Keith Petersen <w8sdz@wsmr-simtel20.army.mil>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Domain resolver resets needed
It might also be interpreted as a need for those organizing such moves
to plan ahead, turn down their TTLs in advance, then turn them back up
after the change is made.

Given that resolvers toss old data as they should, it seems more
reasonable that we put the responsibility on those changing their
addresses than the rest of the Internet.

paul

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 03:08:56 GMT
From:      avolio@decuac.dec.com (Frederick M. Avolio)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix-32

SLIP comes with ULTRIX-32 v3.0.   It is in the ULXBASE030 subset.

Fred

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Mar 1989  10:26 MST
From:      "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To:        cpw%sneezy@LANL.GOV (C. Philip Wood)
Cc:        tcp-ip@SRI-NIC.ARPA, w8sdz@WSMR-SIMTEL20.ARMY.MIL, WANCHO@WSMR-SIMTEL20.ARMY.MIL
Subject:   Domain resolver resets needed
Phil,

Your comment about the short TTL prior to an address change is exactly
what I recommended to the MILNET Manager yesterday.

--Frank
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 03:48:36 GMT
From:      dpz@pilot.njin.net (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   YARD tool available + comments


I have YARD (Yet Another Routing Diagnostic) tool available.  It is your good
friend and mine, "ping".  I've added Ron Natalie's cisco emulation mode and
cleaned up my route record code.  The fun starts when you put them together
for a bit (ping -co hostname).  It is available, with updated manpage, as
"src/ping.shar" via anonymous FTP to rutgers.edu.

Having just turned off our only BSD VAX, I would be appreciative if people
could let me know that it still compiles and runs correctly under 4.3++.  I've
verified that it works under Sun3 and Sun4 SunOS 4.0.1.

Would it be worth the trouble to modify the IP spec at this point?  There are
two things I'd like to see in it, both concerning route recording, and I'm
sure others probably have had ideas to improve on RFC791 over the last 7 or so
years.

						David
-- 
David P. Zimmerman, the Rutgers Dorm Networking Project, the UUCP Project, etc
dpz@pilot.njin.net             rutgers!dpz           dpzimmerman@zodiac.bitnet

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1989 1540-PST (Thursday)
From:      Philip Almquist <almquist@jessica.Stanford.EDU>
To:        Terry Slattery (SECAD) <tcs@brl.mil>
Cc:        almquist@jessica.Stanford.EDU, Keith Petersen <w8sdz@wsmr-simtel20.army.mil>, tcp-ip@sri-nic.arpa
Subject:   Re:  Domain resolver resets needed
Terry,
> The current refresh entry should satisfy this need if the changes are
> expected in advance.  A week before the change, set the refresh
> interval to 24 hours.  Hosts will begin using the 24 hour interval
> when their current info expires.  One day before the change, set the
> refresh interval to something smaller, perhaps 2 or 4 hours.  When the
> change is made, hosts will only be using the wrong addresses for at
> most 2-4 hours.  When things are stable, change back to your normal
> refresh interval.
	The idea is right, but you used the wrong words and therefore
might confuse somebody.  There is a field in the SOA record called the
REFRESH interval, but that is not what you were referring to above.

	What he does want to decrease is the TTLs associated with the
records that are going to change.  Since no record may have a TTL
smaller than the zone MINIMUM TTL (another phrase from RFC 1035), he
may well have to change the zone MINIMUM TTL.

						Philip
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Mar 89 13:29:43 EST
From:      Mike Muuss <mike@BRL.MIL>
To:        John Matthews <ulysses!mhuxo!mhuxu!alux2!matthews@ucbvax.berkeley.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  NFS Performance through Routers
John -

Earlier this week, we moved a bunch of 20 MIPS SGI workstations to another
building for a demo, and for several days, pounded our campus network
with NFS packets.  These packets went from ethernet to 10-Mbit Pronet
and back to ethernet, with two P4200 gateways involved.  I was pleased
to note that performance across the two Proteon gateways was indistinguishable
from performance on the local network.

My ethernet monitoring indicated that the NFS traffic was peaking in the
vicinity of 200-250 packets/sec in each direction;  this was occupying
perhaps 3-4 Mbits of the ether bandwidth on each end, and on the campus
ring.  The Proteon gateways showed no sign of strain, and were not
dropping packets.

Your ARP storms may be part of the your troubles.  We have dealt with
the old/new UDP broadcast problem by having our gateways publish the
ethernet address 00:00:0D:0E:0A:0D (DEAD!) for nn.nn.nn.000 ARP requests.
This solves the problem quite nicely for us, as nothing will see those
packets.  Of course, since you are using the evil level-2 LAN-Bridges,
you will still have to forward them across the bridges.

So far, we have been supremely pleased with the performance of our
Proteon gateways.  Of course, we did order all the "performance" options
(faster CPUs, new ethernet boards, etc), so that may be a factor.

	Best,
	 -Mike
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 15:17:00 GMT
From:      SAC.PRC@E.ISI.EDU (Steve Sidner)
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

Bob, I found the IAB Monthly report informative, particular
regarding mail security and the status of IDEAs.  Is it possible
to get on the distribution list for this report?

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 15:27:34 GMT
From:      tcs@BRL.MIL (Terry Slattery, SECAD)
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain resolver resets needed

> This points out the need for some mechanism to update domain resolver
> caches before their expiration so that when address changes occur they
> do not result in loss of connectivity.

The current refresh entry should satisfy this need if the changes are
expected in advance.  A week before the change, set the refresh
interval to 24 hours.  Hosts will begin using the 24 hour interval
when their current info expires.  One day before the change, set the
refresh interval to something smaller, perhaps 2 or 4 hours.  When the
change is made, hosts will only be using the wrong addresses for at
most 2-4 hours.  When things are stable, change back to your normal
refresh interval.

For this to work, you must know at least your current refresh interval
in advance of the change date.  There will also be a slight increase
in network traffic as hosts refresh more frequently.  Without
significantly more state in the nameserver about who requested host
info, there is no easy way to flush remote caches.  You already know
the alternative - answer phone calls from remote sites who can't
contact you and have them do a manual flush.

I noticed that wsmr-simtel20.army.mil has a ttl of 24 hours, not one
week.  All DNS hosts should work properly after this time and only
hosts using a static host table should have problems.

	-tcs

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 16:03:12 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain resolver resets needed

Kieth:
	There's a simple solution to this.   Walk around to the
back of your PSN and swap the cables for the TAC and your host.
This gratuitous renumbering on the MILNET is one of the silliest
things I've seen in years.  It was a hold over from the old days
(when TIP's were integral with the IMPs) that TAC's occupied port
2.  The displacing of every host on the MILNET who occupy port zero
is a real pain.  I notice that either the NIC didn't get bumped,
or their nameserver info is out of date.

Of course this is from the people who brought you the quaint phrase
"rehomed" as a description of what they did when they kicked most
of the universities off the ARPANET last year.  This from the same
group that wastes more time on the Domain transition issue thinking
up what to name the hosts than actually doing anythign about it.

Several years ago when I was still in the employ of the Army, and one
of the only representives of an actual military site on the Internet
Engineering Task Force, we sat down with a subcommittee to figure a
way to practically make the domain transition for the military nodes.
The recommendation involved things like setting up a first step with
a few nameservers that had the authoritative information for the .MIL
domain, and would forward domain queries for less adventuresome MILNET
sites.  I was probably sufficiently cautious because at the time I
deplored the domain implementation (is this any way to run a distributed
database).  All of these recommendations were ignored.

The next debacle was the demise of the interim .ARPA domain.  People seemed
to think that the magical removal of this domain was going to accomplish
something.  To me it's just another top level domain, nor more or less
valid than .GOV or .MIL or anything else.  What needed to be done is
to convince the military sites to do name resolution, or to at least
fake it well.  Just renaming the hosts did nothing to help this and
we're still in the dark ages where it comes to talking to the guys on
the Autodin II side of the universe.

-Ron (Blown to hell by BRL) Natalie

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Mar 89 21:47:54 EST
From:      David P Zimmerman <DPZ@CORNELLF.tn.cornell.edu>
To:        Nick Gimbrone <NJG@CornellA>, "John A. Shriver" <jas@proteon.com>, Mark Bodenstein <MAB@CornellC>, Mike Hojnowski <MqH@CornellC>, Richard Alexander <RAA@CornellA>, mrc@sumex-aim.stanford.edu
Cc:        netcoor@ncs.dnd.ca, tcp-ip@sri-nic.arpa
Subject:   Re: Odd FTP Problem
  I prefer    /* NEEDSWORK */. This is what LCC uses.

>Note the comment about "/* XXX */" below ;-).
>
>----------------------------Original message----------------------------
>Well Mark, that indeed sounds like a great way to improve the
>antisocial behaviour of 4.[23]bsd in the face of ICMP host and net
>unreachables.  I looked at the source (ip_input.c, tcp_subr.c,
>protosw.h), and it certainly seems that will have the deisred result.
>
>The u_char array inetctlerrmap (in ip_input.c) maps the generic error
>types from protosw.h to error numbers from errno.h.  Offsets 8 and 9
>are (protosw.h):
>
>#define	PRC_UNREACH_NET		8	/* no route to network */
>#define	PRC_UNREACH_HOST	9	/* no route to host */
>
>which are mapped repsectively to (errno.h):
>
>#define	ENETUNREACH	51		/* Network is unreachable */
>#define	EHOSTUNREACH	65		/* No route to host */
>
>Entries in that array which are 0 do not cause user errors.  Patching
>8 & 9 to zero should do this.
>
>Here's an example.  Be careful to use lower case `w'.
>
># adb -w /vmunix /dev/kmem
>inetctlerrmap?w0				patches disk
>inetctlerrmap/w0				patches memory
>
>I have not tried this, no guaruntees.  It looks like this works in
>4.3bsd, Ultrix 2.2, and SunOS 3.5.
>
>It still is not the optimal solution, which would be to pass a warning
>to the user layer, so they could decide what to do.  I suspect that is
>why there is a /* XXX */ at the end of tcp_ctlinput() in tcp_subr.c.
>(/* XXX */ is Berkeley shorthand for kludge, should be fixed.)  There
>are no comments on the entire subroutine.
>
>Any 4.3bsd gurus out there like to verify this?
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 20:01:52 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: syntax of remote pathnames?

Some of us old-timers have used the convention of putting the host name in
square brackets in "[host]path" format, e.g.:
	[WSMR-SIMTEL20.ARMY.MIL]PD1:<MSDOS.NEMACS>EM39EXE.ARC
	[SUMEX-AIM.STANFORD.EDU]info-mac/app/contour81.hqx
	[SAIL.STANFORD.EDU]MONCOM.UPD[S,DOC]
	[AI.AI.MIT.EDU].INFO.;DDT ORDER

The path field is, of course, dependent upon the target operating system and,
as the final example shows, can be bizarre, so you need some reasonable way
to infer the path out of context (e.g. using all uppercase, or make it be a
wholeline, etc...).

-------

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 21:05:47 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

Steve,

There is no distribution list for the IAB report at present. It should be
called a "bulletin", implying publication on an irregular basis as the
need arises (after an IAB meeting, generally).  We will distribute all future
IAB reports/bulletins to the TCP-IP list.

Bob Braden

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 21:10:22 GMT
From:      dpz@pilot.njin.net (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   YARD tool addendum - kernel fixes


src/rr.shar on rutgers.edu, available via anonymous FTP, is a shar of two
kernel fixes that you will have to make to a target 4.3BSD networking-derived
system to reflect the record route IP options back correctly.

						David
-- 
			 David Paul Zimmerman
 the Rutgers Dormitory Networking Project, the UUCP Project, etc, etc
 dpz@pilot.njin.net       rutgers!dpz       dpzimmerman@zodiac.bitnet

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 23:40:00 GMT
From:      almquist@JESSICA.STANFORD.EDU (Philip Almquist)
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain resolver resets needed

Terry,
> The current refresh entry should satisfy this need if the changes are
> expected in advance.  A week before the change, set the refresh
> interval to 24 hours.  Hosts will begin using the 24 hour interval
> when their current info expires.  One day before the change, set the
> refresh interval to something smaller, perhaps 2 or 4 hours.  When the
> change is made, hosts will only be using the wrong addresses for at
> most 2-4 hours.  When things are stable, change back to your normal
> refresh interval.
	The idea is right, but you used the wrong words and therefore
might confuse somebody.  There is a field in the SOA record called the
REFRESH interval, but that is not what you were referring to above.

	What he does want to decrease is the TTLs associated with the
records that are going to change.  Since no record may have a TTL
smaller than the zone MINIMUM TTL (another phrase from RFC 1035), he
may well have to change the zone MINIMUM TTL.

						Philip

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 23:43:25 GMT
From:      dla@athena.mit.edu (Don Alvarez)
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

The most important part of any public-key system is the key distribution
method.  I can "break" any public key encryption scheme, no matter how
robust the algorithm, if you aren't sufficiently careful about distributing
the public keys.

Consider the case of secure communications between your workstation and a
file server which is located on another machine.  Suppose that you have
never used this file server before (not a critical assumption, but it makes
the argument simpler).  You call up some kind of directory service to get
the public key for that file server.  Lets assume that it is a perfect
world, and that you are rightly confident that only one machine on the net
knows the private counterpart to that key, and also rightly confident that
the algorithm is unbreakable.  You now enter into a communication with the
file server using the public key that the directory service has told you 
belongs to the file server to get your private data.  No other machine can
read what you and the file server say to each other, so you are "safe", right?

Wrong.  All you know is that only one machine can read what you say.  You
don't as yet have any way to know that you are really talking to *your* file
server.  You don't even know that you are talking to a file server at all.
Suppose I got on the net and started masquerading as the directory service.
You say "what's the public key of FOOBAR fileserver?"  My fraudulent directory
server intercepts the request and gives you a different public key. The private
counterpart to the public key you just received is known to a confederate of 
mine.  You send your request to (what you believe to be) the file server
encrypted in that public key, along with any info needed to authenticate
yourself to the file server.  The confederate then calls the "real" directory
server, gets the "real" public key of the "real" file server, and passes the
request on to it.

The file server then calls the "directory service" to find *your* public key,
so that it can encrypt any files it needs to send to you.  That request gets
intercepted too, and now the file server sends your data out encrypted in a
key which no one but my confederate can read.  The confederate decrypts
whatever the real fileserver sends back, copies it, and then sends it on to
you reencrypted this time in your true private key.

Your communications have just been completely penetrated, and I never broke a
single code.  

The info posted to this group has implied that keys need to be registered 
with some central body.  Presumably what happens is that the central body
encrypts your name into the public half of your key in some way when it is
created.  Then whenever someone gives you a public key, you can run the 
key through a black box and out will pop the name of the party registered
as owning the private component of the key.  I would argue that if that is
what is done, it is probably not as effective a solution as I would have
liked (a large organization will probably end up with zillions of keys whose
owners have names like FOOBAR_INC:this_machine and FOOBAR_INC:that_machine.
If you don't know what machine your service resides on (suppose many machines
can offer the service, or something similar), I could misappropriate
any valid FOOBAR_INC key any publish it as the key for the other server I want
to penetrate).  As I say, I don't know if that is how it works or not.  If
it is, I'd argue that it is very much not the final solution, but it is at
least a decent starting point.

One thing I will say is that I am VERY heartened to discover that the
committee which picked this scheme is chaired by Stephen Kent.  I've never
met him, but anybody interested in topics like this should DEFINITELY check
out the article he and Victor Voydock wrote in Computing Surveys, Vol. 15,
No. 2, June 1983 (Computing Surveys may be filed under Assoc. of Computing
Machinery in your library).  The article is about forty pages long, readable
by the layman, and in my opinion is probably the best thing ever written on
the subject of network security.  It's a survey article, and the title is
"Security Mechanisms in High-Level Network Protocols".

So, in short, I'd say that the most important technical question to be asked
is how do you know that you can trust the public key you are given.  I don't
know the answer, but the presence of Mr. Kent's name on the committee makes
me think that there will probably be some good way to do so.

					- Don Alvarez

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   boomer@SPACE.MIT.EDU      77 Massachusetts Ave   37-618   |
     |   (617) 253-7457            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 89 23:57:41 GMT
From:      LARSON@KL.SRI.COM (Alan Larson)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain resolver resets needed

Keith Petersen mentioned the need to update domain resolver caches,
noting that it would be 5 days before hosts with domain servers know
that they have made an address change.

Not quite true.  Some hosts will (randomly) have almost expired data
in their local cache, this data will expire in less than five days.
Other hosts that didn't have the address at all, will work instantly.

In any case, this problem need not have occured.  I include excerpts
from two RFCs on the subject:

   -   -   -   -

From RFC1033, "DOMAIN ADMINISTRATORS OPERATIONS GUIDE"

   Most host information does not change much over long time periods.  A
   good way to set up your TTLs would be to set them at a high value,
   and then lower the value if you know a change will be coming soon.
   You might set most TTLs to anywhere between a day (86400) and a week
   (604800).  Then, if you know some data will be changing in the near
   future, set the TTL for that RR down to a lower value (an hour to a
   day) until the change takes place, and then put it back up to its
   previous value.

From RFC1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES"

...  If a change can be anticipated, the TTL can be reduced prior to
the change to minimize inconsistency during the change, and then
increased back to its former value following the change.

   -   -   -   -


	Alan
-------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 89 04:40:05 GMT
From:      glen@aecom.YU.EDU (Glen M. Marianko)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Network graphical map software wanted

I'm looking for a graphical software package that would allow me to
document pictorially the layout of a local area internetwork,
showing with lines and boxes the connections between nodes, gateways
and brides.  Something like drawing it on paper, but "smart" in that
if I move a segment, all the nodes on it follow.  Maybe it could
even use the services on the cable, like a nameserver, to fill in
the blanks about individual nodes w/o having to maintain dual databases.

My environment is primarily ethernet, with some localtalk - however
it should be generic enough to display any network topology.  The
primary protocols on the wire are TCP/IP, Appletalk and Novell SPX.

Now, I have seen some products that offer something like this, but
they are often combined with other features I don't need/want.
Example: Proteon's SNMP management station - give me the mapping,
keep the SNMP for now.  Or, HP's new product recently demoed at
Interface '89 in NY where you sprinkle $8K boxes around your net
and get a picture as well as statistics - keep the stats, gimme
the picture.

Anything just pictures out there (no MacDraw or PC Paintbrush or
good 'ole paper suggestions please)?

-- Glen Marianko
    glen@aecom.yu.edu

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 89 12:27:06 GMT
From:      goldstei@NSIPO.NASA.GOV (Steve Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: syntax of remote pathnames?

S*T*O*P !!!!!

You all are making things start to look like [you should pardon the 
expression . . .]

				VMS !!!

Part of the beauty of using UNIX is that one needn't have to recall all
the different decorations for hosts, devices, directories, etc. in specifying
a file.  (That's a feature of VMS which drives me up the wall!)

--SG

	 Some of us old-timers have used the convention of putting the host nam
	e in
	 square brackets in "[host]path" format, e.g.:
	 	[WSMR-SIMTEL20.ARMY.MIL]PD1:<MSDOS.NEMACS>EM39EXE.ARC
	 	[SUMEX-AIM.STANFORD.EDU]info-mac/app/contour81.hqx
	 	[SAIL.STANFORD.EDU]MONCOM.UPD[S,DOC]
	 	[AI.AI.MIT.EDU].INFO.;DDT ORDER

	 The path field is, of course, dependent upon the target operating syst
	em and,
	 as the final example shows, can be bizarre, so you need some reasonabl
	e way
	 to infer the path out of context (e.g. using all uppercase, or make it
	 be a
	 wholeline, etc...).

	 -------

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 89 15:27:41 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain resolver resets needed

When uunet.uu.net (also a very popular host) changed from 192.12.141.129 to
192.48.96.2 I did exactly as everyone suggested. A week before
the expected change, I dropped the TTL to a day. The day before the
move, I dropped it to 4 hours. After the move, I of course
raised it to 10 days.

It worked just like it was supposed to. Domain server sites didnt
notice any difference. host.txt sites thrashed for a few days until
the updated hosts.txt was available.

--rick

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 89 15:28:09 GMT
From:      ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain resolver resets needed

In article <KPETERSEN.12480089674.BABYL@WSMR-SIMTEL20.ARMY.MIL> w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) writes:
>On Monday March 20 a large number of Milnet hosts changed their
>network addresses.  Simtel20 was one of those.  I've been getting a
>lot of complaints from users on other hosts who cannot connect to
>Simtel20 with FTP.  We are also not receiving mail from a number of
>hosts which are reporting "connection refused".
>
>The problem can be solved by restarting your domain resolver so it
>will pick up the new address for Simtel20 and the many other hosts
>whose addresses changed.

This shouldn't be necessary.  I mean, while it is necessary, it shouldn't
be.  If the TTL (time-to-live) on these entries were set to a short period
of time (say a coupla hours or something) in advance, then set back to their
usual large values afterward, any change in information would be picked up
quickly by other name-domain-servers.

>
>This points out the need for some mechanism to update domain resolver
>caches before their expiration so that when address changes occur they
>do not result in loss of connectivity.  In our case it will be five
>days before hosts with domain servers know that we have made the
>address change.  Meantime they are all trying to connect to
>whitesands-mil-tac which now has our old address.

The BIND operations guide suggests the use of low TTL's in exactly this sort
of situation for exactly this reason.  Sure it would mean a *little* more
traffic and less efficient use of caching, but only temporarily.



Andy

--
Andy Poling						andy@gollum.hcf.jhu.edu
Network Services Group					ecf_hap@jhunix.UUCP
Homewood Academic Computing				ECF_HAP@JHUVMS.BITNET
Johns Hopkins University

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 89 17:48:46 GMT
From:      wcs@skep2.ATT.COM (Bill.Stewart.[ho95c])
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   TCP/IP vs. OSI Performance

Well, OSI seems to be the wave of the future :-), so we might as well
get used to it.  I'm working on several projects that will be using
OSI-based protocols, and I'm concerned about what the performance of
the system will be like.  OSI has a reputation for dogginess, but is it
really justified, or is it just that most implementations have been new
enough mot to be highly tuned yet?

One of the applications we're looking at will be using the misnamed
OSI IP internet protocol (ISO 8473) over X.25.  We know how the current
DoD IP based system performs - will an ISO-based system be about the
same speed, or slower, or faster?  

			Thanks;   Bill Stewart
-- 
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# Washington, DC.  Raining.  Long, cold, heavy rain.  Been raining for days.
# I was here last year in the spring.  It was raining like this then, too.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 89 20:29:14 GMT
From:      mo@prisma.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   filenames and punctuation

The real fact is that they are destination specific and this
is all silly.  Besides, I'm quite sure the dreaded ISOOSI tribe
will declare a standard for file names and everyone will be
forced to gratuitously convert the entire universe.

However, I can't help but mention that I've always believed
the the DEC OS people (probably from time immemorial)
have had a contest going to see who could use the greatest
number of different punctuation characters in a filename.
I guess that's because in their heart of hearts
they still think in RAD-50 and that noone would *EVER* want
to use those characters in a name, much less that anyone would
mind typing all those error-prone things.   Noooooooooo.

	"We be into keystrokes - lots of *DIFFERENT* keystrokes."

	Yours with tongue somewhat in cheek,

	-Mike

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 89 06:50:32 GMT
From:      joel@arizona.edu (Joel M. Snyder)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: TCP/IP vs. OSI Performance

8473 should perform at about the same speed as IP.  I implemented ISO IP
by editing DoD IP code and doing a bit of twiddling of the field
positions.  It turns out that ISO IP is more efficient in its use of
memory; you know at the first fragment the length of the entire message,
so you can preallocate.  Other than that, the protocols are almost
identical.  Of course, some of this depends on whether or not you've
been computing your IP checksum  (and your TCP checksum :-) :-) ).

Joel Snyder
U Arizona MIS Dep't
ANSI X3S3.7

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 89 21:39:04 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: TCP/IP vs. OSI Performance

>It turns out that ISO IP is more efficient in its use of
>memory; you know at the first fragment the length of the entire message,
>so you can preallocate...

I don't quite understand this. If you represent packets as linked lists of
dynamically allocated buffers, then there is no need with either DoD IP or
ISO 8473 to preallocate memory when reassembling fragments. You just keep
the pieces in a sorted linked list, with "fragment descriptors" telling you
where the holes are. As each fragment comes in, you trim off any overlap and
insert (link) it into the proper place.  When all the holes are filled in
and the last fragment (MF=0) has been received, you're done. I suspect
preallocating space means you intend to do memory-to-memory copying. It may
be easier to code, but it's best avoided for performance reasons.

It is true that knowing how long an entire datagram is could save you some
CPU time if you're so memory-starved that you won't be able to reassemble
it; you could toss all of the fragments as soon as you receive them instead
of running out of memory halfway through reassembly and having to toss the
partially reassembled datagram.  I don't see this as a big advantage,
though, since any system that runs out of memory often enough for this to be
a signficant performance factor is going to have many other, much more
serious problems.

One important factor re ISO 8473 performance that hasn't been mentioned yet
is its fetish for variable length fields. These are inherently harder to
deal with than DoD IP's nice fixed-length fields (IP options are rare enough
in most environments that they can be largely ignored as a performance
issue).  It's a *lot* easier to deal with 32-bit IP addresses on machines
that support native 32-bit integers than it will be to handle the monster
variable length byte strings that make up ISO addresses. Van Jacobsen once
commented to me that much of his header prediction work is likely to be
inapplicable to ISO.

Yet another excellent reason to question whether the whole ISO "trip" is
necessary -- as if the many reasons already stated aren't enough...

Phil

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 89 10:25:07 GMT
From:      blarson@skat.usc.edu (Bob Larson)
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain resolver resets needed

In article <8903231027.aa08575@SEM.BRL.MIL> tcs@BRL.MIL (Terry Slattery, SECAD) writes:
>The current refresh entry should satisfy this need if the changes are
>expected in advance.  [description of manually changing refresh time
ommited.]

Wouldn't it be better to give a specific exparation time to the name
server, so the name server caches would all expire at the proper time
without making the refresh interval to short or needing manual
intervention?  (Is this just a case of the available software doesn't
have this capability?)
-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 89 21:01:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Domain resolver resets needed

Settings for TTL values is out of our hands and handled by the NIC
under direction of DCA.  Unfortunately, the directions which DCA gave
the NIC did not include the TTL transition steps you and others
described for this last port address overhaul.  I am sure that they
are now aware and that future updates will include progressive TTL
change instructions.

--Frank

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Mar 89 09:16:22 EST
From:      Marshall Feldman <RLN101%URIACC.BITNET@mitvma.mit.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: LAN performance
I believe Michigan State tested a number of ethernet boards and decided
the Western Digital was most cost-effective.  There also was a review in
a recent issue of *PC* magazine.
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 14:16:22 GMT
From:      RLN101@URIACC.BITNET (Marshall Feldman)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN performance

I believe Michigan State tested a number of ethernet boards and decided
the Western Digital was most cost-effective.  There also was a review in
a recent issue of *PC* magazine.

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 14:55:21 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   MTU answers

These are the following answers that I received on my question on the proper
MTU to use on the Internet.  Obviously, there is a lot of ignorance out there
on the subject.  Consequently, I am posting barns@gateway.mitre.org (Bill
Barns) reply on the matter in a separate message (no need to pollute it
with the wrong answers in *this* message :-).  Each of the paragraphs
below is a separate response.
-russ

By the time you figure in headers and such, the Arpanet MTU should be
1006 because of limitation in 1822-connected hosts.  Bigger sizes work
poorly - so poorly that some can't use them at all.  Sigh.

MTU for X.25 links is 1024, and the MTU for 1822 is 1007(8).
I usually set my MTUs for 1000 just for conformance sake.
	
The maximum safe assumption for acceptable IP datagram size on the
Internet is 576 and this is documented both in the IP spec (under the
definition of the Total Length field) and in the forthcoming Host
Requirements RFC ...  The MTU of the BBN packet switching networks
(Milnet, Arpanet) is 1007 octets, but there are some problems with the
odd number on certain interface boards and it is widely assumed that
the usable MTU is 1006.

The mtu of milnet is 1006 bytes.  ...
Although there is no maximum MTU, gateways are allowed to fragment.

If your host is sending datagrams through a gateway with MTU > 576,
it (your host) is probably broken.

Now, on the otherhand, it has been realized by the Internet community
that things work alot better when the two peers of a connection use
the minimum "mtu" of the various networks traversed.  Consequently,
there has been work in the area of minimum mtu discovery via say an
ICMP or IP option.  Since there is no good way to discover the mtu,
some TCP/IP implimentations decide to use the minimum (512 + 64) if
they know that their route will pass through a gateway.  Obviously,
you don't want to use a minimum when peering with another host on
the same net.

BSD 4.3 assumes an MTU of 1536 (1500?) on local networks and 576 on
packets that go through a gateway.

    I have also found that anything above 1024 is risky (though I tend to
use 1024 rather than 1000 since the performance of many systems improves
with the use of 2^N data sizes).  Older TCP/IPs (and SUN OS 4.0 for some
reason) aren't all that kind about negotiating MTUs.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lama

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 14:57:10 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re:  MTU question

The maximum safe assumption for acceptable IP datagram size on the
Internet is 576 and this is documented both in the IP spec (under the
definition of the Total Length field) and in the forthcoming Host
Requirements RFC (draft obtainable from venera.isi.edu using anonymous
ftp and pathname /pub/ietf-hosts.rfc.txt - see section 3.3.2 and 3.3.3
for a full discussion of the whole issue).

The use of larger datagram sizes is permitted, but not guaranteed to work
with all hosts.  It is almost always safe to assume that a host can 
support what its connected networks support for an MTU, but even this
is not *required*.  The MTU of the BBN packet switching networks
(Milnet, Arpanet) is 1007 octets, but there are some problems with the
odd number on certain interface boards and it is widely assumed that
the usable MTU is 1006.

When you try to send 1500grams onto the Milnet (required to get to BRL
and AMSAA I would think) the gateway is having to perform IP fragmentation
to get down to the Milnet MTU.  Almost certainly it fragments into a 1006
and a 534 or so (remember, the IP header is needed on each fragment).  It
may be the case that something further down the wire does not like the
1006gram because that is too big for it.  Or it may be the case that your
gateway into Milnet is making a 1007gram and BRL has one of the boards that
does not speak 1007 successfully.  There are many possibilities, but if
you send 576's you should avoid all of them except truly broken systems.

Everybody is required to be able to handle fragmentation, and maybe
that is what Phil Karn was thinking of.  That is not the same as saying
that everybody is required to be able to reassemble the fragments of an
arbitrarily large IP DG.  They are required to be able to reassemble
fragments to put together a 576 DG, and it is recommended that they
handle the connected net(s) MTU, further recommended that the max
should be configurable so you can make it even bigger, and yet further
recommended that it handle unlimited sizes.  But those are
recommendations, not requirements.

It is a bad idea from a performance perspective to cause IP fragmentation.
The rationale has to do with source retransmissions causing cascades of
fragments, most of which are not needed to recover the actual error.  Also,
it tends to cause more data copying in gateways and the destination IP.
So, current thinking is that we should be trying to determine the smallest
MTU of a path, and construct our DGs to that size.  There are a couple of
schemes for doing this dynamically, none of which are really standards
at this point, but it is an active area of thought.  The HR RFC alludes to
some of this.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
If you can, help others.
If you can't, at least don't hurt others--the Dalai Lama

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 18:39:05 GMT
From:      ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling)
To:        comp.protocols.tcp-ip
Subject:   Re:  Domain resolver resets needed

In article <16103@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes:
>Wouldn't it be better to give a specific exparation time to the name
>server, so the name server caches would all expire at the proper time
>without making the refresh interval to short or needing manual
>intervention?  (Is this just a case of the available software doesn't
>have this capability?)


Ouch!  Can you imagine every caching nameserver in the country assaulting
the root servers all at once?

I (and I'm sure alot of others do this too) get a full download from the
root servers of the top-level domains which see alot of traffic here.  I can
do this because the host in question hasn't got much else to do.  When that
TTL runs down, I query the root servers to see if I have to down load again.
That would mean that every machine like mine would be requesting a download
within ten minutes of each other (five minute ns_maint sleep gives +/-5
minute spread from the target time).

I don't think the root server's administrators would like that idea.  :-)


Andy
--
Andy Poling						andy@gollum.hcf.jhu.edu
Network Services Group					ecf_hap@jhunix.UUCP
Homewood Academic Computing				ECF_HAP@JHUVMS.BITNET
Johns Hopkins University

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 19:12:15 GMT
From:      manager@a.coe.wvu.wvnet.edu (Cris Fuhrman, Systems Manager)
To:        comp.protocols.tcp-ip,comp.sys.encore
Subject:   An Annex by any other nameserver would smell...

Salut,

We have 3 Annex Terminal servers, connected via TCP/IP to our ethernet.  
The problem concerns the handling of host names.  Here's what happens:

After a server boots, one can access nodes outside of our local domain 
(i.e. outside of .wvnet.edu).  However, after a period of time, if one 
tries to access even the same node as before, the address is resolved, and 
the internet number is added to the cache hosts table, but the Annex 
responds with (an immediate response, i.e. no delay)

    Trying...
    CLI: Network is unreachable.

As I said, the nameserver features appear to be working, and in fact our 
ethernet is working, as I can telnet to remote hosts right after a boot.

Anyone have any input on this one?

Also, I have some related questions:

    1)  What's the difference between BIND, IEN_116, and RWOD name servers?
    2)  Are the RWOD machines the ones that show up in the hosts table with
        a system load factor?

I have a couple of other minor questions about Annex configurations in 
general, and I'd like to pick someone's brain about them if they'd be 
willing to exchange some info.

-Cris
-- 
  /''''--''''''''''''''''.  Cris Fuhrman, Systems Manager''''''''''''''/
 /    /  \               .  WVU College of Engineering                /
<    |      __   o       .  Morgantown WV 26506-6101                 <
 \   |     )  |  |  /\   .  internet:  manager@a.coe.wvu.wvnet.edu    \
  \...\___/...|_/|_/__).....bitnet:....manager%wvucoe@wvnvms...........\
              Plus ca change, plus c'est la meme chose.

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 19:58:31 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension


Kenneth,

Your original message on this topic triggered a fairly constructive blast
of messages (about 35?).  I think you should plow ahead with your
proposal.  A useful approach might be to set up a "Birds-of-a-Feather"
session of VMS vendors at a future IETF meeting, to draft a spec.

I suggest you leave to the Protocol Czar Jon Postel the decision on
syntactic sugar, "STRU xxx" vs. "STRU O xxx" vs. "SITE STRU xxx", etc.
Don't waste any more time on it.  You (the set of VMS vendors) need to do
the hard work, documenting the contents and format for VMS (analogous to
Appendix I of RFC-959).

It should be noted that STRU P (PAGE structure) is in reality "STRU O
TENEX", or  "STRU O TOPS20."  FTP would have been cleaner as a
protocol and more powerful, I think, if we had adopted your idea years
ago, and recognized that STRU P was just one example of a class of
service that FTP ought to provide -- efficient operating-system-specific
transfers.

Bob Braden

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Mar 89 09:27:22 -0800
From:      Marshall Rose <mrose@TWG.COM>
To:        multiple-lists: ;
Subject:   ISODE 5.0 release notice
Sorry for the multiple postings...

/mtr
///////

			  A N N O U N C E M E N T


    The next release of the "ISO Development Environment" will be
    available on 28 March 1989.  This release is called

				   ISODE 5.0

    This software supports the development of certain kinds of OSI protocols
    and applications.  Here are the details: 

  - The ISODE is not proprietary, but it is not in the public domain.  This was
    necessary to include a "hold harmless" clause in the release.  The upshot
    of all this is that anyone can get a copy of the release and do anything
    they want with it, but no one takes any responsibility whatsoever for any
    (mis)use.

  - The ISODE runs on native Berkeley (4.2, 4.3) and AT&T (SVR2, SVR3) systems,
    in addition to various other UNIX-like operating systems.  No kernel
    modifications are required.

  - Current modules include:
	OSI transport service (TP0 on top of TCP, X.25, and CONS;
	    TP4 for SunLink OSI)
	OSI session, presentation, and association control services
	ASN.1 abstract syntax/transfer notation tools, including:
	    remote operations stub-generator (front-end for remote operations)
	    structure-generator (ASN.1 to C)
	    element-parser (basic encoding rules)
	OSI reliable transfer and remote operations services
	OSI file transfer, access and management
	FTAM/FTP gateway
	OSI directory services
	OSI virtual terminal (basic class, TELNET profile)

  - ISODE 5.0 consists of final "IS" level implementations with a few
    exceptions: ROSE and RTSE are current to the last circulated drafts
    (March, 1988); VT is a DIS implementation.  The ISODE also contains
    implementations of the 1984 X.400 versions of ROS and RTS.  ISODE is
    aligned with the U.S. Government OSI Profile (GOSIP).

  - Modules planned for future releases include:
	OSI message handling system
	MHS/SMTP gateway

  - Although the ISODE is not "supported" per se, it does have a problem
    reporting address, Bug-ISODE@TWG.COM.  Bug reports (and fixes) are welcome
    by the way. 

  - The discussion group ISODE@SRI-NIC.ARPA is used as an open forum on ISODE.
    Contact ISODE-Request@SRI-NIC.ARPA to be added to this list.

  - The primary documentation for this release consists of a four volume
    User's Manual (approx. 900 pages) and a set of UNIX manual pages.  The
    sources to the User's Manual are in LaTeX format.  In addition, there are
    a number of notes, papers, and presentations included in the documentation
    set, again in either LaTeX or SLiTeX format.  If you do not have LaTeX, you
    should probably get a hardcopy from one of the distribution sites below.

  - Although ISODE is an openly available implementation of the upper-layers of
    OSI, it is primarily a development environment.  As such, it contains many
    tools and libraries to aid the development process.  Volume 4 of the User's
    Manual, "The Applications Cookbook", has several recipies for automating
    the implementation of OSI applications which use remote operations.  This
    includes use of a stub-generator for remote operations macros, a structure-
    generator to produce equivalent C structs for the ASN.1 type definitions
    used by the application, and so on.  Experience has shown that use of these
    tools can drastically accelerate building distributed applications. 

    For more information, contact:

        The Wollongong Group
        Attn: Marshall T. Rose
        1129 San Antonio Road
        Palo Alto, CA  94303
	USA

        +1-415-962-7100

    There are several ways to get a distribution:

 1. FTP
    If you can FTP to the Internet, you can use anonymous FTP to
    spam.istc.sri.com [10.2.0.107] and retrieve the file portal/isode-5.tar in
    BINARY mode.  This is a 10.5MB tar image.  The file portal/isode-5.tar.Z
    is the tar image after being run through the compress program (3.5MB).  
    The compressed file is also available from the host nisc.nyser.net
    [192.33.4.10] via anonymous FTP in the pub/isode/ directory.

 2. NIFTP
    If you run NIFTP over the public X.25 or over JANET, and are registered in
    the NRS at Salford, you can use NIFTP with username "guest" and your own
    name as password, to access UK.AC.UCL.CS to retrieve the file
    <SRC>isode-5.tar.  This is a 10.5MB tar image.  The file <SRC>isode-5.tar.Z
    is the tar image after being run through the compress program (3.5MB).

 3. NORTH AMERICA
    For mailings in NORTH AMERICA, send a check for 365 US Dollars to:

	University of Pennsylvania
	Department of Computer and Information Science
	Moore School
	Attn: David J. Farber (ISODE Distribution)
	200 South 33rd Street
	Philadelphia, PA 19104-6314
	USA

        +1-215-898-8560

    The tape will be written in tar format at 1600bpi, and returned with a
    documentation set.  Do not send tapes or envelopes.  Documentation only is
    the same price.


  Page 2

 4. EUROPE (tape and documentation)
    For mailings in EUROPE, send a cheque or bankers draft and a purchase order
    for 200 Pounds Sterling to:

        Department of Computer Science
        Attn: Natalie May/Dawn Bailey
        University College London
        Gower Street
        London, WC1E 6BT
        UK

    For information only:
	Telephone:	+44-1-380-7214
	Fax:		+44-1-387-1397
	Telex:		28722
	Internet:	natalie@cs.ucl.ac.uk, dawn@cs.ucl.ac.uk

    Specify either (a) 1600bpi 1/2-inch tape, or (b) Sun 1/4-inch
    cartridge tape.  The tape will be written in tar format and returned
    with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 5. EUROPE (tape only)
    Tapes without hardcopy documentation can be obtained via the European
    UNIX User Group (EUUG). The ISODE 5.0 distribution is called EUUGD14.
    
          EUUG Distributions
          c/o Frank Kuiper
          Centrum voor Wiskunde en Informatica
          Kruislaan 413
          1098 SJ  Amsterdam
          The Netherlands

    For information only:
          Telephone:	+31-20-5924121 (or: +31-20-5929333)
          Telex:	12571 mactr nl
	  Telefax:	+31-20-5924199
          Internet:	euug-tapes@cwi.nl (euug-tapes@mcvax.uucp)

    Specify one of:
	- 1600bpi 1/2-inch tape:			120 Dutch Guilders
	- 800bpi 1/2-inch tape:				120 Dutch Guilders
	- Sun 1/4-inch cartridge tape (QIC-24 format):	180 Dutch Guilders
	- 1/4-inch cartridge tape (QIC-11 format):	180 Dutch Guilders

    If you require DHL this is possible and will be billed through.  Note that
    if you are not a member of EUUG, then there is an additional handling fee
    of 300 Dutch Guilders (please enclose a copy of your membership or
    contribution payment form when ordering).  Do not send money, cheques,
    tapes or envelopes, you will be invoiced.







  Page 3

 6. AUSTRALIA and NEW ZEALAND
    For mailings in AUSTRALIA and NEW ZEALAND, send a cheque for 250 dollars
    Australian to:  

	CSIRO DIT
	Attn: Andrew Waugh (ISODE DISTRIBUTION)
	55 Barry St
	Carlton, 3053
	Australia

	+61-3-347-8644

    The tape will be written in tar format at 1600bpi, and returned with a
    documentation set.  Do not send tapes or envelopes.  Documentation only is
    the same price.

 7. FTAM on the JANET or PSS
    The sources are available by FTAM at UCL over X.25 using JANET
    (00000511160013) or PSS (23421920030013) with TSEL "259" (ascii encoding).
    Use the "anon" user-identity, supply any password, and retrieve the file
    src/isode-5.tar.  This is a 10.5MB tar image.  The file src/isode-5.tar.Z
    is the tar image after being run through the compress program (3.5MB).

 8. FTAM on the Internet
    The sources are available by FTAM at SRI over the Internet at host
    spam.istc.sri.com [10.2.0.107] (TCP port 102 selects the OSI transport
    service) with TSEL 259 (numeric encoding).  Use the "anon" user-identity,
    supply any password, and retrieve the file portal/isode-5.tar.  This is a
    10.5MB tar image.  The file portal/isode-5.tar.Z is the tar image after
    being run through the compress program (3.5MB).  

    For distributions via FTAM, the file service is provided by the FTAM 
    implementation in ISODE 5.0.

    If you wish to use the FTAM implementation in ISODE 4.0, which was a DIS
    implementation of FTAM but with an IS implementation of the rest of the
    stack (i.e., association control, presentation, and so on), use TSEL 258
    instead (ascii encoding at UCL, and numeric encoding at SRI).  This older
    service is temporary and is provided for bootstrap purposes only.

    For distributions via either FTAM or FTP, there is an additional file
    available for retrieval, called isode-ps.tar.Z which is a compressed tar
    image (5MB) containing the entire documentation set in PostScript format.














  Page 4

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 89 22:51:00 GMT
From:      gupta@uxe.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   POP


Hi - I'm just starting to learn about networking and this is the first time
that I've been on this notesfile. I've done a lot of reading on TCP-IP. I am
now interested in learning more about POP (Post Office Protocol). If
anyone has any info/references on this, then please email to:

---
Rohit Gupta 	          Internet:   gupta%uxe.cso.uiuc.edu@uxc.cso.uiuc.edu
P. O. Box 2828 - Sta A    UUCP: uunet!uiucuxc!uxe!gupta
Champaign, IL 61820       Bitnet: gupta@vmd.cso.uiuc.edu  gupta@UIUCVMD

Sam: "Say 'hello' to Alice and the twins for me"
Jack: "Twins? It's triplets."
Sam: "TRIPLETS!? My how time flies..."
					- Brazil

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 08:46:00 GMT
From:      bernsten@phoenix.Princeton.EDU (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

In article <10061@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes:
> The most important part of any public-key system is the key distribution
> method.  I can "break" any public key encryption scheme, no matter how
> robust the algorithm, if you aren't sufficiently careful about distributing
> the public keys.

Your argument is mostly based on a fake directory service providing
false encryption keys. As most discussions of public-key systems point
out, the solution to this is easy. (See, e.g., volume 2 of Knuth.)

Let's say X wants to send a message to Y. Given that unencrypted data
and encrypted data come from the same alphabet, X *decrypts* a message
by his encryption function, signs it, encrypts it by Y's function, and
sends it to Y. Y then receives it, decrypts it by Y, checks the signature
to find out X's identity, and then *encrypts* it by X.

X can be confident that only Y can read the message since only Y knows
Y's decryption function. Y can be confident that only X could have sent
the message since only X knows X's decryption function---otherwise the
final message would be garbage. Thus public-key systems (with the same
set of unencrypted and encrypted data) naturally provide sender
authentication as well as privacy.

How does this apply to the directory service D? There is only a single
encryption function, ED, that must be distributed widely. This single
key becomes common, public knowledge; the average sysadmin will know
the number by heart. Assuming only that this single key can be
distributed safely at the beginning of time, the directory can then
send out *signed* messages containing further keys. (The messages
should contain recognizable format information, or at least a few
checksums, to prevent complete screwups.)

Of course, that encryption function will become the world's most
carefully scrutinized. If someone could find out the directory's
decryption, they could indeed begin masquerading as the directory,
thus posing the security risks you bring up. Thus that directory
encryption function must be chosen very carefully---if RSA, it should
probably be several hundred digits long where three hundred is usually
considered safe, and should probably involve quadruple application
of the key choice method in Knuth rather than double. The decryption
must also be protected very carefully, with a paranoia previously
unheard of.

> The info posted to this group has implied that keys need to be registered 
> with some central body.  Presumably what happens is that the central body
> encrypts your name into the public half of your key in some way when it is
> created.

Why? This seems to me to imply an unnecessary security risk. You want
a mapping from user to key, not from key to user. The latter wouldn't
prevent any security problems; if you claim a key is yours, it can be
checked with the directory service, and I don't think there would be
any reason that ``we have to find out who owns this key!''

> So, in short, I'd say that the most important technical question to be asked
> is how do you know that you can trust the public key you are given.

This reduces to the question of how secure we can make a carefully
chosen single example of a single encryption method: the directory's
encryption function.

---Dan Bernstein, bernsten@phoenix.princeton.edu

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 11:58:46 GMT
From:      rsalz@bbn.com (Rich Salz)
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

The shortest way to ask this question is to be somewhat flip about
it, but I don't mean to be -- it's something I really would like to
know:
	What steps are being taken to ensure that the one group
	that holds the keys to secure Internet mail won't be
	selling them to the Russians?

Reply to me, I'll summarize.
	/rich $alz
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 13:47:14 GMT
From:      pquiring@ncrorl.Orlando.NCR.COM (Powell Quiring)
To:        comp.protocols.tcp-ip
Subject:   wanted tcp/ip streams source

We need tcp, ip, arp, rarp, udp, icmp, ...  driver source for a streams based system. 
We need some of the applications also.  If possible public domain would be great.  If
not streams based I would still like to here about it. It is possible we would pay
for this, maybe one time purchase of the source.

Powell Quiring
pquiring@Orlando.NCR.COM	..!ncrlnk!ncrorl!pquiring

VOICE: (407) 333-9250,     FAX: (407) 333-0050

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 14:10:43 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  syntax of remote pathnames?

If you are serious about coming up with a generic standard for remote
file names (something that could be an RFC, say), then you have to
recognize the fact that file names (aka path names) can be pretty arbitrary.
FTP constrains them not to contain CRLF (I think...), but one could even
imagine a file system that allowed CR, LF, or CRLF in a pathname.  More
importantly, pathnames often depend on login information.  In addition to
Unix-style relative pathnames, remember that many implementations do the
equivalent of a Unix chroot() when you log in as ANONYMOUS, so the directory
tree is substantially different from what a use logging in with some other
user ID would see.

A widely used and fairly robust syntax for specifying remote file names
is:
	<hostname>"<login information>"::<pathname>CRLF

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 18:00:25 GMT
From:      bruce@ssc-vax.UUCP (Bruce Stock)
To:        comp.protocols.tcp-ip
Subject:   Proxy Arp -- How is it Implemented?


After reading many references to the use of proxy arp, I decided to consult
RFC 925 to get the details.  The description there did not match the
mechanism I had mentally envisioned from descriptions of what proxy arp does.

In brief, the RFC describes a mechanism for extending the arp reply service
by expanding the arp cache in the gateway, via a somewhat elaborate means,
to include end systems which the gateway can get to on other networks.  

From reading about the service offered by proxy arp elsewhere, I had
assumed that a gateway would implement it not by an expansion of the arp cache,
but by coupling arp with the routing table.  E.G.:
	1. Recieve Arp request
	2. Consult routing table to see if I can reach the destination
	3. If I can, reply to the arp with my physical address
	4. If not, do nothing.

So my question is:  How is it done in the real world?  Per RFC925, per above,
or otherwise?


		Regards,  Bruce Stock
			uw-beaver!ssc-vax!bruce

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 18:48:19 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   terminal types/assigned numbers

A number of people are currently having problems because the list of Official
Terminal Type Names in RFC 1010, "Assigned Numbers", is incomplete (RFC 1010 was
published in May 1987).  A new Assigned Numbers RFC is scheduled to be published
soon.  I have volunteered (silly me :-) ) to collect a new list of official
names to be published in the next RFC.  If you have a favorite terminal which is
currently unlisted, please send me a short note including the manufacturer,
terminal name/model and suggested official name.  I will collect all responses
and forward them to the RFC authors.

Drew

The following is the current list of official terminal type names taken form RFC
1010:

RFC 1010 - Assigned Numbers                                     May 1987
Terminal Type Names


                          TERMINAL TYPE NAMES

   These are the Official Terminal Type Names.  Their use is described
   in RFC 930 [97].  The maximum length of a name is 40 characters.

   A terminal names may be up to 40 characters taken from the set of
   uppercase letters, digits, and the two punctuation characters hyphen
   and slash.  It must start with a letter, and end with a letter or
   digit.

   ADDS-CONSUL-980
   ADDS-REGENT-100
   ADDS-REGENT-20
   ADDS-REGENT-200
   ADDS-REGENT-25
   ADDS-REGENT-40
   ADDS-REGENT-60
   AMPEX-DIALOGUE-80
   ANDERSON-JACOBSON-630
   ANDERSON-JACOBSON-832
   ANDERSON-JACOBSON-841
   ANN-ARBOR-AMBASSADOR
   ARDS
   BITGRAPH
   BUSSIPLEXER
   CALCOMP-565
   CDC-456
   CDI-1030
   CDI-1203
   CLNZ
   COMPUCOLOR-II
   CONCEPT-100
   CONCEPT-104
   CONCEPT-108
   DATA-100
   DATA-GENERAL-6053
   DATAGRAPHIX-132A
   DATAMEDIA-1520
   DATAMEDIA-1521
   DATAMEDIA-2500
   DATAMEDIA-3025
   DATAMEDIA-3025A
   DATAMEDIA-3045
   DATAMEDIA-3045A
   DATAMEDIA-DT80/1
   DATAPOINT-2200
   DATAPOINT-3000
   DATAPOINT-3300
   DATAPOINT-3360
   DEC-DECWRITER-I
   DEC-DECWRITER-II
   DEC-GT40
   DEC-GT40A
   DEC-GT42
   DEC-LA120
   DEC-LA30
   DEC-LA36
   DEC-LA38
   DEC-VT05
   DEC-VT100
   DEC-VT132
   DEC-VT50
   DEC-VT50H
   DEC-VT52
   DELTA-DATA-5000
   DELTA-TELTERM-2
   DIABLO-1620
   DIABLO-1640
   DIGILOG-333
   DTC-300S
   EDT-1200
   EXECUPORT-4000
   EXECUPORT-4080
   GENERAL-TERMINAL-100A
   GSI
   HAZELTINE-1500
   HAZELTINE-1510
   HAZELTINE-1520
   HAZELTINE-2000
   HP-2621
   HP-2621A
   HP-2621P
   HP-2626
   HP-2626A
   HP-2626P
   HP-2640
   HP-2640A
   HP-2640B
   HP-2645
   HP-2645A
   HP-2648
   HP-2648A
   HP-2649
   HP-2649A
   IBM-3101
   IBM-3101-10
   IBM-3275-2
   IBM-3276-2
   IBM-3276-3
   IBM-3276-4
   IBM-3277-2
   IBM-3278-2
   IBM-3278-3
   IBM-3278-4
   IBM-3278-5
   IBM-3279-2
   IBM-3279-3
   IMLAC
   INFOTON-100
   INFOTONKAS
   ISC-8001
   LSI-ADM-3
   LSI-ADM-31
   LSI-ADM-3A
   LSI-ADM-42
   MEMOREX-1240
   MICROBEE
   MICROTERM-ACT-IV
   MICROTERM-ACT-V
   MICROTERM-MIME-1
   MICROTERM-MIME-2
   NETRONICS
   NETWORK-VIRTUAL-TERMINAL
   OMRON-8025AG
   PERKIN-ELMER-1100
   PERKIN-ELMER-1200
   PERQ
   PLASMA-PANEL
   QUME-SPRINT-5
   SOROC
   SOROC-120
   SOUTHWEST-TECHNICAL-PRODUCTS-CT82
   SUPERBEE
   SUPERBEE-III-M
   TEC
   TEKTRONIX-4010
   TEKTRONIX-4012
   TEKTRONIX-4013
   TEKTRONIX-4014
   TEKTRONIX-4023
   TEKTRONIX-4024
   TEKTRONIX-4025
   TEKTRONIX-4027
   TELERAY-1061
   TELERAY-3700
   TELERAY-3800
   TELETEC-DATASCREEN
   TELETERM-1030
   TELETYPE-33
   TELETYPE-35
   TELETYPE-37
   TELETYPE-38
   TELETYPE-43
   TELEVIDEO-912
   TELEVIDEO-920
   TELEVIDEO-920B
   TELEVIDEO-920C
   TELEVIDEO-950
   TERMINET-1200
   TERMINET-300
   TI-700
   TI-733
   TI-735
   TI-743
   TI-745
   TYCOM
   UNIVAC-DCT-500
   VIDEO-SYSTEMS-1200
   VIDEO-SYSTEMS-5000
   VISUAL-200
   XEROX-1720
   ZENITH-H19
   ZENTEC-30

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 18:56:24 GMT
From:      dla@athena.mit.edu (Don Alvarez)
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

In article <7432@phoenix.Princeton.EDU> bernsten@phoenix.Princeton.EDU 
(Dan Bernstein) writes:
>In article <10061@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes:
>Let's say X wants to send a message to Y. [...]  X [uses his private key
>to encrypt a message], signs it, encrypts it by Y's public function, and
>sends it to Y. Y then receives it, decrypts it by Y[-private], checks the
>signature to find out X's identity, and then [decrypts the message using
>X's public key].
>
>X can be confident that only Y can read the message since only Y knows
>Y's decryption function. Y can be confident that only X could have sent
>the message _since_only_X_knows_X's_decryption_function_ ---otherwise the
>final message would be garbage. Thus public-key systems [...] provide sender
>authentication as well as privacy.
>
(emphasis added)

It is true that only X knows X's decryption function, but only X and the
public key directory know X's PUBLIC key for certain.  Everyone else has to
look up the public key in the directory service.

>How does this apply to the directory service D? There is only a single
>encryption function, ED, that must be distributed widely. This single
>key becomes common, public knowledge; [...] the directory service can then
>send out *signed* messages containing further keys.

I agree that if you only have one single directory service you can handle
things as you suggest.  On a network the size of the internet, with 10^5
or so people and many more companies, organizations, services, etc., each
needing their own keys, no one machine could possibly handle all the traffic
needed to dispense all the keys for everyones mailer and fileserver even if
keys have extended lifespans and caching is allowed.  You would kill the 
network with the volume of packets needed to handle the requests.  

Directory services need to be local and hierarchical, exactly the way
nameservers work on the net today.  That means if you want one single
directory service key, you have to give the private part to every
nameserver manager everywhere in the country.  Guess how long that
will stay secret.  You can't give different local nameservers
different keys without losing the generality of your single key.  Also,
consider what happens if somebody *leaks* your single key.  Every
operating system on every computer on the net has to be recompiled for
the new server key.

You can *perhaps* assume that there is a single directory service for looking
up local directory services, as in "who is the directory server for .FOOU.EDU",
but I'll bet even that traffic will kill the net, and you still run into the
problem of how do you change that single password without bringing the entire
net to a grinding halt.

>> So, in short, I'd say that the most important technical question to be asked
>> is how do you know that you can trust the public key you are given.
>
>This reduces to the question of how secure we can make a carefully
>chosen single example of a single encryption method: the directory's
>encryption function.

Nope, you can't do it with just one directory server.  You still need
something additional to provide trustability of the public key someone
hands you, and that something can not be just a simple
public-key-signed handshake, because any such handshake assumes you
already know the other guys' key.  There is no point in worrying about
security of encryption algorithms until you can solve the distribution
problem. 

>>--Don Alvarez,   boomer@space.mit.edu
>---Dan Bernstein, bernsten@phoenix.princeton.edu

----Don Alvarez,   boomer@space.mit.edu

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 89 20:32:07 GMT
From:      clements@bbn.com (Bob Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP "STRU VMS" extension

In article <8903271958.AA02597@braden.isi.edu> braden@VENERA.ISI.EDU writes:
> ...
>It should be noted that STRU P (PAGE structure) is in reality "STRU O
>TENEX", or  "STRU O TOPS20."  FTP would have been cleaner as a
>protocol and more powerful, I think, if we had adopted your idea years
>ago, and recognized that STRU P was just one example of a class of
>service that FTP ought to provide -- efficient operating-system-specific
>transfers.

Just as a small historic footnote, that's what the "tenex" thing
started as.  I wrote it, the first time.  It was in the NCP-based
FTP, pre-dating TCP.

As I implemented it (and put in some early RFC [which I can't
find -- I thought it was right between my Totally Awesome
Protocol spec and my SUDS manual]) ... Anyway, as I implemented
it the command was "TYPE XTP" and I proposed that "X" meant it
was reserved for use between consenting adults (er, compatible
systems), "T" was an example of the affected part of the
universe, here "TENEX", and "P" was the specific kludge being
added to the protocol, here a "Paged" file format.

(It was implemented in a panic over a weekend when we decided
to do a full file system transfer over the net for the first
time between two PDP-10s.)

(It also had checksums, for the first time.  NCP didn't have
checksums like TCP does, nor did NCP-based FTP.)

>
>Bob Braden
(Hi, Bob!)

/Rcc
clements@bbn.com

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 00:43:10 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: TCP/IP vs. OSI Performance

In article <14957@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
>>It turns out that ISO IP is more efficient in its use of
>>memory; you know at the first fragment the length of the entire message,
>>so you can preallocate...
>
>I don't quite understand this. If you represent packets as linked lists of
>dynamically allocated buffers, then there is no need with either DoD IP or
>ISO 8473 to preallocate memory when reassembling fragments.
> [...]
>It is true that knowing how long an entire datagram is could save you some
>CPU time if you're so memory-starved that you won't be able to reassemble
>it; you could toss all of the fragments as soon as you receive them instead
>of running out of memory halfway through reassembly and having to toss the
>partially reassembled datagram.  I don't see this as a big advantage,
>though, since any system that runs out of memory often enough for this to be
>a signficant performance factor is going to have many other, much more
>serious problems.

As Chris Kent and I wrote (after Dave Mills raised the issue) in our
paper "Fragmentation Considered Harmful" (SIGCOMM '87), one problem
is that because IP doesn't tell you how much space is needed, you
can run into pseudo-deadlock when several large packets are being
reassembled.

If the rate of incoming fragmented packets is high enough, it doesn't
matter how much memory you have, because the situation is unstable:
once you begin to run out of memory, you're likely to see new fragments
arrive faster than the old ones time out.

The real problem, of course, is that IP-style internetwork fragmentation
is generally a bad idea ("Harmful", in fact).  Issues of "efficiency
in the use of memory" are second-order compared to efficient mechanisms
for avoiding fragmentation.  I certainly agree with Phil that variable-
length fields are a false economy.

-Jeff

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Mar 89 07:44:14 LCL
From:      Peter Coleman <PCOLEMAN%MCMVM1.BITNET@CORNELLC.ccs.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: terminal types/assigned numbers
I noticed that the IBM 3151 was not included in the list of terminals.
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 03:06:12 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  syntax of remote pathnames?

jqj@HOGG.CC.UOREGON.EDU writes:
> one could even imagine a file system that allowed CR, LF, or CRLF
> in a pathname.

	You mean like the Unix file system?  To wit:

$ echo xxx* | od -c
0000000    x   x   x  \r  \n   y   y   y  \n
0000011
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu
"The connector is the network"

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 03:27:38 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   syntax of remote pathnames?


I'm having problems understanding all the baroque (or is that rococo?)
suggestions, let's try starting at the beginning...

A file system syntax (not semantics) is a string describing a point in
a data structure.

Most systems I know of use either arrays (ie. no directories, RT-11),
trees (Unix, MS/DOS) or forests (most DEC OS's, IBM/MVS, VM/CMS is a
forest of arrays I guess, degenerate case.)

I call them forests rather than funny-rooted trees since I don't
believe, given some path like [000000,000000]<foo.bar>stuff.xxx you
can add syntax to walk back up and down a different path a la Unix's
/foo/bar/../../down/down which is equvalent (well, usually, ahem) to
/down/down (ahh, symlinks...but I doubt you'll solve that problem here
nor even suggest trying.)

The question is how much SEMANTICS you want to build into the syntax.

Should the SYNTAX reflect that the first step off the root is a
username? Or is it sufficient to just let the remote O/S worry about
that translation? Thus something like <BZS.STUFF>ABC.DEF can be
represented as /bzs/stuff/abc.def and be easily interpreted.

That's really the major difference between Unix syntax and other OS's
being mentioned, Unix isn't using punctuation characters to indicate
semantics.

Now, I will point out that (having written a program to go between
TOPS-20 and Unix paths) there are potential ambiguities, although they
mostly fall into the "would someone really *do* that?" category, for
example, does:

	/foo/bar/baz.xxx

on a TWENEX system become:

	foo:<bar>baz.xxx

or

	<foo.bar>baz.xxx

?

They can both exist simultaneously and describe different files. The
same can be true for VMS and other OS's that have this sort of thing
for devices and logical names. Pity.

Is it sufficient to suggest that people avoid creating that potential
ambiguity if they want to be accessible (or at least only interpret
paths one way? I could imagine a local system optionally interpreting
/foo:/bar/baz.xxx as a device/logical name and /foo/bar/baz always as
<foo.bar>baz.xxx, not pretty.

I suppose the same can be said for hostnames (eg. /foo/bar, is foo a
local directory or a remote host?) It's been "solved" in every
conceivable way (//foo/bar is remote, /../foo/bar is remote, only
/remote/foo/bar is remote, etc etc.)

Of course, whatever we do won't fit the next thing coming around the
corner (I dunno, free-association concept array-driven file systems
with prescient error recovery.)

Anyhow, I think Keep It Simple might be a good plan for this one,
trying to cover every unusual case usually makes for a bad design
("hard cases make bad law".)

	-Barry Shein, Software Tool & Die

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 04:24:32 GMT
From:      welch@cheops.cis.ohio-state.edu (Arun Welch)
To:        comp.protocols.tcp-ip
Subject:   Re:  syntax of remote pathnames?


The Envos Medley lisp environment (originally known as Interlisp-D)
implementation uses a novel approach, namely to treat all filenames at
the user level in the local syntax, namely
{host}<dir>subdir>name.type;version, and provides a translation
function to the remote file name.  There are some obvious problems
with this, in that you now have to provide a conversion function to
every OS out there, but from the users standpoint it's kinda nice,
since they don't have to worry about the remote systems syntax.  Since
dmachines use a variety of other hosts and protocols as file servers,
as far as the user is concerned there's no difference between a
TOPS-20 host and a Unix one, they're all just the same.  For example,
{SERVER}<foo>bar>baz.text could get translated to /foo/bar/baz.text or
to <foo.bar>baz.text, depending on whether SERVER was a Unix or a Tops
host. Things like spaces and other "non-standard" characters simply
have to be escaped.


...arun


----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 05:18:36 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re:  syntax of remote pathnames?

In article <3728@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
+---------------
| > one could even imagine a file system that allowed CR, LF, or CRLF
| > in a pathname.
| 	You mean like the Unix file system?  To wit:
| $ echo xxx* | od -c
| 0000000    x   x   x  \r  \n   y   y   y  \n
+---------------

I even had a use for one of these. When bouncing around a certain LAN I got
so tired of not remembering what a given host's way to clear the screen was
(some systems had a "clear" command, others not) that I put a shell script
in my ~/bin/ on each system to do that. Since my favorite terminal (at the
time) used a form-feed to clear the screen, that's what the name of the
program was: <^L> (the single character 0x0C). Worked fine! (On Unix...)

And a certain computer company whose terminals emitted the triplet <^A>x<CR>
(for various "x") taught its "office automation" users (sec'ys, etc.) to
make "friendly" shell scripts whose names were some function key, so users
could "customize" their terminals with single buttons that, for example,
read mail. To wit:

	% vi <F3>	# note no need to type RETURN after hitting <F3>
	...edit the Function-Key-3 script...
	% chmod a+x <F3>
	% <F3>
	...and the script named "<^A>c<CR>" runs...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 13:31:21 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   RSA encryption on internet

I've been told since some government funds were used to develop
(maybe only test?) the RSA algorithm, organizations doing legitimate
(however broadly) business are not subject to the license arrangment
for either the MIT patent or from RSA Inc. Does this imply that a
seperate registration service run by "the government" will be 
set up for unclassified non-national security related (!) messages
that wish to take advantage of the RSA process?

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 18:36:00 GMT
From:      7thSon@SLCS.SLB.COM (Chris Garrigues)
To:        comp.protocols.tcp-ip
Subject:   syntax of remote pathnames?


    Date: Tue, 28 Mar 89 22:27:38 -0500
    From: Barry Shein <bzs@encore.com>


    I'm having problems understanding all the baroque (or is that rococo?)
    suggestions, let's try starting at the beginning...

What I'm having trouble understanding is why this is such a major issue
so late in OS/networking development.  I'm typing this from my Lisp
machine and from here can access files on all sorts of different hosts
with no problem.

If I want to grab a file from SRI-NIC, I say
"SRI-NIC.ARPA:<RFC>RFC-INDEX.TXT" and I get it.  If I want to write this
file onto my lisp machine file server, I say
"B:>7thson>text>RFC-index.text" and it writes there.  If I want to write
it only one of our Suns, I say "LINUS:~7thson/rfc-index" and it gets
there.  This is using an operating system which has been around for
quite a while and it's been WORKING!!!

	    foo:<bar>baz.xxx

    or

	    <foo.bar>baz.xxx

    ?

    They can both exist simultaneously and describe different files. The
    same can be true for VMS and other OS's that have this sort of thing
    for devices and logical names. Pity.

I think your problem here is in trying to force pathnames into the
rather limited Unix model.  This also loses (good handling of)
extensions and version numbers.  

    Anyhow, I think Keep It Simple might be a good plan for this one,
    trying to cover every unusual case usually makes for a bad design
    ("hard cases make bad law".)

Of course.


Chris

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 19:03:38 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re:  RSA Encryption on the Internet

In article <10159@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes:
>
>Nope, you can't do it with just one directory server.  You still need
>something additional to provide trustability of the public key someone
>hands you, and that something can not be just a simple
>public-key-signed handshake, because any such handshake assumes you
>already know the other guys' key.  There is no point in worrying about
>security of encryption algorithms until you can solve the distribution
>problem. 
>
>----Don Alvarez,   boomer@space.mit.edu


	I'm not an expert on Kerberos, but I have been reading up on
it and it seems to me that it addresses this particular problem.
Kerberos uses DES keys, but conceptually I think that this model could
be used with RSA algorithms.

	You first have to authenticate yourself to Kerberos by sending
your username to a Kerberos authentication server.  This creates a
"ticket" [Kerberos terminology] that is encrypted so the user cannot
alter it.  This ticket is used by the user to gain further tickets
from the ticket-granting server (step two).  This ticket and some
other information is further encrypted with a key derived from your
password.  This is sent back to the user.
	The user then enters his password into the workstation and a
decryption key is derived and the ticket-granting-server ticket is
produced. 
	Further transactions are conducted without user intervention
or re-entering of password with the ticket-granting server for session
keys for use of networks services.
	There are time-outs on session keys and the
ticket-granting-server ticket to limit exposure.  The user password is
only required in the system for the time it takes to decrypt the
authentication response.
	I think this addresses most of the issues that have been
raised in this thread.
	Following all these Kerberos tickets around can give you
brain-pain, but everything is transparent to the user.  In fact, you
only login to Kerberos, not every machine on the net, so user
perception of service is improved over rlogin w/o .rhosts.
	Kerberos can be used only for authenticating the start of a
connection, like Athena uses for Kerberos NFS, or it can be used to
authenticate every message, or it can be used to encrypt messages.
You choose your level of security and performance hit.
	Neat stuff in other words.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 19:50:34 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy Arp -- How is it Implemented?

RFC 925 does not describe how proxy ARP is implemented.  The RFC
proposes a new kind of packet switch, which is somewhere between a
normal IP gateway and a bridge.  ARP is used as part of the design,
but this is *not* proxy ARP as currently used.  (Indeed that term does
not occur in the RFC.)  RFC 925 is describing something that looks a
lot like a learning bridge.  Like a bridge, there is no mapping
between IP address and network topology, i.e. no subnetting.  Like a
bridge, hosts are listed individually in the routing tables, unlike
gateways, which only keep track of routes to nets and subnets (except
for the directly connected subnets, which need ARP caches).  It's an
interesting proposal, but it isn't proxy ARP as currently used.

Proxy ARP is used with conventional IP gateways (routers).  It is
exactly as you describe: a gateway responds to ARP requests for
targets on the other side of the gateway.  It decides whether to
respond to an ARP by looking in its routing tables.  There are two
uses for proxy ARP

  - some gateways implement it only for subnets of the local network.
	The intention is to handle the problem of hosts that do not
	understand subnets.

  - some gateways implement it for all destinations.  In that case it
	is possible for a host to use ARP as a gateway discovery
	technique for all destinations.

I believe proxy ARP was originally invented only to handle hosts that
don't implement subnets.  However we use the second approach at
Rutgers: where possible our hosts are set to issue ARP requests for
all destinations.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 22:53:37 GMT
From:      hrp@boring.cray.com (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   DoD stops buying uncertified TCP/IPs

I have a copy of a memo from the Assistant Secretary of Defense for
C3I, dated August 26, 1988, that says in part

    Implementations of [IP, TCP, FTP, Telnet, and SMTP] must be tested
    by a National Bureau of Standards (NBS) accredited laboratory
    prior to first operational use on any DoD network.  The
    conformance testing requirement is mandatory for all contracts
    executed after 1 June 1989.

I am surprised that this hasn't been discussed on this list, in view
of the technical difficulties of testing and philosophical questions
about the usefulness of conformance testing and certification, not to
mention the difficulty of getting an implementation to conform.  How's
it going?

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp@cray.com			uunet!cray!hrp		   +1 612 681 3145

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 89 23:05:48 GMT
From:      pquiring@ncrorl.Orlando.NCR.COM (Powell Quiring)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   slip

I'm looking for protocol descriptions for all known implementations
of slip.  I'm also looking for any sources for slip preferrably public
domain.

Powell Quiring
pquiring@Orlando.NCR.COM	..!ncrlnk!ncrorl!pquiring

VOICE: (407) 333-9250,     VOICEplus: 656-1219,      FAX: (407) 333-0050

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 00:57:04 GMT
From:      daveb@rtech.rtech.com (Dave Brower)
To:        comp.protocols.tcp-ip
Subject:   Anybody implementing RFC 1078 (TCPMUX)?

Is this RFC a bright idea or a dimming bulb?  Is anyone actively doing
anything to implement services using it?  It would seem to solve some
immediate problems, and I'd be tempted to write a *NIX server to sit on
port 1 to do it.  But if no one is interested and it's a dead end, I'll
think of something else.

-dB

[ short enough i'll just include it verbatim ]

Network Working Group                                          M. Lottor
Request For Comments: 1078                                       SRI-NIC
                                                           November 1988


                 TCP Port Service Multiplexer (TCPMUX)

Status of this Memo

   This RFC proposes an Internet standard which can be used by future
   TCP services instead of using 'well-known ports'.  Distribution of
   this memo is unlimited.

Overview

   Ports are used in the TCP to name the ends of logical connections
   which carry long term conversations.  For the purpose of providing
   services to unknown callers, a service contact port is defined.  The
   contact port is sometimes called the "well-known port".  Standard TCP
   services are assigned unique well-known port numbers in the range of
   0-255.  These ports are of limited number and are typically only
   assigned to official Internet protocols.

   This RFC defines a protocol to contact multiple services on a single
   well-known TCP port using a service name instead of a well-known
   number.  In addition, private protocols can make use of the service
   without needing an official TCP port assignment.

The Protocol

   A TCP client connects to a foreign host on TCP port 1.  It sends the
   service name followed by a carriage-return line-feed <CRLF>.  The
   service name is never case sensitive.  The server replies with a
   single character indicating positive ("+") or negative ("-")
   acknowledgment, immediately followed by an optional message of
   explanation, terminated with a <CRLF>.  If the reply was positive,
   the selected protocol begins; otherwise the connection is closed.

Service Names

   The name "HELP" is reserved.  If received, the server will output a
   multi-line message and then close the connection.  The reply to the
   name "HELP" must be a list of the service names of the supported
   services, one name per line.

   The names listed in the "Protocol and Service Names" section of the
   current edition of "Assigned Numbers" (RFC-1010 at this time) are
   reserved to have exactly the definitions specified there.  Services



Lottor                                                          [Page 1]
 
RFC 1078                         TCPMUX                    November 1988


   with distinct assigned ports must be available on those ports and may
   optionally be available via this port service multiplexer on port 1.

   Private protocols should use a service name that has a high chance of
   being unique.  A good practice is to prefix the protocol name with
   the name of your organization.

   Multiple versions of a protocol can suffix the service name with a
   protocol version number.

Implementation Notes

   A negative reply will typically be returned by the port-multiplexing
   process when it can't find the requested service.  A positive reply
   will typically be returned by the process invoked by the port
   multiplexer for the requested service.
-- 
"If it was easy, we'd hire someone cheaper than you to do it."
{amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucp

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 05:45:21 GMT
From:      koreth@ssyx.ucsc.edu (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Anybody implementing RFC 1078 (TCPMUX)?

In article <2759@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes:
>Is this RFC a bright idea or a dimming bulb?  Is anyone actively doing
>anything to implement services using it?  It would seem to solve some
>immediate problems, and I'd be tempted to write a *NIX server to sit on
>port 1 to do it.  But if no one is interested and it's a dead end, I'll
>think of something else.

[text of RFC1078 deleted]

I've implemented something similar, "supersrv."  It was sent to
comp.sources.unix some time ago, but hasn't been posted.  It does
not sit on port 1 (it's intended to be run by users, not necessarily
by sysadmins) but could be easily modified to conform to the RFC.
Hopefully it will appear on comp.sources.unix soon, and you can see
what you think.  (Mail me your comments...)  It is available for
anonymous ftp on ssyx.ucsc.edu (128.114.133.1) in pub/unix-misc.

---
These are my opinions, which you can probably ignore if you want to.
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ssyx.ucsc.edu	uunet!ucbvax!ucscc!ssyx!koreth

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 05:56:47 GMT
From:      ron@MANTA.NOSC.MIL (Ron Broersma)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip support for Sun 386 Sun OS 4.01

> This has already been done by Rayan Zachariassen at the U of Toronto for
> SunOS 4.0.  It is available for anonymous ftp from neat.ai.toronto.edu
> (128.100.1.65).  I don't remember what the name of the file(s) are.  There is
> lots of stuff in that pub directory.  Its availability was announced in the
> comp.archives group.

Has anyone seen this stuff work on a 386i?  I tried it and it seems to drop
in easy enough but I can't make it talk.  Turning on the internal debug
shows lots of M_UNHANGUP messages from the driver.  I'm not sure how that
gets generated.  It seems to be an undocumented feature of the driver.

--Ron

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Mar 89 13:53:00 EST
From:      Marshall Feldman <RLN101%URIACC.BITNET@mitvma.mit.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  syntax of remote pathnames?
Sounds much like kermits talking between different systems.  But how
would /usr/foo.bar.unix be translated to a file name on a machine running
CMS, PC-DOS, or any of the other IBM curses?
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 14:31:39 GMT
From:      balenson@TIS.COM (David M. Balenson)
To:        comp.protocols.tcp-ip
Subject:   Implementing TCP/IP outside of UNIX kernel?


Is it possible to implement TCP/IP in a UNIX (Berkeley 4.{2,3}, SunOS{3,4})
system OUTSIDE of the kernel?  I presume doing so would have a major impact
on efficiency, but it might be much easier to program.  Does anyone know o
any such TCP/IP implementations?  Thanks.

-David M. Balenson
 Trusted Information Systems
 (301) 854-5358

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 15:03:50 GMT
From:      tdh@moriaMoria.Sp.Unisys.Com (Thomas Hintz)
To:        comp.protocols.tcp-ip
Subject:   Telnet DO Option 30

I'm getting a request to DO option octal 030 from a Sun 3/160
under OS 4.0.1.  Is this standard?  What is it?  Where is it
written?


-- 
Thomas D. Hintz				(612) 687-2684
UNISYS					tdh@moria.sp.unisys.com
Custom Networks				..bungia!com50!mscunx!moria!tdh

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 16:51:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: syntax of remote pathnames?


/* Written 11:18 pm  Mar 28, 1989 by rpw3@amdcad.AMD.COM in p.cs.uiuc.edu:comp.protocols.tcp-ip */

And a certain computer company whose terminals emitted the triplet <^A>x<CR>
(for various "x") taught its "office automation" users (sec'ys, etc.) to
make "friendly" shell scripts whose names were some function key, so users
could "customize" their terminals with single buttons that, for example,
read mail. To wit:

	% vi <F3>	# note no need to type RETURN after hitting <F3>
	...edit the Function-Key-3 script...
	% chmod a+x <F3>
	% <F3>
	...and the script named "<^A>c<CR>" runs...
                          ^^^^^^^^^^^^^^^^


Uh-uh. The script named "<^A>c" runs, since the <CR> tells the shell
about the end of the input line.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 16:59:43 GMT
From:      mfidelma@bbn.com (Miles R. Fidelman)
To:        comp.protocols.tcp-ip
Subject:   RSA for files too?


Since RSA cryptography is about to show up on the Internet, maybe we
should look at extending its application to the protection of file
transers - perhaps by specifying a standard way to generate crypto-checksums
for inclusion in compressed files.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 18:21:39 GMT
From:      crocker@LA.TIS.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing TCP/IP outside of UNIX kernel?

David,

A general (and reasonably obvious) comment on your question: At the
very least, you need access to a network driver to get the data in and
out of your machine.  The connection management stuff can be
implemented as user code, but, as you suggested, may be
extraordinarily inefficient.  (Vint Cerf implemented his first version
of TCP (or perhaps NCP) this way, using one process per connection,
and the result was "of academic interest only.")

A separate but related problem is how the ordinary user processes are
going to communicate with the TCP/IP implementation.  If TCP/IP is not
available as a kernel service, then you have to connect to it via the
standard interprocess communication mechanism.  I'm not familiar with
the current IPC facilities in Unix, but somehow you'd have to set up
your TCP/IP implementation as a server.

And to answer your direct question, I'm afraid I don't know of an
implementation like this.

Zeke

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 18:43:38 GMT
From:      PCOLEMAN@MCMVM1.BITNET (Peter Coleman)
To:        comp.protocols.tcp-ip
Subject:   Re: terminal types/assigned numbers

I noticed that the IBM 3151 was not included in the list of terminals.

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 18:53:00 GMT
From:      RLN101@URIACC.BITNET (Marshall Feldman)
To:        comp.protocols.tcp-ip
Subject:   Re:  syntax of remote pathnames?

Sounds much like kermits talking between different systems.  But how
would /usr/foo.bar.unix be translated to a file name on a machine running
CMS, PC-DOS, or any of the other IBM curses?

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 20:06:39 GMT
From:      elewis@olympos.cs.umd.edu (Ed Lewis)
To:        comp.protocols.tcp-ip
Subject:   Help with VAX EXOS board needed





I am trying to get help using an EXCELAN EXOS 8044-01 TCP/IP board on a Vax
8600.  I have a specific problem, transferring a Vax channel from one
process to another via a sys$qiow(...SET__FLAGS...) call.

For those of you who, regardless of being uninterested in this subject, have
read this far in case this posting gets any better, you should hit 'n' now.
For those still here, here is a little background to my problem:

I am trying to write a simple network server program which does this:

    loop forever
       create a channel (socket, stream, etc...)
       wait for a connection
       spawn a new process
       ...and pass the channel to that process
    end loop

the new process does something like this:

    read from channel
    dump data
    acknowledge data (application-protocol ack)
    close channel
    terminate process

I am using detached process, and have all of the privileges, etc.  In fact, the
child process is launched and starts to work, but bombs on the read (I'm
using sys$qiow(...EX__READ...).  I know the top-level server process is 
correct, and all return codes, even from the offending sys$qiow
(...EX__SETFLAGS...) call, are SS$_NORMAL.

Another twist.  When I run the server, and connect from a Sun client,
I get one error code (insufficient priv.) at the EX__READ.  The next time I
run the client (from a different Sun), I get a different error at the EX__READ,
I have forgotten which specific error.

Here's the question: Has anyone ever sucessfully used the EX__SETFLAGS to
transfer the channel?  If any one has, I like to find out how it is done.
(I pass the channel number through the process name - a hack for sure, but
it gets the number there, and I don't have unsightly mailboxes. I avoid the
timing problem for now by a sleep call -- king of the hacks.)

If you can help, please try to reach me via email, I'm not on this news-
group much (and I doubt that anyone else would be that interested anyway *-)).
Thanks in advance...

Ed Lewis  elewis@palantir.gsfc.nasa.gov

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 20:40:58 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Anybody implementing RFC 1078 (TCPMUX)?

In article <2759@rtech.rtech.com>, daveb@rtech.rtech.com (Dave Brower) writes:
> Is this RFC a bright idea or a dimming bulb?  Is anyone actively doing
> anything to implement services using it?  It would seem to solve some
> immediate problems, and I'd be tempted to write a *NIX server to sit on
> port 1 to do it.  But if no one is interested and it's a dead end, I'll
> think of something else.

Inetd(1m) on at least one workstation family will support it in a not
too future release.  The control file does not seem to fit in inetd.conf,
and so will be separate.  It would be nice if we could agree on a standard
file name.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 89 21:40:44 GMT
From:      oz@yunexus.UUCP (Ozan Yigit)
To:        comp.protocols.tcp-ip
Subject:   4.3 tahoe ping.

Did anyone spent the time to fix 4.3 tahoe ping to a level
where it actually reports the time properly, say, on SUNs,
or should we do it ourselves ??

oz

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Mar 89 07:30:22 PST
From:      ron@manta.nosc.mil (Ron Broersma)
To:        attcan!lsuc!ncrcan!hcr!larry@uunet.uu.net
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Slip support for Sun 386 Sun OS 4.01
>> This has already been done by Rayan Zachariassen at the U of Toronto for
>> SunOS 4.0.  It is available for anonymous ftp from neat.ai.toronto.edu
>> (128.100.1.65).  I don't remember what the name of the file(s) are.  There is
>> lots of stuff in that pub directory.  Its availability was announced in the
>> comp.archives group.
 
>Has anyone seen this stuff work on a 386i?  I tried it and it seems to drop
>in easy enough but I can't make it talk.  Turning on the internal debug
>shows lots of M_UNHANGUP messages from the driver.  I'm not sure how that
>gets generated.  It seems to be an undocumented feature of the driver.
 
I'll answer my own question.  I did finally get it to work and it seems to
work well on the 386i.  My configuration is a 386i connected to a trailblazer
via ttya dialed in to VAX running 4.3 and Rick Adams SLIP.  Even NFS stuff
seemed to work reliably across that link, albeit rather slowly.

--Ron
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 01:27:27 GMT
From:      mark@tls.UUCP (Mark Woodward)
To:        comp.protocols.tcp-ip
Subject:   Request for tech info on TCP/IP


	I was hoping that someone out there would be able to help me.
My company is produces local area networks and is looking into TCP/IP.
It would be of great help if someone could mail me any technical/implementation
material they think may be of use to me. Thanks in advance.

Mark Woodward.
-_-_-_-_-_-_-_
utzoo!tls!mark

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 03:33:56 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   new terminal names

Here is the NEW list of terminal names that I've collected.  New names start
with an "x".  There are now 270 names vs. the 177 in RFC 1010.  If your favorite
still isn't here, let me know!  I grabbed many of these from termcap.  Some
names may not be accurate.

YES, XTERM and SUN are included!  Can anyone think of a better name for these?
Maybe a version number (X11.3) should be included?

Drew

RFC XXX - Assigned Numbers                                     1989
Terminal Type Names


                          TERMINAL TYPE NAMES

   These are the Official Terminal Type Names.  Their use is described
   in RFC 1091 [97].  The maximum length of a name is 40 characters.

   A terminal names may be up to 40 characters taken from the set of
   uppercase letters, digits, and the two punctuation characters hyphen
   and slash.  It must start with a letter, and end with a letter or
   digit.

   ADDS-CONSUL-980
   ADDS-REGENT-100
   ADDS-REGENT-20
   ADDS-REGENT-200
   ADDS-REGENT-25
   ADDS-REGENT-40
   ADDS-REGENT-60
x   ADDS-VIEWPOINT
x   ADDS-VIEWPOINT-60
x   AED-512
x   AMPEX-DIALOGUE-210
   AMPEX-DIALOGUE-80
x   AMPEX-210
x   AMPEX-230
x   ANDERSON-JACOBSON-510
   ANDERSON-JACOBSON-630
   ANDERSON-JACOBSON-832
   ANDERSON-JACOBSON-841
   ANN-ARBOR-AMBASSADOR
x   ANSI
   ARDS
   BITGRAPH
   BUSSIPLEXER
   CALCOMP-565
   CDC-456
   CDI-1030
   CDI-1203
x   C-ITOH-101
x   C-ITOH-50
x   C-ITOH-80
   CLNZ
   COMPUCOLOR-II
   CONCEPT-100
   CONCEPT-104
   CONCEPT-108
   DATA-100
   DATA-GENERAL-6053
   DATAGRAPHIX-132A
   DATAMEDIA-1520
   DATAMEDIA-1521
   DATAMEDIA-2500
   DATAMEDIA-3025
   DATAMEDIA-3025A
   DATAMEDIA-3045
   DATAMEDIA-3045A
   DATAMEDIA-DT80/1
   DATAPOINT-2200
   DATAPOINT-3000
   DATAPOINT-3300
   DATAPOINT-3360
   DEC-DECWRITER-I
   DEC-DECWRITER-II
x   DEC-GIGI
   DEC-GT40
   DEC-GT40A
   DEC-GT42
   DEC-LA120
   DEC-LA30
   DEC-LA36
   DEC-LA38
   DEC-VT05
   DEC-VT100
x   DEC-VT101
x   DEC-VT102
x   DEC-VT125
x   DEC-VT131
   DEC-VT132
x   DEC-VT200
x   DEC-VT220
x   DEC-VT240
x   DEC-VT241
x   DEC-VT300
x   DEC-VT320
x   DEC-VT340
   DEC-VT50
   DEC-VT50H
   DEC-VT52
x   DEC-VT55
x   DEC-VT61
x   DEC-VT62
   DELTA-DATA-5000
x   DELTA-DATA-NIH-7000
   DELTA-TELTERM-2
   DIABLO-1620
   DIABLO-1640
   DIGILOG-333
   DTC-300S
x   DTC-382
   EDT-1200
   EXECUPORT-4000
   EXECUPORT-4080
x   FACIT-TWIST-4440
x   FREEDOM-100
x   FREEDOM-110
x   FREEDOM-200
   GENERAL-TERMINAL-100A
x   GENERAL-TERMINAL-101
   GSI
x   HAZELTINE-1420
   HAZELTINE-1500
   HAZELTINE-1510
   HAZELTINE-1520
x   HAZELTINE-1552
   HAZELTINE-2000
x   HAZELTINE-ESPRIT
x   HP-2392
   HP-2621
   HP-2621A
   HP-2621P
x   HP-2623
   HP-2626
   HP-2626A
   HP-2626P
x   HP-2627
   HP-2640
   HP-2640A
   HP-2640B
   HP-2645
   HP-2645A
   HP-2648
   HP-2648A
   HP-2649
   HP-2649A
x   IBM-1050
x   IBM-2741
   IBM-3101
   IBM-3101-10
   IBM-3275-2
   IBM-3276-2
   IBM-3276-3
   IBM-3276-4
   IBM-3277-2
   IBM-3278-2
   IBM-3278-3
   IBM-3278-4
   IBM-3278-5
   IBM-3279-2
   IBM-3279-3
x   IBM-5151
x   IBM-5154
x   IBM-5081
x   IBM-6153
x   IBM-6154
x   IBM-6155
x   IBM-AED
   IMLAC
   INFOTON-100
x   INFOTON-400
   INFOTONKAS
   ISC-8001
x   LSI-ADM-1
x   LSI-ADM-11
x   LSI-ADM-12
x   LSI-ADM-2
x   LSI-ADM-20
x   LSI-ADM-22
x   LSI-ADM-220
   LSI-ADM-3
   LSI-ADM-31
   LSI-ADM-3A
   LSI-ADM-42
x   LSI-ADM-5
   MEMOREX-1240
   MICROBEE
   MICROTERM-ACT-IV
   MICROTERM-ACT-V
x   MICROTERM-ERGO-301
   MICROTERM-MIME-1
   MICROTERM-MIME-2
x   MICROTERM-ACT-5A
x   MICROTERM-TWIST
x   NEC-5520
   NETRONICS
   NETWORK-VIRTUAL-TERMINAL
   OMRON-8025AG
   PERKIN-ELMER-1100
   PERKIN-ELMER-1200
x   PERKIN-ELMER-550
   PERQ
   PLASMA-PANEL
   QUME-SPRINT-5
x   QUME-101
x   QUME-102
   SOROC
   SOROC-120
   SOUTHWEST-TECHNICAL-PRODUCTS-CT82
x   SUN
   SUPERBEE
   SUPERBEE-III-M
   TEC
x   TEKTRONIX-4006
   TEKTRONIX-4010
   TEKTRONIX-4012
   TEKTRONIX-4013
   TEKTRONIX-4014
   TEKTRONIX-4023
   TEKTRONIX-4024
   TEKTRONIX-4025
   TEKTRONIX-4027
x   TEKTRONIX-4105
x   TEKTRONIX-4107
x   TEKTRONIX-4110
x   TEKTRONIX-4112
x   TEKTRONIX-4113
x   TEKTRONIX-4114
x   TEKTRONIX-4115
x   TEKTRONIX-4125
x   TEKTRONIX-4404
   TELERAY-1061
   TELERAY-3700
   TELERAY-3800
   TELETEC-DATASCREEN
   TELETERM-1030
   TELETYPE-33
   TELETYPE-35
   TELETYPE-37
   TELETYPE-38
x   TELETYPE-40
   TELETYPE-43
x   TELEVIDEO-910
   TELEVIDEO-912
   TELEVIDEO-920
   TELEVIDEO-920B
   TELEVIDEO-920C
x   TELEVIDEO-925
x   TELEVIDEO-955
   TELEVIDEO-950
x   TELEVIDEO-970
x   TELEVIDEO-975
   TERMINET-1200
   TERMINET-300
   TI-700
   TI-733
   TI-735
   TI-743
   TI-745
x   TI-800
   TYCOM
   UNIVAC-DCT-500
   VIDEO-SYSTEMS-1200
   VIDEO-SYSTEMS-5000
x   VOLKER-CRAIG-303
x   VOLKER-CRAIG-303A
x   VOLKER-CRAIG-404
   VISUAL-200
x   VISUAL-55
x   WYSE-30
x   WYSE-50
x   WYSE-60
x   WYSE-75
x   WYSE-85
   XEROX-1720
x   XTERM
   ZENITH-H19
x   ZENITH-Z29
   ZENTEC-30

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 06:15:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   FTP 421 reply action

RFC 959 does not explicitly state what action a user-ftp must take
when it receives a 421 reply code (closing control channel).  Is it
supposed to wait for the telnet close to be received before issuing a
prompt to the user or start a timer and close the connection itself,
or ?

Why I bring this up is that I received a message from a remote ftp
user who received a 421 reply code from us, got his user prompt,
attempted another ftp command, and his user ftp told him he must close
the connection first.  He was assuming that because this happened, we
were not closing the connection, and we do.  My response to him was
that his user ftp should not have prompted him until the connection
was closed.  I believe the RFC and the Host Requirements RFC should be
revised to clarify this matter.

--Frank

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 10:34:36 GMT
From:      jpo@cs.nott.ac.uk (Julian Onions)
To:        comp.protocols.tcp-ip
Subject:   Some alternatives to OSI


Received: from roof.gardenshed.jocks-cabin by patio.macmiggins.stornoway via
	shoutnet; 21 Jan 89 20:50 SST
Received: from patio.macmiggins.stornoway by bonfire.oban.beaconnet via 
	infernonet; 25 Feb 89 15:31 SST
Received: from bonfire.oban.beaconnet by cs.nott.ac.uk via 
	cannet; 30 Mar 89 21:43 BST
To: jpo@cs.nott.ac.uk
From: jock@gardenshed.jocks-cabin
Subject: Alternative protocols
Date: Fri, 21 Jan 89 20:50 SST

			 Alternatives to OSI
			 ===================

			by Jock C. St. Martin

		   University of the Outer Hebrides
			       Scotland

Following recent discussions concerning the relative merits of OSI and
ARPA protocols, I decided to throw my hat into the ring.  Furthermore,
I believe that the ARPA protocols are not the only contenders with
OSI, and that a number of even more "mature" mechanisms exist. I
present seven possibilities for consideration.

1. Bean tins and bits of string
------------------------------- 

The use of bean tins and taut pieces of string has long been
recognised as an effective means of communication. In fact,
excavations from Anglo-Saxon dwellings in Nottingham show their use
(albeit with imported coconuts as opposed to bean tins) in early
everyday office situations.

Bean tins and string have several advantages over OSI:

	a. They are fast, light weight and portable.
	b. They don't require the purchase of expensive computers.
	c. Complex error correction (based on the "NO - I said ..."
	   principal) 
	d. Uses off the supermarket shelf technology.
	e. They were not invented by the ISO.

They also exhibit a very few trifling limitations:

	a. Poor support for "packet" switching (however, tin switching may be
	   supported).
	b. Users often cut themselves on the tins.
	c. Star network topologies become more complex.
	d. They don't scale very well.

2. Shouting from the roof tops
------------------------------

Shouting from the rooftops can be an effective method of optimised
local area communication. It is based on the well understood CMSA/CD
technology but with the notion of priority. Users can insert high
priority traffic with the "If I might get a word in edgeways" packet.
It is already in widespread use - e.g., the House of Commons,
political canvassing and Speakers Corner. Naturally, a roof top is
only necessary for high bandwidth traffic. The PTT's would probably
assume this role. The average user would be content to shout in the
street.

Shouting has many advantages over OSI:

	a. It is not as "complex and obscure".
	b. Most people understand shouting.
	c. Broadcasts are easy.
	d. Its fun.
	e. It wasn't invented by the ISO

OSI has hardly any advantages over shouting:

3. Burning beacons on hill-tops:
---------------------------------

Burning beacons on hill-tops have long been used to warn of advancing
Armadas and their like. However, the author believes that beacons may
have wider applications than just these.

In particular, they have the following advantages over OSI:

	a. No "dangerous checkpointing".
	b. They keep you warm.
	c. Not overly complex and obscure.
	d. A secondary use for the disposal of those nasty ISO people.
	e. Not cluttered with unnecessary functionality.
	f. Not invented by the ISO.

Disadvantages to OSI:

	a. Not suitable for the office environment (this may really be
	   an advantage in some circumstances).
	b. Low bandwidth (may also be an advantage - see 7)
	c. Error rates can be high. Arsonists, pyromaniacs and
	   "Satanic Verses" burners can generate spoof packets. 

4. Semaphore
------------

Semaphore has been in use for many years. So why did ISO not consider
this for international internetworking? This is difficult to
determine, but is probably due to political motivations rather than
any deficiencies in the protocols. Naturally there are a few rough
edges to be addressed.

Advantages over OSI

	a. Broadcasts are easily accommodated.
	b. Widely supported off-the-shelf infra-structure (boy scouts).
	c. Not invented by ISO

Disadvantages over OSI

	a. Not so useful at night (but a working party on luminous
	   flags is in progress).
	b. Bandwidth is rather low - but automation should help.


5. Messages in bottles
----------------------

This is a low cost solution to networking. Bottles are easy to obtain
and with a little development, this neglected backwater of
communications technology could be a real alternative.

Advantages over OSI

	a. High bandwidth data channels already in existence (e.g. the
	   gulf stream, rivers and sewers.)
	b. Large amounts of data can be placed in the appropriate
	   sized bottles.
	c. Not invented by ISO.

Disadvantages to OSI

	a. Transit time is unpredictable (but then IP, for instance,
	   does not guarantee any bounded delivery time)


6. The Telephone
----------------

This might be seen as an enhancement of method 2. However, there is a
lot to be gained from this approach. The name lookup problem is
already solved as are routing issues. Lets face it, communications
protocols are ultimately used for communicating between people. So why
not just standardise the telephone. Add on services such as broadcast
agents (commonly called gossips/operators) are easy to achieve.

Advantages over OSI

	a. Its a mature existing technology.
	b. Directory services issues, routing and charging are 
	   already established.
	c. It's now available in portable form.
	d. Not invented by ISO

Disadvantages to OSI

	a. Because it's a mature technology, there aren't so many
	   interesting research areas.
	b. As a result of 2. there are few exotic conference openings.
	c. It costs money.

7. Not communicating at all
---------------------------

One question I asked myself was "why communicate at all?"  On
consideration it was realised that not communicating has the following
advantages over OSI.

	a. Low consumption of bandwidth.
	b. Cheap and easy to manage.
	c. No one disagrees with you.
	d. Without the time wasted on communication, other business
	   proceeds much quicker.
	e. Not invented by the ISO

No known disadvantages to OSI.


The ARPA protocols.
----------------------

The ARPA protocols deserve consideration along with many of the above
mentioned methods of communication.  In particular, they have one
major advantage over OSI.

	a. Not invented by the ISO

However, despite this overwhelming advantage of the Internet protocol
suite, the ISO proponents simply will not give in. In this section I
therefore give a few other reasons for the superiority of the Internet
suite - as if 1. was not enough.

Scalability. The Internet protocols are obviously scalable as has been
proved time and time again. All that is required is for the PTT's to
take the sensible step of providing a network infra-structure and the
rest can be solved. Charging is easily accommodated - the PTT's pick
up the bills.

Network interface. Many people have commented on how convenient it is
to have a network address which fits into a common word size. This is
such a advantage that the limitations are really insignificant. If the
address space ever gets used up there is an obvious extension
mechanism - the waiting list.

Session layer. The Internet suite sensibly disregarded session
services as superfluous. As has been observed, checkpointing is
inherently dangerous as it can lead to loss of network usage and
revenue. OSI has been influenced by the Internet community here, and
has provided a session service complex enough that most
implementations try and ignore it.

Presentation layer. Again the Internet triumphs. It is quite clear
that for the most part applications only need to exchange data
consisting of bytes of 8, 16 and 32 bit quantities. These simple
structures can be used as building blocks to construct almost any
structure required. If this is not sufficient, there is a simple
escape mechanism provided, known in the jargon as a "string encoding".
It is quite clear that ASN.1 is just over the top - CHOICE's and
OPTIONAL's are for quiche-eating indecisive applications.

Application layer. Well the Internet has got this one too. Honestly,
it's quite obvious that each application should do its own thing.
That's what they're there for. If an application needs remote
procedure call interface, or security, or name lookup, then it can do
it itself rather than forcing it to use some more general service like
ROS or directory services.

SUMMARY
-------

In summary, I feel that all of the above methods are orders of
magnitude better than OSI (which incidently, and by coincidence,
wasn't invented here). In particular, I feel that method 7 offers the
greatest potential and, with this in mind, WE DO NOT WELCOME ANY
FURTHER COMMENTS YOU MIGHT HAVE!


Author's note
------------- 

This article is in no way connected with either Julian Onions or Steve
Benford of the University of Nottingham beyond their role as postal
agents for the author.

-- 
Julian Onions

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 13:35:56 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Van Jacobson's improved TCP code

I noticed a note a few months ago that Van Jacobson's new TCP code was
available from berkeley.edu via anonymous ftp. I do not have internet
access and was wondering if I could get it via uucp (or could someone send
it to me ??). Any assistance or information would be GREATLY appreciated.

------------------------------------------------------------------------------
					Mark Andrews
					Systems Programmer,
					Alias Research,
					Toronto, Canada
					1-(416)-362-9181

					alias!mark@utcsri.uucp

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 16:35:12 GMT
From:      dpz@pilot.njin.net (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   new rev of YARD tool (ping!)


Gosh I love that acronym... :-)

I got some fixes back from Jeffry Mogul @ DECWRL.  Among other things, the big
fix is that my IP option munging code didn't deal with 0 in any of the address
octets very well.  (That's what I get for living in a sheltered environment!)

New src/ping.shar available on rutgers.edu via anonymous FTP.

						David
-- 
David Paul Zimmerman                                 Rutgers University
dpz@pilot.njin.net         rutgers!dpz        dpzimmerman@zodiac.bitnet

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 89 18:10:25 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.sys.encore
Subject:   Re: An Annex by any other nameserver would smell...

RWHOD is a pretty lousy program in that each machine broadcasts it's
users every 3-5 minutes.  That Encore ever used that for getting name
to address matching is an extreme kludge.  They ought to be embarassed.
Part of the rwho message is an indication of the system load and
how long it's been up (as displayed by the ruptime command on UNIX).

IEN-116 was the original name server, but it never really hit wide
use.  It is trivial to implement, and hence you can get it going on
nearly anything that has UDP on it.

BIND is the name of the Berkeley program that implements the IP
Domain Name Service on UNIX.  This is really what people ought
to be using these days, and is really required if you are in a
large network environment or are connected to the Internet at large.

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 April 89 00:00:01 EST
From:      seven@ftam.com  (Benjamin M. Levy, FTAM Hardware Inc.)
To:        comp.protocols.tcp-ip,rec.gardens tcp-ip@sri-nic.arpa
Subject:   LAWNWatch
FTAM Hardware, Incorporated
26 Princess St
Wakefield, MA

Press Release
Hold Until 4/1/89

Press contact:
Benjamin Levy
(617) 246-0900



L A W N W A T C H 
- - - - - - - - -


  The LATEST in LAWN Management systems.


  LAWNwatch allows you to examine the traffic across your LAWN.


  LAWNwatch understands many types of traffic, such as:

    - TCP/IP: Turf Control Procedure for Insect Prevention.

    - ICMP:   Insecticide Control, Managment, and Procuring.

    - SNMP:   Seedling Nurturing and Maintainance Program.

    - SMTP:   Soil Manure Treatment Procedure.

    - TFTP:   Tree Foliage Trimming Practices.

    - FTP:    Fertilizer Transfer Procedure.

    - UDP:    Underground Dirt Placement.

    - ADP:    Aphid Detection Procedure.

    - ATP:    Aphid Termination Procedure.

    - CIA:    Control of Insect Activity.

    - KGB:    Kentucky Grass: Blue.

    - RVD:    Real Virtual Dirt.


    Compatible with pARCNET, TENNIS-Net, DECK-Net, and Vines.
LAWNWatch works with Underground-Bass and Eastern Dig-It-All earthnet
cards.  LAWNWatch is not compatible with IBM's (International Bug and
Mushroom) Toadstool Ring Adapter.

    LAWNWatch is based upon RFC (Request For Compost) 825 written
by J. Post-Hole.




END OF DOCUMENT